2019年8月19日
第17卷，第3期

案例研究

DAML：分布式账本的合约语言

Shaul Kfir 与 Camille Fournier 的对话

当 Shaul Kfir 在 2014 年共同创立 Digital Asset 时，他想要向金融服务行业证明一些事情。他认为金融服务行业不仅因低效的交易对账系统而受到阻碍，而且还可能错失区块链技术在解决其缺陷方面的潜力。

自那时起，Digital Asset 推出了其自身的分布式账本技术 DAML（数字资产建模语言）。它确实利用了区块链——只是方式与 Kfir 最初设想的略有不同。他和 Digital Asset 最终经历了一段工程“旅程”才达到今天的成就。

Kfir 坦率地承认，他自己在密码学和加密货币方面的背景——既是研究员（在以色列理工学院和麻省理工学院），又是以色列的加密货币企业家——对最初规划的路线产生了或多或少的影响。至于一路走来的经验教训，纽约市一家领先对冲基金的平台开发主管 Camille Fournier 在这里帮助引出这些教训。她将自己在分布式系统共识方面的背景（作为 Apache Zookeeper 项目的原始提交者之一）和金融服务方面的背景（曾任高盛技术副总裁）带入这次讨论。

CAMILLE FOURNIER 区块链在金融领域的一个拟议应用现在侧重于如何利用它来解决分布式账本问题。您认为目前对这一挑战的普遍看法是什么？

SHAUL KFIR 让我们首先考虑金融行业 IT 的现状。随着任何新产品被引入到这个高度互联的生态系统中，每个组织都会构建一个系统来处理新产品的工作流程。对于每个金融机构来说，这将只是众多类似系统之一——实际上非常相似，以至于它们复制了许多相同的功能。反过来，这些系统中的每一个都集成到其他内部系统中，这些系统都涉及到相同的账户、相同的资产和相同的参考数据。除此之外，每个组织还面临着与每个交易对手建立对账流程的问题。

这已经带来了两个主要问题。首先，如果行业中有 n 个新系统——每个组织一个——你很快就会得到大约 n² 个不同实体之间的新双边对账关系。其次，你最终会为每个新产品构建一个新系统，而不是共享现有的基础设施，并使产品有可能在彼此之上构建和组合。

随着金融行业或其中的任何产品不断成熟，自然的趋势是以中心辐射的方式围绕已建立的中心基础设施提供商进行集中，以便恢复到更像 n 种不同的关系，每个人都可以专注于与网络中心的基础设施提供商进行对账。

这里需要记住的另一件事是，这些系统的构建方式通常只允许以批量模式对一天内发生的所有交易的汇总进行对账。这是金融系统最初设计方式的历史遗留问题，远远不能满足当今金融世界的需求，仅仅是因为在一天结束时才能确定你拥有的资产和负债会带来太多的日内风险。

CF 您是说当前的模式过于依赖中心化的对账提供商，并且由于要等到一天结束才进行对账而增加了日内风险。用于交易对账的分布式账本将如何解决这两个问题？

SK 实际上，我还需要提到第三个问题——这是最关键的需要解决的问题。随着这种分布式工作流程的生态系统复杂性不断增长，推动创新变得越来越困难，因为每次更改都会迫使每个实体调整其自身的内部系统和流程。因此，变革的步伐最终陷入停滞。

试着将分布式账本想象成整个行业都可以访问的虚拟 SQL 数据库——当然，经过过滤，以便每个公司只能看到它被允许看到的内容。正是凭借这种心智模型，分布式账本设法通过两种主要方式解决这些问题。一种是在每笔交易的基础上实时对不同公司的账本进行对账，从而使一个共享数据库可以向每个公司准确显示其在任何时间点的状况。这意味着您不必等到一天结束才能确认您的头寸。

第二个主要优势是，分布式账本将新工作流程的推出转变为一个轻量级的过程。想象一下，一家公司通过简单地向该数据库添加新表和存储过程来提出新的工作流程——也就是说，通过做一些类似于 SaaS [软件即服务] 公司目前为持续推出功能所做的事情。这将减少摩擦，并因此加快创新步伐，因为现有的工作流程成为新工作流程的可组合元素。

