區塊鏈技術資源分享
追尋中本聰先生的腳步
?

分片應該做到什么?分片方案的一些誤區_王嘉平

分片應該做到什么?

從上面對瓶頸根源進行分析之后,我們可以得到這樣的結論:特定的分片方案至少要切分系統的網絡帶寬、內存容量相關的工作量,才有可能大幅提高全網的伸縮性,才有可能打破所謂的「不可能三角」。

必須再次強調,這個結論非常重要。因為只有真正了解這一點,才能進一步討論分片方案是否真的可以打破「不可能三角」。

雖然在前面的分析中,帶寬和內存是短板,但實際上,其他部分的約束也并不富余。理想的情況下,分片系統能夠切分上述四個方面所有的負擔。對于一個有?n?個分片的系統,其每一個分片僅需要承載?1/n?的全網負荷,將網絡帶寬、硬盤文件 I/O、CPU 處理和內存容量的消耗都降到原來的?1/n。

在分布式系統中,這個是高伸縮性能帶來的性能和容量提升的上界。一個分片系統如果可以實現這個,即性能和容量可能隨著分片個數?n?而線性提升,那么理論上,可以使得全網的性能和容量能夠被無限地提升。

而現實情況是,分片系統為了實現應用邏輯的正確性,協調各個分片之間的運作以及實現整體的安全性,需要每個全節點引入額外的工作量?overhead。

這些額外的工作量是個常數 O(1),即和分片個數?n?無關,那么全網線性提升仍舊可以保證。

如果額外的工作量的階?order?小于線性,例如 O(log?n),那么就意味著隨著?n?的增加,全網提升比額外工作量的增加要來得快,全網線性提升還是可以實現的。但是,如果額外的工作量的階大于或等于線性,例如 O(n?log?n) 或 O(n^2),那么基本上全網提升到一定程度,就無法繼續了。因為全節點額外引入的工作量成為了新的首要瓶頸。

跨分片交易的原子性保證

區塊鏈中的每一個交易都是原子的,必須保證其涉及到的操作或者全部完成,或者一個都不開始,才能使得最終狀態是正確的。

對于涉及到多個分片的交易,我們不得不協調發生在各個分片中的操作,保證它們都能被沒有錯誤地完成,并且不受其他交易的干擾。這里看起來可以簡單借用在多線程編程中常用的線程同步概念,用諸如臨界區?critical section?等方式,鎖住涉及到的狀態,阻止其他交易觸碰這些狀態,在完成交易所有操作后釋放。但是,這會導致部分分片的執行被阻塞,而導致實際性能大打折扣。并且隨著全網規模擴大,分片數量增多,跨分片交易的比例必然會極劇上升,從而使得加鎖變得非常頻繁。

一個設計良好的分片系統,必須具備高效的跨分片交易處理算法,并且算法的開銷應該和分片數量?n?無關。

單個分片的安全性保證

分片系統中,如果每個分片有獨立工作的共識系統,也就是每個分片自己一條鏈,全網能最大獲得的吞吐量的?n?倍提升。

共識系統的安全性依賴于出塊權力的大多數?majority?是可信的,這個大多數在 PoW 系統中為 50%,在 BFT 系統中為 2/3,甚至更高。而當全網有?n?個獨立工作的共識系統時,這時平均分到每一個分片的大多數變會降低到原來的 1/n。這樣攻擊這些分片中的共識系統的壁壘,對于 PoW 系統會降低到全網的 50/n?% , 對于 BFT 系統則會降低到 1/(3n)。從而導致,僅需要非常低的成本,就可以攻擊某一個特定的分片,例如構造雙花攻擊?double spend。而在一個分片系統中,只要有一個分片被攻擊,其后果會藉由跨片交易迅速污染到其他的分片。

這就是為什么每一個分片系統都必須處理好安全問題,使得攻擊特定分片的代價同攻擊全網一樣高。

分片方案的一些誤區

分片的顆粒度不夠細

分片的切分依據需要有足夠的顆粒度,這樣才能使得分片個數 n 取到足夠大的值,并且不容易產生單點過熱 hotspot。例如按照交易參與方的地址分,或者按照交易本身的 hash 值來分。這些是可行的方案,因為地址和交易的數量本身足夠的多。

早期我還看到有些分片的方案按照業務來切分的,這是不可取的,顆粒度不夠細,并且如果單個業務活躍度很高,需要更高的性能和容量,卻無法獲得分片系統所帶來的提升。

