跨链梳理之侧链及OneLedger简评

侧链

关于侧链，在历史上有过不同的定义，目前最受世人接受的定义主要着眼于“双向锚定（2-way pegging）”，即一个区块链可以通过读取另外一个链上数据的能力来使资产在两条链中进行转移。拿BTC和RSK举例的话，双向锚定可以理解成：

允许比特币从比特币区块链转移到其他区块链的机制，反之亦然。RSK实现的就是对比特币一比一的双向锚定（代币叫做SBTC，智能比特币）。这里说的‘转移’并非把比特币真的挪到它的侧链上（比特币是不能被转移的），而是用到了一种‘锁定’和‘解锁’的策略。做法是：暂时性地将比特币（BTC）在比特币主链上锁住，同时等量的等价代币（SBTC）在RSK链上被释放，从而完成价值转移。相反的操作则是SBTC在RSK区块链上被锁定，释放比特币主链上的BTC。

这里告诉了我们两点：

从理论上来说，主链和侧链之间的关系其实是对等的，也就是说，侧链是主链的侧链，主链也是侧链的侧链......（有点人是人他妈生的既视感）

饶是彼此之间是关系对等，主链和侧链之间依旧有主侧之分，因为两条链转移的是同一种资产，那么必然存在一条“主链”是该资产真正的“家”，而另外一条“侧链”上的资产是完全锚定“主链”上的资产的，侧链上是没法单靠自己出块或预铸币来无中生有地发行资产的。

侧链其实也无需妄自菲薄，侧链上可以添加和实现更多的功能，比如RSK链上可以实现智能合约，做到主链所不能做的事情。

再说回双向锚定，双向锚定可以通过不同的办法来实现，比如：

单一保管人

多重签名联盟

侧链协议

驱动链（Drive chain）

以及综合了多个前几种办法的混合方案（Hybrid）

所有这些办法在《RSK简评》中都有过阐述，这里不再赘述。唯一要提一下的是，这里的“侧链协议”也有很多人直接叫做侧链，为了避免混淆，本文还是为其保留协议二字。请注意区分，能满足双向锚定的两条链互为彼此的侧链，而实现双向锚定的某种特定的实现办法可以是侧链协议。

侧链协议

侧链协议作为一套解锁和锁定资产的标准，着重于“主链”和“侧链”之间能够互相理解，并且有能力读取和验证对方链上的事件和状态，于是可以自动且强制执行资产锁定和解锁的能力，而这一切过程中都不需要更多的第三方参与进来。

具体来说就是支持SPV（简单支付验证，Simple Payment Verificaiton），能够验证区块头（Header）、默克尔树（Merkle tree）信息的能力。

顺便普及下默克尔树。区块链的单个区块中可能有成百上千的交易，我们可以将这些交易的哈希值放在最底层（作为叶节点）两两凑在一起再做哈希运算，以此类推，便能生成一棵哈希二叉树，即：除了叶节点外，其他每个节点包括根节点的值都是左右两个子节点的哈希值拼在一起后计算出的哈希值。之所以费力搭出这么一棵二叉树是为了查询的效率，学过数据结构或算法的都知道查询二叉树的时间复杂度是log N，是相当理想的。为了证明区块中存在某个特定的交易，只需要构成Merkle路径的log N个节点中的哈希值即可。btw，对于学计算机的人来说，log默认都是以2作底数。

上述的默克尔树就是用来支持SPV的，SPV也是中本聪提出来的聪明计策之一，用来验证某个交易是否确实存在，并得到多少个确认。BTC白皮书中提到：

不运行全节点也可以验证支付，用户只需要保存所有的区块头（Block Header）就可以了。用户虽然不能自己验证交易，但如果能够从区块链的某处（最长链中的某个区块中）找到相符的交易，他就可以知道网络已经认可了这笔交易，而且得到了网络的多个确认。

在BTC中，每个区块都有属于自己的一棵默克尔树，存在区块中，而莫克尔树的根节点则存在于区块头中，这样的好处则是轻节点可以无需下载所有区块链的完整数据，只要下载区块头就可以了。而且BTC还支持布隆过滤器（Bloom filter）进一步缩小需要下载的区块头的范围。

侧链协议中，用 SPV 来证明一个交易确实已经在区块链中发生过，称为 SPV 证明（SPV Proof）。一个 SPV 证明包括两部分内容：一组区块头的列表，表示工作量证明；一个特定的输出（output）存在于某个区块中的密码学证明。这里的输出可以简单理解为交易产生的可供收款方配置的资金，以后在梳理闪电网络的时候会专门介绍UTXO。

