image description

Click to watch the video

Xiao Xiao:Hello everyone, I am Xiao Xiao, Investment Director of HashKey Capital, and I am also the host of today's AMA. Let's get to the point.

I believe everyone knows that Bitcoin is an asset with the strongest consensus in the Crypto field, but until today its main use is still in the storage and exchange of value. The DFINITY community proposed a direct integration of the ICP and the Bitcoin network in September last year. It also plans to bring more application scenarios to Bitcoin through smart contracts, empowering it, and bringing some high-quality assets to the IC ecosystem. . At that time, this proposal was supported by more than 96% of the people, which is enough to show the community's expectations for this technology.

After the proposal was passed, a very important milestone appeared recently, which is June 10 this year, when the DFINITY Foundation announced the completion of the first phase of Bitcoin and direct integration, which is the threshold ECDSA signature we talked about a lot before. , can be said to be a relatively significant progress, and it is also an important prerequisite for solving the IC integration of Bitcoin.

Do you believe that everyone knows how to realize technology? How to use it? Including how to develop in the future is full of curiosity. We are very honored to invite Mr. Paul Liu, the core technical engineer of DFINITY, to answer questions for you today, and the next time will be handed over to Paul.

Paul Liu：Thank you Mr. Xiao. I am very glad to have the opportunity to share with you. I am an engineer of DFINITY. My name is Paul. I joined DFINITY about four years ago, and I am an early employee. Our mainnet was also launched last year, and has undergone many new developments since its launch. The most important new development is the plan to integrate with Bitcoin.

Today, I would like to introduce to you some overviews of our Internet Computer integrated Bitcoin technology. I will not talk about particularly in-depth technical details, but I hope to give you a clearer understanding of the specific situation before and after.

Let's first review the transaction process on the Bitcoin chain. Suppose there are two classmates, one Alice and one Bob. Alice wants to send some Satoshi to Bob, and she needs to send 400,000. In the illustration here, we use a key to represent the public key, and the dotted line is the private key. Both Alice and Bob have their own public key and private key, and she needs to sign the transaction with the private key to initiate a transaction to the Bitcoin chain.

Let’s take a look at the specific process. To create a transaction, she needs to have a certain amount of bitcoin in hand. Her bitcoin is the output generated by the previous transaction, which we usually call UTXO. The source and input of each transaction must be the output of one or more previous transactions. For example, here Alice gets 100,000 from the previous two transactions, and the other gets 300,000, and then forms an output of 400,000 to Bob. She can only use the previous transactions that have not been used before. This is the bit Coin-specific UTXO model.

The previous two transactions are used to create a new transaction, assign this new transaction to Bob, you can see that it is green, this green refers to the address corresponding to the public key sent to Bob. After that, she wants to initiate this transaction and hand it over to the Bitcoin network. Whether it is a miner or a node in the Bitcoin network, they will put the transaction received from the user into a block. Each block has about There are about 1500 transactions, and such blocks constitute the Bitcoin blockchain. Of course, there are still many details that are ignored here.

What we are concerned about is the whole process of creating a transaction, we can see that it must have its own private key to sign its own transaction. And must know her previous UTXO to be able to quote and issue a new transaction.

After we finish watching the process of Bitcoin, let's briefly introduce Internet Computer. Some audiences may not be particularly familiar with it. We call it the Internet Computer. It runs on a protocol, which we call Internet Computer Protocol, and it provides a public blockchain service platform. The bottom layer is the data center, and the nodes in the data center are independently operated by community node operators. For example, you are As a node operator, you may have an agreement with a certain data center to run a node there. Nodes can join the ICP network. After joining, all the nodes form the underlying network. On top of it, we run the Internet protocol, which is IP. On top of IP, we run the ICP protocol. Nodes are divided into multiple subnets, and consensus protocols are run within each subnet, but all subnets together form a combined network. On this network, we abstract it as a computing platform provided by this network, or a virtual machine, on which programs such as smart contracts can run.

Its main feature is that smart contracts can directly provide network HTTP services, and the query response is at the millisecond level. If a transaction that can change the state is initiated, it may take 2-3 seconds, but 2-3 seconds It is also the most advanced in the current blockchain time. Because the main purpose is to allow smart contracts to run on websites, we cannot charge users. Users can access smart contracts without paying. For example, if you directly use a browser to visit a website, you do not need to pay for this. Reverse gas model. The communication between subnets, and the communication between subnets and external users, uses a model similar to RTC or remote call. You can also think of HTTP as a call.

Why do we say that its calculation cost is relatively low and stable, not that there are few people using it just released, so the calculation cost is low. In fact, because the most advanced sharding technology is used in it, we can share the load of the entire network by adding new subnets, so it actually has no theoretical upper limit and can be expanded infinitely, as long as the hardware allows it. The reason why this can be done is that each of its subnets verify each other's calculation results with very advanced cryptography knowledge. We can verify whether the current calculation of the subnetwork is valid without subnetwork historical transaction records. be believable. This is why we can directly write the service of the website in the smart contract, because we can directly verify that the running result of the smart contract is correct in the mobile phone or browser, because it only needs to pass a public key.

Perhaps one of the most prominent features of IC at the application layer is that it has an autonomous voting governance system, which can vote through smart contracts and can automatically implement voting decisions. The DAO model has developed to this day. I believe that manual voting and one-by-one asking him to sign more will be eliminated, and smart contracts need to be used to automate.

The development environment of IC mentioned above can be regarded as a virtual machine, so the developer can directly upload the smart contract code and deploy it to IC, which is similar to deploying code on cloud services. Each code after deployment becomes an independent container, we call it Canister, each of our containers on IC not only has the code of the smart contract, but also includes its state, all the states it can modify are stored inside the container . If you want to access the state of other containers, you must access it through the interface of other containers. Accessing this interface is equivalent to a remote call. But if the other party does not open this interface or the open interface does not provide the data you need, then you cannot access it. So this is a relatively major difference, which may be quite different from other current blockchains, especially developers need to pay attention. However, it is relatively close to the traditional Internet Docker or MicroService development model, and traditional developers may be relatively familiar with developing on IC.

What is the so-called integration of smart contracts and Bitcoin? We have also seen Bitcoin transactions before. Bitcoin initiates a transaction to be signed. Here we can see that if Alice and Bob are used to send Bitcoin directly to the container, if the container can also receive Bitcoin directly. In this case, containers can also issue transactions back and forth like users, and in fact, a smart contract can manage Bitcoin assets. In other words, we can provide a smart contract platform for Bitcoin.

So one of the more important assumptions in it is that if each Canister on the IC, the smart contract on the IC, if each Canister on the IC can get a Bitcoin address, it means that it can be managed through program logic Bitcoin assets. This is the original intention of the design. We must allow each Canister to have its own Bitcoin address. Having its own address means that it needs to be able to issue its own transactions.

Let's take a look at the specific implementation process. The integration is first at the underlying protocol layer. The protocol layer has made an access to the Bitcoin network, which is the light node of Bitcoin running, and can know the status of transactions on the Bitcoin network. and its latest block, but it does not participate in Bitcoin mining, it is only used to send and receive user transactions. But the information of these blocks can be obtained by every node on the IC, and this node can pass this information up to the virtual machine, which is the Canister run by the user. So Canister can get all the UTXO of this BTC address he owns.

If the user wants to transfer assets to your Canister, that is, I send bitcoins to your Canister, then the Canister can receive this information by monitoring the Bitcoin network, because the latest block can be known, and it can be known that it is Someone has sent bitcoins to its address, and it can learn this information.

How does it send it? He needs to make a signature for his transaction, and the signature he made must be sent to the Bitcoin network, so there is not only a process of input to Canister, but also an output from Canister, which can be circulated to Bitcoin on the network. So this is a service provided by the underlying nodes. Compared with the original node of an IC, it provides a little more service, which is a process of directly exchanging information with the Bitcoin network.

