a16z crypto · First Principles

區塊鏈先問一件事:大家能不能同意同一段歷史?

Leslie Lamport 的訪談把 blockchain 拉回共識的原點:網路會延遲,機器會故障,節點可能說謊,系統仍要讓多個 process 做同一件事。

來源:a16z crypto〈Leslie Lamport on the Science of Distributed Systems〉,Tim Roughgarden、Ittai Abraham 訪問 Leslie Lamport,YouTube 原始發布日期為 2026 年 6 月 25 日。

Logical clocks先把「誰先、誰後」定義清楚,分散式資料庫與區塊鏈才有共同歷史可談。
Byzantine Generals故障節點不只沉默,也可能任意行動。共識要處理最壞的失敗形式。
Paxos原本想證明某件事不可能,最後得到一個能在非同步系統裡求進展的協定。
SCROLL
PART 1

共識不是加密貨幣專用詞,而是「多個 process 做同一件事」。

Lamport 在開場把問題講得很素:如果你有一個 distributed system,其中一些電腦會失敗,你就需要 fault tolerance。真正的問題,是讓多個 process 在不可靠的環境裡做同一件事。區塊鏈後來把這個問題包成交易、區塊、validator、finality,但底層仍是同一件事:系統要承認哪一段歷史。

這也是 First Principles 系列的目的。Bitcoin 白皮書不是憑空出現。它站在分散式系統、密碼學、經濟學與機制設計幾十年的成果上。Lamport 的 logical clocks、Byzantine Generals problem、state machine replication 與 Paxos,把「同意」這件事拆成可以證明、可以推理的工程問題。

一個問題,三層語言
Distributed systems
process、message、failure
Consensus
order、agreement、proof
Blockchain
block、transaction、finality
PART 2

Lamport 從一個印表機問題,走到分散式系統。

Lamport 早期關心的是 mutual exclusion。多個 process 想共享同一個資源,例如早年的 printer,如果兩個 process 同時把字送進 printer,輸出就會混在一起。Dijkstra 把這個問題變成現代 concurrency 的入口:如何保證同一時間最多只有一個 process 進入 critical section。

Lamport 一開始寄出一個簡化解法,很快被編輯指出 bug。這件事讓他決定把問題解乾淨,後來得到 bakery algorithm。更重要的是,他發現單機 concurrency 與多機 distributed algorithm 沒有清楚斷點。當你要證明一個 concurrent algorithm 正確時,你其實已經在面對「順序如何被定義」這個分散式問題。

1972從 ACM 文章中的 mutual exclusion 問題開始,發現簡單直覺很容易有 bug。
Bakery把「誰先排隊、誰進 critical section」做成可推理的演算法。
Clocks進一步追問 distributed database 裡,事件的因果順序要如何被精確表達。
PART 3

「正確」不是感覺,而是安全性與活性各自成立。

訪談中 Roughgarden 問 Lamport:協定正確到底是什麼意思?Lamport 的回答很直接。早期的 property 可以很簡單,例如 mutual exclusion:不會有兩個 process 同時在 critical section。到了 distributed database,問題變成多份資料庫 copy 是否維持一致。你以為自己懂一致,真正寫成精確陳述時,困難才出現。

Lamport 後來把 correctness 拆成兩類。Safety 是壞事永遠不會發生,例如不會同時承認兩段互相衝突的歷史。Liveness 是好事終究會發生,例如系統最後能繼續做出決定。區塊鏈讀者熟悉的 finality、fork choice、停機風險,其實都可以放進這個框架。

Safety不承認兩個互相衝突的狀態。錯了就無法靠等待修復。
Liveness系統不會永遠卡住。進展可能變慢,但不能沒有路徑。
Lamport 在談 Paxos 時說,問題像是「有一個不可解的問題正在被解決」。它不能在純非同步模型裡保證一定結束,實務系統仍要靠 clock 與 timeout 前進。
PART 4

Byzantine Generals 把 failure 想到最壞,Paxos 則處理常見的 crash。

Lamport 談 Byzantine faults 時,沒有把它描述成戲劇化比喻。他的想法是:既然當時還沒有明確的 fault 定義,就直接採用最一般的失敗形式,也就是 failed process 可以做任何事。它可以沉默、亂送訊息、對不同人說不同版本。若系統能在這種模型下維持 agreement,它才真的面對了惡意環境。

Paxos 的來歷更像研究現場。Digital 的 Systems Research Center 有一個 local area network,他們假設故障就是機器 crash。Lamport 原本相信他們想達成的東西不可能,開始寫 impossibility proof。結果沒有得到不可能證明,而是得到 Paxos。它實作的是 state machine,重點不是每次都立刻決定,而是在 failure 與 delay 下仍保留能決定的路徑。

兩種失敗模型
Crash fault
節點停止、消失、不再回應
Paxos
用 proposal、quorum 與 timeout 在不完美網路裡求決定
Byzantine fault
節點任意行動,甚至傳出互相矛盾的訊息
PART 5

理論不是遠離實務,而是把實務問題說清楚。

Lamport 沒把 theory 與 practice 當成兩個世界。他反而說,早期很多人用實體物件或硬體直覺思考問題,他比較傾向把它抽象成 algorithm。這讓問題能被嚴格描述,也讓解法可以移植到不同場景。今天區塊鏈把 Byzantine agreement 用在經濟系統裡,就是這條路徑的延伸。

訪談最後談到 DARPA 與長期基礎研究。Byzantine agreement 的背景之一,是大型分散式系統如何在攻擊、失敗或部分毀損下存活。它最初不是為 token economy 設計,卻成為 blockchain infrastructure 的底層語言。這提醒我們:新金融基礎設施常常先是老科學問題的新部署環境。

區塊鏈共識不是先問誰值得信任,而是先問在不可靠的網路裡,哪些訊息足以讓所有人承認同一段歷史。

讀完 Lamport 這集,你會先看哪個問題?

這不是測驗。選一個你最想帶走的分析入口。

你的觀點

想看更深入的脈絡?

a16z crypto 原始影片包含 Leslie Lamport 對 bakery algorithm、logical clocks、Byzantine Generals、Paxos、理論與實務互動,以及 DARPA 基礎研究脈絡的完整訪談。

觀看原始影片 → 打開 a16z crypto 頻道 →

本頁為繁體中文互動閱讀整理,來源以 a16z crypto YouTube 原始影片為準。