Blockchain Attestation

The Trust Problem in Pentest Reports

A pentest report is a claim: "On this date, we tested this target, and these were the findings." But how does a third party — an auditor, a customer, a regulator — verify that claim? Traditional reports are PDF files that can be modified after the fact. A company could run a pentest, receive a report full of critical findings, fix nothing, and then edit the PDF to show a clean result before handing it to an auditor.

Blockchain attestation solves this problem by creating a tamper-proof, publicly verifiable record that a specific report existed at a specific time with specific contents. The report itself stays private; only a cryptographic proof goes on-chain.

SHA-256 Content Hashing

The foundation of blockchain attestation is cryptographic hashing. TurboPentest uses SHA-256 (Secure Hash Algorithm, 256-bit) to create a unique fingerprint of the report contents.

SHA-256 takes any input — a 50-page PDF, a single sentence, or a terabyte file — and produces a fixed-length 256-bit (32-byte) output called a digest or hash. This hash has critical properties:

• Deterministic — The same input always produces the same hash
• Irreversible — You cannot reconstruct the input from the hash
• Collision-resistant — It is computationally infeasible to find two different inputs that produce the same hash
• Avalanche effect — Changing a single bit of the input produces a completely different hash

When TurboPentest generates a report, it computes the SHA-256 hash of the complete PDF file. This hash is the report's fingerprint. If anyone changes even one byte of the report — a single character in a finding description, a modified severity rating, or an added page — the hash will be entirely different.

To verify a report's integrity, you compute the SHA-256 hash of the PDF you have and compare it to the hash recorded on-chain. If they match, the report has not been modified since attestation. If they differ, the report has been tampered with.

Merkle Tree Anchoring

Computing a SHA-256 hash for each report is straightforward, but writing every individual hash to the blockchain would be expensive and slow. TurboPentest uses Merkle trees to batch multiple attestations into a single on-chain transaction.

How a Merkle Tree Works

A Merkle tree is a binary tree of hashes. Here is how TurboPentest constructs one:

1. Leaf nodes — Each report hash becomes a leaf in the tree. If there are 8 reports in a batch, there are 8 leaf nodes.
2. Pairwise hashing — Adjacent leaves are concatenated and hashed together: SHA-256(hash_A + hash_B) produces a parent node.
3. Recursive construction — This process repeats up the tree until there is a single root hash — the Merkle root.
4. Root anchoring — Only the Merkle root is written to the blockchain.

The Merkle root is a single 32-byte hash that cryptographically represents all reports in the batch. If any one report in the batch changes, its leaf hash changes, which cascades up the tree and changes the Merkle root.

Merkle Proofs

To verify that a specific report is included in a Merkle root, you do not need access to all reports in the batch. You only need a Merkle proof: the sibling hashes along the path from your report's leaf to the root.

For a tree with 8 reports, the Merkle proof for any single report requires only 3 sibling hashes (log2(8) = 3). For a tree with 1,000 reports, you need only 10 sibling hashes. This logarithmic efficiency makes verification fast and lightweight.

TurboPentest stores the Merkle proof for each report alongside its metadata. When someone verifies a report, the system provides the report hash, the Merkle proof, and the on-chain Merkle root. The verifier can independently confirm that the report hash, combined with the proof hashes, produces the Merkle root recorded on the blockchain.

Base L2: The Attestation Chain

TurboPentest anchors Merkle roots on Base, an Ethereum Layer 2 (L2) rollup built on the OP Stack. This choice balances security, cost, and speed:

Why Layer 2 Instead of Ethereum Mainnet?

Ethereum mainnet provides maximum security but at significant cost. A simple data storage transaction on mainnet can cost $5-50+ depending on gas prices. For a platform that produces thousands of reports, this is not economically viable.

Layer 2 rollups inherit Ethereum's security guarantees while dramatically reducing costs. Base transactions cost fractions of a cent, making per-batch attestation economically feasible even at high volume.

Why Base Specifically?

• Ethereum security inheritance — Base posts transaction data to Ethereum mainnet, inheriting its security guarantees
• OP Stack foundation — Built on Optimism's open-source, battle-tested rollup technology
• Low cost — Transaction fees typically under $0.01, enabling frequent attestation batches
• Coinbase backing — Operated by Coinbase with strong infrastructure reliability
• EVM compatibility — Standard Ethereum tooling, wallets, and block explorers work directly

The Anchoring Process

TurboPentest's attestation pipeline runs on a scheduled cadence:

1. Collection — New report hashes are collected since the last anchoring batch
2. Tree construction — A Merkle tree is built from all collected hashes
3. Root extraction — The Merkle root is extracted from the tree
4. On-chain transaction — A transaction is submitted to Base containing the Merkle root, batch timestamp, and batch metadata
5. Confirmation — Once the Base transaction is confirmed (typically seconds), the transaction hash is recorded
6. Proof storage — Each report's Merkle proof and the Base transaction hash are stored in TurboPentest's database

The Base transaction is publicly visible on any Base block explorer. Anyone can look up the transaction, see the Merkle root, and verify it against a report's Merkle proof.

What Attestation Proves

Blockchain attestation proves three things:

1. Existence — The report existed at the time the Merkle root was anchored on-chain
2. Integrity — The report contents have not changed since attestation (hash verification)
3. Temporal ordering — The blockchain timestamp provides a trustworthy record of when the attestation was created

It does not prove that the report's findings are accurate or that the pentest was conducted competently. It proves that this specific document existed in this exact form at this specific time — which is precisely what auditors and compliance frameworks need.

The Verification Pipeline

End-to-end verification works as follows:

1. An auditor receives a pentest report PDF
2. They compute the SHA-256 hash of the PDF
3. They look up the report's attestation on TurboPentest (or use the verification link — covered in Module 6)
4. The system provides the Merkle proof and Base transaction hash
5. The auditor verifies the Merkle proof against the on-chain Merkle root
6. If the computed hash matches the attested hash, the report is verified as unmodified since attestation

Every step of this process is independently verifiable. The auditor does not need to trust TurboPentest — they can verify the SHA-256 hash themselves, check the Merkle proof mathematically, and read the Merkle root directly from the Base blockchain.