日本央行岸道信：欧洲央行、日本央行合作项目Stellar已完成第三阶段的同步跨境支付研究

文丨互链脉搏编辑部
未经授权，不得转载!

【互链脉搏讯】2019年9月17日，第五届区块链全球峰会“区块链新经济：新十年·新起点”在上海召开。峰会论坛上，日本央行支付和结算系统局参事役岸道信进行了“Stella项目第3阶段: 即时跨境支付”主题演讲。互链脉搏授权发布演讲实录，未经本人审阅。

（日本央行支付和结算系统局参事役岸道信）

以下为演讲实录：

岸道信：谢谢主持人的介绍，谢谢主办方邀请我在这里发言。我的名字是岸道信，是日本央行支付和结算系统局参事役，负责Stella项目。Stella是一个欧洲央行、日本央行合作的项目，关于分布式账本。

自人类发展以来有三个发明：（1）火；（2）轮子；（3）中央银行。当然了，中央银行这部分似乎是夸张了，应该不是人类的三大发明之一，但我非常荣幸能够参与今天这样一个重要的会议，和各位专业人员一起探讨区块链技术。

首先，讲一下Stella项目的目的。

Stella项目主要是深化分布式账本技术知识，看看是不是能够通过采购新技术来完善现有的基础架构，同时也为现有概念性研究和实验性工作做出贡献，共同探讨分布式账本技术对金融市场基础设施的机会和挑战。

金融市场基础设施包括了央行、人行、欧洲央行、日本央行等，我们所做的分析和实验结果并不是为了代替、补充现有安排。已经完成了项目的第三阶段：

第一阶段在2016年12月推出，一直持续到2017年9月份。第一阶段的工作主要复制了流动性节省机制，特别是大型价值转移系统中的机制。在效率和安全性方面进行了大量的测试，获得了定量的结果，这应该是有史以来第一次关于效率和安全性方面的测试。

第二阶段持续到2018年3月份，主要将分布式账本技术应用在证券交付上。

第三阶段持续到2019年6月份，主要研究的是及时跨境支付。实验中用的平台在第一阶段是Hyperledger Fabric v0.6.1版本。

第二阶段用的是Corda，希望了解不同平台的区别。

第三阶段用了Hyperledger Fabric v1.2.1版本。选择平台决定主要是看文件的可用性以及相关的用例。

第三阶段的动机是什么呢？跨境支付涉及到不同管辖区域内的不同实体，常常非常慢、成本又高，特别是和国内的支付而言。

现在确实有一些项目旨在解决跨境支付当前低效率的问题，比如说SWIFT gpi。但是，跨支付账本交易的安全问题仍然是很大的挑战。

给大家举一个例子，假设欧洲区发送者想发送1亿日元给日本的接受者，如果第一实体代理行，在转账第一层完成之后就破产了，也就是说100万欧元从A转到B，完成之后B实体就破产了，但第二层还没完成，那A实体实际上会损失所有的资金。如果这两层付款是同时进行的话就能减少分析，可以用哈希时间所合约来解决问题。

分析一下用例，跨境支付实际上是由基础链组成，基础链包括了支付者、接受者、付款人、收款人、账本、支付方式。

支付方式实际上是取决于在支付指令发布后支付是否立即结算区分的，我们想要关注于支付方式的安全安全。

所以，在第三阶段采取了哪些方法？主要关注的是在跨境支付、跨境交易中的安全性。

安全支付方式有什么特点？分析了使用哈希时间所合约的支付方式以及不使用哈希时间所方式的方法。在发现安全的支付方式后想要分析不同账本间交易。比如说中央化账本和DLT账本之间的交易、DLT账本间的交易。

基于第二阶段，在第三阶段的时候用了哈希时间所合约来实现多个支付的同步进行，同时评估了多账本交易的信用风险，看看是否会得到降低。并没有研究操作风险和外汇风险，哈希时间所合约包含加密哈希函数以及时间所函数。加密哈希函数实际上是“H”，Y=H（X），X是源项，而Y是哈希值，如果从Y中找到X是非常难的。

