Implementation and evaluation of smart contracts using a hybrid on- and off-blockchain architecture

1.1 Research problem

Despite the undoubted potential for the implementation of smart contracts on blockchain technologies such as, Bitcoin,¹ Ethereum,² and Hyperledger,³ blockchain based solutions are plagued with questions about their scalability, performance, transaction costs, and other questions that emerge from their decentralized nature. For example, Bitcoin can only process seven transactions per second—a poor throughput compared to visa's 2000 transactions per second.⁴ Also, it takes Bitcoin about 10 minutes to publish a transaction to a block.⁵

Long before Satoshi's seminal paper⁶ that launched Bitcoin, alternative solutions to the execution of smart contracts based on centralized architectures were being proposed.^7-12 However, a noticeable problem with implementing smart contracts using these platforms is that because of their centralized nature, they suffered from limitations such as trust being placed on trusted third parties (TTP), and the centralized server being a single point of failure. The central argument of this article is that in several applications, hybrid platforms composed from the integration of on and off blockchain platforms are more adequate.^{13, 14} Unfortunately, the use of hybrid architectures in smart contract implementations is largely unexplored.

1.2 Research contributions

The remainder of this article is organized as follows: In Section 2, we present the example of an asset tracking service as a motivating scenario. In Section 3, important background concepts are discussed, and we provide an overview of work that is related to this research. The architecture of the system is presented in Section 4, and implementation details are discussed in Section 5. The performance analysis is presented in Section 6 and evaluated in Section 7. Finally, we finish with conclusions and future work directions in Section 8.

3.1 Smart contracts: Background

A smart contract is an event-condition-action stateful computer program, executed between two or more parties that are reluctant to trust each other unguardedly. It can be regarded as an FSM that keeps a state that models the development (from initiation to completion) of a shared activity. For instance, in References 15, and 18-20, the state is used for modeling changes in rights, obligations, and prohibitions as they are fulfilled or violated by the parties.

Research on executable contracts can be traced back to the mid 80s and early 90s.^{7, 8} In 1997, Szabo used the term smart contract²¹ to refer to contracts that can be converted into computer code and executed. However, commercial interest in smart contracts emerged only in 2008 motivated by the publication of Satoshi's Bitcoin paper⁶ that inspired the development of cryptocurrencies, smart contracts, and other distributed applications. Satoshi departed from the centralized approach taken in previous research and demonstrated how smart contracts can be decentralized.

Depending on the number of instances (copies) of the smart contract deployed to monitor and enforce the contract, we distinguish between centralized and decentralized (distributed) approaches (Figure 3). In the figure, A and B are business partners, for example, Alice and Bob of our contract example of Section 2. SC is the corresponding smart contract. op stands for operation executed against SC, and rp is the corresponding response. TTP node is a node under the control of a TTP. N₁,…,N₄ are untrusted nodes. CP stands for Consensus Protocol. As shown in Figure 3A), a contract can be implemented as a centralized application that uses a single instance of the smart contract (SC) running in the TTP node. Besides the disadvantages that a TTP introduces (single point of failure, trust placed on the TTP, etc.), this approach is comparatively simpler that the decentralized approach. The decentralized approach relies on a set of untrusted nodes instead of a single TTP that are used for running several identical instances (shown as SC₁,…,SC₄) of the smart contract. In this approach, A and B are free to place their operation against any of the instances. The price that the decentralized approach pays for getting rid of the TTP is that the untrusted nodes must run a consensus protocol to verify that a given operation has been executed correctly, and to keep the states of SC₁,…,SC₄ identical. Depending on the protocol used, its computational, communication, and performance degradation cost might be unbearable²² or its consistency guarantees inadequate²³ to the extent of rendering the decentralized approach unsuitable.

3.2 Related work

