去中心化Token互換協(xié)議R1協(xié)議介紹

R1協(xié)議是一種高效的去中心化Token互換協(xié)議。它解決了傳統(tǒng)Token互換協(xié)議撮合效率低、用戶體驗差等問題，將去中心化Token互換協(xié)議帶入了一個新的高度。目前，基于以太坊的版本已經(jīng)實現(xiàn)，后續(xù)會開發(fā)其他公鏈版本如NEO、QTUM等。

去中心化Token互換協(xié)議的發(fā)展

傳統(tǒng)互聯(lián)網(wǎng)是傳遞信息的網(wǎng)絡(luò)，信息都保存在中心化的機構(gòu)中，由于缺乏可靠的信任機制，陌生節(jié)點間無法完成大規(guī)模的價值互換。比特幣的出現(xiàn)使可信的價值轉(zhuǎn)移成為了可能，它對中心化互聯(lián)網(wǎng)發(fā)起了挑戰(zhàn)，同時也帶動了區(qū)塊鏈技術(shù)的蓬勃發(fā)展。在后比特幣時代，涌現(xiàn)了一大批區(qū)塊鏈創(chuàng)新技術(shù)，以太坊正是新型區(qū)塊鏈的卓越代表，除了價值轉(zhuǎn)移外，它實現(xiàn)了智能合約，將現(xiàn)實世界的規(guī)則以算法的形式映射在區(qū)塊鏈上，極大的擴展了區(qū)塊鏈的應(yīng)用范圍。一大批區(qū)塊鏈項目基于以太坊的ERC-20標(biāo)準(zhǔn)發(fā)行了自己的代幣，據(jù)不完全統(tǒng)計，目前以太坊上運行的代幣超過一千種， 構(gòu)成了龐大的代幣經(jīng)濟體系。

種類繁多的代幣對于交換提出了強勁的需求，帶動了去中心化Token互換協(xié)議的研究，陸陸續(xù)續(xù)涌現(xiàn)了Etherdelta、0x、IDEX等去中心化交易所，不斷的挑戰(zhàn)中心化交易所的地位。但是，受限于當(dāng)前以太坊的性能，他們都存在著或多或少的問題，交易體驗不盡如人意。

· Etherdelta

Etherdelta的用戶需要把資產(chǎn)存入Etherdelta智能合約。在交易時，用戶將訂單攔到鏈FRelayer，等待別人來成交。如果想要吃別人的訂單，用戶需要手動指定對應(yīng)的訂單發(fā)起交易。Etherdelta不會自動撮合用戶的訂單，交易體驗較差。

· 0x

0x用戶不需要將資產(chǎn)存入智能合約，只需要錢包中擁有ETH或T oken即可。在開始交易之前，用戶需要將錢包中的ETH轉(zhuǎn)換為一種叫做WETH的代幣。WETH是與ETH等價的ERC-20代幣，轉(zhuǎn)換比例為1:1，將ETH轉(zhuǎn)換成W ETH可以使0x合約方便的與其他ERC-20Tokcn進行結(jié)算。

開始新交易對的交易前，用戶還需要設(shè)置對應(yīng)Token的權(quán)限，授權(quán)允許0x合約轉(zhuǎn)移該Token。盡管0x做到了足夠的去中心化，但是其撮合效率還是很低。對接0x協(xié)議的撮合引|擎必須不問斷的監(jiān)聽用戶錢包的資金進出，如果用戶錢包的余額不足，就需要把用戶的委托訂單從訂單簿中剔除，一旦剔除不及時，該委托訂單的對手方將交易失敗。在網(wǎng)絡(luò)擁堵或者波動大時，這種情況可能頻繁出現(xiàn)，嚴(yán)重影響用戶體驗。

· IDEX

意識到0x協(xié)議的不足——0x智能合約和Rela yer無法完美的協(xié)調(diào)合作，IDEX選擇由中心化的Relayer將交易提交到鏈上。這樣IDEX可以很好的空制訂單順序，但是任然沒有解決搶單的問題。

R1協(xié)議

1. 架構(gòu)

R1協(xié)議的架構(gòu)包含三部分。

