他山之石 | 如何用 TLA 工具分析狀態通道？_ALICE

技術的突破是推動區塊鏈行業前進的引擎，幣安中國區塊鏈研究院與鏈聞ChainNews同為密切關注區塊鏈與密碼學等領域技術發展前沿的組織，故而聯合推出「他山之石」專欄，向中文世界讀者介紹全球范圍最值得關注的區塊鏈技術進展，以及在金融等產業最新的應用分析與動態，以期為中國的區塊鏈行業「攻玉」提供借鑒和思考。

本文解釋了如何用TLA證明force-move協議為狀態通道提供了擔保，以確保你能提款。

原文標題：《使用TLA分析狀態通道》撰文：TomClose，Magmo團隊負責人。本文基于AndrewStewart的工作成果，在此感謝MikeKerzhner和GeorgeKnee提出寶貴的意見和建議。

本文已取得作者授權，并由鏈聞和幣安中國區塊鏈研究院獲得中文地區翻譯首發權

目前我們在本系列的文章已經做了諸多與狀態通道相關的專題，其中一篇介紹了狀態通道的底層擔保機制：即在鏈是活動的且不存在監管的情況下，參與方能夠在有限的時間內提款。我們引入了狀體通道退出游戲的一個玩具模型，并證明了該模型能夠提供擔保機制。

為了支持實際的應用，我們需要透過此玩具模型，轉向更先進的狀態通道系統，如此底層擔保機制便能發揮作用嗎？在本文中，我們闡述了如何使用TLA驗證工具來測試我們的協議，以及如何修復該工具檢測到的問題。

什么是TLA及使用TLA的原因

自發布force-move白皮書后，我們便一直在探尋證明該協議正確性的方法。由于狀態通道涉及多個在鏈上和鏈外進行交互的參與方，所以很難照顧到所有的可能性。不過，我們肯定，這個協議沒有問題。但是，我們經常會擔心一些新出現的極端情況，直到確定沒有問題，我們的疑慮才能打消。我們希望能找到一種方法，避免將來出現無法處理的情況，從而消除人們對該協議是否健全的擔憂。

我們到底要證明什么？在此前關于通道融資的文章中，開頭中提到了擔保機制：即在鏈是活動的且不存在監管的情況下，參與方能夠在有限的時間內提款。我們想證明，我們的狀態通道系統也具備這樣的特性。特別是，我們想證明，借助通道中交換的狀態，無論其他參與方采取了什么行動，Alice總是能在鏈上找到通向最終結果的一條路徑。而且，這樣的結果應該是「最新的」，因為其圈數應至少與Alice當前的通道狀態一樣大。

Radiant Capital推出DEV UPDATES，即將上線以太坊主網:7月18日消息，多鏈借貸協議Radiant Capital推出DEVUPDATES，包含一系列已完成的里程碑、當前的主要任務以及未來規劃，其中OpenZ eppelin的審計相關更新已經完成；FE團隊正在通過UI/UX優化來加強他們的游戲，同時正在研究應用程序性能；此外Radiant Capital即將上線以太坊主網，目前開發團隊正在審查Radiant代碼庫和UI/UX以實現以太坊主網集成，團隊正在為平穩過渡做準備。[2023/7/18 11:01:24]

出于其他的一些原因，我們首先研究了智能合約的形式驗證，很快我們就意識到形式驗證無法實現我們需要的擔保程度。智能合約的形式驗證能說明協議的實現沒有問題，但是無法證明協議本身具備我們期望的性質。例如，如果你提交了一次force-move，并簽署上正確的狀態，形式驗證能證明注冊了一次質詢，但是用戶如果想要在有限的時間內退出，無論其如何操作，形式驗證無法證明用戶所調用的一系列force-move操作。

在此背景下，Andrew發現并意識到也許TLA正是我們所需要的。

TLA是一種形式化規范語言，用于搭建算法或系統模型的工具，然后以編程方式驗證此模型是否具備特定的屬性。1999年，LeslieLamport發布了這個工具，用來編寫證明ByzantinePaxos正確性的形式證明。近期，AWS的工程團隊將其應用在了工業中，用于發現并修復DynamoDB中的并發性問題。

