As blockchain developers we are presented with new and exciting tools to solve problems that we have struggled with for years. With this new found functionality we are also presented with new sets of challenges to solve. The need to execute code that is considered sensitive. The desire to transfer value without identifying the participants involved. The need to maintain more privacy than a pseudonymous “public” chain like the Bitcoin or Ethereum Blockchain provide. Lack of intelligent tools, frameworks or libraries. Approaches to these challenges range from elegant to out of band hacks that often undermine the value of a blockchain.
I tend to “off brain” some of the harder problems to whatever magic works in the background processes of the brain. What follows is the result of a bit of news that triggered one of these background processes to start returning data. Specifically the acquisition of a unikernel company by Docker.
The “Smart Contract” concept is one that has been around for at least 15 years. It is most popularly realized through a specialized Language and Virtual Machine designed for the Ethereum project. These specialized contracts, while easy to write, do require developers to learn new languages. Solidity, a specialized object oriented programming language designed for writing contracts for the Ethereum project, is very young and doesn’t have the bells and whistles provided by other higher level languages. The more generalized languages are considered greedy when it comes to resources and time. Greedy code, greedy interpreters and greedy operations would be devastating if executed synchronously within the group execution model blockchains require for group consensus.
One limitation of smart contract systems like the Ethereum Virtual Machine (EVM) is the inability to reach outside the closed environment of the blockchain executing the contract. This severely limits the type of applications that a blockchain can execute. Any outside information has to be provided to the chain from an outside actor. When a single outside Oracle provides data, the group consensus is lost. In other words the chain for the most part has to trust that arbitrary information provided to the blockchain is accurate and cannot be verified by the chain.
An “Oracle” is a particular agent that is trusted by the participants in the blockchain. It can be something like a known API like the Twitter API for example. It can be some other blockchain with built in mechanisms to provide provably accurate information. Or it could be a rogue service made to appear legitimate. Since we can’t rely on the distributed trust of the blockchain we are ultimately left to trust a central authority.
The “Smart Oracle” takes the concept of the Oracle and introduces a model whereby untrusted or complex code (contracts) written in arbitrary languages is executed by the oracle, or collection of oracles. Smart oracle systems like Codius solve many of the issues described within this paper. Developers are able to build decentralized applications that can leverage both an underlying blockchain and the power of languages such as node to provide a feature rich set of development resources that has been up till now unattainable within a blockchain. Code is executed on participants systems using an isolated execution environment. The smart oracle idea also creates a secondary market of sorts that allows participants to monetize their resources by charging for execution of code.
We propose a new type of Oracle, the “I/Oracle”. An enhancement on the smart oracle model. An Introspection Oracle or I/Oracle is similar to the smart oracle but subtly different. Execution of some code is marshaled off the blockchain into a newer technology known as a “Unikernel”. This marshaling is facilitated through the a specialized smart contract that stores uncompiled, compiled, obfuscated or encrypted sensitive contract code on-chain. Another contract is used to handle permissioning. Every full node should have the ability to launch a variety of unikernel’s. Often times only nodes with permission to execute the generalized code will be allowed to do so. We will touch on this later, along with follow up posts.
A “Unikernel” provides an isolated execution environment similar to docker, but is another beast entirely. Where docker is a layered Virtual Machine, a Unikernel contains truly the minimal amount of an OS to function. A unikernel has been described as an application that along with the native libraries required to run, also includes the minimal kernel operations necessary to run. A unikernel can be compiled into a native binary that can run on bare metal and does not necessarily require an Operating System and virtualization to function. For this new distributed architecture that us as blockchain developers are building, the unikernel provides efficiencies beyond even native applications running within a traditional operating system. Unikernels have been demonstrated as small as 5mb that can boot in less than 20ms. The security of unikernels is a mixed bag. Unikernels are a newer technology and have not been proven to battle hardened. On the other hand, they remove most of the attack surface required by a hacker / malware to cause damage.
One condition that I/Oracle’s aim to change is the decoupled nature of oracles and smart oracles. The proposed way to on-chain more of the contract execution and leverage the full power of the blockchain is to provide a contract system that allows the return values attained from unikernel execution to be reported back to the blockchain that spawned them. Consensus rules can be written in the specialized language of the blockchain (solidity in the case of Ethereum). By writing consensus rules on-chain we allow all participants, even if they weren’t involved in the execution, the opportunity to have a consensus on the returned values.
To put it all together, the I/Oracle model is comprised of a contract that can accept generalized execution requests along with any data needed to execute the generalized code, a service that can monitor transactions or contract executions internally (or externally) that will spawn the correct unikernel to allow execution, and a contract to accept return values of unikernels (consensus or reporting thresholds written into the contract)
One exciting thing this proposed model provides is the ability to now support long execution times. By allowing I/Oracles to report to the chain we introduce an on-chain mechanism that can span an arbitrary number of blocks (time) essentially creating a blockchain backed distributed general computer. This allows for a familiar elastic cloud like environment while preserving the group computation & trustless benefits of a blockchain. An I/Oracle could be initiated that can analyze a large dataset or other computation heavy work without introducing any lag into the processing of blocks by the blockchain. This also offers value transfer / instant settlement to the entirety of the software development ecosystem. General applications can monetize in new ways, operate autonomously, earn value and pay fees just like solidity and other specialized contract based applications.
Many other distributed ledger technologies being built are focusing on this area of blockchain computation. Tendermint for example is contemplating using Docker to isolate contract execution. Ethereum discusses another way to connect chain state to off chain processes. Tal Serphos discusses a model to facilitate blockchain backed computation.
One such use of the I/Oracle could be to protect sensitive application code from prying eyes. Another use could be to prevent analytics or data mining of a company’s financial transactions. Another use might be to hide ability to tie customer behavior to specific agents. While the spirit of blockchain technology is transparency, the only way this type of technology can be adopted is if the agents adopting it have the choice of who they share their data with.
One could imagine a key exchange facilitated by the blockchain, initiated by an agent requesting information from an encrypted contract. Nodes with permissions (and private keys) would spawn unikernels, decrypt the contract code, execute the code, encrypt the results in a way that only the requestor can read them. Each unikernel would report back their piece of the keyshare along with a hash of the result and the encrypted copy of the result. The contract that the unikernels report back to can still meet consensus because result hashes should match without revealing the contents of the encrypted result. The requester can trust the contract, or using the provided keys, complete the diffie hellman exchange, compute the decryption keys and read each encrypted result. (2 layer consensus can prove participants didn’t just witness the hash returned by other unikernels and fake an agreement)
A twist on this model might allow all nodes to participate in the unikernel group execution / consensus would be for the requester to only encrypt specific values in a request and utilize any number of Homomorphic Encryption libraries to compute over these encrypted values. (example: get the encrypted balance of an account, add the encrypted value specified in the request to the encrypted balance, resulting in an encrypted balance that can still meet consensus)
While the privacy use-case of the I/Oracle is not fully worked out, the I/Oracle provides us with one more tool to aid in solving these new problems. There is nothing to prevent the installation of a unikernel + necessary contracts on most public chains available today.
Shannon Code — Chief Architect — Loyyal
Christopher Franko — Blockchain Scientist — Loyyal
Reprinted with permission from: Loyyal Medium Blog