关于EOS启动的建议（Go-live阶段后的操作）
版权声明：
以下内容来自微信公共帐号“EOS技术爱好者”，搜索“EOSTechLover”即可订阅，译者Lochaiching。转载必须保留以上声明。仅授权原文转载。
本文原文内容链接来自于https://github.com/eosioca/eos-bios/blob/master/README.md，作者abourget，由本号“EOS技术爱好者”翻译。
由于篇幅较长，第一篇准备阶段的内容可点击此处，第二篇Go-live阶段的详细命令行操作内容可点击此处，本文为Go-live阶段后操作的内容。
This repository follows up on Thomas Cox's post about booting EOS.IO Software.
这篇内容跟帖Thomas Cox关于启动EOS.IO的文章（点击此处可见此内容）。
An EOS BIOS proposal
关于EOS启动的建议
Communications channels
Because of real risks of DDoS at the launch of the EOS Blockchain, the communication in the setup would use public key cryptography, ideally Keybase.io, and a few high-profile properties (Twitter, GitHub's gist, pastebin.com) to share content between the Appointed Block Producers kickstarting the network.
Each launch team, independently, would monitor the other block producers' properties (verified beforehand, ideally through Keybase's social-media vetting system) and see if they publish anything. Where each team publishes wouldn't be known in advance, thus difficult to attack.
通信通道
考虑到在EOS链上发布时DDoS的实际风险，通信设置将使用公钥加密，最好是Keybase.io和用一些众所周知的性能(像Twitter, GitHub的主旨和pastebin.com)在指定区块生产者启动网络时能共享内容。
每个启动团队都将独立地监控其他区块生产者的性能(事先经过验证，最好是通过Keybase的社交媒体审查系统)，看看他们是否发布了东西。每个团队发布的内容都不会提前知道，因此很难进行攻击。
The eos-bios program, could, if we want, have plugins for a few such properties and automate some of the processes.
Otherwise, the teams, watching for the BIOS Boot Node instructions (in the form of an encrypted payload) would simply paste the message in the waiting eos-bios.
This is not optimal in terms of speed, as there would be human intervention, but would satisfy the DDoS protection we need.
There are a few options to speed up comms and make them more automatic, with varying degrees of resilience / feasibility:
1. Ad-hoc VPN between the nodes (with something like http://meshbird.com/, an ad-hoc VPN based on bittorrent-like DHT)
2. Pick some random chat room service
3. Pigeons anyone?
要是我们想要eos-bios这样程序的属性，并使一些过程自动化的话。
否则，观察BIOS引导节点指令(以加密有效负载的形式)的团队只需将消息粘贴到等待的eos-bios中。
这在速度方面不是最佳的，因为会有人工干预，但会满足我们需要的DDoS保护需求。
有几个具有不同程度的弹性/可行性的选项可以加快速度并更具自动化:
1，节点间有Ad-hoc VPN(类似于http://meshbird.com/，这是一种基于bittorrent-like DHT的Ad-hoc VPN)
2，挑选一些随机的聊天室服务
3，Pigeons anyone（译者注：这个注释经过问询前辈，得到解释是与sneakernet相近。有关内容如下图所示，或点击以下链接：https://en.wikipedia.org/wiki/Sneakernet 或 https://www.zhihu.com/question/33634376/answer/125421668）
Kickstart data
The Kickstart data would be an encrypted YAML / JSON, using the 21 Appointed Block Producers' public keys, but no one else's.
That data can be published anywhere, and when pasted in a waiting eos-bios node, it can be decrypted and the process can continue on.
Sample contents:
bios_boot_node: 1.2.3.4:9876
private_key_used: 123123123123123123123123
bitcoin_merkle_root: abcdef123123
The bitcoin_merkle_root would correspond to the height agreed upon in launch.yaml, so that everyone can check this was created after Bitcoin's block, and cannot be replayed.
The private_key_used would only be present in the Kickstart data coming from the BIOS Boot node. Other ABPs would not have that.
Kickstart数据
Kickstart数据将是一个加密的YAML / JSON，只使用21个指定区块生产者的公钥。
该数据可以在任何地方发布，当粘贴在候列的eos-bios节点上时，可以对其进行解密，并进行下一步。
样本内容如下:
bios_boot_node: 1.2.3.4:9876
private_key_used: 123123123123123123123123
bitcoin_merkle_root: abcdef123123
这里的bitcoin_merkle_root将对应于launch.yaml时设置好的高度，以至于每个人都可以看到这个不能再重新来一遍了，因为这是在比特币区块后创建起来的。
private_key_used只会在BIOS启动节点的Kickstart数据中出现，其他的ABP没有这部分的内容。
Sabotaging the network
Sabotaging the network means rendering their BP account useless (just like the eosio account is being rendered useless by replacing the permissions with known-to-be-unknown keys, like EOS000000000000000000...).
If all ABPs run the BIOS software, they should all sabotage the network together, and if you falsely sabotage the network, you lost your chance of being a BP !
破坏网络
破坏网络等于是让他们的BP账户作废了(就像eosio帐户一样，用已知的未知键替换权限，比如EOS000000000000000000…)。
如果所有的ABP都运行BIOS软件，他们应该一起破坏网络才能达到效果。但是如果你是其中的一员，你的BP机会将会作废!
Block Producers publishing their intent
A neat way for block producers to publish their intent, or to prepare a private launch, would be to host/fork their own eos-bios-launch-data repositories and list in there only the candidates with whom they wish to build the network.
Candidates listed in this repository could be less filtered, and it would be up to the communities to agree on a common launch.yaml. It is to be expected that strong teams will want to partner with other strong teams to build the strongest network.
阻止生产者公布他们的意图
有一种灵活的方式可以阻止生产者公布他们的意图，或者准备一个私下的启动方式，只发生在他们自己的eos-bios-launch-data存储中，并且只有在他们希望建立网络的候选人名单上出现。
在这个存储库中列出的候选者尽量少过滤，并且可以由社区来达成共同的launch.yaml。预计有实力的团队可以和其他强队合作，共同打造出最强的网络。
To be fleshed out
• Figure our where genesis.json fits in.. perhaps in https://github.com/eosioca/eos-bios-launch-data agreed upon by the community.
◦ We could add a check by all ABPs
• Regarding initial inflation, and BP average:
◦ Good chances that inflation is set a posteri, when the constitution kicks in or something, and real Block Producers are voted with stakes.. then an avg can be made on their proposition.
具体化
•计算出我们的genesis.json 符合（条件）,也许在https://github.com/eosioca/eos-bios-launch-data商定的社区。
◦我们可以正式开始在之前添加所有ABP的检查这一项
•关于初期的增发，BP将:
◦增发是一个设置posteri的好机会。宪法生效时，真正的区块生产者将会被权益持有者投票产生。然后，可以在他们的提议上做算出平均值。
Hooks
To ensure a speedy ignition, we've designed a super simple remote control protocol, and provided a binary for you to hook in. It's totally optional but can help you speed up the deployment.
By running eos-bios-rc near your node and securely port-forwarding (using ssh -L, kubectl port-forward or other VPN solution), you can it react to the different steps in the booting process, for ex:
• reset the storage upon boot
• write some config.ini bits and restart your node
• update a genesis.json file remotely, and kickstart the node
See hooks.go
WARNING: you are on the hook (ha ha) to do any input validation. If a rogue BP writes an exploit to the Kickstart data, it could execute things on your infrastructure if you haven't checked your things. eos-bios will validate as much as possible its inputs, but be mindful on your end.
钓鱼软件
为了确保快速启动，我们设计了一个超级简单的远程控制协议，并提供了一个二进制文件供你使用。它是完全可选的，它可以帮助你加快部署速度。
通过在你的节点附近运行eos-bios-rc和进行安全的端口转发(使用ssh -L、kubectl port-forward或其他VPN解决方案)，你可以对启动过程中的不同步骤进行响应，比如:
•启动时重置存储。
•写一些config.ini 的bit并重启你的节点。
•远程更新 genesis.json 文件，并启动节点。
再看一下hooks.go
警告:您正在使用钓鱼软件 (哈哈！)进行任何输入验证。如果一个流氓BP在Kickstart data上设置了一个漏洞，如果你没有检查你的东西，它就可以在你的基础设施上执行。eos-bios将尽可能多地验证它的输入，但要注意到了你那里之后会发生什么。
本号翻译转述，
文中观点不代表本号任何立场
本文图片来源于网络
本文原文内容链接来自于hhttps://github.com/eosioca/eos-bios/blob/master/README.md，作者abourget，由Lochaiching翻译。转载请参照本文文首说明。
更多内容，关注“EOS技术爱好者”！
要是这篇文章对你有用，扫描下面erc-20地址给我们赞赏吧 !