Facebook Libra架構設計這麼荒謬,憑什麼還要堅持發行

過去幾年以來,我一直在歐盟國家從事與金融科技相關的工作。這段經歷,也讓我對金融科技建立起特別的審視角度。在本文中,我就將從這一視角出發,談談近來被推上風口浪尖的Facebook Libra項目。

幾個月前,Facebook公司發佈了名爲Libra的全新金融服務平臺。Libra項目顯然是要成長爲以一籃子國際貨幣爲基礎的數字結算系統——這些國際貨幣將通過區塊鏈網絡進行管理,並保存在由瑞士分公司管轄的現金池當中。項目的既定目標可以用“高大上”來形容,同時也將帶來巨大的地緣政治影響。

Facebook Libra項目在架構上並不健全

實際上,《金融時報》與《紐約時報》陸續發表過不少質量頗高的文章,其中提到Libra金融結構背後一系列不夠合理的貨幣與經濟假設。但是,目前還沒有技術專家從純技術角度做出分析。從事金融基礎設施工作的從業者確實很少公開討論自己的日常事務,因此該項目在科技新聞領域獲得了廣泛好評。相比之下,金融新聞媒體則需要對項目進行盡職調查,因此能夠根據已經公開發布的內部結構做出更確切的分析。作爲參考,我這裏指的公開結構是指GitHub存儲庫與Calibra Organisation提供的開源代碼。

但在我看來,Libra項目實際上屬於一種精神分裂性質的產物。雖然號稱是全球支付基礎設施領域的全新可靠平臺,但在具體審視代碼庫時,我發現其中不少奇怪的設定早已偏離了這一目標。我敢肯定,這樣的結構設計一定跟Facebook公司內部的政治鬥爭有關。無論如何,Libra項目如此奇怪的架構選擇會破壞整體系統,並導致消費者面臨風險。

實話實說,我不會假裝自己能夠以完全中立客觀的角度審視Facebook公司,技術人員對企業的看法確實比較消極。通過已經發布的各類資料,明顯可以看到Libra項目的說明描述與具體實施之間存在根本性衝突。簡而言之,Libra項目不會下放任何權力。它是Facebook的救命稻草,旨在通過多元化支付與信用評分緩和前一段時間曝出的醜聞與腐敗問題。Libra項目的明確長期目標是充當數據經紀機構,並根據消費者的私人社交媒體數據調整信貸額度。這是個恐怖的反烏托邦故事,絕對值得引起警惕。

而其中唯一值得討論的,就是作爲一個開源項目,Libra的架構設計非常荒謬,完全不適合Facebook設定的任務。排除其中的傲慢態度,下面我們來具體看看項目中的幾個核心架構錯誤:

Libra在許可網絡上採用拜占庭容錯設計的作法不合邏輯

拜占庭容錯屬於分佈式系統研究中的一個小衆領域,基本思路就是確保網絡系統能夠承受其中組件發生的任意故障,並在發生問題時對系統執行必要的糾正操作。拜占庭容錯網絡必須有能力抵禦多種類型的攻擊,包括重啓、崩潰、惡意負載以及選舉流程中的惡意投票等。這一設計決策對Libra項目至關重要——遺憾的是,起到的並不是什麼正面作用。

這一附加結構的時間複雜度開支取決於具體算法。大量文獻指出,Paxos與Raft派生算法都已經極大豐富了拜占庭容錯的功能水平,但這一切都會在O(n2)時間複雜度算法的固有通信成本之外,帶來額外的通信開銷,用以維持參與仲裁的人數。在領導節點失敗的情況下,Libra選擇的算法可能仍會帶來O(n2)通信成本。面對幾種網絡故障事件,潛在的領導節點連任也會產生額外的開銷。

對於這樣一套用於在高度監管的跨國企業財團內運行的系統,所有運行Facebook簽名代碼並由Facebook進行訪問控制的系統,都沒有必要在共識層面考慮惡意行爲者的影響。這就帶來了第一個問題:爲什麼非要在系統設計中全面引入拜占庭容錯,而不是單純維護統一的審計日誌以進行合規性檢查。Mastercard公司或者Andressen Horrowitz這樣的重要參與者,有可能突然就在Libra節點上運行惡意代碼嗎?既然不可能,項目開發者爲什麼不簡單通過強制性協議完整性與其他非技術(合規)手段解決問題,反而引入了成本開銷最高的拜占庭容錯?

在國會聽證會上,Facebook方面將Libra描述爲國際支付協議領域的新興挑戰者,矛頭直指微信、支付寶以及M-Pesa。然而,他們提到的這些系統都沒有采用拜占庭容錯驗證池。相反,這些系統採用了更簡單的傳統高吞吐量總線設計,該總線會根據一組固定規則打理分類賬交易。這纔是設計支付系統時的自然方法。什麼防止雙重支出啦、預防分叉啦,根本就不是支付設計層面需要考慮的問題。

