How to capture the maximum value of lightning network + smart assets?

OmniLAB中文社区

特邀专栏作者

2020-04-15 14:45 (UTC+8)

This article is about 6325 words, reading the full article takes about 10 minutes

A new era of digital asset circulation & commercial applications.

AI Summary

Expand

A new era of digital asset circulation & commercial applications.

lead

The Lightning Network is a Layer 2 solution based on Bitcoin. It aims to realize instantaneous and small-amount payments through off-chain channels, release the resource pressure of the main chain, and improve the overall performance of the blockchain network. It is distributed in many countries and regions around the world. Developed by several teams at the same time, it is currently one of the most successful expansion solutions in the global blockchain industry, and it is also one of the most critical DeFi infrastructures.

As we all know, the current Lightning Network only supports BTC and does not support the circulation of custom smart assets. And even BTC is only a payment function, which cannot meet the needs of DeFi applications at all.

To this end, based on the basic principles of the Lightning Network, the Omni Specification Committee formulated the OmniBOLT standard, which is the world's first smart asset circulation standard within the Lightning Network and the second major protocol launched by the Omni Specification Committee after OmniLayer. The Omni specification committee is famous for launching the OmniLayer protocol, which is the world's largest digital asset distribution platform and is currently supporting the operations of more than 20,000 blockchain companies around the world.

For the first time, OmniBOLT connects all public chains and related assets to channels designed according to the principle of Lightning Network, allowing them to interact within the Onion Network, which will greatly enhance the interactivity of each public chain. OmniBOLT is built on top of OmniLayer. Because it supports smart assets at the basic level, it not only supports fast payment of BTC, but also has the following significant advantages:
Fast payment of smart assets based on OmniLayer.
Cross-channel atomic swap of different assets.
A decentralized exchange built on Lightning Channel.
Mortgage loan contract based on atomic swap.
More applicable DeFi (Decentralized Finance) smart contracts. Interested readers can visit Chapter 6 of the OmniBOLT specification:

(https://github.com/).

Mortgages, Online Stores and DEXs

1 Lightning Network & OmniLayer

Based on the basic theory of Lightning Network, OmniBOLT describes how to transfer assets on OmniLayer between lightning channels, and how assets on OmniLayer benefit from the new fast payment theory. OmniBOLT is not limited to the circulation support of BTC, and OmniBOLT is a great expansion of the basic theory of Lightning Network to support a wider range of asset circulation, and realize more applicable complex contracts through multi-token atomic swaps. It is also more capable of effectively supporting real-world applications.

OmniBOLT itself does not issue any tokens. All tokens are issued on OmniLayer and enter the OmniBOLT network through a channel supported by P2(W)SH. Related assets are locked on the main chain and can be redeemed on the OmniLayer main chain at any time.

2 Explanation of key concepts

OBD: OmniBOLT Daemon, OmniBOLT daemon process.
Channel: The channel refers to the Poon-Dryja channel in the Lightning Network. The channel consists of [Alice, USDT, Bob], which means Alice and Bob create a channel and recharge with USDT.
Asset (property): Refers to the token issued on OmniLayer, which is equivalent to "asset".
Sequence Maturity Revocable Contract (RSMC): Revocable Sequence Maturity Contract is used to punish malicious nodes that broadcast old transaction commitments to obtain more balance than their original balance.
Hashed Time-Lock Contract (HTLC): Hashed Time-Lock Contract links multiple channels for transferring tokens from two nodes without direct channels.
Commitment Transaction: Refers to those transactions that are created but not broadcast, and may be invalidated when the next Commitment Transaction appears.
Evil Punishment Transaction BR: Breach Remedy is used in the sequence expiration revocable contract, if Alice cheats by broadcasting the old transaction, BR will send all her funds to Bob.
Revocable payment transaction RD: When Alice broadcasts the latest legal transaction commitment, RD pays from the 2-2 P2SH transaction output. It will send money to Bob immediately, and it will send money to Alice after a relative value to the current block height (for example, 100 blocks).
HED: HTLC Execution Delivery, HTLC executes payment transactions.
HBR: HTLC Breach Remedy,HT: HTLC timeout transaction transaction
HTRD: HTLC Timeout Revocable Delivery,Evil punishment transaction
HTBR: HTLC Timeout Breach Remedy,HTLC timeout can revoke the payment transaction
HTLC Timeout Evil Penalty Transactions are used to punish parties that broadcast old hashed timelock transaction information during the timelock period.
HTLSC: Hashed TimeLock Swap Contract,Atomic Swap Atomic Swap: Atomic swap technology enables transactions between tokens without the need for a centralized medium, such as an exchange.

The hash time-locked exchange contract consists of two separate sets of hashed time-locked contracts as well as specific token exchange rates and time locks.

3 The contract can be canceled when the sequence expires

In order to prevent malicious parties from refusing to sign any P2SH transactions, causing the other party's funds to be permanently locked in the channel, we have constructed a commitment transaction that can be canceled, that is, the Revocable Sequence Maturity Contract (Revocable Sequence Maturity Contract). The sequence expiration revocable contract introduced here was first invented by Poon and Dryja and published in the first white paper of the Lightning Network.

The message "funding created" does not mean that any funds have been deposited into the channel by both parties. The first round of communication only created a P2SH address, constructed an RSMC transaction but did not broadcast it. Alice and Bob can then broadcast a funding transaction to transfer real Omni assets into the channel.

The diagram below represents what we have to do before broadcasting a deposit/commitment transaction. BR1a (Breach Remedy) does not need to be created immediately and can be created before the next commitment transaction is constructed.

In summary, RSMC consists of the following five steps:

Step 1: Alice uses the temporary private key Alice2 to build a temporary 2-2 multi-signature address, and waits for Bob's signature: Alice2&Bob;

Step 2: Alice constructs a commitment payment C1a from Alice & Bob, one output points to Alice2 & Bob's 60USDT, and the other output points to Bob's 40USDT.

Step 3: RD1a is the first output of the C1a transaction, paid to Alice 60USDT. But the RD1a transaction has a delayed sequence value to prevent Alice from paying her 60USDT immediately when she cheats.

Step 4: Bob signs C1a and RD1a and sends them back to Alice

Step 5: OBD constructs a redemption transaction: C1a/RD1a

The diagram above shows a commitment transaction taking place within a channel, demonstrating how the state within the channel transitions.

"4 Hash Timelock Contracts"

-- Poon & Dryja, The Bitcoin Lightning Network: Scalable Off-chain Instant Payments

Bi-directional payment channels allow funds to be securely transferred within only one channel. In order to build a multi-channel network and use multi-hop methods to safely transfer funds to the destination, an additional contract needs to be constructed: the hash time-locked contract.

Alice ---(10 USDT)---> Bob ---(10 USDT)---> Carol ---(10 USDT)---> David.

A common misconception when using HTLC for transfers is that if Alice wants to pay David 10 USDT, she can reach David in two hops:

[Alice --(10 USDT)--> Bob] ==(Bob has two channels)== [Bob --(10 USDT)--> Carol] ==(Carol has two channels)== [Carol --(10 USDT)--> David]

[A, USDT,This is confusing because there is no concept of personal accounts in the Lightning Network. The only fundamental building block available in the Lightning Network are channels. So the correct jump is this:

B] represents the channel created by A and B, and recharged with USDT.

Alice transfers 10 USDT to Bob in the channel [Alice, USDT, Bob], then Bob transfers 10 USDT to Carol in the [Bob, USDT, Carol] channel, and finally Carol transfers 10 USDT to David in [Carol, USDT, David] .

>The purpose of designing HTLC is to ensure that the intermediate channel will not withhold money and not transfer it to the next channel. So only when the receiver in the channel presents the correct key (or Hash preimage), he can get the money, and in order to get the correct key, he must pay the key holder the same amount of money in another channel . The specific process is as follows:

If Bob can give Alice R, this R (the original image of Hash(R)) Carol has given to Bob when Carol made a 10 USDT transaction in the channel [Bob, USDT, Carol] 3 days ago, then Bob will receive from the channel [Alice, USDT, Bob] received 10 USDT funds. If Bob cannot give Alice R, 10 USDT will be returned to Alice.

When using HTLC for fund transfer, [Alice-(10 USDT in HTLC)->Bob] is the output of an additional recharge transaction, an unbroadcast transaction tied to RD1a/BR1a.

5 Cross-channel multi-asset atomic swap

Generally speaking, atomic swaps occur between different blockchains, exchanging tokens without trust, and ensuring that neither party to the transaction has the opportunity to cheat. Channels in OmniBOLT can be recharged with any asset issued by OmniLayer. If someone needs to trade their tokens, such as USDT/BTC, both parties need to use a cryptographic hash formula to know the receiver of USDT and BTC within a certain period of time. If one of the parties involved fails to confirm the transaction within a certain period of time, the entire transaction is canceled and the relevant funds are returned to the original account. This removes counterparty risk from the transaction.

- where Tx 1 transfers 1000 USDT to Bob in channel `[Alice, USDT, Bob]`, locked by Hash(R), t1 and Bob's signature.

- Tx 2 transfers 1 BTC to Alice in channel `[Alice, BTC, Bob]`, locked by Hash(R), t2(`t2 < t1`) and Alice's signature .

.The standard exchange program between channels is shown in the figure below

The hash time-locked exchange contract consists of two separate sets of hashed time-locked contracts as well as specific token exchange rates and time locks.

As shown, there are 5 steps in a swap contract. In step 3, Alice enters R in the [Alice, BTC, Bob] channel to unlock transaction 2 to get her 2 BTC in [Alice, BTC, Bob]. Therefore, Bob also gets R, and uses R to unlock his 900 USDT in the channel [Alice, USDT, Bob].

If Alice never enters R in the [Alice, BTC, Bob] channel and does not take her money, then when the time comes, the transaction will be cancelled, and the money on both sides will be returned separately, and neither party will suffer losses.

After inputting R into each channel, transactions 1 and 2 become (turn into) general commitment transactions, which is the same as the process of converting HTLC into commitment transactions.

At the same time, Bob creates another HTLC in another channel [Alice, BTC, Bob], and its mirror transaction on Alice's side, sending the agreed amount of BTC to Alice. Timelock t2 is set to 2 days, less than t1 = 3 days.

Atomic swaps are the basis of many blockchain applications. The next chapter will present more examples, which will be more intuitive and help developers build more complex use cases for the real business world.

6 Applications: Mortgages, Pet Stores, and More Possibilities

The following example uses a multi-level atomic swap for specific scenarios. The relevant process will be executed by a program written in a Turing-complete language (such as Javascript or Solidity), and the OBD API will be called to complete the basic tasks. All participants will run programs to check that all transactions are valid and that the parties involved are honest.

（Collateral Lending Contract）

Mortgage loan contract

Mortgage lending serves the following specific purposes:

“You deposit something of value as collateral in an escrow account and I lend you a loan based on the appropriate LTV (Loan to Value). If you repay by the agreed date, I will return your collateral. If not , your collateral will belong to me."

In effect, an HTLSC creates escrow accounts for the parties in the loan. We assume the following scenario:

Bob wants to borrow 900 USDT from Alice, and he uses 1 BTC as collateral.

Bob initiates an exchange contract (HTLSC 1)

Bob---"Alice: exchange contract (1BTC, asset is USDT, exchange rate is 900, time lock is 30 days, Hash (R1),...)

This creates HTLSC in the channel [Alice, BTC, Bob].

Alice---"Bob: The exchange contract received (the amount is 900 USDT, the exchange rate is 900, the time lock is 20 days, Hash (R1),...).

At the same time, Bob needs to create a redemption contract (HTLSC 2 ) in order to get back his 1 BTC in the future.

Bob --- "Alice: exchange contract (the quantity is 900 USDT, the asset is BTC, the exchange rate is 1/900, the time lock is 60 days, Hash (R2),...).

Alice---"Bob: Exchange contract received (amount is 1 BTC, exchange rate = 1/900, time lock is 50 days, Hash (R2),...)

This creates HTLSC in the channel [Alice, BTC, Bob].

Only after the parties receive both swap contracts and their OBDs help create all corresponding transactions required by HTLSC, Bob can use R1 to get his 900 USDT in the channel [Alice, USDT, Bob] via HTLSC 1 , so Alice gets 1 BTC from Bob as collateral.

After some time, Bob wants to redeem his 1 BTC. He uses R2 in HTLSC 2 to redeem his 1 BTC via HTLSC2 in [Alice, BTC, Bob] channel, so Alice gets her 900USDT in channel [Alice, USDT, Bob].

Of course, Alice can set the exchange rate based on the price of BTC. For example, she can ask Bob to create an exchange contract with an exchange rate of 1/905. Then she will get 905 USDT when Bob redeems the BTC.

online pet store

The pet store application only uses one-stage atomic swap:"PET"Alice uses Omnilayer to publish a release called

assets, each PET represents an encrypted cat.

Bob and Alice establish a USDT channel and a PET channel, and recharge in the USDT channel.

Bob creates HTLSC to pay Alice 100 USDT in exchange for an encrypted kitty.

It's easy :-)

In practice, Alice and Bob don't even need to establish a direct channel. By using HTLC, you can borrow other people's channels for exchange.

7 Wallet Implementation & Official API

https://github.com/omnilaboratory/OmniBOLT-spec

OmniBOLT specification official address:

https://github.com/omnilaboratory/obd/

Implementations of the OmniBOLT specification can access the official repository: