由于每个账户给候选者只能投一次票，我们可以通过这个特性来验证代理投票。首先我们先通过get table查询三个候选者的票数，然后使用useraaaaaaab账户为producer111a投票，再次get table查询可以发现producer111a的票数升高了，此时再使用useraaaaaaaa账户为producer111a进行投票，操作成功，但get table去查询发现producer111a的票数不变，这说明useraaaaaaaa账户的票数已经通过代理账户useraaaaaaab成功代理投票。
七，干掉eosio以及eosio.*系统级账户当我们已经选举出来称职的出块者以后，出块者已经由原来的eosio变为众多出块者轮番出块，eosio变为接收块，随着启动时序接近尾声，eosio的作用越来越小，但它的权限仍是公开的密钥对，这是一件很有风险的事，所以综合考量，这一步骤，我们要改造eosio的权限。 root@iZ2ze5wsiqz8cj0lqgf73tZ:~/lwb-work/eos/tutorials/bios-boot-tutorial/nodes# cleos --wallet-url :6666 --url :8000 push action eosio updateauth '{"account":"eosio","permission":"owner","parent":"","auth":{"threshold":1,"keys":[],"waits":[],"accounts":[{"weight":1,"permission":{"actor":"eosio.prods","permission":"active"}}]}}' -p eosio@owner executed transaction: f738e289214b31b43255cd562bf12ac811f2c7b4cc0acc0b887a8ec7db603679 144 bytes 869 us # eosio <= eosio::updateauth {"account":"eosio","permission":"owner","parent":"","auth":{"threshold":1,"keys":[],"accounts":[{"pe... warning: transaction executed locally, but may not be confirmed by the network yet
通过为eosio账户更新permission，这里没有使用‘cleos set account permission ...’，是因为部署system合约以后，绝大部分的直接操作都失效了，所以转而使用system合约的push action eosio updateauth来更新eosio的permission为：
{ "account": "eosio", "permission": "owner", "parent": "", "auth": { "threshold": 1, "keys": [], "waits": [], "accounts": [ { "weight": 1, "permission": { "actor": "eosio.prods", "permission": "active" } } ] } }最终，我们检查eosio的owner权限为：
privileged: true permissions: owner 1: 1 eosio.prods@active,然后对eosio.prods账户产生了好奇，那么我们就继续查看这个账户：
root@iZ2ze5wsiqz8cj0lqgf73tZ:~/lwb-work/eos/tutorials/bios-boot-tutorial/nodes# cleos --wallet-url :6666 --url :8000 get account eosio.prods permissions: owner 1: active 2: 1 producer111a@active, 1 producer111b@active, prod.major 2: 1 producer111a@active, 1 producer111b@active, prod.minor 1: 1 producer111a@active, 1 producer111b@active, memory: quota: unlimited used: 2.594 KiB net bandwidth: used: unlimited available: unlimited limit: unlimited cpu bandwidth: used: unlimited available: unlimited limit: unlimited可以发现这个账户eosio.prods已经完全被出块者（注意不是候选者，而是成功出块的节点账户）占据，并且有了prod.major和prod.minor两个自定义权限，这里不展开了。
这样一来，我们已经干掉了eosio的owner权限，同理，干掉eosio的active权限。
resign系统账户eosio账户的权限被resign以后，正像使用eosio.prods账户来resign eosio一样，我们使用eosio来resign 所有的系统账户eosio.*。
resign目标：eosio账户以及eosio.*账户的权限被最终下发到区块生产者账户。
启动脚本到目前为止，我们已完成了所有启动阶段的操作的研究，可以看出这个启动流程有些麻烦，我们第一次去手动操作是为了理解每一步的具体含义和内容，而如果之后的生产阶段仍旧采取手动配置的方式无疑效率太低，因此上面反复提及的源码自带的脚本bios-boot-tutorial.py很好的解决了这个问题。前面的分析已基本覆盖脚本的内容，这里介绍上面未涵盖的三个步骤，这三个步骤是在以上内容的最后来执行的：
使用多签名来替换eosio对system合约的控制，这个不难理解，system合约相当于“系统设置”，这个权限层级很高，我们已经resign了eosio，以后system合约相关的操作需要通过提propose，然后经由参与resign eosio的权限账户的审批来最终执行成功。这个过程不介绍了，可以参考《EOS商业落地利器：多签名操作与应用》来自己实践。