• blockchain
• ethereum
• merkle mountain range
• smart contract

Blockchain as Ethereum maintains a distributed ledger that consist in blocks containing transactions, chained together through cryptographic hash. Usually, when a node wants to verify the presence of a specific transaction, for example to verify a payment, it needs to download the whole blockchain from a fullnode, a node that with the entire blockchain. To be precise, to verify a transaction it is needed the whole blockchain because the node that provides the block in which the transaction is may be malicious, and so a client must verify the correctness of the entire blockchain. According to this getting all the blocks of the blockchain, a node can verify all the blocks going back to the genesis. Unfortunately, this may be very expensive in term of storage and bandwidth because it is in order of the hundreds of GB of storage, requiring hours for the download. Since this could be unfeasible for light clients, like Internet of Things (IoT) devices, mobile devices and all those devices with limited storage and bandwidth. For this reason, the original Bitcoin design introduces the Simplified Payment Verification (SPV), a way to light weighting verify a transaction in a blockchain. The SPV approach allows a light client to verify a transaction with the headers of all the blocks, significantly reducing storage and bandwidth needed. Despite that, the number of headers that a light client must downloads grow linearly with the size of the blockchain. According on the high dimension of the blockchain, downloading all the headers requires unsuitable storage, between 5 GB and 8 GB (2020). To overcome this, in 2020 the paper “FlyClient: Super-Light Clients for Cryptocurrencies” introduced a new blockchain verification mechanism, that, instead linear growing amount of storage and bandwidth like SPV, it uses logarithmic number of headers, making this method suitable for a light client. FlyClient exploits the power of Merkle Mountain Range (MMR), a construct based on the Merkle Tree, but unbalanced. Moreover, FlyClient introduced a new probabilistic sampling mechanism to minimize the number of blocks needed for the verification and at the same time maximize the probability to catch a dishonest node. However, FlyClient still presents a problem, because it application requires a modification of the headers of the blocks. An alternative of that could be using the FlyClient mechanism and, exploiting a Smart Contract, update the MMR thanks to nodes called updater. Those updaters update new MMR leaves to the Smart Contract that add them to the MMR and saves the MMR root in the receipt log of the transaction making it available to the off-chain node. Although, this introduces problems about the honesty of updaters. In fact, a malicious updater could send badly generated leaf to corrupt the MMR and, consequently, invalidate the root. The contribution of this project is to model a mechanism to supervise the correctness of the leaves updated and, in case of a detection of a malicious leaf, a way to heal it. These things will done through a Smart Contract deployed with an internal ring buffer and a supervisor, a node that check and heal the leaves updated to the Smart Contract. Therefore, I have implemented a Smart contract like that and the supervisor, to test their performances. The tests done were about the analysing of the mean cost to update MMR leaves and to check them, varying the size of the buffer of the Smart Contract. Tests show that costs of both update and check are directly related to the size of the buffer. In fact, the higher is the buffer size the higher are costs to update and check leaves, and viceversa. Eventually, tests demonstrate that buffer with size equal to one is the best scenario in term cost both for updaters and the supervisors. The rest of the thesis is organized in section 2 that introduced some preliminary concepts. The section 3 describes the buffer of the Smart Contract, and the section 4 is about the Supervisor. Eventually, the section 5 describes the technologies used for the implementation, section 6 is about the test and the section 7 is a conclusion.