換言之,共識算法帶來的根本就是廢熱式的開銷,只會限制系統的整體吞吐量。除了幫助Facebook公司自己摸索公鏈開發技術之外,我看不到任何有說服力的理由。

Libra缺乏交易隱私

根據白皮書的介紹來看,Libra系統採用匿名設計,意味着協議中使用的地址由橢圓曲線公鑰生成,且不包含與賬戶有關的元數據。但是,在組織及協議自身的治理結構描述中,我們看不到任何關於匿名交易中與經濟數據相關的說明。這套系統在設計上以大規模方式向外部交易方複製交易內容,而根據現行歐洲及美國銀行保密法,這些外部交易方並沒有資格瞭解交易的全部細節。

另外,數據政策很難實現跨境協調,這一點在目前不同司法管轄區對數據保護及隱私抱有不同文化觀點、甚至採取差異巨大的法律法規的前提下,就顯得尤其嚴重。默認來講,協議本身會對財團成員完全開放,這是一種明顯的技術設計缺陷,並不適合項目所宣稱的設計應用場景。

Libra HotStuff BFT無法支撐支付通道所需要的吞吐量

在英國,BAC之類的清算系統每月能夠清算約5.8億筆交易。Visa等經過高度優化的系統,每天就能完成1.5億筆交易。這些系統的性能取決於交易大小、網絡路由、系統負載以及AML(反洗錢)檢查等多種因素。

對於國內資金轉移而言,Libra試圖解決的所謂效率問題,早就在前幾年完成了清算基礎設施現代化的民族國家中得到了很好的處理。另外,對於歐盟的零售消費者來說,資金轉移也從來都不是什麼問題。利用傳統基礎設施,我們只需要幾秒鐘就能通過智能手機輕鬆完成轉賬。而對於大型企業,大量資金轉移則需要遵循不同的機制與規定。

除了跨轄區間的規則與要求差異之外,現有傳統基礎設施無法即時完成跨境支付也絕對不是什麼技術問題。目前的交易延遲,主要源自交易鏈中各個不同步驟需要執行的預防性措施(客戶盡職調查、制裁篩選等)。很明顯,這樣的延遲純粹由法律管轄與合規性保障引發,跟技術一點關係都沒有。

對於消費者來說,英國國內的交易完全可以在幾秒鐘之內搞定。而對於歐盟範圍內的零售交易,實際上也僅受KYC(瞭解你的客戶)以及政府與監管機構強加的AML限制(Libra支付也同樣需要接受AML篩查)影響。如果Facebook希望克服國際資金與私人數據流動方面的障礙,就必須拿出一套能夠容納每人每年數百次交易所帶來的巨大全球交易吞吐量的模型——這又是另一碼事了,如此恐怖的負載量可能要求對支付系統從第一原理層面開始做出重新設計。

Libra的Move語言怕是靠不住

白皮書還對一種未經測試的新語言Move提出激進的主張,從編程語言理論(PLT)的角度來看,這種表現未至、讚賞先行的作法相當可疑。

Move”是一種新型編程語言,用於在Libra區塊鏈上實現自定義交易邏輯與“智能合約”。由於Libra的目標是每天服務數十億用戶,因此Move語言在設計中以安全性作爲核心關注重點。

Move的主要特性,在於利用一性邏輯啓發的語義對資源類型做出自定義。

在公鏈當中,智能合約提的是部署在公共網絡上的邏輯,該邏輯允許用戶進行竊取、洗錢以及發行法外證券及賭博產品等操作。這些操作通常是使用Solidity這種令人印象深刻,但設計水平並不算很高的語言完成的。從學術角度來看,PHP的設計質量不知道高到哪裏去了。但奇怪的是,Facebook公司設計的新語言似乎與這些技術沒有什麼相同的用例,而更像是那種爲不太瞭解智能合約的用戶設計的腳本語言。

在私有分佈式賬本中,顧問們最愛聊的就是智能合約——但到底如何定義合約,合約的使用目的又是什麼?其實很多人並不關心。企業軟件顧問就愛在這種模棱兩可的情況下貿然推進,而智能合約正是其中的典型,因爲這東西一聽起來就好、就重要。

至於所謂天然安全性,我們還是得從語言的語義層面出發。PLT中的健壯性主要由兩種證明構成,分別是“進步”與“保存”,二者確定了語言評估規則在整個空間內的一致性。更具體地講,在類型論中,如果函數只使用一次參數,則該函數屬於“線性”函數;如果最多使用一次參數,則屬於“仿射”函數。線性類型的系統會爲所有函數子表達式指定類型並跟蹤調用位置,從而以靜態方式保證所調用的線性函數確實具有線性屬性。這是一種微妙的特性,需要證明,而且需要大量資源進行整體程序分析。線性類型目前仍是個相當學術的研究領域,並啓發出Clean中的唯一性類型與Rust中的所有權類型。Glasgow Haskell編譯器還對線性類型的添加做出了具體建議。

再來看Move語言聲明,其中提到的線性類型說法似乎沒有得到充分證實,因爲聲明並沒有提到這種類型檢查器的邏輯。單從內容來看,我們只能說該白皮書引用了Girard與Pierce的經典文獻,但還完全沒有落到實踐中來。

最重要的是,無論是在現實場景還是該白皮書中,我們都找不到什麼是所謂安全語言的語義形式。Move語言很小,可以輕鬆通過Coq或者Isabelle進行語義的完整正確性證明。確實,利用近十年來出現的現代工具鏈,我們可以利用端到端編譯器實現完全可證明的字節碼轉換。自從George Necula與Peter Lee在1996年開始合作以來,我們已經能夠切實實現這種轉換。

但是,從編程語言理論的角度出發,Move到底安不安全、可不可靠,只能說還無法證明。就目前看來,這種說法似乎只是一種宣傳推銷,沒有任何實際證據。對於語言工程項目來說,這是種令人震驚的立場,我很難想象人們聽了這話就放心用它處理高達數十億美元的資產。

Libra的密碼學工程尚不完善

建立健全的密碼系統無疑是個相當棘手的工程難題。而在處理敏感代碼時,關注密碼學基礎的可靠性纔是正確的態度。在這一領域中已經出現了不少重大飛躍,例如微軟Everest項目構建的可驗證安全TLS堆棧。如今,構建可驗證基元工具雖然成本高昂,但Facebook公司的財力應該足以承擔起來。然而,從現在的結果看,其開發團隊似乎放棄了在密碼學層面做出有意義的努力。

Libra項目依賴於幾套相當新且不知道靠不靠譜的庫來構建實驗性密碼系統。我們無法斷言以下工具依賴項是否安全,因爲它們既沒有經過安全審計,也沒有標準的實踐披露政策。更重要的是,我們不清楚其中幾套核心庫能否抵禦旁路攻擊與定時攻擊。

  1. ed25519-dalek
  2. curve25519-dalek

通過組合這些新穎的技術(例如可驗證隨機函數、雙線性對以及閾值簽名),該庫在密碼學標準模型之外又做出了更多實驗與冒險。這些技術與庫本身可能足夠健壯,但一旦被合併爲統一的整體,那麼攻擊面的增加應該引起我們的關注。這一切新工具與新技術的結合,自然也帶來了更高的舉證責任。

這裏顯然有必要採用有罪推定,即除非能夠明確證明,否則應該默認爲整個密碼棧都容易受到攻擊影響。“快速行動、打破常規”的模式不適用於處理消費者金融數據的加密工具。

Libra項目缺少消費者保護機制

任何支付通道都必須提供一項明確功能,即能夠在出現執法要求、明確申請或者意外的操作失誤及系統故障等情況下,撤銷對應的交易操作。Libra系統在設計中則採用“總終結性”思路,即無法撤銷付款交易。在英國,一切數額在100到30000英鎊之間的付款皆受到《消費者信貸法》的保護。這意味着,如果購買的商品存在問題或者賣方無法履行服務約定,則支付服務供應商負有與賣方相同的責任與義務。事實上,歐盟、亞洲以及北美也擁有類似的規定。

當前的Libra項目設計不包含符合消費者保護法的協議,也沒有明確的協議構建計劃。更糟糕的是,從數據架構角度來看,基於Merkle累加器狀態的核心身份驗證數據結構具有終結性,即不允許在不重新設計核心的前提下向核心賬本中添加新協議。

在對項目進行技術性盡職調查之後,我得出的最終結論是,Libra項目無法通過任何分佈式系統研究或者金融工程知名期刊的審覈。在真正給全球貨幣政策帶來顛覆之前,Facebook公司需要投入大量技術資源以建立一套可靠網絡,否則公衆及監管機構無法相信這樣的解決方案能夠安全處理用戶數據。

就目前而言,我找不到相信Facebook已經克服上述項目技術難題的證據。而且相對於傳統基礎設施而言,Libra項目沒有任何技術優勢。Facebook公司當然可以犧牲一定監管靈活性來換取創新探索空間,但這絕不是在技術層面做出諸多粗暴妥協的藉口。

原文鏈接
Facebook Libra is Architecturally Unsound

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章