Research work on the monitoring and enforcement of interactions between parties using smart contracts was pioneered by Minsky⁷ in the mid-1980s with work on law governed interaction (LGI). LGI is a law enforcer that regulates the interaction between autonomous and distributed agents linked by a communication network. This was followed by Marshall in the 1990s.⁸ Although some of the tools developed exhibited some decentralized features,²⁴ those systems took mainly a centralized approach. Within this category falls References 11 and 25. To the same category belongs the contract enforcer suggested by IBM,¹² and the Heimdhal engine²⁶ aimed at monitoring state obligations (for example, the service provider is obliged to deliver an asset within x business days). Directly related to our work is the contract compliant checker reported in References 15 and 20, which also took a centralized approach to gain in simplicity at the expense of suffering from all the drawbacks that TTPs inevitably introduce.

The publication of the Bitcoin paper⁶ in 2008 motivated the development of several platforms for supporting the implementation of decentralized smart contracts. Platforms in References^1-3 are some of the most representative. A good summary of the features offered by these and other platforms can be found in Reference 27. Although they differ on language expression power, fees, and other features, they are convenient for implementing decentralized smart contracts.

An early example of a permissioned distributed ledger that is similar in functionality to the hyperledger blockchain³ is the “Business to Business Objects” platform (B2Bobjects).²⁸ B2Bobjects is a component based middleware implemented at Newcastle University in the early 2000s and used for the enforcement of decentralized contracts.¹⁹ B2BObjects offers consensus services (based on voting initiated by a proposer of a state change) and storage for recording non-repudiable and indelible records of the operations executed by the contracting parties. B2Bobjects is permissioned (as opposed to public) in the sense that only authenticated parties are granted access to the object. Work at Newcastle University also looked at techniques for verification (model checking) of executable contracts²⁹ deployed using B2BObjects.

The hybrid approach that we suggest and evaluate in this article addresses problems that neither the centralized or decentralized approaches can address separately. The original idea for hybrid contract implementation emerged with the off blockchain payment channel discussed in References 1 and 30. The concept of logic-based smart contracts discussed in Reference 31 has some similarities with our hybrid approach. They suggest the use of logic-based languages in the implementation of smart contracts capable of performing on blockchain and off-blockchain inference. The difficulty with this approach is that current blockchain technologies lacks support for logic-based languages. In our work, we rely on the native languages offered by the blockchain platforms, for example, Ethereum's Solidity. On- and off-blockchain enforcement of contractual operations is also discussed in Reference 32; though an architecture is presented, no technical details about its implementation or functionality are discussed. Another conceptual design directly related to our work is private contracts executed in the Enigma¹⁷ architecture. Like in our work, a private contract is a conventional business contract with contractual operations separated into on- and off-blockchain categories. Similar to our hybrid design, they use a blockchain platform (Ethereum) to execute on blockchain operations. However, unlike in our work, instead of using a TTP to execute off-blockchain operations, they use a set of distrusting Enigma nodes running a Secure Multi-party Computation (SPC) protocol^{33, 34} that guarantees privacy. In this collaborative architecture, the blockchain is in charge. It is responsible for guaranteeing that the contractual operations are honored and for delegating tasks to the Enigma nodes as needed. The integration of the SPC protocol ensures that the smart contract running in the Ethereum blockchain never accesses raw data that might compromise privacy. Unlike our TTP, the Enigma nodes charge computation and storage fees, just like Ethereum and Bitcoin do. The cost that the Enigma architecture pays for privacy protection is complexity. Similar to our work also is Ekiden, a system for combining blockchains with Trusted Execution Environments (TEEs).³⁵ The authors report significant performance improvements; however, they do not discuss the challenges of testing and verification hybrid smart contracts as we do in,^{13, 14} where we also discuss the advantages and disadvantages of each of the on-blockchain, off-blockchain, and hybrid approaches. Another technique suggested for addressing the scalability problems of blockchains is sharding. This approach involves alteration of the blockchain architecture. The central idea of sharding is parallelization with subsequent cross-shard consensus: several transactions are executed in parallel by different independent groups of nodes (called shards) selected from the group of conventional miners (see for example³⁶). To avoid the risk of consuming inconsistent data, one can replace consensus algorithms that offer only eventual consistency like the proof of work (PoW) algorithms with algorithms that offer stronger consistency.³⁷ An example of such algorithms is classical Byzantine fault-tolerant (BFT).³⁸

