From 52ca90a7eef63a602073950cc5683f1273fb76e7 Mon Sep 17 00:00:00 2001 From: Justin Date: Wed, 3 Oct 2018 08:30:42 +0100 Subject: [PATCH 1/5] Remove version number in file name Putting the version number in the file name is not future proof --- specs/{casper_sharding_v2.1.md => spec.md} | 0 1 file changed, 0 insertions(+), 0 deletions(-) rename specs/{casper_sharding_v2.1.md => spec.md} (100%) diff --git a/specs/casper_sharding_v2.1.md b/specs/spec.md similarity index 100% rename from specs/casper_sharding_v2.1.md rename to specs/spec.md From be385b4c57a336db5527c9ead0ae97b49e4a7457 Mon Sep 17 00:00:00 2001 From: Justin Date: Wed, 3 Oct 2018 10:24:31 +0100 Subject: [PATCH 2/5] Clean up header and intro --- specs/casper_sharding_v2.1.md | 20 ++++++-------------- 1 file changed, 6 insertions(+), 14 deletions(-) diff --git a/specs/casper_sharding_v2.1.md b/specs/casper_sharding_v2.1.md index af4793862..d830c36df 100644 --- a/specs/casper_sharding_v2.1.md +++ b/specs/casper_sharding_v2.1.md @@ -1,23 +1,15 @@ -# Casper+Sharding chain v2.1 +# Ethereum 2.0 spec—Casper and sharding ###### tags: `spec`, `eth2.0`, `casper`, `sharding` +###### spec version: 2.2 (October 2018) -## WORK IN PROGRESS!!!!!!! +**NOTICE**: This document is a work-in-progress for researchers and implementers. It reflects recent spec changes and takes precedence over the [Python proof-of-concept implementation](https://github.com/ethereum/beacon_chain). -This is the work-in-progress document describing the specification for the Casper+Sharding (shasper) chain, version 2.1. +### Introduction -In this protocol, there is a central PoS "beacon chain" which stores and manages the current set of active PoS validators. The only mechanism available to become a validator initially is to send a transaction on the existing PoW chain containing 32 ETH. When you do so, as soon as the beacon chain processes that block, you will be queued, and eventually inducted as an active validator until you either voluntarily deregister or you are forcibly deregistered as a penalty for misbehavior. +At the center of Ethereum 2.0 is a system chain called the "beacon chain". The beacon chain stores and manages the set of active proof-of-stake validators. In the initial deployment phases of Ethereum 2.0 the only mechanism to become a validator is to make a fixed-size one-way ETH deposit to a registration contract on the Ethereum 1.0 PoW chain. Induction as a validator happens after registration transactions are processed by the beacon chain and after a queuing process. Deregistration is either voluntary or done forcibly as a penalty for misbehavior. -The primary source of load on the beacon chain is **attestations**. An attestation has a double role: - -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 "crosslink", confirming that shard block into the beacon 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 crosslinks serve to "confirm" segments of the shard chains into the beacon chain, and are also the primary way through which the different shards will be able to talk to each other. - -Note that one can also consider a simpler "minimal sharding algorithm" where crosslinks are simply hashes of proposed blocks of data that are not themselves chained to each other in any way. - -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. +The primary source of load on the beacon chain are "attestations". Attestations simultaneously attest to a shard block and a corresponding 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. ### Terminology From cf7552ee31bb6be22a7c0d4cf50fd718e528f6b8 Mon Sep 17 00:00:00 2001 From: Justin Date: Wed, 3 Oct 2018 14:35:11 +0100 Subject: [PATCH 3/5] Rename spec.md to beacon-chain.md --- specs/{spec.md => beacon-chain.md} | 0 1 file changed, 0 insertions(+), 0 deletions(-) rename specs/{spec.md => beacon-chain.md} (100%) diff --git a/specs/spec.md b/specs/beacon-chain.md similarity index 100% rename from specs/spec.md rename to specs/beacon-chain.md From d8c681b695cc88612e87abfe3c93dbb6ed0b1a36 Mon Sep 17 00:00:00 2001 From: Danny Ryan Date: Wed, 3 Oct 2018 08:45:28 -0500 Subject: [PATCH 4/5] add 'receipts' when discussion registration txs --- specs/casper_sharding_v2.1.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/specs/casper_sharding_v2.1.md b/specs/casper_sharding_v2.1.md index d830c36df..3ac846504 100644 --- a/specs/casper_sharding_v2.1.md +++ b/specs/casper_sharding_v2.1.md @@ -7,7 +7,7 @@ ### Introduction -At the center of Ethereum 2.0 is a system chain called the "beacon chain". The beacon chain stores and manages the set of active proof-of-stake validators. In the initial deployment phases of Ethereum 2.0 the only mechanism to become a validator is to make a fixed-size one-way ETH deposit to a registration contract on the Ethereum 1.0 PoW chain. Induction as a validator happens after registration transactions are processed by the beacon chain and after a queuing process. Deregistration is either voluntary or done forcibly as a penalty for misbehavior. +At the center of Ethereum 2.0 is a system chain called the "beacon chain". The beacon chain stores and manages the set of active proof-of-stake validators. In the initial deployment phases of Ethereum 2.0 the only mechanism to become a validator is to make a fixed-size one-way ETH deposit to a registration contract on the Ethereum 1.0 PoW chain. Induction as a validator happens after registration transaction receipts are processed by the beacon chain and after a queuing process. Deregistration is either voluntary or done forcibly as a penalty for misbehavior. The primary source of load on the beacon chain are "attestations". Attestations simultaneously attest to a shard block and a corresponding 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. From 4076804d2ba55db8ab817a890275b548ffd5562f Mon Sep 17 00:00:00 2001 From: Justin Date: Wed, 3 Oct 2018 15:13:29 +0100 Subject: [PATCH 5/5] Rework Appendix A on hash functions --- specs/beacon-chain.md | 6 +----- 1 file changed, 1 insertion(+), 5 deletions(-) diff --git a/specs/beacon-chain.md b/specs/beacon-chain.md index 41e29a09f..651ab2771 100644 --- a/specs/beacon-chain.md +++ b/specs/beacon-chain.md @@ -634,12 +634,8 @@ Slashing conditions may include: # Appendix ## Appendix A - Hash function -The general hash function `hash(x)` in this specification is defined as: -`hash(x) := BLAKE2b-512(x)[0:32]`, where `BLAKE2b-512` (`blake2b512`) algorithm is defined in [RFC 7693](https://tools.ietf.org/html/rfc7693) and input `x` is bytes type. - -* `BLAKE2b-512` is the *default* `BLAKE2b` algorithm with 64-byte digest size. To get a 32-byte result, the general hash function output is defined as the leftmost `32` bytes of `BLAKE2b-512` hash output. -* The design rationale is keeping using the default algorithm and avoiding too much dependency on external hash function libraries. +We aim to have a STARK-friendly hash function `hash(x)` for the production launch of the beacon chain. While the standardisation process for a STARK-friendly hash function takes place—led by STARKware, who will produce a detailed report with recommendations—we use `BLAKE2b-512` as a placeholder. Specifically, we set `hash(x) := BLAKE2b-512(x)[0:32]` where the `BLAKE2b-512` algorithm is defined in [RFC 7693](https://tools.ietf.org/html/rfc7693) and the input `x` is of type `bytes`. ## Copyright Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/).