Ty Everett (ty@projectbabbage.com)
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.
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.
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.
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.
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.
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.
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.
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.
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:
- 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).
- 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.
- Model the transaction inputs as a Poisson process or another suitable stochastic process that reflects real-world arrival patterns.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.