正如大家所了解的那样，银行为了保障安全性和准确性所以非常严谨，在系统开发中经常遵守最小知识原则（迪米特法则，Law of Demeter），也就是一个“类”对于其他“类”知道的越少越好，一个对象应当对其他对象只传递需要的参数，可以简单理解为“只和朋友通信，不和陌生人说话”。
不可否认这确实能增加一定的安全性，但这种低耦合的设计模式的弊端也是显而易见的：过度使用迪米特法则会产生大量的参数中介和传递类，导致系统复杂度增大，让银行系统架构与其人员机构层级一样冗杂。所以银行系统总是被过度设计的，过度设计会将关注点放在架构设计的完美性上，而忽略了实际项目的可维护性和成本。但没有办法，银行业务系统众多，内外部清算、系统间账户也交互频繁，其数据量庞大、规则复杂，稍微不注意就可能酿成大错，所以只能哪怕牺牲一切也需要最大化地保障安全。但是如此复杂的系统真的给银行带来了真正的安全性和完美不出差错的准确性了吗？并不，它完全没有大家想象中的完美，并且也经常出现事故，甚至在内网还常常能看到某监会给的事故通知文件……
在这里大家可能已经想到，利用区块链不就能解决这个痛点吗？一套 PoW 链直接顶银行几十个核心系统。其实区块链技术在银行业的应用已经推广了很多年，虽然各大银行在区块链技术的研发上也投入了很多成本和力度，但通过对《中国金融杂志》发表的《区块链技术在银行业的运用》等文章的研究，目前银行业可能在供应链金融、对公业务以及其他中间业务场景上的确运用了区块链技术并解决了一些难题，但对于业务量巨大、瞬时性要求高的零售业务而言，短时间内，区块链的大规模应用场景仍需要探索。
- 零售业务的客户隐私保护较为关键，虽然数据上链的过程中可将重要信息进行加密，但是会导致其链上交易速度以及数据可用性等得不到保证；
- 目前各大银行的区块链根本无法达到数字货币与现金的丝滑转换，存在时间成本与资金磨损，而零售数据量又超级庞大，目前很多上市银行的零售业务收入占比甚至达到了营业收入的半壁江山，导致目前区块链维护成本非常高；
- 银行自主研发的区块链性能没有经历过完整测试与安全审计，可能存在诸多风险。而实际零售业务场景中，对于交易的事后监督管理模式也很难第一时间识别记账环节的漏洞与核算风险，所以尤其涉及到一些大额存取款、大额转账业务时，各银行支行和业务部门也宁愿让人工而非程序去进行操作与审核。
笔者作为 PermaDAO 的贡献者，DAO 内的激励结算恰好由一个叫 everPay 的实时金融协议来负责其代发薪业务，于是我很想知道 everPay 是否解决了上述几点问题。体验和研究之后，我真的没想到它能成功震撼到我，everPay 仅仅用小小的身躯就能够有超越银行的完美功能实现，其既能在保护用户隐私的情况下实现交易数据永久存储，又能保证交易成本 0 Gas Fee 的情况下还可以满足超高并发，能够实现 TPS 理论上可无限增长。