iCKB journey into CoBuild

[phroi]

Hey @xxuejie, hope everything is going well, I noticed that you are reviewing xUDT RFC PR and fighting to improve its readability. That’s very appreciated, keep it up!!

@xxuejie

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:

• ckb-transaction-cobuild-poc/ckb-transaction-cobuild at main · cryptape/ckb-transaction-cobuild-poc · GitHub

This is an advanced POC, I was wondering how much time could it take to have a production ready CoBuild Rust Library?

CoBuild OTX Collector, Missing

In these days I started to appreciate more and more CoBuild OTX, so I started looking how to integrate CoBuild OTX-style limit orders into the iCKB flow. Then again, I realized that a key Service is missing for integrating CoBuild OTX into iCKB, let’s call it OTX Collector.

A CoBuild OTX Collector would be defined by the following functionalities:

• Buffer the received messages, while being resistant to DoS.

• Check that these messages can be parsed as CoBuild OTX, so shielding aggregators against malicious XSS messages.

• Organize the CoBuild OTX in Topics.

• As noted by @xxuejie, avoid validating the received CoBuild OTX as it’s a hard problem. (Validation could be achieved by the specific aggregator retrying enough times aggregated transactions, excluding the non validating OTX little by little.)

• Make publicly available for aggregators the received CoBuild OTX.

• Possibly be organized as a P2P network for high availability and for resisting DDoS attacks.

No Cobuild OTX Collector is currently available and I can’t afford to create, deploy and maintain it as I don’t have the required mental power.

iCKB Staggered Adoption of CoBuild

At this point, while in my opinion CoBuild OTX is solid, its integration in iCKB is not 100% workable right away. That’s why we are taking a staggered approach for iCKB. In V1:

1. I’ll complete the proposal update the definition for all scripts in a way that is both L1 Classic and CoBuild OTX compatible. Then I’ll kindly ask @xxuejie for a review.

2. I’ll implement these script in L1 Classic and, if CoBuild Rust Libraries are production ready, possibly CoBuild (OTX).

3. Deploy them on Testnet.

4. Finishing implementing the DApp as L1 Classic.

5. Launch on Mainnet.

When CoBuild back-end and front-end libraries are production ready, in V2:

6. Update the scripts to validate Cobuild (OTX) messages and re-deploy, if not already fully CoBuild OTX.

7. Update the DApp to support CoBuild and possibly CoBuild OTX-style limit orders if a CoBuild OTX Collector-alike service is available by then.