Abstract As the booming of BlockChain technology, the requirement of asset transfer between different ledgers is as imperative as possible. as the kernal of the value network, the technology about inter ledgers is more and more important。On studying the Interledger Protocal given by the ripple company, we give the core point and introduce the trasaction flows, moreover, we list some scene compatible to the ILP technology.
Keyword BlockChain ; InterLedger; hold; ILP; ripple; Interledger Protocol; ledger
Abstract With the widespread emergence of blockchain networks, the need to realize the value conversion of encrypted electronic currency between different networks has become strong, and the cross-chain technology as the core of the value network has become more and more important. This paper analyzes the Interledger Protocol proposed by Ripple in detail, explains the core points and usage methods of the protocol, and lists certain application scenarios combined with the advantages of Interledger Protocol.
Key words blockchain; cross-chain; custody; ILP; Ripple; Interledger Protocol; ledger;
1. Background
Since the birth of Bitcoin, more and more blockchain networks of encrypted digital currencies have formed a vigorous development trend. However, in the transfer and exchange of value between different blockchains, various problems will be encountered. For example, Alice has "Bitcoin" and wants to buy Bob's laptop through "Bitcoin". The laptop is priced in "Ripple" and does not accept "Bitcoin". At this time, Alice has to find a way to exchange the "Bitcoin" in her hand for "Ripple Coin" through a certain exchange, and then pay Bob. The process of this transaction should be: first, Alice sells "Bitcoin" to get USD, and then uses USD to buy "Ripple". There will be a problem in this process - currency price stability, currency price stability Instability will lead to loss of value, and the transaction process is also cumbersome and the cycle is too long. It is precisely in response to such a problem that ripple proposed a technical protocol InterLedger Protocol (hereinafter referred to as ILP) for cross-chain value transmission.
2. Introduction
The ILP creates a system in which two different ledger systems can freely convert currencies to each other through a third-party "connector". The ledger system does not need to trust the "connector", because the protocol uses a cryptographic algorithm to create fund escrow for the two ledger systems and the connector, and when all participants reach a consensus on the funds, they can trade with each other. ILP removes the trust required by transaction participants, and the connector cannot lose or steal funds, which means that such transactions do not need the protection of legal contracts and excessive auditing, which greatly reduces the threshold.
The core idea of the ILP protocol is that the third party provided by the "ledger" will assure the sender that their funds will only be transferred to the connector when the "ledger" has received proof and the receiver has received the payment; The third party also guarantees the connector that they will receive the sender's funds once they have completed the final part of the agreement.
The blockchain is technically a decentralized database and distributed ledger technology, and is a value network from a business perspective. In this value network, the more effective nodes are connected and the more distributed, the greater the possible value superposition will be. Blockchain is the core infrastructure of the value network space. In order to allow this infrastructure to be interconnected and freely transfer value, we need cross-chain technology to connect and expand different blockchains and build a highway of value networks. .
3. Ledger
If each "ledger" wants to use ILP technology to convert value with other blockchains or "ledgers", it must meet certain basic conditions, in order to better exchange the tokens issued by itself with other electronic currency coins, so as to facilitate the exchange of tokens. accepted by the public.
1. You must support the transfer operation from an account managed by your own "book" to another account managed by your own account;
2. It is necessary to support escrow-style transaction operations. This type of transaction requires two necessary parameters: a "pre-image condition" for executing "custodial" transactions and a "timeout time";
3. Any user, not limited to the creator of the "custodial" transaction, can decide whether the "custodial" transaction is executed or rejected when the "pre-image condition" of the "custodial" transaction is provided;
4. If the "custodial" transaction times out after it is created, the "custodial" transaction will automatically become invalid, and the custodial currency in the "custodial" transaction will be re-entered into the account of the creator of the "custodial" transaction;
5. The transactions supported by the "ledger" need to have the ability to carry short messages;
6. The "ledger" supports the event notification function, so that all parties can know in time that there is a "custodial" transaction against themselves.
4. Process
4.1. Overview
The entire transaction process is divided into two main processes: "sender--->receiver" and "receiver--->sender". Each process in turn consists of various sub-transactions ("escrow creation" and "escrow confirmation") that occur on various "ledgers". The "sender--->receiver" process is all the creation action of "custody", and the "receiver--->sender" is all composed of the confirmation action of "custody".
From the figure, we can see that before the receiver confirms the "escrow" transaction on "ledger N", all the "custodial" transactions created on the "ledger" are not confirmed. The source account specified in the "custodial" transaction does not actually transfer its own assets, but is managed by the "ledger" system. Only after the receiver confirms, in the return process of "receiver--->sender", each "custodial" transaction will be confirmed, and the target account specified in the "custodial" transaction of each "ledger" will be The assets of the source account are truly obtained, and the value of the assets is truly transferred.
In the entire chain of transactions, the transactions on each link are in a "custodial" state before being confirmed, and no value transfer occurs. Even if the connector destroys the transaction, such as sending the transaction to another address, the sender will not suffer any loss, because the last hosted transaction will not be executed. After the timeout condition is met, the assets in the transaction will be returned to the source account.
When a recipient is notified of a "custodial" transaction involving their own account, the recipient confirms the transaction details to determine if the transaction is correct, then provides a pre-image of the conditions specified by the "custodial" exchange and sends the "ledger" system " Escrow confirmation" operation, the recipient actually gets the required encrypted electronic currency. Next, each connector in the entire transmission chain uses the same "conditional preimage" to "custody confirmation" for its own "custodial" transaction, and finally each connector receives its due asset value.
A noteworthy detail is that each "connector" must set a timeout period smaller than the timeout period set in the "hosted" transaction that it receives when creating the "custodial" transaction sent by itself, so that it can obtain the conditions for itself. When the original image is created, there is time to perform the confirmation operation of the "custodial" transaction received by yourself, otherwise the "custodial" transaction created by yourself will be confirmed by the receiver or other connectors, but it is too late to confirm that it "belongs" to yourself "custodial" transactions, resulting in losses. In other words, the asset was transferred to another account on "Ledger B", and the corresponding asset was not confirmed on "Ledger A", resulting in asset loss.
4.2. Steps
We use the scenario proposed at the beginning of this article to describe the detailed steps of the entire transaction:
Object: sender--Alice, receiver--Bob, connector--Cot.
Ledger relationship: Alice owns the bitcoin account, Bob owns the ripple account, and Cot owns the bitcoin and ripple accounts.
Scenario: Alice wants to buy Bob's laptop from the Internet, priced at 29230 ripples.
1. Alice obtains a "shared password" provided by Bob through instant messaging software or other means of communication. Communication must be encrypted, so that after communication, only Alice and Bob know the "shared password"; at the same time, Bob will tell Alice his unique address in the ILP network, such as g.ripple.rHCvhtqhXuBvWt5g79gyXfpG8VcrvUm9E9 .
2. Alice goes to Cot to inquire about the price and asks how much BTC she needs to send 29230 ripple coins. At this time, Cot will calculate the need for 1 Bitcoin according to the real-time BTC and ripple market prices, and Cot will charge an extra 0.00001 BTC as a procedure The final inquiry result obtained by Alice is: 1.00001 BTC needs to be paid to Cot.
3. Alice generates the required ILP package according to the message format specified by ILP. The ILP package specifies the destination address as Cot, and generates a "conditional preimage" based on the private content of the ILP package and the "shared password". ” hashes to get the “conditions” of an “escrow” transaction.
4. Alice initiates a "custodial" creation operation on the Bitcoin ledger system, sets the "custodial" condition and a timeout period in step 3, and sets the ILP package at the same time.
5. Cot detected a "custodial" creation operation involving itself on Bitcoin.
6. Cot parses the ILP package, calculates that it should transfer 29230 ripple coins to Bob, and modifies the target address in the ILP to Bob.
7. Cot initiates a "custodial" creation operation on the ripple ledger system, sets the "custodial" condition in step 3 and a timeout period, which is smaller than the timeout period in step 4, and sets the ILP package at the same time.
8. Bob detects an "escrow" creation operation involving himself on ripple.
9. Bob parses the ILP package and uses his "shared password" and the private content in the ILP package to generate a "conditional preimage" and the corresponding "condition". Confirm the "custodial" transaction: accept or reject by comparing whether the "condition" carried in the "custodial" creation transaction is the same as that generated by yourself, and verifying whether the number of assets specified in the "custodial" transaction is 29230. We assume reception here.
10. Bob initiates a "custodial" confirmation operation on the ripple ledger system, sets the "conditional preimage", the "custodial" transaction on the ripple ledger is completed, and Bob receives 29230 ripple coins
11. Cot detected an "escrow" confirmation operation involving itself on ripple.
12. Cot analyzes the content of the "custodial" confirmation operation and obtains the "conditional preimage".
13. Cot initiates a "custodial" confirmation operation on the bitcoin ledger system, sets the "conditional preimage", the "custodial" transaction on the bitcoin ledger is completed, and Cot receives 1.00001 BTC.
14. Cot detected an "escrow" confirmation operation involving itself on bitcoin.
4.3. Hosting
From the transaction process, we can see that ILP is the realization of each sub-transaction using the "custody" function provided by each ledger.
As we can see from the diagram, there are four main steps in the "custodial" transaction
1. Preparation: Nothing happened at this time, only the necessary data was prepared.
2. Creation: Assets belonging to an account on a “ledger” system are “escrowed”.
3. Confirmation: The "custodial" transaction is completed and the assets are transferred from one account in the "Ledger" system to another account.
4. Rejection: The "custodial" transaction is cancelled and the asset is returned to the source account of the "ledger" system.
The main features of the hosting function are as follows:
1. After the "escrow" transaction is created, the sender's assets are not actually transferred.
2. "Escrow" transactions cannot be reversed or cannot be reversed within a certain period of time.
3. Anyone who knows the "pre-conditions" listed in the "escrow" transaction can make the "escrow" transaction confirmed, without the need for the sender to perform the final confirmation of the "escrow" transaction.
4. Anyone who knows the "pre-conditions" listed in the "escrow" transaction can reject the "escrow" transaction, and it is not necessary for the sender to perform the rejection of the "escrow" transaction.
5. The "custodial" transaction can set a timeout period. If no one performs the "confirm" operation or "reject" operation within the specified time, the "custodial" transaction will automatically become invalid.
The "custodial" transaction is a prerequisite for the realization of ILP. There are various ways to realize the "custodial". It can be the function of the "ledger" itself, or it can be realized by a third party trusted by both parties. Only by means of "custody" can the interests of all parties be guaranteed from being infringed.
5. Safety
ILP uses a "conditional" transaction to ensure the security of asset value when it is transferred between various "ledger" systems. The sender uses a cryptographic proof to ensure that the sent asset is either received by the receiver or returned to the The sender's account. in the whole process. The connector may suffer a certain loss, but this risk is basically controllable, and the risk is only related to the ledger system selected by the connector and the directly connected nodes.
5.1. Connectors
In the ILP protocol, the connector is an important role, supporting the entire cross-chain network, so that the cross-chain asset exchange can be carried out normally. The reason why the connector is motivated is that a certain fee will be charged in the process of providing asset conversion, just like the commission charged by the market maker to obtain income.
However, in this process, the connector has certain risks. When the "custodial" transaction sent by the connector is successfully confirmed, but the "custodial" transaction that he received has not been confirmed in time, it should have been sent to himself. The assets will be returned to the address of the source account, causing certain losses.
When the connector fails to confirm the transaction sent to its own escrow in time, it can only rely on the sender to send the same “escrow” transaction with the same execution “conditions” again. When the connector gets the “escrow” transaction , confirm the new transaction with the "conditional preimage" recorded last time.
In order to make the sender willing to resend the expired transaction, it is necessary to give certain rewards to the sender, such as lowering the commission and prioritizing asset conversion, etc.
5.2. Problems
1. Will the receiver reveal the "conditional preimage" without confirming the "escrow" transaction involving itself?
If the receiver is normal, this phenomenon will not occur, because in this way, its own rights and interests will not be guaranteed, which will cause the sender to have sent the asset and the receiver cannot receive the asset. In this case, the receiver should be held responsible.
2. Will the recipient only confirm the other party's "escrow" transaction without publishing the "conditional preimage"?
No, one of the necessary parameters for an "escrow" confirmed transaction is the "conditional preimage", as long as the "escrow" transaction is confirmed
This transaction can be viewed on the Ledger system, resulting in a "conditional preimage".
3. What should the sender do when the sender fails to re-send when the sender fails to confirm the "escrow" transaction involving itself in the future?
No way, really can't avoid this problem.
4. When there are multiple connectors between the sender and the receiver, if the first connector gets the "conditional preimage" before the second connector, will it cause losses to the second connector?
No, because the "escrow" transaction created by the first connector cannot be cancelled for a certain amount of time, as long as the timeout expires
After the second connector gets the "conditional preimage" within that time, it can confirm the "escrow" transaction involving itself.
5. Who can be the connector?
Any individual with more than 2 "ledger" system accounts can be a connector.
6. Core
Throughout this article, we have found that ILP does not create a unified "ledger" system, nor does it require participating parties to trust any individual or institution, but relies on existing, existing "custodial" transactions to ensure The interests of all parties, what did the ILP actually do?
ILP proposes a method for cross-chain asset transfer, but it is first an agreement. The core of the agreement lies in the following two points:
1. Determine the address rules of each account on each "ledger" system, that is, determine whether an account belongs to a certain account within a certain scope through a hierarchical relationship.
For example, g.ripple.bob represents an account bob on the public chain ripple
2. Define the message transfer format in cross-chain transactions, so that the sender, receiver, and connector can use the same message format to transfer information to confirm the receipt of the message and get their own target address.
The core point 1 enables each sub-transaction in the transaction process to determine the transferred account, and the core point 2 enables all parties to use a unified format for message transmission.
7. Application scenarios
1. Pay in the form of encrypted electronic currency B when only owning encrypted electronic currency A;
2. Have accounts with different encrypted electronic currencies, and want to convert the value of currencies between accounts belonging to different "ledgers";
3. Value exchange of the same type of currency between different private chains under the same group.
8. Summary
This paper systematically introduces Interledger protocal, and at the same time fully explains the detailed process of the entire ILP transaction in the form of an example, and conducts an in-depth analysis of the security performance in the transaction process. According to the technical characteristics of ILP, this paper also gives some typical examples of it. application scenarios.
references
1. http://blog.csdn.net/elwingao/article/details/53410750 Gao Zhihao
2. https://interledger.org Ripple Corporation