On September 19, the 9th Blockchain Global Summit organized by Wanxiang Blockchain Lab was held at the W Hotel on the Bund in Shanghai. With the core theme of Next stop, Web3.0, the summit focused on the three major fields of Web3.0, AI, and DePIN, and invited dozens of outstanding developers, experts, scholars and well-known project founders at home and abroad to discuss the future of the new era. Web3.0 world picture.

Jens Groth, chief researcher of DFINITY, delivered a speech on the topic of Blockchain-based ECDSA Signature Service. He said that if the blockchain wants to be successful, it must achieve cross-chain interoperability, and the entire world also needs such cross-chain interoperability. For blockchain to truly engulf the world of software, it must meet two core requirements: performance and integration. Jens Groth said that he will continue to study how to continuously improve performance so that smart contracts on IC can directly store BTC and interact with the Bitcoin network.

The following is the content of Jens Groth’s speech:

Jnes Groth: Hello everyone, what I want to share with you today is the work we do at Dfinity, which is the ECDSA signature service. Here we will introduce from a macro perspective, if the blockchain wants to be successful, it must achieve cross-chain interoperability, and the entire world also needs such cross-chain interoperability. So we hope to make a contribution in the middle and must do some hard-core research. I hope to introduce what to do and what can be done from the perspective of user needs all the way to the perspective of encryption algorithms. Let me first introduce the Dfinity Foundation, which now has nearly 300 employees and is a green non-profit organization. We have invested heavily in research and development, achieved a lot of results, and published many papers. After launching the IC Internet Computer a few years ago, which is our blockchain network, we want to put all the traditional technology stacks on the blockchain platform, and thats what we hope to achieve. We implement the migration from Web2 to Web3. We have been deeply involved in this field for many years.

Let me introduce to you in detail now. A core issue that everyone is currently paying attention to is whether the blockchain will swallow up the software stack? In terms of Dfinitys software, its true that it has a lot of advantages that allow us to replace existing IT stations, which is a good thing and an advantage from a security and user protection perspective. Now it is just a small fish. We hope that this small fish will become bigger and bigger. We must prove that this is a feasible theory, and we will also see how this theory becomes a reality in the next ten years.

Now look at blockchain and what does it mean that blockchain will eat up the entire software world? Blockchain means a public ledger and requires a blockchain protocol. The blockchain protocol mainly defines how the nodes in the blockchain network collaborate, how to reach consensus, what the order of blocks is, etc. We need to interact with the blockchain platform. On this platform, there need to be some physical machines that can connect to the Internet. In addition, we need to have an execution paradigm and Dapp deployed on the blockchain platform. In addition, there must be blockchain projects and some SDKs for developers to develop Dapps on the blockchain platform. There needs to be some way for users to interact with the platform. In addition, there needs to be a community that can interact with different blockchains. So all of this is very important. Only through the achievement of all of this can the blockchain truly engulf the world of software.

There are two core requirements here. One core requirement is performance, because the performance of the blockchain must be improved. People want to get an interactive experience like a mobile phone, which is the core requirement for blockchain. Another core requirement is integration, that is, smart contracts on the blockchain need to interact with each other. To solve the first core appeal, that is, can the blockchain achieve competitive performance? There are challenges here, because with blockchain, the state of the smart contract is replicated between different machines. If you need to execute an instruction, all machines must reach a consensus. All machines must reach a consensus, which determines what the next state is before it can be executed. That is to say, there is some duplication of work in executing on the blockchain. Through research, we have proven that the blockchain can be comparable to traditional cloud computing. This replicated state machine is the information delivered through research. Our research shows that the replicated state machine can compete with traditional servers. This research report was released by us at the 2023 ATC conference. What does this mean in the century? What level of performance can be achieved from a blockchain perspective? We can achieve a write latency of 1 to 2 seconds, which is comparable to the traditional Internet model. The reading time is only 200 milliseconds. Although writing 1 second to 2 seconds is relatively long, it is acceptable for many applications. For example, if you are making a media-oriented application, when a user publishes something, he or she will wait 1 to 2 seconds before publishing it officially on the platform. This waiting time is acceptable to the user. We also have high throughput, which is a mid-century application, and we can handle hundreds of thousands of transactions per second. In addition, smart contracts make us very powerful. Smart contracts can store hundreds of QB of data at a very low cost. I am doing a data performance comparison here. Generally speaking, 32 GB is its upper limit. What is the upper limit of blockchain performance? The unit we measure is energy consumption, so we measure energy consumption. The energy consumption of processing each transaction is less than the energy consumption of a light bulb.

I hope that through my introduction just now, everyone has become convinced that blockchain has the potential and ability to achieve the required performance and can truly replace the traditional IT software stack. Another requirement is that the blockchain must interact with the world. To achieve this, the blockchain must be able to interact with users and provide users with a good terminal experience. If a user opens a browser and is directed to the blockchain or a Dapp on the blockchain, thats the seamless user experience we want to achieve. We also want to give developers a great experience, and we dont want those developers to have a very difficult time in the development process. We hope that developers’ development experience can be very smooth, and everything can be done on smart contracts. The entire underlying blockchain platform can solve all subsequent problems, so use any software you like for development, whether it is python or others. There are some other blockchains that also provide other means, such as providing Web3 with your favorite programming language and compiling the underlying language that blockchains like. This is how to manage, upgrade, optimize the blockchain platform, and ultimately integrate it. In this way, users will gradually accept your blockchain.

