区块链 数据读权限 设计方案
Posted 软件工程小施同学
tags:
篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了区块链 数据读权限 设计方案相关的知识,希望对你有一定的参考价值。
那么我们还有什么方法,在兼顾共享、透明、开放的同时,适当地控制数据可见性呢?
第一个思路是与链外治理结合,约定责权利边界。
我在合约、接口层面做好权限设计和实现,保证在我的业务系统里不泄露数据,我的区块链应用层、展示界面、报表、日志、数据库等环节都不会被越权访问,消除我内部操作风险。
至于别人的节点,我管不着,那是他们的责任,谁泄露滥用数据,就重罚谁(取证、举证其实挺难的)。这种逻辑其实有点“各扫门前雪”的意思,在这种模式下,我的敏感数据还是不能上链给到别人。
第二个思路是引入密码学。这里举几个例子。
非对称加密:上链的数据用接受方的公钥加密,则只有接收方才能用自己的私钥解开。
密码信封:上链数据采用某个口令加密,口令通过链外信道给到接收方,只有知道口令的接收方才能解密。
属性加密:数据采用属性加密算法进行加密,符合指定属性(如具备管理员属性)的才能解密。这些方案的考量在于运算、传输、存储的开销都会大一点,另外加密的数据不支持明文运算,难以实现复杂的业务合约逻辑。还要注意的是,即使加了密,本质上数据的全部信息还是都上链了,随着时间推移,计算能力和算法(如量子密码)的进化,存在被暴力破解的可能性,或者因为密钥泄露/太简单被猜到,链上的数据又无法撤回,就有被昭告天下的风险。
第三个思路是仅摘要上链,数据明文根本就不上链。
其实,区块链的作用并不一定是全面掌握数据和执行复杂的业务规则,而是凭借多方见证的公信力,验证数据的准确性、完整性,并起到存证和追溯的作用,事实上现阶段很多区块链系统主要是这么个逻辑,客观上已经能起到信任的锚点作用。
如果需要明文数据,再通过摘要里的寻址信息去链外系统获取数据,在这个环节上做精细的权限控制,并和链上摘要进行互验。
第四 隐私计算
以上是关于区块链 数据读权限 设计方案的主要内容,如果未能解决你的问题,请参考以下文章