## 3 Results
### A Generic Blockchain-Based Traceability System
Examples of such data are the unique identifier of the new node, the unique identifier of its creator, and the unique identifiers of the nodes from the previous step in the trace contributing to the new node. Traceability-critical data are immutable by nature and can be used to reconstruct the structure of the whole upstream trace from just the content of the blockchain, and to rebuild the general DAG table discussed in Section 2.1. 3. Complementary data. These data may be dynamic and change over time, such as quality records, real-time inventory data, transportation and logistics information, pictures, catalogue content, etc. Traceability-critical data are stored as part of the state information of the traceability smart contract by means of the data structures below (cf. Figure 4):  
* A record collecting the public blockchain address of the owner or creator of the batch; the SHA-256 hash key of the traceability-relevant data; a JavaScript Serialised Object Notation (JSON) record with the contributions to the new node. * A mapping that binds node IDs to node records. Figure 4 includes, as a matter of example, additional fields that may be considered critical for specific applications. For example, a boolean field to mark a given node as cancelled if the specific applications support node deletion (note that in a blockchain information cannot be actually deleted as it is immutable), or a field keeping track of the units remaining of a given batch to contribute to other batches downstream. The actual data structure storing all traceability nodes is mapping _nodes in Figure 4. According to object-oriented encapsulation principles, this structure will not be directly visible by external code, and access to it will be performed through the corresponding getters and setters, as discussed below. The JSON record embedded in the Node record collects the minimal information required to reconstruct the structure of a backwards trace, namely the list of all contributions to the new node, each contribution represented as a pair \((id,\,d_{hash})\) where \(id\) is the ID of the contributing node and \(d_{hash}\) is a cryptographic digest of the details of that contribution (cf. Figure 5). In cases where the contribution details are simple (e.g., just the number of units contributed and/or the CO\({}_{2}\) balance of that operation), that information may be stored directly in the JSON record. It can be argued that contributions may also be stored as an array of records. However, this would require further processing on-chain, involving loops, which would compromise efficiency, cost, and security, while processing that (simple) data structure off-chain would not involve relevant additional complexity. Figure 4: Solidity code for the declaration of the data structure utilised to store traceability-critical data as part of the smart contract’s state. Figure 3: Basic data model for a blockchain-based traceability solution. Function createNode in Figure 6 exemplifies how a new node is notarised in the blockchain. It checks that the caller is authorised to create new traceability nodes and that the node does not already exist, creates the node with the provided details, and emits an event to log the creation. This function ensures traceability by recording the creator, the hash digest of the node's payload, contributions, and initial remaining units, thereby maintaining the integrity and auditability of the traceability system. In general, an event will be generated every time a new node is created in the blockchain, and every time one critical data item is modified, if allowed by the application. Before creating the new node, creator verification and node existence checks are performed using guards (i.e., require operator). If any of the checks fail, function execution terminates and the blockchain transaction is reverted. Creator verification is supported by an additional mapping that maps blockchain registered creator addresses to a boolean true value, or to some real-world creator identifier (e.g., fiscal number, ID card, etc.).