?

新加坡金管局的 Ubin 項目已經進行了五個階段的研究工作，研究領域包括新加坡元的 Token 化、支付系統、券款對付、同步跨境轉賬。本文對 Ubin 項目的研究工作進行分析和總結，從中可以看出新加坡金管局對 DLT 的重點應用方向。在 DLT 的研究中，各國央行都非常重視對 HTLC 的應用。

Ubin 是新加坡金管局（MAS）開展的研究項目，其研究目標是探索區塊鏈和分布式賬本技術（DLT）在貨幣 Token 化、支付系統、券款對付、同步跨境轉賬等領域中的應用，旨在解決金融業和區塊鏈生態系統所面臨的實際問題。目前，Ubin 項目進行了五個階段的研究工作，并公開發布了前四階段的研究報告。

第一階段

Ubin 項目第一階段的主要研究工作包括將新加坡元（SGD）進行 Token 化，并使用 DLT 完成跨行轉賬，同時評估 DLT 對新加坡金融生態的潛在影響。參與 Ubin 項目第一階段的成員有 MAS、美林銀行、星展銀行、匯豐銀行和摩根大通等。

研究目標

Ubin 項目第一階段的研究目標分為兩部分。

一是基于分布式賬本為境內銀行之間的轉賬系統建立一個概念設計原型，這個分布式賬本上記錄的每個銀行的余額是由其在央行的存款準備金支撐的。概念設計原型中應該包括以下幾點：記錄所有參與者余額的分布式賬本，在分布式賬本上參與者可以實時開戶、轉賬和銷戶，在分布式賬本上參與者可以實時、全天候完成轉賬，將分布式賬本與現有的央行結算基礎設施整合。

二是研究 DLT 在實際應用中的非技術影響。例如，貨幣 Token 化對貨幣政策、市場規則、貨幣供應、金融市場基礎設施的原則或系統性風險、監管政策等方面的影響。

研究方法

針對上述兩部分研究目標，Ubin 項目第一階段分別開展了技術工作和研究工作：技術工作聚焦于概念設計原型，研究工作則聚焦于 DLT 的潛在影響。

技術工作

Ubin 項目第一階段的概念設計原型中使用了現有 Jasper 項目和 BCS 信息系統（BCSIS 區塊鏈）的部分設計組件。在原型設計中，Ubin 項目在分布式賬本上為 Token 化的存托憑證（Depository Receipts，DR）創建了存托憑證資金托管賬戶。

Ubin 項目第一階段的分布式賬本是基于以太坊的私有鏈。下圖是 Ubin 項目的結構示意圖，展示參與者（包括銀行和用戶）通過分布式賬本進行轉賬，以及存托憑證的抵押和贖回。

圖 1：Ubin 項目的結構示意圖

Ubin 項目第一階段的結構示意圖中包含兩個單獨的系統，這兩個系統可以綜合使用以提高不同賬戶之間的轉賬效率。MEPS+（即 MAS Electronic Payment System，是 SGD 的全額實時結算系統）用來處理銀行間的 SGD 轉賬，區塊鏈系統用來處理參與者錢包之間的轉賬。通過將轉賬資金合并到存托憑證，MEPS+和區塊鏈這兩個系統可以有機結合起來，銀行間的 SGD 轉賬轉化成參與者錢包之間的轉賬。整個轉賬流程的步驟如下。

第一，資金劃轉和抵押。參與者 A 在當前賬戶（即下圖中 CA 賬戶）中的資金會劃轉到全額實時結算（RTGS）賬戶。參與者 A 向 MEPS+發送請求，開通區塊鏈賬戶（即下圖中 BCA 賬戶）。參與者 A 在 RTGS 賬戶中的資金會轉到區塊鏈賬戶。此時，區塊鏈賬戶中的資金就可以用來抵押生成存托憑證。在這個階段，MAS 必須驗證抵押品的有效性以便后續發行存托憑證。

第二，MAS 通過智能合約向參與者 A 的錢包中發放存托憑證。如果參與者 A 的區塊鏈賬戶中有 300 SGD，那么參與者 A 的錢包中就會有價值 300 SGD 的存托憑證。存托憑證是 MEPS+和區塊鏈之間的連接。

第三，基于區塊鏈，參與者 A 可以向其他參與者的錢包進行轉賬。例如，參與者 A 向參與者 B 轉賬 30 SGD。

第四，區塊鏈系統會向 RTGS 發送一個 FAST 凈結算文件。

第五，參與者 A 的 RTGS 賬戶中 30 SGD 會被記入參與者 B 的 RTGS 賬戶。

第六，參與者 A 的區塊鏈賬戶會減少 30 SGD，余額為 270 SGD。

第七，參與者 B 的 RTGS 賬戶中資金會轉到參與者 B 的區塊鏈賬戶。

圖 2：轉賬流程示意圖

結合上述轉賬步驟，概念設計原型中包括三個關鍵因素。一是建立分布式賬本網絡，Ubin 項目第一階段的分布式賬本是基于以太坊的私有鏈，節點包括 MAS 和銀行。二是開發智能合約和工具。三是連接分布式賬本網絡和 MEPS+，Ubin 項目第一階段通過存托憑證連接兩個系統。

研究工作

研究工作流程的主要任務是：確定和闡明 Ubin 項目概念設計原型的監管問題，確定 DLT 對貨幣和金融政策的影響，評估解決方案是否滿足 PFMI （Principles for Financial Market Infrastructure）的要求并找出存在的差距。同時，為后續研究央行數字貨幣制定一份研究清單。

研究結論

Ubin 項目第一階段在基于以太坊的私有鏈上建立了一個銀行間轉賬的概念設計原型。概念設計原型包含了現有 Jasper 項目的部分設計組件，并開發了一個新的智能合約代碼庫。并且，BCSIS 成功實現了區塊鏈系統和 MEPS+之間的連接。通過研究貨幣政策和法律監管等問題，Ubin 項目第一階段的研究工作為概念設計原型的今后實施奠定了堅實的基礎。

Ubin 項目第一階段的概念設計原型解決了轉賬雙方之間的信用風險。將新加坡元 Token 化之后，交易雙方之間的轉賬相當于是抵押在 MAS 的資金轉賬，抵押在 MAS 的資金不存在信用風險。

Ubin 項目第一階段的概念設計原型中分布式賬本不存在流動性風險。即使生態中最大的參與者發生故障或中斷，也不會阻礙其他參與者完成相應的轉賬交易。

第二階段

Ubin 項目第二階段的主要研究工作是使用 DLT 模擬銀行間實時全額結算系統（RTGS），在保護隱私的前提下，用一種去中心化的方式實現流動性節約機制（LSM），解決交易的隱私性和最終性等問題。參與 Ubin 項目第二階段的成員包括 MAS、新加坡銀行協會（ABS）、埃森哲、11 家金融機構和 4 個技術合作伙伴。

研究設置

Ubin 項目第二階段是基于三個平臺進行研究：Corda、Hyperledger Fabric 和 Quorum，并對三個平臺的不同功能和特點進行探索。在研究過程中，所有節點部署在微軟的 Azure 云平臺。

Ubin 項目第二階段的研究目標是基于上述平臺分別開發三個包含 RTGS 系統功能的原型。原型的六個主要設計準則是：轉賬數字化，去中心化架構，排隊機制，交易隱私保護，結算最終性和流動性優化。

圖 3：設計原型的功能

研究方法

設計原型的主要功能包括：資金轉賬、排隊機制和交易擁堵解決方案。

資金轉賬

Ubin 項目第二階段的資金轉賬是指從一家銀行到另一家銀行的轉賬。當付款方有足夠的流動資金且交易隊列中沒有等待交易的指令時，資金轉賬會即時結算。

Corda

在 Corda 的設計中，資金轉賬通過點對點的方式執行，只有付款方和收款方會處理、驗證和記錄交易。通過使用機密身份（Confidential Identities），付款方可以要求從收款方那里獲得一對新的且唯一的公鑰和證書。這個匿名身份只有付款方和收款方知道。

在這種情況下，資金的未來擁有者無法識別之前擁有者的身份，可以有效保護交易中的參與者。這對于在 UTXO 模型中保護隱私是很重要的，在 UTXO 模型中，資金的監管可以一直追溯到發行方 MAS。通過使用機密身份，收款方可以驗證資金的真實性，但不能將資金與現實世界中的擁有者對應起來。

