|
1 | | -# ERC-8002: SPV Gateway |
| 1 | +# ERC-8002: SPV Gateway |
2 | 2 |
|
3 | | -Introduce a singleton contract for on-chain verification of transactions that happened on Bitcoin. The contract acts as a trustless Simplified Payment Verification (SPV) gateway where anyone can submit Bitcoin block headers. The gateway maintains the mainchain of blocks and allows the existence of Bitcoin transactions to be verified via Merkle proofs. |
| 3 | +This repository contains the smart contracts and services for the `SPV Gateway` — protocol that enables the trustless on-chain verification of transactions that happened on the Bitcoin network. |
4 | 4 |
|
5 | | -Link to [ERC-8002](https://ethereum-magicians.org/t/erc-8002-simplified-payment-verification-gateway/25038). |
6 | | - |
7 | | -> [!NOTE] |
8 | | -> Since the ERC is currently a draft, there is no deployment on mainnet available. Please use [the contract on Sepolia](https://sepolia.etherscan.io/address/0xE8e6CA2113338c12eb397617371D92239f3E6A60) for testing purposes. |
9 | | -
|
10 | | -# How it Works |
11 | | - |
12 | | -The gateway is a permissionless contract that operates by receiving raw Bitcoin block headers (anyone can submit them), which are then parsed and validated against Bitcoin's consensus rules: |
13 | | - |
14 | | -1. Header Parsing: Raw 80-byte Bitcoin block headers are parsed into a structured *BlockHeader.HeaderData* format, handling Bitcoin's little-endian byte ordering. |
15 | | -2. Double SHA256 Hashing: Each block header is double SHA256 hashed to derive its unique block hash, which is then saved in a big-endian format. |
16 | | -3. Proof-of-Work Verification: The calculated block hash is checked against the current network difficulty target (derived from the *bits* field in the block header). |
17 | | -4. Chain Extension & Reorganization: New blocks are added to a data structure that allows for tracking multiple chains. When a new block extends a chain with larger cumulative work, the *mainchainHead* is updated, reflecting potential chain reorganizations. |
18 | | -5. Difficulty Adjustment: Every 2016 blocks, the contract calculates a new difficulty target based on the time taken to mine the preceding epoch. This ensures the 10-minute average block time is maintained. |
19 | | - |
20 | | -Under the hood, the contract builds the mainchain but doesn't define its finality. The number of required block confirmations is up to the integration dApps to decide. |
21 | | - |
22 | | -## Submitting Bitcoin Blocks |
23 | | - |
24 | | -To submit a new Bitcoin block, call `addBlockHeader` function by passing a valid raw block header as a parameter. It is an open function that will revert in case Bitcoin PoW checks don't pass. |
25 | | - |
26 | | -In case multiple blocks can be added, call `addBlockHeaderBatch` function to save ~15% on gas per block. |
27 | | - |
28 | | -## Verifying Bitcoin Tx Inclusion |
29 | | - |
30 | | -In order to verify the tx existence, the `checkTxInclusion` function needs to be called. |
31 | | - |
32 | | -The list parameters to be passed: |
33 | | - |
34 | | -1. `merkleProof` - Merkle path for a given transaction to be checked. The Merkle path can either be built locally or by calling `gettxoutproof` on a Bitcoin node. |
35 | | -2. `blockHash` - Hash of the block to check the tx inclusion against. This block is required to exist in the SPV storage. |
36 | | -3. `txId` - Tx hash (Merkle leaf) to be checked. |
37 | | -4. `txIndex` - The Merkle "direction bits" to decide on left or right hashing order. |
38 | | -5. `minConfirmationsCount` - Number of required mainchain confirmation for the block to have. |
39 | | - |
40 | | -> [!TIP] |
41 | | -> Please check out [this test case](./test/SPVGateway.test.ts#L223) for more integration information. |
42 | | -
|
43 | | -## Permissionlessness |
44 | | - |
45 | | -In order for the gateway to be truly permissionless, the contract's initialization needs to be permissionless as well. Alongside the regular `SPVGateway`, the repository hosts a `HistoricalSPVGateway` contract, that uses a "proof-of-bitcoin" ZK proof for its initialization. This enables verification of historical Bitcoin blocks and transactions otherwise too expensive to include. Since syncing up the gateway from Bitcoin's genesis would cost ~100 ETH on the mainnet. |
46 | | - |
47 | | -# HistoricalSPVGateway |
48 | | - |
49 | | -`HistoricalSPVGateway` is an extension of the basic `SPVGateway` contract. It uses "proof-of-bitcoin" ZK proof that compresses the entire Bitcoin block history into a single Merkle root to be used during the contract's initialization. This root can then used to verify the "historical" existence of some blocks and transactions. |
50 | | - |
51 | | -> [!IMPORTANT] |
52 | | -> Currently, the "proof-of-bitcoin" ZK proof is generated to the first *912384* Bitcoin blocks. The circuits source code can be found [here](https://github.com/distributed-lab/bitcoin-prover). |
53 | | -
|
54 | | -## Building the History Merkle Tree |
55 | | - |
56 | | -In order to prove the historical block existence, you need to pass the corresponding Merkle path to a smart contract. For that, the entire historical Merkle tree needs to be built: |
57 | | - |
58 | | -1. Fetch all block hashes from the genesis block up to the height of `provedBlocksCount - 1`. |
59 | | -2. Split these blocks into *1024-block* chunks. |
60 | | -3. Create Level1 Merkle trees for each chunk. |
61 | | -4. Create an array containing all the Level1 tree roots. |
62 | | -5. Pad the array from the previous step with zeros for its length to reach the next power of 2. |
63 | | -6. Create a Level2 Merkle tree, using the array from the previous step as the tree's values. |
64 | | - |
65 | | -> [!NOTE] |
66 | | -> For the Level1 Merkle tree use `SHA256("leaf1" | blockHash)` and `SHA256("node1" | left | right)` for hashing leaves and nodes. And for the Level2 Merkle tree, `SHA256("leaf2" | level1MerkleRoot)` and `SHA256("node2" | left | right)` respectively. |
67 | | -
|
68 | | -## Verifying History Bitcoin Blocks Inclusion |
69 | | - |
70 | | -To verify the existence of a historical Bitcoin block, call the `checkHistoryBlockInclusion` function. |
71 | | - |
72 | | -This function requires a `HistoryBlockInclusionProofData` struct as a parameter, which contains the following fields: |
73 | | - |
74 | | -1. `level1MerkleProof` - Level1 Merkle path for the block hash being checked. |
75 | | -2. `level2MerkleProof` - Level2 Merkle path for the Level1 Merkle root (which is calculated from the `level1MerkleProof`) |
76 | | -3. `blockHash` - Block hash to be checked. |
77 | | -4. `blockHeight` - Block height of the passed block hash. |
78 | | - |
79 | | -> [!TIP] |
80 | | -> Please check out [this test cases](./test/HistoricalSPVGateway.test.ts#L181) for more integration information. |
81 | | -
|
82 | | -## Verifying History Bitcoin Tx Inclusion |
83 | | - |
84 | | -In order to verify the tx existence in the proven Bitcoin history, the `checkHistoryTxInclusion` function needs to be called. |
85 | | - |
86 | | -The list of parameters to be passed: |
87 | | - |
88 | | -1. `merkleProof` - Merkle path for a given transaction to be checked. The Merkle path can either be built locally or by calling `gettxoutproof` on a Bitcoin node. |
89 | | -2. `blockHeaderRaw` - Raw block header of the block to check the transaction's inclusion against. |
90 | | -3. `txId` - Tx hash (Merkle leaf) to be checked. |
91 | | -4. `txIndex` - The Merkle "direction bits" to decide on left or right hashing order. |
92 | | -5. `blockInclusionProofData` - The proof data for the historical block hash inclusion. |
93 | | - |
94 | | -> [!TIP] |
95 | | -> Please check out [this test case](./test/HistoricalSPVGateway.test.ts#L309) for more integration information. |
96 | | -
|
97 | | -# Disclaimer |
98 | | - |
99 | | -Bitcoin + Ethereum = <3 |
| 5 | +The protocol functions as a permissionless Simplified Payment Verification (SPV) gateway. Anyone can submit Bitcoin block headers to the gateway, which then validates them against Bitcoin's consensus rules. The gateway maintains the mainchain and allows dApps to verify a transaction's existence using Merkle proofs. |
0 commit comments