Comments (10)
With some help from libp2p we can make validators anonymous in the libp2p network:
https://hackmd.io/Mn7pPTtVTfWrg0RRhKBpNA#
from nimbus-eth2.
One previously raised concern of the "validation API" is that it's not defined to be async. This won't be a problem for us if we can use the following alternative approach:
- Always block the incoming messages for re-transmission by simple doing
return false
. - Add them to a queue for validation.
- Once validated, gossip them normally as new messages.
This approach also gives us the opportunity to look at the pool of collected messages before deciding what should be re-transmitted. Similar prioritisation strategy is proposed for attestation aggregation here: https://notes.ethereum.org/9Ijj2RkuRiqQYB9NOfY_9Q
from nimbus-eth2.
To suggest the capabilities of what sort of filtering is implementable: https://github.com/ethereum/eth2.0-specs/blob/v0.9.2/specs/networking/p2p-interface.md#topics-and-messages requires the following filtering:
-
Probably should live in a layer closer to
libp2p
:Each gossipsub message has a maximum size of GOSSIP_MAX_SIZE. Clients MUST reject (fail validation) messages that are over this size limit. Likewise, clients MUST NOT emit or propagate messages larger than this limit.
-
Clients MUST reject (fail validation) messages containing an incorrect type, or invalid payload.
(check matchingbeacon_block
topic withBeaconBlock
message type,beacon_aggregate_and_proof
topic withAggregateAndProof
message type, etc, and reject anything not from that fixed list. -
For each topic/message type pair, there are specific verification checks, e.g.,
beacon_block - This topic is used solely for propagating new beacon blocks to all nodes on the networks. Blocks are sent in their entirety. Clients MUST validate the block proposer signature before forwarding it across the network.
The general theme is that one validates the relevant messages viaprocess_voluntary_exit()
,process_proposer_slashing()
, orprocess_attester_slashing()
as appropriate before accepting or retransmitting.
from nimbus-eth2.
Pubsub validators were added in libp2p in status-im/nim-libp2p#58. This should be available to use as a filtering mechanism now.
from nimbus-eth2.
In terms of nim-libp2p
APIs, remaining are a couple of things, validation-wise:
-
https://github.com/ethereum/eth2.0-specs/blob/v0.10.1/specs/phase0/p2p-interface.md#topics-and-messages says
Each gossipsub message has a maximum size of GOSSIP_MAX_SIZE. Clients MUST reject (fail validation) messages that are over this size limit. Likewise, clients MUST NOT emit or propagate messages larger than this limit.
but the current validation API requires specifying a specific topic, for a constraint that applies to all topics. @dryajov has said he'll add direct support for this innim-libp2p
. -
https://github.com/ethereum/eth2.0-specs/blob/v0.10.1/specs/phase0/p2p-interface.md#topics-and-messages and https://github.com/ethereum/eth2.0-specs/blob/v0.10.1/specs/phase0/p2p-interface.md#why-are-we-overriding-the-default-libp2p-pubsub-message-id discuss that:
For our current purposes, there is no need to address messages based on source peer, and it seems likely we might even override the message from to obfuscate the peer. By overriding the default message-id to use content-addressing we can filter unnecessary duplicates before hitting the application layer.
such that The message-id of a gossipsub message MUST be: message-id: base64(SHA256(message.data))
. It's not clear this information should available at all to the Ethereum 2 networking layer as such, or compliant with the libp2p
specification.
from nimbus-eth2.
The message-id of a gossipsub message MUST be: message-id: base64(SHA256(message.data)).
This is currently impossible to do in some (most?) implementations as the gossipsub RPC message isn't exposed to the application, consequently the neither the message-id
nor the from
fields are accessible. Currently, the nim-libp2p doesn't expose this functionality either.
Given that Eth2 networking spec mandates this for all clients, we should propose this changes to be included in the gossipsub spec.
from nimbus-eth2.
Other already-done aspects, in terms of what nim-beacon-chain
implements (it largely doesn't interact with these messages) from https://github.com/ethereum/eth2.0-specs/blob/v0.10.1/specs/phase0/p2p-interface.md#global-topics and which aren't necessary for attestation aggregation include:
Additional global topics are used to propagate lower frequency validator messages. Their TopicNames
are:
voluntary_exit
- This topic is used solely for propagating signed voluntary validator exits to proposers on the network. Signed voluntary exits are sent in their entirety. Clients who receive a signed voluntary exit on this topic MUST validate the conditions withinprocess_voluntary_exit
before forwarding it across the network.proposer_slashing
- This topic is used solely for propagating proposer slashings to proposers on the network. Proposer slashings are sent in their entirety. Clients who receive a proposer slashing on this topic MUST validate the conditions withinprocess_proposer_slashing
before forwarding it across the network.attester_slashing
- This topic is used solely for propagating attester slashings to proposers on the network. Attester slashings are sent in their entirety. Clients who receive an attester slashing on this topic MUST validate the conditions withinprocess_attester_slashing
before forwarding it across the network.
Also already done:
beacon_block
- This topic is used solely for propagating new signed beacon blocks to all nodes on the networks. Signed blocks are sent in their entirety. The following validations MUST pass before forwarding the signed_beacon_block on the network
The proposer signature, signed_beacon_block.signature is valid.
The block is not from a future slot (with aMAXIMUM_GOSSIP_CLOCK_DISPARITY
allowance) -- i.e. validate thatsigned_beacon_block.message.slot <= current_slot
(a client MAY queue future blocks for processing at the appropriate slot).
The necessary code already exists (all those process_*
functions already work and are tested by the EF test vectors).
from nimbus-eth2.
Items in #781 related to content-hashing in for message-ID and for max gossip message size are out of scope of this issue for March purposes, leaving only the nim-beacon-chain
internal ones.
from nimbus-eth2.
For beacon_block
(https://github.com/ethereum/eth2.0-specs/blob/v0.11.0/specs/phase0/p2p-interface.md#global-topics):
-
The block is not from a future slot (with a
MAXIMUM_GOSSIP_CLOCK_DISPARITY
allowance) -- i.e. validate thatsigned_beacon_block.message.slot <= current_slot
(a client MAY queue future blocks for processing at the appropriate slot). -
The block is from a slot greater than the latest finalized slot (with a
MAXIMUM_GOSSIP_CLOCK_DISPARITY
allowance) -- i.e. validate thatsigned_beacon_block.message.slot > compute_start_slot_at_epoch(state.finalized_checkpoint.epoch)
(a client MAY choose to validate and store such blocks for additional purposes -- e.g. slashing detection, archive nodes, etc). -
The block is the first block with valid signature received for the proposer for the slot,
signed_beacon_block.message.slot
. -
The proposer signature,
signed_beacon_block.signature
, is valid.
For attestations
(https://github.com/ethereum/eth2.0-specs/blob/v0.11.0/specs/phase0/p2p-interface.md#attestation-subnets):
-
The attestation's committee index (attestation.data.index) is for the correct subnet.
-
attestation.data.slot is within the last
ATTESTATION_PROPAGATION_SLOT_RANGE
slots (within aMAXIMUM_GOSSIP_CLOCK_DISPARITY
allowance) -- i.e.attestation.data.slot + ATTESTATION_PROPAGATION_SLOT_RANGE >= current_slot >= attestation.data.slot
(a client MAY queue future attestations for processing at the appropriate slot). -
The attestation is unaggregated -- that is, it has exactly one participating validator (
len([bit for bit in attestation.aggregation_bits if bit == 0b1]) == 1
). -
The attestation is the first valid attestation received for the participating validator for the slot, attestation.data.slot.
-
The block being voted for (attestation.data.beacon_block_root) passes validation.
-
The signature of attestation is valid.
from nimbus-eth2.
#812 implements this.
from nimbus-eth2.
Related Issues (20)
- Body of POST to validators endpoint not filtering correctly HOT 1
- With low peers (< 10), sync manager may get stuck in with workers map full of 'w'/'Q' HOT 7
- Relay the external builder signature to verifying Web3Signers
- Implement an in-house release publishing for DappNode
- `/eth/v3/validator/blocks/{slot}` not returning consensus value HOT 2
- Allow providing suggestedFeeRecipient as a file HOT 10
- REST endpoint fails to accept connections and times out HOT 17
- beacon API eventstream `blob_sidecar` topic versioned hash incorrect format HOT 1
- Nimbus falling back to doppelgänger unexpectedly HOT 2
- `/eth/v3/validator/blocks/{slot_id}` inserting default graffiti HOT 2
- Inconsistent types for reason field in logs HOT 2
- Safety Mecanism against validator running on 2 clients HOT 2
- Nimbus VC with Lighthouse BN never exits doppelganger HOT 2
- Ensure all `vendors/` dependencies run in Nim 2.0/`refc` CI
- Holesky out of sync and stuck in a validation error loop HOT 2
- [v24.2.1] VC crashes during proposals HOT 3
- Changing fee recipient with KeyManager API does not trigger mev-boost relayer update without a restart HOT 1
- Core dump when stopping
- Add experimental Yamux support HOT 3
- Provide a way to detect next proposal time HOT 9
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from nimbus-eth2.