From 86ea004ea6273840059e14983f1b9a98839d9c93 Mon Sep 17 00:00:00 2001 From: Vitalik Buterin Date: Tue, 2 Oct 2018 19:05:30 -0400 Subject: [PATCH 1/3] Added hash chain for light clients --- specs/casper_sharding_v2.1.md | 24 ++++++++++++++++++++++-- 1 file changed, 22 insertions(+), 2 deletions(-) diff --git a/specs/casper_sharding_v2.1.md b/specs/casper_sharding_v2.1.md index af4793862..8bcc85f26 100644 --- a/specs/casper_sharding_v2.1.md +++ b/specs/casper_sharding_v2.1.md @@ -55,6 +55,8 @@ Note: the python code at https://github.com/ethereum/beacon_chain and [an ethres * **PENDING\_WITHDRAW** = 3 (status code) * **PENALIZED** = 128 (status code) * **WITHDRAWN** = 4 (status code) +* **ENTRY** = 1 (flag) +* **EXIT** = 2 (flag) ### PoW chain changes @@ -163,7 +165,9 @@ fields = { # Start of the current dynasty 'dynasty_start': 'int64', # Total deposits penalized in the given withdrawal period - 'deposits_penalized_in_period': ['int32'] + 'deposits_penalized_in_period': ['int32'], + # Hash chain of validator set changes, allows light clients to track deltas more easily + 'validator_set_delta_hash_chain': 'hash32' } ``` @@ -345,6 +349,15 @@ def get_block_hash(active_state, curblock, slot): `get_block_hash(_, _, h)` should always return the block in the chain at slot `h`, and `get_shards_and_committees_for_slot(_, h)` should not change unless the dynasty changes. +We define a function to "add a link" to the validator hash chain, used when a validator is added or removed: + +```python +def add_validator_set_change_record(crystallized_state, index, pubkey, flag): + crystallized_state.validator_set_delta_hash_chain = \ + hash(crystallized_state.validator_set_delta_hash_chain + + bytes1(flag) + bytes3(index) + bytes32(pubkey)) +``` + Finally, we abstractly define `int_sqrt(n)` for use in reward/penalty calculations as the largest integer `k` such that `k**2 <= n`. Here is one possible implementation, though clients are free to use their own including standard libraries for [integer square root](https://en.wikipedia.org/wiki/Integer_square_root) if available and meet the specification. ```python @@ -504,7 +517,12 @@ Let `committees` be the set of committees processed and `time_since_last_confirm For each `SpecialObject` `obj` in `active_state.pending_specials`: * **[coverts logouts]**: If `obj.type == 0`, interpret `data[0]` as a validator index as an `int32` and `data[1]` as a signature. If `BLSVerify(pubkey=validators[data[0]].pubkey, msg=hash("bye bye"), sig=data[1])`, and `validators[i].status == LOGGED_IN`, set `validators[i].status = PENDING_EXIT` and `validators[i].exit_slot = current_slot` -* **[covers NO\_DBL\_VOTE, NO\_SURROUND, NO\_DBL\_PROPOSE slashing conditions]:** If `obj.type == 1`, interpret `data[0]` as a list of concatenated `int32` values where each value represents an index into `validators`, `data[1]` as the data being signed and `data[2]` as an aggregate signature. Interpret `data[3:6]` similarly. Verify that both signatures are valid, that the two signatures are signing distinct data, and that they are either signing the same slot number, or that one surrounds the other (ie. `source1 < source2 < target2 < target1`). Let `inds` be the list of indices in both signatures; verify that its length is at least 1. For each validator index `v` in `inds`, set their end dynasty to equal the current dynasty + 1, and if its `status` does not equal `PENALIZED`, then (i) set its `exit_slot` to equal the current `slot`, (ii) set its `status` to `PENALIZED`, and (iii) set `crystallized_state.deposits_penalized_in_period[slot // WITHDRAWAL_PERIOD] += validators[v].balance`, extending the array if needed. +* **[covers NO\_DBL\_VOTE, NO\_SURROUND, NO\_DBL\_PROPOSE slashing conditions]:** If `obj.type == 1`, interpret `data[0]` as a list of concatenated `int32` values where each value represents an index into `validators`, `data[1]` as the data being signed and `data[2]` as an aggregate signature. Interpret `data[3:6]` similarly. Verify that both signatures are valid, that the two signatures are signing distinct data, and that they are either signing the same slot number, or that one surrounds the other (ie. `source1 < source2 < target2 < target1`). Let `inds` be the list of indices in both signatures; verify that its length is at least 1. For each validator index `v` in `inds`, set their end dynasty to equal the current dynasty + 1, and if its `status` does not equal `PENALIZED`, then: + +1. Set its `exit_slot` to equal the current `slot` +2. Set its `status` to `PENALIZED` +3. Set `crystallized_state.deposits_penalized_in_period[slot // WITHDRAWAL_PERIOD] += validators[v].balance`, extending the array if needed +4. Run `add_validator_set_change_record(crystallized_state, v, validators[v].pubkey, EXIT)` #### Finally... @@ -540,10 +558,12 @@ def change_validators(validators): if validators[i].status == PENDING_LOG_IN: validators[i].status = LOGGED_IN total_changed += DEPOSIT_SIZE + add_validator_set_change_record(crystallized_state, i, validators[i].pubkey, ENTRY) if validators[i].status == PENDING_EXIT: validators[i].status = PENDING_WITHDRAW validators[i].exit_slot = current_slot total_changed += validators[i].balance + add_validator_set_change_record(crystallized_state, i, validators[i].pubkey, EXIT) if total_changed >= max_allowable_change: break From d85cb48fef9d032fd1c1d921ab845de1e549704c Mon Sep 17 00:00:00 2001 From: Justin Date: Wed, 3 Oct 2018 10:28:15 +0100 Subject: [PATCH 2/3] Rework registration contract --- specs/casper_sharding_v2.1.md | 12 ++++++++++-- 1 file changed, 10 insertions(+), 2 deletions(-) diff --git a/specs/casper_sharding_v2.1.md b/specs/casper_sharding_v2.1.md index af4793862..86532fa3f 100644 --- a/specs/casper_sharding_v2.1.md +++ b/specs/casper_sharding_v2.1.md @@ -56,9 +56,17 @@ Note: the python code at https://github.com/ethereum/beacon_chain and [an ethres * **PENALIZED** = 128 (status code) * **WITHDRAWN** = 4 (status code) -### PoW chain changes +### PoW chain registration contract -This PoS/sharding proposal can be implemented separately from the existing PoW chain. On the PoW chain a contract is added; this contract allows you to deposit `DEPOSIT_SIZE` ETH; the `deposit` function also takes as arguments (i) `pubkey` (bytes), (ii) `withdrawal_shard_id` (int), (iii) `withdrawal_address` (address), (iv) `randao_commitment` (bytes32), (v) `bls_proof_of_possession`. The proof of possession is **not** verified on the PoW chain. +The initial deployment phases of Ethereum 2.0 are implemented without consensus changes to the PoW chain. A registration contract is added to the PoW chain to deposit ETH. This contract has a `registration` function which takes the following arguments: + +1) `pubkey` (bytes) +2) `withdrawal_shard_id` (int) +3) `withdrawal_address` (address) +4) `randao_commitment` (bytes32) +5) `bls_proof_of_possession` (bytes) + +The registration contract does minimal validation, pushing most of the registration logic to the beacon chain. In particular, the BLS proof of possession (based on the BLS12-381 curve) is not verified by the registration contract. ## Data Structures From 8210eb02339803682f603085bfdef7db3d4ae381 Mon Sep 17 00:00:00 2001 From: Justin Date: Wed, 3 Oct 2018 10:38:09 +0100 Subject: [PATCH 3/3] Start work on glossary A lot more work required. The goal is to get it to the standard of the [retired phase 1 spec](https://ethresear.ch/t/sharding-phase-1-spec-retired/1407). --- specs/casper_sharding_v2.1.md | 27 +++++++++++++-------------- 1 file changed, 13 insertions(+), 14 deletions(-) diff --git a/specs/casper_sharding_v2.1.md b/specs/casper_sharding_v2.1.md index af4793862..4c83b6ac9 100644 --- a/specs/casper_sharding_v2.1.md +++ b/specs/casper_sharding_v2.1.md @@ -19,21 +19,20 @@ Note that one can also consider a simpler "minimal sharding algorithm" where cro Note: the python code at https://github.com/ethereum/beacon_chain and [an ethresear.ch post](https://ethresear.ch/t/convenience-link-to-full-casper-chain-v2-spec/2332) do not reflect all of the latest changes. If there is a discrepancy, this document is likely to reflect the more recent changes. -### Terminology +### Glossary -* **Validator** - a participant in the Casper/sharding consensus system. You can become one by depositing 32 ETH into the Casper mechanism. -* **Active validator set** - those validators who are currently participating, and which the Casper mechanism looks to produce and attest to blocks, crosslinks and other consensus objects. -* **Committee** - a (pseudo-) randomly sampled subset of the active validator set. When a committee is referred to collectively, as in "this committee attests to X", this is assumed to mean "some subset of that committee that contains enough validators that the protocol recognizes it as representing the committee". -* **Proposer** - the validator that creates a block -* **Attester** - a validator that is part of a committee that needs to sign off on a block. -* **Beacon chain** - the central PoS chain that is the base of the sharding system. -* **Shard chain** - one of the chains on which user transactions take place and account data is stored. -* **Crosslink** - a set of signatures from a committee attesting to a block in a shard chain, which can be included into the beacon chain. Crosslinks are the main means by which the beacon chain "learns about" the updated state of shard chains. -* **Slot** - a period of `SLOT_DURATION` seconds, during which one proposer has the ability to create a block and some attesters have the ability to make attestations -* **Dynasty transition** - a change of the validator set -* **Dynasty** - the number of dynasty transitions that have happened in a given chain since genesis -* **Cycle** - a span of blocks during which all validators get exactly one chance to make an attestation (unless a dynasty transition happens inside of one) -* **Finalized**, **justified** - see Casper FFG finalization here: https://arxiv.org/abs/1710.09437 +* **Validator**—a participant in the Ethereum 2.0 consensus system with the right to produce blocks, attestations, and other consensus objects. +* **Committee**—a statistically representative validator subset, sampled pseudo-randomly. +* **Proposer**—a validator with the right to create a block at a given slot. +* **Attester**—a validator in an attestation committee with the right to attest to a block. +* **Beacon chain**—the central proof-of-state chain of Ethereum 2.0. +* **Shard**—one of the chains on which user transactions take place and contract state is stored. +* **Crosslink**—sufficient signatures from an attestation committee attesting to a given block. +* **Slot**—a period of `SLOT_DURATION` seconds, during which one proposer has the ability to create a block and some attesters have the ability to make attestations +* **Dynasty transition**—a beacon chain state transaction where the validator set may change. +* **Dynasty height**—the number of dynasty transitions that have happened in a given chain since genesis. +* **Cycle**—a span of slots during which all validators get exactly one chance to make an attestation. +* **Finalized**, **justified**—see the [Casper FFG paper](https://arxiv.org/abs/1710.09437). [TODO: flesh out definitions] ### Constants