In Reference 39, the authors present an improvement to the architecture of the Hyperledger Fabric designed to improve the throughput of the blockchain. The method by which the number of transactions per second was increased involved altering some of the operations on the blockchain by manipulating data and memory and implementing concurrent operations. The proposed changes to the blockchain would require altering the entire Hyperledger platform and would only be applicable to applications based upon the Hyperledger blockchain. However, this work shows that there is potential for significant increases in performance, and particularly increasing the throughput of Hyperledger by nearly 600% with indications that the throughput could be further increased to 50 000 transactions per second which would rival VISA. In addition to the potential benefits to Hyperledger, hopefully lessons learnt from this work can be applicable to other blockchains solutions and hybrid solutions such as ours. The advantage of our work is that it aims to provide a solution to the scalability issues regardless of what blockchain is being used.

The idea of applying blockchain technologies to asset tracking is discussed in Reference 40, whereby an asset has a starting point and a destination, with multiple intermediary locations. The design of the system is also aimed toward following the conventional delivery model of signing for the delivery of an asset, meaning that the sender and recipient both agree when the asset has been delivered and leaves the possibility of completely automating the system.

One of the current solutions to this problem is designed by IBM.⁴¹ The system uses RFID tags and barcodes to keep track of the location of a given asset and each person in the supply chain publishes their information to a shared ledger. The system is designed using Hyperledger and is designed more to keep track of business assets and to be used in an industrial scenario rather than a retail setting. One of the limitations with the system is that it only handles the part of the contract concerned with the delivery of the asset. This means the system does handle other events such as placing of payment, and therefore cannot ensure the entire series of events involved in the delivery process are contract compliant.

4.1 The contract compliance checker

We also consider that the execution of a given sequence of operations is NCC if it includes one or more operations that are flagged by the CCC as NCC. A sequence of operations is also known as an execution sequence or execution trace and drives the choreography of interaction from its initial state to a final state.

4.1.1 Architecture of the CCC

A high level view of the CCC is shown in Figure 5. It consists of two layers: The CCC Engine (The Logical Layer), and the CCC Service (The Presentation Layer). The CCC Engine is responsible for processing business events and for determining whether they are contract compliant or not. The CCC Service is an interface to the CCC Engine, it is used for delivering business events to the CCC, and for collecting the corresponding responses. In addition, the CCC Service can be used for loading and editing the clauses of the smart contract. The functionality of the architecture is as follows: A business event is received through the monitoring channel as an XML document that includes the names of the participants, the business operation, and its outcome from the set: (Success, BizFail, TecFail):

Listing 1..

The XML document representing the business event is passed to the BEvent queue. Business events are retrieved and converted using the xml2Obj/Obj2xml Convertor from their XML format into business event objects. Events are then passed to the Logical Layer. The filter discards mismatched business events that are not among the permitted events defined within the ROP set. Business events that pass this filter are inserted into the Event queue. All deadlines are set and reset by the relevance engine and enforced by the timer. Timeout events are added to the filter as required by the contract and are examined by the filter to decide if events are mismatched. For example, receiving a Confirm event from the Sender after the deadline has elapsed will be treated as mismatched. The relevance engine removes a business event from the head of the event queue and compares it to the rules stored in the Smart Contract. Rules that match the event under examination are triggered to determine if their conditions are satisfied. The actions of the rules whose conditions are satisfied are executed, and this may alter (add/del) the current state of the ROP set. For our example in Figure 2, a rule triggered by a Confirm business event and finds its conditions satisfied will delete (disable) the Sender's right to execute another Confirm business operation, and delete the Sender's right to execute a Reject operation. The rule also will add (impose) an obligation on the Recipient to either initiate the execution of Pay, or initiate the execution of Cancel. The event is then stored in the Event logger as a record for any future dispute resolution. The relevance engine eventually declares the business event either CC or NCC and produces a response as a business object, which is sent out to the Presentation Layer. The business object passes through the xml2Obj/Obj2xml Converter, where it is serialized into an XML message of the following format:

Listing 2..

