# DPtracer: Integrating Log-Driven Accountability into Data Provision Networks
## 5 DPTracer Protocol
### Nodes
(Logger) LogUpdate\((R,\mathbb{C})\rightarrow(C,\pi)\mid\bot\): When a log request from an aggregator node is received, the logger verifies the commitments in \(\mathbb{C}\) to ensure that each commitment corresponds accurately to the Process Tree root of the specific version. The versions of the inputs, which are encoded in the commitments, are collected into a set \(\mathbb{V}\). If any commitment mismatches, the logger halts the process and returns \(\bot\) to the node and notifies of the inconsistency. If all commitments are verified, the logger assigns a new version number \(v\) to \(R\), composes \(X_{v}\) as \((R,\mathbb{V})\), and adds \(X_{v}\) to Process Tree at the corresponding group. Subsequently, a new commitment \(C_{v}\) is calculated. Using the updated Process Tree, the logger generates an interval proof \(\pi\) that spans the input versions in \(\mathbb{V}\) and includes the new version \(v\). Finally, it sends back \(C_{v}\) and \(\pi\) to the node. For instance, in Figure 6a, step (2), after verifying the commitments in \(\mathbb{C}\), the logger assigns a new version for \(R_{k}\), denoted as \(\mathsf{v}(k)\). It then adds \(R_{k}\) along with its input versions \(\left\{\mathsf{v}(i),\mathsf{v}(j)\right\}\) as a new leaf element, computes \(C_{\mathsf{v}(k)}\), and generates \(\pi_{\mathsf{v}(i),\mathsf{v}(j),\mathsf{v}(k)}\), confirming that \(R_{i}\), \(R_{j}\), and \(R_{k}\) are accurately recorded in the DPLog. For collector nodes, the logger uses the received source IDs in the place of \(\mathbb{V}\) in \(X_{v}\) without verifying input commitments and generates \(\pi_{v}\) for the current output solely. The rest of the process remains the same as that for the aggregator. 3. (Node) Report\(\mathsf{Send}(\mathbb{R},\mathbb{C},R,C,\pi)\rightarrow(R,C)\mid\bot\): The node receives the new commitment for its report from the logger and verifies the two conditions. First, the node checks whether all the input reports in \(\mathbb{R}\) and its own report \(R\) correspond with the entries in \(\pi\), which should contain all target reports from Process Tree. It also confirms that its input version set is correctly contained in \(\pi\). Second, the node verifies that all input commitments in \(\mathbb{C}\) and the received commitment \(C\) match the corresponding commitment recalculated from \(\pi\). Notably, collector nodes are required to perform these verifications only for their own \(R\) and \(C\). If all conditions are satisfied, this confirms that all input nodes have faithfully delivered their reports without any modification and that \(R\) is correctly logged in the DPLog. Consequently, the node forwards the report and commitment \((R,C)\) to the parent node in the Report Tree. If any condition is not met, the process is halted, and no data are forwarded. In Figure 6a, step (3), \(n_{k}\) receives \(C_{\mathsf{v}(k)}\) and \(\pi_{\mathsf{v}(i),\mathsf{v}(j),\mathsf{v}(k)}\) and then verifies that \(R_{i}\), \(R_{j}\), \(R_{k}\) and \(\mathbb{V}\) (extracted from \(\mathbb{C}\)) are included in \(\pi_{\mathsf{v}(i),\mathsf{v}(j),\mathsf{v}(k)}\). It also confirms that \(C_{\mathsf{v}(i)}\), \(C_{\mathsf{v}(j)}\), and \(C_{\mathsf{v}(k)}\) are accurately recalculated from it. If all conditions hold true, \(n_{k}\) ensures the integrity of the inputs and the DPLog and sends \(R_{k}\) and \(C_{k}\) to the next node.