Blockchain abstraction and interoperability 2.0

2021-03-24 17:15

Read this article in 31 Minutes

Interoperability 2.0 could make the cryptocurrency world like the Internet is today, and this would require a new blockchain abstraction.

原文标题：《区块链抽象和互操作性 2.0 》

Original source: Nervos

After Bitcoin was born in 2009, we soon entered the era of so-called "shanzhai coins". Many ideas have been developed and experimented with, and thousands of cryptocurrencies have sprung up. Some of the new cryptocurrencies survived, while others quickly disappeared from view. One of the most successful is Ethereum. Why Ethereum?

Before Ethereum, every time someone launched a new blockchain application, a new "copycat currency" was created to implement that application. Ethereum ended this tedious approach to innovation by introducing a common programming model on which developers could build any decentralized application. Ethereum has freed developers from the burden of writing consensus code and building peer-to-peer networks, allowing them to devote more valuable time to business logic. Ethereum is to other "shanzas" what the iPhone is to its feature phones. Fearers, we started the Cambrian explosion of DAPP.

Looking back on this history, it is easy to understand why Ethereum has evolved into the most valuable blockchain -- solving thousands of problems at a time, in a systematic way, while other projects were solving one problem at a time. And the way Ethereum provides a systematic solution is by solving the problem at a different level: not just answering how to build the next app, but how to more easily build the next 10,000 apps -- is there a better way than "one app, one chain"? Such a dimensional-reducing attack on other "copycats" [2] opens a new era of Ethereum. Because development costs have fallen dramatically, dApps have flourished. Almost all dApps now run on Ethereum, making Ethereum a cryptocurrency leader.

The question is often asked: Will Ethereum be the final form of blockchain? Or is there going to be a new blockchain that will be to Ethereum what Ethereum was to Bitcoin? What will the next era look like?

Blockchain abstraction

Ethereum's major breakthrough is a common programming model (also known as a smart contract model, interchangeable in this article) consisting of EVM and account models, on which developers can implement various application logic. The smart contract model is an intermediate layer that isolates developers from the underlying details of the blockchain that applications don't need to care about, while at the same time giving developers great programming flexibility. What Ethereum does is abstract, as the Wikipedia definition of abstract [3]‍& NBSP; Says:

In software engineering and computer science, abstraction refers to:

The process of ignoring physical, spatial, or temporal details or properties of an object or system in order to focus only on more important details. It is essentially similar to the generalization process;

To create abstract concept objects by copying common features or attributes of various non-abstract objects or systems (the result of an abstraction process).

Seen from this perspective, Ethereum is an abstraction of Bitcoin and so-called "copycats." Abstract is an eternal theme of system evolution, which has happened many times in history. In the early days of programming, we could only write assembly code to deal directly with machines. Later, higher-level programming languages and compilers were created, freeing us from the minutia of machines and focusing on the more important issues.

At first, we managed the hardware resources directly within our own programs, and then we built the operating system as an intermediary to handle the heavy lifting for us. Later on, we virtualized the hardware so that the application could run in the cloud. In the early days of the Internet, there were only a few layers of protocols, such as TCP/IP, and then there was the application layer, which led to HTTP, FTP, SMTP and so on. As you can see, abstract examples abound.

So what I'm saying is that new abstractions are a sign of evolution, and the next generation of blockchains must be more abstract than the last. The leap from Bitcoin to Ethereum is the first blockchain abstraction, and I believe the process of abstraction will not end there. If we want to know what the post-Ethereum world will look like, we should first consider what can be further abstracted from Ethereum.

New abstract

Ethereum's general-purpose smart contract model is a big step forward over Bitcoin. One direction to further abstraction is to create a more abstract model based on the Ethereum smart contract model. If we dig deeper into the Ethereum model, we find that it incorporates a number of specific design choices, the main ones being:

The account address. The user needs to initiate the transaction via an EOA (external account). The EOA address is the of the public key; Keccak256 (a specific hash algorithm)

The hash value.

Sender authentication. Ethereum uses two specific cryptographic algorithms, SECP256K1 and Keccak256, to authenticate the sender of the transaction. To create a valid Ethereum transaction, a client (such as a wallet) must implement the SECP256K1 and Keccak256 algorithms to sign the transaction. This also leads to the need for a secure way for clients to manage the SECP256K1 key pair.

