狀態通道的基本組成非常簡單：
1.將區塊鏈狀態的一部分透過多重簽名或某種智慧合約鎖定，因此，特定的參與者集必須彼此間完全同意才能對其狀態進行更新。
2.參與者們透過構建和簽名可被提交至區塊鏈的交易，以更新他們之間的狀態，而在此之前狀態只是暫時保持在內部。每個新的狀態更新都“高於”之前的更新。
3.最後，參與者們將狀態提交回區塊鏈，這將關閉狀態通道，並再次解鎖狀態。
就這樣。如果參與者之間更新的“狀態”是加密貨幣的餘額，那麼，我們就有了一個支付通道。開啟和關閉通道的步驟1和3涉及到了區塊鏈操作。
但步驟2可以快速執行不限制次數的更新，且無須涉及到區塊鏈。這就是狀態通道可以發揮作用的地方。因為，僅有步驟1和3需要釋出到網路上，以及支付費用或等待確認。
實際上，透過仔細的規劃和設計，狀態通道幾乎可以無限期保持開放狀態，且可用於大型樞紐系統的一部分，為整個經濟或生態系統提供動力。
儘管這裡描述看似簡單，但人們通常認為狀態/支付通道是非常複雜的。造成這種情況的原因有很多：其中之一就是在對這三個步驟的表述中隱藏了一些重要的微妙之處。讓我們仔細看下這些簡單的短語所隱含的含義：
· 可以提交到區塊鏈
為了使狀態通道正常工作，必須確保參與者可以在任何時候將其當前通道的狀態釋出到區塊鏈上。這導致產生了一些重大的侷限，例如這樣的事實：在通道關閉之前，有人必須保持線上以保護每一方的利益。
想象一下，假設當我們開啟一個支付通道時，我以100BTC開始，而你以10BTC開始。如果我們首先簽署將10個BTC轉給我的更新，然後又簽署將50個BTC轉回給你的更新，第二個更新明顯比上個更新對你更有利。如果你意外地網路掉線，而我則可以假裝第二次更新從來沒有發生過，那麼，我能將第一次更新發布到區塊鏈上，從而有效地從你哪裡竊取了50個BTC。
你需要的是有人保持線上，擁有最新交易的副本，以便於它們可以“高於”早前的交易，並確保你的比特幣得到保護。不一定是你自己保持線上。你可以將副本傳送到很多隨機伺服器，它們同意透過智慧合約僅在需要時才釋出它（可以節省費用）。但是，無論你如何做，你都需要確保最新簽名的狀態更新都是高於其他所有更新的。這使得我們進入下一個微妙的短語：
· 每個最新更新都“高於”之前的更新
為了使狀態通道的這一部分正常工作，必須正確地設計鎖定和解鎖機制，以便提交給區塊鏈的舊狀態有機會被取代它們的新狀態所糾正。最簡單的方法是讓任何解鎖嘗試啟動計時器，在此期間，任何新的更新都能取代舊的更新（也重啟計時器）。當計時器完結，通道關閉，並且狀態將進行調整以反映最後一次收到的更新。
可以為每個狀態通道選擇計時器的長度，以平衡較長通道關閉時間的不便利性和不斷增加的應對網際網路連線或區塊鏈問題的安全性。（藍狐筆記：此處意思是權衡利弊，計時器過長，導致通道關閉時間過長，則會帶來不便，而計時器過短，則可能帶來安全問題）
或者，你可以透過罰款方式來構建通道，這樣任何向區塊鏈釋出不正確更新的人的損失要比他們假裝沒有發生後續交易所獲得的更多。
但是這個機制最終不會有太大關係，因為（回到上一點）這種情況的博弈論使得事情產生變化。只要這種機制在理論上是合理的，它就可能永遠不必使用它。
實際上透過計時器/ 懲罰程式可能會帶來額外的費用、時延或其他不便；考慮到迫使某人進入機制並不能給你帶來任何好處，因此，一個狀態通道的參與方可能會只是透過相互商定最終通道狀態來關閉通道。
這種最終關閉操作跟普通的“中介”更新有根本上的不同（既然它將繞過上面提及的最新交易“高於”之前交易的機制），因此，參與者對於在特定通道內鎖定的狀態的每個部分僅是簽署一次關閉交易。
這些“微妙之處”的細節並不是特別重要。最終歸結為參與者透過設定“法官”智慧合約來開啟通道，相互簽署如有必要“法官”可以強制執行和裁決的承諾，然後，相互協商關閉通道，這樣法官的裁決就不需要。
只要“法官”機制被認為是可靠的，這些承諾就可以算作為即時轉移，只有在特殊情況下法官才會出現，例如參與方消失時。當然，這些細節只是人們認為狀態/支付通道是複雜的部分原因。更大的原因是比特幣的支付通道是複雜的。在比特幣上構建具有合理有用屬性的“法官”機制是非常複雜的。
不過，一旦你對狀態通道有一個清晰的總體概念，就能看到，這只是由於在一個受限的環境中試圖實施這個概念而產生。基本的智慧合約功能，例如計時器機制和根據提交的簽名資訊來允許採用兩種不同路徑，這些在比特幣中很難做到。
其中的一些功能正在逐步新增或構建。支付通道只是更廣泛“狀態通道”概念的特殊子情況，我們可以意識到這是一種更廣泛的技術，狀態通道可以應用到任何智慧合約，這些智慧合約在定義好的參與者組中處理頻繁的更新。你可以預期在很多（如果不是大多數）分散式應用中看到這種方法。
現在，我們對什麼是“狀態通道”有了更明晰的理解。因此，我們來看看側鏈。
什麼是側鏈？
側鏈是使用雙向錨定關聯於其父鏈（主鏈）的單獨區塊鏈。換句話說，你可以將資產移至側鏈，並再移回父鏈。（藍狐筆記：就是將主鏈資產在主鏈和側鏈間來回移動）
雙向錨定使得可以在父鏈和子鏈之間以預定的匯率進行資產互換。原始區塊鏈通常成為“主鏈”，其他所有外加的區塊鏈都稱為“側鏈”。區塊鏈平臺Ardor將其側鏈稱為“子鏈”。
父鏈上的使用者首先必鬚髮送其代幣到一個輸出地址，這些代幣會被鎖定，因此使用者無法在其他地方消費它們。在交易完成之後，會透過跨鏈進行確認，然後等待一段時間，以提高安全性。
在等待期過後，側鏈上會釋放等量的代幣，允許使用者獲取並在此處進行消費。當將資產從側鏈移回主鏈，流程剛好相反。
聯盟
聯盟是一個組，它在主鏈和其一個側鏈之間充當中間點。這個組確定何時鎖定和釋放使用者使用的代幣。側鏈的建立者可以選擇聯盟的成員。聯盟結構的問題在於，它在主鏈和側鏈之間新增了另外一個層。
側鏈要負責自身的安全。如果沒有足夠的算力來保護側鏈的安全，它有可能會被攻破。因為每條側鏈都是獨立的，如果它遭受攻擊或入侵，損壞會在該鏈中發生，而不會影響主鏈。相反，如果主鏈遭受攻擊，側鏈仍能執行，但其錨定資產將會失去大部分價值。
側鏈需要它們自己的礦工。可以透過“合併挖礦”激勵這些礦工，因此，兩種獨立的代幣，基於相同的演算法，可以同時開採出來。
現在，我們對側鏈也有一個很好的瞭解。所以，讓我們把它們放在一起。
它們想解決什麼問題？
通常，側鏈和狀態通道都是用來提高區塊鏈可擴充套件性的。他們遵循類似的模型。
· 鎖定狀態/資產
· 在區塊鏈/主鏈之外進行交易
· 從狀態通道/側鏈中解鎖狀態/資產
但儘管有這樣的類比，但兩者間有很多不同，這是因為狀態通道中我們不使用單獨的區塊鏈，而在側鏈中我們使用單獨的區塊鏈。讓我們來看看這會導致什麼結果。
兩者中哪個是更好的擴充套件性解決方案？
為了得出答案，我們來看看它們的優缺點。
狀態通道的優點
狀態通道有很強的隱私屬性：這是因為所有事情都發生在參與者之間的通道“內部”，而不是公開廣播和在鏈上記錄。只有開啟和關閉的交易必須是公開的。
而在側鏈上，每筆交易都會發布到側鏈上，無論你是否跟側鏈上的所有參與者互動，交易都會被側鏈上每個參與者接收。
狀態通道有即時最終性。這意味著只要雙方簽署狀態更新，它就可以被認為是最終狀態。雙方都有很高的保證，如有必要，他們可以在鏈上“強制執行”該狀態。但正如上面提到的，考慮交易的安全級別，狀態通道的關閉可能需要花費不同的時間。
而在側鏈中，另一邊有一條區塊鏈，因此，最終性依賴於側鏈的挖礦算力。
狀態通道的缺點
狀態通道需要所有參與者100%的線上（可用性）：正如我們上面討論的，如果任何參與者不線上，那麼，這可能對他來說要付出代價。如果參與者不線上，參與者可以使用其他人來代表TA。但代表被攻擊或被賄賂的可能性讓會它會成為狀態通道的問題。而在側鏈上則你不必總是線上。
狀態通道最適合用於有已定義好參與者集的應用：這是因為“法官”合約（用於鎖定狀態的合約）必須瞭解特定通道部分的參與者/主體（即地址）。我們可以新增和移除人，但它要求每次對合約進行更改。而在側鏈中，參與者變化方面沒有這種限制。
狀態通道在這種情形下尤其有用：參與者將要在長時期內交換很多狀態更新：這是因為建立通道部署“法官”合約會產生初始成本。但是，一旦部署，在狀態通道內每次狀態更新的成本會非常低。
側鏈的優點
側鏈是永久的。如果存在有側鏈，你無須為特定目的而建立專屬的側鏈。側鏈一旦建立，就是完成構建並進行維護。我們不會關閉側鏈，而是鎖定在側鏈上的資產以移回主鏈。這是非常有用的方式，任何在區塊鏈/主鏈外做特定任務的人都會來到相同的側鏈。
因此，你不必為每個新參與者建立獨立的鏈。而在狀態通道，你通常必須建立新的狀態通道來新增新參與者。但諸如閃電網路、雷電網路這些專案為此提出了出色的解決方案。他們建立了參與者網路，由此你不必為與之互動的每個新參與者建立新的通道。
你可以跟參與者進行間接互動，方式是在你和接收者之間透過你們之間共同的其他參與者來建立一個通道：你和接收者。
側鏈允許加密貨幣相互互動：它們增加了靈活性，並允許開發者在山寨幣的Beta版本或軟體更新上線主鏈之前，可以在側鏈上實驗。像傳統的銀行功能（如發行和跟蹤股份所有權）可以在側鏈上測試，然後再移至主鏈。
側鏈的缺點
側鏈需要很多初始投資來啟動：為了建立側鏈，我們需要足夠的礦工，以使網路免遭攻擊者的攻擊。此外，我們必須確保它們已經啟動和在執行。然而，在狀態通道中沒有區塊鏈，因此，沒有這些要求。
側鏈需要聯盟：這在主鏈和側鏈之間增加了額外的層。這可能是攻擊者可以攻擊的另外一個弱點：可以賄賂或攻擊聯盟。然而在狀態通道中，我們只需要一個智慧合約就可以為我們完成這項任務。
兩者之間的競爭是偉大的。塵埃落定，但兩者依然站立。由於研究依然在持續，實際的使用還沒有傳播，我們無法確定誰會是贏家。或許它們會融合，形成一種混合解決方案，來解決擴充套件性問題。直到實現之前，我們還需要等待，看看什麼時候能看到。
