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