一文读懂三式记账法（下）

干货 | 三式记账法（上）

以带签名的收据作为簿记系统

收据即事务的原则越来越凸显出其重要性。我们的客户端软件在设计上也贯彻了这一原则，从而简化记账系统，提供更高的可靠性。但问题依然存在，例如，客户端软件丢失收据并因此使余额统计出错。但是，一旦设计者将收据即事务视为首要原则，这些问题就都能迎刃而解。

单式记账

为了根据一组相关收据计算余额，或呈现事务历史记录，我们需要基于收据集合动态构建账簿。这就相当于将带有签名的收据作为单式记账系统的基础。事实上，簿记由原始收据衍生而来，这就带来了一个问题：是否要保存这些账簿。

我们可以从关系数据库的原则中找到答案。根据 第四范式（译者注：数据库正规化中用到的一种形式），我们存储主要记录（在此语境下就是收据集合），并动态构建衍生记录和会计账簿 9。

复式记账

身为发行者的 Ivan 也遇到了同样的问题。服务器必须根据受影响的账簿中的可用余额接受每一笔新事务。因此，Ivan 需要找到一种方法来高效使用这些账簿。由于收据和账簿（每个用户账户都有一个账簿）数量庞大，这些收据和账簿都将保存下来（与第四范式截然相反）。将具有关联性的收据集合和复式账簿结合起来会有帮助。

在服务器的架构中，Alice 和 Bob 各自会被赋予一个账簿。按照惯例，我们会将这些账簿记作负债。然后，收据会被放到另一个单独的账簿中记作资产。Alice 和 Bob 之间的每笔事务都有一个逻辑上对应的条目（contra entry），然后在服务器账户中的 3 个地方显示。不过，资产端的数据仍会保持第四范式的形式，因为资产端的条目被推导出来时，每一对条目都来自资产端的一个条目（译者注：即收据）。

展开来说， Alice 或 Bob 所用的客户端软件，（愿意做得高级一些就）可以采用同样的方法。在这种极端情况下，条目保存在三个不同的地方，而且每个地方都有可能存在三个记录。

三式记账

带数字签名的收据、可明确表达的对一笔事务的完整授权，对复式记账法构成了巨大威胁，至少从概念层面来说是这样。数字签名这一密码学发明为收据提供了强有力的证明，并将记账问题缩小到收据存在与否的问题。这一问题的解决方案就是共享记录 —— 让每个主体都持有一个正确的副本。

如果严格依照关系数据库理论，复式记账法已然成了多余的。根据第四范式，它已经被排除在标准之外。然而，这更多是从理论而非实践上来说的。在我们所构建的软件系统中，复式记账法和三式记账法同时存在、协同工作。

这就导致成对的复式条目通过中心化的收据列表相互关联。每个事务都有 3 个条目。每个记账主体都要保存 3 个条目，如果考虑到事务所涉及的 3 个参与方，就变成了 9 个条目。

这就是我们所说的 三式记账法。虽然带有数字签名的收据在信息方面占据优势，但是在处理方面处于劣势。复式记账法弥补了三式记账法在处理方面的不足，因此二者更适合协同工作。从这个意义上来说，三式记账法是一种进步，而非一场革命。

软件方面的考虑因素

从软件和数据角度来说，目前还没有制定一个明确的条目布局，这最终可能会成为短期实现问题之一。带有签名的收据可能会形成一个天然的资产方对应账户（contra account），或者形成一个独立的非账簿清单、化作一个记账系统及其资产记录和负债记录的基础。

基于收据构建账簿会产生审计问题，收据丢失时会产生标准化问题。这些问题都是未来研究的方向。

值得一提的是，签署收据的技术既可以使用私钥签名，也可以使用纠缠消息摘要签名。相应的技术是否具有足够高的安全性则取决于业务环境。

主体的角色

请注意，在上述三式记账法的设计中，Alice 和 Bob 都是具有一定独立性的主体。由此可见，三式记账法不仅可以作为记账系统，还可以作为数字现金系统。

这一设计并没有脱离会计专业，而是引入数字现金来代替公司记账。如果公司或其它管理实体的记账系统被重塑为数字现金（或内部货币）系统，则经验表明相关组织会从中受益。

虽然这一系统的核心看起来与记账系统并无差别，但是每个部门的账簿都变成了数字现金账户。各部门不再需要在制定预算上耗费太多精力，因为它们可以控制自己的资金。基本的治理控制权依然掌握在会计部门手中，因为该部门是记账系统的运行方，而且资金只能在组织内部使用。会计部门可能会充当做市商的角色，将内部货币付款兑换成外部货币付款来支付给外部供应商。

