一個多月前，我們熱情地宣佈了OVM，一個區塊鏈的擴充套件通用2層（L2）解決方案，同時繼承了基礎鏈（L1）的所有安全性。這項工作雖然非常有希望，但純粹是理論上的…直到今天！我們很高興地宣佈rubber已經以概念驗證的形式在OVM上實現了狀態通道。這項工作演示了狀態通道如何在OVM上無縫執行，如果您稍微推斷一下，如何在OVM上構建所有的二級解決方案，從而以較少的開發工作實現更好的標準化、安全性和互操作性。什麼是OVM？OVM是一個通用框架，可以在廉價，輕便的L2應用程式中完全繼承緩慢而昂貴的基鏈的優勢。其區別在於它是區塊鏈不可知論。建立了使用者、錢包、開發人員等可以遵循的標準，以支援許多不同的二級應用程式，而不是每個二層方法的單獨範例。它是怎麼做到的？我們將深入探討，但與許多提議的縮放解決方案一樣，OVM僅使用L1來實現L1擅長的功能：基於一組明確定義的規則實現不變、一致的共識。我一直認同的思維模式是，L1是法官和陪審團，用它來追溯處理法律沒有得到遵守的主張要比主動監督一切以確保法律始終得到遵守要有效得多。OVM進一步採用這種方法，認識到如果所有這些不良行為的宣告都能以相同的方式表達，我們可以對所有情況使用相同的司法系統（L1爭議合同）（L2實施）。

狀態通道POC概述它是什麼？1. 具有證明OVM上可能存在完整狀態通道所需的最低功能的示例。2. 透過L2中的相互協議樂觀地演變L1狀態的程式碼，完全不用瞭解L1，以參與者可驗證和爭議的方式，從而完全繼承L1安全性。3. 在通用OVM L2客戶端上實現的眾多擴充套件思想之一。它不是什麼？

1. 僅用於狀態通道的特殊用途程式碼。2. 狀態通道的生產就緒演示，沒有錯誤和小的加密經濟漏洞。3. 實際上與L1互動的東西（我們將在這裡討論如何發生這種情況並在後面的文章中演示該部分的工作原理）。高階OVM工作流輸入L2：將資金（新增/狀態）鎖定在L1上的爭議合同中，參考[L1]裁決合同。在這種情況下，我們將引用包含邏輯的狀態通道合約，該邏輯定義什麼構成有效的可退出狀態。狀態通道合約以及可能所有的OVM裁決合同，將依賴於爭議合同來進行標準的退出請求和退出爭議處理。使用L2：在L2中高效互動，完全繼承L1安全性。

按照L1狀態通道合同中規定的規則，在沒有實際互動的情況下，交換L2中雙方約定狀態的光速更新。退出L2：在挑戰期間沒有有效挑戰的有效索賠退出。對於狀態通道，此宣告將為退出狀態有效，如一級狀態通道合約所定義。在使用L2狀態通道時，雙方必須收集能夠對無效退出宣告進行爭議的證據。深入瞭解狀態通道L2L1裁決合同如果我們要使用L1作為法官和陪審團，我們需要定義一套清晰的法律，它將用於對索賠作出裁決。這將至少包括定義有效的可存在狀態。對於狀態通道，可以用英語將有效的可存在狀態定義為“通道的最新相互簽署狀態”。為了使該宣告可由通用法官評估，甲方退出狀態通道C並更新其L1狀態以匹配L2狀態的有效退出宣告包含兩個斷言：

1. 所有通道參與者已簽署通道C的狀態為S的訊息M。2. 對於通道C，不存在訊息m'，因此m'的nonce比m高，m'由所有通道參與者簽名。如果提出此類索賠，可能會導致兩種可能的情況：1. 該索賠透過爭議期的重疊進行驗證，沒有有效的質疑。2. 如果發生以下任何一種情況，索賠在爭議期間無效：    a）L1合同評估訊息M，並確定它不是由通道C的所有參與者簽署的。

    b）一級合同從任何一方收到一條“M”資訊，該資訊否定了該資訊不存在的主張。評估此類索賠的邏輯必須存在於L1合同中。雖然這篇文章不會證明這一點，但希望讀者充分相信可以構建智慧合約以將地址與通道ID相關聯，確定特定地址是否已簽署特定訊息，比較不同訊息的非屬性，採取後續行動指定的時間延遲等。L2互動Alice和Bob已將資金存入L1合同，成功啟動了狀態通道。怎麼辦？OVM完全取決於它們。資訊如果Alice和Bob想要改變其在L2的初始存款狀態，他們需要簽署和交換符合L1合同可驗證格式的訊息，並確保不會違反L1合同中規定的任何規則。假設這是訊息格式（如我們在此處和此處的repo中所述）：

