性能趕超EOS？一文帶你深挖並發執行模型
公鏈性能一直是行業關注的重點，如DAG的強一致性，sharding的技術可行性，超級節點的中心化問題等等。對於這些問題的解決方案都在試圖通過改變區塊鏈共識結構的方式提升性能，適用性不高，安全性也有待證明。
8月11日，在以「公鏈的應用挑戰與機遇」為主題的CSDN區塊鏈技術沙龍中，星雲鏈首席研發&星雲鏈技術白皮書主編尚書為我們分享了一個性能提升方向的探索成果——並發執行模型，有效地在8核16G的機器上實現了2000TPS的最大並發，且還可以根據需求做橫向擴展。
作為開發者或者投資者，你對公鏈真正了解多少？本文將帶你去偽存真，從多維度認知主流公鏈。
尚書，星雲鏈技術白皮書主編，星雲鏈首席研發，和團隊一起從零自主研發星雲鏈v1.0，3個月時間完成測試網上線，共6個月完成主網上線，並在2個月內在主網上支撐了7000+DApp的研發和運行，單日最高交易量達百萬，未出現過一起安全事故。曾全程參與海豚瀏覽器高並發手游伺服器重構，完成單機性能十倍增長。曾任TOTFREE CTO，設計並實現跨國免稅業務產品矩陣。清華大學計算機系碩士。
以下內容為尚書現場分享實錄，由區塊鏈大本營整理髮布。
責編 | 韓依依
正文：
我們今天的主題是關於公鏈性能的提升。接下來我將會講一個我們星雲鏈研發團隊獨創的並發執行模型。
今天的分享內容一共有以下五個部分：
一、如何評估公鏈性能
二、前提條件
三、並發執行模型
四、性能評測
五、未來發展方向
一、如何評估公鏈性能
TPS(Transaction per Second)，指的是每秒交易數量。一般來說，一個區塊鏈每秒鐘能打包的交易數量就是TPS，但這樣評估並不完全準確。因為在區塊鏈的結構裡面，是一個區塊一個區塊產生的，每個區塊從產生到傳播到公網之間，存在網路延遲，下一個人拿到這一區塊的時候，才能生成下一個區塊。
所以中間除了打包這個過程外，還有一些其他的操作。打包的時間並不等同於TPS，而是比如說有1萬個交易發送上鏈，直到最後一個交易上鏈，這中間有個時間窗口。用N除以這個時間窗口，得到的TPS才是準確的。
再嚴格一點說，我們在錢包裡面做交易的時候，會出現什麼場景？
這裡我們首先要知道一個概念：51%攻擊。它指的是有人掌握了全網50%以上算力之後，用這些算力來重新計算已經確認過的區塊，使其產生分叉並且獲得利益的行為。
比如說我們有一條10個區塊的主鏈，但有另一個算力更強的人，他悄悄在世界上一個隱秘的地方挖了20個區塊出來。這時，大家在公網上面看到的只有10個區塊，這10個區塊交易完之後，你的賬戶應當有10塊錢，但是在它挖的20個區塊的公鏈上面，你可能只有5塊錢。又因為最長的鏈是主鏈，一旦他把20個區塊釋放到公網上，這條長鏈就變成了主鏈。實際上在公鏈上的10個區塊裡面，記錄的所有的數據都被回滾掉了。
你在以太上面做完交易，imToken會告訴你需要等12個區塊的確認。這個確認是什麼意思呢？當一個區塊產生了之後，並沒有人可以保證這個區塊會永遠被寫在整個區塊鏈的主鏈上面，它有可能變成一條側鏈。
這裡存在著巨大的風險，比如說在交易所里像OTC這種業務，你給交易所10萬塊錢，拿到了1萬個Token。但可能過一段時間，交易所之前驗證的那個區塊被回滾了，這個時候實際上你手上並沒有那些Token。這樣也就導致你原來花的10萬塊錢買的Token消失了，沒有任何人能幫你找的回來。
因此，所有的交易所錢包都需要一個確認的過程。交易完成後，一定要等到多少個區塊確認之後，交易所和錢包認為你這個交易所在的那個主鏈，很難被回滾了——當然只是說很難被回滾，並不是說不可能被回滾，比如說它有90%的概率不可能被回滾了，交易所也同意承擔這10%的風險，通知你轉賬成功。這裡就存在一個確認的時間。
從更嚴格的角度來講，我們發了一萬個交易到鏈上去，理論上只有這一萬個交易全部確認之後，我們才說這一萬個交易真正上鏈了，這個TPS才是我們最真實的TPS。那麼，我們要怎樣來衡量這個確認的概念呢？
1.PoW
2年前我們的公鏈有比特幣，有以太坊。這兩條公鏈所採用的共識演算法叫做PoW。這就相當於大家一起來解一個智力遊戲，比如說猜數字，誰最先猜出來了，誰擁有記賬的權力。大家都在拼算力，隨著整個網路算力的提升，題目的難度也在不斷加大。
比特幣設計了一個演算法，保證平均每10分鐘出一個區塊。隨著網路算力提升，它也會不斷調整遊戲的難度，以保證每10分鐘出一個區塊。通過對安全性做計算，它認為每10分鐘出現一個區塊，並且，當有6個區塊出現時，在將近一個小時的時間窗口裡面，不可能再有另外一個挖出了7個區塊的大礦場，能夠把這6個區塊一次性全部給回滾掉。
所以說，我們所謂的確認狀態，不是100%的確認，只是一個大概率確認狀態。
雖然比特幣說它是6個區塊確認，但是可能在交易所裡面你需要等到12個確認，或者20個確認，才把那個賬目真正打到你的賬戶裡面去，因為交易所也怕風險。
以太的方案在比特幣之上做了一個擴展。因為比特幣10分鐘才有一筆交易，這對於所有的交易場景來說，基本是不可用的，除非是非常大額的交易，願意等這10分鐘。比特幣的策略是上一個區塊出完之後，緊跟著出來下一個區塊，這是一個比拼算力的過程。
以太引入了一個新的概念。在同一個高度上，比如說上一個區塊鏈已經出完了，接下來該出高度為11的區塊了，這時可能在整個網路裡面，有100個人在一個很短的時間窗口裡同時挖出了第11個區塊。但只有一個最終能夠鏈到我們主鏈上來，所以有10個是作廢的。
這10個被作廢掉的區塊當然是有價值的，因為它也消耗了算力。以太的方案是把這10個區塊的算力，也加入到整個主鏈狀態評估過程中，就可以在一個更短的時間內確認。因為在那個很短的時間窗口裡，全網貢獻的算力跟比特幣在一個區塊上貢獻的算力差不多，通過這種方式它也能夠達到跟比特幣相當的一個安全指標。以太這樣做的轉賬速度差不多在15-20秒一個區塊，它需要等12個區塊。
而在火幣上面，大約要等到28個區塊才會確認。因為火幣也怕承擔風險。到了12個區塊也並不能說100%能夠確認，它還有概率會被回滾掉。一旦回滾，火幣平台就需要擔負極大的資產損失責任，所以它在這個地方會等得更久。
這就是在最早一代的公鏈項目里，我們確認狀態的現狀。它是一個概率，不是100%。
2. DPoS
到了下一代，我們現在看的EOS，包括我們星雲1.0所用的共識，就是DPoS。
DPoS的方案是怎樣的呢？比如說我們有21個人在參與挖礦，一起編製了一條主鏈。在這條主鏈里我挖了一個礦之後，剩下的人在輪流挖礦的過程中，如果有14個不一樣的人在我挖的這個區塊後面出了區塊，就證明他認可我這個區塊，可以認為他給我投了一票。一個區塊如果拿到了2/3+1的票，也就是21個人裡面15個人的票，包括我自己，那麼這個區塊就能夠得到確認。這其中有一個巨大的假設條件——整個網路裡面，這21個人裡面，不會超過7個人及以上是壞人，所以我們能幹這個事情。
但是這個裡面依舊會存在一個場景：這21個人裡頭，如果有7個作惡節點，他有可能在這邊挖了一個區塊，在另外一條隱藏的側鏈上面也挖一個區塊，然後再賄賂另外的8個人，也就是一共搞到15個人，在另外一條側鏈上挖出一個更長的區塊。等到哪天符合他的利益，比如說他在主鏈上已經花了1個億，但是在側鏈上那1個億還在的時候，他們把隱藏的那條側鏈公開給全網，全網在舊鏈上的所有數據全部被擦除掉，他們手上就重新得到了1個億。也就是說，這少部分的15個人剝奪了所有人的利益。這樣理論上來講，也是不安全的。
當然現在大家對這個事情沒有那麼關注，大家還是相信那21個人，那21個人也是公開自己身份的。如果他們真的幹了這個事情，可能會被人追殺，但是你也不知道他們會不會幹。如果他能掙100億美金，他也是有可能會幹的，對吧？
這個就是第二階段，大家對如何確認的一個看法。
3. PoS變種
到了第三個階段，就是現在以太在提的Casper，然後我們提了一個Proof of Devotion。在我們這裡，要保證的是做到100%確認。也就是如果公鏈告訴你，這個區塊被確認了，那它一定是100%被確認了。這裡引入了一個新的機制在於，所有要進來挖礦的人，需要先交一筆押金，你如果在這裡面做了惡，你的押金會被扣。這就有一個可控的變數，你要是作惡到了極限，那就把所有人的押金全部扣完。
我們設計的方案是，即使所有人的押金全部扣完，你也沒有辦法把我們之前確認過的區塊給回滾掉。從而保證我們一旦確認，就是100%的確認，因為在我們的體制下面，你已經沒有足夠的資金去回滾區塊。這個就是第三代Casper和我們提的Proof of Devotion要做的事情，也就是確認的狀態。這兩個演算法都設計出來了，但還是在驗證階段。
這就是在一個公鏈上面交易確認狀態的三個發展方向。
二、前提條件
公鏈畢竟是公鏈，我們有一個不可能的三角，就像我們原來分散式的Cap一樣，在公鏈里也有一個不可能的三角——安全性、去中心化、性能。在現有的條件下，三者只能選二，然後等到整個大環境，包括硬體條件、軟體條件、網路環境等全部上來之後，剩下的那一個指標，才能隨著大環境而提升。而安全性和去中心化，在這裡面扮演的是很重要的角色。所以，在提升公鏈性能的時候是有一些假設、一些條件在前面的，這些條件從理論上來講是不應該逾越的。
在這裡，我們可以操作的事情有哪些呢？共識這裡出現了一個新的變種DAG，它不是區塊鏈，在它的場景裡面已經沒有區塊的概念了，而是所有的交易在整個網路中織成一張大網來做到一致性。但這個方案現在要想做到強一致，還是存在一些問題的，所以我們現在還只是關注區塊鏈項目，是有區塊概念的。
在這個大環境下面，每一個區塊在挖的過程中，必須要經歷三個階段。
第一是打包時間。一個礦工從網路中收集到了很多交易，要把這些交易打包成一個區塊。打包結束之後，算好最終狀態變化的情況，就可以把所有的數據廣播到全網去。這裡面就有一個打包的時間。
除此之外，還有一個網路延遲。它不像EOS，公網是所有的礦工網路直連的，相當於是一個小的區域網。正經的說，我們要保證去中心化場景時，我們一定是要在公網環境的，這就不可避免會存在網路延遲。
那麼對方（另外一個礦工）收到區塊之後，他需要去驗證一下你算的所有的數據是不是對的，你如果算不對，那我在你的後面出塊的話，相當於所有的數據都錯了。所以收到的礦工一定還有一個驗證時間。這樣來看，一個區塊必然有這三個時間，這三個時間裡面，又很詭異的有一個現象，就是我們在一個特定的演算法裡面，驗證時間是可以遠小於計算時間的。
舉個例子，比如說排序，我們現在來看，最快的排序也是O(NlogN)的，但在特定場景裡面，我們要想驗證一個排序實際上是很快的，只需要判斷是從大到小或者從小到大一個排序的過程就可以了，這就是O(N)的時間複雜度。
在一個特定的演算法裡面，我們演算法執行的時間，實際上遠遠大於演算法驗證的時間。這是一個很好的現象，如果真的可以做到這一點的話，我們的打包時間會遠遠大於驗證時間。但我們是一個通用公鏈，並不知道用戶會在我們鏈上寫什麼演算法。我們不知道他們什麼時候會做什麼樣的事情，也就不知道該怎麼去驗證它算的對不對。
因此，在這樣一個尷尬的場景裡面，我們的打包時間跟驗證時間實際上是一樣的，因為我們必須重走一遍它的邏輯。這樣來看，我們只能盡量把這兩個時間都縮小，把網路延遲時間縮小。
根據網路延遲，實際上就是要減少網路包的大小。我們可以從兩個方向著手。
一個是序列化。我們能不能找到一個更好的序列化的方案，把我們的數據全部變成一個更好的序列化結構，變成二進位流發出去？這個裡面我們使用了Protocol Buffer，以太用了它自己設計的一個RLP。
其實RLP的性能會比Protocol Buffer要好，但RLP演算法本身的擴展性非常差，我們在設計整個區塊鏈的過程中，不能保證未來會發生什麼變化——我們未來的核心協議網路包的結構會不會產生變化，會不會添加一些新的欄位，會不會改一些欄位，這些都是我們不知道的，所以我們必須保留這個擴展性。從這個角度來說，Protocol Buffer比RLP要靈活的多。因此，我們選擇了一個性能稍微更差一點的Protocol Buffer，但是它的擴展性更好。
第二是數據壓縮。我們做完序列化之後，要打包成網路包，發到網路裡面去。這裡我們一定要做一個壓縮，我們現在用的是Google Snappy。這個演算法能夠幫助我們完成50%的壓縮率，對整個網路延遲的貢獻度實際上是相當高的。
三、並發執行模型
接下來我們要考慮的事情就是怎麼把打包時間和驗證時間進行縮短。這就是我們今天要講的重點。我們首創的並發執行模型是什麼樣的，為什麼這樣設計，它為什麼可以提升公鏈的性能，又是如何縮短設計的並行執行模型時間的。
我們可以直觀地感受到所有交易被提交到區塊鏈上時，礦工打包的過程和它驗證的過程可以理解為一個有限狀態機，區塊鏈可以理解為一個狀態的集合。它有很多狀態，所有交易到我們區塊鏈公網上來之後，實際上我們狀態的集合會發生遷移，它從某一個狀態變到下一個狀態。它就是一個有限狀態機。
在傳統的場景下面，這個狀態機是什麼樣的呢？所有的交易被提交到公網上來了之後，他們對狀態遷移的過程是一個交易執行的過程。一個交易執行完了之後，它遷移到下一個狀態，我們再基於這個狀態再接進來一個交易，再跳到下一個狀態，所以，就變成了一個串列的確定有限狀態機。
那麼我們能不能把交易的執行過程，這個串列的狀態機變成一個並行的——你提交上來10個交易，我能不能把這10個交易同時執行，最終合併到同一個狀態集合裡面去，這種情況能不能實現？
問題重重
我們上來就遇到了這樣三個問題。
第一個問題：
當我們把狀態的遷移過程從串列變成並行之後，會不會每次執行的結果不一樣？這一過程是否為確定有限狀態機？
第二個問題：
假設我們可以把所有的狀態做成並行的。那麼要將多個交易並行後得到的狀態集合融合，這一過程中會不會產生衝突？產生衝突了怎麼辦？有沒有辦法互不衝突？
第三個問題：
在傳統的MySQL里有個讀寫鎖，只要讀寫不衝突就好了。但在我們並行執行過程中是否存在一個更強的邏輯？我們是否需要事務隔離？如果不需要，我們能否讓它變成一個更加並行的狀態？
在第一個問題里，它變成並行化之後，還是不是確定的狀態機呢？很不幸它不是。這個問題非常棘手，我們可以通過一個實際例子來說明。比如說我們在初始狀態下，A和B有兩個賬戶，A有1 NAS，B和C都沒有NAS，那我們現在要挖一個區塊，這個區塊裡面我們收到了2筆交易。
第一種情況是A到B轉賬執行完後，B到C再轉賬，這個時候的結果就是A和B都沒有NAS了，C有一個NAS。
第二種情況是B和C可能先執行了，A和B再執行，但是B到C執行的過程中，它們之間轉移一個NAS是不成功的，所以這一交易失敗，A向B則會轉移成功。最後的結果是A和C沒有NAS，B有一個NAS。顯然，我們把它並行化之後，如果這個順序被打散了，最終的結果也就不一致了。
在第二個問題里，我們能不能讓兩個交易並發執行，在最終做狀態合併的時候互不衝突？這其實也很難做到。我們有一個很直觀的感覺，比如說A到B我們收到了一個區塊，裡面有三個交易，A到B、B到C和D到E。
這樣看來，感覺「A到B」和「B到C」是相互關聯的，因為它們共享了一個地址B，而D到E似乎跟這兩個交易沒有太多的關係，是兩波不一樣的人。
那我們能不能由此把它分成兩個部分，讓A到B，B到C串列執行，D到E跟他們並行執行呢？這個想像很美好，但是實際上不是這樣子的。比特幣上可以這樣干，但是所有基於以太的、通用的智能合約結構，這樣都做不了。
A到B這一筆交易，它有可能不是一個普遍的轉賬，並不只是單純的NAS轉移。B可能是一個合約——這又是一個致命的問題：A到B轉賬可能會調用某一個合約，在這個合約的邏輯里，可能其中的某一條指令要從合約把一筆錢轉到另一個賬戶上去，那個賬戶有可能是D，有可能是E。
我們根本不知道用戶會在他的合約裡面存什麼樣的地址，結果我們想當然地把AB、BC、DE做分割，但是可能就踩到雷了，A到B實際上是影響D到E的，這些事情在早期其實是沒有辦法預判的。所以說，我們想做到互不衝突也非常困難。
第三個問題，我們是否需要做事務隔離？
顯然，我們不能允許1、2兩個中間，互相操作相同的數據，如果操作相同數據——我舉個例子，比如在2裡面它先讀了X=0，在2執行的過程中，1執行結束了，它把X設為了1，那2還在同一個交易裡面再去讀X的時候，又變成了1，實際上這個場景是不可能出現的。2在執行過程中，要麼X全程都是1，要麼X全都是0，不可能出現先讀到0，再讀到1。
所以，場景裡面一定要做事務隔離。
解決思路
那麼要解決這三個問題，我們能幹些什麼？
關於第一個問題，我們從一個確定的狀態變成一個非確定的，我們需要去關注交易和交易之間的依賴關係。存在依賴關係的交易，是一定存在先後執行順序的，比如我們常說的拓撲排序結構。所以，除了打包過程要記錄它的依賴關係以外，我們在驗證的時候，還要根據所記錄的依賴關係做最終驗證。
這裡我們需要做兩個事情。如果我們要記錄依賴關係的話，相當於有兩個交易，第一個交易做完，它所有狀態修改的集合，我們是需要保存的，不然再做第二個交易的時候，都不知道它改過什麼，也沒辦法去判斷依賴關係。也就是說，我們就需要保存所有的交易執行之後的狀態集合。另外，我們要提供機制，能夠查詢兩個修改後的集合之間的精確依賴關係，這個存儲其實也是要很大開銷的。
第二個問題，我們能不能做到互不衝突？極難做到，因為我們完全不知道用戶在他的合約裡面放了什麼數據，也極難追蹤。我們只能盡量使兩個交易互不衝突，因為我們有一個基礎的預判，from和to只要互不重疊，衝突的概率就會相對小一點。
我們有一個調動模型，但最終還要有一個東西來保證它們真的互不衝突。所以兩個修改後的狀態集合產生了之後，我們要去看這個集合裡面都修改過什麼？增刪查改4個操作他們都做過什麼？對同一個數據做的增刪查改，哪種場景下是衝突的，哪種是不衝突的？我們需要定義這個衝突模式。
與此同時，我們也需要保存所有修改後集合的狀態，因為我們最終需要去判斷兩個集合是否相互衝突，和第一個問題一樣，我們需要一大筆存儲的開銷。
到了第三個問題，我們要做事務隔離。比如交易1執行之前的狀態是0，交易2在執行之前狀態也是0，1和2可能並行執行。這一過程中，可能都會對0那個狀態的數據做修改，但他們一旦修改做了重疊之後影響了其他交易的執行，這就不是事務隔離。所以我們還要保證一點：1和2在做執行的過程中，他們所依賴的前提的狀態都是0，相當於把0的狀態拷貝兩份，給他們各自一份作為初始條件。
除了要把所有交易的修改集合保存以外，我們還要把所有的交易最開始依賴的初始條件保存，這樣看的話，又是一大堆東西要存，而且這個場景是事務隔離，這個交易可能會失敗，需要讓它回滾。所以演算法複雜度也提高了，我的存儲複雜度也提高了。
解決方案
為了解決這幾個問題，我們做了三個事情：
第一，我們把所有的狀態統一到一起。原來的狀態是分散的，我們不知道如何判斷不同狀態之間的衝突關係和依賴關係。所以我們在這邊做了一個叫World State的工具，把所有的狀態都統計、管理起來。你在增刪查改任何東西之前，可以通過它來判斷衝突、查看狀態。
World State只是一個管理工具，那數據存在哪呢？我們還要存所有的交易修改之後的狀態、和所有交易執行前的狀態。而且在這個過程中，我們還得去判斷它的依賴關係、衝突關係，實際上是要把每一份都拷貝一份，這個事情非常好解決。但實際上是不可行的，比如說TPS要上萬，相當於是一秒鐘以內要複製1萬份；要上百萬，就要複製上百萬份…相當於是TPS越高，要的存儲就越高，哪幾台機器能夠扛得住這麼大的存儲呢？
所以第二件事是，我們設計了一個結構來簡化這個存儲，這個名字叫做「支持嵌套事務的多版本控制並發資料庫（MVCC DB）」，這個結構在我們的代碼裡面已經開源了，大家如果感興趣可以看一下裡面更多的細節。
第三個，我們剛剛說它變成一個非確定性狀態機，要根據依賴關係來構建結構。它實際上是個拓撲圖，會隨著網路傳播到下一個驗證者那裡，那個驗證者會根據它的拓撲排序結構做一個調度，哪些交易可並行執行，哪些交易必須等到上一個交易執行完之後才能做，這裡就要有一個拓撲圖的執行引擎，來保障我們最終完成的一致性。
四、性能評測
這是我們整個模型在公鏈上跑出來的測試數據。我們可以看一下這樣的結構給我們的性能帶來了哪些變化。
我們的機器是i7，四核，純智能合約的交易，在一秒內我們嘗試打包，我們可以看到下面分別是一個核、兩個核和四個核的狀態，這個數據實際上是線型增長的。
所以如果我們控制了更多的核，這個數據還會不斷往上漲，直到哪一天它遇到了IO瓶頸——就像右邊純轉賬交易測試數據看到的，我們也是一個核、兩個核、四個核在做，但是它達到一個高度之後，它就遇到了IO瓶頸，我本機的IO撐不住這麼多的場景了，這以後它增長的速度就開始放緩了。
我們現在本機是四核的，在線上跑的是八核的。線上8核情況下，合約交易和轉賬交易混合的場景下，我們最高測出了2000TPS。EOS單條鏈測的大約是1000-3000TPS，它的機器設備是128核的配置，網路是10GB/s直連，也就是說128核做到了1000-3000。實際上我們通過8核已經做到了，而且我們橫向擴展到128核的話，性能還會提升。從這個角度來說，我們的性能是會擴展得比它更好的。
當然我們現在只是一個模型結構的優化，沒有對IO做任何的優化，接下來我們實際上有一套IO的優化策略要去執行，那部分做完之後，我們的性能實際上會比EOS高的多得多。
這些是我們目前已經完成的工作。
五、未來發展方向
最後，我們來看一下現在的行業內部都在如何優化他們各自供應鏈的性能。
演算法優化
首先是一個縱向的優化。在所有的結構確定下來之後，你可以把你的演算法，把IO速度做優化。我們去選取交易做並發的時候，選取策略也可以做優化，包括我們在做網路傳輸的過程中，每一個交易的from和to實際上是很長的。但這個交易除了廣播到了我以外，也廣播到了所有其他的人。也就是說，其他人手上是有它的from和to地址的，那我在網路傳輸過程中，是否可以優化策略，就不用傳這些信息了。通過這樣的方式我們可以減少網路包大小，把網路延遲拉低，也能整體延長我們的TPS。
這是在已有框架內的優化方向，那麼如果你有條件改框架的話，你能做哪些事情呢？
提升CPU核數以提升性能，這實際上是一個橫向擴展的機制。
所有的挖礦節點，網路直連，就像EOS做的那樣，網路延遲速度幾乎可以忽略不計，這樣的話，TPS也高，所以它做到了0.5秒出塊。
以太V神提出的sharding。
這個sharding是什麼概念呢？以太現在是一條單鏈，他想通過多鏈結構來提升它的性能。在多鏈狀態里，並不是說你擁有一個錢包，你就可以在多鏈上自由買賣。你在A鏈上有100個ETH，你在B鏈上你沒有這100個ETH，你如果要用B鏈的服務，你首先需要把你的錢從A鏈轉到B鏈。
這樣看來，多鏈結構並沒有給大家帶來任何實質便利性，所以他提的sharding，我個人認為是一個偽命題。既然是這樣一個sharding模式的話，你為什麼要把所有人綁在你的多鏈裡面呢？你為什麼是一個側鏈的結構，而不是單獨的另外一條鏈，通過跨鏈協議的方式讓大家交互起來，最終就變成網路裡面上千萬條鏈，都是以太，但是這些鏈之間可以通過跨鏈協議彼此互連，數據共享。每一條線每天都能提供百萬TPS，對於任何一個單獨的廠商來說，是足夠使用的。所以我們覺得sharding是一個偽命題，跨鏈才是真命題。
最近比較火的Nervos。
他們提出一個方案，不要把計算放在公鏈的礦工節點去做計算，而是放在客戶端去做計算，你算完以後給我就好了。你在算的過程中，要把所有的依賴關係和衝突都算好，我這邊只做驗證。這個角度上來看的話，它把我們之前並行的結構通過另外一個方案，從一個非確定狀態機變成了一個確定狀態機。理論上可行，但是這裡面存在一個重大的問題在於，在客戶端完成計算，如何在服務端進行驗證？如何保證兩種運算的一致？
區塊鏈共識，這是清華的姚期智教授參與做的方案，將區塊變成一個DAG。
在某一個高度上，你可能挖出了10個區塊，這10個區塊並不是只有一個被網路接受，而是10個都被網路接受，這10個裡面包含的交易能夠有一個演算法達成最終一致性。
純DAG模式。
實際上，純DAG現在還面臨著眾多問題，每個人在自己的節點上看到的數據都不一樣，那你怎麼保證最終的一致性？每個時間窗口的強一致性？這些都是存在的問題。
大力戳 加入區塊鏈大本營讀者號群
TAG:區塊鏈大本營 |