LogoLogo
  • README
  • Contribute
    • Discuss on Github
  • Example
    • Banana-Powered Bitcoin Wallet Control Protocol
  • Apps
    • The deployment-info.json Specification
  • Wallet
    • Transaction Creation
    • Data Encryption and Decryption
    • Digital Signature Creation and Verification
    • Input Redemption
    • HTTP Wallet Communications Substrate
    • XDM Wallet Communications Substrate
    • Window Wallet Communication Substrate
    • Wallet Transaction Output Tracking (Output Baskets)
    • Submitting Received Payments to a Wallet
    • Certificate Creation and Revelation
    • Unified Abstract Wallet-to-Application Messaging Layer
    • Transaction Labels and List Actions
    • Output Basket Removal and Certificate Deletion
    • Group Permissions for App Access
    • Extensible Proof-Type Format for Specific Key Linkage Claims
    • P Protocols: Allowing future wallet protocol permission schemes
    • P Baskets: Allowing Future Wallet Basket and Digital Asset Permission Schemes
    • Unified, Vendor-Neutral, Unchanging, and Open BSV Blockchain Standard Wallet-to-Application Interface
  • Transactions
    • Everett-style Transaction Envelopes
    • Simplified Payment Verification
    • Merkle proof standardised format
    • TSC Proof Format with Heights
    • Raw Transaction Format
    • TXO Transaction Object Format
    • Transaction Extended Format (EF)
    • Merkle Path JSON format
    • Compound Merkle Path Format
    • Background Evaluation Extended Format (BEEF) Transactions
    • Simplified Payment Verification
    • Merkle Path Binary Format
    • BSV Unified Merkle Path (BUMP) Format
    • Graph Aware Sync Protocol
    • Scalable Transaction Processing in the BSV Network
    • Atomic BEEF Transactions
    • BEEF V2 Txid Only Extension
  • Scripts
    • Bitcoin Script Binary, Hex and ASM Formats
    • Bitcoin Script Assembly Language
    • Pay to Public Key Hash
    • Pay to R Puzzle Hash
    • Pay to False Return
    • Pay to True Return
    • Push TX
    • Bare Multi-Signature
    • Pay to Push Drop
  • Tokens
    • There is no BRC-20
    • Definition of UTXOs as Bitcoin Tokens
    • Token Exchange Protocol for UTXO-based Overlay Networks
    • Mandala Token Protocol
  • Overlays
    • Overlay Network Data Synchronization
    • Confederacy Host Interconnect Protocol (CHIP)
    • Overlay Network Lookup Services
    • Confederacy Lookup Availability Protocol (CLAP)
    • Universal Hash Resolution Protocol
    • Overlay Network Transaction History Tracking
    • Private Overlays with P2PKH Transactions
    • Standardized Naming Conventions for BRC-22 Topic Managers and BRC-24 Lookup Services
    • Overlay Services Synchronization Architecture
    • Diverse Facilitators and URL Protocols for SHIP and SLAP Overlay Advertisements
  • Payments
    • Direct Payment Protocol (DPP)
    • Paymail Payment Destinations
    • Simple Authenticated BSV P2PKH Payment Protocol
    • PacketPay HTTP Payment Mechanism
    • Hybrid Payment Mode for DPP
    • HTTPS Transport Mechanism for DPP
    • Paymail BEEF Transaction
    • HTTP Service Monetization Framework
  • Peer-to-Peer
    • Authrite Mutual Authentication
    • PeerServ Message Relay Interface
    • PeerServ Host Interconnect Protocol
    • Identity Certificates
    • Genealogical Identity Protocol
    • Publishing Trust Anchor Details at an Internet Domain
    • Message Signature Creation and Verification
    • Serialization Format for Portable Encrypted Messages
    • Defining a Scalable IPv6 Multicast Protocol for Blockchain Transaction Broadcast and Update Delivery
    • Proven Identity Key Exchange (PIKE)
    • Peer-to-Peer Mutual Authentication and Certificate Exchange Protocol
    • HTTP Transport for BRC-103 Mutual Authentication
  • Key Derivation
    • BIP32 Key Derivation Scheme
    • BSV Key Derivation Scheme (BKDS)
    • Security Levels, Protocol IDs, Key IDs and Counterparties
    • Admin-reserved and Prohibited Key Derivation Protocols
    • Revealing Key Linkages
    • Protecting BRC-69 Key Linkage Information in Transit
    • Mnemonic For Master Private Key
    • Linked Key Derivation Scheme
    • Bidirectionally Authenticated Derivation of Privacy Restricted Type 42 Keys
    • Limitations of BRC-69 Key Linkage Revelation
    • Verifiable Revelation of Shared Secrets Using Schnorr Protocol
  • Outpoints
    • Format for Bitcoin Outpoints
    • Spending Instructions Extension for UTXO Storage Format
  • Opinions
    • Users should never see an address
    • List of user experiences
    • Legitimate Uses for mAPI
    • Security and Scalability Benefits of UTXO-based Overlay Networks
    • Improving on MLD for BSV Multicast Services
    • Web 3.0 Standard (at a high level)
    • Thoughts on the Mandala Network
    • Outputs, Overlays, and Scripts in the Mandala Network
  • State Machines
    • Simplifying State Machine Event Chains in Bitcoin
