1. 區塊鏈擴展性迷局
比特幣作為第一個區塊鏈應用與運行到目前為止最被信任的公鏈，其擴展性問題卻持續被作為焦點貫穿著整個鏈的發展週期。事實上，在2009年1月4日比特幣出現的那一天到2010年10月1日之間，並沒有明確的區塊上限，根據比特幣區塊鏈區塊的數據結構最高可達到32M的容量。而在2010年10月1日的一個commit當中，中本聰第一次在代碼中明確限定了1M的區塊上限，就在10月3日，Jeff Garzik發佈了將區塊上限擴展到7M的補丁，成為了第一個硬分叉的嘗試。當然，這個補丁並沒有用戶使用，而彼時的平均區塊數據量僅在幾十k左右，中本聰也在當時說明為了保證比特幣系統的安全和穩定，建議不要採用Jeff Garzik所發佈的補丁。隨著比特幣網絡規模的持續擴張，鏈上交易變得更為活躍，區塊內的數據量也逐漸增多，於是每秒7筆的交易處理速度成為瓶頸的趨勢也越發明顯。
圖表 1 比特幣區塊鏈歷史大小（BitinfoCharts.com）
從2015年開始Jeff Garzik就曾再次通過BIP100提出移除1MB上限，迴歸最早的32MB，而此時比特幣算力早已突破了1P的規模邊界，利益相關方中比起一般的支付用戶，更多的是礦工。然而對於礦工來說，打包更多的交易意味著消耗更多的資源，也因此，一直以來比特幣區塊鏈區塊的擴容從未真正達成共識，隨之而來的是BCH、BSV等的分叉。而無限放大區塊容量上限來解決交易處理速度的問題，顯然只是權宜之計。
類似的問題，在以太坊上依然存在。雖然其區塊大小並未像比特幣那樣以一個常數作為限制，但gaslimit作為上限的設置與礦工利益的平衡也同樣對以太坊的交易處理速度形成了限制，使其秒處理速度在15筆左右。也因此在ICO盛行的2017年以及類似以太貓這樣的遊戲爆火的時候，整個以太坊網絡都會陷入交易堆積成山的癱瘓狀態。
在主鏈擴展難以破局的過程中，一方面出現了將主鏈區塊鏈數據驗證和計算的責任僅交由一小組高性能節點來完成的解決方式，比特股、EoS等的DPoS機制即通過這種方式啦實現。這類解決方案通過模擬現實中的議會制選舉高性能節點，而難免引起了利益集團與中心化趨勢的疑議。除此之外，也有通過鏈下交易來解決這類問題的嘗試，其中比特幣的閃電網絡和以太坊的雷電網絡是較為典型的兩個實例。
由於比特幣UTXO的區塊鏈模型和以太坊基於賬戶餘額模型的區別，在鏈下交易通道的具體協議設計上就有了閃電網絡和雷電網絡的差異。然而兩者之間有著共通的基本邏輯，即通過在主鏈外開闢針對特定交易對象的交易通道。也就是說，特定交易對象之間通過共同鎖定一筆保證金，來用於特定時間區間內的交易結算，只要雙方或多方交易結果沒有超出保證金的額度，或者沒有超時，或者沒有任何一方選擇中止交易通道，雙方或多方的交易就不需要向全網廣播獲得確認，也不需要向區塊鏈主網支付任何手續費。這使得高頻小額的交易不再依賴於區塊的大小或者區塊的出塊速度。
當然，為了實現儘可能多的匹配高頻交易的各種需求，閃電網絡中會出現多箇中轉節點，用於匹配交易需求的各方。也是由於閃電網絡中的交易過程要求收款環節通過簽名回收，因此交易方需要實時在線，也而從這個邏輯來看，似乎中心化的交易所最適合擔任中轉節點的角色。而這也讓社區擔憂，是否最終會讓高頻小額交易變得日益中心化並在安全性上做出妥協。
當然，不管如何，閃電網絡與雷電網絡的設計已經將擴展性問題的解決引導向了主鏈之外的第二層，將不同需求的網絡和主鏈網絡分層，成為了解決擴展性問題的一大趨勢。
2. 主子鏈設計與分片概念
分片源於數據庫設計中的概念，通過分類備份和冗餘來增加整體數據庫的處理效率和容錯性。分佈式數據庫中通過建立不同的分片機制滿足業務系統的不同要求。區塊鏈中針對性能擴展所提出的第二層（Layer 2）解決方案也借用了這一概念，通過將不同業務對區塊鏈的不同需求進行分類，並各自分佈在不同的子鏈當中，從而解決全鏈共識的性能瓶頸。
然而，區塊鏈與分佈式數據庫中較大的區別在於，分佈式數據庫的增刪改查以及計算來自於業務系統或者中心化的數據管理系統，分佈式數據庫各節點僅負責響應數據管理員（DBA）；而區塊鏈的業務邏輯也來自於各節點即包含也業務邏輯、計算、也包含了至少賬本層面數據的管理，也就是每個節點都可以是DBA，或者理解為根本沒有DBA，因此在設計上則更為複雜。
由於分佈式數據庫的交易邏輯為中心化控制，因此其分片可以被看作是單純的存儲分片。區塊鏈的分片則主要分為相對簡單的交易分片：即仍然保持全網絡節點在數據上的全同步，僅通過分片來讓不同節點運行不同的運算邏輯；和更為困難的狀態分片：即同時包含了對交易與存儲的分區。狹義上來理解，最直觀的狀態分片其實就是各種分叉，不同分叉鏈上各自處理的自己的交易、存儲自己的賬本數據，驗證歷史區塊有效性的時候可以選擇一直回溯到分叉發生前的區塊，通過快照來確認歷史交易。但這種類型的分片由於沒有後續跨片交互的機制設計，因此並沒有提升太多實際價值。
那麼狀態分片的跨片交易需要解決的就是如何去相互驗證不同分片內交易的有效性了。分片內部交易的有效性由分片內的節點通過共識機制確保，也因此在某公鏈的設計當中，不同的分片內也同樣擁有著區塊鏈的運行機制，因此跨片交易問題在該公鏈當中就被理解為跨鏈交易的問題，而分片則被定義為子鏈。
3. 跨鏈交易的形成
由於跨子鏈交易來自於兩個賬本數據不一致的區塊鏈用戶之間，因此通過構造一個不作為狀態存儲在賬本中的“對象”，可以實現類似於SPV（簡單支付驗證）的機制，即通過互相之間所同步的區塊頭來完成梅克爾證明，來驗證這個構造出來的“對象”所傳遞信息的有效性。我們可以把這個對象稱為收據。
圖表 2 基於收據的跨鏈交易確認（Ethereum wiki）
在上述圖表中，表示的是一個從區塊鏈X中的用戶A向在區塊鏈Y中的用戶C發送100個單位的資產的過程。
（1） 這個過程首先通過生成一筆交易以及一個編號為154016的收據，並在區塊鏈X的賬本中扣除A的100個單位資產來發起。
（2） 這個收據發送到區塊鏈Y之後，通過梅克爾證明可以驗證到收據所包含的信息是否正確，也就是第一筆交易是否已經在X區塊鏈被確認，A是否已經被扣除了100個單位的資產。
（3） 獲得確認後，用戶C從區塊鏈Y發送一筆包含了對收據154016的梅克爾證明的交易給到區塊鏈X，可以把這筆交易看作回執，並增加C賬本中的100個單位資產。
（4） 區塊鏈X收到這個回執，並將之前的收據進行銷燬，同時區塊鏈Y也在後續的區塊中將收據154016進行銷燬，跨鏈交易完成。當然區塊鏈X與Y也可以保留回執，用於驗證後續跨鏈交易的持續性。
為了確保上面這個機制的持續有效，我們還需要考慮跨鏈交易中的終局性問題，或者叫做分叉選擇機制。區塊鏈Y所驗證的區塊鏈X交易必須來自於區塊鏈X有效鏈的塊中的交易，而不是來源於一個孤塊或者孤鏈。Vlad Zamfir提出過一個合併塊的設計，也就是兩條鏈在需要發起跨鏈交易時，兩個在不同鏈上的塊合併為同一個區塊，各自的鏈都基於這個合併塊去延長之後的塊數據。但實際上合併塊意味著兩條鏈的賬本同步，因此我們認為並不能解決兩個分片或者兩個鏈之間的相互獨立性問題。但是跨鏈交易中，如何尋找正確的對方鏈的塊去完成收據的梅克爾證明，是可以從Vlad的思路中找到答案的。
Vlad將兩條需要實現跨鏈的鏈進行等級排序，分為“父鏈”和“子鏈”，“子鏈”需要在與“父鏈”高度相同，或高於“父鏈”高度所產生的區塊與“父鏈”進行區塊合併，或者在我們的場景中是在“父鏈”上進行區塊跨鏈驗證。這樣能夠確保兩個鏈在各自延長的過程中，跨鏈部分數據能夠持續保持一致。
圖表 3 合併塊機制（Vlad Zamfir）
但是，在上述的解決方案中存在需要兩個區塊鏈同步出塊的前提，因為如果“父鏈”X的交易遲遲不能確認，或者沒有延長，或者“子鏈”Y沒有及時收到X的延長情況，亦或者“子鏈”與“父鏈”存在間斷性同步，則“子鏈”Y的後續交易有效性也都會受到相應的影響。
圖表 4 非同步跨鏈（跨片）交易在分叉時的情況（Alexander Skidanov）
從上圖中可以看出，兩個分片或者鏈各自存在分叉的情況下，如果分片1中的A-B以及分片2中的V’-X’-Y’-Z’各自被確認為主鏈，則跨鏈或跨片交易沒有問題，亦或A’-B’-C’-D’和V-X成為了主鏈，則跨片交易就失效。但假設是另外兩種情況，則存在了原子性故障，也就是在一個分片中交易有效而在另一個分片中交易無效。由於兩個分片或者鏈的異步性，導致在發起跨鏈交易時並不能確定兩個鏈內部各自的主鏈確定情況，因此這種問題就會產生。於是分片或者子鏈之間的跨鏈交易就需要一箇中間共識機制來進行協調。
在以太坊2.0的設計中，信標鏈被賦予了這個職能。信標鏈可以被認為是以太坊2.0設計中所有分片鏈的主鏈，這條主鏈通過Casper共識機制來選舉並在每一輪中隨機產生分片驗證者，用於協調分片之間的交易正確性。但是在屬於PoS的Casper共識機制中，由於沒有了難度要求、nonce、塊哈希這些原本在PoW中能夠執行無狀態SPV證明的工具，因此要驗證分片鏈的有效性需要回溯到可信區塊，再重新計算可信區塊後的區塊狀態一致到當前區塊，才能完成驗證。導致了驗證者增加了工作量。因此在該採用主子鏈結構的公鏈當中，為了減少驗證者的工作量，類似信標鏈的角色則通過PoW的主鏈來完成。
主鏈當中存在錨定礦工的角色，所謂錨定礦工承擔三個功能角色，1. 負責在某子鏈發起跨鏈交易時驗證該子鏈狀態的有效性；2. 負責在主鏈中寫入子鏈交易並廣播獲得確認；3. 將意在主鏈確認的跨鏈交易結果分別寫入交易發起子鏈與交易接收子鏈的區塊中。
錨定礦工在驗證、廣播、和傳遞跨鏈交易時，既作為子鏈礦工也作為主鏈礦工存在。然而在主鏈上的礦工數量會比子鏈中的礦工數量多，因此在子鏈中偽造交易傳遞到主鏈的成本將大大低於在主鏈偽造交易寫入子鏈。因此需要一種更為合理的錨定礦工選舉機制。
圖表 5 子鏈中作惡礦工的概率將會高於主鏈（Alexander Skidanov）
錨定礦工不針對於某個子鏈長期存在，但需要長時間作為主鏈礦工存在。由於PoW的主鏈能夠允許無狀態SPV證明，因此我們在該應用主子鏈結構的公鏈中將錨定礦工的選舉通過隨機的形式來完成。
一次跨鏈交易驗證的錨定礦工數量上限=Min[（全網礦工數/子鏈數量）*3,全網礦工數]
由於錨定礦工來自於PoW主鏈礦工，因此通過從小到大排列主鏈礦工所計算出的工作量證明計算結果，進行錨定礦工篩選。由於數值越小的工作量證明計算結果獲得的概率越低，因此在錨定礦工預選列表中的排名越高，超出該次錨定礦工數量上限排名的礦工則在當前輪的交易驗證中不參與籤。錨定礦工選舉過程的PoW排序與主鏈延長的PoW同步進行，即主鏈礦工不僅將使用工作量證明計算結果獲得主鏈Token獎勵，還將獲得錨定礦工獎勵。錨定礦工獎勵來自於子鏈跨鏈交易發起者所支付的礦工手續費。
在保證主子鏈的一致性問題上，我們採用了n個確認的機制。當發起一筆跨鏈交易時，子鏈內的區塊應首先獲得n個塊高的確認，才能夠通過錨定礦工的驗證並廣播至主鏈上。經過主鏈n各塊高的確認後，才分別將確認後的交易狀態寫入跨鏈交易所涉及的兩個子鏈當中。
n的大小與跨鏈交易的金額、數據量成正比，也就是價值越高的交易所需要的在子鏈和主鏈中的確認數要求越高。目前設計中，主鏈確認數n沿襲了比特幣的常數設定思路，由於主鏈平均出塊時間12秒，因此主鏈的n值設定為15時其安全性將會接近於比特幣6個確認的時間。而子鏈確認數則以主鏈15個確認的基礎，基於跨鏈交易的金額、數據量進行動態調整。
4.主子鏈結構持續穩態的經濟設計
圖表 6 主子鏈結構公鏈項目經濟模型
基於主子鏈結構的該公鏈項目採取了主鏈數字資源的微通脹機制，即隨著子鏈的增加、子鏈活躍度的增加以及對跨鏈交易需求的增加，區塊獎勵會在原本的衰減曲線基礎上產生微調（上圖中從綠色虛線變為黑色實線）。這種微調的結果就是當主鏈通證被作為一種資源，子鏈對其的需求量增加的時候，主鏈出塊獎勵將相應增加，以當前狀態為例，主鏈出塊獎勵將可能從20增加到21。
這一設計的目的在於讓子鏈與主鏈上的角色之間的關係更為穩固。子鏈對主鏈的需求在於通過主鏈協調跨鏈交易，一筆跨鏈交易的過程為：
（1） 子鏈用戶發起跨鏈交易並支付手續費，手續費包含子鏈Token（T）與主鏈Token（S）；
（2） 子鏈礦工或驗證節點完成共識驗證並收取部分子鏈Token（t1）作為手續費；
（3） 被選舉出來的跨鏈礦工收取剩餘部分子鏈Token（t2）以及手續費中的全部主鏈Token（S）以及運營池中的部分Token（s2）作為手續費完成跨鏈錨定與廣播；
（4） 一般主鏈礦工收取主鏈交易手續費Token（S’）打包跨鏈交易；
（5） 另一條子鏈錨定礦工讀取主鏈中的跨鏈交易，廣播至目標子鏈中。
以上過程中T=t1+t2，然而一般主鏈礦工收取的主鏈交易手續費S’=R+k，R為原始主鏈出塊獎勵，即當前的20Token，k則為微通脹調節獎勵。
上面出現了運營池的概念，所謂運營池即是在子鏈初期創建時，創建節點通過抵押Token的形式向子鏈注入的啟動資源，運營池中的Token將在跨鏈交易中作為部分獎勵s，輸出給錨定礦工。
假設一個資料的啟動運營池容量是10Token，在跨鏈過程中，每次會分出其中的0.1Token給到跨鏈礦工作為跨鏈礦工的部分獎勵，一次交易過後運營池容量減少為9.9Token。此時，一般主鏈礦工收取到的交易手續費S’=20+0.01，這0.01就是微通脹調節獎勵。
運營池可以由任何該通證用戶選擇再次注入Token，也可由子鏈共識觸發活躍度下限，更改跨鏈礦工獎勵來使得跨鏈礦工獲得的s2為負，即部分跨鏈手續費被存入子鏈運營池。此時，一般主鏈礦工收取的手續費中的微通脹調節獎勵k將為0或轉向負數。這種情況下表明子鏈走向衰退期，或子鏈與主鏈將逐漸通過減少互相激勵而脫離關係。
5. 潛在風險與後期討論
上述模型中可能存在的技術風險包括主鏈區塊當中對於包含跨鏈交易的交易量上限問題，以及過多錨定礦工造成的主鏈負擔過重的問題。
經濟模型方面，存在“損人不利己”攻擊的可能，即通過創建衰減子鏈，影響主鏈礦工與用戶利益的情況。
6. References
[1]. BitInforCharts (2019) Bitcoin Block Size historical chart, Available from: https://bitinfocharts.com/comparison/bitcoin-size.html[Accessed on 02/04/2019]
[2]. Buterin. V(2015) On Slow and Fast Block Times, Available from: https://blog.ethereum.org/2015/09/14/on-slow-and-fast-block-times/[Accessed on 04/04/2019]
[3]. Buterin. V(2019) Merge blocks and synchronous cross-shard state execution, Available from: https://ethresear.ch/t/merge-blocks-and-synchronous-cross-shard-state-execution/1240[Accessed on 03/04/2019]
[4]. Buterin. V(2019) How can we facilitate cross-shard communication?, Available from: https://github.com/ethereum/wiki/wiki/Sharding-FAQ#what-is-the-train-and-hotel-problem [Accessedon 03/04/2019]
[5]. Prestwich. J(2019) What to expect when eths expecting, Chinese Version Translated by EthFans, Available fromhttps://ethfans.org/posts/what-to-expect-when-eths-expecting[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-authoritative-guide-to-blockchain-sharding-part-1[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/unsolved-problems-in-blockchain-sharding[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?v=GNGbd_RbrzE[Accessed on 03/04/2019]
（來源：數秦研究院)