Merge branch 'dev' into generators-workflow
This commit is contained in:
commit
318188dfd0
|
@ -1,89 +1,97 @@
|
|||
version: 2.1
|
||||
commands:
|
||||
restore_cached_venv:
|
||||
description: "Restores a cached venv"
|
||||
parameters:
|
||||
reqs_checksum:
|
||||
type: string
|
||||
default: "1234"
|
||||
venv_name:
|
||||
type: string
|
||||
default: "default-name"
|
||||
steps:
|
||||
- restore_cache:
|
||||
keys:
|
||||
- << parameters.venv_name >>-venv-<< parameters.reqs_checksum >>
|
||||
# fallback to using the latest cache if no exact match is found
|
||||
- << parameters.venv_name >>-venv-
|
||||
save_cached_venv:
|
||||
description: "Saves a venv into a cache"
|
||||
parameters:
|
||||
reqs_checksum:
|
||||
type: string
|
||||
default: "1234"
|
||||
venv_path:
|
||||
type: string
|
||||
default: "venv"
|
||||
venv_name:
|
||||
type: string
|
||||
default: "default-name"
|
||||
steps:
|
||||
- save_cache:
|
||||
key: << parameters.venv_name >>-venv-<< parameters.reqs_checksum >>
|
||||
paths: << parameters.venv_path >>
|
||||
jobs:
|
||||
build:
|
||||
checkout_specs:
|
||||
docker:
|
||||
- image: circleci/python:3.6
|
||||
working_directory: ~/repo
|
||||
|
||||
working_directory: ~/specs-repo
|
||||
steps:
|
||||
# Restore git repo at point close to target branch/revision, to speed up checkout
|
||||
- restore_cache:
|
||||
keys:
|
||||
- v1-specs-repo-{{ .Branch }}-{{ .Revision }}
|
||||
- v1-specs-repo-{{ .Branch }}-
|
||||
- v1-specs-repo-
|
||||
- checkout
|
||||
- run:
|
||||
name: Build pyspec
|
||||
command: make pyspec
|
||||
|
||||
name: Clean up git repo to reduce cache size
|
||||
command: git gc
|
||||
# Save the git checkout as a cache, to make cloning next time faster.
|
||||
- save_cache:
|
||||
key: v1-specs-repo-{{ .Branch }}-{{ .Revision }}
|
||||
paths:
|
||||
- ~/specs-repo
|
||||
install_test:
|
||||
docker:
|
||||
- image: circleci/python:3.6
|
||||
working_directory: ~/specs-repo
|
||||
steps:
|
||||
- restore_cache:
|
||||
key: v1-specs-repo-{{ .Branch }}-{{ .Revision }}
|
||||
- restore_cached_venv:
|
||||
venv_name: v1-pyspec
|
||||
reqs_checksum: '{{ checksum "test_libs/pyspec/requirements.txt" }}'
|
||||
- run:
|
||||
name: Install pyspec requirements
|
||||
command: make install_test
|
||||
- save_cached_venv:
|
||||
venv_name: v1-pyspec
|
||||
reqs_checksum: '{{ checksum "test_libs/pyspec/requirements.txt" }}'
|
||||
venv_path: ./test_libs/pyspec/venv
|
||||
test:
|
||||
docker:
|
||||
- image: circleci/python:3.6
|
||||
working_directory: ~/specs-repo
|
||||
steps:
|
||||
- restore_cache:
|
||||
key: v1-specs-repo-{{ .Branch }}-{{ .Revision }}
|
||||
- restore_cached_venv:
|
||||
venv_name: v1-pyspec
|
||||
reqs_checksum: '{{ checksum "test_libs/pyspec/requirements.txt" }}'
|
||||
- run:
|
||||
name: Run py-tests
|
||||
command: make test
|
||||
|
||||
# TODO see #928: decide on CI triggering of yaml tests building,
|
||||
# and destination of output (new yaml tests LFS-configured repository)
|
||||
#
|
||||
# - run:
|
||||
# name: Generate YAML tests
|
||||
# command: make gen_yaml_tests
|
||||
#
|
||||
# - store_artifacts:
|
||||
# path: test-reports
|
||||
# destination: test-reports
|
||||
#
|
||||
# - run:
|
||||
# name: Save YAML tests for deployment
|
||||
# command: |
|
||||
# mkdir /tmp/workspace
|
||||
# cp -r yaml_tests /tmp/workspace/
|
||||
# git log -1 >> /tmp/workspace/latest_commit_message
|
||||
# - persist_to_workspace:
|
||||
# root: /tmp/workspace
|
||||
# paths:
|
||||
# - yaml_tests
|
||||
# - latest_commit_message
|
||||
# commit:
|
||||
# docker:
|
||||
# - image: circleci/python:3.6
|
||||
# steps:
|
||||
# - attach_workspace:
|
||||
# at: /tmp/workspace
|
||||
# - add_ssh_keys:
|
||||
# fingerprints:
|
||||
# - "01:85:b6:36:96:a6:84:72:e4:9b:4e:38:ee:21:97:fa"
|
||||
# - run:
|
||||
# name: Checkout test repository
|
||||
# command: |
|
||||
# ssh-keyscan -H github.com >> ~/.ssh/known_hosts
|
||||
# git clone git@github.com:ethereum/eth2.0-tests.git
|
||||
# - run:
|
||||
# name: Commit and push generated YAML tests
|
||||
# command: |
|
||||
# cd eth2.0-tests
|
||||
# git config user.name 'eth2TestGenBot'
|
||||
# git config user.email '47188154+eth2TestGenBot@users.noreply.github.com'
|
||||
# for filename in /tmp/workspace/yaml_tests/*; do
|
||||
# rm -rf $(basename $filename)
|
||||
# cp -r $filename .
|
||||
# done
|
||||
# git add .
|
||||
# if git diff --cached --exit-code >& /dev/null; then
|
||||
# echo "No changes to commit"
|
||||
# else
|
||||
# echo -e "Update generated tests\n\nLatest commit message from eth2.0-specs:\n" > commit_message
|
||||
# cat /tmp/workspace/latest_commit_message >> commit_message
|
||||
# git commit -F commit_message
|
||||
# git push origin master
|
||||
# fi
|
||||
#workflows:
|
||||
# version: 2.1
|
||||
#
|
||||
# build_and_commit:
|
||||
# jobs:
|
||||
# - build:
|
||||
# filters:
|
||||
# tags:
|
||||
# only: /.*/
|
||||
# - commit:
|
||||
# requires:
|
||||
# - build
|
||||
# filters:
|
||||
# tags:
|
||||
# only: /.*/
|
||||
# branches:
|
||||
# ignore: /.*/
|
||||
command: make citest
|
||||
- store_test_results:
|
||||
path: test_libs/pyspec/test-reports
|
||||
workflows:
|
||||
version: 2.1
|
||||
test_spec:
|
||||
jobs:
|
||||
- checkout_specs
|
||||
- install_test:
|
||||
requires:
|
||||
- checkout_specs
|
||||
- test:
|
||||
requires:
|
||||
- install_test
|
||||
|
|
18
Makefile
18
Makefile
|
@ -16,7 +16,7 @@ PY_SPEC_PHASE_0_TARGETS = $(PY_SPEC_DIR)/eth2spec/phase0/spec.py
|
|||
PY_SPEC_ALL_TARGETS = $(PY_SPEC_PHASE_0_TARGETS)
|
||||
|
||||
|
||||
.PHONY: clean all test gen_yaml_tests pyspec phase0
|
||||
.PHONY: clean all test citest gen_yaml_tests pyspec phase0 install_test
|
||||
|
||||
all: $(PY_SPEC_ALL_TARGETS) $(YAML_TEST_DIR) $(YAML_TEST_TARGETS)
|
||||
|
||||
|
@ -27,11 +27,17 @@ clean:
|
|||
rm -rf $(PY_SPEC_ALL_TARGETS)
|
||||
|
||||
# "make gen_yaml_tests" to run generators
|
||||
gen_yaml_tests: $(YAML_TEST_TARGETS)
|
||||
gen_yaml_tests: $(PY_SPEC_ALL_TARGETS) $(YAML_TEST_TARGETS)
|
||||
|
||||
# installs the packages to run pyspec tests
|
||||
install_test:
|
||||
cd $(PY_SPEC_DIR); python3 -m venv venv; . venv/bin/activate; pip3 install -r requirements.txt;
|
||||
|
||||
# runs a limited set of tests against a minimal config
|
||||
test: $(PY_SPEC_ALL_TARGETS)
|
||||
cd $(PY_SPEC_DIR); python3 -m venv venv; . venv/bin/activate; pip3 install -r requirements.txt; python -m pytest -m minimal_config .
|
||||
cd $(PY_SPEC_DIR); . venv/bin/activate; python -m pytest -m minimal_config .
|
||||
|
||||
citest: $(PY_SPEC_ALL_TARGETS)
|
||||
cd $(PY_SPEC_DIR); mkdir -p test-reports/eth2spec; . venv/bin/activate; python -m pytest --junitxml=test-reports/eth2spec/test_results.xml -m minimal_config .
|
||||
|
||||
# "make pyspec" to create the pyspec for all phases.
|
||||
pyspec: $(PY_SPEC_ALL_TARGETS)
|
||||
|
@ -59,7 +65,7 @@ define build_yaml_tests
|
|||
echo "generator $(1) started"; \
|
||||
mkdir -p $(YAML_TEST_DIR)$(1); \
|
||||
cd $(GENERATOR_DIR)$(1); \
|
||||
if test -d venv; then python3 -m venv venv; fi; \
|
||||
if ! test -d venv; then python3 -m venv venv; fi; \
|
||||
. venv/bin/activate; \
|
||||
pip3 install -r requirements.txt; \
|
||||
python3 main.py -o $(CURRENT_DIR)/$(YAML_TEST_DIR)$(1) -c $(CURRENT_DIR)/$(CONFIGS_DIR); \
|
||||
|
@ -75,5 +81,5 @@ $(YAML_TEST_DIR)/:
|
|||
|
||||
# For any target within the tests dir, build it using the build_yaml_tests function.
|
||||
# (creation of output dir is a dependency)
|
||||
$(YAML_TEST_DIR)%: $(YAML_TEST_DIR)
|
||||
$(YAML_TEST_DIR)%: $(PY_SPEC_ALL_TARGETS) $(YAML_TEST_DIR)
|
||||
$(call build_yaml_tests,$*)
|
||||
|
|
|
@ -42,8 +42,8 @@ HIGH_BALANCE_INCREMENT: 1000000000
|
|||
# Initial values
|
||||
# ---------------------------------------------------------------
|
||||
GENESIS_FORK_VERSION: 0x00000000
|
||||
# 2**32, GENESIS_EPOCH is derived from this constant
|
||||
GENESIS_SLOT: 4294967296
|
||||
# 0, GENESIS_EPOCH is derived from this constant
|
||||
GENESIS_SLOT: 0
|
||||
GENESIS_START_SHARD: 0
|
||||
# 2**64 - 1
|
||||
FAR_FUTURE_EPOCH: 18446744073709551615
|
||||
|
@ -116,7 +116,7 @@ MAX_TRANSFERS: 16
|
|||
|
||||
# Signature domains
|
||||
# ---------------------------------------------------------------
|
||||
DOMAIN_BEACON_BLOCK: 0
|
||||
DOMAIN_BEACON_PROPOSER: 0
|
||||
DOMAIN_RANDAO: 1
|
||||
DOMAIN_ATTESTATION: 2
|
||||
DOMAIN_DEPOSIT: 3
|
||||
|
|
|
@ -42,8 +42,8 @@ HIGH_BALANCE_INCREMENT: 1000000000
|
|||
# Initial values
|
||||
# ---------------------------------------------------------------
|
||||
GENESIS_FORK_VERSION: 0x00000000
|
||||
# 2**32, GENESIS_EPOCH is derived from this constant
|
||||
GENESIS_SLOT: 4294967296
|
||||
# 0, GENESIS_EPOCH is derived from this constant
|
||||
GENESIS_SLOT: 0
|
||||
GENESIS_START_SHARD: 0
|
||||
# 2**64 - 1
|
||||
FAR_FUTURE_EPOCH: 18446744073709551615
|
||||
|
@ -116,7 +116,7 @@ MAX_TRANSFERS: 16
|
|||
|
||||
# Signature domains
|
||||
# ---------------------------------------------------------------
|
||||
DOMAIN_BEACON_BLOCK: 0
|
||||
DOMAIN_BEACON_PROPOSER: 0
|
||||
DOMAIN_RANDAO: 1
|
||||
DOMAIN_ATTESTATION: 2
|
||||
DOMAIN_DEPOSIT: 3
|
||||
|
|
|
@ -88,7 +88,7 @@ def hash_to_G2(message_hash: Bytes32, domain: uint64) -> [uint384]:
|
|||
|
||||
`modular_squareroot(x)` returns a solution `y` to `y**2 % q == x`, and `None` if none exists. If there are two solutions the one with higher imaginary component is favored; if both solutions have equal imaginary component the one with higher real component is favored (note that this is equivalent to saying that the single solution with either imaginary component > p/2 or imaginary component zero and real component > p/2 is favored).
|
||||
|
||||
The following is a sample implementation; implementers are free to implement modular square roots as they wish. Note that `x2 = -x1` is an _additive modular inverse_ so real and imaginary coefficients remain in `[0 .. q-1]`. `coerce_to_int(element: Fq) -> int` is a function that takes Fq element `element` (ie. integers `mod q`) and converts it to a regular integer.
|
||||
The following is a sample implementation; implementers are free to implement modular square roots as they wish. Note that `x2 = -x1` is an _additive modular inverse_ so real and imaginary coefficients remain in `[0 .. q-1]`. `coerce_to_int(element: Fq) -> int` is a function that takes Fq element `element` (i.e. integers `mod q`) and converts it to a regular integer.
|
||||
|
||||
```python
|
||||
Fq2_order = q ** 2 - 1
|
||||
|
|
|
@ -253,7 +253,7 @@ These configurations are updated for releases, but may be out of sync during `de
|
|||
| `MAX_ATTESTATIONS` | `2**7` (= 128) |
|
||||
| `MAX_DEPOSITS` | `2**4` (= 16) |
|
||||
| `MAX_VOLUNTARY_EXITS` | `2**4` (= 16) |
|
||||
| `MAX_TRANSFERS` | `2**4` (= 16) |
|
||||
| `MAX_TRANSFERS` | `0` |
|
||||
|
||||
### Signature domains
|
||||
|
||||
|
@ -295,7 +295,7 @@ The types are defined topologically to aid in facilitating an executable version
|
|||
'epoch': 'uint64',
|
||||
# Root of the previous crosslink
|
||||
'previous_crosslink_root': 'bytes32',
|
||||
# Shard data since the previous crosslink
|
||||
# Root of the crosslinked shard data since the previous crosslink
|
||||
'crosslink_data_root': 'bytes32',
|
||||
}
|
||||
```
|
||||
|
@ -1236,7 +1236,7 @@ def initiate_validator_exit(state: BeaconState, index: ValidatorIndex) -> None:
|
|||
|
||||
# Compute exit queue epoch
|
||||
exit_epochs = [v.exit_epoch for v in state.validator_registry if v.exit_epoch != FAR_FUTURE_EPOCH]
|
||||
exit_queue_epoch = sorted(exit_epochs + [get_delayed_activation_exit_epoch(get_current_epoch(state))])[-1]
|
||||
exit_queue_epoch = max(exit_epochs + [get_delayed_activation_exit_epoch(get_current_epoch(state))])
|
||||
exit_queue_churn = len([v for v in state.validator_registry if v.exit_epoch == exit_queue_epoch])
|
||||
if exit_queue_churn >= get_churn_limit(state):
|
||||
exit_queue_epoch += 1
|
||||
|
@ -1276,7 +1276,7 @@ The initial deployment phases of Ethereum 2.0 are implemented without consensus
|
|||
|
||||
### Deposit arguments
|
||||
|
||||
The deposit contract has a single `deposit` function which takes as argument a SimpleSerialize'd `DepositData`.
|
||||
The deposit contract has a single `deposit` function which takes as argument the `DepositData` elements.
|
||||
|
||||
### Withdrawal credentials
|
||||
|
||||
|
@ -1311,7 +1311,7 @@ For convenience, we provide the interface to the contract here:
|
|||
|
||||
* `__init__()`: initializes the contract
|
||||
* `get_deposit_root() -> bytes32`: returns the current root of the deposit tree
|
||||
* `deposit(bytes[512])`: adds a deposit instance to the deposit tree, incorporating the input argument and the value transferred in the given call. Note: the amount of value transferred *must* be within `MIN_DEPOSIT_AMOUNT` and `MAX_DEPOSIT_AMOUNT`, inclusive. Each of these constants are specified in units of Gwei.
|
||||
* `deposit(pubkey: bytes[48], withdrawal_credentials: bytes[32], signature: bytes[96])`: adds a deposit instance to the deposit tree, incorporating the input arguments and the value transferred in the given call. Note: the amount of value transferred *must* be within `MIN_DEPOSIT_AMOUNT` and `MAX_DEPOSIT_AMOUNT`, inclusive. Each of these constants are specified in units of Gwei.
|
||||
|
||||
## On genesis
|
||||
|
||||
|
@ -2013,7 +2013,7 @@ def process_deposit(state: BeaconState, deposit: Deposit) -> None:
|
|||
|
||||
# Verify the Merkle branch
|
||||
merkle_branch_is_valid = verify_merkle_branch(
|
||||
leaf=hash(serialize(deposit.data)), # 48 + 32 + 8 + 96 = 184 bytes serialization
|
||||
leaf=hash_tree_root(deposit.data),
|
||||
proof=deposit.proof,
|
||||
depth=DEPOSIT_CONTRACT_TREE_DEPTH,
|
||||
index=deposit.index,
|
||||
|
|
|
@ -102,7 +102,7 @@ def get_generalized_indices(obj: Any, path: List[int], root: int=1) -> List[int]
|
|||
|
||||
## Merkle multiproofs
|
||||
|
||||
We define a Merkle multiproof as a minimal subset of nodes in a Merkle tree needed to fully authenticate that a set of nodes actually are part of a Merkle tree with some specified root, at a particular set of generalized indices. For example, here is the Merkle multiproof for positions 0, 1, 6 in an 8-node Merkle tree (ie. generalized indices 8, 9, 14):
|
||||
We define a Merkle multiproof as a minimal subset of nodes in a Merkle tree needed to fully authenticate that a set of nodes actually are part of a Merkle tree with some specified root, at a particular set of generalized indices. For example, here is the Merkle multiproof for positions 0, 1, 6 in an 8-node Merkle tree (i.e. generalized indices 8, 9, 14):
|
||||
|
||||
```
|
||||
.
|
||||
|
|
|
@ -27,7 +27,7 @@ __NOTICE__: This document is a work-in-progress for researchers and implementers
|
|||
|
||||
### Expansions
|
||||
|
||||
We define an "expansion" of an object as an object where a field in an object that is meant to represent the `hash_tree_root` of another object is replaced by the object. Note that defining expansions is not a consensus-layer-change; it is merely a "re-interpretation" of the object. Particularly, the `hash_tree_root` of an expansion of an object is identical to that of the original object, and we can define expansions where, given a complete history, it is always possible to compute the expansion of any object in the history. The opposite of an expansion is a "summary" (eg. `BeaconBlockHeader` is a summary of `BeaconBlock`).
|
||||
We define an "expansion" of an object as an object where a field in an object that is meant to represent the `hash_tree_root` of another object is replaced by the object. Note that defining expansions is not a consensus-layer-change; it is merely a "re-interpretation" of the object. Particularly, the `hash_tree_root` of an expansion of an object is identical to that of the original object, and we can define expansions where, given a complete history, it is always possible to compute the expansion of any object in the history. The opposite of an expansion is a "summary" (e.g. `BeaconBlockHeader` is a summary of `BeaconBlock`).
|
||||
|
||||
We define two expansions:
|
||||
|
||||
|
|
|
@ -34,11 +34,11 @@ This is a **work in progress** describing typing, serialization and Merkleizatio
|
|||
|
||||
### Composite types
|
||||
|
||||
* **container**: ordered heterogenous collection of values
|
||||
* **container**: ordered heterogeneous collection of values
|
||||
* key-pair curly bracket notation `{}`, e.g. `{"foo": "uint64", "bar": "bool"}`
|
||||
* **vector**: ordered fixed-length homogeneous collection of values
|
||||
* angle bracket notation `[type, N]`, e.g. `["uint64", N]`
|
||||
* **list**: ordered variable-length homogenous collection of values
|
||||
* **list**: ordered variable-length homogeneous collection of values
|
||||
* angle bracket notation `[type]`, e.g. `["uint64"]`
|
||||
|
||||
We recursively define "variable-size" types to be lists and all types that contains a variable-size type. All other types are said to be "fixed-size".
|
||||
|
|
|
@ -13,6 +13,7 @@ type_name: string -- string, object name, formatted as in spec. E.g. "BeaconBlo
|
|||
value: dynamic -- the YAML-encoded value, of the type specified by type_name.
|
||||
serialized: bytes -- string, SSZ-serialized data, hex encoded, with prefix 0x
|
||||
root: bytes32 -- string, hash-tree-root of the value, hex encoded, with prefix 0x
|
||||
signing_root: bytes32 -- string, signing-root of the value, hex encoded, with prefix 0x. Optional, present if type contains ``signature`` field
|
||||
```
|
||||
|
||||
## Condition
|
||||
|
@ -20,4 +21,12 @@ root: bytes32 -- string, hash-tree-root of the value, hex encoded, with pre
|
|||
A test-runner can implement the following assertions:
|
||||
- Serialization: After parsing the `value`, SSZ-serialize it: the output should match `serialized`
|
||||
- Hash-tree-root: After parsing the `value`, Hash-tree-root it: the output should match `root`
|
||||
- Optionally also check signing-root, if present.
|
||||
- Deserialization: SSZ-deserialize the `serialized` value, and see if it matches the parsed `value`
|
||||
|
||||
## References
|
||||
|
||||
|
||||
**`serialized`**: [SSZ serialization](https://github.com/ethereum/eth2.0-specs/blob/dev/specs/simple-serialize.md#serialization)
|
||||
**`root`** - [hash_tree_root](https://github.com/ethereum/eth2.0-specs/blob/dev/specs/simple-serialize.md#merkleization) function
|
||||
**`signing_root`** - [signing_root](https://github.com/ethereum/eth2.0-specs/blob/dev/specs/simple-serialize.md#self-signed-containers) function
|
||||
|
|
|
@ -60,7 +60,7 @@ __NOTICE__: This document is a work-in-progress for researchers and implementers
|
|||
|
||||
## Introduction
|
||||
|
||||
This document represents the expected behavior of an "honest validator" with respect to Phase 0 of the Ethereum 2.0 protocol. This document does not distinguish between a "node" (ie. the functionality of following and reading the beacon chain) and a "validator client" (ie. the functionality of actively participating in consensus). The separation of concerns between these (potentially) two pieces of software is left as a design decision that is out of scope.
|
||||
This document represents the expected behavior of an "honest validator" with respect to Phase 0 of the Ethereum 2.0 protocol. This document does not distinguish between a "node" (i.e. the functionality of following and reading the beacon chain) and a "validator client" (i.e. the functionality of actively participating in consensus). The separation of concerns between these (potentially) two pieces of software is left as a design decision that is out of scope.
|
||||
|
||||
A validator is an entity that participates in the consensus of the Ethereum 2.0 protocol. This is an optional role for users in which they can post ETH as collateral and verify and attest to the validity of blocks to seek financial returns in exchange for building and securing the protocol. This is similar to proof of work networks in which a miner provides collateral in the form of hardware/hash-power to seek returns in exchange for building and securing the protocol.
|
||||
|
||||
|
@ -101,11 +101,10 @@ In phase 0, all incoming validator deposits originate from the Ethereum 1.0 PoW
|
|||
To submit a deposit:
|
||||
|
||||
* Pack the validator's [initialization parameters](#initialization) into `deposit_data`, a [`DepositData`](../core/0_beacon-chain.md#depositdata) SSZ object.
|
||||
* Let `proof_of_possession` be the result of `bls_sign` of the `signing_root(deposit_data)` with `domain=DOMAIN_DEPOSIT`.
|
||||
* Set `deposit_data.proof_of_possession = proof_of_possession`.
|
||||
* Let `amount` be the amount in Gwei to be deposited by the validator where `MIN_DEPOSIT_AMOUNT <= amount <= MAX_DEPOSIT_AMOUNT`.
|
||||
* Set `deposit_data.amount = amount`.
|
||||
* Send a transaction on the Ethereum 1.0 chain to `DEPOSIT_CONTRACT_ADDRESS` executing `deposit(deposit_input: bytes[512])` along with `serialize(deposit_data)` as the singular `bytes` input along with a deposit of `amount` Gwei.
|
||||
* Let `signature` be the result of `bls_sign` of the `signing_root(deposit_data)` with `domain=DOMAIN_DEPOSIT`.
|
||||
* Send a transaction on the Ethereum 1.0 chain to `DEPOSIT_CONTRACT_ADDRESS` executing `def deposit(pubkey: bytes[48], withdrawal_credentials: bytes[32], signature: bytes[96])` along with a deposit of `amount` Gwei.
|
||||
|
||||
_Note_: Deposits made for the same `pubkey` are treated as for the same validator. A singular `Validator` will be added to `state.validator_registry` with each additional deposit amount added to the validator's balance. A validator can only be activated when total deposits for the validator pubkey meet or exceed `MAX_DEPOSIT_AMOUNT`.
|
||||
|
||||
|
@ -141,7 +140,7 @@ A validator has two primary responsibilities to the beacon chain -- [proposing b
|
|||
|
||||
A validator is expected to propose a [`BeaconBlock`](../core/0_beacon-chain.md#beaconblock) at the beginning of any slot during which `get_beacon_proposer_index(state, slot)` returns the validator's `validator_index`. To propose, the validator selects the `BeaconBlock`, `parent`, that in their view of the fork choice is the head of the chain during `slot - 1`. The validator is to create, sign, and broadcast a `block` that is a child of `parent` and that executes a valid [beacon chain state transition](../core/0_beacon-chain.md#beacon-chain-state-transition-function).
|
||||
|
||||
There is one proposer per slot, so if there are N active validators any individual validator will on average be assigned to propose once per N slots (eg. at 312500 validators = 10 million ETH, that's once per ~3 weeks).
|
||||
There is one proposer per slot, so if there are N active validators any individual validator will on average be assigned to propose once per N slots (e.g. at 312500 validators = 10 million ETH, that's once per ~3 weeks).
|
||||
|
||||
#### Block header
|
||||
|
||||
|
|
|
@ -46,7 +46,7 @@ def build_deposit(state,
|
|||
|
||||
deposit_data = build_deposit_data(state, pubkey, withdrawal_cred, privkey, amount)
|
||||
|
||||
item = spec.hash(deposit_data.serialize())
|
||||
item = deposit_data.hash_tree_root()
|
||||
index = len(deposit_data_leaves)
|
||||
deposit_data_leaves.append(item)
|
||||
tree = calc_merkle_tree_from_leaves(tuple(deposit_data_leaves))
|
||||
|
@ -69,7 +69,7 @@ def build_deposit_for_index(initial_validator_count: int, index: int) -> Tuple[s
|
|||
)
|
||||
state = genesis.create_genesis_state(genesis_deposits)
|
||||
|
||||
deposit_data_leaves = [spec.hash(dep.data.serialize()) for dep in genesis_deposits]
|
||||
deposit_data_leaves = [dep.data.hash_tree_root() for dep in genesis_deposits]
|
||||
|
||||
deposit = build_deposit(
|
||||
state,
|
||||
|
|
|
@ -4,7 +4,7 @@ from typing import List
|
|||
|
||||
|
||||
def create_genesis_state(deposits: List[spec.Deposit]) -> spec.BeaconState:
|
||||
deposit_root = get_merkle_root((tuple([spec.hash(dep.data.serialize()) for dep in deposits])))
|
||||
deposit_root = get_merkle_root((tuple([(dep.data.hash_tree_root()) for dep in deposits])))
|
||||
|
||||
return spec.get_genesis_beacon_state(
|
||||
deposits,
|
||||
|
@ -32,7 +32,7 @@ def create_deposits(pubkeys: List[spec.BLSPubkey], withdrawal_cred: List[spec.By
|
|||
]
|
||||
|
||||
# Fill tree with existing deposits
|
||||
deposit_data_leaves = [spec.hash(data.serialize()) for data in deposit_data]
|
||||
deposit_data_leaves = [data.hash_tree_root() for data in deposit_data]
|
||||
tree = calc_merkle_tree_from_leaves(tuple(deposit_data_leaves))
|
||||
|
||||
return [
|
||||
|
|
|
@ -2,3 +2,5 @@
|
|||
|
||||
The purpose of this test-generator is to provide test-vectors for the most important applications of SSZ:
|
||||
the serialization and hashing of ETH 2.0 data types
|
||||
|
||||
Test-format documentation can be found [here](../../specs/test_formats/ssz_static/README.md).
|
||||
|
|
|
@ -2,7 +2,11 @@ from random import Random
|
|||
|
||||
from eth2spec.debug import random_value, encode
|
||||
from eth2spec.phase0 import spec
|
||||
from eth2spec.utils.minimal_ssz import hash_tree_root, serialize
|
||||
from eth2spec.utils.minimal_ssz import (
|
||||
hash_tree_root,
|
||||
signing_root,
|
||||
serialize,
|
||||
)
|
||||
from eth_utils import (
|
||||
to_tuple, to_dict
|
||||
)
|
||||
|
@ -21,6 +25,8 @@ def create_test_case(rng: Random, name: str, mode: random_value.RandomizationMod
|
|||
yield "value", encode.encode(value, typ)
|
||||
yield "serialized", '0x' + serialize(value).hex()
|
||||
yield "root", '0x' + hash_tree_root(value).hex()
|
||||
if hasattr(value, "signature"):
|
||||
yield "signing_root", '0x' + signing_root(value).hex()
|
||||
|
||||
|
||||
@to_tuple
|
||||
|
|
|
@ -19,6 +19,8 @@ Or, to build a single file, specify the path, e.g. `make test_libs/pyspec/eth2sp
|
|||
|
||||
## Py-tests
|
||||
|
||||
After building, you can install the dependencies for running the `pyspec` tests with `make install_test`
|
||||
|
||||
These tests are not intended for client-consumption.
|
||||
These tests are sanity tests, to verify if the spec itself is consistent.
|
||||
|
||||
|
@ -38,8 +40,9 @@ python3 -m venv venv
|
|||
. venv/bin/activate
|
||||
pip3 install -r requirements.txt
|
||||
```
|
||||
Note: make sure to run `make pyspec` from the root of the specs repository,
|
||||
Note: make sure to run `make -B pyspec` from the root of the specs repository,
|
||||
to build the parts of the pyspec module derived from the markdown specs.
|
||||
The `-B` flag may be helpful to force-overwrite the `pyspec` output after you made a change to the markdown source files.
|
||||
|
||||
Run the tests:
|
||||
```
|
||||
|
|
|
@ -79,7 +79,7 @@ def create_mock_genesis_validator_deposits(num_validators, deposit_data_leaves=N
|
|||
amount=spec.MAX_DEPOSIT_AMOUNT,
|
||||
signature=signature,
|
||||
)
|
||||
item = hash(deposit_data.serialize())
|
||||
item = deposit_data.hash_tree_root()
|
||||
deposit_data_leaves.append(item)
|
||||
tree = calc_merkle_tree_from_leaves(tuple(deposit_data_leaves))
|
||||
root = get_merkle_root((tuple(deposit_data_leaves)))
|
||||
|
@ -204,7 +204,7 @@ def build_deposit(state,
|
|||
amount):
|
||||
deposit_data = build_deposit_data(state, pubkey, privkey, amount)
|
||||
|
||||
item = hash(deposit_data.serialize())
|
||||
item = deposit_data.hash_tree_root()
|
||||
index = len(deposit_data_leaves)
|
||||
deposit_data_leaves.append(item)
|
||||
tree = calc_merkle_tree_from_leaves(tuple(deposit_data_leaves))
|
||||
|
|
|
@ -235,7 +235,7 @@ def test_deposit_in_block(state):
|
|||
privkey = privkeys[index]
|
||||
deposit_data = build_deposit_data(pre_state, pubkey, privkey, spec.MAX_DEPOSIT_AMOUNT)
|
||||
|
||||
item = hash(deposit_data.serialize())
|
||||
item = deposit_data.hash_tree_root()
|
||||
test_deposit_data_leaves.append(item)
|
||||
tree = calc_merkle_tree_from_leaves(tuple(test_deposit_data_leaves))
|
||||
root = get_merkle_root((tuple(test_deposit_data_leaves)))
|
||||
|
@ -274,7 +274,7 @@ def test_deposit_top_up(state):
|
|||
deposit_data = build_deposit_data(pre_state, pubkey, privkey, amount)
|
||||
|
||||
merkle_index = len(test_deposit_data_leaves)
|
||||
item = hash(deposit_data.serialize())
|
||||
item = deposit_data.hash_tree_root()
|
||||
test_deposit_data_leaves.append(item)
|
||||
tree = calc_merkle_tree_from_leaves(tuple(test_deposit_data_leaves))
|
||||
root = get_merkle_root((tuple(test_deposit_data_leaves)))
|
||||
|
@ -380,7 +380,10 @@ def test_voluntary_exit(state):
|
|||
return pre_state, [initiate_exit_block, exit_block], post_state
|
||||
|
||||
|
||||
def test_transfer(state):
|
||||
def test_transfer(state, config):
|
||||
# overwrite default 0 to test
|
||||
spec.MAX_TRANSFERS = 1
|
||||
|
||||
pre_state = deepcopy(state)
|
||||
current_epoch = get_current_epoch(pre_state)
|
||||
sender_index = get_active_validator_indices(pre_state, current_epoch)[-1]
|
||||
|
|
Loading…
Reference in New Issue