A notable suggestion for executing smart contracts in a manner that diverges from their conventional presentation in Ethereum revolves around the idea of oracles. Essentially, rather than allowing a long-term contract to execute directly on the blockchain, all assets intended for the contract would be directed to an M-of-N multisig address governed by a group of specialized entities known as “oracles”, with the contract code concurrently dispatched to these entities. Each time an individual wishes to communicate with the contract, they would direct their message to the oracles. The oracles would execute the code, and if the execution results in a withdrawal from the contract to a specific address, the oracles would facilitate a transaction to send the funds and validate it.
This method maintains a lower level of trust, as no singular oracle possesses the capability to unilaterally withdraw the assets, but it brings forth several distinct benefits:
- Not all nodes in the blockchain are required to perform the computations – only a limited number of oracles do.
- Theoretically, it does not necessitate a platform more complex than Bitcoin or Ripple in their current forms.
- Contracts can have an elevated level of privacy – although exit transactions remain fully visible, internal computations may not. Moreover, the framework can be enhanced with secure multiparty computation protocols, enabling the contract to potentially include confidential information (which would demand efficient and secure obfuscation to function directly on Ethereum).
- Contracts can depend on external data (e.g., currency rates, weather conditions) since it is considerably easier for N nodes to achieve consensus on the outcome of an HTTP request than for an entire blockchain. In fact, they can even utilize data from proprietary APIs, provided the oracles subscribe to these APIs and relay the expenses to the contract users.
Considering these advantages, it is evidently clear that oracles hold the potential to become a highly beneficial paradigm for future smart contracts. Nevertheless, the pivotal inquiry is: how will oracle-driven computation interact with blockchain-based computation, as seen in Ethereum?
Oracles Are Not Always Superior
To begin with, it’s crucial to point out that the oracle-based method of contract execution will not always prove to be more efficient than the blockchain-based methodology (not to mention non-currency/non-contract applications of the blockchain, such as name registries and the People’s Republic of DOUG where oracle systems are inapplicable). A widespread misunderstanding is that Ethereum’s main characteristic is its Turing-completeness; therefore, while Bitcoin permits only simple scripts for verification, Ethereum contracts enable much more complex and computationally demanding tasks. This viewpoint can be challenged.
Ethereum’s main feature is not Turing-completeness; in fact, we have a section in our whitepaper offering the argument that even if we completely stripped away Ethereum contracts’ Turing-complete abilities, it would make minimal difference and a demand for “gas” would persist. To make contracts genuinely statically analyzable, we would need to consider removing the first-class-citizen characteristic (i.e., the fact that contracts can create and invoke other contracts), resulting in Ethereum having very limited utility.
Instead, the central feature of Ethereum is its state – Ethereum accounts can comprise not only a balance and code, but also arbitrary data, facilitating multi-step contracts, long-lasting contracts such as DOs/DACs/DAOs and particularly non-financial blockchain-based applications to flourish. For instance, take into account the following contract:
init: contract.storage[0] = msg.data[0] # Limited account contract.storage[1] = msg.data[1] # Unlimited account contract.storage[2] = block.timestamp # Time last accessed code: ```html if msg.sender == contract.storage[0]: last_accessed = contract.storage[2] balance_avail = contract.storage[3] # Withdrawal cap is 1 finney per second, maximum 10000 ether balance_avail += 10^15 * (block.timestamp - last_accessed) if balance_avail > 10^22: balance_avail = 10^22 if msg.data[1] balance_avail: send(msg.data[0], msg.data[1]) contract.storage[3] = balance_avail - msg.data[1] contract.storage[2] = block.timestamp # Unlimited account has no limitations elif msg.sender == contact.storage[1]: send(msg.data[0], msg.data[1])
This contract is quite simple. It consists of an account featuring two access keys, where the initial key has a withdrawal cap while the second key lacks limitations. You may consider it as a cold/hot wallet configuration, except that there is no requirement to periodically visit the cold wallet for replenishing unless a significant amount of ether is intended to be withdrawn at once. If a message is dispatched with data [DEST, VALUE], then if the sender is the first account, it can transfer up to a specific limit of ether, which gets replenished at a pace of 1 finney per second (i.e., 86.4 ether daily). If the sender is the second account, then the account contract sends the requested amount of ether to the specified destination without any restrictions. Now, let’s examine what costly operations are essential to carry out here, particularly for a withdrawal using the restricted key:
- An elliptic curve verification to confirm the transaction
- 2 storage database reads to obtain the last access timestamp and last withdrawable balance
- 1 storage database write to document the balance modifications that emanate from the sending transaction
- 2 storage database writes to record the updated last access timestamp and withdrawable balance
There are also numerous stack operations and memory reads/writes, though these are significantly faster than database and cryptographic operations, so we will omit them from consideration. The storage database reads can be optimized through caching, while the writes will necessitate several hashes each to rewrite the Patricia tree, making them less straightforward; thus, SLOAD incurs a gas cost of 20, but SSTORE can cost up to 200. Furthermore, the entirety of the transaction is expected to be around 160 bytes, the Serpent code occupies 180 bytes, and the four storage
“`slots utilize 100-150 bytes – therefore, a one-time expenditure of 350 bytes and a 160 bytes bandwidth cost per transaction.
Consider now this contract involving a multisig oracle. The identical tasks will need to be performed, but limited to a few servers making the expense negligible. Yet, when the multisig transaction is transmitted to Bitcoin, if the multisig is 3-of-5, then three elliptic curve verifications will be necessary, requiring 65 bytes per signature alongside 20 bytes for each public key. This means it will amount to approximately 350-400 bytes altogether (also accounting for metadata and inputs). The cost of storing on the blockchain will be around 50 bytes per UTXO (in contrast to a fixed 350 bytes in Ethereum). Therefore, assuming that an elliptic curve verification consumes more time than a few hashes (which it does), the blockchain-oriented method is indeed more straightforward. This scenario is particularly advantageous because it exemplifies how Ethereum is focused on state rather than Turing-completeness: no loops were employed, but the magic of the contract arose from the ability to maintain a live record of the withdrawal limit within the contract.
(Note: adept cryptographers might point out that there exists a specific type of threshold signature which only necessitates a single verification operation even when a large number of oracles are utilized to generate it. Nevertheless, if we were to use a currency with such a feature, we would already be deviating from Bitcoin’s current infrastructure and network effect; in that scenario, why not simply employ the Ethereum contract?)
However, At Times They Are
At other instances, on the contrary, oracles are indeed sensible. The most prevalent scenario likely to appear in practice is that of external data; at times, one might require a financial contract that leverages the value of the US dollar, which cannot be cryptographically ascertained merely by executing a few hashes and measuring ratios. In such situations, oracles are absolutely essential. Another significant circumstance involves smart contracts that are rather challenging to evaluate. For instance, if you are acquiring computational resources from a decentralized cloud computing service, confirming that computations were performed legitimately is not a task that the Ethereum blockchain can handle economically. For the majority of computation types, validating their correctness takes precisely as much time as executing them initially, making occasional spot-checking through, well, oracles the only feasible method to accomplish this. A different cloud-computing application for oracles, although we do not consider them as such in this context, is file storage – you definitely do not wish to back up your 1GB hard drive onto the blockchain.
Another application, previously mentioned, is privacy. Occasionally, you might prefer not to have the particulars of your financial contracts made public, thus conducting everything on-chain might not be ideal. Certainly, you can utilize standard-form contracts, and individuals won’t know that it’s you engaging in a contract for difference between ETH and USD at 5:1 leverage; however, the risk of information leakage remains high. In such situations, it may be prudent to restrict what is executed on-chain and manage the majority of transactions off-chain.
Thus, How Can They Collaborate
We have these two systems: entirely on-chain and partially on-chain, with each possessing its respective strengths and weaknesses. Yet, the real question is, are the two truly merely adversarial? The answer is, as it turns out, no. To support this assertion, here are several specific illustrations:
- SchellingCoin – incentivized decentralized oracles. The SchellingCoin protocol serves as a proof of concept demonstrating the creation of a decentralized oracle protocol that is incentive-compatible: it implements a two-step commitment process, ensuring that oracles do not initially know each other’s responses, followed by an Ethereum contract rewarding those oracles closest to the median. This approach encourages everyone to report the truth since coordinating on a falsehood is considerably challenging. A separately conceived alternative, TruthCoin, achieves a similar outcome for prediction markets with binary results (e.g., did the Toronto Maple Leafs secure the World Cup?).
- Verifiable computation oracles – if the oracles involved are executing moderately computationally demanding code, we can actually transcend the admittedly unreliable and untested economics of the SchellingCoin/TruthCoin protocols. The concept is straightforward. By default, we have M out of N oracles executing the code and casting their votes on the outcomes. However, if an oracle is perceived to have voted incorrectly, that oracle can be “challenged”. At that juncture, the oracle must submit the code to the blockchain, the blockchain verifies the code against a pre-established hash, executes the code, and checks if the outcome aligns. Should the results not match, or if the oracle fails to respond to the challenge, it forfeits its security deposit. The equilibrium in game theory here encourages no cheating whatsoever, as any attempts to deceive would inherently disadvantage another party, which then has an incentive to perform a check.
- Signature batching – one issue I raised with the multisig oracle model above is signature inflation: if three oracles sign each transaction, that’s an additional 195 bytes on the blockchain and three costly verification operations per transaction. Nevertheless, with Ethereum we can act with greater ingenuity – we can devise a unique “oracle contract,” enabling oracles to submit a single transaction comprising a single signature that consolidates multiple votes: [addr1, vote1, addr2, vote2 … ]. The oracle contract will then process the complete list of votes and simultaneously update all the multisig voting pools within it. As a result, a single signature could support an unlimited volume of votes, significantly alleviating scalability issues.
-
Blockchain-based auditing – the notion of oracle-driven computation could actually extend much farther than just the “Bitcoin multisig oracle” (or the Ethereum multisig oracle, for that matter). The extreme would be a scenario where oracles also determine the one element that Bitcoin-based schemes continue to leave for the blockchain to resolve: the sequence of transactions. Should we forgo this requirement, achieving much greater efficiencies becomes feasible via an oracle maintaining a centralized ledger of transactions and state as they arrive, providing a signed record for each new balance sheet whenever a transaction is processed, enabling applications such as microtransactions and high-frequency trading. However, this presents clear trust issues; particularly, what happens if the oracle engages in double-spending?
Fortunately, we can establish an Ethereum contract to resolve this issue. Similar to the verifiable computation illustration mentioned earlier, the concept is that, by default, everything
would operate completely on the oracle, but if the oracle opts to authenticate two distinct balance sheets that stem from incompatible transactions, then those two authorizations can be imported into Ethereum. The contract will confirm the validity of both signatures, and if they are indeed valid, the contract will confiscate the oracle’s collateral. More intricate schemes to address other attack vectors are also feasible.
- Verifiable secure multiparty computation – in situations where you utilize oracles specifically to preserve confidential data, you can establish a protocol where the oracles securely generate a new secret key using multiparty random number generation every 24 hours, sign a message with the previous key to demonstrate to the public that the new key has legitimacy, and subsequently submit all computations conducted with the old key to the Ethereum blockchain for authentication. The old key would be disclosed, yet it would become ineffective since a message transferring ownership rights to the new key is already embedded in the blockchain several blocks earlier. Any misconduct or negligence uncovered in the audit would result in the forfeiture of a security deposit.
The broader fundamental point of all this is that the main purpose of Ethereum is not merely to function as a smart contract platform; it is more broadly to act as a global trustless decentralized computation system, albeit with the drawbacks that it can maintain no secrets and is approximately ten thousand times slower than a conventional machine. The efforts in crafting cryptoeconomic protocols to guarantee that everyday individuals have access to dependable, trustworthy, and efficient markets and institutions are far from complete, and the most thrilling end-user-focused innovations are likely what will be developed subsequently. It is entirely plausible to have systems that utilize Ethereum for one function, an M-of-N oracle configuration for another, and some alternative network like Maidsafe for others; foundational protocols are your servant, not your overseer.
Special appreciation to Vlad Zamfir for contributing some of the concepts behind integrating oracles and Ethereum