Alexandre helps explain what it means when Block Producers say that they are validating the EOS blockchain before it launches.
Hello everyone. I just wanted to give a little bit of clarity on what is going on in validation. What are the things being validated, and what makes a chain valid or not?
The validation tools that are being written right now, and have been written lately the past few weeks, verify a few important things. Of course, for all the token holders, it verifies that all the accounts that honor the token crowd sale are properly created and have the right balance. And anyone who has a little bit more than 10 EOS has 10 free-floating EOS so you can transfer right away when the chain starts. And the rest is all staked properly for voting and using the network. Which you can unstake and get that sort of "refund" after three days. So we want to verify these balances match.
We want to verify also that there's no account that was added that was not in the list, right. You don't want to have an extraneous account there. We also want to validate that the system accounts are properly set and there's two accounts in there that have a privilege flag, we want that one to be privileged and no other account to be privileged. Those accounts that allow the contract to impersonate or sign transactions on behalf of other people so the system contract has that ability, and the "M-sig," multi-sig contract has that ability because it manages and facilitate people doing multi signature in the contract. And then that contract releases that transaction as those who have agreed on the multi signature.
We also want to verify, if we go with that solution, to have the unregistered contract with all the balances from the people who have not registered their key. So the Ethereum address and their balance is going to be stored on chain for future use. And so the balance of the unregistered contract which holds the bucket of all these funds also has the right balance.
Another thing we need to validate is the contract code. There's some code injected in the chain and we want to make sure that it matches what everyone compiles. So you can deterministically compile the code and verify that the SHA-sum matches. Now we've uncovered a little issue this morning is that when you compile the contract with a default flags, the building flags, the path in which you do the compilation leaks in. It's included in the file. So when you compare them, they don't match exactly. Because you know if you're called Paul and your home directory is /home/Paul, that goes in. And then if you're Alex /home/Alex goes in so you compare and they don't match. So most of the docker builds have a deterministic location, /contracts, where the contracts are built. So this all matched, but some people were surprised to see you didn't match, and that was the issue. It's a non-blocker for a launch and there's also a commit in the repo that will solve that. But it's just cosmetic. That path is just for debug info, so it doesn't have an impact on the actual code being run.
But that's one thing we need to validate. Make sure the code is what we agreed on, and the other thing we want to validate is the Ricardian contract content. The the governance community has been talking and going through all the words of all these Ricardian contracts for all the operations and they came up with that final list of contracts and we need to put it in-chain. This needs to be validated to match that new governance repository, where the community came into agreement.
So these are most of the things that need to be validated and we need to have consensus on that. Many people doing those checks and leadership being taken to do those checks, because it won't happen by itself. And we've seen a lot of leadership from different block producers stepping in and saying I've tested that, and we want to have more than one test right? Before we can say okay this is all good and these validation tools can all run on one, two, four chains and test it locally. So that's really useful for the whole community.