此前 Mimblewimble 協議因爲要交易的求發送方和接收方同時在線而難以推廣,新的 Mimblewimble 提案可支持非交互式交易。

原文標題:《Mimblewimble 可實現非交互式交易,萊特幣、Grin 等將受益》
撰文:David Burkett,Grin++開發者
編譯:灑脫喜

一項技術如果是難用的,或者說對用戶不友好的,那麼它就很難被廣泛採用。而此前的 Mimblewimble 協議,其交易就要求發送方和接收方同時在線交互才能實現,從而阻礙了相關項目的大規模應用。而在今日,Grin++錢包開發者 David Burkett 提出了一種支持 Mimblewimble 非交互式交易的提案,其可適用於萊特幣、Grin 等區塊鏈項目。

Mimblewimble 新提案:實現非交互式交易,萊特幣與 Grin 將受益

David Burkett 在萊特幣論壇開發者板塊中提到:

一月份最大的消息是,我找到了一種方法來支持 Mimblewimble 的非交互式交易!使用 MW 協議最大的困難,是需要發送方和接收方進行通信,這需要雙方在線。而新的提議,可消除這種需要,由此可清除掉主要的用戶體驗障礙,同時支持通過冷存儲進行接收,從而使硬件錢包更易於支持。

在開發方面,已經爲 libmw 確定了構建過程,並且本地構建正在爲 libmw-ltc 工作(將 libmw-core 和 libmw-ltc 檢出到同一父目錄,並且你應該能夠構建 libmw-ltc)。我將在下個月左右設置 CI/CD。

另外,我還構建了一個具有交易處理功能的健壯數據庫框架,以支持跨多個 table 的原子更新,並實現了與幣無關的區塊數據庫查詢和更新,並且已使用特定於 LTC 的區塊頭和區塊模型進行了部分測試。

安全審計結果是從 Grin++得出的,因此我已將所有修復程序應用於 Grin ++和 libmw,並將等待審計人員的最終審查。事實證明,C++的實現是非常複雜的,相關的審計給了我教訓。作爲這個過程的一部分,我學到了很多,因此 Grin++& libmw 代碼庫明顯變得更好了。再次感謝 Grin、Beam 和 LTC 社區的貢獻者,他們使審計成爲可能。

在 Grin++方面,我們已完成了一個成功的計劃硬分叉,解決了硬分叉前的同步問題,並且 Grin ++ 0.7.5 現在已經可用,它是迄今爲止最穩定的版本。

而二月份的首要任務,就是實施萊特幣擴展區塊(EB)的共識規則,包括所有驗證和一整套測試。這是代碼中最重要的部分,因此要確保所有詳細信息正確無誤,並且代碼具有完整的測試覆蓋範圍,而這將非常耗時。一旦完成,我將爲擴展區塊(EB)開發 API,這樣我們就可以開始將 LBMW 集成到現有的萊特幣代碼庫中。

我還將集中精力全面審查新的單側交易提案,如果未發現重大的安全問題,我將創建一個 LIP (萊特幣改進提議)以供社區反饋。

從這個帖子當中,我們可以看到,目前 David Burkett 正在爲萊特幣開發的 Mimblewimble 應用方案正處於初期階段,而其中最大的進展就是非交互式交易提案。

那麼,這個神奇的方案具體是如何實現的呢?下面我們來看提案譯文:

Mimblewimble 離線交易提案

Mimblewimble 區塊鏈協議通過使用 pedersen 承諾、schnorr 簽名和一種稱爲‘cut-through’的新技術,可提高比特幣等加密貨幣的隱私性和可擴展性。而帶來這些好處的同時,也需要付出一些昂貴的代價。到目前爲止,構建 MW 交易需要發送方和接收方之間的交互來創建輸出並集體簽署交易。本文提出了一種在最小化影響 mimblewimble 協議可擴展性及隱私性條件下,實現單側交易的方法。

