区块链技术总结与架构实战

周围所有想了解区块链的人一上来都会问我们这样的问题:什么是区块链?和比特币是什么关系?到如今,稍微了解区块链技术的人应该可以很容易地回答第二个问题:区块链是比特币的底层账本技术的衍生技术,比特币是目前区块链最成熟的一个应用。但是第一个问题至今仍然很难说清楚。接下来就让我们脱离所有区块链的经济属性,纯粹从技术来探讨看看目前的区块链技术,思考一下区块链技术本质特征,个人也推测一下未来可能的发展情况。

我们知道区块链本身是一个技术系,而非一种具体技术或产品,名词状况有点像云计算或NoSQL,当我们问“什么是云计算”或“什么是NoSQL”时,我们也无法简单的概括出来,我们会首先尝试开始描述这类技术系的特征,因此我们不妨也从区块链的技术特征描述入手。

一、技术特征

区块链衍生于比特币的底层机制,目前涌现的产品包括:以太坊、Fabric、Corda、Ripple等,这些系统总体表现为分布式P2P通信结构,每个节点拥有运算或存储能力,所有节点共同维护一个账本。

系统的明显技术特征表现为:

  1. 存储信息难篡改
  2. 每个节点都拥有完整历史信息
  3. 拜占庭容错一致性
  4. 系统可靠性极高
  5. 系统拥有执行运算能力
  6. 安全的账号体系

想更好理解这些目前表现出的技术特征,我们需要牢记从技术本源出发做思考,否则很容易被各种产品不同设计和宣传的不同特性弄糊涂。区块链技术创造的初衷就是要解决分布式环境下存储可靠性的问题,这里的可靠既指系统的服务时间不能因为节点数的减少而暂停,更重要是指存储信息的真实性。因此,存储信息不能被节点私自篡改,传输拜占庭容错且系统整体一致性都是最基本的要求。

试想下攻破区块链有哪几种方法,然后结合区块链上述六个特性进行对比思考,就能对区块链功能设计有更深刻的理解:

  1. 利用分叉处理弱点直接修改节点系统存储信息(比如伪造某个节点的ip加入然后宣称刚刚出现网络分割现象,应该同步自己的这些信息),由特性1、2防范

  2. 部分节点被停电或关停,由特性2、4防范

  3. 造成区块链网络故障或拦截并伪造信息,由特性3防范

  4. 在区块链上执行恶意逻辑或同步类似病毒信息,由特性1、特性5防范

  5. 攻破区块链的账号体系,直接变成合法修改内部状态,由特性6防范

智能合约一定要在区块链技术之上实现吗?当然不是,传统中心化数据库也可以存储实现智能合约逻辑。但是在分布式环境下,合约有很高的被篡改之类道德风险,抑或被黑客攻击的技术风险,因此才需要使用区块链来存储智能合约,保证逻辑的可靠性,因此合约代码本身发布后也是难篡改的。需要注意这里跟数据一样,难篡改不等于不能修改,只是存储的历史记录不会篡改而已。

二、技术实质

区块链通过设计链式存储结构,每次新信息产生实际需要使用系统中所有历史信息产生的摘要,这样其他节点就可以对新信息的真实性进行验证。

  • 比特币和以太坊依靠椭圆曲线非对称算法完成难篡改特性和拜占庭容错一致性,基本思路是增加作恶代价,保证节点产生新信息困难但是验证简单
  • Fabric则依靠???(谁知道可以回答一下Fabric怎么保证历史信息不被篡改,完成合法性验证)实现难篡改特性,利用PBFT算法保证拜占庭容错一致。

根据上面总结的六个区块链特性,大家可以发现区块链也并没有什么特别的,完全可以把区块链视为一个由多方共同来使用运维的分布式数据库,智能合约类似触发器和存储过程,区别在于:

  1. 区块链不一定要是关系型数据库,现阶段产品更类似一个NoSQL数据库
  2. 这里的分布式仅用于加强系统可用性,每个节点都是完整备份节点,并不用于水平扩展,因此系统存在存储极限,需要其他技术配套解决这个问题而非区块链本身
  3. 系统默认保证节点间的网络通信安全,可以支持类似跨境的互联网环境
  4. 因为多方参与维护运维且节点拥有全量数据,因此账号权限划分需要内置提供相关机制(这点最需要加强,但相信会有解决方案出现)

因此,目前工程使用时可以将区块链视为一个分布式部署的NoSQL数据库解决方案,该方案要求公网通信环境即可,未来运维需要多方参与。

留存疑惑:各种产品如何保证通信信道安全,又如何保证存储历史信息安全,PBFT只能保证通信安全情况下,节点之间接收交易请求顺序一致且内容未在其他节点上被篡改或伪造。

三、如何使用

注意区块链使用的基本:

  1. 区块链和智能合约能实现的,现在IT系统都能实现;
  2. 区块链不保证提升系统性能而是系统架构模式的改变;
  3. 只有链内信息保证信任,外部信息不能保证;
  4. 区块链应用不一定非要数字货币参与

正如上面分析的,目前使用区块链产品就跟使用数据库一样:首先是要设计建立表格,对应区块链就是设计智能合约中的数据结构,确定哪些数据需要记录到区块链上;接着是设计权限和逻辑,对应智能合约中的业务逻辑,保证记录到区块链上数据的正确性与合法性;最后是确定智能合约的访问接口。

作为一名区块链应用架构设计师,可以从下面几个维度去设计架构:

1)区块链或分布式账本技术:根据业务特性,在需要增加“信任”的场景下,选择区块链或分布式账本技术解决方案。

2)身份管理:构建一个弱中心的认证中心,补充目前区块链解决方案在权限和账号认证上面的不足。

3)安全数据访问:存储的数据需要在区块链中全局共享,需考虑数据访问层对安全的要求。

4)链上-链下数据访问:分布式应用程序需要与传统的链下系统进行互操作;在区块链高速发展期,不可避免需要与传统数据库应用系统进行交互。

5)智能合约:通过设计出细粒度运作的独立子链(逻辑/物理),考虑通过多个智能合约满足不同的业务需求。

7)编程接口:需要提供熟悉的API接口方便调用区块链上的智能合约程序。

所以不同领域的区块链应用在智能合约的设计上会稍有不同,需要一些最基础的业务逻辑支撑,比如金融区块链中应该有几个基础合约来解决一些最基础的业务逻辑,包括验证、冻结、仲裁等,特别是仲裁逻辑,可以应用到包括合约升级、节点加入、审计发起、分叉解决等多个业务行为中。

四、未来技术走向

对应数据库的技术走向,一定程度可以预测区块链技术的未来发展。下图是美国提交的区块链架构标准,拥有相当的参考学习价值。

国际区块链架构参考标准

区块链节点保存全量数据,历史信息完全保存做到可追溯,这两个特性的初衷是为加强信息真实性,未来可能会出现部分产品舍弃这个特性。通过引入如RAID编码或erase code等技术来解决保存全量数据的问题,做到一定信息的物理隔离,并方便数据压缩。

对于开发者,智能合约需要具备可移植性,尽可能支持多个不同的区块链平台,降低跨平台移植的工作量。对于合约开发平台,应该提供一个语法规范,让不同的区块链平台支持该开发语言。区块链上数据访问构筑肯定会增强,不排除未来直接暴露SQL支持,从底层到外部合约接口都可能支持SQL。

未来可能会实现跨链服务,即不同区块链间的智能合约数据交互。这个服务使得区块链之间构建了互操作性,在复杂的业务场景下,可以设计出细粒度运作的独立子链(逻辑或物理上的),并通过母-子智能合约满足不同的业务需求,提升了全局“臃肿”账本的灵活度。

参考文章

  1. 困挠我的几个fabric问题咨询
  2. hyperledger fabric PBFT算法简要解析
  3. Blockchain区块链架构设计之六:Fabric 1.0账本设计(1)
  4. 关于美国区块链参考架构设计的思考

Hyperledger Fabric CA设计

1. 需求描述

基于商业安全需求考虑进行设计,需要身份与角色管理相结合(身份管理将商业中的问责制更加明确)交易隐私表现为:交易匿名和交易不可关联。

实现:

  • 向CA注册静态登记证书(ECerts,仅用于身份认证,包含公钥部分,使用方法A:所有人可访问;使用方法B:仅TCA和审计访问,对交易不可见)
  • 登记用户向交易CA获取伪匿名代表的交易证书(TCerts,用于配置交易可见性,可以选择性暴露身份)

0.6简化Tcerts设计使用对称密钥加密来提供交易保密性。

DB多用户及用户权限

0.6 设计

memsrvc服务

1.0 设计

configtx.yaml包含示例区块链网络内角色的定义;/crypto目录包含管理员证书,CA证书,每个角色的私钥和用于签名的证书

部署合约时可以选择背书策略

改名为fabric-ca服务

Open Chain系统设计

OpenChain简介

openchain使用C#开发的分布式总账系统,有比较强的横向扩展能力,并利用比特币的区块链保证不可更改性。

常见问题

  1. openchain是一种区块链吗?
    答:不是,其不使用块这个概念,并直接使用事务链。
  2. openchain是一条侧链吗?
    答:提供了模块将openchain部署为侧链,但并非必要步骤。

部署方法

提供docker方法直接部署openchain的服务器,使用sqlite作为默认存储,运行在.NET Core和.NET Framework上面

系统架构

  1. 事务流
    openchain的服务节点可以分为两种:validator节点、observer节点:前者接收事务并进行验证,只有通过验证的才计入总账(验证规则由管理员配置);后者会下载所有通过验证的事务信息流(形成备份?)
  2. 利用区块链
    即利用公链提交事务形成hash(使用OP_RETURN)
  3. 数据结构
    使用Protocol Buffers进行客户端与服务器之间的编解码操作
  4. 总账结构
    kv结构的有层级的总账
本站总访问量