区块链要去中心化么
区块链（Blockchain）技术自身仍然在飞速发展中，目前还缺乏统一的规范和标准。Wikipedia 给出的定义为：
A blockchain—originally, block chain —is a distributeddatabase that maintains acontinuously-growing list of data records hardenedagainst tampering andrevision. It consists of data structure blocks—which hold exclusively data ininitial blockchain implementations,and both data and programs in some of themore recent implementations—with each block holding batches of individualtransactions and theresults of any blockchain executables. Each block containsa timestamp andinformation linking it to a previous block.
简而言之，区块链技术让参与系统中的任意多个节点，把一段时间系统内全部信息交流的数据，通过密码学算法计算和记录到一个数据块（block），并且生成该数据块的指纹用于链接（chain）下个数据块和校验，系统所有参与节点来共同认定记录是否为真。
1. 区块链本质
区块链实质是由多方参与共同维护一个持续增长的分布式数据库，也被称为分布式共享账本（Distributed Shared Ledger），其核心在于通过分布式网络、时序不可篡改的密码学账本及分布式共识机制建立彼此之间的信任关系，利用由自动化脚本代码组成的智能合约来编程和操作数据，最终实现由信息互联向价值互联的进化，如图1所示。
图1 从传统集中记账方式（左）到分布式总账（右）
区块链是一种与传统集中记账方式不同的记录技术。参与到区块链系统上的节点，可能不属于同一组织、彼此无需信任；区块链数据由所有节点共同维护，每个参与维护节点都能复制获得一份完整记录的拷贝。与传统的记账技术相比，其特点包括：维护一条不断增长的链，只可能添加记录，而发生过的记录都不可篡改；无需集中的控制而能达成共识，实现上尽量分布式；通过密码学的机制来确保交易无法抵赖和破坏，并尽量保护用户信息和记录的隐私性。
2. 区块链工作原理
所谓区块链，正是由一个个区块组成的链状数据结构及存储方式。每个区块分为区块头和区块体，区块头主要用来实现区块链接的前一区块哈希散列值（Hash Value），而区块体主要包括交易账本，如图2所示。
图2 区块链的账本
以交易场景为例，区块链工作原理如下：首先客户端将发起的一笔交易经数字签名后广播给网络上其他节点并等待确认；网络中的节点对收到的数据记录信息进行校验，通过校验后，数据记录被记录到一个区块中；全网所有接收节点对区块执行共识算法，区块通过共识算法过程后被正式纳入区块链中存储，全网节点均表示接受该区块。而表示接受的方法，就是将该区块的随机散列值视为最新的区块散列值，新区块将提供永久和透明的交易记录并以该区块链为基础进行延长，实现资金转移。
3. 区块链技术特点
具体来说，区块链技术作为创造信任的机器，主要有以下特点：
分布式结构。区块链构建在分布式网络基础之上，账本并不是集中存放在某个服务器或数据中心，也不是由第三方权威机构来负责记录和管理，而是分散在网络中的每一个节点，每一节点都有一个该账本的副本，所有副本同步更新。
信任机制。区块链技术通过数学原理和程序算法，使系统运作规则公开透明，实现交易双方在不需要借助第三方权威机构信用背书下通过达成共识建立信任关系。
公开透明。区块链对其上的节点可以做到开放、透明。任何人都可以加入区块链，也能查询区块链上的区块记录；同时所有用户看到的是同一个账本，能看到这一账本所发生和记录的每一笔交易。
时序且不可篡改。区块链采用带有时间戳的链式区块结构存储数据，具有极强的可追溯性和可验证性；同时由密码学算法和共识机制保证了区块链的不可篡改性。
4. 区块链层次模型
区块链技术的模型是由自下而上的数据层、网络层、共识层、激励层、合约层和应用层组成，共有六层。
数据层、网络层、共识层这三层是区块链的必要元素。
1）数据层：最下层是“数据层”，封装了底层数据区块的链式结构，以及相关的非对称公私钥数据加密技术和时间戳等技术，这是整个区块链技术中最底层的数据结构。
2）网络层：中间是网络层，包括P2P组网机制、数据传播机制和数据验证机制等。
3）共识层：第三层是共识层，封装了网络节点的各类共识机制算法。
而激励层、合约层和应用层不是区块链的必要元素，一些区块链应用并不完整地包含上面三层结构。
第四层是“激励层”，将经济因素集成到区块链技术体系中来，包括经济激励的发行机制和分配机制等，主要出现在公有链当中。
第五层是“合约层”，封装各类脚本、算法和智能合约。
第六层是“应用层”，封装了区块链的各种应用场景和案例，未来的可编程金融和可编程社会也将搭建在应用层。
在区块链加密技术出现之前，互联网上的信息拷贝起来是零成本的，数字资产具有无限可复制性，如果没有可信赖的第三方监督，我们根本无法确认一笔数字现金是否被花掉，因此可能出现重复支付问题。
为了解决这个问题，区块链参照了“拜占庭将军问题（Byzantine failures）”[5]的算法。该问题是一个协议问题，指拜占庭帝国军队的将军们必须全体一致的决定是否攻击某一支敌军。问题是这些将军在地理上是分隔开来的，并且将军中存在叛徒，而将军们只能依靠信使来传递信息。如何才能防止受到叛徒欺骗而做出错误决策呢？数学家设计的算法是让将军在接到其上一位将军标有进攻时间的信件之后，写上同意或反对并盖上的自己的图章，然后把信转发给其他所有的将军，在这样的信息周转之后，最后会出现一个盖有超过半数将军图章的信息链，以保证将军们在互不信任的情况下达成共识。
莱斯利·兰伯特把拜占庭将军问题引入点对点通信。拜占庭假设是对现实世界的模型化，由于硬件错误、网络拥塞或断开以及遭到恶意攻击，计算机和网络可能出现不可预料的行为。拜占庭容错协议必须处理这些失效，并且这些协议还要满足所要解决的问题要求的规范。
区块链的技术原理参考了拜占庭将军问题的算法，通过盖戳的形式来进行公证。网络上的每一个参与者的电脑都会有一份总账的备份，也都能在这本总帐里记上一笔，并且所有的备份都是在实时的、持续的进行更新、对账、以及同步着拷贝，即全网记账，每个节点都可以来竞争盖戳，互相认证。这使得一个不可信网络变成了一个可信的网络，使得所有参与者可以在某些事情上达成一致。
5. 区块链并不一定去中心化
理想化的区块链系统，是由许许多多节点组成的点与点的网络结构，似乎既不需要中心化的硬件设备，也不需要任何管理它的机构。在很多文献中都提出区块链是去中心化的（Decentralized），即整个网络没有中心化的硬件或者管理机构，任意节点之间的权利和义务都是均等的，且任一节点的损坏或者失去都会不影响整个系统的运作。
需要指出的是，区块链并不一定是去中心化的。实际上，软件系统的网络架构一般有三种模式：单中心、多中心、分布式，Decentralized只表明不是单中心模式，它可能是多中心或弱中心，也可能是分布式的。把Decentralized翻译成“去中心化的”可能与最早由国内“币圈”所做出的翻译偏差有关，实际上在中国台湾地区，大多译为“分散式的”而不是“去中心化的”。因此，把Decentralized翻译成“分布式”或者“多中心化”，可能更切合今天技术和金融场景应用的实际。
在人类社会的历史上，信息传播的延迟和谬误导致信息不对称，形成了各种中心化的强权组织和阶级分化。虽然信息社会特别是社交媒体的出现已经减弱了这种情况，但是目前仍无法达到绝对的信息对称。我们期待在区块链搭建的机器社会中进行深刻且迅速的社会关系变革，形成绝对信息对称，但是至少目前在机器社会还难以实现，即不能完全去中心化。
2016年TheDAO受攻击事件也表明，完全去中心化至少在现阶段是不可行的。The DAO是一个基于以太坊公有链的众筹项目，成为史上最大的众筹项目。然而由于其智能合约的漏洞，导致The DAO被黑客攻击并转移走价值6000万美元的数字货币，最后不得不黯然落幕。这给以太坊生态系统带来了很多负面影响。此次事件之后，很多人对区块链的“去中心化”进行了反思：在挽回这个损失的过程中，原有的去中心化机制未能解决问题，最后还是通过“集中式”的方式，强制以太坊进行“硬分叉”完成交易回滚。
如果我们仔细研究中本聪的论文中，就会发现其中只有Peer-to-Peer（P2P），而没有Decentralized一词。业界也正在逐渐对区块链并不一定去中心化形成共识。在2016年6月召开的W3C区块链标准会议上，以太坊的核心开发团队EthCore明确表示，不再使用Decentralized这个词，而是用P2P、Secure、Serverless这类纯技术性词语。
但是如果简单地宣称去中心化，或会被误读成是在某种程度上存在着一种既想从事金融活动，又不愿意接受金融监管的倾向。
——本文摘自《深度探索区块链：Hyperledger技术与应用》
推荐阅读
《深度探索区块链》
Hyperledger技术与应用
ISBN：978-7-111-58932-7
作 者：张增骏 董宁 朱轩彤 陈剑雄
定 价：79.00元
出版时间：即将出版
内容简介：
超级账本执行董事Brian Behlendorf领衔推荐，资深一线区块链专家联合撰写，区块链和Hyperledger技术扛鼎之作；深度剖析区块链框架Hyperledger Fabric 1.0的架构、核心技术、部署与应用开发。
（向上滑动）
目 录 Contents
序一
序二
序三
前言
第一篇 准备篇
第1章 区块链概述 2
1.1 区块链的前世今生 2
1.1.1 区块链的历史起源——比特币 2
1.1.2 欢迎来到区块链的世界 3
1.1.3 区块链演进趋势 4
1.2 区块链概念 5
1.2.1 区块链本质 6
1.2.2 区块链工作原理 6
1.2.3 区块链技术特点 7
1.2.4 区块链层次模型 8
1.2.5 区块链共识算法 8
1.2.6 区块链并不一定去中心化 9
1.3 区块链技术平台 10
1.3.1 比特币 10
1.3.2 以太坊 11
1.3.3 瑞波 13
1.3.4 区块链商用平台：超级账本 13
1.3.5 区块链技术平台比较 15
1.4 区块链的商用之道 15
1.4.1 区块链的2.0时代：商用区块链 15
1.4.2 超级账本：商用区块链的“第五元素” 17
1.4.3 区块链的商业应用场景 17
1.5 本章小结 18
第2章 超级账本初体验 19
2.1 基础环境安装 19
2.1.1 Docker的安装和使用 19
2.1.2 Docker Compose的安装和使用 21
2.1.3 下载超级账本源代码 24
2.2 超级账本部署调用 24
2.2.1 下载Docker镜像文件 24
2.2.2 部署超级账本网络 25
2.2.3 链码调用和查询 26
2.2.4 常见错误 27
2.3 节点的配置参数传递规则 29
2.4 本章小结 31
第二篇 核心篇
第3章 超级账本的系统架构 34
3.1 系统逻辑架构 35
3.2 网络节点架构 37
3.3 典型交易流程 39
3.3.1 创建交易提案并发送给背书节点 39
3.3.2 背书节点模拟交易并生成背书签名 41
3.3.3 收集交易的背书 42
3.3.4 构造交易请求并发送给排序服务节点 43
3.3.5 排序服务节点以对交易进行排序并生成区块 45
3.3.6 排序服务节点以广播给组织的主节点 45
3.3.7 记账节点验证区块内容并写入区块 45
3.3.8 在组织内部同步最新的区块 49
3.4 消息协议结构 49
3.4.1 信封消息结构 49
3.4.2 配置管理结构 51
3.4.3 背书流程结构 52
3.5 策略管理和访问控制 56
3.5.1 策略定义及其类型 56
3.5.2 交易背书策略 57
3.5.3 链码实例化策略 60
3.5.4 通道管理策略 61
3.6 本章小结 63
第4章 基于Gossip的P2P数据分发 64
4.1 概述 64
4.2 超级账本中的Gossip协议 65
4.3 成员认证及身份管理 67
4.4 节点启动及成员管理 67
4.5 主节点选举过程 68
4.6 基于反熵的状态同步 69
4.7 数据传播过程 70
4.8 多通道的支持 70
4.9 消息的验证策略 71
4.10 消息的多路分用及分区 73
4.11 和Gossip相关的配置参数 76
4.12 本章小结 77
第5章 分布式账本存储 78
5.1 概述 78
5.2 读写集 79
5.2.1 交易模拟和读写集 79
5.2.2 交易验证和世界状态更新 80
5.2.3 模拟和验证示例 80
5.3 账本编号 81
5.4 账本数据 81
5.4.1 账本数据存储 82
5.4.2 账本数据读取 83
5.4.3 交易模拟执行 84
5.5 区块索引 84
5.5.1 文件位置指针 85
5.5.2 索引的同步过程 86
5.6 状态数据 87
5.6.1 LevelDB 88
5.6.2 CouchDB 89
5.6.3 基于状态数据的区块验证 91
5.7 历史数据 92
5.8 数据恢复 92
5.9 本章小结 93
第6章 集成共识机制的排序服务 94
6.1 概述 94
6.1.1 共识算法的类型 95
6.1.2 Hyperledger Fabric 1.0的共识机制 96
6.2 实现数据隔离的多通道 97
6.2.1 排序服务的初始化 99
6.2.2 通道的创建 101
6.2.3 通道的更新 105
6.2.4 通道的加入 107
6.2.5 通道的查询 107
6.3 可插拔的排序服务 108
6.3.1 排序服务接口 108
6.3.2 基于单进程的排序服务 110
6.3.3 基于Kafka的排序服务 110
6.3.4 链消息过滤器 122
6.4 本章小结 124
第7章 实现数据隔离的多链及多通道 125
7.1 数据存储对多链的支持 126
7.1.1 账本数据 126
7.1.2 索引数据 126
7.1.3 状态数据 127
7.1.4 历史数据 127
7.2 链码对多链的支持 128
7.2.1 链码的生命周期管理 128
7.2.2 链码和背书节点的通信 129
7.2.3 链码的部署和调用 130
7.3 多通道对多链的支持 131
7.4 命令行和SDK对多链的支持 132
7.5 关于系统链 132
7.6 本章小结 132
第8章 基于数字证书的成员管理服务 133
8.1 实现成员管理的MSP 133
8.1.1 MSP成员的验证 133
8.1.2 MSP的目录结构 134
8.1.3 MSP的配置最佳实践 140
8.2 颁发数字证书的Fabric CA 142
8.2.1 概述 142
8.2.2 Fabric CA服务端的安装部署 143
8.2.3 Fabric CA服务端的操作使用 148
8.3 本章小结 158
第9章 支持多种语言的智能合约 159
9.1 概述 160
9.2 链码的生命周期管理 160
9.2.1 链码的生命周期 160
9.2.2 应用程序和链码的交互流程 164
9.2.3 背书节点接收应用程序的请求处理 165
9.2.4 采用上下文实现交易的模拟执行 166
9.2.5 链码消息的数据分发 166
9.2.6 链码运行环境的管理 168
9.3 内置的系统链码 172
9.3.1 生命周期管理系统链码 173
9.3.2 配置管理系统链码 180
9.3.3 查询管理系统链码 182
9.3.4 交易背书系统链码 182
9.3.5 交易验证系统链码 184
9.4 链码的相互调用 184
9.5 背书节点和链码的有限状态机 185
9.5.1 背书节点和链码之间的事件 188
9.5.2 背书节点的有限状态机 189
9.5.3 链码的有限状态机 190
9.6 本章小结 192
第三篇 应用篇
第10章 超级账本的应用开发模型 194
10.1 应用开发模型 194
10.2 应用程序开发的SDK 194
10.2.1 概述 195
10.2.2 SDK规范 195
10.2.3 应用场景介绍 204
10.3 链码的开发和调试 210
10.3.1 链码需要实现的接口 210
10.3.2 链码的SDK提供给链码的接口 212
10.3.3 链码开发的注意事项 214
10.3.4 链码的调试 215
10.4 本章小结 216
第11章 从零开始部署超级账本网络 217
11.1 准备超级账本运行环境 217
11.1.1 超级账本运行环境 217
11.1.2 编译超级账本镜像文件 224
11.2 快速构建超级账本网络 227
11.2.1 下载BYFN的代码 227
11.2.2 BYFN脚本介绍 227
11.2.3 生成网络初始化配置 228
11.2.4 启动超级账本网络 230
11.2.5 关闭超级账本网络 235
11.3 逐步建立超级账本网络 236
11.3.1 生成MSP证书 236
11.3.2 生成排序服务创世区块 236
11.3.3 生成通道配置创世区块 236
11.3.4 定义组织锚节点 237
11.3.5 启动超级账本网络 237
11.3.6 创建并加入通道 238
11.3.7 安装和实例化链码 240
11.3.8 执行链码查询 243
11.3.9 执行链码调用 244
11.4 本章小结 245
第12章 超级账本的应用开发实例 246
12.1 票据背书场景介绍 246
12.1.1 票据关系人 247
12.1.2 票据行为分类 247
12.1.3 基于区块链技术的数字票据 249
12.2 票据背书需求分析 250
12.3 票据背书架构设计 251
12.3.1 票据背书的分层架构 252
12.3.2 票据背书的数据模型 253
12.4 票据背书实现 254
12.4.1 应用程序实现 254
12.4.2 链码功能实现 275
12.5 票据背书快速部署 287
12.6 票据背书展示 288
12.6.1 系统登录 288
12.6.2 发布票据 288
12.6.3 我的票据 289
12.6.4 发起票据背书 289
12.6.5 待签收票据列表 290
12.6.6 签收票据背书 290
12.6.7 拒收票据背书 291
12.7 本章小结 292
附录A 术语表 293
附录B 超级账本的实用工具 297
参考文献 308
点击“阅读原文”可以提前加购哦~