区块链世界里不能信什么?

-回复 -浏览
楼主 2019-09-15 17:25:35
举报 只看此人 收藏本贴 楼主
GMTC

大家好,我是张开翔。

上一篇分享了“信任区块链时究竟在信任什么?”,这次换个角度,漫步月之暗面,谈谈在区块链系统和业务设计时,不信任什么。

先讲结论: 几乎什么都不能信!

建立Don't Trust,Just Verify的理念,才是通往区块链世界的正确态度。

——By我随口说的

1 不信任其他节点

区块链节点和其他节点会建立P2P通信,共同组成网络,传递区块、交易、共识信令等各种信息。其他节点可能是由不同的机构、不同的人持有,持有节点的人可能是善意,也可能是恶意。

即使在善意假设时,节点运行存活的健康度也会受运维水平和资源影响,比如处于一个不稳定的网络里,会偶尔挂掉,会抽风乱发消息,或者硬盘满等原因导致数据存储失败,以及出现其他可能的故障。

在恶意假设时,要预设其他节点可能会骗自己或伤害自己,比如传递过来错误的协议包,或者用诡异的指令寻找漏洞进行攻击,或者发起高频垃圾请求,频繁连接然后断开,又或者海量连接占用资源等。

所以节点应该是把自己看成在黑暗丛林里孤身求生存的猎人,必须有“独立自主”、“自给自足”的态度,摆出“不相信其他任何节点”的姿势保护自己。在节点准入时,需要采用证书技术来认证节点身份;在连接控制上,拒绝有异常的连接;采用频率控制对连接次数、请求量等做限制;在协议包格式和指令正确性等方面做验证。自己发出去的信息,不应暴露自己的私有信息,也不期望其他节点一定会给出立刻和正确的响应,必须采用异步处理和校验容错的设计。

2 节点和客户端互相不信任

客户端,指在区块链网络外,向区块链发起请求的模块,如业务使用的java sdk、钱包客户端等。客户端和节点通过网络端口通信。

如果客户端掌握在不受控的人手里,有可能会向节点发起大量的请求,或发送一堆垃圾信息,使节点疲于应对,甚至巧妙地构建漏洞攻击信息,试图越权访问,窃取信息或使节点出错。

同时,从客户端的角度看,节点有可能不响应或响应缓慢,或者返回错误的数据,包括格式错误、状态错误、表示收妥但其实不处理等,甚至别有用心的人会设置一个“假”节点和客户端通信,欺骗客户端。节点做出这些与期望不符的反应,可能使客户端运行出错,功能受损。

为提升节点和客户端的互信,可以为双方分配数字证书,必须通过证书进行双向握手,客户端经过私钥签名才能对节点发起交易类请求,节点应对客户端进行权限控制,拒绝高危的接口调用,不要轻易开放节点管理接口、系统配置接口等。双方对每次通信的数据格式、数据有效性都进行严密校验。

双方在交互时也应该进行频率控制,异步处理,对每一个交互进行结果校验,不能预设对方正确处理,必须获取交易回执和处理结果进行确认。

当认为只和一个节点通信并不能保证安全时,客户端可以采用“f+1查询”的思路,尽可能多地和几个节点通信。如果当前链的共识安全模型是“3f+1”,那么,如果从f+1个节点读到的信息是一致的,结果是可以确认的。

3 不信任区块高度

区块高度是一个非常关键的信息,代表整个链当前的状态。向区块链发送交易、节点间进行共识、对区块和状态的校验等操作都会依赖区块高度。

某个节点在断网或处理速度缓慢时,其区块高度有可能落后于整个链,又或者某个节点恶意伪造数据时,其高度又可能超过整个链。在链出现分叉时,如某一个分叉上的区块高度被另一个分叉超越,落后的分叉就会变得毫无意义。即使在正常的情况下,节点依旧有可能间歇性地落后于整个链一到几个区块,然后在一定时间内才可能追上最新高度。

如在PBFT共识模型里,总数2/3以上节点在同一个高度时,全链就有机会达成共识继续出块。余下的1/3的节点有可能和参与共识的节点高度不同,这时意味着从这个节点读取到的数据,并不是全网最新的数据,只能代表链在该高度时的一个快照。

业务逻辑可以把区块高度做为一个参考值,基于高度做一些判定逻辑,在确定性共识(如PBFT)的链上,采用f+1查询等方法确认链的最新高度,在可能分叉的链上,需要参考“6个区块确认”的逻辑,审慎选取可信的区块高度。