{  "channelId": "1234567890", // L1 ID  "nonce": 1,                // The first message  "data": {    "addressBalance": {      "0x0a": 100,           // Alice's initial balance

      "0x0b": 100            // Bob's initial balance    }  }}如果交換的訊息不遵循這種格式，那麼L1合同將無法解釋它們，它們將毫無用處。傳送，簽名和重新簽名

假設Alice正在從她的餘額中支付Bob 5以獲得一些好處或服務。她可以透過簡單地簽署並向他傳送以下訊息（我們的回購中的邏輯）來做到這一點：{  "channelId": "1234567890",  "nonce": 2,      // Most recent message  "data": {    "addressBalance": {

      "0x0a": 95,  // Alice -5      "0x0b": 105  // Bob +5    }  }}如果Bob接受該訊息有效，他將簽署此訊息並將其傳送回Alice（讓我們忽略他現在沒有簽署有效訊息的情況，因為這是狀態通道中已解決的問題）。

如果訊息無效，Bob將不會對其進行簽名，並且前一個狀態將繼續為有效狀態。他們可以透過以這種方式簽名和交換訊息來繼續發展狀態，從而增加每條新訊息的隨機數。訊息儲存正如OVM不規定如何交換訊息一樣，它也不規定Alice和Bob需要儲存什麼，但他們知道L1合同處理出口需要什麼資訊，以及他們需要提供什麼來質疑出現的任何無效出口。因此，他們需要儲存最近的會籤簽名訊息以及任何一方已簽署和傳送的任何待處理（意思不是會籤）訊息。如果Alice或Bob想要退出，他們將向L1合同提交最近的會籤簽名訊息作為他們想要退出的狀態。如果任何一方試圖退出先前狀態的訊息，則另一方將提交最新的會籤訊息作為另一訊息無效的證據。狀態通道訊息的示例資料儲存在我們的repo中（請注意，它擴充套件了我們的基本MessageDB中的功能）。

退出和挑戰退出每個退出和退出挑戰不僅需要L1裁決合同需要對其進行評估的資料，而且還需要以一般L1爭議合同可以理解的方式呈現。這就是我們真正瞭解OVM如何工作的地方。假設Alice想在上面的訊息之後退出狀態通道和nonce 2。這是她將傳送給L1裁決合約的狀態通道出口索賠的結構。它現在沒有什麼意義，但當我們透過下面的過程時，它會變得更加清晰：{  "decider": AndDecider,

  "input": {    "left": {      "decider": SignedByDecider,      "input": {        "publicKey": "0x0b", // Bob's Address        "message": { // Most recent message

          "channelId": "1234567890",          "nonce": 2,          "data": {            "addressBalance": {              "0x0a": 95,              "0x0b": 105

            }          }        }      }    },    "leftWitness": {

      "signature": "0xbbbbbbbbbbbbbbb" // Bob's msg signature    },    "right": {      "decider": ForAllSuchThatDecider,      "input": {        "quantifier": SignedByQuantifier,

        "quantifierParameters": {          "publicKey": "0x0a", // Alice's address          "channelID": "1234567890" // Our Channel        }        "propertyFactory": (message) => {          return {

            "decider": MessageNonceLessThanDecider,            "input": {              "messageWithNonce": deserializeBuffer(                signedMessage,                deserializeMessage,                stateChannelMessageDeserializer

              ),              "lessThanThis": 3,            },          }        }      }

    },    "rightWitness": undefined  }}首先，讓我們回到上面的狀態通道退出宣告定義：1、所有通道參與者已簽署通道C的狀態為S的訊息M。

