Closed KolbyML closed 6 months ago
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. 0x51xx
), but I wasn't aware that 0x50
stands for P
. I'm not sure how important is to keep that for testnet as well, and maybe we can do something like 0x54
(for T
).
I'm also fine with adding fixed prefix to the second byte (e.g. 80
or 40
). I'm leaning towards 40
as we can easily create more test networks if we need to (we can also go for 80
and still use 40
for the second testnet).
So it would be something like this:
MAINNET | TESTNET | |
---|---|---|
State | 0x500A | 0x504A |
History | 0x500B | 0x504B |
TransactionGossip | 0x500C | 0x504C |
CanonicalIndices | 0x500D | 0x504D |
Verkle (pending PR) | 0x500E | 0x504E |
Beacon | 0x501A | 0x505A |
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.
Summary is that I don't like that there is no connection between mainnet and testnet ids.
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.
Summary is that I don't like that there is no connection between mainnet and testnet ids.
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 🚀
That would be a dream come true if beacon was aligned with the other ids 🚀
Then I'd say, lets make beacon 0x500C
and TransactionGossip 0x500F
(Or even remove it for now).
@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.