OTX Scenarios on Nervos CKB
I believe that the first step to design a protocol should be thinking about the scenarios where it will be used. Nervos CKB is the security anchor of a layered system, it supports UTXO like transaction structure and Turing complete VM through lock script and type script. This transaction schema is much more complex than Ethereum, but it also enables more possibilities.
Here I list some possible scenarios that may need open transaction technology. Thanks to the advanced framework of CKB, none of the following examples requires a system upgrade.
Flexible Transaction Fee Charge Model
Most of the blockchain systems only support native token as transaction fee payment. Bonding native token value to transaction fee is not a pefect economic model, because transaction fee is essentially pay-for-priority model instead of pay-for-usage model. Besides, it is weird to request ordinary users to buy a little native tokens as “gas fees”, no matter how much other assets the users have or how eagerly the dApp operators want to pay it for their users.
In this demostration, Alice (who initializes OTX#0) holds 100 USDT and transfer 20 of them to Bob, with 80 USDT as change. Alice has no native tokens to pay for the transaction fee. However, another guy who wants to give a subsidy to this transaction could append OTX#1 to provide sufficient native tokens, and these two open TXs combines to a fully verifierable TX with fee for miners.
For more common circumstances, Alice is not so lucky, she has to pay the transaction fee herself. Remember she has no native tokens for mining fee? She simply subtracts 1 USDT from her change, and leave it to anyone who append enough native tokens for transaction fee. Another user, or miner, could add an open transaction to provide the fee, and take the USDT as compensation.
Ethereum Like Smart Contract Invoking
Every transaction on Nervos CKB is deterministic. Clients have to assemble a transaction with output state well prepared. Under some circumstances, it is not very convenient, especially for the smart contracts that manage shared states.
In the demostration above, Alice and Bob sign two open transactions, with their personal state cell and their purposes in witness field. Let’s say they are interacting with Uniswap like DEX, the user state cells store their deposit infomation, and the function arguments in witness filed store their operation commands. The operation commands will modify the global state as well as their own states. So if everyone sends transactions to modify it separately, they will compete the control right of the global state cell, which is inefficiency. With open transaction, Alice and Bob send their state cell and purposes, the operator, miner or anyone else could combine them into one transaction, and calcuate the result, update users and global state. This will dramatically decrease network traffics and improve user experience.
Layer 1.5 DEX
OTX could be used to join users’ token exchange requests, and complete them with one transaction. As shown above, Alice and Bob wanna exchange 700 CNYT with 100 DAI, and 70 USDT with CNYT. Some broker notices these OTXs, and believe there’re profit. So the broker complements the transaction with necessary inputs and outputs, fulfill other’s demands, and earn the margin.
Assets Discounting
Discounting is the process of determining the present value of a payment or a stream of payments that is to be received in the future. Take deposits in NervosDAO as an example, they cannot be used until unlock, but their owner could sell the future withdraw rights for present value.
In this example, the deposit owner will receive 1.1M tokens in the future, but the owner needs the token immediately. So the owner posts an OTX to claim only 1M CKB right now. If someone else think it’s profitable, the guy could complete this transaction, send 1M tokens to the deposit owner and take the deposit (with extra 0.01M CKBytes as transaction fee).
Deposit UDT to Exchange
UDT data structure on CKB is included in cell’s data field, and you need CKBytes to provide store capacity. So when users deposit UDT to exchange, the simplest way is to create a new cell, write deposit amount into the cell data field. This will cost user’s extra CKBytes. In this thread CKBytes in UDT transfer, Jan suggests an OTX based method to figure out this problem. Here I make a little modify to his method to avoid frontrunning attack.
In this demostration, Bob and Clare deposit 220 and 1000 USDT to exchange, and they need their CKBytes capacity back. Both Bob and Clare’s OTXs require a cell with exchange’s lock as input, so that exchange could collect the deposit, and no one else could replace it.
Requirements That OTX Protocol Should Meet
According to the analyzing of the typical scenarios, we can achieve this conclusion, that the OTX protocol on CKB should have the ability to describe the constrains to input/output, witness, and specific field of a cell. Which is Scope Level 2 defined in Open Tx Protocol Brainstorm: (2) Design a Practical Protocol on CKB. It seems that we needn’t a Scope Level 3 protocol.
And we need the description of constrains to be composable and anti-frontrunning. I will give a proposal that may work on CKB in the next article.