用BTC举例的话，侧链协议实际的操作步骤是：

提交锁定交易：比特币持有者在BTC主链上发送一个特殊交易，把比特币锁定在BTC链上。

等待确认：在BTC链上等待锁定交易被更多区块确认，以防止该锁定是虚假的交易。

解锁交易：锁定交易确认后，用户在侧链上创建一个解锁交易（也被叫做赎回交易）花掉锁定交易的输出，并提供SPV工作量证明（即该解锁交易所在区块的工作量证明），并将赎回交易的输出导入自己在侧链上的地址中。

等待一个竞争期：竞争期也被称作可修改阶段，作用是防双花。而且在此期间，

解锁交易不会被打包到区块

新转移到侧链上的比特币还不能被使用

如果解锁交易包括了比特币主链更大难度的SPV证明，则上一个解锁交易将被替换。

竞争期结束后，该解锁交易将被打包到区块中，用户可以使用他的比特币了（其实是侧链上相对应的代币）。

运用了侧链技术的好项目相当的多，不乏各种成名项目，以后会一个一个梳理。

今天先来简评下近期的新项目，OneLedger，也正好看看业界最新的侧链项目做到什么样了。看这个项目的名字就知道是和跨账本有关的。不过这个项目并没有打算打造一个“至尊魔链”，而只是起了这么个名字而已。

OneLedger

当然，OneLedger还是会有自己独立的区块链（们），不过基本都是以“侧链”的形态存在。这里的“侧链”是通过联盟模式 + 驱动链的混合模式来使得底层公链主网和OneLedger中对应“侧链”的资产和信息同步。诚如前文所介绍的，联盟模式和驱动链都是比较常见的实现主侧链之间双向锚定的技术方案。

联盟模式是通过公证人联盟的多重签名对侧链的资产流动进行确认，好处是不需要主链这一侧的改变就可以移动资产，但是安全性方面仍会受限于公证人联盟的诚实度。

驱动链模式则是将在主链上锁定资产的监管权交给矿工，由矿工来投票何时解锁主链上的资产、并且将解锁的资产发往何处。矿工可以使用区块里的某些字段（比如Coinbase）来实现投票。越多的诚实矿工参与进来投票，则安全性就越高。不过需要对主链进行软分叉。

除了提到了上述两个侧链技术方案之外，OneLedger并未透露其他更多的关于实现侧链的细节，不过确实在路线图里写了在2018会先后推出以太坊和比特币的侧链。

如此一来，一套“曲线救国”般的跨链功能就显出雏形，即：将公链主网之间的跨链转账，转换成OneLedger内部对应的侧链间的操作。从而一方面OneLedger作为底层的开发商承担了大量的技术细节，使得用户可以更加统一和便利地执行和管理跨链操作，另一方面如闪电网络一般，将大量频繁的转帐交易从公链主网转移到了OneLedger网络的头上，有点类似于建立了一个更加通用化的链化了的闪电网络。OneLedger内部链之间的跨链是通过建立第三条侧链来完成的，而不是使用HTLC（可以参看《跨链梳理之哈希锁定 及 IOV简评》来回顾HTLC是如何实现跨链原子性互换的）。

通读白皮书，可以明显得感到OneLedger迫切地希望能提供一个帮助传统企业平滑快速得过渡到、甚至进而拥抱区块链和跨账本技术的平台，并且依靠这个平台来做到与其他跨链项目的差异化竞争。作为传统企业中心化系统和区块链系统之间的桥梁，OneLedger平台允许企业或个人（更多的是企业）在平台上方便快捷地创建适合自己业务的公链、许可链或者私链，并且专门为企业许可链专门加了很多功能，比如身份管理系统，个人信任评级，以及角色控制来管理数据的读写权限和共识模式。

所以白皮书中除了对底层跨链和共识的介绍外，很大篇幅都在介绍上层各种便利的系统和工具，一开始让人不免有东一榔头西一棒槌的感觉，但是如果理解了项目方着眼于企业级用户和应用的出发点，就能稍微习惯这样的编排了。不过看惯了基础公链项目，比如Hashgraph，Algorand等，再回过头来看OneLedger，会发现OneLedger想做的东西真的非常多，撸一遍看不全，要撸好几遍...

