Counterfactual是一個典型的狀態通道（state channel），由counterfactual實例化對象構成。
在L4中，我們已經研究了狀態通道和其它的一些區塊鏈擴展性方案。今天我們很高興能夠和大家分享我們工作中的一個基礎部分，關于廣義狀態通道counterfactual的研究。
狀態通道是可用分布式應用程序的基層技術，可用于一組特定的成員之間的任何互動，例如支付活動或者象棋和撲克之類的小游戲。將這些應用“通道化”可以大大降低其使用成本，而且可以減少目前使用區塊鏈應用的等待時間，達到用戶們期待的web服務響應時間。（每次用戶想要進行鏈上操作的時候，他們都必須支付gas費用，而且他們必須等幾個塊開采后才能采取下一步行動。）
盡管如此，狀態通道在今天的以太坊應用中并沒有得到充分的利用。每一個想要使用狀態通道的項目都必須要搭建自己的自定義實現框架，從而導致冗余和不必要的風險出現。其次，現存的狀態通道實現還是會將很多操作放在鏈上，而且需要以不必要的方式放棄一些隱私性。
（狀態通道，Plasma 和 Truebit 等“鏈下”技術也被稱為第二層解決方案）
我們期待未來這項技術能夠被更好的利用，我們曾經描述過關于狀態通道的兩大目標：
1. 設計一個可以保護隱私的廣義狀態通道，使用模塊化組件搭建，支持單個通道內的多個并行操作，而且允許用戶在不進行任何鏈上操作的情況下升級通道設計。
2. 提供一個框架和標準化組件，構建安全、性能良好的應用，讓開發者能夠更簡單地使用狀態通道。
我們的論文描述了一個狀態通道設計方案，在保證安全的情況下盡可能的減少鏈上操作。我們相信它會成為構建安全、優化的狀態通道的一個標準參考設計，這也是以太坊社區長久以來一直需要的。
我們將會參加柏林的Off the Chain活動，更深層次的討論我們的技術技巧。我們不會進行ICO或者任何與token相關的募資活動。
在這篇文章中，我們總結了論文中描述的方法。如果你只對狀態通道如何工作的概念描述感興趣，請查看the state channels section of Josh Stark’s Layer 2 scaling article。閱讀本文的需要讀者掌握一些基礎的技術知識。
狀態通道術語
狀態通道背后的基礎技術好幾年前已經為人所知。這期間，我們發現了新的詞匯能夠讓我們抽象出現在所有狀態通道中的特定的實現并討論組件與技術。
狀態通道通過將區塊鏈狀態的某些部分“鎖入”多重簽名合約來進行工作，該合約由一組固定的參與者控制。這種被“鎖定”的狀態被稱為狀態存入（state deposite）。舉個例子，存入可能是一定數量的以太幣或者是一個ERC20 token，但是也可以是一只加密貓或者一個ENS域名。
在狀態存入被鎖定后，通道參與者使用鏈下信息傳遞來進行交換和簽署有效的以太坊交易，而不用將它們部署在鏈上。這些交易可以隨時被放回到鏈上，但是它們并不在鏈上發生。
通道狀態的更新需要獲得一致同意（unanimous consent），所有的成員都要在每一筆鏈下交易上簽字（并保留一份副本）。由于這些“狀態更新”完全在鏈下發生，交易者無需支付任何交易費用，而且它們的速度僅受限于底層通信協議。
因此可以說狀態通道能夠提供“即時”交易，例如：參與者不需要等待任何來自區塊鏈的確認。無需等待一系列鏈上確認，應用可以立即將操作認定為終止并且展示給用戶。這就是狀態通道可以提供web服務響應時間的原理。
我們將這種特質稱為即時終結性（instant finality）。在共識研究中，“終止（fanality）”的意思是到達狀態轉換不會被還原的程度。在狀態通道的例子中（Alice和Bob是密碼學中經常會引用的一對學術情侶，關于解釋狀態通道的例子是這樣的：想象一下，Alice 和Bob 想玩一個井字游戲，贏家可以獲得1eth。摒棄在以太坊鏈上創建一個智能合約，每次操作支付gas費用而且需要等待時間的做法，我們可以設計一個系統，讓Alice和Bob在盡可能少地進行鏈上操作的情況下來玩井字游戲。Alice和Bob將能在鏈下更新游戲的狀態，同時仍然有充分的信心，如果有必要的話，他們可以恢復到以太坊主鏈的狀態。我們把這種系統稱為狀態通道。），如果當Bob和Alice選擇將交易放在鏈上而不能阻止Alice進行操作時，那操作就終止了。
(Alice和Bob是密碼學中經常會引用的一對學術情侶)
如果狀態通道中最新的狀態“更新”說“Alice = 5ETH, Bob = 1 ETH”，那么這個狀態就是終結性的。記住，這個更新是由Alice和Bob兩個人共同簽名的有效交易，他們兩人的任何一方都可以隨時將這筆交易放回到鏈上。只要我們可以假設Alice可以在某個時間向全網廣播這筆交易，她就可以認為這筆交易終止了。
狀態通道的核心特質是僅在必要時才返回鏈上。如果通道能夠被合理構建，那么所有的參與方都可以進行更快的操作并且獲得即時終結性。如果有任何地方出現了問題，所有的參與方都可以選擇將最新版本的狀態發布到鏈上。
狀態通道以及所有的區塊鏈技術都應該考慮其威脅模式的驗證。（我們在論文的第3部分中詳細查驗了狀態通道的威脅模式，在第7部分中檢查了狀態通道的局限性。）
最小化鏈上操作
目前存在的用于特定應用的狀態通道實施需要用戶為他們想要使用的每一個應用都打開一個新的通道，并且需要支付高昂的交易費用。舉個例子，如果兩個用戶在鏈上進行了一筆交易開通了一條支付通道，他們需要再做一筆交易來玩象棋游戲。
我們的狀態通道把對鏈上的需要減少到了極致，盡可能的將壓力轉移到非鏈層。這就引出了我們論文中最重要的一個見解：一個強大的多重簽名錢包是個人狀態通道所需要的唯一鏈上組件。
將操作邏輯轉移到鏈下使我們能夠獲得現在的通道所不具有的優勢。我們可以直接在鏈下向狀態通道安裝新的應用。我們甚至可以不通過鏈上交易，并支付費用而直接升級或者重新設計一個狀態通道。
這種方法對于保護隱私也有很好的作用。通過合適的構造，用于保護狀態存入的多重簽名錢包就會和其它的多重簽名錢包一樣。沒有任何方式可以分辨普通的多重簽名錢包和創建狀態通道的錢包。
counterfactual術語
我們可以使用 “counterfactual實例化”來實現這些結果。解釋這項技術需要首先定義術語。
“counterfactual”意思是某件可以是真實的事情卻不是真實的。當討論狀態通道時，這是一個非常有幫助的概念。我們在狀態通道上花大量的時間推理可以發生在鏈上的事情，但是他們卻不是發生在鏈上。
在狀態通道中，我們用“counterfactual X”來描述這樣一個案例：
1. X可以發生在鏈上，但是卻不是
2. 任何參與者都可以單方面地使X發生在鏈上
3. 參與者可以因此認為X發生在鏈上
舉個例子，想像Alice和Bob之間有一個支付通道。Alice使用通道向Bob發送了4ETH，實際上就是雙方對交易進行了簽名。這筆交易可以由他們兩人中的任一人隨時部署在鏈上，但是它并沒有在鏈上發生。因此我們可以說“Alice 反事實地‘counterfactually’給了Bob 4個ETH”。這樣他們就可以認為交易已經發生了，而且在適用的威脅模式內，交易是最終有效的。
Counterfactual實例化
在上面的部分中，我們說我們的方法可以讓你任何鏈上操作或費用直接向狀態通道內安裝新的應用。你可能會想這怎么可能呢？
實現它的關鍵就是我們所說的counterfactual實例化（counterfactual instantiation）。在上面的部分中，我們描述了Alice和Bob 之間的counterfactual/鏈下交易。但是我們也可以通過創建一個counterfactual合約的形式來實現。
counterfactual實例化的意思是在不部署在鏈上的情況下將合約實例化。當一份合約被counterfactual實例化后，通道中所有的參與者都會當作它已經被部署在鏈上了，即使它其實并沒有在鏈上。這種技術幾乎可以讓我們將所有的通道邏輯全部轉移到鏈下。
counterfactual實例化是通過讓用戶簽名并共享對多重簽名錢包的承諾來實現的。這些承諾是如果counterfactual實例化合約在鏈上實現了實例化，多重簽名錢包（持有狀態存入的錢包）將會查看實例化合約并按照合約狀態轉移約定的狀態存入。
為了實現這一點，我們需要在合約部署之前，在承諾中引用counterfactual實例化合約。而為了做到這一點，我們引入一個全局注冊表：一個鏈上合約，可以將任意counterfactual合約的唯一確定地址映射到真實的鏈上部署地址。（在未來，一旦可以實現抽象賬戶，我們就可以做到這一點，這是由于合約地址可以根據字節和構造函數參數計算得出。）用于產生確定性地址的散列函數可以是包含賬戶字節，持有者（例如多重簽字錢包地址）和唯一標識符的任意函數。
舉個例子，我們有一份合約‘C’擁有‘initcode’字節和構造函數參數。運行函數調用‘initcode’參數注冊表的結果是向注冊表中添加一個條目；它的密匙是counterfactual地址，它的值是真正的鏈上地址。
這給了我們一種無需部署在鏈上就可以引用鏈下合約的方式。我們只需要在注冊表中進行查找，看看哪個地址對應cunterfactual地址。在Solidity語言中，就像下面一樣簡單：
Registry(registryAddress).resolve(counterfactualAddress)
面向對象的通道設計
我們的通道設計讓開發人員采用一種面向對象的方法來實現狀態通道。任何個人狀態通道都會由幾個counterfactual對象構成，例如：支付通道對象，或者象棋游戲通道對象。因為這些是counterfactual實例化的，通道中不存在任何費用，只有參與者之間簽字的承諾。
舉個例子，Alice和Bob可以隨時選擇在他們的通道中counterfactual實例化一份合約，假設是一份定義了象棋游戲的合約。為了能夠真正的玩游戲，他們可以參照實例化的游戲彼此交換狀態更新，并且不需要支付鏈上費用。
我們認為這個面向對象的方法提供了很多顯著的好處：
應用開發人員可以針對一個定義良好的API進行編程，插入到每一個通道所需的核心組件中。
我們可以確保，只要核心組件經過大量審計并且保持安全，應用程序開發人員代碼中的bug就可以被隔離到只有代碼控制的狀態區域。
應用程序開發人員可以通過counterfactual尋址重新使用現有組件，就像再次使用以太坊合約一樣，例如：通過可證公平隨機性源。
用戶可以在糾紛中保留隱私，只需要把有爭議的對象放在鏈上。
我們可以獲取更多正常操作中信息傳遞的選擇曲線上的點，以及在產生爭執的情況下需要發布的交易，在某些情況下，我們可以跨通道分期處理陳舊的狀態。
結論
如果你想要了解更多關于廣義狀態通道和counterfactual技術的知識，我們推薦你閱讀一下論文原文。論文中還有我們在這篇文章中沒有總結的重要內容，包括：
與其他技術，如：側鏈和Plasma的比較
對狀態通道現有設計的回顧
相關威脅模式的深度驗證
Meta-channels
廣義狀態通道的一個構建示例
更多更新，請關注我們的twitter賬號@statechannels 和網站。
最后，我們想要感謝以太坊基金會對這項工作的支持。我們很高興能夠成為社區的一部分推動以太坊網絡規模化，這也為Web 3奠定了基礎。我們也要感謝以下人員在論文早期起稿時給予的討論與反饋：Vitalik Buterin, Erik Bryn, Tom Close, Josh Stark, Nima Vaziri, Armani Ferrante, Lisa Eckey, Kristina Hostakova, Yoichi Hirai, Sylvain Laurent。
作者簡介 Liam Horne 狀態通道開發人員
零識僅為翻譯中文供大家學習使用，本文原英文內容版權歸原作者所有。 