作為去中心化的媒介，R1智能合約部署在以太坊區(qū)塊鏈上，可以存儲用戶的資產(chǎn)、交易記錄，達(dá)到資產(chǎn)去中心化、交易記錄可審計的目標(biāo)。

Relayer是訂單中繼系統(tǒng)，與R1智能 合約交互，主要負(fù)責(zé)訂單撮合與提交上鏈。Relayer對外提供OpenAPI，允許第三方交易所提交訂單到撮合引擎。

第三方交易所的主要職責(zé)是收集用戶的訂單數(shù)據(jù)，并將簽名后的訂單提交給Relayer。通過R1協(xié)議，不同交易所可以成為分布式商業(yè)系統(tǒng)的一部分，共享訂單數(shù)據(jù)和流動性，為用戶帶來更好的交易深度和體驗。

2. 訂單交易

2.1訂單交易流程

訂單交易處理流程描述了從用戶提交訂單開始，到Relayer撮合訂單，再到將交易數(shù)據(jù)提交到區(qū)塊鏈上的過程。如圖所示：

1. 用戶輸入訂單信息。用戶以一定價格和數(shù)量買入或者賣出token， 客戶端將數(shù)據(jù)轉(zhuǎn)換成約定的訂單數(shù)據(jù)格式。

2. 用戶使用私鑰對訂單簽名。私鑰由用戶保管，任何交易所以及Relayer不存儲用戶的私鑰。放入后臺訂單池。簽名完成后，客戶端將訂單信息發(fā)送給Relayer， Relayer對訂 單信息進行合法性校驗后，放入訂單池進行撮合。

3. 后臺撮合成功。Relayer的撮合引擎對來自不同交易所的所有訂單進行統(tǒng)一撮合。

4. 后臺提交到鏈上交易。撮合成功后，Relayer會將匹配的兩個訂單信息及交易額提交到區(qū)塊鏈上進行最終的結(jié)算。

以上為訂單交易的基本流程，下面詳細(xì)說明每個過程的技術(shù)細(xì)節(jié)，包含：

●訂單的數(shù)據(jù)格式;

●訂單簽名算法;

●Relayer職責(zé);

●鏈上結(jié)算邏輯。

2.2 訂單

訂單數(shù)據(jù)格式

在交易所中，用戶的訂單信息體現(xiàn)為：交易對+交易價格+交易數(shù)量。

而在R1智能合約中，訂單的數(shù)據(jù)格式如下：

參數(shù)說明如下：

● tokenBuy： 用戶希望購買的token合約地址

● amountBuy： 用戶 希望購買的token數(shù)量

● tokenSel： 用希望賣出的token合約地址

● amountSell： 用戶希望賣出的token數(shù)量

●baseToken：交 易對錨定的基礎(chǔ)token。默認(rèn)填0，表示對ETH的交易對。如果是對RNT的交易對，此處填RNT的合約地址

● expires：訂單過期區(qū)塊數(shù)。默認(rèn)設(shè)置-一個比較大的值，表示永不過期

● nonce： 隨機數(shù)。 用來保證訂單唯一性，目前的方案是nonce值為時間藏

●feeToken： 手續(xù) 費支付方式。如果為0，按傳統(tǒng)方法支付，即手續(xù)費從用戶獲得的token中扣除。如果為token合約地址，則使用該種Token支付手續(xù)費，前提是用戶存入了該token到R1智能合約中

訂單簽名

為了讓用戶的訂單能夠在網(wǎng)絡(luò)中安全的傳播并且不被篡改，需要用戶的私鑰對訂單數(shù)據(jù)進行簽名。

訂單數(shù)據(jù)的簽名過程為：

其中

客戶端將訂單數(shù)據(jù)簽名完成后，會將訂單原始數(shù)據(jù)、訂單哈希值和訂單簽名一起發(fā)生到Relayer。Relayer會對這些數(shù)據(jù)進行合法性校驗，主要校驗訂單哈希值是否一致、訂單簽名是否正確，以防止訂單數(shù)據(jù)被篡改。