I just talked about the main reason because we can make each Canister contract have its own bitcoin address to control bitcoin assets. Its premise is that we need to implement a technology called Threshold ECDSA threshold signature, which is also being developed In development, we have made relatively good progress. This technology allows us to assign each Canister its own BTC address. The so-called own address means that it has its own public key. It can sign, but this signature is not that he keeps his own private key, but that his signature is signed through the subnet on the IC network, and the subnet can replace Canister to sign the contract that Canister wants to sign. sign. This will be discussed in detail later.

If each Canister has its own Bitcoin address, and it can obtain related UTXO transactions on the chain, then it can make a decision by itself through the program, whether it needs to initiate a new transaction or I want to get more information from users. More information, so that it can not only interact with the Bitcoin network, but also interact with users directly through the browser at the same time. It can also send new transactions to the network for transactions. If the entire cycle can run down, it is equivalent to the user code running on the IC can already provide a smart contract service for the Bitcoin network. So these three points are the most important of what we call the integration of IC and BTC, as long as we can do these three points.

To use this function, developers must go through some system interfaces. This interface is relatively simple. You can directly get your own balance or send bitcoins, and there is also an interface that provides signatures. The most important thing is to provide a signature. How is this technology implemented? First of all, the main core technology of IC is DKG, which is a distributed key generation protocol. The main process of DKG is that each node in the subnet can generate a share of a private key, which is theoretically not a complete private key, although it can be used for signatures. Each node keeps its own secret, and this private key share only belongs to this node, and it will not tell anyone else. After the DKG protocol, each participating node can generate its own private key share. They don't know each other's, but they know their own.

This protocol generates another result. This subnet will have a public key. This public key is unique. After each node has its own private key share, it can use the private key share to sign independently. If these nodes share the same message Sign and broadcast this signature. After knowing the signatures of other nodes, these signatures can be combined into a final signature. This final signature can be verified with the public key of the subnet. This means that the final signature can be verified with a fixed public key, but no single party knows the private key corresponding to this public key.

Visually speaking, it is distributed to all the nodes and everyone has a copy, and then everyone signs it. If a final signature can be synthesized after signing, then the public key can be verified, but no one has the secret of the corresponding private key. , a majority of nodes must participate in order to synthesize all signatures. Usually, more than two-thirds of the nodes are required to complete the signature, and the final signature of a transaction can be verified with the public key. The main technology of IC is this, but the signature we made before is based on the technology of BLS cryptographic signature. Now we need to complete a similar technology for ECDSA, which also supports ECDSA signature. Compared with BLS, it needs It is much more complicated, and many papers discussed the frontier research of cryptography in the past, but they have not found a method that is particularly safe, and it always has some compromises of one kind or another. So we have made the latest breakthrough in this area, and we are quite satisfied with the design of the whole system. Of course, it also needs to be audited by experts in cryptography, and its security can be finally confirmed after various verifications.

But its specific approach is consistent with the entire DKG process at the level of abstract understanding. At the beginning, by running a DKG protocol, the nodes of the subnet get their own private keys, sign with their own private keys, and after signing Put it all together, and that's about it. The combined signature is indistinguishable from the ordinary ECDSA signature, because its public key is the ordinary ECDSA public key, so the Bitcoin network uses the ECDSA signature, which later introduced the Schnorr signature, Schnorr It will be simpler than ordinary ECDSA if the signature is to be DKG. The reason why we choose to support ordinary ECDSA is that the scope of application is not limited to Bitcoin, and it can have some other directions.

Just said that the subnet has a public key. In the Bitcoin ECDSA signature, there is a BIP32 standard, through which more key pairs can be generated from a pair of keys. Use these subkeys to sign, and the signature has its own address, and the counterparty who receives the transaction does not know what your master key is. The system used is based on the BIP32 standard, which is also applicable to our threshold signature. Therefore, the public key of each Canister is through its Canister ID, which is a unique ID assigned when it is created, and this ID cannot be faked after consensus on the IC network.

Therefore, it is completely feasible to use this ID to use the BIP32 standard to match the public key of the subnet to generate the public key of each Canister. Even in a Canister, if you want to sign and issue transactions in it, it is possible to use more different public keys to do different things, because each public key corresponds to an address, so basically any number of public keys can Provided for use by a Canister. In this way, when each Canister signs, it sends its own signature requirements to the subnet, and then each node of the subnet signs with its own private key through BIP32 to finally synthesize the final signature.