由于TLA的功能，有人將其描述成可充分測試的偽代碼。正是這一點使其符合我們的需要。我們意識到，可以基于裁決人以及在通道中與之交互的參與方，搭建一個模型。借助此模型及TLA，我們可以找出所有可允許操作的潛在序列，找出在哪些場景下，Alice無法在指定的時段內提款。而且，如果我們能按照「對于長度為n的所有可能的操作序列，Alice能在m步之內取出其資金，且m收獲的見解

本節總結了TLA在從初版到最新版的連續三版協議下的應用情況。在該狀態庫中可找到模型的代碼以及關于結果重建的說明。

在深入此模型之前，我們希望先呈現以下內容，因為據我們猜測，會有很多人對這些內容感興趣。如果想了解全部的細節，建議先閱讀最后的「模型」章節。

數據：72%的ETH流動性集中在Binance、Bitfinex、OKX、Coinbase和Kraken:5月30日消息，Kaiko 數據顯示，72% 的 ETH 流動性集中在 5 個交易所，分別為Binance、Bitfinex、OKX、Coinbase 和 Kraken，所有其他 41 家交易所僅占市場深度的 28%。在 FTX 崩潰之前，FTX 及 FTX.US 占市場流動性的份額曾高達近 40％。目前美國交易所的市場深度份額約為 40%，低于去年 5 月 Terra 崩盤前 54% 的歷史高位。[2023/5/30 9:49:49]

第一次嘗試

我們首先嘗試了force-move白皮書中定義的協議版本，這一版協議對gas進行了優化。此協議與《上手狀態通道退出游戲》一文中的玩具模型非常相似，區別在于，在此版本下，可以從質詢中「恢復」并繼續進行鏈下交互，而不必在發起首次質詢后就結束。為了防止質詢進入無限循環，裁決人需要跟蹤其觀察的最新受支持狀態的輪號，并且只能允許可使此數值增大的質詢。與裁決人進行交互的方法可總結如下：

這有一種發起質詢的方法：forceMove(m,s*,p)操作要求受支持狀態s*需要帶有輪號m，并且該操作必須由通道參與方p發起。假設m大于鏈上的輪號，則通道轉換成質詢狀態Chal(m,s,p)。

這里有三種響應force-move的方式。分別是：respond、refute和altRespond：

respond：是響應質詢的「預期」方式

響應人提供下一狀態，然后在鏈下繼續進行交互。鏈上的輪號計數器會計數，因為響應狀態擴展了受支持的質詢狀態，故之后會再創建一個受支持的狀態。refute：是響應狀態質詢的一種方式

響應人提供由質詢人簽名的下一狀態。這么做可以代表質詢人證明可證明的不良行為，所以，此時有機會在協議中構建slashing這種方式也非常高效，因為我們不需要檢查任何狀態轉換由于參與方只能看到一個狀態，也就不需要告訴他們最新的受支持狀態，所以鏈上的輪號計數器不會計數altRespond：當參與方用相同的輪號簽名了多個狀態時，需要用到這種方式來說明情況

基于Solana的memecoin項目Bonk Inu宣布推出DEX:金色財經報道，基于 Solana 的 memecoin 項目 Bonk Inu(Bonk)開發人員宣布推出去中心化交易所 (DEX)，名為 BonkSwap 的 DEX 將利用 Solana 智能合約允許用戶交換 solana (SOL)、bonk inu (BONK) 和穩定幣。BonkSwap 的 80% 將用于獎勵流動性提供者以及 Bonk 和 BonkSwap LP 頭寸的鎖定利益相關者。[2023/4/13 14:01:53]

響應者提供一個會使輪號計數器1的新受支持狀態。由于下一個受支持狀態是可見的，所以鏈上的輪號計數器也會計數。這就是響應人在說：「你已經質詢了狀態s，但你之前給我發了一個狀態s'，所以我想從s'那里開始」在任何情況下，由于性能優化的影響，必須提供質詢狀態s的一個副本，因為在優化版中，鏈上只儲存了s的哈希值。接下來你會看到，這個看似微不足道的變化會對協議的健全性產生相當大的影響。

TLA裁定

