Ethereum 把 Wikipedia 變開發者速查表

我把 Wikipedia 的 Ethereum 條目拆成一份開發者能直接複製的速查表。

我玩 Ethereum 一陣子了，越看越火大。大家不是把它講成「數位黃金」，就是講成一坨只有研究生才看得懂的黑話。這兩種都不對。我真正需要的，是能拿去跟 PM、後端、甚至法務講清楚的版本：它到底在做什麼、smart contract 為什麼重要、gas 為什麼不是多收你錢而已、還有 The Merge 到底改掉了什麼。

我後來回頭啃了 Ethereum Wikipedia 頁面，才發現它其實很適合拿來拆。不是因為它完美，而是因為它把設計、歷史、應用全塞在一起，剛好能逼你把「能不能做」和「值不值得做」分開。

所以這篇我不想寫成介紹文。我想直接把那頁拆成一份開發者版 cheat sheet，讓你看完就能拿去寫 team doc、產品簡報，或是自己做架構判斷。

Ethereum 不是幣，它是執行層

“Ethereum is a decentralized blockchain with smart contract functionality. Ether (abbreviation: ETH) is the native cryptocurrency of the platform.”

翻譯一下就是：Ethereum 是機器，ETH 是燃料。很多人一講 Ethereum 就先想到幣價，這很煩，因為那是把結果當本體。真正重要的是這條鏈提供了一個共享的執行環境，讓任何人都能部署應用，不用先去求一個中心化平台點頭。

我之前看過不少團隊，一開始就說「我們要上鏈」，但問下去才發現他們其實只是想發 token。這種做法很容易把產品做歪，最後變成一個錢包外殼加一堆故事。Ethereum 的順序剛好相反：先有共享執行，再談資產層。

如果你要查官方資料，我會先看 ethereum.org。如果你要看 client 生態，最常見的 Go 實作是 Geth，原始碼在 GitHub。

實操寫法很簡單：你在跟團隊講 Ethereum 的時候，不要說「我們做 crypto」。改成「我們要用一個共享執行層，必要時再用 ETH 結算」。這句話比較像工程決策，不像宗教宣言。

• 需要多方共同驗證狀態時，再考慮 Ethereum。
• 不要先想 token，再倒推用途。
• 把應用與資產分開看，會少走很多冤枉路。

Vitalik 一開始想解決的是應用，不是支付

Ethereum 的起點不是「再做一個幣」，而是 Vitalik Buterin 2013 年那份白皮書想把區塊鏈變成更通用的應用平台。Wikipedia 也明講了它朝向 Turing-complete 的腳本模型走。這句話很學術，但意思很直接：它想讓鏈不只會轉帳，還能跑規則。

也就是說，Ethereum 的核心不是「能不能搬錢」，而是「能不能把一段需要被大家共同遵守的邏輯放上去」。像 escrow、拍賣、借貸、治理、權限控制，這些都不是單純的資料寫入，而是規則執行。

我之前評估過一個流程要不要上鏈，最後發現如果只是記帳，根本不用折騰；但如果是多方互不完全信任、又需要同一套規則自動執行，那鏈就開始有意義。這個判斷點，我覺得比「是不是很 Web3」實在多了。

Wikipedia 也列了早期創辦人：Vitalik Buterin、Gavin Wood、Charles Hoskinson、Anthony Di Iorio、Joseph Lubin。這很重要，因為它從來不是單一公司單一 roadmap 的產品。它一開始就是多方協作、甚至帶點混亂的系統。

實操寫法：每次你想把某個流程搬到 Ethereum，上來先問一句——這個系統是不是需要多方共享、可驗證、而且不完全信任單一操作者的邏輯？如果答案不是很明確的 yes，就先別硬上。

• Ethereum 強在共享邏輯，不只是共享資料。
• Smart contract 是規則執行，不是自動化口號。
• General-purpose execution 才是它的核心賣點。

Yellow Paper 這種無聊文件，才是平台真正站得住的地方

Wikipedia 提到 Gavin Wood 寫了 Ethereum Yellow Paper，定義了 Ethereum Virtual Machine。這種東西很少人愛看，因為沒有梗圖、沒有幣價、也沒有「未來感」。但老實說，平台能不能被陌生人信任，靠的就是這種無聊文件。

