長話短說：StarkPay 是一種基于STARK技術(shù)的可擴(kuò)展支付引擎，它可以解決第二層（Layer-2）支付解決方案閃電網(wǎng)絡(luò)（Lightning）的許多缺點(diǎn)。

StarkWare 的第一個 STARK 技術(shù)應(yīng)用是一個 Layer-2 可擴(kuò)展引擎。我們最近發(fā)布了 StarkDEX，一個去中心化交易所（DEX）可擴(kuò)展引擎。

我們將該可擴(kuò)展引擎應(yīng)用于加密貨幣支付場景，構(gòu)建了 StarkPay。穩(wěn)定幣的出現(xiàn)滿足了密碼學(xué)貨幣作為交換媒介的必要條件。然而，該生態(tài)系統(tǒng)依舊缺少一個可擴(kuò)展支付系統(tǒng)。我們相信 StarkPay 能夠滿足這一需要。

本文將對比分析 StarkPay 與閃電網(wǎng)絡(luò)（最著名的比特幣支付可擴(kuò)展性解決方案）。我們將首先回顧閃電網(wǎng)絡(luò)的優(yōu)缺點(diǎn)。然后，闡述 StarkPay 基礎(chǔ)架構(gòu)，并舉例說明其執(zhí)行流程。最后，分析 StarkPay 的優(yōu)缺點(diǎn)，以及缺點(diǎn)的改進(jìn)方案。

本文將不探討兩種方案隱私保護(hù)方面的內(nèi)容。

閃電網(wǎng)絡(luò)

自 Poon 與 Dryja 2016 年發(fā)布白皮書以來，閃電網(wǎng)絡(luò)引起了公眾的廣泛關(guān)注。閃電網(wǎng)絡(luò)目前擁有超過 3000 個節(jié)點(diǎn)，全網(wǎng)鎖定資產(chǎn)價值超過 200 萬美元。閃電火炬接力賽（Lightning Torch）的金額也已超過 100 美元，高科技巨頭 Jack Dorsey 與 Reid Hoffman、金融巨頭 Fidelity 等也都參與其中。

Lightning 是為了擴(kuò)展比特幣網(wǎng)絡(luò)而提出的。作為最早一批出現(xiàn)的 Layer-2 解決方案之一，它天才地提議將交易轉(zhuǎn)移到鏈下處理，而不改變區(qū)塊鏈的安全模型。它希望不僅能夠提升交易規(guī)模，還能夠保證低延遲與最低交易費(fèi)。

閃電網(wǎng)絡(luò)也有幾個缺點(diǎn)：

活性需求：付款方必須在線才能完成付款——這一點(diǎn)沒什么奇怪的。但是，與比特幣不同，在閃電網(wǎng)絡(luò)中，收款方也必須在線，以便使用雙方的私鑰對鏈下交易簽名（稍后將詳細(xì)闡述操作的安全考慮）。更糟糕的是，從交易雙方建立鏈下通道開始，收款人就必須一直監(jiān)測區(qū)塊鏈狀態(tài)，以確保付款人不會將他們余額的舊狀態(tài)提交上鏈并關(guān)閉通道。路由節(jié)點(diǎn)也必須在上下游通道超時之前在線，以便在上游 HTLC（哈希時間鎖）超時之前參與協(xié)議、履行職責(zé)（即路由支付請求）。

閃電網(wǎng)絡(luò)試圖引入瞭望塔節(jié)點(diǎn)來解決用戶需要持續(xù)監(jiān)測區(qū)塊鏈的問題。瞭望塔節(jié)點(diǎn)通過向用戶收取費(fèi)用來提供區(qū)塊鏈網(wǎng)絡(luò)狀態(tài)監(jiān)測服務(wù)。

資金利用率低：一般來說，為了方便使用，付款方愿意鎖定一些資產(chǎn)（例如：使用借記卡）。但是在閃電網(wǎng)絡(luò)中，每個用戶需要在每個通道都鎖定一筆資金，從而將一個用戶的資金打散。

更糟糕的是，如果鏈下交易不是直接從付款方發(fā)送給收款方（例如：轉(zhuǎn)移金額為 X），而是通過其他路由節(jié)點(diǎn)轉(zhuǎn)發(fā)，那么所涉及的路由節(jié)點(diǎn)也需要鎖定數(shù)量至少為 X 的資金。

