企业级区块链应用的公有链解决方案.docxVIP

说到区块链的企业级应用，大家首先想到是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的区块链方案在部署和运行时也存在诸多问题。一般很难有多家企业共同开发一款区块链系统，通常由其中一家企业或者某个第三方软件公司提供。因为缺乏相应的知识，相关企业很容易被软件提供商留下后门，这点让区块链不可篡改的特性得不到安全的保障。 介于以上问题，笔者认为，基于共有链（如以太坊）的企业级应用解决方案将是未来的一个方向（至少是个必要的补充）！ ? 设计思路： ? 将企业级区块链应用中，需要用到区块链的地方抽离出来，逻辑上分成应用系统和区块链系统，而用公有链（如以太坊）实现其区块链功能。 这样设计的优点有很多，如： 应用系统、区块链系统分离，最大程度复用原有系统的功能和特性； 利用公有区块链的网络安全强大、不可篡改等特性保证区块链功能； 设计简单、费用极低； 公有链解决企业问题，也将面临很多挑战，主要的挑战有如下几点： 挑