作者：靈巧@螞蟻安全實驗室
原文鏈接：https://mp.weixin.qq.com/s/oILVBQSIG5PDpBS4rCCh8A

同濟大學教授史揚：

拜占庭將軍問題的研究始于1982年，由LeslieLamport等學者提出。它以古代拜占庭帝國的將軍們圍攻城市為背景，講述了一個關于忠誠與背叛的故事，并且巧妙的蘊含了現代分布式系統的一致性問題。正是由于在分布式和并行系統的理論與實踐方面的巨大成就， Lamport在2013年成為圖靈獎得主。

拜占庭容錯（BFT）則給出了存在“叛徒”時解決拜占庭問題的方法，它不僅僅在許可鏈中受到高度的重視，在公有鏈中也有廣泛的應用，例如由另一位圖靈獎得主Sivio Micali 等設計的Algorand 這一PoS機制中，相關技術也被反復的使用。

螞蟻安全實驗室的這篇分享首先介紹了BFT的基本概念，隨后以Fabric和DPoS協議等為例介紹了BFT在區塊鏈中的應用；在此基礎上，對BFT協議的威脅模型展開探討，分別分析了理想世界和現實世界的威脅模型，以及在BFT協議被攻破后，對區塊鏈安全會有哪些影響。文章內容豐富，敘述詳盡，可以供研究和開發區塊鏈系統的讀者們參考，相信會對分析甚至是提高區塊鏈系統的安全性有所裨益。

關于區塊鏈安全，特別是智能合約的安全性方面，螞蟻安全實驗室還發表了一系列頗有價值的文章。希望螞蟻安全實驗室可以繼續為提高區塊鏈系統與應用的安全性做出的貢獻，也非常感謝他們的分享。

01 引言

共識算法是區塊鏈的核心基石，是區塊鏈系統安全性的重要保障。區塊鏈的共識算法中，除了常見的工作量證明（PoW，Proof of Work）和權益證明（PoS，Proof of Stake）外，還有拜占庭容錯（Byzantine Fault Tolerance, BFT）共識算法。拜占庭容錯（Byzantine Fault Tolerance, BFT）共識算法是由拜占庭將軍問題衍生出來的共識算法。

拜占庭將軍問題（Byzantine Generals Problem），首先由 Leslie Lamport 與另外兩人在1982年提出。故事大概是這么說的：

一組拜占庭將軍分別各率領一支軍隊共同圍困一座城市。為了簡化問題，將各支軍隊的行動策略限定為進攻或撤離兩種。因為部分軍隊進攻、部分軍隊撤離可能會造成災難性后果，因此各位將軍必須通過投票來達成一致策略，即所有軍隊一起進攻或所有軍隊一起撤離。因為各位將軍分處城市不同方向，他們只能通過信使互相聯系。在投票過程中每位將軍都將自己投票給進攻還是撤退的信息通過信使分別通知其他所有將軍，這樣一來每位將軍根據自己的投票和其他所有將軍送來的信息就可以知道共同的投票結果而決定行動策略。

這就是拜占庭將軍問題。解決拜占庭將軍問題的協議稱為拜占庭將軍協議，也稱拜占庭容錯協議 Byzantine Fault Tolerance，簡稱 BFT 協議。

Byzantine錯誤，或者稱為任意錯誤，指實體(服務器或者客戶端)被攻擊者完全控制，攻擊者可以根據自己的意愿和環境情況執行各種操作。當實體發生Byzantine錯誤時，行為是不可預測的，常見的可能行為包括:

●停機，錯誤實體不響應其他服務器和客戶端所發送的信息；

●發送正確或錯誤的消息，造成網絡擁塞，使得其它正確的服務器和客戶端不能正常地接收、發送和處理信息；

●篡改和轉發消息，使得頻繁地出現操作沖突，降低系統性能。

BFT 協議討論的是允許存在少數節點發生 Byzantine 錯誤的場景下如何達成共識的問題。BFT 協議最主要的目的是保證運行協議的各服務節點保持狀態一致，即：

●相同的處理邏輯。通常，各服務器運行相同代碼。

●相同的初始狀態。在系統初始化時，配置為相同的初始狀態。

●執行相同的操作序列。各服務器按照一致順序處理客戶端的多個請求消息，保證狀態變化的一致性。

