经常有人问:“如何通过合同实现链上数据的读取权限? ”这样的问题。
在这种需求的背后,是开发者上传一些数据到链条上,让智能合约进行管理和运算,希望达成业务上的协议,但不希望数据被公开看到,链条上的其他非法参与者读取,信息不会泄露
最直观的实现思路是,在合同代码中写入过滤逻辑,以确定是在满足调用方在白名单中的特定条件后才允许返回数据,还是拒绝。
我们设定一个情况。 有点联盟链,链上的参与者有Alice、Bob、Carl、Dave等多人及其家人。 我们希望每个人的积分余额只允许自己和家人看到,其他参与者看不到。
客户端通过区块链的APP级接口向某个节点发送请求,调用智能合约的get方法来研究Bob的点。 智能合约写权限控制逻辑,拒绝越权访问。
由于智能合约在每个节点上一致工作,所以无论请求发送到哪个节点,结果都是相同的。 这看起来没问题,实际上也是吗?
在这里说结论,这是“治标不治本”的做法,不能不泄露数据。
从现在开始我们将以“多中心,信任”的想法重新审视这个案例。
让我先分析一下。 链上的数据是如何存储的? 什么情况下会泄露?
区块链网络节点分散在不同参与者的环境中,由于区块链的数据完整性特性,每个节点都有完整的数据拷贝。 无论该数据库是文件类型数据库(如LevelDB/RocksDB )还是关系数据库(如Mysql ),数据都会落在每个节点的数据库实例中。
也就是说,Bob的积分余额在所有节点硬盘中保存一份。 用MySQL数据库工具来看,大致是这样的。
如果链中存在对“恶意”(所谓的拜占庭玩家)抱有区块链知识的参与者“以很少的概率”,他可以使用工具打开本地数据库,直接调查Bob的余额这样就完全绕过了合同中防止数据泄露的控制逻辑。 这么简单。
另外,区块链的数据不仅与合同有关,还与交易记录密切相关。
在提交事务处理时,事务处理参数包含部分或全部数据(如Alice向Bob汇款100次),然后将事务处理打包成块,最终写入节点数据库。
区块和交易数据的查询通常不能通过合同逻辑实现。 因此,只在合同中写入过滤逻辑并不能防止读取这些数据。 拜占庭玩家可以在本地数据库中遍历块数据,获取交易历史的详细信息,从头到尾播放交易流程,从而知道当前Bob的余额为300。
从整个技术栈来看,签证玩家通过工具访问本地数据,然后拦截和交易是小事。 他修改了区块链系统代码,从区块链网络接口、程序存储器、智能合约引擎等层面切入,从协议包、区块、交易流水、合同上下文、 即使数据被加密了,密钥也在节点持有人手里,他同样可以解开。
因此,控制从区块链底层代码读取数据的权限也同样没有用。 毕竟,开源代码,谁都可以改变。 俗话说:“坏人会武术。 虽然有人说“谁也阻止不了”,但知道技术的“坏人”什么都能做,防不胜防。
总之,区块链强调“共享”和“一致性”,只要明文数据在链上广播,其他人就会通过无数途径获取。 无论是合同层还是底层代码,大部分的读取控制逻辑在窗边的纸一扎就破,形状像马奇诺诺线一样。
看到这里,可能会有人问,明明读取数据这么无防备,区块链上的“写”权限还有意义吗? 是的,有。
让我们回到重点的例子。 设定Alice为积分管理员,她可以开始移动积分的交易。 而且,Bob也只接受Alice给自己的积分。 移动积分的交易必须经过全网的协商,所有的协商节点都要检查合同上写的规则,如果不一致就拒绝签名,如果越权交易不能达成协商,数据就不会被修改。
在这种情况下,即使只有少量的拜占庭节点,无论本地节点多么辛苦,也无法篡改整个网络的数据。
因为“写”交易是为了追求共识,所以如果客户端发来交易(sendTransaction或sendRawTransaction ),会进行数字签名,区块链系统会验证签名,然后从哪个外部账户发送。
“阅读”操作更强调共享,阅读数据的操作其实不经过共识过程,在自己的节点上翻数据就可以了。 由于区块链系统通常不需要在读取接口(call )中严格填写发送者或进行数字签名,因此通过合同的读取方法来判断外部账户实际上是无效的。
综合以上各种分析,可以得出结论,在链条上实现领先控制并不是一件简单的事。
如果没有充分考虑读控制的逻辑,效果就是在自己的节点上读取数据并测试验证。 表象看起来很好。 虽然觉得岁月静好,但不知道数据在拜占庭玩家那里翻了。
考虑到多边合作中的去信任化,如果追求数据共享、公开、透明的方向,一般来说,只要是重要的、不可泄露的机密数据,就必须小心走上链条。 能上链条的,一定是大家都说可以共享的“最大公约数”。
事实上,很多区块链系统中的交易、余额等状态在网络上随处可见。 所谓匿名性和隐私性,只是用公开密钥和地址体系代替了明文账户。 这一级别的“匿名”不适用于商业模式复杂、强调全面隐私的金融、政务等领域。
那么,在兼顾共享、透明度和开放性的同时,如何正确控制数据的可视性呢?
第一种想法是结合连锁治理,约定责任权利的边界。 我在合同、接口层面做好权限设计和实现工作,确保我的业务系统中数据不被泄露,我的区块链APP层、展示接口、报告、日志、数据库等环节不被越权访问。
关于别人的节点,我管不了。 那是他们的责任,如果有人滥用了数据,就会惩罚谁(取证、举证其实很难)。 这个逻辑其实有“扫门前的雪”的意思。 在这种模式下,我的机密数据还是不能链接到别人。
第二种观点是引入密码学。 让我在这里举几个例子。
非对称加密:如果用接收者的公钥加密上行链路数据,则只有接收者能用自己的私钥解密。
信封:链上的数据用某个密码加密,密码通过链外通道给接收者,只有知道密码的接收者才能解密。
属性加密:使用属性加密算法加密数据,并且仅当数据与指定属性(如具有管理员属性)匹配时才进行解密。 这些情况的考虑因素是运算、传输和存储开销稍大,加上加密数据不支持明文运算,难以实现复杂的业务合同逻辑。 另外,请注意,即使添加了密码,数据中的所有信息本质上都是链上的。 随着时间的推移,计算能力和算法(量子密码等)会不断发展,有可能被暴力破解,或者密钥泄露/过于简单被推测,链上的数据无法撤回,因此有被世界举报的风险。
第三种想法是只有摘要连锁,数据没有明文连锁。
其实,区块链的作用并不一定是全面掌握数据,执行复杂的业务规则,而是依靠很多人亲眼看到的公信力,验证数据的正确性、完整性,保存和跟踪证据。 事实上,现阶段很多区块链系统主要是这样的逻辑,作为客观可靠的锚点起着作用。
需要明文数据时,通过摘要内的地址信息向链外的系统获取数据,在这个阶段进行精细的权限控制,与链上的摘要进行相互验证。
但是,数据没有放在链条上,有点不甘心啊。 区块链这样的创新理念,智能合约这样的强大功能,如何充分发挥呢?
这必须论述隐私计算。 包括但不限于知识零证明、准同态加密、安全多方计算、联邦学习等一系列重型武器。 在实现保密数据、身份的同时,对加密数据进行加减乘除运算、逻辑运算、排序、统计分析,进而实现“前台匿名、后台查实”的效果,满足监管合规的要求。 这是用区块链实现“可用的和看不见的”的最终奥秘。
仅限于篇幅,这里不展开隐私计算的详细内容。 请参考与WeDPR隐私保护相关的开源场景方案。 特别地,其中的一些场景,例如VCL区块链,可以验证密码账本,可以用于解决上述点案例的一些隐私问题。