不依赖于哈希时间所合约的付款方式也被考虑在内，实际上和二阶段相比是扩展。评估了五种支付方式的安全性，在谈到安全支付方式的时候意味着如果那些完全履行了交易过程中责任的交易方不会曝露在信用风险中，如果这样的话，那支付的方式就是安全的。

列出了所评估的五种支付方式：横轴可以看到交易在账上还是账下进行，托管账户还是锁定账户，有没有支付执行机制、有没有具体的账本要求。我们发现三种支付方式包括：账上托管、使用哈希时间所合约第三方托管；使用哈希时间所有条件的支付条件。这三种支付方式都有付款的执行机制。

第一种支付方式是用HTLC的账上托管以及第三种HTLC的有条件支付渠道，能够看到是由账本来执行的。而第三方托管的执行是由第三方负责的。

在五种支付方式中有三种支付方式能够确保安全跨境支付的，安全性的分析有几点前提：托管资金是安全的，不会受到付款人破产的影响，参与者和账本有充足的处理能力。

接下来详细说一说安全的支付方式是如何运作的，用在哈希时间所合约的账上托管为例。

第一步是准备阶段，收款人要提供源项及其哈希值，收款人要通知发送人哈希值和超时值，比如说今天下午3点钟。第二步是发送者要求账本1托管100万欧元，发送者通知连接行以及账本1哈希值和超时时间，比如说今天下午5点钟。第三步连接行也会请求账本2在T时间之前托管1亿日元，连接行还会通知收款人以及账本2哈希值和超时的时间，比如说今天下午的一点钟。

如果收款人在T2之前就像账本2提交了源项，托管的资金/基金会转给收款人，连接行在5点钟之前把源项提交给账本1，如果这样的话托管资金会转给连接行。这就是及时以及安全支付方式的特点。

虽然1点钟和5点钟确实存在着差距，但这两层付款都是安全执行的，因为资金是托管在账本之上的，所以即使付款人出现了破产，资金也能够得到保护。

接下来谈一谈那些安全性能特别差的支付方式，以Trustline为例，Trustline有三个阶段：

第一阶段，付款人和收款人会达成共识，在不结算的情况下能够达成的最大金额达成共识。但付款人的资金并没有托管，首先付款人向收款人承诺，如果收款人在超时之前提交源项就会付款执行，也就是说收款人要在超时之前向转款人提供源项，同时借记付款人以及代记收款人。

为什么这种方法是不安全的？付款人的资金是没有托管的，如果在结算阶段之前付款人违约的话收款人是拿不到钱的。分析了一方违约情况下的场景。

假设双方之前做了准备，现在已经进入到了执行阶段，那在收款人和连接行执行了之后，比如在连接行1和2之间的执行之前连接行1就已经违约了，也就是说连接行2没有办法获得资金，在违约的场景下假设各方之间都采用安全的支付方式，即使连接行1和连接行2都采用安全的支付方式，就算连接行1违约了，那连接行2仍然能够收到资金，因为所有的资金都是得到托管的。

我们发现了三种安全的支付方式，也要尝试一下如何应用不同的账户上。可以看到测试了几种及时结算的方式，获得了成功的结果：

第一，用了Interledger.js来进行开源的实现。ILVPv3版本是比较老的版本，是用来实现中心化的账本，我们用的是Five Bells Ledger作为中心化的账本。Stella上的工程师最新实现了Hyperledger Fabric中LP的插件。

这是我们实验设置的例子，用在跨平台环境中。跨平台是什么意思？第一层用的是Hyperledger Fabric；第二层用的是Five Bells Ledger（中心化账本），研究结果非常成功。

研究结果是什么呢？第三阶段评估了五种支付方式，只有那种拥有执行机制的支付方式才能确保资金的安全性。通过实验发现了不同类型的账本之间支付是有技术可行性的，包括分布式账本和中心化账本之间的结算。

从技术角度，当前跨境支付安全性是可以进一步提升的，可以用支付方式实现付款同步，同时能够锁定支付链上的资金。但是，我们也应该意识到，要进行实际实现必须要考虑到法律和合规方面的问题，同时要考虑到技术的成熟性也要做成本效益的分析。

谢谢大家的聆听。

请备注来意，谢谢！