警告:您可能成为了企图假冒本网站内容的目标。 我们检测到该网站被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 - Understanding the Whitelist and Blacklist Features of EOSIO

June 06, 2018 / by Alexandre Bourget

Alexandre from EOS Canada discusses the issue #3814 involving contract whitelisting and blacklisting, with some learnings every Block Producer ought to know.


Transcription:

Hello everyone. Today I want to talk about a few features that were recently introduced in the latest code base of EOSIO. It's the contract whitelist and blacklist, plus the author whitelist and blacklist feature.

This is a thing that allows Block Producers to fend off a few transactions that are destined to certain contracts, or that had come from certain authors or certain accounts. But first let me just tell you a story of what happened yesterday.

So yesterday we're orchestrating the launch right, and it was crazy time with all the community together, and we had an issue. The test net we were testing sort of started forking the `nodeos` locally thought it was alright. It continued producing blocks. But the other ones receiving those blocks said "Oh, unlinkable block, invalid signatures." So it was not a good time to have that.

So I poked a few folks, block.one responded and said "yeah there's something there." And we dug, we cloned a copy of the chain, we shared it around so people could try it and we found out something that we absolutely need to share so that no one hits that issue anymore. It goes this way so. Let me explain first the contract whitelist and blacklist feature. If you add that to your `config.ini` or on the command line - - *shows paper* If you put that in your configuration file, so the contract will require a contract name, it could be `eosio.token` for example. That would set up some white listing or black listing on that account.

If you whitelist something, it will ignore any blacklist. It means it's exclusive. You can only send transactions to that contract. If you add many whitelists, they're going to be added together so you can send only transactions to those few contracts. If you have a black list plus one whitelist, the moment you have one white list, the blacklist is ignored. Any blacklist statement is ignored. So if you want to blacklist some contract, say there's a rogue contract stealing money, then you put a blacklist. And every block producer will need to do that to fend off transactions that try to run that contract. It's something that the block producers need to set on their own machine. So they need to call maybe if there's an urgent matter, they need to call one another and say hey this contract needs to be blocked, put that `config` and restart your node. And this is the only way that those transactions will not get into any blocks. Because what could happen is that the transaction could be refused by someone who black listed a contract, but the next block producer will just put him in. So this needs to go through all the block producers and no one puts that transaction in.

Now the other aspect is `author whitelist` and `author blacklist`. So this is a similar feature but instead of checking in the destination contract, it checks the source account, who is using the permission. There's an author field when you send a transaction, it says who is issuing that transaction and who signed it. So by doing that you can prevent certain people from issuing transaction. Again whitelist takes precedence over blacklist. You can have many of these and you can blacklist certain people, and that same thing also regarding block producers doing the setting there. Everyone needs to put the setting for that to be applied, otherwise it's just going to fall to the next block and it's still going to be included.

So the issue we had yesterday is that for testing purposes with a community we started the node with contract whitelist "nobody." That meant we only allowed transaction to the account "nobody" which didn't exist, so that really no one could send transactions that would be included in any block. It's just a way to block the chain so people can inspect it in read-only. The thing is the system contract has a side-effect. There's an unblocked method that the core chain calls inside the smart contract. And if this is not called then there was an `action_mroot` which was not updated. So it's an action that's built by the chain on each block, ran by the system contract.

If you white listed out the system contract, you would get into that situation which would have created a big fork and mess. So we just need to know about that and not freeze the system contract. Maybe there's some fix that can come out later on if we can work around it, but knowing it is a big part of solving the issue.

So I think that's it mostly. If there's an issue up, I don't have a number, we'll put that maybe in the description. And block.one's going to put that in the next fields of improvements. It's not a blocker, so that was one of our concerns there. It's not a blocker. So we can go out for a launch. We need to know that, please share that out and we'll talk to you later

 

Topics: Video, Q&A, EOS Launch, EOSIO

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