Shulou(Shulou.com)06/01 Report--

Today, the editor will share with you where the relevant knowledge of cryptography is used in the blockchain. The content is detailed and the logic is clear. I believe most people still know too much about this knowledge, so share this article for your reference. I hope you can get something after reading this article, let's take a look at it.

Where is cryptography used in the blockchain?

First of all, if you are a blockchain user, there may be a note somewhere in your room with twelve words that you don't know how to get, some people have many, and even some big holder will engrave the twelve English words on the steel plate and lock them in the safe.

Yes, why do these twelve mnemonic words, or a long string of garbled private keys, represent your ownership of the asset?

The principle behind this is actually cryptography.

The key, address and wallet on the block chain are all realized by cryptography. The asymmetric encryption technology-Elliptic Curve algorithm (ECC) can be used to verify whether the private key held by someone matches a public key. In this way, we can prove whether this person is the holder of the encrypted asset, because other people who do not have the private key have no way to unlock the asset.

Here we use Bitcoin as an example of the principle of private key, public key and address generation. A bitcoin wallet contains a series of key pairs, each including a private key and a public key. The private key is usually a randomly selected 256-bit number. Based on the private key, we can use the secp256k1 standard elliptic curve as an one-way cryptographic function to generate a public key. Based on the public key, we can use an one-way hash function SHA256 and RIPEMD160 to generate a bitcoin address, and then encode the bitcoin address into the more concise form it is now. The mnemonic words that we often use are random English words based on the BIP 39 standard. The encrypted asset cannot be used without a private key or mnemonic.

When we have a key pair that can be matched, we can verify it on various types of wallets or clients, confirm the ownership of the assets, and use various assets through this client. For example, the simplest BTC transfer, or a more advanced transaction to sign a smart contract with a wallet: buying an encrypted cat with an ETH in a wallet such as Metamask, imToken, or Alphawallet, or borrowing on DeFi's platform, or exchanging Uniswap for some ERC20 Token.

In addition to basic authentication such as money transfer, even some platforms can now use public and private keys for login authentication, or prove your interests by verifying that you are the owner of an asset. To put it simply, the cryptography behind the public and private key authentication system is the pass for users to travel around the blockchain world.

In the block chain, there is another cryptographic usage scenario that can not be ignored, that is, the transaction ordering in the block, and the process of determining the block ordering, such as Merkle Tree. Bitcoin encrypts every transaction with the SHA256 algorithm, which ensures the security of the blockchain and features that are almost impossible to tamper with. Cryptography is used in the basic usage scenarios of these two bitcoins alone, so many people even speculate that Satoshi Nakamoto may be a big shot in cryptography. to be able to make the best use of cryptography in this peer-to-peer cash system.

Of course, apart from being useful in the core functions of the two blockchains: block generation and public and private key verification, cryptography can be useful in privacy protection and even expansion.

How does the current public chain use cryptography?

Wow, is this a new public chain?

Does it have a wallet?

We need a new set of addresses and a new set of mnemonic words.

If a user is really willing to take good care of his assets and is diligent in investing in different public chains, I am sure they will have similar experience and several different sets of mnemonics or private keys. But in the end, they may be able to preserve only the most important position assets, and some people even forget to back up the mnemonic words of some assets.

In the long run, the problem of blockchain asset management also leads to the higher and higher threshold of blockchain. So some wallets have put forward a lot of optimization schemes to solve this problem. Some wallets can even do a single mnemonic of an identity wallet, manage multiple assets and other functions, but there are still many different groups of addresses that must be managed by the user. This problem may be even more serious for many new public chains, because if users want to try the applications on the chain through their web pages or mobile wallets, they will increase the cost of managing public and private keys. What's more, unlike the passwords of mailboxes, they can be defined by users themselves, which is neither smooth nor fragrant.

But why is the blockchain so limited?

This restriction is due to the fact that many public chains have written many scenarios of cryptographic primitives into the consensus layer, so in these public chains, such as public and private key signatures, client verification, and block-generated hashes and commonly used encryption algorithms, basically are embedded in the consensus layer. For example, the verification used by the address, the signature used by the transaction, etc., are actually written in the underlying protocol, so it becomes very difficult to change. In addition, the virtual machine performance of many public chains is not enough to support flexible cryptographic primitive deployment, so for such a common chain, if the underlying virtual machine does not support a cryptographic primitive in advance, then scenarios based on this cryptographic primitive may be difficult for developers to use directly.

