Summary
The networking codec test vectors introduced in PR #608 define gossip topic strings using the hex-encoded forkDigest as the path segment:
/leanconsensus/0x12345678/block/ssz_snappy
However, all clients currently build gossip topics using a fixed network name string:
/leanconsensus/devnet0/block/ssz_snappy
This means every client fails all 8 gossip_topic test vectors. The mismatch is ecosystem-wide, not specific to any single client.
Evidence across clients
Verified in source code:
| Client |
Language |
Topic format |
Source |
| gean |
Go |
const NetworkName = "devnet0" |
p2p/topics.go:6 |
| ethlambda |
Rust |
pub const NETWORK_NAME: &str = "devnet0" |
crates/net/p2p/src/gossipsub/messages.rs:13 |
| zeam |
Zig |
chain_config.spec.name → "devnet0" from config |
pkgs/network/src/interface.zig + pkgs/cli/src/node.zig:145 |
| ream |
Rust |
LeanGossipTopic { fork: String } (generic) |
crates/networking/p2p/src/gossipsub/lean/topics.rs — unit tests use "0x12345678" but runtime format is configurable |
Switching any one client to the forkDigest format would break the gossip mesh.
Fixture test results (from gean's spec harness)
Running leanSpec PR #608 networking codec fixtures:
| Codec |
Passed |
Failed |
| varint |
13/13 |
0 |
| gossip_message_id |
8/8 |
0 |
| enr |
3/3 |
0 |
| gossip_topic |
0/8 |
8 |
All 8 gossip_topic failures are the same pattern:
got: /leanconsensus/devnet0/block/ssz_snappy
want: /leanconsensus/0x12345678/block/ssz_snappy
Question to delibrate on
Which format is canonical for devnet-4?
- Fixed network name (devnet0) — what every client currently uses in production. Simple, no fork-awareness.
- Hex forkDigest (0x12345678) — what the spec fixtures define. Fork-aware, supports multiple concurrent forks on the same network.
If option 2 is the direction, all client teams would need to coordinate the switch simultaneously to avoid breaking the live gossip mesh. If option 1, the fixtures in PR #608 should be updated to reflect the deployed reality.
Related
Summary
The networking codec test vectors introduced in PR #608 define gossip topic strings using the hex-encoded forkDigest as the path segment:
/leanconsensus/0x12345678/block/ssz_snappyHowever, all clients currently build gossip topics using a fixed network name string:
/leanconsensus/devnet0/block/ssz_snappy
This means every client fails all 8 gossip_topic test vectors. The mismatch is ecosystem-wide, not specific to any single client.
Evidence across clients
Verified in source code:
Switching any one client to the forkDigest format would break the gossip mesh.
Fixture test results (from gean's spec harness)
Running leanSpec PR #608 networking codec fixtures:
All 8 gossip_topic failures are the same pattern:
Question to delibrate on
Which format is canonical for devnet-4?
If option 2 is the direction, all client teams would need to coordinate the switch simultaneously to avoid breaking the live gossip mesh. If option 1, the fixtures in PR #608 should be updated to reflect the deployed reality.
Related