Review casper_v2.1.md #1

hwwhww · 2018-07-21T13:40:24Z

No description provided.

hwwhww · 2018-07-21T13:58:42Z

sharding/review/casper_v2.1.md

+* **MAX_VALIDATOR_COUNT** - `ETH_SUPPLY_CAP / DEPOSIT_SIZE = 4194304`
+* **EPOCH_LENGTH** - 64 blocks
+* **SLOT_DURATION** - 8 seconds
+* **MIN_COMMITTEE_SIZE** - 128


What do you think about elaborating why we use MIN_COMMITTEE_SIZE = 128 from the view of security model?

Search for "111" here: https://vitalik.ca/files/Ithaca201807_Sharding.pdf

hwwhww · 2018-07-21T14:01:53Z

sharding/review/casper_v2.1.md

+* **MIN_COMMITTEE_SIZE** - 128
+* **END_EPOCH_GRACE_PERIOD** - 8 blocks
+
+### Main chain changes


Suggestion: we can call the legacy chain the PoW main chain for differentiating its role.

hwwhww · 2018-07-21T14:07:57Z

sharding/review/casper_v2.1.md

+    # cross-links what shard in this epoch
+    'current_epoch_shuffling': ['int24'],
+    # The current epoch
+    'current_epoch': 'int64',


nitpick: put current_epoch before current_epoch_shuffling?

hwwhww · 2018-07-21T14:14:07Z

sharding/review/casper_v2.1.md

+
+### Beacon chain fork choice rule
+
+The beacon chain uses the Casper FFG fork choice rule of "favor the chain containing the highest-epoch justified checkpoint". To choose between chains that are all descended from the same justified checkpoint, the chain uses "recursive proximity to justification" to choose a checkpoint, then uses GHOST within an epoch.


nitpick: "recursive proximity to justification (RPJ)"

hwwhww · 2018-07-21T14:15:28Z

sharding/review/casper_v2.1.md

+
+We now define the state transition function. At the high level, the state transition is made up of two parts:
+
+1. The epoch transition, which happens only if `slot_count // 64 > epoch_number`, and affects the crystallized state and active state


To be consistent, slot_count -> slot_number? Or it's a different parameter?

You're right! Fixed.

hwwhww · 2018-07-21T14:16:41Z

sharding/review/casper_v2.1.md

+
+We now define the state transition function. At the high level, the state transition is made up of two parts:
+
+1. The epoch transition, which happens only if `slot_count // 64 > epoch_number`, and affects the crystallized state and active state


64 -> EPOCH_LENGTH

hwwhww · 2018-07-21T16:28:15Z

sharding/review/casper_v2.1.md

+1. It attests to some parent block in the beacon chain
+2. It attests to a block hash in a shard (a sufficient number of such attestations create a "cross-link", confirming that shard block into the main chain).
+
+Every shard (e.g. there might be 1024 shards in total) is itself a PoS chain, and the shard chains are where the transactions and accounts will be stored. The cross-links serve to "confirm" segments of the shard chains into the main chain, and are also the primary way through which the different shards will be able to talk to each other.


there might be 1024 shards in total -> there might be 1024 shards initially to imply that the shards may grow?

The number of shards is constant within the scope of the mechanism (ie. adding more would require a hard fork). So IMO better to keep the emphasis of "it's 1024, deal with it".

hwwhww · 2018-07-21T16:29:13Z

sharding/review/casper_v2.1.md

+* Verify that `height <= slot_number`
+* Use `get_cutoffs` above to get the index cutoffs for the heights and the shards.
+    * If `height_in_epoch < EPOCH_LENGTH - END_EPOCH_GRACE_PERIOD`, verify that `si = (shard_id - next_shard) % SHARD_COUNT` is a valid shard index for that height (ie. check `height_cutoffs[height_in_epoch] <= shard_cutoffs[si] < height_cutoffs[height_in_epoch + 1])`).
+    * Otherwise, verify `shard_id == 65535` and `shard_block_hash == 0`.