The xml2Obj/Obj2xml Converter inserts the response into the outcome queue, which can be accessed by the contracted parties. The Presentation Layer allows a “rule manager” to update the contract rules at run time. For this purpose, rules can be edited using the Smart Contract editor (in a browser) and sent to the upload smart contract service as a conventional RESTful POST operation. The  upload smart contract service is responsible for producing a drl (Drools) file (for example new–rules.drl) from the payload of the POST operation, and for uploading it to the CCC Logical Layer to replace the Smart Contract.

The CCC Logical Layer is implemented using JBoss's Drools rules Engine. Drools is a declarative Turing complete language designed for writing business rules.⁴⁴ The Drools rules engine powers the decision making capabilities of the relevance engine. The relevance engine acts as a wrapper for the Drools rule engine and its responsibilities include the initialization of the contract, as well as the addition and processing of events received from the Presentation Layer. The Presentation layer exposes the CCC as a RESTful web service. Its aim is to enable the exchange of XML event messages between the CCC and the contracted clients, and to ease the editing and update of the contract rules. The Presentation Layer is implemented using the JBoss Enterprise Application Platform (EAP). The Event queue and the outcome queue are implemented using JBoss's HornetQ (a message oriented middleware layer), and using the Java Message Service (JMS) API. A Message-Driven Bean (MDB) receives business events from HornetQ and passes them to the XML2Obj/Obj2XML converter, which is implemented using Java.

4.2 Ethereum

We chose the Ethereum platform² for implementing the decentralized smart contract service for the following reasons: It is currently one of the most mature blockchains. It supports solidity—a turing–complete language⁴⁵ that designers can use for encoding stateful smart contracts of arbitrary complexity. Equally importantly, Ethereum provides, in addition to the main Ethereum network (Mainnet), four experimental networks (Ropsten, Kovan, Sokol, and Rinkeby) that developers can use for experimenting with their ideas using Ethereum tokens instead of real ether money. A summary of technologies used is as follows. Solidity is the main programming language used to create Ethereum smart contracts. Remix IDE is an online IDE for development of Solidity smart contracts. It can identify any semantic errors in code as well as offering warnings when functions can potentially run over the gas limit of the contract. Node Package Manager (NPM) is an open-source collection of JavaScript packages. It is used connect the website to the Solidity code on the blockchain. MetaMask is a browser extension for Google Chrome, which connects the browser to the Ethereum network. Truffle is a development framework used to interact with the Ethereum blockchain. Ganache is a personal blockchain. It is used for testing contracts in combination with Truffle and MetaMask. JBoss: middleware designed to aid in hosting applications.

4.3 Deployment of the hybrid smart contract

The technology used in the integration of the CCC with the Ethereum Blockchain is shown in Figure 6. The contract is split into two parts: (i) the smart contract SC_c deployed on the a TTP (CCC), encoded in drools, and deployed on a Mac computer (regarded as a TTP node). On the Mac, we also deploy an Ethereum client connected to the rinkeby Ethereum network. (ii) The blockchain based smart contract SC_d, encoded in the Solidity language.⁴⁵ SC_d receives string messages from the SC_c and replies with another string message.

The client acts as a web client to the CCC. We use it to test the implementation of the contract example implemented by the combination of SC_c and SC_d. We provide the client with all the execution sequences required to measure the performance of the hybrid architecture. We generate all the execution sequences in advance and store them in a folder with N sub-folders: each sub-folder corresponds to one execution sequence and contains as many files as messages are included in each execution sequence. As shown in Figure 6, the CCC relies on the web3j library to communicate with the Ethereum client. Among other services, the web3j library includes a command line application that mechanically generates wrapper code from a smart contract specified using solidity and compiled using the solc compiler. The CCC (a Java application) can use the generated wrapper code to communicate with the SC_d contract, through the json-rpc API provided by Ethereum. In addition, the web3j library provides an API for the CCC to unlock an Ethereum client account by providing the path to the key-store file and the password.

5.1 On-chain implementation