So IC integrated BTC is not a bridge. Bridging is to facilitate cross-chain assets. Usually, it is locked by a smart contract on one of the chains, that is, the assets are sent to this smart contract, and then the same developer develops another chain on the corresponding other chain. A set of smart contracts will issue you new assets over there, so that an asset can be exchanged.

The main problem with this is that everyone needs to trust the developer who provides the bridge, but because of this signature on the IC, there is no need to trust a single party, nor does it need to trust a single developer. It can be directly released by publishing my smart contract source The code is here, and my smart contract runs on the IC platform. If you trust that the IC subnet is a decentralized platform, and trust that the result of its operation is correct, if there is such a layer of trust in it, In fact, it is a decentralized trust, which can do more things.

Especially through bridging, you need to pledge your assets. Not all applications need bridging. For example, if you want to send some bitcoins to an account regularly, then there is no need for bridging or pledging, and you can send it directly by signing.

To sum up our technical characteristics, each smart contract has its own independent BTC address, and the core technology is the Threshold ECDSA threshold signature. It is important to point out that bitcoin transactions still go through the bitcoin network. All our bitcoin transactions are ultimately sent to the bitcoin network and confirmed by the bitcoin network, so that we can confirm that UTXO transactions are correctly recorded in bitcoin on the chain. The contract can query UTXO, issue and send transactions through the API. Its security comes from the security of the IC subnet. Through the combination of the IC blockchain and the Bitcoin blockchain, the security of the two together guarantees the smart contract security.

Probably I will stop here first with a brief introduction, and see if you have any questions.

Xiao Xiao:Okay, thank you very much Paul for sharing. Let’s move on to today’s Q&A session. We have also collected a lot of questions from the developer community and the general user community in the past week, including some left over from my own research. question. Today we have selected some of the more important and more general questions to ask. In addition, friends who are watching the AMA, if you have other friends, you can also call in the communication and discussion area of ​​the live broadcast room. If time permits, we can also take a few more questions from the scene to ask later.

First of all, the first question everyone is most concerned about is the most important question for users and developers. What is the specific launch schedule, including when will the developer end and user end be able to officially use this function?

Paul Liu：I can’t say too much about the timetable. One of the technologies we know so far is ECDSA signature, which cannot be said to be fully completed, because there are still a lot of testing work that has not been completed, but the current signed demo can pass. The user can send a message and request Canister to sign it. Canister receives the message and makes a call to the system API, and then the system API is transmitted to each node, and each node can perform a signature. Together, a final signature is finally obtained, and the final signature is fed back to Canister, and then Canister feeds back to the user. Such a process has already been run through internally, and the entire development process will be accelerated next.

So our preliminary plan is to launch an ECDSA test version in the first quarter, allowing developers to use real ECDSA signatures. There is also a preliminary version of Bitcoin’s integration with Bitcoin to listen to the Bitcoin network and send transactions. It may be at the end of this month that a dedicated API will be released for developers to use and do some debugging work locally. This is used It is a test network rather than Bitcoin's main network. I believe that a developer preview version will be launched at the end of this month. The specific launch date will also be a beta version in March of the first quarter. I hope that real large assets will not be put in it. The test will take a certain amount of time to be sure. It is safe and reliable and there are no bigger problems in all aspects of use, probably so.

Xiao Xiao:Theoretically speaking, after the real direct integration, how much will the speed of Bitcoin transfer be accelerated?

Paul Liu: All Bitcoin transactions are still on the Bitcoin network, so we are not trying to speed up the transaction speed of Bitcoin. Simply understand that the set of things we do is for developers to use, and we belong to what we do underlying infrastructure. The developer uses this technology to make the application he wants. I can give a few simple examples. One is that I will make a bridge. If I am a developer, I will make a bridge. I can use a smart contract for both Bitcoin users and IC users. It can Receive bitcoins. This is something that can be done directly. Now in the market, this kind of bridge needs a centralized company to operate, and you need to trust them. If this can be included in the contract, you can directly use the WBTC issued by this contract to trade on the IC network. In the end, you need settlement to convert it to BTC, or on the BTC network. This is a bit like the Lightning Network. Your real transaction happens elsewhere, and it is faster. Bitcoin transactions are still placed on the Bitcoin network, and there will be no acceleration.

