Actividad inhibitoria del extracto alcaloidal de Phaedranassa cuencana sobre BuChE

The deployment of smart contract on a sharded architecture is still in early stages of research and poses many challenges [51]. A major issue is that the invocation of cross-shard operations involve significant delays. Highly correlated smart contract may arise in many nested or sequential cross- shard operations. The result is that cross-shard transactions involve high latencies and the state of all involved smart contracts may be locked for other users during this period. Besides, allowing

x x

Data Duplicated Data

Data Loss Recovery

x

(a)Duplicated Data blocks

x x

Data Parity Fragments

Recoverd data Recovery

(b)Erasure encoding

Figure 4.6: Recovering data from duplication versus erasure encoded blocks

smart contract to lock the state of other smart contracts could lead to denial-of-service attacks in which attackers prevent users from accessing particular smart contracts.

To minimise the number of blocking cross-shard operations one could dispatch correlated smart contract to the same shard. That is, allow user to select to which shard a smart contract must be deployed. Ethereum 2.0 is adapting this approach [55]. While this increases smart contract performance and reduces latencies, it requires other measures, among others to balance shards. Ethereum addresses the former via independent Gas markets, i.e. new smart contracts will typically be deployed on ‘the cheapest’ shard and thus automatically balance the shards. However, the assumption is that new new smart contracts are not related to other smart contracts, otherwise it would probably be deployed in the same shard. It seems not unreasonable that new deployed smart contracts will have other dependencies. Moreover, assigning smart contracts statically to shards may be problematic foradaptive sharding, in which the number may be reorganised based on the number of active validators.

On the other hand, one could dynamically dispatch smart contracts in shards. This approach is used by Elrond [51]. Elrond partitions the address space deterministically according to a binary tree structure. That is, a node in the binary represents a address range and splitting the range by halve will result into two children. The leafs of the tree represent the actual shards. By dividing the address space deterministically, it also provides a mechanism for automatic transaction routing in the corresponding shards. However, this approach assumes that the contract-state and transaction is equally balanced. If some sets of account addresses are almost never used while others are used all the time, the shards may not be balanced after all. Alternatively, one could use dynamic account address ranges, by storing the start address of each shard as extra overhead instead of using predefined split structure. This way, shards could dynamically be adapted based on the number of transaction being processed during some previous Epochs. However, this will add extra split overhead, as shard need to resynchronise state after adapting.

A key observation is that the design heavily depends on the assumed use case. How correlated will the deployed smart contracts be? Can we split correlated smart contracts in disconnected sets? How frequent will shard be reorganised? Unfortunately, we could not find data regarding smart contract correlation. Moreover, it is questionable whether empirical data reflects future use cases. It is argued that the lack of scalability is the major bottleneck for widely adoption.

Nonetheless, every sharding model is a trade-off between (i)performance- the number of trans- actions being processed, (ii)latencies- the time needed for transaction to be finalised, (iii)security - the exploitability of possible vulnerabilities , and (iv) overhead the additional cost of storage or computation with regards to shard reorganisation and transaction processing.

4.4.1 Smart Contract invocation

While smart contract methods may be invoked by other smart contracts, the initial invocation is always an transaction. Such a transaction typically includes an ‘address’ field including the address of the smart contract, a ‘value‘ field to add some inherent token that may be send to the smart contract and some ‘transaction fee’ field to pay for the transaction cost. The execution then includes the following steps:

2. Execute the specified message call

3. Refund unconsumed transaction fee (if applicable)

In a full-sharding model, the account of the user may not be stored on the same shard as the account of the smart contract. Then, this operation will involve at least 2 cross-shard transactions and thus at least 3 block periods before the transaction is processed in its entirety. Similar to payment transactions, one could assume that the probability of having a user account and a random smart contract on the same shard is 1/n, with n shards. Then, there will be point in at which adding an extra shard will lead to more cross-shard transaction than actual user transactions. Using a transaction rate to compare sharding designs or improvement with regard to non-sharded ledgers does not seems to make sense.

Alternatively, one could require users to have an account in the shards as the smart contracts. Quarkchain uses this approach [44]. They assume that only a small set of users would want to communicate with multiple smart contracts. However, if a user will use a huge number of dApps, it effectively needs to create multiple accounts in multiple shards. Some argue, that this is not state- sharding [52].