BFT 協議早在區塊鏈提出之前，就在一些行業被廣泛應用，如航空、航天、核電行業。這些行業和區塊鏈賬本一樣，對穩定性和一致性的要求非常之高，要求即使一些節點發生了 Byzantine 錯誤，也要保證系統穩定和一致地運行下去。這在區塊鏈上就表現為鏈不停擺、不分叉。

BFT 協議對編程語言沒有要求，只要能夠實現協議算法，滿足實現過程中沒有漏洞，可以使用任何編程語言。但是在實際的實現和運行過程中，很難做到沒有漏洞，現實世界中 BFT 協議面臨多種威脅。當 BFT協議作為區塊鏈的共識算法時，攻擊 BFT 會對區塊鏈產生怎樣的影響呢？

本文共分為上下兩集：上集第 2 節介紹了BFT協議在區塊鏈的應用，我們選取了有代表性的應用案例。下集第 1 節分析BFT協議的威脅模型，分別分析了理想世界和現實世界的威脅模型。第 2 節分析了BFT協議被攻破后，對區塊鏈安全會有哪些影響。第 3 節做了簡要總結。

02 BFT 協議在區塊鏈的應用

2.1 PBFT -- Fabric 共識協議

PBFT 是第一個性能能滿足實用要求的協議，也是后續眾多變種協議主要的參考對象。PBFT 由 n=3f + 1 臺服務器組成，最多容忍 f 臺 Byzantine 錯誤服務器，算法復雜度為O(N2)。由于隨著節點的增加，PBFT 的性能會顯著下降，所以 PBFT 更多的是應用在聯盟鏈中，如 Fabric。

在正常情況下，PBFT 使用如下通信過程協商請求消息的操作順序。由特定的、負責確定順序的服務器（稱為 Primary 圖中的 0）發起操作。當 Primary 收到客戶端的請求消息后，確定相應的順序，轉發給其它服務器，通過 2 步通信（Pre-prepare 和 Prepare）保證至少 f+1 臺正確服務器就客戶端請求的執行順序達成一致，然后再經 1 步 Commit 通信通知各服務器。

圖中 c 表示客戶端，0 表示主節點，1表示副本節點1，2表示副本節點2，3表示副本節點3，類似的，i 表示副本節點i

1.REQUEST：

客戶端c向主節點p發送<REQUEST, o, t, c>請求。o: 請求的具體操作，t: 請求時客戶端追加的時間戳，c：客戶端標識。REQUEST: 包含消息內容m，以及消息摘要d(m)。客戶端對請求進行簽名。
2.PRE-PREPARE：

主節點收到客戶端的請求，需要進行以下交驗：

a. 客戶端請求消息簽名是否正確。

非法請求丟棄。正確請求，分配一個編號n，編號n主要用于對客戶端的請求進行排序。然后廣播一條<<PRE-PREPARE, v, n, d>, m>消息給其他副本節點。v：視圖編號，d：客戶端消息摘要，m：消息內容。<PRE-PREPARE, v, n, d>進行主節點簽名。n是要在某一個范圍區間內的[h, H]，具體原因參見垃圾回收部分。
3.PREPARE：

副本節點i收到主節點的PRE-PREPARE消息，需要進行以下交驗：

a. 主節點PRE-PREPARE消息簽名是否正確。

b. 當前副本節點是否已經收到了一條在同一v下并且編號也是n，但是簽名不同的PRE-PREPARE信息。

c. d與m的摘要是否一致。

d. n是否在區間[h, H]內。

非法請求丟棄。正確請求，副本節點i向其他節點包括主節點發送一條<PREPARE, v, n, d, i>消息, v, n, d 與上述 PRE-PREPARE消息內容相同，i是當前副本節點編號。<PREPARE, v, n, d, i>進行副本節點i的簽名。記錄PRE-PREPARE和PREPARE消息到log中，用于View Change過程中恢復未完成的請求操作。
4.COMMIT：

主節點和副本節點收到PREPARE消息，需要進行以下交驗：

a. 副本節點PREPARE消息簽名是否正確。

b. 當前副本節點是否已經收到了同一視圖v下的n。

c. n是否在區間[h, H]內。

d. d是否和當前已收到PRE-PPREPARE中的d相同。

非法請求丟棄。如果副本節點i收到了2f+1個驗證通過的PREPARE消息，則向其他節點包括主節點發送一條<COMMIT, v, n, d, i>消息，v, n, d, i與上述PREPARE消息內容相同。<COMMIT, v, n, d, i>進行副本節點i的簽名。記錄COMMIT消息到日志中，用于View Change過程中恢復未完成的請求操作。記錄其他副本節點發送的PREPARE消息到log中。
5.REPLY：

主節點和副本節點收到COMMIT消息，需要進行以下交驗：

a. 副本節點COMMIT消息簽名是否正確。

b. 當前副本節點是否已經收到了同一視圖v下的n。

c. d與m的摘要是否一致。

d. n是否在區間[h, H]內。

非法請求丟棄。如果副本節點i收到了2f+1個驗證通過的COMMIT消息，說明當前網絡中的大部分節點已經達成共識，運行客戶端的請求操作o，并返回<REPLY, v, t, c, i, r>給客戶端，r是請求操作結果，客戶端如果收到f+1個相同的REPLY消息，說明客戶端發起的請求已經達成全網共識，否則客戶端需要判斷是否重新發送請求給主節點。記錄其他副本節點發送的COMMIT消息到log中。

垃圾回收：

在上述算法流程中，為了確保在View Change的過程中，能夠恢復先前的請求，每一個副本節點都記錄一些消息到本地的log中，當執行請求后副本節點需要把之前該請求的記錄消息清除掉。最簡單的做法是在Reply消息后，再執行一次當前狀態的共識同步，這樣做的成本比較高，因此可以在執行完多條請求K（例如：100條）后執行一次狀態同步。這個狀態同步消息就是CheckPoint消息。

副本節點i發送<CheckPoint, n, d, i>給其他節點，n是當前節點所保留的最后一個視圖請求編號，d是對當前狀態的一個摘要，該CheckPoint消息記錄到log中。如果副本節點i收到了2f+1個驗證過的CheckPoint消息，則清除先前日志中的消息，并以n作為當前一個stable checkpoint。

這是理想情況，實際上當副本節點i向其他節點發出CheckPoint消息后，其他節點還沒有完成K條請求，所以不會立即對i的請求作出響應，它還會按照自己的節奏，向前行進，但此時發出的CheckPoint并未形成stable，為了防止i的處理請求過快，設置一個上文提到的高低水位區間[h, H]來解決這個問題。低水位h等于上一個stable checkpoint的編號，高水位H = h + L，其中L是我們指定的數值，等于checkpoint周期處理請求數K的整數倍，可以設置為L = 2K。當副本節點i處理請求超過高水位H時，此時就會停止腳步，等待stable checkpoint發生變化，再繼續前進。

View Change：

如果主節點作惡，它可能會給不同的請求編上相同的序號，或者不去分配序號，或者讓相鄰的序號不連續。備份節點應當有職責來主動檢查這些序號的合法性。如果主節點掉線或者作惡不廣播客戶端的請求，客戶端設置超時機制，超時的話，向所有副本節點廣播請求消息。副本節點檢測出主節點作惡或者下線，發起View Change協議。

副本節點向其他節點廣播<VIEW-CHANGE, v+1, n, C, P, i>消息。n是最新的stable checkpoint的編號，C是2f+1驗證過的CheckPoint消息集合，P是當前副本節點未完成的請求的PRE-PREPARE和PREPARE消息集合。

當主節點p = v + 1 mod |R|收到2f個有效的VIEW-CHANGE消息后，向其他節點廣播<NEW-VIEW, v+1, V, O>消息。V是有效的VIEW-CHANGE消息集合。O是主節點重新發起的未經完成的PRE-PREPARE消息集合。PRE-PREPARE消息集合的選取規則：

1.選取V中最小的stable checkpoint編號min-s，選取V中prepare消息的最大編號max-s。

2.在min-s和max-s之間，如果存在P消息集合，則創建<<PRE-PREPARE, v+1, n, d>, m>消息。否則創建一個空的PRE-PREPARE消息，即：<<PRE-PREPARE, v+1, n, d(null)>, m(null)>, m(null)空消息，d(null)空消息摘要。

副本節點收到主節點的NEW-VIEW消息，驗證有效性，有效的話，進入v+1狀態，并且開始O中的PRE-PREPARE消息處理流程。

在 PBFT 中，通過如下設計，使其在正常情況下的性能有顯著優化：

●使用快速的消息認證碼和 hash 計算代替計算量大的數字簽名計算；

●采用緩存機制，批量的處理客戶端請求；

●僅由某一臺服務器向客戶端發送完整的響應消息，其余服務器只發送 hash 值驗證已響應消息的正確性。

但是 PBFT 也存在一些不足之處：

1.客戶端請求的處理延時較大，在 5 步通信后才會返回執行結果（使用暫態優化執行仍需要 4 步通信延時）。這是因為正確服務器需要確定至少 f 臺其他正確服務器就執行順序達成一致后才會處理請求消息。

2.服務器間的廣播通信量巨大 ,導致容錯擴展性方面表現不佳。對于 n 臺服務器，通信復雜度是 O(N2)。隨著容忍的拜占庭錯誤服務器數目增加，通信量急劇上升，正常情況下的性能也會明顯下降。

2.2 DPOS - aBFT -- EOS2.0 共識協議

要理解 EOS 平臺的 DPoS+aBFT 就要先介紹 DPos 機制。在最早的 EOS 技術白皮書中，EOS主要采用的是 DPoS 機制，而在新版的白皮書中，做了一些改進，采用了 aBFT+DPoS共識機制。

2.1.1 什么是DPoS呢？

DPoS：Deligated Proof of Stake，也稱委托股權證明，在 EOS 的白皮書中對 EOS 為何使用 DPoS 進行了詳盡的解釋，簡單摘錄如下：

EOS.IO軟件架構中采用目前為止唯一能夠復合上述性能要求的區塊鏈共識算（DPOS）。根據這種算法，全網持有代幣的人可以通過投票系統來選擇區塊生產者，一旦當選任何人都可以參與區塊的生產。

EOS.IO里預計每3秒生產一個區塊。任何時刻，只有一個生產者被授權產生區塊。如果在某個時間內沒有成功出塊，則跳過該塊。

EOS.IO架構中區塊產生是以21個區塊為一個周期。在每個出塊周期開始時，21個區塊生產者會被投票選出。前20名出塊者首選自動選出，第21個出塊者按所得投票數目對應概率選出。所選擇的生產者會根據從塊時間導出的偽隨機數進行混合。以便保證出塊者之間的連接盡量平衡。

如果出塊者錯過了一個塊，并且在最近24小時內沒有產生任何塊，則這個出塊者將被刪除。這確保了網絡的順利運行。

在正常情況下，DPOS塊鏈不會經歷任何分叉，因為塊生產者合作生產區塊而不是競爭。如果有區塊分叉，共識將自動切換到最長的鏈條。具有更多生產者的區塊鏈長度將比具有較少生產者的區塊鏈增長速度更快。此外，沒有塊生產者應該同時在兩個區塊鏈分叉上生產塊。如果一個塊生產者發現這么做了，就可能被投票出局。

2.1.2 那么什么又是 aBFT+DPoS？

aBFT+DPoS: asynchronous Byzantine Fault Tolerance- Deligated Proof of Stake，又稱具有異步拜占庭容錯機制的DPoS。典型的 DPoS 區塊鏈有100％的區塊生產者參與。從廣播時間開始平均0.25秒后，可以認為交易具有99.9％的確定性。除 DPoS 外，EOS.IO 還添加了異步拜占庭容錯（aBFT），以更快地實現不可逆性。aBFT 算法可在1秒內提供 100％的不可逆性確認。

拜占庭容錯的“異步”屬性克服了對容錯的挑戰，即時序問題。很多 BFT 協議都假定在達成共識時存在最大消息延遲閾值。異步拜占庭容錯（aBFT）網絡消除了這種假設，并允許某些消息丟失或無限期地延遲。

DPOS 共識加上 aBFT 算法后，驗證時不再按照出塊順序由超級節點一個個驗證區塊內容，而是讓出塊節點成為主節點，出塊后同時向剩下 20 個節點進行廣播，并獲得節點的驗證反饋，如果有超過 2/3 的節點驗證通過，則該區塊成為不可逆區塊。aBFT可以使得EOS的區塊確認速度顯著增加。

該機制的具體過程是：EOS 的持有者通過投票系統對各個超級節點競選者進行投票，選出 21 個節點為超級節點。然后這 21個超級節點以自身的網絡資源狀況商議出一個出塊權擁有順序，在每個超級節點擁有出塊權時，以間隔為500毫秒(500毫秒是EOS團隊通過大量實驗測試得出的當前網絡狀態下可達到的最小的穩定狀態下的出塊間隔)連續產生 6 個新區塊，然后切換到下一個超級節點連續產生之后的 6 個區塊。

該方式可以保證一個超級節點可以連續以500毫秒的間隔產生區塊，因為在同一超級節點產生新區塊時不受當前網絡狀況的影響，但由于網絡的延遲很難使得其他節點對已經產生的區塊進行確認，使其成為不可逆區塊。使用上aBFT+DPoS 協議就可以使得 EOS 的出塊間隔從原來的3秒降低到500毫秒，這也使得跨鏈通信的時延大大縮短，單位時間內可確認的交易數量大大提升。

如果網絡狀況完美，一筆交易被打包后，在0.5秒內就可完全確認。當然，網絡不可能一直這么完美，很有可能上一個超級節點出塊后，下一個超級節點還沒來得及確認這個塊，自己就要產生新塊了。為避免因出塊速度過快而漏塊，EOS中21個超級節點的出塊順序是精心確定的。EOS的超級節點按照其他的地理位置依次輪流成為主節點，盡可能減少超級節點的網絡延遲。比如超級節點有中國、美國、加拿大、日本，那么成為主節點的順序是中國>日本>美國>加拿大或者反過來，總之保證相鄰最近的超級節點要依次交接主節點角色。

除此之外，還有另外一個機制來避免這一點。在EOS中，雖然出塊時間降為0.5秒，但每個超級節點在一輪中連續出 6 個塊，也就是說，仍然負責 3 秒時間的出塊，只不過是由 1 個塊變成了 6 個塊。這樣，前面幾個塊肯定有足夠時間經過確認，不存在整個超級節點被跳過的現象。可以看出每輪記賬節點的出塊總時間還是 3 秒鐘，在這 3 秒里，因為他對他自己出的塊是信任的，所以可以持續出塊。一邊出塊一邊廣播，3 秒之內率先廣播的區塊肯定能夠得到確認，在網絡通暢的情況下，6 個區塊都會可能得到確認。

EOS共識處理分叉問題非常簡單，和比特幣一樣，節點只會認可最長的鏈作為合法鏈。假如某個節點開始作惡，自己出塊并生成自己的鏈，也就是每次輪到它就產生 6 個塊。但是超級節點總共 21 個，每輪產生理論 126 個塊。根據選擇最長鏈作為主鏈原則，肯定作惡的鏈得不到認可。所以 EOS 不會發生分叉問題。

總結起來，aBFT+DPoS共識算法相比于單純的DPOS算法的優勢在于：

1.一致性和安全性得到提升；

2.出塊速度可以更快，吞吐性能更強；

3.BFT提供了不可逆確認功能，這也是跨鏈通信的關鍵屬性，適合于側鏈通信，為EOS的側鏈生態構建提供了基礎。

2.3 BABE-GRANDPA -- 波卡混合共識協議

波卡被譽為 2020 最受期待的公鏈項目，其不斷攀升的市值也印證了大家的期待。當我們談到 Polkadot 的共識協議時，大家經常看到兩個縮略詞，GRANDPA 和 BABE。我們同時提到了這兩個詞是因為 Polkadot 使用的是混合共識。

Polkadot使用帶有兩個子協議的混合共識協議：BABE和GRANDPA，合在一起稱為“快速轉發”。BABE 使用可驗證的隨機函數（VRF）為驗證者分配插槽。GRANDPA 對鏈投票而不是對單個塊投票。BABE可以一起編寫候選塊以擴展最終鏈，而GRANDPA可以分批完成它們（一次最多數百萬個塊）。

2.3.1 BABE

BABE （Blind Assignment for Blockchain Extension）是在驗證節點之間運行并確定新塊生產者的區塊生成機制。BABE 作為一種算法可以與 Ouroboros Praos 相比較，在鏈選擇規則和 slot （驗證人插槽）時間調整方面有一些關鍵的區別。BABE 根據 stake 和使用 Polkadot 隨機循環機制將區塊生產的 slot 分配給驗證人。

BABE中leader的選舉是通過一個隨機函數（VRF）來實現的，在每個slot階段，每一個節點會通過運算VRF函數來獲得一個數值，如果這個數值小于網絡中預先規定好的閾值，那么節點就會認為自己就是這個時間段的leader，于是節點就開始出塊了。

值得注意的是在上述的過程中，由于VRF函數是隨機生成數字的，所以可能造成在某一slot中沒有leader或者有多個節點算出自己的VRF值小于閾值進而產生多個leader的情況。我們依次分析兩種情況：

當沒有leader產生時，Polkadot就規定按照順序來決定誰是leader，這個順序是預先確定好的。

當出現多個leader的時候，Polkadot允許多個節點都提交區塊，而最終區塊的確認則由GRANDPA來決定。

2.3.2 GRANDPA

GRANDPA(GHOST-based Recursive ANcestor Deriving Prefix Agreement) 是用來做區塊確認的，BABE 會對Polkadot的交易進行出塊，這些塊最終就是由GRANDPA來確定的。

像其他PBFT的衍生算法一樣，GRANDPA的時間復雜度也是O(N2)。它在一個部分同步的網絡模型中工作，要求 2/3 的節點是誠實的。但是Polkadot之所以采用GRANDPA是因為GRANDPA并不是每次只確認一個區塊，它每一次都會確定好幾個區塊來做確認，所以效率比普通的 PBFT 更高。算法的主要流程如下：

1.一個主節點廣播之前一輪確認后的區塊高度；

2.等待網絡延遲以后，每個節點都廣播他們認為的可以被確認的最高的區塊（pre-vote）；

3.每個節點對步驟2接受到的區塊集進行計算，算出他們認為的能夠被確認的最高區塊，并且將結果廣播出去(pre-commit)；

4.當節點接收到足夠的pre-commit的消息能夠確認區塊后就會形成commit的消息，一般認為大于2/3就可以被確認了。

通過結合BABE和GRANDPA我們可以看到在出塊的時候Polkadot采用BABE出塊，此時節點之間只要發送一次塊信息即可，這樣的話時間復雜度僅僅是O(N)，在出塊之后節點之間再采用GRANDPA進行塊確認，此時由于確認階段節點之間要通過二次確認來保證確認塊結果的一致性，時間復雜度是O(N2)，不過由于是多個塊一次性進行確認，所以兩者結合的混合共識是非常高效的，比普通的PBFT共識要高效很多。

2.4 小結

PBFT算法由于每個副本節點都需要和其他節點進行P2P的共識同步，因此隨著節點的增多，性能會下降的很快，但是在較少節點的情況下可以有不錯的性能，并且分叉的幾率很低。所以在區塊鏈中，更多應用于聯盟鏈或私有鏈場景中。如 Fabric 和螞蟻鏈。

如果能夠結合類似 DPOS 這樣的節點代表選舉規則的話也可以應用于公鏈，并且可以在一個不可信的網絡里解決拜占庭容錯問題，有些公鏈對此進行了有益的嘗試。

為了適應公有鏈場景中的大規模擴展需求，有不少項目大膽采用了 PBFT，比較知名的有 EOS 鏈首先采用了 DPoS + aBFT 共識協議，后起之秀波卡采取了 BABE + GRANDPA 的混合共識協議，這兩個公鏈都是先用一些方法在眾多的公鏈節點中選舉出參與共識的節點，然后再進行 BFT 共識。采用這種方法會有效減少節點的數量，使性能能夠滿足公鏈的需求。所以 BFT 協議在聯盟鏈和公鏈都可以廣泛應用。

本文主要介紹了BFT 協議概念及在區塊鏈的應用，本系列的下集在次條更新，歡迎關注。

本文圖片來源于：

劉秋杉. Practical Byzantine Fault Tolerance[EB/OL].2014-09-09.

區塊鏈安全：基于區塊鏈網絡攻擊的方式原理詳解

參考資料

https://academy.binance.com/zh/articles/what-is-social-engineering

https://mp.weixin.qq.com/s/uE_3NhH0mlEejJoUCfEchQ

https://www.jianshu.com/p/5fea30b25f0a

https://www.chainnews.com/articles/066979964730.htm

https://learnblockchain.cn/2019/08/29/pbft/

https://blog.csdn.net/yuanfangyuan_block/article/details/79872614

https://bihu.com/article/1427644620