• <option id="cacee"><noscript id="cacee"></noscript></option>
  • <table id="cacee"><noscript id="cacee"></noscript></table>
  • <td id="cacee"></td>
  • <option id="cacee"></option>
  • <table id="cacee"></table>
  • <option id="cacee"><option id="cacee"></option></option>
  • <table id="cacee"><source id="cacee"></source></table><td id="cacee"><rt id="cacee"></rt></td>
    <option id="cacee"><option id="cacee"></option></option>
     找回密碼
     立即注冊

    掃一掃,登錄網站

    首頁 區塊鏈生態 查看內容
    • 13217
    • 0
    • 分享到

    側鏈和狀態通道試圖解決什么問題?

    2018-8-12 19:06

    來源: 巴比特

    狀態通道技術基本的組成包含哪些部分?


    狀態通道基本的組成部分有以下:

    1*6eEGoEk7_bmt4JCNmCnKnA


    1. 區塊鏈的部分狀態通過多個簽名和部分智能合約鎖定,所以這部分參與者必須要完全同意對方去更新它。


    2. 參與者通過產生以及簽名轉賬來自己更新狀態,這最終會上傳到區塊鏈上,而不是直接在鏈上進行計算。每個新的更新會刷新之前的更新。


    3. 最終,參與者將狀態傳回到區塊鏈上,然后關閉狀態通道,并且再次鎖定狀態(通常是按照和開始不同的設置)。


    如果參與者之間更新的“狀態”是數字貨幣余額,那么我們就會有支付通道。第一步和第三步,就會開啟和關閉這個通道,包括區塊鏈操作。但是第二步,無限的更新就會快速進行,而且不需要區塊鏈的干預- 這就是狀態通道的力量,因為只有第一步和第三步需要公開到網絡上,支付手續費,或者等待確認。其實,有了精心的計劃和設計,狀態通道可以幾乎保持無限開啟,并且被用作中心和分支系統,來助力整個經濟和生態系統。


    盡管我們是很簡單地描述,其實狀態/支付通道是很復雜的。這里有幾個原因,其中一個就是這三步背后有很復雜的分散步驟。讓我們仔細來看看,這些都是什么,讓我們從以下開始:可以提交到區塊鏈。


    為了讓狀態通道工作,參與者必須要保證他們可以在任何時候公開通道目前的狀態。這就會導致很多重要的限制,例如有人必須要在線去保護每個參與者,直到通道關閉。


    想象下,當我們開啟支付通道,我通過100個比特幣開始,但是你是通過10個比特幣開始。如果我們開始簽名一個更新,轉賬10個比特幣給我,然后又簽名一個更新,轉賬50個比特幣給你,那么之后的更新很明顯是比早前的那個更有利益。如果你不幸地沒有網絡連接了,那么假設第二個更新永遠不會發生,那么我就可以將第一個轉賬更新到區塊鏈上,然后從你那邊偷走50個比特幣!你需要做的,就是有人在線,并且有之后轉賬的復制,從而他們可以“覆蓋”前個轉賬,并且保證你的比特幣是被保護的。不一定非要是你- 你可以這個備份傳送給很多隨機的服務器,它們都是通過智能合約同意地,并且只要需要,就可以公開轉賬(當然,需要很少的手續費)。但是無論你怎么做,你需要保證最近的簽名更新是可以覆蓋所有其他的。這就到我們的第二個步驟:


    每個新狀態“覆蓋”之前的更新


    為了完成狀態通道的這部分工作,鎖定和解鎖機制必須要能夠合理地設計,從而提交到區塊鏈的舊狀態更新有機會被替代他們的更新狀態所糾正。最簡單的方法,就是讓任何解鎖都開啟計時器,在這段時間里,任何更新的更新能替代舊的更新(同時也重新啟動計時器)。當計時器完成的時候,通道就會關閉,并且狀態就會反應收到的最后一個更新。計時器的長度會為每個狀態通道特定選擇,從而平衡一個長通道的關閉時間,同時也增強安全性,這會防止網絡連接或者區塊鏈問題。另外,你可以通過金融懲罰的方式來構建通道,從而任何向區塊鏈公開不準確更新的人,通過假設之后的轉賬不會發生,讓這些人失去更多。


    但是這個機制并不是很重要,因為(回到之前所說的點)這個情況下的博弈論會讓事情變得很糟糕。這個機制可能只是理論上聽起來沒問題,但是可能從不會使用。其實通過計時器/懲罰過程,也許會導致多余的費用,延遲或者其他不方便;如果讓某些人進入到這個機制,并不能給你任何好處,狀態通道的更方可能只是通過人工同意最終的狀態通道,從而關閉通道。最終的關閉操作需要和正常的“中介”更新不同(因為它會繞過上面的“覆蓋”機制),所以一旦在某個通道的部分狀態鎖定,參與者會只是簽署最終的轉賬。


    這些“細節”不是特別重要。它最終分解開,可以理解為,參與者通過設置一個“法官”智能合約來打開通道,互相簽署協議,如有必要,裁判可以強制執行,然后通過在其中達成共識關閉通道,那么法官的判斷就不需要。只要“法官”機制是可靠的,這些承諾就可以被認為是即時轉賬,法官只在特殊情況下上述,例如一方參與者消失。


    當然,這些細節只是人們認為狀態/支付通道復雜的愿意之一。更多地是,比特幣支付通道是很復雜的。在比特幣中建立“法官”機制是非常錯綜復雜的。但是一旦你對狀態通道有清晰的理解,你可以看到這僅僅來自于在受限的上下文中實現這個想法。基礎的智能合約機制,例如計時器機制以及根據上傳的簽名信息來選擇兩個不同的道路,這其實在比特幣中更難做到。某些功能是逐漸添加和建立的。通過看到支付通道只是特殊的廣泛“狀態通道”概念的子案例,我們發現這是更快寬泛的技術,并且這個狀態通道能夠應用到任何智能合約中,它們和定義的參與者之間進行高頻的更新。你可以預見,這種方式會在很多分布式應用中出現。

    現在,我們應該對什么是“狀態通道”比較清楚了,接下來我們來看看側鏈技術。


    版權申明:本內容來自于互聯網,屬第三方匯集推薦平臺。本文的版權歸原作者所有,文章言論不代表鏈門戶的觀點,鏈門戶不承擔任何法律責任。如有侵權請聯系QQ:3341927519進行反饋。
    相關新聞
    發表評論

    請先 注冊/登錄 后參與評論

      回頂部
    • <option id="cacee"><noscript id="cacee"></noscript></option>
    • <table id="cacee"><noscript id="cacee"></noscript></table>
    • <td id="cacee"></td>
    • <option id="cacee"></option>
    • <table id="cacee"></table>
    • <option id="cacee"><option id="cacee"></option></option>
    • <table id="cacee"><source id="cacee"></source></table><td id="cacee"><rt id="cacee"></rt></td>
      <option id="cacee"><option id="cacee"></option></option>
      妖精视频