为了澄清，请考虑大型科技公司如何利用其基础设施来实现更大的敏捷性。他们中的大多数今天都有一些逻辑上集中的基础设施，其中包括一个中央代码存储库和一个 CI/CD [持续集成/持续交付] 系统。如果这些想法可以扩展到行业层面，从某种意义上说，你可以开始推出工作流程，作为智能合约，只需编写一次，然后就可以供所有人在此基础上构建，这显然比让每个组织编写自己的工作流程更有效率。

CF 好的，但现在让我们退一步，谈谈分布式账本与金融网络中心的这些大型机构目前遵循的经典对账方法有何区别。

SK 按照目前的状况，这些大型机构掌握着许多不同市场的记录账本。至少有两个问题。一个是许多基础设施提供商使用的系统都很陈旧——也就是说，你不能使用 API 进入并获得实时视图，而是被迫等待当晚的批处理运行。分布式账本并没有直接解决这个问题，但它们的设计明确是为了利用现代技术。

这里还有第二个更根本的问题。一家大型金融机构不能处于需要信任对其他人基础设施的 API 调用来获悉其交易之一刚刚发生了数百万美元的变动。每个金融机构都持有自己的记录账本，可以在需要时参考。但是，由于交易双方至少有一方，这意味着将至少有两个账本在运行，这两个账本都需要围绕每个事件进行对账，因为它们都涉及相同的数据。分布式账本同步这些独立的账本，就好像它们是同一数据库的一部分一样，而实际上，每个账本都由交易的一方机构控制。

CF 所以，这不仅仅是技术过时的问题。至少在理论上，您是说中心化的对账提供商应该能够利用更新的硬件来变得更快、更以 API 驱动、更少以批处理驱动。但似乎交易对手并不真正信任中心化的第三方代表他们持有所有这些信息。相反，他们真正想要的是拥有他们自己的数据副本，无论如何。

SK 是的，因为他们需要验证，以及信任。

CF 分布式账本与中心化对账系统有何不同？

SK 首先，分布式账本当然是分布式的。每个机构都有一个特定于该机构资产的本地账本。从这个意义上说，账本是分布式的，以便每个实体都能够查看与其相关的数据碎片。与此同时，系统的完整性提供了保证——如果实体 A、实体 B 和实体 C 都拥有一些特定数据——他们对该数据的看法以及他们相对于该数据持有的头寸是一致的。

另一个区别是，今天大多数分布式账本都采用了区块链。但是，随着时间的推移，我认为我们会看到更多非区块链的分布式账本，它们仍然设法解决一致性和基础设施共享这些目标。区块链带来的等式是完全的信任——也就是说，每个实体如何知道其账本视图代表真相、全部真相，以及绝无虚假？

从工程角度来看，获得真相很容易。哈希是对某些数据真实性的承诺。

至于“绝无虚假”，则有签名来验证数据是正确的。

但还有“全部真相”。这就是区块链结构发挥作用的地方，附加式的哈希链提供了一种确保这一点的方法。

然而，这不是唯一实现这一目标的方法。我们需要区分区块链的技术含义——指的是维护变更的附加式链的不可变数据结构——以及更流行的行业对区块链的用法，后者可以指代任何与分布式账本有关的事物，或者，就此而言，可以指代任何可能用于跟踪某些分布式服务历史记录的事物。实际上，这就是为什么我们开始使用术语分布式账本技术——或 DLT——来暗示这种更广泛的观点。

CF 您一直谨慎地指出，区块链数据结构只是可用选项之一。是否有理由考虑其他选项？

SK 实际上，区块链存在一个问题。假设我们有两家不同的公司决定进行互换，一家公司借出一种资产，并获得另一种资产作为回报。每种资产恰好由不同的账本管理。处理这个问题的一种方法是使用两阶段提交，就像加密货币采用哈希锁一样。但这确实将负担放在了应用程序开发人员或您可能碰巧拥有的任何中间件身上。另一种选择是确保分布式账本是可组合的，并且在设计上能够无缝地合并和拆分。有很多方法可以实现这一点。

从概念上讲，区块链设计只是一条哈希链，因此实际上并不利于网络的可组合性。如果您想使用区块链而不牺牲网络的可组合性，则需要采取完全不同的方法。我认为分布式账本网络具有这种可组合性至关重要。

CF 在深入探讨区块链方面之前，我想知道在使用这种分布式账本方法解决中心化对账问题时，哪些部分被证明尤其具有挑战性。

