電子發燒友App
一個多月前，我們熱情地宣布了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狀態通道時，雙方必須收集能夠對無效退出聲明進行爭議的證據。
深入了解狀態通道L2
L1裁決合同
如果我們要使用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代碼。
工商網監
評論