Blockchain is a distributed ledger that replicates data in a peer-to-peer network of nodes. Transactions are ledger updates digitally signed by the account requiring their execution. The nodes of the network collect broadcasted transactions into a growing cryptographically-linked chain of blocks. A set of consensus rules specifies constraints on the way the blockchain grows, which normally amounts to expected security guarantees for the state of the blockchain: money cannot be spent twice, and, in general, the evolution of the state must be consistent with the semantics of the transactions. Once consensus is achieved, it is hard, or impossible, to withdraw transactions from the blockchain. In this sense, blockchains are immutable data structures.

Smart contracts specify rules and effects of transactions and can be either built-in, as a fixed module of the blockchain software, or given as code dynamically deployed inside the same blockchain. In the second case, users who deploy the code identify themselves by signing a code install transaction request. The typical applications of smart contracts are related to finance and cryptocurrencies, tokens, coordination of purchases, electronic elections, and law. The critical nature of such applications and the fact that smart contracts cannot be replaced after being installed require a high level of code quality. That is, smart contracts are expected to be flawless, as much as possible, and to not harm the network.

Smart contracts can be written in a variety of programming languages, either specific for them or general-purpose. Most such languages are Turing-complete, with the notable exception of Bitcoin's. Not surprisingly, Turing-completeness for smart contracts introduces the risk of many kinds of bugs (Atzei et al., 2017; Popper, 2016). An extensive review for the specific case of Ethereum is in Antonopoulos and Wood (2018) and includes the reentrancy issue, arithmetic under/overflows, incorrect use of low-level calls, weak encapsulation, ineffective randomization, logical bugs in the code of contracts, fund locking, wrong identification of the transaction originator. Such vulnerabilities have actually been exploited in practice. Because of this, there exist many analyzers that verify smart contracts before they get installed in the blockchain (Hejazi and Lashkari, 2025; Kushwaha et al., 2022; Ressi et al., 2024). Furthermore, there are companies that provide code audit services, using both automatic tools and human investigation (Certik, 2025; OpenZeppelin, 2025; Consensys Diligence, 2025). A limit of these tools and procedures is that they are optional and external to the blockchain (hence off-chain): the latter does not actively protect itself against the deployment of incorrect or dangerous code. Moreover, they mostly apply to Solidity rather than to general-purpose languages used for writing smart contracts.

This paper makes the following contributions:

This paper is organized as follows.

Section 2 provides the background of this paper. Section 3 presents related work. Section 4 describes the Takamaka subset of Java for smart contracts and its Hotmoka runtime. Section 5 defines a general architecture for protocol-based code verification. Section 6 describes our implementation of protocol-based verification, over Tendermint and Mokamint, and shows two examples of protocol-based checks. Section 7 reports experiments with our implementation and describes how readers and reviewers can validate them. Section 8 shows how the blockchain can cope with the evolution of code verification rules. Section 9 concludes the paper and discusses limitations.

This paper is an extended version of Olivieri et al. (2021). The main differences with that conference paper are: a more extended related work section; an extended description of Takamaka and Hotmoka; a second example of verification rule implementation; the description of the implementation of the verification module update; the implementation over Mokamint, not just over Tendermint, which gives more relevance to the results; a simplification of the execution of the experiments; a global revision and extension of the article.

Bitcoin (Nakamoto, 2008; Antonopoulos, 2017) was the first popular blockchain implementation. It is a peer-to-peer electronic cash system that stores and transmits value in a currency called bitcoin, by using a Proof of Work (PoW) consensus algorithm: each block contains a proof that some heavy work has been performed to create the block, which makes double-spending attacks expensive. A Turing-incomplete low-level Script language specifies the effects of Bitcoin's transactions. Script can be seen as a limited scripting language for smart contracts.

Ethereum (Buterin, 2013; Antonopoulos and Wood, 2018) later introduced a Turing-complete bytecode for executing actual fully-fledged smart contracts, with the goal of developing decentralized applications. Ethereum smart contracts can be programmed in various high-level languages, with Solidity being the most popular one, but all run on the Ethereum virtual machine. Ethereum used PoW previously to switch to Proof of Stake (PoS). Solidity embeds some features specific to the development of smart contracts, such as a notion of gas, charged for code execution, that allows to meter the amount of code execution and avoids the risk of non-termination; and a strict deterministic execution.

