Add eth-evm-code codec

[ghost]

This is the binary found in a smart contract account, referenced in ethereum by keccak256(evm_code_binary). It is binary data, which the Ethereum Virtual Machine (EVM) interprets.

[whyrusleeping]

This is yet another distinct ethereum format?

[ghost]

@whyrusleeping It is a raw binary. The work around is using 0x55 to reference it. We would like to have a codec for meta purposes, i.e. We would know "Oh, this IPLD is an EVM Code"

[whyrusleeping]

Hrm... if there isnt any inherent structure to the data, then i really hesitate to add another new code for it.

[Stebalien]

In general, that's not what CIDs are for. CIDs allow one to interpret unstructured binary into structured data but shouldn't (usually) be used to determine the intended use of the data (unixfs currently does this but it but shouldn't).

For example, we've considered adding a code for webasm but that's because it's an AST, not just raw binary. However, if a user provided a CBOR-encoded webasm AST, an IPLD webasm VM shouldn't care.

[ghost]

I see. I'm short on argumentations, as I am not particularly clear on the overall vision of CID. While the points expressed above make sense to me, I'd like to get @kumavis feedback, as he is the "end user" of this information.

[Stebalien]

Basically, IPLD == structured data. CIDs exist to allow us to be compatible with existing merkledags (e.g., eth, git, our own protobuf-based merkledag (used in unixfs), etc.). In general, IPLD does not encode type information beyond basic primitives such as: byte array, array, string, number, float, map, etc... (exact primitives TBD by the end of this week or I start kidnapping people).

[kumavis]

yeah theres not a lot of structure to this. you could index it by program counter or op code index (skipping inline data associated with an opcode) but no external links.
but there is value in identifying what the data is "this is evm code"

im indifferent

[daviddias]

A couple of questions:

• Is there a need for this to be "serialized and deserialized"?
• Is there any local resolve to happen?

From the thread, sounds like you won't benefit from having the evm code as a IPLD Format.

[ghost]

@diasdavid

Is there a need for this to be "serialized and deserialized"?
Is there any local resolve to happen?

No and no. 😄

Just a little bit of context...

We have eth-account-snapshots. One of their fields is the codeHash (for now, just a keccak256 hash of the actual EVM code this account holds, but wanting it to become a CID, so we can fetch it).

What are we doing now? We are importing this data, making it a "raw" (0x55) elementand hashing it as a "keccak256" (0x1b). One example is zb34VweGrraA5TkNXMLYj1AEUw9GfqsU9ov6PM9QiKjxKFf6J. We already imported 30,261 of these, which are the unique versions of the 1845516 smart contracts of the current mainnet ethereum blockchain (yeah, there is a huge number of dups in there).

So, as @kumavis said, there is value on identifying that this is not just ordinary raw information hashed into keccak256, but actual ethereum smart contract code. I second him, as I see a meta value in figuring out the contents of a cid via its codec, But @Stebalien well argues that CID shouldn`t convey this information. Both arguments make sense to me, therefore I am indiferent.

Do we close this PR then?

[daviddias]

@Stebalien is right, CID should not convey that information. That doesn't mean that the metadata information should not exist in the whole data structure. Think of CID such as Content Address + File Extension, the File Extension part lets the IPLD resolver figure out what content it is, how to parse it and traverse through it and that is pretty much it (for now).

Also, if I'm understanding correctly, you know that the codeHash is indeed pointing to EVM code, isn't that enough meta info to know that the data coming from that pointer is indeed EVM code?

[ghost]

All clear. Closing this issue.