值得信赖的区块链资讯!
比推数据  |  比推终端  |  比推英文  |  比推 APP  | 

下载比推 APP

值得信赖的区块链资讯!
iPhone
Android

【Press Release】Soteria 主题分享 | Min Wu: 如何运行和维护区块链网络

Soteria

Claire : 大家好!我是【魔笛手技术开发社区】的创始人Claire Wu. 在习大大的号召下,很多企业都在研究如何区块链+,利用区块链的优点来提高企业,产品或服务的公信力。区块链如雨后春笋般越来越多,如何维护区块链变得越来越重要。今天非常高兴请来吴岷先生和我们一起探讨这个大家非常关心的话题:『如何运行和维护区块链网络』,有请Min Wu 吴岷先生……


17.jpg

吴岷: 大家好,我是Min Wu, 今天主要和大家讨论一下如何运行和维护区块链网络。


首先我们讨论一下不同种类的区块链和其相关的系统。(因为运行和维护不同的区块链系统是不一样的),今天我们主要看一下公链和私链的区别。


公链 (Public Blockchain) vs. 私链 (Private Blockchain)


公链是指全世界任何人都可以参与,随时进入到系统中读取数据、发送可确认交易、竞争记账的区块链。公链通常被认为是“完全去中心化”的,因为没有任何个人或者机构可以控制数据的读写,或者不许其他人参与。


公链的特点:网络拥堵效率低, 交易费用高, 扩展性差,比如比特币的10分钟一个区块。


公链的优点: 比私链更加彻底的去中心化,任何人都可以参与。


私链是指其写入权限仅在一个组织手里的区块链。读取权限也许是对外开放的,或者被一定程度地进行了限制。相关的应用是比如数据库管理、审计、甚至一个公司,尽管在有些情况下希望它能有公共的可审计性,但在很多的情形下,公共的可读性并非是必须的。


私链的特点:不开放,权利掌握在少数组织手中。


私链的优点:交易速度快,隐私性好,交易成本低


公链和私链谁好谁不好,什么时候应该用公链,什么时候应该用私链,不在今天讨论的范围。我们假设已经选定了一个区块链的解决方案。


区块链的相关系统和生态


无论公链和私链,都会有钱包或者客户端,这样最终用户可以在区块链上做交易,转账,DAPP,等等。除了非常早期的用户和开发人员,大多数用户希望有移动端的用户界面,至少是个网页版。


POW的公链会有矿工,挖矿是获取比特币的唯一方式,矿工需要购买专业的挖矿设备(ASIC),连接网络和电源之后进行挖矿。专业矿机噪音很大,不建议大家在家里部署。


超级节点:就是从 N 个备用节点中,经过所有持币用户投票选举诞生的最终获得记帐权的 M 个节点。


由于我们的时间有限,今天先不讨论钱包/应用/矿工/超级节点等的运维问题,我们聚焦在区块链本身。


和大部分的IT项目类似,运维需要解决的问题都会包括部署/监控/升级/测试等几个方面,下面我们一一分析。


部署


在区块链项目中,部署本身有很大一部分不是技术问题,是多方利益均衡的问题。比如公链,如果是POW,怎么冷启动,怎么有足够的全节点,怎么有足够多的人参与挖矿,这些都不是单纯技术可以解决的问题,我们今天不讨论。假设这些都不是问题,那么就简单了,大家上github下载源代码,编译(注意,有能力的参与者,一定要从源代码自己编译,不要用别人已经编译好的执行文件),执行,搞定。


真的这么简单吗?没有。比如大多数公链都是采用的点对点通信,举例子吧,小明和小芳是两个节点,他们会把自己已知节点中的8个节点信息互换,就像现实生活中,8个邻居一样。然后再去和这8个节点去互换他们邻居的信息,这样一层层的换下去,很快就有了所有节点的信息。

17-1.jpg


但是小明和小芳一开始是怎么认识的呢?Tinder 或者 陌陌。都不是。是DNS。以比特币为例吧,大家就是通过固定的DNS节点获取其他人的信息的。


比如: seed.bitcoin.sipa.be


具体代码可以去这里看:

https://github.com/bitcoin/bitcoin/blob/30521302f90e4856a7516867b32a4576fa6d98b3/src/chainparams.cpp#L116


vSeeds.emplace_back("seed.bitcoin.sipa.be"); // Pieter Wuille, only supports x1, x5, x9, and xd


vSeeds.emplace_back("dnsseed.bluematt.me"); // Matt Corallo, only supports x9


vSeeds.emplace_back("dnsseed.bitcoin.dashjr.org"); // Luke Dashjr


vSeeds.emplace_back("seed.bitcoinstats.com"); // Christian Decker, supports x1 – xf


vSeeds.emplace_back("seed.bitcoin.jonasschnelli.ch"); // Jonas Schnelli, only supports x1, x5, x9, and xd