PoS is a consensus algorithm with reduced resource consumption (Sedlmeir et al., 2020). It limits the right to propose a next block to a small set of nodes called validators. This set can be static or dynamic, exclusive or delegatable: in any case, this limitation allows the network to scale better and avoid the computational cost of PoW. Network participants that want to become validators freeze a certain amount of stake, which acts as an economic incentive that dissuades from validating or creating fraudulent transactions. If the validator does its job correctly, it will be remunerated for every confirmed transaction. If, instead, the network detects a fraudulent transaction, the culprit loses part of its stake and possibly the right to act as a validator. The Tendermint protocol (Kwon, 2014) provides a generic and customizable infrastructure for networking and consensus through PoS, with a pseudo-random election of the validator for the next block. This protocol tolerates up to 13 of misbehaving validators. The Tendermint's architecture is shown in Figure 1 and consists of three software layers:

Tendermint is a generic blockchain engine since it is not a monolithic software application for a specific set of blockchain transactions (like Bitcoin or Ethereum and most of all other blockchains), but it leaves the notion of transaction unspecified: programmers can develop an application layer that runs on top of Tendermint (Figure 1) and specifies which transactions exist and which is their semantics. This application layer can be written in any programming language and can even be an actual software layer that executes Turing-complete smart contracts, as it will be in our case, as long as it connects with the blockchain engine through its Application BlockChain Interface (ABCI). The blockchain engine replicates the application state on each machine of the network.

Proof of Stake (PoS) is often criticized for being based on a restricted club of validators that should be trusted because they are rich and, by acting as validators, become even richer. But another problem is that, to start a new network, it is difficult to convince independent entities to run, maintain and update the validators node since the cryptocurrency of a new network has initially no economic value. Therefore, another alternative has been developed, called proof of space (PoSp) (Ateniese et al., 2014; Dziembowski et al., 2015; Abusalah et al., 2017), where miners must dedicate a large amount of disk memory in order to be able to propose a new block. The idea is that the proposal of a new block requires to solve a challenge whose solution can be computed easily in terms of computational power but requires one to allocate a large amount of disk space. Moreover, the quality of the solution determines if the block will be preferred to other blocks proposed concurrently by other miners, and this quality is proportional to the amount of disk memory committed to the task. The energy consumption of PoSp is negligeable, and no special hardware helps for mining; currently, the technology is both cheap and democratic. Moreover, PoSp allows one to capitalize on unused memory, for free, while PoW always has an inherent electricity cost. There are a few implementations of PoSp networks that can execute Turing-complete smart contracts, namely, Chia⁴ and Signum.⁵ Mokamint is a generic engine for running applications over the PoSp protocol of Signum, as formalized in Spoto (2025). Therefore, Mokamint is the equivalent of Tendermint but for PoSp, and its architecture is identical to that of Tendermint (see Figure 1): the only difference is that the Mokamint's consensus layer is based on PoSp. The same ABCI of Mokamint is almost identical to that of Tendermint.

Smart contract verification is challenging and most of the available solutions are for Ethereum-based blockchains, mainly for economic reasons: Ethereum-based blockchains currently lock the highest amount of economic value.⁶ Static analysis techniques can detect issues without executing the code before the contract gets deployed and becomes immutable. Specifically, these techniques examine the syntax, structure, and in some cases also the semantics of the contract at different stages of development. An intuitive example of static analysis is the compiler. For instance, in Ethereum smart contracts, the Solidity compiler (e.g., solc) performs basic checks on syntax and grammar. It issues alerts during the compilation process, ensuring that the source code is well-formed before being translated into EVM bytecode. It applies a static analysis because the checked code is the high-level source code (typically, Solidity), and it is static because the executable code (that is, the EVM bytecode) has not been generated yet. However, since the compiler focuses primarily on code correctness rather than on performing security checks, additional tools are necessary for more comprehensive verification. In the early stages of software development, linters may help maintain coding standards and best practices by identifying code smells, minor bugs, and stylistic inconsistencies. Popular solutions for Ethereum include Ethlint (formerly Solium) (Dua, 2025) and Solhint (Protofire, 2025). Beyond linters, also advanced static analysis tools can be applied for deeper code investigation, to detect complex security vulnerabilities and logic errors. Compared to linters, they offer more detailed and precise results by analyzing the semantics of the instructions, though they may require significant computational resources and extended processing time. Notable examples are Oyente (Loi et al., 2016), SmartCheck (Tikhomirov et al., 2018), Slither (Feist et al., 2019), eThor (Schneidewind et al., 2020), Echidna (Grieco et al., 2020), EtherSolve (Pasqua et al., 2023), and EVMLiSA (Arceri et al., 2024). Advanced tools are also delivered as a service, such as https://mythx.io. Furthermore, there are companies that provide code audit services by using both automatic tools and human investigation. However, a limit of these off-chain tools and procedures is that they are optional: users are not required to analyze their code before it gets deployed in the blockchain.

