By Bitcoin 雜誌 - 4 個月前 - 閱讀時間：5 分鐘
Mercury Layer：狀態鏈的巨大改進
CommerceBlock is releasing Mercury Layer today, an improved version of their variation of a statechain. You can read a longer form explanation of how their Mercury statechains work 請點擊這裡. The upgrade to Mercury Layer represents a massive improvement against the initial statechain implementation, however unlike the initial Mercury Wallet release, this is not packaged as a fully consumer ready wallet. It is being released as a library and CLI tool other wallets can integrate. Here’s a quick summary of how they work:
狀態鏈在許多方面本質上類似於支付管道，即它們是一種協作共享的 UTXO，具有預先簽署的交易，作為人們強制執行其所有權的最後手段。閃電通道和狀態鏈之間的主要區別在於參與協作共享 UTXO 的各方，以及如何將針對其的可執行索賠的所有權轉移給其他方。
與在兩個靜態參與者之間創建和共享的閃電通道不同，狀態鍊是由服務商/操作員打開的，並且可以在任何兩個願意信任操作員是誠實的、完全獨立的參與者之間自由地整體轉移。- 鏈。希望載入狀態鏈的人與運營商合作創建一個公鑰，創建者和運營商都持有相應私鑰的份額，但都沒有密鑰的完整副本。他們從這裡預先簽署一項交易，允許創建者在時間鎖定後單方面收回他們的代幣。
為了轉移狀態鏈，當前所有者與接收者和操作者合作，使用他們正在轉移代幣的密鑰共享來簽署加密證明，然後接收者和操作者產生一對新的密鑰共享，它們加起來等於相同的私鑰並簽署為新所有者提供的時間鎖定交易，其時間鎖定比原始所有者更短（以確保他們可以比以前的所有者更快地使用他們的交易）。每次傳輸都會重複此過程，直到時間鎖無法再縮短，此時狀態鏈必須在鏈上關閉。
Owners transfer the entire historical chain of past states with each transfer so that users can verify timelocks have been properly decremented and the operator timestamps them using 支柱, a variant of Opentimestamps where each piece of data has its own unique “slot” in the merkle tree to guarantee that only a single version of the data is timestamped. This let’s everyone audit the transfer history of a statechain.
在盲人之地
Mercury Layer 為原始版本的狀態鏈帶來的巨大變化是令人眼花繚亂的。狀態鏈服務的運營商將不再能夠了解有關正在傳輸的內容的任何資訊：即涉及的 TXID、涉及的公鑰，甚至是它與用戶合作為收回所需的預簽名交易創建的簽名您的資金單方面。
Mercury 引入了 Schnorr MuSig2 的盲態變體，可以促進撤銷交易簽名的過程，而無需了解他們正在簽名的任何細節。這需要進行一些設計更改，以考慮到操作員無法再查看和發布狀態鏈的全部傳輸歷史記錄的事實。他們甚至根本無法驗證他們正在簽署的交易。
在先前的迭代中，當前狀態鏈所有者/交易集的唯一性由運營商透過與 Mainstay 發布狀態鏈的整個傳輸歷史記錄來證明。這裡是不可能的，因為在盲版本中，操作員根本不知道有關這些交易的任何細節。這需要營運商採用一種新的方式來證明狀態鏈的當前所有權。所有這些數據都完全推送到客戶端驗證模型。操作員只需追蹤它為單一狀態鏈簽署的次數，並在用戶請求時告訴用戶該數字。然後，用戶從發送給他們的用戶接收過去狀態鏈狀態的交易，並完全驗證客戶端的交易數量是否與操作員聲稱的相符，然後完全驗證簽名是否全部有效，並且時間鎖減少適當的數量每一次。因為它被設計為不知道所有這些信息，所以它不是向 Mainstay 發布完整的狀態鏈交易和轉移訂單，而是為每個狀態鏈的當前用戶發布其公鑰份額（而不是完整的聚合公鑰）用戶。這允許接收狀態鏈的任何用戶根據發送者發送的交易資料來驗證傳輸歷史記錄和當前狀態是否合法。
運營商伺服器透過在創建時為每個狀態鏈分配一個隨機標識符來追蹤唯一的狀態鏈，以計算過去的簽名，並與其面額及其私鑰和公鑰共享（而不是整個聚合公鑰）一起儲存。用於分片和重新分片密鑰的新協調方案是透過以下方式完成的：伺服器將其密鑰份額傳遞給用戶，並且重新分片所需的資料是盲目的，因此伺服器無法了解用戶的完整金鑰。公鑰共享，允許它創建完整的聚合公鑰並識別鏈上的代幣。
該設計甚至不允許運營商知道何時與當前所有者簽署了合作閉包，而不是為新的鏈下所有者簽署了預簽名交易；它沒有看到任何細節來區分這兩種情況。然而，這對用戶來說是安全的，他們可能會受到試圖「雙花」鏈下狀態鏈並提供無法結算的虛假交易的人的攻擊。首先，該用戶將在鏈上看到支援該狀態鏈的 UTXO 已被花費。其次，交易歷史記錄，因為操作者必須簽署所有狀態更新，所以在過去的交易鏈中只會有一個明確的合作閉包。這兩件事都允許用戶在知道交易不合法的情況下拒絕交易。
Statechains also allow Lightning channels to be “put on top” of the statechain by having the statechain pay out to a multisig address between two people, and the two of them negotiating a conventional set of Lightning commitment transactions on top of it. It would need to close the statechain on-chain before closing the Lightning channel so would need to use longer timelock lengths for Lightning payments, but otherwise would function perfectly normally.
Overall with the massive privacy improvements of the new iteration of statechains, and the composability with Lightning, this opens many doors for the economic viability and flexibility of second layer transactional mechanisms on Bitcoin. Especially in light of the recent radical changes in mempool dynamics and the resulting fee pressure.
它提供了與 Ark 相同類型的流動性優勢，即能夠自由轉讓而無需接收流動性，但與 Ark 不同的是，Ark 目前已上線並正常運作。不可否認，它是一種與單獨的閃電網路不同的信任模型，但對於靈活性和可擴展性方面的巨大收益，它絕對是值得探索的可能性。
原始來源： Bitcoin 雜誌