Graph Aware Sync Protocol
Two parties who each hold part of a transaction history need to reconcile without sending each other everything. This describes a back-and-forth that works out exactly what is missing and fills only the gaps.
Summary
- Why
- Two parties holding overlapping but incomplete sets of transaction data need a way to find the gaps and fill them in without re-sending everything or trusting unverified claims.
- What
- GASP (Graph Aware Sync Protocol) is an exploratory proposal describing how two parties compare transaction sets using a bloom filter and recursively exchange only the transactions, metadata, and merkle proofs each side is missing.
- How
- One party sends a bloom filter of everything it holds, the other replies with an inventory of items not covered by that filter, and each side keeps requesting missing transactions, metadata, or proofs recursively until nothing is left unaccounted for, then the roles swap.
What this lets you do
- Compare two transaction sets without sending full data upfront
- Request only the transactions and metadata actually missing
- Verify each received transaction against a merkle proof before accepting it
- Recursively chase down unknown input transactions until fully proven
- Sync in both directions by reversing roles after one pass completes
Written by claude-sonnet-5 from the specification text. Where the two differ, the original is correct.
Reference for an AI
Everything an assistant needs to answer questions about BRC-76 accurately, including what it depends on.
The specification
Abstract
GASP is designed to synchronize transaction data between two parties in a blockchain environment. It ensures the legitimacy and completeness of transaction data using a recursive reconciliation method.
Status Note
This document is an exploratory graph synchronization proposal. It is not the current wallet-toolbox user wallet storage synchronization protocol. Current wallet-toolbox storage synchronization is the chunked, resumable storage-provider protocol specified by BRC-40. Current transaction exchange and wallet APIs generally use BEEF / Atomic BEEF rather than the bloom-filter INV flow described here.
Participants
- Alice: Initiates the sync process.
- Bob: Responds and participates in the sync process.
Protocol Steps
-
Initialization
- Alice starts by sending a bloom filter containing all current spendable TXID+VOUTs as elements.
-
Receiving and Building List
- Bob receives the filter and builds a list of his items that are not members of the set.
-
Transaction Verification
- Bob sends an INV (Inventory) message to Alice for each item not in the set.
- The INV includes:
- Output, transaction, and associated merkle proof.
- Any metadata (such as labels, descriptions, or local timestamps) associated with transactions or outputs.
- A list of VOUTs spent by its inputs and associated metadata hashes.
- The preimage for each hash, including all metadata and the merkle proof or broadcast response.
-
Alice's Response
- For each INV, Alice responds with a list of input transactions she does not know about.
- If Alice has the transaction but the metadata hash differs, she requests updated metadata.
- If Alice lacks the transaction, she requests the entire transaction.
-
Recursive Transaction Sync
- Bob responds to Alice's requests with an INV containing the encompassing transaction, done recursively.
- When including the full transaction, all metadata is provided.
- When only metadata is included, it encompasses the list of spent VOUTs and associated metadata hashes.
- Bob responds to Alice's requests with an INV containing the encompassing transaction, done recursively.
-
Error Handling and Recovery
- In case of errors, affected transactions are ignored and not synced.
- If errors prevent a party from fully anchoring transactions back to the blockchain, these transactions are ignored.
- Failures experienced by one party are not communicated to the other due to the declaratory nature of the protocol.
-
Finalization of Sync
- The process continues until there are no more INVs for Bob to send.
- Once complete, all of Bob's records are considered synced with Alice.
-
Role Reversal
- The roles reverse, with Bob sending Alice a bloom filter.
- The parties then exchange data in the other direction, following the same steps.
Security Measures
- Verification of merkle proofs and the longest chain of block headers.
- Recursively requesting information until all inputs are fully proven.
- Invalidating transactions that cannot be linked back to a valid proof.
Notes
- The protocol is adaptable to various blockchain environments.
- The recursive nature ensures thorough and complete data synchronization.
- The protocol emphasizes security, efficiency, and data integrity.
Conclusion
GASP offers a robust and secure method for synchronizing transaction data between parties in a blockchain network, leveraging recursive data exchange and thorough verification mechanisms.