另外吐槽一下，OneLedger的白皮书一方面可能是写的过于简练和晦涩了，另一方面结合了公链、侧链和HyperLedger联盟链三者庞杂的概念，而且野心勃勃地想做很多东西，使得一般人很难看懂OneLedger的白皮书，就算大致猜对了大方向也很难照着白皮书来验证技术细节和可行性。码农在网上搜了下，市面上大部分的中英评测基本就是照抄白皮书原文及译文，或者做下简单的剪裁，或者是将比较表层的理解叙述出来，基本都没有对原文中的很多细节做深入挖掘和确认，恐怕能确切理解OneLedger白皮书背后想法和技术细节的人屈指可数，码农勉强算一个吧。话说如果OneLedger能在白皮书能加上具体的示例，估计会有助于读者的理解，所以本简评里有不少内容都是码农先脑补然后找OneLedger团队再做确认后得出的，所以团队大佬们被我烦了大概有好几天的样子，多谢你们的时间和耐心咯。

上图是OneLedger的架构图：

OneLedger共识协议层（OneLedger Consensus Protocol）居于中央。

共识协议层之上都是前面说到的用来方便企业入驻平台打造自己区块链应用的上层系统和工具，包括业务中心（Business Center），身份管理系统（Identity Management System）等。

共识协议层之下是跑在OneLedger网络内的区块链层，可以是锚定各大主流公链的侧链，也可以是对应不同商业场景需求的区块链们（白皮书中把这些也叫做侧链，不过我觉得直接叫做OneLedger区块链或内部链可能更加容易理解）。换句话说，OneLedger选择了内置侧链来适配其他公链，再加上专作跨链交易的中间链来双向锚定代表交易双方的内部链，从而做到了底层区块链无关以及跨链跨账本。另外，补充一个有意思的洞察则是，这些存在于区块链层中的内部链并非实际的物理链，而更像是动态的虚拟链或虚拟网络，在需要执行交互操作的和达成共识的时候，节点会被挑选出来，完成该链的出块，并且区块会存在相应的参与了共识的所有节点中。有点类似于《Pallet简评》中提到过的陪审团共识制度，但是更动态更复杂。具体细节后面部分详述。

1. 上层应用

1.1 业务中心

“业务中心”作为一个工具门户，主要目的是使得用户可以快速地搭建起适用于自己行业和商业场景的区块链应用，而且这里用到了抽象的概念，即把底层区块链搭建的细节给隐藏了，用户在这里只需关注业务模型本身，比如定义数字化的资产（财务，产品或内容类资产），角色控制，业务逻辑等。它的作用可以简单理解成和某些提供快速创建以太坊的ERC20 Token的工具差不多，只不过业务中心里包含的元素更多，产出物（比如合约）也是更通用化的合约，而且能支持多个底层区块链。此外，业务中心会提供各种可视化工具降低开发的难度。

这里还引入了一个软件开发中常见的最佳实践就是“模块化”，即一个产品或应用程序可以通过各个现成的模块集成在一起而组建起来，如此一来模块可以由不同的独立开发人员来完成，同时也催生出一个将雇主和开发人员撮合串联起来的模块市场（OneLedger Marketplace，又可以是个独立的产品）。最终的目的是通过正在开发的SDK和API，系统可以自动将通用化的业务模型定义转换成能真正可运行在不同公链上的链码（Chain code）。

业务中心这个想法和其立足点都很有可取之处，但是落地的话可能并不容易，需要好好研究。

1.2 身份管理系统

系统为每个身份（即终端用户）分配一组主公钥密钥对(master key-pair)，可以通过使用私钥对消息进行数字签名，从而将任意的公钥和身份进行绑定。具体来说，主私钥可以被迁移到OneLedger一站式钱包（又一个类似于IOV万能钱包的竞品）中，由于OneLedger天生内置的各种侧链，使得该钱包可以理论上支持各种数字货币资产，在进行资产转账时，钱包可以使用主私钥对交易进行签名，从而其他节点可以通过公开的主公钥验证出交易中的他链资产地址属于这个身份。

另外，身份还可以给其他身份赋予可信度评级，类似一种声望管理系统。

1.3 OneLedger智能引擎

该系统没有专门的文字介绍，只出现在图中，就此略过。感觉也可以是一个相对独立的产品。

2. OneLedger共识协议栈

OneLedger的核心是一组共识协议，这些协议使得OneLedger能够有效集成不同的区块链产品。我感觉是这里说的协议不是传统意义上具体的共识协议算法，而是分别介绍了一系列的概念和应用场景。

2.1 业务初始化层

这一层承接来自于业务中心的业务模型，模块以及身份角色信息。本层有两个功能：

