ipld / specs

Content-addressed, authenticated, immutable data structures
Other
592 stars 108 forks source link

Ethereum data structures #358

Closed i-norden closed 3 years ago

i-norden commented 3 years ago

Hello 👋

This PR introduces the IPLD schemas for Ethereum. I'm opening it as a draft as I still need to verify the correctness of the schemas, but would like to open it up to feedback at this stage.

In addition to the canonical Ethereum IPLD structures, that exist natively within the Ethereum merkle forest due to the hash-linked nature of the Ethereum blockchain, there are also additional, proposed "convenience type IPLDs" which are not linked to directly from any canonical Ethereum objects but can be generated and verified from said objects.

rvagg commented 3 years ago

:boom: amazing. You might have to be a bit patient for us to find the time to review this as we're all a bit scattered at the moment but I'm very keen to dig into this. Keep us updated in the thread about any further progress.

Rendered for anyone who wants a quick link: https://github.com/vulcanize/specs/tree/ethereum-data-structures/data-structures/ethereum

warpfork commented 3 years ago

I have skimmed and I think I'm happy with this, as far as I can tell. (Still with the disclaimer of not being an Ethereum domain expert, so I'm necessarily trusting those things to be correct.)

In the hypothetical, I'd love to have more fixtures, as well as some automaticed syntax validation on the schema components. However, this repo as a whole is a fair stride from having that infrastructurally available, today, and so it would not be reasonable to hold up for that (more likely it's more productive to merge this in the meanwhile, and try to add that later).

warpfork commented 3 years ago

How would you folks feel about merging these things? I think I'm happy enough carrying them in their current state (and accepting future PRs quickly if things need patching or expansion).

I'd actually like to start carrying them on master, I think, because it would make it easier for carry them along while doing some reorganizing of the specs and docs content as a whole which is on my near future todo list. (These files will probably move during that -- though I think relative arrangement to each other is great and would stay.) It's equally fine with me if we want to keep them as a draft PR, but I just don't see the need.

i-norden commented 3 years ago

Hi @warpfork I am definitely fine with merging as is. I need to make some updates to support the new EIP-2718 and EIP-2929 tx types which were recently added in the Berlin fork. I will try to get that done today, but I can do that in a second PR if you want to go ahead and merge.

rvagg commented 3 years ago

+1 to merging as is and updating as we go since @warpfork is itching to reorg our docs and having this along for the ride would be helpful