Invoking Smart Contracts
The Call
operation within the L2 transaction block is the one that
executes/invokes/calls a smart contract in Coinweb's L2 computer.
export interface CwebCall {
resources: CompResources;
smart_contract: ContractRef;
number_of_arguments: number;
}
The extracted interface above reveals that the operation provides the
smart_contract
reference in order for the L2 computer to locate and process it
in Coinweb. Further it indicates resources
and the number_of_arguments
. The
parameters are described more closely below.
Resources
The Coinweb VM is the actual machine that executes a smart contract. By providing the resources field you can control which kind of VM shall be used.
Currently supported resources for the Coinweb VM is only SmallWasmInstance
.
Number of Arguments
The number of arguments describes the count of subsequent Coinweb operations
after a CallOp
, in which every following operation after the call becomes a
contract argument. This argument is equivalent to a
ResolvedOperation
,
which can be parsed using
getContractArgument
.
This parameter is important for the composition of operations in a smart
contract invocation. These subsequent operations are also referred to as
slices.
Assuming an arbitrary CallOp
includes subsequent slices in the following
order: Call, Read, Read, Data, Store. The initial CallOp
will be treated as
the 0 argument, and the number_of_arguments
becomes 4 (1. ReadOp
, 2.
ReadOp
, 3. DataOp
, 4. StoreOp
).
Contract Reference
The contract reference (v0) represents how to construct the virtual file system (VFS) for the contract. There are two ways to do this, either by referencing stored claims that include the VFS information, or explicitly by providing raw data in the form of a [ContractTree]. The explicit approach is typically used when first invoking a contract (see the self registration system), potentially combined with also using stored claims for parts of the VFS that can be reused from other parts of the system.
If a smart contract is executed in a WASM interpreter, which is also used by
other smart contracts, it is not necessary to (re-)deploy it for each contract.
It can be published once and further referenced in other smart contracts
utilising a ReadOp
operation.
Virtual file system and its components are deeper described in the upcoming chapters.
export type ContractIssuer = {
FromSmartContract: ContractId;
};
export type ContractRef = {
stored: CwebRead[];
explicit: ContractTree;
};
export interface ResolvedContractRef {
contract_id: HashId;
resolved: ContractTreeResolved;
}
export function contractRef(
issuer: ContractIssuer,
explicit: ContractTree
): ContractRef {
return {
stored: [{ Claim: { issuer, key } } as SingleClaimRead],
explicit,
};
}
The contract_id
is a function of the ResolvedContractRef
and therefore can
be reconstructed from the resolved reference object.