其一，是将定义了业务逻辑的通用合约编译成适用于不同底层区块链的合约（比如对以太坊来说就是Soldity智能合约），这个有点类似于一键将广告发到各个广告平台的功能，公司和开发人员只需关心业务逻辑本身，然后平台会完成剩下的一切，包括实际合约在不同底层公链上的生成和部署等。实现方法是OneLedger会保存一个主智能合约（master smart contract），这个合约是按照指定的某个语言进行编写的，然后在部署到不同平台的时候可以被翻译（Transpile）成适用的语言（另，关于跨语言翻译可以点这个连接感受一下https://ide.onelang.io/?input=ReflectionTest）。

其二，是使得基于角色的共识定义变得可行。合约里除了定义行为外，还可以定义有权访问许可链和触发这些链中交易的角色。每个身份可以关联某个角色，而角色可以被授权访问某条链。好似大家在公司里会有IT部门给每个人设定相应的系统访问权限，个人身份是第一层认证，被授于的角色则作为第二层认证。

在进行基于角色的共识的时候，允许参与交易的角色形成了一个多重签名环。而且一般是发生在许可链中的交易才需要使用角色定义，所以只有部分达到一定标准的节点会被选中参与到这个共识中来。白皮书中某些语句表示了角色会被一一关联到网络中的节点上（Each role is linked to an independent node that participates in consensus; business logic will then determine how each role is fed into node data.），经过和团队确认并非如此，角色和节点并没有直接的关联（码农还傻不拉叽一度试图理解这一点[捂脸]）。

如果不需要角色控制，则相应OneLedger网络内的所有节点都会一起参与共识，当然这样会导致最差的共识效率，OneLedger可能需要类似委托代理的机制来提高共识效率。

所以，角色控制一方面为许可链引入了访问权限验证机制，另一方面使得参与共识的范围变得更小（反正本来就是许可链），从而使得共识过程变得更加快速。并且通过配置角色控制的能力，企业可以灵活的在共识性能和共识可靠性之间找到平衡。

业务中心中的概念比较多，文中也没有特别厘清他们的之间的关系，也没怎么详细说如何在这一层把这些概念转化成区块链的元素。现整理如下：

业务模型（Business model）：真实世界中的业务，比如一个汽车公司。

模块（Module）：一个模块代表了复杂的业务逻辑，是组建和支撑起业务模型中实际业务运作的通用化或定制的业务集成单元。一个业务模型中可以配有多个模块，比如生产制造，仓储，销售和财会。同时，每一个模块也可以看成一个单独的OneLedger链，角色可以被定义在模块上负责访问权限的验证和限制。

流程（Workflow/Process）：一个模块可以通过多个流程来实现。每个流程都是一个最小的逻辑单元，映射到区块链中就是一个个可执行的智能合约。比如，配件入库，整车批发给合作经销商，等等。智能合约中可以进一步定义有权调用合约的角色。

数字资产：现实生活中各种实体的数字化体现，货币，物品，内容，等。OneLedger的区块链中可以维护多个数字资产。

2.2 通道共识层（Channel consensus）

这里的通道共识仅仅指的是一个用来在不同角色之间执行交易或业务交互的概念。上一节提到过，在处理配置了角色控制的交易或交互（即合约）的时候，需要把一部分合格的节点挑选出来聚在一起，组成一个通道（Channel），等于组建起来一个“虚拟链”或“虚拟子网（subnet）”，这里很有点HyperLedger的感觉。

基于pBFT（实用拜占庭容错）的被OneLedger称为侧链共识算法（Sidechain Consensus Algorithm）的共识步骤将在所有参与者节点中被使用，只要多于2/3的参与者节点达成一致，就可以出块。算法具体步骤在2.3中介绍，主要两大步骤，预共识（Pre-consensus）和提交（Commit）。本层中的共识算法和2.3中公链共识层的区别在于仅仅用于OneLedger链上和链间的交互共识，本层共识不包含和公链交互的中间步骤（该步发生在预共识和提交两步之间的）。

通道可以横跨一个或最多两个业务模型（其实将业务模型换成模块更贴切），换句话说，通道内的角色可以来自于一个模块（链内）或最多两个模块（跨链）。后者需要将这两个业务模型内的角色分开进行共识，也就是说都需获得2/3以上的投票才算通过。

这里提到的链内交易是很容易被人理解的，但是跨链交易在白皮书中写的并不清晰，所以在这一点上码农和团队做了反复的探讨，实际上这里的意思是如果要做跨链交易的话，就需要再额外创建一个新的模块来启动一条中间链，并且该链相当于交易双方链的侧链。这个新模块代表的链作为一条独立的虚拟链，保存了双方的交易结果，然后再通过双向锚定把交换后的资产分别挪回原始链上。特别的，如果交易双方都是私有链或许可链，那么交易双方可以选择将机密内容存于自己的链上，跑在自己信任的节点上，而只把可以被公开的内容（比如用来交互的数字资产）提取出放到侧链上去，这条侧链可以是联盟链或公链。