圖 4：Corda 轉賬流程示意圖

當生成交易的輸出狀態、命令和簽名時，機密身份的公鑰會在交易中使用。作為資金的當前擁有者，付款方使用匿名身份對交易進行簽名，然后系統中的公證人（Notary）驗證了狀態的唯一性并進行簽名。經過公證人之后，付款方和收款方會將最終交易的輸出狀態記錄在各自的賬本上。

公證人的功能是對提交的交易進行唯一性驗證。當接受交易時，公證人會對交易進行簽名；當拒絕交易時，公證人返回聲明表示發生雙花。如果交易過程中付款方的資金不足，那么會產生一個債務狀態并注冊到交易隊列中。債務狀態可以取消、重新設置或完成結算。

Hyperledger Fabric

在 Hyperledger Fabric 的設計中，資金轉賬在付款方和收款方之間的雙邊通道（bilateral channel）執行。當付款方的雙邊通道賬戶中有足夠資金且交易隊列中沒有優先級更高的交易指令時，交易指令會即時結算，即減少付款方的雙邊通道賬戶余額并增加收款方的雙邊通道賬戶余額。否則，付款方將根據交易隊列中的交易指令執行雙邊凈額結算。

圖 5：Hyperledger Fabric 轉賬流程示意圖

排序節點（Orderer）是 Hyperledger Fabric 系統架構中的重要角色，負責處理用戶提交的交易消息請求。如上圖所示，付款方將資金轉給收款方，在 Orderer 進行全網廣播之前，付款方和收款方會對交易進行簽名。雙邊通道中的所有參與者（付款方、收款方和 MAS）會收到一個區塊來驗證并提交這個交易到他們的分布式賬本。

Quorum

在 Quorum 的設計中，資金轉賬在交易雙方之間私下執行，沒有其他人可以看到交易細節。通過零知識證明，對余額進行驗證。進行交易時，付款方和收款方生成并提交相同的零知識證明并進行全網驗證。在這個過程中會用到私有智能合約（private smart contracts）和公開智能合約（public smart contracts）。

圖 6：Quorum 轉賬流程示意圖

資金轉賬的交易指令是付款方的 DApp 發起的。DApp 調用私有智能合約并生成一個私有交易。然后，付款方的 DApp 調用全網執行的公開交易。公開交易是使用交易指令中金額的哈希值創建的，這個哈希值是零知識證明生成和驗證的輸入。Quorum 通過零知識證明驗證公開交易的有效性和完整性，因此不需要顯示交易中的任何數據。

排隊機制

當銀行為資金轉賬創建交易指令但流動性不足時，交易指令被放入交易隊列中。銀行可以在交易隊列中查看所有與自己相關的交易指令。當銀行的流動性充足時，交易隊列將根據以下順序自動結算：先比較優先級，優先級高的交易會先進行結算；再比較進入交易隊列的時間，時間越早的交易會先結算（First-In First-Out，FIFO）。

Corda

如果付款方的余額不足，那么在付款方和收款方的分布式賬本中會出現債務狀態。類似于資金轉賬，交易者使用機密身份為交易創建新的公鑰和證書。生成的公鑰將用于識別債務狀態的參與者。債務狀態會作為交易的輸出，付款方簽名后發送給收款方。如果收款方對經過核實和簽名的交易作出響應，那么債務態詳的詳細信息將被放入付款方的交易隊列中。如果收款方不對交易作出響應，那么債務狀態會被取消。交易隊列中的每個債務狀態都會被標記只能由付款方修改的優先級，并且優先級只對付款方可見。

Hyperledger Fabric

當新的交易指令添加到交易隊列中時，系統會創建一個新的「正在排隊交易」狀態（queued transaction state）。雙邊通道中的兩家銀行可以看到相同的交易排隊信息，沒有必要為同一個交易指令維持兩個交易隊列。交易指令完成結算后，交易指令從「正在排隊交易」狀態更改為「完成交易」狀態。

Quorum

每個銀行都維護自己的交易隊列，這是一個尚未結算的交易指令列表。交易隊列中保存交易指令的引用 ID，從而保護交易隊列的隱私。只有與交易相關的參與方才能訪問交易時間戳、交易金額等數據。