在理想情況下（從資金利用率的角度考慮），單一中心節(jié)點(diǎn)的星型網(wǎng)絡(luò)流動性上限為中心節(jié)點(diǎn)愿意鎖定的資金量。付款方的鎖定資金對于網(wǎng)絡(luò)流動性毫無貢獻(xiàn)。換句話說，需要路由節(jié)點(diǎn)來給網(wǎng)絡(luò)帶來流動性，這是一個令人有點(diǎn)驚訝又不合需要的特性。

要是我們再想避免形成這樣的中心化網(wǎng)絡(luò)，又會遇到什么樣的問題呢？降低網(wǎng)絡(luò)中心化水平需要增強(qiáng)路由路徑選擇的多樣性。但是在一筆轉(zhuǎn)賬中，參與路由的節(jié)點(diǎn)越多，交易資金成本就會越高（這是因為用于路由的資金需要在一段時期內(nèi)鎖定，在鎖定期間并不能產(chǎn)生利息）。具體而言，如果 Alice 想通過 5 個路由節(jié)點(diǎn)向 Bob 發(fā)送 1 個比特幣，那么總共就需要在閃電網(wǎng)絡(luò)中鎖定 5 個比特幣。這種成本（以及路由節(jié)點(diǎn)不配合時的惡意攻擊成本）必須轉(zhuǎn)化為交易方所承擔(dān)的費(fèi)用。現(xiàn)在閃電網(wǎng)絡(luò)中并向付款方未收取這部分費(fèi)用，而是基于網(wǎng)絡(luò)早期用戶的利他行為來維持網(wǎng)絡(luò)正常運(yùn)轉(zhuǎn)。

閃電網(wǎng)絡(luò)生態(tài)系統(tǒng)的中心化趨勢能夠緩解資金利用率低下的問題。閃電網(wǎng)絡(luò)中心化程度顯然是一個有趣的話題。

運(yùn)營安全挑戰(zhàn)：中心化交易所最具爭議的點(diǎn)是，它們創(chuàng)造了一種蜜罐，會引來攻擊者的攻擊。但是，隨著網(wǎng)絡(luò)的擴(kuò)大，閃電網(wǎng)絡(luò)路由節(jié)點(diǎn)會創(chuàng)建更多臨時蜜罐。設(shè)想一下熱錢包中有一個私鑰需要暴露的情況：中心化交易所只需要在它們選擇的時間段內(nèi)短暫暴露私鑰。但在閃電網(wǎng)絡(luò)中，路由節(jié)點(diǎn)為了提供幾乎實(shí)時的服務(wù)，必須一直暴露私鑰。與此同時，為了提供穩(wěn)定的路由服務(wù)，它們需要保證每個通道都有足夠的資金。這就構(gòu)成了一個理想的蜜罐：充足的資金與在熱錢包中暴露的私鑰。為了彌補(bǔ)保護(hù)這個蜜罐所需投入的資本，路由節(jié)點(diǎn)很可能將這部分投入增加到交易費(fèi)當(dāng)中。

交易完成率隨支付金額增加而降低：考慮到多跳支付中的每個通道都需要鎖定超過支付金額的資金，這些支付在網(wǎng)絡(luò)中可選擇的路由更少，因此更高金額的交易支付完成可能性更低。由于通道路由限制了容量大小，支付金額增加可能導(dǎo)致交易費(fèi)用也會水漲船高。理想情況下，用戶當(dāng)然希望交易完成率獨(dú)立于交易金額。

交易完成率隨方向性增強(qiáng)而降低：與增加支付金額的負(fù)面影響類似，當(dāng)許多付款方同時向一個收款方支付費(fèi)用時（例如：真實(shí)世界中消費(fèi)者向商家付款），他們會爭奪有限的（指向收款方的）路由節(jié)點(diǎn)資金容量。請注意，閃電火炬接力賽并沒有證明閃電網(wǎng)絡(luò)能應(yīng)付這種場景。

總的來說，閃電網(wǎng)絡(luò)總資源消耗似乎不僅僅與參與者的數(shù)量或支付金額相關(guān)，還與支付筆數(shù)成比例。這對于支付擴(kuò)容方案來說顯然是一種硬傷。

［插播：為了簡單起見，我們假設(shè)閃電網(wǎng)絡(luò)中路由問題已經(jīng)被完美解決，并且免費(fèi)提供服務(wù)。當(dāng)然，有些人認(rèn)為這是一個難題］

StarkPay

StarkPay 的目標(biāo)是提供一種無活性需求的、可擴(kuò)展、資金高效、非托管的支付解決方案。

StarkPay 由鏈下組件與鏈上組件兩個部分組成。

鏈下

