mirror of
https://github.com/status-im/EIPs.git
synced 2025-02-04 19:13:48 +00:00
Automatically merged updates to draft EIP(s) 1011
Hi, I'm a bot! This change was automatically merged because: - It only modifies existing draft EIP(s) - The PR was approved or written by at least one author of each modified EIP - The build is passing
This commit is contained in:
Danny Ryan
EIP Automerge Bot
parent
05cb9d1ca9
commit
1fd4fb8d28
@ -42,13 +42,14 @@ The Casper FFG contract can be layered on top of any block proposal mechanism, p
|
||||
* `HYBRID_CASPER_FORK_BLKNUM`: TBD
|
||||
* `CASPER_ADDR`: TBD
|
||||
* `CASPER_CODE`: see below
|
||||
* `CASPER_BALANCE`: 1e24 wei (1,000,000 ETH)
|
||||
* `CASPER_BALANCE`: 1.25e24 wei (1,250,000 ETH)
|
||||
* `SIGHASHER_ADDR`: TBD
|
||||
* `SIGHASHER_CODE`: see below
|
||||
* `PURITY_CHECKER_ADDR`: TBD
|
||||
* `PURITY_CHECKER_CODE`: see below
|
||||
* `NULL_SENDER`: `2**160 - 1`
|
||||
* `NEW_BLOCK_REWARD`: 6e17 wei (0.6 ETH)
|
||||
* `REWARD_STEPDOWN_BLOCK_COUNT`: 5.5e5 blocks (~3 months)
|
||||
* `NON_REVERT_MIN_DEPOSIT`: amount in wei configurable by client
|
||||
|
||||
### Casper Contract Parameters
|
||||
@ -96,9 +97,13 @@ If `block.number >= HYBRID_CASPER_FORK_BLKNUM`, then:
|
||||
* When producing and validating a block, when handling `vote` transactions to `CASPER_ADDR`:
|
||||
* Only include "valid" `vote` transactions as defined above
|
||||
* Place all `vote` transactions at the end of the block
|
||||
* Track total gas used by votes separately from total gas used by normal transactions
|
||||
* The `vote_gas_limit` is equal to the `block_gas_limit`
|
||||
* Total gas used by votes cannot exceed the `vote_gas_limit`
|
||||
* When applying `vote` transactions to `CASPER_ADDR` to vm state:
|
||||
* Set sender to `NULL_SENDER`
|
||||
* Do not count gas of `vote` toward the block gas limit
|
||||
* Count gas of `vote` toward the `vote_gas_limit`
|
||||
* Do not count gas of `vote` toward the `block_gas_limit`
|
||||
* Do not increment the nonce of `NULL_SENDER`
|
||||
* All unsuccessful `vote` transactions to `CASPER_ADDR` are invalid and must not be included in the block
|
||||
|
||||
@ -134,7 +139,21 @@ casper_state_during_epoch_in_question.total_prevdyn_deposits_scaled() > NON_REVE
|
||||
|
||||
#### Block Reward
|
||||
|
||||
If `block.number >= HYBRID_CASPER_FORK_BLKNUM`, then `block_reward = NEW_BLOCK_REWARD` and utilize the same formulas for ommer rewards but with the updated `block_reward`.
|
||||
If `block.number >= HYBRID_CASPER_FORK_BLKNUM`, then `block_reward` is defined by the following logic and utilizes the same formulas for ommer rewards but with the updated `block_reward`.
|
||||
|
||||
```python
|
||||
if block.number < HYBRID_CASPER_FORK_BLKNUM + REWARD_STEPDOWN_BLOCK_COUNT:
|
||||
block_reward = 5 * NEW_BLOCK_REWARD
|
||||
elif block.number < HYBRID_CASPER_FORK_BLKNUM + 2*REWARD_STEPDOWN_BLOCK_COUNT:
|
||||
block_reward = 4 * NEW_BLOCK_REWARD
|
||||
elif block.number < HYBRID_CASPER_FORK_BLKNUM + 3*REWARD_STEPDOWN_BLOCK_COUNT:
|
||||
block_reward = 3 * NEW_BLOCK_REWARD
|
||||
elif block.number < HYBRID_CASPER_FORK_BLKNUM + 4*REWARD_STEPDOWN_BLOCK_COUNT:
|
||||
block_reward = 2 * NEW_BLOCK_REWARD
|
||||
else:
|
||||
block_reward = NEW_BLOCK_REWARD
|
||||
```
|
||||
|
||||
|
||||
#### Validators
|
||||
|
||||
@ -144,7 +163,7 @@ See the [Validator Implementation Guide](https://github.com/ethereum/casper/blob
|
||||
#### SIGHASHER_CODE
|
||||
|
||||
The source code for `SIGHASHER_CODE` is located [here](https://github.com/ethereum/casper/blob/master/casper/contracts/sighash.se.py).
|
||||
The source is to be migrated to Vyper LLL before it's bytecode is finalized for this EIP.
|
||||
The source is to be migrated to Vyper LLL before its bytecode is finalized for this EIP.
|
||||
|
||||
The EVM init code is:
|
||||
```
|
||||
@ -159,7 +178,7 @@ TBD
|
||||
#### PURITY_CHECKER_CODE
|
||||
|
||||
The source code for `PURITY_CHECKER_CODE` is located [here](https://github.com/ethereum/research/blob/master/impurity/check_for_impurity.se).
|
||||
The source is to be migrated to Vyper LLL before it's bytecode is finalized for this EIP.
|
||||
The source is to be migrated to Vyper LLL before its bytecode is finalized for this EIP.
|
||||
|
||||
The EVM init code is:
|
||||
```
|
||||
@ -175,7 +194,7 @@ TBD
|
||||
|
||||
The source code for `CASPER_CODE` is located at
|
||||
[here](https://github.com/ethereum/casper/blob/master/casper/contracts/simple_casper.v.py).
|
||||
The contract is to be formally verified and further tested before it's bytecode is finalized for this EIP.
|
||||
The contract is to be formally verified and further tested before its bytecode is finalized for this EIP.
|
||||
|
||||
The EVM init code with the above specified params is:
|
||||
```
|
||||
@ -203,7 +222,7 @@ The suggested default value that clients should ship with is at least 2e23 wei (
|
||||
See "Fork Choice" more details.
|
||||
|
||||
##### Exclusion
|
||||
The ability to exclude a specified blockhash and all of it's descendants from a client's fork choice. A suggested implementation is `--exclude BLOCKHASHES`, where `BLOCK_HASHES` is a comma delimited list of blockhashes to exclude.
|
||||
The ability to exclude a specified blockhash and all of its descendants from a client's fork choice. A suggested implementation is `--exclude BLOCKHASHES`, where `BLOCK_HASHES` is a comma delimited list of blockhashes to exclude.
|
||||
|
||||
Note: this _can_ by design override a client's forkchoice and revert finalized blocks.
|
||||
|
||||
@ -212,6 +231,47 @@ The ability to manually join a fork specified by a blockhash. A suggested implem
|
||||
|
||||
Note: this _can_ by design override a client's forkchoice and revert finalized blocks.
|
||||
|
||||
##### Monitor Votes
|
||||
The ability to monitor incoming `vote` transactions for slashing conditions and submit proof to the casper contract for a finder's fee if found. A suggested implementation is `--monitor-votes`.
|
||||
|
||||
The setting should default to disabled.
|
||||
|
||||
The following pseudocode defines when two `vote` messages violate a slashing condition. A `vote` message is the singular argument included in a `vote` transaction.
|
||||
```python
|
||||
def decode_rlp_list(vote_msg):
|
||||
# [validator_index, target_hash, target_epoch, source_epoch, signature]
|
||||
return RLPList(vote_msg, [int, bytes, int, int, bytes])
|
||||
|
||||
def same_target_epoch(vote_msg_1, vote_msg_2):
|
||||
decoded_values_1 = decode_rlp_msg(vote_msg_1)
|
||||
target_epoch_1 = decoded_values_1[2]
|
||||
|
||||
decoded_values_2 = decode_rlp_msg(vote_msg_2)
|
||||
target_epoch_2 = decoded_values_2[2]
|
||||
|
||||
return target_epoch_1 == target_epoch_2
|
||||
|
||||
def surrounds(vote_msg_1, vote_msg_2):
|
||||
decoded_values_1 = decode_rlp_msg(vote_msg_1)
|
||||
target_epoch_1 = decoded_values_1[2]
|
||||
source_epoch_1 = decoded_values_1[3]
|
||||
|
||||
decoded_values_2 = decode_rlp_msg(vote_msg_2)
|
||||
target_epoch_2 = decoded_values_2[2]
|
||||
source_epoch_1 = decoded_values_1[3]
|
||||
|
||||
vote_1_surrounds_vote_2 = target_epoch_1 > target_epoch_2 and source_epoch_1 < source_epoch_2
|
||||
vote_2_surrounds_vote_1 = target_epoch_2 > target_epoch_1 and source_epoch_2 < source_epoch_1
|
||||
|
||||
return vote_1_surrounds_vote_2 or vote_2_surrounds_vote_1
|
||||
|
||||
def violates_slashing_condition(vote_msg_1, vote_msg_2):
|
||||
return same_target_epoch(vote_msg_1, vote_msg_2) or surrounds(vote_msg_1, vote_msg_2)
|
||||
```
|
||||
This setting is to be used for clients that wish to monitor vote transactions for slashing conditions. If a slashing condition is found, the client creates and sends a transaction to `slash` on the casper contract. The first transaction to include the slashing condition proof slashes the validator in question and sends a 4% finder's fee to the transaction sender.
|
||||
|
||||
Suggested default disabled. Block producers would be the most likely to want to enable this flag as they are likely to frontrun anyone else that submit the slashing tx to grab the reward. Because block producers are likely to front-run, others would probably leave off so they don't submit a tx that will be included, cost them gas, but be too late to get the reward
|
||||
|
||||
## Rationale
|
||||
|
||||
Naive PoS specifications and implementations have existed since early blockchain days, but most are vulnerable to serious attacks and do not hold up under crypto-economic analysis. Casper FFG solves problems such as "Nothing at Stake" and "Long Range Attacks" through requiring validators to post slashable deposits and through defining economic finality.
|
||||
@ -219,7 +279,7 @@ Naive PoS specifications and implementations have existed since early blockchain
|
||||
#### Minimize Consensus Changes
|
||||
The finality gadget is designed to minimize changes across clients. For this reason, FFG is implemented within the EVM, so that the contract byte code encapsulates most of the complexity of the fork.
|
||||
|
||||
Most other decisions were made to minimize changes across clients. For example, it would be possible to allow `CASPER_ADDR` to mint Ether each time it payed rewards (as compared to creating the contract with `CASPER_BALANCE`), but this would be more invasive and error-prone than relying on existing EVM mechanics.
|
||||
Most other decisions were made to minimize changes across clients. For example, it would be possible to allow `CASPER_ADDR` to mint Ether each time it paid rewards (as compared to creating the contract with `CASPER_BALANCE`), but this would be more invasive and error-prone than relying on existing EVM mechanics.
|
||||
|
||||
#### Casper Contract Params
|
||||
`EPOCH_LENGTH` is set to 50 blocks as a balance between time to finality and message overhead.
|
||||
@ -235,13 +295,15 @@ Most other decisions were made to minimize changes across clients. For example,
|
||||
`MIN_DEPOSIT_SIZE` is set to 1500 ETH to form a natural upper bound on the total number of validators, bounding the overhead due to `vote` messages. Using formulas found [here](https://medium.com/@VitalikButerin/parametrizing-casper-the-decentralization-finality-time-overhead-tradeoff-3f2011672735) under "From validator count to minimum staking ETH", we estimate that with 1500 ETH minimum deposit at an assumed ~10M in total deposits there will be approximately 900 validators at any given time. `vote`s are only sent after the first quarter of an epoch so 900 votes have to fit into 37 blocks or ~24 `vote`s per block. We have experimented with more dynamic models for `MIN_DEPOSIT_SIZE`, but these tend to introduce significant complexities and without data from a live network seem to be premature optimizations.
|
||||
|
||||
#### Issuance
|
||||
A fixed amount of 1M ETH was chosen as `CASPER_BALANCE` to fund the casper contract. This gives the contract enough runway to operate for approximately 2 years (assuming ~10M ETH in validator deposits). Acting similarly to the "difficulty bomb", this "funding crunch" forces the network to hardfork in the relative near future to further fund the contract. This future hardfork is an opportunity to upgrade the contract and transition to full PoS.
|
||||
A fixed amount of 1.25M ETH was chosen as `CASPER_BALANCE` to fund the casper contract. This gives the contract enough runway to operate for approximately 2 years (assuming ~10M ETH in validator deposits). Acting similarly to the "difficulty bomb", this "funding crunch" forces the network to hardfork in the relative near future to further fund the contract. This future hardfork is an opportunity to upgrade the contract and transition to full PoS.
|
||||
|
||||
The PoW block reward is reduced to 0.6 ETH/block because the security of the chain is greatly shifted from PoW difficulty to PoS finality and because rewards are now issued to both validators and miners. See [here](https://gist.github.com/djrtwo/bc864c0d0a275170183803814b207b9a) for further analysis of the effect of PoW block reward reduction in the context of Hybrid Casper FFG.
|
||||
The PoW block reward is reduced from 3.0 to 0.6 ETH/block over the course of approximately one year because the security of the chain is greatly shifted from PoW difficulty to PoS finality and because rewards are now issued to both validators and miners. Rewards are stepped down by 0.6 ETH/block every 3 months (`REWARD_STEPDOWN_BLOCK_COUNT`) to provide for a conservative transition period from full PoW to hybrid PoS/PoW. This gives validators time to become familiar with the new technology and begin logging on and also provides the network with more leeway in case of any unforseen issues. If any major issues do arise, the Ethereum network will still have substantial PoW security to rely upon while decisions are made and/or patches are deployed. See [here](https://gist.github.com/djrtwo/bc864c0d0a275170183803814b207b9a) for further analysis of the current PoW security and of the effect of PoW block reward reduction in the context of Hybrid Casper FFG.
|
||||
|
||||
In addition to block rewards, miners now receive an issuance reward for including successful `vote` transactions into the block on time. This reward is equal to 1/8th that of the reward the validator receives for a successful `vote` transaction. Under optimal FFG conditions after group validator reward adjustments are made, miners receive approximately 1/5th of the total ETH issued by the Casper contract.
|
||||
|
||||
Below is a table of deposit sizes with associated annual interest rate and approximate time until funding crunch:
|
||||
|
||||
| Deposit Size | Annual Interest | Funding Crunch |
|
||||
| Deposit Size | Annual Validator Interest | Funding Crunch |
|
||||
| -------- | -------- | -------- |
|
||||
| 2.5M ETH | 10.12% | ~4 years |
|
||||
| 10M ETH | 5.00% | ~2 years |
|
||||
@ -249,7 +311,9 @@ Below is a table of deposit sizes with associated annual interest rate and appro
|
||||
| 40M ETH | 2.48% | ~1 year |
|
||||
|
||||
#### Gas Changes
|
||||
Successful casper `vote` transactions are included at the end of the block so that they can be processed in parallel with normal block transactions and cost 0 gas for validators.
|
||||
Normal block transactions cannot affect casper `vote` validation results, but casper `vote` validation results can affect normal block transaction execution. Due to this asymmetrical relationship, `vote` transactions can be processed in parallel with normal block transactions if `vote` transactions are placed after all normal block transactions. Because `vote` transactions can be processed in parallel to normal block transactions, `vote` transactions cost 0 gas for validators, ensuring that validators can submit votes even in highly congested or high gas-price periods.
|
||||
|
||||
`vote_gas_limit` is introduced to ensure that `vote` transactions do not put an undue burden on block processing. The additional overhead from `vote` transactions is capped at the overhead of normal block transactions so that when run in parallel, neither sets of transactions exceeds the overhead defined by the `block_gas_limit`.
|
||||
|
||||
The call to `initialize_epoch` at the beginning of each epoch requires 0 gas so that this protocol state transition does not take any gas allowance away from normal transactions.
|
||||
|
||||
@ -265,7 +329,9 @@ For more details on validator account abstraction, see the [Validator Implementa
|
||||
|
||||
#### Client Settings
|
||||
##### Enable Casper Fork Choice
|
||||
Releasing client versions with the casper fork choice as initially default disabled allows for a more conservative transition to hybrid Casper FFG. Validators will begin to log on, vote, and finalize the FFG contract before the majority of the network begins explicitly relying upon the new finality mechanism. Once a significant number of validators have logged on and the finality mechanism has been tested on the live network, new client software versions that change the default to enabled will be released.
|
||||
Releasing client versions with the casper fork choice as initially default disabled allows for a more conservative transition to hybrid Casper FFG. Under normal operating conditions there are no disparities between the PoW fork choice and the hybrid Casper FFG fork choice. The two fork choice rules can only diverge if either 51% of miners or 51% of validators are faulty.
|
||||
|
||||
Validators will begin to log on, vote, and finalize the FFG contract before the majority of the network begins explicitly relying upon the new finality mechanism. Once a significant number of validators have logged on and the finality mechanism has been tested on the live network, new client software versions that change the default to enabled will be released.
|
||||
|
||||
##### NON_REVERT_MIN_DEPOSIT
|
||||
`NON_REVERT_MIN_DEPOSIT` is defined and configurable locally by each client. Clients are in charge of deciding upon the minimum deposits (security) at which they will accept the chain as finalized. In the general case, differing values in the choice of this local constant will not create any fork inconsistencies because clients with very strict finalization requirements will revert to follow the longest PoW chain.
|
||||
@ -280,6 +346,11 @@ This setting is to be used by new clients that are syncing the network for the f
|
||||
|
||||
This setting is also useful for coordinating minority forks in cases of majority collusion.
|
||||
|
||||
##### Monitor Votes
|
||||
Monitoring the network for slashing conditions is key to Casper FFG's "accountable safety" as submitting proof of nefarious activity burns a validator's deposit.
|
||||
|
||||
This setting is suggested default disabled because the block producer will almost certainly frontrun anyone else submitting a `slash` transaction. To prevent every client on the network from submitting a `slash` transaction in the event of a slashing condition, this setting should only be enabled by block producers and those clients who explicitly choose to monitor votes.
|
||||
|
||||
## Backwards Compatibility
|
||||
This EIP is not forward compatible and introduces backwards incompatibilities in the state, fork choice rule, block reward, transaction validity, and gas calculations on certain transactions. Therefore, all changes should be included in a scheduled hardfork at `HYBRID_CASPER_FORK_BLKNUM`.
|
||||
|
||||
|
||||
Loading…
x
Reference in New Issue
Block a user