當付款方的流動性不足時，交易指令會被添加到私有交易隊列和全局交易擁堵隊列中（Global Gridlock queues）。交易隊列的結算按照優先級和 FIFO 原則，結算完成后，交易會被移出私有交易隊列和全局交易擁堵隊列。

交易擁堵解決方案

全額結算對資金流動性的要求很高。當交易雙方的資金不足、無法按照交易順序完成全額結算時，就會發生交易擁堵。此時，可以通過軋差后進行凈額結算，解決交易擁堵問題。

Corda 的交易擁堵解決方案分為發現、計劃和執行三個階段。交易擁堵解決方案會反復運行以解決隊列中交易指令的結算問題。Corda 沒有采用類似于 EAF2 （一個最早用于德國的 FIFO 算法）等傳統交易擁堵解決方案，而是開發了一種新的基于循環的算法，稱為循環求解器（Cycle-solver）。

Hyperledger Fabric 的交易擁堵解決方案采用 EAF2 算法。Hyperledger Fabric 的交易擁堵解決方案分為初始化和結算兩個階段。

Quorum 的交易擁堵解決方案采用 EAF2 算法。Quorum 的交易擁堵解決方案分為四個階段：標準化，排隊，作出決定和結算。這些狀態被寫入智能合約中，由與所有節點同步維持。

研究結論

第一，三個平臺都可以實現 RTGS 系統的關鍵功能，例如資金轉賬、排隊機制和交易擁堵解決方案。三個平臺在可擴展性、性能和可靠性等方面都可以滿足相關要求。

第二，使用 DLT 實現 RTGS 系統不僅可以降低單點失效等中心化系統的固有風險，而且可以獲得 DLT 的優點，例如安全性和不可篡改。

第三，在研究過程中，隱私保護是非常重要的因素，三個平臺都有針對隱私保護的考慮和設計。Corda 使用 UTXO 模型和機密身份，Hyperledger Fabric 使用獨特的雙邊通道設計，Quorum 使用點對點的消息交換系統和零知識證明。

Ubin 項目第二階段成功地證明了在保護隱私的前提下，可以用去中心化的方式實現 RTGS 系統的功能。DLT 的成功應用意味著需要重新考慮 MAS 在銀行間轉賬所扮演的角色。

第三階段

Ubin 項目第三階段的主要研究工作是使用 DLT 進行 Token 化資產之間的結算，例如在不同的賬本上對新加坡政府證券（Singapore Government Securities，SGS）和央行發行的資金存托憑證（cash-depository receipts，CDRs）進行券款對付（Delivery versus Payment，DvP），旨在實現 DvP 的互操作性和最終性。參與 Ubin 項目第三階段的成員包括 MAS、SGX （新加坡交易所）、Anquan Capital、德勤和納斯達克等。

研究設置

Ubin 項目第三階段是基于幾個不同的平臺進行研究：Quorum，Hyperledger Fabric，Ethereum、Anquan 區塊鏈和 Chain Inc 區塊鏈，每個平臺都有不同的功能和特點。
如下圖所示，Ubin 項目第三階段的設計原型有三種。

圖 7：三種設計原型示意圖

第一種原型是由 Anquan 設計，CDRs 的賬本基于 Quorum，SGS 的賬本基于 Anquan 區塊鏈。第二種原型是由德勤設計，CDRs 的賬本基于 Etherum，SGS 的賬本基于 Hyperledger Fabric。第三種原型是由納斯達克設計，CDRs 的賬本基于 Hyperledger Fabric，SGS 的賬本基于 Chain Inc 區塊鏈。

交易流程是：48 小時內，證券從賣方轉到買方；24 小時內，資金從買方轉到賣方。買方和賣方都可以訪問資金和證券的分布式賬本，這兩個賬本是分別結算的。Ubin 項目第三階段對四種 DvP 場景進行研究。

結算成功

在這種場景中，買方和賣方都履行了交易義務，最終成功進行結算，如下圖所示，整個交易步驟如下。

圖 8：結算成功流程示意圖

第一，買方和賣方向匹配引擎或 OTC 平臺提交訂單。匹配成功后，交易雙方根據商定的資產類型和金額進行交易。

第二，匹配引擎或 OTC 平臺生成哈希原像和哈希值，并通過加密文件的方式共享給賣方。哈希原像和哈希值將用于驗證結算過程中的交易指令。

