火币官方网站-比特币投资,区块链技术,数字货币交易平台

火币官方网站

怎么样全方位控制区块链上数据的“读”权限

htth3s://fintech.webank.com/wedh3r/

出处 |  FISCO Bcosh3lay开源社区

常常有人问到一个问题:“如何在合约里达成链上数据的读取权限?”

如此的需要背后,是开发者想把一些数据上链,让智能合约管理和运算,以达成业务上的共识,但又不期望数据公开可见,防止链上其他未授权参与者读取,致使信息泄露。

最直观的达成思路,就是在合约代码里写一段过滤逻辑,判断调用者满足某些条件(如在白名单里)才允许返回数据,不然拒绝。

大家设定一个案例:有一个积分网盟链,链上参与者有Alice、Bob、Carl、Dave等多方与他们的家人,每一个人的积分余额期望设定只有自己和家人可见,其他参与者不可见。

推广客户端通过区块链的应用级接口,发送请求到某个节点,调用智能合约的get办法查Bob的积分,智能合约写了权限控制逻辑,拒绝越权访问。

由于智能合约在每一个节点上的运行逻辑是一致的,因此无论请求发往什么节点,结果都一样。这看着貌似没什么问题,但实质是不是也是这样?

这里先说结论:这是个“治标不治本”的做法,并不可以确保数据不泄露。

目前开始大家要用“多中心、去信赖”的思维重新去审视这个案例。

大家先剖析下:链上数据是如何存储?在那种情况下会被泄露呢?

区块链互联网节点分布在不同参与者的环境里,出于区块链的数据一致性特质,每一个节点都持有一份完整的数据副本。无论这个数据库是LevelDB/RocksDB如此的文件型数据库,还是Mysql如此的关系型数据库,数据都会落到每一个节点的数据库实例里。

也就是说Bob的积分余额,在所有些节点硬盘上都存了一份,在MySQL数据库工具里看,大概这个样子:

假如链上(小概率地)存在某个有点儿区块链技术经验的参与者,暗戳戳地怀揣“恶意”(也就是俗称的拜占庭玩家),他可以用工具打开当地的数据库,直接查看Bob的余额。如此,用合约去预防数据泄露的控制逻辑就会完全被绕过。就这么容易。

另外,区块链的数据不只与合约有关,还和买卖记录密切有关。

在发送买卖的时候,买卖参数会包含一部分或全部数据(如Alice给Bob转账100),买卖会打包进区块,最后也写入节点数据库里。

对区块和买卖数据的查看通常不会用合约逻辑达成,于是,仅仅在合约里写过滤逻辑并没办法预防这部分数据的读取。拜占庭玩家可以在当地数据库里遍历区块数据,获得买卖历史明细,从头到尾回放买卖流水,得知目前Bob的余额是300。

从整个技术栈来看,拜占庭玩家用工具访问当地数据、遍历区块和买卖都算是小意思了,他甚至可以修改区块链系统代码,从区块链互联网接口、程序内存、智能合约引擎等层面切入,从协议包、区块、买卖流水、合约上下文、状况数据等环节嗅探和拦截到明文数据,即便数据落盘是加密的,密钥也在节点持有人手里,他照样能解开。

所以,从区块链底层代码入手去控制读数据的权限,同样也是不管用的,毕竟开源的代码,大家都可以改,俗话说:“坏人会武术,大家都挡不住”,而懂技术的“坏人”更是无所不可以、防不胜防。

总之,区块链强调“推荐”和“一致性”,只须明文数据在链上广播,其他人就有无数种办法去获得。无论是在合约层还是底层代码,几乎所有些读控制逻辑都像窗户纸一捅就破,像马其诺防线一样形同虚设。

看到这里,有人可能会问:读数据这样不设防,那区块链上的“写”权限还有意义吗?回答是:有些。

回到积分这个例子,大家设定Alice是积分管理员,她才能发起转移积分的买卖,然后Bob也只同意Alice给我们的积分。转移积分的买卖需要经过全网共识,所有共识节点会检查合约里写的规则,不符合就拒绝签名,越权买卖没办法得到共识,则数据不会被修改。

这个时候即便有少量的拜占庭节点,无论在当地节点如何折腾,也篡改不了全网数据。

“写”买卖追求共识,所以推广客户端发买卖(sendTransaction或sendRawTransaction)时,要打上数字签名,区块链系统验证签名,确认是什么外部竞价推广账户发过来的买卖,可以进行严格地校验和准确地追溯。

