加入收藏 | 设为首页 | 会员中心 | 我要投稿 新余站长网 (https://www.0790zz.com/)- 科技、建站、经验、云计算、5G、大数据,站长网!
当前位置: 首页 > 站长资讯 > 传媒 > 正文

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

发布时间:2019-07-26 02:30:00 所属栏目:传媒 来源:张开翔
导读:大家好,我是张开翔。 上一篇分享了信任区块链时究竟在信任什么?,这次换个角度,漫步月之暗面,谈谈在区块链系统和业务设计时,不信任什么。 先讲结论: 几乎什么都不能信! 建立Don't Trust,Just Verify的理念,才是通往区块链世界的正确态度。 By我随口

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

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

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

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

7 不信任其他链

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

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

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

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

8 不信任网络层

区块链节点需要和其他节点发生通信,所以必须在网络上暴露自己的通信端口,如果通过公网通信,那么相当于在公网上暴露了自己,很容易遭到类似渗透、DDOS这样的网络攻击。节点必须在网络层保护自己,包括在网关上设置IP黑白名单、设置端口策略、进行DDOS流量防护,且对网络流量、网络状态进行监测,如果突发网络流量或连接数暴增,说不定,就是被人当肉鸡或者正在脱库进行时了。

非必要端口,切忌对公网开放,如用于做管理监控的RPC端口,只能对机构内部开放,在进行网络策略设定之前,一定要慎之又慎。

9 不信任代码

“Code is law”确实是一句响亮的口号,但是在程序员头发掉光之前,他写的代码都可能有bug,只是看写bug快还是修bug快而已。

无论是底层的代码还是智能合约代码,都可能存在技术性或逻辑性的坑,但凡代码产生的数据和指令行为,都需要另一段代码对其进行严格地校验,代码本身也需要进行静态和动态扫描,包括采用形式化证明等技术进行全面地审核验证,以检测可能的逻辑错误、安全漏洞或是否有信息泄露。前段时间有一份公布到github上的某酒店系统的代码,居然包括了mysql的连接用户名密码,且数据库端口居然是向公网开放的,这种坑简直不可想象。

开放出去的开源代码,固然可以被人审查、反馈以提升安全性,也可能被人翻找漏洞、随意修改,甚至恶意埋雷。但总的来说,开源还是利大于弊。在开源社区中,开发者会向项目提交PR(Pull Request)。审核PR是很关键也很繁重的工作,值得安排专家并分配大量时间去做审核。有开源项目的老司机透露,其项目核心模块的PR的审核时间长达经年,否则“加了个功能引入两个bug”那真是得不偿失,更别说如果被植入漏洞埋雷了。

10 不信任记账者

共识的流程大致可以抽象为,选出记账者,记账者发布区块,其他节点校验和确认。公链里记账可以用“挖矿”的方式进行(如比特币),矿工用大量的算力代价为它自己的诚信背书,又或者是用大量的资产权益抵押获得记账权(Pos和DPos等共识)。在联盟链常用的PBFT/Raft等算法里,记账者列表可以是随机或轮换产生,记账者给出提案,其他投票人多步提交,收集投票。按少数服从多数的原则,一般是2/3以上共识节点同意,共识才能达成。

从系统可用性角度看,记账者有可能出错、崩溃,或者运行缓慢,影响整个链的出块。又或者记账者可以只收录手续费高的交易,抛弃一些交易,导致有些交易总是不能达成。有的记账者还可以凭借算力或暗箱运作,进行“预挖”或者“扣块攻击”,破坏博弈关系……

记账者故障或作恶,超越了共识的安全阈值的话,将直接伤害整条链的价值基础。根据不同的记账模式,记账者需要设计不同的容错、校验、抗欺诈算法,执行激励和惩罚机制,在运行过程中定期检查记账者的健康度,对于无力记账或者作恶的记账节点,全网不接受他们的记账结果,并对其进行惩戒,甚至是踢出网络。

……

罗列起来还有很多,包括合约、证书、同步等等,每一个模块都有自己的功用和风险点,简直罄竹难书。总之,区块链做为分布式的多方协作的体系,接入了形形色色参与者,整个体系绝不是单个开发者或运营者所能单点把控,“善意推测”在这个领域已经不尽适用,整个世界步步惊心,处处冷箭,只能通过周密的算法和繁杂的流程维系共识和安全,简而言之,没有经过验证的信息,一个字节都不能相信。

比起单一环境里的软件设计,区块链领域的设计思路确实存在颠覆性,开发者要从“做功能,只容错,不防骗”的思维模式里跳出来,带着“怀疑一切”的态度进行设计。

开发者在面向区块链领域时,不能只是思考怎么实现一个功能,而更要去思考整个流程会不会有出错,会不会被人篡改数据、发掘漏洞、攻击系统、欺诈其他参与者。要换位思考自己所实现的功能,会被别人用什么方式使用,在不同的环境会有什么表现,可能造成什么后果。任何收到的信息,任何流程输入、输出,都必须经过严格地校验才能采信,开发者能做到这一点,才算是打开了区块链新世界的大门,才能在连续剧里至少活到第二集。

(编辑:新余站长网)

【声明】本站内容均来自网络,其相关言论仅代表作者个人观点,不代表本站立场。若无意侵犯到您的权利,请及时与联系站长删除相关内容!

热点阅读