关于EOS启动的建议（Go-live阶段）
版权声明：
以下内容来自微信公共帐号“EOS技术爱好者”，搜索“EOSTechLover”即可订阅，译者Lochaiching。转载必须保留以上声明。仅授权原文转载。
本文原文内容链接来自于https://github.com/eosioca/eos-bios/blob/master/README.md，作者abourget，由本号“EOS技术爱好者”翻译。
由于篇幅较长，本文为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启动的建议
Go-Live
Everyone trying to participate in the Go-Live would execute eos-bios this way:
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 is the target API endpoint for the locally booting node, a clean-slate node. It can be routable only from the local machine.
• --bp-p2p-address is the endpoint which will be published at the end of the process
• --eosio-my-account is what links the launch.yml with the current instance of the program.
• --eosio-private-key must correspond to the eosio_public_key of the current instance's producers stanza in launch.yaml.
• --eosio-system-code and --eosio-system-abi point to the compiled eosio.system contract
• --keybase-key would point to the PGP key, or Keybase something, to decrypt payloads.
This process would:
• Verify that the --opening-balances-snapshot hashes to the value in launch.yaml:opening_balances_snapshot_hash.
• Verify that the --eosio-system-code and --eosio-system-abi hash to launch.yaml:system_contract_hash when concatenated. eos-bios will print the hashes on stdout in any case.. for you to adjust or verify with the community.
• Verify there are no duplicates within all these fields from launch.yaml: eosio_account_name, keybase_user, agent_name, eosio_public_key
◦ That no eosio_account_name equal eosio, eosio.auth, eosio.system or a few other names that wouldn't be cool.
• Verify there are at least 50 candidates in producers list.
• Fetch the Bitcoin block at height launch.yaml:launch_btc_block_height, take its Merkle Root, massage it into an int64.
◦ We could have 3 sources, like https://blockexplorer.com/ https://blockchain.info/ and https://live.blockcypher.com/btc/ chosen randomly by the local process, or a connection to a local Bitcoin node.
◦ At this point, we have a deterministically random number generator, with a value unknown before, fed to rand.Seed
• eos-bios would then deterministically shuffle the list of producers from launch.yaml:producers and select the first 22. These are the Appointed Block Producers (ABPs). The first of them is the BIOS Boot node
◦ Based on --eosio-account-name, your eos-bios instance knows if it is the Boot node or not.
▪ eos-bios would print the name of the BIOS Boot node, and URL, and ask you to watch for that organization to publish the Kickstart data (see below).
▪ eos-bios could have fetched the other properties linked to the Keybase account listed in launch.yaml, to display them in case Keybase.io goes down while the launch is running.
◦ The BIOS Boot node's eos-bios continues:
▪ Generates a new keypair, displays it. Let's call that one the ephemeral key (to contrast with the producer's key passed through --eosio-secret-key)
▪ Generates a genesis.json file, which includes:
▪ initial_key, set to the generated ephemeral key. This is the key used to sign the first transactions and setup the chain (see chain_initializer::get_chain_start_producers).
▪ initial_timestamp will be reset to the time of the BTC block, or now( ).
▪ initial_chain_id will be set to [insert something not dumb] (encoded title of a news article of the day?! :)
▪ The operator sets these values in his node's config.ini (producer-name = eosio and private-key = ["EOS6MRyAjQq8ud7hVNYcfnVPJqcVpscN5So8BhtHuGYqET5GDW5CV","5KQwrPbwdL6PhXujxW37FSSQZ1JiwsST4cq ▪ QzDeyXtP79zkvFD3"])
▪ The operator boots the node, which starts producing.
▪ eos-bios is now capable of injecting the system contracts, setup the initial producers (unrewarded ABPs). Any transaction herein is signed with the ephemeral key generated on boot, and passed as initial_key in the genesis.json:
▪ eos-bios uses the --bp-api-address to submit a setcode transaction to inject the code for the eosio account (with both --eosio-system-code and --eosio-system-abi).
▪ it also create account [producer's eosio_account_name] [producer's eosio_public_key] [producer's eosio_public_key] for all producers listed in launch.yaml, in order of the shuffle. This is to simplify the takeoff after votes come in.
▪ it issues all opening balances in eosio with the contents of snapshot.csv and creates all the corresponding accounts and assigns the pubkeys. These actions can be batched in a few transactions hopefully, maxed at chain_config.max_block_size (currently 1024*1024 bytes) minus some overhead.
▪ TODO: We need to figure out how the Ethereum addresses come into play. For those who haven't registered/claimed, that's sort of the last call!
▪ is pushes an updateauth on the account eosio he had control over, with a public key similar to EOS0000000000000000000000000000000000000000000000000000000000, rendering the eosio account unusable.
▪ PERHAPS we should have something more intrinsic, that would make that key null, either a privileged primitive that skips the updateauth checks (that verify the owner key is valid, thresholds are sufficient, etc..), and render the account permanently disabled.
▪ eos-bios will then create the Kickstart data file, encrypt it for the 21 other ABPs and print it on screen.
▪ The operator will publish that content on its social media properties.
▪ Then, the BIOS Boot node has done its job. He then reverts as being only one of the 50+ waiting since the beginning, with the sole exception that he knows the address of one of the nodes, and can watch the ▪ other ones connect.
◦ While the Boot node does the steps above, the other 21 ABPs wait on standard input, for the operator to paste the Kickstart data (see below) from the BIOS Boot node, somewhere on the interwebs.
▪ When your launch team discovers that data, it pastes it in stdin, and if you're part of the 21 ABPs, you will have the key (through --keybase-key or a locally running keybase instance or shelling to pgp or something) to decrypt the file and know how to continue.
▪ This reveals the location of the BIOS Boot node, and the private key used to bootstrap that first node.
▪ eos-bios then does one of:
a. If enabled, issue a call to /v1/net/connect on their --bp-api-address to add the BIOS Boot node address, and starts to sync.
b. If the eosio::net_api_plugin isn't enabled, eos-bios would also print the config.ini snippet needed, the operator does it manually and boots is node, which would connect to the Boot node.
▪ At this point, the network syncs, shouldn't be too long.
▪ The 21 ABPs poll their node (through --bp-api-address) until they obtain the hash of block 1. They used the private_key_used in the Kickstart data to validate the signare on block 1, proving it was from the BIOS Boot node.
▪ If it wasn't, sabotage the network (see below). A few good rehearsals should prevent this.
▪ The 21 verify that all of the 21 that were voted have their account properly set up with the pubkey in the launch.yaml file, otherwise they sabotage the network (if they can and they're not the ones that were left out with no account/key)
▪ The 21 interim BPs verify the integrity of the Opening Balances in the new nascent network, against the locally loaded snapshot.csv.
▪ eos-bios takes a snapshot of eosio's currency table and compares it locally with snapshot.csv.
▪ Any failure in verifications would initiate a sabotage.
▪ The eos-bios program pushes a signed transactions to eosio system contract, with the regproducer action (with --eosio-my-account and the matching eosio_public_key in the matching producers definition in launch.yaml), effectively registering the producer on the chain.
▪ When all checks are done eos-bios will poll the node and try to discover all the other participants, and display them on screen.
◦ At this point, BIOS Boot node is back to normal, as one of the 50+ persons waiting for which nothing has happened (except perhaps seeing who were the ABPs and the BIOS Boot node). They're waiting on standard input for the next stage.
◦ We come to a point where anyone feeling comfortable can start publishing addresses for the whole world to connect, or publishing the Kickstart data unencrypted.
▪ This would allow all the 50+ who were still waiting, to join in using the same logic, albeit with validation disabled (so they wouldn't sabotage their account!)
◦ eos-bios quits, and says thanks or something.
◦ The rest of the steps in Thomas Cox's would probably be handled a posteri, or by the system contract itself. Some code still needs to be written to clarify it all.
(以下是中文翻译内容)
系统上线
每个想要参与系统上线的人都要这样执行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处理，或者由系统的合同处理，还需要编写代码来说明这一切。
下一篇将会继续提及到Go-live阶段之后的操作，敬请期待。
本号翻译转述，
文中观点不代表本号任何立场
本文图片来源于网络
本文原文内容链接来自于hhttps://github.com/eosioca/eos-bios/blob/master/README.md，作者abourget，由Lochaiching翻译。转载请参照本文文首说明。
更多内容，关注“EOS技术爱好者”！
要是这篇文章对你有用，扫描下面erc-20地址给我们赞赏吧