需要強調(diào)的一點是，對于Relayer來說，在接收到用戶的訂單信息之前，無法知道這個用戶是maker還是taker。Relayer會根據(jù)訂單信息到達(dá)的時間先后和當(dāng)前訂單池的數(shù)據(jù)，來決定這個用戶是taker還是maker。如果訂單池中有對應(yīng)的訂單匹配價格，則最新提交訂單的用戶成為taker，另一方則成為maker。所以，每個用戶提交的訂單都應(yīng)該包含訂單原始數(shù)據(jù)、訂單哈希值和訂單簽名，對于Relayer來說每個用戶都是對等的。

2.3 Relayer撮合

Relayer主要負(fù)責(zé)訂單撮合、錢包余額維護、提交上鏈等。Relayer內(nèi)部各系統(tǒng)組成如下圖所示：

● OpenAPl： Relayer 對外提供API，第三方可以通過OpenAPI提交訂單、查詢交易狀態(tài)、訂單深度以及錢包余額

● Valiator： 對訂單數(shù)據(jù)合法性進行校驗，對賬廣余額進行校驗

● AccountSystem： 負(fù)責(zé)維護錢包余額

● BlockSyncing： 負(fù)責(zé)區(qū)塊信息同步，同步區(qū)塊鏈余額信息等

● MatchingEngine： 撮合引擎，負(fù)責(zé)撮合訂單

● MessageQueue： 消息系統(tǒng)。負(fù)責(zé)系統(tǒng)間通信

●Store： 存儲模塊。負(fù)責(zé)存儲信息，臨時數(shù)據(jù)緩存等。

Relayer處理邏輯

Relayer收到訂單數(shù)據(jù)后的內(nèi)部處理流程如下：

1. 對訂單數(shù)據(jù)進行校驗。 這里主要校驗訂單的哈希值是否匹配，防止訂單數(shù)據(jù)被篡改;校驗用戶簽名是否正確，保證訂單數(shù)據(jù)確實由某個擁有正確私鑰的賬號發(fā)起; 校驗余額是否充足; 這里任何一步交易不通過都會引發(fā)訂單提交的失敗

2. 訂單撮合。訂單數(shù)據(jù)校驗成功后，訂單被放入撮合引擎進行撮合，同時訂單數(shù)據(jù)記錄到數(shù)據(jù)庫中。撮合引擎會根據(jù)訂單提交時間和價格高低來匹配訂單，一旦撮合成功，會標(biāo)記訂單成交。并且會將匹配的兩個訂單放入消息隊列，等待提交到鏈上結(jié)算。

3. 提交上鏈。 提交到鏈上結(jié)算調(diào)用合約的batchTrade或trade方法， 并且只有admin賬號進行提交。admin賬號是由合約owner設(shè)置的賬號，有權(quán)限調(diào)用trade方法。為了提高并發(fā)，Relayer可以用多個admin賬號調(diào)用trade方法。

交易手續(xù)費

由于調(diào)用trade方法的是admin賬號，因此gas費用是從admin賬號中扣除的。Relayer需 要保證admin賬號有足夠的ETH額度，否則可能由于額度不足以支付gas費用而無法提交上鏈。

這筆gas費用會由admin事先墊付，但是最終還是需要由交易雙方來共同承擔(dān)。目前的做法是maker和taker各承擔(dān)gas費用的50%。

所以，用戶的手續(xù)費包含兩部分：交易額的0.1%+ gas費用的50%。Relayer會根據(jù)這 個原則算出需要扣除的token數(shù)量，傳入trade方法作為參數(shù)，trade方法 會扣除相應(yīng)的費用。對于用戶來說，用戶實際得到的token數(shù)量會比交易計算得到的數(shù)量少一些，少的部分即為扣除的費用。

2.4 鏈上結(jié)算

鏈上結(jié)算的邏輯主要在R1智能合約的trade方法中實現(xiàn)。trade方法主要對maker和taker的訂單進行校驗，以及做資產(chǎn)的鏈上交割。

以下說明trade方法的具體實現(xiàn)細(xì)節(jié)

輸入?yún)?shù)

trade方法的輸入?yún)?shù)包含以下幾部分： ;

1. maker的訂單數(shù)據(jù)（見訂單數(shù)據(jù)格式一節(jié)說明）

2. taker的訂單數(shù)據(jù) （見訂單數(shù)據(jù)格式一節(jié)說明）

3. maker的簽名信息（υ，r，s）