SK 首先，我应该提供一些背景信息。首先，重要的是要承认，在任何分布式系统中，一致性、数据隐私和活性都是非常微妙的问题。然后还有一些更特定于分布式账本的东西。我们面临着确保机密性的挑战，即应该允许人们只看到直接与他们相关的数据片段，同时还要确保维护整体数据模型的完整性。这是一个细致入微的计算机科学问题，涉及协议的形式化分析。

第二件事——我认为这个问题在行业内没有得到广泛承认——与我称之为 SLA [服务级别协议] 的独立性有关，或者用计算机科学术语来说是活性。这意味着，在多方工作流程中，您不希望单个方的系统停机阻碍整个流程。例如，一旦交易所撮合了买方和卖方——称为执行——这在法律上是具有约束力的。如果我们试图采用大多数区块链使用的模型，交易所将通过与多方签名工作流程协调交易来报告交易。至少需要三个不同的方签署以确认交易：交易所、买方和卖方。实际上，总是超过三方。事实上，在所有不同的清算参与者、托管人等等之间，至少有七个不同的方需要签署每笔交易执行交易。

尽管如此，从法律角度来看，如果这些方之一的系统碰巧宕机或无响应，您不希望阻止整个工作流程，因为交易在法律上是具有约束力的，并且需要输入到账本中。维护活性——同时确保如果某事需要通过，它就会通过——是需要解决的不同问题。为了解决这个问题，我们基本上不得不构建一个非常细粒度的委托模型，类似于 OCAP [对象能力] 模型。

在 Kfir 及其 Digital Asset 团队努力构建用于交易对账的新系统时，他们学到的更重要的教训之一是，他们实际上处理的不仅仅是分布式系统问题。事实证明，远不止于此。

令他们惊讶的是，他们发现他们遇到的每个金融机构都以略微不同的方式实施了行业交易对账规范。这导致了最终对账中的值不一定与一家机构与另一家机构匹配。

这就是他们了解到他们还面临着重大的数据建模问题的原因。

CF 请详细告诉我区块链在您的分布式账本中扮演的角色。

SK 我们本身不使用区块链数据结构。目前的区块链主要与代币一起使用。无论是比特币、以太坊还是其他什么，它们都采用固有的第一类公民代币。但是，当你增加哪怕少量复杂性时，该模型很快就会开始崩溃。

问题在于，代币是金融世界中不记名票据的数字等价物。它们根本无法捕捉到细粒度的权利。例如，对于股票，所有者有权转让，而股份登记处有权拆分或合并。加密货币和类似的代币无法捕捉到这些类型的权利。

然后，随着投票权等公司行为的出现，事情变得更加复杂。这就是我们了解到我们需要提出一个非基于代币的抽象层的原因。这被证明非常具有挑战性。话虽如此，我们最终保留下来的比特币元素之一是它的状态管理模型，其中每笔交易都会消耗合约，然后创建新合约。

人们经常问我，“你们为什么觉得需要构建一种新的合约语言或新的抽象层？” 我告诉他们，我们基本上是被迫寻找一种新的范式。

正如 REST [具象状态传输] API 在 2000 年之前不存在一样，原因很简单，在 Web 出现之前，没有人真正需要 RESTful 架构，我们发现自己也处于类似的情况。我们正在解决一种新型问题——工作流程问题——并发现我们需要提出一种新的语言和新的抽象层。我们学会了不要害怕这样做。

有趣的是，在客户需求的驱动下，我们将我们的语言移植到了传统的 SQL 数据库，因为人们认为即使在实际上不需要分布式方面的情况下，它也为建模资产和工作流程提供了强大的抽象。

CF 好的，但我仍然想知道是什么最初让您想到区块链作为解决您的对账问题的潜在方案。是什么暗示区块链将是一个明显的选择？

SK 这只是我个人的天真。我们公司有其他来自其他学科的人，但我的背景是密码学和加密货币，所以我还在喝 2012 年的区块链酷爱饮料。这让我认为，“这些银行 IT 人员可能只是不知道他们在做什么，所以我会向他们展示区块链如何让事情变得更好。”

CF 这听起来有点熟悉。我想说你并不是唯一喝过那种酷爱饮料的人。

SK 随着我们开始深入研究，我们与许多金融机构的不同职位的人员进行了交谈，并开始看到一些令人不安的模式出现。其中之一是整个行业的创新步伐充其量也是缓慢的。这首先让我们想到，“好的，也许区块链在这里实际上确实有意义，因为智能合约语言真的可以帮助这些人更快地推出一些东西。”

