原文鏈接：https://mp.weixin.qq.com/s/nr7nNMaDZ7b1PP25glrWWA
區(qū)塊鏈利凑，或廣義地稱為分布式賬本技術(shù)（DLT），無疑是2016年度的全球熱詞之一，幾乎每天都有這樣的新聞傳來：世界上的某處又有某家知名機構(gòu)宣布和某家初創(chuàng)公司開展合作矩距，嘗試使用區(qū)塊鏈或分布式賬本技術(shù)解決某個問題捞镰。除此之外，各大咨詢公司浩峡、各類行業(yè)組織及監(jiān)管機構(gòu)也紛紛發(fā)布報告可岂，研討區(qū)塊鏈將如何顛覆我們熟知的世界。
但是翰灾，在區(qū)塊鏈晴朗的天空的遠處缕粹，還有兩朵小小的令人不安的烏云：其一是區(qū)塊鏈的隱私保護，其二是區(qū)塊鏈的性能問題纸淮。對于前者平斩，業(yè)界已有同態(tài)加密、零知識證明咽块、偽匿名等多種對策绘面，只是未臻完美，本文也不準備展開闡述侈沪。對于后者揭璃，其難度相當(dāng)程度與區(qū)塊鏈的類型相關(guān)：就當(dāng)下常見的非許可鏈及許可鏈二分法而言，由于共識節(jié)點之多寡不同峭竣，基礎(chǔ)設(shè)施之良莠不齊塘辅，成員身份之明暗不一，故此非許可鏈的性能提升相對困難皆撩，許可鏈的性能提升相對容易扣墩。然此亦非一定之規(guī)哲银，比如通過代議制可在公有鏈的幾千個節(jié)點中定期選舉產(chǎn)生一個為數(shù)較小的共識節(jié)點集合，此時也可借鑒許可鏈的優(yōu)化技術(shù)提升性能呻惕。
有鑒于此荆责，本文將縮小關(guān)注點，重點關(guān)注許可鏈的性能優(yōu)化問題亚脆。由于PBFT算法[1]及其變體在開源許可鏈項目中得到的廣泛應(yīng)用做院，本文將主要以PBFT算法為例展開討論。
關(guān)鍵詞：區(qū)塊鏈 許可鏈 性能優(yōu)化

一濒持、不忘初心

不完美是這個世界的重要特征键耕，如張愛玲所說的：“有人說過‘三大恨事’是‘一恨鰣魚多刺，二恨海棠無香柑营，三恨紅樓夢未完’屈雄。”對于每一位架構(gòu)師而言官套，“優(yōu)化”是個永恒的話題酒奶，無論多完美的產(chǎn)品都總有改進之處，而且很多時候一方面的改進必須以另一方面的犧牲為代價奶赔。經(jīng)驗告訴我們惋嚎，在系統(tǒng)和算法的優(yōu)化過程中，有百利無一弊的帕累托改進縱然不是沒有站刑，至少也是稀罕事另伍，最常見的優(yōu)化都會涉及某種犧牲和代償。作為優(yōu)化的最終指導(dǎo)笛钝，業(yè)務(wù)目標優(yōu)先級的明確是最首要的事情质况。“優(yōu)化”所需的“取舍”玻靡，一定是服務(wù)于業(yè)務(wù)目標的结榄。鑒于此，本文后續(xù)所說的各種優(yōu)化思路應(yīng)被理解為僅是參考而非必選囤捻，實際項目中仍要“不忘初心”——所謂“初心”臼朗，就是業(yè)務(wù)目標。

二蝎土、硬件加速

