Fault tolerance and integrity
Resource limits and ledger integrity checks run in the API middleware, ordering service and block verifier.
Resource protection
- Rate and payload limits live in
hierachain/api/middleware.py(add_rate_limit,add_payload_limitwithHRC_RATE_LIMIT,HRC_RATE_LIMIT_RPM,HRC_RATE_LIMIT_BACKEND,HRC_TRUSTED_PROXIES). For POST, PUT, and PATCH requests, a parseableContent-Lengthis checked against 1 MiB;request.stream()byte counting runs only when the header is absent. HRC_EVENT_POOL_MAX_SIZEdefaults to 10,000 and bounds the ordering queue.HRC_RAM_CRITICAL_THRESHOLDis declared with a 95% default but has no runtime consumer underhierachain/.ResourceValidatorreports its separately configured CPU, memory, and disk thresholds when called; it does not enforce this RAM setting in ordering or storage.- Use app middleware together with reverse proxy limits.
PerformanceMonitorreports metrics; it does not install a per-request CPU/RAM guard.
Integrity checks
Ledger loading and verification use the following mechanisms:
- Merkle and chain links in
hierachain/core/block.pyandcore/merkle_tree.py(domain-separated0x01prefix) andconsensus/ordering/storage.py:_verify_chain_links()(previous_hashchain). - Proof verification in
hierachain/hierarchical/main_chain/proofs.py:_verify_proof_in_main_chain(fallback chain scan) andsecurity/verify/block_verifier.py. - Runtime integrity checks use chain links, Merkle roots, proof verification, and consensus validation. State snapshots and rollback are deployment responsibilities.
BlockVerifier.verify_chain()checks the sequence supplied. For a nonempty sequence, the first block must be genesis at index0withprevious_hashequal to"0", and links among supplied blocks are checked. An empty sequence returnsVALID. The API has no expected tip height or hash, so a valid prefix that omits later blocks can pass.
graph LR
A[Block finalize] --> B[previous_hash check]
B --> C[Merkle root verify]
C --> D[Proof verify on MainChain]
D --> E[Operational recovery if needed]