Xiao Xiao:But will there be a delay in the transfer during this process, and how long will it take in addition to the time required for Bitcoin itself?

Paul Liu: This does not take much time. Our extra time is all done in seconds. For example, it takes a few seconds to issue a signature. Obtaining UTXO is basically a direct call, so I think the additional time for our integration is negligible. Compared with Bitcoin, which needs to be confirmed 10 to 20 times. It is a safer way, and the possible additional time can be ignored.

Xiao Xiao:I understand, just now it was mentioned that the integration of Bitcoin is also subject to the nodes of the subnet. I would like to ask if the official plans to open a dedicated subnet for Bitcoin?

Paul Liu: I think this is a good idea. We have several different solutions, and we haven't decided which one to use yet. Personally, I think it is necessary to open a subnet for it. It is more efficient to open a dedicated subnet, because it does not need to run other types of smart contracts. It may be more efficient to focus on signing for Bitcoin in terms of calculations.

Xiao Xiao:Understood, the key derivation BIP32 standard was also mentioned just now, please Paul brother to further introduce the advantages of this standard? Why choose the BIP32 standard for key development instead of using the traditional independent key method?

Paul Liu：Bitcoin adopts the ECDSA curve for this consideration. It hopes that everyone can use different addresses through different public keys, which is more flexible. Your assets do not necessarily only need one address. You can use different addresses. Since the different addresses are generated by you, you can manage them. As for why this BIP32 derivation method is more advantageous, because it does not depend on you to save each individual key, it uses a key according to a derivation rule, you can decide its prefix and suffix to achieve a The ladder structure is more flexible in this way. However, in terms of security or other aspects, some people may have different needs, and they also need to use different public and private key pairs.

For example, I can use a hardware device to generate a pair of public and private keys, so that I can hand over the hardware device to others, and the other party may feel more at ease if the public and private keys are generated directly through hardware.

It is unrealistic to use this derivation method, because it is impossible for you to hand over your main private key to a third party. So each has its own advantages. In our integration, I just mentioned that a subnet has its own public key, which is unique. But we can have different subnets, and different subnets can provide services issued by different bitcoins. Different subnets can run the same public key and private key, or they can run different public and private keys. Because it can communicate between different subnets, no matter which subnet your smart contract is on, you can use Bitcoin services provided by other subnets. You send your signature request to that subnet, and that subnet signs it through the nodes in its subnet, and the result of the signature corresponds to the public key of that subnet.

So we can also implement more pairs of public and private keys. Perhaps the focus is not on this aspect, but on being able to derive more different addresses. Directly through the derivation relationship, the application of this derivation relationship on our side is mainly to support all Canisters, instead of each Canister generating a public key and private key for you separately. The main trouble of generating it separately is because the technology used behind it has a relatively large overhead. It is not as simple as I just said to save a private key share to sign for you. This process is more complicated. To put it simply, it is not just one DKG, but there are many DKGs in it, and many of them are temporary. If you do it once and use it up, you will throw it away. Therefore, a subnet only uses one public key pair, which is more acceptable to our nodes. In terms of security, if one pair is unsafe, many pairs are even more unsafe. So we have to make sure that at least one pair is safe. The ID of each Canister is unique, so the address and public key assigned to each Canister are also safe, probably like this.

Xiao Xiao:I understand, I would like to ask if it is possible to query the source and whereabouts of Bitcoin funds through Canister after the integration, or its transaction history? Does this query process need to consume the resources of the IC network, or may I directly integrate the Bitcoin browser to do this query during the APP development process?

Paul Liu：For this query, we directly provide the API of the system for querying, because each IC node will run a Bitcoin light node, which can verify all new transactions on the Bitcoin network. The so-called light nodes are not particularly light, starting from the Genesis block.

