Merkle is someone's name (#5265)
This commit is contained in:
tersec
GitHub
parent
e194d7b4ab
commit
2c424cac87
|
|
@ -29,7 +29,7 @@ logScope: topics = "lcdata"
|
|||
# - Capella: ~222 KB per `SyncCommitteePeriod` (~6.1 MB per month)
|
||||
# - Deneb: ~230 KB per `SyncCommitteePeriod` (~6.3 MB per month)
|
||||
#
|
||||
# `lc_altair_current_branches` holds merkle proofs needed to
|
||||
# `lc_altair_current_branches` holds Merkle proofs needed to
|
||||
# construct `LightClientBootstrap` objects.
|
||||
# SSZ because this data does not compress well, and because this data
|
||||
# needs to be bundled together with other data to fulfill requests.
|
||||
|
|
|
|||
|
|
@ -232,11 +232,11 @@ const
|
|||
AggregationSelectionNotImplemented* =
|
||||
"Attestation and sync committee aggreggation selection are not implemented"
|
||||
MissingMerkleProofError* =
|
||||
"Required merkle proof is missing"
|
||||
"Required Merkle proof is missing"
|
||||
InvalidMerkleProofError* =
|
||||
"The given merkle proof is invalid"
|
||||
"The given Merkle proof is invalid"
|
||||
InvalidMerkleProofIndexError* =
|
||||
"The given merkle proof index is invalid"
|
||||
"The given Merkle proof index is invalid"
|
||||
FailedToObtainForkError* =
|
||||
"Failed to obtain fork information"
|
||||
InvalidTimestampValue* =
|
||||
|
|
|
|||
|
|
@ -36,7 +36,7 @@
|
|||
# * Throughout, we're affected by the overloading rules that prefer a `var`
|
||||
# overload to a non-var overload - look for `asSeq()` - when the `var`
|
||||
# overload is used, the hash tree cache is cleared, which, aside from being
|
||||
# slow itself, causes additional processing to recalculate the merkle tree.
|
||||
# slow itself, causes additional processing to recalculate the Merkle tree.
|
||||
|
||||
{.push raises: [].}
|
||||
|
||||
|
|
|
|||
|
|
@ -44,7 +44,7 @@ The related base types are:
|
|||
- + metadata (slot, blockchain state before/after, proposer)
|
||||
- BeaconBlockHeader
|
||||
- metadata (slot, blockchain state before/after, proposer)
|
||||
- merkle hash of the BeaconBlockBody
|
||||
- Merkle hash of the BeaconBlockBody
|
||||
- SignedBeaconBlock
|
||||
- BeaconBlock
|
||||
- + BLS signature
|
||||
|
|
|
|||
|
|
@ -20,7 +20,7 @@ AMD: Bulldozer, 2011\
|
|||
Flag: `-mssse3`
|
||||
Configuration: https://github.com/supranational/blst/blob/v0.3.4/build/assembly.S#L3-L6
|
||||
|
||||
SSSE3 improves SHA256 computations. SHA256 is used **recursively** to hash all consensus objects and to build a merkle tree.
|
||||
SSSE3 improves SHA256 computations. SHA256 is used **recursively** to hash all consensus objects and to build a Merkle tree.
|
||||
Thanks to caching, SHA256 computation speed is mostly relevant only when receiving new blocks and attestations from the network, but state transitions do not depend on it (unlike a naive spec implementation).
|
||||
|
||||
**SSSE3 must not be confused with SSE3 from Pentium 3 (2004) and Athlon 64 (2005)**
|
||||
|
|
|
|||
|
|
@ -30,7 +30,7 @@ The fields have the following semantics:
|
|||
5. `remote` - An URL of a remote signing server.
|
||||
6. `remotes` - A [distributed keystore](#distributed-keystores) configuration including two or more remote signing servers.
|
||||
7. `ignore_ssl_verification` - An optional boolean flag allowing the use of self-signed certificates by the signing server.
|
||||
8. `proven_block_properties` - When the `verifying-web3signer` type is used, this is a list of locations withing the SSZ block body for which the block signing requests will contain additional merkle proofs, allowing the signer to verify certain details about the signed blocks (e.g. the `fee_recipient` value).
|
||||
8. `proven_block_properties` - When the `verifying-web3signer` type is used, this is a list of locations withing the SSZ block body for which the block signing requests will contain additional Merkle proofs, allowing the signer to verify certain details about the signed blocks (e.g. the `fee_recipient` value).
|
||||
|
||||
!!! info
|
||||
The current version of the remote keystore format is `3` which adds support for the experimental [verifying web3signer setups](#verifying-web3signer).
|
||||
|
|
@ -125,7 +125,7 @@ If you are already using a threshold signing setup (e.g. based on Vouch and Dirk
|
|||
|
||||
The verifying Web3Signer is an experimental extension to the [Web3Signer protocol](https://consensys.github.io/web3signer/web3signer-eth2.html#tag/Signing/operation/ETH2_SIGN) which allows the remote signer to verify certain details of the signed blocks before creating a signature (for example, the signer may require the signed block to have a particular fee recipient value).
|
||||
|
||||
To enable this use case, the `BLOCK_V2` request type of the `/api/v1/eth2/sign/{identifier}` endpoint is extended with an additional array field named `proofs`. The array consists of objects with the properties `index`, `proof` and `value`, where `index` is an arbitrary [generalized index](https://github.com/ethereum/consensus-specs/blob/v1.4.0-beta.0/ssz/merkle-proofs.md#generalized-merkle-tree-index) of any property nested under the block body and `proof` is its corresponding merkle proof against the block body root included in the request. The `value` property is optional and it is included only when the SSZ hash of the field included in the merkle proof doesn't match its value.
|
||||
To enable this use case, the `BLOCK_V2` request type of the `/api/v1/eth2/sign/{identifier}` endpoint is extended with an additional array field named `proofs`. The array consists of objects with the properties `index`, `proof` and `value`, where `index` is an arbitrary [generalized index](https://github.com/ethereum/consensus-specs/blob/v1.4.0-beta.0/ssz/merkle-proofs.md#generalized-merkle-tree-index) of any property nested under the block body and `proof` is its corresponding Merkle proof against the block body root included in the request. The `value` property is optional and it is included only when the SSZ hash of the field included in the Merkle proof doesn't match its value.
|
||||
|
||||
Since the generalized index of a particular field may change in a hard-fork, in the remote keystore format the proven fields are usually specified by their name:
|
||||
|
||||
|
|
@ -145,4 +145,4 @@ Since the generalized index of a particular field may change in a hard-fork, in
|
|||
```
|
||||
|
||||
Nimbus automatically computes the generalized index depending on the currently active fork.
|
||||
The remote signer is expected to verify the incoming merkle proof through the standardized [is_valid_merkle_branch](https://github.com/ethereum/consensus-specs/blob/v1.4.0-alpha.3/specs/phase0/beacon-chain.md#is_valid_merkle_branch) function by utilizing a similar automatic mapping mechanism for the generalized index.
|
||||
The remote signer is expected to verify the incoming Merkle proof through the standardized [is_valid_merkle_branch](https://github.com/ethereum/consensus-specs/blob/v1.4.0-alpha.3/specs/phase0/beacon-chain.md#is_valid_merkle_branch) function by utilizing a similar automatic mapping mechanism for the generalized index.
|
||||
|
|
|
|||
|
|
@ -1094,7 +1094,7 @@ block:
|
|||
sres1.isOk()
|
||||
sres2.isOk()
|
||||
sres3.isOk()
|
||||
# Remote requests with proper merkle proof of proper FeeRecipent field
|
||||
# Remote requests with proper Merkle proof of proper FeeRecipent field
|
||||
rres1.isOk()
|
||||
rres2.isOk()
|
||||
rres3.isOk()
|
||||
|
|
@ -1183,7 +1183,7 @@ block:
|
|||
sres1.isOk()
|
||||
sres2.isOk()
|
||||
sres3.isOk()
|
||||
# Remote requests with proper merkle proof of proper FeeRecipent field
|
||||
# Remote requests with proper Merkle proof of proper FeeRecipent field
|
||||
rres1.isOk()
|
||||
rres2.isOk()
|
||||
rres3.isOk()
|
||||
|
|
@ -1272,7 +1272,7 @@ block:
|
|||
sres1.isOk()
|
||||
sres2.isOk()
|
||||
sres3.isOk()
|
||||
# Remote requests with proper merkle proof of proper FeeRecipent field
|
||||
# Remote requests with proper Merkle proof of proper FeeRecipent field
|
||||
rres1.isOk()
|
||||
rres2.isOk()
|
||||
rres3.isOk()
|
||||
|
|
|
|||
Loading…
Reference in New Issue