I believe that before you read this NGIN Weekly, you have already got a general understanding of what the project wants to do through our official website and the original whitepaper on github.
This week we will make a brief review of the original project and then start to talk about how we are going to design our new backend daemon.
Let’s review how Arseniy#8378 led Ngin to “errors”.
First, their first algorithm version had a fatal error, which made it impossible to dig out the first block.
After the emergency repair, they wanted to make the user experience more. Well, they started to build a web wallet, but the users are still not satisfied. They started to build the computer GUI wallet.
At this time, they once again saw the drawbacks of the Ethereum classic code: the network id in the rust wallet can only take 0-255, and many The ethereum forks have been entrenched in this range, and the NGIN team was forced to modify theirs to a higher value which stackoverflow due to the int8 limits.
At the same time, the miners are eager to have a mine pool in NGIN and to appease the miners, they first open source the mine and then develop mining software. As a result, their official mine pool is almost no hashrate, it is a very ridiculous result.
Subsequently, they released the super-node model without burning money. The good news is that this model does make more and more nodes (the entire network node has only the mining pool and the official node after the mining pool), but because of the Ethereum classic transaction model limits that the automatic revenue distribution of the main node leads to congestion on the main network. Due to the error, after the fork, other mining pools reject all transactions that are not generated by theirselves. The congestion situation is not fixed unless it is forked again. In the end, Arseniy#8378 and others decided to give up the project.
According to Arseniy#8378’s own words, he lost his original interest in the process of adapting to ethereum classic and serving customers, and lost his inspiration of the product.
This is one of the reasons we decided to restart the project from nothing.
Because it is impossible to talk all the things in a short article, this week we will talk about our new data structure.
First we still save the block struct. In the block we will save the PoW data and the transaction data - this is exactly the same as the concept of bitcoin, ethereum.
Our innovation is to introduce a new type of block that binds vault, and our blocktime is set to 10s as before.
For the sake of easy understanding, we call it checkpoint, and every 6 blocks will have a vault to encapsulate the transaction content of the previous 6 blocks.
The vault itself becomes a chain, and all blocks are mounted on this vault chain. Vault, as its name suggests, is a safe for user balances. In vault, in addition to the hash required for chaining, its biggest content is a k-v table that holds all user balances and user-hosted data.
This is the content that is stored permanently in project. All the content that needs to be persisted, such as the source code of layer2 contracts, is stored in the vault.
In contrast, the transaction data in the block, we make it a content that does not need to be saved: the synchronization of a new node only needs to synchronize at least 2 vaults and corresponding 12 blocks, and other historical transactions can be directly deleted.
Since vault is already a summary of the longest chain of trust, we only need to ensure that the vault is associated with the last vault and immediately prove that the longest chain is synchronized. And because of the limitation of the verification of its own currency in the vault phase, even a 51% attack on our main chain will not succeed.
As a result, our node’s storage footprint can be very small, discarding cumbersome and meaningless content, and retaining meaningful content associated with the account.
This time we introduce the concept of vault, more details such as account strcuture and operation pool we will elaborate in the following ngWeekly.