EPF - Sixth Update
In my last update I described the code involved so far in the CL P2P setup, but I also talked briefly about the necessary next steps for the implementation, which were the main points that took place for these last two weeks.
Ethereum Network
As specified in the consensus specs, the Ethereum Node Record (ENR) for an Ethereum consensus client must carry a generic eth2
key with an 16-byte value of the node's current fork digest, next fork version, and next fork epoch to ensure connections are made with peers on the intended Ethereum network.
This is how the struct looks in rust:
And the constructor for the default fork id:
We don't plan a future fork so we can take these values:
next_fork_version
: Remains the same as the current fork.
next_fork_epoch
: Max possible epoch.
And the default config values for the Bellatrix fork are:
I took these values from the Eth2 Book , these are valid for the current main Ethereum network.
Now let’s take a look at how the fork_digest
is calculated:
The key part in these structs are the helpful macros provided by the libraries I’ll add below, they allow us to encode and serialize the data in the specified way.
Now using this in the ENR creation:
Now the ENR created will have the eth2 key with the formatted ForkId.
I started modifying the gossipsub behaviour creation to include the transform:
Then created a simple struct with a constructor:
Implemented the gossipsub::DataTransform
trait for this struct:
inbound_transform
: Takes a RawGossipsubMessage
received and converts it to a GossipsubMessage
outbound_transform
: Takes the data to be published and transforms it. The transformed data will then be used to create a crate::RawGossipsubMessage
to be sent to peers.
And finally update the behavior gossipsub type:
Current Challenges
I added the necessary changes I mentioned in the last update, but of course there are still some things to solve. Currently I can connect to peers and receive messages, but I keet being disconnected.
Local peer id: 16Uiu2HAkySRycoEf4hjCHyHqEU3J54RswvSFkmmAx4mtsdHzmPhH
Swarm: NewListenAddr { listener_id: ListenerId(8721776756759638073), address: "/ip4/127.0.0.1/tcp/9000" }
Swarm: NewListenAddr { listener_id: ListenerId(8721776756759638073), address: "/ip4/10.182.221.108/tcp/9000" }
Swarm: ConnectionEstablished { peer_id: PeerId("16Uiu2HAmVEWyvezosFuFbnpTt7RWfQBGHUWAx76GhdV6R66hak1o"), endpoint: Dialer { address: "/ip4/127.0.0.1/tcp/9002", role_override: Dialer }, num_established: 1, concurrent_dial_errors: Some([]) }
Swarm: ConnectionEstablished { peer_id: PeerId("16Uiu2HAmMJ5wq7Uih3RQ2PzisBCFcBuYg5Qy15BYMh8dQnBVcvVr"), endpoint: Dialer { address: "/ip4/127.0.0.1/tcp/9003", role_override: Dialer }, num_established: 1, concurrent_dial_errors: Some([]) }
Swarm: ConnectionEstablished { peer_id: PeerId("16Uiu2HAkxXY47H2ecnysMRHPzu4Kc2S7AuE8DjhgKNShNUME2382"), endpoint: Dialer { address: "/ip4/127.0.0.1/tcp/9004", role_override: Dialer }, num_established: 1, concurrent_dial_errors: Some([]) }
Gossipsub: Message { propagation_source: PeerId("16Uiu2HAkxXY47H2ecnysMRHPzu4Kc2S7AuE8DjhgKNShNUME2382"), message_id: MessageId(62f8937b482d3174c5017e3ef573786914617c17), message: GossipsubMessage { data: 640000008067ec8433.., source: None, sequence_number: None, topic: TopicHash { hash: "/eth2/224daa27/beacon_block/ssz_snappy" } } }
Gossipsub: Message { propagation_source: PeerId("16Uiu2HAkxXY47H2ecnysMRHPzu4Kc2S7AuE8DjhgKNShNUME2382"), message_id: MessageId(b691f9178a00274025696ee204bd5a94d4ac8688), message: GossipsubMessage { data: 64000000848102bf4f.., source: None, sequence_number: None, topic: TopicHash { hash: "/eth2/224daa27/beacon_block/ssz_snappy" } } }
Gossipsub: Message { propagation_source: PeerId("16Uiu2HAmMJ5wq7Uih3RQ2PzisBCFcBuYg5Qy15BYMh8dQnBVcvVr"), message_id: MessageId(fed1c3b8a90ca2dadc91c360885c4a89fe1e3d19), message: GossipsubMessage { data: 64000000b3235b0fac.., source: None, sequence_number: None, topic: TopicHash { hash: "/eth2/224daa27/beacon_block/ssz_snappy" } } }
Gossipsub: Message { propagation_source: PeerId("16Uiu2HAmMJ5wq7Uih3RQ2PzisBCFcBuYg5Qy15BYMh8dQnBVcvVr"), message_id: MessageId(ffc781e23087d5d66e23e13042830ab60ed3ab90), message: GossipsubMessage { data: 64000000a8ee44128b.., source: None, sequence_number: None, topic: TopicHash { hash: "/eth2/224daa27/beacon_block/ssz_snappy" } } }
Gossipsub: Message { propagation_source: PeerId("16Uiu2HAmMJ5wq7Uih3RQ2PzisBCFcBuYg5Qy15BYMh8dQnBVcvVr"), message_id: MessageId(fa73d2d9ca6a73c40c47417060ec16b739b4f8a5), message: GossipsubMessage { data: 64000000b88551ad1f.., source: None, sequence_number: None, topic: TopicHash { hash: "/eth2/224daa27/beacon_block/ssz_snappy" } } }
ConnectionClosed: Some(IO(Custom { kind: Other, error: A(YamuxError(Closed)) }))
ConnectionClosed: Some(IO(Custom { kind: Other, error: A(YamuxError(Closed)) }))
ConnectionClosed: Some(IO(Custom { kind: Other, error: A(YamuxError(Closed)) }))
I couldn't find anything in the specs that could let me know what was lacking in my codebase, so I reached to @alexstokes for help, and he suspected it could be a scoring issue (yes, peers are scored to keep track of usefulness or maliciousness) and advised me to test with a local testnet to see what was going on.
I went on with that using the lighthouse client, and here is what I found:
I was being disconnected for:
- Not supporting the
metadata
protocol
- Not supporting the
ping
protocol
I was also curious about which other unsupported protocols could make me a bad peer, so I looked in the lighthouse client for it:
Clearly I needed the ping
protocol working. For my next steps I will implement these protocols. Until then!