If you want to change, the only way is to fork hard!

Take Taifang as an example, what cryptographic scenes have been written into the consensus layer of Taifang?

In addition to the encrypted signature of the block and the hash of Merkle Tree, there are transaction signatures and client verification. If anyone wants to make changes at these points, such as replacing the keccak-256 hash algorithm of Ethernet public and private keys with other signature algorithms, the only way is to mention an EIP (Ethereum Improvement Proposal), and then wait and pray that the proposal is placed into the hard fork. Because the content written in the protocol layer is the rule that all users of the whole network must follow.

However, hard forking often takes a very long time. Take EIP 152 as an example, this is a proposal put forward in 2016 to add the signature algorithm BLAKE2 to the Ethernet Square, but it was not added to the upgraded content until the Istanbul proposal at the end of 2019, which lasted for three years.

Another limitation we will find from the example of EIP 152 is that it is almost impossible to use cryptographic primitives that are not supported by virtual machines in Ethernet Square. Because performance is a big limitation for Ethernet virtual machines, simple operations alone can consume a lot of gas.

Therefore, if we review the previous bifurcations in Ethernet Square, we can find that from the beginning of the hard bifurcation upgrade of HomeStead, Taifang has continuously added all the cryptographic primitives that may be commonly used, such as sha256 hash, ripenmd160hash, etc., to the underlying virtual machine by means of precompilation (precompiled). This can also be seen in upgrades in Byzantium or Istanbul. In the form of hard bifurcation, Taifang precompiles cryptographic primitives and the gas pricing of these cryptographic primitive operations.

If it is not implemented in the node first through the pre-compiled contract, then the intelligent contract deployment of many signature algorithms will cost a very high gas fee, which makes it impossible to deploy at all. For example, the adoption of EIP 196and EIP 197foresees that zkSNARK requires a large number of gas to perform chain operations. Therefore, these encryption algorithms, such as elliptic curve addition, multiplication and pairing verification, are compiled into the underlying EVM in advance, so that these computational costs can be saved. Therefore, we can say that in the Ethernet Square, except for the pre-compiled signature algorithm, the rest of the encryption algorithm is basically impossible to use.

These fixed ways of using cryptography are a great limitation for developers.

Because both the transaction and the client signature verification are written to the consensus layer, the verification tools and processes must be carried out in accordance with the prescribed encryption algorithm. For example, in Bitcoin or Ethernet Square, if we want to create an account, then we still need to manage a new set of key pairs.

For developers who want to bring a good user experience, this will create a lot of limitations, and need to be in other ways to make up for the unfriendly user experience brought by the solidified underlying facilities. For example, after creating mnemonics, we can use FaceID in some wallets (such as imToken). For example, in ABC Wallet, users only need to log in with a six-character verification code like the one in their mobile phone, and then export and back it up when you really think you need to export the private key or mnemonic words.

These are good ways for developers to try to improve the user experience, but for each new public chain, the essence of key pair management is to have a new set of addresses and keys, and this problem exists all the time.

The inflexibility of the above public and private key verification methods may not be obvious in the more initial public chains such as Bitcoin and Ethernet Fong, because they already have existing users who are used to being tortured. However, for the recent rise of public chain, if there is the same entry friction cost as the previous public chain, it will not only create obstacles for users, but also affect the willingness of developers to develop on this public chain.

A public chain with learning costs for users has inherent barriers to acquiring users, and even if these public chains have other bright spots, they may not be so attractive to developers. Because they know that many users may be scared away by these unfriendly user experiences.

In addition, the problem that cryptographic primitives can not be used flexibly affects more than the preservation of public and private keys. For developers, if they want to use more advanced cryptographic primitives to ensure privacy and security in the future, they will also face the challenge of whether the underlying virtual machine can be deployed and support signature verification. Of course, it will also affect the hot topic currently discussed: cross-chain, because different chains use different cryptographic primitives, which is a problem encountered in virtual machine verification transactions, which is why many isomorphic cross-chain solutions (Cosmos / Polkadot) are feasible, but heterogeneous cross-chain solutions are stagnant.

How is the design of Nervos different?

In Nervos CKB, there are no other hard-coded cryptographic primitives except transaction sorting. Asset ownership verification is done through lock script in cell, in which the verification rules and cryptographic primitives can be customized, so almost all cryptographic primitives can be used flexibly by developers.