The initial step of implementing the on-chain section of the asset tracking project was to provide the data structures necessary for representing an asset and a location. A location requires a unique identifier. To make the system easier to understand and use, a string representation was applied to represent a name which is the unique identifier. A location also contains a unique integer identifier used to check if the identity of two locations is the same. This is because Solidity does not have a string comparison method, meaning to compare if two strings are the same, the strings need to be hashed and then have the hashed values compared, which is computationally expensive and increases the gas cost of some of the methods, whereas comparing two integers is a cheaper operation with regards to gas cost. While it is more expensive to store the data initially, if the proposed solution was implemented on a widespread use, the more important factor would be the average cost of executing methods, meaning integer comparison would be preferred to string comparison. A location also required an address field to represent the owner of a specified location to allow the contract to compare the owner of a location with the owner of an asset or the address initiating any of the methods in the contract. A Boolean was also used to check that the name of the location is unique when it is created and used when adding assets to the map of all assets in the system.

An asset required a unique identifier which was also represented as a string for ease of use, and similarly to the location data structure also had a unique integer identifier for comparison within the contract for the same reasons described above. An asset also required an address variable which is the address of the user who currently is in possession of the asset. To represent what stage in the delivery process each unique asset is currently in, an integer was used with the numbers 0 to 6 representing the different stages as indicated in Figure 8. The rights, obligations, and prohibitions described are generated from the contract design in Figure 2.

An integer variable is stored in the asset class which is used to keep count of the length of the route between the starting and ending locations when adding new locations to the route. There is also a Boolean check variable in the Asset class to ensure that the string identifier is unique. In order to track the delivery time of each stage of delivery, a mapping of integers to integers is used. The integer keys in the mapping are equal to the integer keys in the mapping for previous locations. A location is stored in the asset structure as the destination of the delivery. This is so that the contract can check when the asset has reached the end of its route. Each of the assets and locations must be stored on the blockchain. This was achieved by having two mappings: one of the location names to the location struct and one of the asset names to the asset struct. Mappings were chosen over arrays to store the locations and assets as there is no need to iterate over every asset or location, so it is computationally less expensive to use a mapping to store and access individual assets or locations, which reduces the cost of interacting with the methods on the blockchain. Each of the functions in the code also has a list of require() statements at the beginning. This is a way of validating the data, which is passed into the methods and also controls who can execute each method at a particular time. A require() statement is the same as an if-else statement but if the conditional statement is false, the function is not executed, and the gas cost of the function is returned to the sender of the message. Therefore, require() statements are used as a method of saving as much gas as possible by refunding gas when functions are not called and is an important method of reducing the gas cost of executing functions on the blockchain.

5.2 Off-chain implementation

The CCC is a piece of software which evaluates contractual compliance given a set of rules written in Drools and a series of events in the form of XML files. The XML files have four fields: originator, responder, type, and status. In the contract used in this project, the sender and recipient are the originators and responders of the messages, which are sent between each other. Using the Drools language, each of the role players in the scenario is assigned an initial set of rights, obligations, and prohibitions. The CCC is then able to check when each event arrives, and whether the event complies with the ROP set. If an event is compliant with the ROP set, then the appropriate alteration of the ROP set involved is made; for example, upon initialization the recipient has the right to request delivery of an asset. Once the event comes in whereby the recipient requests the delivery of an asset, the right to request delivery for an asset is removed from the recipient and the sender is assigned the obligation to respond to the request with either a confirmation that the recipient can have the asset delivered or a rejection of the delivery.

5.3 Hybrid implementation

When implementing the hybrid solution, the first step was to decide upon which parts of the system would be placed on-blockchain and which parts would remain off-blockchain. Due to the blockchain being used as a decentralized database, this meant that any parts of the contract where a significant change in data takes place must be added to the blockchain. Any methods that are used for payment must also be on the blockchain. The areas where the biggest change in data occurs are when a recipient has paid for delivery of an asset, as it means that the asset must then begin the process of delivery. If the payment method is placed on the blockchain, the cancellation method must also be on-blockchain. This is so that whether the recipient pays for or cancels the delivery, the status is on the blockchain and the result of this can be retrieved at any time. Due to the process of adding to the list of locations where the asset is being delivered being a data change, this method also needs to be on the blockchain; however, it may be possible to adjust the CCC to take in extra fields in the Event class to pass locations into the CCC to add to the route and have one final method when the route is finished which pushes the result to the blockchain. The final indication of when an asset has been delivered needs to be on the blockchain, as well as the result of whether the recipient has claimed a refund or accepted a late delivery as this is related to payment. On the hybrid architecture, the stage variable in the asset data structure was no longer required, as all requests go through the CCC first, which checks that the correct clause of the contract is being executed. So this is removed from the asset data structure.