當前的 Mimblewimble 協議

和比特幣一樣,Grin 也使用了 UTXO 模型。交易是通過包含要花費的輸入、創建相等或較低價值的新輸出,以及簽名和構建驗證輸入所有權的範圍證明(range proof)來創建的。
與比特幣不同的是,Grin 使用了保密交易(CT)技術,因此輸入和輸出是 pedersen 承諾(rG + vH)。與添加到輸入的簽名不同,每筆交易只有一個簽名,它是交易內核的一部分。

爲了使交易有效,必須滿足以下條件(爲簡單起見,忽略交易費用和交易補償):

  1. 輸出承諾的總和減去輸入承諾的總和必須等於內核承諾,即 (r_out1..nG +v_out1..nH) - (r_in1..nG +v_in1..nH) = r_kern*G ;
  2. 對某些已知消息基點 G 的內核 excess value (rk = sum(ro1..n) - sum(ri1..n)) 的一種簽名;
  3. 一種證明所有輸出值都不是負的範圍證明(rangeproof);

這三者的結合,證明了發送者( sender)是輸入的所有者,並保證在交易中沒有新的幣被創造出來。

而這種協議就要求發送者(Alice)與接收者(Bob)進行交互以構建交易,以避免暴露彼此輸入和輸出的盲因子。這是一個三步過程:

1.Alice 用她的輸入創建一筆未簽名交易,改變輸出和範圍證明(rangeproof),一個包含輸出和輸入盲因子差異的中間內核,並提交給 schnorr 簽名的 nonce;
2.Bob 創建他的輸出和範圍證明(rangeproof),添加他在內核承諾(commitment)中的份額以生成實際的交易內核,提交到 nonce,並提供交易內核的部分簽名;
3.Alice 簽署她的內核簽名,並聚合這兩個簽名;

雖然該協議可以運作,並且允許 Alice 不受限制地將資金轉移到 Bob,但是交互屬性帶來了一些安全性、可用性和隱私方面的挑戰。構建交易要麼需要用戶保持密鑰在線,要麼需要某種形式的帶外通信,而這可能導致隱私泄露和 MITM 攻擊。

建立非交互式交易

長期以來,絕大多數人都認爲在 mimblewimble 協議中不可能實現非交互式交易,因爲知情輸出盲因子對於創建範圍證明(rangeproof)和構建 schnorr 簽名而言是必要的。

而要解決這個問題,我們必須首先找到一種方法,讓發送者和接收者都知道盲因子,而不是其他人。而 Diffie-Hellman 密鑰交換算法很適合解決這一問題。發送方只需生成一個密鑰對,使用接收方的 pubkey (公鑰)執行 ECDH,並生成一個共享密鑰,該密鑰可用作盲因子。然後,發送方可以生成接收方的輸出、盲因子和簽名,以創建有效的交易。

但這種方案,也帶來了兩個明顯的問題。

第一個問題是,發送方仍需要將其公鑰和值傳遞給接收方,因此我們需要在不影響隱私的情況下將其作爲輸出的一部分包含進來。但是沒有明顯的方法可提交數據。我們不能將它作爲內核的一部分,因爲它會將內核鏈接到輸出,從而消除隱私的好處。

第二個問題是 Alice 和 Bob 最終都拿到了資金的密鑰,這意味着 Bob 沒有成爲資金的獨家所有人,也不可能解決糾紛。我們需要一種方法來驗證只有 Bob 才能花費輸出。

新的提案

事實證明,在範圍證明(rangeproof)中可以加密近 32 字節的數據。例如,如果我們使用一個已知的密鑰 blake2b(output_commitment),我們就可以公開提交一些額外的數據。如果我們在範圍證明(rangeproof)中「加密」的數據是哈希,那麼我們實際上就可以公開提交所需的數據。這允許我們納入一個新的數據塊 (output_data),其中包含:

  1. 發送人的短暫公鑰;
  2. 接受者公鑰;
  3. 輸出值(使用 ECDHE(sender's key, receiver's key) 加密);
  4. 輸出的盲因子(使用 ECDHE(sender's key, receiver's key) 加密);

