WASM oracle in Nitro

1

Motivation
Solidity is a great language for articulating contracts over on-chain events. Especially for smart contracts about real-world systems however, there’s a need to perform computations which cannot be efficiently described via solidity. For example, for a truly trust-minimal version of our interactive https oracle protocol, which uses enclaves to create proofs of web2 events, a smart contract would have to directly verify a special certificate chain provided by the enclave manufacturer/host, whose signatures are generally on curves that are not natively supported by Ethereum. We currently solve this by having one trusted enclave permanently running that verifies the certificates of others, but that trusts us developers for the liveness of the system.

Of course, the utility of supporting general purpose computation in smart contracts goes beyond web2 oracle protocols - it unlocks the whole stack of battle-tested software packages developed before blockchain came around. It could position Arbitrum as a trustless settlement layer for all kinds of currently non-crypto apps.

Proposal
I want to propose allowing solidity contracts to query the result of executing arbitrary WASM code on a given input. For simplicity, we should require both the input and the .wasm file to be posted on l1, at first.

Maybe the easiest EVM-centric design here would be to modify geth to let calls to a special ‘precompiled contract’ trigger the execution of arbitrary WASM code, feeding back the results to the calling contract in a synchronous fashion.

What would be the main challenges to implementing this?

Alternatives
Basically, there’s only Cartesi and Truebit. Cartesi is great, but unlike Arbitrum, it doesn’t pursue a global consensus model, requiring contract users to trust a whitelisted committee to challenge invalid state updates - hence contract developers are likely still a single point of failure. Also, solutions like Truebit and Cartesi always require a delay between the contract query and the result - whereas extending an optimistic rollup to handle non-evm execution would not come with an additional delay, since optimistic computations can trust each other. Arbitrum is in the unique position to provide this utility to the ecosystem, allowing it to capture a unique network effect of contracts about real-world events.

59 Likes
2

Thanks for suggesting this! We’re interested to hear some potential use cases, and how people would want to use a facility like this.

12 Likes
3

Thank you for hearing me out!

Other general-purpose computation oracles like Cartesi seem to focus a lot on Gaming dApps, which wil likely require tooling beyond what Solidity can provide. Again, what would attract these applications to Arbitrum(+WASM oracle) over Cartesi would be that L2 contracts immediately obtain the results as they can ‘trust’ the optimistic computations.

However, my perspective will inevitably focus on ways to have smart contracts about off-chain data. It’s just something I’m inherently more excited about. I’m talking about

  • contracts about Venmo (MPesa, PayPal, etc) transactions, enabling trustless fiat-crypto on-/offramps
  • contracts about NASA weather data, enabling trustless, scalable weather-insurance for the developing world
  • contracts receiving proofs of a unique-for-life ID (computed from online social security data) to enable e.g. uncollateralized lending over the blockchain
  • contracts providing trustless, long-term incentives for carbon-negative land-use changes (e.g. reforestation) to the degree that is observable from e.g. NASA data
  • contracts selling carbon credits on one end, and on the other end reimbursing people who generate a proof (from their online utilities bill) that they switched to more expensive, renewable utilities providers.

What most of these have in common is that we don’t want decentralized set of Chainlink nodes to independently verify this data, because it’s behind private login credentials that you don’t want to share with these nodes. That’s why I’ve explored the design space for solutions which don’t require the users to give up their login credentials, or other sensitive data to enter into any of the above contracts. What they also have in common is that all of these contracts require a way to authenticate https data, and then perform off-chain computation based on it (e.g. execute the javascript generating the venmo page, process raw satellite data, etc).

II wrote an FAQ on why I think enclaves hosted by reputable cloud providers (I know! Centralized, AWS, red flag!) are currently the best trade-off for smart contracts like above (tldr: trusting e.g. Venmo’s servers is a stronger assumption than trusting AWS enclaves). Smart contracts still provide a meaningful benefit by eliminating counterparty risk, being permissionless, and globally available.

That’s why we built an oracle platform based on it, which is actually soft-launched on Arbitrum right now. We have prototypes of most of the stuff above live, too. (We didn’t announce it yet, but e.g. you can actually trade USD for ETH on Arbitrum with any other Venmo user right now, without trusting anyone but Venmo and AWS enclaves! We’re currently integrating with OpenGSN to support initially empty wallets too. It will be a 10x cheaper onramp than Coinbase et al, directly to L2!). In my previous post, I mentioned why a trust-minimal version of our platform would require a trustless WASM oracle: the contracts need to verify ‘attestation documents’ containing certificate paths which trace back to the centralized point of trust hosting/building the enclaves.

But I do see enclaves as only the lowest hanging fruit/a temporary evil, and I see (and want to pursue) a few possibilities for moving beyond it. They all rely on some form of multi-party computation to create a ‘proof’ of a valid TLS connection. Then they need to perform two computational tasks:

  • verify the TLS certificate chain
  • execute the JavaScript which creates the html on modern websites (for non-API data like venmo, or online utilities bills) OR run a python script over some raw API data (e.g. for weather insurance based NASA satellites).

both of which would require a general-purpose computational (at least WASM) oracle - either zk (maybe possible in 4 years?) or optimistic (possible now!).

I’d be happy to hop on a call with you for details, that might be more efficient. You can reach me at jonas(at)opencontracts.io

19 Likes
4

Another thought: to make this broadly accessible for devs, and to keep the ability for contract users to read the source code, it would suffice for most applications if we compiled the Pyodide python interpreter to run on Nitro. Then, contracts could execute arbitrary pure python scripts and packages (+many with C extensions are supported too!) as long as they are posted to l1.

11 Likes
5

Hi @edfelten! What do you think? Would you be open to supporting such a functionality? I’d be happy to contribute to e.g. getting the Pyodide interpreter to run on Nitro.

11 Likes
6

Some interesting ideas there. Do you have a guesstimate for how much overhead would be involved in running something like Pyodide?

7 Likes
7

@edfelten It turns out you can run try out the Pyodide CLI in real time running on WASM in your browser. I timed a little code snippet:
image
roughly 4x slower than Python natively running on windows:
image

Totally reasonable, don’t you think?

17 Likes