shard_id == 65535 implies that MAX_SHARD_COUNT is 2^16. Why not set MAX_SHARD_COUNTto 2^15, where MAX_VALIDATOR_COUNT / MIN_COMMITTEE_SIZE = 2^15?

The point is to have an "out of the way" shard ID that doesn't represent any shard.

hwwhww · 2018-07-21T16:33:14Z

sharding/review/casper_v2.1.md

+
+### Epoch transitions
+
+When the current block height (ie. the height in the active state) is 0 mod SHARD_COUNT, we execute an epoch transition, which breaks down into several parts. Note that all validator balance changes only take effect after all of these parts finish.


nitpick: formatting 0 mod SHARD_COUNT

hwwhww · 2018-07-21T16:38:08Z

sharding/review/casper_v2.1.md

@@ -246,9 +247,9 @@ def get_cutoffs(validator_count):

    # For the validators assigned to each height, split them up
    # into committees for different shards. Do not assign the
-    # last 8 heights in an epoch to any shards.
+    # last END_EPOCH_GRACE_PERIOD heights in an epoch to any shards.


END_EPOCH_GRACE_PERIOD should be defined in Constants section.

hwwhww · 2018-07-21T16:41:57Z

sharding/review/casper_v2.1.md

+}
+```
+
+Here's the crystallized state:


Better to use CrystallizedState for consistency

hwwhww · 2018-07-21T16:42:17Z

sharding/review/casper_v2.1.md

+
+The beacon chain state is split into two parts, _active state_ and _crystallized state_.
+
+Here's the active state:


Better to use ActiveState for consistency

hwwhww · 2018-07-21T16:43:54Z

sharding/review/casper_v2.1.md

+    * Otherwise, verify `shard_id == 65535` and `shard_block_hash == 0`.
+* If `height_in_epoch < EPOCH_LENGTH - 8`, let `start = shard_cutoffs[si]` and `end = shard_cutoffs[si+1]`. Otherwise, let `start = height_cutoffs[height_in_epoch]` and `end = height_cutoffs[height_in_epoch + 1]`
+* Verify that `len(attester_bitfield) == ceil_div8(end - start)`, where `ceil_div8 = (x + 7) // 8`. Verify that bits `end-start....` and higher, if present (ie. `end-start` is not a multiple of 8), are all zero
+* Take all indices `0 <= i < end-start` where the ith bit of `attester_bitfield` equals 1, take `current_epoch_shuffling[start+i]` as the indices of those validators, extract their pubkeys, and add them all together to generate the group pubkey.


Eh, don't really care 😄

hwwhww · 2018-07-21T17:03:42Z

sharding/review/casper_v2.1.md

+
+The beacon chain uses the Casper FFG fork choice rule of "favor the chain containing the highest-epoch justified checkpoint". To choose between chains that are all descended from the same justified checkpoint, the chain uses "recursive proximity to justification" to choose a checkpoint, then uses GHOST within an epoch.
+
+RPJ works as follows. First, start at the latest justified checkpoint. Then, choose the descendant checkpoint that has the most attestations supporting it. Repeat until you get to a checkpoint with no children (in this phase, only checkpoints whose epochs are completed, ie. epoch N where the timeslots for epoch N+1 have already begun, are admissible)


latest justified checkpoint (LJC)

hwwhww · 2018-07-21T17:39:53Z

sharding/review/casper_v2.1.md

+    # Randao commitment reveal
+    'randao_reveal': 'hash32',
+    # Attestation votes
+    'attestation_votes': [AttestationVote],


AttestationVote is not defined.

Fixed (changed AggregateVote to AttestationVote later)

hwwhww · 2018-07-21T18:08:02Z

sharding/review/casper_v2.1.md

