[Random idea] To what extent can Open Transaction resolve state contention on Cell model?

Fuellabs FuelLabs/fuel-specs designed The Sway Programming Language, which is a smart contract language that implements account model equivalence in UTXO. User calls to contracts will be executed by Sequencer is constructed as a complete UTXO transaction, so Fuel can avoid state contention in the UTXO model. the idea is very similar to OpenTransaction.

In addition, Sui’s use of Move makes it more like an account model built on top of the UTXO model. How Sui Move differs from Core Move | Sui Docs

While there is a grant here that tries to do this, there is no follow-up, AVOUM for Nervos - Creating an open market for miner extractable value - English / Grants - Nervos Talk

Below are just some ideas:

Similarly, an Executor code can be deployed on CKB, and its corresponding generator runs off chain. The Generator converts the user’s call into a complete CKB transaction, and the Executor verifies whether all the inputs and outputs are consistent with the user’s call to the contract.

Assuming that there is an Executor, the code_hash of all contract and resource-related cells defined by Executor are Executor code_hash, and args refers to the type of cell (contract or specified resources).

In the input area of the witness of the first resources cell, the user can place the specified contract call, and the signature only contains the resource cell and the contract call.

Take the following AMM call as an example:

  • First, the type script of the AMM contract cell looks for the cell in the input which typescript code_hash is the same as itself, and its owner is not itself, then it returns success.
  • The type script of the AMM contract controled cells looks for the AMM contract in the input, and returns success if the AMM contract is unlocked.
  • User 's Asset A Cell’s typescript first reads witness.input and parses the contract call, then finds the corresponding contract in the inputs according to the contract address, then loads its bytecode, finds the function called by the user, and starts to execute the contract call.
  • This function, firstly checks the amount of Asset A input, as well as the amount of AssetA and AssetB controlled by the current AMM contract, calculates the exchange ratio, and then obtains the amount of AssetB exchanged, the status read and write operations of these instructions will be automatically Executor translates to inspection of resources in input cells and output cells through ckb syscall.
  • Except for the cell involved in the contract call, the code_hash of any cell is not allowed to be Executor code hash

By adding another virtual machine on top of CKB-VM, programming on CKB does not require manual operating system calls, or consider low-level details such as dynamic calls or exec.

At the same time, the experience of writing a Generator for the Cell model is not pleasant. With a unified Generator, developers only need to write contracts on top of it, and it can automatically generate the required transactions, which is very developer-friendly. This makes it unnecessary for developers to implement the required Generator by themselves.

This idea of implementing the account model through UTXO, if the Generator is completely embedded in the chain level, it looks very similar to Sui using the Move programming language, and Cell is very similar to Objects | Sui Docs.

Inputs:
    AssetA Cell
        Data:
            <amount: uint128>
        Type:
            code_hash: executor
            args: assetID_A
        Lock:
            <user defined>
    AMM Contract Cell
    	Data:
    		<Bytecode>
    	Type:
    		code_hash: executor
    		args:contract_address
    	Lock: Proof of Stake lock or always_success
    AMM controled AssetA Cell
    	Data:
    		<amount: uint128>
    	Type:
    		code_hash: executor
    		args:assetID_A
    	Lock: AMM cell must be unlocked first
    AMM controled AssetB Cell
    	Data:
    		<amount: uint128>
    	Type:
    		code_hash: executor
    		args:assetID_B
    	Lock: AMM cell must be unlocked first
Outputs:
    AssetB Cell
        Data:
            <amount: uint128>
        Type:
            code_hash: executor
            args: assetID_B
        Lock:
            <user defined>
    AMM Cell
    	Data:
    		<AMM State>
    	Type:
    		code_hash: executor
    		args:contract_address
    	Lock: Proof of Stake lock or always_success
    AMM controled AssetA Cell
    	Data:
    		<amount: uint128>
    	Type:
    		code_hash: executor
    		args:assetID_A
    	Lock: AMM cell must be unlocked first
    AMM controled AssetB Cell
    	Data:
    		<amount: uint128>
    	Type:
    		code_hash: executor
    		args:assetID_B
    	Lock: AMM cell must be unlocked first
Witnesses:
    WitnessArgs structure:
      Lock: <user defined>
      Input Type: contract_address.swap(AssetA, AssetB)

In order to avoid state contention, all contract locks can be a Proof of stake lock, based on which the Proof of stake can control a UTXO Layer2 (Compact Fraud Proofs for UTXO Chains Without Intermediate State Serialization), so as to use a completely unified programming model in Layer1 and Layer2, a Cell can be used flows between Layer1 and Layer2.

Even if there are multiple transactions calling the same contract in the same block, the transaction can still be verified completely in parallel, just like the serial hash of 100,000 times of SHA256, when verifying the hash, a ten-core machine can be used to Verify the result of this serial operation ten times faster.

When transaction X calls contract A and modifies the state, transaction B is the next transaction that modifies the state of contract A, similar to calculating hashes serially but verifiable in parallel, since the input and output are determined, the verification of transaction A and transaction B will be Fully parallel, if transaction A fails verification, then the entire block will fail verification.

In addition, if Proof of stake lock is used to solve state contention, maybe we can build CKB rent in Executor. The lock and type of each Cell are special scripts used to control rent, and its real script will be placed in args, called by exec.

Cell
	Data:
		<amount: uint128>
	Type:
		code_hash: rent_type
		args:type|codehash|args
	Lock:
		code_hash: rent_lock
		args:startEpoch|balance|type|codehash|args

Maybe the rent_type can be embedded in the Executor, and at the same time simulate a shared state context through Proof of stake, which is used to calculate the interest of the ckb rent, just like the DAO field in the blockHeader.

还是尽快做出cell模型的layer2吧,这样ckb上面的应用和nft市场就不需要用layer1.5来节约状态空间了,毕竟layer1.5也会破坏可组合性

I think Fuel made some real progress (congrats!). Open transaction and “event compiler” (compiling user events to CKB transactions) are valuable complements to CKB. Both are on the roadmap, and were considered and discussed after Lina launch. Unfortunately they were always preempted by other tasks :frowning:

A good news is the CKB team has already resumed open transaction work after Mirana hardfork, although there’s no ETA but at least we’re on the road again.

I also think it’s worth exploring the possibility of combining Sui / Move / FuelVM with CKB in some way, I’d love to see initiatives in this direction, they would be good candidates for Nervos grants.

The AVOUM project has been stopped after 2 milestones because the progress didn’t meet expectation.

2 Likes