search

ethereumjs / organization

A repo for discussions and other non-code organizing stuff
https://ethereumjs.readthedocs.io
12 stars 17 forks source link

Witness Support #73

Closed holgerd77 closed 2 weeks ago

holgerd77 commented 3 years ago

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 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...

type Witness = Buffer // some basic Buffer-based witness type

Trie.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 https://github.com/ethereum/stateless-ethereum-specs/issues/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:

holgerd77 commented 3 years ago

(older issue, moved over from https://github.com/ethereum/js-team-organization repository)