硬件加速可能是最簡單粗暴的性能優(yōu)化方案视哑，在區(qū)塊鏈的發(fā)展歷史中也有跡可循。比特幣的挖礦芯片極大加快了SHA256難題的解題速度誊涯，使得使用者相對于未使用者而言獲得了相當(dāng)?shù)膬?yōu)勢挡毅。但是由于比特幣的動態(tài)難度調(diào)整機制的存在，挖礦芯片的升級換代本身并不能縮短比特幣的平均出塊時間暴构，也無助于比特幣吞吐量的提升跪呈，所以稱其為“性能優(yōu)化方案”得看是在什么意義上說事段磨。
然而硬件加速確實可以做得更多，最容易想到的是對非對稱密鑰簽名的并行驗證耗绿。以FPGA為例苹支，雖然其主頻比通用處理器為低（典型值如百MHz之于GHz），但其專用電路可以進行并行流水線處理误阻，在一個時鐘周期內(nèi)實現(xiàn)更多操作债蜜。且FPGA可提供遠比通用處理器更多的寄存器，從而可以并行驗證多個簽名究反。因此在自動化交易領(lǐng)域寻定，硬件加速早已獲得廣泛應(yīng)用[2],類似思想自然可以用于區(qū)塊鏈的加速。
對于安全性要求很高的許可鏈來說奴紧，硬件加速還有其他附加收益特姐。正如網(wǎng)銀若使用USB Key可較使用文件證書有更高安全性一般，許可鏈私鑰的存放若固化于可靠硬件（硬件錢包）也可提升其安全性黍氮。另一方面，硬件加速會帶來一定的研發(fā)及實施成本浅浮，但鑒于許可鏈的玩家都具有相當(dāng)?shù)慕?jīng)濟實力沫浆，通常不構(gòu)成問題。

三滚秩、共識算法選擇

共識算法的選擇是區(qū)塊鏈的核心設(shè)計考量之一专执。就目前公開的項目看，相當(dāng)多的許可鏈直接采用了傳統(tǒng)的拜占庭容錯算法（BFT）郁油，其中又以經(jīng)典的PBFT算法及其變體最為常見本股。這是因為在惡意節(jié)點數(shù)不超限制的前提下，BFT類算法可以支持較高的吞吐量和極短的終局時間桐腌，其正確性和活動性又可被嚴格證明拄显，非常合乎大機構(gòu)的需求。由于BFT算法為了達成單次共識一定需要借助消息的多輪組播案站，有些甚至是多對多的消息組播躬审，比如在PBFT算法中需要1對N的pre-prepare消息組播、N對N的prepare消息組播和commit消息組播蟆盐，受互聯(lián)帶寬的限制一般不適用于共識節(jié)點數(shù)較大的情形承边，但對于成員節(jié)點數(shù)不大、對交易終局性要求較高的許可鏈而言卻正可揚長避短石挂。反觀公有鏈中使用的POW[3]博助、DPOS[4]等算法，由于每一輪共識都不可能通過成員間反復(fù)傳播比對消息來實現(xiàn)痹愚，因此需要通過延長終局時間來間接校驗富岳，遂有“等待6個以上塊的確認”等概率性的終局性規(guī)則出現(xiàn)蛔糯。由此可見，共識節(jié)點數(shù)和終局性時間之間存在矛盾城瞎，每一種區(qū)塊鏈都在基于自身目標進行取舍渤闷，只有是否適合自己，并無抽象的優(yōu)劣高下脖镀。
學(xué)術(shù)界已經(jīng)提出了各種BFT[5] [6] [7]算法飒箭，在此難以一一枚舉。面對數(shù)量眾多的BFT算法蜒灰，如何結(jié)合自身需求選擇合適的BFT算法是一個大課題弦蹂，要求區(qū)塊鏈的設(shè)計者同時深入理解業(yè)務(wù)需求和算法細節(jié)，在此僅舉幾例以供賞鑒强窖。
Aardvark算法[5]是一個相當(dāng)值得關(guān)注的BFT算法凸椿，也被稱為RBFT（Robust BFT）算法，其設(shè)計指導(dǎo)思想在于提供一種“能夠真正容忍拜占庭錯誤的拜占庭算法”翅溺。其作者通過研究認為脑漫，當(dāng)下的很多BFT算法，包括PBFT和Zyzzyva[6]算法在內(nèi)咙崎，其設(shè)計思路都是首先考慮盡力優(yōu)化無拜占庭錯誤存在時的正確性和系統(tǒng)性能优幸，其次作為兜底方案只是確保即使存在拜占庭錯誤系統(tǒng)也多少能夠繼續(xù)推進而已，并不去考慮面臨拜占庭錯誤時的系統(tǒng)性能褪猛。其結(jié)果是网杆，雖然論文中公布的理想情況測試數(shù)據(jù)一個比一個漂亮，當(dāng)真面臨精心設(shè)計的惡意節(jié)點協(xié)作攻擊時系統(tǒng)性能就會急劇下降到接近癱瘓伊滋，因此雖然名為拜占庭容錯算法碳却，其實并不能在工程實用意義上容忍拜占庭錯誤。通過對PBFT算法的改良笑旺，RBFT算法使得面對最好和最壞的情況系統(tǒng)的性能都能大致保持不變昼浦，從而提供了真正實用的BFT。正如我們所熟知的那樣燥撞，世上沒有免費的午餐座柱，其最壞情況的性能提升實際是以降低最好情況的性能換取的。如果區(qū)塊鏈支持的業(yè)務(wù)要求在最壞情況下都能保持良好的性能物舒，則基于RBFT算法構(gòu)建區(qū)塊鏈是值得考慮的色洞。如果區(qū)塊鏈的應(yīng)用場景更關(guān)注正常情況的高性能，且能夠容忍極端情況下的系統(tǒng)活動性喪失冠胯，則傳統(tǒng)的PBFT算法可能更為合適火诸。
開源項目Chain提出了自身獨特的共識算法坏瞄，稱為Federated Consensus[7]玖翅，曾經(jīng)也用過Simplified BFT的名稱挑豌，筆者將其理解為PBFT算法的裁剪版本（不要將其與HyperLedger Fabric 1.0使用的SBFT算法[8]混淆起來姐霍，后者是PBFT算法的增益版本，將check point的穩(wěn)定化變?yōu)槊恳惠喒沧R皆需的第四階段）盯荤。在chain之中馋吗，有一個固定的、不可變的塊生成者（block generator）秋秤，其唯一的任務(wù)就是將交易打包進待簽名塊后群發(fā)給N個塊簽名者（block signor）驗證宏粤。每個塊簽名者如果驗證通過了塊，就將自己對待簽名塊的簽名回送給塊生成者灼卢。塊生成者只要搜集到M個（M超過N的半數(shù)）來自不同塊簽名者對此的合法簽名绍哎，對塊的驗證即告通過，此時塊生成者只需要將帶有M個簽名的塊群發(fā)出去鞋真，接收者看到了M個簽名就認為共識已經(jīng)完成崇堰。容錯能力方面，這種算法在惡意的塊簽名者不超過（2M–N–1）個時有效涩咖，且算法明確注明不能承受塊生成者出現(xiàn)拜占庭錯誤的情形海诲。值得注意的是，由于其消息模式完全類似RAFT算法[9]和 2PC協(xié)議檩互，因此撇開簽名和驗簽的開銷不談饿肺，性能上有望接近非拜占庭容錯的RAFT算法，實現(xiàn)上也可以簡化很多盾似，畢竟傳統(tǒng)拜占庭容錯算法最大的復(fù)雜性正是來自于自動處理塊生成者的拜占庭錯誤。仔細分析可以看出雪标，此算法的性能提升和開發(fā)簡化完全來自于犧牲了塊生成者的拜占庭容錯能力零院，也犧牲了塊生成者出問題時的系統(tǒng)活動性。
社區(qū)中類似的對PBFT算法的裁剪尚有多種村刨，筆者對此的看法是：由于PBFT算法的每一階段都有其特殊作用告抄，故除非是裁剪者真正清楚裁剪的代價，業(yè)務(wù)目標也能夠支持此類裁剪嵌牺，否則不要輕易動手改造PBFT算法打洼。
前文曾述及專用硬件設(shè)備的使用。如果區(qū)塊鏈的設(shè)計者能夠投信于特殊的硬件設(shè)備逆粹，還可在共識方面獲得更大的收益募疮。比如Intel的Sawtooth Lake[10]項目構(gòu)建于Intel自身的SGX技術(shù)之上，其中提出的POET（Proof of Elapsed Time）算法提供了一種POW算法的替代方案僻弹，可以在不耗費大量電力的同時在公有鏈中達成類POW共識阿浓。可信硬件設(shè)備在許可鏈中的使用尚不止此蹋绽，比如還可以利用可信硬件設(shè)備構(gòu)建最多能夠容忍接近半數(shù)惡意節(jié)點的區(qū)塊鏈芭毙，突破普通BFT算法33%惡意節(jié)點的限制[11]筋蓖，恐繁不錄。
共識算法雖有多種退敦，但值得慶幸的是在目前的許可鏈設(shè)計中將共識算法抽象化粘咖、模塊化的趨勢已經(jīng)出現(xiàn)。通過將共識算法設(shè)計為可插拔侈百、可替換的組件瓮下，用戶在使用區(qū)塊鏈時可以根據(jù)自身需要選擇最合適的共識算法（甚至可以選用RAFT一流非拜占庭容錯的共識算法），無需修改系統(tǒng)的其他部分设哗。

四唱捣、共識算法性能優(yōu)化：以PBFT為例

PBFT協(xié)議的論文中自帶了若干優(yōu)化，不在此重復(fù)細節(jié)网梢。有幾處值得關(guān)注震缭，其一是，文中所說用基于對稱密鑰的MAC（消息認證碼）替代基于非對稱密鑰的數(shù)字簽名一法战虏，仍有可以討論之處：雖然法律和監(jiān)管要求用戶指令使用非對稱密鑰完成數(shù)字簽名拣宰，但法律和監(jiān)管者是否要求許可鏈的共識節(jié)點間傳遞的一切信息都使用數(shù)字簽名而非MAC？由于法律和監(jiān)管者未必要求系統(tǒng)內(nèi)部不同組件之間處處啟用非對稱加密完成通信烦感，因此可能尚留有部分使用MAC替代數(shù)字簽名的空間可資利用巡社。其二則是幾處用摘要發(fā)送替代消息發(fā)送的優(yōu)化，此法大大降低了帶寬占用手趣，從而使得網(wǎng)絡(luò)數(shù)據(jù)傳送量趨近于用來傳統(tǒng)的RAFT算法晌该，只在內(nèi)部消息傳送跳數(shù)上略有增加，因此合理的判斷是绿渣，只要優(yōu)化得當(dāng)朝群，PBFT集群的吞吐量應(yīng)該和RAFT集群接近，時延只略有上升中符，但不應(yīng)存在數(shù)量級的差異姜胖。雖然理論推演結(jié)論如此，鑒于如今基于PBFT的高性能區(qū)塊鏈尚不多見淀散，故筆者擬補充幾點PBFT原始論文未能提及的性能優(yōu)化方案以供參考右莱。

1. 打包

因為單個區(qū)塊通常包含不止一筆交易，而共識或稱出塊明顯是按塊進行的档插，所以打包很可能是在實施區(qū)塊鏈時最為普通的優(yōu)化方案慢蜓。打包可以將共識節(jié)點間進行簽名和驗簽的開銷在塊中的每筆交易上平攤，從而降低總體的開銷阀捅。更重要的是胀瞪，即使區(qū)塊鏈的實現(xiàn)者采用最簡單的停等模式來實現(xiàn)PBFT算法，也即在第N塊達成共識前不啟動第N+1塊的共識凄诞，單純依靠打包即可顯著提升系統(tǒng)的吞吐量》考慮到許可鏈的成員節(jié)點可能跨地域分布，假設(shè)節(jié)點最大距離2000公里汛蝙，則在全部節(jié)點間完成PBFT所要求的3輪通信至少耗時30ms，使用停等模式1秒最多完成33輪共識（以上計算還尚未計入報文經(jīng)過網(wǎng)絡(luò)設(shè)備時的額外延時等其他開銷）窖剑。如果1輪共識只能如論文所說對單個消息完成共識，則每秒吞吐量只是33筆西土，雖然好于比特幣，但若和RAFT的優(yōu)秀實現(xiàn)相比明顯存在問題需了。如果每輪共識針對打包后的一組消息進行，吞吐量雖不能線性提升肋乍，但也可提升明顯，在中心化系統(tǒng)性能優(yōu)化中有過經(jīng)驗的人應(yīng)該都不難理解這一點墓造。
如果打包方案僅限于此，仍不能減少區(qū)塊中每筆外部交易帶來的驗簽工作觅闽，雖然可以用前文所述硬件方案予以并行處理，但還有結(jié)合業(yè)務(wù)特征進一步優(yōu)化的可能。許可鏈的共識節(jié)點通常是B端而非C端禽拔，C端客戶通過B端客戶間接接入?yún)^(qū)塊鏈刘离。如果業(yè)務(wù)允許，共識節(jié)點作為C端客戶的代理睹栖，可以要求C端客戶在提交請求前打包簽名再一并提交硫惕，比如原本客戶對每一筆申報都要獨立簽名的，現(xiàn)在可以要求客戶可將最多10筆申報打成一個小包并一次性簽名提交野来，如此驗簽工作量直接可以降為原來的若干分之一恼除，若再輔以前述并行硬件處理方案，則系統(tǒng)性能可有明顯提升。

2. 異步模式

通過上面的分析可以看出豁辉，如果限于停等模式令野，不要說PBFT集群，哪怕是在RAFT集群中吞吐量也不能做到最優(yōu)徽级。經(jīng)驗表明气破，在RAFT集群中要想進一步提升吞吐量可以使用所謂“異步”模式，也即主節(jié)點甫一發(fā)出第N號待共識報文即可立刻發(fā)出第N+1號待共識報文餐抢，完全無需等到集齊超過半數(shù)的確認應(yīng)答现使，同樣的經(jīng)驗也適用于PBFT集群。在這種模式下旷痕，pre-prepare/prepare/commit中的任一階段都可以有多個區(qū)塊同處其中碳锈，網(wǎng)絡(luò)帶寬得到最大利用，系統(tǒng)吞吐量也能接近對等的RAFT集群欺抗。
另一方面售碳，異步模式下有一種更激進的策略：構(gòu)建一個有區(qū)塊但沒有鏈的“區(qū)塊鏈”。觀察PBFT算法即可發(fā)現(xiàn)佩迟，PBFT算法一次只是對一個數(shù)組特定下標的內(nèi)容完成共識团滥，數(shù)組元素是否另行勾連成鏈則全不相干。PBFT算法允許先對第1001號元素達成共識报强，再回頭對第1000號元素達成共識灸姊，這點很類似于以太坊CASPER協(xié)議的某個早期版本[12]。其好處是有望進一步降低共識達成的時延秉溉，缺點當(dāng)然是增加了實現(xiàn)的復(fù)雜度力惯。鑒于基于prevHash的勾連成鏈便于迅速比對完整歷史，筆者傾向于若非萬不得已不需要采用此種策略召嘶。

3. 并行執(zhí)行

這里的并行執(zhí)行特指PBFT算法執(zhí)行的內(nèi)部并行父晶。前面提及利用硬件并行驗簽的手法，并行執(zhí)行的思路當(dāng)然還可以發(fā)揚光大弄跌。此處可以參考Disruptor[13]的性能優(yōu)化思路铛只，一方面通過共享緩沖區(qū)消除不必要的內(nèi)存拷貝，一方面將多個原來單線程順序完成的操作分拆至多個線程并行執(zhí)行以提升處理速度淳玩。實因此種優(yōu)化并非區(qū)塊鏈獨有蜕着，因此只略提一二。

4. 減少傳輸量

PBFT協(xié)議中常常用到一對多的組播锤悄，根據(jù)跨機構(gòu)的網(wǎng)絡(luò)互聯(lián)情況铁蹈，這種組播不一定真能基于UDP組播實現(xiàn)众眨。如果跨機構(gòu)的網(wǎng)絡(luò)互聯(lián)只允許走TCP娩梨，此時網(wǎng)卡/網(wǎng)絡(luò)帶寬可能會成為瓶頸狈定。一種解決方法是使用P2P網(wǎng)絡(luò)和Gossip協(xié)議來減少網(wǎng)卡上實際外發(fā)的數(shù)據(jù)量，比如從直接給另外21個節(jié)點各發(fā)送一份pre-prepare消息變?yōu)橹唤o邏輯相鄰的5個節(jié)點各發(fā)送一份pre-prepare消息措嵌。另一種可以疊加使用的解決方法是嘗試引入壓縮算法以期降低數(shù)據(jù)傳送量企巢，但此種方法是否奏效相當(dāng)依賴于客戶消息的可壓縮性浪规，即使奏效探孝，也還需要觀察額外的壓縮解壓操作引發(fā)的資源消耗是否會引發(fā)新的問題顿颅，所以也得靈活應(yīng)變粱腻。
尚有另一種思路也可歸入此中，其要旨是將完整數(shù)據(jù)的傳播及存儲交由較小的集群完成（此集群甚至未必要是BFT集群），在較大BFT集群中針對數(shù)據(jù)指紋進行共識遇革，如此也可降低BFT集群中需要傳播的數(shù)據(jù)量萝快。公有區(qū)塊鏈和IPFS[14]的結(jié)合揪漩、BigchainDB[15]對Casaandra數(shù)據(jù)庫的運用、Polkadot[16]分離出單獨的availability guarantors角色冰更，都是很好的案例蜀细。與此同時奠衔，對這種設(shè)計作出的犧牲也應(yīng)該有清晰的認識塘娶，并結(jié)合實際面臨的狀況予以評估刁岸。

五难捌、共識分層和性能優(yōu)化

稍加思考即可發(fā)現(xiàn)，區(qū)塊鏈中其實存在兩個獨立層面的共識员淫，其一可稱為“輸入共識”介返，其含義是各節(jié)點對指令的順序及內(nèi)容達成共識圣蝎，類似傳統(tǒng)數(shù)據(jù)通信的會話層衡瓶，不牽涉業(yè)務(wù)操作哮针；其二可稱為“輸出共識”，其含義是業(yè)務(wù)系統(tǒng)受輸入的驅(qū)動等太，狀態(tài)不斷發(fā)生躍遷缩抡，同時產(chǎn)生一系列輸出，此時各參與方對業(yè)務(wù)系統(tǒng)進入的狀態(tài)及產(chǎn)生的輸出達成共識 压真。此非孤明之見榴都，Corda 區(qū)分交易的uniqueness和validity二者[17]嘴高， Polkadot區(qū)分cononicality與validity二者拴驮，都應(yīng)是有見于此柴信。
雖然這兩層共識在設(shè)計上可以分離随常，但不同區(qū)塊鏈對此的回應(yīng)差別很大绪氛，將其說為區(qū)塊鏈設(shè)計時面臨的一大抉擇也不為過≌迹總的來說有三種方式：
第一種方式是只提供輸入共識臂痕，此以Factom[18]項目為例握童。Factom只對數(shù)據(jù)內(nèi)容和順序進行共識澡绩，把對數(shù)據(jù)的后續(xù)檢驗及處理交給其他應(yīng)用程序完成。由于不做輸出共識，這種區(qū)塊鏈很可能不內(nèi)置智能合約功能昙读。
第二種方式是以緊耦合的方式同時提供輸入共識和輸出共識蛮浑，典型案例如以太坊沮稚。以太坊的區(qū)塊頭中不僅包含交易根，也包含狀態(tài)根障般，通過一套機制同時達成對交易和終態(tài)的共識挽荡。
第三種方式是以分離的方式同時提供輸入共識和輸出共識定拟，典型案例如Fabric 1.0[19]的設(shè)計青自。在Fabric 1.0中驱证，輸入共識在Orderer之間達成雷滚，Orderer只看到數(shù)據(jù)，并不理解任何業(yè)務(wù)含義呆万，輸出共識則通過Endorsor谋减、Committer和應(yīng)用層CheckPoint在一定程度上實現(xiàn)出爹。
若按區(qū)塊鏈實現(xiàn)的復(fù)雜程度來排序，第一種自然最簡單总寻，第二種次之渐行，第三種最復(fù)雜铸董。若按是否有利于性能優(yōu)化來排序粟害，則是第一種最佳悲幅，第三種次之，第二種最不利于性能優(yōu)化芋哭。取以太坊為例减牺，為了同時達成兩層共識拔疚，必須在輸入共識后串行執(zhí)行業(yè)務(wù)邏輯稚失，如此方才完成一輪共識恰聘。業(yè)務(wù)代碼本身就可能很復(fù)雜晴叨，而以太坊的狀態(tài)通常會保存在KV數(shù)據(jù)庫中兼蕊，完成一次Patricia樹[20]訪問又可能需要多次數(shù)據(jù)庫讀寫，因此共識速度難以提升产禾。另有一重緣故：出塊者必須自己先執(zhí)行一遍業(yè)務(wù)代碼獲得終態(tài)指紋后才能出塊，但出塊只是提議妄痪，存在交易歷史稍后被逆轉(zhuǎn)的可能拌夏，哪怕采用BFT算法也是一樣。如果交易歷史被逆轉(zhuǎn)盹愚，原出塊者必須先回滾原有交易皆怕。為了實現(xiàn)交易回滾愈腾，正常執(zhí)行時就得增加額外操作和資源占用，同時還需要提供回滾邏輯悦即，如以太坊就需通過Patricia樹支持狀態(tài)回滾辜梳，但付出了很大性能代價作瞄。
第一第三種方式下宗挥，業(yè)務(wù)邏輯和輸入共識可以并行執(zhí)行契耿、不同業(yè)務(wù)邏輯也可能并行執(zhí)行蛤吓，因此最有利于性能優(yōu)化会傲。第一種方式更是給予用戶更大的自由拙泽，用戶可以完全甩開輸出共識顾瞻，也可以結(jié)合應(yīng)用特征實現(xiàn)自己的輸出共識荷荤，因此留出更大的性能優(yōu)化空間移稳。

六个粱、狀態(tài)通道與分區(qū)設(shè)計

閃電網(wǎng)絡(luò)[21]可能是最有名的狀態(tài)通道應(yīng)用案例。其論文非车巨保晦澀塞椎，但原理卻很簡單睛低。代碼性能調(diào)優(yōu)的經(jīng)驗提示我們：優(yōu)化編譯钱雷、改進算法、調(diào)整數(shù)據(jù)結(jié)構(gòu)等方式雖然很重要也很管用从铲，但怎么能比得上“根本不執(zhí)行”的強悍名段？既然在比特幣區(qū)塊鏈中優(yōu)化性能如此艱難泣懊，為何不盡可能將交易放到鏈外執(zhí)行馍刮？以比特幣區(qū)塊鏈為后盾，在鏈下實現(xiàn)真正的點對點微支付交易警没，區(qū)塊鏈處理能力的瓶頸被徹底打破振湾，時延押搪、最終性、容量甚至隱私問題也迎刃而解续语，這就是比特幣“閃電網(wǎng)絡(luò)”（Lightning Network）的基本思路绵载。
一般而言，通過狀態(tài)通道技術(shù)焚虱，兩方或有限多方得以共享一套狀態(tài)鹃栽，狀態(tài)必須局部的民鼓，也即其變更只影響狀態(tài)本身，不及其余夯到。初態(tài)通過區(qū)塊鏈創(chuàng)建耍贾，稱為建立一個“狀態(tài)通道”路幸，其后對狀態(tài)的變更都在鏈外進行简肴，對外界保密，通過各方聯(lián)合簽名實現(xiàn)狀態(tài)變更合法性的確認能扒，并通過狀態(tài)序號等方式在眾多合法狀態(tài)中區(qū)分出最新版本。在出現(xiàn)爭議時观话，只要向區(qū)塊鏈出示最新版本的合法狀態(tài)频蛔，即可關(guān)閉狀態(tài)通道并根據(jù)預(yù)設(shè)邏輯完成爭議裁決晦溪。
分區(qū)（Sharding）以區(qū)塊鏈互操作技術(shù)為基礎(chǔ)三圆，輔以合理的業(yè)務(wù)分區(qū)避咆，雖然易于理解但很難實現(xiàn)查库，即使對于許可鏈也是一樣樊销，其主要挑戰(zhàn)在于單純增加分區(qū)未必能同步提升總吞吐量，尤其當(dāng)分區(qū)間通信量很大更是如此裤园∨±浚考慮到即使對于傳統(tǒng)的中心化系統(tǒng)要實現(xiàn)通用的水平擴展也非易事强法，所以必須降低對于萬能靈丹的心理預(yù)期饮怯。另一方面蓖墅，從云計算论矾、大數(shù)據(jù)、雙11獲得的經(jīng)驗告訴我們饱亿，充分利用業(yè)務(wù)特征將是緩解此類問題的有效手段彪笼。建議讀者認真揣摩RSCoin[22]的分區(qū)設(shè)計配猫，自當(dāng)有所會心杏死。

七淑翼、結(jié)語

許可鏈技術(shù)還在飛速發(fā)展玄括，由于作者水平所限，本文內(nèi)容一方面未必最新，尤其是不能涵蓋未公開的獨門秘技洁墙，一方面也未能面面俱到热监，有些課題如虛擬機優(yōu)化孝扛、區(qū)塊鏈動態(tài)配置切換[23]等無法一一予以探討苦始。總而言之慌申，技術(shù)是靈活的陌选，只要不忘初心，觸類旁通，則優(yōu)化之道自當(dāng)無窮如天地咨油，不絕似江河您炉。

作者簡介：朱立 上交所技術(shù)公司架構(gòu)師，主要研究方向為高可用架構(gòu)役电、區(qū)塊鏈赚爵。
lzhu@sse.com.cn

參考文獻

[1]M. Castro and B. Liskov, “Practical Byzantine fault-tolerance and proactive recovery,” ACM Transactions on Computer Systems, vol. 20, no. 4, pp. 398–461, Nov. 2002.
[2] A. MacArthur, “FPGA's - Parallel Perfection?,” Automated Trader, issue 02, July. 2006
[3] Satoshi Nakamoto, “ Bitcoin: A Peer-to-Peer Electronic Cash System”
https://bitcoin.org/bitcoin.pdf, 2008.
[4] “Delegated Proof-of-Stake Consensus,”
https://bitshares.org/technology/delegated-proof-of-stake-consensus/, 2014
[5] A. Clement, E. Wong, L. Alvisi, M. Dahlin, and M. Marchetti, “Making Byzantine fault tolerant systems tolerate Byzantine faults,” in Proc. of NSDI’09, 2009.
[6] Kolta, R., Alvisi, L., Dahlin, M., Clement, A., and Wong, E., “Zyzzyva: speculative Byzantine fault tolerance,” In SOSP (2007).
[7] “Federated Consensus

https://chain.com/docs/protocol/papers/federated-consensus, 2016
[8] S. Schubert, “Simple BFT,
https://jira.hyperledger.org/browse/FAB-378, 2016
[9] D. Ongaro, and J. Ousterhout, “In Search of an Understandable Consensus Algorithm,” In Proc ATC’14, USENIX Annual Technical Conference (2014), USENIX.
[10] Sawtooth Lake Project Homepage

http://intelledger.github.io/
[11] G.S.Veronese,M.Correia,A.N.Bessani,L.C.Lung,andP.Ver′?ssimo, “Ef?cient byzantine fault-tolerance,” IEEE Trans. Computers, vol. 62, no. 1, pp. 16–30, 2013.
[12] V. Buterin, “Understanding Serenity, Part 2: Casper

https://blog.ethereum.org/2015/12/28/understanding-serenity-part-2-casper/ , 2015
[13] M. Fowler, “Dissecting?the?Disruptor:?Why it’s so fast

http://mechanitis.blogspot.com/2011/07/dissecting-disruptor-why-its-so-fast.html, 2011
[14] J. Benet, “IPFS-Content Addressed, Versioned, P2P File System(Draft 3)

https://github.com/ipfs/ipfs/blob/master/papers/ipfs-cap2pfs/ipfs-p2p-file-system.pdf
[15] T. McConaghy et al , “BigchainDB, A Scalable Blockchain Database
https://www.bigchaindb.com/whitepaper/, 2016
[16] G. Wood, “POLKADOT: VISION FOR A HETEROGENEOUS MULTI-CHAIN FRAMEWORK. Draft 1

https://raw.githubusercontent.com/polkadot-io/polkadotpaper/master/PolkaDotPaper.pdf
[17] R. G. Brown, “Corda: An introduction

https://www.r3cev.com/blog/2016/8/24/the-corda-non-technical-whitepaper, 2016
[18] P. Snow, et al., “Factom: Business Processes Secured by Immutable Audit Trails on the Blockchain, ”

https://github.com/FactomProject/FactomDocs/blob/master/Factom_Whitepaper.pdf
[19] E. Androulaki, et al., “Next Consensus Architecture Proposal, ”
https://github.com/hyperledger/fabric/blob/f19a1e6988b62c9ba566d6268d5baedea36061b8/proposals/r1/Next-Consensus-Architecture-Proposal.md
[20] Ethereum, “Patricia Tree, ”
https://github.com/ethereum/wiki/wiki/Patricia-Tree
[21] J. Poon, and T. Dryja, “The Bitcoin Lightning Network: Scalable Off-Chain Instant Payments, ”

https://lightning.network/lightning-network-paper.pdf, 2016
[22] G. Danezis, S Meiklejohn, “ Centrally Banked Cryptocurrencies,”

https://arxiv.org/abs/1505.06895, 2015
[23] A. Bessani, J. Sousa, “State Machine Replication for the Masses with BFT-SMART,”In 44th Annual IEEE/IFIP International Conference on Dependable Systems and Networks, DSN 2014, pages 355–362, 2014