From 3dbee05aa6a29392e067fe797940d3a87bbaec2b Mon Sep 17 00:00:00 2001 From: Hsiao-Wei Wang Date: Wed, 2 Jan 2019 18:11:31 +0800 Subject: [PATCH 1/4] Rename `pow_receipt_` to `deposit_` --- specs/core/0_beacon-chain.md | 53 ++++++++++++++++++------------------ 1 file changed, 26 insertions(+), 27 deletions(-) diff --git a/specs/core/0_beacon-chain.md b/specs/core/0_beacon-chain.md index beafa9372..51015e362 100644 --- a/specs/core/0_beacon-chain.md +++ b/specs/core/0_beacon-chain.md @@ -47,7 +47,7 @@ - [`CrosslinkRecord`](#crosslinkrecord) - [`ShardCommittee`](#shardcommittee) - [`ShardReassignmentRecord`](#shardreassignmentrecord) - - [`CandidatePoWReceiptRootRecord`](#candidatepowreceiptrootrecord) + - [`DepositRootVote`](#depositrootvote) - [`PendingAttestationRecord`](#pendingattestationrecord) - [`ForkData`](#forkdata) - [`ValidatorRegistryDeltaBlock`](#validatorregistrydeltablock) @@ -94,7 +94,7 @@ - [Slot](#slot) - [Proposer signature](#proposer-signature) - [RANDAO](#randao) - - [PoW receipt root](#pow-receipt-root) + - [Deposit root](#deposit-root) - [Operations](#operations) - [Proposer slashings](#proposer-slashings-1) - [Casper slashings](#casper-slashings-1) @@ -104,7 +104,7 @@ - [Miscellaneous](#miscellaneous) - [Per-epoch processing](#per-epoch-processing) - [Helpers](#helpers) - - [Receipt roots](#receipt-roots) + - [Deposit roots](#deposit-roots) - [Justification](#justification) - [Crosslinks](#crosslinks) - [Rewards and penalties](#rewards-and-penalties) @@ -113,7 +113,6 @@ - [Crosslinks](#crosslinks-1) - [Ejections](#ejections) - [Validator registry](#validator-registry) - - [Proposer reshuffling](#proposer-reshuffling) - [Final updates](#final-updates) - [State root processing](#state-root-processing) - [References](#references) @@ -196,7 +195,7 @@ Unless otherwise indicated, code appearing in `this style` is to be interpreted | `SLOT_DURATION` | `6` | seconds | 6 seconds | | `MIN_ATTESTATION_INCLUSION_DELAY` | `2**2` (= 4) | slots | 24 seconds | | `EPOCH_LENGTH` | `2**6` (= 64) | slots | 6.4 minutes | -| `POW_RECEIPT_ROOT_VOTING_PERIOD` | `2**10` (= 1,024) | slots | ~1.7 hours | +| `DEPOSIT_ROOT_VOTING_PERIOD` | `2**10` (= 1,024) | slots | ~1.7 hours | | `COLLECTIVE_PENALTY_CALCULATION_PERIOD` | `2**20` (= 1,048,576) | slots | ~73 days | | `ZERO_BALANCE_VALIDATOR_TTL` | `2**22` (= 4,194,304) | slots | ~291 days | @@ -421,7 +420,7 @@ Unless otherwise indicated, code appearing in `this style` is to be interpreted 'parent_root': 'hash32', 'state_root': 'hash32', 'randao_reveal': 'hash32', - 'candidate_pow_receipt_root': 'hash32', + 'deposit_root_vote': 'hash32', 'signature': ['uint384'], ## Body ## @@ -500,9 +499,9 @@ Unless otherwise indicated, code appearing in `this style` is to be interpreted 'latest_attestations': [PendingAttestationRecord], 'batched_block_roots': ['hash32'], - # PoW receipt root - 'processed_pow_receipt_root': 'hash32', - 'candidate_pow_receipt_roots': [CandidatePoWReceiptRootRecord], + # Deposit root + 'processed_deposit_root': 'hash32', + 'deposit_root_votes': [DepositRootVote], } ``` @@ -569,12 +568,12 @@ Unless otherwise indicated, code appearing in `this style` is to be interpreted } ``` -#### `CandidatePoWReceiptRootRecord` +#### `DepositRootVote` ```python { - # Candidate PoW receipt root - 'candidate_pow_receipt_root': 'hash32', + # Deposit root + 'deposit_root_vote': 'hash32', # Vote count 'vote_count': 'uint64', } @@ -641,7 +640,7 @@ Every deposit, of size between `MIN_DEPOSIT` and `MAX_DEPOSIT`, emits an `Eth1De When sufficiently many full deposits have been made the deposit contract emits the `ChainStart` log. The beacon chain state may then be initialized by calling the `get_initial_beacon_state` function (defined below) where: * `genesis_time` equals `time` in the `ChainStart` log -* `processed_pow_receipt_root` equals `receipt_root` in the `ChainStart` log +* `processed_deposit_root` equals `receipt_root` in the `ChainStart` log * `initial_validator_deposits` is a list of `Deposit` objects built according to the `Eth1Deposit` logs up to the deposit that triggered the `ChainStart` log, processed in the order in which they were emitted (oldest to newest) ### Vyper code @@ -712,7 +711,7 @@ For a beacon chain block, `block`, to be processed by a node, the following cond * The parent block with root `block.parent_root` has been processed and accepted. * The node has processed its `state` up to slot, `block.slot - 1`. -* The Ethereum 1.0 block pointed to by the `state.processed_pow_receipt_root` has been processed and accepted. +* The Ethereum 1.0 block pointed to by the `state.processed_deposit_root` has been processed and accepted. * The node's local clock time is greater than or equal to `state.genesis_time + block.slot * SLOT_DURATION`. If these conditions are not met, the client should delay processing the beacon block until the conditions are all satisfied. @@ -1142,7 +1141,7 @@ A valid block with slot `INITIAL_SLOT_NUMBER` (a "genesis block") has the follow parent_root=ZERO_HASH, state_root=STARTUP_STATE_ROOT, randao_reveal=ZERO_HASH, - candidate_pow_receipt_root=ZERO_HASH, + deposit_root_vote=ZERO_HASH, signature=EMPTY_SIGNATURE, body=BeaconBlockBody( proposer_slashings=[], @@ -1162,7 +1161,7 @@ A valid block with slot `INITIAL_SLOT_NUMBER` (a "genesis block") has the follow ```python def get_initial_beacon_state(initial_validator_deposits: List[Deposit], genesis_time: int, - processed_pow_receipt_root: Hash32) -> BeaconState: + processed_deposit_root: Hash32) -> BeaconState: state = BeaconState( # Misc slot=INITIAL_SLOT_NUMBER, @@ -1201,9 +1200,9 @@ def get_initial_beacon_state(initial_validator_deposits: List[Deposit], latest_attestations=[], batched_block_roots=[], - # PoW receipt root - processed_pow_receipt_root=processed_pow_receipt_root, - candidate_pow_receipt_roots=[], + # Deposit root + processed_deposit_root=processed_deposit_root, + deposit_root_votes=[], ) # handle initial deposits and activations @@ -1462,10 +1461,10 @@ Below are the processing steps that happen at every `block`. * Set `proposer.randao_commitment = block.randao_reveal`. * Set `proposer.randao_layers = 0`. -### PoW receipt root +### Deposit root -* If `block.candidate_pow_receipt_root` is `x.candidate_pow_receipt_root` for some `x` in `state.candidate_pow_receipt_roots`, set `x.vote_count += 1`. -* Otherwise, append to `state.candidate_pow_receipt_roots` a new `CandidatePoWReceiptRootRecord(candidate_pow_receipt_root=block.candidate_pow_receipt_root, vote_count=1)`. +* If `block.deposit_root_vote` is `x.deposit_root_vote` for some `x` in `state.deposit_root_votes`, set `x.vote_count += 1`. +* Otherwise, append to `state.deposit_root_votes` a new `DepositRootVote(deposit_root_vote=block.deposit_root_vote, vote_count=1)`. ### Operations @@ -1528,7 +1527,7 @@ Verify that `len(block.body.deposits) <= MAX_DEPOSITS`. For each `deposit` in `block.body.deposits`: * Let `serialized_deposit_data` be the serialized form of `deposit.deposit_data`. It should be the `DepositInput` followed by 8 bytes for `deposit_data.value` and 8 bytes for `deposit_data.timestamp`. That is, it should match `deposit_data` in the [Ethereum 1.0 deposit contract](#ethereum-10-deposit-contract) of which the hash was placed into the Merkle tree. -* Use the following procedure to verify `deposit.merkle_branch`, setting `leaf=serialized_deposit_data`, `depth=DEPOSIT_CONTRACT_TREE_DEPTH` and `root=state.processed_pow_receipt_root`: +* Use the following procedure to verify `deposit.merkle_branch`, setting `leaf=serialized_deposit_data`, `depth=DEPOSIT_CONTRACT_TREE_DEPTH` and `root=state.processed_deposit_root`: ```python def verify_merkle_branch(leaf: Hash32, branch: [Hash32], depth: int, index: int, root: Hash32) -> bool: @@ -1621,12 +1620,12 @@ For every `shard_committee` in `state.shard_committees_at_slots`: * Let `inclusion_slot(state, index) = a.slot_included` for the attestation `a` where `index` is in `get_attestation_participants(state, a.data, a.participation_bitfield)`. * Let `inclusion_distance(state, index) = a.slot_included - a.data.slot` where `a` is the above attestation. -### Receipt roots +### Deposit roots -If `state.slot % POW_RECEIPT_ROOT_VOTING_PERIOD == 0`: +If `state.slot % DEPOSIT_ROOT_VOTING_PERIOD == 0`: -* Set `state.processed_pow_receipt_root = x.receipt_root` if `x.vote_count * 2 > POW_RECEIPT_ROOT_VOTING_PERIOD` for some `x` in `state.candidate_pow_receipt_root`. -* Set `state.candidate_pow_receipt_roots = []`. +* Set `state.processed_deposit_root = deposit_root_vote.receipt_root` if `deposit_root_vote.vote_count * 2 > DEPOSIT_ROOT_VOTING_PERIOD` for some `deposit_root_vote` in `state.deposit_root_votes`. +* Set `state.deposit_root_votes = []`. ### Justification From 9a90803f5c3f1cb7a4bcc561c4518ee289ffab5a Mon Sep 17 00:00:00 2001 From: Justin Date: Wed, 2 Jan 2019 13:18:35 +0000 Subject: [PATCH 2/4] Update 0_beacon-chain.md * `processed_deposit_root` => `latest_deposit_root` * `receipt_root` => `deposit_root` * `receipt_tree` => `deposit_tree` * Emphasize that deposits are Ethereum 1.0 deposits in text in various places * `Eth1Deposit` => `Deposit` for consistency (Also happy sticking with `Eth1Deposit` and replacing `deposit_` with `eth1_deposit_` everywhere. This may be unnecessary since Ethereum 2.0 deposits can be distinguished with the `shard_` prefix, e.g. `ShardDeposit` and `shard_deposit`.) * Clarify `withdrawal_credentials`. * Clarify that multiple Ethereum 1.0 blocks can have the same deposit root. --- specs/core/0_beacon-chain.md | 59 +++++++++++++++++++----------------- 1 file changed, 32 insertions(+), 27 deletions(-) diff --git a/specs/core/0_beacon-chain.md b/specs/core/0_beacon-chain.md index 51015e362..224510e0e 100644 --- a/specs/core/0_beacon-chain.md +++ b/specs/core/0_beacon-chain.md @@ -53,7 +53,8 @@ - [`ValidatorRegistryDeltaBlock`](#validatorregistrydeltablock) - [Ethereum 1.0 deposit contract](#ethereum-10-deposit-contract) - [Deposit arguments](#deposit-arguments) - - [`Eth1Deposit` logs](#eth1deposit-logs) + - [Withdrawal credentials](#withdrawal-credentials) + - [`Deposit` logs](#Deposit-logs) - [`ChainStart` log](#chainstart-log) - [Vyper code](#vyper-code) - [Beacon chain processing](#beacon-chain-processing) @@ -126,7 +127,7 @@ This document represents the specification for Phase 0 of Ethereum 2.0 -- The Beacon Chain. -At the core of Ethereum 2.0 is a system chain called the "beacon chain". The beacon chain stores and manages the registry of [validators](#dfn-validator). In the initial deployment phases of Ethereum 2.0 the only mechanism to become a [validator](#dfn-validator) is to make a one-way ETH transaction to a deposit contract on Ethereum 1.0. Activation as a [validator](#dfn-validator) happens when deposit transaction receipts are processed by the beacon chain, the activation balance is reached, and after a queuing process. Exit is either voluntary or done forcibly as a penalty for misbehavior. +At the core of Ethereum 2.0 is a system chain called the "beacon chain". The beacon chain stores and manages the registry of [validators](#dfn-validator). In the initial deployment phases of Ethereum 2.0 the only mechanism to become a [validator](#dfn-validator) is to make a one-way ETH transaction to a deposit contract on Ethereum 1.0. Activation as a [validator](#dfn-validator) happens when Ethereum 1.0 deposit receipts are processed by the beacon chain, the activation balance is reached, and after a queuing process. Exit is either voluntary or done forcibly as a penalty for misbehavior. The primary source of load on the beacon chain is "attestations". Attestations are availability votes for a shard block, and simultaneously proof of stake votes for a beacon chain block. A sufficient number of attestations for the same shard block create a "crosslink", confirming the shard segment up to that shard block into the beacon chain. Crosslinks also serve as infrastructure for asynchronous cross-shard communication. @@ -368,7 +369,7 @@ Unless otherwise indicated, code appearing in `this style` is to be interpreted ```python { - # Deposit parameters + # Deposit input 'deposit_input': DepositInput, # Value in Gwei 'value': 'uint64', @@ -389,7 +390,7 @@ Unless otherwise indicated, code appearing in `this style` is to be interpreted 'randao_commitment': 'hash32', # Initial proof of custody commitment 'poc_commitment': 'hash32', - # a BLS signature of this ``DepositInput`` + # A BLS signature of this `DepositInput` 'proof_of_possession': ['uint384'], } ``` @@ -499,8 +500,8 @@ Unless otherwise indicated, code appearing in `this style` is to be interpreted 'latest_attestations': [PendingAttestationRecord], 'batched_block_roots': ['hash32'], - # Deposit root - 'processed_deposit_root': 'hash32', + # Ethereum 1.0 deposit root + 'latest_deposit_root': 'hash32', 'deposit_root_votes': [DepositRootVote], } ``` @@ -620,28 +621,32 @@ Unless otherwise indicated, code appearing in `this style` is to be interpreted ## Ethereum 1.0 deposit contract -The initial deployment phases of Ethereum 2.0 are implemented without consensus changes to Ethereum 1.0. A deposit contract at address `DEPOSIT_CONTRACT_ADDRESS` is added to Ethereum 1.0 for deposits of ETH to the beacon chain. Validator balances will be withdrawable to the shards when the EVM2.0 is deployed and the shards have state. +The initial deployment phases of Ethereum 2.0 are implemented without consensus changes to Ethereum 1.0. A deposit contract at address `DEPOSIT_CONTRACT_ADDRESS` is added to Ethereum 1.0 for deposits of ETH to the beacon chain. Validator balances will be withdrawable to the shards in phase 2, i.e. when the EVM2.0 is deployed and the shards have state. ### Deposit arguments -The deposit contract has a single `deposit` function which takes as argument a SimpleSerialize'd `DepositInput`. One of the `DepositInput` fields is `withdrawal_credentials` which must satisfy: +The deposit contract has a single `deposit` function which takes as argument a SimpleSerialize'd `DepositInput`. + +### Withdrawal credentials + +One of the `DepositInput` fields is `withdrawal_credentials`. It is a commitment to credentials for withdrawals to shards. The first byte of `withdrawal_credentials` is a version number. As of now the only expected format is as follows: * `withdrawal_credentials[:1] == BLS_WITHDRAWAL_PREFIX_BYTE` * `withdrawal_credentials[1:] == hash(withdrawal_pubkey)[1:]` where `withdrawal_pubkey` is a BLS pubkey -We recommend the private key corresponding to `withdrawal_pubkey` be stored in cold storage until a withdrawal is required. +The private key corresponding to `withdrawal_pubkey` will be required to initiate a withdrawal. It can be stored separately until a withdrawal is required, e.g. in cold storage. -### `Eth1Deposit` logs +### `Deposit` logs -Every deposit, of size between `MIN_DEPOSIT` and `MAX_DEPOSIT`, emits an `Eth1Deposit` log for consumption by the beacon chain. The deposit contract does little validation, pushing most of the validator onboarding logic to the beacon chain. In particular, the proof of possession (a BLS12-381 signature) is not verified by the deposit contract. +Every Ethereum 1.0 deposit, of size between `MIN_DEPOSIT` and `MAX_DEPOSIT`, emits an `Deposit` log for consumption by the beacon chain. The deposit contract does little validation, pushing most of the validator onboarding logic to the beacon chain. In particular, the proof of possession (a BLS12-381 signature) is not verified by the deposit contract. ### `ChainStart` log When sufficiently many full deposits have been made the deposit contract emits the `ChainStart` log. The beacon chain state may then be initialized by calling the `get_initial_beacon_state` function (defined below) where: * `genesis_time` equals `time` in the `ChainStart` log -* `processed_deposit_root` equals `receipt_root` in the `ChainStart` log -* `initial_validator_deposits` is a list of `Deposit` objects built according to the `Eth1Deposit` logs up to the deposit that triggered the `ChainStart` log, processed in the order in which they were emitted (oldest to newest) +* `latest_deposit_root` equals `deposit_root` in the `ChainStart` log +* `initial_validator_deposits` is a list of `Deposit` objects built according to the `Deposit` logs up to the deposit that triggered the `ChainStart` log, processed in the order in which they were emitted (oldest to newest) ### Vyper code @@ -656,10 +661,10 @@ DEPOSIT_CONTRACT_TREE_DEPTH: constant(uint256) = 32 TWO_TO_POWER_OF_TREE_DEPTH: constant(uint256) = 4294967296 # 2**32 SECONDS_PER_DAY: constant(uint256) = 86400 -Eth1Deposit: event({previous_receipt_root: bytes32, data: bytes[2064], deposit_count: uint256}) -ChainStart: event({receipt_root: bytes32, time: bytes[8]}) +Deposit: event({previous_deposit_root: bytes32, data: bytes[2064], deposit_count: uint256}) +ChainStart: event({deposit_root: bytes32, time: bytes[8]}) -receipt_tree: map(uint256, bytes32) +deposit_tree: map(uint256, bytes32) deposit_count: uint256 full_deposit_count: uint256 @@ -674,13 +679,13 @@ def deposit(deposit_input: bytes[2048]): timestamp_bytes8: bytes[8] = slice(concat("", convert(block.timestamp, bytes32)), start=24, len=8) deposit_data: bytes[2064] = concat(msg_gwei_bytes8, timestamp_bytes8, deposit_input) - log.Eth1Deposit(self.receipt_tree[1], deposit_data, self.deposit_count) + log.Deposit(self.deposit_tree[1], deposit_data, self.deposit_count) # add deposit to merkle tree - self.receipt_tree[index] = sha3(deposit_data) + self.deposit_tree[index] = sha3(deposit_data) for i in range(32): # DEPOSIT_CONTRACT_TREE_DEPTH (range of constant var not yet supported) index /= 2 - self.receipt_tree[index] = sha3(concat(self.receipt_tree[index * 2], self.receipt_tree[index * 2 + 1])) + self.deposit_tree[index] = sha3(concat(self.deposit_tree[index * 2], self.deposit_tree[index * 2 + 1])) self.deposit_count += 1 if msg.value == as_wei_value(MAX_DEPOSIT, "ether"): @@ -688,12 +693,12 @@ def deposit(deposit_input: bytes[2048]): if self.full_deposit_count == CHAIN_START_FULL_DEPOSIT_THRESHOLD: timestamp_day_boundary: uint256 = as_unitless_number(block.timestamp) - as_unitless_number(block.timestamp) % SECONDS_PER_DAY + SECONDS_PER_DAY timestamp_day_boundary_bytes8: bytes[8] = slice(concat("", convert(timestamp_day_boundary, bytes32)), start=24, len=8) - log.ChainStart(self.receipt_tree[1], timestamp_day_boundary_bytes8) + log.ChainStart(self.deposit_tree[1], timestamp_day_boundary_bytes8) @public @constant -def get_receipt_root() -> bytes32: - return self.receipt_tree[1] +def get_deposit_root() -> bytes32: + return self.deposit_tree[1] ``` @@ -711,7 +716,7 @@ For a beacon chain block, `block`, to be processed by a node, the following cond * The parent block with root `block.parent_root` has been processed and accepted. * The node has processed its `state` up to slot, `block.slot - 1`. -* The Ethereum 1.0 block pointed to by the `state.processed_deposit_root` has been processed and accepted. +* A Ethereum 1.0 block pointed to by the `state.latest_deposit_root` has been processed and accepted. * The node's local clock time is greater than or equal to `state.genesis_time + block.slot * SLOT_DURATION`. If these conditions are not met, the client should delay processing the beacon block until the conditions are all satisfied. @@ -1161,7 +1166,7 @@ A valid block with slot `INITIAL_SLOT_NUMBER` (a "genesis block") has the follow ```python def get_initial_beacon_state(initial_validator_deposits: List[Deposit], genesis_time: int, - processed_deposit_root: Hash32) -> BeaconState: + latest_deposit_root: Hash32) -> BeaconState: state = BeaconState( # Misc slot=INITIAL_SLOT_NUMBER, @@ -1201,7 +1206,7 @@ def get_initial_beacon_state(initial_validator_deposits: List[Deposit], batched_block_roots=[], # Deposit root - processed_deposit_root=processed_deposit_root, + latest_deposit_root=latest_deposit_root, deposit_root_votes=[], ) @@ -1527,7 +1532,7 @@ Verify that `len(block.body.deposits) <= MAX_DEPOSITS`. For each `deposit` in `block.body.deposits`: * Let `serialized_deposit_data` be the serialized form of `deposit.deposit_data`. It should be the `DepositInput` followed by 8 bytes for `deposit_data.value` and 8 bytes for `deposit_data.timestamp`. That is, it should match `deposit_data` in the [Ethereum 1.0 deposit contract](#ethereum-10-deposit-contract) of which the hash was placed into the Merkle tree. -* Use the following procedure to verify `deposit.merkle_branch`, setting `leaf=serialized_deposit_data`, `depth=DEPOSIT_CONTRACT_TREE_DEPTH` and `root=state.processed_deposit_root`: +* Use the following procedure to verify `deposit.merkle_branch`, setting `leaf=serialized_deposit_data`, `depth=DEPOSIT_CONTRACT_TREE_DEPTH` and `root=state.latest_deposit_root`: ```python def verify_merkle_branch(leaf: Hash32, branch: [Hash32], depth: int, index: int, root: Hash32) -> bool: @@ -1624,7 +1629,7 @@ For every `shard_committee` in `state.shard_committees_at_slots`: If `state.slot % DEPOSIT_ROOT_VOTING_PERIOD == 0`: -* Set `state.processed_deposit_root = deposit_root_vote.receipt_root` if `deposit_root_vote.vote_count * 2 > DEPOSIT_ROOT_VOTING_PERIOD` for some `deposit_root_vote` in `state.deposit_root_votes`. +* Set `state.latest_deposit_root = deposit_root_vote.deposit_root` if `deposit_root_vote.vote_count * 2 > DEPOSIT_ROOT_VOTING_PERIOD` for some `deposit_root_vote` in `state.deposit_root_votes`. * Set `state.deposit_root_votes = []`. ### Justification From 36231e698adb091767823ade0dae62d2408300c6 Mon Sep 17 00:00:00 2001 From: Danny Ryan Date: Fri, 4 Jan 2019 13:37:15 +0800 Subject: [PATCH 3/4] Apply suggestions from code review Co-Authored-By: hwwhww --- specs/core/0_beacon-chain.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/specs/core/0_beacon-chain.md b/specs/core/0_beacon-chain.md index 71a309f87..4ab3882a2 100644 --- a/specs/core/0_beacon-chain.md +++ b/specs/core/0_beacon-chain.md @@ -623,7 +623,7 @@ The private key corresponding to `withdrawal_pubkey` will be required to initiat ### `Deposit` logs -Every Ethereum 1.0 deposit, of size between `MIN_DEPOSIT` and `MAX_DEPOSIT`, emits an `Deposit` log for consumption by the beacon chain. The deposit contract does little validation, pushing most of the validator onboarding logic to the beacon chain. In particular, the proof of possession (a BLS12-381 signature) is not verified by the deposit contract. +Every Ethereum 1.0 deposit, of size between `MIN_DEPOSIT` and `MAX_DEPOSIT`, emits a `Deposit` log for consumption by the beacon chain. The deposit contract does little validation, pushing most of the validator onboarding logic to the beacon chain. In particular, the proof of possession (a BLS12-381 signature) is not verified by the deposit contract. ### `ChainStart` log @@ -701,7 +701,7 @@ For a beacon chain block, `block`, to be processed by a node, the following cond * The parent block with root `block.parent_root` has been processed and accepted. * The node has processed its `state` up to slot, `block.slot - 1`. -* A Ethereum 1.0 block pointed to by the `state.latest_deposit_root` has been processed and accepted. +* An Ethereum 1.0 block pointed to by the `state.latest_deposit_root` has been processed and accepted. * The node's local clock time is greater than or equal to `state.genesis_time + block.slot * SLOT_DURATION`. If these conditions are not met, the client should delay processing the beacon block until the conditions are all satisfied. From 61b2b6392cb81cb2b86640322d4c132c3526b2fb Mon Sep 17 00:00:00 2001 From: Hsiao-Wei Wang Date: Fri, 4 Jan 2019 15:46:06 +0800 Subject: [PATCH 4/4] bugfix and rename Use `deposit_root_vote` for `DepositRootVote` object and `deposit_root` for the deposit root hash. --- specs/core/0_beacon-chain.md | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/specs/core/0_beacon-chain.md b/specs/core/0_beacon-chain.md index 4ab3882a2..e1c9a3056 100644 --- a/specs/core/0_beacon-chain.md +++ b/specs/core/0_beacon-chain.md @@ -420,7 +420,7 @@ Unless otherwise indicated, code appearing in `this style` is to be interpreted 'parent_root': 'hash32', 'state_root': 'hash32', 'randao_reveal': 'hash32', - 'deposit_root_vote': 'hash32', + 'deposit_root': 'hash32', 'signature': ['uint384'], ## Body ## @@ -559,7 +559,7 @@ Unless otherwise indicated, code appearing in `this style` is to be interpreted ```python { # Deposit root - 'deposit_root_vote': 'hash32', + 'deposit_root': 'hash32', # Vote count 'vote_count': 'uint64', } @@ -1131,7 +1131,7 @@ A valid block with slot `INITIAL_SLOT_NUMBER` (a "genesis block") has the follow parent_root=ZERO_HASH, state_root=STARTUP_STATE_ROOT, randao_reveal=ZERO_HASH, - deposit_root_vote=ZERO_HASH, + deposit_root=ZERO_HASH, signature=EMPTY_SIGNATURE, body=BeaconBlockBody( proposer_slashings=[], @@ -1453,8 +1453,8 @@ Below are the processing steps that happen at every `block`. ### Deposit root -* If `block.deposit_root_vote` is `x.deposit_root_vote` for some `x` in `state.deposit_root_votes`, set `x.vote_count += 1`. -* Otherwise, append to `state.deposit_root_votes` a new `DepositRootVote(deposit_root_vote=block.deposit_root_vote, vote_count=1)`. +* If `block.deposit_root` is `deposit_root_vote.deposit_root` for some `deposit_root_vote` in `state.deposit_root_votes`, set `deposit_root_vote.vote_count += 1`. +* Otherwise, append to `state.deposit_root_votes` a new `DepositRootVote(deposit_root=block.deposit_root, vote_count=1)`. ### Operations