6.1 Gas cost

To calculate the cost of each implementation, the gas cost of each method within the Ethereum solidity code was measured using the truffle console. The console logs the gas cost when a function is executed. Some functions are shared between the on-blockchain and hybrid solution. The gas price of each function is not constant due to the use of strings in each method, which are of variable length. So each function has a base cost and a cost per character. Figure 9 shows a table of values for the gas cost of these functions. The gas cost of the findAsset() function is a constant value of 0 as it is a function which does not manipulate any data and only returns a value. There are also functions that are only used in the fully on-blockchain solution. Figure 10 shows a table of these functions. There are functions that are shared between the hybrid and on-blockchain implementations but have different gas costs. This is due to a reduced amount of information required to be manipulated and posted to the blockchain in the hybrid architecture of the implementation. Figure 11 details the functions that are shared between the two implementations but have different gas costs. Finally, Figure 12 shows a table of the deployment and migration cost of the on-blockchain and hybrid implementation of the asset tracker. The last step for testing the average gas cost of each of the implementations was to calculate the gas cost of each of the series of contract compliant events which can happen in the system. Figure 13 shows the results. The minimum total gas cost of each function was calculated by taking the minimum gas cost of adding two locations and an asset to the system along with invoking all the methods which are required to iterate through each clause in the contract. The rejection of deliver test requires 23.6% less gas using the hybrid implementation, the cancellation test requires 23.3% less gas using the hybrid implementation, and the full contract requires 32.1% less gas using the hybrid implementation.

6.2 Average execution time

To test the average execution time of the contract, Ganache was set up to mirror the rate at which Ethereum blocks are mined. In practice, this solution would be implemented on a private blockchain with multiple nodes connected to the network. Etherscan³² shows that the average block time for Ethereum has ranges between 10 and 30 seconds per block, being mostly restricted between 10 and 20 seconds. To test the average execution time of the solutions, we ran the tests at 10 seconds per block to get an indication of the best-case time for the solution. To make sure that the tests were fair for each system, a predetermined series of events needed to be derived for each solution to see how each solution handles the requests. The series of events which were chosen were a combination of full sequences of events which can be executed on the blockchain. This meant that no events which were not contract compliant were chosen, as when these events are attempted to be executed in the on-chain solution, they are caught in the require statements and not executed at all. The tests were conducted via the web browser created using MetaMask to confirm every transaction, meaning there is latency added for the accepting of transactions. All the series of tests were run for 10 assets and executed 5 times each. Figure 14 shows the results of each test. The first test was a recipient placing an order for delivery, and that order being rejected. The second test was the order being placed and accepted, then canceled by the recipient. The next test was to execute the entire delivery process, with the asset being sent from one location to the next location with no extra stops on the route (a direct delivery). The chart shows that for the test where the delivery request was rejected, the response time was exactly the same for the hybrid implementation and the off-blockchain implementation. This is because no information is actually sent to the blockchain at all for the rejection of a delivery request. The on-blockchain implementation had an execution time, which was nearly 35 times longer than the off-blockchain architecture for this test. The test case where the recipient cancels the delivery after the order has been placed is the first case where the hybrid implementation takes longer than the off-blockchain implementation. However, it is clear to see that there is a significant improvement in the time taken for this architecture to process the requests, reducing the time taken by over 80%. The final test also showed a significant reduction in the time taken for a full delivery to be completed, taking one third of the time to execute the same number of orders.

7.1 Gas cost

