長話短說：StarkPay 是一種基于 STARK 技術的可擴展支付引擎，它可以解決第二層(Layer-2)支付解決方案閃電網絡(Lightning)的許多缺點。-圖片
長話短說：StarkPay 是一種基于 STARK 技術的可擴展支付引擎，它可以解決第二層(Layer-2)支付解決方案閃電網絡(Lightning)的許多缺點。
-圖片來源：Unsplash，作者：Cade Roberts-
StarkWare 的第一個 STARK 技術應用是一個 Layer-2 可擴展引擎。我們最近發布了 StarkDEX，一個去中心化交易所(DEX)可擴展引擎(早期成果請查看該鏈接)。
我們將該可擴展引擎應用于加密貨幣支付場景，構建了 StarkPay。穩定幣的出現滿足了密碼學貨幣作為交換媒介的必要條件。然而，該生態系統依舊缺少一個可擴展支付系統。我們相信 StarkPay 能夠滿足這一需要。
本文將對比分析 StarkPay 與閃電網絡(最著名的比特幣支付可擴展性解決方案)。我們將首先回顧閃電網絡的優缺點。然后，闡述 StarkPay 基礎架構，并舉例說明其執行流程。最后，分析 StarkPay 的優缺點，以及缺點的改進方案。
本文將不探討兩種方案隱私保護方面的內容。
閃電網絡
自 Poon 與 Dryja 2016 年發布白皮書以來，閃電網絡引起了公眾的廣泛關注。閃電網絡目前擁有超過 3000 個節點，全網鎖定資產價值超過 200 萬美元。閃電火炬接力賽(Lightning Torch)的金額也已超過 100 美元，高科技巨頭 Jack Dorsey 與 Reid Hoffman、金融巨頭 Fidelity 等也都參與其中。
閃電網絡也有幾個缺點：活性需求：
付款方必須在線才能完成付款——這一點沒什么奇怪的。但是，與比特幣不同，在閃電網絡中，收款方也必須在線，以便使用雙方的私鑰對鏈下交易簽名（稍后將詳細闡述操作的安全考慮）。更糟糕的是，從交易雙方建立鏈下通道開始，收款人就必須一直監測區塊鏈狀態，以確保付款人不會將他們余額的舊狀態提交上鏈并關閉通道。路由節點也必須在上下游通道超時之前在線，以便在上游 HTLC（哈希時間鎖）超時之前參與協議、履行職責（即路由支付請求）。
閃電網絡試圖引入瞭望塔節點來解決用戶需要持續監測區塊鏈的問題。瞭望塔節點通過向用戶收取費用來提供區塊鏈網絡狀態監測服務。
資金利用率低：
一般來說，為了方便使用，付款方愿意鎖定一些資產(例如：使用借記卡)。但是在閃電網絡中，每個用戶需要在每個通道都鎖定一筆資金，從而將一個用戶的資金打散。
更糟糕的是，如果鏈下交易不是直接從付款方發送給收款方(例如：轉移金額為 X)，而是通過其他路由節點轉發，那么所涉及的路由節點也需要鎖定數量至少為 X 的資金。
在理想情況下(從資金利用率的角度考慮)，單一中心節點的星型網絡流動性上限為中心節點愿意鎖定的資金量。付款方的鎖定資金對于網絡流動性毫無貢獻。換句話說，需要路由節點來給網絡帶來流動性，這是一個令人有點驚訝又不合需要的特性。
要是我們再想避免形成這樣的中心化網絡，又會遇到什么樣的問題呢?降低網絡中心化水平需要增強路由路徑選擇的多樣性。但是在一筆轉賬中，參與路由的節點越多，交易資金成本就會越高(這是因為用于路由的資金需要在一段時期內鎖定，在鎖定期間并不能產生利息)。
具體而言，如果 Alice 想通過 5 個路由節點向 Bob 發送 1 個比特幣，那么總共就需要在閃電網絡中鎖定 5 個比特幣。這種成本(以及路由節點不配合時的惡意攻擊成本)必須轉化為交易方所承擔的費用?，F在閃電網絡中并向付款方未收取這部分費用，而是基于網絡早期用戶的利他行為來維持網絡正常運轉。
閃電網絡生態系統的中心化趨勢能夠緩解資金利用率低下的問題。閃電網絡中心化程度顯然是一個有趣的話題。
運營安全挑戰：
中心化交易所最具爭議的點是，它們創造了一種蜜罐，會引來攻擊者的攻擊。但是，隨著網絡的擴大，閃電網絡路由節點會創建更多臨時蜜罐。設想一下熱錢包中有一個私鑰需要暴露的情況：中心化交易所只需要在它們選擇的時間段內短暫暴露私鑰。
但在閃電網絡中，路由節點為了提供幾乎實時的服務，必須一直暴露私鑰。與此同時，為了提供穩定的路由服務，它們需要保證每個通道都有足夠的資金。這就構成了一個理想的蜜罐：充足的資金與在熱錢包中暴露的私鑰。為了彌補保護這個蜜罐所需投入的資本，路由節點很可能將這部分投入增加到交易費當中。
交易完成率隨支付金額增加而降低：
考慮到多跳支付中的每個通道都需要鎖定超過支付金額的資金，這些支付在網絡中可選擇的路由更少，因此更高金額的交易支付完成可能性更低。由于通道路由限制了容量大小，支付金額增加可能導致交易費用也會水漲船高。理想情況下，用戶當然希望交易完成率獨立于交易金額。
交易完成率隨方向性增強而降低：
與增加支付金額的負面影響類似，當許多付款方同時向一個收款方支付費用時(例如：真實世界中消費者向商家付款)，他們會爭奪有限的(指向收款方的)路由節點資金容量。請注意，閃電火炬接力賽并沒有證明閃電網絡能應付這種場景。
總的來說，閃電網絡總資源消耗似乎不僅僅與參與者的數量或支付金額相關，還與支付筆數成比例。這對于支付擴容方案來說顯然是一種硬傷。
[插播：為了簡單起見，我們假設閃電網絡中路由問題已經被完美解決，并且免費提供服務。當然，有些人認為這是一個難題]
StarkPay
StarkPay 的目標是提供一種無活性需求的、可擴展、資金高效、非托管的支付解決方案。
組件
StarkPay 由鏈下組件與鏈上組件兩個部分組成。
鏈下
支付處理者：與付款方與收款方交互。
付款方余額樹：由 Prover(證人節點) 更新，并且保證可用性(后文詳述)。
證人節點(Prover)：產生 STARK 證據，從而證明支付處理者傳來的幾批支付的有效性，以及付款方余額更新的有效性。
鏈上
支付合約：StarkPay 的資金入/出(鎖定/解鎖)站，同時存儲更新付款者余額的承諾(付款者余額更新存儲在鏈下，待驗證者合約驗證通過后將承諾存儲在鏈上)。
驗證者合約：驗證由證人節點(Prover)產生的 STARK 證據，并將驗證結果反饋給支付合約。
讓我們將以上模型帶入一些基本場景：
存款（“入站”）
付款者向支付合約存入密碼學貨幣。通過 STARK 證據將存入資金轉移到鏈下余額樹。此操作類似于閃電網絡通道建立過程，但有一個很重要的區別在于，StarkPay 中 “入站” 操作可以指定多個資產接收方地址。
取款（“出站”）
同樣通過使用 STARK 證明證據，將鏈下余額樹中資金轉移至支付合約，之后付款方便可從支付合約中取出余額。此操作類似于閃電網絡的通道關閉過程。
Alice 通過 StarkPay 向 Bob 轉賬
Alice 簽名向 Bob 發送一筆交易，并將該交易發送給支付處理者(Alice 并沒有放棄她的資金監管權)。
支付處理者將一批支付交易(包括 Alice 的支付)發送給證人節點。
證人節點生成這批支付的 STARK 證據，以證明這批支付以及賬戶余額更新的有效性，具體過程如下：
檢驗支付的數字簽名;
驗證付款方有充足的資金;
更新余額承諾(例如：Merkle 樹根)。
證人節點向鏈上的驗證合約發送 STARK 證明證據以及余額承諾。如果驗證通過，驗證者就向支付合約發送新的余額承諾，并將其存儲在鏈上(如上文所述)。
對于證人不需要引入信任假設，惡意或粗心大意的證人無法讓驗證合約相信無效證明是有效的。
優勢
我們相信 StarkPay 體系架構能夠提供預期的優勢：
可擴展性：
StarkPay 所消耗的計算資源隨著付款者以及支付的數量增加而增大。更重要的是，計算資源的變化不再與流通總金額掛鉤。我們已經達到了一個比較理想的結果：StarkPay 在單個區塊(當前 Etherum gasLimit 限制內)內能夠支持超過 10000 筆交易。
值得注意的是，STARK 適度地消耗了極為稀缺的鏈上計算資源：它所消耗的資源隨著鏈下計算規模的增加以對數方式增長。具體而言：為使 StarkPay 吞吐量提升 10 倍，鏈上計算資源消耗僅需增加不到 50%。
插播：如果將擴容的標準設置為 金額/秒 而不是 交易量/秒，那么 StarkPay 其實是沒有上限的。
資金利用率高：
就像借記卡那個比喻一樣，在 StarkPay 中，除了每個付款方希望在鏈下用于支付的資金外，不需要鎖定額外的資金。尤為重要的是，對支付處理者與證人沒有流動性要求。
無活性需求：
收款方余額更新時無需其保持在線。在所有場景中(存款、取款與支付)，交易都可以離線構造并在之后發送給區塊鏈或支付處理者。
非托管：
付款方無需將加密貨幣托管給 StarkPay。所有操作都需要付款方簽名，即便在證人作惡或者不合作的情況下，他們也可以隨時直接從支付合約(Payment contract)中取出鎖定資金(后續博客將詳細闡述有關安全退出的內容)。
在這方面，StarkPay 與 閃電網絡的效果相同，用戶仍然保留對資金的控制權。
劣勢
StarkPay 有一些明顯的缺點：
數據可用性：
為了充分利用 STARK 的鏈上對數擴展性，數據最好存儲在鏈下，但這就會帶來交易數據不可用的問題。為了去信任，并且打破可擴展性上限，數據有效性是每個基于 Plasma 的擴容方案必須解決的挑戰。
改進方案：
鏈上分批記錄交易：我們認為在這種模式下 StarkPay 能夠輕松達到每秒處理幾百筆交易。
未來鏈下數據一個可能的方向：構建數據可用性見證聯盟，聯盟對提交給鏈上驗證者合約的證明簽名就表示數據在鏈下是可用的。鏈上驗證者合約將不接受缺少此證明的證據。值得注意的是，該聯盟沒有被委托保證系統狀態的有效性 —— 他們不能盜竊資金，也不能將讓系統狀態失效。
為了支持更加去中心化的解決方案，這個聯盟之后將逐步被淘汰。
中心化：
證人(Provers)節點最初將由 StarkWare 運營。這帶來的中心化與審查的風險。
改進方案：
中心化：其他市場參與者(包括其他支付處理者)，自然會提供自己的證人節點(Provers)。從長遠來看，證人節點可以通過共識算法在網絡中競爭證據生成業務。注意，由于狀態僅通過有效證明來改變，證人節點不能通過切換到無效狀態來攻擊網絡，在這個意義上，StarkPay 的方法很像第一層(Layer-1)共識的解決方案。
審查：在 StarkPay 上，STARK 也可以用來保護隱私。具體而言，付款方可以隱藏他們的交易內容，即便是證人節點也無法獲取。由證人節點生成的計算聲明是它驗證了從付款者收到的一批獨立交易后生成的，因此他人無法從中追溯單筆交易。
延遲：
與點對點閃電通道保證的即時結算不同，目前為大批量交易生成證明所需的時間大約是幾分鐘。
改進方案：
證人節點可以在驗證收到的一批交易之后，立即向鏈上的支付合約提交承諾，并同時生成證明證據。收款人有幾分鐘的時間需要承擔證人節點會無限期扣留證據的風險。該風險可以通過持有證人節點基金來補償。值得注意的是：StarkPay 的延遲是主鏈對于證據提交交易的共識延遲，而不是閃電網絡中近乎即時的鏈下節點交易處理延遲。
同時，延遲不應該等同于吞吐量：StarkPay 能夠通過提升證人節點計算資源(全部都在鏈下的資源)的方式，來達到更高的吞吐量水平。
沒有適用于比特幣的解決方案：
以目前的形式，比特幣尚不能支持高效鏈上 STARK 驗證。
緩解措施：
如果你有解決方案的話，一定要告訴我們。在此之前，我們將集中精力適配支持高效鏈上 STARK 驗證的區塊鏈。
本文我們介紹了一種適用于加密貨幣支付場景的基于 STARK 算法的可擴展引擎(StarkPay)。我們首先分析了當前最熱門的比特幣擴容方案 —— 閃電網絡，并將其與 StarkPay 進行了比較。我們的結論是，StarkPay 提供了一種引人注目的替代方案，能夠在幾個值得注意的維度對閃電網絡進行改進。
感謝 Vitalik Buterin, Patrick McCorry, Jim Posen 與 Dan Robinson 對本文草稿提出的意見。
(作者: Tom Brand, Uri Kolodny &Avihu Levy)
