A CKB-efficient and Anti-Collision xudt Transfer Scheme on CKB L1

English CKB Development & Technical Discussion
, ,
1

Problem

As is well known, udt token scheme requires ~145 CKB to build the data structure. And there should be another 145 CKB to be provided to send tokens as the ‘receive box’. It is a significant burden from both user education and product design perspectives.

Anyone-can-pay lock is a good solution for the extra CKB spending. It allows sender directly modifies the receiver’s udt cell to add up the token without the interaction from the receiver. But the concurrency problem prevent ACP from wide usage: when more than one transfer happens at the same, only one transaction could be processed, the others will fail.

image
image1240×852 39.8 KB

Solution

A trivial solution to this problem is to prepare more acp cells from the receiver side. It will dramatically decrease the collision possibility. However, in most of the mass-adoption scenarios, users cannot afford lots of cells (more than $1 per cell).

We propose this acp-in-middle solution to this problem, which could solve it perfectly.

image
image2384×1062 208 KB

Here we prepare a number of “public relay cells”, which allows sender store udt temporarily. Then the decentralized seveice collect the cells and send tokens to the receiver periodically. All the public relay cells can be used to receive and store some tokens from any sender, the more relay cells exist, the less probabilitys occur.

The basic data structure of relay cells may looks like as follows.

// relay cells
data:
    amount
    target_lockscript
type:
    udt
lock:
    acp or modified_acp

The service provider collect the relay cells periodically, then send the tokens to the target lockscript in the ACP way. This hub-like design have lots of benefits.

  • Reduce cell collision probability, improvce user experience
  • Every user uses only one acp cell, reduce their account cost
  • Non-breaking change, application could use a plain acp solution at the beginning, then switch to non-contract based relay cell hub, and finally a contract-based trustless relay cell hub
  • Business opportunities for service providers, they can charge like 0.1% fee for every relay.
15 Likes
2

This solution might have one more benefit: Lower Barrier to Entry for New Users

For newcomers to the Nervos Network, not having any CKB initially is a common challenge. Creating an ACP (Anyone-Can-Pay) cell requires a minimum amount of CKB, which can be a barrier to onboarding-especially since each ACP cell can only hold a single UDT type. This limitation means new users need even more CKB if they want to receive multiple types of tokens, further increasing the entry hurdle.

With the relay cell scheme, a newbie can temporarily rent one or more relay cells from a provider to receive UDT without needing to own CKB upfront. This means they can start receiving and holding tokens immediately, and later, once they acquire some CKB/UDT, they can claim and move their tokens to their personal ACP cell. This makes the onboarding process much smoother and more user-friendly.

Note: The rent fee for a relay cell could be incorporated/defined as part of the relay cell provider’s service fee rate.

9 Likes
3

很高兴看到这样的探索，这显然是当前技术条件下正确的方向

任何生态中新用户的加入都可以总结为“技术层面的门槛”和“意愿层面的门槛”，而我们在技术上做的越细越多越深，意愿层面也会随之被影响，从而形成良性循环

其他没有什么好说的，只在关于中继提供者的回报这方面有一些参考建议，那就是除了收取的0.1%的代币回报，团队可以考虑给他们发送徽章也就是除了物质层面还可以从非物质或者说物质加精神层面给予他们回报和奖励

这个徽章可以设置成不可转移的（技术上我不确定但感觉cota应该能做到，成本上也可以接受）且分不同等级的（根据中继代币数量不断的升级）也就是提供中继服务的人除了获取代币的应有回报，还有对整个生态贡献的一张“奖状”（准确说是多张，从低级到高级慢慢解锁成就）

这个“奖状”是另外的一层认可，这是整个生态对他们付出的另外感谢，同时，这些奖状还可以作为后面有发币和空投项目的其中的一个参考（当然这个由发币的项目方自己决定）

这样就能在没有提高原有成本的情况下最大化的提高用户加入到中继服务商的动力，而这样的生态不断壮大，获益的会是生态中的每一个人

4

这个做出来以后在joyid会有acp地址吗？是否需要达到一定的ckbtes才能提取cell里面的资产？Will there be an acp address on joyid after this is made? Is it necessary to reach a certain ckbtes to withdraw the assets inside the cell？

1 Like
5

cool, the unique design of CKB requires middle services like this one to lower the barrier for new users. This is also a unique design space that can be explored for developers. Looking forward some very different products/services growing out from this!

2 Likes
6

JoyID lock can be upgraded when necessary.

7

What prevents the public relay cells from becoming clogged if tokens are sent to an ACP address with no live ACP cells?

@Flouse’s suggested use case for renting cells during new user on-boarding seems beneficial, but this could also lead to more congestion of available cells.

It seems like a stronger incentive to claim the assets is needed, such as asset forfeiture after a period of time if it remains unclaimed for too long.

3 Likes
8

IMO,
When the value in a rent cell exceeds that of an ACP cell’s capacity, the relay cell provider can release the rent cell, create an ACP cell for the receiver, and transfer the remaining assets to the target ACP cell.

When a rent relay cell holds insufficient value, an asset forfeiture model —where unclaimed funds can be recovered by providers once the value in the rent cell is insufficient to pay the service fee—is a viable solution.

Suppose a relay cell provider charges a rent fee higher than NervosDAO’s Annual Percentage Compensation (APC) (e.g., 3~30% per year). This creates clear financial incentives:

  1. Recipients are discouraged from leaving assets unclaimed, since they lose value faster than they would by simply store cell capacity in NervosDAO.

  2. Inactivity eventually leads to forfeiture, with unclaimed assets decreasing in value until insufficient to cover the rent fee, enabling providers to reclaim the cell.

  3. If the relay cell provider needs additional CKB to create more relay cells, CKB DAO depositors may be motivated to supply that CKB, because the rent fee rate charged by providers is higher than the NervosDAO’s annual yield. This creates a financial incentive for DAO depositors to support service growth by lending their CKB.

1 Like
9

I was thinking too around these lines, but then again, do we really want to add on-chain oracles for permission-lessy authorize forfeiture?

Not only that, it also means binding a specific oracle vendor to a common protocol.

Additionally, this protocol is easy to DoS: an attacker can just send the bare minimum assets required to fill up these cells (3% -30% of cell value) and leave it there until forfeiture. New cells added, new asset sent until forfeiture.

When considering everything needed for a working prototype, it seems an over-complicated design.

Conversely, in the Rosen Bridge integration I’m aiming for the following:

  • CKB → OUT: User sends UDT to Bridge’s ACP, Bridge maintain a pool of them which it owns
  • OUT → CKB: Bridge sends UDT to user address (non-ACP usually), CKB is factored in as network fee

Say CKB price raises to over 1 USD we can always re-implement UDT transfers in the Rosen Bridge integration. Ideally new Token protocols will emerge in the meantime.

In this regard, my idea is that in the future a token standard will emerge that allows its token cells to be represented in two ways:

  • UDT: sUDT-alike for backward compatibility
  • non-UDT: a state rent aware representation

UDT cell representation can be transformed permissionlessy into non-UDT cell representation and backward.

This with a couple more ideas, I call interphase UDT or iUDT.

Love & Peace, Phroi %42

10

could these issues be resolved by abstraction?

It sounds like this kind of system is already getting kind of complicated already, would tasking an application with structuring deposit/withdrawal proofs be reasonable?

1 Like