Non-blocking Chained Transaction and its applications in CKB

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.







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.

1 Like

1. 介绍











2. 应用

2.1 手续费提供者

在某些应用中,应用服务商可能会为所有的用户代付手续费,如果同时使用的用户大于服务商当前可用的Cell数,在不使用Non-blocking Chained Tx时,对于某些用户可能会有较大的delay,而借助Non-blocking Chained Tx,即使只有一个cell提供手续费,也可以给用户丝滑的反馈。

2.2 NFT购买和交易所提款

在使用NFT平台时,用户可能会一次往平台地址充值大额资金,存储在单个Cell内,在未使用Chained TX时,用户快速购买多个NFT,将会出现令用户十分疑惑的现象,明明账户余额充足,当前却无法使用,这将大大影响Cell模型的使用体验,而使用了Chained TX则不会再有这个困扰。就像在使用Metamask一样,Metamask缓存了用户的nonce,从而使用用户无需等待上一笔交易完成,即可持续往ETH发送交易,使用ChainedTX拥有同样的体验。


2.3 全局状态


2.4 访问列表和账户模型

通过ChainedTX加上Access List以及一个额外的准入机制,可以在Cell模型上模拟各种账户模型,同时并不存在”一个区块最多一笔交易“的问题,这将使得swap、借贷等多种Defi应用可以存在于Layer1上。

2.5 加速Rollup的确认



3. 建议

3.1 优化RPC方法


3.2 Chained Tx友好的SDK

目前的SDK,至少我使用的Rust SDK并不能成功构建出ChainedTX,我不知道其他语言的sdk是否在这一点上做了优化,不过我觉得这是一个很重要的特性,为了能让Dapps使用上,SDK必须首先支持得很好才行。

3.3 dApps应采用以优化体验


1 Like

Agree. I think off-chain transaction chain construction is a very useful pattern for CKB dapps. RPC and SDK developers should keep this use case in mind and provide support for chained transactions construction and broadcast.

If CKB can loosen the check in send_transaction and allow the transaction to refer to the cells in the transaction pool (off-chain transaction), it could solve parts of the problem. But CKB may need to take more care about miner’s strategies regarding how to order or choose transaction in each block period

CKB already allows refer to cells in the transaction pool, and I have constructed such transaction samples in the article. But to fully utilize this design requires more support.