This specification extends EVM assembly and Solidity semantics, allowing for the annotating of storage keys as single-owned to allow concurrent execution of transactions sent by different message senders. SolidityX and EVMx are completely backward compatible, i.e., any existing Solidity contract can be deployed to the pod as is, though it will not use the fast path. To leverage the fast path, the developer has to use the SolidityX semantics described below.
EVM transactions currently rely on the total ordering of the transactions, such that a change in order can lead to a completely different final execution state. Pod relaxes the transaction total ordering assumption to allow for extremely fast confirmation, referred to as the fast path. For a transaction to be safely executed in the fast path, it must only access storage owned by the transaction sender. We extend the EVM/Solidity semantics to allow for special storage locations, which are always owned and consumed by a single party, ensuring the safety of the fast path. The extension is intended to be minimal and adhere to the solidity style to ensure easy onboarding of the existing solidity developers.
An object is an instance of a single-owned struct.
An owner of an object is an address (usually the address of the owner who initialized the struct) or another object.
An indirect owner of an object is an address or another object, possibly following a chain of owner
relations.
owned
keywordThe owned keyword can be placed at the start of a struct definition. The struct definition in solidity grammar becomes:
*owned*? struct _identifier_ { struct-member* }
A struct in order to be owned:
uint256 id
.uint256 owner
.All objects are immutable. When initializing, the id
field is omitted and cannot be set. It will be set automatically. For example, the struct:
owned struct UTXO {
uint256 id
uint256 amount
uint256 owner
}
Is initialized by:
utxo = UTXO(amount, owner)