先不谈实现的难易度，这个技术设想应该可以算是OneLedger独有的比较亮眼的创新点（虽然我不觉得有任何人能从白皮书里看出这弦外之音）。之所以不用HTLC来做内部链之间的跨链，而用第三条中间链的原因是为了交易数据保存的冗余性。HTLC虽然可以做到跨链转移，但是交易数据只存在于交易双方各自的链中。OneLedger的做法使得第三条链上或通道上存了完整的双方交易数据备份，出发点可能是为了应对比较鸡毛的企业级用户吧。从这一角度来说，OneLedger把自己的内部链都叫做侧链也没什么毛病，毕竟任何一条链但凡要和整个生态沟通，必然要借助侧链技术成为某条链的侧链。

一旦节点们达成共识，新产生的区块将被仅仅广播给通道内所有的参与者节点（局部广播），并被这些节点保存起来。任何一个节点如果有异议，可以发起仲裁，然后区块将被同样放到网络内所有节点内进行共识（这里可能需要更多推敲，如果是设定了角色控制的许可链模式，使用全网节点做共识是否会泄露隐私是个问题）。

此外，如果模块或流程中没有指定任何角色，那么共识将在整个OneLedger中的节点中进行。

因为每个节点可能被动态分配到不同通道里参与共识操作，所以在节点上是按照通道来保存区块数据的，而且每个节点上的区块高度可能不同。OneLedger引入了弹性分布式区块（Resilient Distributed Block，RDB）的概念，通过默克尔树（Merkle tree）将区块联系起来。

默克尔树在本文开头已经介绍过了。而弹性分布式区块的概念是将默克尔树运用在了区块本身而非区块内的交易。由此，每个节点上保存的区块之间的关系和结构可以被记录下来，可以快速查询是否该节点存有某个区块。示意图如下：

2.3 公链共识层（Public chain consensus）

该层主要用来对应通过OneLedger网络发起公链主网之间原子性转账的情况。

其中用到了完整的侧链共识算法（Sidechain Consensus Algorithm），分两步：

基于轮次的预共识步骤（Round based Pre-consensus）：用来获得一个超过2/3参与者同意的共识提案。这里说到的“轮次”包括了拥有相同时间限制的三个小步骤：

某节点A被选中来负责新区块的提案

所有收到提案区块的节点执行相应的合约，并对该区块进行预投票（Pre-vote）。预投票的结果在参与节点中被广播和收集。

一旦任一节点收到了超过2/3的预投票，会对该提案区块执行预提交（Pre-commit），如果没有节点在超时前没有收到这么多预投票，则进行新一轮的共识，并且将新一轮中每一步骤所需的时限拉长，直到收到一个预提交申请。

提交（commit）：到这一步，被提出的区块成为了已被预共识了的区块（Pre-consensus Block），仅当该提案涉及到两个公链间的跨链交易（比如以太坊和比特币之间），那么这个提案还会被额外驱动到公链上，并且接受公链上验证者对于是否可以执行资产的锁定或解锁的查验和投票。一旦该提案被同时被两个公链接受，那么新区块将正式被“提交”到OneLedger网络，一旦超过2/3的参与者完成提交，该区块则被最终敲定。

下图就是侧链共识算法完整步骤的图示。

其实从我角度看来，这层描述的应用场景不是一个强需求，因为OneLedger主打的就是通过内置的BTC侧链和ETH侧链把很多主链上以及主链间的交易挪到这些侧链上去，所以更加普遍的交易场景应该是用户在OneLedeger的两条侧链中完成了BTC和ETH的价值互换，然后用户可以选择适当的时机把每个资产分别从侧链挪回主链，并不一定需要同步的原子性互换。当然OneLedger试图通过这一层告诉读者，他们是可以做到主链间原子性互换的。另外，这里终于用到了我们耳熟能详的HTLC，不过主要是用来确保不同性能和出块速度的主链间交易的可靠性，更像是当作一个纯粹的“锁”来用的。

3. OneLedger区块链层

OneLedger中实际运行着的虚拟链们，包括OneLedger会陆续提供的以太坊侧链和比特币侧链，以及公司和个人为自己的业务场景设计出的内部区块链们。其中OneLedger提供的侧链可以和相应的公链主网进行数据状态同步（毕竟作为侧链）。

总结来说，OneLedger的抱负远大，理想也很高远，不过现实中要克服的难点也是有不少的。