Blockchain Abstraction and Interoperability 2.0
Shortly after the birth of Bitcoin in 2009, we ushered in an era of so-called “altcoin”, in which people experimented with various ideas to extend Bitcoin. Thousands of cryptocurrencies were created. Some of the altcoins survived, while others disappeared. Among them, the most successful is Ethereum. Why Ethereum? Prior to Ethereum, each time a new blockchain application was proposed, a new “altcoin” was created to implement that particular application. Ethereum ended that cumbersome way of evolution and introduced a generic programming model that allows developers to build any decentralized application on it. Ethereum emancipated developers from the burden of building consensus and p2p network and granted developers the privilege to allocate their precious time to business logic. Ethereum acts like an iPhone comparing to its feature phone predecessors, brings us the Cambrian explosion of DApps.
In retrospect, Ethereum has grown into the most valuable blockchain because it solved thousands of problems systematically while others were trying to solve only one at a time. Ethereum provides a systematic solution by asking the question at a different level - instead of thinking about how to build the next big application, Ethereum asked how to make it easier to build the next 10000 applications - is there a way better than “one application one blockchain”? That is to take a dimension reduction strike against “altcoins”, which results in the birth of a new era, Ethereum’s era. The cost of decentralized application development reduced a lot, DApps boomed. Today, almost all decentralized applications live on Ethereum, they make Ethereum stronger than any other “altcoin”.
A frequently asked question is whether Ethereum is the ultimate form of blockchain or will there be a blockchain X to Ethereum as Ethereum to Bitcoin? What does the next era look like?
Blockchain Abstraction
Ethereum’s key break-through is a generic programming model (or smart contract model, interchangeable in this post) consisting of EVM and Account model on which developers can implement all sorts of application logic. The smart contract model is a middle layer that insulates developers from unnecessary underlying blockchain details and provides high programming flexibility to developers. What Ethereum does is abstraction, as its definition on Wikipedia says:
In software engineering and computer science, abstraction is:
- the process of removing physical, spatial, or temporal details or attributes in the study of objects or systems to focus attention on details of greater importance; it is similar in nature to the process of generalization;
- the creation of abstract concept-objects by mirroring common features or attributes of various non-abstract objects or systems of study – the result of the process of abstraction.
From this point of view, Ethereum is an abstraction of Bitcoin and “altcoins”. Abstraction is an eternal theme of system evolution and had repeated many times before. Back in the early days of programming, we wrote assembly code, then we created high-level languages and compilers that liberated us from machine trivial and focused on more important issues. At first, we managed hardware resources directly in our own program, then we built operating systems as a middle layer and delegated those onerous tasks onto them, later we added hardware virtualization, and applications now live on the cloud. The adolescent Internet had only a few protocol layers such as TCP/IP, then there comes the application layer and we get HTTP, FTP, SMTP, etc. As you can see, examples are everywhere.
That’s why I would argue that new abstraction is the hallmark of evolution and that the next-generation blockchain must be more abstract than its predecessor. The Bitcoin to Ethereum leap was the first blockchain abstraction, and I believe it won’t be the last. As for how the post-Ethereum era might resemble, one should initially think about what can be abstracted further away from Ethereum.
New Abstractions
Ethereum’s generic smart contract model is a step forward from Bitcoin. One direction for further abstraction is to create an even more abstract one based on what Ethereum presents. As we examine the Ethereum model deeper, we can find many specific design choices embedded in it. Here’re some of the most prominent ones:
- Account address. An EOA (Externally Owned Account) is required for a user to initiate a transaction. The address of EOA is the Keccak256 hash of the public key.
- Sender authentication. Ethereum authenticates the sender of a transaction with two specific cryptographic algorithms, Secp256k1 and Keccak256. To create a valid Ethereum transaction, a client (e.g. wallet) must implement Secp256k1 and Keccak256 to sign the transaction. It also means the client needs a secure way to manage Secp256k1 keypairs.
- Cryptographic primitives (algorithms used as basic building blocks in applications). Ethereum’s virtual machine, EVM, hard-coded several cryptographic primitives in it as precompiles, such as ECDSA signature verification and SHA256 hash function for developers’ convenience. Hardcoded precompiles are much more efficient than the same algorithm implemented in Solidity and thus are practical for real-world applications.
- World state structure. Ethereum’s world state is organized as a gigantic Merkle Patricia Tree (MPT) with accounts as leaves. Each account also maintains its own key-value storage as an MPT. MPT is one of many authenticatable data structures.
These technical choices are quite esoteric to non-technical users, but nothing makes them less important than the choice of consensus algorithm or economical parameters. These choices affect Ethereum in every aspect, just like a small tweak to the Planck constant could change our universe drastically. To build a new decentralized ecosystem would akin to creating a new universe, and these design choices are like the physical rules embedded in that universe.
The design choices were made to help Ethereum fulfil its initial goals, but they were not the best choices. For example, the chosen sender authentication algorithm secp256k1 is convenient for designers but posed unnecessary obstacles for using Ethereum in environments without Secp256k1 support. The precompiles selected is a small whitelist which basically omitted the most widely used primitives today. The MPT used in state structure was proven to be very inefficient, exacerbated the state explosion problem and induced difficulties in pricing IO-related EVM opcodes, while mispricing could lead to security problems such as DoS attacks.
The Ethereum community and other new projects have also noticed these problems and have tried different solutions. For instance, Ethereum added useful precompiles and re-priced opcodes via series of hard-forks, Tezos added support for secp256r1 for sender authentication, etc. The problem is that it’s similar to how we tackled application requirements here and there in the “altcoin” era. Furthermore, these design decisions can be more intricate than applications, and usually, no optimal solution exists, we may prefer different options in different cases. Even in the rare cases where the best choice does exist today, there’s no guarantee that it will still be the best tomorrow. A better solution, therefore, is to think at a different level, again - instead of adding new features by the core team coordinated hard-forks, can we create new abstractions and let smart contract developers do whatever they want?
Nervos CKB answered the question and created a new level of abstraction. For example, a CKB transaction is abstract where users and developers are not limited to the default blake2b-secp256k1 authentication, anyone can replace it with blake2b-secp256r1, keccak256-ed25519 or blake2b-sha3-schnorr. CKB-VM is abstract and has zero precompiles in it, even the default cryptographic primitives like hash function blake2b and signing verification secp256k1 are just smart contracts running in the virtual machine. They run in the same environment as smart contracts created by application developers, with no special privileges. The cell model is abstract where a cell is simply storage without any internal structure and its layout is completely left to developers, as we witnessed in sUDT and xUDT. Since CKB is abstract in many regards, developers are granted greater freedoms and new abilities. CKB is an abstraction of Ethereum, just as Ethereum is an abstraction of Bitcoin. Abstraction makes CKB a simpler yet more powerful blockchain and shifts much of the work off-chain, some of which will be done on layer 2. The abstraction of Bitcoin split developers into blockchain developers who work on the underlying blockchain and smart contract developers who build applications. The abstraction of Ethereum will split smart contract developers into system contract developers and application contract developers, while the former will focus on system-level smart contracts, such as cryptographic primitives, lock scripts, and even memory management modules.
The importance of abstraction has been recognized by the Ethereum community recently. If accomplished I think it could make Ethereum more abstract than it is now, gives it an edge over those unable to keep up. Nevertheless, I also doubt that proposals such as account abstraction could attain the same level of abstraction as CKB did, since it would be extremely difficult to introduce radical changes to a running ecosystem, just like it’s impossible to tweak the Planck constant without tearing down the universe. For example, account abstraction will introduce new security complexity to critical modules like transaction pool, as a validator would need to handle arbitrary computation rather than fixed signature verification each time a new transaction is signed.
The other direction of abstraction goes for scalability. Both sharding and layer 2 solutions share a common problem - they change application development in certain ways. For example, it may be completely different to handle cross-shard calls or cross-layer2 transactions from contract calls on layer 1. Layer 2 application developers may also face different smart contract models on different layers (e.g. a UTXO-model layer 2 chain over an Account model layer 1, or vice versa). How to conceal these details and render a smooth experience for application developers as if they were building on layer 1 is still an open question. It’s one of the challenging problems we’re actively working on. The first channel construction on CKB, Generic Payment Channel, is an example under this line of thought. GPC aims to provide a “transparent” scalability layer to UDTs on layer 1 so that any UDT can be channelized from day 1 without any extra effort from developers. In GPC, we abstract the details of the payment channel protocol out from UDT developers. An alternative attempt can be found in our works on Godwoken and Polyjuice, which can be considered as both computation and scalability abstraction on top of CKB.
Interoperability 2.0
Each blockchain abstraction will bring us something new, something we’ve never seen at the previous abstraction levels. The first blockchain abstraction presented us with general programmability and inter-connected decentralized applications, what will the next blockchain abstraction bring us?
Interoperability 2.0 (a concept first mentioned here) is definitely an apple that will grow out on new abstractions. We envisage a digital economy future with multiple permissionless blockchains, permissioned blockchains, and centralized systems. Interoperability allows digital assets to be moved and smart contracts to be called across these independent systems. In recent years, numerous studies / researches on interoperability have been conducted and it is believed that the problem can be solved with an array of basic primitives, such as multi-sig notary, relay and hash-locking.
Although blockchain interoperability is technically possible today, there’re other missing pieces between technical feasibility and the realization of a seamless interoperable digital economy. First, our interoperability initiatives will only create more split networks. Projects like Polkadot and Cosmos have defined each their own standards and attempted to build a multi-chain network around their own “hub”. There’re also parallel efforts building bridges between Bitcoin and Ethereum directly. It’s inconceivable sometime in the future the core teams and communities of these separate networks could come to the table and agree on a common interoperability standard for all to follow. Second but more critically, even if these blockchain networks were perfectly interoperable, lousy interoperation user experiences would still prevent users from using them. From a user’s perspective, if I were a Bitcoin user who wanted to transfer my BTCs to Ethereum to engage in DeFi applications, I have to first run my Bitcoin wallet and then cross-chain, then to use a separate Ethereum wallet. To complete such a cross-chain operation, I had to install two wallet applications, kept two sets of mnemonics and used two addresses. This process itself is very fractious and only applies to two chains. As users want to interact with more blockchains, the more mnemonics/addresses/keypairs they need to manage. This user experience problem not only hinders the adoption of DApps, but also sabotages decentralization, the core value of blockchain, because users would be forced to rely on centralized custody services to avoid all the hassles.
Solving these two problems requires a new type of interoperability, something we call Interoperability 2.0. A blockchain with this new interoperability would be like a “universal hub” which could interact with any other blockchain without being noticed by other blockchains. A “universal hub” must be capable of understanding and executing the protocols of other blockchains, rather than inventing its own and requiring everyone else to learn. A universal hub would be similar to a multilingual individual who can speak other people’ languages so that the hub could talk to everyone and everyone would be willing to dialogue with the hub. In the crypto world, all protocols (the language used by blockchains) are composed of cryptography, which means such a universal hub must support a wide range of cryptographic primitives used in the blockchains we would see today and tomorrow. The universal hub must be able to understand the transactions signed by all kinds of blockchain wallets, allowing users to stick with a single wallet alongside being able to use any applications running on the universal hub.
These requirements of Interoperability 2.0 are exactly what the new abstractions, cryptographic primitives and sender authentication, provided. That’s why an Ethereum user can use his/her Metamask wallet to operate assets or dapps on Nervos CKB today, without any manual settings, without even notice he/she is using Nervos applications. Not only Ethereum users, EOS/Tron/… users can also operate assets or dapps on Nervos CKB. No worries if you find out that your favourite chain is not in the list yet, you can simply create and deploy smart contracts for it (or wait/pay a smart contract developer to do it for you). No pleas to the core team and/or hard fork needed, all can be done with smart contracts.
For applications running on Nervos, they get interoperability 2.0 for free. Thus a Nervos application can be widely accessed by users from every blockchain community, such an application is referred to by us as a Universal Application. As a developer, you can reach to a larger user base than elsewhere by learning how to build applications on Nervos. As a user, all you need to do is to use your current wallet and account to access universal applications on Nervos, no need to install or learn anything new. You may think you’re using an Ethereum or EOS DApp, while the underlying pipeline and infrastructure have been replaced by Nervos. And I believe that’s the way things should be. Like the fact that a user who visits a website doesn’t care whether the website is written in PHP or JAVA, using MySQL or PostgreSQL. Users simply don’t care, rightfully so. We as developers have the responsibility to create abstractions and hide implementation details from users, so we can replace implementations in use with better ones, for a superior and better user experience. Interoperability 2.0 will make the crypto world resemble the Internet of today, and it’s enabled by new blockchain abstractions.
Even better, universal applications can be accessed by a far more audience than blockchain users. The crypto world is a relatively small circle, and we can go much further. Blockchain wallet and account are nothing more than another account/identity system. Yet in the Internet world, numerous established standards for identity/account and authentication exist, such as OpenID, face recognition, fingerprint recognition, etc. With cryptographic primitive and sender authentication abstraction, Nervos CKB can also understand the widely used Internet protocols. Users are able to access universal applications by using browsers and mobile phones, with no need to install any blockchain wallets, generate any keypairs, not even remember any mnemonics. In this way, we cater to the existing Internet ecosystem, rather than creating a completely new one. We wouldn’t require our grandma to learn some magic that she has no idea about. The barriers preventing Internet users from entering the crypto world no longer exist here.
A New Metropolis
Many modern metropolises sprung from being hubs of trade routes or harbours. Venice, New York, Hongkong, Shanghai and Singapore all emerged as highly commercialized cities by virtue of their harbours. GPS, freighters and containers are the interoperate technology we use to shift assets between cities in the industrial age, but now we have crypto assets, blockchains and interoperability 2.0. Better interoperability brings more immigrants, more businesses, and more vitality to cities. Skyscrapers will pop up, cargos will be shipped, assets will be kept, people will stay, and a new metropolis will be born.