“读”操作更强调共享,读数据的操作其实并不经过共识步骤,在我们的节点翻翻数据就好了。一般区块链系统在读接口(call)并不需要严格填写发送者,也不需要打上数字签名,所以,在合约的读办法里判断外部竞价推广账户,其实是无效的。

综合以上种种剖析,可以得出结论:在链上达成读控制并非容易的事情。

假如对读控制逻辑考虑不足,那样成效将是:你在我们的节点上读一下数据来测试验证,表象看着OK,你以为岁月静好,却不知晓在一个拜占庭玩家那里,数据已经被翻得底朝天了。

考虑到多方协作中的去信赖化,追求数据共享、公开、透明的取向,通常来讲,若是重要的、不可以泄露的敏锐数据,必须要慎重上链,能上链的,肯定是大伙说好可以推荐的“最大公约数”。

事实上不少区块链系统里的买卖和余额等状况都是全网可见的,所谓的匿名性或隐私性,只不过用公私钥和地址体系代替了明文竞价推广账户,这个级别的“匿名”,在业务模型复杂且强调全方位隐私的金融、政务等范围并不适用。

那样大家还有哪些办法,在兼顾共享、透明、开放的同时,适合地控制数据可见性呢?

第一个思路是与链外治理结合,约定责权利边界。我在合约、接口层面做好权限设计和达成,保证在我的业务系统里不泄露数据,我的区块链应用层、展示界面、报表、日志、数据库等环节都不会被越权访问,消除我内部操作风险。

至于其他人的节点,我管不着,那是他们的责任,哪个泄露滥用数据,就重罚哪个(取证、举证其实挺难的)。这种逻辑其实有点“各扫门前雪”的意思,在这种模式下,我的敏锐数据还是不可以上链给到其他人。

第二个思路是引入密码学。这里举几个例子。

非对称加密:上链的数据用同意方的公钥加密,则只有接收适才可以用我们的私钥解开。

密码信封:上链数据使用某个口令加密,口令通过链外信道给到接收方,只有知晓口令的接收适才能解密。

属性加密:数据使用属性加密算法进行加密,符合指定属性(如拥有管理员属性)的才能解密。这部分策略的考量在于运算、传输、存储的开销都会大一点,另外加密的数据不支持明文运算,难以达成复杂的业务合约逻辑。还应该注意的是,即便加了密,本质上数据的全部信息还是都上链了,伴随时间推移,计算能力和算法(如量子密码)的进化,存在被暴力破解的可能性,或者由于密钥泄露/太容易被猜到,链上的数据又没办法撤回,就有被昭告天下的风险。

第三个思路是仅摘要上链,数据明文根本就不上链。

其实,区块链有哪些用途并可能不是全方位学会数据和实行复杂的业务规则,而是凭着多方见证的公信力,验证数据的准确性、完整性,并起到存证和追溯有哪些用途,事实上现阶段不少区块链系统主如果这么个逻辑,客观上已经能起到信赖的锚点用途。

假如需要明文数据,再通过摘要里的寻址信息去链外系统获得数据,在这个环节上做精细的权限控制,并和链上摘要进行互验。

但,数据不上链还是有点不甘心呀,区块链这么革新的理念,智能合约这么强大的功能,如何充分发挥呢?

这就要讲到隐私计算了,包括但不限于零常识证明、同态加密、安全多方计算、联邦学习等一系列重武器,可以做到隐秘数据、身份的同时,对加密数据进行加减乘除运算、逻辑运算、排序、统计剖析,更进一步还可以做到“前台匿名,后台可审计”的成效,以符合监管合规需要。这就是在区块链上达成“可用不可见”的最后奥义。

限于篇幅,这里不展开隐私计算的细则,可以参考WeDPR隐私保护有关的开源场景策略,特别是其中的几个场景,如VCL区块链可验证密文账本,可以用于解决前面提到的积分案例里的一些隐私问题。

WeDPR隐私保护有关开源场景策略:

结语

本来只不过想聊聊“如何写合约读权限”如此一个小问题,结果变成了长篇。

其实面对区块链编程和开发时,真的不可以像写单机或集群软件那样考虑问题,而要充分考量多方参与、去信赖环境下的协作关系,在共享、透明、可追溯的基本哲学之上,关注隐私保护诉求,掂量数据的重要程度和敏锐性,再深入到技术栈,考虑各种算法的效果和本钱、综合目前和将来的风险和收益以选择适合方案,如此才能全方位保护数据和隐私,安全地进步业务,维护自己和用户权益。

VCL区块链可验证密文账本:

https://sandbox.webank.com/wedpr/confidentialpayment/#/start

查询更多

我们的缺点麻烦您能提出,谢谢支持!