From 4eadebbb5154c6bdba63cf568aef672017d4ff6e Mon Sep 17 00:00:00 2001 From: Evan Blank <32708219+evanblank3@users.noreply.github.com> Date: Sun, 13 Mar 2022 11:17:03 -0400 Subject: [PATCH 01/16] fix: oder to order --- book/01__consensus/02__crash-faults.md | 2 +- zh-CN/book/01__consensus/02__crash-faults.md | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/book/01__consensus/02__crash-faults.md b/book/01__consensus/02__crash-faults.md index afce9c1..63083aa 100644 --- a/book/01__consensus/02__crash-faults.md +++ b/book/01__consensus/02__crash-faults.md @@ -18,7 +18,7 @@ Computers are, unsurprisingly, the foundation of computational systems. However, Communication lines between computers are similarly abstracted to remove any notion of an underlying physical medium. Whether information is transferred via electromagnetic waves, sound waves, or even carrier pigeon makes no difference to our analysis. We instead depict "logical" connections between nodes, over which nodes can send distinct packets of information called "messages." We further assume that some unknown amount of time must elapse between the moment that a message is sent and the moment at which it is received. -Lines of communication are necessary but not sufficient for collaboration between nodes. Just as humans need languages, nodes must share a vocabulary of sorts in oder to successfully send and receive information. These communication "protocols" allow nodes to understand the meaning of messages on the network. We generally do not define any specific communication protocol in theoretical network studies, though we do assume that one exists. +Lines of communication are necessary but not sufficient for collaboration between nodes. Just as humans need languages, nodes must share a vocabulary of sorts in order to successfully send and receive information. These communication "protocols" allow nodes to understand the meaning of messages on the network. We generally do not define any specific communication protocol in theoretical network studies, though we do assume that one exists. ### Protocols as a set of behaviors diff --git a/zh-CN/book/01__consensus/02__crash-faults.md b/zh-CN/book/01__consensus/02__crash-faults.md index afce9c1..63083aa 100644 --- a/zh-CN/book/01__consensus/02__crash-faults.md +++ b/zh-CN/book/01__consensus/02__crash-faults.md @@ -18,7 +18,7 @@ Computers are, unsurprisingly, the foundation of computational systems. However, Communication lines between computers are similarly abstracted to remove any notion of an underlying physical medium. Whether information is transferred via electromagnetic waves, sound waves, or even carrier pigeon makes no difference to our analysis. We instead depict "logical" connections between nodes, over which nodes can send distinct packets of information called "messages." We further assume that some unknown amount of time must elapse between the moment that a message is sent and the moment at which it is received. -Lines of communication are necessary but not sufficient for collaboration between nodes. Just as humans need languages, nodes must share a vocabulary of sorts in oder to successfully send and receive information. These communication "protocols" allow nodes to understand the meaning of messages on the network. We generally do not define any specific communication protocol in theoretical network studies, though we do assume that one exists. +Lines of communication are necessary but not sufficient for collaboration between nodes. Just as humans need languages, nodes must share a vocabulary of sorts in order to successfully send and receive information. These communication "protocols" allow nodes to understand the meaning of messages on the network. We generally do not define any specific communication protocol in theoretical network studies, though we do assume that one exists. ### Protocols as a set of behaviors From a5d6f0e8b78cc750f889ee38b921b26cabecedaa Mon Sep 17 00:00:00 2001 From: Evan Blank <32708219+evanblank3@users.noreply.github.com> Date: Sun, 13 Mar 2022 11:48:56 -0400 Subject: [PATCH 02/16] fix: cause to case --- book/01__consensus/03__byzantine-faults.md | 2 +- zh-CN/book/01__consensus/03__byzantine-faults.md | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/book/01__consensus/03__byzantine-faults.md b/book/01__consensus/03__byzantine-faults.md index 273d19e..3706aa0 100644 --- a/book/01__consensus/03__byzantine-faults.md +++ b/book/01__consensus/03__byzantine-faults.md @@ -39,4 +39,4 @@ If the commander is a traitor, more formal reasoning is necessary to see the cor A traitorous commanding general could coordinate with other traitors to attempt to give loyal generals different sets of orders. For instance, the traitors could choose to only send the conflicting order to half of the loyal generals. Without further communication, the loyal generals would not act in unison. We can provide a simple solution by requiring that loyal generals relay conflicting orders to all other generals. After this second round of communication, all loyal generals are guaranteed to share the same information. The paper shows that we can achieve the same result if loyal generals only relay orders with less than `f` votes, where `f` is the maximum number of traitors that can be safely handled by the system. -One way to understand the `3f + 1` general requirement for `f` traitors is again through the lens of a "threshold" for carrying out an action. In the context of crash-faults, we needed a threshold of `n - f` votes in order to make a decision. Since crashed nodes could not vote, we could derive that all of the `n - f` votes came from properly functioning nodes. When the faulty nodes, in this cause our traitorous generals, can actually contribute to the vote, we must increase the threshold to effectively discount the possibility of malicious votes. +One way to understand the `3f + 1` general requirement for `f` traitors is again through the lens of a "threshold" for carrying out an action. In the context of crash-faults, we needed a threshold of `n - f` votes in order to make a decision. Since crashed nodes could not vote, we could derive that all of the `n - f` votes came from properly functioning nodes. When the faulty nodes, in this case our traitorous generals, can actually contribute to the vote, we must increase the threshold to effectively discount the possibility of malicious votes. diff --git a/zh-CN/book/01__consensus/03__byzantine-faults.md b/zh-CN/book/01__consensus/03__byzantine-faults.md index 273d19e..3706aa0 100644 --- a/zh-CN/book/01__consensus/03__byzantine-faults.md +++ b/zh-CN/book/01__consensus/03__byzantine-faults.md @@ -39,4 +39,4 @@ If the commander is a traitor, more formal reasoning is necessary to see the cor A traitorous commanding general could coordinate with other traitors to attempt to give loyal generals different sets of orders. For instance, the traitors could choose to only send the conflicting order to half of the loyal generals. Without further communication, the loyal generals would not act in unison. We can provide a simple solution by requiring that loyal generals relay conflicting orders to all other generals. After this second round of communication, all loyal generals are guaranteed to share the same information. The paper shows that we can achieve the same result if loyal generals only relay orders with less than `f` votes, where `f` is the maximum number of traitors that can be safely handled by the system. -One way to understand the `3f + 1` general requirement for `f` traitors is again through the lens of a "threshold" for carrying out an action. In the context of crash-faults, we needed a threshold of `n - f` votes in order to make a decision. Since crashed nodes could not vote, we could derive that all of the `n - f` votes came from properly functioning nodes. When the faulty nodes, in this cause our traitorous generals, can actually contribute to the vote, we must increase the threshold to effectively discount the possibility of malicious votes. +One way to understand the `3f + 1` general requirement for `f` traitors is again through the lens of a "threshold" for carrying out an action. In the context of crash-faults, we needed a threshold of `n - f` votes in order to make a decision. Since crashed nodes could not vote, we could derive that all of the `n - f` votes came from properly functioning nodes. When the faulty nodes, in this case our traitorous generals, can actually contribute to the vote, we must increase the threshold to effectively discount the possibility of malicious votes. From d464afea960abf97aa32e3a98ffd39097595bda8 Mon Sep 17 00:00:00 2001 From: Evan Blank <32708219+evanblank3@users.noreply.github.com> Date: Sun, 13 Mar 2022 12:05:41 -0400 Subject: [PATCH 03/16] fix: word tense --- book/02__blockchains/01__digital-cash.md | 2 +- zh-CN/book/02__blockchains/01__digital-cash.md | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/book/02__blockchains/01__digital-cash.md b/book/02__blockchains/01__digital-cash.md index 03525b3..ee6b02e 100644 --- a/book/02__blockchains/01__digital-cash.md +++ b/book/02__blockchains/01__digital-cash.md @@ -4,7 +4,7 @@ title: "Digital Cash" # {{ $frontmatter.title }} -From the ubiquity of money as a dominant system of social coordination it's no challenge to understand why attempts at digital financial products have been plentiful. Given the inherently social nature of money and finance, it should also come as no surprise that these projects gained significant traction with the launch of the world wide web in 1989. As the dotcom bubble made undeniably clear, the internet-connected universe was enamoured with a wholly digital vision of the future. Digital reality held limitless possibility, but it most certainly help digital money. +From the ubiquity of money as a dominant system of social coordination it's no challenge to understand why attempts at digital financial products have been plentiful. Given the inherently social nature of money and finance, it should also come as no surprise that these projects gained significant traction with the launch of the world wide web in 1989. As the dotcom bubble made undeniably clear, the internet-connected universe was enamoured with a wholly digital vision of the future. Digital reality held limitless possibility, but it most certainly helped digital money. Beyond the apparent social impact of such a system, already confirmed by the success of other financial conveniences like the ATM, money was ultimately relatively straightforward to construct. Accounts, balances, and transactions translated cleanly into the computer databases necessary to represent finance in cyberspace. Even the ATM required the development of digital banking tools as early as the 1960s. With most of its raw components sitting in plain sight, digital money was simply waiting to be plugged into the internet. diff --git a/zh-CN/book/02__blockchains/01__digital-cash.md b/zh-CN/book/02__blockchains/01__digital-cash.md index 03525b3..ee6b02e 100644 --- a/zh-CN/book/02__blockchains/01__digital-cash.md +++ b/zh-CN/book/02__blockchains/01__digital-cash.md @@ -4,7 +4,7 @@ title: "Digital Cash" # {{ $frontmatter.title }} -From the ubiquity of money as a dominant system of social coordination it's no challenge to understand why attempts at digital financial products have been plentiful. Given the inherently social nature of money and finance, it should also come as no surprise that these projects gained significant traction with the launch of the world wide web in 1989. As the dotcom bubble made undeniably clear, the internet-connected universe was enamoured with a wholly digital vision of the future. Digital reality held limitless possibility, but it most certainly help digital money. +From the ubiquity of money as a dominant system of social coordination it's no challenge to understand why attempts at digital financial products have been plentiful. Given the inherently social nature of money and finance, it should also come as no surprise that these projects gained significant traction with the launch of the world wide web in 1989. As the dotcom bubble made undeniably clear, the internet-connected universe was enamoured with a wholly digital vision of the future. Digital reality held limitless possibility, but it most certainly helped digital money. Beyond the apparent social impact of such a system, already confirmed by the success of other financial conveniences like the ATM, money was ultimately relatively straightforward to construct. Accounts, balances, and transactions translated cleanly into the computer databases necessary to represent finance in cyberspace. Even the ATM required the development of digital banking tools as early as the 1960s. With most of its raw components sitting in plain sight, digital money was simply waiting to be plugged into the internet. From 0027a5e349444ff292d5c4f934e3ea5d8358938e Mon Sep 17 00:00:00 2001 From: Evan Blank <32708219+evanblank3@users.noreply.github.com> Date: Sun, 13 Mar 2022 16:15:32 -0400 Subject: [PATCH 04/16] fix: add with --- book/02__blockchains/02__open-access.md | 2 +- zh-CN/book/02__blockchains/02__open-access.md | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/book/02__blockchains/02__open-access.md b/book/02__blockchains/02__open-access.md index 0905366..b812d3c 100644 --- a/book/02__blockchains/02__open-access.md +++ b/book/02__blockchains/02__open-access.md @@ -28,7 +28,7 @@ Although this may seem surprising, email spam prevention actually faced many of Researchers looking into this problem found an interesting solution. Spam couldn't be entirely prevented, but it could be throttled. If users were required to pay for each email they sent, then spam would become increasingly costly. One 2014 report places the average number of spam emails sent per day at 54 billion messages. A charge of even a single US cent per email would cost the global spam industry upwards of 200 billion USD annually. It's undoubtedly clear that the number of spam emails would drop under such a model. -Although this system sounds ideal in theory, it still requires the existence of some gateway through which users can make the necessary payment for each email. Any form of online payment associated with traditional finance would force email users to register accounts old-world institutions, a concept that flew in the face of openly accessible email. Instead, researchers found that users could make "payment" in the form of an expenditure of electricity. Users could generate an email "stamp" by running a program that took, on average, a small fixed amount of time to execute. Stamp generation and verification was designed so that it was essentially impossible to decrease execution time. Even a short computation time on the order of a single second per email would massively throttle spam while leaving "real" users mostly unaffected. +Although this system sounds ideal in theory, it still requires the existence of some gateway through which users can make the necessary payment for each email. Any form of online payment associated with traditional finance would force email users to register accounts with old-world institutions, a concept that flew in the face of openly accessible email. Instead, researchers found that users could make "payment" in the form of an expenditure of electricity. Users could generate an email "stamp" by running a program that took, on average, a small fixed amount of time to execute. Stamp generation and verification was designed so that it was essentially impossible to decrease execution time. Even a short computation time on the order of a single second per email would massively throttle spam while leaving "real" users mostly unaffected. Adam Back's HashCash is likely the most widely recognized of these constructions today. Crucially, HashCash popularized the concept of using hashing algorithms as a mechanism for proving that a certain amount of computational effort had been expended. This mechanism, which we often now call "Proof-of-Work," became a keystone of the peer-to-peer digital currencies to come. Proof-of-Work's importance is so crucial that it's necessary to fully understand its basic operation before we continue with our analysis of its eventual use. diff --git a/zh-CN/book/02__blockchains/02__open-access.md b/zh-CN/book/02__blockchains/02__open-access.md index 0a1e085..03a5ca7 100644 --- a/zh-CN/book/02__blockchains/02__open-access.md +++ b/zh-CN/book/02__blockchains/02__open-access.md @@ -26,7 +26,7 @@ Although this may seem surprising, email spam prevention actually faced many of Researchers looking into this problem found an interesting solution. Spam couldn't be entirely prevented, but it could be throttled. If users were required to pay for each email they sent, then spam would become increasingly costly. One 2014 report places the average number of spam emails sent per day at 54 billion messages. A charge of even a single US cent per email would cost the global spam industry upwards of 200 billion USD annually. It's undoubtedly clear that the number of spam emails would drop under such a model. -Although this system sounds ideal in theory, it still requires the existence of some gateway through which users can make the necessary payment for each email. Any form of online payment associated with traditional finance would force email users to register accounts old-world institutions, a concept that flew in the face of openly accessible email. Instead, researchers found that users could make "payment" in the form of an expenditure of electricity. Users could generate an email "stamp" by running a program that took, on average, a small fixed amount of time to execute. Stamp generation and verification was designed so that it was essentially impossible to decrease execution time. Even a short computation time on the order of a single second per email would massively throttle spam while leaving "real" users mostly unaffected. +Although this system sounds ideal in theory, it still requires the existence of some gateway through which users can make the necessary payment for each email. Any form of online payment associated with traditional finance would force email users to register accounts with old-world institutions, a concept that flew in the face of openly accessible email. Instead, researchers found that users could make "payment" in the form of an expenditure of electricity. Users could generate an email "stamp" by running a program that took, on average, a small fixed amount of time to execute. Stamp generation and verification was designed so that it was essentially impossible to decrease execution time. Even a short computation time on the order of a single second per email would massively throttle spam while leaving "real" users mostly unaffected. Adam Back's HashCash is likely the most widely recognized of these constructions today. Crucially, HashCash popularized the concept of using hashing algorithms as a mechanism for proving that a certain amount of computational effort had been expended. This mechanism, which we often now call "Proof-of-Work," became a keystone of the peer-to-peer digital currencies to come. Proof-of-Work's importance is so crucial that it's necessary to fully understand its basic operation before we continue with our analysis of its eventual use. From e83942271212a402144db250e34db3034bdea1d3 Mon Sep 17 00:00:00 2001 From: Evan Blank <32708219+evanblank3@users.noreply.github.com> Date: Sun, 13 Mar 2022 16:19:57 -0400 Subject: [PATCH 05/16] fix: add have --- book/02__blockchains/02__open-access.md | 2 +- zh-CN/book/02__blockchains/02__open-access.md | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/book/02__blockchains/02__open-access.md b/book/02__blockchains/02__open-access.md index b812d3c..1c06e0c 100644 --- a/book/02__blockchains/02__open-access.md +++ b/book/02__blockchains/02__open-access.md @@ -40,7 +40,7 @@ Cryptographic hash functions are designed to be highly resistant to collisions, We can demonstrate a simple partial collision under SHA256 quite easily. In the following example, two different inputs produce hashes that share the same first few bytes: -Partial hash collisions no significant impact on the security of a hash function. We find them useful, however, because the amount of computational effort required to find a collision depends on the number of bytes we're aiming to share between the two resulting hashes. Cryptographic hash functions are constructed to be almost entirely random, such that it's infeasible to "guess" the hash of an input without actually running it through the algorithm. From this property, we can determine the probability of finding a particular collision with some light mathematics. +Partial hash collisions have no significant impact on the security of a hash function. We find them useful, however, because the amount of computational effort required to find a collision depends on the number of bytes we're aiming to share between the two resulting hashes. Cryptographic hash functions are constructed to be almost entirely random, such that it's infeasible to "guess" the hash of an input without actually running it through the algorithm. From this property, we can determine the probability of finding a particular collision with some light mathematics. Each byte of the hash output has 256 possible values, represented in hexadecimal as `0x00` to `0xFF`. The probability of finding an input with prefix `00` (or any other specific byte prefix), as the first values of the hash is therefore one in 256, meaning it takes 256 hash attempts on average to find such an input. Similarly, the probability of finding an input with `0000` as its first two bytes is `1/256 * 1/256 = 1/65536`, a total of 65,536 attempts on average. For each additional byte we want to match, the number of hash attempts required is multiplied by 256. Clearly, the number of required attempts grows extremely quickly as the number of bytes to match increases. diff --git a/zh-CN/book/02__blockchains/02__open-access.md b/zh-CN/book/02__blockchains/02__open-access.md index 03a5ca7..ffba255 100644 --- a/zh-CN/book/02__blockchains/02__open-access.md +++ b/zh-CN/book/02__blockchains/02__open-access.md @@ -36,7 +36,7 @@ Cryptographic hash functions are designed to be highly resistant to collisions, We can demonstrate a simple partial collision under SHA256 quite easily. In the following example, two different inputs produce hashes that share the same first few bytes: -Partial hash collisions no significant impact on the security of a hash function. We find them useful, however, because the amount of computational effort required to find a collision depends on the number of bytes we're aiming to share between the two resulting hashes. Cryptographic hash functions are constructed to be almost entirely random, such that it's infeasible to "guess" the hash of an input without actually running it through the algorithm. From this property, we can determine the probability of finding a particular collision with some light mathematics. +Partial hash collisions have no significant impact on the security of a hash function. We find them useful, however, because the amount of computational effort required to find a collision depends on the number of bytes we're aiming to share between the two resulting hashes. Cryptographic hash functions are constructed to be almost entirely random, such that it's infeasible to "guess" the hash of an input without actually running it through the algorithm. From this property, we can determine the probability of finding a particular collision with some light mathematics. Each byte of the hash output has sixteen possible values, represented as 0-9 and A-F. The probability of finding an input with "1" or any other particular digit, as the first value of its hash is therefore one in sixteen, meaning it takes sixteen hash attempts on average to find such an input. Similarly, the probability of finding an input with "12" as its first two bytes is `1/16 * 1/16 = 1/256`, a total of 256 attempts on average. For each additional byte we want to match, the number of hash attempts required is multiplied by sixteen. Clearly, the number of required attempts grows extremely quickly as the number of bytes to match increases. From dd187e858b350a270f44f58f13d7b1e63be523ca Mon Sep 17 00:00:00 2001 From: Evan Blank <32708219+evanblank3@users.noreply.github.com> Date: Sun, 13 Mar 2022 16:31:43 -0400 Subject: [PATCH 06/16] fix: add could --- book/02__blockchains/03__chains-of-blocks.md | 2 +- zh-CN/book/02__blockchains/03__chains-of-blocks.md | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/book/02__blockchains/03__chains-of-blocks.md b/book/02__blockchains/03__chains-of-blocks.md index dd6cea5..b8a6571 100644 --- a/book/02__blockchains/03__chains-of-blocks.md +++ b/book/02__blockchains/03__chains-of-blocks.md @@ -32,7 +32,7 @@ Perhaps, depending on the hash function, `hash(10, "Hello!", 6)` provides us wit TODO: Diagram ::: -At this point, we are still emulating traditional BFT system, though we've replaced the way in which votes are generated. Now, we begin to partially diverge. Most BFT systems will elect a "leader" responsible for proposing potential updates to all other nodes in the system. Within a Proof-of-Work system, nodes will most likely not be aware of all other nodes in the network. If a designated leader were to exist, then it is possible that a node not be aware of the leader and, as a result, not be able to participate. Therefore, we need to eliminate the need for a designated leader. +At this point, we are still emulating traditional BFT system, though we've replaced the way in which votes are generated. Now, we begin to partially diverge. Most BFT systems will elect a "leader" responsible for proposing potential updates to all other nodes in the system. Within a Proof-of-Work system, nodes will most likely not be aware of all other nodes in the network. If a designated leader were to exist, then it is possible that a node could not be aware of the leader and, as a result, not be able to participate. Therefore, we need to eliminate the need for a designated leader. ::: tip TODO TODO: Diagram diff --git a/zh-CN/book/02__blockchains/03__chains-of-blocks.md b/zh-CN/book/02__blockchains/03__chains-of-blocks.md index 59f0950..7d02981 100644 --- a/zh-CN/book/02__blockchains/03__chains-of-blocks.md +++ b/zh-CN/book/02__blockchains/03__chains-of-blocks.md @@ -28,7 +28,7 @@ Perhaps, depending on the hash function, `hash(10, "Hello!", 6)` provides us wit ::: tip TODO TODO: Diagram ::: -At this point, we are still emulating traditional BFT system, though we've replaced the way in which votes are generated. Now, we begin to partially diverge. Most BFT systems will elect a "leader" responsible for proposing potential updates to all other nodes in the system. Within a Proof-of-Work system, nodes will most likely not be aware of all other nodes in the network. If a designated leader were to exist, then it is possible that a node not be aware of the leader and, as a result, not be able to participate. Therefore, we need to eliminate the need for a designated leader. +At this point, we are still emulating traditional BFT system, though we've replaced the way in which votes are generated. Now, we begin to partially diverge. Most BFT systems will elect a "leader" responsible for proposing potential updates to all other nodes in the system. Within a Proof-of-Work system, nodes will most likely not be aware of all other nodes in the network. If a designated leader were to exist, then it is possible that a node could not be aware of the leader and, as a result, not be able to participate. Therefore, we need to eliminate the need for a designated leader. ::: tip TODO TODO: Diagram ::: From 5476ee33286fa23c8a5454198d7a3019c8055468 Mon Sep 17 00:00:00 2001 From: Evan Blank <32708219+evanblank3@users.noreply.github.com> Date: Sun, 13 Mar 2022 16:36:57 -0400 Subject: [PATCH 07/16] fix: AS to As --- book/02__blockchains/03__chains-of-blocks.md | 2 +- zh-CN/book/02__blockchains/03__chains-of-blocks.md | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/book/02__blockchains/03__chains-of-blocks.md b/book/02__blockchains/03__chains-of-blocks.md index b8a6571..08c16aa 100644 --- a/book/02__blockchains/03__chains-of-blocks.md +++ b/book/02__blockchains/03__chains-of-blocks.md @@ -54,7 +54,7 @@ Let's take a look at the perspective of any one node in the system. For simplici TODO: Diagram ::: -AS discussed in our sections regarding state and state transitions, a transaction acts as an input to some state transition function, which in turn mutates some initial state. The initial state can have an effect on the result of the transaction, so it's important that all nodes execute any given transaction against the same state. Therefore, a record of a transaction in the system must always include a reference to the specific state on which the transaction operates. Since the state may be quite large, we often use some commitment to the state, like a hash, instead of the full state. +As discussed in our sections regarding state and state transitions, a transaction acts as an input to some state transition function, which in turn mutates some initial state. The initial state can have an effect on the result of the transaction, so it's important that all nodes execute any given transaction against the same state. Therefore, a record of a transaction in the system must always include a reference to the specific state on which the transaction operates. Since the state may be quite large, we often use some commitment to the state, like a hash, instead of the full state. Let's assume that our node has selected some transaction, `T0`, to attempt to process. We required that all nodes share the same initial state, which we'll call `S0`. The "thing" that our node wants to have recognized is that other nodes should accept `T0` as the transaction that mutates `S0` into some second new state, `S1`. We can describe this as the message `(S0, T0, S1)`. diff --git a/zh-CN/book/02__blockchains/03__chains-of-blocks.md b/zh-CN/book/02__blockchains/03__chains-of-blocks.md index 7d02981..a3060a0 100644 --- a/zh-CN/book/02__blockchains/03__chains-of-blocks.md +++ b/zh-CN/book/02__blockchains/03__chains-of-blocks.md @@ -44,7 +44,7 @@ Let's take a look at the perspective of any one node in the system. For simplici ::: tip TODO TODO: Diagram ::: -AS discussed in our sections regarding state and state transitions, a transaction acts as an input to some state transition function, which in turn mutates some initial state. The initial state can have an effect on the result of the transaction, so it's important that all nodes execute any given transaction against the same state. Therefore, a record of a transaction in the system must always include a reference to the specific state on which the transaction operates. Since the state may be quite large, we often use some commitment to the state, like a hash, instead of the full state. +As discussed in our sections regarding state and state transitions, a transaction acts as an input to some state transition function, which in turn mutates some initial state. The initial state can have an effect on the result of the transaction, so it's important that all nodes execute any given transaction against the same state. Therefore, a record of a transaction in the system must always include a reference to the specific state on which the transaction operates. Since the state may be quite large, we often use some commitment to the state, like a hash, instead of the full state. Let's assume that our node has selected some transaction, `T0`, to attempt to process. We required that all nodes share the same initial state, which we'll call `S0`. The "thing" that our node wants to have recognized is that other nodes should accept `T0` as the transaction that mutates `S0` into some second new state, `S1`. We can describe this as the message `(S0, T0, S1)`. From 08665b9027972d0bb6835a85e44d0c5f008327ab Mon Sep 17 00:00:00 2001 From: Evan Blank <32708219+evanblank3@users.noreply.github.com> Date: Sun, 13 Mar 2022 16:42:07 -0400 Subject: [PATCH 08/16] fix: equal to equals --- book/02__blockchains/03__chains-of-blocks.md | 2 +- zh-CN/book/02__blockchains/03__chains-of-blocks.md | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/book/02__blockchains/03__chains-of-blocks.md b/book/02__blockchains/03__chains-of-blocks.md index 08c16aa..82aa17b 100644 --- a/book/02__blockchains/03__chains-of-blocks.md +++ b/book/02__blockchains/03__chains-of-blocks.md @@ -60,7 +60,7 @@ Let's assume that our node has selected some transaction, `T0`, to attempt to pr Our node must now produce some "voting power" to attach to this message. The extent of the voting power attached will determine whether or not other nodes accept the message. As we previously explained, this means repeatedly performing `hash(ID, message, nonce)` until the node is satisfied with the result. Of course, we have yet to define the conditions under which a node would find the result sufficient. We can take a stab at a first attempt for this metric as follows. -The level of "work" a node is willing to do for any given transaction should, in theory, depend on the expected return for doing so. Any work performed translates directly into resource expenditure on the part of the node. Assuming that the node receives a reward for its effort, it seems sensible to say that a node will continue to do work on a particular transaction until the resources expended approximately equal the value of the reward. The node can then attach whichever result is the smallest. As we will shortly find out, this method is reasonable but not entirely ideal. +The level of "work" a node is willing to do for any given transaction should, in theory, depend on the expected return for doing so. Any work performed translates directly into resource expenditure on the part of the node. Assuming that the node receives a reward for its effort, it seems sensible to say that a node will continue to do work on a particular transaction until the resources expended approximately equals the value of the reward. The node can then attach whichever result is the smallest. As we will shortly find out, this method is reasonable but not entirely ideal. Before we continue our analysis, we should briefly touch on the topic of reward values. This is a complex subject that we explore in much greater depth later within this text. For the moment, however, one may find it useful to assume that reward value is proportional to the value or "importance" for the transaction being processed. This mental model suggests that nodes will generally do more work for transactions that users wish to see processed quickly and spend less time on non-critical tasks. diff --git a/zh-CN/book/02__blockchains/03__chains-of-blocks.md b/zh-CN/book/02__blockchains/03__chains-of-blocks.md index a3060a0..a50f835 100644 --- a/zh-CN/book/02__blockchains/03__chains-of-blocks.md +++ b/zh-CN/book/02__blockchains/03__chains-of-blocks.md @@ -50,7 +50,7 @@ Let's assume that our node has selected some transaction, `T0`, to attempt to pr Our node must now produce some "voting power" to attach to this message. The extent of the voting power attached will determine whether or not other nodes accept the message. As we previously explained, this means repeatedly performing `hash(ID, message, nonce)` until the node is satisfied with the result. Of course, we have yet to define the conditions under which a node would find the result sufficient. We can take a stab at a first attempt for this metric as follows. -The level of "work" a node is willing to do for any given transaction should, in theory, depend on the expected return for doing so. Any work performed translates directly into resource expenditure on the part of the node. Assuming that the node receives a reward for its effort, it seems sensible to say that a node will continue to do work on a particular transaction until the resources expended approximately equal the value of the reward. The node can then attach whichever result is the smallest. As we will shortly find out, this method is reasonable but not entirely ideal. +The level of "work" a node is willing to do for any given transaction should, in theory, depend on the expected return for doing so. Any work performed translates directly into resource expenditure on the part of the node. Assuming that the node receives a reward for its effort, it seems sensible to say that a node will continue to do work on a particular transaction until the resources expended approximately equals the value of the reward. The node can then attach whichever result is the smallest. As we will shortly find out, this method is reasonable but not entirely ideal. Before we continue our analysis, we should briefly touch on the topic of reward values. This is a complex subject that we explore in much greater depth later within this text. For the moment, however, one may find it useful to assume that reward value is proportional to the value or "importance" for the transaction being processed. This mental model suggests that nodes will generally do more work for transactions that users wish to see processed quickly and spend less time on non-critical tasks. From 8ceea15743cea6603bf60fb81b398ca767ffec17 Mon Sep 17 00:00:00 2001 From: Evan Blank <32708219+evanblank3@users.noreply.github.com> Date: Sun, 13 Mar 2022 16:45:25 -0400 Subject: [PATCH 09/16] fix: IF to If --- book/02__blockchains/03__chains-of-blocks.md | 2 +- zh-CN/book/02__blockchains/03__chains-of-blocks.md | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/book/02__blockchains/03__chains-of-blocks.md b/book/02__blockchains/03__chains-of-blocks.md index 82aa17b..324cfb3 100644 --- a/book/02__blockchains/03__chains-of-blocks.md +++ b/book/02__blockchains/03__chains-of-blocks.md @@ -66,7 +66,7 @@ Before we continue our analysis, we should briefly touch on the topic of reward Let's now shift our attention back to our individual node. Take the scenario in which `T0` is only valuable enough such that its associated reward covers a few seconds of work. After this short period of time, our node picks its smallest result and attaches it as the voting power for the message `(S0, T0, S1)`. The node then broadcasts the combined message and vote to the network of other nodes. -To understand what happens next, we must zoom out of the perspective of an individual node and look again at the network as a whole. IF we assume that all nodes are similar to our particular node, we find a network flooded with potential transactions to be executed against the genesis state. We chose the work time of a few seconds quite deliberately. At this interval, many nodes will finish their votes before the votes from others have enough time to propagate through the network. If nodes selected different transactions from the pool, there are now many conflicting messages of the form `(S0, T?, S1)`. +To understand what happens next, we must zoom out of the perspective of an individual node and look again at the network as a whole. If we assume that all nodes are similar to our particular node, we find a network flooded with potential transactions to be executed against the genesis state. We chose the work time of a few seconds quite deliberately. At this interval, many nodes will finish their votes before the votes from others have enough time to propagate through the network. If nodes selected different transactions from the pool, there are now many conflicting messages of the form `(S0, T?, S1)`. ::: tip TODO TODO: Diagram diff --git a/zh-CN/book/02__blockchains/03__chains-of-blocks.md b/zh-CN/book/02__blockchains/03__chains-of-blocks.md index a50f835..fed33d0 100644 --- a/zh-CN/book/02__blockchains/03__chains-of-blocks.md +++ b/zh-CN/book/02__blockchains/03__chains-of-blocks.md @@ -56,7 +56,7 @@ Before we continue our analysis, we should briefly touch on the topic of reward Let's now shift our attention back to our individual node. Take the scenario in which `T0` is only valuable enough such that its associated reward covers a few seconds of work. After this short period of time, our node picks its smallest result and attaches it as the voting power for the message `(S0, T0, S1)`. The node then broadcasts the combined message and vote to the network of other nodes. -To understand what happens next, we must zoom out of the perspective of an individual node and look again at the network as a whole. IF we assume that all nodes are similar to our particular node, we find a network flooded with potential transactions to be executed against the genesis state. We chose the work time of a few seconds quite deliberately. At this interval, many nodes will finish their votes before the votes from others have enough time to propagate through the network. If nodes selected different transactions from the pool, there are now many conflicting messages of the form `(S0, T?, S1)`. +To understand what happens next, we must zoom out of the perspective of an individual node and look again at the network as a whole. If we assume that all nodes are similar to our particular node, we find a network flooded with potential transactions to be executed against the genesis state. We chose the work time of a few seconds quite deliberately. At this interval, many nodes will finish their votes before the votes from others have enough time to propagate through the network. If nodes selected different transactions from the pool, there are now many conflicting messages of the form `(S0, T?, S1)`. ::: tip TODO TODO: Diagram ::: From 83e11d5e2d71c66256ea48de554da2edb74ac001 Mon Sep 17 00:00:00 2001 From: Evan Blank <32708219+evanblank3@users.noreply.github.com> Date: Sun, 13 Mar 2022 18:51:33 -0400 Subject: [PATCH 10/16] fix: remove s --- book/02__blockchains/04__fork-choice-rules.md | 2 +- zh-CN/book/02__blockchains/04__fork-choice-rules.md | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/book/02__blockchains/04__fork-choice-rules.md b/book/02__blockchains/04__fork-choice-rules.md index fd7bff7..3f549d9 100644 --- a/book/02__blockchains/04__fork-choice-rules.md +++ b/book/02__blockchains/04__fork-choice-rules.md @@ -20,7 +20,7 @@ LCR explainer The longest chain rule has the effect that a competing fork can only become canonical once its total difficulty overtakes that of any other chain. Difficulty essentially acts as a proxy for resource expenditure, so we can say that the chain chosen by the LCR generally follows whichever parties control, jointly, more than half the total current hash power. The probability of producing a valid block increases with the amount of hash power dedicated to doing so. A group of miners with more than half total hash power will always be slightly more likely than any other group to find a valid block. Over time, this ensures with increasing probability that a minority chain cannot overtake a majority one. -One significant shortcoming of the longest chain rule is that it favors smaller groups with more hash power per member over larger groups with the same total hash power. This stems from the fact that a group working on many different blocks on the same chain can only produce a single block to be factored in by the LCR. The total rate of block production between the two groups will be approximately equal, as s the first generates fewer blocks with higher frequency and the second many blocks with lower frequency. However, a larger percentage of these blocks become ommers and are thereby ignored by the LCR. The LCR effectively weighs the "winning" block as if only its producer, and not any others in the group, had performed any work to extend the target chain. +One significant shortcoming of the longest chain rule is that it favors smaller groups with more hash power per member over larger groups with the same total hash power. This stems from the fact that a group working on many different blocks on the same chain can only produce a single block to be factored in by the LCR. The total rate of block production between the two groups will be approximately equal, as the first generates fewer blocks with higher frequency and the second many blocks with lower frequency. However, a larger percentage of these blocks become ommers and are thereby ignored by the LCR. The LCR effectively weighs the "winning" block as if only its producer, and not any others in the group, had performed any work to extend the target chain. The alternative GHOST fork choice rule attempts to address this problem by accounting for the existence of ommer blocks. When computing a score for each block, GHOST sums the difficulty of all chains that stem from the block and not only the heaviest one. This modification to the LCR guarantees that a majority group will always outpace a minority one, even if the majority is poorly coordinated. In general, GHOST has a positive effect on the extent of decentralization among the mining population. The basic algorithm behind GHOST is: diff --git a/zh-CN/book/02__blockchains/04__fork-choice-rules.md b/zh-CN/book/02__blockchains/04__fork-choice-rules.md index 24ac299..327e403 100644 --- a/zh-CN/book/02__blockchains/04__fork-choice-rules.md +++ b/zh-CN/book/02__blockchains/04__fork-choice-rules.md @@ -18,7 +18,7 @@ It's perhaps no surprise then that the earliest fork choice rules simply selecte The longest chain rule has the effect that a competing fork can only become canonical once its total difficulty overtakes that of any other chain. Difficulty essentially acts as a proxy for resource expenditure, so we can say that the chain chosen by the LCR generally follows whichever parties control, jointly, more than half the total current hash power. The probability of producing a valid block increases with the amount of hash power dedicated to doing so. A group of miners with more than half total hash power will always be slightly more likely than any other group to find a valid block. Over time, this ensures with increasing probability that a minority chain cannot overtake a majority one. -One significant shortcoming of the longest chain rule is that it favors smaller groups with more hash power per member over larger groups with the same total hash power. This stems from the fact that a group working on many different blocks on the same chain can only produce a single block to be factored in by the LCR. The total rate of block production between the two groups will be approximately equal, as s the first generates fewer blocks with higher frequency and the second many blocks with lower frequency. However, a larger percentage of these blocks become ommers and are thereby ignored by the LCR. The LCR effectively weighs the "winning" block as if only its producer, and not any others in the group, had performed any work to extend the target chain. +One significant shortcoming of the longest chain rule is that it favors smaller groups with more hash power per member over larger groups with the same total hash power. This stems from the fact that a group working on many different blocks on the same chain can only produce a single block to be factored in by the LCR. The total rate of block production between the two groups will be approximately equal, as the first generates fewer blocks with higher frequency and the second many blocks with lower frequency. However, a larger percentage of these blocks become ommers and are thereby ignored by the LCR. The LCR effectively weighs the "winning" block as if only its producer, and not any others in the group, had performed any work to extend the target chain. The alternative GHOST fork choice rule attempts to address this problem by accounting for the existence of ommer blocks. When computing a score for each block, GHOST sums the difficulty of all chains that stem from the block and not only the heaviest one. This modification to the LCR guarantees that a majority group will always outpace a minority one, even if the majority is poorly coordinated. In general, GHOST has a positive effect on the extent of decentralization among the mining population. The basic algorithm behind GHOST is: From c961ab5373bac7e26095895be85664cf60081de6 Mon Sep 17 00:00:00 2001 From: Evan Blank <32708219+evanblank3@users.noreply.github.com> Date: Sun, 13 Mar 2022 18:55:35 -0400 Subject: [PATCH 11/16] fix: lock to block --- book/02__blockchains/04__fork-choice-rules.md | 2 +- zh-CN/book/02__blockchains/04__fork-choice-rules.md | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/book/02__blockchains/04__fork-choice-rules.md b/book/02__blockchains/04__fork-choice-rules.md index 3f549d9..03374ff 100644 --- a/book/02__blockchains/04__fork-choice-rules.md +++ b/book/02__blockchains/04__fork-choice-rules.md @@ -31,7 +31,7 @@ The alternative GHOST fork choice rule attempts to address this problem by accou 5. If we have more than one potential chain (a fork), then we move on to the first block of the fork with the most *total* blocks, including uncle blocks. 6. Head back to step (2) with our current block. -GHOST is additionally useful when block production rate is closer to network latency. For instance, this would be the case when network latency and block production rate are both on the order of 5-15 seconds. Lower ratio between the two metrics leaders to an increase in the probability that a miner fails to see a new block and instead begins to work on a lock stemming from the same parent. If the miner later chooses to switch their efforts to the new block, any work carried out is essentially now wasted. GHOST ensures that the miner can still influence the canonical chain by continuing work on their initial block. GHOST is typically accompanied by a reward system that compensates the producers of ommer bocks in line with the probability of such an event. +GHOST is additionally useful when block production rate is closer to network latency. For instance, this would be the case when network latency and block production rate are both on the order of 5-15 seconds. Lower ratio between the two metrics leaders to an increase in the probability that a miner fails to see a new block and instead begins to work on a block stemming from the same parent. If the miner later chooses to switch their efforts to the new block, any work carried out is essentially now wasted. GHOST ensures that the miner can still influence the canonical chain by continuing work on their initial block. GHOST is typically accompanied by a reward system that compensates the producers of ommer bocks in line with the probability of such an event. ## GHOST vs. LCR diff --git a/zh-CN/book/02__blockchains/04__fork-choice-rules.md b/zh-CN/book/02__blockchains/04__fork-choice-rules.md index 327e403..3eb17cf 100644 --- a/zh-CN/book/02__blockchains/04__fork-choice-rules.md +++ b/zh-CN/book/02__blockchains/04__fork-choice-rules.md @@ -29,7 +29,7 @@ The alternative GHOST fork choice rule attempts to address this problem by accou 5. If we have more than one potential chain (a fork), then we move on to the first block of the fork with the most *total* blocks, including uncle blocks. 6. Head back to step (2) with our current block. -GHOST is additionally useful when block production rate is closer to network latency. For instance, this would be the case when network latency and block production rate are both on the order of 5-15 seconds. Lower ratio between the two metrics leaders to an increase in the probability that a miner fails to see a new block and instead begins to work on a lock stemming from the same parent. If the miner later chooses to switch their efforts to the new block, any work carried out is essentially now wasted. GHOST ensures that the miner can still influence the canonical chain by continuing work on their initial block. GHOST is typically accompanied by a reward system that compensates the producers of ommer bocks in line with the probability of such an event. +GHOST is additionally useful when block production rate is closer to network latency. For instance, this would be the case when network latency and block production rate are both on the order of 5-15 seconds. Lower ratio between the two metrics leaders to an increase in the probability that a miner fails to see a new block and instead begins to work on a block stemming from the same parent. If the miner later chooses to switch their efforts to the new block, any work carried out is essentially now wasted. GHOST ensures that the miner can still influence the canonical chain by continuing work on their initial block. GHOST is typically accompanied by a reward system that compensates the producers of ommer bocks in line with the probability of such an event. ## GHOST vs. LCR From da1a4139cd0a9e850cd08b26c2bfcbd4ed807cfb Mon Sep 17 00:00:00 2001 From: Evan Blank <32708219+evanblank3@users.noreply.github.com> Date: Sun, 13 Mar 2022 19:02:02 -0400 Subject: [PATCH 12/16] fix: by to but --- book/02__blockchains/04__fork-choice-rules.md | 2 +- zh-CN/book/02__blockchains/04__fork-choice-rules.md | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/book/02__blockchains/04__fork-choice-rules.md b/book/02__blockchains/04__fork-choice-rules.md index 03374ff..cb89e3e 100644 --- a/book/02__blockchains/04__fork-choice-rules.md +++ b/book/02__blockchains/04__fork-choice-rules.md @@ -47,4 +47,4 @@ However, in some cases, GHOST will disagree with the longest-chain rule: In this chain, the LCR picks `Block G` because it's part of the longest chain (seven blocks). GHOST diverges from the LCR after `Block B`. Although the chain following `Block C` is longer at five blocks, there are a total of *six* blocks in the fork starting at `Block C'` when we count uncle blocks. -GHOST and the LCR have a lot in common, by clearly have certain key differences. Although GHOST consumes more information, it also introduces complexities for implementation. The LCR has seen significantly more use within existing blockchains running in production today. Our study of GHOST will, however, prove valuable when we later analyze its modification and adoption in Eth2. +GHOST and the LCR have a lot in common, but clearly have certain key differences. Although GHOST consumes more information, it also introduces complexities for implementation. The LCR has seen significantly more use within existing blockchains running in production today. Our study of GHOST will, however, prove valuable when we later analyze its modification and adoption in Eth2. diff --git a/zh-CN/book/02__blockchains/04__fork-choice-rules.md b/zh-CN/book/02__blockchains/04__fork-choice-rules.md index 3eb17cf..ffe28dc 100644 --- a/zh-CN/book/02__blockchains/04__fork-choice-rules.md +++ b/zh-CN/book/02__blockchains/04__fork-choice-rules.md @@ -45,4 +45,4 @@ However, in some cases, GHOST will disagree with the longest-chain rule: In this chain, the LCR picks `Block G` because it's part of the longest chain (seven blocks). GHOST diverges from the LCR after `Block B`. Although the chain following `Block C` is longer at five blocks, there are a total of *six* blocks in the fork starting at `Block C'` when we count uncle blocks. -GHOST and the LCR have a lot in common, by clearly have certain key differences. Although GHOST consumes more information, it also introduces complexities for implementation. The LCR has seen significantly more use within existing blockchains running in production today. Our study of GHOST will, however, prove valuable when we later analyze its modification and adoption in Eth2. +GHOST and the LCR have a lot in common, but clearly have certain key differences. Although GHOST consumes more information, it also introduces complexities for implementation. The LCR has seen significantly more use within existing blockchains running in production today. Our study of GHOST will, however, prove valuable when we later analyze its modification and adoption in Eth2. From f841573a36e8910635b57582a8674a1029c843d2 Mon Sep 17 00:00:00 2001 From: Evan Blank <32708219+evanblank3@users.noreply.github.com> Date: Sun, 13 Mar 2022 19:14:01 -0400 Subject: [PATCH 13/16] fix: PArt to Part --- book/02__blockchains/05__applications.md | 8 ++++---- zh-CN/book/02__blockchains/05__applications.md | 2 +- 2 files changed, 5 insertions(+), 5 deletions(-) diff --git a/book/02__blockchains/05__applications.md b/book/02__blockchains/05__applications.md index 4d905bb..f41b8d3 100644 --- a/book/02__blockchains/05__applications.md +++ b/book/02__blockchains/05__applications.md @@ -60,7 +60,7 @@ def state_transition_function(old_state, transaction): assert tx_input.spent == False # Make sure the input corresponds to a valid signature assert is_valid_signature(signatures[x], tx_input["owner"], transaction) - + # Find the sum of all input values tx_input_sum = 0 for x in range(0, len(transaction["inputs"])): @@ -88,9 +88,9 @@ def state_transition_function(old_state, transaction): for x in range(0, len(transaction["outputs"])): tx_output = transaction["outputs"][x] new_state["outputs"][tx_output["id"]] = tx_output - + return new_state - + ``` Let's run through this system with an example. Suppose that our initial state is as follows: @@ -171,7 +171,7 @@ This transaction consumes `Output #1` as an input and simultaneously generates t We now see one "spent" output and three "unspent" outputs, as expected. If one attempts to run the same transaction through the state transition function against this new state, the function will throw an error as `Output #1` is now marked as "spent." We've successfully managed to design a basic UTXO currency system in only a few lines of code. In practice, we may wish to support more complex behavior within our application. Bitcoin, for instance, replaces the "owner" of each output with a "verification script," essentially a small piece of code that defines the conditions under which an output may be spent. This allows users to attach elaborate ownership models to an output that go beyond simple ownership managed by a digital keypair. -The early ubiquity of the UTXO model was challenged by the introduction of the "account model," popularized by Ethereum. This alternative representation of value exchange more closely resembles digital banking than physical bank notes. In essence, the state of an account-based system consists of a mapping between unique user accounts and information about those accounts. PArt of this information typically includes the "balance" of each account in the unit of the system. Once again examining a simple state of such a model: +The early ubiquity of the UTXO model was challenged by the introduction of the "account model," popularized by Ethereum. This alternative representation of value exchange more closely resembles digital banking than physical bank notes. In essence, the state of an account-based system consists of a mapping between unique user accounts and information about those accounts. Part of this information typically includes the "balance" of each account in the unit of the system. Once again examining a simple state of such a model: ```json { diff --git a/zh-CN/book/02__blockchains/05__applications.md b/zh-CN/book/02__blockchains/05__applications.md index 5bfdfb8..f41b8d3 100644 --- a/zh-CN/book/02__blockchains/05__applications.md +++ b/zh-CN/book/02__blockchains/05__applications.md @@ -171,7 +171,7 @@ This transaction consumes `Output #1` as an input and simultaneously generates t We now see one "spent" output and three "unspent" outputs, as expected. If one attempts to run the same transaction through the state transition function against this new state, the function will throw an error as `Output #1` is now marked as "spent." We've successfully managed to design a basic UTXO currency system in only a few lines of code. In practice, we may wish to support more complex behavior within our application. Bitcoin, for instance, replaces the "owner" of each output with a "verification script," essentially a small piece of code that defines the conditions under which an output may be spent. This allows users to attach elaborate ownership models to an output that go beyond simple ownership managed by a digital keypair. -The early ubiquity of the UTXO model was challenged by the introduction of the "account model," popularized by Ethereum. This alternative representation of value exchange more closely resembles digital banking than physical bank notes. In essence, the state of an account-based system consists of a mapping between unique user accounts and information about those accounts. PArt of this information typically includes the "balance" of each account in the unit of the system. Once again examining a simple state of such a model: +The early ubiquity of the UTXO model was challenged by the introduction of the "account model," popularized by Ethereum. This alternative representation of value exchange more closely resembles digital banking than physical bank notes. In essence, the state of an account-based system consists of a mapping between unique user accounts and information about those accounts. Part of this information typically includes the "balance" of each account in the unit of the system. Once again examining a simple state of such a model: ```json { From fe8b8e048b94c5a2895e8c560c1cd900f47ff042 Mon Sep 17 00:00:00 2001 From: Evan Blank <32708219+evanblank3@users.noreply.github.com> Date: Sun, 13 Mar 2022 19:27:45 -0400 Subject: [PATCH 14/16] fix: noes to nodes --- book/02__blockchains/06__participation.md | 2 +- zh-CN/book/02__blockchains/06__participation.md | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/book/02__blockchains/06__participation.md b/book/02__blockchains/06__participation.md index 960adc3..4936889 100644 --- a/book/02__blockchains/06__participation.md +++ b/book/02__blockchains/06__participation.md @@ -16,4 +16,4 @@ Archival nodes and full nodes can easily expand beyond the reach of resource con One common approach to light client support requires a distinction between "block header" and "block body" components to a block. Within these systems, a block header represents a concise description of the contents of the block body. Specifically, the header will typically contain the roots of Merkle trees that contain the full list of, for example, transactions within the block body. Light clients can download specific pieces of information within a block by requesting a Merkle proof of inclusion for that particular data point. Light clients can therefore be sure that some information was included within a block at a cost of only the size of the Merkle proof. However, these clients cannot ascertain the validity of a block without access to the block's full contents. Light clients must instead use the Proof-of-Work for a block as a proxy for its validity. -Distinctions between various types of clients can often be somewhat arbitrary. This is particularly apparent among full noes that choose to enable or disable different software features. That said, the general definition of full, archival, and light clients can be found in many blockchain systems. New designs introduced in Eth2 only serve to blur any dividing lines further. Eth2 aims to use these changes to improve flexibility and, as a result, expand the platforms from which Eth2 is accessible. +Distinctions between various types of clients can often be somewhat arbitrary. This is particularly apparent among full nodes that choose to enable or disable different software features. That said, the general definition of full, archival, and light clients can be found in many blockchain systems. New designs introduced in Eth2 only serve to blur any dividing lines further. Eth2 aims to use these changes to improve flexibility and, as a result, expand the platforms from which Eth2 is accessible. diff --git a/zh-CN/book/02__blockchains/06__participation.md b/zh-CN/book/02__blockchains/06__participation.md index 960adc3..4936889 100644 --- a/zh-CN/book/02__blockchains/06__participation.md +++ b/zh-CN/book/02__blockchains/06__participation.md @@ -16,4 +16,4 @@ Archival nodes and full nodes can easily expand beyond the reach of resource con One common approach to light client support requires a distinction between "block header" and "block body" components to a block. Within these systems, a block header represents a concise description of the contents of the block body. Specifically, the header will typically contain the roots of Merkle trees that contain the full list of, for example, transactions within the block body. Light clients can download specific pieces of information within a block by requesting a Merkle proof of inclusion for that particular data point. Light clients can therefore be sure that some information was included within a block at a cost of only the size of the Merkle proof. However, these clients cannot ascertain the validity of a block without access to the block's full contents. Light clients must instead use the Proof-of-Work for a block as a proxy for its validity. -Distinctions between various types of clients can often be somewhat arbitrary. This is particularly apparent among full noes that choose to enable or disable different software features. That said, the general definition of full, archival, and light clients can be found in many blockchain systems. New designs introduced in Eth2 only serve to blur any dividing lines further. Eth2 aims to use these changes to improve flexibility and, as a result, expand the platforms from which Eth2 is accessible. +Distinctions between various types of clients can often be somewhat arbitrary. This is particularly apparent among full nodes that choose to enable or disable different software features. That said, the general definition of full, archival, and light clients can be found in many blockchain systems. New designs introduced in Eth2 only serve to blur any dividing lines further. Eth2 aims to use these changes to improve flexibility and, as a result, expand the platforms from which Eth2 is accessible. From 9a0a15ea47bb4dbbc2fd02a50dc10527f916a9ca Mon Sep 17 00:00:00 2001 From: Evan Blank <32708219+evanblank3@users.noreply.github.com> Date: Sun, 13 Mar 2022 19:34:00 -0400 Subject: [PATCH 15/16] fix: transactions to transaction --- book/03__eth1/02__state.md | 2 +- zh-CN/book/03__eth1/02__state.md | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/book/03__eth1/02__state.md b/book/03__eth1/02__state.md index 47b1173..5a8ab28 100644 --- a/book/03__eth1/02__state.md +++ b/book/03__eth1/02__state.md @@ -14,7 +14,7 @@ TODO: World state diagram. Given the ID, or address, of a particular account, the world state returns some information associated with the account. This information is called the "account state." The account state for all accounts, for instance, contain a "balance" field that represents the account's current balance of a currency known as Ether, or ETH. ETH can be transferred between accounts. ETH is also used as the reward for block producers and the fee users must pay for any transactions on the system. -Eth1 allows for two types of accounts. The first is the "user account," which is controlled by a cryptographic private key. The address of a user account is derived from the public key associated with its private key and is therefore guaranteed to be unique. A user account can make a transactions, perhaps an ETH balance transfer, by signing the transaction with the private key. Besides a balance, user account state includes a field for a "nonce," which counts the total number of transactions sent from that account. A user account takes the following structure within Ethereum: +Eth1 allows for two types of accounts. The first is the "user account," which is controlled by a cryptographic private key. The address of a user account is derived from the public key associated with its private key and is therefore guaranteed to be unique. A user account can make a transaction, perhaps an ETH balance transfer, by signing the transaction with the private key. Besides a balance, user account state includes a field for a "nonce," which counts the total number of transactions sent from that account. A user account takes the following structure within Ethereum: ```json { diff --git a/zh-CN/book/03__eth1/02__state.md b/zh-CN/book/03__eth1/02__state.md index ea2d441..10d3c37 100644 --- a/zh-CN/book/03__eth1/02__state.md +++ b/zh-CN/book/03__eth1/02__state.md @@ -12,7 +12,7 @@ Ethereum forever changed the blockchain landscape with the introduction of the a Given the ID, or address, of a particular account, the world state returns some information associated with the account. This information is called the "account state." The account state for all accounts, for instance, contain a "balance" field that represents the account's current balance of a currency known as Ether, or ETH. ETH can be transferred between accounts. ETH is also used as the reward for block producers and the fee users must pay for any transactions on the system. -Eth1 allows for two types of accounts. The first is the "user account," which is controlled by a cryptographic private key. The address of a user account is derived from the public key associated with its private key and is therefore guaranteed to be unique. A user account can make a transactions, perhaps an ETH balance transfer, by signing the transaction with the private key. Besides a balance, user account state includes a field for a "nonce," which counts the total number of transactions sent from that account. A user account takes the following structure within Ethereum: +Eth1 allows for two types of accounts. The first is the "user account," which is controlled by a cryptographic private key. The address of a user account is derived from the public key associated with its private key and is therefore guaranteed to be unique. A user account can make a transaction, perhaps an ETH balance transfer, by signing the transaction with the private key. Besides a balance, user account state includes a field for a "nonce," which counts the total number of transactions sent from that account. A user account takes the following structure within Ethereum: ```json { From 8b4c96f58058ac70279c53f04f6ac0bef90cef2a Mon Sep 17 00:00:00 2001 From: Evan Blank <32708219+evanblank3@users.noreply.github.com> Date: Sun, 13 Mar 2022 19:34:43 -0400 Subject: [PATCH 16/16] fix: remove a --- book/03__eth1/07__clients.md | 2 +- zh-CN/book/03__eth1/07__clients.md | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/book/03__eth1/07__clients.md b/book/03__eth1/07__clients.md index 9c94192..3441c60 100644 --- a/book/03__eth1/07__clients.md +++ b/book/03__eth1/07__clients.md @@ -32,7 +32,7 @@ The root of the world state trie can be found in every block header. Light clien Diagram showing requests necessary to get state element. ::: -Light clients can employ a very similar protocol to check for the inclusion of a transaction within a block. Transaction receipts already contain the index of a transaction in the full list of a transactions in a block. Light clients can therefore simply request nodes from a block's transaction trie until they find their desired transaction: +Light clients can employ a very similar protocol to check for the inclusion of a transaction within a block. Transaction receipts already contain the index of a transaction in the full list of transactions in a block. Light clients can therefore simply request nodes from a block's transaction trie until they find their desired transaction: ::: tip TODO Diagram showing requests necessary to get transaction. diff --git a/zh-CN/book/03__eth1/07__clients.md b/zh-CN/book/03__eth1/07__clients.md index 20af44e..699cb25 100644 --- a/zh-CN/book/03__eth1/07__clients.md +++ b/zh-CN/book/03__eth1/07__clients.md @@ -26,7 +26,7 @@ The root of the world state trie can be found in every block header. Light clien ::: tip TODO Diagram showing requests necessary to get state element. ::: -Light clients can employ a very similar protocol to check for the inclusion of a transaction within a block. Transaction receipts already contain the index of a transaction in the full list of a transactions in a block. Light clients can therefore simply request nodes from a block's transaction trie until they find their desired transaction: +Light clients can employ a very similar protocol to check for the inclusion of a transaction within a block. Transaction receipts already contain the index of a transaction in the full list of transactions in a block. Light clients can therefore simply request nodes from a block's transaction trie until they find their desired transaction: ::: tip TODO Diagram showing requests necessary to get transaction. :::