Update README

README.md

@@ -30,9 +30,7 @@ scarb test
 
 ### Running the Verifier on Example Proof
 
-For local proof verification, follow these steps:
-
-1. Run the verifier locally using the following command on example proof, followed by the Cairo version (cairo0 or cairo1) used to generate the proof:
+Run the verifier locally using the following command on example proof, followed by the Cairo version (cairo0 or cairo1) used to generate the proof:
 
 ```bash
 cargo run --release --bin runner -- --program target/dev/cairo_verifier.sierra.json -c cairo0 < examples/proofs/recursive/cairo0_example_proof.json
@@ -44,11 +42,11 @@ cargo run --release --bin runner -- --program target/dev/cairo_verifier.sierra.j
 By default, the verifier is configured for monolith version, recursive layout and keccak hash for verifier unfriendly commitment layers. You can easily change that by using scarb's features:
 
 ```bash
-scarb build --no-default-features --features small,blake2s,split
+scarb build --no-default-features --features small,blake2s,monolith
 ```
 
-layout types: [dex, recursive, recursive_with_poseidon, small, starknet, starknet_with_keccak]  
-hash types: [keccak, blake2s]
+layout types: [dex, recursive, recursive_with_poseidon, small, starknet, starknet_with_keccak]<br />
+hash types: [keccak, blake2s]<br />
 verifier types: [monolith, split]
 
 ### Benchmarking
@@ -73,7 +71,13 @@ How to prove [Cairo1](https://github.com/starkware-libs/stone-prover?tab=readme-
 
 ### Background information
 
-TODO: why we need splitting, starknet limits, autogenerated and fri split
+Because of great complexity of the verifier compared to standard starknet contracts, we encounter some limitations enforced by starknet. The most important ones are:
+
+-   Contract classhash size limit
+-   Transaction calldata limit
+-   Transaction steps limit
+
+To overcome these limitations, we split the verifier into multiple contracts and transactions. The biggest part of classhash size is autogenerated (e.g. [recursive autogenerated](/src/air/layouts/recursive/autogenerated.cairo)), so we extracted that part into separate contract (or many contracts in case of `starknet` and `starknet_with_keccak` layout), which is called automatically by the main verifier contract. On the other hand the biggest part of calldata is fri witness, so user can send subsequent chunks of fri witness in separate step transactions.
 
 ### FactRegistry and Proxy contract
 
@@ -83,7 +87,7 @@ After proof is verified, `FactRegistered` event is emitted which contains `fact_
 
 `FactRegistry` provides two methods for checking verified proofs:
 
--   `get_verification(verification_hash)`
--   `get_all_verifications_for_fact_hash(fact_hash)`
+-   `get_verification(verification_hash)` - returns fact hash, security bits and settings for given `verification_hash`.
+-   `get_all_verifications_for_fact_hash(fact_hash)` - returns list of all verification hashes, security bits and settings for given `fact_hash`. This method is useful for checking if given program has been verified by someone with secure enough proof.
 
 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.