As can be seen from the testing of the gas costs for each of the implementations discussed, the hybrid implementation is a lot cheaper than the entirely on-chain implementation. The most interesting difference in the gas costs is between the functions which are shared between the hybrid and on-blockchain implementations. The addToRoute() function is particularly interesting as the difference in gas cost between the implementations is very low. This is due to the code between the two implementations being quite similar. On the other hand, the payOrCancel() method requires 17.8% less gas on the hybrid implementation. This is because the hybrid smart contract does not contact the blockchain to confirm which actions have occurred, meaning there is no writing to the blockchain in the hybrid solution, whereas in the on-blockchain solution, the smart contract has to change the stage variable. It is clear to see that in order to decrease the amount of gas required for each of the functions is to remove computation from the Ethereum smart contract where possible. This links to research in Reference 16, which suggested off-chaining as much computation as possible. A particularly relevant idea from the paper was the Delegated Computation Pattern, where a third party does computation off the blockchain and rather than having to replicate this on the blockchain, generate a proof of correct execution. While this solution does not have a proof of correct execution on the blockchain, using the CCC to check contracts compliant off the blockchain is a similar idea.

7.2 Average time

The big difference between the three solutions is the average time to execute each of the contracts. While this was a known issue with using a public blockchain such as Ethereum, our results clearly demonstrate the sizable difference in performance between the three solutions. Although this could be inflated by having to accept each transaction through MetaMask, there is still a limit on how fast the blockchain can process the data, which is dependent on the gas limit on each block. One of the problems with the testing method used for the on-chain solution was that each time a clause in the contract was called and accepted with MetaMask, the next clause in the contract for that asset could not be checked for contract compliance until the blockchain had mined the block. This is because the data are not actually put onto the blockchain until the block is mined. This means that the require() statements cannot be passed until the block is mined. This then creates a backlog of transactions that are waiting to be accepted when it takes too long to mine a block before the next clause in the contract is executed. This problem would be further exacerbated with slower block mining speeds. Our tests were conducted for a best case scenario taking the peak of the average block speed for Ethereum from the past year. If the speed was to slow down to 15 or 20 seconds per block, more of a back log would be created, leading to an even slower throughput. Despite this, we believe this would not be a problem for the proposed asset tracking system and for a host of similar applications. In a real-world application based on a blockchain asset tracker, the users of the software would not be going through the clauses in the contract within 10 to 30 seconds of each clause being executed. This would mean that the issue of blocks being mined too slowly for the data to be updated would only be a problem for applications where contract clauses need to be executed at a faster rate. Also, the above discussion assumes implementation of a solution using the public Ethereum blockchain. Mining speeds maybe significantly reduced if implementing a solution using a private permissioned chain.

7.3 Transactions per block

Taking into consideration the impact of mining speeds on the average execution time discussed in the previous section, another area can also be measured to discover the maximum potential throughput of the system. Each of the functions in the contracts has a gas cost that is only variable by a small percentage per character passed into the function parameters. This means that the base cost of the function could be used to calculate the maximum number of each function that could be called within a particular block. This would give us an idea of how many clients could be interacting with the smart contract at a particular time. The default block gas limit on Ganache is 6 721 975 gas per block. Using the values generated for the minimum gas cost per function, we can generate the maximum number of function calls per block, as shown in Figure 15. The methods where there is no orange bar are methods that do not have an on-blockchain execution on the hybrid architecture. Figure 16 shows the increased throughput of each method using the hybrid architecture. As the table shows, the throughput of the system is increased significantly in most cases. However, the maximum throughput is only as large as the smallest throughput in the system. Even though adding an asset to the system has the smallest number of possible function calls per block, it is not what will be used to calculate the throughput, as there is only a finite number of assets which can be added to the system. But we assume that there are an infinite number of deliveries, which can occur across time. This means the lowest throughput of the system is in the addToRoute() method. This is problematic for the hybrid solution as the increased throughput using this solution is only one function call per block, equating to a 1.78% increase in maximum throughput. This suggests that when using a public blockchain such as Ethereum, the hybrid solution is actually not very impactful at combating time related scalability and high throughput requirements of using a blockchain. To add to this problem, the average block gas limit has changed drastically over time, ranging from 500 000 to 10 000 000. This means that the throughput of the system is still open to changes depending on how much the block gas limit changes over time. Therefore, in addition to giving careful consideration to which contract clauses are to be placed on-blockchain and which are to be placed off-blockchain within a hybrid solution, it is also important, as discussed in Section 3, to identify additional methods that can improve the overall performance of blockchain technologies.