· 支付處理者：與付款方與收款方交互。

· 付款方余額樹：由 Prover（證人節(jié)點(diǎn)） 更新，并且保證可用性（后文詳述）。

· 證人節(jié)點(diǎn)（Prover）：產(chǎn)生 STARK 證據(jù)，從而證明支付處理者傳來的幾批支付的有效性，以及付款方余額更新的有效性。

鏈上

· 支付合約：StarkPay 的資金入/出（鎖定/解鎖）站，同時存儲更新付款者余額的承諾（付款者余額更新存儲在鏈下，待驗證者合約驗證通過后將承諾存儲在鏈上）。

· 驗證者合約：驗證由證人節(jié)點(diǎn)（Prover）產(chǎn)生的 STARK 證據(jù)，并將驗證結(jié)果反饋給支付合約。

讓我們將以上模型帶入一些基本場景：

存款（“入站”）

付款者向支付合約存入密碼學(xué)貨幣。通過 STARK 證據(jù)將存入資金轉(zhuǎn)移到鏈下余額樹。此操作類似于閃電網(wǎng)絡(luò)通道建立過程，但有一個很重要的區(qū)別在于，StarkPay 中 “入站” 操作可以指定多個資產(chǎn)接收方地址。

取款（“出站”）

同樣通過使用 STARK 證明證據(jù)，將鏈下余額樹中資金轉(zhuǎn)移至支付合約，之后付款方便可從支付合約中取出余額。此操作類似于閃電網(wǎng)絡(luò)的通道關(guān)閉過程。

Alice 通過 StarkPay 向 Bob 轉(zhuǎn)賬

· Alice 簽名向 Bob 發(fā)送一筆交易，并將該交易發(fā)送給支付處理者（Alice 并沒有放棄她的資金監(jiān)管權(quán)）。

· 支付處理者將一批支付交易（包括 Alice 的支付）發(fā)送給證人節(jié)點(diǎn)。

· 證人節(jié)點(diǎn)生成這批支付的 STARK 證據(jù)，以證明這批支付以及賬戶余額更新的有效性，具體過程如下：

檢驗支付的數(shù)字簽名；

驗證付款方有充足的資金；

更新余額承諾（例如：Merkle 樹根）。

· 證人節(jié)點(diǎn)向鏈上的驗證合約發(fā)送 STARK 證明證據(jù)以及余額承諾。如果驗證通過，驗證者就向支付合約發(fā)送新的余額承諾，并將其存儲在鏈上（如上文所述）。

對于證人不需要引入信任假設(shè)，惡意或粗心大意的證人無法讓驗證合約相信無效證明是有效的。

優(yōu)勢

我們相信 StarkPay 體系架構(gòu)能夠提供預(yù)期的優(yōu)勢：

可擴(kuò)展性：StarkPay 所消耗的計算資源隨著付款者以及支付的數(shù)量增加而增大。更重要的是，計算資源的變化不再與流通總金額掛鉤。我們已經(jīng)達(dá)到了一個比較理想的結(jié)果：StarkPay 在單個區(qū)塊（當(dāng)前 Etherum gasLimit 限制內(nèi)）內(nèi)能夠支持超過 10000 筆交易。

值得注意的是，STARK 適度地消耗了極為稀缺的鏈上計算資源：它所消耗的資源隨著鏈下計算規(guī)模的增加以對數(shù)方式增長。具體而言：為使 StarkPay 吞吐量提升 10 倍，鏈上計算資源消耗僅需增加不到 50%。

插播：如果將擴(kuò)容的標(biāo)準(zhǔn)設(shè)置為 金額/秒 而不是 交易量/秒，那么 StarkPay 其實(shí)是沒有上限的。

資金利用率高：就像借記卡那個比喻一樣，在 StarkPay 中，除了每個付款方希望在鏈下用于支付的資金外，不需要鎖定額外的資金。尤為重要的是，對支付處理者與證人沒有流動性要求。

無活性需求：收款方余額更新時無需其保持在線。在所有場景中（存款、取款與支付），交易都可以離線構(gòu)造并在之后發(fā)送給區(qū)塊鏈或支付處理者。

非托管：付款方無需將加密貨幣托管給 StarkPay。所有操作都需要付款方簽名，即便在證人作惡或者不合作的情況下，他們也可以隨時直接從支付合約（Payment contract）中取出鎖定資金（后續(xù)博客將詳細(xì)闡述有關(guān)安全退出的內(nèi)容）。