4. taker的簽名信息 （υ，r，s）

5. 交易額（ Relayer根據(jù)撮合結(jié)果設(shè)置本次交易額）

6. maker和taker的應(yīng)收手續(xù)費（由Relayer設(shè)置）

7. 接收手續(xù)費的賬號 （由Relayer設(shè)置）

其中1、2、3、4這四部分的信息由用戶提供，其他人都不可篡改；而5、6、7三項數(shù)據(jù)由Relayer設(shè)置，

輸入?yún)?shù)校驗

在進行最終的資產(chǎn)交割前，需要交驗輸入的參數(shù)是否合法，以保證交易能夠按照用戶的意圖進行成交。需要校驗的步驟包含：

●必須是admin賬號調(diào)用trade方法

●feeAccount （手續(xù)費接收賬號）必須合法。也就是說feeAccount必須是合約owner授權(quán)過的

●交易雙方的訂單必須是同一交易對。合約中的代碼片段：

· maker和taker的簽名確認(rèn)。 合約中的代碼片段如下：

· 訂單價格必須匹配。訂單成交的基礎(chǔ)是價格匹配，價格必須滿足：

其中：

合約中代碼片段如下：

●余額充足。需要保證訂單交易的時候有足夠的額度，不會超過用戶希望交易的額度

以上所有條件校驗通過，才能進行最終的資產(chǎn)交割。交割成功，該筆交易會完整的記錄在區(qū)塊鏈上。

3. 充值與提現(xiàn)

R1協(xié)議的充值提現(xiàn)與中心化交易所的流程基本一致，不同的是使用R1協(xié)議的用戶將資金存入智能合約中，不受任何第三方控制，即使交易所被黑客攻擊，用戶的資金也是安全的，做到了資產(chǎn)的去中心化。需要注意的是，只有私鑰的所有者才能操作轉(zhuǎn)入R1智能合約的資產(chǎn)，用戶需要妥善保管自己的私鑰。

3.1充值

R1智能合約中用戶通過兩個方法進行充值：

●deposit （）

●depositToken

deposit方法允許用戶將eth充入R1智能合約中。該方法會在區(qū)塊鏈上登記用戶的資產(chǎn)余額，同時拋出一個Deposit 充值事件; Relayer通過監(jiān)聽該事件感知用戶的充值。

depositToken方法允許用戶將token充入R 1智能合約中。與充值eth的不同之處在于，根據(jù)ERC-20 Token的標(biāo)準(zhǔn)，用戶充值前需要調(diào)用token合約的approve 方法，授權(quán)R 1智能合約轉(zhuǎn)賬token。只有完成這一步操作， 用戶才能成功將token充入智能合約中。為了減少approve操作次數(shù)，接入R1協(xié)議的交易所可以在用戶第一次充值token時讓用戶授權(quán)一個比較大的額度。這樣，用戶再次充值該token時，不需要進行額外的approve操作，消耗gas 費用。

3.2 提現(xiàn)

用戶可以隨時取出自己的資金，不需要人工審核。R1智能合約的用戶提現(xiàn)有以下幾種方法：

● adminWithdraw

● withdraw

● withdrawNoLimit

adminWithdraw是比較常用的提現(xiàn)方法。它的原理是，用戶將提現(xiàn)的操作委托給Relayer，Relayer根據(jù)用戶的提現(xiàn)請求調(diào)用R1合約的admin Withdraw，將資金轉(zhuǎn)賬給用戶的錢包。由于提現(xiàn)請求需要用戶的私鑰簽名，任何第三方（包括Relayer ）都不能篡改用戶的數(shù)據(jù)，保證了提現(xiàn)的安全可靠。該方法的意義在于，提現(xiàn)請求最先由Relayer感知，Relayer可以快速及時地更新訂單池，提供更好的交易體驗。

withdraw適用于懂得如何調(diào)用智能合約的用戶。如果用戶不希望將提現(xiàn)數(shù)據(jù)委托給Relayer，那么他可以選擇調(diào)用合約的withdraw方法。但是在調(diào)用該方法前，用戶需要經(jīng)歷一個兩階段提現(xiàn)的過程。即用戶需要先調(diào)用apply Withdraw方法申請?zhí)岈F(xiàn)，在滿足以下兩個條件的情況下，用戶才能調(diào)用

