Steps of Transaction Proving

The transaction proving process enables Attestcoin Smart Contracts to trustlessly verify and use data from source chains. The process consists of four main phases:

1. Query Phase: Identifying the target transaction for verification

2. Proof Generation Phase: Creating Merkle and continuity proofs

3. Verification Phase: Cryptographic verification of the proofs

4. Data Extraction Phase: Extracting transaction data from verified bytes

Transaction Proving Visualized

Phase 1: Query Phase

A query specifies what needs to be proven:

• Source Chain: Which blockchain the transaction occurred on (identified by chainKey)

• Block Height: Which block contains the transaction

• Transaction: The specific transaction to verify (identified by transaction index or hash)

Example: "Prove that transaction at index 5 in block 18,000,000 on Ethereum mainnet actually occurred."

This query information is used to:

• Retrieve transaction data from the source chain

• Determine which source chain blocks need to be fetched

• Identify which attestations are needed for continuity proof

Phase 2: Proof Building Phase

The Proof Builder service creates two complementary proofs that together prove the transaction is legitimate.

2.1 Generating Merkle Proofs

The service then requests the block at the specified height from a source chain RPC node. All transactions in the block are hashed to form a Merkle tree, with the Merkle root stored in the block header. The Merkle proof consists of:

• The Merkle root (from block header)

• Array of sibling hashes with position information

• The transaction bytes themselves

By providing the sibling hashes and the transaction bytes, anyone can reconstruct the path to the Merkle root. If the computed root matches the block header's root, the transaction is proven to be in that block.

2.2 Generating Continuity Proofs

Finally the service then takes our query block height and determines that query's attestation bounds. Attestation bounds consist of the closest attestations above and below the query block height.

Next, the server fetches all the source chain blocks between our lower and upper attestation bounds. These blocks are used to form a continuity proof as detailed in our next section, Continuity Proving for Queries

Now that both proofs have been generated, our Proof Builder returns the following:

• Merkle Proof: Proves transaction inclusion in a block

• Continuity Proof: Proves the block is part of the finalized source chain

• Encoded Transaction: The full transaction bytes (transaction + receipt data)

These three components together provide complete cryptographic proof that the transaction occurred on the source chain.

Phase 3: Verification Phase

The off-chain worker (or user) calls the ASC contract function with the proofs and encoded transaction bytes. The ASC contract then calls the native query verifier precompile to verify the proofs.

3.1 Merkle Proof Verification process:

• Start with: leafHash = hash(transaction_bytes)

• For each sibling: combine with sibling hash (left or right based on position)

• Final step: Check computedRoot == merkleRoot (from continuity proof roots array)

3.2 Continuity Proof Verification process:

• Starting from the back of the continuity chain, compute the following for each block: computedDigest = hash(block_number, merkleRoot, previousDigest)

• Final step: Verify that finalDigest == onChainAttestationDigest

The verification happens synchronously in the same transaction execution.

• No Waiting: Results are available within seconds

• Atomic: Either all verification steps succeed (transaction continues) or all fail (transaction reverts)

• No Intermediate State: No query storage, no async processing, no waiting for finalization

ASC contracts can use verified data immediately in the same transaction, enabling complex cross-chain logic without multi-step async flows.

Phase 4: Data Extraction Phase

After verification succeeds, the ASC contract extracts the data it needs from the verified transaction bytes. The encodedTransaction bytes contain the full transaction data. It can be used to decode the transaction type, common fields, type-specific fields and the receipt fields.

Once data is extracted, the ASC contract:

• Validates the extracted data (e.g., receipt status = success, expected event found)

• Executes business logic based on the verified cross-chain data

• Updates contract state or triggers additional actions

Example: A bridge contract might:

1. Verify a Transfer event showing tokens were burned on Ethereum

2. Extract the from, to, and value from the event

3. Mint equivalent tokens on Creditcoin to the to address