To paraphrase a Nervos researcher, teacher Cipher, it is: "except for the most basic transaction ranking on CKB, the rest is application layer content." "this gives developers a lot of flexibility to do all kinds of development, such as freer account verification methods.

Because in RISC-V-based CKB-VM, what is required is a set of verification rules that can comply with RISC-V coding, developers have a lot of room for free. The following figure shows the difference in flexibility between Nervos and other public chains that can support intelligent contracts. The content of the application layer can be customized, and the protocol layer represents the content that needs to be changed after "bifurcation".

Take the current Grnats team Lay2 of Nervos as an example, why can the pw-sdk they developed be used to receive CKB with the address of Taifang, or even ENS? Because on CKB, the address is the application layer content that developers can play with at will. Theoretically, as long as there are already cell verification rules and asymmetric encryption algorithm libraries on the chain, this kind of address generation rules can be verified. For example, we can deploy the signature algorithm and verification rules of ethernet Keccak-256 (SHA-3) and the SHA-256 of bitcoin on the chain, so that other future developers can use cell deps to call it.

Therefore, it is entirely feasible for any developer to add more advanced encryption algorithms to his assets as an unlocking rule on CKB in the future. Because anyone can deploy a variety of cryptographic primitives on CKB, and can reduce the cost of deployment by optimizing to save storage space and reduce the cycle required for verification, so that any advanced cryptographic primitives can be used without waiting for hard bifurcations.

The future of blockchain that you may see on CKB: close to the user experience of the Internet

Based on flexible cryptographic primitives, we can say that in the future, the authentication rules that many Internet users are very used to may also be written in a form that can be read by RISC-V and deployed to the chain, such as PGP Key authentication or fingerprint unlocking. If there is a script on the chain that corresponds to the verification standard they use, and there is a trusted environment that can support such validation, then such a convenient use is really possible in the future.

Taking a closer look, in the future application layer, there will be more scenarios that will use a variety of cryptographic algorithms.

In recent two years, in the field of hierarchical expansion (Layer 2), in addition to the original lightning network, state channel and other side chain solutions, there is a new cryptographic expansion application: Rollup, that is, the use of signature algorithm to compress transactions.

At present, the most mainstream way to compress transactions on Rollup is zero knowledge proof (zkp), which is the so-called zkRollup. In the future, if there are other more advanced zero-knowledge proof solutions on Rollup, or use other de-signature algorithms (such as BLS, etc.), for CKB, as long as developers can think of low-cost implementation methods, they can directly let CKB-VM verify without the need to go through hard bifurcation. Because this does not involve the content of the consensus layer, and CKB-VM is more efficient than EVM. At present, Amby Labs is also developing a zero-knowledge proof library that can be used on CKB, which can be used by developers in the future.

In addition, because CKB can support flexible cryptographic primitives, but also in block chain cross-chain asset transfer, compared with other public chains, CKB has a greater inherent advantage to verify transactions from different chains, so that CKB has a better chance to complete heterogeneous cross-chain asset circulation and transfer.

Since the publication of Satoshi Nakamoto's Bitcoin white paper, blockchain has been a new technology that can prove consensus with cryptography in a centralised environment, something that cannot be done on the Internet. But to use blockchain on a large scale, what we need to do is not to let users compromise in terms of experience, but as Frank of the Lay2 team said: "We need an infrastructure that can support developers to 'open the door', so that blockchain will not become a plaything for a few geeks or insiders because of the inflexibility of the underlying infrastructure.

If the public chain can flexibly support a variety of cryptographic primitives, so that developers can have more flexibility, then they can skip the slow process of "educating users". Because just like the Internet, although everyone is happy without a network, for pure C-end users, they still don't need to know how many layers the Internet is divided into, or what the P2P network is all about.

Similarly, pure C-end users of blockchain do not need to know the underlying knowledge of blockchain when using blockchain technology. what we need to do is to create an infrastructure that can have an Internet experience, certificates for blockchain, and additional effects such as security and decentralization, and Nervos CKB, with high programming flexibility, is moving forward on this road!

These are all the contents of the article "where is cryptography used in the blockchain?" Thank you for reading! I believe you will gain a lot after reading this article. The editor will update different knowledge for you every day. If you want to learn more knowledge, please pay attention to the industry information channel.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.