但这也是我们真正将重点转移到更全面的观点的时候：“我们如何才能使这个行业更高效、更敏捷？” 这完全改变了我们的价值主张。我们今天的使命是通过构建强大的抽象以及强大的开发人员工具集来加速这些行业的创新步伐。

最初真正让我们感到惊讶的另一个因素与垃圾数据输入，垃圾数据输出问题有关。基本上，当我们试图弄清楚我们应该做什么时，我们发现几乎每种资产的数据结构和消息结构都非常糟糕。每个人似乎对数据应该如何呈现都有不同的看法，虽然大多数行业标准都详细说明了参与者之间消息的规范，但它们没有解决语义问题。因此，每个人都以不同的方式实施了交易对账规范。从底层到上层都存在这些差异。这导致了最终对账中的值实际上与一家机构与另一家机构不匹配。

一旦我们看到这一点，我们就知道这不仅仅是一个分布式系统问题，还是一个涉及抽象和数据结构的问题。那时我们开始以完全不同的方式处理事情。作为一家公司，我们意识到我们正在解决的问题比我们当时能够处理的问题更大。

一旦我们接受了这一点，我们就与另一家公司——总部位于苏黎世的 Elevence 联手，我们后来最终收购了该公司。Elevence 主要由编程语言专家、形式化方法专家和前数量分析师组成，他们一直在研究与我们一直在苦苦思索的相同的数据建模问题，并且他们已经意识到他们的方法特别适合分布式账本。另一方面，我们对我们的分布式账本工作感觉良好，但我们知道我们需要数据建模方面的帮助。事实证明，我们都很幸运能找到彼此。

CF 那么，您将您的分布式账本与 Elevence 的数据建模工作结合在一起，或多或少地解决了您的系统设计问题。但是，在您最初在分布式账本上完成的所有区块链工作中，还剩下什么？那部分工作被证明仍然稳定，并且至少对您来说有些用处？

SK 我们早期工作中最重要的剩余工作是分布式账本的强大抽象模型。也就是说，在设计理想领域语言和实用分布式账本之间的接口过程中，我们不得不设计一个正式指定的区块链抽象模型，其中包括数据结构模型、完整性模型和隐私模型。

虽然我们最初是为满足我们自己的内部需求而构建这一切，但事实证明它足够强大，可以让我们稍后将 DAML 与许多其他分布式账本集成，不仅包括我们自己的，还包括来自 VMware、Hyperledger 等的账本。这也使我们能够使用通用语言向用户介绍不同 DAML 平台之间的权衡。

CF 您是否遇到过任何其他您认为会在区块链世界中引起真正痛苦的问题？

SK 在某些情况下，要使区块链代币匹配起来将变得很困难。代币的表达能力不足以代表任何呈现出适度复杂性的应用程序。这往往会在所有区块链炒作中迷失方向。

我们还需要处理一个更大的问题——尽管这个问题在许多其他平台上似乎都不是什么大问题——那就是子交易隐私。即使在单个交易中，不同的实体对他们可以看到的内容也拥有不同的权利。例如，如果我和您要将股票换成现金，我们的银行应该只看到现金转移，而股份登记处应该只看到股票转移——即使我们两个人都能看到整个交易。如果还有其他区块链能够实现这一点，我们还不知道。

Kfir 和他的同事们的另一个重大发现是，他们正在解决的问题与其说是技术问题，不如说是不断增长的复杂性的普遍负担。也就是说，与其构建机构自己可以部署的定制解决方案，不如专注于创建工具，让每个机构的程序员都可以使用这些工具来创建自己的解决方案。

有了这个，重点转移到创建同步层，以为所有交易伙伴提供一致性，并辅之以合约语言和抽象层，该抽象层对系统功能提供足够的支持，以便让每个机构的开发人员更多地关注业务逻辑，而不是更传统的编程问题。

CF 您提到了您决定与 Elevence 合作并最终收购 Elevence，以便利用其在形式化方法和编程语言方面的专业知识。是什么促使您做出这个决定？您是否认为正是缺乏此类专业知识可能与多年来分布式账本领域发生的失败有关？

SK 我不会如此草率地将之前的努力标记为失败。我只是认为它们是分布式账本早期发生的事情。请记住，这些项目中的第一个项目始于 20 世纪 80 年代，远早于互联网繁荣时期。同样，我也不认为我们最初也失败了。我们朝着一个方向前进，然后才意识到我们最初的模型与加密货币有很多相似之处，许多人在复杂性随着时间的推移而增长的情况下很难使用它。基本上，您最终需要密码学或安全方面的博士学位才能编写您的分布式账本应用程序。这显然不会让我们非常接近实现我们提高生产力和加速创新的目标。

