From 5ff687201ff4e7aea92e417a0d0755125a43a9bc Mon Sep 17 00:00:00 2001 From: happi Date: Mon, 20 Jan 2025 11:09:33 +0100 Subject: [PATCH 1/6] Update with new fork resolution and reward distribution. --- Periodically-Syncing-HyperChains.md | 82 +++++------------------------ staking.md | 81 ++++++++++++++++------------ 2 files changed, 61 insertions(+), 102 deletions(-) diff --git a/Periodically-Syncing-HyperChains.md b/Periodically-Syncing-HyperChains.md index bdc3a3f..d123754 100644 --- a/Periodically-Syncing-HyperChains.md +++ b/Periodically-Syncing-HyperChains.md @@ -675,6 +675,11 @@ below `MINIMUM_STAKE`.) ### Consensus Details +For hyperchains we calculate the "difficulty" of a normal block as the difficulty of the preceding +block + 1. The difficulty of a hole is the same as the difficulty of the preceding block. +Choosing the best fork is done by choosing the block with the highest difficulty. In the case of two +The block with the highest height is better for blocks with the same difficulty. + #### Producer diagram ```mermaid @@ -777,7 +782,7 @@ graph TD penalty["Prepare proof of all 'double' blocks in same slot. Post proof of missconduct. Fill all 'double' blocks with 'holes' "] - n21["Prefer chain with holes late"] + n21["Prefer chain with holes early"] done["pick that fork"] @@ -791,65 +796,6 @@ graph TD ``` -#### More... -```mermaid -graph TD - n13["Unsolved or un-placed problems"] - n14["Gossiped block is too late"] - n15["Network split?"] - n16["Lasting multiple epochs?"] - n17["No majority can't finish the epoch"] - n18["Malicious or bad nodes"] - n19["How to choose the best fork?"] - n20["Pick 1 with fewest holes"] - n21["Prefer chain with holes late"] - n22["Can a producer do multiple blocks in a slot\nNO!"] - n23["How to detect?"] - n24["Act?"] - n25["Producer timing Design decisions"] - n26["How long to wait?"] - n27["Prefer to gossip early?"] - n28["But prefer to build complete chain!\nHow to incentivize?"] - - - - n13 --> n14 - n13 --> n15 - n15 --> n16 - n15 --> n17 - n13 --> n18 - n10 --> n19 - n19 --> n20 - n19 --> n21 - n13 --> n22 - n15 --> n23 - n15 --> n24 - n8 --> n25 - n25 --> n26 - n25 --> n27 - n27 --> n28 - - ``` - -```mermaid -graph TD - - n29["Attacks?"] - n30["Double spend"] - n31["Halt"] - n32["Take over\n* Force majority while not having majority stake"] - n34["Penalties\nhttps://ethereum.org/en/developers/docs/consensus-mechanisms/pos/#crypto-economic-security"] - n35["Extra end of epoch logic"] - - - n29 --> n30 - n29 --> n31 - n29 --> n32 - n13 --> n34 - n13 --> n35 - ``` - - ### End of Epoch Fork Resolution A Byzantine Fault Tolerant (BFT) voting mechanism is proposed to allow producers to reach consensus on the correct fork. @@ -1040,18 +986,16 @@ Penalties are enforced to deter malicious actions or protocol violations. Slasha - **Definition**: A validator casts multiple votes for different forks or outcomes in a single voting phase. This action is considered malicious and undermines the voting process. - **Penalty**: The validator's stake is slashed, and their voting rights are suspended for one or more epochs. The network may also distribute the slashed amount among honest validators as a reward for maintaining integrity. -3. **Ignoring Votes:** - - - **Definition**: A validator deliberately ignores valid votes when creating a "Finalize" transaction, attempting to force a minority or incorrect outcome. This is only an offense if the ignored votes - would change the outcome. This is so that it is not an attack to send in a late vote for the majority - outcome and then slash the validator for not including it. - - **Penalty**: The validator's stake is partially slashed, and they are penalized with a temporary ban from participating in leader elections or block production if their deposit stakes fall below the minimum. +3. **Not producing blocks:** -4. **Submitting an incorrect block, or not submitting a block in time**: If a block producer's block has been replaced by holes more than 50% of the time during one epoch. + - **Definition**: A validator that was chosen leader but that does not produce any + valid or in time blocks during an epoch. + - **Penalty**: The validator's stake is partialy slashed down below minimum stake, + causing a temporary ban from participating in leader elections and block production. -5. **Ignoring the finalize_epoch fork**: This is a minor event just as any other incorrect block. It should probably just be ignored with no penalty. +4. **Ignoring the finalize_epoch fork**: This is a minor event just as any other incorrect block. It should probably just be ignored with no penalty. -6. **Ignoring a correctly pinned fork**: This is a minor event just as any other incorrect block. It should probably just be ignored with no penalty. +5. **Ignoring a correctly pinned fork**: This is a minor event just as any other incorrect block. It should probably just be ignored with no penalty. #### Submitting Proof of Wrongdoings diff --git a/staking.md b/staking.md index 8e19afd..0400020 100644 --- a/staking.md +++ b/staking.md @@ -424,7 +424,7 @@ the whole locking period. - Serves as a placeholder to maintain the continuity of the blockchain. - **No Rewards for Holes**: - Validators producing holes do **not** receive any rewards for these blocks. - - The missed block's potential rewards are effectively forfeited, including the award of fees for following the previous block. + - The missed block's potential rewards are effectively forfeited, including the award of fees for following the previous block, and for the following block. ## Reward Distribution for Correct Blocks @@ -439,34 +439,43 @@ When a validator successfully produces a block on time, the rewards are distribu ### Distribution Breakdown - **Block Producer (Current Validator)**: - - Receives **X% of the block fees**, X defaults to 75% but is configurable in genesis. + - Receives **X% of the block fees**, X defaults to 40% but is configurable in genesis. - Receives the **full epoch coinbase reward**. - **Incentive**: Encourages validators to produce blocks promptly and include transactions to maximize fees. - **Next Validator (Following Validator)**: - - Receives **(100-X)% of the block fees** from the previous block. + - Receives **Y% of the block fees**, Y defaults to 30% from the previous block. - **Role**: - Validates the correctness of the previous block. - Builds upon it by producing the next block in the chain. - **Incentive**: Motivates validators to participate actively in the validation process and ensures they have a stake in the accuracy of preceding blocks. +- **Previous Producer (Preceding Validator)**: + - Receives **(100-(X+Y))% of the block fees** from the following block. + - **Role**: + - Validates the correctness of the previous block. + - Is encourage to produce the block in time so that the next validator builds on top of it. + - **Incentive**: Motivates validators to produce blocks in a timely manner. + + ### Visualization of Reward Flow ```plaintext -+-----------------------+ +-----------------------+ -| | | | -| Validator A | | Validator B | -| (Block Producer) | | (Next Validator) | -| | | | -| - Validates Block N-1 | | - Validates Block N | -| - Produces Block N | | - Builds Block N+1 | -| - Receives: | | - Receives: | -| * 25% of N-1 Fees | | * 75% of Block N+1 | -| * 75% of Block |------------------>| * 25% of N-1 Fees | -| N Fees | | | -| * Epoch Coinbase | | * Epoch Coinbase | -| | | | -+-----------------------+ +-----------------------+ ++-----------------------+ +-----------------------+ +-----------------------+ +| | | | | | +| Validator: A | | Validator B | | Validator C | +| Block: N-1 | | Block: N | | Block: N+1 | +| (Previous Producer) | | (Block Producer) | | (Next Validator) | +| | | | | | +| - Validates Block N-2 | | - Validates Block N-1 | | - Validates Block N | +| - Produces Block N-1 | | - Produces Block N | | - Builds Block N+1 | +| - Receives Fees: | | - Receives Fees: | | - Receives Fees: | +| * 30% of N-2 | | * 30% of N-1 | | * 30% of N | +| * 40% of N-1 |-------->| * 40% of N |------->| * 40% of N+1 | +| * 30% of N | | * 30% of N+1 | | * 30% of N+2 | +| * Epoch Coinbase | | * Epoch Coinbase | | * Epoch Coinbase | +| | | | | | ++-----------------------+ +-----------------------+ +-----------------------+ ``` ## Fee Payout Timing @@ -489,9 +498,9 @@ When a validator successfully produces a block on time, the rewards are distribu ### Configurable Parameters -- **75/25 Fee Split**: +- **30/40/30 Fee Split**: - The proportion of fees allocated to the block producer and the next validator is **configurable** for a Hyperchain. - - Networks can adjust the split (e.g., 80/20, 70/30) based on governance decisions or to incentivize certain behaviors. + - Networks can adjust the split (e.g., 10/70/20, 20/30/50) based on governance decisions or to incentivize certain behaviors. - **Epoch Coinbase Amount**: - The coinbase reward (newly minted tokens) per epoch is **configurable** per chain. @@ -523,36 +532,43 @@ When a validator successfully produces a block on time, the rewards are distribu ### Assumptions -- **Fee Split**: 75% to block producer, 25% to next validator. +- **Fee Split**: 30% previous produer, 40% to block producer, 30% to next validator. - **Epoch Coinbase**: 10 tokens per epoch. - **Block Fees**: Varies per block. ### Block Production Sequence -1. **Validator A** produces Block N on time. -2. **Validator B** is scheduled to produce Block N+1. +1. **Validator A** has produced Block N-1 on time. +2. **Validator B** produces Block N on time. +2. **Validator C** is scheduled to produce Block N+1. ### Reward Distribution -- **Validator A (Block N Producer)**: +- **Validator A (Block N-1 Producer)**: + - Receives: + - **30% of Block N Fees**. + - **Epoch Coinbase** (10 tokens). + + +- **Validator B (Block N Producer)**: - Receives: - - **75% of Block N Fees**. + - **40% of Block N Fees**. - **Epoch Coinbase** (10 tokens). -- **Validator B (Block N+1 Producer)**: +- **Validator C (Block N+1 Producer)**: - Receives: - - **25% of Block N Fees** (for validating and building upon Block N). + - **30% of Block N Fees** (for validating and building upon Block N). - Their own rewards for producing Block N+1 when applicable. ### Missed Block Scenario -- If **Validator A** fails to produce Block N: - - **Validator B** produces a **hole** instead. +- If **Validator B** fails to produce Block N: + - **Validator C** produces a **hole** instead. - **No Rewards**: - - Validator B receives **no rewards** for the hole. - - Validator A forfeits potential rewards for Block N. + - Validator C receives **no rewards** for the hole. + - Validator B forfeits potential rewards for Block N. - **Continued Operation**: - - **Validator B** continues with Block N+1. + - **Validator C** continues with Block N+1. --- @@ -579,8 +595,7 @@ Penalties are enforced to deter malicious actions or protocol violations. **Slas 1. **Producing Two Versions of a Block at a Specific Height (Double-Spending Attack)** 2. **Double Voting** -3. **Ignoring Votes** -4. **Consistently Failing to Submit Blocks on Time** +3. **Consistently Failing to Submit Blocks on Time** ### Minor Offenses 1. **Ignoring the `finalize_epoch` Fork** From 593ad3c7b2a784b43319ad27ca5c5dc68a0222bf Mon Sep 17 00:00:00 2001 From: happi Date: Mon, 20 Jan 2025 13:00:53 +0100 Subject: [PATCH 2/6] Fix rewrite leftover. --- Periodically-Syncing-HyperChains.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Periodically-Syncing-HyperChains.md b/Periodically-Syncing-HyperChains.md index d123754..8ee32f4 100644 --- a/Periodically-Syncing-HyperChains.md +++ b/Periodically-Syncing-HyperChains.md @@ -677,7 +677,7 @@ below `MINIMUM_STAKE`.) For hyperchains we calculate the "difficulty" of a normal block as the difficulty of the preceding block + 1. The difficulty of a hole is the same as the difficulty of the preceding block. -Choosing the best fork is done by choosing the block with the highest difficulty. In the case of two +Choosing the best fork is done by choosing the block with the highest difficulty. The block with the highest height is better for blocks with the same difficulty. #### Producer diagram From 387e50e1dbeb736093dca0547e8a6dfaef16296a Mon Sep 17 00:00:00 2001 From: happi Date: Mon, 20 Jan 2025 13:12:51 +0100 Subject: [PATCH 3/6] Descibe result of voting. --- Periodically-Syncing-HyperChains.md | 3 +++ 1 file changed, 3 insertions(+) diff --git a/Periodically-Syncing-HyperChains.md b/Periodically-Syncing-HyperChains.md index 8ee32f4..0f8fbe4 100644 --- a/Periodically-Syncing-HyperChains.md +++ b/Periodically-Syncing-HyperChains.md @@ -680,6 +680,9 @@ block + 1. The difficulty of a hole is the same as the difficulty of the precedi Choosing the best fork is done by choosing the block with the highest difficulty. The block with the highest height is better for blocks with the same difficulty. +When a vote for a fork gets 2/3 of the stake the dificulty of the block containing that vote will be +updated so that difficulty is set to the height. + #### Producer diagram ```mermaid From 523e77d1f98374990a5eaca931d94caeeeb93825 Mon Sep 17 00:00:00 2001 From: happi Date: Mon, 20 Jan 2025 13:28:36 +0100 Subject: [PATCH 4/6] Spelling. --- Periodically-Syncing-HyperChains.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Periodically-Syncing-HyperChains.md b/Periodically-Syncing-HyperChains.md index 0f8fbe4..f7d868e 100644 --- a/Periodically-Syncing-HyperChains.md +++ b/Periodically-Syncing-HyperChains.md @@ -680,7 +680,7 @@ block + 1. The difficulty of a hole is the same as the difficulty of the precedi Choosing the best fork is done by choosing the block with the highest difficulty. The block with the highest height is better for blocks with the same difficulty. -When a vote for a fork gets 2/3 of the stake the dificulty of the block containing that vote will be +When a vote for a fork gets 2/3 of the stake the difficulty of the block containing that vote will be updated so that difficulty is set to the height. #### Producer diagram From a42f02d4e887fd7a7413448ac79b2ac3b89dbb60 Mon Sep 17 00:00:00 2001 From: Richard Carlsson Date: Fri, 14 Feb 2025 09:50:14 +0100 Subject: [PATCH 5/6] Spelling --- staking.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/staking.md b/staking.md index 0400020..c135db4 100644 --- a/staking.md +++ b/staking.md @@ -454,7 +454,7 @@ When a validator successfully produces a block on time, the rewards are distribu - Receives **(100-(X+Y))% of the block fees** from the following block. - **Role**: - Validates the correctness of the previous block. - - Is encourage to produce the block in time so that the next validator builds on top of it. + - Is encouraged to produce the block in time so that the next validator builds on top of it. - **Incentive**: Motivates validators to produce blocks in a timely manner. From cbb4883f83815493db2d0c82ea72bb2fe2dc6606 Mon Sep 17 00:00:00 2001 From: Richard Carlsson Date: Fri, 14 Feb 2025 09:53:34 +0100 Subject: [PATCH 6/6] Spelling --- Periodically-Syncing-HyperChains.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Periodically-Syncing-HyperChains.md b/Periodically-Syncing-HyperChains.md index f7d868e..9e84cff 100644 --- a/Periodically-Syncing-HyperChains.md +++ b/Periodically-Syncing-HyperChains.md @@ -993,7 +993,7 @@ Penalties are enforced to deter malicious actions or protocol violations. Slasha - **Definition**: A validator that was chosen leader but that does not produce any valid or in time blocks during an epoch. - - **Penalty**: The validator's stake is partialy slashed down below minimum stake, + - **Penalty**: The validator's stake is partially slashed down below minimum stake, causing a temporary ban from participating in leader elections and block production. 4. **Ignoring the finalize_epoch fork**: This is a minor event just as any other incorrect block. It should probably just be ignored with no penalty.