第三，賣方創建第一個證券交易指令，確定證券的交易數量，并設置兩種可能的交易結果狀態，然后提交給證券分布式賬本。一種狀態是在買方可以提供哈希原像或者交易雙方都同意的情況下，買方可以獲得證券。另一種狀態是買方在 48 小時內無法提供哈希原像或者交易雙方都同意的情況下，賣方收回證券。

第四，證券分布式賬本的共識機制驗證和確認第一個證券交易指令，然后更新分布式賬本。同時，使用哈希時間鎖智能合約鎖定賣方的證券。

第五，買方在核實第一個證券交易指令的內容后，創建與資金轉賬相關的第一個資金交易指令。在這個指令中，買方確定了兩種可能的交易結果狀態。一種是在賣方可以提供哈希原像或者交易雙方都同意的情況下，賣方可以獲得資金。另一種是賣方在 24 小時內無法提供哈希原像或者交易雙方都同意的情況下，買方收回資金。

第六，資金分布式賬本的共識機制驗證和確認第一個資金交易指令，然后更新分布式賬本。同時，使用哈希時間鎖智能合約鎖定買方的資金。

第七，在核實買方第一個資金交易指令的內容后，賣方創建第二個資金交易指令（獲得商定數額的資金），并提供哈希原像。然后賣方對第二個資金交易指令進行簽名并提交給資金分布式賬本。

第八，資金分布式賬本的共識機制驗證和確認第二個資金交易指令，然后更新分布式賬本。此時，鎖定的資金被轉給賣方，資金支付流程結束。

第九，在收到賣方第二個資金交易指令的內容后，買方創建第二個證券交易指令（獲得商定數額的證券），并提交賣方提供哈希原像。然后買方對第二個證券交易指令進行簽名并提交給證券分布式賬本。

第十，證券分布式賬本的共識機制驗證和確認第二個證券交易指令，然后更新分布式賬本。此時，鎖定的證券被轉給買方，證券交付流程結束。

結算失敗，資金和證券返還給原持有人

如果上述場景中的某一個步驟沒有成功完成，例如交易雙方沒有在規定的時間內提交交易指令，那么結算失敗。此時，資金和證券沒有換手，買方和賣方都沒有失去本金的風險。

結算失敗，要求仲裁

如果結算成功場景中前面的步驟順利完成，但買方未能在 48 小時內提交第二個證券交易指令，那么結算失敗。買方已經完成付款，會面臨本金和流動性風險。此時，買方會要求仲裁。

結算失敗，仲裁機構介入

在這種場景中，結算失敗，仲裁機構介入。此時，買方可以要求仲裁機構幫助，從賣方那里獲得商定數額的證券或收回已經支付的資金。

研究方法

Anquan

在 Anquan 設計中，CDRs 的賬本基于 Quorum，SGS 的賬本基于 Anquan 區塊鏈。其設計特點包括以下三點。

圖 9：Anquan 設計原型示意圖

第一，分布式原子交易。為了保護參與者，交易的原子性是在沒有中心化仲裁機構的情況下實現的。雖然在分布式賬本中實現 DvP 可能使買方面臨一定的本金風險，但可以通過交易雙方提交到賬本的交易指令來降低這個風險。第二，可以與支付系統整合。這個設計可以與 Ubin 項目第二階段開發的支付系統進行整合。第三，可擴展性。PBFT 共識算法和分片的設計使得這個系統具備可擴展性，可以快速實現跨鏈原子交易而不必等待幾個區塊確認。在這種方法中，仲裁機構是一個重要角色。在交易失敗的情況下，仲裁機構可以撤銷時間鎖智能合約，解決潛在的流動性風險。

德勤

在德勤設計中，CDRs 的賬本基于 Etherum，SGS 的賬本基于 Hyperledger Fabric。其設計特點包括以下四點。

圖 10：德勤設計原型示意圖