Powered by GitBook
On this page
  • Abstract
  • 1. Transaction Submission
  • 2. Transaction Stripping
  • 3. Edge-Level Stripped Transaction Graph Summarization
  • 4. Regional Aggregation
  • 5. Global Aggregation and Block Assembly
  • 6. Proof Completion
  • 7. Summary
  • 8. Future Work: Modeling the BSV Network
  • 8.1. Parameters and Metrics
  • 8.2. Modeling Steps
  • 8.3. Utilizing the Model

Was this helpful?

Edit on GitHub
Export as PDF
  1. Transactions

Scalable Transaction Processing in the BSV Network

Ty Everett (ty@projectbabbage.com)

Abstract

The BSV network is designed to process transactions at scale, leveraging a robust, distributed system of miners, validators, and aggregators. This system balances parallel processing with sequential validation, ensuring transactions are both processed rapidly and recorded in the correct order. Below, we document the detailed processes by which BSV miners will come to handle transactions at scale.

1. Transaction Submission

Users and services across the globe create and sign Bitcoin transactions, broadcasting them to the network. The network's miners collect these transactions at numerous Points of Presence (PoPs), which act as edge nodes in the BSV ecosystem. The following steps outline the process:

  • Preliminary Checks: Upon receiving a transaction, miners at PoPs verify its scripts, ensuring they comply with network standards and contain valid signatures. If valid, the transaction proceeds to the next stage.

  • Batching: After initial verification, the miners batch transactions, preparing them for forwarding to regional aggregators. This batching process occurs periodically, facilitating efficient transfer and further processing.

2. Transaction Stripping

After initial verification, transactions undergo a stripping process, which reduces each transaction to its essential elements:

  • Stripped Data: The remaining data includes:

    • The TXID and output indices of the consumed outputs.

    • The TXID of the transaction itself.

    • The number of new outputs it creates.

  • Graph Representation: The stripped transaction thus forms a node in the transaction graph, containing only the necessary information to link it to other transactions.

3. Edge-Level Stripped Transaction Graph Summarization

Where possible, edge validators summarize stripped transaction graphs before sending them to regional aggregators. This process is crucial in reducing the workload of higher-level aggregators:

  • Internal Transactions: The summarized graph only needs to include:

    • The TXIDs and output indices of previously consumed outputs.

    • The newly created outputs.

    • A merkle root for the transactions it includes.

    • The total amount of fees left for the miners.

  • Merkle Paths: The summarized graph also contains partial merkle paths, linking all transactions or child graphs to the merkle root of the summarized graph. However, this information only needs to be retained locally and never shared upwards.

4. Regional Aggregation

After receiving stripped transactions and summarized graphs, regional aggregators build subtrees of transactions:

  • Subtree Formation: Subtrees are groups of transactions or graphs, each forming a summarized graph with a merkle root and lists of outputs consumed and created.

  • Multi-Level Aggregation: Multiple levels of regional aggregation may occur in parallel, gradually integrating more of the completed transaction graph into larger structures.

  • Fee Tracking: Fees from child graphs are aggregated to track the total fees collected by the parent graph.

5. Global Aggregation and Block Assembly

