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 scriptof 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 scriptof 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.