+* Use `get_cutoffs` above to get the index cutoffs for the heights and the shards.
+    * If `height_in_epoch < EPOCH_LENGTH - END_EPOCH_GRACE_PERIOD`, verify that `si = (shard_id - next_shard) % SHARD_COUNT` is a valid shard index for that height (ie. check `height_cutoffs[height_in_epoch] <= shard_cutoffs[si] < height_cutoffs[height_in_epoch + 1])`).
+    * Otherwise, verify `shard_id == 65535` and `shard_block_hash == 0`.
+* If `height_in_epoch < EPOCH_LENGTH - 8`, let `start = shard_cutoffs[si]` and `end = shard_cutoffs[si+1]`. Otherwise, let `start = height_cutoffs[height_in_epoch]` and `end = height_cutoffs[height_in_epoch + 1]`


Should replace 8 with END_EPOCH_GRACE_PERIOD.

hwwhww · 2018-07-21T18:08:35Z

sharding/review/casper_v2.1.md

+
+* Take the set of `shard_block_hash` values that have been proposed for S in the attestations (call this set ROOTS)
+* Take the ROOT in ROOTS such that the total deposit size of the subset of validators that have voted for `shard_block_hash` ROOT and `shard_id` S is maximal; call this BESTROOT
+* For every validator that voted for BESTROOT, increment their balance by `online_crosslink_reward`. For everyone else who was assigned to a shard (ie. not the proposers of the last 8 blocks), decrement their balance by `offline_crosslink_penalty`


Should replace 8 with END_EPOCH_GRACE_PERIOD.

hwwhww · 2018-07-21T19:36:02Z

sharding/review/casper_v2.1.md

+For a block on the beacon chain to be processed by a node, three conditions have to be met:
+
+* The parent pointed to by the `parent_hash` has already been processed and accepted
+* The main chain block pointed to by the `main_chain_ref` has already been processed and accepted


Is there any in-protocol condition of main_chain_ref? e.g., the main chain block number should within head_main_chain_block_number - X?

hwwhww · 2018-07-27T05:28:16Z

sharding/review/casper_v2.1.md

-    # Reference to main chain block
-    'main_chain_ref': 'hash32',
+    # Attestations
+    'attestations': [AttestationRecord],


AttestationRecord can be renamed to Attestation, more concise.

hwwhww · 2018-07-27T05:33:45Z

sharding/review/casper_v2.1.md


 ```python
 fields = {
-    'height': 'int16',
+    'slot': 'int64',


In Block, the slot number is slot_number; it would be nice to use the same name for the same property.

hwwhww · 2018-07-27T05:48:41Z

sharding/review/casper_v2.1.md

 * Logic for inducting queued validators from the main chain
 * Penalties for signing or attesting to non-canonical-chain blocks (update: may not be necessary, see https://ethresear.ch/t/attestation-committee-based-full-pos-chains/2259)
 * Slashing conditions
 * Logic for withdrawing deposits to shards
 * Per-validator proofs of custody
+* Full rewards and penalties
+* Versioning and upgrades
+


Add: Full RNG process

hwwhww · 2018-07-27T07:28:24Z

sharding/review/casper_v2.1.md

+
+```python
+def get_shuffling(seed, validator_count):
+    assert validator_count <= 16777216


Why using 16777216 (2^24) while MAX_VALIDATOR_COUNT is defined as 2^22 = 4194304?

The algorithm very directly depends on the number of validators being less than 2^24 because of how it gets indices three bytes at a time.

hwwhww · 2018-07-27T07:42:33Z

sharding/review/casper_v2.1.md

+    'current_epoch': 'int64',
+    # The permutation of the validators that
+    # determines who participates in what
+    # committee and at what height


height -> slot

hwwhww · 2018-07-27T07:46:24Z

sharding/review/casper_v2.1.md

