6.2.3. Discussion

Limited to the scenario we tested, it seems that a number of data owners around 30 and 40 induces the best ratio of completed rounds to response latency time. With this workload, the system can fulfill around 0.17 rounds per seconds. Overall, we can observe how the writing in the blockchain greatly impacts the whole system performance and that the number of requests related only to the TPRE operations can still scale to a larger number of data owners.

In reality, the interaction of owners with the system may be much slower, making the overall round latency increase but, at the same time, diminishing the system workload. We can imagine that the *NewRequest* event triggered by the *requestAccess()* method is shown to the data owner through a smartphone notification, thus requiring seconds, if not hours, to be read and accepted. In this context, the use of semantic web-based policy languages to express rich rules for consent and data requests could be useful in automating (and thus speeding up) this process [59]. This is left as future work.

Nonetheless, we argue that the results show the viability of our approach, especially having the possibility to tweak the authorization blockchain parameters and node hardware configuration. Moreover, the good response of the TPRE implementation gives reason to believe that, by moving this module to another blockchain that supports smart contracts but provides better latency, even improved outcomes can be achieved.

### *6.3. Smart Contract Gas Usage*

Our focus is now on the execution of the smart contracts that we described in the use case Section 5, with regards to steps 1 to 4. In Ethereum, the *gas* is a unit that measures the amount of computational effort needed to execute operations. Thus, the higher the gas usage for a method, the more intense the computation of a blockchain node to execute the method's instructions. In Table 4, we provide the execution cost for the main methods in terms of gas usage.



We start from the analysis of the gas usage of the *trans f er*() method of the *kDaOToken* contract. This acts as a reference point, as this method is one of the most invoked ones in the Ethereum public permissionless blockchain, because it consists of the standard implementation of the ERC20 token. The associated gas usage of ∼52k can be relatively considered cheap, and it helps to give a measure of comparison. The *DataOwnerContract*'s methods can, then, be considered relatively cheap in comparison. This result is needed because these methods are executed many times. The method *requestAccess()* is the one with the highest gas usage because it takes as input several parameters, i.e., IOTA announcement link, variable list of Ethereum accounts, a string for the request.

The *AggregatorContract*'s method *requestAccessToData()* has an high gas usage, i.e., ∼700k, because it interacts with several other contracts on-chain. This usage value represents a request made to other two smart contracts. In general, the gas usage in this case increases linearly with the number of contracts to make the request to. The *createkDaO()* method is cheaper because it only reads from those smart contracts. However, the gas usage is high because it deploys a new contract, i.e., the *kDaO* one, using the proxy pattern. By using the EIP-1167 Minimal Proxy pattern [72] instead of a standard factory pattern, this method only uses ∼447k gas units instead of ∼2840k.

In the *kDaO* contract, the *submitProposal()* method is used to submit a generic proposal and uses less gas than the *submitRefundProposal()* because the latter executes two more operations, i.e., submits two proposals "refund" and "not-refund". The *vote()* and *changeVote()* methods have slightly higher gas usages because of the check of the locked tokens. The *lockTokens()* method in the *TokenTimelockProxy* contract for locking a certain amount of *kDaOToken*s is expensive in terms of gas usage, i.e., ∼256k, because it also deploys a new contract using the proxy pattern. However, also in this case, there are savings compared with the factory pattern, that requires ∼1037k gas units.

Generally speaking, the methods that are executed the most do not appear to be a concern for their execution in a private permissioned blockchain environment.
