You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The format definition itself is not too much of black magic and I think it makes sense to start on an integration early on to help a bit along on the research and specification side. Scope of the work is limited and there needs to be a start at some point (imagine Prysmatic having waited for the Eth 2.0 specs to finalize 😜).
Things get trickier on the real-life-behavior properties side with demands on stream- and chunkability together with restrictions on memory allocation, see Representation section in the docs. I e.g. first thought to have a separate witness repository with a class-based representation of a witness: this might not be feasible due to the memory constraints?
My suggestion would be to start relatively low and to concentrate on format decoding and to forget about the other properties for now.
We can e.g. add an (experimental) function...
typeWitness=Buffer// some basic Buffer-based witness typeTrie.fromWitness(witness: Witness,trie?: Trie): Promise<Trie>
... to the merkle-patricia-tree library a bit analogue (on the signature) to the Trie.fromProof method. Then we can slowly get a better feeling for the format and are driven more to engage in the specs repo and so generally have some starter here to further build upon. I would assume that it should be possible for larger parts of the code created along to be re-used within a more finalized implementation structure going more coherent with the additional properties from the spec. Does this make sense?
One base question here to answer as a pre-requisite is if this makes sense to implement on top of a hex trie implementation, also asked this here ethereum/portal-network-specs#10 on the specs repo.
So eventually we need to reflect on a binary trie strategy (add/implement/re-use) first. Update: see also #16
Witness format specification along the Eth1.x initiative is in development within the stateless-ethereum-specs repository.
The format definition itself is not too much of black magic and I think it makes sense to start on an integration early on to help a bit along on the research and specification side. Scope of the work is limited and there needs to be a start at some point (imagine Prysmatic having waited for the Eth 2.0 specs to finalize 😜).
Things get trickier on the real-life-behavior properties side with demands on stream- and chunkability together with restrictions on memory allocation, see Representation section in the docs. I e.g. first thought to have a separate
witnessrepository with a class-based representation of a witness: this might not be feasible due to the memory constraints?My suggestion would be to start relatively low and to concentrate on format decoding and to forget about the other properties for now.
We can e.g. add an (experimental) function...
... to the merkle-patricia-tree library a bit analogue (on the signature) to the Trie.fromProof method. Then we can slowly get a better feeling for the format and are driven more to engage in the specs repo and so generally have some starter here to further build upon. I would assume that it should be possible for larger parts of the code created along to be re-used within a more finalized implementation structure going more coherent with the additional properties from the spec. Does this make sense?
One base question here to answer as a pre-requisite is if this makes sense to implement on top of a hex trie implementation, also asked this here ethereum/portal-network-specs#10 on the specs repo.
So eventually we need to reflect on a binary trie strategy (add/implement/re-use) first. Update: see also #16
Other sources:
The text was updated successfully, but these errors were encountered: