基於SimpleChain Beta的跨鏈交互與持續穩態思考

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，所以在設計上則更爲複雜。

 

因爲分佈式數據庫的交易邏輯爲中心化控制，所以其分片能夠被看做是單純的存儲分片。區塊鏈的分片則主要分爲相對簡單的交易分片：即仍然保持全網絡節點在數據上的全同步，僅經過分片來讓不一樣節點運行不一樣的運算邏輯；和更爲困難的狀態分片：即同時包含了對交易與存儲的分區。狹義上來理解，最直觀的狀態分片其實就是各類分叉，不一樣分叉鏈上各自處理的本身的交易、存儲本身的帳本數據，驗證歷史區塊有效性的時候能夠選擇一直回溯到分叉發生前的區塊，經過快照來確認歷史交易。但這種類型的分片因爲沒有後續跨片交互的機制設計，所以並無提高太多實際價值。

 

那麼狀態分片的跨片交易須要解決的就是如何去相互驗證不一樣分片內交易的有效性了。分片內部交易的有效性由分片內的節點經過共識機制確保，也所以在SimpleChain的設計當中，不一樣的分片內也一樣擁有着區塊鏈的運行機制，所以跨片交易問題在SimpleChain當中就被理解爲跨鏈交易的問題，而分片則被定義爲子鏈。

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證實的工具，所以要驗證分片鏈的有效性須要回溯到可信區塊，再從新計算可信區塊後的區塊狀態一致到當前區塊，才能完成驗證。致使了驗證者增長了工做量。所以在SimpleChain當中，爲了減小驗證者的工做量，相似信標鏈的角色則經過PoW的主鏈來完成。

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

 

錨定礦工在驗證、廣播、和傳遞跨鏈交易時，既做爲子鏈礦工也做爲主鏈礦工存在。然而在主鏈上的礦工數量會比子鏈中的礦工數量多，所以在子鏈中僞造交易傳遞到主鏈的成本將大大低於在主鏈僞造交易寫入子鏈。所以須要一種更爲合理的錨定礦工選舉機制。

 

 

 

圖表 5 子鏈中做惡礦工的機率將會高於主鏈（Alexander Skidanov）

錨定礦工不針對於某個子鏈長期存在，但須要長時間做爲主鏈礦工存在。因爲PoW的主鏈可以容許無狀態SPV證實，所以咱們在SimpleChain中將錨定礦工的選舉經過隨機的形式來完成。

 

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

 

因爲錨定礦工來自於PoW主鏈礦工，所以經過從小到大排列主鏈礦工所計算出的工做量證實計算結果，進行錨定礦工篩選。因爲數值越小的工做量證實計算結果得到的機率越低，所以在錨定礦工預選列表中的排名越高，超出該次錨定礦工數量上限排名的礦工則在當前輪的交易驗證中不參與籤。錨定礦工選舉過程的PoW排序與主鏈延長的PoW同步進行，即主鏈礦工不只將使用工做量證實計算結果得到主鏈SIPC獎勵，還將得到錨定礦工獎勵。錨定礦工獎勵來自於子鏈跨鏈交易發起者所支付的SIPC礦工手續費。

 

在保證主子鏈的一致性問題上，咱們採用了n個確認的機制。當發起一筆跨鏈交易時，子鏈內的區塊應首先得到n個塊高的確認，纔可以經過錨定礦工的驗證並廣播至主鏈上。通過主鏈n各塊高的確認後，才分別將確認後的交易狀態寫入跨鏈交易所涉及的兩個子鏈當中。

 

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

 

4. 主子鏈結構持續穩態的經濟設計

 

 

圖表 6 SIPC模型 （Simplechain Foundation）

SimpleChain在白皮書1.0中提出了主鏈數字資源SIPC的微通脹機制，即隨着子鏈的增長、子鏈活躍度的增長以及對跨鏈交易需求的增長，SIPC的區塊獎勵會在本來的衰減曲線基礎上產生微調（上圖中從綠色虛線變爲黑色實線）。這種微調的結果就是當主鏈SIPC被做爲一種資源，子鏈對其的需求量增長的時候，主鏈出塊獎勵將相應增長，以當前狀態爲例，主鏈出塊獎勵將可能從20SIPC增長到21SIPC。

 

這一設計的目的在於讓子鏈與主鏈上的角色之間的關係更爲穩固。子鏈對主鏈的需求在於經過主鏈協調跨鏈交易，一筆跨鏈交易的過程爲：

 

（1） 子鏈用戶發起跨鏈交易並支付手續費，手續費包含子鏈Token（T）與主鏈SIPC（S）；

（2） 子鏈礦工或驗證節點完成共識驗證並收取部分子鏈Token（t1）做爲手續費；

（3） 被選舉出來的跨鏈礦工收取剩餘部分子鏈Token（t2）以及手續費中的所有主鏈SIPC（S）以及運營池中的部分SIPC（s2）做爲手續費完成跨鏈錨定與廣播；

（4） 通常主鏈礦工收取主鏈交易手續費SIPC（S’）打包跨鏈交易；

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

以上過程當中T=t1+t2，然而通常主鏈礦工收取的主鏈交易手續費S’=R+k，R爲原始主鏈出塊獎勵，即當前的20SIPC，k則爲微通脹調節獎勵。

 

上面出現了運營池的概念，所謂運營池便是在子鏈初期建立時，建立節點經過抵押SIPC的形式向子鏈注入的啓動資源，運營池中的SIPC將在跨鏈交易中做爲部分獎勵s，輸出給錨定礦工。

 

假設一個資料的啓動運營池容量是10SIPC，在跨鏈過程當中，每次會分出其中的0.1SIPC給到跨鏈礦工做爲跨鏈礦工的部分獎勵，一次交易事後運營池容量減小爲9.9SIPC。此時，通常主鏈礦工收取到的交易手續費S’=20+0.01，這0.01就是微通脹調節獎勵。

 

運營池能夠由任何SimpleChain用戶選擇再次注入SIPC，也可由子鏈共識觸發活躍度下限，更改跨鏈礦工獎勵來使得跨鏈礦工得到的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 [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/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]