区块链到底在忙什么从一本账本到一个互不完全信任的协作网络一篇写给好奇者的区块链入门博客。我们从一家咖啡店的账本出发经过蓝眼睛岛看看账户、交易、区块、共识与智能合约究竟怎样拼成一个系统。海风岛的四位店主各自维护并核验共同账本。写在前面先把“币”放在一边第一次听到“区块链”你可能会想到比特币、挖矿或者一串看不懂的地址。我最开始困惑的却是另一件事数据库已经能记账了为什么还要把数据装进区块再把区块连起来如果回答只是“因为它去中心化、不可篡改”我仍然不太满意。这些词像产品介绍却没有告诉我谁在记账谁能修改有人撒谎怎么办所以这篇文章想换一种走法。先不背术语我们去一座小岛看看几个不愿把账本交给同一个人管理的店主会遇到什么麻烦。等故事讲完再回头看那些词你会发现它们都有自己的工作也都有自己的边界。一、海风岛的难题这本账到底听谁的海风岛上有四家店小岚的咖啡店、阿墨的书店、桃子的面包店还有老周的杂货铺。为了方便结算他们约定使用一种虚构的“海风积分”。顾客可以在几家店之间使用积分店主也可以互相转账。这里的积分只是教学道具不对应任何真实币种。最省事的办法是让老周维护一套数据库。谁转给谁多少积分都向老周提交请求由他的系统检查余额并记账。这完全可以工作而且常常更简单、更高效。问题出在四家店的关系上他们愿意合作却不愿让其中一家单独掌握所有记账权。小岚担心老周误操作阿墨担心数据库停机桃子担心以后出了争议自己只能接受对方给出的记录。于是他们提出一个想法每家店都保存相关账本新增记录按共同规则确认任何一家都能独立核验。听起来只是多复制几份数据真正的问题却刚刚开始。假设小岚只有 10 个积分却几乎同时发出两笔请求转给阿墨 10 个转给桃子 10 个。阿墨先看见第一笔桃子先看见第二笔。两笔请求都可能有小岚的有效签名但它们不能同时成功。签名能说明“这是小岚授权的”却不能单独说明“这笔积分没有被重复花掉”。大家需要接受同一套有效性规则并就冲突请求的处理顺序形成一致结果。这才是区块链真正要面对的系统问题。[1]两笔请求都可能具有有效签名但同一笔余额不能重复支出。区块链的基本定义可以先这样理解区块链是一种按协议维护的分布式账本记录被组织成区块区块通过密码学摘要关联参与节点按照共同规则验证并确认账本历史。这里有三个不同的工作区块负责组织记录密码学负责关联与核验共识协议负责让正确节点接受相容的历史。只有哈希链没有多方协作协议未必构成我们通常讨论的完整区块链系统只有多台服务器也不自动意味着它们能在不完全互信的条件下共同记账。二、先认清角色用户、账户、钱包和节点故事讲到这里很容易把“岛民”“店铺”“账本管理员”统称为区块链用户。但落到技术系统这几种角色需要分开。账户像署名身份节点像运行系统的工作站小岚想转账需要某种可被系统识别的身份与授权方式。运行账本服务的电脑则需要接收交易、验证规则、保存数据或者参与共识。前者对应账户或身份体系后者对应节点。概念它是什么在海风岛故事中的类比用户使用系统的人或组织小岚、阿墨以及四家店账户链上身份协议用于识别主体、关联状态或权限的表示在账本上可被识别的署名钱包管理密钥、构造或授权交易、连接网络的工具保管签字工具并填写转账单的助手节点运行区块链软件的计算实例接收记录并维护账本的工作站共识参与者按协议参与出块、排序或确认的节点角色有资格参与记账决策的工作站使用一个账户不代表你运行了一个节点运行一个节点也不代表你只有一个账户。还有一个细节不同链的账户模型并不一样。以太坊具有显式账户与账户状态比特币采用 UTXO即“未花费交易输出”模型不宜把所有链都想成“每个账户有一个余额字段”。[3]UTXO 可以粗略类比为一张张尚未花掉的票据。付款时消费旧票据生成给收款人和找零的新票据而不是直接在统一账户表里扣减一个数字。私钥不是余额钱包也不把资产装在本地在常见的公私钥授权方式中私钥用于签名其他人用对应公钥验证。地址则按具体链的规则生成通常与公钥或其他协议数据有关。钱包主要保管和使用授权材料并展示链上的记录与状态。你在钱包里看到的余额通常来自它查询或核验的链上信息。[3]我喜欢把钱包想成“钥匙包加账本阅读器”钥匙控制你能授权什么账本记录系统承认什么。这个比喻也有边界托管钱包可能由服务方保管密钥合约钱包又有自己的授权逻辑不能都用一把个人私钥概括。用户、钱包、账户和节点分别承担不同角色。三、一笔交易怎样成为大家承认的记录先用一个抽象流程看海风积分转账不把它当成任何具体区块链的逐步实现。小岚填写“给阿墨转 3 个积分”通过钱包完成授权向网络提交请求。收到它的节点依据规则检查格式对不对授权有效吗是否具备使用这笔资产的条件之后请求按具体协议参与排序、打包或共识并在满足确认条件后影响账本状态。提交请求、被某个节点接收、进入区块以及获得最终确认是不同的事情。比如咖啡店电脑显示“已收到”只是说明它收到了请求并不等于另外三家店已经接受更不等于交易永远不会被重组。“交易”不一定是转钱区块链里的交易也可能是登记一份文件的摘要、调用一个合约、修改某项资产的持有人或者提交一次业务授权。因此更通用的理解是交易是按协议提交的一项操作请求它可能引起状态变化。如果几家店的账本都从相同状态出发按相同顺序执行相同的确定性规则才有机会得到相同的新状态。反过来即使请求集合相同顺序不同也可能出现不同结果。例如同一份余额只能支持一笔全额支出时哪笔先被有效执行会影响后一笔能否成立。交易处理的概念流程收到请求并不等于最终确认。四、为什么是“区块”和“链”如果交易像一张张小票区块就像把一批小票整理在一起的资料袋。以比特币为例区块包含区块头和交易等内容。区块头含有前一区块的哈希、交易的 Merkle 根以及时间、难度相关字段等。其他链的结构可能不同。[2]部分主要作用阅读时抓住什么区块头描述区块并承载与前块、内容摘要及协议验证有关的信息它如何关联前块、约束当前内容区块内容保存该区块收录的交易等数据到底记录了哪些操作协议相关证据依链而异可能涉及工作量或共识认证信息为什么网络可以接受这个区块“协议相关证据”是概念层面的分类并非所有链都有一个同名独立字段。哈希给数据做一份可核验的摘要哈希函数把输入映射成固定长度的摘要。适当的密码学哈希函数应当让寻找碰撞、逆推出原始输入等操作在计算上足够困难。你可以把摘要类比为数据的“指纹”但别把比喻理解成数学上的绝对唯一固定长度输出不可能与所有任意长度输入一一对应。概念上可以写成h i H ( Encode ⁡ ( H e a d e r i ) ) h_i H(\operatorname{Encode}(\mathrm{Header}_i))hi​H(Encode(Headeri​))这里的编码规则和哈希算法由具体协议规定。例如比特币对序列化区块头使用双 SHA-256。[2]下一块引用上一块的哈希。如果有人改变旧块中被摘要覆盖的交易内容摘要会改变区块头与其哈希随之改变后续引用也就对不上了。能发现修改和不能改写公认历史是两层问题有人可能立刻想到那我改完以后把后面的哈希重新算一遍不就行了这个反问非常好。单纯重新计算哈希并不是不可完成的事情。哈希关联主要使修改变得可检测让其他节点接受这段改写后的历史则还要越过验证规则与共识机制。这就是为什么“用了哈希所以绝对不能篡改”说得太满。区块链对历史的保护来自密码学、协议、故障假设及运行治理的共同作用。Merkle 树一批交易怎样汇成一个摘要可以想象四张交易小票先分别算摘要再把相邻摘要按规则组合计算逐层汇成一个根。[2]它的好处是验证某项内容是否属于这批记录时可以使用一条较短的证明路径而不必总是取得全部内容。不过“它被收录了”与“它的业务内容真实可靠”仍然是两回事。区块的内容摘要与前块哈希使历史修改能够被检测。五、共识不是大家都觉得对而是大家按规则决定回到海风岛。四家店都拥有账本但只要看到消息的顺序不同它们仍可能维护出不同结果。共识是多个参与节点在明确的网络与故障假设下通过协议对某个值、操作顺序或账本历史形成一致决定的过程。理解时可以抓住三个问题性质通俗问题一致性正确节点会不会决定相互冲突的结果有效性决定是否满足协议定义的有效条件终止性在规定条件下正确节点最终能不能作出决定这里的“正确节点”是遵守协议、未发生所考虑故障的节点。共识不能只剩一句“少数服从多数”。你还得解释谁有投票资格消息晚到怎么办同一个人向不同节点说不同的话怎么办大家什么时候可以认为决定已经成立蓝眼睛岛一句没有新鲜感的话为什么改变所有人我们暂时离开四家店去另一座经典逻辑故事中的小岛。岛民能看见别人的眼睛却看不见自己的也不能交流眼睛颜色。一旦推理确定自己是蓝眼睛就必须在当天午夜离岛。所有人都是完美的逻辑推理者这些规则与推理能力是公共知识外来者的宣布被所有人共同听见每晚是否有人离开也能被可靠地共同观察。岛上恰好有三个蓝眼睛的人但他们不知道总数。某天外来者公开说“岛上至少有一个蓝眼睛的人。”每个蓝眼睛的人都看得见另外两个这句话似乎没有告诉他们新事实。可到了第三天午夜三个人一起离岛。我们把人数从一开始推蓝眼睛人数每人看到什么推理与行动1 人看不到其他蓝眼睛公告说至少有一个那一定是自己第一夜离开2 人看见一个蓝眼睛若自己不是蓝眼睛对方第一夜会离开第一夜无人离开于是第二夜离开3 人看见两个蓝眼睛若自己不是蓝眼睛另外两人第二夜会离开第二夜无人离开于是第三夜离开关键不只是“我知道”而是“我知道你知道并且知道你也知道我知道”如此递归下去。这叫公共知识。公开宣布建立共同起点每晚无人离开又提供可共同观察的推理证据。公开宣布建立共同起点三位蓝眼睛岛民在第三夜离开。为什么我想把它放在共识的故事里因为它让“信息”和“协调”之间的距离变得可见参与者各自知道一些事实并不意味着他们已经拥有作出一致行动所需的共同认知。这也让我觉得区块链有意思。它试图让不同主体通过可核验的记录与明确规则协作而不必把所有判断都交给一个中心。但蓝眼睛岛讲的是公共知识与协调行为并不是可以直接部署的共识算法。现实网络会延迟、丢包节点会宕机也可能作恶“今晚没人离开”在网络中可能只是“消息还没收到”。真实协议必须处理这些情况而且通常不要求建立故事中那种无限层次的公共知识。更重要的是一致接受一条记录不等于证明外部世界的事实是真的。四家店可以一致记录“某箱牛奶温度合格”却不能仅凭共识保证测温人员没有撒谎。六、PoW开放网络里怎样让一堆陌生节点收敛如果四家店扩展成一个任何人都能加入的网络直接按身份投票就遇到麻烦一个人可以制造很多身份。比特币式机制采用工作量证明PoWProof of Work。矿工尝试调整区块头等相关数据寻找满足目标的哈希结果。简化写成HashValue ⁡ ( H e a d e r ) ≤ T \operatorname{HashValue}(\mathrm{Header}) \leq THashValue(Header)≤T其中T TT是目标值。目标越小通常越难碰到合格结果。验证者检查给出的结果远比产生它所需的反复尝试便宜。[1][2]可以把挖矿想成一次“难找、好验”的抽签岛上准备了一个特殊抽签机每次换参数得到一个难以预测的号码。合格号码很少因此大家必须反复尝试。某个矿工找到合格结果只是获得提出候选区块的机会其他节点还要核验区块是否有效。无效交易不会因为矿工算得辛苦就变成有效交易。如果两个有效区块几乎同时出现节点可能暂时跟随不同分支。协议依据累计工作量最多的有效链选择历史后续工作量帮助网络逐步收敛。[1]所以PoW 本身是一种证明机制把它与交易验证、网络传播和链选择结合起来才构成这里讨论的共识路线。为什么不能只说“最长链”“最长链”方便口头讲解但精确理解应关注累计工作量单纯数区块个数在不同难度下可能产生误解。这套机制也不保证所有人立即看到同一条链。确认越深历史被重组的风险通常越低这叫概率性最终性其成立依赖算力与网络传播等条件。[1]它的魅力在于开放参与其代价包括持续计算开销、等待确认以及对资源分布和网络条件的依赖。比特币式共识结合工作量证明、有效性验证与累计工作量链选择。七、PBFT已知成员之间怎样防住一个会说谎的人再回到海风岛的四家店。成员数量可控身份也已知未必需要让店主一直消耗算力。PBFT即实用拜占庭容错Practical Byzantine Fault Tolerance走的是另一条路通过有规则的多轮消息让正确副本就请求顺序达成一致。[4]“拜占庭故障”可以包括故意撒谎、向不同对象发送矛盾消息或者任意偏离协议。经典配置用n 3 f 1 n3f1n3f1个副本容忍最多f ff个拜占庭副本。我们选f 1 f1f1因此需要四个副本下面的阈值也按这个经典配置说明。正常情况下的三个阶段阶段做什么直观含义Pre-prepare预准备主节点提出请求及其序列位置“把这项请求安排在这里”Prepare准备副本核验提案并传播匹配消息“我看到并接受了这个安排”Commit提交满足 prepared 条件的副本传播提交消息“已具备按协议确认它的条件”经典 PBFT 的 prepared 条件包含请求、匹配的预准备消息及来自不同备份副本的2 f 2f2f条匹配 Prepare。提交还要求本地 prepared并收集来自不同副本的2 f 1 2f12f1条匹配 Commit可含自身。执行要遵守序列顺序。[4]这些数字看上去绕但它们不是随意选的。四个人中要三个人支持为什么有用假设最多一个节点作恶。任何两个大小为三的节点集合在四个节点中至少重叠两个其中至少一个是正确节点。正确节点遵守协议不会在同一视图、同一序列位置对冲突请求提供相应的矛盾支持。这个交集是安全性的关键。不过交集只是解释入口不是完整安全性证明。主节点可能出问题协议还需要视图切换并在切换时保留此前的准备信息防止换了主节点就抹掉已经形成的约束。[4]可以把它想成四家店的联合记账会议但“开会”只是比喻真实系统靠消息认证、状态条件和证据而不是靠大家坐在一张桌边互相信任。一致性和持续推进是不同的保证在故障数量不超过阈值、认证等前提成立时PBFT 保持安全性不让正确节点提交冲突结果活性则需要网络最终足够及时、协议能够推进等条件。如果网络长期分割它可能暂时停下来。没有进展与作出矛盾决定是两种不同故障。PBFT 提供的是条件成立时的确定性提交安全保证其代价包括多轮通信经典正常路径的副本间消息量随节点数呈二次增长。[4]PBFT 正常流程的角色化示意冲突指同一视图、同一序号下的不同请求。阴影是作恶行为的符号并非额外副本图中省略证书与视图切换细节。两种机制解决的是不同环境中的协作问题维度比特币式 PoW 共识经典 PBFT典型参与环境开放网络成员已知的许可环境关键约束攻击者算力与网络条件拜占庭副本数量与认证等条件如何形成共同历史工作量证明与有效链选择多轮消息、证据与视图切换最终性概率性条件成立时的确定性安全保证主要代价计算与确认等待通信与成员管理它们都不是“保证所有人永远正确”的魔法而是明确说明在什么条件下正确参与者可以接受怎样的一致性保证。八、智能合约把约定写成共同执行的规则账本已经能记录发生过什么但店主还有一个想法某些事情能不能按事先约定的规则处理比如小岚向桃子订购一批面包希望在约定的签收授权通过后才释放预先锁定的积分。这类规则可以表达成智能合约。在以太坊等平台中智能合约是部署在链上的程序与相关状态符合条件的交易调用它节点按协议执行或验证执行结果。[5]教学伪代码 如果调用者具有签收权限且订单状态允许签收 将订单标记为已签收 按约定释放托管积分 否则 拒绝本次操作它不因为叫“智能”就懂得现实也不因为叫“合约”就自动具有完整法律效力。谁来维护合约这里的“维护”至少有三种含义工作通常由谁承担编写、部署与设置业务权限开发者、部署主体或治理主体保存相关代码和状态执行或核验结果按具体链角色运行的节点决定能否升级、由谁升级合约设计与治理规则指定的主体合约不是通常意义上“放在某台业务服务器里的一段后台程序”。但不同链的执行架构并不一致也不是每种节点都执行所有合约。[5][6]最大的反问面包真的送到了吗这是我觉得智能合约最值得追问的地方。合约可以核验“谁提交了签收”却无法自己走出电脑检查纸箱里的面包。外部事实需要由签收方、设备或预言机等机制提供。如何信任这些来源是额外的问题。若签收人撒谎合约可能只是忠实执行了错误输入对应的规则。链上执行的一致性不会自动转换成链下事实的真实性。签收信息连接现实输入与链上规则但合约无法自行检查货物。九、从故事到工程联盟链、Peer、Orderer 与 BaaS到这里你可能会问企业真正建设区块链时是不是就把四台服务器接起来运行 PBFT没有这么固定。不同平台会拆分身份、执行、排序、验证、存储和运维角色也可能采用不同共识协议。公有链、联盟链、私有链重点是权限与治理类型常见组织方式需要关注什么公有链参与通常较开放权限由协议规定谁能验证、出块如何防止身份滥用联盟链多个获准组织共同参与和治理谁能入网谁能读写谁能参与共识私有链参与和治理主要受单一主体控制相比其他系统链式审计或治理规则带来什么收益这是一种通俗分类各平台的实际权限应单独查看。“去中心化”也不是开关治理、共识资源、访问入口和基础设施可能有不同程度的集中。用 Hyperledger Fabric 举一个具体例子Fabric 的 Peer 与 Orderer 是平台里的特定角色不能照搬到所有区块链。[6][7]组件在 Fabric 中的主要职责Peer维护所属通道账本承担交易验证、提交符合相应角色与配置的 Peer 还参与背书执行Orderer为交易建立顺序并形成区块向 Peer 交付不替代 Peer 完成完整的业务有效性验证客户端业务应用构造交易请求收集所需响应提交交易并查询结果因此可以把 Peer 理解为承担账本和业务相关工作的节点把 Orderer 理解为排序服务节点但不宜简单说“Peer 没有共识工作Orderer 承担全部共识”。尤其要注意Fabric 不应直接等同于经典 PBFT。排序服务所采用的协议及其容错能力需要结合具体版本和配置判断。[7]BaaS 是平台服务Nginx 是入口组件BaaSBlockchain as a Service通常是一组帮助部署、管理和使用区块链的服务能力可能提供节点管理、证书管理、监控以及接入接口。具体功能由产品决定它通常是软件与服务体系不是一种固定硬件。Nginx 则可能承担反向代理、流量转发或负载均衡。它可以出现在 BaaS 或业务系统的入口但这不使它自动成为区块链共识节点。业务用户可以通过应用访问链也可以通过平台接口接入“使用区块链”并不必然意味着每位用户都先登录 BaaS 控制台。联盟链组件的场景化示意业务、Peer、排序与运维承担不同职责。十、账本放在哪里共识消息也会上链吗问到这里就已经从“区块链是什么”走到了“系统如何运行”。谁保存哪些数据取决于平台、节点角色、通道和裁剪等策略。不能笼统认为所有节点都保存所有数据。全节点、轻客户端、归档节点可能保存不同范围在 Fabric 中Peer 保存它所加入通道的相关账本私有数据又有额外分发限制。[6][8]历史记录和当前状态可以分开理解在一些账本架构中可以同时看到“按顺序保存的历史”和“便于查询的当前状态”。Fabric 就把区块链与世界状态作为账本的两个相关部分。[8]海风岛的历史可能记录小岚从 10 积分转出 3 积分当前状态则方便查询“现在剩多少”。两者有关系却不必是同一份物理存储。共识消息不等于业务交易数据类别例子是否一定写入区块业务交易转账、登记、合约调用按协议与处理结果决定共识过程消息提案、准备、提交、视图切换消息不一定常用于节点间通信共识证据或元数据某些协议中的证书、签名集合依协议可能进入区块或相关记录本地恢复和运维数据持久化协议状态、日志、缓存通常与账本内容区分但可能需要持久保存所以“这是一条共识消息”不能直接推出“它必然永远上链”也不能推出“它只在内存里无需保存”。协议恢复、安全审计和工程实现都会影响保存方式。账本、通信消息与恢复审计记录用途不同。当前业务状态也应与节点运行指标区分。十一、我希望读完以后你能反问这五句话“区块链上的数据一定真实。”记录经过协议确认不代表现实输入没有造假。看供应链案例时我会先问谁采集谁授权出了错怎样纠正“上链以后绝对不能修改。”更准确地说系统按协议保护已确认历史修改可被检测改写公认历史需要突破相应条件。重组、治理变更、升级及纠错机制都要结合具体系统讨论。“有数字签名就足够安全。”签名保护授权与消息完整性却不能单独防止重复花费也不能自动避免私钥失窃。账户授权、共识、密钥管理和业务权限是不同工作。“去中心化就是不需要信任。”我更愿意说信任被重新分配了。你可能减少了对单一记账机构的依赖却仍依赖协议、实现、参与者假设、密钥保管和治理机制。“多个部门共享数据就应该用区块链。”还得往下问这些部门为什么不能接受一个共同管理方是否需要各自核验历史写入权与争议处理由谁决定增加的通信、存储与治理成本是否值得如果中心管理方能够被各方接受数据库配合签名、审计与备份可能已经合适。区块链是否有价值要从具体协作关系出发判断。理解区块链时先追问保证成立的条件与技术边界。写在最后链起来的是区块协作起来的是人现在我们可以再看一眼海风岛。小岚用账户和授权工具发起请求节点依据规则检查交易被组织和排序共识让正确参与者接受相容的历史智能合约把部分约定变成可执行规则。这些东西合在一起才形成一个能运行的系统。蓝眼睛岛让我看到知道一件事与能够协调行动之间隔着共同认知。现实区块链则必须在更困难的环境里用明确协议建立足够的一致决策依据。所以如果让我用一句话介绍区块链我会说它尝试让不完全互信的参与者按照共同规则维护一份可以各自核验的历史。至于这份历史记录什么输入是否可靠谁能参与代价是否值得——这些问题比“是不是上了链”更值得我们继续聊。延伸阅读与技术出处正文中的海风岛人物、积分及情节均为教学设定类比用于解释直觉不构成某个平台的完整实现描述。技术阅读可从以下原始论文和官方文档继续Satoshi NakamotoBitcoin: A Peer-to-Peer Electronic Cash System——双重支付、工作量证明、链选择与确认风险。Bitcoin Developer ReferenceBlock Chain——区块头、目标值和 Merkle 树。该页面部分版本与数值叙述较旧本文只引用基础结构。EthereumAccounts——账户、密钥与钱包的关系本文另用 UTXO 作模型对照。Miguel Castro、Barbara LiskovPractical Byzantine Fault Tolerance——经典 PBFT 的阶段、故障阈值与视图切换。EthereumIntroduction to Smart Contracts——合约代码、状态与执行机制。Hyperledger FabricPeers——Peer、账本、通道与链码角色。Hyperledger FabricThe Ordering Service——排序服务与交易验证职责的区别。Hyperledger FabricLedger——区块历史与世界状态。