## 2 Materials and Methods
### Smart Contracts
Moreover, the execution environment for object-oriented applications is centralised, with the code running on a specific server or a client machine, where resource constraints like memory and processing power are relatively flexible, and always known in advance. In contrast, developing a smart contract involves writing code that runs on a blockchain node, which imposes specific constraints and considerations. For example, Ethereum smart contracts running on an EVM that in turn runs on a blockchain node must always terminate, and must be deterministic and secure since they manage digital assets and execute transactions autonomously. The execution environment is decentralised, and every operation has an associated fee, typically measured in gas, which translates to real-world monetary costs, at least in public blockchains. Due to the Turing-complete nature of the EVM, a mechanism is needed to guarantee smart contract termination [36]. In a nutshell, the EVM will keep executing smart contract code until the gas amount purchased by the executing address is depleted, and feeding more gas to the contract implies increasing amounts of real money. As a consequence of their unique audit and security-related requirements [37], the total cost of creating a smart contract in a public blockchain such as Ethereum can range from a few thousand Euro to hundreds of thousands, depending on several factors such as contract complexity, security characteristics, and legal considerations. In addition, there is also an important difference in the cost of invoking contract functions that change the state of the contract and those that just perform some computation or return some value without triggering state changes, as the former require a blockchain transaction that involves fees to compensate miners or validators who process and validate the transaction on the blockchain that would change the contract's state, whereas the latter require gas just to run the corresponding state-independent instructions (i.e., pure computations or consulting state information) and guarantee termination. A simple transfer of tokens might consume some Euros' worth of gas units, whereas a more complex function that includes multiple state changes or computations could become prohibitively expensive. Besides thoroughly auditing the code prior to deployment, optimising it to be as efficient and secure as possible is also required. Indeed, unlike traditional object-oriented code, smart contracts are immutable, meaning that any bugs, inefficiencies, or vulnerabilities are permanently embedded in the contract's code unless a new contract is deployed or the original contract is destroyed, making testing and security audits critical and more rigorous due to the irreversible nature of blockchain transactions. Frameworks are being proposed to support the update of deployed smart contracts through contract proxies [38], but in any case additional complexity is introduced to support code updates, and nevertheless deprecated versions will always be available on-chain. Additionally, developers must consider the transparency of the blockchain, where the contract's code and state are visible to all participants, and even occasional visitors, requiring careful handling of sensitive data [39] (cf. Section 2.3). For example, batch details along a supply chain may not pose security or privacy concerns at the time of deploying a smart contract to support traceability, but may become relevant in the future due to strategic reasons or because ways are found to exploit permanently stored data to challenge the manufacturing company. Note that, even if the contract is destroyed, the original transaction that created it, together with all the associated data, will live forever on-chain.