iCKB journey into CoBuild

English CKB Development & Technical Discussion
,
3

There are several issues discussed in this post:

The ability(or inability) to build new locks in the context of cobuild

I’m not gonna lie here, cobuild is indeed complex. It’s the combination of several different factors:

  • L1 CKB is flexible enough, but in a way, the flexibility could be seen as a curse: a huge deal of work is required at script side to make cells secure
  • We do want CKB untyped cells to become typed via cobuild, making collaborations between scripts to be easier. Personally I think this used to be a nightmare, and I do think we should work together to fix the problem
  • There are already code running on CKB, it makes no sense to break them. As a result, a ton of efforts were put into cobuild to ensure compatibility with existing scripts

The good news is, a huge deal of validation logic in cobuild, to me, is just repetitive work. This is still early days of cobuild, but as we continue to build things, I do envision that the majority of cobuild logic, can be distilled into libraries, that one can simply invoke to do the validation, and we are already moving into this direction:

So for future CKB locks, I would never recommend one to manually code all the cobuild related logic unless absolutely necessary. It’s better to just rely on commonly maintained libraries, or as you mentioned, focus on business logic.

OTX

I dabbled on this problem briefly here: A Fine-Grained Control Scheme Based on Cobuild-OTX - #7 by xxuejie. The way I see CKB TX and OTX, is that we now really have 3 different levels of granularity:

  1. A sighash-all signed transaction, where every piece in the transaction is signed. No modification is allowed
  2. An OTX, where input / output cells are fully guarded by OTX signature. No modifications to those cells are allowed
  3. An OTX with only input cells and action objects. No output cells are guarded, or part of the output cells are guarded.

I do agree that partial fulfillability is not possible at level 2 here. But it’s okay to build an OTX for limit orders with only input cells, then use an Action object(it could then use the limit order cell’s lock/type script as Action’s script_hash) to fill in parameters for limit orders, which will enable partial fulfillability. The way I look at this design, is that it is essentially an “atomic approve” function, that basically approves certain amount of tokens(determined by the input cells of the OTX) to a certain type script(limit order cell’s lock/type script here). The lock/type script of limit order cell, can then look against all OTXs in current CKB TX, processes the Action objects of each limit order, then either completely fulfills or partially fulfills each order.

This is indeed contrary to previous OTX design, but fundamentally we are throwing a new question: does an OTX really need to fixate all requirements in the fields of cells? I personally have different opinions, yes we could have apps that fixate both input cells and output cells, but different apps are designed with different minds having different feature sets, there are certainly people who can benefit from OTXs that only fixate input cells(essentially limiting the maximum amount of tokens participating in the actions), and leverage cobuild’s Action objects for complex operations, which they are also designed for.

Omnilock

I could understand the rationale here, but I personally would think it in different ways:

  • An Action object using the lock script’s hash as script_hash, in cobuild’s convention, is already a P2SH design.
  • I would personally recommend keeping app logic in type scripts, and only do signature validation for proving ownership in lock scripts.
5 Likes