我们从一个非常基于代币的模型开始，但随后意识到，随着我们面临日益增长的复杂性，我们需要更加以工作流程为中心。实际上，我们转向了一个模型，在该模型中，您为需要执行的不同类型的事情拥有不同的操作类型，有点像 Ripple 交易类型。[Ripple 是一种基于共享公共账本的金融交易协议。] 这在 Ripple 的案例中效果很好，因为它专注于一个非常特定的领域——即支付。它可以将重点放在定义某些类型的交易上，作为您被允许使用系统执行的各种操作。

但是，与 Ripple 不同，我们并没有专注于特定领域，而是专注于为多个领域构建灵活的 SDK。对于其中的每一个，我们都有称为操作的单独的事务处理者类。但是，在进行代码审查的过程中，我们不断发现错误，这让我们得出结论，我们过于信任我们的 SDK 用户编写安全操作并处理签名和类似性质的事物的能力。

那时我们才意识到，我们需要停止每次遇到问题时都求助于定制解决方案，而是将注意力转向提出通用的编程补救措施。

起初，我们认为我们会编写一个抽象层并开发一种编程语言来配合它。但随后我们发现 Elevence 团队已经开发出一种自上而下的方法来解决此类问题。因此，归根结底，我们知道我们遇到了一个问题，而他们显然有解决方案。这太明显了。

CF 现在您将所有内容组合在一起后，您的架构是什么样的？

SK 有许多组件，但让我们从我们称之为抽象账本模型开始，这是一个可实现的规范，用于在各种账本上运行 DAML 应用程序——我指的是分布式账本和传统数据库、图形数据库、事件流，甚至是我们尚未想到的事物。显然，我们有我们自己的分布式账本平台，但它也得到了 PostgreSQL 和 VMware 等其他持久层实现的补充。

我们还有我们称之为 DAML 引擎的东西。DAML 是我们的合约语言，您可以将其视为为多方工作流程中的安全性而构建，而 DAML 引擎则提供以该语言编写的合约的解释。它还确保作用于分布式账本当前状态的授权命令产生与 DAML 中编写的合约语义一致的新状态。所有这些层都位于我们称之为账本服务器中的内容中，这是一个可交换的组件，它实现了抽象账本模型以及 DAML 程序的运行时环境。

其他账本提供商现在也使用我们开源的集成工具包实现了相同的 DAML 抽象和 API。这允许用户根据自己的需求和供应商偏好选择不同的区块链。

最重要的是一个应用程序和集成框架，它采用事件处理程序模型。这意味着应用程序可以对来自账本的事件做出反应，同时也可以向其提交命令。基本上，该框架提供了支持缓存、系统重启、优化等所需的所有属性。它关注这些类型的问题，以便开发人员可以专注于编写业务逻辑。这类似于使用 AWS [亚马逊网络服务]、GCP [谷歌云平台] 和 Microsoft Azure 提供的无服务器或 lambda 函数的体验。

CF 真令人印象深刻！还有什么吗？

SK 我们还有一个 SDK，它不是平台架构本身的一部分，但它确实带有一个嵌入式分布式账本模拟器，以及一种测试语言，该语言提供了分布式账本的完整语义模型——这意味着如果它可以在您的本地机器上运行，它也可以在平台上运行。其中包括分析工具，这些工具利用语言的结构来检查常见错误和授权逻辑。从您编写的合约中，它可以推导出网络上所有不同参与者中，谁应该有权查看此特定数据。所有授权逻辑都由工作流程驱动，因此您作为开发人员不必自己指定任何内容。

CF 您是如何做到的？

SK 这实际上来自语言的结构。当您指定您的业务逻辑时，您就指定了工作流程。然后，参考函数签名，您可以看到将受此合约影响或可能在以后受到影响的所有网络参与者。这使您可以分析合约未来所有演变的情况。

CF 太酷了！听起来您最终得到了一些可能非常强大的东西。现在告诉我您一路走来学到的一些更有趣的工程经验教训。

SK 从工程管理角度来看，我有很多东西需要学习。我从一个研究尖端零知识证明和 SNARK [简洁非交互式知识论证] 的密码学家转型而来，所以我的意图只是在我们创立公司时继续使用所有这些很酷的工具。好吧，正如代币模型未能达到我们的期望一样，尖端加密技术也不是那么适合。这是一个教训。