The accounts maintained are all UTXO, and we don’t need to trust each of the nodes, because the nodes are all independently running a light node of BTC, and the calculations run by the nodes of each subnet must be the same in order to be able to calculate The result is a verification. Because it has to go through a round of consensus, the result it obtains needs consensus. After multiple subnetwork nodes perform consensus, it proves that your UTXO query is accurate, and it can only be returned to our smart contract without string modification.

Another is the resources it consumes. This runs on the IC network. You need to pay for this API call. I mentioned earlier that end users do not need to pay for this, but developers need to be in their own contracts. Calls or signatures require a separate fee for each call.

Xiao Xiao:Speaking of developer payment, I just mentioned that the bitcoin transfer itself is still on the bitcoin network, so it may still consume some bitcoin network gas. Can this gas be made insensitive on the user side, a reverse gas model? Can this type of gas be covered?

Paul Liu: This type of Gas can be covered, because each smart contract has a BTC address, which should be paid by the contract, so this is still passed on to the developer. If the developer decides that I am willing to pay for my user's transaction, then of course he can pay for it on the BTC network.

Xiao Xiao: Another question is that WBTC was mentioned just now. I would like to ask what kind of standard or format exists for BTC after IC integration, or is it the original UTXO or is there a new one for Bitcoin? standard out?

Paul Liu：I don’t think the foundation is very good at making this standard. It’s better to leave this to developers. What we do is that each Canister has a BTC address. You decide how to use the BTC inside. This is all in Bitcoin. On the Internet, there is no IC network. So you can choose to make a WBTC, but there are other developers who do similar things, and this fair competition is left to the market to decide. Of course, it is not necessary to do WBTC, there are many applications that do not need this method.

Xiao Xiao:If the community establishes an asset standard, will the official choose to stand in line or choose to support a certain standard?

Paul Liu：I think our most important consideration is not to appear too many scammers, or to worry more about security. As for which standard will win in the end, it is not certain, and the Foundation will not take sides.

Xiao Xiao:We are also paying attention to some other ecology. For example, from our perspective, from the early days of Bitcoin to the present, many projects want to derive smart contracts on Bitcoin, such as RSK or Blockstack. I would like to ask for direct integration of IC Compared with the smart contract layer protocol layer projects that can be seen on the market today, what kind of advantages do they have in terms of technology? Or where is the most important difference?

Paul Liu：I think the main difference is the storage method of the private key. I just said that no one knows what its private key is in the threshold signature. Each node only knows its own share, so this is relatively a decentralized storage of private keys. Way, it's now safe to say that no one actually did this. Previously, it was proposed to provide smart contracts for Bitcoin, and they all bypassed this in some ways, such as hardware, trusted hardware to store private keys, and hardware signatures that can be trusted. But trust where the hardware signature is trusted. You can trust that the signature will not be stolen, but can you trust that the signature is used correctly. So if they want to design a complicated process to win the trust of users, such a method is more difficult, and there may be some technical difficulties or compromises.

I think the main method on IC is to make signatures in a decentralized way. Let's imagine DeFi, and we emphasize DeFi instead of CeFi. CeFi is like an exchange. The correct way to sign the exchange is to carefully manage the wallet. If it is accidentally leaked, it will cause big trouble. The number of times the wallet is used and the way it is used require a lot of procedures and rules, which also brings inconvenience.

But now there is a decentralized way to do signatures or to do calculations. The existing decentralized method allows everyone to trust the calculation results of the smart contract, but it cannot hold secrets. Now the DKG technology can trust the signature in a decentralized way. I think this is a breakthrough. Not only from the perspective of cryptography, but if it can be applied on a large scale, it will definitely be a new breakthrough.

Xiao Xiao:This ECDSA seems to be a very low-level technology. Does it mean that after this technology is really realized, it is relatively easy to integrate other networks later, such as integrating Ethereum or integrating existing mature protocols?

Paul Liu：Yes, we too are hopeful about such a prospect. The reason why Bitcoin is chosen first is that Bitcoin is currently still concentrated in an asset network, and it lacks a credible smart contract architecture. So we first choose Bitcoin as the pilot of our combination, and the next step is to have a plan for Ethereum. Ethereum itself also has 2.0 changes, so it is at such a stage, so we are still waiting to see its changes. However, the integration of Ethereum has also been proposed and is under development. So the same technology can be used in Ethereum, and we can sign Ethereum transactions without too many problems.

