# DPtracer: Integrating Log-Driven Accountability into Data Provision Networks
## 8 Evaluation
### Real-World Deployment Scenarios  
In this section, we evaluate DPTracer by reflecting on real-world DPN deployments. Chainlink and Pyth Network are two well-known oracle networks that operate based on the DPN model. However, since their network topologies are not publicly disclosed, we make assumptions based on the available service status information from their official websites [26; 27] and define two network scenarios to approximate real-world deployments:  
* **Direct Aggregation DPN (DA-DPN)**: In this scenario, the final result is decided by a single level of aggregator nodes directly connected to the collector nodes. The submitter acts as the final aggregator and the data requester. The Chainlink ETH/USD Price Feed [26] represents this scenario, where the final price is decided by a quorum of aggregator nodes at an on-chain smart contract, which serves as the final aggregator.
* **Network Aggregation DPN (NA-DPN)**: This scenario involves a network of nodes participating in the aggregation and validation of data. The aggregator network handles multiple types of data from various sources and thus represents a more  
Figure 10: Communication overhead.  
complex and large-scale DPN compared to DA-DPN. The Pyth Network [14] reflects this scenario, where data providers perform validation and aggregation of price data.  
Figure 11 illustrates the node configurations for two scenarios. Using the configurations of aggregator nodes, we instantiate the scenarios with the node configurations according to our DPN model (Section 3.5), including collector nodes and aggregator nodes. For the DA-DPN scenario, we set the number of aggregator nodes to 31 based on the Chainlink ETH/USD Price Feed [26] (as of September 2024). For the NA-DPN scenario, we set the number of aggregator nodes to 114, matching the number of data providers in Pyth Network [27] (as of September 2024).  
Price sources encompass various forms of price data, such as APIs and on-chain smart contracts. To represent the normalization and preprocessing required in data collection, which can differ depending on price sources, we assign collector nodes to the price sources. In the DA-DPN scenario, assuming multiple data sources per aggregator node, we set the number of collector nodes to 123 (three data sources per aggregator node). For NA-DPN, we refer to the number of serving price feeds in Pyth Network, which is 507, as the number of collector nodes since it reflects the average number of unique data types handled within the aggregator network. In total, the number of nodes in the DA-DPN and NA-DPN scenarios are 154 and 621, respectively.  
Figure 12 shows the overheads in the DA-DPN and NA-DPN scenarios. The overall overhead of the NA-DPN is higher due to the larger number of nodes and the complexity of the network structure. However, the high aggregation factor (maximum \(d=31\)) in the DA-DPN, resulting from single-level aggregation, leads to increased memory usage and communication overheads. In contrast, the NA-DPN has a lower aggregation factor (\(d=15\)) as multi-level aggregation can be applied in the aggregator network.  
Figure 11: Real-world deployment scenarios of price oracle networks.  
The results in Figure 12 illustrate that the network configuration significantly impacts the performance of the DPN. However, the overheads for both scenarios are still within acceptable limits for real-world DPN deployments. Even in the more complex NA-DPN scenario, DPTracer incurs less than 800 KBytes of network-wide communication overhead and generates commitments and proofs in under 0.05 ms, which is well within the typical round time for oracle networks (ranging from 400 ms to 6 s).