我们已经小规模运行了该系统。该系统不仅没有出现效率低下的问题，还大幅降低了协调成本。账单和工资都不再使用传统货币支付。许多交易都是通过内部货币转账处理的。在组织边缘，正式主体和非正式主体进行内外部货币兑换。文书工作大量减少，因为货币系统的记录已经足够可靠，即使在事件发生多年后，也能快速解决问题。

虽然内部货币的创新不属于本文的讨论范围，但是它们可以回答一个显而易见的问题：为什么这种三式记账法设计源于数字现金，又与企业界息息相关。

商业的模式

Todd Boyle 从互联网时代小型企业需求的角度探究了这一问题，并得出了相同的结论 —— 三式记账法 10。他的前提是：

主要的需求不是记账或支付本身，而是交换模式 —— 复杂的交易模式；

小型企业负担不起采取这类模式的大型复杂系统的成本；

小型企业不会将自己锁定在专有框架中。

在此基础上，Boyle 的结论是，小型企业需要一个提供公平访问权限的共享存储库。从根本上来说，这个库类似于记录事务条目的传统复式分类账【“GLT”—— General Ledger-Transaction（总帐-交易）】，然而它的条目是动态且共享的。

举例来说，Alice 创建了一个事务，她将这个事务输入她的软件。每个 GLT 事务都需要注明她的外部对手方 Bob 的名字。当她公布这个事务时，她的软件会将其存入她的本地 GLT，并提交至共享存储库服务的 GLT。

然后，共享事务存储库（STR，Shared Transaction Repository）会将这个事务转发给 Bob。Bob 和 Alice 存储该事务的句柄（handle）作为索引或桩（stub），由 STR 存储完整的事务。

Boyle 的想法在逻辑上与 Grigg 和 Howland 的想法类似，尽管二者的出发点不同（STR 就等同于上文提到的 Ivan），观点也不完全相同。Grigg 和 Howland 的想法仅限于付款、数量的准确性以及如何利用密码学来保障安全性。Boyle 则着眼于更广泛的事务模式，并证明了如果我们可以提取核心共享数据并将生成一条共享记录，STR 就可以协调这些事务。Boyle 的关注点在于事务的经济实质。

发票

想象一个简单的发票开具流程。Alice 创建了一个发票并通过自己的软件（GLT）发布出去。由于她已经在发票上注明了对手方是 Bob，GLT 会自动将该发票转发给 Ivan（STR），再由 Ivan 转发给 Bob。这时，Bob 需要决定是接受还是拒绝。如果 Bob 接受了，他的软件就会发送一条接受消息给 Ivan。STR 就会生成一条“已接受发票”记录来代替之前的“待确认发票”记录，并发布到 3 个地方。在（支付条款规定的）相应时间，Bob 会发布一个单独的事务来支付该发票。这在运作上很大程度类似单独的事务，直接链接至原始发票。

由于 Bob 的付款链接至发票，且发票是包含在三个记账系统中三个条目内的实时事务，我们或许能够通过已更新发票记录来引用付款活动。当付款完成时，新的记录会再度替换掉之前的未付款记录，并发布给 3 个参与方。

事务模式

我们可以编写软件来促进并监控该流程以及类似流程。如果付款系统具有足够的灵活性并与用户需求相结合，我们就有可能在收据层面将上述发票与付款本身合并。从这个角度来看，带有签名的收据所提供的李嘉图式合约是所有通用模式中最简单的一种。我们认为 “收据即事务” 这一狭隘的理论可以扩展为 “发票即事务”。

在商业世界中，每一个事务都不是孤立的，而是有模式的。例如，要约（offer）与承诺（acceptance）构成一个较宽泛的事务，但是很少覆盖整个履约和付款周期。即使有了带有采购订单消息的付款，客户也要等待履约。

关于这些事务模式已经有了大量研究和文献成果。ebXML 业务流程工作组等标准制定团体已经采用了这些模式，并称之为“商业交易”。然而，如今我们所做的是将这些事务分解成原子。这就是我们目前的方向。

三式记账法的必备条件

三式记账法的实现会在不断的演化过程中支撑这些事务模式。显然，复式记账法已经不足以支撑这些模式，因为一旦参与方超过 1 个，这个框架就会失败。虽然复式记账法不适用于网络，并且无法满足商业需求，但是三式记账法没有得到广泛理解，它对基础设施的要求也没有得到高度认可。

