Ethanos: Efficient Bootstrapping for Full Nodes on Account-based Blockchain - Ben Kim

Hello everyone. I'm Ben, CEO and founder of Superblock in Korea, and today I'll be introducing efficient bootstrapping for states on the Conflux blockchain. This talk is about my paper published at the USENIX ATC 2021 conference last year; USENIX is an academic conference in the field of computer science, and Superblock is implementing a backbone network based on this idea. As blockchains become more popular blockchains become more popular , the number of accounts has skyrocketed , the number of accounts has skyrocketed . Surpassing 180 million in February 2022.

In addition, storage size and synchronization time have increased to over 530 GB, taking more than half a day to synchronize a full node. If you want to run a file node, it exceeds 9 terabytes and takes more than a week. Therefore, running a node is a heavy load. As a result, ordinary people cannot operate a complete node on their own. So they have no choice but to rely on full node services like Infura or Alchemy, and service providers must also cover the cost of running a full node by paying for services or maintaining their own nodes.

That cost is passed on to users in the form of fees, which increases transaction rates which increases transaction rates . Before talking about Etheranos, let's review Ethereum to learn some background. Ethereum stores each account in a state tree whose structure is a Merkle Patricia Trie or MPT, and the character sequence of the account address determines the path to the account data. Each node is labeled with a hash value node is labeled with a hash value ; this MPT is stored using LevelDB, and each node is saved using this hash as the key. Accessing an account requires multiple hash-based accesses , which is the main bottleneck for synchronization; MPT also allows for efficient verification through two types of tests efficient verification through two types of tests : inclusion testing and exclusion testing.

The inclusion test provides proof that an account exists in the state tree. For example, an account 0x71CDF could be tested using nodes such as branch node zero, extension node zero, branch node one, and extension node one, in addition to the account itself. We can serialize these nodes and this test can prove that this account is in this state tree; We can also prove that an account is not in this MPT by using an exclusion test. For example, if you want to prove that account 0x714a0 is not in this tree, we can use branch node zero, extension node zero, and branch node one, since there is no path for it, and we can create an exclusion test by serializing those nodes in the path. If a new node wants to join the network, it must synchronize the current state of the blocks.

There are two synchronization processes. One is active synchronization and the other is fast synchronization. There's also "snap" synchronization in the latest versions, but it's similar to the quick one. So I will explain these two processes. The "archive" synchronization downloads all blocks and executes all transactions from the first block to the current one to reproduce the current state.

The " current state. The " archive" synchronization stores the entire history of the blockchain. That's why it requires a lot of space and a lot of time. Therefore, fast synchronization was proposed, which downloads all blocks, but also downloads the pivot block state and only executes transactions from that point to the current one, significantly reducing storage and synchronization time, although it is still slow because we have to transmit and rebuild each node of the huge state tree, which generates intense disk activity. So we want to optimize storage size and synchronization time.

We investigated Ethereum and discovered that most accounts are inactive and only a fraction are active. 3% are active for one week and 5% for one month. We also discovered that active accounts tend to be reactivated soon. An account is updated in a week with a probability of 76% and in a month with a probability of 89%. Therefore, we propose reducing storage size and synchronization time by cleaning accounts periodically.

Let's create a lightweight node that only contains active accounts. Eternos cleans the accounts periodically every lambda epoch. For example, lambda could be 40,320 blocks per period. Eternals simply creates a new tree each time a new era arises. And yes, because traversing the state tree to find and remove accounts is extremely costly, so Eternals stores the last checkpoint of each epoch.

Then, Eternos creates a new tree only with the active accounts used for transactions in the new era. The reason Eternos keeps the last checkpoint is that the new tree has no state. So we need to copy the data from the latest account statement. This is the mechanism of Eternals. Uh...

If an account is in the current tree, just use it. But if an account is not in the current trie but is in the cache trie, copy it to the current trie to update it. If a score is not in either of the two tries, two cases could occur. If it is a sender, it is an invalid transaction because it has no state. If you are a recipient, create a "chrome" account as if you were creating a new account.

This "chrome" account is different from the "term" account because those states are different, but it is the Ethereum mechanism that creates an account. So we need to cover the " need to cover the " Chrome" accounts. And we purge the "term" accounts Chrome" accounts. And we purge the "term" accounts , and if a user wants to restore them, we have to provide a restoration process. And the user of the "term" account has to transmit a restore transaction.

Restore transactions recover the last active state of an account by merging its " an account by merging its " chrome" states. But there could be some deceptions. So, to avoid fraud, a restore transaction includes a sequence of proof-of-work and void tests that will be verified by the miners. And these proofs of work also demonstrate, and include, the last "term" account status and prove that that account really existed in the last block. And we use the restoration flag because we cannot distinguish the state from the restored state.

So we use this flag to prevent an already restored account from behaving as if it were a "chrome" account. Therefore, a valid state generated by a restore transaction can be expressed using a regular expression like this. And if a test sequence of a settlement transaction does not follow this regular expression, it will be rejected. Therefore, an attacker has no choice but to follow the regular expression, but this only generates a correct state. And Eteranos also provides another synchronization mode called compact synchronization.

Eteranos unloads the state tries from both the pivot block and the last checkpoint block, and reduces the size of the state try. Therefore, the size of both tries is very small, about 220 megabytes according to our experiment over a week, and we also removed old transactions because if we reduce the size of the state trie, the total size of the transactions increases. So we reduce them by omitting the download of all old transactions prior to the pivot block. In this way, we can significantly reduce the state size and synchronization time. Um...

Through the experiment, we discovered that we can reduce the size to less than 1 GB and that we could reduce the boot time to a few minutes. So we think this is something that can be preserved for ordinary people. This is the experimental setup. We evaluate using real Ethereum data. Uh, and we evaluated 300,000 Ethereum blocks from block 7 million to 7.

3 million. And there are 30.6 million transactions that updated 4.6 million accounts over two months in early 2019. There are around 1 million active accounts that occupy 23.

5% in block 300,000. and we adapted the Geth 1.9 client for implementation and compared it with the original Geth. We set the size of the epoch at 40,320. blocks, which is approximately one week, and there are around 200,000 resource transactions; The host and client specifications are written here, and the network environment was the internet.

This is the experimental result. The total storage size for Geth compact synchronization was approximately 1 GB and for Ethernos it was approximately 40 megabytes. And the size of the state tree was about 833 megabytes for Geth and 220 megabytes for Ethernos. And we found that its size is almost constant as time passes. And the total storage size is less than 600 megabytes, including the compact sync node and cache, and we think 600 megabytes is reasonable for ordinary people to run a full node.

We also measured sync time and found that Ethernos is always better than Geth's fast sync , and compact sync keeps sync time constant at around 100 seconds. So we conclude that if we apply Ethernos, we can limit or expect the Ethernos synchronization time to be very small and constant. So, Superblock is a company I founded, and we're creating a main network based on this idea and building the next- generation platform. We believe we can create two key features. One is a cross-chain hub and the other is standalone applications.

For the cross-chain hub , validators can operate additional lightweight nodes without the burden of cross-chain communication, because the size of Ethernos is very small. Therefore, the validator has a low load to run the nodes. Therefore, we think this could be a key feature for the cross-chain hub, and the other is the autonomous application because everyone runs their own node. So a standalone application could be implemented by integrating a front-end user interface into a smart contract and could be run by ordinary people. This way we can eliminate intermediate services and people can run the standalone application on their own computers.

Yes, that's all, and thank you.