From cb160d75362b778b544ff9d9b58008eceb1a8d95 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Tom=C3=A1s=20Arjovsky?= Date: Wed, 2 Aug 2023 15:29:33 +0200 Subject: [PATCH 01/10] Add consensus basic notes --- docs/consensus.md | 57 +++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 57 insertions(+) create mode 100644 docs/consensus.md diff --git a/docs/consensus.md b/docs/consensus.md new file mode 100644 index 000000000..0d279944f --- /dev/null +++ b/docs/consensus.md @@ -0,0 +1,57 @@ +# Consensus basics + +## Classic consensus + +As a distributed state machine, the EVM takes some elements from classic consensus algorithms, such as [Raft](https://raft.github.io/): + +- Users of the network send commands (transactions) to change the state of the EVM. +- Nodes propagate those transactions. +- A leader is elected and proposes a transaction to be the next one to be applied. +- As there's a single leader, each node will receive that transaction and add it to its local copy of the transaction history. +- Mechanisms are put in place so that nodes make sure that they have the same order of transactions and applying them to their local state machines is safe. + +Algorithms like Raft assume a setup where nodes are known, running the same software, well intentioned, and the only problems arise from network/connectivity issues, which are inherent to any distributed system. They prioritize safety and require 50% of the network plus one node to be live in order to be available. + +## Blockchain consensus + +Blockchains like ethereum are designed to prioritize liveness in a bizantine environment, where anyone can join the network running a software that may be different, due to bugs or intentionally ill-intentioned. This means there are several fundamental differences: + +- Cryptographic signatures are introduced to validate authority of transactions. +- Transactions are batched into blocks, so that the consensus overhead is reduced. +- Verifying the integrity of blocks needs to be easy. For this reason each block is linked to its parent, each block has a hash of its own contents, and part of each block's content is its parent hash. That means that changing any block in history will cause noticeable changes in the block's hash. +- Leaders are not elected by a simple majority, but by algorithms such as proof of work or proof of stake, that introduce economic incentives so that participating in consensus is not cost-free and chances of spamming the protocol are reduced. They are only elected for a single block and the algorithm is repeated for the next one. +- Liveness is prioritized over safety, by allowing forks: different versions of history can be live at the same time. + +## Forks + +Due to networking delays or client differences, a client may receive to different blocks at the same time as the next one. + +```mermaid +graph LR + Genesis --> A + Genesis --> B + A --> C + A --> D +``` + +This means that instead of a block chain we get a block tree, were each branch is called a "fork". Consensus, in this context, means nodes need to chose the same forks as the canonical chain, so that they share the same history. The criteria to chose from a particular fork is called "Fork-choice algorithm". + +```mermaid +graph LR + Genesis --> A + Genesis --> B + A --> C + A --> D + + classDef chosen fill: #666666 + class Genesis chosen + class A chosen + class D chosen +``` + +Genesis will always be chosen as it will be the first block in any chain. Afterwards, if blocks A and D are chose by the algorithm, that means the canonical chain will now be: + +```mermaid +graph LR + Genesis --> A --> D +``` From 9177d571b724d13ec5a31bec3722d8c275f1538d Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Tom=C3=A1s=20Arjovsky?= Date: Fri, 4 Aug 2023 18:43:42 +0200 Subject: [PATCH 02/10] Complete consensus doc, add fork-choice (missing slashings) and finality --- docs/consensus.md | 31 ++++++++++++++++++++--- docs/finality.md | 3 +++ docs/fork_choice.md | 60 +++++++++++++++++++++++++++++++++++++++++++++ 3 files changed, 90 insertions(+), 4 deletions(-) create mode 100644 docs/finality.md create mode 100644 docs/fork_choice.md diff --git a/docs/consensus.md b/docs/consensus.md index 0d279944f..715afb57a 100644 --- a/docs/consensus.md +++ b/docs/consensus.md @@ -7,12 +7,12 @@ As a distributed state machine, the EVM takes some elements from classic consens - Users of the network send commands (transactions) to change the state of the EVM. - Nodes propagate those transactions. - A leader is elected and proposes a transaction to be the next one to be applied. -- As there's a single leader, each node will receive that transaction and add it to its local copy of the transaction history. +- As there's a single leader, each node will receive that transaction and add it to its local copy of the transaction history. - Mechanisms are put in place so that nodes make sure that they have the same order of transactions and applying them to their local state machines is safe. Algorithms like Raft assume a setup where nodes are known, running the same software, well intentioned, and the only problems arise from network/connectivity issues, which are inherent to any distributed system. They prioritize safety and require 50% of the network plus one node to be live in order to be available. -## Blockchain consensus +## Bizantine consensus Blockchains like ethereum are designed to prioritize liveness in a bizantine environment, where anyone can join the network running a software that may be different, due to bugs or intentionally ill-intentioned. This means there are several fundamental differences: @@ -20,11 +20,10 @@ Blockchains like ethereum are designed to prioritize liveness in a bizantine env - Transactions are batched into blocks, so that the consensus overhead is reduced. - Verifying the integrity of blocks needs to be easy. For this reason each block is linked to its parent, each block has a hash of its own contents, and part of each block's content is its parent hash. That means that changing any block in history will cause noticeable changes in the block's hash. - Leaders are not elected by a simple majority, but by algorithms such as proof of work or proof of stake, that introduce economic incentives so that participating in consensus is not cost-free and chances of spamming the protocol are reduced. They are only elected for a single block and the algorithm is repeated for the next one. -- Liveness is prioritized over safety, by allowing forks: different versions of history can be live at the same time. ## Forks -Due to networking delays or client differences, a client may receive to different blocks at the same time as the next one. +In ethereum, liveness is prioritized over safety, by allowing forks: different versions of history can be live at the same time. Due to networking delays (e.g. block production being faster than propagation) or client differences, a client may receive to different blocks at the same time as the next one. ```mermaid graph LR @@ -55,3 +54,27 @@ Genesis will always be chosen as it will be the first block in any chain. Afterw graph LR Genesis --> A --> D ``` + +## Ethereum consensus algorithms + +In post-merge Ethereum, consensus is reached by two combined fork-related algorithms: + +- LMD GHOST: provides per-slot liveness by allowing blocks to be added in separate forks if they are not in the chain percieved as canonical. +- Casper FFC: provides some level of safety by defining a finalization criterion. It takes a fork tree and defines a strategy to prune it (make branches inaccessible). Once a block is tagged as "final", blocks that aren't either parents (which are also final) or decendents of it, are not valid blocks. This prevents long reorganizations, which might make users vulnerable to double spends. + +Here we expand a bit on those: + +- Fork choice: [LMD GHOST](fork_choice.md). +- Finality: [Casper FFC](finality.md). + +### Attestation messages + +A single vote emitted by a validator consists of the following information: + +- slot at which the attestation is being emmited. +- index: index of the validator within the comittee. +- beacon block root: the actual vote. This identifies a block by the merkle root of its beacon state. +- source: checkpoint +- target: checkpoint + +This messages are propagated either directly (attestation gossip) or indirectly (contained in blocks). diff --git a/docs/finality.md b/docs/finality.md new file mode 100644 index 000000000..5b052772c --- /dev/null +++ b/docs/finality.md @@ -0,0 +1,3 @@ +# Finalization: Casper FFG + +The name stands for Friendly Finality Gadget. It as a "finality gadget" as it always works on top of a block-proposing algorithm. diff --git a/docs/fork_choice.md b/docs/fork_choice.md new file mode 100644 index 000000000..d23474f7e --- /dev/null +++ b/docs/fork_choice.md @@ -0,0 +1,60 @@ +# Fork-choice: LMD GHOST + +Let's separate the two parts of the name. + +- GHOST: Greediest, heaviest-observed sub-tree. The algorithm recognizes that by voting block B, we also vote its parent, block A, so the amount of votes of A represents the "weitght" of that whole tree. +- LMD: in proof of work, each block would be a single vote for its parents. In proof of stake, each validator gives attestations/votes to the block they think is the current head of the chain (message driven). "Latest" means that only the last attestation for each validator will be taken into account. + +By choosing a fork, each node has a single, linear chain of blocks that it considers canonical. The last child of that chain is called the chain's "head". + +## Reacting to an attestation + +When an attestation arrives, the `on_attestation` callback must: + +1. Perform the [validity checks](https://eth2book.info/capella/part3/forkchoice/phase0/#validate_on_attestation). tl;dr: the slot and epoch need to be right, the vote must be for a block we have, validate the signature and check it doesn't conflict with a different attestation by the same validator. +2. [Save the attestation](https://eth2book.info/capella/part3/forkchoice/phase0/#update_latest_messages) as that validator's latest message. If there's one already, update the value. + +## Choosing forks + +We now have a store of each validator's latest vote, which allows LMD GHOST to work as a `get_head(store) -> Block` function. + +We first need to calculate each block's weight: + +- For leaf blocks, we calculate their weight by checking how much votes they have. +- For each branch block we calculate its weight as the sum of the weight of every child, plus its own votes. We repeat this until we reach the root, which will be the last finalized block (there won't be any branches before, so there won't be any more fork-choice to perform). + +This way we calculate the weight not only for each block, but for the subtree were that block is the root. + +Afterwards, when we want to determine which is the head of the chain, we traverse the tree, starting from the root, and greedily (without looking further ahead) we go block by block chosing the sub-tree with the highest weight. + +Let's look at an example: + +```mermaid +graph LR + + Genesis --> A[A\nb=10\nw=50] + Genesis --> B[B\nb=20\nw=20] + A --> C[C\nb=15\nw=15] + A --> D[D\nb=25\nw=25] + + classDef chosen fill: #666666 + class Genesis chosen + class A chosen + class D chosen +``` + +Here, individual block weights are represented by "b", while subtree weights are represented by "w". Some observations: + +- $W = B$ for all leaf blocks, as leafs are their own whole subtree. +- $W_A=W_C+W_B +B_A= B_B + B_C + B_A$ +- While the individual weight of $A$ is smaller than $B$, its children make the $A$ subtree heavier than the $B$ subtree, so its chosen by LMD GHOST over $B$. + +In general: + +$$W_N = B_N + \sum_i^{i \in \text{children}[N]}W_i$$ + +## Guarantees + +- Majority honest progress: if the network has over 50% nodes running this algorithm honestly, the chain progresses and each older block is exponentially more unlikely to be reverted. +- Stability: fork-choice is self-reinforcing and acts as a good predictor of the next block. +- Manipulation resistence. Not only is it hard to build a secret chain and propose it, but it prevents getting attestations for it, so the current canonical one is always more likely to be heavier. This holds even if the length of the secret chain is higher. From 8f5e1241c8e2a9899823fbe4e35c1191a0b81d06 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Tom=C3=A1s=20Arjovsky?= Date: Fri, 4 Aug 2023 18:59:19 +0200 Subject: [PATCH 03/10] Add slashing --- docs/fork_choice.md | 19 +++++++++++++++++++ 1 file changed, 19 insertions(+) diff --git a/docs/fork_choice.md b/docs/fork_choice.md index d23474f7e..f5ec3595d 100644 --- a/docs/fork_choice.md +++ b/docs/fork_choice.md @@ -53,6 +53,25 @@ In general: $$W_N = B_N + \sum_i^{i \in \text{children}[N]}W_i$$ +## Slashing + +In the previous scheme, there are two rewards: + +- Proposer rewards, given to a proposer when their block is included in the chain. This also adds an incentive for them to try to predict the most-likely branch to be the canonical one. +- Attester rewards, which are smaller. These are in effect if the blocks they attest to are included. + +These incentives, however, are not enough. To maximize their likelyhood of getting rewards, they may missbehave: + +- Proposers may propose a block for every current fork. +- Attesters may attest to every current head in their local chains. + +These missbehaviors debilitate the protocol (they give weight to all forks) and no honest node running fork-choice would take part on them. To prevent them, nodes that are detected while doing them are slashed (punished), which means that they are excluded from the validator set and a portion of their stake is burned. + +In turn, nodes that provide proof of offending nodes are given a whistleblower reward. Proofs are: + +- For proposer slashing: two block headers in the same slot signed by the same signature. +- For attester slashing: two attestations signed in the same slot by the same signature. + ## Guarantees - Majority honest progress: if the network has over 50% nodes running this algorithm honestly, the chain progresses and each older block is exponentially more unlikely to be reverted. From 75b1afccd65cbffe1e5e307835a6484ad55bcaba Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Tom=C3=A1s=20Arjovsky?= Date: Fri, 4 Aug 2023 19:17:18 +0200 Subject: [PATCH 04/10] small typos and fixes --- docs/consensus.md | 13 ++++--------- docs/finality.md | 2 ++ docs/fork_choice.md | 6 +++--- 3 files changed, 9 insertions(+), 12 deletions(-) diff --git a/docs/consensus.md b/docs/consensus.md index 715afb57a..e3f69de35 100644 --- a/docs/consensus.md +++ b/docs/consensus.md @@ -14,7 +14,7 @@ Algorithms like Raft assume a setup where nodes are known, running the same soft ## Bizantine consensus -Blockchains like ethereum are designed to prioritize liveness in a bizantine environment, where anyone can join the network running a software that may be different, due to bugs or intentionally ill-intentioned. This means there are several fundamental differences: +Blockchains like Ethereum work in a bizantine environment, where anyone can join the network running a software that may be different, due to bugs or intentionally. This means there are several fundamental differences: - Cryptographic signatures are introduced to validate authority of transactions. - Transactions are batched into blocks, so that the consensus overhead is reduced. @@ -23,7 +23,7 @@ Blockchains like ethereum are designed to prioritize liveness in a bizantine env ## Forks -In ethereum, liveness is prioritized over safety, by allowing forks: different versions of history can be live at the same time. Due to networking delays (e.g. block production being faster than propagation) or client differences, a client may receive to different blocks at the same time as the next one. +In Ethereum, liveness is prioritized over safety, by allowing forks: different versions of history can be live at the same time. Due to networking delays (e.g. block production being faster than propagation) or client differences, a client may receive to different blocks at the same time as the next one. ```mermaid graph LR @@ -59,13 +59,8 @@ graph LR In post-merge Ethereum, consensus is reached by two combined fork-related algorithms: -- LMD GHOST: provides per-slot liveness by allowing blocks to be added in separate forks if they are not in the chain percieved as canonical. -- Casper FFC: provides some level of safety by defining a finalization criterion. It takes a fork tree and defines a strategy to prune it (make branches inaccessible). Once a block is tagged as "final", blocks that aren't either parents (which are also final) or decendents of it, are not valid blocks. This prevents long reorganizations, which might make users vulnerable to double spends. - -Here we expand a bit on those: - -- Fork choice: [LMD GHOST](fork_choice.md). -- Finality: [Casper FFC](finality.md). +- LMD GHOST: a fork-choice algorithm based on votes (attestations). If a majority of nodes follow this algorithm, they will tend to converge to the same canonical chain. We expand more on it on [this document](fork_choice.md). +- Casper FFC: provides some level of safety by defining a finalization criterion. It takes a fork tree and defines a strategy to prune it (make branches inaccessible). Once a block is tagged as "final", blocks that aren't either parents (which are also final) or decendents of it, are not valid blocks. This prevents long reorganizations, which might make users vulnerable to double spends. We expand on it in [this document](finality.md). ### Attestation messages diff --git a/docs/finality.md b/docs/finality.md index 5b052772c..9605a631c 100644 --- a/docs/finality.md +++ b/docs/finality.md @@ -1,3 +1,5 @@ # Finalization: Casper FFG The name stands for Friendly Finality Gadget. It as a "finality gadget" as it always works on top of a block-proposing algorithm. + +**This document will be expaned in a different PR** diff --git a/docs/fork_choice.md b/docs/fork_choice.md index f5ec3595d..5b0fa1358 100644 --- a/docs/fork_choice.md +++ b/docs/fork_choice.md @@ -2,8 +2,8 @@ Let's separate the two parts of the name. -- GHOST: Greediest, heaviest-observed sub-tree. The algorithm recognizes that by voting block B, we also vote its parent, block A, so the amount of votes of A represents the "weitght" of that whole tree. -- LMD: in proof of work, each block would be a single vote for its parents. In proof of stake, each validator gives attestations/votes to the block they think is the current head of the chain (message driven). "Latest" means that only the last attestation for each validator will be taken into account. +- GHOST: Greediest, heaviest-observed sub-tree. The algorithm recognizes that by voting block $B$, we also vote its parent, block $A$, so the amount of votes of A represents the "weight" of that whole tree. +- LMD: each validator gives attestations/votes to the block they think is the current head of the chain (Message Driven). "Latest" means that only the last attestation for each validator will be taken into account. By choosing a fork, each node has a single, linear chain of blocks that it considers canonical. The last child of that chain is called the chain's "head". @@ -58,7 +58,7 @@ $$W_N = B_N + \sum_i^{i \in \text{children}[N]}W_i$$ In the previous scheme, there are two rewards: - Proposer rewards, given to a proposer when their block is included in the chain. This also adds an incentive for them to try to predict the most-likely branch to be the canonical one. -- Attester rewards, which are smaller. These are in effect if the blocks they attest to are included. +- Attester rewards, which are smaller. These are given if the blocks they attest to are included. These incentives, however, are not enough. To maximize their likelyhood of getting rewards, they may missbehave: From 57ca51ff0dfd3b26f4eca2ee29f9fedf1407bfde Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Tom=C3=A1s=20Arjovsky?= Date: Tue, 8 Aug 2023 14:31:50 +0200 Subject: [PATCH 05/10] fix typos and errors --- docs/fork_choice.md | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/docs/fork_choice.md b/docs/fork_choice.md index 5b0fa1358..889fd8b98 100644 --- a/docs/fork_choice.md +++ b/docs/fork_choice.md @@ -2,7 +2,7 @@ Let's separate the two parts of the name. -- GHOST: Greediest, heaviest-observed sub-tree. The algorithm recognizes that by voting block $B$, we also vote its parent, block $A$, so the amount of votes of A represents the "weight" of that whole tree. +- GHOST: **G**reediest, **H**eaviest-**O**bserved **S**ub-**T**ree. The algorithm provides a strategy to choose between two forks/branches. Each branch points to a block, and each block can be thought of the root of a subtree containing all of its child nodes. The weight of the subtree is the sum of the weights af all blocks in it. The weight in each individual block is obtained from the attestations on them. - LMD: each validator gives attestations/votes to the block they think is the current head of the chain (Message Driven). "Latest" means that only the last attestation for each validator will be taken into account. By choosing a fork, each node has a single, linear chain of blocks that it considers canonical. The last child of that chain is called the chain's "head". @@ -23,7 +23,7 @@ We first need to calculate each block's weight: - For leaf blocks, we calculate their weight by checking how much votes they have. - For each branch block we calculate its weight as the sum of the weight of every child, plus its own votes. We repeat this until we reach the root, which will be the last finalized block (there won't be any branches before, so there won't be any more fork-choice to perform). -This way we calculate the weight not only for each block, but for the subtree were that block is the root. +This way we calculate the weight not only for each block, but for the subtree where that block is the root. Afterwards, when we want to determine which is the head of the chain, we traverse the tree, starting from the root, and greedily (without looking further ahead) we go block by block chosing the sub-tree with the highest weight. @@ -60,14 +60,14 @@ In the previous scheme, there are two rewards: - Proposer rewards, given to a proposer when their block is included in the chain. This also adds an incentive for them to try to predict the most-likely branch to be the canonical one. - Attester rewards, which are smaller. These are given if the blocks they attest to are included. -These incentives, however, are not enough. To maximize their likelyhood of getting rewards, they may missbehave: +These incentives, however, are not enough. To maximize their likelyhood of getting rewards, they may misbehave: - Proposers may propose a block for every current fork. - Attesters may attest to every current head in their local chains. -These missbehaviors debilitate the protocol (they give weight to all forks) and no honest node running fork-choice would take part on them. To prevent them, nodes that are detected while doing them are slashed (punished), which means that they are excluded from the validator set and a portion of their stake is burned. +These misbehaviors debilitate the protocol (they give weight to all forks) and no honest node running fork-choice would take part on them. To prevent them, nodes that are detected while doing them are slashed (punished), which means that they are excluded from the validator set and a portion of their stake is burned. -In turn, nodes that provide proof of offending nodes are given a whistleblower reward. Proofs are: +Nodes provide proofs of the offenses, and proposers including them in blocks get whistleblower rewards. Proofs are: - For proposer slashing: two block headers in the same slot signed by the same signature. - For attester slashing: two attestations signed in the same slot by the same signature. From dd6bbf870cbc3a69fb5e6642422bd495c9cc923c Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Tom=C3=A1s=20Arjovsky?= Date: Tue, 8 Aug 2023 15:52:36 +0200 Subject: [PATCH 06/10] "many" typo MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Co-authored-by: Tomás <47506558+MegaRedHand@users.noreply.github.com> --- docs/fork_choice.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/fork_choice.md b/docs/fork_choice.md index 889fd8b98..843e07469 100644 --- a/docs/fork_choice.md +++ b/docs/fork_choice.md @@ -20,7 +20,7 @@ We now have a store of each validator's latest vote, which allows LMD GHOST to w We first need to calculate each block's weight: -- For leaf blocks, we calculate their weight by checking how much votes they have. +- For leaf blocks, we calculate their weight by checking how many votes they have. - For each branch block we calculate its weight as the sum of the weight of every child, plus its own votes. We repeat this until we reach the root, which will be the last finalized block (there won't be any branches before, so there won't be any more fork-choice to perform). This way we calculate the weight not only for each block, but for the subtree where that block is the root. From 06fc08eb3c2da8a06983aecaf33c0f7f70562133 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Tom=C3=A1s=20Arjovsky?= Date: Tue, 8 Aug 2023 15:52:46 +0200 Subject: [PATCH 07/10] two typo MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Co-authored-by: Tomás <47506558+MegaRedHand@users.noreply.github.com> --- docs/consensus.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/consensus.md b/docs/consensus.md index e3f69de35..c23ca8a15 100644 --- a/docs/consensus.md +++ b/docs/consensus.md @@ -23,7 +23,7 @@ Blockchains like Ethereum work in a bizantine environment, where anyone can join ## Forks -In Ethereum, liveness is prioritized over safety, by allowing forks: different versions of history can be live at the same time. Due to networking delays (e.g. block production being faster than propagation) or client differences, a client may receive to different blocks at the same time as the next one. +In Ethereum, liveness is prioritized over safety, by allowing forks: different versions of history can be live at the same time. Due to networking delays (e.g. block production being faster than propagation) or client differences, a client may receive two different blocks at the same time as the next one. ```mermaid graph LR From 4343205f06b0c20b5407ab966d9dc620d2ed974a Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Tom=C3=A1s=20Arjovsky?= Date: Tue, 8 Aug 2023 15:52:58 +0200 Subject: [PATCH 08/10] FFG typo MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Co-authored-by: Tomás <47506558+MegaRedHand@users.noreply.github.com> --- docs/consensus.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/consensus.md b/docs/consensus.md index c23ca8a15..621be38cb 100644 --- a/docs/consensus.md +++ b/docs/consensus.md @@ -60,7 +60,7 @@ graph LR In post-merge Ethereum, consensus is reached by two combined fork-related algorithms: - LMD GHOST: a fork-choice algorithm based on votes (attestations). If a majority of nodes follow this algorithm, they will tend to converge to the same canonical chain. We expand more on it on [this document](fork_choice.md). -- Casper FFC: provides some level of safety by defining a finalization criterion. It takes a fork tree and defines a strategy to prune it (make branches inaccessible). Once a block is tagged as "final", blocks that aren't either parents (which are also final) or decendents of it, are not valid blocks. This prevents long reorganizations, which might make users vulnerable to double spends. We expand on it in [this document](finality.md). +- Casper FFG: provides some level of safety by defining a finalization criterion. It takes a fork tree and defines a strategy to prune it (make branches inaccessible). Once a block is tagged as "final", blocks that aren't either parents (which are also final) or decendents of it, are not valid blocks. This prevents long reorganizations, which might make users vulnerable to double spends. We expand on it in [this document](finality.md). ### Attestation messages From a004a48a63e61aaee3b730271f6eca35a8517c87 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Tom=C3=A1s=20Arjovsky?= Date: Tue, 8 Aug 2023 15:53:09 +0200 Subject: [PATCH 09/10] typos MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Co-authored-by: Tomás <47506558+MegaRedHand@users.noreply.github.com> --- docs/fork_choice.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/fork_choice.md b/docs/fork_choice.md index 843e07469..3f88145a5 100644 --- a/docs/fork_choice.md +++ b/docs/fork_choice.md @@ -2,7 +2,7 @@ Let's separate the two parts of the name. -- GHOST: **G**reediest, **H**eaviest-**O**bserved **S**ub-**T**ree. The algorithm provides a strategy to choose between two forks/branches. Each branch points to a block, and each block can be thought of the root of a subtree containing all of its child nodes. The weight of the subtree is the sum of the weights af all blocks in it. The weight in each individual block is obtained from the attestations on them. +- GHOST: **G**reediest, **H**eaviest-**O**bserved **S**ub-**T**ree. The algorithm provides a strategy to choose between two forks/branches. Each branch points to a block, and each block can be thought of as the root of a subtree containing all of its child nodes. The weight of the subtree is the sum of the weights of all blocks in it. The weight of each individual block is obtained from the attestations on them. - LMD: each validator gives attestations/votes to the block they think is the current head of the chain (Message Driven). "Latest" means that only the last attestation for each validator will be taken into account. By choosing a fork, each node has a single, linear chain of blocks that it considers canonical. The last child of that chain is called the chain's "head". From 2565b94208bd13c80c7a78d63da493681482613d Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Tom=C3=A1s=20Arjovsky?= Date: Tue, 8 Aug 2023 15:53:19 +0200 Subject: [PATCH 10/10] likelihood typo MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Co-authored-by: Tomás <47506558+MegaRedHand@users.noreply.github.com> --- docs/fork_choice.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/fork_choice.md b/docs/fork_choice.md index 3f88145a5..b1f97522c 100644 --- a/docs/fork_choice.md +++ b/docs/fork_choice.md @@ -60,7 +60,7 @@ In the previous scheme, there are two rewards: - Proposer rewards, given to a proposer when their block is included in the chain. This also adds an incentive for them to try to predict the most-likely branch to be the canonical one. - Attester rewards, which are smaller. These are given if the blocks they attest to are included. -These incentives, however, are not enough. To maximize their likelyhood of getting rewards, they may misbehave: +These incentives, however, are not enough. To maximize their likelihood of getting rewards, they may misbehave: - Proposers may propose a block for every current fork. - Attesters may attest to every current head in their local chains.