Cryptographic primitives (a class of algorithms used as an underlying component). For developers' convenience, specific cryptographic primitives are hard-coded into EVM (Ethereum Virtual Machine) as precompiled contracts, such as ECDSA signature verification and SHA256 hash functions. The same algorithm that is hardcoded into EVM is much more efficient than implementing it in Solidity, and thus gains utility.

World state structure. The world state of Ethereum is a giant Merkle Patricia Tree (MPT), where accounts are leaves. Each of these accounts also maintains its own internal key-value database in the form of MPT. MPT is one of many options for verifying data structures.

To a user with a non-technical background, these design choices may seem obscure, but they are as important as the choice of consensus algorithms or economic model parameters. These choices affect every aspect of Ethereum, just as they do Planck's constant. A little tweaking would also make a huge difference to our universe. Building a new decentralized ecology is like building a new universe, and these design choices are like the laws of physics set in that universe.

These design choices were made to help Ethereum achieve its original goals, and in hindsight they were not optimal choices. For example, the sender authentication algorithm SECP256K1 may be a natural choice for a designer, but in environments where SECP256K1 is not supported [6]. It creates unnecessary obstacles; By embedding precompiled contracts in a small whitelist, most of the widely used cryptographic primitives are excluded from application; The MPT used in the state data structure also proved to be very inefficient. [J]. The state explosion problem also leads to the EVM opcodes associated with IO [9] Pricing is difficult, and improper pricing can lead to security issues such as DoS attacks.

The Ethereum community and other new protocols have also taken note of these issues and tried different solutions. For example, Ethereum uses a series of hard forks to add more useful precompiled contracts and reprice opcodes; Tezos added SECP256R1 as the new sender authentication algorithm, and so on.

The problem is that this is no different from the way people used to solve app needs in the shanzhai era. To make matters more troubling, these design choices can be more complex and difficult to understand than the application, and often there is no optimal solution. In different situations, there may be different optimal solutions. Even in the rare cases where there is a general optimal solution, there is no guarantee that the best choice today will be the same in the future. So, it's better to think again at a new level: instead of continuing to add new functionality through hard forks that require coordination from the core team, can we create new abstractions and give smart contract developers the freedom to do so?

Nervos CKB answers this question and creates a new abstractionIn the hierarchy. For example, CKB transactions are abstract because users and developers are not limited to using the default BLAKE2B-SECP256K1 validation algorithm, anyone can replace it [10]. Other methods such as ake2B-secp256r1, keccak256-ed25519, or blake2B-sha3-schnorr; CKB-VM Is abstract, which does not contain any pre-compiled contracts, even as a hash function Blake2b and signature verification algorithm Secp256k1 such default cryptography primitive also only in a virtual machine running intelligent contract, in other words, these cryptographic primitives and application developers to create intelligent contracts in the same environment, do not have any privileges; The Cell model is abstract, where each Cell is simply a data storage space without any internal structure, and its layout is entirely up to the developer, as we did at sUDT[11] And & have spent xUDT[12] As you can see.

Because CKB is abstract in many ways, developers are given more freedom and new capabilities. CKB is an abstraction of Ethereum, just as Ethereum is an abstraction of Bitcoin. The abstraction makes CKB a simple yet powerful blockchain and moves a lot of work down the chain (including Layer 2). The result of Ethereum's abstraction of Bitcoin is to divide developers into two parts: blockchain developers who focus on the underlying blockchain, and smart contract developers who build applications.

CKB's abstraction of Ethereum also predictably divides smart contract developers into system contract developers and application contract developers, with the former focusing on system-level smart contracts such as cryptography primitives, Lock Script, and even memory management modules.

Recently, the Ethereum community has recognized the importance of blockchain abstraction and proposed some related improvements [13]. If these improvements are implemented, I think it will make Ethereum more abstract than it is today, and further distant from other projects that can't do this. However, I don't think these proposals for blockchain abstraction will bring Ethereum to the same level of abstraction as CKB, because it would be extremely difficult to make such a low-level change to a functioning ecosystem, just as we can't change Planck's constant without ruining the universe. For example, account abstraction introduces a new security complexity to important modules such as trading pools -- where the verification node needs to handle arbitrary calculations every time a new transaction is signed, rather than fixed signature verification.