To the best of our knowledge, this paper defines and implements the first protocol-based code verification for smart contracts that allows the same blockchain to reject the code that does not pass a set of verification rules. From this point of view, the technique is related to continuous integration, that builds and deploys code only if it passes all compilation and testing requirements. The main difference is that smart contracts cannot be replaced or debugged once installed in blockchain.

Some blockchains, such as Ethereum, apply a notion of transparency (Oliva et al., 2020), that lets one store in blockchain the source code of the smart contracts to guarantee that it actually compiles into their bytecode. But this is only an optional technique that ensures that bytecode and source code match and no code verification is applied.

The specific technique for updating the consensus rules of a network, after a change in the verification rules (Section 8), is orthogonal to our work. In Cosmos, the government module supports such an update, with (dis-)incentives to minimize misconduct within the participants. Polkadot delegates updates to periodic referendums among stakeholders. Algorand (Chen and Micali, 2019) triggers an update if a large majority of block proposers declare to be ready for that.

This section introduces the Takamaka smart contract language and its Hotmoka runtime. The goal of this section is to provide knowledge about the specific language that we analyze, with examples that clarify the difference with Solidity (use of a general-purpose language, use of generic types, access to the keys of a map, checked casts). These examples show correct uses of Takamaka, so that subsequent static analyses become clear. Moreover, the voting example in this section is also used to coordinate the update of the verification module (Section 8).

Solidity is probably the most used programming language for smart contracts. Despite its success, it has limits that make its use complex and error-prone. The first problem is that it lacks support for runtime type introspection and dynamic dispatch: types used in the code can be violated at runtime since casts cannot be checked. Objects cannot even be checked at runtime for their actual type (no instanceof operator exists in Solidity). Lack of runtime type checks and certain safety features have contributed to bugs and vulnerabilities in many Solidity smart contracts (Antonopoulos and Wood, 2018). Moreover, Solidity does not feature modern programming patterns such as generic types. Smart contracts use maps extensively but, in Solidity, these are not real data structures and miss basic functionalities, such as the ability to iterate over their set of keys and values.

On the contrary, modern programming languages such as Java provide strong types, generic types and complex data structures (including actual and flexible maps). However, they miss some features that are specific to smart contracts: Java does not allow one to access the caller of a method, nor to sign method calls; Java does not natively include a gas mechanism to limit resource consumption, a feature that smart contract platforms typically use to enforce predictable execution and prevent infinite loops. Finally, Java is not deterministic, which is a problem in blockchain, whose consensus requires to reach the same state in all nodes of the network, impossible in the case of non-determinism.

For this reason, Java (and other general-purpose languages) has been used for writing blockchain code, statically installed in the blockchain at deployment time or only in the context of permissioned blockchains. But a free dynamic deployment model in a permissionless blockchain, in the style of Solidity, has never been possible with Java and other general-purpose languages, since they allow many dangerous executions in blockchain and contain a large library that allows programmers to perform actions that, in blockchain, are both meaningless and dangerous, such as file access, reflection and non-deterministic object finalization.

The goal of the Takamaka project was exactly to enable the use of Java as a smart contract language, analogous to how Solidity is used in Ethereum. The use of a well-known programming language such as Java leverages expertise and existing mature development tools. The application layer of Takamaka is a state machine (the application in Figure 2) that executes transactions from request to response. Requests can specify the addition of a jar in the permanent state of the application, or the execution of a constructor, or of an instance or static method of code previously installed in the state. Responses include the effects of the transaction as a set of field updates. Updates can be computed since the jar of the Java code is instrumented before being installed in the blockchain, with extra code that keeps track of the affected fields of objects (Spoto, 2019). Determinism is ensured by a static analysis that ensures that only a deterministic subset of Java is used, restricted to a minimal deterministic and non-dangerous API of the Java library. The state machine (runtime) of Takamaka is called Hotmoka⁷ and is implemented itself in Java. It runs on a standard Java virtual machine. The state is kept in a Merkle-Patricia trie that implements a map from the hash of requests to their corresponding response. This trie is kept in the Xodus transactional database by JetBrains.⁸

