Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

I fixed all the dangling links. All dangling links route properly now #1195

Open
wants to merge 1 commit into
base: develop
Choose a base branch
from
Open
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Jump to
Jump to file
Failed to load files.
Diff view
Diff view
8 changes: 5 additions & 3 deletions 02intro.asciidoc
Original file line number Diff line number Diff line change
Expand Up @@ -251,7 +251,7 @@ You can explore the transaction history of any address. Take a look at the trans

((("Ethereum (generally)","and EVM")))((("EVM (Ethereum Virtual Machine)","as world computer")))((("world computer, Ethereum as")))You've now created a wallet and sent and received ether. So far, we've treated Ethereum as a cryptocurrency. But Ethereum is much, much more. In fact, the cryptocurrency function is subservient to Ethereum's function as a decentralized world computer. ((("smart contracts","ether and")))Ether is meant to be used to pay for running _smart contracts_, which are computer programs that run on an emulated computer called the _Ethereum Virtual Machine_ (EVM).

The EVM is a global singleton, meaning that it operates as if it were a global, single-instance computer, running everywhere. Each node on the Ethereum network runs a local copy of the EVM to validate contract execution, while the Ethereum blockchain records the changing _state_ of this world computer as it processes transactions and smart contracts. We'll discuss this in much greater detail in <<evm_chapter>>.
The EVM is a global singleton, meaning that it operates as if it were a global, single-instance computer, running everywhere. Each node on the Ethereum network runs a local copy of the EVM to validate contract execution, while the Ethereum blockchain records the changing _state_ of this world computer as it processes transactions and smart contracts. We'll discuss this in much greater detail in xref:13evm.asciidoc#evm_chapter[evm_chapter].

[[EOA_contracts]]
=== Externally Owned Accounts (EOAs) and Contracts
Expand All @@ -267,7 +267,7 @@ In the next few sections, we will write our first contract. You will then learn
[[simple_contract_example]]
=== A Simple Contract: A Test Ether Faucet

((("contract accounts","creating", seealso="Faucet.sol contract", id="ix_02intro-asciidoc10", range="startofrange")))((("Faucet.sol contract (test example)","creating", id="ix_02intro-asciidoc11", range="startofrange")))Ethereum has many different high-level languages, all of which can be used to write a contract and produce EVM bytecode. You can read about many of the most prominent and interesting ones in <<high_level_languages>>. One high-level language is by far the dominant choice for smart contract programming: Solidity. ((("Wood, Dr. Gavin","and Solidity")))Solidity was created by Dr. Gavin Wood, the coauthor of this book, and has become the most widely used language in Ethereum (and beyond). We'll use Solidity to write our first contract.
((("contract accounts","creating", seealso="Faucet.sol contract", id="ix_02intro-asciidoc10", range="startofrange")))((("Faucet.sol contract (test example)","creating", id="ix_02intro-asciidoc11", range="startofrange")))Ethereum has many different high-level languages, all of which can be used to write a contract and produce EVM bytecode. You can read about many of the most prominent and interesting ones in xref:07smart-contracts-solidity.asciidoc#high_level_languages[high_level_languages]. One high-level language is by far the dominant choice for smart contract programming: Solidity. ((("Wood, Dr. Gavin","and Solidity")))Solidity was created by Dr. Gavin Wood, the coauthor of this book, and has become the most widely used language in Ethereum (and beyond). We'll use Solidity to write our first contract.

((("Solidity","faucet.sol and")))For our first example (<<solidity_faucet_example>>), we will write a contract that controls a _faucet_. You've already used a faucet to get test ether on the Ropsten test network. A faucet is a relatively simple thing: it gives out ether to any address that asks, and can be refilled periodically. You can implement a faucet as a wallet controlled by a human or a web server.

Expand Down Expand Up @@ -542,4 +542,6 @@ Next, you wrote a faucet contract in Solidity. You used the Remix IDE to compile

It may not seem like much, but you've just successfully interacted with software that controls money on a decentralized world computer.

We will do a lot more smart contract programming in <<smart_contracts_chapter>> and learn about best practices and security considerations in <<smart_contract_security>>.(((range="endofrange", startref="ix_02intro-asciidoc0")))
We will do a lot more smart contract programming in xref:07smart-contracts-solidity.asciidoc[smart_contracts_chapter]
and learn about best practices and security considerations in xref:09smart-contracts-security.asciidoc[smart_contract_security].(((range="endofrange",
startref="ix_02intro-asciidoc0")))
2 changes: 1 addition & 1 deletion 03clients.asciidoc
Original file line number Diff line number Diff line change
Expand Up @@ -5,7 +5,7 @@

