# DPtracer: Integrating Log-Driven Accountability into Data Provision Networks
## 5 DPTracer Protocol
### Submitter  
The submitter is a designated aggregator node and submits the final aggregated result to the data requester. Before submission, the submitter assesses the sufficiency of the input and aggregation for that round to ensure the results have been thoroughly processed by the nodes. Figure 6b demonstrates the operations of the submitter. The detailed operations are as follows:  
1. (Submitter) LogRequest\((\mathbb{R},\mathbb{C})\rightarrow(R,\mathbb{C})\): This operation is the same as that of other nodes as detailed in Section 5.1. For example, as illustrated in Figure 6b, step (1), the submitter \(n_{N}\), which is the final aggregator node, receives input reports and commitments \(R_{N-1}\) and \(C_{\mathsf{v}(N-1)}\), respectively. It then compiles its report \(R_{N}\) and includes \(C_{\mathsf{v}(N-1)}\) in the \(\mathbb{C}\), and it sends them to the logger.  
2. (Logger) LogUpdate\((R,\mathbb{C})^{\prime}\rightarrow(C,\pi,\mathbb{L})\mid\bot\): This operation is similar to LogUpdate\(()\) performed by nodes, but it additionally includes an engagement list \(\mathbb{L}\). When the logger recognizes LogRequest\(()\) from the submitter, it recursively traces the input versions \(\mathbb{V}\) from the submitter's log entry in Process Tree down to the child nodes' \(\mathbb{V}\). Accordingly, the logger can gather all versions and identifiers of external data sources into \(\mathbb{L}\) and can capture only the versions and external source identifiers that influence the final results.
3. (Submitter) Submit\((\mathbb{R},\mathbb{C},R,C,\pi,\mathbb{L})\rightarrow(R,\mathbb{V},C)\mid\bot\): As the final step in data provisioning, the submitter verifies the integrity of its direct inputs and the logger's records using \(\mathbb{R}\), \(R\), \(C\), and \(\pi\). This step mirrors the verification described in ReportSend\((\mathbb{R},\mathbb{C},R,C,\pi)\) and is detailed in Algorithm 2. Once the integrity is confirmed, the submitter reviews the engagement level of nodes and external data sources with \(\mathbb{L}\). If this engagement level is below a predefined threshold \(\mathbb{T}\), which varies depending on the DPN application, the submitter may reject the final result. A low engagement level indicates that the results may not sufficiently reflect a diverse range of data sources or may lack adequate consensus among nodes, possibly caused by intentional delivery omission. In such cases, the submitter sends \(\bot\) to the data requester to notify it that the final result is rejected. If all conditions are satisfied, the submitter transmits the final result \(R_{N}\), including its input version set \(\mathbb{V}_{N}\) and commitment \(C_{N}\), to the data requester, as depicted in Figure 5(b).  
```
1:procedureSubmitter.Submit\((\mathbb{R},\mathbb{C},R,C,\pi,\mathbb{L})\)
2:input\(\mathbb{R}\): List of input reports
3:input\(\mathbb{C}\) : List of input commitments
4:input\(R\): Submitter's own report
5:input\(\mathbb{C}\): Commitment received along with the report
6:input\(\pi\): Interval proof for verification
7:input\(\mathbb{L}\): List of node IDs
8:
9:for each \((w,q)\) in \((\mathbb{R}\cup\{R\},\mathbb{C}\cup\{C\})\)do
10:if not IsFound\((w,\pi)\)
11:or ComputeRoot\((\pi,\text{ExtractVersion}(q))\
eq q\)then
12:return\(\bot\)
13:endif
14:endfor
15:if not IsFound\((\text{ExtractVersionSet}(\mathbb{C}),\pi)\)then
16:return\(\bot\)
17:endif
18:
19:\(v\leftarrow\text{ExtractVersion}(C)\)
20:if ComputeEngagementLevel\((\mathbb{L},v)<\mathbb{T}\)then
21:return\(\bot\)
22:endif
23:
24:\(\text{SendFinalResult}(R,\text{ExtractVersionSet}(\mathbb{C}),C)\)
25:endprocedure
```  
**Algorithm 2** Submission