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