大道至简

本人渣硕期间主攻机器学习和区块链，目前这两方面只能说自己略懂。机器学习很多时间都会花在特征工程上，也许就是一个简单的模型也可以调出很漂亮的ROC，也许，这就是大道至简吧，无招胜有招，一气化三清。好吧，小说看多了，讲正题。
在之前和一公司合作开发了一款基于Ethereum的Dapp，具体是哪一个不方便透露，但是其中的技术逻辑和商业逻辑的结合的确让我走了不少的弯路，最主要的是其中对于代币或代币化标的的确权问题，其实这并不是真正完全去中心化的，很简单你一定会有一个模板库或者就是用户信息的匹配库吧，这一部分当然也可以用IPFS，但一个应用需要让你用两种代币，会不会让你觉得有点狗尾续貂（这个词今天听见了，贴切）！
其次，关于IBM支撑的Fabric这个项目，我一度觉得这个东西才是工业界真正能用上的，应该是和其它的妖艳贱货不一样。但是，在实际操作过程中，总觉得哪里不舒服，也不是说交易速度的问题，这个技术逻辑再看完区块链的大量文献后的感觉是，的确做到了分类账，弱中心化，较高频交易。但是在实际开发中发现，这个架构方案简直就是一顿传销般的操作啊，让你陷入其中还深感牛逼，其实还不如EOS，终于，一朝顿悟。以下是恰好看到的一篇网上关于fabric的吐槽文章。

---

说到区块链的企业级应用，大家首先想到是IBM主导的hyperledger fabric项目和有微软、intel、摩根等大企业参与的企业以太坊（Enterprise Ethererum）项目。企业以太坊联盟刚刚成立，其产品发布还有待时日。hyperledger fabric 1.0 alpha则已经发布。我有幸参与了国内最早一批应用hyperledger进行企业级区块链的设计和开发。不幸的是，我觉得它不好，非常的不好。我们似乎走在了一条错误的道路上，fabric的设计者也似乎走在了一条错误的道路上。

问题一：不区分应用系统和区块链系统
fabric的设计没有区分应用系统和区块链系统。fabric试图在引导大家将应用系统区块链化，将原先可简单解决的问题复杂化。例如一个供应链系统，我们称之为应用系统，它已经存在，在区块链技术被应用之前已经大规模存在。我们现在来改造它，或者重新设计，让其具有区块链的特性。fabric给我们的方案会引导我们将大部分业务逻辑放进chaincode，使得整个系统变成一个区块链系统。这是非常错误的，原因有三：区块链的运行效率很低；区块链的存储消耗高，查询效果很差（尽管fabric 1.0支持结构化查询，如：CouchDB，但相比传统的，如：mysql，其效率低一个数量级）；系统过于复杂，且没有必要。

问题二：endorsement的设计似是而非
fabric 1.0的endorsement policy的设计只在理论上工作，实际情况下运行效果很差。例如，一个供应链区块链系统涉及到3家企业，我们分别部署1个peer（同时是endorse peer和commit peer）在各自的机房（或云系统），我们的policy定义为必须同时获得这3个peer的endorsement。当一个交易发生时，我们的请求需要通过网络穿越公网进入各自的机房（或云系统），然后和各个peer进行交互，获取endorsement。而这其中的延迟非常不确定，可能很大，会导致各种交易失败的情况发生。

问题三：channel的设计让人又爱又恨
fabric 1.0中的channel设计似乎是一个很棒的功能，可以让不同企业间的商业隐私得到极大的保护。但是它却是不完整的，或者很难使用的。因为不同channel间不能交互，很多数据需要在多个不同的channel间共享，我们要么将冗余数据写入不同的channel，要么将系统设计成颗粒度很细，让不同的peer加入到多个channel中。无论何种方式都是在将简单问题复杂化。让系统变成更加复杂，和更加容易出错。

问题四：用docker执行chaincode设计粗糙
没有像以太坊里设计有EVM，而只是用docker来执行chaincode，其设计相当粗糙，而且会有很多运行过程中发生的问题。这点非常易于理解，不用多说。
以上说得都是fabric设计中的问题，那么如果用enteth会不会就没有问题了呢？企业级以太坊（enteth）会很大程度上解决以上的问题。但是并不全部，而且不能解决的是一个核心问题：我们为什么要用区块链？

区块链唯一的作用，是为了解决信任问题。提供一个防篡改、无抵赖、公开透明（这点在企业应用中不一定适用）的交易和商业环境。

在我们的供应链例子中涉及到三家企业A、B、C。不管是fabric的方案还是enteth的方案，只能在ABC之间保证数据一致性。但是现在A篡改了数据，BC因为手上有所有数据的副本，可以轻松地证明A的篡改行为。这时A请来了黑客，攻入了BC系统，将BC系统里的数据副本也一并篡改。攻入BC系统的难度远远小于劫持公有链中（如以太坊）51%的算力的难度。

实际上，在现实的商业环境中，很多系统都是由强一方提供，如A，帮助BC部署其区块链系统。在这样的环境中区块链的防篡改特性难以生效。
另外，基于fabric或enteth的区块链方案在部署和运行时也存在诸多问题。一般很难有多家企业共同开发一款区块链系统，通常由其中一家企业或者某个第三方软件公司提供。因为缺乏相应的知识，相关企业很容易被软件提供商留下后门，这点让区块链不可篡改的特性得不到安全的保障。

介于以上问题，笔者认为，基于公有链（如以太坊）的企业级应用解决方案将是未来的一个方向（至少是个必要的补充）！

设计思路：
将企业级区块链应用中，需要用到区块链的地方抽离出来，逻辑上分成应用系统和区块链系统，而用公有链（如以太坊）实现其区块链功能。
这样设计的优点有很多，如：
应用系统、区块链系统分离，最大程度复用原有系统的功能和特性；利用公有区块链的网络安全强大、不可篡改等特性保证区块链功能；设计简单、费用极低；

公有链解决企业问题，也将面临很多挑战，主要挑战有如下几点：
挑战一：企业级应用的隐私问题
企业级应用涉及到商业、用户数据，系统需要大量的保密安全措施，不可公开泄漏到网络上，解决这一问题有2个可选方案：加密，只将加密数据存在在公有网络上；两级分离，只将头部信息，数据hash值存储在公有网络上，将真实数据存储在安全的企业环境中。

挑战二：公有链网络费用的问题
使用公有网络，如以太坊存储企业区块链，将面临着较高的网络费用，尤其涉及到大量存储时。解决的方案有2个：只存储企业区块链的头部信息（类似于比特币的SPV），将区块内容放在非常便宜的企业数据环境中；剪裁功能，对于历史无用数据可以实施备份存储和剪裁。
下面笔者给出的两个方案建议：
方案一：基于以太坊的企业应用解决方案
在以太坊智能合约中维护企业区块链的头部信息； -〉网络安全、防篡改
企业区块链区块内容放在二级存储（安全的企业存储环境中）；-〉企业信息隐私保护，省钱
对于历史头信息进行剪裁；-〉省钱
关联以太坊地址和企业身份；-〉不可抵赖
方案二：基于字节雪球（byteball）的企业应用解决方案
用字节雪球的存储功能，形成企业区块链；-〉网络安全、防篡改；
对于敏感信息加密存储，安全级别较高的放在二级存储；-〉隐私保护；
关联雪球地址和企业身份；-〉不可抵赖
雪球费用相对较低，存储空间大，未来将是以太坊方案的一个很好补充，也可和以太坊方案结合使用；

---

巴比特论坛原文章