status-im
/
eth2.0-specs
mirror of https://github.com/status-im/eth2.0-specs.git
2
0
Fork 0
Code Issues Projects Releases Wiki Activity

lint

This commit is contained in:
Danny Ryan 2019-10-23 17:29:53 +09:00
parent a9c2112571
commit 7fcb60795b
No known key found for this signature in database
GPG Key ID: 2765A792E42CE07A
3 changed files with 13 additions and 9 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

1
scripts/build_spec.py
View File

@ -28,6 +28,7 @@ from eth2spec.utils.ssz.ssz_typing import (
Bytes1, Bytes4, Bytes8, Bytes32, Bytes48, Bytes96, Bitlist, Bitvector, Bytes1, Bytes4, Bytes8, Bytes32, Bytes48, Bytes96, Bitlist, Bitvector,
) )
from eth2spec.utils.bls import ( from eth2spec.utils.bls import (
bls_aggregate_signatures,
bls_aggregate_pubkeys, bls_aggregate_pubkeys,
bls_verify, bls_verify,
bls_verify_multiple, bls_verify_multiple,

8
specs/networking/p2p-interface.md
View File

@ -116,7 +116,7 @@ This section outlines constants that are used in this spec.
| `REQ_RESP_MAX_SIZE` | `TODO` | The maximum size of uncompressed req/resp messages that clients will allow. | | `REQ_RESP_MAX_SIZE` | `TODO` | The maximum size of uncompressed req/resp messages that clients will allow. |
| `SSZ_MAX_LIST_SIZE` | `TODO` | The maximum size of SSZ-encoded variable lists. | | `SSZ_MAX_LIST_SIZE` | `TODO` | The maximum size of SSZ-encoded variable lists. |
| `GOSSIP_MAX_SIZE` | `2**20` (= 1048576, 1 MiB) | The maximum size of uncompressed gossip messages. | | `GOSSIP_MAX_SIZE` | `2**20` (= 1048576, 1 MiB) | The maximum size of uncompressed gossip messages. |
| `SHARD_SUBNET_COUNT` | `TODO` | The number of shard subnets used in the gossipsub protocol. | | `ATTESTATION_SUBNET_COUNT` | `TODO` | The number of shard subnets used in the gossipsub protocol. |
| `TTFB_TIMEOUT` | `5s` | The maximum time to wait for first byte of request response (time-to-first-byte). | | `TTFB_TIMEOUT` | `5s` | The maximum time to wait for first byte of request response (time-to-first-byte). |
| `RESP_TIMEOUT` | `10s` | The maximum time for complete response transfer. | | `RESP_TIMEOUT` | `10s` | The maximum time for complete response transfer. |
| `ATTESTATION_PROPAGATION_SLOT_RANGE` | `4` | The maximum number of slots during which an attestation can be propagated. | | `ATTESTATION_PROPAGATION_SLOT_RANGE` | `4` | The maximum number of slots during which an attestation can be propagated. |
@ -200,8 +200,8 @@ The payload is carried in the `data` field of a gossipsub message, and varies de
| Topic | Message Type | | Topic | Message Type |
|------------------------------|-------------------| |------------------------------|-------------------|
| beacon_block | BeaconBlock | | beacon_block | BeaconBlock |
| beacon_aggregate_and_proof | Attestation | | beacon_aggregate_and_proof | AggregateAndProof |
| shard{N}\_beacon_attestation | Attestation | | index{N}\_beacon_attestation | Attestation |
| voluntary_exit | VoluntaryExit | | voluntary_exit | VoluntaryExit |
| proposer_slashing | ProposerSlashing | | proposer_slashing | ProposerSlashing |
| attester_slashing | AttesterSlashing | | attester_slashing | AttesterSlashing |
@ -648,7 +648,7 @@ No security or privacy guarantees are lost as a result of choosing plaintext top
Furthermore, the Eth 2.0 topic names are shorter than their digest equivalents (assuming SHA-256 hash), so hashing topics would bloat messages unnecessarily. Furthermore, the Eth 2.0 topic names are shorter than their digest equivalents (assuming SHA-256 hash), so hashing topics would bloat messages unnecessarily.
### Why are there `SHARD_SUBNET_COUNT` subnets, and why is this not defined? ### Why are there `ATTESTATION_SUBNET_COUNT` subnets, and why is this not defined?
Depending on the number of validators, it may be more efficient to group shard subnets and might provide better stability for the gossipsub channel. The exact grouping will be dependent on more involved network tests. This constant allows for more flexibility in setting up the network topology for attestation aggregation (as aggregation should happen on each subnet). Depending on the number of validators, it may be more efficient to group shard subnets and might provide better stability for the gossipsub channel. The exact grouping will be dependent on more involved network tests. This constant allows for more flexibility in setting up the network topology for attestation aggregation (as aggregation should happen on each subnet).

13
specs/validator/0_beacon-chain-validator.md
View File

@ -78,6 +78,7 @@ All terminology, constants, functions, and protocol mechanics defined in the [Ph
| Name | Value | Unit | Duration | | Name | Value | Unit | Duration |
| - | - | :-: | :-: | | - | - | :-: | :-: |
| `ETH1_FOLLOW_DISTANCE` | `2**10` (= 1,024) | blocks | ~4 hours | | `ETH1_FOLLOW_DISTANCE` | `2**10` (= 1,024) | blocks | ~4 hours |
| `TARGET_AGGREGATORS_PER_COMMITTEE` | `2**4` (= 16) | validators | |
## Becoming a validator ## Becoming a validator
@ -361,14 +362,14 @@ Some validators are selected to locally aggregate attestations with a similar `a
A validator is selected to aggregate based upon the following A validator is selected to aggregate based upon the following
```python ```python
def slot_signature(slot: Slot, privkey: int) -> BLSSignature: def slot_signature(state: BeaconState, slot: Slot, privkey: int) -> BLSSignature:
domain = get_domain(state, DOMAIN_BEACON_AGGREGATOR, attestation.data.slot) domain = get_domain(state, DOMAIN_BEACON_ATTESTER, compute_epoch_at_slot(slot))
return bls_sign(prvkey, hash_tree_root(slot), domain) return bls_sign(privkey, hash_tree_root(slot), domain)
``` ```
```python ```python
def is_aggregator(state: BeaconState, slot: Slot, committee_index: CommitteeIndex, slot_signature: BLSSignature) -> bool: def is_aggregator(state: BeaconState, slot: Slot, index: CommitteeIndex, slot_signature: BLSSignature) -> bool:
committee = get_beacon_committee(state, slot, committee_index) committee = get_beacon_committee(state, slot, index)
modulo = max(1, len(committee) // TARGET_AGGREGATORS_PER_COMMITTEE) modulo = max(1, len(committee) // TARGET_AGGREGATORS_PER_COMMITTEE)
return bytes_to_int(hash(slot_signature)[0:8]) % modulo == 0 return bytes_to_int(hash(slot_signature)[0:8]) % modulo == 0
``` ```
@ -410,6 +411,8 @@ If the validator is selected to aggregate (`is_aggregator`), then they broadcast
Aggregate attestations are broadcast as `AggregateAndProof` objects to prove to the gossip channel that the validator has been selected as an aggregator. Aggregate attestations are broadcast as `AggregateAndProof` objects to prove to the gossip channel that the validator has been selected as an aggregator.
### `AggregateAndProof`
```python ```python
class AggregateAndProof(Container): class AggregateAndProof(Container):
index: ValidatorIndex index: ValidatorIndex