Unique content key prefixes cross portal content networks #1924
Assignees
Labels
Comments
|
Ultralight already did it: https://discord.com/channels/890617081744220180/890617082243350560/1182016810376253450 and they plan to enable it soon |
That's fine. The ids for history network remain the same. The other networks are not really enabled yet for us (well state is enabled but no data is going around, I guess I could disable it). |
kdeme
added a commit
that referenced
this issue
Dec 19, 2023
The Portal specifications where adjusted so that the content key prefixes become unique selectors over all networks. Fixes issue #1924 SSZ Union is still used, but it could be that in the future we need to move to our own custom serialization here.
kdeme
added a commit
that referenced
this issue
Dec 19, 2023
The Portal specifications where adjusted so that the content key prefixes become unique selectors over all networks. Fixes issue #1924 SSZ Union is still used, but it could be that in the future we need to move to our own custom serialization here. The unused enum value and the fact that we have to add these to the case of is quite annoying but unless we stop using a case object seems not avoidable.
kdeme
added a commit
that referenced
this issue
Dec 19, 2023
The Portal specifications were adjusted so that the content key prefixes become unique selectors over all networks. Fixes issue #1924 SSZ Union is still used, but it could be that in the future we need to move to our own custom serialization here. The unused enum value and the fact that we have to add these to the case of is quite annoying but unless we stop using a case object seems not avoidable.
|
Solved in #1950 |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
We need to implement this spec change: ethereum/portal-network-specs#233
The text was updated successfully, but these errors were encountered: