关于EOS启动的建议

in #eostechlover6 years ago (edited)

版权声明:

以下内容来自微信公共帐号“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-accountlaunch.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_hasheos-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)
WechatIMG989.jpeg
2,挑选一些随机的聊天室服务

3,Pigeons anyone(译者注:这个注释经过问询前辈,得到解释是与sneakernet相近。有关内容如下图所示,或点击以下链接:https://en.wikipedia.org/wiki/Sneakernethttps://www.zhihu.com/question/33634376/answer/125421668)
WechatIMG1031.jpeg
WechatIMG1032.jpeg
WechatIMG1033.jpeg
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 -Lkubectl 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技术爱好者”!
微信公众号QR码.jpg

Coin Marketplace

STEEM 0.19
TRX 0.15
JST 0.029
BTC 62869.05
ETH 2545.35
USDT 1.00
SBD 2.72