vSeeds.emplace_back("seed.btc.petertodd.org"); // Peter Todd, only supports x1, x5, x9, and xd


vSeeds.emplace_back("seed.bitcoin.sprovoost.nl"); // Sjors Provoost


vSeeds.emplace_back("dnsseed.emzy.de"); // Stephan Oeste


(这里扯一句闲话,如果大家关心Bitcoin's Taproot Privacy Improvement, 大牛Pieter Wuille 就是github上的sipa, 就是上面DNS里面的第一个)


回到部署问题上,POW的公链是全开放的,任何人都可以参与,最开始的时候DNS非常重要,不然大家不知道在哪里寻找“组织”。而且一定不要只有一个DNS哦,(比特币有8个)不然被人DDOS攻击了以后,临时准备新的DNS就难看了。

17-2.jpg




还有就是bootstrap 的过程,这个过程通常是指,一个全节点第一次加入网络,(找到了组织)需要从网络下载以前的历史数据,比如今天(2019/11)比特币已经有250GB 左右的数据了。一个4K的电影每小时用7.2GB, 比特币的历史数据大约是35个小时的4K电影。如何从网络里面把这些数据下载到全节点的硬盘上(电驴是不行的,毕竟不是真的4K电影),在不同阶段的项目会有不同的解决办法。代码都是自己写的,也都开源了,种类繁多,要记住的是,不要只从一个种子那里bootstrap,有各种的随机分布方式可以选择,不然自己把自己DDOS就不好看了。


我们再看看私链的部署有什么不一样?


一点都不一样。


代码没开源,开源了也没用,因为可以验证产生交易的节点一定得自己部署。比如500个节点吧(有人问,为啥不是5个节点,其实我也不知道,上面说了,部署本身有很大一部分不是技术问题,是多方利益均衡的问题)。


那么问题来了,这些节点需要一样的操作系统,一样的版本,一样的补丁,一样的设置。那我们上云计算吧,大家都用AWS(或者其他,通常会有一个自己喜欢的云平台,强烈不建议跨平台,自己以后麻烦多多),最好统一的Terraform + Dockerfile。这样出了问题容易比较排查。


私链的初期部署比较容易控制,毕竟是有权限控制的,后期开放应用多的情况下,多加几个load balancer会对流量的动态调整有帮助,也可以避免不少单点故障。而且最大的好处是,可以先做一段时间的close loop testing再公开,对运维的压力会小很多。


监控


公链的监控比较困难,毕竟你能看到的层面就是那几个。共识层是最重要的,也是最不容易监控的。因为网络是开放的,软件是开源的,比如你自己的节点上的日志文件你可以采集和监控,但是别人的就不行了,人家都不一定是和你一个版本的软件。建议大家写一些点对点的小爬虫(github上找找),至少公开参与网络的节点可以被统计出来,然后你可以猜到大体上整个网络的变化,进一步产生一个dash board,需要的东西一目了然。


私链的监控可以在几个不同层面体现。不同区域的网络使用情况需要监控,在线的Docker数量,主机的CPU及内存情况,异常请求的数量,等等(这些数据公链就都没有了,因为大家的全节点是各自为政的)。好在很多的数据AWS都有现成的工具可以使用(或者其他的云服务商),这也是为什么尽量不要跨平台,不然很难有一个统一的监控平台。


无论是公链还是私链,在区块链中打包的交易都是需要监控的,比如大额的单笔交易(后面会有例子),比如包含超过正常水平很多交易数量的区块,比如超出正常范围的手续费,比如超多的节点连接数量。这些不一定都是问题,不一定需要采取行动,但是如果不知道这些就一定是问题。


升级


公链的升级很重要一点是兼容性,网络是开放的,大家不一定(几乎是一定不)在同一时间段升级,这时候上面提到的dashboard就有用了,你至少可以知道有多少人升级到了新版本,有多少人还在旧版本上。


私链升级,更多的是要考虑容量问题。比如现在的RPS是500K,一个容器可以处理20个RPS,一共有25000个容器。新版本的升级需要做到的是每次升级一小部分的容器,分多次升级,最终把所有的容器升级到最新的版本。还有就是如果升级失败后的回滚问题,以及回滚后的数据兼容问题。下面需要介绍的测试就有很大的帮助了。


测试


为什么要测试,这点不是我们今天讨论的范围,总之必须测就行了。


公链和私链在测试方面很多是相同的,比如每个PR (Pull Request)之前需要测试,每个release之前需要测试,平时还需要一个testnet来随时随地的测试。当然每个测试的侧重点都不一样了,具体问题具体分析。


好了,长篇大论讲到这里,下面说两个实例吧,都是比特币的。


第一个和升级有关。


升级出现的问题:https://github.com/bitcoin/bips/blob/master/bip-0050.mediawiki


2013年的升级到0.8。在pre-0.8的代码里面有一个bug,升级了的版本没有了这个bug,从现在的观点看(事后诸葛亮),当然大家都需要升级了,事实上发生了什么,和现在大家的想法完全不一样。具体看一下:


在0.8以前的代码里,后台存储数据是使用的Berkeley DB, 在0.8的新代码里面,升级到了LevelDB。在Berkeley DB的缺省设置情况下,是无法处理比较大的区块的(大而且交易很多的区块,并不是大但是交易数量少的区块),在文档说明里面,开发者写了如何调整缺省设置,可以支持更大的区块。怎么写的呢,这里是原文:


The recommended algorithm for selecting the maximum number of locks, lockers, and lock objects is to run the application under stressful conditions and then review the lock system's statistics to determine the maximum number of locks, lockers, and lock objects that were used. Then, double these values for safety.


就是说你自己在高压情况测试一下,然后把观察到的数据乘以2。那么问题来了,每个人的全节点或者矿机的环境不一样,测试情况不同,时间不同,高压情况下得到的数据就不同。乘以2以后也不同。那么也就是说,如果大家都按照文档做事情,大家得到的数据(也就是这个层面的共识)都是不一样的。记住,共识不一样就会非常不好,就会分叉。


事实上是怎样的呢?极大多数人都聪(偷)明(懒)的使用了缺省设置,于是大家的共识就是缺省设置了,于是大家的共识就是“我们都不支持大的区块咯”,尽管这个共识其实是错的哦。这也就是为什么说pre-0.8的代码有bug..这也是比特币代码实现品种单一的弊病。


0.8的代码解决了这个问题,升级到LevelDB以后,可以支持更大的区块了,而且更多的交易。那么问题简单了,大家一起升级就是了。事实上是,约有4成的人升级了,还有6成的人没升级或者在升级中。这个时刻,一个大的区块被挖出来了,4成的人说是好的,我们接受,6成的人说我们不明白,处理不了。


于是分叉了,硬分叉哦。


和现今主流观点完全不同的是,当这个硬分叉发生的时候的处理办法。Marek Palatinus (Slush) 和 Michael Marsee (Eleuthria of BTCGuild)回滚了他们的矿机。他们当时是已经升级的4成中的主要两个矿工,他们牺牲了自己的利益以保证了全网的共识(尽管这个共识是错的哦,另外一句闲话,这个是不是很像ETH vs. ETC?)。然后就是一大堆的紧急的布丁,和通知所有人,需要升级,几个月以后才第二次升级成功。具体的步骤由于今天篇幅有限,就不细说了。


第二个例子和交易有关。


Bitcoin 2010 event https://nvd.nist.gov/vuln/detail/CVE-2010-5139..


和第一个例子比起来,这个就不那么烧脑了。


在2010年的时候,区块74638包括了一个很牛逼的交易,任何一个比特币交易都有输入和输出(input output),这个交易输入了0.5个比特币,但是输出了184 Billion,就是1840亿个比特币(收钱的人们发财了,一共两个地址)。


没看错啊,就是184个Billion的BTC!


原因是黑客找到了一个漏洞,检查交易记录的代码在处理巨大的输出数值的时候溢出了,于是这么大的交易本应该被reject的,反而被接受了。


几个小时以后开发者就发布了一个补丁,53个区块以后,新的区块链取代了“坏”的区块链。


大家可以思考一下,这两个截然不同的实例中,对运维的考验有什么共同的特点。


代码是不可能没有bug的,共识不是一成不变的,环境和系统中各种因素都会不断变化。


建立更有效的运维体系,更早的认识到问题,更快的解决问题才是硬道理。


最后提一下反馈和沟通,需要有常规的渠道,同时需要避免单点故障,比如不应该把交易需要用的网络和反馈用的网络合二为一,比如他们底层都是用AWS,当AWS出现故障的时候,你连报错的渠道都没有了。


今天分享就到这里,大家有什么问题可以一起讨论。


特别鸣谢赞助和主办机构Soteria社区,魔笛手技术开发社区,参与本次直播的社群 (排名不分先后) 和所有参与讨论及关注的群友。


- 魔笛手技术开发社区

- Soteria 硬核科技社区

- Soteria SSDE开发社区

- 数字万物讨论群

- 新通证经济无名高地

- 盗火者区块链应用联盟

- 7月线下线上交流学习社群

- 加密数字货币与区块链生态系统

- Defi 研究院 成都

- Metamask中文社区

- 量子计算 人工智能 区块链 00003

- 西电区块链兴趣组

(未完待续)


说明:比推所有文章只代表作者观点,不构成投资建议
原文链接:https://www.bitpush.news/articles/648012

比推快讯

更多 >>

下载比推 APP

24 小时追踪区块链行业资讯、热点头条、事实报道、深度洞察。

邮件订阅

金融科技决策者们都在看的区块链简报与深度分析,「比推」帮你划重点。