Fact Registry contracts

Fact Registry

The Fact Registry design pattern is a way to separate statement verification from the business logic of the contract flow.

A Fact Registry does the following:

  • It holds a hash table of verified facts, which are represented by a hash of claims that the registry has checked and found valid.

    You can query this table by using the isValid function of the registry with a given hash.

  • It exposes a registry-specific function for submitting new claims together with their proofs. The information submitted varies from one registry to the other depending on 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 on Medium.

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.

For more information, see verifyProofAndRegister in the GpsStatementVerifier contract.

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, which is the root of the Merkle tree. For more information, see the verifyEscape function in the EscapeVerifier smart contract.

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 format for the escape proof,escapeProof, which you pass when invocating the verifyEscape function. Notice that unlike a standard Merkle proof, The escape proof 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, it is registered under the following claim hash, which can later be queried for validity:

claimHash = keccak256(starkKey, assetId, quantizedAmount, vaultRoot, treeHeight, vaultId)

For more information, see Forced actions and escape hatch