在全網分片結構不發生改變的前提下 例如給定分片數量 n,分片的切分依據應該是確定的,和賬簿狀態無關的,并且是可以被簡單計算的。

對于提交交易的輕量節點,可以根據交易內容唯一確定這個交易應該被發送到對應的某個分片。早期看到動態的調整地址歸屬,試圖將經常交互的地址劃分在同一個分片,從來減少跨分片交易發生的概率。這種做法是不切實際的,因為本質上同分片數量相矛盾。就以太坊 ERC20 的歷史支付交易來看,在 4 個分片的時候,跨分片交易比例為 75%,在 32 個分片的時候,跨分片交易比例為 97% 按支付發起者的地址 , 平均隨機劃片。

鼓吹智能合約的計算復雜性

從前面的分析可以看到,CPU 處理并不是短板。不過我卻在現實中看到若干方案,強調智能合約非常復雜,不僅 GPU 不夠用,甚至還需要 GPU 乃至集群來計算。

在分片設計中,每個分片依舊承載全網全部的吞吐和容量,只是將交易的驗證以及狀態更新分開在各個分片做,并且之后引入一個 O(n^2) 的通訊量,將部分更新過的狀態傳播到其他分片。而事實上,即使是現實世界中的業務,各種交易、清算其實際計算一點都不復雜,就是一些加減乘除,而更多的工作量是在安全驗證以及通訊上面。

當然我們可以假想一種奇特的應用,需要巨大的計算量來完成邏輯層面的交易驗證和狀態更新。這會使得 CPU 處理最先成為瓶頸,并且使得 GPU 加速變得可能有意義。不過我會很懷疑這樣的應用 或者應用的這個部分 是不是區塊鏈的真實需求,是不是應該由區塊鏈來承載。

忽略容量瓶頸

近期我看到一些分片方案,認識到了性能瓶頸的本質是帶寬的約束,并從這一點切入劃分工作量,讓每個分片負責全網的一部分交易,包括其相關的計算。

不過非常遺憾,我看到的這些方案沒有切分和用戶容量相關的負荷,每個分片仍舊需要維護全網所有用戶所有 DApps 的狀態。并且,由于所有用戶狀態需要每個分片都維護,導致某用戶在特定分片中的更新必須廣播到其他的分片,這將額外引入一個 O(n) 的通訊量。由于用戶容量相關的負荷沒有被切分,導致系統無法承載更多的用戶和DApp在鏈上發生交互,從而使得性能的提升無法被充分利用,約束上層應用的發展。

忽略安全問題 被稀釋的可信大多數

前面的分析已經提到,在分片之后可信大多數被稀釋,攻擊成本將極大下降。但是,到目前為止,我還沒有看到有可靠的方案,能切實解決這個問題。

可能會有團隊說,攻擊成本即使降個幾倍,也是很難攻擊的,攻擊要花很多資金,沒人會真的去攻擊。我不認同這種看法。

我的觀點是,即使在不分片系統中,直接的暴力算力攻擊已經屢有發生,更別說攻擊成本被降低的分片系統了。如果我們不處理這個問題,只是祈禱沒有人來攻擊,那么在這樣的系統設計之下,性能和安全就構成了直接的矛盾,越高的性能,即越多的分片,就會導致更低的攻擊成本。這其中安全風險巨大。

雙層設計

有不少分片方案,在各個獨立的分片之外,引入了一個根鏈 有些叫做主鏈或母鏈,由其完成各個分片之間的溝通和協調,或者由其來保障各個分片的安全。

對于這類方案,需要比較細致的個例分析,不排除有可行的方案出現。但是總體上,當跨分片交易的比例很高的時候,根鏈有極大的可能成為系統的瓶頸。而利用根鏈作為安全保障的系統,其實本質上很可能就是一個單鏈系統。

在我看來,優異的分片設計方案,不應有分層的結構,而是各個分片應該是同質的,在功能上完全一致,地位上也完全平等。

下一篇《異步共識組 Asynchronized Consensus Zones


歡迎大家通過我的微信公眾號「王嘉平」和知乎專欄「去中心化數字世界隨想」,就這個話題展開更多討論。


分片應該做到什么?分片方案的一些誤區

分享到:更多 ()
0
區塊鏈神吐槽
pi幣注冊流程教程圖解中文版

來評論吐槽 搶沙發

評論前必須登錄!

 

區塊鏈資源分享聯系我

區塊鏈資源分享聯系我首頁更多新聞
做滴滴代驾还是开滴滴那个赚钱