Dfinity and Ether interoperability insights: How to interact? What are the potential opportunities?
The first issue is focused on interoperability cost, and the later issue is focused on security. It is a potential development direction to weigh the two to make a better interoperability solution.
This article, from Dfinity founder Dominic Williams’ May 28 Medium “Internet Computer <> Ethereum Integration Explained” notes, answers several of my questions.
Where do ICP and ETH fit in and how do they relate to each other?
How is ICP currently interacting with ETH? What are the problems faced?
What opportunities will interoperability between ICP and ETH present?
Positioning and relationship between ICP and ETH
ICP and ETH are designed for different purposes and are positioned differently, and are complementary to each other; the structure of ICP is a different subnet composed of independent nodes, whose computing resources are provided by local computing centers, and the hardware equipment used by the computing centers is specially customized. It is a two-tier structure consisting of computing centers – neurons (subnets) – containers (canisters). Compared to Ether, the underlying layer of computing is much more open, and anyone can provide computing. Its structure is a single-layer structure of miners (computation) – smart contracts (smart contracts). The different structure design allows for different functional focus, with ICP tending towards the application layer for end-users, while ETH tends towards the financial settlement layer for high-value assets. As the ETH network becomes more accepted, GAS fees are rising rapidly and compute resources are stretched so thinly that 1GB of smart contracts will cost 100 million USD worth of ETH (latest data), while running such applications at ICP will cost less than 5USD in Cycle.
In the future, people are likely to use consumer-grade applications on ICP, and the data assets that are deposited are packaged and traded to form financial assets. This part of financial assets is likely to be transferred to ETH for financial related operations. With the computing and storage performance of ICP containers, users can obtain richer web3.0 services; and with the atomicity and tamper-evident nature of ETH smart contracts, users can obtain greater security for their high-value assets.
In addition, ICP’s Chain Key feature allows users to connect directly to Ethernet via digital identity (Face ID, fingerprints, YubiKeys) without having to manage a complex wallet. All these features will greatly enrich the ecology of both.
Principle of interoperability between ICP and ETH
We will introduce support for a threshold variant of ECDSA. In essence, this will enable smart contracts on the Internet Computer to create Bitcoin and Ethereum transactions pertaining to public keys on those chains, without holding corresponding private keys (which will not even exist, and instead take the form of private key shares securely distributed across independent nodes).
ICP also uses the Elliptic Curve Digital Signature Algorithm (ECDSA), which allows ICP users to create transactions on the chain without private keys. This is achieved by multi-signing the private key through the subnet and then verifying it with the public key, thus realizing the entire transaction. In other words, interoperability from ICP to ETH network is achieved through subnet multi-signature on ICP, where the transaction is first issued by the subnet multi-signature and then traded within ICP by the subnet. Simply put, the role of BLS threshold signature is equivalent to a private key.
After solving the problem if from ICP to ETH chain, then how to return the result of the execution from ETH?
Phase 1: Since the current ETH is atomic in nature, the state of each address is verified and synchronized by PoW. So when we need to get the ETH state on ICP, we can check the state of the ETH block and whenever the block is verified (after a certain block so that the correctness is guaranteed), the smart contract on ETH can read the desired state from all the data in the block and transmit it to the smart contract on ICP. When the ICP smart contract is finished, it can directly transmit information and data back to ETH via the prophecy machine, thus forming a closed loop between ICP and ETH operations.
Because of the smart contract functionality required to move from ETH to ICP, this all runs on ETH, which means that this type of operation is very expensive. The high cost will limit the integration and collaboration between ICP and ETH when ICP requires a lot of information to be transferred from ETH.
Phase 2: To save the cost of ETH smart contract functionality, we will synchronize the ETH node state to the ICP’s smart contract. This contract will not only scan the blocks of Ether, but also update the entire data of Ether. Once this is done, it means that querying the state of Ether will not affect the state of Ether (mainly due to the fact that after EIP1559, the operation of smart contracts will burn ETH and the state of the whole network will change as a result.) On the one hand, ICP will run a node of ETH, and on the other hand, the real-time state of ETH will be synchronized on the ICP network.
Moving into phase 2 means that the cost of the ICP to call the contract on ETH and get the state is reduced to a very low position. At the same time, however, another issue emerges. Since ICP network-wide access to ETH state relies on the ETH nodes operated by the ICP network. Once a node goes down, then it poses a huge security risk. So can we build a node/smart contract dual interoperability system for gradual transition and progression? A gradual trade-off between efficiency and security is necessary to match the level of development of ICP.
ICP to ETH, mainly by way of subnet multi-signature creation of smart contracts.
Phase 1: ETH returns ICP data, uses ETH smart contracts to obtain the specific state of the ETH block, and then returns it. Phase 2: ETH returns ICP data, creates Canister in ICP to synchronize the complete information of ETH nodes, evolves from phase 1: learning information from smart contracts on ETH (interoperation) to phase 2: learning information from smart contracts on ICP to synchronize ETH nodes (interoperation).
The first phase focuses on the cost of interoperability, and the second phase focuses on security. The trade-off between cost and security to make a better interoperability solution is a potential development direction.
Posted by:CoinYuppie，Reprinted with attribution to:https://coinyuppie.com/dfinity-and-ether-interoperability-insights-how-to-interact-what-are-the-potential-opportunities/
Coinyuppie is an open information publishing platform, all information provided is not related to the views and positions of coinyuppie, and does not constitute any investment and financial advice. Users are expected to carefully screen and prevent risks.