Blockchain 5.0 — Fusing DAG ledgers with Smart Contracts
Part 5: Summary
When combing smart contracts with DAGs, we can circumvent the scalability problems of existing smart contract platforms, albeit on the cost of reduced interoperability.
I am working on a Proof-of-Concept that will demonstrate the concept using the best-known technologies of both worlds: Ethereums EVM as smart contracts engine, and IOTAs Tangle as storage. This behaves similar to sidechains, but due to the DAG, everything can be stored on IOTAs mainnet, instead of relying on off-chain storage.
This Proof-of-Concept is a second-layer solution, which will not be able to directly use IOTA as currency, and centralized at the beginning (although this is not a hard limitation).
I will keep you updated here as soon as the source code is publicly available. See you!
F.A.Q.
Q: Will this be implemented with the actual ETH EVM or my own flavored VM?
Short answer: the real ETH EVM.
Long answer: The PyEVM implementation, which is pretty modular. So I extend and monkey-patch this VM to better integrate with IOTA (e.g. to make it compatible with IOTA addresses). But the main goal is to be bytecode-compatible with EVM bytecode (or as close to that as possible).
Or, to better explain the motivation: In a perfect world, you would run your tangle-evm node that exposes a RPC interface that can be used by ethereum clients. Your transactions wouldn’t be stored in the Ethereum mainnet (or any testnet), but on one of arbitrary many chains that live in the Tangle. None of the tools (Remix, web3-DApps) would need to care that this chain is actually on the Tangle, they would just work as usual.
Q: Why not just wait for Qubic, as this project will bring smart contracts to IOTA as well?
Yes, Qubic will have smart contracts as well — which is really cool, and they are great for certain tasks.
But I think having a choice would be good, as qubic is quite different from existing platforms: the smart contracts are not turing-compatible, and behave differently than the many, many contracts that already exist today (function programming style for example) — not that these things are bad, but I think enough reasons for both solutions to coexist. :)
Donation address: JKELRMVXOGDHKUJGIZJZGFBYCNPUXCGRZPPFDFAPLBVWLNKXVG9COTWTYCWIMFYQAZFNBV9YEVVPZFXZWWDQBQSFOC
Part 1: Introduction
Part 2: Relaxations
Part 3: Platforms
Part 4: Implementation
Part 5: Summary
