Ethereum enables arbitrary computations to be run in a decentralized and trust minimized manner, but in reality developers are much more limited in the types of computation they can include in their smart contracts. Computationally heavy tasks quickly become prohibitively expensive to run on-chain due to gas costs. Their execution time is also bounded by the time it takes for the network to achieve consensus. As a result, on-chain execution of computationally heavy tasks such as video transcoding and 3D rendering are infeasible. However, smart contract developers nonetheless have a number of options to work around these restrictions today. Many of these solutions borrow ideas from the formal field of verifiable computation, which studies the outsourcing of computation to untrusted third parties while maintaining verifiable results. A key attribute of verifiable computation is the ability of clients to not only retrieve the result and proof of correctness for an outsourced operation, but to also verify the proof of correctness with less computational power than is required by the actual operation.
In the context of Ethereum, computation can be outsourced to oracles, third parties that push external data onto the blockchain. Oracles can be categorized into
- Data carrier oracles that relay query results from a trusted data source to a smart contract
- Computation oracles that not only relay query results, but also perform the relevant computation themselves. Computation oracles can be used as building blocks to construct off-chain computation markets
Both types of oracles can be used to connect smart contracts with the results of arbitrary computations (with the caveat that data carrier oracles must support and have access to an existing data source that is capable of performing the computation). The rest of this post presents a high level overview of a few oracle based off-chain computation solutions that Ethereum developers can use to integrate computationally heavy tasks into their smart contracts and compares their varying trust properties.
Data Carrier Oracles
Data carrier oracles commonly use cryptographic proofs to provide data authenticity guarantees. Examples of data carrier oracles include Oraclize and TownCrier. Oraclize offers a number of authenticity proof options depending on the data source being used including TLSNotary and Android remote attestation based proofs. TownCrier uses signed attestations by trusted hardware (specifically Intel SGX).
Oraclize allows developers to fetch the results of arbitrary computations on an AWS virtual machine using Oraclize’s computation data source. Developers can upload a zip archive containing a Dockerfile and the necessary dependencies for the Docker application to IPFS. Oraclize monitors the blockchain such that when a smart contract queries the Oraclize smart contract with the IPFS hash of the archive, an Oraclize AWS instance will retrieve the archive, initialize and execute the Docker application, and then the Oraclize smart contract will send the result of the computation to the original smart contract.
Developers can optionally ask Oraclize for a TLSNotary proof to verify data authenticity. This proof uses the TLSNotary algorithm which allows an auditor to verify that an auditee did not tamper with data retrieved from a data source by withholding a secret from the auditee that is generated by splitting the TLS master key (this feature is only available for TLS v1.0 and v1.1) until the auditee commits to the hash of a result that it will later reveal after it obtains the withheld secret. In this case, Oraclize is the auditee and the Oraclize AWS instance is the auditor. The Oraclize AWS instance is setup as an AWS oracle, which enables anyone to verify that a set of programs is running on the machine and has not been modified since some time in the past using the AWS API. The authenticity proof is a signed attestation by the Oraclize AWS instance that the TLSNotary algorithm was executed and that Oraclize could not have tampered with the retrieved data. As a result, users do not need to trust Oraclize. Instead, users trust Amazon’s infrastructure, which might be acceptable depending on one’s goals and preferences.
Similar to Oraclize, TownCrier allows users to query a smart contract which is monitored by an external service that relays the query to a machine which will retrieve data from the relevant data source. The main difference is that TownCrier executes code in an Intel SGX enclave which is a protected address space. Any processes running in the enclave are protected from hardware attacks and software running on the same host. Additionally, any remote client can verify the software running in the enclave by requesting a hash of the enclave state which is signed by the enclave’s hardware protected private key. Anyone with the enclave’s public key can then verify signed attestations made by the enclave about program state. The signed attestation proves to users that TownCrier could not have tampered with retrieved data as long as users believe that Intel’s trusted hardware implementation is trustworthy. As a result, users do not need to trust TownCrier. Instead, users trust Intel’s hardware. Once again, this might be acceptable depending on one’s goals and preferences. Note that TownCrier currently only supports a limited number of public APIs and does not currently support arbitrary computation defined by users.
Computation Oracles
Data carrier oracles can be incredibly useful, but since they are only used to relay data from an existing data source, users still have to trust the data source. Computation oracles go one step further by actually performing the relevant computation. A number of models for computation oracles have been proposed in the past. The SchellingCoin protocol incentivizes a decentralized network of oracles to perform computation by rewarding participants who submit results that are closest to the median of all submitted results in a commit-reveal process. A model for verifiable computation oracles involves m-of-n oracles performing computation and voting on the correct result with the ability to challenge results by submitting a security deposit— in the scenario of a challenge, the computation is performed on-chain to decide whether to penalize the challenger or a misbehaving oracle. Ethereum computation markets present the verifiable computation oracle model in the context of an open market in which anyone can request for computation to be performed by another market participant.
One of the most promising implementations of a verifiable computation market is TrueBit, which expands on the idea of Ethereum computation markets by introducing a system of solvers and verifier — solvers are compensated for performing computation and verifiers are compensated for detecting errors in solutions submitted by solvers. Additionally, to ensure verifiers are incentivized to closely monitor solvers, TrueBit forces solvers to occasionally submit solutions with errors that verifiers are tasked to report. In the event of a challenged solution, solvers and verifiers play an interactive verification game such that only a small portion of the computation is performed on-chain after a number of rounds during which the challenger disputes increasingly smaller subsets of the original computation.
A system like TrueBit might be the ideal solution for scalable off-chain computation, but given that development is still in-progress and the estimated verification tax for a computational task is 5x to 500x the cost of the actual computation, Ethereum developers might consider using TrueBit as a single component of their off-chain computation solution rather than relying on TrueBit alone. One option is to to use a data carrier oracle such as Oraclize or a custom trusted hardware oracle setup (or TownCrier if it supports the computational task) that offers the ability to relay results from a trusted data source performing the computation and use TrueBit once it is in production as a backstop if a certain participant believes the trust properties of the data carrier oracle or data source have been compromised. Another option is for developers to design protocols to only require verification for a number of randomly selected smaller subsets of all computation to reduce the cost of using a system like TrueBit while relying on the random challenges to encourage honest behavior by participants.
Conclusion
The ability to integrate arbitrary off-chain computation into smart contracts will unlock many interesting possibilities for developers creating cryptoeconomic protocols and decentralized applications. A production ready TrueBit will be incredibly important, but developers should also keep in mind the time horizon of their own development roadmap relative to the time horizon of the TrueBit development roadmap as well as the eventual costs of using TrueBit when it is ready. Intelligent protocol design and leveraging oracle solutions available today can help developers architect off-chain computation solutions that will last into the future.
Thanks to Doug Petkanics and Eric Tang for providing feedback on this post.
