Skip to content
New issue

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

Sign up for GitHub

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

Already on GitHub? Sign in to your account

Update with new fork resolution and reward distribution. #41

Open
wants to merge 4 commits into
base: master
Choose a base branch
from
+64 −102
Open

Update with new fork resolution and reward distribution. #41

Show file tree
Hide file tree
Changes from 3 commits
Commits
Show all changes
4 commits
Select commit Hold shift + click to select a range
5ff6872
Update with new fork resolution and reward distribution.
happi Jan 20, 2025
593ad3c
Fix rewrite leftover.
happi Jan 20, 2025
387e50e
Descibe result of voting.
happi Jan 20, 2025
523e77d
Spelling.
happi Jan 20, 2025
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
85 changes: 16 additions & 69 deletions Periodically-Syncing-HyperChains.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -675,6 +675,14 @@ 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.
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
richcarl marked this conversation as resolved.
Show resolved Hide resolved
updated so that difficulty is set to the height.

#### Producer diagram

```mermaid
Expand Down Expand Up @@ -777,7 +785,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"]


Expand All @@ -791,65 +799,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.
Expand Down Expand Up @@ -1040,18 +989,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,
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

partially with 2 L

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
Expand Down
81 changes: 48 additions & 33 deletions staking.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -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
Expand All @@ -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.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

"Is encouraged"

- **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
Expand All @@ -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.
Expand Down Expand Up @@ -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.

---

Expand All @@ -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**
Expand Down
Loading