Blockchain Abstraction and Interoperability 2.0

The birth of Bitcoin in 2009 ushered in an era of “altcoins”. Thousands of cryptocurrencies have been created; various ideas have been experimented with to extend Bitcoin. Some altcoins survived, while others disappeared. Among them, the most successful is Ethereum.

Why Ethereum? Before Ethereum, each time a novel blockchain application was proposed, a new altcoin was created to implement that particular application. Ethereum ended this cumbersome process and introduced a generic programming model that allows developers to build any decentralized applications on top of it. Ethereum freed developers from the burden of developing consensus and building peer-to-peer networks, allowing them to focus more on business logic. Like iPhones to their feature phone predecessors, Ethereum brings us the Cambrian explosion of decentralized applications (DApps).

What made Ethereum the most valuable blockchain among its peers? Because Ethereum solved thousands of problems systematically while others projects were trying to solve 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, it asked how to make it easier to build the next 10000 applications: Is there a better solution than “one application, one blockchain”? Following this line, Ethereum eventually succeeded by taking a dimension reduction strike against altcoins, which results in the birth of Ethereum’s era. DApps boomed as the cost of development dropped. Today, almost all DApps live on Ethereum, making Ethereum stronger than any other altcoin.

A frequently asked question is whether Ethereum is the ultimate form of blockchain. Will there be a new blockchain to Ethereum as Ethereum to Bitcoin? If so, what will the next era be like?

Blockchain Abstraction

Ethereum’s key breakthrough is its “generic programming model”, which this article interchangeably refers to as the “smart contract model”. This model consists in the Ethereum Virtual Machine (EVM) and the Account Model. It allows developers to implement all sorts of application logic. As the middle layer, the smart contract model insulates developers from unnecessary underlying details and provides high programming flexibility.

Ethereum’s innovation consists in its abstraction. On Wikipedia, it is defined as follows:

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 of a higher abstraction level than Bitcoin and altcoins. Abstraction is an eternal theme of system development and has been repeated throughout the evolution process. In the early days of programming, we wrote assembly code. Then we created high-level languages and compilers that liberated us from the trivialities of the machines and focused on more critical issues. At first, we managed hardware resources directly in our own program, then we built operating systems as the middle layer and delegated those laborious tasks. Later, we added hardware virtualization and applications which are now live on the cloud. The earlier Internet had only a few protocol layers such as TCP/IP. Then came the application layer and we got HTTP, FTP, SMTP, etc. As you can see, those examples are countless.

That’s why I would argue that new abstraction is the hallmark of evolution, and the next generation of blockchain must be more abstract than its predecessors. The jump from Bitcoin to Ethereum was the first abstraction of blockchain, and I don’t think it will be the last. So, how the post-Ethereum era might look like? Just think about what we can further abstract from Ethereum.

New Abstractions

Ethereum’s generic smart contract model is a step forward from Bitcoin. One approach to further abstraction is to create an even more abstract model based on what Ethereum presents.

Let’s examine Ethereum more closely. We can find many embedded specific designs. These are the places where new changes begin. 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 using two specific cryptographic algorithms, secp256k1 and seccak256. To create a valid transaction, a client (a wallet) must implement secp256k1 and keccak256 to sign the transaction. This also means that the client needs a secure way to manage Secp256k1 key pairs.
Cryptographic primitives These primitives refer to the algorithms used as basic building blocks in applications. To make things easier for developers, Ethereum’s virtual machine hard-coded several cryptographic primitives as precompiles, such as ECDSA signature verification and SHA256 hash function. Because hardcoded precompiles are much more efficient than the same algorithm implemented in Solidity, they are more practical for real-world applications.
World state structure Ethereum’s world state is organized as a giant Merkle Patricia Tree (MPT) with accounts as leaves. Each account also maintains its own key-value storage as an MPT. The MPT is one of many authenticatable data structures.

These technical considerations are quite esoteric to non-technical users, but they are in no way less important than the choice of consensus algorithm or economic parameters. Building a new decentralized ecosystem is tantamount to creating a new universe, and the design decisions can be compared to the physical rules embedded in the universe. These choices affect Ethereum in every way, just as a small tweak to the Planck constant can drastically change our universe.