翻譯一下就是：EVM 定義了程式怎麼跑、狀態怎麼改、交易怎麼被解釋。你如果曾經 debug 合約時看著 revert、gas 被吃掉、或是一個看起來沒什麼的修改把相容性炸掉，你其實就是在跟 EVM 的精確規則打交道。

我以前跟後端工程師講區塊鏈執行模型，他們常會直覺把它當成一般 API call。這不對。Ethereum 上的執行是被計量、被複製、被每個 node 驗證的。這表示它在一致性上很硬，但在開發體驗上也很不客氣。

如果你要看技術基礎，我會直接丟 Ethereum 開發文件。如果你想看實作，Geth repo 很適合拿來對照。

實操寫法：不要用寫 REST API 的心態寫合約。把它當成公開機器規格來設計，任何 branch、storage write、external call 都要能扛住公開執行與惡意 replay。

Gas 不是收費機制，是防濫用機制

Wikipedia 把 gas 放進核心設計，這點我很認同。因為只要你真的碰過 Ethereum，就會知道它不是「區塊鏈版資料庫」，而是一個會對每次計算收費的公開系統。Gas 的存在不是要讓你心痛，是為了避免整個網路被任意運算拖垮。

也就是說，每個操作都有成本。存儲通常比計算更貴，複雜路徑比簡單路徑更貴，寫得爛的合約不只是慢，還可能貴到沒人用。這不是邊角料，這就是架構。

我看過不少團隊合約功能上沒錯，但經濟上很蠢。多寫幾次 storage、亂加 loop、合約間一直互 call，然後再抱怨使用者嫌費用高。這種時候你不能只說「功能都對啊」，因為在 Ethereum 上，能跑不等於值得跑。

如果你做的是產品，實作上最好把 gas budget 當成 latency budget 一樣看。先估算最常見使用路徑的成本，再去砍掉不必要的寫入、批次化操作、把能 off-chain 的檢查移出去。

• Gas 是保護共享資源，不是單純抽成。
• Storage 成本高，是有設計理由的。
• 合約要看邏輯，也要看經濟效率。

The Merge 不是改名而已，它把整個參與模型換掉了

Wikipedia 寫得很清楚：Ethereum 在 2022-09-15 透過 The Merge 從 proof-of-work 轉成 proof-of-stake，而且能耗下降超過 99%。這不是包裝文案，這是整個共識機制換了。

白話一點說，Ethereum 不再靠 miners 拼算力，而是靠 validators 質押 ETH 來參與驗證。也就是說，你如果還把 Ethereum 當成挖礦網路在理解，那你的模型早就過期了。

我很常遇到一種討論：有人一講 Ethereum 就先拿環境成本來打。The Merge 沒有讓所有批評消失，但它確實把最常被拿來酸的那個點砍掉了。對要對內說服主管、對外說服客戶的人來說，這件事很實際。

如果你要看官方脈絡，我會直接看 The Merge 文件，再搭配 Ethereum Foundation 的說明。這比看社群二手轉述準很多。

實操寫法：不要再用「挖礦網路」的舊腦袋理解 Ethereum。你在評估產品時，也要把 staking-based consensus 算進去，因為參與者、誘因、風險結構都變了。

ERC 標準讓 Ethereum 變得好用，也變得更吵

Wikipedia 提到 ERC-20、NFT、DeFi 是重要應用場景。這段我覺得最有感，因為它說明 Ethereum 真正有用的地方不是某個幣，而是標準化之後，大家可以共用同一種資產格式。

翻譯一下就是：ERC-20 讓 fungible token 彼此相容，ERC-721 讓 NFT 變成標準而不是土炮格式，DeFi 則把合約變成金融基礎設施。標準一旦成立，錢包、交易所、市集、app 都能直接接，不用每次都客製一套。

我以前做過一個系統，最痛的不是功能，而是每多一種資產型態就多一個 adapter。Ethereum 的標準至少把這個問題砍掉一大半。當然，它也順便讓一堆垃圾專案更容易包裝自己，這兩件事是同時成立的。

如果你要看標準本體，直接去 EIPs。ERC-20 看 EIP-20，NFT 看 EIP-721。這些 spec 比很多長篇介紹文更有用。

