The flow of CKB is not something we want to express using cobuild Messages. A wallet is expected to visualize the cobuild message to users(which would include the flow of UDT tokens as well as other contract defined information), the wallet is also expected to visualize the basic flow of CKB tokens, L1 tx fee, and any other information defined in the consensus level of CKBs.
So I personally think a wallet should warn users that 1M CKB is up for grabs, this is not something we want to do in cobuild messages.
You may want to document this implicit requirement for wallet developers in the CoBuild proposal, otherwise they may not be aware that this is expected of them.
By the way, where does happen the validation that all script_hash of message actions are indeed included in the transaction? Wallet/DApp level or is there a planned softfork for direct support of CoBuild?
Wallet or on-chain validation would change the security assumptions when developing scripts, as a CoBuild soft-fork would guarantee that full on-chain message validation always occurs, while wallet validation can be bypassed by an attacker using a customized front-end.
Cobuild does not need any hardforks or softforks. Enough work has been done to ensure cobuild stays compatible and secure with existing conventions. The adoption of cobuild, to me, will be a gruadual process as more locks and types start to use it.
That being said, I do want to point out that CKB is a permissionless platform. Theorectically one can ignore all the cobuild process, one can even ignore the whole sighash-all process and roll out one new stack here. There is inherently nothing against it, nor can we say “you must not do it”. That’s the merit and the curse of permissionless systems. Even when we introduced cobuild here, the best we can say is “okay we have thought hard on this problem, and we believe if enough players pay attention to this cobuild protocol, together we can have an ecosystem that brings us interoperability powers”, after that we can only hope for the best. All things discussed here, might never be requirements, but only conventions, or recommendations.
CoBuild enables protocols to formalize user intentions, but defines no standard to describe how a set of intentions is transformed into a tx/otx, so a standard for defining a function f(intentions, l1_state, tx_pool, ...) -> tx/otx. I imagine this step similarly to how a molecule schema can be translated into an executable.
Of course this is a much more complex problem, then again this second formalization step would truly enable an EVM-alike developer experience with the security of a Cell Model.
Have any thoughts been given on this? If so, what’s its progress status?
In addition to the SighashAll variant, there is a special SighashAllOnly variant of WitnessLayout. This variant only contains seal, not message. If all witnesses in a transaction are of the SighashAllOnly type, it means that this transaction does not contain any Message.
Maybe the message of BuildingPacketV1 should be optional. Not all transactions require an action in the packet, like transferring CKB
If the BuildingPacketV1 structure is intended for data exchange, it should be compatible with the SighashAllOnly scenario for communication between the dApp and the wallet(signer). Requiring the message field would force developers to use a custom structure that omits the message field, in order to sign a SighashAllOnly transaction
SighashAllOnly is not designed for communication between wallet and a dapp. As long as a wallet is involved, it is expected that SighashAll will be used, and a message will be present
