PBM 要解决的问题是对货币进行编程。

撰文：孟岩

一周以前我们在卢旺达开会的时候，新加坡 MAS 在现场发布了 Purpose Bound Money （PBM） 的技术白皮书。行业媒体发了几条新闻，然后就放过去了。实际上 PBM 代表着货币当局对于数字货币编程问题迄今为止最深度的思考，其白皮书所反映思考深度和技术规范的详细与成熟度，简直不像是出自政府机构，而像是出自专业的数字货币和区块链学术机构。由于 PBM 似乎尚未引起圈内的高度关注，因此我觉得有必要简单介绍一下其基本要点。

PBM 要解决的问题是对货币进行编程。在现实世界支付中，设定各种支付条件和逻辑，比如什么时候可以支付、什么时候不能支付、可以支付给谁、什么时候支付、一次能支付多少等等，是非常普遍的需求。数字货币的一大卖点就是 programmable money，照理说这个应用应该很快推广开。但是具体实施的时候，对货币编程并不简单。在 PBM 之前，有两个对货币编程的主要模式：一是可编程支付（programmable payment），相当于是在支付函数上附加编程逻辑，比如运用数据库触发器和存储过程，或者区块链智能合约来对支付过程加以约束和引导。二是可编程货币（programmable money），直接把支付条件和逻辑内置到数字货币里面了。举例子比较容易说明。在 Web3 里，大多数面向 ERC-20 的支付、结算、交易智能合约都是属于可编程支付，它们处理的 ERC-20 token 本身都是中立、自由、无逻辑的，支付逻辑都写在智能合约里。而专门为表达 Security Token 所创建的 ERC-1400/1404 是典型的可编程货币，把限制白名单支付的逻辑直接内置在 token 合约内部了。可编程支付的优点是适应能力强，可以处理多种资产，缺点是难以在灵活性、安全性与简单性之间达成平衡。要灵活，合约就得写得特别复杂，复杂以后必然带来安全隐患。而要简单，就可能应对不了未来的新变化。我们在 Web3 之所以要花大钱去请人审计智能合约，就是因为功能稍微强大一点，智能合约就会变得非常复杂，安全性隐患就会非常突出。可编程货币的缺点则是流动性的碎片化。一种货币天生只能在某一个范围和条件内流转，几百几千种这样的「局部货币」就破坏了货币的同质化（fungibility），在市场上就会带来严重的流动性摩擦和估值困难，破坏货币作为价值媒介的功能。

PBM 就是为了解决以上问题而寻找的第三条路线。其核心要点是用一个「包装合约」来包裹和管理通用的数字货币，把支付逻辑放在这个「包装合约」里，去管理其中的数字货币。对应不同的应用场景，我们可以选择不同的「包装合约」来约束和管理被包装的数字货币，从而起到对支付过程和条件进行编程的效果。但这些被包装的数字货币本身都是统一的、中立的、自由的、同质化的，一旦条件满足，收款人可以从包装中提出数字货币，恢复数字货币自身的「无条件」天性。

我在这里的介绍十分简略而不全面，只是择要而论。MAS 的论文中详细讨论了三种模式的优缺点，而且详细定义了 PBM 应该具有的接口和特征，有兴趣的读者绝对应该仔细阅读一遍。

熟悉 ERC-3525 的读者看到这里，应该恍然大悟了，我对于 PBM 的关注不仅是作为区块链创业者的一般性的兴趣，而是「暗藏私货」，是出于 PBM 与 ERC-3525 的神契合。ERC-3525 就是作为这样的对数字资产进行编程管理的包装性技术提出的。我们所谓的「数字票据」，不就是对数字货币（也包括未来的数字货币现金流）进行包装、管理、约束和编程的工具吗？因此我可以毫不谦虚地说，ERC-3525 是目前实现 PBM 最好的协议，应该没有之一。读完白皮书，我觉得 ERC-3525 简直是为实现 PBM 量身定做的协议，然而事实上却是 ERC-3525 设计发布在前，而 PBM 发表在后。提前预判了重大的创新方向，对于做技术创新的团队来说，这毫无疑问也是人生一大快事。

当然，MAS 自己的 PBM 实现应该不是使用 ERC-3525，但我还是很高兴 MAS 从另一个完全不同的角度为 ERC-3525 确立了一个主要的应用场景和发展方向。我们将会积极支持 PBM。不久之后大家将会看到我们推出完全支持白皮书规定的所有接口的 ERC-3525 PBM。

附：PBM 白皮书可从以下页面下载：

https://www.mas.gov.sg/publications/monographs-or-information-paper/2023/purpose-bound-money-whitepaper