withdraw方法成功提現(xiàn)。這兩個條件是：

1. Relayer調(diào)用了approveWithdraw 方法， 同意用戶的提現(xiàn)請求;

2. 申請超過了一定的等待期后;

等待期由合約的owner設(shè)置，當(dāng)前設(shè)置的等待期為7天。合約owner會視不同情況調(diào)整等待期，如1天甚至1小時，但不能超過7天。

withdrawNoLimit允許用戶方便的提現(xiàn)。只需要調(diào)用該方法即可提現(xiàn)，前提是合約的owner開啟該方法的開關(guān)。一般情況下該方法是關(guān)閉的，只有在特殊情況如Relayer由于某些原因不能及時響應(yīng)用戶的提現(xiàn)申請時，該方法才會打開，方便用戶提現(xiàn)。

4. R1合約的治理

作為以太坊區(qū)塊鏈上的-份智能合約，R1 由ONEROOT團隊創(chuàng)建并部署，即R1智能合約的owner為ONEROOT團隊。為了保證R1協(xié)議安全穩(wěn)定的運行，R1 智能合約的owner擁有一些特殊的權(quán)限，包含：

● 設(shè)置admin 管理員賬號。admin賬號負(fù)責(zé)調(diào)用trade、 adminWithdraw、 approveWithdraw等方法，保證Relayer維持正常的交易功能。

● 設(shè)置手續(xù)費賬號。只有經(jīng)過授權(quán)的賬號才能接受用戶支付的手續(xù)費。

● 調(diào)整提現(xiàn)等待時間。R1智能合約的owner可以根據(jù)情況調(diào)整提現(xiàn)等待時間，方便用戶提現(xiàn)。

● 開啟便捷提現(xiàn)開關(guān)。在特殊情況下，如Relayer無法提供提現(xiàn)服務(wù)時，R1 合約的owner需要開啟該開關(guān)，方便用戶快速地提現(xiàn)。

admin Withdraw是比較常用的提現(xiàn)方法。它的原理是，用戶將提現(xiàn)的操作委托給Relayer，Relayer根據(jù)用戶的提現(xiàn)請求調(diào)用R1合約的adminWithdraw，將資金轉(zhuǎn)賬給用戶的錢包。由于提現(xiàn)請求需要用戶的私鑰簽名，任何第三方（包括Relayer ）都不能篡改用戶的數(shù)據(jù)，保證了提現(xiàn)的安全可靠。該方法的意義在于，提現(xiàn)請求最先由Relayer感知，Relayer可以快速及 時地更新訂單池，提供更好的交易體驗。

未來研究

作為價值傳輸網(wǎng)絡(luò)的重要組成部分，中心化Token互換協(xié)議的研究日益深入，相關(guān)產(chǎn)品層出不窮。R1協(xié)議專注于提升用戶的交易體驗，力求達(dá)到中心化交易所的標(biāo)準(zhǔn)。然而，對所有基于以太坊的協(xié)議來說，以太坊網(wǎng)絡(luò)的處理能力始終是提升交易速度的瓶頸。但這并非一成不變的，即將到來的Plasma技術(shù)為以太坊帶來了商用化的希望。

Plasma技術(shù)的實現(xiàn)將大幅度提升以太坊網(wǎng)絡(luò)的TPS，改變以太坊網(wǎng)絡(luò)擁堵的狀況。同樣的，R1協(xié)議也可以采用Plasma技術(shù)，在以太坊上部署-份Plasma合約， 同時啟動一條Plasma子鏈，將Relayer的功能遷移到Plasma子鏈上，在提升性能的同時做到完全的去中心化。

除了以太坊網(wǎng)絡(luò)的技術(shù)發(fā)展，在其他公鏈上實現(xiàn)R1協(xié)議也是ONEROOT團隊的研究方向。以EOS為例，隨著生態(tài)的不斷發(fā)展，基于EOS的Token將越來越多，相應(yīng)的去中心化交易所也會不斷涌現(xiàn)。受益于良好的TPS性能，這些交易所性能將遠(yuǎn)超以太坊，為用戶帶來非凡的交易體驗，而這也是ONEROOT研究的方向。