## 4 Discussion
Storage on the blockchain is inherently expensive due to the need for each piece of data to be replicated across all nodes in the network, ensuring immutability and consensus. Consequently, applications that store large amounts of data will incur higher costs, which could become prohibitively high depending on network congestion, adding uncertainty to the process. Additionally, the complexity and frequency of smart contract executions directly impact operational expenses, as each function call to a smart contract consumes gas, the unit of computational work in blockchain ecosystems like Ethereum. Complex smart contracts with multiple functions and extensive logic require more gas to execute, increasing costs. Furthermore, the design of the smart contract can influence cost efficiency; thus, well-optimised contracts can minimise unnecessary computations and storage, thereby reducing gas consumption. As a consequence, careful consideration of data-storage requirements and smart contract functionality is instrumental in managing and optimising the operational costs of traceability blockchain applications. In this context, a solution biased towards the notarisation-only approach will have clear advantages. For example, it will incur lower storage costs, as storing a hash key (i.e, 32 bytes per batch for a SHA-256 hash) instead of the full batch payload significantly reduces the storage costs on the blockchain. In addition, storing only batches' hash keys makes the system more scalable, as there is no need to store large volumes of data on the blockchain, with a consequent increase in the blockchain load, where each node stores a full copy of the chain, increasing the resources needed to complete storage transactions. Blockchains are not designed to store large volumes of data, and are generally not scalable or efficient as an off-chain storage solution (cf. Section 4.1 below). With respect to privacy, storing just the hash key does not reveal the original content, which provides an additional layer of privacy, as someone viewing the hash digest on the blockchain cannot deduce the original content without having access to it. This is especially relevant considering that all information transferred to a blockchain is immutable and persistent over time, and storing the full content on the blockchain exposes the data to all participants in the network. Even if no personal information is managed, information could be stored that could be of interest to competitors in the future, or detrimental to the future strategies of producers or operators. Still, this scenario ensures the immutability and verifiability of the information. Once the hash key is stored in the blockchain, it is guaranteed to be immutable, so that any modification to the external content can be easily detected by comparing the hash digest of the challenged content with that stored in the blockchain. As disadvantages of the first scenario, which in turn would be advantages of solutions biased towards the full on-chain storage, we can point out its dependence on external storage. Reliable and persistent external storage is required for the actual batch data. Verification depends on the original content remaining accessible over time. In addition, to verify data integrity, the original content must be accessed and the hash recalculated. This adds an additional step in the verification process and can be challenging if the content is not immediately available or is large in size. In addition, an external-only backend adds complexity. Mechanisms are also needed to hash the content and compare it with the hash stored in the blockchain to verify integrity. However, with today's development environments and the wide availability of backend solutions of many different types and flavours, this aspect is becoming less and less relevant.