警告:您可能成为了企图假冒本网站内容的目标。 我们检测到该网站被IFRAME包裹,这意味着与EOS Canada无关的人试图向您展示他们的内容与我们的内容相关,可能为了让您相信他们与EOS Canada有关。 我们与任何试图这样做的组织都没有联系,它也没有受到我们的认可



WARNING: you may have been the target of an attempt to misrepresent the content of this site. We detected that the site was wrapped in an IFRAME, which means that someone else, not associated with EOS Canada, attempted to show you their content combined in some way with ours, possibly to make you believe they are associated with EOS Canada. We are not associated with, and do not endorse, any organization attempting to do this.
background-flotant-top-right-01

Blog: EOS Block Producer Tips & News

background-flotant-top-left-01

Q&A - What Does Validation of Candidate EOS Chains Mean

June 06, 2018 / by Alexandre Bourget

Alexandre helps explain what it means when Block Producers say that they are validating the EOS blockchain before it launches.

 
Transcription:

 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.

 

Topics: Block Producer, EOS Launch, Validation, EOS Chain

Alexandre Bourget

Written by Alexandre Bourget

Alexandre lives through technology. He wrote his first botnet at 12, later graduated in classical piano and went on to a prolific career in software engineering, with notable open source contributions. Alexandre co-founded two startups, including Bitcredits (a bitcoin payments processor, FounderFuel 2014 Spring Cohort). He then helped PasswordBox (acquired by Intel) craft their data stack and ended up as a lead Data Scientist in the Intel Security Consumer division. Today, Alexandre is very active in the blockchain space, advising several early stage companies. Alexandre taught programming for many years. He does live-coding presentations like no one else (Confoo, PyCon conferences) and is the lead organizer of Golang Montréal. You’ll often find him on Telegram, working through lines of code and bugs with others, doing what he can to help build the EOS community.

dfuse - Template Blog Post Thumbnail-5

Building on EOSIO?

Develop your project with dfuse, the most powerful blockchain API.

BUILD NOW

cubes-solid

ABCs of EOS

A glossary of terms that every EOS user should know.

MORE