1. Introduction
Due to the off-chain determinism of the Cell model, even if the dependent cell is not confirmed, a chained transaction can be constructed and then quickly submitted to the transaction pool without waiting.
This is useful in many scenarios, for example, many people accuse “AMM in the blockchain of the UTXO model can only have at most one transaction per block”, but this is not correct, when Layer1 guarantees the validity of the transaction, but the transaction ordering is handled by another consensus mechanism (PoS), the AMM experience for UTXO can be as smooth as the account model.
I have a rough look at the transaction verification code of ckb. ckb supports transactions referencing cells in the pending state, which makes it possible to use this cell immediately without waiting for a new cell to be generated, so that the transaction does not need to block to wait for the confirmation of the previous transaction.
To verify ckb’s support for chained transactions, I used rust-sdk to send many chained transactions to ckb node in testnet, but currently many checks of rust-sdk hinder this, I had to remove many checks and add some code, and finally successfully sent a non-blocking chain transaction on CKB.
In the following six transactions, the three input cells of each transaction depend on the output of the previous transaction, but they are packaged into the same block 5586924.
0xdf4e50350b325964177f66034dd9d348901d7e3f87c71e04f87eef5bcf1cf0e3
0x75860ab2c8214cef99d045683565a7e9321b5009c320ed01f8bd29041a566f3d
0x98fd512e5fe9ab4535a430e618cf73acf9ad0bb61f229b2cb5f2e020ba3bbc37
0xbaa24d56fef4f956b0725a23a8731fdd0512f0de4df76e82a57f242dfbcd7f7f
0x992f11a0bd81a2ab3a7f3ac045e6dbae885835f70422572daa8b1ca5bdcb7cc0
0x02d5c2005fe2a68a5b043764ac1ee3965c7baa6c2033951c83853202833f3742
In addition to the fact that rust-sdk is not well adapted to the construction and transmission of chained-tx, because the the input cell at least exists in the pending pool, I can only send transactions serially, which does not achieve perfect non-blocking.
2. Applications
2.1 Fee Provider
In some dApps, the service provider may pay the tx fee for all users. If the number of users using at the same time is greater than the number of cells currently available to the service provider, when Non-blocking chained tx is not used, some users may have larger delay, and with Non-blocking Chained Tx, even if only one cell provides tx fees, it can give users silky feedback.
2.2 NFT buying and exchange withdraw
When using the NFT platform, users may deposit a large amount of assets in a single cell for the purchase of NFTs. When chained tx is not used, if users quickly purchase multiple NFTs, it will appear that the account balance is sufficient but cannot be used, which will make users very confused and will greatly affect the experience of using the Cell model, while using chained tx will not Will have this trouble again. Just like using Metamask, Metamask caches the user’s nonce, so that the user can continue to send transactions to ETH without waiting for the completion of the previous transaction. Using ChainedTX has the same experience.
Another similar scenario is the withdrawal of the exchange. Since the exchange often collects funds, a large amount of funds often exist in a few cells. In addition to constructing multiple outputs within a transaction, ChainedTX can also be used to speed up withdrawals.
2.3 Global State
Although intuitively, the cell model has no global state, but after using chainedTX, if a certain consensus mechanism (such as DPoS, PoS) is adopted, the global state can be perfectly realized. Such a global state design can be a timestamp that an application depends on, or it can be a global state where users help the application calculate interest (for example, a ckb renting dapp).
2.4 Access List and account model
Through ChainedTX plus access list and an additional consensus mechanism, various account models can be simulated on the cell model, and there is no problem of “one block can only have one transaction”, which will enable Defi applications such as swap and lending available on layer1 for everyone to use.
2.5 Speed up rollup confirmation
For Layer 1.5 dApps and Rollup, since the transactions on them are decoupled from Layer 1, their block generation speed is often faster than that of Layer 1. Through ChainedTX, such applications can generate blocks without blocking, while there is no need to consider the block rhythm of Layer1.
At the same time, when the block is reorganized and the transaction is not replayed, this type of application can also use ChainedTX to speed up the confirmation speed of its block.
3. Suggestions
3.1 Optimize RPC methods
When testing ChainedTX, I can only send the next transaction after the previous transaction is verified, so that ChainedTX can only be verified serially, but this is not logically necessary.
If there is a send_chained_transaction rpc method that can send transactions in batches at a time, then these transactions can be verified in parallel, thereby speeding up the submission of ChainedTX. At the same time, if the application adopts such transactions on a large scale, it is also very good to optimize the broadcast of such transactions in the P2P layer, but adding an rpc method does not require a hard fork, so it is better to implement, while modifying the P2P layer may need to introduce hard fork.
3.2 ChainedTX friendly SDK
The current SDK, at least the Rust SDK I use, can’t successfully build ChainedTX. I don’t know if the SDKs of other languages are optimized at this point, but I think this is a very important feature, in order to allow dApps to use it, the SDK must first be well supported.
3.3 dApps should use chainedTx to optimize the experience
After the SDK supports ChainedTx well, dApps should try to adopt the design of ChainedTX to optimize the user experience. Of course, it stands to reason that this should be done by Signer, just like in the ETH ecosystem, nonce is cached in metamask.
