版权声明：
以下内容来自微信公共帐号“EOS技术爱好者”，搜索“EOSTechLover”即可订阅，译者Lochaiching。转载必须保留以上声明。仅授权原文转载。
本文原文内容链接来自于https://github.com/eosioca/eos-bios/blob/master/README.md，作者abourget，由本号“EOS技术爱好者”翻译。
This repository follows up on Thomas Cox's post about booting EOS.IO Software.
这篇内容跟帖Thomas Cox关于启动EOS.IO的文章。
An EOS BIOS proposal
关于EOS启动的建议
这个网站（https://github.com/eosioca/eos-bios-launch-data）中包含一个简单文件有如以下内容：
launch_btc_block_height: 525123 # Approx June 3rd 2018 9am EST, 6am PST, 3pm UTC.
opening_balances_snapshot_hash: abcdef123123123
system_contract_hash: 123123abcdef
producers:
- eosio_account_name: acctname
eosio_public_key: EOSexample
keybase_user: example
agent_name: Example EOS.IO BP
url: https://example.com
当前的存储库起草了一个实验性的BIOS程序，它致力于简化和自动化启动一个新的EOS网络的过程。
你可以去这个网站下载安装：https://golang.org/dl，并运行以下命令：
go get github.com/eosioca/eos-bios
它将构建并安装一个二进制文件 ` ~/go/bin/eos-bios.
为了方便我们也会发布一个版本，但是建议你最好自己构建。
准备工作
• 要是你想要launch.yaml文件(来自eos-bios-launch-data)，可以通过从GitHub，或者从社区的朋友那里(如果GitHub能够DDoS)用P2P或其他方法拉出来。
◦该文件将包含一个商定的比特币区块号码，用于随机化的seed，`launch_btc_block_height`。
◦它包含这些公开余额快照的csv文件的哈希值，还有编译完成的系统合约。
◦它包含在网络中你想要的区块生产商的名单。
• 一个有硬件和网络准备的新 node，不是一个带着(编译和测试过的)从Block.one中释放EOS.IO Software的版本的空区块链。
• 一个刚被作废的ERC-20代币余额快照(snapshot.csv)，与launch.yaml中的opening_balances_snapshot_hash相匹配。可参见https://github.com/eosio/genesis/tree/0.3.0-beta
• 建立 DDoS-proof 通信通道，在ABPs之间发送信息(见下文)。
• 将你系统的时钟与世界的同步(运行ntpdate)。
系统上线
每个想要参与系统上线的人都要这样执行eos-bios:
eos-bios --launch-data ./launch.yaml \
--eosio-my-account acctname \
--eosio-private-key ./eospriv.key \
` --keybase-key ./file.key \`
--bp-api-address http://1.2.3.4:8888 \
` --bp-p2p-address 1.2.3.4:9876 \`
` --eosio-system-code ./eosio-system.wasm \`
` --eosio-system-abi ./eosio-system.abi \`
` --opening-balances-snapshot ./snapshot.csv`
• —bp-api-address是本地引导节点的目标API端点，一个clean-slate节点，它只能从本地机器上进行循环。
• —bp-p2p-address 是将在流程结束时发布的端点。
• —eosio-my-account 是launch.yml程序当前实例的链接。
• --eosio-private-key 必须对应于launch.yaml中当前实例的producers这一节的eosio-private-key。
• —eosio-system-code 和 --eosio-system-abi指向编译的eosio系统合同
• --keybase-key会指向PGP密钥或者Keybase，来解密有效负载。
整个过程将会是这样的：
• 验证—opening-balances-snapshot 哈希中launch.yaml:opening_balances_snapshot_hash的值。
• 验证—eosio-system-code 和 —eosio-system-abi 哈希中当launch.yaml:system_contract_hash和 eos-bios 链接，然后标准输出哈希表，让你不管在什么情况下都能对社区进行调整或核实。
• 验证以下字段中没有副本launch.yaml: eosio_account_name, keybase_user, agent_name, eosio_public_key
◦ 这里的` eosio_account_name` 不等同于 `eosio`, `eosio.auth`, `eosio.system` ，或者其他一些不cool的名字。
• 验证在producers列表中至少有50个申请者
• 在高度为yaml:launch_btc_block_height 时取回区块，取它的Merkle Root，然后用int64格式把这个信息传送出去。
◦ 我们有3个资源，像 https://blockexplorer.com/ https://blockchain.info/ 和 https://live.blockcypher.com/btc/由本地程序随机选择，或连接到本地比特币节点。
◦ 在这一点上，我们有一个确定的随机数生成器，它的值在以前是未知的，然后输入到rand.Seed（https://golang.org/pkg/math/rand/#Rand.Seed）。
• 然后，eos-bios就会从launch.yaml:producers中确定调整生产者的名单以及选出第一批22位指定区块生产者(ABP)，其中第一个就是需要用BIOS来引导启动节点。
◦ 基于——`eosio-account-name`，你的`eos-bios`实例情况知道它是否能启动节点。
▪ `eos-bios`将输出BIOS引导节点的名称和URL，并要求你监视发布Kickstart数据的组织(参见下文)。
▪ `eos-bios`可以获取列出在`launch.yaml`的Keybase帐户相关的其他属性，显示要是Keybase.io在启动的时候下降的情况。
◦* BIOS引导节点*中的`eos-bios` 将会继续以下操作：
▪ 用生成一个新的密钥对来显示它。让我们把它称为`ephemeral key`(与生产者的密钥通过`——eosio-secret-key`形成对比)
▪ 生成一个` genesis.json` 文件，其中包括：
▪ `initial_key`，设置为生成的临时密钥，这是用在第一个交易上签名并设置链的密钥(参见`chain_initializer::get_chain_start_producers`)
▪ `initial_timestamp`将重置BTC区块的时间，或者设置成`now（）`
▪` initial_chain_id`将被设置为[插入一些不愚蠢的](编码一天新闻文章的标题?!):)
▪ 在操作者节点中设置这些值：`config.ini` (`producer-name = eosio` 和` private-key = ["EOS6MRyAjQq8ud7hVNYcfnVPJqcVpscN5So8BhtHuGYqET5GDW5CV","5KQwrPbwdL6PhXujxW37FSSQZ1JiwsST4cq ▪ QzDeyXtP79zkvFD3"]`)
▪ 该节点开始生成，操作者开始引导。
▪ `eos-bios`现在能够注入系统合同，设置初始生产者(未获奖励的ABP)。这里的任何交易都是用引导中临时生成的密钥签名的，并用`genesis.json`中的`initial_key`来通过：
▪ `eos-bios`使用` --bp-api-address `提交一个`setcode`交易来为`eosio`帐户注入代码(同时包含了 `--eosio-system-code`和` —eosio-system-abi`)。
▪ 为了重新调整，在`launch.yaml`中列出所有生产者的` create account [producer's eosio_account_name] [producer's eosio_public_key] [producer's eosio_public_key]`，这是为了简化投票后的重新启动。
▪ 它用`snapshot.csv` 内容在`eosio`中 `issue` 所有的开放余额，并创建所有相应的帐户和分配pubkey。这些操作可以在一些交易中进行批处理，并在`chain_config.max_block_size`(当前1024*1024字节) 中进行最大化来减少开销。
▪ 需要做的是:我们需要弄清楚Ethereum的地址是如何起作用的。对于那些没有注册/声明的用户，这是最后一次调用!
▪ 用一个和`EOS0000000000000000000000000000000000000000000000000000000000`相似的公钥m在他控制的`eosio`账户上推动`updateauth`，显现`eosio`账户无法使用
▪ 也许我们应该有一些更本质的东西使得密钥无效，或者是跳过`updateauth`检查原始享有的特权(验证持有者密钥是有效的或者阈值是足够的等验证信息)，并使帐户永久禁用。
▪ `eos-bios`将会创建Kickstart数据文件，加密其他21个ABP并在屏幕输出。
▪ 操作者将在其有社交媒体属性的平台上发布该内容。
▪ 这时BIOS启动节点完成了它的工作。然后它恢复成从一开始就在50+等待中的其中一个，也是唯一一个知道其中一个节点地址并且可以看到其他连接的节点。
◦ 当引导节点执行上述步骤时，其他21个ABP等待标准输入，操作者从BIOS引导节点粘贴Kickstart 数据(参见以下内容)到网络上的某个地方。
▪ 当你启动发现数据时，它会粘贴到stdin中。如果你是21个ABP的其中之一，你会有密钥(通过`—keybase-key`或本地运行的keybase实例情况或对pgp的攻击)来解密文件并知道下一步应该做什么。
▪ 这将显示BIOS启动节点的位置，以及用于引导第一个节点的私钥。
▪` eos-bios `将会做以下其中之一：
a. 如果开始启用，在它们`--bp-api-address `上发出一个调用` /v1/net/connect`的命令语句，来添加BIOS启动节点地址，并开始同步。
b. 如果` eosio::net_api_plugin`没有启用，那么`eos-bios`也会输出需要的片段` config.ini` ，操作员手动操作并引导节点，该节点将连接到引导节点。
▪ 在这一点上，网络同步的时间不会太长。
▪ 在获得第1个区块的哈希之前， 21个ABP轮询他们的节点(通过`bp-api-address`)。他们在Kickstart数据中使用`private_key_used`来验证第1块上的signare，证明它来自BIOS启动节点。
▪ 如果不是的话，将会破坏网络(见下文)。好的演练应该能避免这种情况。
▪ 21个ABP验证所有投票产生的21位的帐户是否正确在` launch.yaml `文件中设置pubkey，否则他们会破坏网络(如果他们可以的话，他们也不是没有账号和密钥的人)
▪ 这21个临时BP验证了刚生成的网络中 Opening Balances的完整性，与在本地加载的`snapshot.csv`。
▪ `eos-bios`记录了`eosio`的` currency`表，并将其与`snapshot.csv`进行了比较。
▪ 任何失败的验证都会引发破坏。
▪` eos-bios`程序将一个已签名的交易推送到`eosio`系统合约中，用`regproducer`操作(和`launch.yaml`匹配的`producers` 定义中使用和`-eosio-my-account`匹配的`eosio_public_key`)，有效地注册了链上的生产者。
▪ 当所有的检查完成时，`eos-bios`将轮询节点并尝试发现所有其他参与者，并显示输出。
◦ 此时，BIOS启动节点恢复正常，这是等待的50多人什么都没有发生的情况下(除了可能看到ABP和BIOS引导节点)。接下来就是等待下一个阶段的标准输入。
◦ 我们来到了轻松的步骤，可以开始发布在全世界连接的地址，或者发布未加密的Kickstart数据。
▪ 这将允许所有仍在候列的50个以上的人用相同的循环，尽管验证已被禁用(这样就不会破坏他们的帐户!)
◦ eos-bios退出，说谢谢之类的东西
◦ Thomas Cox的其余步骤可能会被一个posteri处理，或者由系统的合同处理，还需要编写代码来说明这一切。
通信通道
考虑到在EOS链上发布时DDoS的实际风险，通信设置将使用公钥加密，最好是Keybase.io和用一些众所周知的性能(像Twitter, GitHub的主旨和pastebin.com)在指定区块生产者启动网络时能共享内容。
每个启动团队都将独立地监控其他区块生产者的性能(事先经过验证，最好是通过Keybase的社交媒体审查系统)，看看他们是否发布了东西。每个团队发布的内容都不会提前知道，因此很难进行攻击。
要是我们想要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数据
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没有这部分的内容。
破坏网络
破坏网络等于是让他们的BP账户作废了(就像eosio帐户一样，用已知的未知键替换权限，比如EOS000000000000000000…)。
如果所有的ABP都运行BIOS软件，他们应该一起破坏网络才能达到效果。但是如果你是其中的一员，你的BP机会将会作废!
阻止生产者公布他们的意图
有一种灵活的方式可以阻止生产者公布他们的意图，或者准备一个私下的启动方式，只发生在他们自己的eos-bios-launch-data存储中，并且只有在他们希望建立网络的候选人名单上出现。
在这个存储库中列出的候选者尽量少过滤，并且可以由社区来达成共同的launch.yaml。预计有实力的团队可以和其他强队合作，共同打造出最强的网络。
具体化
•计算出我们的genesis.json 符合（条件）,也许在https://github.com/eosioca/eos-bios-launch-data商定的社区。
◦我们可以正式开始在之前添加所有ABP的检查这一项
•关于初期的增发，BP将:
◦增发是一个设置posteri的好机会。宪法生效时，真正的区块生产者将会被权益持有者投票产生。然后，可以在他们的提议上做算出平均值。
钓鱼软件
为了确保快速启动，我们设计了一个超级简单的远程控制协议，并提供了一个二进制文件供你使用。它是完全可选的，它可以帮助你加快部署速度。
通过在你的节点附近运行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技术爱好者”！