The design choices were made to help Ethereum achieve its initial goals, but they were not necessarily the best. For example, the sender authentication algorithm secp256k1 is convenient for designers but it sets unnecessary obstacles for users operating in environments without secp256k1 support. The precompiles previously selected are a small whitelist that excludes the most widely used cryptographic primitives today. The MPT used in the state structure was proven to be inefficient. It exacerbates the state explosion problem and leads to difficulties in pricing IO-related EVM opcodes. The mispricing could lead to security problems such as DoS attacks.

The Ethereum community and other new projects have noticed these problems and experimented with various solutions. For instance, Ethereum has added widely used precompiles and repriced opcodes via a series of hard-forks. Tezos has added support for secp256r1 for sender authentication. However, these tweaks are ad hoc adjustments that miss the picture of the system as a whole. It is similar to how we tackle application requirements in altcoins. Furthermore, these ad hoc decisions are more complicated than the applications themselves, and, in most cases, there is no optimal solution available. We may prefer different options in different cases. Even in the rare cases where the best solution does exist today, there is no guarantee that it will still be the best tomorrow.

To get a better solution is to think at a different level. Again, instead of adding new features through hard-forks coordinated by core team members, can we create new abstractions that give smart contract developers more flexibility?

Nervos’ Approach

Nervos Common Knowledge Base (CKB) answered this question and created a new level of abstraction. Abstraction makes CKB a simpler yet more powerful blockchain that can provide developers with greater freedom and new possibilities. Let me illustrate this from three aspects: transaction, virtual machine, and account model.

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’s virtual machine, CKB-VM, is abstract without precompiles. Even the default cryptographic primitives, like the blake2b hash function, and the signing verification secp256k1 are just smart contracts running on the virtual machine. They run in the same environment as the smart contracts created by developers and have no privileges.
CKB’s account model, the Cell Model, is also abstract. A cell is a simple storage unit without any internal structure. A Cell’s layout is completely left to its developers, as we have seen with sUDT and xUDT .

CKB is an abstraction of Ethereum, just as Ethereum is an abstraction of Bitcoin. The abstraction of Bitcoin splits developers into two groups: the blockchain developers who work on the underlying infrastructure; the smart contract developers who build applications. The abstraction of Ethereum will further split the smart contract developers into two groups: the system contract developers and the application contract developers. The former group focuses on system-level smart contracts, such as cryptographic primitives, lock scripts, and even memory management modules.

The importance of abstraction was recently recognized by the Ethereum community. If their designs are successfully realized, Ethereum can become even more abstract, giving it an advantage over those who failed to keep up. Nevertheless, it is questionable whether their proposals can reach the same level of abstraction that CKB aims to achieve. Because it would be extremely difficult to introduce radical changes to a running ecosystem, just like it is impossible to tweak the Planck constant without tearing down the universe. Take Ethereum’s account abstraction as an example. It will introduce a new security complexity to critical modules such as the transaction pool, because each time when a new transaction is signed, a validator has to perform an arbitrary computation instead of a fixed signature verification.

The other direction of abstraction is towards scalability. Both sharding and Layer 2 solutions share a common problem — they change application development in certain ways. For example, handling cross-shard calls or cross-layer2 transactions may be completely different from handling contract calls on Layer 1. Application developers on Layer 2 may also face different smart contract models on different layers (e.g., a UTXO-model Layer 2 chain over an Account model Layer 1 chain, or vice versa). How to keep these details unnoticed and create a smooth experience for developers as if they were working on Layer 1? This is an open question, and also one of the most challenging problems we are actively working on.

CKB’s solution for a higher abstraction level from the aspect of scalability is the Generic Payment Channel (GPC), the first channel construction built on CKB. In GPC, we abstract the details of the payment channel protocol from UDT developers. GPC aims to provide a “transparent” scalability layer for UDTs on Layer 1, so that developers can channel any UDT from day one without extra effort. An alternative attempt is in our works on Godwoken and Polyjuice, which can be considered as an abstraction of both computation and scalability on CKB.

Interoperability 2.0

Each blockchain abstraction will bring us something we have never seen before at the previous abstraction levels. The first blockchain abstraction Ethereum has presented us with general programmability and inter-connected decentralized applications. What will the next blockchain abstraction bring us?

