## 2 Backgrounds and Related Works
### Blockchain Basic
The complete dependency of UTXO-Check on the remittance address \(addr\) and the location \(loc\) in the blockchain where the transaction is recorded shows that sharding of cryptocurrencies can easily be accomplished in the UTXO model. For example, following two transactions \(t_{0}\) and \(t_{1}\) in the UTXO model,  
\[ \begin{array}{rcl}t_{0}&:&x_{0}\to addr_{0}:v_{0},\\ t_{1}&:&x_{1}\to addr_{1}:v_{1},\end{array}  \tag{5}\]  
which represent the transfer of cryptocurrencies with values \(v_{i},i=0,1\) from UC \(x_{i},i=0,1\) to \(addr_{i},i=0,1\), respectively, do not make any conflict as long as \(UC_{0}\
eq UC_{1}\), especially, even if \(addr_{0}=addr_{1}\). Therefore, the processing of \(t_{0}\) and \(t_{1}\) can be preformed in different shards without any conflict, since the shard itself affects the location \(loc\) in the blockchain and, hence, the outputs of \(t_{0}\) and \(t_{1}\) would make different UCs. Ethereum uses an account-based ledger model. Ethereum uses an Externally Owned Account (EOA) to store the ether (the name of the cryptocurrency used in Ethereum). This EOA works like a bank account. For instance, the transaction that transfers \(v\) ether from EOA \(E_{0}\) to EOA \(E_{1}\),  
\[t:E_{0}\to E_{1}:v, \tag{6}\]  
instructs all nodes in the Ethereum network to subtract \(v\) ether from EOA \(E_{0}\)'s ether balance and add \(v\) ether to EOA \(E_{1}\)'s ether balance. Smart contracts in Ethereum have their own accounts, named contract accounts or CAs, to store ether balances and the values for internal variables that need to be stored (as, being a program code, a smart contract can produce the internal variable values that are needed in the next execution). The smart contract cannot start by itself. It must be triggered by spending ether in an EOA. For instance, the transaction,  
\[t:E\to C:v,d, \tag{7}\]  
which instructs all nodes in the Ethereum network to execute the smart contract associated with the contract account \(C\) with the \(v\) ether transfer from EOA \(E\) to CA \(C\) and input data \(d\), must be properly requested by the user with the authority to control EOA \(E\). Once smart contracts are initiated, they can call other smart contracts in their executions by transferring ethers and input data. The Ethereum blockchain records the transactions that instruct all nodes in the Ethereum network to compute something, not the results of computations such as ether balance changes in EOAs and CAs or values for internal variables of smart contracts. These results are to be maintained by nodes. This makes sharding difficult in Ethereum. For example, two transactions,  
\[ \begin{array}{rcl}t_{0}&:&E_{0}\to E_{2}:v_{0},\\ t_{1}&:&E_{1}\to E_{2}:v_{1},\end{array}  \tag{8}\]which instructs all nodes in Ethereum network to transfer \(v_{i},i=0,1\) ethers to EOA \(E_{2}\) from EOAs \(E_{i},i=0,1\), respectively, cannot be processed in different shards, since the ether balance of EOA \(E_{2}\) in each shard would not match. In general, the smart contracts that produce values for the internal variables to be used in the next execution make sharding very difficult. In addition, inter-smart contract calling makes sharding even more difficult to deployed. It is worth noting that the next Ethereum protocol is scheduled to include sharding technology [20].