實操寫法：只要你的資產或合約需要被外部工具認得，先用標準，不要自己發明格式。你如果連別人的錢包都接不起來，那大概率不是平台功能，只是你自己的小玩具。

• 標準化是互通的前提。
• 別自己造格式，除非你真的有很硬的理由。
• 能被工具辨識，才有機會成為生態的一部分。

Ethereum 的歷史其實就是一連串取捨

Wikipedia 的歷史段落很長，而且不太好看，但我反而覺得這才是重點。從眾籌、client 競爭、DAO exploit、hard fork、Ethereum Classic 分裂、Enterprise Ethereum Alliance，到後來的 The Merge，整條線都在告訴你：Ethereum 從來不是單純的 codebase。

也就是說，它同時是治理問題、安全問題、協調問題、還有生態問題。尤其 DAO 那次事件，直接把「不可變」這種口號打回現實。真出事的時候，大家還是得選擇要不要改歷史。

我一直覺得 DAO fork 是 Ethereum 最值得記的教訓。因為它讓你看到，所謂 immutability 在簡報裡很漂亮，但在災難面前，社群還是會討論怎麼處理損失、怎麼維持信任、怎麼決定規則。

實操寫法：你如果要在 Ethereum 上做長壽產品，先看它的 protocol history。知道升級怎麼發生、fork 怎麼處理、社群怎麼面對重大 bug。不要只看合約層，因為治理層真的會影響你。

可抄的模板

# Ethereum，給開發者看的版本

Ethereum 是一個去中心化的區塊鏈執行層，支援 smart contract。
ETH 是原生資產，但真正的重點是共享執行環境。

## 這是什麼
- 公開可驗證的 state machine
- 可部署、可執行的合約環境
- 開源協議，有多個 client 實作
- 支援 ETH、ERC-20、NFT 等資產標準

## 為什麼要管它
- 讓多方共享同一套規則
- 可把資產與邏輯一起標準化
- 用 gas 限制濫用與浪費
- 已從 proof-of-work 轉成 proof-of-stake

## 什麼情況適合用
適合用 Ethereum，如果：
- 你需要多方共同驗證的邏輯
- 你的產品需要公開結算或公開可驗證狀態
- 你要跟錢包、交易所、市集等外部工具互通
- 合約規則比單純資料存取更重要

不適合用 Ethereum，如果：
- 你只是需要一個資料庫
- 單一服務商可以更便宜、更快地處理
- 你的主要需求是私有、高吞吐、低成本寫入
- 你只是想「順便發個 token」

## 核心心智模型
1. Chain 是 runtime，不是行銷詞。
2. ETH 支付執行與狀態變更成本。
3. Gas 是防濫用，不是額外稅。
4. Smart contract 是公開機器碼。
5. ERC 標準決定外部工具能不能接。
6. 共識機制已經是 staking，不是 mining。

## 建議你在設計前先問
- 這個系統需要誰信任誰？
- 哪些狀態一定要上鏈？
- 哪些檢查可以移到 off-chain？
- 常用路徑的 gas 成本是多少？
- 我是不是應該先用標準而不是自創格式？

## 給團隊文件的短版說法
Ethereum 是一個公開的執行層，適合需要共享、可驗證規則的應用。
ETH 用來支付計算與狀態變更成本。
如果產品不需要公開結算、合約可組合性、或多方共享信任，那 Ethereum 多半不是對的工具。

## 參考來源
- Ethereum: https://ethereum.org
- Wikipedia: https://en.wikipedia.org/wiki/Ethereum
- Geth: https://geth.ethereum.org/
- EIPs: https://eips.ethereum.org/
- The Merge: https://ethereum.org/en/roadmap/merge/

如果我要把這段直接丟進 team wiki，我會把前半段留短，把 checklist 留狠一點。這樣大家才不會一邊喊要做鏈上，一邊根本沒想清楚自己在解什麼問題。

我這篇是拿 Wikipedia 的 Ethereum 條目當底，再加上我自己的開發者拆解。原始資料來自 Wikipedia、ethereum.org、EIPs 和 Geth；模板與白話翻譯是我整理出來的。