Blockchain区块链架构设计之五：让DLT产生协作，对Corda和GSL的思考

首页 > 币界资讯 > 区块链新闻 2017-02-02 16:35

摘要

让DLT产生协作：结合R3 Corda，对DAH GSL技术的思考去年年底，DAH公司发布了一份优秀的技术预览白皮书全局共享日志Global Synchronisation Log 简称GSL，这份白皮书有助于我们理解分布式账本系统设计的一些关键要素。它指出，应用于关键金融业务领域的分布式账本� 。

币界网报道：

让DLT产生协作：结合R3 Corda，对DAH GSL技术的思考

去年年底，DAH公司发布了一份优秀的技术预览白皮书 – 全局共享日志Global Synchronisation Log 简称GSL，这份白皮书有助于我们理解分布式账本系统设计的一些关键要素。它指出，应用于关键金融业务领域的分布式账本技术的正确架构应该是基于UTXO模型的，这与我们万达网络的设计理念一致。

dah

分布式账本技术可以解决什么问题？构建一个DLT系统的难点是什么？

分布式账本技术允许我们建立一个系统，让所有的关联方可以看到相关的数据并使用这些数据。在比特币和其他分布式账本技术出现之前，只有两种方式来实现这一点：1）我们可以建立一个中心化的基础设施平台，所有人完全遵从它的处理规则 2）我们可以建立属于我们自己的系统，然后花大量的时间来检查、核对所有最终的结果是否一致，这里可能存在大量的纠纷，也许最终的结果都是通过和解来达成共识的。这两种方式都不完美。比特币及受其启发的分布式账本系统向我们展示了第三种方式：我们可以使用密码学算法、共识算法和其他技术一起来保障我们的系统是全局同步的，这是一大进步。

但依然有一个问题困扰着当前的DLT领域，那就是全局数据共享。比特币及其衍生系统的解决方案提供了全局数据共享的账本，一方面，它为我们提供了许多优点：比如高可用性、数据全局复制、防篡改等等。但另一方面，它也造成了账本容量臃肿、工作量证明算法大量依赖算力的支持以及账本匿名使用产生的反洗钱监管漏洞。

这些都是商用化分布式账本技术正在着手解决的难题，R3的Corda重构了组成现有区块链平台的区块和链，他们根据所熟悉的JAVA线程模型、应用场景以及业务可以接受的妥协程度重新组合，形成一种适用于强监管环境的分布式账本技术解决方案。在这个场景中，我们发现有两个典型问题：1）交易验证 2）两个已验证交易是否彼此冲突

Corda将交易验证的问题交给交易参与方来处理：如果他们中的一个伪造智能合约的运行结果使之与实际结果不同，那么Corda会将争议交给“带外”系统来处理。因为Corda是一个许可制的分布式账本系统，系统中的成员知道彼此的身份，所以通过技术造假来获益的成本较高。

Corda将交易确认的问题交给一个独立观察员，它是一个大家都信任的角色，即仲裁者，他可以在两个同样有效但相互冲突的交易结果之间进行判断，使得哪个交易最终得到确认。在Corda里，这个观察者角色被称为Notary（公证人），而在比特币区块链中，我们称之为Miner 矿工。

通过这种处理方式，Corda解决了隐私保护和拓展性的问题。但是，作为一种妥协的方式，Corda方案失去了公有链当中全局广播和有效确认的特性。因此，在我们设计DLT平台时，首先必须要权衡哪些功能需要，哪些应用场景需要哪些功能并针对性的选择相关的模块，DLT作为一种技术集合，需要高度的模块化。

GSL的白皮书着眼于说明解决几项关键争议问题的思路，比如拒绝状态攻击、隐私保护和交易验证等等，两个典型的问题如下：

• 如果将一个完整的交易发送给公证人，因为公证人可以看到交易中的所有相关的数据，这可能导致隐私泄露。但是，如果我只发送需要查看的交易部分给公证人，然后我可以通过在确认“消耗”一个输入后执行一个拒绝状态攻击，停止随后被确认的有效交易，同时让公证人确认那些无效的交易。

• 向公证人发送的交易，公证人如何知道要通知哪些参与方？当我得到一个交易确认结果但是另一方还不知道的时候.（非同时到达交易结果），如果这个结果对我有利，我可以发起一个攻击使得交易结果不告诉其他方。

这些问题都非常棘手，在Corda中，相应的解决方法如下：

•“ 公证人隐私与拒绝状态攻击问题应该根据应用场景来选择对应的解决方案。因此，Corda支持需要查看所有数据的“验证公证人”和只查看部分数据以使他们能够确认交易的“非验证公证人”。Corda要求非验证公证人记录所有收到的签名交易，便于系统知道谁在试图作恶。

• 不过，如何通知的问题更加棘手：一个公证人需要知道你是谁以及如何联系你。如果使用全局广播，这就会成为隐私保护问题。因此，Corda赋予用户权利来决定选择信任公证人还是交易对手。

我们看到在GSL的白皮书里，他们的技术主张非常合理，与Corda有许多异曲同工的地方：

• DAH的GSL模型能够降低拒绝状态攻击的风险，而这在Corda的设计里是天生考虑的。

• GSL里，公证人只能看到为确定交易排序/唯一性所需的交易数据，而不是全部数据。

• 被确认的交易，需要保障同时被交易相关者收到。

GSL白皮书重点说明了如何处理通知问题，解决思路如下：

将应该知道交易的所有各方的身份添加到交易之外。这些信息是公证人可以看到的部分。
实际上，为了避免身份信息泄露，GSL并没有直接把身份信息加上，而是通过类似给交易打标签的方式把需要知道这个交易的每个人的列表加上。
虽然公证人无法看到大部分的交易内容，但是公证人可能并不知道这个列表是错误的。所以，GSL在交易验证逻辑中添加了一个附加规则：即如果交易没有标注正确的接收人列表，那么这个交易就是无效的。
所以你会发现GSL很酷：你可以执行任意交易，但是如果没有标记正确的交易接收人，公证是可以顺利通过的（公证人在GSL模型中是非验证公证人），只是“攻击者”什么好处都得不到，因为每个交易根据系统中的规则都会被认为是无效的，所以无论你如何作恶都会失败。如果构建的是有效交易，在公证人通知所有接收方并确认交易后就是不可逆的。所以一个作恶的角色不能拒绝有效、经过确认的交易。

GSL的解决方法将交易有效性问题与通知问题紧密结合起来，它实现了很多现实业务的需求：1）交易内容只有那些允许查看的人才能看到 2）交易验证掌握在交易参与方手中，公证人没有看到他们不该看的 3）如果交易被提交，那么交易参与方都可以接收到结果。GSL对于现实广泛的应用场景，是一个不错的权宜方案。