Because Ethereum is a smart contract platform, our integration of BTC is still focused on assets, which can have BTC addresses and can be signed. But Ethereum is not just about signing. It has a smart contract. We need to be able to call the smart contract of Ethereum. Calling the smart contract of Ethereum may mean sending a message to make a signature, but there are still some things to do when Ethereum calls the contract on our IC, so the integration with BTC is still slightly different. If two-way calls can be realized, the difference from bridging will be even greater, because bridging can only be the mortgage of one asset, and an equivalent asset or different asset will be exchanged there. If two-way invocation of smart contracts can be realized, I believe it will also be a great breakthrough for cross-chain.

Xiao Xiao:I understand, besides the difficulty of smart contracts, do you think the asset side will be another difficulty? Because in fact, the Ethereum account model is somewhat different from the Bitcoin UTXO. Does this whole set of logic need to be rewritten from scratch or is it actually not particularly difficult?

Paul Liu：There should be no problem with this, because the account models are different, and it actually depends on how your application uses these account models. We just provide an interface that you can query, and you can query all the UTXOs in Bitcoin. . All the status of Ethereum can also be checked. We guarantee that the query is distributed, and the results it finds are credible. It is not difficult to do this. Since each IC subnet node can run the client of Bitcoin, it can also run the client of other chains.

Xiao Xiao:In the long-term future, after combining many main chains, can the smart contracts and assets on each chain be called simultaneously from the same Canister? At that time, there may not be a concept of multi-chains. In fact, one Canister is Can you control all your chains or all your wallet assets?

Paul Liu：This is a very good prospect, and we hope to be able to achieve this.

Xiao Xiao:From the application point of view, the Lightning Network was mentioned just now, and its development speed is very fast. I would like to ask whether there will be some synergy or integration with the Lightning Network after Bitcoin is integrated in the future?

Paul Liu：The main technology of Lightning Network is that it can merge transactions. It can transfer money between Lightning Networks without using BTC. It uses some knowledge of cryptography to verify the final merged transaction through a single transaction. It is like this a technique. The same technology can also be implemented on the IC. As for whether this is meaningful, I am not particularly clear, but I want to point out that there should be no major technical difficulties here. The technology combined with the Lightning Network can completely occur at the application layer. , does not require us to do new things on the underlying infrastructure of the IC.

But Lightning Network can only do this. The reason why it can merge these transactions is because it has this set of cryptography knowledge to do this, but you want to do more things, such as more complicated The logic, such as whether I can judge whether these transactions are successful through some conditions, send a little to that place and send a little to this place. Wherever you need to be able to program, it will not work to use the Lightning Network. A whole set of things that require smart contracts is in it. I believe that Lightning Network is also trying to find this breakthrough. Therefore, the smart contract on the IC may also provide the next development space for the Lightning Network.

Xiao Xiao:I understand that in addition to payment, the application will have other directions, such as bringing Bitcoin into DeFi, or having its own ecology or adding Bitcoin itself. I am not sure if there is any plan for future applications. The next step To develop Bitcoin payment or to develop applications such as Bitcoin plus Defi?

Paul Liu：We leave these to the application layer or our developers. I believe that many developers are now very concerned about this matter, including the ability to promote their own applications after integration. I think from what our foundation is currently doing, one theme that runs through everything is that we want to promote the decentralization of the IC network, we hope it will become more credible, and only after it becomes more credible can we have a bigger Expansion capacity.

So one is the decentralization of IC nodes, and the other is the decentralization of our voting mechanism, which means that we, as a foundation, do not want to compete with other application developers at the application layer, unless the underlying application needs to use We will participate in the technology we get. If it can be completed at the application layer, we will try our best to hand it over to the application layer. The foundation does not need to have a special position in it.

Xiao Xiao:Understand, according to the timeline just now, developers can do some basic tests and basic attempts at the end of this month, which is very good news.