An important difference between Takamaka and Solidity is that smart contracts are deployed in Solidity, together with their compiled code: every deployed instance of the contract carries its own copy of the code. In Takamaka, instead, the standard Java approach is used: the code of the smart contract is installed in the database of the blockchain, once and for all; later, smart contracts are instantiated from that single code instance by calling their respective constructors. Because of this, this paper refers to the installation of the code of a smart contract and to the subsequent instantiation of specific smart contract instances, rather than to the deployment of a smart contract, which is the usual terminology in Solidity. This difference is important for the scalability of our technique, as Section 7 will show later.

Another significant difference is that externally-owned accounts are just a special case of smart contracts in Takamaka, while they are different concepts in Solidity. Namely, in Takamaka, an externally-owned account is a smart contract that embeds a public key and that has the right to originate a transaction, as long as that transaction is signed with the matching private key. Externally-owned accounts, in Takamaka, have an actual type (a class), that extends Contract and can be redefined and specialized.⁹ It follows that externally-owned accounts are objects in Takamaka (in the sense of object-oriented programming) and that two distinct objects might even contain the same public key and therefore be controllable with the same, corresponding private key. It is even possible to rotate the key of an externally-owned account, and still keep the identity of that object. None of this is possible in Solidity. As in Solidity, also in Takamaka both smart contracts and externally-owned accounts have a balance.

In Takamaka, bytecode instrumentation is also used to add features that are needed for smart contracts but that are not available in standard Java: for instance, in Takamaka the caller of a method can be identified as caller(); cryptocurrency can be used to pay for code execution; the latter is metered through gas and stops if gas expires. Instrumentation is run by each node when smart contracts get installed (Spoto, 2019); the correct use of caller() and payments are enforced by a set of static analyses (see Section 6). All such analyses are implemented at the protocol level, as mandatory steps for the installation of new smart contracts and could be improved/expanded in the future, as this paper will show. A specific Takamaka library includes typical data structures used in smart contracts, such as very flexible maps. Takamaka has been proven to be able to implement non-trivial smart contracts for tokens and data snapshots (Crosara et al., 2023) and to support smart contracts with generic types (Spoto et al., 2023).

Let us see an example of a Takamaka smart contract for the implementation of a poll. Its interface is given in Figure 2. It is a generic interface parametric w.r.t. the type Voter of the voters allowed to vote. A poll is similar to the vote of the shareholders of a company. Each of them has a power, that is, a maximal number of votes that it can cast. This information is returned by method getEligibleVoters(). Note that this method returns a map from each eligible voter to its power. Maps are real data structures in Takamaka. Therefore, clients can find the keys and the values of a map and iterate over them. Shareholders vote by calling one of the vote() methods: they cannot vote twice, or otherwise, these methods will throw an exception. The votes cast up to now are returned by getVotersUpToNow(). Method isOver() checks if the poll is over (that is, if a majority of the votes have been cast or all voters have voted). Method close() closes the poll if it is over and runs an action if a majority has been reached. This method cannot be called twice.

Figure 2 shows the use of specific Takamaka annotations: these are a Java mechanism for adding metadata information to source and compiled code. They are irrelevant for the code executor but can be used by code analysis and instrumentation tools. Namely, @FromContract states that a method or constructor can only be called from the code of a contract, which, as said before, in Takamaka includes externally-owned accounts as well. Such annotation allows the programmer to refer to the caller of the method as caller(). This is important, for instance, for the vote() methods, which need to be sure of the actual intent of the caller to cast its vote. This explains why the generic type Voter is bound to be a Contract: Voter extends Contract. If a method or constructor is annotated as @FromContract, then it can be additionally annotated with @Payable, which states that the caller can send cryptocurrency when calling the method or constructor. The fact that @Payable only works together with @FromContract is to guarantee that the caller is a contract and, therefore, that it has a balance to pay with. Moreover, @Payable only works in contracts, to guarantee that the callee has a balance and can receive cryptocurrency.

