Generate Code For ethPM Contracts.

[nlordell]

This will be in two parts:

• Don't depend on the contract being in Truffle artifact representation (needs to support plain JSON ABI + extra data)
• Support ethPM manifests and packages

[fubuloubu]

Hey! I'm the maintainer of the rust ethPM bindings: https://github.com/ethpm/ethpm-rs

It's still a work in progress, but I would like to collaborate on this if possible!

[nlordell]

Hey, that would be awesome! Currently, the code generation backend still heavily relies on the Truffle artifact format. However, it is possible to get around that limitation by converting the data from the EthPM manifest to this format (similar to what was done with the Etherscan verified contract support).

What the code generation backend needs as a bear minimum is:

• A contract name
• A contract ABI

The next things that would be useful and can probably be provided by EthPM are:

• Deployed contract addresses on the network
• Bytecode with linking locations

And finally the super nice to have would be to also get some of the contract metadata like descriptions and method documentation to generate rustdoc documentation.

Ideally, it would be great to be able to get a manifest from some URL (either directly or by registry + package + version). At that point I think integrating it into the code generation backend should be fairly straightforward.

Feel free to reach out with questions or ideas anytime!

[fubuloubu]

We can parse ethPM manifests, but the end data format is simple and wouldn't integrate well as is. I'd like to make it do so, but it would make a heavy use of macros over ABIs, similar to the ones you already have.

I had some grand ideas of how this macro could retrieve and parse the manifest into a static data type with some standard trait implementations, such that the resulting code could be no_std compliant for use in things like web assembly.

[nlordell]

That sounds like cool idea! What kinds of methods would these generated types have? I’m assuming it would be used to ABI encode thing and maybe make HTTP requests over some WebAssembly std-web bindings?

[fubuloubu]

Well I mean more that when you process a manifest, it produces a series of contract data types in the manifest, so that it's more ergonomic than having to mash it. For example, here is where we parse for ethPM contract_types. It produces pretty raw results, it would be nicer to have them directly usable as web3 contract types. Nicer still to have them produce individual types like RustCoin which contain the ABI and bytecode necessary to work with it in a project.

[nlordell]

Sounds great! And I’m definitely looking forward to it.

Just a heads up though, I don’t know how feasible it is to make ethcontract generated types no-std at the moment. Off the top of my head some important crates that are needed but as far as I know aren’t no-std friendly:

• rust-web3
• secp256k1

[fubuloubu]

libsecp256k1 is a pure-Rust, no-std compliant crate for secp256k1 curves fully supported by Parity (used in Substrate). It's a good library that I would recommend over the Rust bindings for Peter Wiulle's C++ Bitcoin secp256k1 library.

There is talk about decontructing rust-web3 into a chunk of functionality that is no-std compliant: tomusdrw/rust-web3#21. I would definitely like to see this happen, as it should possible to construct and sign transactions and deal with internal data types without an RPC connection.

[nlordell]

libsecp256k1

If only I'd have known, I would probably just have used this directly 😝

There is talk about decontructing rust-web3 into a chunk of functionality that is no-std compliant

That would be a huge step. I'd be happy to support no_std here where possible as well.