我們編寫了這個模型的代碼，接著在TLA中跑了一遍。TLA并不喜歡這個模型，并且發現了以下失敗場景：

從Open(n)狀態開始2.Alice調用了forceMove(n,s,Alice)3.Eve利用forceMove(n,s,Eve)進行超前交易，將裁決人至于Chal(n,s,Eve)狀態下。4.Alice的force-move從第2步開始失敗。5.Eve調用refute(nk,s,s')，其中k大于1，這樣的話就輪到了Eve，并且s'可以是任何輪號為nk的有效狀態。通道返回至Open(n)狀態。轉到第1步。TLA發現了一個無限循環，這個循環使Eve可以將資金無限期地鎖定在通道中！當然，Eve必須付款，但是，每次交易失敗時，Alice也在損失資金。而且損失率非常偏向Eve：對應Alice的一筆交易，Eve只需提交兩筆交易。無論如何，協議中都存在嚴重的漏洞。

不過，修復辦法可不容易找到。造成這種循環的原因是refute不會使鏈上的輪號計數器計數，因為參與方不一定會看到新的受支持狀態。驗證鏈上的交易是確定存在新的受支持狀態的唯一方法，但是refute的意義就在于取消可查驗的不良質詢，從而不耗費gas去運行鏈上的轉換函數。

Zhu Su：FTX和Alameda自成立以來就混在一起，SBF自7月以來就已資不抵債:12月1日消息，Zhu Su發推稱，FTX和Alameda自成立以來就混在一起。SBF自7月以來就已資不抵債，他有很多瘋狂的行為，包括：對貸方的虛假救助；籌集下一輪資金激怒前投資者等。Zhu Su還表示，了解FTT的起源，Alameda/FTX的整個商業模式是向其他交易公司提供短期流動性上虧損，以吸引交易量和交易員，再通過掠奪性的自由交易賺回利潤。[2022/12/1 21:14:47]

我們想出的一種辦法是在鏈上保存一份在當前的輪號計數器下已經成功調用了force-move的參與方名單，從而確保輪號計數器每次1時，參與方只能調用一次force-move。由于對通道中參與方的數量沒有限制，我們認為這樣做太復雜了，同時浪費gas。最終，我們決定完全刪除refute操作，以精簡該協議。去掉對狀態質詢響應的優化也不是什么大問題，因此在此情況下，我們仍然可以選擇引入slashing，同時退還響應人的gas費用，這樣似乎是一種更能激勵正確行為的方式。

第二次嘗試

在刪除refute后，我們保留了以下操作：

TLA裁定

我們在TLA中跑了一遍這個新模型。

這次的結果變好了：Alice總是能使通道向前走。但是，其中仍存在造成損失的機會，Eve可以拖延Alice一會兒，而具體拖多久則與當前的輪號成比例：

從Open(0)狀態開始2.Alice調用forceMove(n,s,Alice)3.Eve利用forceMove(0,s0,Eve)進行超前交易，裁決人轉換至Chal(0,s0,Eve)。4.Alice的force-move失敗。然后，Eve調用respond(1,s0,s1)，將通道轉換至Open。。6.Alice調用forceMove(n,s,Alice)7.Eve利用forceMove(1,s1,Eve)進行超前交易8.……諸如此類看來這里出現的問題至少與第4步存在一定的關聯：forceMove函數之所以失敗，是因為在交易提交后，鏈的狀態已經變化了。我們意識到，forceMove應當覆蓋之前的質詢，并且使操作盡可能適用于更多的鏈狀態似乎是不錯的設計原則。

上海虛擬體育公開賽暨莓塔體育元宇宙開啟:金色財經報道，據上海久事智慧體育官方公眾號，首屆上海虛擬體育公開賽(Shanghai Virtual Sports Open，簡稱SVS)暨莓塔體育元宇宙5日開啟。SVS賽事是中國首個虛擬體育綜合性賽事，納入了虛擬賽艇、虛擬賽車、虛擬滑雪、虛擬騎行、虛擬高爾夫5個項目。[2022/8/6 12:06:18]

第三次嘗試

在第三次嘗試時，我們重寫了forceMove，使其能適用于質詢狀態，并且不再需要提供鏈上質詢狀態。在實現這一點的同時保證gas效率是個挺有趣的挑戰，因為需要將大量的信息壓縮至現有的bytes32通道存儲區中。

此外，我們還考慮了另外的移動操作，也意識到了一些問題。首先，不應該將altRespond限制成僅使輪號1，由于已經提供了完整的受支持狀態，所以，無論增加了多少，都應使輪號計數器增至該狀態的輪號。其次，這種情況不能僅發生在質詢狀態下，例如，當你需要長時間下線時，為了先發制人地提前排除大多數質詢，根據開放狀態增加輪號計數器也是非常實用的。

綜上，altRespond像是更基本的操作，因此我們決定將其重命名為checkpoint。然后，我們開始把respond視作更高效的checkpoint版本，用一個后續狀態，優化了對force-move的響應。我們最終得到了以下一系列操作：

TLA裁定

成功！TLA沒發現任何問題，所以通過窮舉搜索，我們知道此協議是可靠的。

不僅如此，假如Alice提交了forceMove(n,s,Alice)，Alice僅需一筆交易就能使通道向前走。此交易失敗的唯一可能是鏈上輪號計數器的次數>n，在此情況下，通道已經前進了，并且Alice完成了交易。如果交易成功，則裁決人處于Chal(n,s,Alice)狀態下，接下來的唯一可能是鏈上的輪號計數器計數或超時，從而結束通道。因此，僅提交一項交易，Alice就實現了其目的。

這樣可以保證條理有序，因為我們能嚴格限制Alice需要提交多少次交易才能退出通道：在最壞的情況下，Alice需要調用k個事務，其中k是參與方的數量。第一個參與方k-1首先使通道向前走，直到輪到Alice為止，如上所述，最后一個用來force-move她自己，完成后，她便不再響應。

協議建模

在本節中，我們將更詳細介紹如何設置TLA規范以上述內容。如果對本節不感興趣，可以放心地跳過。

在深入研究我們的TLA建模決策之前，值得花一點時間來回顧我們的狀態通道協議有哪些關鍵特性：force-move協議圍繞輪流制構建。在通道中交換的每個狀態都有一個輪號，通過輪號可以確定哪個參與方在當時有權使通道向前走。例如，在有兩個參與方的通道中，如果第一個參與方負責所有的偶數輪號，第二個參與方負責所有的奇數輪號。那么，一個狀態必須由當時輪到的那個人簽名，才能成為有效狀態轉換的一部分。

另外，引入受支持狀態的概念也非常有用。在有k個參與方的通道中，受支持狀態s*是k個狀態之間有效轉換的序列，其最終狀態為s：s1->...->sk=s。由于輪流屬性，受支持狀態總會包含各個參與方的簽名。受支持狀態類似于輪流制的完全簽名狀態，即表示所有參與方均參與了將通道推進至該狀態。

下一步是檢查我們要證明的內容，看看是否可以減少問題，以簡化輸入TLA的模型。

我們想證明，Alice有一種策略，這種策略使她可以無視其他參與方所采取的操作，始終能在有限時間內得出鏈上最終敲定的最新結果。我們實際證明的是以下主張成立：

通道進度聲明：如果Alice看到最新受支持狀態的輪號是n，那么她可以獲得一個輪號>n的受支持狀態，或者確保通道結束時狀態的輪號>=n。為什么這就夠了？假設在輪號是nm時會再次輪到Alice。如果Alice不用這個輪號簽名任何狀態，那么沒有受支持的狀態會帶有此輪號或更高的輪號。因此，通過應用m次通道進度聲明，唯一可能的結果是該通道最終結束時狀態的輪號>=n。

我們還需要指定該聲明成立的條件。我們的模型捕捉了以下場景：

Alice是狀態通道中一名誠實的參與方，持有受支持的狀態，狀態的輪號是n。Alice的目標是獲得一個輪號大于n的受支持狀態，或在輪號大于等于n的狀態下關閉通道Alice只儲存了最后一輪的狀態，因此只能訪問最新受支持的狀態。的數量而非狀態總數來擴展。）Alice總是能在質詢期內將交易打包，但是無法進行超前交易，也無法阻止別人進行超前交易。僅在輪到她的時候，Alice才能給狀態簽名，并且表示從她所持有的受支持狀態開始的有效轉換。Eve是她的對手，控制著通道中其他的參與方。Eve儲存了在通道中交易的所有歷史狀態。Eve愿意給過去或未來的任何狀態簽名，但不表示從她所持有的受支持狀態開始的有效轉換。她無法簽名的狀態是那些輪到Alice簽名的狀態，其輪號>n，因為這些狀態只有Alice可以簽名，但她還沒簽。Eve可以任意地在Alice之前進行超前交易，但無法阻止Alice的交易在質詢期內被打包。

如何用TLA給此場景建模？如果你夠勇敢，可以去代碼中自己找，也可以看我們在這里的總結概括。

首先要了解的是，TLA規范涉及到了多個過程，這些過程創建了修改共享狀態的操作。在模擬系統時，TLA會搜索通過插入過程操作創建的所有潛在序列，在達到共享狀態上的某些條件時，則會停止各個序列。

在我們的案例中，Alice和Eva是獨立的過程，裁決人構成共享狀態的一部分。為了捕獲到超前交易行為，我們需要引入一個額外的過程和狀態——交易處理器和交易池。當Eve流程直接修改裁決人狀態時，Alice只能將交易放入交易池中，然后交易池會把此交易交給裁決人。

TLA的概念是「公平過程」，即其行動不會受到無限阻礙的過程。這正是我們建模「Eve可以任意地在Alice之前進行超前交易，但Alice最終會得到一筆交易」的行為所需要的工具。我們沒有明確地對超時本身進行建模，因為我們知道，只要Alice或Eve持有能避免超時的狀態，她們一定會避免超時。因此，發生超時的情況恰好是無法采取其他行動的情況，而TLA會自動阻止這種情況的發生。

就成功標準而言，有必要把聲明從「Alice可在有限的時間內成功」改成「Alice可在N步內成功」，其中N由我們決定。在這樣的修改后，我們可以確保TLA是在有限的、可管理的狀態空間內進行搜索。

另外，我們還選出了一對參與方來進行模擬。具體地說，我們證明了「在任何由2個參與方組成的通道內，Alice可以在5步內實現其目標」。當然，盡管還不足以證明所有通道的聲明，但是，確實為由少量參與方組成的通道提供了堅實的保障，這正是我們在實際應用中所關心的。我們也越來越相信，這種方法適用于任意數量的參與方，即便有額外的參與方，也不會有任何變化——在設置模型時，我們就有這種感覺。

總結

在本文中，我們解釋了如何用TLA證明force-move協議為狀態通道提供了擔保，以確保你能提款。

下周，隨著Web3Torrent項目的發布，我們將從理論轉向實踐。Web3Torrent改善了Webtorrent的點對點文件共享，在狀態通道上構建了點對點微支付。我們希望它能證明當今狀態通道的可能性，啟發更多人在其機制設計中使用微支付/狀態通道。敬請期待！

來源鏈接：blog.statechannels.org

免責聲明：作為區塊鏈信息平臺，本站所發布文章僅代表作者個人觀點，與鏈聞ChainNews立場無關。文章內的信息、意見等均僅供參考，并非作為或被視為實際投資建議。

幣安

幣安

幣安Binance區塊鏈數字資產交易平臺，引領幣幣交易創新模式，為用戶提供更加安全、便捷的數字貨幣兌換服務，聚合全球優質數字貨幣，致力于打造世界級的區塊鏈資產交易平臺。提供比特幣、以太坊、萊特幣、幣安幣等主流加密數字貨幣交易。公司幾乎所有的資產，包括對于交易收取的費用及拿到的融資，都以加密數字貨幣形式保存。幣安BinanceBNBBinanceChainBinanceLabsBinanceLabs幣安慈善幣安慈善基金會幣安孵化器BinanceDEX幣安寶幣安研報幣安研究院BinanceResearch幣安美國BinanceFuturesBinanceLaunchpad幣安云BinanceCloudBinanceCardBinance.US幣安Launchpad幣安LaunchpoolBinancePay查看更多

Tags：LICALIALICEICESoliceALIF CoinChalice FinanceRICE

聚幣