第一，中心化用戶證書管理。通常情況下，Token 化資產是所有者通過自己的私鑰來保管的，所有者自己負責私鑰的安全。但在這個設計中，經過授權的第三方可以提供私鑰托管服務，持有托管的私鑰并為交易進行簽名。第二，含有仲裁機構的半中心化 DvP。Token 化資產通常是在去中心化的環境中以效率更高且成本更低的方式進行交易。然而，如果沒有中心化的流程和仲裁途徑，買方或賣方將不得不自己承擔可能發生的任何損失。因此，在這個設計中引入可信的第三方作為仲裁機構。第三，智能合約和公鑰基礎設施。DvP 邏輯在智能合約中實現，以便外部機構進行審計，并通過智能合約維持交易的原子性。第四，可以與其他圖靈完備的區塊鏈平臺兼容。

納斯達克

在納斯達克設計中，CDRs 的賬本基于 Hyperledger Fabric，SGS 的賬本基于 Chain Inc 區塊鏈。其設計特點包括以下四點。

圖 11：納斯達克設計原型示意圖

第一，即使用戶對底層的 DLT 不了解，也可以通過 API 執行必要的功能。用戶可以檢索資金和證券的帳戶狀態，使用私鑰對智能合約進行簽名，或在兩個分布式賬本上進行輸入。第二，智能合約引擎可以幫助用戶創建智能合約。智能合約引擎允許用戶用人類可讀的格式定義智能合約的標準，并在分布式賬本上執行交易。第三，安全的云解決方案。整個設計是完全封裝好的，可以直接部署到后端或用戶界面。這種設計非常容易擴展和使用，底層 DLT 的變化不會影響 API 和用戶體驗。第四，封裝結構，可以直接在云平臺環境中運行。

研究結論

DvP 智能合約可以確保投資者同時履行權利和義務，從而增加投資者的信心，降低市場上的合規成本。設計原型中有市場運營商（RMO），這是一個中心化的角色，可以起到監測和促進市場功能的作用。投資者的資金安全至關重要，設計原型具有以下主要設計特點：多重簽名、智能合約鎖、時間限制和仲裁機構。

目前，新加坡市場的結算周期是 T+3，使用 DLT 可以縮短結算周期，達到 T+1 或者全天候實時結算。結算周期的縮短會降低交易對手風險、本金風險和流動性風險。

在交易過程中使用哈希時間鎖智能合約，買方可能會面臨本金風險。因此，仲裁機構是一個重要設計，用于解決系統中的交易爭端。設計原型對增強安全性和隱私保護非常重視，交易者可以在匿名狀態下完成交易。需要指出的是，使用 DLT 時，資產會被智能合約鎖定，在鎖定期間，資產不能用于其他交易，這可能會導致市場流動性降低。

第四階段

Ubin 項目第四階段的主要研究工作是使用 DLT 進行同步跨境轉賬。2016 年，MAS 和 BOC （加拿大銀行）分別開展了 Ubin 項目和 Jasper 項目；2019 年 5 月，MAS 和 BOC 對跨境轉賬進行共同研究并發表研究報告。

研究設置

Ubin 項目第四階段提出了三種同步跨境轉賬的概念設計。在第一種設計中，采用中間人的方法；在第二種設計中，允許金融機構同時使用國內網絡和國外網絡，可以同時持有兩種貨幣；在第三種設計中，每個網絡可以有兩種貨幣，并可以直接交易，這可以視作一種多貨幣結算體系。

圖 12：三種同步跨境轉賬的概念設計

中間人的方法

這種方法通過中間人結算來實現跨境轉賬。中間人是支付的第三方，通常是銀行，可以使用國內和國外的網絡。中間人可以在國內網絡中從付款方那里接收資金，并在國外網絡中向收款方發送資金。付款方和收款方不需要同時在兩個網絡中擁有賬戶。

圖 13：中間人方法流程示意圖

同時使用國內和國外網絡方法

在這種方法中，金融機構可以使用國內和國外網絡，并在兩個網絡中持有兩種貨幣。目前，有這種資質的金融機構比較少。如下圖所示，銀行 1 和銀行 2 都在兩個網絡中擁有賬戶，可以直接進行兩種貨幣的交易。

圖 14：同時使用國內和國外網絡方法流程示意圖

支持多貨幣的網絡

這個模型假設在每個網絡中可以交易多種貨幣，付款方可以在國內網絡中同時擁有國內貨幣和國外貨幣。付款方可以直接與其他參與者交易，在國內網絡中使用國內貨幣兌換國外貨幣。

圖 15：支持多貨幣的網絡方法流程示意圖