The abstraction can also start with extensibility. The problem with sharding and Layer 2 solutions is that they change the way the application is developed in some way. For example, cross-shard calls [14] Or a transaction across Layer 2 May be handled completely differently from a contract call on Layer 1. Layer 2 application developers may also encounter different smart contract models at different layers (for example, Layer 1 has an account model, Layer 2 has a UTXO model, or vice versa). How can we mask these details and provide a smooth development experience for app developers that is at Layer 1? The jury is still out on that, and it's one of the things we're actively challenging.

The first channel design on CKB,Generic Payment Channel (GPC), is built along this line of thought. The GPC is designed to provide a "transparent" performance extension Layer for UDTs (user-defined tokens) on Layer 1, so that any UDT can be "channels" from birth without the UDT developer doing anything else. In GPC, we abstract away the details of the payment channel protocol for the UDT developer.Godwoken and Polyjuice Is another attempt by us. The two solutions can be considered as Extensibility and computational abstraction on CKB.

Interoperability 2.0

Each blockchain abstraction level brings us something new, something that we have never seen at the previous abstraction level. The first blockchain abstraction brought us universal programmability and interconnected decentralized applications. What will the next blockchain abstraction bring us?

Interoperability 2.0 (I first mentioned this concept at Wanxiang Blockchain 2020) will be one of the fruits of the new level of abstraction. Our vision for the future of the digital economy is one in which public chains, licensing chains, and centralized systems coexist. With interoperability, we can move assets and invoke smart contracts between independent systems. In recent years, people have carried out experiments. A lot about interoperability [16] [18] NBSP; , and believes that this problem can be solved with a number of interoperable basic primitives, such as multi-signature notarization, relay, and hash locking.

While blockchain interoperability is now technically possible, there are missing links to a digital economy with seamless interoperability.

First, current attempts at interoperability are only leading to greater network fragmentation. Polkadot[19] And & have spent Cosmos[20] And others have defined their own standards and are trying to build a multi-link network around their own "Hub". There are also projects that try to build direct Bridges, such as a direct cross-link between Bitcoin and Ethereum. It's hard to imagine the core teams and communities of these independent networks ever sitting down together and agreeing on an interoperability standard that everyone adheres to.

Second, and more importantly, even if there is perfect technical interoperability between these blockchain networks, users will still be discouraged by a poor interoperability experience. From a user's point of view, if I'm a Bitcoin user and want to transfer my Bitcoin to Ethereum to participate in the Defi app, I have to first run my Bitcoin wallet, initiate a cross-chain transaction, and then use another Ethereum wallet. To complete a cross-chain operation, I had to install two wallet apps, store two sets of mnemonic words, and use two addresses. The process itself is very complex and only applies to two blockchains. If users want to interact with more blockchains, they must manage more mnemonic/address/key pairs. UX issues not only prevent the widespread adoption of dApps, but also undermine decentralization -- the core value of blockchain -- because users have to and will choose centralized services to avoid all this trouble.

To solve these two problems, we need a new kind of interoperability, which we call Interoperability 2.0. Blockchains with this new type of interoperability act as a "world wide port of exchange" that interoperates with other blockchains without their awareness. To do this, WorldWide Switchport must be able to understand and implement the protocols of other blockchains, rather than creating its own and requiring other chains to learn from it. It's like a "linguist" who learns and speaks someone else's language on his own initiative, so that he can communicate with people who speak a different language, and who are more likely to communicate with him.

In the cryptocurrency world, all protocols (that is, the language used by the blockchain) are constructed from cryptographic techniques. This also means that the "WorldWide Exchange" must support a wide range of cryptographic primitives, whether they are used in blockchains now or in the future. In addition, the World Wide Exchange also needs to be able to understand the transactions signed by various wallets, allowing users to use any wallet (only one wallet is required) and all the applications running on the World Wide Exchange.

These requirements for Interoperability 2.0 can be addressed with the new abstractions, cryptographic primitives, and authentication mentioned above. This is why Ethereum users can manipulate assets and dApps on Nervos CKB using the MetaMask wallet. You don't have to do any manual setting, and you don't even know you're using the Nervos app. Not only Ethereum users, but users of EOS, TRON, and other blockchains can also manipulate assets or dApps on Nervos CKB [22]. If your favorite blockchain isn't on the current support list, don't worry, you can add support yourself by creating and deploying a smart contract (or waiting/hiring a smart contract developer to do it for you). This can all be done by writing smart contracts without having to ask the core development team and/or hard fork.