This is what we have been committed to doing. We host everything on the chain, which means that when users go to IC, they can view the next generation of dapps on IC’s unified interface. If they agree to upgrade through a vote, the platform can be upgraded, but they can see the next generation of the platform, and we do this every week. We call this a hard fork. Shown here are some links. If you want to feel the user experience of IC, you can click on the links to see the user experience. At the same time, we also have links to let developers experience the development experience. Everything is hosted directly on the IC, that is, there is no middle layer.

In addition, I hope to focus on ECDSAs signature service, and what possibilities the ECDSA signature service brings, and how it helps dapps interact with the world. Dapps deployed on IC must obtain data from other places and send it to other applications. and platform. We can also provide related services so that smart contracts can make HTB requests. We provide blockchain integration services. But today my topic is ECDSA, which means I will focus on how Dapp interacts with the Bitcoin network on IC.

We mainly do cross-chain communication and interaction, which means that the nodes deployed in IC IQ operation can have multiple contact methods to establish interactions and connections with the verifiers of the Bitcoin network.

Even if some Bitcoin network validators are malicious validators, the connection between the nodes on the IC network and the Bitcoin network will not be lost. The key here is that it sounds good and can already communicate with the Bitcoin network. But the Bitcoin network will only accept signed transactions because smart contracts have no way to store private keys because smart contracts are copied. Any node stores data and copies the node. If the Squab node is malicious, there will be some risk of the private key being stolen. Yes what this means is that for the signing service to need to be there, I need a public key and the signing service says, this is the public key. The smart contract says, please sign. Then he signed. Now that the smart contract has obtained the signed transaction, it can interact with the Bitcoin network.

We now turn this question back to the ECDSA signing service, and how signing services can potentially interoperate. For example, anonymous sharing technology means that all nodes collectively own the signature key, but no single node in the entire node network owns the complete key. By creating a key, we can sign messages using a multi-signature computing protocol. And in this way, we have also achieved security, and no single node in the entire node network will tamper with the signature. In fact, this technology has been around since the 1980s, so its security is proven. The difficulty lies in ensuring its operation while achieving security. We propose a holistic solution in this regard, and at the same time we can also have a high degree of fault tolerance for nodes. Moreover, asynchronous transactions and asynchronous communication are implemented. This is different from the multi-party calculation file. You think asynchronous transaction or asynchronous communication is a very simple model. But the reality is that sometimes, there will be some communication interruptions during the communication process. In addition, there is also a lot of research and performance in the ECDSA signature service. In fact, there is no way to finally get the signature through ECDSA. This is an area that we are concerned about and committed to research. Now you can see that I have just raised a question and need an efficient way to solve the problem. What is the solution? I propose a solution. ECDSA hashes the message before performing subsequent operations. For example, here we have a smart contract in one slice, and the message we want to send in the other slice. In this case, the entire message is delivered, the message is hashed, and only the hash of the message is sent, which is the original signature generated. As for the other two performance improvement solutions, let me quickly introduce them to you. This includes big D, which is a long algorithm and is used for signatures. It contains a Y as a collective element. The core now is that you dont do multi-party calculations. You first have a stage where you can pre-sign without knowing the message, making the signing process faster. Because once you do the pre-calculation, you can quickly sign the message after receiving it. From this perspective, there is still a question of whether it is still safe. You first issued a warning and then released it. Is this step safe? We conducted a security analysis on it and finally concluded that it is completely unsafe if you do not combine it with the original signature.

The last optimization solution is additive key derivation. Think about it, we have ECDSAs signature service, which has millions of different smart contracts and manages millions of keys, which is very expensive. Because it needs to generate the key first, if some nodes leave the network, the key needs to be transferred. Our solution to this is to derive or derive other keys from a single master key, implemented through algorithms. Here, there are already relevant standards. For example, this standard tells you how to use the smart contract ID to derive the public number E. That is, this way, you only need to manage one master key. In terms of security, it is combined with pre-computation. Does the security meet the requirements? This is a subject worthy of study. We have made a lot of optimizations, which have brought security issues, and we need to take measures to reduce risks. One of the solutions included is that I pre-sign, pre-compute the signature, and perform public randomization. In this way, its efficiency can be improved through pre-signature and predicted calculation.

So we compared all the different combinations, including pre-signed disclosures, additions, keys, derivation, and original signatures, etc., all in a research paper published in 2022. This slide shows the results of our analysis. What you need is to filter between these different LOGOs according to your needs. This allows us to successfully complete the integration between IC and the Bitcoin network. Although it is still very slow, considering that Bitcoin’s transaction processing speed is only 7 transactions per second, we can do ECDSA’s signature service. Whether it is integration with Bitcoin, integration with Ethereum, or integration with other currencies, it can be done. What we continue to study is how to continue to improve performance. We will also look at other signatures, such as graphite signatures, which can achieve faster processing speeds. All of these allow smart contracts on ICs to directly store BTC and be able to interact with Bitcoin. Interact on the Internet, thank you very much for listening!