研究方法

目前，不同國家的貨幣記錄在不同的賬本上。因此，在 Ubin 項目第四階段的研究中，加拿大的分布式賬本基于 Corda 平臺，新加坡的分布式賬本基于 Quorum 平臺，通過 HTLC 實現同步跨境轉賬。

在研究過程中，新加坡的銀行 A 是在 Quorum 平臺上的節點，加拿大的銀行 B 是在 Corda 平臺上的節點，中間人 A 在兩個平臺都有節點。銀行 A 用 105 SGD 向銀行 B 轉賬，根據兩種貨幣之間的匯率，銀行 B 最終收到 100 CAD。整個轉賬流程如下圖所示。

圖 16：轉賬過程中 HTLC 的流程示意圖

第一，加拿大的銀行 B （收款方）創建哈希原像 S 和哈希值 H(S)，并將哈希值 H(S) 共享給新加坡的銀行 A （付款方）。

第二，銀行 A 在新加坡網絡發起含有 HTLC 的交易，將 105 SGD 鎖定在指定的托管賬戶中，轉給新加坡的中間人 A。同時，規定了整個交易的時間 T。

第三，新加坡的中間人 A 審查智能合約的內容，并確認 105 SGD 鎖定在指定的托管賬戶中。然后，新加坡的中間人 A 將哈希值 H(S) 和時間限值 T/2 轉給加拿大的中間人 A。

第四，加拿大的中間人 A 使用哈希值 H(S) 和時間限值 T/2 在加拿大網絡創建第二個智能合約，并將 100 CAD 鎖定在指定的托管賬戶中，轉給銀行 B。

第五，銀行 B 審查加拿大網絡上智能合約的內容，確定鎖定金額，然后使用哈希原像 S 從這個智能合約中獲得資金 100 CAD。在這個過程中，哈希原像 S 提交給加拿大的中間人 A。

第六，加拿大的中間人 A 與新加坡的中間人 A 共享哈希原像 S。

第七，新加坡的中間人 A 可以用哈希原像 S 從新加坡網絡的智能合約中獲得托管賬戶中的資金 105 SGD。

研究結論

Ubin 項目第四階段成功實現了跨境（加拿大和新加坡）、跨幣種（CAD 和 SGD）和跨平臺（Corda 和 Quorum）的原子交易。在這個過程中，不需要交易雙方都信任的第三方。

HTLC 使用哈希鎖和時間鎖來實現兩個 DLT 平臺之間原子交易。即使在交易失敗的場景中，HTLC 也是一種可靠的方法，付款方在絕大多數情況下不會有本金風險。如果收款方不能在規定的時間內提交哈希原像，那么 HTLC 協議就會失敗，托管的資金會返還給付款方。

思考和總結

Ubin 是新加坡金管局開展的研究項目，其研究目標是探索區塊鏈和分布式賬本技術在貨幣 Token 化、支付系統、券款對付、同步跨境轉賬等領域中的應用，旨在解決金融業和區塊鏈生態系統所面臨的實際問題。從中可以看出新加坡金管局對 DLT 的重點應用方向。

在 Ubin 項目研究過程中，新加坡金管局非常重視與其他國家央行、金融機構和科技公司的合作，并大量借鑒和吸取傳統金融領域或現有 DLT 項目的研究成果。

Ubin 項目目前還處于研究階段，在 DLT 大規模實際應用之前還有很多問題需要解決。例如，研究階段的設計原型可能無法滿足實際應用的性能要求，以及現有法律法規體系下的監管問題等。

Ubin、Stella 和 Jasper 等各國央行主導的 DLT 研究項目在研究內容上有非常相似的地方。支付系統、證券結算系統和跨境轉賬系統都是重點研究領域。同時，各國央行都非常重視對 HTLC 的應用。但 HTLC 也存在缺陷，并不是一種完美的解決方案。未來，各國央行需要進一步對其他技術路線進行研究和探索。

原文標題：《新加坡金管局 Ubin 項目進展分析》
撰文：郝凱，就職于 HashKey Capital Research
審核：鄒傳偉，萬向區塊鏈與 PlatON 首席經濟學家

總結

以上是生活随笔為你收集整理的深入分析新加坡金管局区块链计划 Ubin的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。