長話短說：StarkPay 是一種基於 STARK 技術的可擴充套件支付引擎，它可以解決第二層（Layer-2）支付解決方案閃電網路（Lightning）的許多缺點。
StarkWare 的第一個 STARK 技術應用是一個 Layer-2 可擴充套件引擎。我們最近釋出了 StarkDEX，一個去中心化交易所（DEX）可擴充套件引擎（早期成果請檢視該連結）。
我們將該可擴充套件引擎應用於加密貨幣支付場景，構建了 StarkPay。穩定幣的出現滿足了密碼學貨幣作為交換媒介的必要條件。然而，該生態系統依舊缺少一個可擴充套件支付系統。我們相信 StarkPay 能夠滿足這一需要。
本文將對比分析 StarkPay 與閃電網路（最著名的比特幣支付可擴充套件性解決方案）。我們將首先回顧閃電網路的優缺點。然後，闡述 StarkPay 基礎架構，並舉例說明其執行流程。最後，分析 StarkPay 的優缺點，以及缺點的改進方案。
本文將不探討兩種方案隱私保護方面的內容。
閃電網路
自 Poon 與 Dryja 2016 年釋出白皮書以來，閃電網路引起了公眾的廣泛關注。閃電網路目前擁有超過 3000 個節點，全網鎖定資產價值超過 200 萬美元。閃電火炬接力賽（Lightning Torch）的金額也已超過 100 美元，高科技巨頭 Jack Dorsey 與 Reid Hoffman、金融巨頭 Fidelity 等也都參與其中。
Lightning 是為了擴充套件比特幣網路而提出的。作為最早一批出現的 Layer-2 解決方案之一，它天才地提議將交易轉移到鏈下處理，而不改變區塊鏈的安全模型。它希望不僅能夠提升交易規模，還能夠保證低延遲與最低交易費。
閃電網路也有幾個缺點：
活性需求：付款方必須線上才能完成付款——這一點沒什麼奇怪的。但是，與比特幣不同，在閃電網路中，收款方也必須線上，以便使用雙方的私鑰對鏈下交易簽名（稍後將詳細闡述操作的安全考慮）。更糟糕的是，從交易雙方建立鏈下通道開始，收款人就必須一直監測區塊鏈狀態，以確保付款人不會將他們餘額的舊狀態提交上鍊並關閉通道。路由節點也必須在上下游通道超時之前線上，以便在上游 HTLC（雜湊時間鎖）超時之前參與協議、履行職責（即路由支付請求）。
閃電網路試圖引入瞭望塔節點來解決使用者需要持續監測區塊鏈的問題。瞭望塔節點透過向使用者收取費用來提供區塊鏈網路狀態監測服務。
資金利用率低：一般來說，為了方便使用，付款方願意鎖定一些資產（例如：使用借記卡）。但是在閃電網路中，每個使用者需要在每個通道都鎖定一筆資金，從而將一個使用者的資金打散。
更糟糕的是，如果鏈下交易不是直接從付款方傳送給收款方（例如：轉移金額為 X），而是透過其他路由節點轉發，那麼所涉及的路由節點也需要鎖定數量至少為 X 的資金。
在理想情況下（從資金利用率的角度考慮），單一中心節點的星型網路流動性上限為中心節點願意鎖定的資金量。付款方的鎖定資金對於網路流動性毫無貢獻。換句話說，需要路由節點來給網路帶來流動性，這是一個令人有點驚訝又不合需要的特性。
要是我們再想避免形成這樣的中心化網路，又會遇到什麼樣的問題呢？降低網路中心化水平需要增強路由路徑選擇的多樣性。但是在一筆轉賬中，參與路由的節點越多，交易資金成本就會越高（這是因為用於路由的資金需要在一段時期內鎖定，在鎖定期間並不能產生利息）。具體而言，如果 Alice 想透過 5 個路由節點向 Bob 傳送 1 個比特幣，那麼總共就需要在閃電網路中鎖定 5 個比特幣。這種成本（以及路由節點不配合時的惡意攻擊成本）必須轉化為交易方所承擔的費用。現在閃電網路中並向付款方未收取這部分費用，而是基於網路早期使用者的利他行為來維持網路正常運轉。
閃電網路生態系統的中心化趨勢能夠緩解資金利用率低下的問題。閃電網路中心化程度顯然是一個有趣的話題。
運營安全挑戰：中心化交易所最具爭議的點是，它們創造了一種蜜罐，會引來攻擊者的攻擊。但是，隨著網路的擴大，閃電網路路由節點會建立更多臨時蜜罐。設想一下熱錢包中有一個私鑰需要暴露的情況：中心化交易所只需要在它們選擇的時間段內短暫暴露私鑰。但在閃電網路中，路由節點為了提供幾乎實時的服務，必須一直暴露私鑰。與此同時，為了提供穩定的路由服務，它們需要保證每個通道都有足夠的資金。這就構成了一個理想的蜜罐：充足的資金與在熱錢包中暴露的私鑰。為了彌補保護這個蜜罐所需投入的資本，路由節點很可能將這部分投入增加到交易費當中。
交易完成率隨支付金額增加而降低：考慮到多跳支付中的每個通道都需要鎖定超過支付金額的資金，這些支付在網路中可選擇的路由更少，因此更高金額的交易支付完成可能性更低。由於通道路由限制了容量大小，支付金額增加可能導致交易費用也會水漲船高。理想情況下，使用者當然希望交易完成率獨立於交易金額。
交易完成率隨方向性增強而降低：與增加支付金額的負面影響類似，當許多付款方同時向一個收款方支付費用時（例如：真實世界中消費者向商家付款），他們會爭奪有限的（指向收款方的）路由節點資金容量。請注意，閃電火炬接力賽並沒有證明閃電網路能應付這種場景。
總的來說，閃電網路總資源消耗似乎不僅僅與參與者的數量或支付金額相關，還與支付筆數成比例。這對於支付擴容方案來說顯然是一種硬傷。
[插播：為了簡單起見，我們假設閃電網路中路由問題已經被完美解決，並且免費提供服務。當然，有些人認為這是一個難題]
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 對本文草稿提出的意見。
