经常有人问：“如何通过合同实现链上数据的读取权限？ ”这样的问题。
在这种需求的背后，是开发者上传一些数据到链条上，让智能合约进行管理和运算，希望达成业务上的协议，但不希望数据被公开看到，链条上的其他非法参与者读取，信息不会泄露
最直观的实现思路是，在合同代码中写入过滤逻辑，以确定是在满足调用方在白名单中的特定条件后才允许返回数据，还是拒绝。
我们设定一个情况。 有点联盟链，链上的参与者有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区块链，可以验证密码账本，可以用于解决上述点案例的一些隐私问题。
关注微信