+
+Here's a depiction of what is going on with reduced parameters for simplicity of exposition:
+
+![](http://vitalik.ca/files/ShuffleAndAssign.png)


height -> slot

hwwhww · 2018-07-27T07:53:02Z

sharding/review/casper_v2.1.md

+
+Repeat for every shard S:
+
+* Take the set of `shard_block_hash` values that have been proposed for S in the attestations (call this set ROOTS)


The writing style of this paragraph is quite different from the others; IMO it's more readable if:

Repeat for every shard s:

Take the set of shard_block_hash values that have been proposed for shard s in the attestations; call this set roots

hwwhww · 2018-07-27T07:56:11Z

sharding/review/casper_v2.1.md

+Repeat for every shard S:
+
+* Take the set of `shard_block_hash` values that have been proposed for S in the attestations (call this set ROOTS)
+* Take the ROOT in ROOTS such that the total deposit size of the subset of validators that have voted for `shard_block_hash` ROOT and `shard_id` S is maximal; call this BESTROOT


Take root in roots such that the total deposit size of the subset of validators that have voted for shard_block_hash and shard s is maximal; call this best_root

hwwhww · 2018-07-27T07:56:43Z

sharding/review/casper_v2.1.md

+
+* Take the set of `shard_block_hash` values that have been proposed for S in the attestations (call this set ROOTS)
+* Take the ROOT in ROOTS such that the total deposit size of the subset of validators that have voted for `shard_block_hash` ROOT and `shard_id` S is maximal; call this BESTROOT
+* If the size of the subset that voted * 3 >= `total_deposits * 2`, and `crosslink_records[shard_id].epoch < last_finalized_epoch`, set `crosslink_records[shard_id]` to `{epoch: current_epoch, hash: BESTROOT}`


BESTROOT -> best_root

hwwhww · 2018-07-27T07:57:07Z

sharding/review/casper_v2.1.md

+* Take the set of `shard_block_hash` values that have been proposed for S in the attestations (call this set ROOTS)
+* Take the ROOT in ROOTS such that the total deposit size of the subset of validators that have voted for `shard_block_hash` ROOT and `shard_id` S is maximal; call this BESTROOT
+* If the size of the subset that voted * 3 >= `total_deposits * 2`, and `crosslink_records[shard_id].epoch < last_finalized_epoch`, set `crosslink_records[shard_id]` to `{epoch: current_epoch, hash: BESTROOT}`
+* If the crosslink was saved, for every validator that voted for BESTROOT, increment their balance by `online_crosslink_reward`. For everyone else who was assigned to a shard (ie. not the proposers of the last `END_EPOCH_GRACE_PERIOD` blocks), decrement their balance by `offline_crosslink_penalty`


best_root

Nichebiche

Ok

Nichebiche · 2024-06-12T19:37:10Z

sharding/review/casper_v2.1.md

@@ -0,0 +1,446 @@
+# Casper+Sharding chain v2.1


Ethereum community shall be blessed by Nichebiche love

Nichebiche · 2024-06-12T19:38:58Z

sharding/review/casper_v2.1.md

+* **MAX_VALIDATOR_COUNT** - `ETH_SUPPLY_CAP / DEPOSIT_SIZE = 4194304`
+* **EPOCH_LENGTH** - 64 blocks
+* **SLOT_DURATION** - 8 seconds
+* **MIN_COMMITTEE_SIZE** - 128


Nichebiche · 2024-06-12T19:40:45Z

sharding/review/casper_v2.1.md

+
+### Beacon chain fork choice rule
+
+The beacon chain uses the Casper FFG fork choice rule of "favor the chain containing the highest-epoch justified checkpoint". To choose between chains that are all descended from the same justified checkpoint, the chain uses "recursive proximity to justification" to choose a checkpoint, then uses GHOST within an epoch.


Nichebiche · 2024-06-12T19:41:26Z

sharding/review/casper_v2.1.md

+
+We now define the state transition function. At the high level, the state transition is made up of two parts:
+
+1. The epoch transition, which happens only if `slot_count // 64 > epoch_number`, and affects the crystallized state and active state


Nichebiche · 2024-06-12T19:46:48Z

sharding/review/casper_v2.1.md

+
+We now define the state transition function. At the high level, the state transition is made up of two parts:
+
+1. The epoch transition, which happens only if `slot_count // 64 > epoch_number`, and affects the crystallized state and active state


Nichebiche · 2024-06-13T02:03:38Z

sharding/review/casper_v2.1.md

@@ -246,9 +247,9 @@ def get_cutoffs(validator_count):

    # For the validators assigned to each height, split them up
    # into committees for different shards. Do not assign the
-    # last 8 heights in an epoch to any shards.
+    # last END_EPOCH_GRACE_PERIOD heights in an epoch to any shards.


Nichebiche

Awesome

Nichebiche · 2024-06-20T03:56:57Z

sharding/review/casper_v2.1.md

+    # after withdrawal
+    'withdrawal_shard': 'int16',
+    # And what address
+    'withdrawal_address': 'address',


0x9320BceD0068fdF72C278Fc5721aB776ef0Cc6B9

Create casper_v2.1.md

d84e841

hwwhww commented Jul 21, 2018

View reviewed changes

Sync with notes.ethereum.org

d5e3e71

hwwhww commented Jul 21, 2018

View reviewed changes

20180727 0723

fd11053

hwwhww commented Jul 27, 2018

View reviewed changes

hwwhww added 8 commits August 3, 2018 17:29

20180803 0606

6cd7719

20180811 0554

d6791b1

20180819 0812

5283f0a

20180827 0133

0b81acd

20180902 0702

524040a

20180904 1407

10a25f9

20180905 1127

b34748a

20180907 1816

eba19c1

Nichebiche reviewed Jun 12, 2024

View reviewed changes

Nichebiche mentioned this pull request Jun 13, 2024

What do you think about elaborating why we use MIN_COMMITTEE_SIZE = 128 from the view of security model? ethereum/sharding#119

Open

Nichebiche approved these changes Jun 13, 2024

View reviewed changes

Nichebiche mentioned this pull request Jun 13, 2024

Nichebiche equals love ethereum/staking-launchpad#698

Open

Nichebiche reviewed Jun 20, 2024

View reviewed changes


		### Beacon chain fork choice rule

		The beacon chain uses the Casper FFG fork choice rule of "favor the chain containing the highest-epoch justified checkpoint". To choose between chains that are all descended from the same justified checkpoint, the chain uses "recursive proximity to justification" to choose a checkpoint, then uses GHOST within an epoch.


		We now define the state transition function. At the high level, the state transition is made up of two parts:

		1. The epoch transition, which happens only if `slot_count // 64 > epoch_number`, and affects the crystallized state and active state


		### Epoch transitions

		When the current block height (ie. the height in the active state) is 0 mod SHARD_COUNT, we execute an epoch transition, which breaks down into several parts. Note that all validator balance changes only take effect after all of these parts finish.


		The beacon chain state is split into two parts, _active state_ and _crystallized state_.

		Here's the active state:


		The beacon chain uses the Casper FFG fork choice rule of "favor the chain containing the highest-epoch justified checkpoint". To choose between chains that are all descended from the same justified checkpoint, the chain uses "recursive proximity to justification" to choose a checkpoint, then uses GHOST within an epoch.

		RPJ works as follows. First, start at the latest justified checkpoint. Then, choose the descendant checkpoint that has the most attestations supporting it. Repeat until you get to a checkpoint with no children (in this phase, only checkpoints whose epochs are completed, ie. epoch N where the timeslots for epoch N+1 have already begun, are admissible)


		Here's a depiction of what is going on with reduced parameters for simplicity of exposition:

		![](http://vitalik.ca/files/ShuffleAndAssign.png)


		Repeat for every shard S:

		* Take the set of `shard_block_hash` values that have been proposed for S in the attestations (call this set ROOTS)

Review casper_v2.1.md #1

Are you sure you want to change the base?

Review casper_v2.1.md #1

Conversation

hwwhww commented Jul 21, 2018

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

hwwhww Jul 27, 2018 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

hwwhww Jul 27, 2018 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Nichebiche left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Nichebiche left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

hwwhww Jul 27, 2018 •

edited

Loading

hwwhww Jul 27, 2018 •

edited

Loading