fixed styling issues

ERCS/erc-7812.md

@@ -10,28 +10,28 @@ category: ERC
 created: 2024-11-08
 ---
 
-# Abstract
+## Abstract
 
 This EIP introduces an on-chain registry system for storing abstract statements, where the state of the system can be proven in zero knowledge without disclosing anything about these statements. Developers may use the singleton `EvidenceRegistry` contract available at `0x<TODO>` to integrate custom business-specific registrars for statement processing and proving.
 
-# Motivation
+## Motivation
 
 The standardization and aggregation of provable statements in a singleton on-chain registry significantly improves reusability, scalability, and security of the abundance of zero knowledge privacy-oriented solutions. The abstract specification of the registry allows custom indentity-based, reputation-based, proof-of-attendance-based, etc., protocols to be implemented with little to minimal constraints.
 
 The given proposal lays the important foundation for specific solution to build upon. The more concrete specifications of statements and commitments structures are expected to emerge as separate, standalone EIPs. 
 
-# Specification
+## Specification
 
 The keywords “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” in this document are to be interpreted as described in RFC 2119.
 
-## Definitions
+### Definitions
 
 - A “Sparse Merkle Tree (SMT)” is a special Merkle tree that works by deterministically and idempotently storing key/value pairs in the given locations leveraging a hash function. The Poseidon hash function is often used to optimize the compatibility with ZK.
 - A “statement” is an accepted structured representation of some abstract evidence. A statement can range from a simple `string` to a Merkle root of some SMT.
 - A “commitment” is a special public value resulting from blinding a statement to conceal it. Commitments allow the authenticity of a statement to be proven in ZK without disclosing the statement itself.
 - A “commitment key” is a private salt mixed with the statement to obtain a commitment to that statement. The commitment key must be kept private to maintain the confidentiality of statements.
 
-## General
+### General
 
 The proposed on-chain registry system consists of two subsystems: the `EvidenceRegistry` with `EvidenceDB` and `Registrar` components. This EIP will focus on describing and standardizing the former, while the `Registrar` specification may be amended as the separate proposals.
 
@@ -45,7 +45,7 @@ In order to prove that certain data is or is not present in the `EvidenceDB` Mer
 
 The Circom implementation of a general-purpose SMT-driven `EvidenceDB` verifier circuit together with the Solidity implementation of `EvidenceRegistry` and `EvidenceDB` smart contracts may be found in the “Reference Implementation” section.
 
-## Evidence DB
+### Evidence DB
 
 The `EvidenceDB` smart contract MAY implement an arbitrary provable key/value data structure, however it MUST support the `addition`, `update`, and `removal` of elements. All of the supported write operations MUST maintain the property of idempotence (e.i. `addition` followed by `removal` should not change the state of the database). The data structure of choice MUST be capable of providing both element inclusion and exclusion proofs. The functions that modify the `EvidenceDB` state MUST be callable only by the `EvidenceRegistry`.
 
@@ -123,7 +123,7 @@ interface EvidenceDB {
 }
 ```
 
-## Evidence Registry
+### Evidence Registry
 
 The `EvidenceRegistry` smart contract is the central piece of this EIP. The `EvidenceRegistry` MUST implement the following interface, however, it MAY be extended:
 
@@ -175,31 +175,31 @@ bytes32 isolatedKey = hash(msg.sender, key)
 
 Where the `hash` is secure protocol-wide hash function of choice.
 
-## Hash function
+### Hash Function
 
 The same secure hash function MUST be employed in both `EvidenceRegistry` and `EvidenceDB`. It is RECOMMENDED to use ZK-friendly hash function such as `poseidon` to streamline the database proving.
 
 In case ZK-friendly hash function is chosen, `EvidenceRegistry` MUST NOT accept `keys` or `values` beyond the underlying elliptic curve prime field size (`21888242871839275222246405745257275088548364400416034343698204186575808495617` for `BN128`). 
 
-# Rationale
+## Rationale
 
 This EIP stemmed from the need to localize and unravel the storage and issuance of provable statements so that future protocols can anchor to the standardized singleton registry. The proposal is deliberately written as abstract as possible to not constraint the possible business use cases and allow `Registrars` to implement arbitrary provable solutions.
 
-It is expected that based on this work future EIPs will describe concrete registrars with the exact procedures of generation of commitments, management of commitment keys, and proving of operated statements. For instance, there may be a registrar for on-chain accounting of national passports, a registrar with [EIP-4337](https://eips.ethereum.org/EIPS/eip-4337) confidential account identity management, a registrar for POAPs, etc.
+It is expected that based on this work future EIPs will describe concrete registrars with the exact procedures of generation of commitments, management of commitment keys, and proving of operated statements. For instance, there may be a registrar for on-chain accounting of national passports, a registrar with [EIP-4337](./erc-4337.md) confidential account identity management, a registrar for POAPs, etc.
 
 The `EvidenceDB` namespacing is chosen to segregate the write access to the database cells, ensuring that no entity but issuer can alter their content. However, this decision delegates the access control management responsibility solely to registrars, an important aspect to be considered during their development.
 
 The `EvidenceRegistry` maintains the minimal viable (gas-wise) history of roots on-chain for smooth registrars integration. In case more elaborate history is required, it is RECOMMENDED to implement off-chain services for parsing of `RootUpdated` events.
 
-# Backwards Compatibility
+## Backwards Compatibility
 
 This EIP is fully backwards compatible.
 
-# Deployment method
+### Deployment Method
 
- The `EvidenceRegistry` is a singleton contract available at `0x<TODO>` deployed via the “deterministic deployment proxy” from `0x4e59b44847b379578588920ca78fbf26c0b4956c` with the salt `0x<TODO so that the ER address starts with the EIP number>`. 
+The `EvidenceRegistry` is a singleton contract available at `0x<TODO>` deployed via the “deterministic deployment proxy” from `0x4e59b44847b379578588920ca78fbf26c0b4956c` with the salt `0x<TODO so that the ER address starts with the EIP number>`. 
 
-# Reference Implementation
+## Reference Implementation
 
 The reference implementation of `EvidenceRegistry` and `EvidenceDB` Solidity smart contracts together with the evidence registry state verifier Circom circuit is provided in the proposal.
 
@@ -499,14 +499,14 @@ template EvidenceRegistrySMT(levels) {
 component main {public [root]} = EvidenceRegistrySMT(80);
 ```
 
-# Security Considerations
+## Security Considerations
 
 From security standpoint there are several important aspects that must be highlighted. 
 
 The individual registrars are expected to provide the functionality for both management and proving of statements. The proving will often be carried out by ZK proofs, which require trusted setup. Improperly setup ZK verifiers can be exploited to verify forged proofs.
 
 The `getRoot` method of `EvidenceDB` SHOULD NOT be used on-chain by the integrating registrars to check the validity of the database state. Instead, the required `root` SHOULD be passed as a function parameter and checked via `getRootTimestamp` method to avoid being frontrun.
 
-# Copyright Waiver
+## Copyright
 
 Copyright and related rights waived via [CC0](../LICENSE.md).