The annotation @View states that a method has no side-effect and, consequently, can be run without modifying the state of the blockchain. This allows to call @View methods without paying for their execution since they do not give rise to transactions stored in blockchain but simply read its persistent state.

A possible concrete implementation of a poll is given in Figure 3. It is a class that implements the Poll interface and extends Storage. The latter is a class of Takamaka's runtime whose instances can be created, kept and shared in blockchain: without extends Storage, instances of class Poll could only be used as temporary objects in methods. A Contract is a Storage with a balance. SimplePoll is not a Contract since it does not need a balance, and indeed none of its methods receive cryptocurrency at call-time (none is @Payable).

The constructor of SimplePoll receives a map that states who the voters are and how many votes each of them can cast. This is not necessarily a modifiable map but just a map view: it is possible to read its mappings but not necessarily to modify them. The constructor iterates on the voters to compute the sum of all votes that can be cast. As said before, this iteration would be impossible in Solidity. The addition of two Java's BigIntegers is not performed through their add() method, which would be rejected by the static verifier of Takamaka's code since its complexity is not constant; hence, its gas consumption is not constant either. Instead, the support class BigIntegerSupport is used, which charges a variable amount of gas, depending on the size of the BigIntegers. The constructor terminates by computing an immutable snapshot of the (currently empty) map of votes cast that will be returned to clients by the getVotersUpToNow() method. The constructor receives a second argument action, that implements the local class Action and that it stores in the poll. This action will be used later, to run its run() method if the poll reaches its goal.

The vote() methods modify the votersUpToNow map. Since these are @FromContract methods, they are allowed to refer to the caller() contract, the one that signed the transaction for calling the method. Method vote() delegates to vote(BigInteger votes) by passing the total amount of votes that the caller can cast. The latter method checks if the caller is allowed to cast votes votes. That is, if the caller is actually a potential voter, if it did not already vote, if votes is non-negative and if votes is not larger than the maximal amount of votes that the caller can cast (see the auxiliary method checkIfCanVote()). Note the use of containsKey() inside it, which would be impossible in Solidity. Moreover, note that vote() recreates the snapshotOfVotersUpToNow, since the votes have changed.

Method close() checks if the poll has been closed already. Otherwise, it checks if the poll is over (a majority has been reached or all voters have cast their vote). If a majority has been reached (goalReached()) the action gets run, that was provided to the constructor of the poll.

Hotmoka is the runtime that instruments the bytecode of Takamaka smart contracts, interprets their annotations and runs their constructors and methods inside database transactions. Instrumentation is needed since annotations such as @FromContract and the access to the caller() are not available in Java, hence they must be provided by code instrumentation. A full description of Hotmoka is beyond the scope of this paper, therefore no more details are provided here. The interested reader can find more information in Spoto (2019). Here, we just say that the state of all smart contracts installed in blockchain, and their bytecode, is stored inside a persistent database. The bytecode instrumentation allows Hotmoka to infer the set of fields of objects modified by a transaction. This set is stored in the database, as the result of a transaction. The database implements a Merkle-Patricia trie, exactly as in Ethereum. Therefore, it is possible to revert to previous states. This is important if Hotmoka runs on top of a consensus engine that requires history changes, such as Mokamint.

This section presents protocol-based code verification in the context of a generic blockchain engine, such as Tendermint or Mokamint. This allows one to understand where it runs and which software architecture can be used to support its execution.

Figure 4 shows a more detailed picture of a generic blockchain engine and of an application connected through its application layer interface, such as ABCI. It shows that the engine keeps the blocks of the blockchain in its own database, that does not need to be the same used to hold the application's state. The latter holds, for instance, the code of the smart contracts installed in blockchain and the value of their state variables. The engine needs only the hash of the application state, for consensus, to ensure that all nodes have reached the same application state.

One can define the application state as a map σ from the hash of the requests that the blockchain has executed to the responses that have been computed for them. Therefore, the responses are contained in the application state; instead, the requests are not contained in the application state: only their hash is used and mapped into the corresponding response. Since the state is a map, it can be implemented as a Merkle-Patricia trie from hashes of requests to responses. The full requests are contained in the database of blocks of the engine since they are needed to replay the transactions in all nodes of the network.

