• <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>
     找回密碼
     立即注冊

    掃一掃,登錄網站

    首頁 自媒體 查看內容
    • 4139
    • 0
    • 分享到

    【演講視頻】李一靈:解決比特幣擴容問題的四個方案

    2018-4-28 06:19

    來源: jazzchain

    演講嘉賓:李一靈 編輯:希安 

    設計:孫佳棟 公眾號:甲子區塊鏈(ID:jazzchain)


    李一靈演講視頻



    本期主講嘉賓:李一靈,前小蟻(Neo)海外經理,負責2016年小蟻的全球代幣眾售及其后續的社區建設、商業合作、生態建設等。加密貨幣項目PR與咨詢企業FourierPR聯合創始人,Fourier的客戶涵蓋coinmarket cap前一百的列表。壘石科技創始人,旗下產品有媒體網站inwecrypto.com,多資產錢包InWeWallet。



    作為一個老生常談的問題,區塊擴容似乎有了越來越多的答案。


    區塊鏈(特別是公鏈)想要真正做到更深度化的應用和普及,關鍵就是要解決交易的吞吐量和交易的時延問題,這在區塊鏈中也被稱作“可擴展性” (Scalibility)。


    Trinity State Channels創始人李一靈在演講中回顧了,迄今為止區塊鏈領域對于解決比特幣擴容問題的四種嘗試,并一一點評:


    增大區塊的方法簡單粗暴,但治標不治本;修改共識機制提高了出塊效率,但不夠“去中心化”;分片通過限制了交易的類別與范圍來減小共識的范圍,但是無法滿足日益增長的多種類交易需求,其技術實現也異常復雜,截止目前鏈上分片也依然停留在理論研究階段;構筑狀態通道網絡應被視為對主鏈擴容本身的補充方案,但是其吞吐量仍受制于底層鏈


    李一靈給出的結論是:區塊鏈擴容是個工程問題,需要多個方案同時使用。





    以下為壘石科技創始人、FourierPR聯合創始人李一靈「甲子光年」主辦的「正本清源 | 2018“中國區塊鏈第一辯”暨行業領袖峰會」上的演講整理:



    大家好,簡單介紹一下我自己,我之前是在Neo做一個海外經理,后來做FourerPR,這個公司從去年成立,從9·4后響應國家號召,停掉所有業務。但是你們看到的市面上絕大部分的項目,比如Coin Market Cap上面排前100-150的最出名的國際上的項目,都是我們帶到中國市場上的。現在我們是做了Trinity State Channels,這是一個二層的裝載通道網絡。



    我先回答清華大學徐恪教授講到的兩個問題。


    第一個是比特幣算力攻的問題,很多年前就有人想過用超級計算機來挖比特幣,而且已經有人做過了,這樣做得結果是他連電費都付不起。大概在2014年的時候,比特幣全網的實際算力,如果用球TOP500的超級計算機來挖,大概是全網算力已經是超級計算機來做這件事的14萬倍,想一想最近這幾年算力膨脹了多少,這是不可行的。


    第二個問題是量子安全的問題,我們很早的時候已經和這方面的團隊做過這方面的論證,實際上有人已經做過這方面的嘗試。有一個項目叫Quantum Resistant Ledger(QRL),現在網上還能找到它零星的相關資料。


    實際的情況是什么呢?你們可以參考VitalikBitCoin Magazine上發布的一篇文章,這個文章就是討論的量子安全的問題。


    可以明確的說,首先第一點,假設有量子計算機,假設我們迎來了量子計算機的性能超過傳統計算機,甚至達到了可以做SHA256碰撞的時候會發生什么事情?它第一個動作當然不是攻擊比特幣區塊鏈,它可以有無數傳統的行業去攻擊,那個的經濟價值,比攻擊這個價值很小的區塊鏈市場有利可圖得多


    第二點,如果現在你的地址沒有多次使用,向外發送交易,其實它是非常安全的,相對安全的。只有那種反復使用過幾百次的地址來存儲你的加密貨幣資產,可能才會比較危險。


    但是隨著密碼學的發展,我們相信以后能過渡到更新的,被認為能抗量子攻擊的一些密碼學算法,比如說格密碼


    講講今天的技術問題,區塊鏈會面臨很多的挑戰,特別要實現技術升級。比如說更好的密碼學算法,更好的共識機制,或者怎么樣把現實世界的數據上鏈,這個要用到去中心化的預言機,諸如此類的,但最重要的方向是擴容




    何為擴容?


    擴容是什么意思呢?就是我們知道現在比特幣區塊鏈吞吐量非常低,以太坊也好不了多少,現在已經運營的公有鏈里面實際交易吞吐量最高是Neo,但這依然不夠。


    作為對比,Visa它的交易量可以達到幾萬筆,微信、支付寶一樣的,對比我們這種個位數、十位數或者百位數的交易量,完全沒有可比性。如果沒有承載這樣交易量,你連基本的全球的金融交易量都無法支撐,更不要說是支撐那些復雜的業務邏輯。


    為什么要支撐業務邏輯?就是所有應用的邏輯如果要上鏈,是以trunsaction的形式在鏈上跑起來的,它都以交易呈現,就需要有非常高的交易吞吐量。這也就是所謂scalebility的問題,scalebility這個問題在2014年就被提出來,因為大家認識到比特幣區塊逐漸被填滿。


    2015年的時候,比特幣圈的人搞了一個香港共識,國內外主要一些企業爭得不可開交,最后撕毀協議,什么都沒有達成。它不是一個最近才出現的問題,只是說去年由以太坊帶來的ICO Boom太火了,以至于掩蓋這個問題的存在。


    我們來講一講現在有哪幾個方案來解決這個問題。第一個,大區塊。這里主要是在說比特幣分叉BCH。大區塊的解決方案很簡單粗暴,你不是說區塊滿了嗎,區塊容量不是中本聰定的金科玉律,實際上中本聰說過,滿了就提嘛。




    Plan A: 擴大區塊容量


    有人說,現在主要解決比特幣擴容問題的方案,就是去擴大區塊容量


    擴大區塊容量會帶來什么問題?它會帶來更多的鏈和塊的體積,全網節點數降低。先不講安全問題,我們講這會導致什么情況,大家都知道比特幣的生態是什么回事,挖礦,這樣就導致全節點數量降低,大家知道現在比特幣全網節點的數量有多少嗎?幾千,實際上以前你要跑一個全節點很容易,只是現在你不會去做的。


    區塊容量更大了之后,普通人就更難參與了,連全節點都做不到,不要說挖礦了。這是第一個。第二個,數量降低之后這個東西天然集中,集中到有利于誰呢?利于礦工和礦池。這里也有這方面的朋友在,所以我就不再多說這個問題。


    總的來說,這是一個治標不治本的方案,而且我相信只要對這個有基本技術認識的人應該是有共識的。



    Plan B:改共識機制


    第二方案,改共識機制。改共識機制最有代表性的就是BitSharesEOS,而且實際上這都是出自同一人之手,所以說它有一定的慣性。其實比特股做得挺好的,但是現在怎么樣大家心里也知道。



    我覺得BM這個人他是一個天才,他做的東西都非常好,但是往往因為不知道什么樣的原因會走形。比如說由于DPOS機制帶來的中心化問題,這里面最大的問題就是選出來的節點不代表全網用戶的利益。而且一個利益群體可以控制多個節點,這是一個問題。第二個問題,實際上BM對此有一個很意思的論斷,他認為去中心化我們最后追求的不應該是為去中心化而去中心化,或者是網絡結構上的一個去中心化,而是為了去中心化能實現的那些好處,比如杜絕了單點故障問題,帶來了更高的安全性等。


    除此之外,這個方案還有一個問題,3秒鐘仍然有時延,只要有區塊時間它仍然有延遲。只要有延遲,需要時間敏感性,需要瞬時交易的那些應用都不能足夠滿足,但是我要指出的是,目前看來,幾個方向里面EOS的方案是最靠譜的,是最有可能實現的,當然肯定達不到它聲稱一百萬TPS。主網出來的時候可能會到一個四位數的TPS就是一個比較理想的情況,這應該是目前最好的方案之一。



    Plan C鏈上分片


    第三個方案,鏈上分片。就是sharing,這個概念很有意思,就是我們同一個片里面只負責處理某一類交易,這樣的話效率顯然高很多,也就是減小共識的范圍



    但是鏈上分片存在一個問題:如果我們只跑一類交易,比如說轉賬比特幣,那可能沒有問題,但是一旦我們加入了智能合約,支持了更多的應用,就意味著開發者會創新,創新之后就會帶來更多種類的交易不是更多數量,是更多種類更多種類的交易它要跨片通信就會有問題了,這是矛盾是沒有辦法調和的。


    有可能導致一個結果就是說,你分片之后,你在處理不同交易的時候,其實效果比你不分片還慢,也就是實說你還不如不分片。所以我們這個地方現在也沒有一個可行的解決方案。


    Casper是以太坊的一個解決方案,Zilliqa是一條自己的公鏈,當然它的虛擬機用的是EVM,它們兩個目前都不是一個可用的狀態Zilliqa團隊解釋說他們會很快,在一到兩周之間,可能會推出一個測試網,在測試網上大家可以做簡單的交易,來進行測試,看分辨的結果怎么樣。


    在他們自己測試環境里面TPS可以達到1200-2000,但是后面實際情況我們要再看。至于說不同交易類型支持的問題,它的選擇不像Casper那樣,它不做狀態分片,這實際上是給交易類型做限制,他們認為如果能支撐大部分的交易類型就可以了,具體情況等到測試網出來測試了才知道。



    Plan D:狀態通道


    第四個方案,叫State ChannelState Channel這個東西很早就有人提出來,但是實際上是這樣的,Raiden和閃電網絡很早就提出來了,但是提出狀態通道這個詞是在2016年底



    這幾個項目實際上做的都是一個東西,放到鏈下。什么叫放到鏈下?我打一個比方,我們可以把不同的公鏈都看成是地上的公路系統,而狀態通道網絡是構筑在公路系統上的高架橋系統,所以一個Vehicle可以是一筆交易,它可以幫助你的Vehicle快速地從A點達到B點。怎么講呢?這個東西帶來很多好處,第一個所有的交易都是即時的,帶來的體驗可能比支付寶和微信還要好。具體來說,經常有人問我,你出來能給多少TPS?我說你用通道嗎?他說是,我就隨便編一個數,哄哄他,因為我說實話可能不懂,我說可能8萬、10萬、20萬,喜歡嗎?其實就是無窮大,一個節點只要它的硬件性能足夠,帶寬足夠,它可以做到無窮大。


    但是有一個問題,狀態網絡只是主鏈本身補充的方案。你回想一下上海的高架系統或者杭州的高架系統,往往高架本身不堵,但是在上高架和下高架的時候會堵,因為下面的主路堵車


    所以如果說主鏈的處理性能不夠,我們狀態通道做得再好,也會被它卡住。我們做一個假設,以太坊每秒交易20筆,也就是說能同時支撐十個人開啟通道,這是一筆交易,也能支撐十個人關閉通道,這也是一筆交易。這是20個人,同時用通道網絡就崩掉了,根本不可能支持任何其它的交易。


    你想像一下,假設有一個APP,有幾萬用戶同時在使用,有無數多這樣的APP,你的主鏈性能要到多少,僅僅是支持狀態通道交易。所以說區塊鏈擴容的這個工程問題,是需要多個方案同時使用,最重要的就是鏈上和鏈下的方案同時使用


    狀態通道的另一個問題,就是去中心化。通道的去中心化有幾個方面,第一個方面是業務本身,經常有人抱怨說,最近臉書的數據泄露事件,這個東西你能怪臉書嗎?大家都去用臉書,不能說因為臉書不好,然后你去怪下面的操作系統不好吧?如果說一個產品本身有中心化的問題,你就用另外一個產品好了,這是市場競爭帶來了,所以說和區塊鏈、狀態通道無關。


    第二點,交易流程。這個問題我在這里不深入去講。狀態通道雖然在鏈下進行,但是它仍然用了區塊鏈基本的屬性,依然是不可篡改的


    第三點,物理結構。這是很多人噴閃電網絡就是這個問題,我不是在這里說我簡單粗暴地支持比特幣閃電網絡,因為那個東西跟我沒有關系,但是我要解釋一下。有個笑話是說,有個人布了一個節點之后,沒有人跟他連接,因為它支持BCH,他們就說最后的問題是會有很多大的節點運營者成為壟斷的對象,這是沒有辦法的,這是市場競爭自然的結果。如果你阻止人通過提供更好的服務和產品,獲取更好的經濟收益,你阻止他這么做,你強行一個CPU一票,強行一人一票的共識,這是大鍋飯,那大家就不要干了。其二,狀態通道具體來說,和現在的工作證明機制來比的話,我雖然電腦性能比較高,帶寬比較高,我依然可以做比特幣全節點,但是肯定挖不了礦。但是如果不屬于一個自己的閃電網絡節點,你實際還是可以和別人連接,然后轉發交易的,這是第三個問題,所以狀態通道是可以做到完全去中心化的

    版權申明:本內容來自于互聯網,屬第三方匯集推薦平臺。本文的版權歸原作者所有,文章言論不代表鏈門戶的觀點,鏈門戶不承擔任何法律責任。如有侵權請聯系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>
      妖精视频