2、對於通道C，不存在訊息m'，因此m'的nonce比m高，m'由所有通道參與者簽名。如果我們暫時忽略這種時髦的格式，我們可以看到Alice的宣告型別遵循這種宣告結構。第一部分列出了一個名為SignedByedAcider的東西，雖然我們還不知道這意味著什麼，但我們看到它是由Bob的地址、我們最近的訊息和Bob對我們最近訊息的簽名列出的。我們可以看到，這有所有必要的資訊來證明Bob簽署了最新的狀態。第二部分更加激烈，但是我們看到一個我們不完全理解的ForAllSuchThatDecide，一個帶有Alice的地址和我們的Channel ID引數的SignedByQuantifie，以及一個MessageNonceLessThanDecider，右邊是LessThanThis：3。如果我們只是按順序讀取部分內容，我們請參閱ForAll ... SignedBy ... Alice的地址和我們的頻道ID，MessageNonceLessThan ... 3。這是一個延伸，但也許這聲稱Alice已為此頻道簽名的所有訊息的nonce小於3？最後，這兩個部分巢狀在AndDeciderblock中。它有一個左側部分和一個右側部分，所以它可能意味著左右兩邊？OVM中的VM表示虛擬機器

OVM是一個虛擬機器，虛擬機器需要執行有用的指令。為此，OVM必須為指令定義基本介面。由於OVM完全基於這些宣告的宣告和爭議，因此其指令必須遵循“根據規則集S確定輸入N是否有效”的形式。為此，OVM具有Property的概念。屬性由一個Decider組成，它直接對映到一個簡單的L1智慧合約，能夠做出非常具體的true/false決策，並輸入到要評估的決策者。例如，AndDecider決定是否為true，並且僅當其input.leftproperty求值為true且其input.rightproperty求值為true時。決策者也可能需要證人，這是與輸入相關的證明。例如，SignedByDecider決定訊息是否已由公鑰簽名。它的輸入（message和publicKey）定義了正在決定的內容，其見證（簽名）是用於做出決定的證明。最後一部分是Quantifiers（其他簡單的L1智慧合約）。在給定一組特定約束的情況下，Quantifiers能夠列出所有適用的資訊。例如，SignedByQuantifier能夠列出由給定公鑰簽名的所有訊息。在上面，您可以看到ForAllSuchThatDecider使用SignedByQuantifie來獲取Alice為相關頻道簽名的所有訊息。ForAllSuchThatDecideralso接受它呼叫的屬性工廠函式，傳遞其量詞的每個結果，以獲得它將評估的所有屬性*。正如您可能想象的那樣，ForAllSuchThatDecider會判斷它正在評估的所有屬性是否為true。把它們組在一起

Alice的退出宣告演示瞭如何將這些粒度屬性巢狀在一起以表示複雜語句。我們還可以看到，就像其他虛擬機器一樣，組裝一小組細粒度指令（決策者）的不同排列，我們應該能夠代表每一個可能的宣告。*注意：PropertyFactoryfunctions適用於此示例，但它們最終不會用於傳遞給L1合同的宣告中，因為它們不能一般地表示。這不是一個阻塞，因為它很容易透過簡單地傳遞一個Decider和一個變換器將Quantifierresults轉換為ForAllSuchThatDeciderto來列舉屬性本身來解決，但我們正在尋找最好的方法。現在我們知道OVM如何啟用狀態通道。我不會討論OVM如何支援其他擴充套件解決方案，將其作為練習向讀者介紹如何為這些其他實現構建L1裁決合同和退出宣告。然而，我要談到的一件事是這種方法如何提供其他有價值的好處，例如安全性，相容性和鏈不可知性。在標準化實際擁有所有L2資金的L1爭議合同時，OVM將透過提供類似於ERC-20標準的可重複使用，可擴充套件，經過實戰檢驗的合同來提供出色的安全性。這種標準化以及OVM操作的通用性將提供作為副產品的其他不同擴充套件解決方案之間的相容性，從而允許更好的錢包整合和UX。最後，儘管我們將目標定位於以太坊進行初始實施，但由於某種原因，我沒有提到具體的L1鏈--OVM應該適用於任何支援智慧合約的L1。更進一步，使用OVM，可以在不相容的L1鏈上實現相同的擴充套件解決方案，並共享幾乎所有L2程式碼。