Rosetta Abstractions for Ethereum based protocols

Congratulations on releasing Rosetta! One thing I couldn’t infer from a quick scan of the docs is whether or not a protocol deployed on Ethereum (with an accompanying ERC-20 asset) could use any of the Rosetta abstractions on top of it’s node/wallet APIs, in order to get the Rosetta benefits of easier ecosystem integration support?

I suspected not, at first glance, as there would need to be a universal Ethereum Rosetta to expose the ETH blockchain information in the common formats. (And Ethereum is already generally supported widely). But then I saw the staking + smart contract abstractions mention in the docs, and thought that the notion of sub-accounts and delegated stake balances would provide what’s needed for protocols deployed within Ethereum or other smart contract platforms.

Thanks!

Rosetta :heart: Ethereum Smart Contracts (I’ll work on making this more clear on the website!)

The Rosetta APIs were designed specifically to support the generic usage of smart contracts on Ethereum (or any other blockchain with smart contracting). As you mentioned, the expressive notion of accounts allows an implementer of the Rosetta APIs to represent an account’s on-chain activity in the context of a smart contract:

{
    "address": "<address>",
    "sub_account": {
        "address": "<smart contract>",
    }
}

The lack of pre-defined operation types allows for you to support any on-chain activity with types that are native to your deployed contracts. Celo’s implementation of the Node API is based on a fork of geth and may provide some insight on how to proceed with an Ethereum-based implementation.

The way I see it, you have 2 choices for implementing Rosetta on top of Ethereum (your choice will very likely depend on what sort of native ETH functionality you want integrators to have):

  1. Support all native Ethereum operations + any operations from your smart contracts
  2. Just support operations related to your smart contracts (likely MUCH easier)

If you do decide to undertake option 1, I HIGHLY recommend breaking out your work into 2 projects:

  1. Basic EVM Rosetta implementation that allows for module-based smart contract parsing
  2. Your module that fits into this implementation (which wraps item 1)

This will allow other projects that want to use Ethereum to not have to re-invent the wheel and for you guys to get shared development resources on the core Ethereum implementation. If you go the route of working on a master Ethereum repo, it could get unwieldy pretty quickly if each team deploying smart contracts on Ethereum has to open a PR.

Hope this helps!

3 Likes