Interoperability 2.0, a concept we mentioned here for the first time, is the fruit of new abstractions. We envisage a future of digital economy with multiple permissionless blockchains, permissioned blockchains, and centralized systems. In this picture, interoperability allows digital assets to be moved and smart contracts to be called across these independent systems. In recent years, numerous studies and researches on interoperability have been conducted. 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 are other gaps 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 Cosmo s have each defined their standards and attempted to build a multi-chain network around their own “hub”. There are also parallel efforts to build bridges directly between Bitcoin and Ethereum. It is inconceivable that in the future the core teams and communities of these separate networks will eventually come to the table and agree on a common interoperability standard for all to follow.

Second, and more importantly, even if these blockchain networks were perfectly interoperable, unpleasant user experiences would still prevent users from interacting with 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 cross-chain, then use a separate Ethereum wallet. To complete such a cross-chain operation, I had to install two wallet applications, keep two sets of mnemonics, and use two addresses. This process itself is fractious and only applies to two chains. As users want to interact with more blockchains, the more mnemonics/addresses/keypairs they need to manage. Such user experience problem not only hinders the adoption of DApps, but also sabotages decentralization, the core value of blockchain. This is because users would be forced to rely on centralized custody services to avoid all the hassles.

These two problems cry out for a new interoperability solution, which we call Interoperability 2.0. A blockchain with this new interoperability would be a “universal hub” that 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 it. A universal hub would be similar to a multilingual speaker who masters other languages, so that the hub can talk to everyone and everyone is willing to communicate with the hub. In the crypto world, all protocols (the language used by blockchains) are composed of cryptography, which means that such a universal hub must support a wide range of cryptographic primitives used in the blockchains of today and tomorrow. The universal hub must be able to understand the transactions signed by all types of blockchain wallets, so that users can keep a single wallet while accessing any applications running on the universal hub.

These Interoperability 2.0 requirements 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, or even without noticing he/she is using Nervos applications. Not only Ethereum, users from EOS, Tron, etc., can also operate assets or DApps on Nervos CKB. Do not worry if you find that your favorite chain is not yet on the list. You can simply create and deploy smart contracts for it, or wait, or pay a smart contract developer to do it for you. There is no need for a hard fork or the core team’s approval. All can be done with smart contracts.

For applications running on Nervos, interoperability 2.0 is free. So a Nervos application can be widely accessed by users from any blockchain community. We call such an application a Universal Application. As a developer, you can reach a larger user base than anywhere else by learning how to build applications on Nervos. As a user, you only need to use your current wallet and account to access universal applications on Nervos, without installing or learning anything new. You may think that you are using an Ethereum or EOS DApp, while the underlying pipeline and infrastructure have been replaced by Nervos. And I believe that’s the way the future blockchain should be. It's like a user who visits a website that does not care whether the website is written in PHP or JAVA, uses MySQL or PostgreSQL. Users don’t care. And rightfully so.

Our job as developers is to create abstractions and hide implementation details from users. In this way, we upgrade the current implementations to create a better user experience. Interoperability 2.0 will make the crypto world resemble today’s Internet. And this is realized by the new blockchain abstractions.

Even better, universal applications can be accessed by a much wider 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. However, in the Internet world, there are numerous established standards for identity/account and authentication, such as OpenID, face recognition, fingerprint recognition, and more. With cryptographic primitive and sender authentication abstraction, Nervos CKB can also understand those widely used Internet protocols. Users can access universal applications via browsers and mobile phones, without installing blockchain wallets or generating keypairs, not even writing down any mnemonics. In this way, we cater to the existing Internet ecosystem rather than creating a completely new one. We would not ask our grandmas to learn some magic tricks that she knows nothing about. The barriers that prevent Internet users from entering the crypto world will no longer exist.

New Metropolises

Many modern metropolises sprung from being the intersections of trade routes or harbors. Venice, New York, Hong Kong, Shanghai, and Singapore have all emerged as highly commercialized cities thanks to their harbors. GPS, freighters, and containers are the interoperating technologies we used in the industrial age to move assets between cities. Now we have crypto assets and blockchains. Just like before, improved interoperability will attract more businesses and immigrants, bringing more vitality to the cities. New metropolises will arise.

✍🏻 Witten by Jan Xie

Other articles that you might like: