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

    掃一掃,登錄網站

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

    我們是如何用分片技術把7筆/秒的區塊鏈交易提升到2488筆/秒的?

    2018-4-13 09:09

    來源: blockchain_camp


    內容 | 賈瑤琪  Zilliqa技術總監、聯合創始人

    整理 Aholiab



    眾所周知,吞吐量一直是區塊鏈的一個痛點。比特幣的底層設計僅支持每秒7筆交易,還不及傳統支付工具Visa每秒8000筆交易的一個零頭,更別說支付寶在去年雙十一創造的每秒25.6萬筆的記錄。這嚴重制約了去中心化應用的發展。去年以太貓風靡全球,造成了以太坊的大堵塞,以至于人們戲稱用是否造成區塊鏈堵塞來評價去中心化應用的熱度。


    針對如何提高區塊鏈的吞吐量,業界也在不斷嘗試。為改善比特幣網絡的吞吐量,去年比特幣硬分叉出了比特幣現金。


    近期,Zilliqa技術總監、聯合創始人賈瑤琪談到了這一問題的解決方案。


    賈瑤琪來自Zilliqa團隊,之前在新加坡國立大學讀博士,博士期間主要研究偏底層的網絡協議,以及點對點協議的隱私保護,還有可擴展性問題。2017年,跟師兄還有導師一起創建了Zilliqa團隊,主要就是用分片技術,來提高整個公有鏈的可擴展性,以及實現高吞吐量


    說到分片技術,里面包含很多種不同的技術。比如以太坊的分片技術,還有Zilliqa的分片技術。



     公有鏈的吞吐量問題


    大家可能都了解比特幣、以太坊,以及其他的公有鏈。區塊鏈技術為大家提供了很多好的特性,比如去中心化、透明性、以及不可篡改性。但如果大家把區塊鏈作為一個記賬或者帳本系統,這其中有一個很大的問題,就是關于吞吐量的問題。



     

    比特幣每秒最多只能處理7筆的交易,如果用搭火車的例子來講,比特幣就對應著手工檢票,每秒只能檢7個人。而傳統的記帳系統,例如信用卡、VISA或者MasterCard,他們平均的處理效率超過每秒8000筆交易,就類似于現在我們高速公路上使用的ETC,或者檢票中刷臉進站的系統,可以迅速地處理大量的交易。



    低吞吐量的弊端

     

    由此可見,目前公有鏈的低吞吐量會帶來很多問題,例如大家都會見到的高手續費問題。在去年有一段時間,如果你在比特幣上面進行一些交易,比如A轉比特幣給B,手續費可能就高達50美元。另一個方面,像以太坊去年做ICO,或者做這種代幣募資,很多人為了搶資格,就會花費很高很高的手續費,來競爭去加入一個代幣募集。



    其實,雖然你設置了這么高的手續費,有時候也是搶不到這個資格的。高手續費會限制很多功能,從而導致我們現在沒有一個很好的殺手級的應用。大家可能都知道,去年在以太坊上面最火的兩個應用,一個就是ICO,另一個就是風靡全網的以太貓。但以太貓在以太坊上比較火的時候,占據了以太坊上超過30%的流量,導致整個以太坊有很多的擁塞。在那個時候,如果你想做一筆簡單的轉帳,必須支付更高的手續費才能完成這筆交易。


    因此,這個低吞吐量導致了目前還沒有殺手級應用。我們可以聯想到在互聯網初期,大家用的整個底層系統可能還沒有搭好,同時網絡費用又特別得高,我們只能瀏覽一些簡單的網頁。但隨著整個互聯網系統生態的發展,大家慢慢也會看到一些很偉大的公司。例如像Google、Facebook、Twitter,以及國內的百度、阿里巴巴、騰訊,他們的崛起就是因為這個底層生態系統建好了。有了這樣的高吞吐量,才使得更多的企業以及程序員參與進來,創建許多殺手級的應用。


     公有鏈的可拓展性


    那么如何來解決低吞吐量問題,我們需要公有鏈有「可擴展性」,但可拓展性其實并不等同于高吞吐量。



    很多場景下只需要高吞吐量,不需要可擴展性,所以你只需要一個很強大的服務器來提供一個很高的吞吐量。但是對于可擴展性,就要求你隨著節點數的增加,你的吞吐量也得相應地增加(因為可擴展性更多地是指隨著節點數目的增加,吞吐量或者性能也增加,所以很多時候大家其實是要求的高吞吐量而不是可擴展性)。



     已有的解決方案


    目前來看,比特幣處理交易的速度小于每秒10筆,以太坊小于每秒20筆,但傳統的記帳系統,例如信用卡,交易速度超過每秒8000筆交易。我們如何去解決這個可擴展性,或者說低吞吐量的問題呢?目前有幾種方案。


    方案一,增加區塊的大小。例如比特幣,我們現在一個區塊的大小可能只有1MB的存儲空間。如果要進行交易的話,只能把交易加到這1MB里面。如果大家也做比特幣交易,可能都知道去年底的SegWit2x,將區塊大小從1MB提高到2MB。但是出于對安全性和其他因素的考慮,最終Bitcoin Core取消了這個SegWit2x硬分叉。導致了當時大量的資金都投向了以太坊的ICO項目。



    當你把區塊大小從1MB升級到2MB,或者10MB,甚至1GB,但這個方案是否能達到提高100倍吞吐量的效果呢?不一定,因為你雖然可以把區塊大小升級到1GB,但由于你的計算性能以及帶寬的限制,導致整個網絡不能正常運行。像比特幣或以太坊,都是要通過工作量證明達成共識,工作量證明之后還要在整個網絡進行廣播,如果是1MB可能還好,如果1GB的話,要進行這個廣播,基本上不可能在10分鐘以內通知每一個礦工。所以這里面有一個很大的限制。

     

    方案二,鏈下交易。對應比特幣的閃電網絡(Lightning Network)和以太坊的Raiden Network。他們給出的解決方案大致是這樣的,你提前支付一些以太坊或比特幣作為押金,之后你可以在鏈下通過一些手段,來跟其他人進行交易。這就類似于你提前在鏈上存了一些押金,然后其他的終端用戶可以在咖啡店里和你進行交易。交易結束后,你要把這個結算放在區塊鏈上面,這樣一個鏈下的方案。因為你鏈下處理這些交易的話,可以用一個十分強大的服務器來進行處理。這樣就可以大幅度提升系統的吞吐量,可以做到每秒上萬,甚至是幾十萬的交易量,類似于淘寶。



    但是大家可以看到,這里有一些問題,就是你一旦用鏈下的話,雖然能夠達到高吞吐量,但是交易失去了開放性、透明性的優勢,相當于做了客戶端服務器的一個終端。同時由于你用鏈下交易,就沒有那么多節點去進行行為監督,那么也就少了去中心化的優勢。

     

    方案三,代理人共識協議解決方案。如何選出這些代理人,你可以用權益證明,也可以通過一些官方的驗證。例如我有一個公司,這個公司有相應的資質,那么官方就會給我發一張牌照,我就可以作為一個代理人。



    不管是7個代理人還是21個代理人,甚至可能是幾十個代理人,大家會形成一個小團體。例如我們現在這些人,都可以去做一個代理人。之后我們去運行一些共識協議或者類似功能的協議,來達成一個共識,產生區塊,然后再將這個區塊廣播給整個網絡,從而達成整個網絡的共識。這樣做的好處就是,這個機制可以保證在一個很小的團體內部,很快就達成共識。這樣做很簡單,只要使用一些已有的共識協議,你就可以很快達成共識。


    不過,代理人共識協議也會帶來一些問題,我們剛剛也有提到大家對于去中心化的擔憂。因為像比特幣或以太坊都有成千上萬的節點來做共識決策。代理人共識協議目前只有一個小團體的代理人來做共識,難免會被大家質疑你是否去中心化,以及你的安全性。因為這一小部分的節點可能都是一些利益團體選出來的,他們是否能代表絕大多數人的利益呢?這些都是有待考證的。


    不過以上這三個解決方案都是很好的解決方案,大家如果從不同維度,不同場景出發,這幾個方案都是有很大的用處。而今天我要跟大家分享一下,我們Zilliqa是如何用另外一種解決方案,我們叫做分片技術,來實現這樣一個高吞吐量的。我們的方案跟前面的幾個方案不在同一個維度,但是幾種方案其實是可以共生的。



     一種新的解決方案


    在講分片技術前,大家可以先看看整體的結果和運行效果。這些數據都是在亞馬遜的EC2上面測試得到的,通過搭測1800個節點、2400個節點以及3600個節點運行我們的算法,得到了下面的數據。直觀上看,隨著節點數以及分片數的提升,我們的測試數據,可以從每秒1218筆交易,達到每秒2488筆交易。



    這樣我們可以得出一個結論,相對于比特幣或以太坊我們可以獲得一個很高的吞吐量。另一點也很有意思,從圖中我們可以看到隨著節點數目的增加,吞吐量也是在增加的,我們真的實現了這種可擴展性。


    講了這么多,那么這個技術到底是怎樣的呢?



     分片技術概覽


    網絡分片,簡而言之就是并行化的分而治之。例如我們整個網絡有1萬個節點,我們可以把1萬節點,分成不同的小組,每一個小組,可以有不少于600個節點,這樣來叫做一個劃分。劃分之后,我們在每一個分片里,處理不同的交易。之后先在每個分片里面達成共識,然后會有一個單獨的分片將共識的結果進行匯總,廣播給整個網絡。

     


    在這個系統的初始化階段,我們會將整個網絡劃分成不同的分片,每個分片不少于600個節點。過了一段時間,可能有一些新的節點想要加入,也可能有一些舊的節點因為自身網絡的問題,或者系統的問題,想要離開。這種情況下,我們該如何將這些新的節點加入網絡,將那些舊的節點從網絡中剔除。

     


    每過一段時間,我們都需要做一次工作量證明。工作量證明部分跟以太坊基本上是一樣的,這要求你將上一個區塊的哈希值、節點的IP地址和你的公鑰一起進行哈希計算。大家都知道,哈希計算就是工作量證明,最終你要滿足哈希值的閾值。對應的難度是相匹配的,例如哈希值的前100位都是0,如果你算出來的哈希值滿足這個條件,就說明你完成了工作量證明。



    之后你就可以產生這樣的一個結果:我們會得出你的ID,之所以要你的ID就是因為我們會根據你ID的最后幾位,來決定你應該被分到哪一個分片上。這樣的話,對于一個新的節點來說,是無法通過自己的意志去加入某一個分片的,只能通過工作量證明,而工作量證明難度較高,因此可以避免出現新節點自己選擇分片的情況。因此工作量證明的最后幾位,就可以從數學上保證你的隨機性是足夠的。


    如果一個節點想要加入我們的系統,他加入的方法就是做工作量證明,然后被隨機分配到一個分片里面。這樣做的好處就是,我們可以保證一些惡意節點不能直接加入到某一個分片,因為所有的節點都是被隨機分配到不同的分片里面的。



    有了這些分片,每個分片里面都有很多的節點,我們要怎樣進行交易處理呢?我們在這里也做了一個交易分片,就是用來處理不同的交易,不同交易會被分到不同的片里面。那么每筆交易是根據什么來分到不同片里面?我們做了一個簡單的分片處理,就是根據發送者的地址分片。那樣的話,如果A把錢發給B和C,那么這兩個交易應該是在同一個分片里面處理的,這樣保證沒有雙重支付問題。


    如果A發給B和C,但是你把A發給C的交易分到另一個分片里面,這個分片里面的節點,會很容易檢測出來,然后把這筆交易拒絕掉。通過這種很簡單的方式,我們達到一個交易分片的效果。因此你在不同分片里可以處理不同的交易,之后可以在每個分片里面,驗證你的交易是否是正確的。驗證過程很簡單,例如A發給B了10塊錢,分片會檢查A的余額是否是足夠的,如果A發給B了10塊錢然后A又發給C了10塊錢,那么分片就檢查有沒有雙重支付的問題。



    在每個分片內,每個節點都會進行這樣的一個對交易的處理,之后通過運行一個協議達成共識,最終附上自己的簽名,生成一個叫做MicroBlock的微小區塊,提交給目錄委員會,目錄委員會會運行另一個共識協議,從而形成了一個共識。最終生成一個區塊,并向不同的分片進行廣播。


    在這個過程中,每一個節點都可以收到最終的區塊,這個區塊的內容是很小的。同時,不同區塊之間也會進行交換數據,從而分享最終區塊內的這些交易。整個系統有三層結構:


    • 第一層,是哈希的哈希;

    • 第二層,交易的哈希;

    • 第三層,真正的交易內容。


    通過這種三層結構來保證整個系統在每一步進行廣播的時候,內容量都是相對比較小的。因此過了一段時間之后,你的不同分片里面,大家都可以獲得這一段時間以來交易處理之后的一個共同狀態。


    剛剛提到了,在每個分片里面,我們都會運行共識協議。那么我們是如何來保證每個分片里面,超過100個的節點能夠很有效而且安全地運行共識協議。這里我們用到了在2000年之前學術界很出名的容錯協議,叫做:實用拜占庭容錯協議——PBFT。


    這樣一個容錯協議可以保證在一個小范圍內,例如幾十個節點,或者上百個節點,大家同時運行這個協議,最終形成一個共識。共識就是A發給B了多少錢,C發給D了多少錢,大家有這樣一個共識之后,就可以去完成剛剛提到的協議。


    我們還用了一個叫做「集體簽名」,或「多重簽名」的方案,從而減少拜占庭協議里對不同節點簽名的要求。因為如果有600或者800個節點,都對同一個信息進行簽名的話,就會有600、800這么多的簽名數據,這個數據是很大的。所以我們用多重簽名來減少集體簽名數據量的大小。


    最終通過結合PBFT和集體簽名,我們實現了所要求的安全、高效的共識協議。在共識協議部分,如果大家只是把它當做一個黑盒的話,其實我們還有很多種選擇的。


    第一種,像比特幣或者以太坊里面的共識協議,學術界把它叫做Nakamoto Consensus,用中文講就是「中本聰協議」。可能有時候大家會把這個協議理解為只能做工作量證明,這種理解其實是不完整的。比特幣的共識協議其實分兩部分:第一部分,大家都在做工作量證明,過了十分鐘,會有一個成功獲得結果的人,他會生成一個新的區塊。


    這樣是不夠達成一個共識的,因為你之后還要再繼續做工作量證明,在后面,要生成超過6個的確認區塊,才能保證你在第一個區塊里面那些交易被整個網絡接收。所以比特幣的共識協議分兩部分,第一部分是工作量證明,第二部分還要有超過6個確認區塊,才能保證你的共識結果是有效的。


    但問題是這樣的共識協議消耗的時間是很大的,例如在比特幣里面,一個共識中運行一輪工作量證明要花費10分鐘,再加上6個確認的區塊時間,超過1個小時。那么你整體算下來,有可能會超過一個半小時才能確認你的交易。這樣就導致比特幣的吞吐量低,同時時間消耗高。


     

    我們是否有其他選擇呢?在學術界,只要使用PBFT或者類似的共識協議就可以相對高效地去實現多個節點之間的共識。舉個例子,在一個房間里,A要給B發10塊錢,A要給C發20塊錢,B要給D發50塊錢,那么我們這個屋子要形成一個共識,最終有哪些交易要加入到區塊鏈里面?可能初期的話,會有一個領導者把大家的建議都收集起來,然后再分發給每一個人,說我現在收集到這么多交易,大家就跟隨我把這些交易收集起來加入到區塊鏈里面。這樣每個節點都會收到一個請求,對于節點該如何決策呢?我作為一個節點,我怎么確定其他人也收到同樣一個請求,或者同樣一個區塊呢?


    那我就全網廣播我收到的信息,廣播給所有人,其他人也會廣播給我。這樣通過預準備,達到了初步共識的效果,即每個人都確定我收到這樣一個區塊,或者對應一系列的交易。最終再通過這樣一個廣播,來保證我知道超過三分之二的人也收到同樣一個區塊,或者同樣一系列的交易信息。這樣才能保證整個網絡里面,大家都在同一個狀態下面,每個人都知道,所有人收到了同樣一個區塊,大家可以繼續往下一步走了。

     


    這個共識協議很高效,運行幾十個節點達成一個共識,大概只需要幾十秒的時間。同時也很節能,不用做工作量證明。你的電腦不用無時無刻都在做哈希運算才能獲得最終性。我們都知道,在下一個區塊里面,這些交易是會被加進去的。


    但是有一個問題,這中間有好多輪的廣播。我收到交易之后,要廣播給大家,大家也要廣播給我,這樣的話,信息的交換量是很大的,導致整個網絡的擁塞程度是很高的。如果我們只用一個簡單的數字簽名來做,比如你把你的信息發給我,其他人廣播也把他們的信息發給我,同時附上他們的簽名。這樣的話,如果600個人用傳統數字簽名,可能就會產生600條數字簽名信息。這會導致整個網絡非常擁塞,網絡會很慢。所以我們之后就采用了多重簽名技術。這個技術不算是新的密碼學技術。好處就是可以把600個簽名壓縮成一個簽名,大家可以想象,如果之前廣播600個簽名,現在換成一個簽名,整個網絡的擁塞程度會減輕很多。通過使用多重簽名,整個網絡的消息規模會減少,同時溝通成本會降低。




    做一個簡要的總結,就是每一個分片首先收到了多條交易,接著會運行拜占庭容錯協議,大家先達成一個共識,有哪些交易要被寫到區塊里面。之后因為要記錄下來,我們整個屋子N個人都同意把N個交易寫在區塊鏈上,我們就會采用多重簽名,從而減少簽名的大小,使得整個協議消耗比較小。



    智能合約

     

    當我們知道了分片技術帶來的好處,以及分片技術給整個系統帶來的高吞吐量之后,相當于我們有了一條高速跑道,還應該有一個相對安全,同時可以支撐高速性能的一輛跑車。所以我們就要開發對應的智能合約。

     

    對于已有的智能合約,大家如果作為開發者可能都知道以太坊上的Solidity,在過去的兩年里,以太坊上面的智能合約遇到了很多的漏洞和攻擊。例如兩年前,其中的The DAO漏洞導致價值6000萬美金的以太坊被盜,去年Parity多重簽名錢包的漏洞,導致超過3億美金的帳戶被凍結。


    究其原因的話,首先是因為智能合約是一個很年輕,同時也是很復雜的編程框架。很多程序員寫的一些邏輯,復雜性是很難想象的。我們知道編程時很多時候我們都是隨著邏輯寫代碼,但是問題是我們寫出來的代碼,可能會有很多的不可預知性,比如那些邊邊角角的漏洞。還有就是目前的智能合約,沒有一個形式化證明。在學術界現在有很多語言,它們都是支持形式化證明。形式化證明的意思很簡單,就是我寫出來了一系列的代碼,我可以保證我寫的代碼就是我想要的邏輯,沒有越出我想要的邏輯的框架



    基于這些原因,我們團隊設計開發了一個基于自動機的智能合約語言,叫做SCILLA。



    對于一個程序,例如開關燈的操作,你可以有不同的狀態,例如關閉、暗光、明亮,同時你也有很多行為來去觸發使一個狀態跳到另一個狀態。例如短按一下、按一秒、以及長按。如果你在關閉狀態,簡單地按一下,就會切換到暗光狀態,再按一下,切換到明亮狀態。在智能合約里面,你可以很清楚地把這些狀態互相進行切換的行為定義清楚。


    這樣我們就可以提供一個形式化的證明。同時對于程序員來說,也可以很清晰地得出自己想要執行的邏輯。目前SCILLA是非圖靈完備的。之所以我強調非圖靈完備,是因為我們發現像以太坊的Solidity,雖然是圖靈完備的,但有時候是不需要的。你如果寫以太坊智能合約,應該知道它的燃料限制,因此很多時候智能合約是不需要做無限循環的,同時燃料的限制也支持不了無限循環。雖然支持圖靈完備,但更多的時候對于程序來說,非圖靈完備可以保證一個更加安全的邏輯執行,而且非圖靈完備其實大多時候也可以實現很多你想要的功能。



    上圖是一個SCILLA提供的眾籌智能合約。大家可以看到,類似于以太坊上智能合約的這些不可變參數,以及可變的狀態。不同于智能合約里面,我們這里用的是一個狀態轉換來實現每個人要貢獻多少錢,以及退款是如何進行的。


    下圖是模擬的一個兩年前的攻擊,大家可以看到,智能公約要進行一個退款行為。最開始智能合約會檢查發起人當時有沒有給我打錢。如果給我打錢了,我在退款的時候就會按同樣的數目退款給你,最終把智能合約針對投資人部分,設置為0。但問題是在攻擊的時候,不是最終直接把這個狀態設置為0,而是在最終設置為0。中間的部分,進行了一個跨智能合約的調用。結果是,如果智能合約碰到一個惡意的程序可以退回重來,再執行一遍這部分邏輯。這部分邏輯就會導致這個投資人的錢數,可以循環地進行增加。例如你運行一次代碼,可以使得投資人的錢數增加一倍,反過來惡意的程序再運行回來,進行一個回調,又可以使得把投資人的錢數再增加一倍。這樣無限地運行下去,導致他損失了超過6000萬美元。


     

    那么我們如何去做安全補救?很簡單,如果程序員小心一點的話,可以去遵循這樣一個模式。先去檢查這個投資人是否當初投資了我,之后進行執行:如果你投資了我,我先把你這部分的數目在我這里設置為0(反正我后面要轉帳的),之后再進行交互。交互時把那部分錢轉帳給之前的投資人。


    說起來很簡單,但很多時候,作為程序員,我們可能會忽略掉這些安全檢查。在SCILLA這里,我們可以用自己的編譯器,做一個自動的檢查。就是你如果在寫類似代碼的時候,必須要符合安全規范。就像剛才說的,先去檢查,然后再去進行交互。如果你不遵循這個規范的話,我們的編譯器是不會通過的,或者會給你提供一些對應的提示。



     去中心化應用的落地場景


    未來的話,因為我們有了這樣一個相對高吞吐量的區塊鏈平臺系統,共享經濟,例如OfO、Uber,這樣的共享經濟公司都可以將主要的業務邏輯放在區塊鏈上,運用智能合約來處理不同的用戶請求。目前大家都是通過一個服務器來進行這種中心化交易,但之后如果用區塊鏈進行去中心化的交易,就可以省去很多中間的費用,以及中間的一些可能比較灰色的花銷。當然區塊鏈也可以用作支付網絡,支付網絡目前的痛點就是手續費很高,但是如果能實現高吞吐量,大家可以用相對低廉的手續費去做一些支付。



    另一個方面,因為有了分片技術,我們之后可以做一些分片的并行計算,即類似于MapReduce的一些計算。包括深度學習,在不同分片里面,可以放不同的神經元(neuron)來進行科學計算。我們目前還是在做更多的測試,以及其他功能例如智能合約的開發。在上個月,我們已經放出了我們的測試網絡,以及數字錢包。

      

    大家可以通過https://explorer.zilliqa.com,去訪問Zilliqa的測試網絡。目前我們在其中加入了很多自己的交易,對這個網絡進行壓力測試。錢包的話,你可以通過https://wallet.zilliqa.com去訪問,來生成自己的帳戶,之后我們還會將一些測試代幣放到你錢包里,你可以在我們的測試網絡中進行一些簡單的測試,包括對交易的測試。

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