Applications running on Nervos receive the benefits of interoperability 2.0 for free. Each Nervos Application can be accessed by all blockchain user groups, which we refer to as the Universal Application.

As a developer, you can reach a wider user base by learning how to build on Nervos than any other blockchain platform can offer.

As a user, you can access the world wide apps on Nervos using your existing wallet and account, without having to install a new app or adapt to a new learning curve.

You may feel like you're using dApps on Ethereum or EOS, when in fact the underlying plumbing and infrastructure is provided by Nervos. I believe this is how life should be, just as an Internet user visiting a website doesn't care whether it's written in PHP or Java, MySQL or PostgreSQL. Users don't care, and that's right.

As developers, it is our responsibility to create abstractions and hide implementation details from users so that we can continually replace existing implementations with better software to provide a better user experience. Interoperability 2.0 could make the cryptocurrency world like the Internet is today, and this would require a new blockchain abstraction.

Even better, besides blockchain users, WorldWide Apps can reach a much larger group of people than blockchain users. The cryptocurrency world is still a very small circle, and we can break out of it. Blockchain wallets and accounts are just another account/identity system, while the Internet world has already established multiple identity/account systems and authentication standards such as OpenID, face recognition and fingerprint recognition. Through cryptographic primitives and authentication abstractions, Nervos CKB can also understand widely used Internet protocols.

This allows users to access WorldWide apps using their browsers and phones without installing any blockchain wallets, generating key pairs, or even keeping any mnemonic words. In this way, we can actively adapt to the existing ecosystem of the Internet, rather than creating a whole new one. Our grandparents don't have to struggle to learn something that looks like magic to enjoy the benefits of technology. The barriers that prevented Internet users from entering the cryptocurrency world no longer exist here.

New Metropolis

Many modern metropolises grew out of trading hubs or ports. Venice, New York, Hong Kong, Shanghai and Singapore are all highly commercialized cities based on their port status. In the industrial age, we used interoperable technologies like GPS, cargo ships, and containers to move assets between cities. Today we have crypto assets, blockchain, and Interoperability 2.0. Better interoperability will lead to more migration, trade and dynamism in cities. Tall buildings will rise, goods will flow, assets will reside, people will gather, and a new metropolis will be born.

Ref:

[1]https://en.wikipedia.org/wiki/Feature_phone[2]https://en.wikipedia.org/wiki/Death%27s_End

[3] https://en.wikipedia.org/wiki/Abstraction_ (computer_science) [4] [5] [6] HTTP: / / https://crypto https://iopscience.iop.org/article/10.1088/0143-0807/37/5/055406/meta https://en.wikipedia.org/wiki/Planck_constant .stackexchange.com/questions/85831/what-ec-curve-is-used-by-apple-ios-platform[7]https://hackernoon.com/getting-deep-into-geth-why-syncing-ethereum-node-is-slow-1edb04f9dc5

[8]https://blog.ethereum.org/2021/03/03/geth-v1-10-0/[9]https://eips.ethereum.org/EIPS/eip-1884[10]https://talk.nervos.org/t/lay2-pw-sdk-build-dapps-on-ckb-and-run-them-everywhere/4289[11]https://talk .nervos.org/t/rfc-simple-udt-draft-spec/4333[12]https://talk.nervos.org/t/rfc-extensible-udt/5337[13]https://hackmd.io/@SamWilsn/ryhxoGp4D[14]https://ethresear.ch/t/cross-shard-defi-composability/6268 [15]https://docs.zkproof.org/pages/standards/accepted-workshop3/proposal-plumo_celolightclient.pdf[16]https://docs.keep.network/tbtc/index.pdf[17]https://www.r3.com/wp-content/uploads/2017/06/chain_in teroperability_r3.pdf[18]https://www.weforum.org/whitepapers/inclusive-deployment-of-blockchain-for-supply-chains-part-6-a-framework-for-blockchain-interoperability[19]https://polkadot.network/[20]htt ps://cosmos.network/