Blockchain 5.0 — Fusing DAG ledgers with Smart Contracts
Part 4: Implementation
We know how our ledger structure can be structured for smart contract support, now we will discuss how a concrete implementation in the Tangle can look like.
First, let’s talk about the drawbacks of this approach.
As the contracts live independently in their own chains, no direct interactions between them will be possible. Instead of enforcing this strictly, we can define “namespaces” as grouping of dependable contracts (similar to Sharding). This means that CryptoPenguins, and every other App that depends on them, can be in the same namespace. Several approaches to get interoperability between different blockchains are currently researched, and those solution could be applied here as well. Also, asynchronous calls between different namespaces could be a worthwhile topic for future research.
This is also a second-layer solution on top of the Tangle, and therefore unfortunately can’t directly use IOTA as currency (because IOTA nodes don’t understand the EVM protocol, and e.g. could not transfer money out of smart contracts). Each app would therefore need to introduce its own Token.
Another important aspect is how consensus will be achieved.
We can draw parallels to the infamous IOTA Coordinator here. For our first Proof of Concept this will be an centralized service, appropriately called EVM coordinator, which periodically issues milestones (like blocks in Ethereum that would be mined). These milestone blocks link to the transactions included in that particular block (which users previously attached arbitrary in the Tangle), and therefore determine the execution order of the transactions.
The big advantage of our DAG is that there can be indefinitely many of those coordinators — so a huge traffic of transactions in one DApp doesn’t influence any other, unrelated ones.
While for now centralized — think of a Proof-of-Authority-type of network, solutions exist to achieve a more decentralized consensus, and can be implemented after further research (notice again the similarities to the Coordicide).
Several difficulties also need to be overcome when developing the Proof-of-Concept.
Ethereum and IOTA are based on vastly different cryptographic principles. While Ethereum uses fairly standard and widespread cryptographic functions, IOTA decided to roll out their own crypto — e.g. by using the quantum computing-resistent Winternitz one time signature scheme (W-OTS). We want to use as many of those fundamentals of IOTA as possible.
Therefore our transactions will be unsigned EVM messages, and the signature should be handled by some IOTA-specific library. When looking for possible message stream libraries, many many different projects can be found: The “official” Masked Authenticated Messaging (MAM) library of the IOTA Foundation, Mam Lite, MAM Ultra Lite and Random Access Authenticated Messaging (RAAM).
Our ideal solution would be a library, that opens a public message channel (the EVM transactions should be publicly readable and verifiable), with some fixed channel ID (to uniquely identify the sender among many transactions), signatures (W-OTS; preferably by generating a large merkle tree in advance, and revealing parts of it with every transaction — like the IOTA coordinator does), and index-based access of the messages in the channel (for performance reasons and as substitution for the nonce in EVM messages).
Unfortunately no single solution offering all of those features can be found — while e.g. RAAM offers index-based access and pre-generated merkle signing trees, it does not have a public mode.
As the other solutions seem fairly similar, we settled for MAM — as this is the commonly used framework for streams — , but want to revisit this decision in future (especially when the successor MAM+ gets released).
This means our unsigned EVM (RLP-encoded) message will be converted from bytes to trytes, and encapsulated into a signed MAM message.
Part 1: Introduction
Part 2: Relaxations
Part 3: Platforms
Part 4: Implementation
Part 5: Summary
