Introduction

Cardano Computation Layer

As mentioned previously, there are two components of a transaction: the mechanism to send and record the flow of tokens and the reasons as well as conditions behind moving tokens. The latter can be arbitrarily complex and involve terabytes of data, multiple signatures and special events occurring. The latter can also be remarkably simple with a single signature pushing value to another address.

The challenge behind modeling the reasons and conditions of value flow is that they are immensely personal to the entities involved in the most unpredictable of ways. Lessons from contract law paint an even more problematic picture where the actors themselves might not even be aware that the transaction does not match commercial reality. We generally call this phenomenon "the semantic gap"¹¹.

Why should one build a cryptocurrency chasing an endless layer of complexity and abstraction? It seems Sisyphean in nature and naive in practice. Furthermore, each abstraction embraced has both legal and security consequences.

For example, there are numerous activities online that are universally deemed illegal or scorned such as the trafficking of child pornography or the selling of state secrets. By deploying robust decentralized infrastructure, one is now providing a channel for this activity to occur with the same censorship resistance that normal commercial transactions enjoy. It is legally unclear if the consensus nodes of the network — which have the incentive to become more federated over time to promote efficiency — would be held accountable for the content they host.

Prosecution of Tor operators, the brutal treatment of Silk Road’s operator and the lack of overall legal clarity behind legal protections of protocol participants leaves an uncertain road. There is no lack of imagination of what else a sufficiently advanced cryptocurrency could enable (see the Ring of Gyges). Is it reasonable to force all users of a cryptocurrency to endorse or at least enable the worst acts and conduct of the web?

Unfortunately, there are no clear answers that provide insight to a cryptocurrency designer. It is more about picking a position and defending its merit. The advantage that both Cardano and Bitcoin have is that we have chosen to separate concerns to layers. With Bitcoin, there is Rootstock. With Cardano, there is the Cardano Computation Layer.

The kinds of complex behavior that would enable the acts elaborated previously cannot run on CSL. They require the ability to run programs written in a Turing complete language and some form of gas economics to meter computation. They also require consensus nodes willing to include the transactions in their blocks.

Thus, a functionality restriction could reasonably protect users. So far, most established governments have not taken the position that the use or maintenance of a cryptocurrency is an illegal act. Hence, the vast majority of users should be comfortable maintaining a ledger that is comparable in capability with a digital payment system.

When one wants to extend capability, there are two possibilities. It is enabled by a private collective of likeminded individuals and ephemeral in nature (for example, a poker game). Or, it is enabled by a ledger of comparable capabilities as Ethereum. In both cases, we have chosen outsourcing the events to another protocol.

In the case of a private, ephemeral event, it is reasonable to avoid the blockchain paradigm entirely, but rather restrict efforts towards a library of special purpose MPC protocols that can be invoked when desired by a group of likeminded participants. The computations and activities are coordinated in a private network and reference CSL only as a trusted bulletin board and a message passing channel when necessary.

The key insight in this case is that there is consent, encapsulation of liability and privacy. CSL is being used as a digital commons for users to meet and communicate — like a park would host a private event — but does not provide any special accommodations or facilitation. Furthermore, the use of special purpose MPC will enable low latency interaction without the need for blockchain bloat. Thus, it improves the scale of the system.

Cardano’s research efforts towards this library are centralized at our Tokyo Tech laboratory with some assistance from scientists abroad. We call the library "Tartaglia" after a fellow mathematician as well as contemporary of Cardano and expect the first iteration to be available in Q1 of 2018.

In the second case, one needs a blockchain with a virtual machine, a set of consensus nodes and a mechanism to enable communication between the two chains. We have begun the process of rigorously formalizing the Ethereum Virtual Machine using the K-framework¹² in partnership with a team from the University of Illinois.

There are still unresolved questions about the gas economics proposed by Ethereum and how it relates to work such as Jan Hoffmann et al’s resource aware ML and the broader study of resource estimation for computation. We are also curious about the level of language independence of the virtual machine. For example, the Ethereum project has expressed desire for transition from their current VM to Web Assembly.

The next effort is in developing a reasonable programming language to express stateful contracts that will be called as services by decentralized applications. For this task, we have chosen both the approach of supporting the legacy smart contract language Solidity for low assurance applications and developing a new language called Plutus for higher assurance applications requiring formal verification.

Like the solidity based Zeppelin project, IOHK will also develop a reference library of Plutus code for application developers to use in their projects. We will also develop a specialized set of tools for formal verification inspired by work from UCSD’s Liquid Haskell project.

In terms of consensus, Ouroboros was designed in a sufficiently modular fashion to support smart contract evaluation. Hence, both CSL and CCL will share the same consensus algorithm. The difference is that Ouroboros can be confirmed to permit both permissioned and permissionless ledgers via token distribution.

With CSL, Ada has been distributed by a token generating event to purchasers throughout Asia who will eventually resell on a secondary market. This means that CSL’s consensus algorithm is controlled by a diverse and increasingly more decentralized set of actors or their delegated assigns. With CCL, it is possible to create a special purpose token held by delegates of that ledger who could be regulated entities, thereby creating a permissioned ledger.

The flexibility of this approach allows for different instances of CCL to materialize with different rules about the evaluation of transactions. For example, gambling activities could be restricted unless KYC/AML data is present simply by blacklisting non-attributed transactions.

Our final design focus is on adding trusted hardware security modules (HSM) to our protocol stack. These are two enormous advantages when introducing these capabilities into the protocol. First, HSMs provide massive boosts in performance¹⁴ without introducing security concerns beyond trusting the vendor. Second, through the use of Sealed Glass Proofs (SGP), HSMs can provide assurances that data can be verified and then destroyed without being copied or leaked to malicious outsiders.

Focusing on the second point, SGPs could have a revolutionary impact upon compliance. Ordinarily, when a consumer provides personally identifiable information (PII) to authenticate identity or prove the right to participate, this information is handed to a trusted third party with the hope it will not act maliciously. This activity is intrinsically centralized, the data provider loses control over their PII and is also subject to various regulations based on jurisdiction.

The ability to select a set of trusted attestors and then warehouse PII in a hardware enclave means that any actor with a sufficiently capable HSM will be able to verify facts about an actor in an unforgeable way without the verifier knowing the identity of the actor. For example, Bob is not an US citizen. Alice is an accredited investor. James is a US taxpayer and one should send taxable profits to account X.

Cardano’s HSM strategy will be to attempt implemented specialized protocols over the next two years using Intel SGX and ARM Trustzone. Both modules are built into billions of consumer devices from laptops to cellphones and require no additional effort on the consumer side to use. Both are also heavily vetted, well designed and based upon years of iteration from some of the largest and best funded hardware security teams.

---

Footnotes

11: Loi Luu et al. discuss the gap in their recent paper on Making Smart Contracts Smarter.