On Ethereum, you can have a way to create a Contract from another Contract (by calling CREATE opcode in EVM).
How can I do something similar on CKB?
Here’s my guess:
There should be some opcode in CKB-VM that can make a transaction and send to node.
and somehow this transaction can create another Cell using the original Cell as input?
CKB only stores the final states, so just create the new cells as transaction output. When the cell output is later used in the cell output type script, it then is considered as a verifier.
When user interacts with a Dapp, and the Dapp needs to create a new verifier, the transaction should contain the verifier cell as an output.
Thanks for the reply! Great explanation!
However I still think there could be some scenarios that need a verifier to create another verifier/cell by making a tx itself.
E.g. I want a verifier (cell A) to verify a hash that is stored in another cell B, at a certain block height that is higher than the current tip block. (So basically verifies a future state) and create a cell C depending on the verification result.
Or am I making some mistakes here?
There’re no features to execute some code automatically on the CKB yet.
All code executions are triggered by transactions, just like in Ethereum. But unlike Ethereum, which transaction only contains an event, CKB contains the final state after applying the event.
If user Alice sends a transaction T to contract C in Ethereum, and C creates another contract D, while D is just one of the final state.
Alice -> Event -> C -> Modifer Some Context Storage
`-> Creates contract D
In CKB, Alice should send a transaction includes all the modified state, including the indirect changes, such as C calls another contract E, and E has changed some of its storage. Take the example above, the transaction looks like:
Cell C State -> Modified Cell C State
`--> New Cell D
CKB is unable to run some code at a specific height. CKB also cannot guarantee a specific transaction will be packaged in a block at a specific height. CKB even does not support accessing the number of the block including the transaction, nor the timestamp of the block. This feature is still in discussion and PoC stage. A similar feature similar to the Bitcoin timelock is also in consideration, which allows submitting a transaction to the P2P network, but only can be packaged into a block after a specific height.
E.g. I want a verifier (cell A) to verify a hash that is stored in another cell B, at a certain block height that is higher than the current tip block. (So basically verifies a future state) and create a cell C depending on the verification result.
This example does not make much sense in CKB. It is not even possible in Ethereum. A similar solution is like the state channel. A guardian monitors the cell B and responds by submitting new transactions when B is transferred into new cells.
3 Likes