Regional aggregators send subtree summaries to global aggregation systems, which then prepare the final block:

  • Graph Consistency: The system checks graph edges for consistency, ensuring no edge is consumed by one graph before being created by another.

  • Block Template: The block assembler combines these subtrees, including the coinbase transaction with the correct amount of fees, forming a finalized block template ready for hashing.

  • Proof of Work: Upon finding a valid proof-of-work header, the new block header is immediately propagated throughout the network for parallel validation by all systems.

6. Proof Completion

Once a valid header is found, it triggers a cascading parallel proof completion process:

  • Downstream Propagation: The header propagates down to all regional aggregators, who append the upper layers of the merkle tree to their subgraph roots.

  • Notifier Chain: Each regional aggregator notifies its child aggregators or edge validators, which in turn notify their children. This chain of notifications continues until all edge validators have completed proofs for all transactions they submitted.

  • End-User Notification: Finally, edge validators notify network end-users of the completed proofs available for their transactions.

7. Summary

The BSV network effectively balances parallel processing and sequential validation to achieve scalable transaction processing. By employing edge-level validation, regional aggregation, and global assembly, the system reduces the workload at higher levels, ensuring rapid, consistent processing. This layered, hierarchical approach to aggregation, alongside the use of transaction stripping and summarization, makes the BSV network a robust solution for scalable blockchain processing.

8. Future Work: Modeling the BSV Network

To model and describe the BSV network quantitatively, it is essential to focus on the parameters and metrics that influence the performance and scalability of the system. Here are some key components and steps to construct a quantitative model of the BSV transaction processing system:

8.1. Parameters and Metrics

Key Parameters

  • Transaction Arrival Rate: The rate at which transactions are received at edge nodes, typically expressed in transactions per second (tps).

  • Batch Size: The number of transactions processed together in batches at edge nodes before being sent to regional aggregators.

  • Transaction Processing Time: Time taken to verify and strip a single transaction.

  • Propagation Delay: The time it takes for information to travel from the edge nodes to the regional and global aggregators.

  • Aggregation Time: Time required to aggregate transactions into subtrees and summarize them into merkle roots at various levels (edge, regional, global).

Performance Metrics

  • Throughput: The total number of transactions processed per unit time across the network.

  • Latency: The total time taken from when a transaction is submitted until it is included in a validated block.

  • Resource Utilization: Measures how efficiently resources (computational, bandwidth) are used.

  • Scalability: The ability of the network to handle increasing transaction loads without a proportional increase in latency or resource costs.

8.2. Modeling Steps

Step 1: Transaction Input Modeling

  • Model the transaction inputs as a Poisson process or another suitable stochastic process that reflects real-world arrival patterns.

Step 2: Process Modeling at Edge Nodes

  • Model the batch processing as a queue where transactions are collected, verified, and stripped. Queuing theory, specifically a batch service queue model, can be applied here.

  • Calculate the processing rate of batches based on the transaction processing time and batch size.

Step 3: Summarization and Aggregation Modeling

  • Use a hierarchical tree model to represent the multi-level aggregation process. Each node in the tree represents an aggregation point (edge, regional, global).

  • Model the propagation of transaction summaries through this tree, accounting for delays and processing times at each node.

Step 4: Block Assembly and Propagation

  • Model the final block assembly as a sequential process that only begins once all necessary summaries and proofs are available.

  • Consider the proof-of-work process and its impact on block propagation and finality.

Step 5: Analytical Model Construction

  • Construct a series of equations or a simulation model that integrates these components. For example, use differential equations to represent the rate of change in the queue sizes, or develop a discrete-event simulation to model the dynamic interactions and delays.

Step 6: Validation and Simulation

  • Validate the model against real data or simulated data to ensure it accurately represents the BSV network's behavior.

  • Use the model to simulate different scenarios, such as increased transaction loads, changes in batch sizes, or different network delays, to study their impacts on throughput, latency, and scalability.

8.3. Utilizing the Model

  • Optimization: Use the model to find optimal parameters (e.g., batch size, number of edge nodes) that maximize throughput or minimize latency.

  • Capacity Planning: Estimate the resources needed to achieve certain performance metrics under expected future loads.

  • Scenario Analysis: Assess the impact of network changes or growth on performance and resource needs.

By quantitatively modeling these processes, the BSV network's design and operation can be better understood, optimized, and scaled to meet the demands of a high-volume, real-time transaction processing environment.

PreviousGraph Aware Sync ProtocolNextAtomic BEEF Transactions

Last updated 11 months ago

Was this helpful?