以下是我们认为重要的必备条件 11 12：

强假名性，这是最起码的。由于事务模式中有很多循环，系统必须支持参与者之间存在清晰的关系。这至少需要具有李嘉图式合约或 AADS 特性的署名架构。（这是一个明确的要求，但是本文篇幅有限，不作深入讨论。）

条目签名。为了中和各参与方之间互相施加的威胁，我们需要一个机制来封存并确认基础数据。这就是签名，我们要求所有条目都能携带数字签名（上文要求 1 将要求我们使用公钥签名）。

消息传递。该系统从根本上来说是一种消息传递系统，与网络上大多数基于连接的架构形成鲜明的对比。Boyle 早就认识到，通用消息传递特性是一大关键。在 2001 至 2004 年间 13，Systemics 就提议并将这个特性构建到了李嘉图合约中。

条目扩张和迁移。消息的每个新版本都代表一个将要更新或添加的条目。当每个消息添加到之前的会话时，已存储条目需要扩张并吸收新的信息，同时保留其它特性。

本地条目存储和报告。条目的持久存储和响应可得性。实际上，这是典型的会计总分类账，至少从存储的角度来说是这样。它需要经过一些调整才能处理更加灵活的条目，而且其报告功能会变得更加重要，因为该功能会在需求或实时基础上进行内部协调。

整合硬支付。贸易的效率不可能高于支付的效率。也就是说，支付部分的效率必须与其他部分一样高；在实践中，这也意味着支付系统必须内置在架构层。

集成应用层的消息服务。与协议底层的消息服务（见要求 1）不同，Alice 和 Bob 还必须能够磋商。因为绝大多数的模式都围绕着主体之间的基本沟通。建立更好的支付和发票机制并不能替代沟通和谈判的机制。这个概念可能在 SWIFT 系统上表现得最明显：SWIFT 从头到尾只是一个消息系统，负责分发支付的指令。

结论

复式簿记法提供了事务意图和来源的证据，使我们有办法能区分无心之失和欺诈。而带签名的收据这一金融密码学创新提供了同样的好处，因此挑战了复式记账长达 800 年的统治地位。实际上，从证据的角度来看，（因为数字签名的一系列技术属性）带签名的收据比复式账本的记录强大得多。

严格比较起来，带签名的收据还是有一些弱点。首先，在三式记账法的李嘉图式实例中，收据可能会丢失，或被有意移除，因此我们要强调一个原则是 “条目即事务（the entry is the transaction）”。结果是，三个主体会自己负责保管签过名的条目，作为最重要的事务记录。

其次，三式记账需要用到软件，没办法像复式记账那么方便。出于这个原因，我们将收据中包含的信息扩展成为一组复式的账本，如此一来，在每一个节点上我们都可以两全其美：既能获得带签名收据的证据力量，又能获得复试记账的便利性和本地的交叉查验能力。

这些解决方案都将带签名的收据与复式记账如何在一起。最后，我们获得了一个三乘三的逻辑序列，我们认为 “三式记账” 一词可以准确描述此一对旧式记账方法的改进。

引入主体

为了得到三式记账所有的好处，我们必须将记账系统拓展到为其他主体服务，并赋予他们直接发起事务的能力。也就是说，我们通过向主体发放内部货币 14，使他们成为系统的利益相关者。使用电子现金系统来做公司的账户，可以让电子现金在整体上替代使用账簿和部门预算的会计系统；并且，也能通过对带签名收据的使用，为验证和审计中心化的账户系统打开大门。

解决欺诈

实现了所有这些之后，治理流程将可得到极大的便利。账户将变得难以更改，也会变得透明很多。我们认为，有了这些技术，那些千奇百怪的丑闻和治理失败就都不会发生了：共同基金的丑闻将有清晰的事务踪迹可供审计，因此被推迟标记（late timing）的事务以及被扭曲或丢弃的事务都可以得到清晰的定位，或被完全消除 15。美国正在上演的、叫做 “股票门” 的丑闻也不会再发生，因为带签名的收据可以揭露为操纵市场而伪造的股票和价值。类似地，如果账户都围绕着很透明的电子现金组织起来，辅之以公开、不能删减的带签名的收据（可作为无形账户（88888）的证明），巴林银行也不会在投资银行界消失。更直接的 “追踪金钱流向”的治理，也将能揭开那些令人眼花缭乱、但在经济上毫无意义的交换活动的面纱，扼杀安然公司丑闻这样的案件。