Protocol-based code verification requires a code verification module (Figure 1). This is part of the application layer since it contributes to the execution of the application-specific requests to install code (for instance, smart contracts) in blockchain. Assume that a request, whose hash is request_h, reaches the blockchain, requiring to install, in blockchain, the code of some smart contracts, reported inside request.

Figure 5 shows the sequence diagram for the execution of request. Namely, the generic blockchain engine routes request through networking and consensus up to the application, which uses its verification module to either approve or reject the code. If approved, the application packs the installed code in a response and updates its state σ with a new binding: σ(request_h) = response. The hash request_h is an immutable, machine-independent reference to this code, used later to instantiate and execute smart contracts. If the code is rejected, instead, the application state is expanded with a failure response; this kind of response does not contain any installed code since failure prevented the installation of any code in blockchain.

Figure 6 reports an example of application state evolution. It reports the requests in full for readability, but we stress that only the hash of the requests is kept in the application state. Figure 6a shows the application state after the execution of a code installation request for which verification succeeds. In this example, the code is Java bytecode because it is the target of the compilation of Takamaka, packaged into a jar, i.e., a zipped container of Java bytecode. The response contains the instrumented jar. In terms of Java, the hash of the request can be used as the classpath of subsequent code executions. Figure 6b reports, instead, a request whose code fails to verify. The response does not include any instrumented code to install in the blockchain. This shows that the verification rules are part of the consensus rules that determine which code installation request is valid and which must be rejected instead (Figures 6a, b). Hence, they must be the same in every node of the network and must be deterministic.

Protocol-based verification performs code verification statically, only once, when the code is installed in the blockchain. For instance, Figure 6c shows a subsequent request that asks to instantiate a smart contract whose code has been installed by the request in Figure 6a. The request in Figure 6c uses the hash of the request in Figure 6a as its classpath and contains the parameters for calling the constructor of the smart contract. The execution of the request runs that constructor without code verification: the latter has already been performed in Figure 6a. The immutable reference hash of request#0 is used later to refer to the new smart contract: the index #0 is used in the implementation of Takamaka to refer to the first object created during the execution of a request. In general, a request can instantiate many objects, depending on the code that it executes (for simplicity, this example assumes that only one has been instantiated). The state of the new smart contract is reported in the response as a set of updates, that is, instance fields modified during the execution of the request, including those of the smart contract instance hash of request#0 that has been created in blockchain. Finally, Figure 6d shows the execution of a request asking to call a method on the instance of the smart contract hash of request#0. This last request refers to both the classpath and the target instance smart contract. Its execution, in general, modifies some instance fields of some objects in the blockchain that are reported as updates in its response. This last request does not verify the code either since it is not a code installation request.

The fact that code verification is run only once, at code installation time, is important for efficiency since the installation of new code in the blockchain is a relatively rare event in comparison to the instantiation of new smart contracts and the execution of their methods. This is particularly the case for Hotmoka, where the code of a smart contract is installed once and then recycled for all instances of the smart contract that get subsequently created. This is different from Ethereum, where each instance of the smart contract reinstalls the code, although it is identical to that of the other instances. Therefore, Hotmoka installs (and verifies) the code of a smart contract only once, independently from how many instances of that smart contract will be created later. This is at the basis of the efficiency results that will be described in Section 7.

The rules of protocol-based verification are part of the consensus rules of the blockchain, since they determine if the response of a request to install code in blockchain is successful or fails. Therefore, they determine the evolution of the state of the application layer and its hash, which is reported in the blocks of the underlying blockchain engine and used for consensus. This means that all nodes must use the same verification rules, or otherwise, the network nodes will never agree on a common state: nodes that use different rules will automatically exclude each other.

We have implemented protocol-based verification inside the Hotmoka runtime for executing smart contracts written in the Takamaka subset of Java. Hotmoka is an application with an interface to the ABCI. Hence, it can therefore run on top of both Tendermint and Mokamint (Figure 4). Hence, our protocol-based verification is currently available for both PoS and PoSp blockchains.

The verification module is implemented as a sequence of checks performed on methods and classes. Since a request to install new code in blockchain contains the compiled bytecode only, such checks run at Java bytecode level, by using the BCEL library for Java bytecode manipulation.¹⁰ The source code is simply not available in blockchain. Currently, Takamaka's protocol-based verification performs 21 checks on every jar that gets installed in blockchain. They must all pass, or otherwise the jar will be rejected. Figure 7 describes some of them.