4 不信任交易数据

交易(Transaction)代表一方向另一方发起了一个事务请求,交易可能导致资产的转移、改变帐户状态或系统配置,区块链系统通过共识后确认交易,使相关的事务生效。

交易必须带上发送者的数字签名,交易里所有数据字段都必须包含在签名里,未经签名的字段存在被伪造的可能,不予采信。

交易数据在网络上广播时,可以被其他人读取,如交易数据里包含隐私数据,发送者则必须对数据进行脱敏或加密保护。

交易可能因为网络原因被重发,或者被其他人保存下来刻意再次发送,造成交易的“重放”,所以区块链系统必须对交易进行防重,避免出现“双花”。

5 不信任状态数据

区块链的状态(State)数据是由智能合约运行后生成的,理想情况下,每个节点的合约引擎一致、输入一致、规则一致,那么输出的状态就应该一致。但不同的节点可能安装了不同的软件版本,或者合约引擎的沙盒机制不够严密引入了不确定性因素,甚至被侵入、篡改,或者存在其他莫名其妙的bug,都可能导致合约运行输出结果不一致,那么一致性和事务性就无法得到保障。

状态的校验是成本很高的事情,典型的校验方法是使用MPT(Merkle Patricia Tree)树,把所有状态都塞到树里管理起来。MPT树可以把所有的状态归结为一个Merkleroot Hash,节点之间在共识过程中确认交易运行后生成的状态树Merkleroot,确保状态一致。

这棵树结构复杂,数据量大,消耗不少的计算和存储资源,很容易就成为了性能瓶颈。所以对状态的校验需要有更快、更简单,且又稳妥的方案,如结合版本验证、增量Hash验证等算法,辅以数据缓存,可减少重复计算和优化IO次数,能在保证一致性、正确性的同时,有效地提升验证效率。

6 不信任私钥持有者

采用私钥对交易以及其他关键操作进行签名,再使用公钥验签,是区块链上最基础的验证逻辑。只要私钥被正确使用,这个逻辑是安全的。

但私钥仅仅是一段数据,只依赖私钥则用户是匿名的。在联盟链面对的场景里,需要使用许可型的身份,首先通过KYC、尽调、权威认证等现实世界的验证方式确认身份,然后将身份和公钥绑定并公示,或者结合PKI体系的数字证书发放公私钥,这样私钥对应的身份是可知、可信、可控的。

私钥可能会因丢失、泄漏而被他人盗用,或者因被遗忘导致资产损失。所以在私钥的保存上,需要考虑采用周全的保护方案,如加密存储、TEE环境、密码卡、USBkey、软硬加密机等方案。在私钥的管理上,则需要考虑密钥丢失后如何安全的重置、找回。

加强版的私钥使用思路有几个,比如使用多签、门限签名等方式,每次交易时必须用多个私钥进行签名,私钥可以保管在不同的地方,安全性高,但技术方案和使用体验复杂。

还有一种是交易私钥和管理私钥分离。交易私钥用于管理资产,管理私钥用于管理个人资料,交易私钥可以被管理私钥重置,管理私钥本身则通过门限、分片等算法,分开存储保管,以备重置或找回。

7 不信任其他链

在跨链的场景里,每条链有自己的资产、共识,链之间的安全模型变得非常复杂,比如一条链上的记账者串通造假,或者链出现了分叉、区块高度回滚,这时如果链外的其他模块和链有不够严谨的交互,都会造成数据不一致或资产损失。

如果不同的链采用的还是不一样的平台架构,那么在工程上会更加复杂。

跨链、侧链目前依旧是业界在研究和逐步实现的课题,主要目的是解决链和链之间的通信,进行资产锁定和资产交换,保证整个过程的全局一致性、交易事务性,以及抗欺诈。从A链往B链转移一个资产,必须要确保A链上的资产被锁定或销毁,且B链上一定能增加对应的一笔资产,在双方可能分别出现分叉、回滚的时间窗里,要有机制确保双向的资产安全。

在现有跨链的方案里,存在中继、链间HUB等方式,这些系统的设计本身也要达到高度可信可靠的标准,安全等级应不低于甚至高于所对接的链,同样也应采用多中心、群体共识的体系设计,整体复杂度可算是链的N次方了。

8 不信任网络层

我要推荐
转发到