Fact Registry contracts
Fact Registry
The Fact Registry design pattern is a way to separate statements verification from the business logic of the contract flow.
A Fact Registry holds a hash table of verified “facts” which are represented by a hash of claims that the registry has checked and found valid. This table may be queried by accessing the isValid function of the registry with a given hash.
In addition, each Fact Registry exposes a registry specific function for submitting new claims together with their proofs. The information submitted varies from one registry to the other depending of the type of fact requiring verification.
For more information on the Fact Registry design pattern see The Fact Registry: Proofs, DApps, and Economies of Scale.
StarkEx uses the following fact registries:
STARK Verifier for Cairo programs
Verifies programs that are written in Cairo. Specifically, it verifies the computational integrity of executing a Cairo program P on an input data D, and the correctness of the post-execution state of the system.
The verifier gets as part of the input a hash of the program P.
Committee Signature Verifier
Verifies the availability proof in Validium. Reverts if invalid. An availability proof should have a form containing a concatenation of signatures by signatories. Signatures should be sorted in ascending order by signatory address. Signatures should be 65 bytes long. r(32) + s(32) + v(1). There should be at least the number of required signatures as defined in this contract and all signatures provided should be from signatories.
For more information, see Availability verifiers.
Escape Verifier
Verifies that the contents of a vault belong to a certain Merkle commitment (root).
The Merkle commitment uses the Pedersen hash variation described next:
-
Hash constants: A sequence \(p_i\) of 504 points on an elliptic curve and an additional \(ec_{shift}\) point
-
Input: A vector of 504 bits \(b_i\)
-
Output: The 252-bit coordinate of \((ec_{shift} + \sum_i b_i*p_i)\)
The following table describes the expected escapeProof format. Note that unlike a standard Merkle proof, the escapeProof contains both the nodes along the Merkle path and their siblings. The proof ends with the expected root and the ID of the vault for which the proof is submitted (which implies the location of the nodes within the Merkle tree).
| starkKey (252) | assetId (252) | zeros (8) |
|---|---|---|
hash(starkKey, assetId) (252) |
quantizedAmount (252) |
zeros (8) |
left_node_0 (252) |
right_node_0 (252) |
zeros (8) |
… |
… |
… |
left_node_n (252) |
right_node_n (252) |
zeros (8) |
root (252) |
zeros (4) | vaultId (248) |
zeros (8) |
If the proof is accepted, this is registered under the following claim hash that may later be queried for validity:
claimHash = keccak256(starkKey, assetId, quantizedAmount, vaultRoot, treeHeight, vaultId)
For more information, see Forced actions and escape hatch