在這方面，StarkPay 與 閃電網(wǎng)絡(luò)的效果相同，用戶仍然保留對資金的控制權(quán)。

劣勢

StarkPay 有一些明顯的缺點(diǎn)：

數(shù)據(jù)可用性：為了充分利用 STARK 的鏈上對數(shù)擴(kuò)展性，數(shù)據(jù)最好存儲在鏈下，但這就會帶來交易數(shù)據(jù)不可用的問題。為了去信任，并且打破可擴(kuò)展性上限，數(shù)據(jù)有效性是每個基于 Plasma 的擴(kuò)容方案必須解決的挑戰(zhàn)。

改進(jìn)方案：

· 鏈上分批記錄交易：我們認(rèn)為在這種模式下 StarkPay 能夠輕松達(dá)到每秒處理幾百筆交易。

· 未來鏈下數(shù)據(jù)一個可能的方向：構(gòu)建數(shù)據(jù)可用性見證聯(lián)盟，聯(lián)盟對提交給鏈上驗證者合約的證明簽名就表示數(shù)據(jù)在鏈下是可用的。鏈上驗證者合約將不接受缺少此證明的證據(jù)。值得注意的是，該聯(lián)盟沒有被委托保證系統(tǒng)狀態(tài)的有效性 —— 他們不能盜竊資金，也不能將讓系統(tǒng)狀態(tài)失效。

為了支持更加去中心化的解決方案，這個聯(lián)盟之后將逐步被淘汰。

中心化：證人（Provers）節(jié)點(diǎn)最初將由 StarkWare 運(yùn)營。這帶來的中心化與審查的風(fēng)險。

改進(jìn)方案：

· 中心化：其他市場參與者（包括其他支付處理者），自然會提供自己的證人節(jié)點(diǎn)（Provers）。從長遠(yuǎn)來看，證人節(jié)點(diǎn)可以通過共識算法在網(wǎng)絡(luò)中競爭證據(jù)生成業(yè)務(wù)。注意，由于狀態(tài)僅通過有效證明來改變，證人節(jié)點(diǎn)不能通過切換到無效狀態(tài)來攻擊網(wǎng)絡(luò)，在這個意義上，StarkPay 的方法很像第一層（Layer-1）共識的解決方案。

· 審查：在 StarkPay 上，STARK 也可以用來保護(hù)隱私。具體而言，付款方可以隱藏他們的交易內(nèi)容，即便是證人節(jié)點(diǎn)也無法獲取。由證人節(jié)點(diǎn)生成的計算聲明是它驗證了從付款者收到的一批獨(dú)立交易后生成的，因此他人無法從中追溯單筆交易。

延遲：與點(diǎn)對點(diǎn)閃電通道保證的即時結(jié)算不同，目前為大批量交易生成證明所需的時間大約是幾分鐘。

改進(jìn)方案：

· 證人節(jié)點(diǎn)可以在驗證收到的一批交易之后，立即向鏈上的支付合約提交承諾，并同時生成證明證據(jù)。收款人有幾分鐘的時間需要承擔(dān)證人節(jié)點(diǎn)會無限期扣留證據(jù)的風(fēng)險。該風(fēng)險可以通過持有證人節(jié)點(diǎn)基金來補(bǔ)償。值得注意的是：StarkPay 的延遲是主鏈對于證據(jù)提交交易的共識延遲，而不是閃電網(wǎng)絡(luò)中近乎即時的鏈下節(jié)點(diǎn)交易處理延遲。

同時，延遲不應(yīng)該等同于吞吐量：StarkPay 能夠通過提升證人節(jié)點(diǎn)計算資源（全部都在鏈下的資源）的方式，來達(dá)到更高的吞吐量水平。

沒有適用于比特幣的解決方案：以目前的形式，比特幣尚不能支持高效鏈上 STARK 驗證。

緩解措施：如果你有解決方案的話，一定要告訴我們。在此之前，我們將集中精力適配支持高效鏈上 STARK 驗證的區(qū)塊鏈。

本文我們介紹了一種適用于加密貨幣支付場景的基于 STARK 算法的可擴(kuò)展引擎（StarkPay）。我們首先分析了當(dāng)前最熱門的比特幣擴(kuò)容方案 —— 閃電網(wǎng)絡(luò)，并將其與 StarkPay 進(jìn)行了比較。我們的結(jié)論是，StarkPay 提供了一種引人注目的替代方案，能夠在幾個值得注意的維度對閃電網(wǎng)絡(luò)進(jìn)行改進(jìn)。
責(zé)任編輯；zl