From 168139210099bdd9363279cf16ecd86cc1993c89 Mon Sep 17 00:00:00 2001 From: Filip Krawczyk Date: Tue, 10 Sep 2024 23:32:25 +0200 Subject: [PATCH] Update README --- README.md | 2 ++ 1 file changed, 2 insertions(+) diff --git a/README.md b/README.md index 252b4079..b3df118e 100644 --- a/README.md +++ b/README.md @@ -98,4 +98,6 @@ TODO: why we need splitting, starknet limits, autogenerated and fri split Since verifier can be configured in many ways and some parts of the logic changes with new stone versions, a contract which routes calls to the correct verifier is needed. This task is handled by FactRegistry contract that also stores data for all verified proofs. +After proof is verified, `FactRegistered` event is emitted which contains `fact_hash`, `verification_hash`, `security_bits` and `settings`. `fact_hash` is a value that represents proven program and its output (formally `fact_hash = poseidon_hash(program_hash, output_hash)`). Remember that registration of some `fact_hash` doesn't necessary mean that it has been verified by someone with secure enough proof. You always need to check `security_bits` and `settings` which is part of `verification_hash` (formally `verification_hash = poseidon_hash(fact_hash, security_bits, settings)`). + FactRegistry contract is trustless which means that owner of the contract can't override or change any existing behavior, they can only add new verifiers. Proxy contract on the other hand is upgradable, so every function can be changed or removed. It has the advantage of having all future updates of the verifier logic without having to replace the address of FactRegistry contract.