Ethereum is an open source project, and the source code for all the major clients is available under open source licenses (e.g., LGPL v3.0), free to download and use for any purpose. _Open source_ means more than simply free to use, though. It also means that Ethereum is developed by an open community of volunteers and can be modified by anyone. More eyes means more trustworthy code.

((("Yellow Paper specification")))Ethereum is defined by a formal specification called the "Yellow Paper" (see <<references>>).
((("Yellow Paper specification")))Ethereum is defined by a formal specification called the "Yellow Paper" (see xref:01what-is.asciidoc#references[references]).

((("Bitcoin","Ethereum definition compared to")))This is in contrast to, for example, Bitcoin, which is not defined in any formal way. Where Bitcoin's "specification" is the reference implementation Bitcoin Core, Ethereum's specification is documented in a paper that combines an English and a mathematical (formal) specification. This formal specification, in addition to various Ethereum Improvement Proposals, defines the standard behavior of an Ethereum pass:[<span class="keep-together">client</span>]. The Yellow Paper is periodically updated as major changes are made to pass:[<span class="keep-together">Ethereum</span>].

Expand Down
8 changes: 4 additions & 4 deletions 04keys-addresses.asciidoc
Original file line number Diff line number Diff line change
Expand Up @@ -12,13 +12,13 @@ In this chapter we will introduce some of the cryptography used in Ethereum: nam

((("cryptography","keys and addresses")))((("EOA (Externally Owned Account)","keys and addresses")))((("keys and addresses")))As we saw earlier in the book, Ethereum has two different types of accounts: _externally owned accounts_ (EOAs) and _contracts_. Ownership of ether by EOAs is established through digital _private keys_, _Ethereum addresses_, and _digital signatures_. ((("private keys", seealso="keys and addresses")))The private keys are at the heart of all user interaction with Ethereum. In fact, account addresses are derived directly from private keys: a private key uniquely determines a single Ethereum address, also known as an _account_.

Private keys are not used directly in the Ethereum system in any way; they are never transmitted or stored on Ethereum. That is to say that private keys should remain private and never appear in messages passed to the network, nor should they be stored on-chain; only account addresses and digital signatures are ever transmitted and stored on the Ethereum system. For more information on how to keep private keys safe and secure, see <<control_responsibility>> and <<wallets_chapter>>.
Private keys are not used directly in the Ethereum system in any way; they are never transmitted or stored on Ethereum. That is to say that private keys should remain private and never appear in messages passed to the network, nor should they be stored on-chain; only account addresses and digital signatures are ever transmitted and stored on the Ethereum system. For more information on how to keep private keys safe and secure, see xref:02intro.asciidoc#control_responsibility[control_responsibility] and xref:05wallets.asciidoc[wallets_chapter].

((("digital signatures")))Access and control of funds is achieved with digital signatures, which are also created using the private key. Ethereum transactions require a valid digital signature to be included in the blockchain. Anyone with a copy of a private key has control of the corresponding account and any ether it holds. Assuming a user keeps their private key safe, the digital signatures in Ethereum transactions prove the true owner of the funds, because they prove ownership of the private key.

((("key pairs")))In public key cryptography&#x2013;based systems, such as that used by Ethereum, keys come in pairs consisting of a private (secret) key and a public key. Think of the public key as similar to a bank account number, and the private key as similar to the secret PIN; it is the latter that provides control over the account, and the former that identifies it to others. The private keys themselves are very rarely seen by Ethereum users; for the most part, they are stored (in encrypted form) in special files and managed by Ethereum wallet software.

In the payment portion of an Ethereum transaction, the intended recipient is represented by an Ethereum address, which is used in the same way as the beneficiary account details of a bank transfer. As we will see in more detail shortly, an Ethereum address for an EOA is generated from the public key portion of a key pair. However, not all Ethereum addresses represent public–private key pairs; they can also represent contracts, which, as we will see in <<smart_contracts_chapter>>, are not backed by private keys.
In the payment portion of an Ethereum transaction, the intended recipient is represented by an Ethereum address, which is used in the same way as the beneficiary account details of a bank transfer. As we will see in more detail shortly, an Ethereum address for an EOA is generated from the public key portion of a key pair. However, not all Ethereum addresses represent public–private key pairs; they can also represent contracts, which, as we will see in xref:07smart-contracts-solidity.asciidoc[smart_contracts_chapter], are not backed by private keys.

In the rest of this chapter, we will first explore basic cryptography in a bit more detail and explain the mathematics used in Ethereum. Then we will look at how keys are generated, stored, and managed. Finally, we will review the various encoding formats used to represent private keys, public keys, and addresses.

Expand Down Expand Up @@ -50,7 +50,7 @@ Take a look at the following resources if you're interested in reading more abou
* http://bit.ly/2zfeKCP[Elliptic curve cryptography]
====

In Ethereum, we use public key cryptography (also known as asymmetric cryptography) to create the public–private key pair we have been talking about in this chapter. They are considered a "pair" because the public key is derived from the private key. Together, they represent an Ethereum account by providing, respectively, a publicly accessible account handle (the address) and private control over access to any ether in the account and over any authentication the account needs when using smart contracts. ((("digital signatures","private key and")))The private key controls access by being the unique piece of information needed to create _digital signatures_, which are required to sign transactions to spend any funds in the account. Digital signatures are also used to authenticate owners or users of contracts, as we will see in <<smart_contracts_chapter>>.
In Ethereum, we use public key cryptography (also known as asymmetric cryptography) to create the public–private key pair we have been talking about in this chapter. They are considered a "pair" because the public key is derived from the private key. Together, they represent an Ethereum account by providing, respectively, a publicly accessible account handle (the address) and private control over access to any ether in the account and over any authentication the account needs when using smart contracts. ((("digital signatures","private key and")))The private key controls access by being the unique piece of information needed to create _digital signatures_, which are required to sign transactions to spend any funds in the account. Digital signatures are also used to authenticate owners or users of contracts, as we will see in xref:07smart-contracts-solidity.asciidoc[smart_contracts_chapter].

[TIP]
====
Expand Down Expand Up @@ -631,4 +631,4 @@ The capitalization of the address we input doesn't match the checksum just calcu
[[keys-addresses-conclusions]]
=== Conclusions

In this chapter we provided a brief survey of public key cryptography and focused on the use of public and private keys in Ethereum and the use of cryptographic tools, such as hash functions, in the creation and verification of Ethereum addresses. We also looked at digital signatures and how they can demonstrate ownership of a private key without revealing that private key. In <<wallets_chapter>>, we will put these ideas together and look at how wallets can be used to manage collections of keys.(((range="endofrange", startref="ix_04keys-addresses-asciidoc0")))
In this chapter we provided a brief survey of public key cryptography and focused on the use of public and private keys in Ethereum and the use of cryptographic tools, such as hash functions, in the creation and verification of Ethereum addresses. We also looked at digital signatures and how they can demonstrate ownership of a private key without revealing that private key. In xref:05wallets.asciidoc[wallets_chapter], we will put these ideas together and look at how wallets can be used to manage collections of keys.(((range="endofrange", startref="ix_04keys-addresses-asciidoc0")))
4 changes: 2 additions & 2 deletions 05wallets.asciidoc
Original file line number Diff line number Diff line change
Expand Up @@ -5,7 +5,7 @@

At a high level, a wallet is a software application that serves as the primary user interface to Ethereum. The wallet controls access to a user's money, managing keys and addresses, tracking the balance, and creating and signing transactions. In addition, some Ethereum wallets can also interact with contracts, such as ERC20 tokens.

((("wallets","defined")))More narrowly, from a programmer's perspective, the word _wallet_ refers to the system used to store and manage a user's keys. Every wallet has a key-management component. For some wallets, that's all there is. Other wallets are part of a much broader category, that of _browsers_, which are interfaces to Ethereum-based decentralized applications, or _DApps_, which we will examine in more detail in <<decentralized_applications_chap>>. There are no clear lines of distinction between the various categories that are conflated under the term wallet.
((("wallets","defined")))More narrowly, from a programmer's perspective, the word _wallet_ refers to the system used to store and manage a user's keys. Every wallet has a key-management component. For some wallets, that's all there is. Other wallets are part of a much broader category, that of _browsers_, which are interfaces to Ethereum-based decentralized applications, or _DApps_, which we will examine in more detail in xref:12dapps.asciidoc[decentralized_applications_chap]. There are no clear lines of distinction between the various categories that are conflated under the term wallet.

In this chapter we will look at wallets as containers for private keys, and as systems for managing these keys.

Expand Down Expand Up @@ -419,4 +419,4 @@ Because BIP-44 was created originally for Bitcoin, it contains a "quirk" that is

=== Conclusions

Wallets are the foundation of any user-facing blockchain application. They allow users to manage collections of keys and addresses. Wallets also allow users to demonstrate their ownership of ether, and authorize transactions, by applying digital signatures, as we will see in <<tx_chapter>>.(((range="endofrange", startref="ix_05wallets-asciidoc0")))
Wallets are the foundation of any user-facing blockchain application. They allow users to manage collections of keys and addresses. Wallets also allow users to demonstrate their ownership of ether, and authorize transactions, by applying digital signatures, as we will see in xref:06transactions.asciidoc[tx_chapter].(((range="endofrange", startref="ix_05wallets-asciidoc0")))