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.
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.
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.
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.
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).
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.
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.
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.
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.
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.