docs: define testnet protocol identifier #258
Conversation
portal-wire-protocol.md
Outdated
| - Inclusive range of `0x5000` - `0x5009`: Reserved for future networks or network upgrades | ||
| - `0x500A`: Execution State Network | ||
| - `0x500B`: Execution History Network | ||
| - `0x500C`: Execution Transaction Gossip Network | ||
| - `0x500D`: Execution Canonical Transaction Index Network | ||
| - `0x501A`: Beacon Chain Light Client Network | ||
| ### Testnet identifiers | ||
| Currently defined testnet protocol identifiers: | ||
| - `0x501A`: Execution State Test Network |
There was a problem hiding this comment.
This is the same as Beacon Chain Light Client from mainnet.
There was a problem hiding this comment.
Ok I updated them to not conflict
|
Resuming discussion here for greater visibility and input from other people (previous discussion is here) Summary is that I don't like that there is no connection between mainnet and testnet ids. My first idea was to just change the first byte (e.g. I'm also fine with adding fixed prefix to the second byte (e.g. So it would be something like this:
Ultimately, it's just a matter of preference and I don't think there is big advantage one way or the other. So I'm fine with anything we agree on. |
I agree that, while not being necessary, this would be nice. I'd also be fine with changing some Mainnet ID's of the networks that are not in use yet (e.g. beacon) if that helps. |
That would be a dream come true if beacon was aligned with the other ids 🚀 |
Then I'd say, lets make beacon |
KolbyML
requested review from
morph-dev,
pipermerriam,
kdeme,
njgheorghita and
ogenev
and removed request for
morph-dev
|
@morph-dev @kdeme ready for another look |
|
You guys can merge this whenever you guys are comfortable |
We are approaching launching a pre-merge history mainnet for serving 4444's data.
With the idea of mainnet in mind that means distinguishing a test network for testing major features to protect against breakages on mainnet. Or for testing future networks like beacon and state which would now take the place on the testnet work.
To distinguish these networks we will use different discv5 talkreq protocol id's.
Currently we have mainnet running history and beacon, testing if we can propagate new blocks in a timely matter. But we currently don't have validation for the post-merge data.
The mainnet's purpose would only support strict validation of data. Unlike the flexibility a testnet provides where we don't require stringent rules. So we would move the testing of beacon to our testnet.
We would only officially run history pre-merge data on mainnet as it is currently the only network which has the gears in place for this process to begin.