摘要：區(qū)塊鏈擴展性迷局比特幣作為第一個區(qū)塊鏈應用與運行到目前為止最被信任的公鏈，其擴展性問題卻持續(xù)被作為焦點貫穿著整個鏈的發(fā)展周期。當然區(qū)塊鏈與也可以保留回執(zhí)，用于驗證后續(xù)跨鏈交易的持續(xù)性。

區(qū)塊鏈擴展性迷局

比特幣作為第一個區(qū)塊鏈應用與運行到目前為止最被信任的公鏈，其擴展性問題卻持續(xù)被作為焦點貫穿著整個鏈的發(fā)展周期。事實上，在2009年1月4日比特幣出現(xiàn)的那一天到2010年10月1日之間，并沒有明確的區(qū)塊上限，根據(jù)比特幣區(qū)塊鏈區(qū)塊的數(shù)據(jù)結(jié)構最高可達到32M的容量。而在2010年10月1日的一個commit當中，中本聰?shù)谝淮卧诖a中明確限定了1M的區(qū)塊上限，就在10月3日，Jeff Garzik發(fā)布了將區(qū)塊上限擴展到7M的補丁，成為了第一個硬分叉的嘗試。當然，這個補丁并沒有用戶使用，而彼時的平均區(qū)塊數(shù)據(jù)量僅在幾十k左右，中本聰也在當時說明為了保證比特幣系統(tǒng)的安全和穩(wěn)定，建議不要采用Jeff Garzik所發(fā)布的補丁。

隨著比特幣網(wǎng)絡規(guī)模的持續(xù)擴張，鏈上交易變得更為活躍，區(qū)塊內(nèi)的數(shù)據(jù)量也逐漸增多，于是每秒7筆的交易處理速度成為瓶頸的趨勢也越發(fā)明顯。

圖表 1 比特幣區(qū)塊鏈歷史大小（BitinfoCharts.com）

從2015年開始Jeff Garzik就曾再次通過BIP100提出移除1MB上限，回歸最早的32MB，而此時比特幣算力早已突破了1P的規(guī)模邊界，利益相關方中比起一般的支付用戶，更多的是礦工。然而對于礦工來說，打包更多的交易意味著消耗更多的資源，也因此，一直以來比特幣區(qū)塊鏈區(qū)塊的擴容從未真正達成共識，隨之而來的是BCH、BSV等的分叉。而無限放大區(qū)塊容量上限來解決交易處理速度的問題，顯然只是權宜之計。

類似的問題，在以太坊上依然存在。雖然其區(qū)塊大小并未像比特幣那樣以一個常數(shù)作為限制，但gaslimit作為上限的設置與礦工利益的平衡也同樣對以太坊的交易處理速度形成了限制，使其秒處理速度在15筆左右。也因此在ICO盛行的2017年以及類似以太貓這樣的游戲爆火的時候，整個以太坊網(wǎng)絡都會陷入交易堆積成山的癱瘓狀態(tài)。

在主鏈擴展難以破局的過程中，一方面出現(xiàn)了將主鏈區(qū)塊鏈數(shù)據(jù)驗證和計算的責任僅交由一小組高性能節(jié)點來完成的解決方式，比特股、EoS等的DPoS機制即通過這種方式啦實現(xiàn)。這類解決方案通過模擬現(xiàn)實中的議會制選舉高性能節(jié)點，而難免引起了利益集團與中心化趨勢的疑議。除此之外，也有通過鏈下交易來解決這類問題的嘗試，其中比特幣的閃電網(wǎng)絡和以太坊的雷電網(wǎng)絡是較為典型的兩個實例。

由于比特幣UTXO的區(qū)塊鏈模型和以太坊基于賬戶余額模型的區(qū)別，在鏈下交易通道的具體協(xié)議設計上就有了閃電網(wǎng)絡和雷電網(wǎng)絡的差異。然而兩者之間有著共通的基本邏輯，即通過在主鏈外開辟針對特定交易對象的交易通道。也就是說，特定交易對象之間通過共同鎖定一筆保證金，來用于特定時間區(qū)間內(nèi)的交易結(jié)算，只要雙方或多方交易結(jié)果沒有超出保證金的額度，或者沒有超時，或者沒有任何一方選擇中止交易通道，雙方或多方的交易就不需要向全網(wǎng)廣播獲得確認，也不需要向區(qū)塊鏈主網(wǎng)支付任何手續(xù)費。這使得高頻小額的交易不再依賴于區(qū)塊的大小或者區(qū)塊的出塊速度。

當然，為了實現(xiàn)盡可能多的匹配高頻交易的各種需求，閃電網(wǎng)絡中會出現(xiàn)多個中轉(zhuǎn)節(jié)點，用于匹配交易需求的各方。也是由于閃電網(wǎng)絡中的交易過程要求收款環(huán)節(jié)通過簽名回收，因此交易方需要實時在線，也而從這個邏輯來看，似乎中心化的交易所最適合擔任中轉(zhuǎn)節(jié)點的角色。而這也讓社區(qū)擔憂，是否最終會讓高頻小額交易變得日益中心化并在安全性上做出妥協(xié)。

當然，不管如何，閃電網(wǎng)絡與雷電網(wǎng)絡的設計已經(jīng)將擴展性問題的解決引導向了主鏈之外的第二層，將不同需求的網(wǎng)絡和主鏈網(wǎng)絡分層，成為了解決擴展性問題的一大趨勢。

主子鏈設計與分片概念

分片源于數(shù)據(jù)庫設計中的概念，通過分類備份和冗余來增加整體數(shù)據(jù)庫的處理效率和容錯性。分布式數(shù)據(jù)庫中通過建立不同的分片機制滿足業(yè)務系統(tǒng)的不同要求。區(qū)塊鏈中針對性能擴展所提出的第二層（Layer 2）解決方案也借用了這一概念，通過將不同業(yè)務對區(qū)塊鏈的不同需求進行分類，并各自分布在不同的子鏈當中，從而解決全鏈共識的性能瓶頸。

然而，區(qū)塊鏈與分布式數(shù)據(jù)庫中較大的區(qū)別在于，分布式數(shù)據(jù)庫的增刪改查以及計算來自于業(yè)務系統(tǒng)或者中心化的數(shù)據(jù)管理系統(tǒng)，分布式數(shù)據(jù)庫各節(jié)點僅負責響應數(shù)據(jù)管理員（DBA）；而區(qū)塊鏈的業(yè)務邏輯也來自于各節(jié)點即包含也業(yè)務邏輯、計算、也包含了至少賬本層面數(shù)據(jù)的管理，也就是每個節(jié)點都可以是DBA，或者理解為根本沒有DBA，因此在設計上則更為復雜。

由于分布式數(shù)據(jù)庫的交易邏輯為中心化控制，因此其分片可以被看作是單純的存儲分片。區(qū)塊鏈的分片則主要分為相對簡單的交易分片：即仍然保持全網(wǎng)絡節(jié)點在數(shù)據(jù)上的全同步，僅通過分片來讓不同節(jié)點運行不同的運算邏輯；和更為困難的狀態(tài)分片：即同時包含了對交易與存儲的分區(qū)。狹義上來理解，最直觀的狀態(tài)分片其實就是各種分叉，不同分叉鏈上各自處理的自己的交易、存儲自己的賬本數(shù)據(jù)，驗證歷史區(qū)塊有效性的時候可以選擇一直回溯到分叉發(fā)生前的區(qū)塊，通過快照來確認歷史交易。但這種類型的分片由于沒有后續(xù)跨片交互的機制設計，因此并沒有提升太多實際價值。

那么狀態(tài)分片的跨片交易需要解決的就是如何去相互驗證不同分片內(nèi)交易的有效性了。分片內(nèi)部交易的有效性由分片內(nèi)的節(jié)點通過共識機制確保，也因此在SimpleChain的設計當中，不同的分片內(nèi)也同樣擁有著區(qū)塊鏈的運行機制，因此跨片交易問題在SimpleChain當中就被理解為跨鏈交易的問題，而分片則被定義為子鏈。

跨鏈交易的形成

由于跨子鏈交易來自于兩個賬本數(shù)據(jù)不一致的區(qū)塊鏈用戶之間，因此通過構造一個不作為狀態(tài)存儲在賬本中的“對象”，可以實現(xiàn)類似于SPV（簡單支付驗證）的機制，即通過互相之間所同步的區(qū)塊頭來完成梅克爾證明，來驗證這個構造出來的“對象”所傳遞信息的有效性。我們可以把這個對象稱為收據(jù)。

圖表 2 基于收據(jù)的跨鏈交易確認（Ethereum wiki）

在上述圖表中，表示的是一個從區(qū)塊鏈X中的用戶A向在區(qū)塊鏈Y中的用戶C發(fā)送100個單位的資產(chǎn)的過程。

（1） 這個過程首先通過生成一筆交易以及一個編號為154016的收據(jù)，并在區(qū)塊鏈X的賬本中扣除A的100個單位資產(chǎn)來發(fā)起。

（2） 這個收據(jù)發(fā)送到區(qū)塊鏈Y之后，通過梅克爾證明可以驗證到收據(jù)所包含的信息是否正確，也就是第一筆交易是否已經(jīng)在X區(qū)塊鏈被確認，A是否已經(jīng)被扣除了100個單位的資產(chǎn)。

（3） 獲得確認后，用戶C從區(qū)塊鏈Y發(fā)送一筆包含了對收據(jù)154016的梅克爾證明的交易給到區(qū)塊鏈X，可以把這筆交易看作回執(zhí)，并增加C賬本中的100個單位資產(chǎn)。

（4） 區(qū)塊鏈X收到這個回執(zhí)，并將之前的收據(jù)進行銷毀，同時區(qū)塊鏈Y也在后續(xù)的區(qū)塊中將收據(jù)154016進行銷毀，跨鏈交易完成。當然區(qū)塊鏈X與Y也可以保留回執(zhí)，用于驗證后續(xù)跨鏈交易的持續(xù)性。

為了確保上面這個機制的持續(xù)有效，我們還需要考慮跨鏈交易中的終局性問題，或者叫做分叉選擇機制。區(qū)塊鏈Y所驗證的區(qū)塊鏈X交易必須來自于區(qū)塊鏈X有效鏈的塊中的交易，而不是來源于一個孤塊或者孤鏈。Vlad Zamfir提出過一個合并塊的設計，也就是兩條鏈在需要發(fā)起跨鏈交易時，兩個在不同鏈上的塊合并為同一個區(qū)塊，各自的鏈都基于這個合并塊去延長之后的塊數(shù)據(jù)。但實際上合并塊意味著兩條鏈的賬本同步，因此我們認為并不能解決兩個分片或者兩個鏈之間的相互獨立性問題。但是跨鏈交易中，如何尋找正確的對方鏈的塊去完成收據(jù)的梅克爾證明，是可以從Vlad的思路中找到答案的。

Vlad將兩條需要實現(xiàn)跨鏈的鏈進行等級排序，分為“父鏈”和“子鏈”，“子鏈”需要在與“父鏈”高度相同，或高于“父鏈”高度所產(chǎn)生的區(qū)塊與“父鏈”進行區(qū)塊合并，或者在我們的場景中是在“父鏈”上進行區(qū)塊跨鏈驗證。這樣能夠確保兩個鏈在各自延長的過程中，跨鏈部分數(shù)據(jù)能夠持續(xù)保持一致。

圖表 3 合并塊機制（Vlad Zamfir）

但是，在上述的解決方案中存在需要兩個區(qū)塊鏈同步出塊的前提，因為如果“父鏈”X的交易遲遲不能確認，或者沒有延長，或者“子鏈”Y沒有及時收到X的延長情況，亦或者“子鏈”與“父鏈”存在間斷性同步，則“子鏈”Y的后續(xù)交易有效性也都會受到相應的影響。

圖表 4 非同步跨鏈（跨片）交易在分叉時的情況（Alexander Skidanov）

從上圖中可以看出，兩個分片或者鏈各自存在分叉的情況下，如果分片1中的A-B以及分片2中的V’-X’-Y’-Z’各自被確認為主鏈，則跨鏈或跨片交易沒有問題，亦或A’-B’-C’-D’和V-X成為了主鏈，則跨片交易就失效。但假設是另外兩種情況，則存在了原子性故障，也就是在一個分片中交易有效而在另一個分片中交易無效。由于兩個分片或者鏈的異步性，導致在發(fā)起跨鏈交易時并不能確定兩個鏈內(nèi)部各自的主鏈確定情況，因此這種問題就會產(chǎn)生。于是分片或者子鏈之間的跨鏈交易就需要一個中間共識機制來進行協(xié)調(diào)。

在以太坊2.0的設計中，信標鏈被賦予了這個職能。信標鏈可以被認為是以太坊2.0設計中所有分片鏈的主鏈，這條主鏈通過Casper共識機制來選舉并在每一輪中隨機產(chǎn)生分片驗證者，用于協(xié)調(diào)分片之間的交易正確性。但是在屬于PoS的Casper共識機制中，由于沒有了難度要求、nonce、塊哈希這些原本在PoW中能夠執(zhí)行無狀態(tài)SPV證明的工具，因此要驗證分片鏈的有效性需要回溯到可信區(qū)塊，再重新計算可信區(qū)塊后的區(qū)塊狀態(tài)一致到當前區(qū)塊，才能完成驗證。導致了驗證者增加了工作量。因此在SimpleChain當中，為了減少驗證者的工作量，類似信標鏈的角色則通過PoW的主鏈來完成。

主鏈當中存在錨定礦工的角色，所謂錨定礦工承擔三個功能角色，1. 負責在某子鏈發(fā)起跨鏈交易時驗證該子鏈狀態(tài)的有效性；2. 負責在主鏈中寫入子鏈交易并廣播獲得確認；3. 將意在主鏈確認的跨鏈交易結(jié)果分別寫入交易發(fā)起子鏈與交易接收子鏈的區(qū)塊中。

錨定礦工在驗證、廣播、和傳遞跨鏈交易時，既作為子鏈礦工也作為主鏈礦工存在。然而在主鏈上的礦工數(shù)量會比子鏈中的礦工數(shù)量多，因此在子鏈中偽造交易傳遞到主鏈的成本將大大低于在主鏈偽造交易寫入子鏈。因此需要一種更為合理的錨定礦工選舉機制。

圖表 5 子鏈中作惡礦工的概率將會高于主鏈（Alexander Skidanov）

錨定礦工不針對于某個子鏈長期存在，但需要長時間作為主鏈礦工存在。由于PoW的主鏈能夠允許無狀態(tài)SPV證明，因此我們在SimpleChain中將錨定礦工的選舉通過隨機的形式來完成。

一次跨鏈交易驗證的錨定礦工數(shù)量上限=Min[（全網(wǎng)礦工數(shù)/子鏈數(shù)量）*3,全網(wǎng)礦工數(shù)]

由于錨定礦工來自于PoW主鏈礦工，因此通過從小到大排列主鏈礦工所計算出的工作量證明計算結(jié)果，進行錨定礦工篩選。由于數(shù)值越小的工作量證明計算結(jié)果獲得的概率越低，因此在錨定礦工預選列表中的排名越高，超出該次錨定礦工數(shù)量上限排名的礦工則在當前輪的交易驗證中不參與簽。錨定礦工選舉過程的PoW排序與主鏈延長的PoW同步進行，即主鏈礦工不僅將使用工作量證明計算結(jié)果獲得主鏈SIPC獎勵，還將獲得錨定礦工獎勵。錨定礦工獎勵來自于子鏈跨鏈交易發(fā)起者所支付的SIPC礦工手續(xù)費。

在保證主子鏈的一致性問題上，我們采用了n個確認的機制。當發(fā)起一筆跨鏈交易時，子鏈內(nèi)的區(qū)塊應首先獲得n個塊高的確認，才能夠通過錨定礦工的驗證并廣播至主鏈上。經(jīng)過主鏈n各塊高的確認后，才分別將確認后的交易狀態(tài)寫入跨鏈交易所涉及的兩個子鏈當中。

n的大小與跨鏈交易的金額、數(shù)據(jù)量成正比，也就是價值越高的交易所需要的在子鏈和主鏈中的確認數(shù)要求越高。目前設計中，主鏈確認數(shù)n沿襲了比特幣的常數(shù)設定思路，由于主鏈平均出塊時間12秒，因此主鏈的n值設定為15時其安全性將會接近于比特幣6個確認的時間。而子鏈確認數(shù)則以主鏈15個確認的基礎，基于跨鏈交易的金額、數(shù)據(jù)量進行動態(tài)調(diào)整。

主子鏈結(jié)構持續(xù)穩(wěn)態(tài)的經(jīng)濟設計

圖表 6 SIPC模型 （Simplechain Foundation）

SimpleChain在白皮書1.0中提出了主鏈數(shù)字資源SIPC的微通脹機制，即隨著子鏈的增加、子鏈活躍度的增加以及對跨鏈交易需求的增加，SIPC的區(qū)塊獎勵會在原本的衰減曲線基礎上產(chǎn)生微調(diào)（上圖中從綠色虛線變?yōu)楹谏珜嵕€）。這種微調(diào)的結(jié)果就是當主鏈SIPC被作為一種資源，子鏈對其的需求量增加的時候，主鏈出塊獎勵將相應增加，以當前狀態(tài)為例，主鏈出塊獎勵將可能從20SIPC增加到21SIPC。

