文章來自王嘉平??
我的上一篇文章探究了單鏈公鏈系統(tǒng)在性能和容量上受限的本質原因。本來我以為文章過于「技術」，會遭到普通讀者的嫌棄超燃。完全出乎我意料的是，竟然有上萬的讀者通過各種渠道閱讀了這篇文章拘领，并且意乓，我收到了不少朋友和讀者的反饋。他們鼓勵我繼續(xù)寫下去约素，把我自己在分布式系統(tǒng)研究和區(qū)塊鏈投資領域的經驗和心得分享出來届良。
我非常感謝這些朋友，還有每一位讀者圣猎。但是我還是非常擔心士葫，我的文章有太多技術性語言和技術上的分析——比如今天這一篇。不過送悔，我會努力用最簡單的詞句慢显、最直白的語言，把區(qū)塊鏈領域看似很深奧的理論和方案欠啤，用淺顯易懂的方式介紹給大家荚藻。
通過上一篇文章「區(qū)塊鏈公鏈如何才能快起來?」，希望讀者可以從文中解釋的那些原因出發(fā)洁段，明白這樣一個結論：安全的共識機制本質上并不跟系統(tǒng)的吞吐性能以及容量相矛盾 鞋喇。在區(qū)塊鏈的系統(tǒng)里面，所謂的「不可能三角」——安全眉撵、去中心化、性能落塑，這三者只能取其二的說法纽疟，并沒有技術邏輯的論證，而只是對現(xiàn)有解決方案的觀察憾赁。
不過污朽，對于現(xiàn)有的單鏈系統(tǒng)，確實有一個不可逾越的物理限制龙考，那就是全節(jié)點平均帶寬蟆肆。以13Mbps的帶寬為例(這是互聯(lián)網(wǎng)帶寬中位數(shù), 4K電影在線播放帶寬下限要求為15Mbps)矾睦，無論基于什么共識技術，即使完全喪失去中心化炎功，并忽略傳送協(xié)議枚冗，以及層層封包等額外引入的代價，以比特幣網(wǎng)絡現(xiàn)在的每秒處理 7 筆交易的吞吐量來算蛇损，其吞吐量理論上限為6825TPS（7TPS × 13Mbps / 8Mb × 600s）赁温。否則就會出現(xiàn)部分全節(jié)點脫網(wǎng)，即長時間無法趕上全網(wǎng)的區(qū)塊增長淤齐，而離最新頭部塊越來越遠股囊。
我的上一篇已經提到，性能瓶頸和容量瓶頸在現(xiàn)在的結構下無法突破更啄，因為單個全節(jié)點的帶寬和存儲資源總是有限的稚疹，并且我們還不能要求部署全節(jié)點的機器都具備頂級的配置，因為只有保證了參與全網(wǎng)的壁壘較低祭务，才能真正具備有良好的去中心化特性内狗。從這個意義上來說，要獲得大幅度的伸縮性待牵，我們必須要能夠有一個合理的設計其屏，使的單個全節(jié)點僅僅負責整個網(wǎng)絡吞吐量和容量的一部分，這樣缨该，才有可能在維持全節(jié)點的負荷比較小的前提下偎行，使得全網(wǎng)的性能和容量有大幅提升。
分片(Sharding)技術就是針對這一思路提出的贰拿。分片最初是基于數(shù)據(jù)庫系統(tǒng)提出的蛤袒，泛指橫向切分數(shù)據(jù)庫服務器的負荷，用多個數(shù)據(jù)庫服務器平行服務的方式膨更，以提升整體的服務吞吐量和數(shù)據(jù)容量妙真。實際上，分片并不單指一種特定的技術荚守，而是一大類橫向切分系統(tǒng)負荷珍德，多實例并行，以提高整體性能和容量的技術矗漾。
不過锈候，分片這個提法在區(qū)塊鏈技術中過于寬泛。在這篇文章的最后部分敞贡，我會通過引入「異步共識組」這個概念泵琳，談談我認為什么會是區(qū)塊鏈中理想的分片方案。
在討論我認為的理想方案之前，我還是用我習慣的邏輯获列，先向讀者解釋為什么我們需要分片技術谷市、理想的分片技術究竟應該解決什么問題這些最基本的知識；然后击孩，我會根據(jù)自己看過的大量的分片方案迫悠，談談目前市面上已有的分片方案存在的五個誤區(qū)或謊言。
為什么需要分片：從全節(jié)點的負擔談起
在分析具體技術方案之前溯壶，先來看看一個全節(jié)點都有哪些負荷:
網(wǎng)絡帶寬及皂，這個部分同吞吐量(TPS)線性相關
1. 新區(qū)塊的廣播
全節(jié)點需要下載周期性出現(xiàn)的新區(qū)塊，并進一步上載給其他需要的節(jié)點且改。對于現(xiàn)在7TPS的比特幣區(qū)塊鏈來說验烧，平均下載帶寬消耗是13.6Kbps，完全不是負擔又跛。但是如果TPS提高到7000TPS碍拆，則至少需要13.6Mbps的下載帶寬才能承受——請注意，這個是關鍵數(shù)據(jù)慨蓝，并且有序感混，如果區(qū)塊數(shù)據(jù)得不到及時傳輸，區(qū)塊鏈將無法持續(xù)構造礼烈，并且無法重建全網(wǎng)的賬簿狀態(tài)弧满。
2. 未確認新交易的廣播
全節(jié)點需要持續(xù)發(fā)現(xiàn)，并下載尚未被確認的新交易此熬，然后上載給其他節(jié)點庭呜。在全網(wǎng)不擁堵的情況下，這個數(shù)據(jù)量和新區(qū)塊的數(shù)據(jù)量相當犀忱。相對的募谎，這個數(shù)據(jù)不需要保序，即使下載不全也不會直接導致全節(jié)點本身工作異常阴汇。但是数冬，如果這種情況大規(guī)模地發(fā)生，最終會導致部分交易始終沒有被礦工看到搀庶，而長時間不被確認拐纱，最終超時。
內存容量哥倔，這個部分同用戶量(address數(shù)量)以及智能合約數(shù)量線性相關
賬簿的存儲占據(jù)主要的內存消耗戳玫，其他部分的消耗不多，并且基本不會隨著網(wǎng)絡擴展而增加未斑。
區(qū)塊鏈的基本賬簿, 至少需要維護每個用戶(每個address)上的余額，每個用戶至少需要16 + 32個字節(jié)。對于支持智能合約的區(qū)塊鏈蜡秽，每個用戶至少需要額外32個字節(jié)記錄每個智能合約的代幣的余額府阀。智能合約自身還可以自定義更多的字段，可以占用遠超32字節(jié)的內容芽突。
當然试浙，并不是所有的用戶都參與了所有的智能合約，所以我們并不以用戶量和智能合約數(shù)量的乘積作為內存消耗的估量∧觯現(xiàn)實的情況是田巴，我們按照以太坊的現(xiàn)狀來估計，約 4500 萬個地址挟秤，至少占據(jù)了約3GB的內存壹哺。每個地址平均消耗了68個字節(jié)。這里并不是說以太坊有了4500 萬個用戶艘刚，通常而言管宵，一個用戶會擁有好多個地址。
磁盤 I/O攀甚，這個部分同吞吐量(TPS)線性相關
全節(jié)點收到區(qū)塊并確認成鏈之后箩朴，區(qū)塊會被寫入磁盤歸檔起來。這個部分的吞吐量大體和下載新區(qū)塊的帶寬一致秋度。
這里需要注意的是炸庞，按照以太坊的觀點(賬戶模型)，賬簿是指全網(wǎng)的某一時刻的全量狀態(tài)荚斯，而區(qū)塊(若干交易的集合)是對賬簿的增量修改信息埠居。在磁盤實際存儲的是區(qū)塊，而不是賬簿鲸拥。節(jié)點在啟動的時候拐格，需要重放所有已經記錄的區(qū)塊，以構造賬簿的最新狀態(tài)刑赶。截至目前捏浊，以太坊的全部歸檔區(qū)塊數(shù)據(jù)量已經超過160GB。這里的一個優(yōu)化是定期將賬簿全量快照也記錄下來(即checkpoint)撞叨，這樣只需要從最近的checkpoint開始重放就可以了金踪。
而UTXO模型是比特幣的觀點，這是一個非常有意思的結構牵敷，它的區(qū)塊既是若干交易的集合胡岔，同時也是部分賬簿的狀態(tài)，即特定地址上的余額枷餐。整條鏈上余額不為0的UTXO都是賬簿的最新狀態(tài)靶瘸。至今比特幣區(qū)塊鏈的全部歸檔區(qū)塊數(shù)據(jù)量已經超過220GB。不過從磁盤I/O的角度來看，重建全網(wǎng)賬簿還是需要掃描整條鏈找出全部余額不為0的UTXO怨咪，并沒有什么優(yōu)勢屋剑。當然checkpoint技術對UTXO一樣有效。
在這個領域诗眨，最近我看到了一些被熱炒的改進唉匾，尤其是在已確認交易集合的聚合表示方面。我注意到斯坦福大學的一個團隊最近提出匠楚，RSA累加器(RSA Accumulator)可以代替Merkle Tree巍膘，用來表示一個已確認交易的集合。這個想法的優(yōu)異之處在于芋簿，可以直接用一個交易的Hash值來校驗一個交易是否存在于已確認交易的集合峡懈，而Merkle Tree不僅需要一個交易的Hash，還需要從樹根到該交易沿途路徑上的所有兄弟節(jié)點上的Hash益咬。不過逮诲，這個做法的代價是，這個表示本身要1.5K字節(jié)幽告，Merkle Tree的根僅需要20或32個字節(jié)梅鹦。同時，這并不意味著全節(jié)點可以不再保存歷史交易冗锁，原因在于齐唆，首先集合的聚合表示是不具備枚舉的能力的，也就是說冻河，在交易未知的情況下箍邮，集合的聚合表示無法告訴你里面具體的交易是什么，所以你也無法判讀這個集合本身是不是正確的叨叙，所以全節(jié)點也無法僅憑這個信息確認鏈頭的正確性锭弊。全節(jié)點在自舉的時候還是需要從創(chuàng)始區(qū)塊(genesis block)開始下載，逐塊驗證全鏈的完整性和正確性擂错。但是味滞，當這個驗證過程完成之后，為了節(jié)省空間全節(jié)點钮呀，是可以刪除掉區(qū)塊中的實際交易內容的剑鞍，其代價是喪失枚舉交易的能力，同時也喪失了幫助其他全節(jié)點自舉的能力爽醋。
另外蚁署，通過驗證一個交易是否在鏈頭上，來確定賬戶余額的做法蚂四，僅對于UTXO交易模型有效光戈。對于以太網(wǎng)這樣每個交易僅為增量修改信息的交易模型哪痰，僅靠驗證一個交易是否在鏈頭上，是無法得知賬戶的余額的久妆。
CPU處理能力妒御，這個部分同吞吐量(TPS)線性相關
1. 密碼學相關計算
對于每一個收到的新區(qū)塊，無論最終時候成功成為鏈的一部分镇饺，全節(jié)點都需要驗證其攜帶的每一個交易是否被正確簽名。同時會驗算每個區(qū)塊的Hash送讲，以確保其達到了當前工作量證明（PoW）難度的要求奸笤。對于拜占庭容錯（BFT）算法，還需要驗證各個委員會成員的簽名是否正確哼鬓。這里主要的工作量是驗證簽名监右。驗證簽名在一臺普通計算機上(E5-1620@3.5GHz, C++并行實現(xiàn))的速度可達 40K op/s，也就是4萬TPS(每個交易需要驗簽一次)异希。
2. 交易驗證相關計算
對于每個交易健盒，如果是支付交易，將需要至少查找一次賬戶的索引結構(通常為哈希表)称簿，并做一次加法和大于的判斷扣癣；為了更新賬簿，還需要至少一次加法和減法憨降。這樣的一系列操作父虑，在一臺普通計算機上的速度可以輕松達到1M op/s。如果是智能合約授药，會需要在虛擬機中執(zhí)行對應的智能合約指令士嚎，對于現(xiàn)有的金融本質的應用(包括類似Cryptokittes類或Fomo3D類的區(qū)塊鏈游戲)，至少可以達到100K op/s悔叽。
這意味著什么莱衩？
針對上面的分析，我來做一個小結：對于一臺普通的計算機娇澎，擁有13Mbps的互聯(lián)網(wǎng)連接笨蚁，E5-1620@3.5GHz 4Core的CPU，16G內存九火，512G SSD 硬盤 (250MB/s)赚窃。網(wǎng)絡帶寬導致的TPS理論上限約為7千TPS，硬盤文件I/O導致的TPS理論上限為5萬TPS岔激，CPU處理能力導致的的TPS理論上限約為5萬TPS勒极。另外，內存大小導致的地址理論上限約為 2.5 億個地址虑鼎。
這里可以看到辱匿，對于性能來說键痛，網(wǎng)絡帶寬是最首要的瓶頸根源，其次是硬盤的I/O和CPU的處理能力匾七。對于容量來說絮短，內存是最主要的瓶頸根源。
分片應該做到什么昨忆？
從上面對瓶頸根源進行分析之后丁频，我們可以得到這樣的結論：特定的分片方案至少要切分系統(tǒng)的網(wǎng)絡帶寬、內存容量相關的工作量邑贴，才有可能大幅提高全網(wǎng)的伸縮性席里，才有可能打破所謂的「不可能三角」。必須再次強調拢驾，這個結論非常重要奖磁。因為只有真正了解這一點，才能進一步討論分片方案是否真的可以打破「不可能三角」繁疤。
雖然在前面的分析中咖为，帶寬和內存是短板，但實際上稠腊，其他部分的約束也并不富余躁染。理想的情況下，分片系統(tǒng)能夠切分上述四個方面所有的負擔麻养。對于一個有n個分片的系統(tǒng)褐啡，其每一個分片僅需要承載1/n的全網(wǎng)負荷，將網(wǎng)絡帶寬鳖昌、硬盤文件I/O备畦、CPU處理和內存容量的消耗都降到原來的1/n。在分布式系統(tǒng)中许昨，這個是高伸縮性能帶來的性能和容量提升的上界懂盐。一個分片系統(tǒng)如果可以實現(xiàn)這個，即性能和容量可能隨著分片個數(shù)n而線性提升糕档，那么理論上莉恼，可以使得全網(wǎng)的性能和容量能夠被無限地提升。
而現(xiàn)實情況是速那，分片系統(tǒng)為了實現(xiàn)應用邏輯的正確性俐银，協(xié)調各個分片之間的運作以及實現(xiàn)整體的安全性，需要每個全節(jié)點引入額外的工作量(overhead)端仰。這些額外的工作量是個常數(shù)O(1)捶惜，即和分片個數(shù)n無關，那么全網(wǎng)線性提升仍舊可以保證荔烧。
如果額外的工作量的階(order)小于線性吱七，例如O(logn)汽久，那么就意味著隨著n的增加，全網(wǎng)提升比額外工作量的增加要來得快踊餐，全網(wǎng)線性提升還是可以實現(xiàn)的景醇。但是，如果額外的工作量的階大于或等于線性吝岭，例如O(n?logn) 或 O(n^2)三痰，那么基本上全網(wǎng)提升到一定程度，就無法繼續(xù)了窜管。因為全節(jié)點額外引入的工作量成為了新的首要瓶頸酒觅。
跨分片交易的原子性保證
區(qū)塊鏈中的每一個交易都是原子的，必須保證其涉及到的操作或者全部完成微峰，或者一個都不開始，才能使得最終狀態(tài)是正確的抒钱。
對于涉及到多個分片的交易蜓肆，我們不得不協(xié)調發(fā)生在各個分片中的操作，保證它們都能被沒有錯誤地完成谋币，并且不受其他交易的干擾仗扬。這里看起來可以簡單借用在多線程編程中常用的線程同步概念，用諸如臨界區(qū)(critical section)等方式蕾额，鎖住涉及到的狀態(tài)早芭，阻止其他交易觸碰這些狀態(tài)，在完成交易所有操作后釋放诅蝶。但是退个，這會導致部分分片的執(zhí)行被阻塞，而導致實際性能大打折扣调炬。并且隨著全網(wǎng)規(guī)模擴大语盈，分片數(shù)量增多，跨分片交易的比例必然會極劇上升缰泡，從而使得加鎖變得非常頻繁刀荒。
一個設計良好的分片系統(tǒng)，必須具備高效的跨分片交易處理算法棘钞，并且算法的開銷應該和分片數(shù)量n無關缠借。
單個分片的安全性保證
分片系統(tǒng)中，如果每個分片有獨立工作的共識系統(tǒng)宜猜，也就是每個分片自己一條鏈泼返，全網(wǎng)能最大獲得的吞吐量的n倍提升。
共識系統(tǒng)的安全性依賴于出塊權力的大多數(shù)(majority)是可信的宝恶，這個大多數(shù)在PoW系統(tǒng)中為50%符隙，在BFT系統(tǒng)中為2/3趴捅，甚至更高。而當全網(wǎng)有n個獨立工作的共識系統(tǒng)時霹疫，這時平均分到每一個分片的大多數(shù)變會降低到原來的 1/n拱绑。這樣攻擊這些分片中的共識系統(tǒng)的壁壘，對于PoW系統(tǒng)會降低到全網(wǎng)的 50/n?% , 對于BFT系統(tǒng)則會降低到1/(3n)丽蝎。從而導致猎拨，僅需要非常低的成本，就可以攻擊某一個特定的分片屠阻，例如構造雙花攻擊(double spend)红省。而在一個分片系統(tǒng)中，只要有一個分片被攻擊国觉，其后果會藉由跨片交易迅速污染到其他的分片吧恃。
這就是為什么每一個分片系統(tǒng)都必須處理好安全問題，使得攻擊特定分片的代價同攻擊全網(wǎng)一樣高麻诀。
分片方案的一些誤區(qū)
?
分片的切分依據(jù)需要有足夠的顆粒度痕寓，這樣才能使得分片個數(shù)n取到足夠大的值，并且不容易產生單點過熱(hotspot)蝇闭。例如按照交易參與方的地址分呻率，或者按照交易本身的hash值來分。這些是可行的方案呻引，因為地址和交易的數(shù)量本身足夠的多礼仗。有些分片的方案按照業(yè)務來切分的，這是不可取的逻悠，顆粒度不夠細元践，并且如果單個業(yè)務活躍度很高，需要更高的性能和容量童谒，卻無法獲得分片系統(tǒng)所帶來的提升卢厂。
在全網(wǎng)分片結構不發(fā)生改變的前提下(例如 給定分片數(shù)量n)，分片的切分依據(jù)應該是確定的惠啄，和賬簿狀態(tài)無關的慎恒，并且是可以被簡單計算的。對于提交交易的輕量節(jié)點撵渡，可以根據(jù)交易內容唯一地確定這個交易應該被發(fā)送到對應的某個分片融柬。早期看到動態(tài)的調整地址歸屬，試圖將經常交互的地址劃分在同一個分片趋距，從來減少跨分片交易發(fā)生的概率粒氧。這種做法是不切實際的，因為本質上同分片數(shù)量相矛盾节腐。就以太坊ERC20的歷史支付交易來看外盯，在4個分片的時候摘盆，跨分片交易比例為75%，在32個分片的時候饱苟，跨分片交易比例為97% (按支付發(fā)起者的地址 , 平均隨機劃片)孩擂。
誤區(qū)二：鼓吹智能合約的計算復雜性
從前面的分析可以看到，CPU處理并不是短板箱熬。但是現(xiàn)實中有若干方案类垦，強調智能合約非常復雜，不僅GPU不夠用城须，甚至還需要GPU乃至集群來計算蚤认。
在分片設計中，每個分片依舊承載全網(wǎng)全部的吞吐和容量糕伐，只是將交易的驗證以及狀態(tài)更新分開在各個分片做砰琢，并且之后引入一個O(n^2)的通訊量，將部分更新過的狀態(tài)傳播到其他分片良瞧。而事實上氯析，即使是現(xiàn)實世界中的業(yè)務，各種交易莺褒、清算其實際計算一點都不復雜，就是一些加減乘除雪情，而更多的工作量是在安全驗證以及通訊上面遵岩。
當然我們可以假想一種奇特的應用，需要巨大的計算量來完成邏輯層面的交易驗證和狀態(tài)更新巡通。這會使得CPU處理最先成為瓶頸尘执，并且使得GPU加速變得可能有意義。不過我會很懷疑這樣的應用(或者應用的這個部分)是不是區(qū)塊鏈的真實需求宴凉，是不是應該由區(qū)塊鏈來承載誊锭。
誤區(qū)三：忽略容量瓶頸
近期我看到一些分片方案，認識到了性能瓶頸的本質是帶寬的約束弥锄，并從這一點切入劃分工作量丧靡，讓每個分片負責全網(wǎng)的一部分交易，包括其相關的計算籽暇。
不過非常遺憾温治，我看到的這些方案沒有切分和用戶容量相關的負荷，每個分片仍舊需要維護全網(wǎng)所有用戶所有DApps的狀態(tài)戒悠。并且熬荆，由于所有用戶狀態(tài)需要每個分片都維護，導致某用戶在特定分片中的更新必須廣播到其他的分片绸狐，這將額外引入一個O(n)的通訊量卤恳。由于用戶容量相關的負荷沒有被切分累盗，導致系統(tǒng)無法承載更多的用戶和DApp在鏈上發(fā)生交互，從而使得性能的提升無法被充分利用突琳，約束上層應用的發(fā)展若债。
誤區(qū)四：忽略安全問題(被稀釋的可信大多數(shù))
前面的分析已經提到，在分片之后可信大多數(shù)被稀釋本今，攻擊成本將極大下降拆座。但是，到目前為止冠息，我還沒有看到有可靠的方案挪凑，能切實解決這個問題。
可能會有團隊說逛艰，攻擊成本即使降個幾倍躏碳，也是很難攻擊的，攻擊要花很多資金散怖，沒人會真的去攻擊菇绵。我不認同這種看法。
我的觀點是镇眷，即使在不分片系統(tǒng)中咬最，直接的暴力算力攻擊已經屢有發(fā)生，更別說攻擊成本被降低的分片系統(tǒng)了欠动。如果我們不處理這個問題永乌，只是祈禱沒有人來攻擊，那么在這樣的系統(tǒng)設計之下，性能和安全就構成了直接的矛盾，越高的性能棘脐，即越多的分片，就會導致更低的攻擊成本望几。這其中安全風險巨大。
誤區(qū)五：雙層設計
有不少分片方案萤厅，在各個獨立的分片之外橄抹，引入了一個根鏈(有些叫主鏈或母鏈)，由其完成各個分片之間的溝通和協(xié)調惕味，或者由其來保障各個分片的安全害碾。
對于這類方案，需要比較細致的個例分析赦拘，不排除有可行的方案出現(xiàn)慌随。但是總體上，當跨分片交易的比例很高的時候，根鏈有極大的可能成為系統(tǒng)的瓶頸阁猜。而利用根鏈作為安全保障的系統(tǒng)丸逸，其實本質上很可能就是一個單鏈系統(tǒng)。
在我看來剃袍，優(yōu)異的分片設計方案黄刚，不應有分層的結構，而是各個分片應該是同質的民效，在功能上完全一致憔维，地位上也完全平等。
異步共識組
可以說畏邢，以伸縮性為目標的公鏈研發(fā)項目业扒，其方案中如果沒有分片的設計，都是不切實際的舒萎，在未來的實際應用中必將面對性能瓶頸和容量瓶頸程储，至少會遭遇這兩個瓶頸中的一個。
由于分片這個術語本身太過于寬泛臂寝，我想在下面引入異步共識組(Asynchronized Consensus Zones)這個概念來章鲤，大家討論一下理想的分片設計究竟應該是什么樣的。
我先來解釋一下咆贬，什么是異步共識組败徊。
異步共識組由多個同質的、功能上完全一致掏缎、地位上也完全平等皱蹦，并邏輯上盡量隔離的獨立共識系統(tǒng)的實例所構成，他們并行工作御毅，分攤全網(wǎng)的吞吐壓力，分攤全網(wǎng)狀態(tài)的維護工作怜珍。
0. 具備獨立的相對穩(wěn)定的節(jié)點集合端蛆，邏輯上不要求一個節(jié)點參與到多個共識組
1. 具備獨立的賬簿，承載全網(wǎng)的一部分用戶(組內用戶)酥泛。各個共識組的組內用戶沒有交集
2. 具備獨立的Chain of Blocks今豆，僅記錄已經確認的和組內用戶相關的交易
3. 具備獨立的非阻塞的出塊過程，各個組之間沒有任何同步的需要 (如需要互斥鎖定特定資源)
4. 具備獨立的未確認交易集合柔袁，僅有和組內用戶相關的未確認交易會被暫存
5. 具備獨立的出塊候選或競爭機制呆躲，礦工僅限于組內競爭，和其他組的礦工無直接競爭關系
6. 具備獨立的Gossip網(wǎng)絡捶索，完成區(qū)塊和未確認交易的廣播插掂，不波及其他共識組的節(jié)點
異步共識組中每一個共識組采用具體的共識算法可以是PoW/PoS，也可以是BFT類算法，或這些算法的改進辅甥。異步共識組的設計是如何讓他們完全獨立地并行工作酝润，由于各個共識組在IT資源的消耗上是互相獨立的，那么全網(wǎng)的吞吐性能和賬簿容量將隨著全網(wǎng)共識組的數(shù)量增加而線性增加璃弄，而參與其中的全節(jié)點的工作壓力依舊是單個共識組的負荷要销。
異步共識組是共識算法中立的，并不限定具體的在各個分片中采用的共識算法夏块。有很多團隊在研究和改進共識算法疏咐，無論共識算法被改進到什么程度，任何已知的共識算法或者是今后的改進版本脐供，都可以被應用在異步共識組這個技術架構之中浑塞，從而得幾個數(shù)量級的性能和容量的提升。
假設我們用比特幣的PoW算法患民，用同樣的配置參數(shù)(1MB的塊缩举，10 分鐘的出塊間隔)作為共識組的共識算法，對于一個具有1024個共識組的網(wǎng)絡匹颤，全網(wǎng)將獲得7000多TPS的吞吐性能仅孩。分片的全節(jié)點按照一臺普通的計算機來算，在13Mbps的互聯(lián)網(wǎng)連接印蓖、E5-1620@3.5GHz的CPU辽慕、16G內存、SSD 硬盤 (250MB/s)的情況下赦肃，全網(wǎng)將具備等效的13Gbps帶寬溅蛉、16TB內存、4096個Core的計算能力他宛，以及250GB/s的I/O能力船侧，用來承載所有用戶的賬簿和DApp的狀態(tài)，以及其中涉及的計算厅各。而對于每個共識組里面的每個節(jié)點镜撩，它們所負擔的通訊、計算和存儲的壓力队塘，僅同運行一個比特幣系統(tǒng)的全節(jié)點的負荷相當袁梗。無論全網(wǎng)擴張到多大的程度，網(wǎng)絡中的單個參與者始終不會有明顯増大的負擔憔古。
異步共識組的挑戰(zhàn)有哪些遮怜？
異步共識組是一個理想方式的模型，不僅概念簡單鸿市，而且可以完美突破全網(wǎng)的性能瓶頸和容量瓶頸锯梁，實現(xiàn)高伸縮性的區(qū)塊鏈系統(tǒng)即碗，并且對去中心化程度沒有任何的犧牲。但是涝桅，這個模型要成為切實可行的方案拜姿，正如上文提到的，需要讓這樣的一個系統(tǒng)正確工作并保障安全性冯遂。這里需要兩個方面的設計巧思：
第一蕊肥， 如何正確高效地完成跨共識組的交易；
第二蛤肌， 如何保障每個共識組的安全性壁却。
只有，解決了這兩個挑戰(zhàn)裸准，才能使得異步共識組系統(tǒng)能夠正確安全地工作展东，釋放其強大的性能和容量，打破所謂的「不可能三角」炒俱，服務于大體量的區(qū)塊鏈應用盐肃。
具體這些挑戰(zhàn)如何解決，并且如何最小化所引入的額外開銷权悟？我會留點時間砸王，在未來的文章中和大家繼續(xù)探討 :)。
歡迎大家留言峦阁，或通過我的微信公眾號「王嘉平」和知乎專欄「去中心化數(shù)字世界隨想」谦铃，就這個話題展開更多討論。