然後,我們就可以添加以下用於驗證輸出的共識規則:

  1. 每個範圍證明(rangeproof),通過使用 blake2b(output_commitment) 都是可重繞(rewindable)的;
  2. 每個輸出都必須包含 output_data (其中包括 sender_pubkey、receiver_pubkey 和一些附加加密數據);
    3.ripemd160(blake2b(output_data)) 必須與重繞的範圍證明數據的前 20 個字節匹配;

節點必須存儲所有 UTXO 的 output_data,因此在之後使用時,我們還可以要求 1 個新的共識規則來驗證輸入:
每個輸入都必須包含一個有效的簽名:sig(receiver_pubkey, input_commitment)

輸入和輸出可以繼續像往常一樣被修剪,我們現在提供了一種向接收者發送資金的方法,並保證發送者無法重花費這些資金。

安全性

因爲發送方和接收方都知道輸出的盲因子,所以僅僅根據內核驗證當前的 UTXO 集是不夠的。這需要驗證所有最近輸入的簽名,我們建議新節點驗證最近 X 區塊的所有輸入簽名,其中 X=coinbase 成熟值,因爲風險是相似的。

而這仍然會留下一個在今天看來不太可能實現的攻擊點。這種攻擊的工作方式如下(假設過去一天的輸入簽名經過驗證 ):

  1. Alice 創建一筆包含用於 Bob 輸出的交易;
  2. Bob 將 Alice 買的東西寄給對方;
  3. 幾天(甚至可能幾年)過去了,而 Bob 仍舊沒有花掉他的幣;
  4. Alice 強制對過去一天+1 個區塊進行一次大的重組。然後,她可以將 Bob 的輸出發回給自己,因爲她知道盲因子,並且未對超過 1 天的區塊中的交易進行簽名驗證;

儘管這種攻擊在理論上允許你花費任何幣齡的幣,但它們必須是攻擊者之前發送的幣,而且沒有被接受者花費掉。然而,這種攻擊能夠帶來的效益,不太可能覆蓋掉進行重組攻擊的代價。不過,爲了謹慎起見,當你收到大量幣時,你只需要自己花掉這些幣,就可以防止這種攻擊,而所需的額外內核成本卻很小。

隱私問題

只要密鑰對不被重用,上面提到的方案就不會泄露任何額外的隱私。爲了確保這一點,我們建議對輸出數據進行一個相當小的修改,以支持某種形式的隱祕地址(ISAP 或 DKSAP)。

支付證明

現在,支付可相當容易地進行證明。要證明一筆支付的所有必要條件,是原始輸出、範圍證明(rangeproof)、output_data 以及顯示範圍證明(rangeproof) MMR 成員身份的 merkle 證明。

多重簽名錢包

目前,要安全地將資金髮送到多重簽名錢包,需要發送者和所有接收方進行交互。而新提案消除了這種需要,代價是造成多重簽名錢包隱私性方面的損失。

其他改進

由於我們現在有一種方法來提交額外的數據,並將其作爲輸出的一部分,我們可以將費用或者其它數據從內核移到 output_data 結構當中,這就允許進行修剪,從而減少區塊鏈的大小。

致謝

感謝 John Tromp 對重組攻擊的詳細描述,感謝 Jasper van der Maarel 關於防彈證明( bulletproofs)和多重簽名錢包技術方面提供的建議,感謝 Phyro 提出的將內核細節移動到輸出數據結構中的建議。同時,非常感謝 Daniel Lehnberg、Antioch Peverell、Phyro 以及 Vladislav Gelfer 對以上設計提供的寶貴反饋意見。

來源鏈接:litecointalk.io