另一个教训是，虽然我以前从未用函数式编程语言编写过代码，但我现在完全转变为函数式编程和强类型语言的拥护者。我已经开始相信，整个行业需要朝着防御性编程技术发展。函数式编程和强类型是可用于此目的的最佳工具之一。

我还了解到，您永远不能与您拥有的工具或您构建的代码紧密结合。在公司成立一年后，我们已经完全废弃了我们编写的所有代码，并放弃了我们使用的大部分工具。也许我们应该更早地注意到我们可以管理账本本身上的所有状态，但重要的是我们最终确实发现了这一点。这主要是因为我们倾听了客户的意见，以找出他们的真正问题所在。这就是我们发现我们走错了方向的原因。请注意，我们并没有完全按照客户告诉我们的应该如何做来解决这些问题，因为那样也会使我们完全偏离轨道。

我还了解到，您需要仔细考虑每一个权衡。我给你举个例子：区块链的不可变性使得从数据损坏中进行解决和恢复成为一个非同小可的问题。埃森哲发布了一篇宣传可变区块链的论文，并因此受到嘲笑。我来自区块链社区，我理解嘲笑的原因，但论文本身实际上相当平衡。只是区块链的真正信徒真的无法以公正的方式阅读它。我已经了解到你不能像那样教条主义，因为你需要能够自由地对你遇到的每一个重要的权衡采取分析方法。

CF 如果您为分布式账本构建的这个模型以及您用于定义它们的形式化方法被广泛采用，您预计会发生哪些类型的变化？我问这个问题是因为您说您希望实现的目标之一是开放整个行业的创新。

SK 我认为我们会看到与网络世界类似的寒武纪大爆发，就像当初我们开始在公有云和框架中使用共同基础设施时一样。我经常引用的一个例子是，几年前我在以色列创办比特币经纪公司时，我对网络开发一窍不通，因为当时我还是一个非常底层的汇编语言和密码学爱好者。但后来我只用了三周时间就学会了足够的 Ruby on Rails 和 Heroku，推出了该经纪公司的第一个管理系统版本。那是因为我只需要考虑模型、视图和控制器——也就是说，只需要考虑业务流程。当然，最困难的部分是构建一个安全的钱包，但那是我的专长。

总之，回到今天的银行业，如果我们看看目前所有拥有共同工作流程的金融机构网络，你会发现没有任何框架、抽象层或共同基础设施。对于那些有好想法的人来说，没有任何东西可以用来快速推出新系统，然后对其进行迭代或升级。这意味着，如果有人提出了金融创新，例如，可以在医疗保健领域中使用以降低支付交易对手风险，那么目前根本没有简单的方法来部署它。

但是，如果我们发现自己身处一个每个大型企业都是分布式网络一部分的世界，而这些网络确实实现了基础设施的共同化，那么人们将能够非常快速地迭代这些想法。基本上，他们将能够提出新产品并将其部署为智能合约。事实证明，这种影响在一些迄今为止创新步伐缓慢的大型行业中可能尤其显着。我认为那里的潜力可能是巨大的。

比特币的学术渊源
加密货币的概念建立在研究文献中被遗忘的思想之上。
Arvind Narayanan 和 Jeremy Clark
https://queue.org.cn/detail.cfm?id=3136559

实践研究：加密货币、区块链和智能合约
专家策划的最佳计算机科学研究指南
Arvind Narayanan 和 Andrew Miller
https://queue.org.cn/detail.cfm?id=3043967

比特币的潜在激励机制
支配比特币协议的看不见的经济力量
Yonatan Sompolinsky 和 Aviv Zohar
https://queue.org.cn/detail.cfm?id=3168362

最初发表于 Queue vol. 17, no. 3—
在数字图书馆中评论这篇文章

更多相关文章

Theo Schlossnagle, Justin Sheehy, Chris McCubbin - 永远在线的时序数据库：在无法追赶的情况下保持领先
如果您发现需要提供从断开连接的操作中捕获数据的功能，以便不同的各方可能同时进行更新而不会发生冲突，该怎么办？如果您的服务要求您几乎全天候持续接收大量数据，以至于您真的无法承受在任何时候中断数据摄取，以免发现自己远远落后于当前状态，以至于几乎无法追赶，又该怎么办？