StarkEx smart contract architecture
The StarkEx smart contract enforces a trader’s self-custody. It maintains the StarkEx state hash and allows a state transition only if both the integrity Verifier, that is, the Verifier Fact Registry, and the Committee Fact Registry, which supports custom constraints, approve the new state.
The Dispatcher contract invokes the business logic of the StarkEx smart contract.
Ethereum limits contract size to 24kB. To accommodate this, the logic is spread among several library contracts and invoked with delegate calls.
The sub-contracts implement different modules used by the StarkEx smart contract. They are executed in the context of the Proxy contract (both address and storage), using delegate calls.
A contract linking the main contract the operator’s application, that is, all code that is executed in the context of the Proxy contract, to the Verifier contract, which is part of the SHARP proving service. The Verifier Fact Registry contract implements the Fact Registry API, and translates facts of the format that the operator’s application contract uses to the format that the SHARP Proving Service Verifier contract uses, such as by hashing the operator’s application contract with the Cairo application program hash).
A Fact Registry enforcing custom off-chain approval of state transitions (e.g., data availability on some off-chain repository).
The Proxy contract supports upgradability by changing the address of the Dispatcher contract (i.e., the version) it delegates the calls to. To ensure self custody, an immediate upgrade is not supported.
The standard upgrade flow is:
Register a new version of a contract.
A timelock is applied. This allows any trader that does not approve the new version, to leave the system.
After the timelock period, the version can be switched to the new version.
Versions that already passed this standard flow can be reinvoked. This enables the immediate return to a previous version in case of a bug in a new version.
In case of a soundness issue with the Verifier Fact Registry, a new Verifier can be added immediately. To ensure the operation does not harm the system soundness, this operation allows state transition only if all the Verifiers approve it. Note, the simplest scenario is that both old and new Verifiers approve the change. However, the list can be more extensive.
A Verifier can be removed from the list only after a timelock. This prevents the operator from causing harm to the system’s soundness.
The same mechanism applies to Committee contracts.