The checks in Figure 7 filter out smart contracts whose installation would compromize the security and the functionality of the blockchain. As already discussed in the introduction, they are specific of a general-purpose language that must be used for writing smart contracts. For instance, the correct type for the storage fields is already enforced by the compiler of Solidity, while a specific check is needed for Java, that was not devised for smart contracts, originally. Determinism comes out-of-the-box in Solidity, that was designed for being deterministic, while that is not true in general-purpose languages. The rule that enforces a white-listed API is needed in Java also to avoid library calls to the file system, for instance, that are not useful for smart contracts and dangerous in blockchain, while Solidity has almost no library support and the little that exists is meant for smart contracts. Note that this same rule forbids calls to Java reflection, that is, to low-level calls that might bypass most security checks, and correspond to the dangerous delegatecall() of Solidity.

The rest of this section shows, in detail, the implementation of the last two checks from Figure 7.

This section reports experiments with protocol-based verification. The goal is twofold:

The evaluation metric, in the second case, is the extra time required for the protocol-based verification, in comparison with the same blockchain without protocol-based verification. This will of course depend on the complexity of the analyses that one wants to perform. Therefore, the context of this paper are the 21 analyses for Takamaka, in part reported in Figure 7.

This section shows how to deal with updates to the verification module of a blockchain that applies protocol-based code verification. There are many reasons for an update: the verification module might need to be updated in order to include new verification rules or to improve the precision of the already existing rules or even to patch some bugs in the module itself. When a new version is deployed, it becomes necessary to update all nodes to that version (or at least all validators), or otherwise consensus might be lost. A change in the verification rules, if deployed on a subset of the network only, entails that the updated nodes might accept a request that the non-updated nodes might reject instead, or vice versa. Moreover, there must be a way to coordinate the moment when the update must be considered activated.

To the best of our knowledge, this paper presents the first protocol-based verification of blockchain code. The technique is fully implemented inside the Hotmoka runtime for executing smart contracts written in the Takamaka subset of Java. Experiments show that the addition of a code verification layer to the nodes of a blockchain network does not affect its efficiency (Section 7). However, this is true also because the static analyses performed by the verification module of Hotmoka are still quite simple and largely related to checking the correct use of the annotations and primitives of the Takamaka language (Figure 7). The cost of verification might explode, instead, if more complicated static analyses would be considered in the future, such as those already existing for Java.

In comparison with off-chain static analysis, the following considerations are relevant:

Such considerations imply that protocol-based and off-chain static analyses could actually coexist since they address different goals: the former checks the correct use of the language primitives that, if violated, would introduce security holes in the blockchain network itself; while the latter verifies more complicated, global properties of the code, that would not introduce security risks to the network but might be of paramount importance to the programmer. That is, protocol-based verification must be understood as a mandatory, defensive verification technique for the blockchain, rather than as a replacement of the off-chain verification that is useful for the programmer.

The issue of reverification of legacy code after an update of the verification module has not been studied much up to now. In Section 8.2, it is said that it should trigger the re-verification of code already in blockchain. But this might not be the best choice, since it might disable some smart contracts already in blockchain and lock their funds for ever. Moreover, a large number of users could oppose a change of the verification rules that affects some highly popular contracts. Future work will investigate linguistic primitives and programming patterns that allow funds to be unlocked or specify that some contract should not be re-verified after an update of the verification module.

Protocol-based verification has been developed to support the safe use of general-purpose languages in a permissionless blockchain. As such, its applicability is much larger than the case of Java, and spans all general-purpose languages used so far for writing smart contracts (Golang, Python, and Rust, for instance). Its application to Solidity remains limited, since Solidity was meant for writing smart contracts, from its very inception, therefore most of our checks are already performed by the Solidity compiler. Nevertheless, it is possible, in principle, to modify the Ethereum Virtual Machine and trigger code verification of every Solidity smart contract deployed in Ethereum. This would be perfectly possible for simple checks (for instance, for the use of msg.sender instead of tx.origin or for unexpected and non-standard uses of delegatecall()) while we remain skeptical about protocol-based verification of more complicated security issues, such as overflows, underflows and reentrancy, whose computational cost is quite higher. For reentrancy, a more syntactical approach, such as making the default payment method final, as done in Takamaka, catches most attacks in a much simpler way than a static analysis.