這一設計的目的在于讓子鏈與主鏈上的角色之間的關系更為穩(wěn)固。子鏈對主鏈的需求在于通過主鏈協(xié)調(diào)跨鏈交易，一筆跨鏈交易的過程為：

（1） 子鏈用戶發(fā)起跨鏈交易并支付手續(xù)費，手續(xù)費包含子鏈Token（T）與主鏈SIPC（S）；

（2） 子鏈礦工或驗證節(jié)點完成共識驗證并收取部分子鏈Token（t1）作為手續(xù)費；

（3） 被選舉出來的跨鏈礦工收取剩余部分子鏈Token（t2）以及手續(xù)費中的全部主鏈SIPC（S）以及運營池中的部分SIPC（s2）作為手續(xù)費完成跨鏈錨定與廣播；

（4） 一般主鏈礦工收取主鏈交易手續(xù)費SIPC（S’）打包跨鏈交易；

（5） 另一條子鏈錨定礦工讀取主鏈中的跨鏈交易，廣播至目標子鏈中。

以上過程中T=t1+t2，然而一般主鏈礦工收取的主鏈交易手續(xù)費S’=R+k，R為原始主鏈出塊獎勵，即當前的20SIPC，k則為微通脹調(diào)節(jié)獎勵。

上面出現(xiàn)了運營池的概念，所謂運營池即是在子鏈初期創(chuàng)建時，創(chuàng)建節(jié)點通過抵押SIPC的形式向子鏈注入的啟動資源，運營池中的SIPC將在跨鏈交易中作為部分獎勵s，輸出給錨定礦工。

假設一個資料的啟動運營池容量是10SIPC，在跨鏈過程中，每次會分出其中的0.1SIPC給到跨鏈礦工作為跨鏈礦工的部分獎勵，一次交易過后運營池容量減少為9.9SIPC。此時，一般主鏈礦工收取到的交易手續(xù)費S’=20+0.01，這0.01就是微通脹調(diào)節(jié)獎勵。

運營池可以由任何SimpleChain用戶選擇再次注入SIPC，也可由子鏈共識觸發(fā)活躍度下限，更改跨鏈礦工獎勵來使得跨鏈礦工獲得的s2為負，即部分跨鏈手續(xù)費被存入子鏈運營池。此時，一般主鏈礦工收取的手續(xù)費中的微通脹調(diào)節(jié)獎勵k將為0或轉(zhuǎn)向負數(shù)。這種情況下表明子鏈走向衰退期，或子鏈與主鏈將逐漸通過減少互相激勵而脫離關系。

潛在風險與后期討論

上述模型中可能存在的技術風險包括主鏈區(qū)塊當中對于包含跨鏈交易的交易量上限問題，以及過多錨定礦工造成的主鏈負擔過重的問題。

經(jīng)濟模型方面，存在“損人不利己”攻擊的可能，即通過創(chuàng)建衰減子鏈，影響主鏈礦工與用戶利益的情況。

References

[1]. BitInforCharts (2019) Bitcoin Block Size historical chart, Available from: https://bitinfocharts.com/com... [Accessed on 02/04/2019]

[2]. Buterin. V(2015) On Slow and Fast Block Times, Available from: https://blog.ethereum.org/201... [Accessed on 04/04/2019]

[3]. Buterin. V(2019) Merge blocks and synchronous cross-shard state execution, Available from: https://ethresear.ch/t/merge-... [Accessed on 03/04/2019]

[4]. Buterin. V(2019) How can we facilitate cross-shard communication?, Available from: https://github.com/ethereum/w... [Accessed on 03/04/2019]

[5]. Prestwich. J(2019) What to expect when eths expecting, Chinese Version Translated by EthFans, Available from https://ethfans.org/posts/wha... [Accessed on 02/04/2019]

[6]. Skidanov. A(2019) The authoritative guide to blockchain sharding part 1, Chinese Version Translated by EthFans, Available from: https://ethfans.org/posts/the... [Accessed on 02/04/2019]

[7]. Skidanov. A(2019) The authoritative guide to blockchain sharding part 2: Unsolved problems in blockchain sharding, Chinese Version Translated by EthFans,https://ethfans.org/posts/uns... [Accessed on 02/04/2019]

[8]. Zamir. V(2018) Casper, Ethereum Community Conference on March 8-10,2018, Available from: https://www.youtube.com/watch...[Accessed on 03/04/2019]