電子發(fā)燒友App
一個多月前，我們熱情地宣布了OVM，一個區(qū)塊鏈的擴展通用2層（L2）解決方案，同時繼承了基礎鏈（L1）的所有安全性。這項工作雖然非常有希望，但純粹是理論上的…直到今天！
我們很高興地宣布rubber已經(jīng)以概念驗證的形式在OVM上實現(xiàn)了狀態(tài)通道。這項工作演示了狀態(tài)通道如何在OVM上無縫運行，如果您稍微推斷一下，如何在OVM上構建所有的二級解決方案，從而以較少的開發(fā)工作實現(xiàn)更好的標準化、安全性和互操作性。
什么是OVM？
OVM是一個通用框架，可以在廉價，輕便的L2應用程序中完全繼承緩慢而昂貴的基鏈的優(yōu)勢。其區(qū)別在于它是區(qū)塊鏈不可知論。創(chuàng)建了用戶、錢包、開發(fā)人員等可以遵循的標準，以支持許多不同的二級應用程序，而不是每個二層方法的單獨范例。
它是怎么做到的？我們將深入探討，但與許多提議的縮放解決方案一樣，OVM僅使用L1來實現(xiàn)L1擅長的功能：基于一組明確定義的規(guī)則實現(xiàn)不變、一致的共識。我一直認同的思維模式是，L1是法官和陪審團，用它來追溯處理法律沒有得到遵守的主張要比主動監(jiān)督一切以確保法律始終得到遵守要有效得多。
OVM進一步采用這種方法，認識到如果所有這些不良行為的聲明都能以相同的方式表達，我們可以對所有情況使用相同的司法系統(tǒng)（L1爭議合同）（L2實施）。
狀態(tài)通道POC概述
它是什么？
1. 具有證明OVM上可能存在完整狀態(tài)通道所需的最低功能的示例。
2. 通過L2中的相互協(xié)議樂觀地演變L1狀態(tài)的代碼，完全不用了解L1，以參與者可驗證和爭議的方式，從而完全繼承L1安全性。
3. 在通用OVM L2客戶端上實現(xiàn)的眾多擴展思想之一。
它不是什么？
1. 僅用于狀態(tài)通道的特殊用途代碼。
2. 狀態(tài)通道的生產(chǎn)就緒演示，沒有錯誤和小的加密經(jīng)濟漏洞。
3. 實際上與L1交互的東西（我們將在這里討論如何發(fā)生這種情況并在后面的文章中演示該部分的工作原理）。
高級OVM工作流
輸入L2：將資金（添加/狀態(tài)）鎖定在L1上的爭議合同中，參考［L1］裁決合同。在這種情況下，我們將引用包含邏輯的狀態(tài)通道合約，該邏輯定義什么構成有效的可退出狀態(tài)。狀態(tài)通道合約以及可能所有的OVM裁決合同，將依賴于爭議合同來進行標準的退出請求和退出爭議處理。
使用L2：在L2中高效交互，完全繼承L1安全性。
按照L1狀態(tài)通道合同中規(guī)定的規(guī)則，在沒有實際交互的情況下，交換L2中雙方約定狀態(tài)的光速更新。
退出L2：在挑戰(zhàn)期間沒有有效挑戰(zhàn)的有效索賠退出。對于狀態(tài)通道，此聲明將為退出狀態(tài)有效，如一級狀態(tài)通道合約所定義。在使用L2狀態(tài)通道時，雙方必須收集能夠?qū)o效退出聲明進行爭議的證據(jù)。
深入了解狀態(tài)通道L2
L1裁決合同
如果我們要使用L1作為法官和陪審團，我們需要定義一套清晰的法律，它將用于對索賠作出裁決。這將至少包括定義有效的可存在狀態(tài)。對于狀態(tài)通道，可以用英語將有效的可存在狀態(tài)定義為“通道的最新相互簽署狀態(tài)”。
為了使該聲明可由通用法官評估，甲方退出狀態(tài)通道C并更新其L1狀態(tài)以匹配L2狀態(tài)的有效退出聲明包含兩個斷言：
1. 所有信道參與者已簽署信道C的狀態(tài)為S的消息M。
2. 對于通道C，不存在消息m‘，因此m’的nonce比m高，m‘由所有通道參與者簽名。
如果提出此類索賠，可能會導致兩種可能的情況：
1. 該索賠通過爭議期的重疊進行驗證，沒有有效的質(zhì)疑。
2. 如果發(fā)生以下任何一種情況，索賠在爭議期間無效：
a）L1合同評估消息M，并確定它不是由通道C的所有參與者簽署的。
b）一級合同從任何一方收到一條“M”信息，該信息否定了該信息不存在的主張。
評估此類索賠的邏輯必須存在于L1合同中。雖然這篇文章不會證明這一點，但希望讀者充分相信可以構建智能合約以將地址與通道ID相關聯(lián)，確定特定地址是否已簽署特定消息，比較不同消息的非屬性，采取后續(xù)行動指定的時間延遲等。
L2交互
Alice和Bob已將資金存入L1合同，成功啟動了狀態(tài)通道。怎么辦？OVM完全取決于它們。
信息
如果Alice和Bob想要改變其在L2的初始存款狀態(tài)，他們需要簽署和交換符合L1合同可驗證格式的消息，并確保不會違反L1合同中規(guī)定的任何規(guī)則。假設這是消息格式（如我們在此處和此處的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合同將無法解釋它們，它們將毫無用處。
發(fā)送，簽名和重新簽名
假設Alice正在從她的余額中支付Bob 5以獲得一些好處或服務。她可以通過簡單地簽署并向他發(fā)送以下消息（我們的回購中的邏輯）來做到這一點：
{
“channelId”： “1234567890”，
“nonce”： 2， // Most recent message
“data”： {
“addressBalance”： {
“0x0a”： 95， // Alice -5
“0x0b”： 105 // Bob +5
}
}
}
如果Bob接受該消息有效，他將簽署此消息并將其發(fā)送回Alice（讓我們忽略他現(xiàn)在沒有簽署有效消息的情況，因為這是狀態(tài)通道中已解決的問題）。
如果消息無效，Bob將不會對其進行簽名，并且前一個狀態(tài)將繼續(xù)為有效狀態(tài)。
他們可以通過以這種方式簽名和交換消息來繼續(xù)發(fā)展狀態(tài)，從而增加每條新消息的隨機數(shù)。
消息存儲
正如OVM不規(guī)定如何交換消息一樣，它也不規(guī)定Alice和Bob需要存儲什么，但他們知道L1合同處理出口需要什么信息，以及他們需要提供什么來質(zhì)疑出現(xiàn)的任何無效出口。因此，他們需要存儲最近的會簽簽名消息以及任何一方已簽署和發(fā)送的任何待處理（意思不是會簽）消息。
如果Alice或Bob想要退出，他們將向L1合同提交最近的會簽簽名消息作為他們想要退出的狀態(tài)。如果任何一方試圖退出先前狀態(tài)的消息，則另一方將提交最新的會簽消息作為另一消息無效的證據(jù)。
狀態(tài)通道消息的示例數(shù)據(jù)存儲在我們的repo中（請注意，它擴展了我們的基本MessageDB中的功能）。
退出和挑戰(zhàn)退出
每個退出和退出挑戰(zhàn)不僅需要L1裁決合同需要對其進行評估的數(shù)據(jù)，而且還需要以一般L1爭議合同可以理解的方式呈現(xiàn)。
這就是我們真正了解OVM如何工作的地方。
假設Alice想在上面的消息之后退出狀態(tài)通道和nonce 2。這是她將發(fā)送給L1裁決合約的狀態(tài)通道出口索賠的結(jié)構。它現(xiàn)在沒有什么意義，但當我們通過下面的過程時，它會變得更加清晰：
{
“decider”： AndDecider，
“input”： {
“l(fā)eft”： {
“decider”： SignedByDecider，
“input”： {
“publicKey”： “0x0b”， // Bob’s Address
“message”： { // Most recent message
“channelId”： “1234567890”，
“nonce”： 2，
“data”： {
“addressBalance”： {
“0x0a”： 95，
“0x0b”： 105
}
}
}
}
}，
“l(fā)eftWitness”： {
“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
），
“l(fā)essThanThis”： 3，
}，
}
}
}
}，
“rightWitness”： undefined
}
}
首先，讓我們回到上面的狀態(tài)通道退出聲明定義：
1、所有信道參與者已簽署信道C的狀態(tài)為S的消息M。
2、對于通道C，不存在消息m‘，因此m’的nonce比m高，m‘由所有通道參與者簽名。
如果我們暫時忽略這種時髦的格式，我們可以看到Alice的聲明類型遵循這種聲明結(jié)構。
第一部分列出了一個名為SignedByedAcider的東西，雖然我們還不知道這意味著什么，但我們看到它是由Bob的地址、我們最近的消息和Bob對我們最近消息的簽名列出的。我們可以看到，這有所有必要的信息來證明Bob簽署了最新的狀態(tài)。
第二部分更加激烈，但是我們看到一個我們不完全理解的ForAllSuchThatDecide，一個帶有Alice的地址和我們的Channel ID參數(shù)的SignedByQuantifie，以及一個MessageNonceLessThanDecider，右邊是LessThanThis：3。如果我們只是按順序讀取部分內(nèi)容，我們請參閱ForAll 。.. SignedBy 。.. Alice的地址和我們的頻道ID，MessageNonceLessThan 。.. 3。這是一個延伸，但也許這聲稱Alice已為此頻道簽名的所有消息的nonce小于3？
最后，這兩個部分嵌套在AndDeciderblock中。它有一個左側(cè)部分和一個右側(cè)部分，所以它可能意味著左右兩邊？
OVM中的VM表示虛擬機
OVM是一個虛擬機，虛擬機需要執(zhí)行有用的指令。為此，OVM必須為指令定義基本接口。由于OVM完全基于這些聲明的聲明和爭議，因此其指令必須遵循“根據(jù)規(guī)則集S確定輸入N是否有效”的形式。
為此，OVM具有Property的概念。屬性由一個Decider組成，它直接映射到一個簡單的L1智能合約，能夠做出非常具體的true/false決策，并輸入到要評估的決策者。例如，AndDecider決定是否為true，并且僅當其input.leftproperty求值為true且其input.rightproperty求值為true時。
決策者也可能需要證人，這是與輸入相關的證明。例如，SignedByDecider決定消息是否已由公鑰簽名。它的輸入（message和publicKey）定義了正在決定的內(nèi)容，其見證（簽名）是用于做出決定的證明。
最后一部分是Quantifiers（其他簡單的L1智能合約）。在給定一組特定約束的情況下，Quantifiers能夠列出所有適用的信息。例如，SignedByQuantifier能夠列出由給定公鑰簽名的所有消息。
在上面，您可以看到ForAllSuchThatDecider使用SignedByQuantifie來獲取Alice為相關頻道簽名的所有消息。ForAllSuchThatDecideralso接受它調(diào)用的屬性工廠函數(shù)，傳遞其量詞的每個結(jié)果，以獲得它將評估的所有屬性*。正如您可能想象的那樣，F(xiàn)orAllSuchThatDecider會判斷它正在評估的所有屬性是否為true。
把它們組在一起
Alice的退出聲明演示了如何將這些粒度屬性嵌套在一起以表示復雜語句。我們還可以看到，就像其他虛擬機一樣，組裝一小組細粒度指令（決策者）的不同排列，我們應該能夠代表每一個可能的聲明。
*注意：PropertyFactoryfunctions適用于此示例，但它們最終不會用于傳遞給L1合同的聲明中，因為它們不能一般地表示。這不是一個阻塞，因為它很容易通過簡單地傳遞一個Decider和一個變換器將Quantifierresults轉(zhuǎn)換為ForAllSuchThatDeciderto來枚舉屬性本身來解決，但我們正在尋找最好的方法。
現(xiàn)在我們知道OVM如何啟用狀態(tài)通道。我不會討論OVM如何支持其他擴展解決方案，將其作為練習向讀者介紹如何為這些其他實現(xiàn)構建L1裁決合同和退出聲明。然而，我要談到的一件事是這種方法如何提供其他有價值的好處，例如安全性，兼容性和鏈不可知性。在標準化實際擁有所有L2資金的L1爭議合同時，OVM將通過提供類似于ERC-20標準的可重復使用，可擴展，經(jīng)過實戰(zhàn)檢驗的合同來提供出色的安全性。這種標準化以及OVM操作的通用性將提供作為副產(chǎn)品的其他不同擴展解決方案之間的兼容性，從而允許更好的錢包集成和UX。最后，盡管我們將目標定位于以太坊進行初始實施，但由于某種原因，我沒有提到具體的L1鏈--OVM應該適用于任何支持智能合約的L1。更進一步，使用OVM，可以在不兼容的L1鏈上實現(xiàn)相同的擴展解決方案，并共享幾乎所有L2代碼。
工商網(wǎng)監(jiān)
評論