從以太坊區塊鏈當前的困境談 eth 1.0 ➔ eth 1.x 升級和 stateless clients 改動

本篇文章將剖析 eth 1.0 存在的各項問題，並介紹 Ethereum Foundation 提出的 eth 1.x 升級相關改動能如何改善當前以太坊的困境。

什麼是 eth 1.x

以太坊 2.0 的研究行之有年，迄今（2020/06 ）距離全面啟動仍需要 2–3 年的時間，並且 eth 2.0 將被部署為由信標鏈（Beacon Chain）與多條分片鏈（Shard Chains）構成的獨立區塊鏈，而 eth 1.0 需要經過改動與升級方能成為 eth 2.0 中的其中一條分片鏈。這意味著現在運行的以太坊 1.0 區塊鏈需要進行改動，並且在未來的 5~10 年保持運作，持續發展。而 eth 1.x 即為以太坊 1.0 升級版本的代稱。

eth 1.x 的首要目標旨在解決現在區塊鏈日益增長的資料負擔，在區塊鏈大小持續增長的情況下保持 eth 1.0 網路的彈性。

以太坊 1.0 的弊端與問題

在開始介紹以太坊 1.x 之前，必須先認知到目前（2020/06）以太坊存在的問題，如此方能充分瞭解 eth 1.x 被提出的背景與旨在解決的痛點。

Problem (A)：網路趨於中心化

自 2020/05 以來，Gas Price 的節節攀升導致開發者與高頻率使用者叫苦連天，其背後原因除了以太坊用戶數量的增加，亦是由於耗費大量 Gas 的智慧合約互動行為比例提升（單純轉帳 ETH 的占比被稀釋），使得以太坊網路持續壅塞。

面對這樣的情景，礦工社群於 2020/6/19 UTC 投票通過，將每個區塊的 Gas Limit 從 10,000,000 提升到 12,000,000。

截至 2020/06/30，儘管每個區塊的 Gas Limit 提升至 12,000,000，合約交易占比的提升依舊讓每個區塊所能容納的交易數十分有限，在 Etherscan 上可以查看到以太坊的 TPS（Transactions Per Second）在 Gas Limit 提升前平均落在 12 左右（低於號稱的 15 TPS）；在 Gas Limit 擴增後，TPS 亦沒有出現明顯的提升。

可能有些人會想說既然 12,000,000 Gas Limit 依舊壅塞，那怎麼不再往上提升？原因是 Gas Limit 的提升將導致每個區塊的處理時間變長，進而造成 Uncle Block 的數量增加，使得網路的共識機制變不健康，礦工必須耗費大量額外運算來進行處理。

此外，由於獨立節點與小型礦池更容易挖到 Uncle Block，長期下來出塊獎勵的期望值降低將導致部分節點入不敷出，進而離開網路。如此將讓以太坊網路變得更加中心化，更向大型礦池集中，危害了網路的長期健康與安全性。

Problem (B)：狀態爆炸

隨著越來越多的智慧合約被部署，以及大量的合約互動行為，導致以太坊網路需要儲存的「狀態」大小正以「等比級數」增長。狀態的增長即反映在節點的儲存空間大小上。

筆者於另一篇文章中摘要介紹了以太坊網路中的節點：
全節點與輕節點：以太坊節點面面觀 <10> 文組也該知道的區塊鏈技術知識

在 2019 年年底，全節點的每月增長大小「小於 20 GB」；到了 2020/06，隨著 Gas Limit 的提升，全節點的每月增長大小「逼近 40 GB」。狀態不斷加速增長的結果會對以太坊網路的性能帶來衰退與網路健康的損害。未來全節點的運行將會變得更加艱難，可能導致網路變得越來越「中心化」。

此外，區塊驗證的難度將隨之提升，導致整體網路的延遲與 TPS 的進一步下降。

儘管這個過程如同溫水煮青蛙，在數年之後才會導致以太坊網路出現巨大的安全性問題，然而為了避免走到那步田地，早在數年前便開始以太坊 2.0 的相關研究與開發。

以太坊的未來

Vitalik 於 2020/3/19 在推特上分享了他對於以太坊未來 5~10 年發展觀點的路線圖，主要由以下四個部分構成：

• eth 1.x other
• eth 1.x statelessness（無狀態性）
• eth 2 phase 0 prep（核心路徑，聚焦於 eth 1 ➔ eth 2 合併，移除PoW）
• eth 2 phase 2 and beyond

圖中間的橫軸代表時間線，沿著時間軸是一個從 Phase 0 啟動，到 Phase 1，再到「eth1 ➔ eth2 合併」的「核心路徑」。要完成合併有三個先備條件：

• eth 2 phase 1
• eth1 ➔ eth2 合併的規範與實現
• eth 1.x statelessness（無狀態性）

其中，「eth 1.x statelessness（無狀態性）」可說是對於 eth1 ➔ eth2 合併最至關重要的一個條件，本文將以「無狀態性」為主軸做相關的介紹。

狀態爆炸對以太坊網路的影響

由於以太坊區塊鏈的本質是一台依靠礦工維護的去中心化大型「狀態機」，隨著區塊數量的增加更迭狀態，不斷向前移動。以太坊的完整「狀態」包含所有個人帳戶和餘額的當前狀態，以及在 EVM 中部署和運行的所有智慧合約的整體記憶體。

以太坊網路在每個區塊高度都只有唯一一個獲得全網所有節點共識的「狀態」，這個「狀態」在每一個新區塊會產生變動並隨著區塊接至區塊鏈上。

礦工在執行交易運算時，必須依據交易內容至節點內以「Merkle-Patricia Trie 」資料結構組成的狀態樹中更改相關的狀態值，再重新計算出每個樹狀節點的 hash 值，算出新的「Merkle Root」，生成新的狀態樹。

截至 2020/06，當前的以太坊網路中約有 5 億個狀態值，總狀態大小約為 10 GB，狀態會隨著網路上的帳戶與智慧合約數量增加而按比例增長。因此，如果以太坊繼續獲得主流採納，狀態可能會在未來數年持續爆發性增長。不斷擴大的狀態主要會對節點造成兩大影響：

節點讀取狀態耗時增加，交易處理速度變慢

目前每個新區塊礦工大約需要添加或修改 3000~6000 個狀態值。由於礦工處理每一筆交易時都必須要讀取節點資料庫中狀態的相關資訊，當狀態數量持續增長，在狀態樹中查詢到指定狀態值的耗費時間就越長。

建構新的狀態樹耗時更長，區塊驗證速度減慢

當礦工將交易處理完時，必須建構一個由新的狀態組成的 Trie 結構狀態樹，當中涉及大量的 hash 值運算。計算完 Root Hash 方能建構出新的 Block Header，打包出新區塊。

小結

綜合來說，持續增大的「狀態」與「節點大小」將導致新的全節點啟動成本大幅提升：對於「儲存空間」的需求與「同步時間」的增加可能會進一步導致網路中全節點數量的減少。

此外，以太坊網路的整體性能下降也在所難免。以太坊隨著狀態樹查詢與運算耗時的增加以及越來越多的合約交易，TPS 可能會進一步下降，導致網路變得更加壅塞，迎來更高的 Gas Price 競逐。

eth 1.x 的提出

對於以太坊 1.0 升級的相關研究最早可以溯及到 2018/10 在捷克布拉格召開的 Devcon IV，會議談論到以太坊 2.0 無法在未來 3~5 年內完全取到以太坊 1.0 的所有功能，因此 eth 1.0 仍必須保持安全穩定運行，於是乎無數的核心開發人員開始研究一系列延長 eth 1.0 壽命以及與 eth 2.0 介接的解決方案。

既然狀態的持續增大對於以太坊網路的健康帶來重大影響，解決方案之一便是「消除以太坊網路對狀態的需求」。細看 Vitalik 於 2020/3/19 發布的以太坊未來路線圖中即可看到一系列的解決方案：

上述的路線圖是較為精要的版本，以太坊研究員 Griffin Ichiba Hotchkiss 於 2020/4/2 在 Ethereum Blog 分享了他對於目前 eth 1.x 研究開發方向的理解，整理出下圖的「技能樹」：

由於細節族繁不及備載，本文只會挑出其中幾個核心來做說明。有興趣的朋友可以參考並持續關注 Ethereum Blog 中的相關文章：

The 1.x Files: The Updated Stateless Tech Tree
（April 2, 2020）

The 1.x Files: A Primer for the Witness Specification
（May 4, 2020）

The 1.x Files: EIP 1559 and the Ethereum Improvement Horizon
（June 16, 2020）（Up to date）

eth 1.x 的目的

簡而言之，eth 1.x 的核心目的有兩個：

(A) 延長 eth 1.0 的壽命

在區塊持續增長的情況下維持 eth 1.0 區塊鏈的安全、穩定與彈性，讓人們可以選擇僅下載部分的狀態，在較便宜的硬體上運行節點。

(B) 與 eth 2.0 介接

由於 eth 2.0 中的分片（shards）將是無狀態的，因此「無狀態」將是參與 eth 2.0 區塊驗證的先決條件。eth 1.0 要與 eth 2.0 相容的話勢必得支援無狀態運作，方能順利過度，與 eth 2.0 介接。

為了達成這兩個目的，在技能樹圖最右側的終點我們可以看到「無狀態以太坊 Stateless Ethereum」。然而，「無狀態」的以太坊這個詞可能有些不夠精確，因為整個以太坊網路就是基於狀態而存在的。

具體來說，是找到一種方式讓以太坊網路中的部分節點可以將「保留整個以太坊狀態的副本」這件事變為一個選項，而非必須。因此，要讓現行的以太坊網路能夠支援沒有保存完整全網狀態的輕量級節點：「無狀態節點」參與到網路中的新區塊驗證。

而為了讓無狀態節點能夠進行驗證，以太坊 1.x 提出了以下三項主要改動，我們將逐一來進行介紹：

(1) 區塊見證機制

(2) EVM 改動

(3) 資料結構轉換為二進位制（Binary）

(1) 區塊見證機制

無狀態節點如何參與驗證

簡單來說，作法是：擁有全網狀態資訊的「完整狀態節點 Full State Node」在打包新區塊時會一併產生「區塊見證 Block Witness」，讓沒有保存全網狀態的「無狀態節點」能藉由區塊見證提供的資訊對新區塊進行驗證。

什麼是「區塊見證 Block Witness」

前面提到，以太坊的資料結構是由約 5 億個狀態值所構成的 Merkle-Patricia Trie。然而，其中大約只有 0.1% 狀態值（約 50 萬個）會隨著區塊高度產生變化，如：個人帳戶的 ETH 餘額、合約底下記載的每個地址持有 Token 數量。99.9% 的狀態值如：智慧合約的程式碼、Uniswap 手續費 0.3% 的參數等資訊一但智慧合約部署完成便不會再進行更動。

由於一個新的區塊（目前為 1,200 萬 Gas Limit）至多只能容納 571 筆交易，其涉及的狀態值更改是十分有限的。那麼一個沒有儲存所有狀態值的無狀態節點只要向擁有完整狀態的節點請求涉及交易的相關狀態值與未涉及到的 hash 值其實即可算出 Merkle Root 進行驗證。

如下圖所示，假設底層的 14 個菱形代表以太坊網路中所有的狀態值，而新區塊中僅有一筆交易，針對綠色的狀態值進行更改，那麼無狀態節點其實只需要 1 個綠色的原狀態值以及紫色的 Hash 值與其它未變動的 6 個 Hash 值資訊即能透過 4 次 Hash 值計算，算出新的 Root Hash（Merkle Root），而不需要擁有所有的 14 個狀態值來進行 9 次 Hash 值計算。

這些為了完成 Root Hash 計算所需要向擁有全網狀態資訊的「完整狀態節點（全節點）」請求的「最小資訊量」即為「區塊見證 Block Witness」，包含了狀態 Trie 中「不涉及變動的部分 Hash 值」與「涉及變動的原狀態值」。如此一來，沒有保存完整全網狀態的「無狀態節點 Stateless Client」將可以藉由請求而來的「區塊見證」資訊計算出新的 Root Hash。

為了便於讓無狀態節點參與驗證，目前的最新研究方向是「區塊見證」將可能成為「區塊標頭 Block Header」的一部分，隨著新挖出的區塊一併廣播給全網節點，讓無狀態節點不用再發起額外的「區塊見證請求」即能進行驗證區塊的動作。

透過這樣的方式，無狀態節點即能參與以太坊網路中新區塊的驗證。

礙於篇幅，我們在這篇文章只會做概念性的闡述，具體的實作細節先不展開細說，想更進一步瞭解的朋友可以參考我上方附上的連結以及以太坊部落格中的其它相關文章。

(2) EVM 改動

狀態值的更改和運算都是在 EVM 中進行，同理，區塊見證也必須經由全節點的 EVM 透過運算來生成。EVM 的改動目標與成本和激勵機制息息相關，主要包含耗費 Gas 的估算以及如何降低對節點間廣播延遲的影響。

區塊見證 Gas 計算（Witness Gas Accounting）

由於區塊見證必須由全節點花費額外的算力來運算生成，因此會產生相應的 Gas 成本，而這個成本目前比較可行的方式是由交易的發起者來進行負擔。至於如何讓交易發起者在發送交易時即能準確估算額外的 Gas，以設定精確的 Gas Limit，目前仍在研究中，尚未產生明確的定案。

另外，考慮到在同個區塊中可能有一個狀態值被不止一筆交易進行更改，因而產生重複支付 Gas 的情形，這部分可能會成為礦工額外的獎勵費用。

智慧合約程式碼分塊（Code Merkleization）

區塊見證的目的是為了讓無狀態節點能夠進行新區塊的驗證，其中必定包含了智慧合約相關的運算。然而，無狀態節點沒有儲存包含智慧合約程式碼在內的狀態，所以當無狀態節點要進行一筆智慧合約交易的狀態運算時，便需要一併擁有包含智慧合約程式碼的在內區塊見證。

這時會有另外一個問題，智慧合約洋洋灑灑的程式碼中可能只有其中的一小片段是與該交易運算相關聯的，因此「程式碼分塊」的概念被提出。

「程式碼分塊」是一種拆分智慧合約位元組碼（Bytecode）的方式，將智慧合約中與涉及交易相關的程式碼拆出，作為區塊見證中的一部分，一併提供給無狀態節點讓其做運算驗證之用。

其目的便是避免調用到不必要的程式碼，免於生成龐大的區塊鏈見證導致運算時間的增加及節點間傳遞溝通的延遲。

(3) 資料結構轉換為二進位制（Binary）

根據以太坊研究員 Igor Mandrigen 進行的實驗（Binary Tries Experiment），若將以太坊資料結構從目前的十六進位制（Hex）更改為二進位制（Binary），每個區塊的區塊見證大小將能從 800~3,400 kB 縮小至 300~1,400 kB，如此將大幅減低區塊見證在網路中傳播的延遲時間，讓區塊見證機制能夠運行得更加理想。

然而從 Hex 轉換為 Binary 具體的實作方式以及過度策略目前仍未有完全的定論，有興趣的朋友可以持續關注 Ethereum Foundation 釋出的相關消息。

無狀態以太坊 Stateless Ethereum

介紹至此，透過引入「區塊見證機制」、對「EVM」進行必要的改動，以及將資料結構轉換為「二進位制」，已能勾勒出 eth 1.x 的大致樣貌。

支援無狀態節點的 1.x 網路，將能夠對以太坊 1.0 的區塊鏈網路產生下方幾點關鍵影響：

<i> 對新加入節點更加友善

隨著全網狀態的膨脹與區塊高度的提升，啟動一個新節點的同步時間會變得越來越長（截至 2020/06，啟動一個新全節點需要同步至少一週的時間），超長耗時的原因是因為全節點的同步必須從創世區塊開始對每一個區塊進行驗證與同步的動作，而驗證區塊必須要擁有該區塊高度的全網狀態，因此在每一個區塊同步狀態是目前同步節點的極大瓶頸。

無狀態節點時代的到來將能夠大幅改善同步區塊的痛苦過程，未來僅需憑藉「區塊標頭」與「區塊見證」即能完成區塊的驗證，同步節點體驗的改善將能讓更多人有意願且能夠負擔運行節點的成本（時間與硬體資源）。

<ii> 輕節點得以自力更生

在現行的以太坊網路中，輕節點不具備獨立驗證新區塊與驗證交易的能力，因為輕節點沒有保存驗證交易需要的 merkle proof 資訊，因而必須向鄰近全節點發出 p2p request 進行請求，但輕節點現在願意提供支援的佛心全節點變得越來越少。

無狀態機制將能幫助輕節點依靠自己維護的部分狀態（自己帳戶與合約的餘額等資訊），以區塊標頭和區塊見證獨立進行驗證，不求於人。

<iii> 節點網路安全性提升

由於區塊鏈網路的安全性取決於能參與新區塊驗證的節點總數量，對網路的攻擊成本將隨著節點總數量的增加而提高，能有效地低系統被擊潰的風險。

隨著新節點啟動成本的降低以及大量的輕節點投入到新區塊的驗證中，將讓網路的整體安全性大幅提升。

<iv> 介接 eth 2.0

最後一點也是最核心的一點，前面提到 eth 2.0 將會是由核心的信標鏈與多條分片鏈構成，全網的狀態將被多個分片分開儲存。由於每條分片各自擁有不同的狀態，並且沒有保存其它分片的狀態資訊。因此對每條分片來說，其它條分片都像是「無狀態節點」。

為了能夠在多條分片鏈間有效驗證與同步，必須依靠「無狀態的驗證機制」。因此現在的 eth 1.0 未來要能順利成為 eth 2.0 的其中一條分片鏈，升級為無狀態的 eth 1.x 是至關重要的一個步驟。

結論

透過以上介紹，相信讀者們應該對於現行的 eth 1.0 升級到 eth 1.x 需要進行的改動，以及改動完成後的未來有更清晰的認識。

在 eth 1.x 升級完成後，人們將能用便宜的硬體運行自己的無狀態節點（輕節點），更多能夠參與驗證的輕節點可以進一步維護全網的安全性。

擁有無狀態驗證機制的 eth 1.x 方能順利和 eth 2.0 的信標鏈與其它分片鏈介接，正式讓以太坊網路進入由無狀態驗證機制與分片技術構築成的輕量化 eth 2.0 未來。

以上，若有任何

A. 我寫得不夠清楚的地方
B. 撰寫上改進的建議
C. 希望我能夠撰寫分享的區塊鏈技術知識內容

都非常歡迎在底下留言回覆。希望我的文章能幫助到更多像我一樣想學習區塊鏈技術與知識的朋友。如果您覺得讀完有所收穫，也希望能

• 給我 50 claps
• 分享給您的朋友們

謝謝大家！

也歡迎大家閱讀區塊鏈技術知識系列的其它篇文章：
https://medium.com/pelith/blockchain-technical-overview-8c2a643424fa

eth 1.x 與無狀態節點介紹：從以太坊區塊鏈當前的困境談起 was originally published in CryptoCow on Medium, where people are continuing the conversation by highlighting and responding to this story.

收看本系列文章的讀者，應該都對於區塊鏈的基本原理和架構有些概念，如果沒有，推薦您先去 Google 搜尋 區塊鏈、比特幣、以太坊這些關鍵字了解一下。我們將在這些基礎概念之上，來談區塊鏈的技術知識。本系列文章並不會談到太深的技術鑽研，而是希望以深入淺出的方式讓每一個想要搞懂區塊鏈技術的人都能在讀完後說出：原來如此！

本系列文章由區塊鏈技術解決方案開發公司：Pelith 編撰。內容皆經過諸位區塊鏈資深研究員及開發者校對與驗證，盡可能確保內容正確無誤，讓讀者能安心吸收正確的區塊鏈技術知識。

在本系列過往的文章中我們逐一介紹了以太坊各個環節的運作機制，相信有在持續關注的讀者都已對以太坊技術架構有粗略的認識。

上一篇 我們用較長的篇幅完整解析「預言機 Oracle：區塊鏈與現實世界的橋樑」。

因應以太坊 2.0 的即將來臨，本篇文章將針對以太坊節點（Ethereum Nodes）做概論性的介紹，讓讀者能充分瞭解節點的運作機制。

以太坊網路 Ethereum Network

以太坊 Ethereum 是由分散式節點所組成的網路架構，這些節點稱為「以太坊節點 Ethereum Nodes」或「以太坊客戶端 Ethereum Clients」。任何人只要有規格足夠的電腦硬體設備都能夠加入以太坊網路中成為節點，貢獻算力賺取區塊挖礦獎勵。截至 2020/05，分佈在全世界各地的以太坊節點總共約有 5,756 個。

在當前的以太坊網路中，每個節點都是相互平等的，彼此間即時溝通「同步區塊資料」及「打包待出塊的交易（挖礦）」來維持以太坊區塊鏈的運作，我們可以透過下圖一覽節點的主要作業內容：

以太坊節點所做的工作

• Receive Transactions：接收來自 DApp、錢包 或 其它節點 的交易資訊
• Receive Blocks：從其它節點接收區塊資訊同步至最新的區塊高度
• Validating：驗證新的區塊之正確性、驗證待處理交易之有效性
• Executing：處理交易，進行運算並更改狀態值，打包成新區塊
• Mining：用電腦算力來計算 nonce 值，最先找到 nonce 值出塊並廣播的礦工可以獲得區塊獎勵與所有交易之手續費（Gas）
• Consensus：通過共識機制達成全網帳本之一致性或區塊重組（reorg）

以上便是以太坊節點常態性的工作內容，正是這些分佈在全球的數千個節點們不間斷地工作維繫了以太坊區塊鏈的正常運作。

然而其實節點有許多不同形式，上述參與所有工作內容（包含接收、驗證、挖礦）的節點僅是大眾普遍認知的其中一種形式，接著我們將介紹現行各種不同形式的節點。

以太坊的節點種類 Ethereum Nodes

在以太坊網路中，節點大致可被分為「全節點 Full Node」、「輕節點 Light Node」、「歸檔節點 Archive Node」三大類。我們將逐一來進行介紹。

全節點 Full Node

全節點是擁有完整區塊鏈帳本資料的節點，具備獨立驗證的能力來確認交易之有效性。具體來說全節點主要在處理下列四件事：

1. 儲存所有歷史交易資訊，資料公開透明
2. 監測礦工挖出來的新區塊，驗證其合法性後同步該區塊
3. 監測區塊鏈網路中的新交易資訊，驗證每個交易的合法性
4. 將驗證過的「交易／區塊資訊」廣播給全網路節點

一個節點只要下載了完整且最新的區塊鏈資料，穩定運行驗證交易和同步區塊資訊，那它就是一個全節點了。由於每一個全節點都保有全網資料，所以即使其中部分節點出現問題，例如斷網或被駭客攻擊，都不會影響整個區塊鏈網路的安全性。這即是「去中心化」記帳系統的優勢所在。

同時，全節點的數量越多，也代表完整的區塊鏈帳本被保存的份數越多，「不可篡改性」也就越強，整個區塊鏈網路的安全性也隨之提升。一但有人企圖組織算力叛變，試圖改變區塊共識或發動雙花攻擊，其它正常運作的全節點可以即時驗證拒絕掉這些交易。

隨着持續增加的交易記錄與智慧合約部署，全節點所需的儲存空間也在不斷增長。截至 2020/05，以太坊全節點的資料大小已經超過 360 GB，並以每個月約 30 GB 的速度持續增長中。

礦工節點

挖礦的過程即是將驗證過的待處理交易打包成新區塊，並以電腦算力來計算 「nonce 值」，最先找到 nonce 值成功出塊並廣播的礦工會獲得區塊獎勵與所有交易之手續費（gas）作為報酬。

礦工必須要運行全節點才能即時瀏覽區塊鏈歷史資料進行交易驗證，再將驗證通過的交易進行打包。因此，所有礦工必定是全節點；然而全節點未必是礦工，運行全節點的人未必會花費電腦算力去參與新區塊 nonce 值的運算來爭取區塊獎勵。

輕節點 Light Node

輕節點顧名思義即是輕量級的節點，具體定義是不儲存或維護完整的區塊鏈副本，只儲存最小量的狀態來作為發送或傳遞交易訊息的節點。至於輕節點究竟儲存了哪些狀態，我們得先透過下圖瞭解以太坊的資料結構：

Block Header and Body

以太坊的每個區塊主要分為 Header 和 Body 兩個部分存儲，Body 即是交易列表；Block Header 則較為複雜，包含了前個區塊的 Hash、時間戳及挖礦難度等相關參數。

在 Block Header 中採用一種名為 Merkle-Patricia Trie (MPT) 的核心資料結構來儲存區塊鏈資訊，可以理解為把帳本分割成無數個小的資料塊，每個資料塊像是一棵樹中的無數葉片，而我們把每兩個相鄰的葉片合併成一個字串，並算出該字串的 Hash 值。如此過程經過無數次後，最終如同所有樹枝歸向一個樹幹一般，會得到一個包含了所有區塊資料的 Hash 值，稱為「Merkle Root」。

輕節點資訊

全節點儲存了所有區塊的 Block Header 與 Body（交易列表），而輕節點只儲存最小量的狀態：即「區塊標頭 Block Header」，藉此大幅降低儲存空間的需求。截至 2020/05，以太坊主網上約有 1017 萬個區塊，而每個區塊標頭的大小約為 508 bytes，故輕節點的大小約為 4.8 GB。

輕節點如何驗證交易

由於割捨掉區塊的 Body，即所有歷史的交易列表，因此當輕節點需要驗證某個交易的合法性時，具體做法為：

1. 向鄰近的全節點發起確認請求
2. 全節點收到請求後提供所需相關資訊供驗證

需要向全節點請求的原因是：假設有一個合約執行的交易，那麼便必須要有該合約部署時的原始碼（位在 Contract Created 之交易中）。由於該交易位於某個區塊之 Body，故輕節點必須要向全節點請求該合約之相關資訊方能進行交易驗證。

輕節點的特色摘要

整體而言，輕節點大致上具備以下幾點特色：

• 只儲存每個區塊的區塊標頭 Block Header
• 不一定保持隨時在線（獲取最新的 Block Header 資訊）
• 根據需求可以只保存與自己相關的交易內容
• 無法驗證大多數交易的合法性，只能驗證與自己相關交易的合法性
• 無法驗證新區塊的正確性
• 只能檢測到當前的最長鏈，但無法知道哪條是最長合法鏈

由於輕節點必須要向全節點請求與交易驗證相關的 Block Body 資訊，那麼要怎麼知道全節點回傳的資訊是正確的呢？

這時就要回到以太坊的資料結構來談，前面提到輕節點為了減少儲存空間，而割捨掉 Block Body，僅保留作為驗證之用的 Block Header。由於存有已經驗證合法之 Block Header，因此當未來需要驗證相關交易時只要透過跟全節點請求相關的 Block Body 資訊即可進行驗證，不需要從頭驗證整個區塊。

Block Header 與交易驗證

輕節點能夠利用 Block Header 驗證交易的原因為： Block Header 中的 Merkle Root 即是由 Block Body 中的交易資訊經由雜湊演算法（Hash Algorithm）生成的「數位指紋（Digital Fingerprint）」，因此 Block Header 可以充分代表 Block Body 內的資訊。

Block Header 中的 Merkle-Patricia Trie 是一個生成 Hash 需要花費大量算力，但驗證非常迅速的結構。當輕節點收到全節點提供的資訊時，便能夠利用已有的 Block Header 相關訊息迅速驗證該資訊是否正確，進一步進行交易驗證。

介紹完全節點與輕節點後，最後我們來介紹 Archive Node，即歸檔節點。

歸檔節點 Archive Node

「歸檔節點」是在全節點的基礎之上，額外儲存了每個區塊高度的區塊狀態（個人帳戶與合約帳戶之當時餘額等資訊），即針對每個區塊高度當下的狀態進行快照並存檔。歸檔節點能讓你快速回到某個區塊高度去查詢當下狀態：例如你想要知道某一個帳戶在區塊高度 #5,000,000 的餘額時便會派上用場。

歸檔節點截至 2020/05 的資料大小已經超過 4 TB，對硬體要求相當龐大。通常只有特殊的服務如「區塊鏈瀏覽器：Etherscan」或「RPC Endpoint Provider：Infura」等底層服務會有架設歸檔節點的需求，大多數的情況全節點已非常足夠。

歸檔節點與安全性

歸檔節點對於區塊鏈的信任模型與整體安全性原則上「不會有額外的加成或影響」，全節點（包含挖礦節點）已能充分保障全網路的安全。然而如果沒有人繼續維護歸檔節點的話，查詢區塊鏈上的歷史資料得花費許多的時間。Archive Node 保存了區塊鏈上的完整歷史紀錄與資料，以及所有區塊高度的當時全網狀態。

截至 2020/05，以太坊全網的歸檔節點總數量約為 100 個。

最後，我們透過下方的圖表來綜覽三種節點之異同：

結論

1. 在以太坊網路中，節點大致可被分為「全節點 Full Node」、「輕節點 Light Node」、「歸檔節點 Archive Node」三大類。
2. 輕節點（Light Node）僅儲存了區塊標頭 Block Header，沒有儲存 Body。當需要驗證交易時會向鄰近的全節點發起相關資訊請求以進行驗證。
3. 歸檔節點（Archive Node）即在全節點基礎之上多儲存了每個區塊高度的狀態（State）快照，供檢索相關用途。

介紹至此，讀者應該對於節點有初步的認識。未來，我將在這基礎之上進行以太坊 2.0 上線前的過度階段「以太坊 1.X」相關介紹，敬請期待！

以上，若有任何

A. 我寫得不夠清楚的地方
B. 撰寫上改進的建議
C. 希望我能夠撰寫分享的區塊鏈技術知識內容

都非常歡迎在底下留言回覆。希望我的文章能幫助到更多像我一樣想學習區塊鏈技術與知識的朋友。如果您覺得讀完有所收穫，也希望能

• 給我 50 claps
• 分享給您的朋友們

謝謝大家！

也歡迎大家閱讀區塊鏈技術知識系列的其它篇文章：
https://medium.com/pelith/blockchain-technical-overview-8c2a643424fa

全節點與輕節點：以太坊節點面面觀 <10> 文組也該知道的區塊鏈技術知識 was originally published in Pelith on Medium, where people are continuing the conversation by highlighting and responding to this story.

收看本系列文章的讀者，應該都對於區塊鏈的基本原理和架構有些概念，如果沒有，推薦您先去 Google 搜尋 區塊鏈、比特幣、以太坊這些關鍵字了解一下。我們將在這些基礎概念之上，來談區塊鏈的技術知識。本系列文章並不會談到太深的技術鑽研，而是希望以深入淺出的方式讓每一個想要搞懂區塊鏈技術的人都能在讀完後說出：原來如此！

本系列文章由區塊鏈技術解決方案開發公司：Pelith 編撰。內容皆經過諸位區塊鏈資深研究員及開發者校對與驗證，盡可能確保內容正確無誤，讓讀者能安心吸收正確的區塊鏈技術知識。

上一篇 我們解析了「為何發送 ERC20 Token 需要兩次交易」，本篇文章將用較長的篇幅來帶大家完整認識 預言機 Oracle：區塊鏈與現實世界的橋樑。

2019 年普遍被認為是屬於 DeFi 的一年。然而，隨著各式去中心化金融應用的蓬勃發展，背後不可忽視的議題：「Oracle」也逐漸被重視。

什麼是 Oracle？

我們從《精通以太坊》的定義來看：

《精通以太坊（Mastering Ethereum）》Chapter 11: Oracles

Oracles provide a crucial service to smart contracts: they bring external facts to contract execution.
（翻譯）Oracle 為智慧合約提供關鍵的服務：把外部事實帶進合約中執行。

在進入本文之前，想先問讀者一個問題：

「要如何設計一個讓智慧合約取得鏈外資訊的方法？」

希望讀者在閱讀本文之前都能先來思考看看，假設區塊鏈上的智慧合約需要區塊鏈外部的資訊來觸發與執行，那麼我可以如何做到這件事呢？這個架構的設計會長什麼樣子？有哪些決定性的細節？

好，接著我們進入本文的脈絡：

為什麼區塊鏈需要 Oracle？

由於區塊鏈是一個封閉的系統環境，目前區塊鏈只能獲取到鏈內的數據，而無法獲取鏈外真實世界的數據。

本質上來說，智慧合約即寫好了條件和結果的程式碼，當特定條件被給予或滿足時即能夠觸發。而若智慧合約執行需要的觸發條件是區塊鏈外部的訊息時，就必須要依靠 Oracle 提供數據，透過 Oracle 將現實世界的數據輸入到智慧合約中。

因為智慧合約只能被動接收數據，無法主動去獲取鏈外的數據，這就是區塊鏈需要 Oracle 的原因。

Oracle 的實際應用情境

Oracle 作為現實世界數據與區塊鏈的橋樑，各式各樣的區塊鏈應用都需要 Oracle 提供外部數據。例如：穩定幣、借貸平台、金融衍生品交易平台、預測市場、博弈遊戲、保險等。

博弈遊戲與隨機數

我們首先來談為什麼「博弈遊戲」需要 Oracle。無論是拉霸、撲克牌、柏青哥等各樣的博弈遊戲都有個核心：「隨機性」，由於在區塊鏈上的隨機數都是可以被預測和破解的，因此一種可行的方式是依靠 Oracle 從外部餵給智慧合約不可預測的隨機數。

智慧合約保險與理賠

區塊鏈上的智慧合約保險也是，假設某間公司推出了透過智慧合約執行的車禍保險，究竟有沒有發生車禍、情節嚴重性及應理賠金額其實都必須要靠人來定奪並透過 Oracle 從外部餵入資訊給智慧合約才能觸發理賠執行。

去中心化金融與即時價格資訊

最常見且大宗的應用莫過於「DeFi」相關領域。各式各樣與加幣貨幣幣價或現實世界中的金融產品相關的應用前仆後繼被推出，而這些金融應用不可或缺的「即時價格資訊」便是存在於區塊鏈外的現實世界當中，必須仰賴 Oracle 來將資訊餵入區塊鏈（智慧合約）當中。

光是說明可能不夠清楚，我們實際來看一些牽涉 Oracle 的大型專案案例：

去中心化美元穩定幣「DAI」的 Oracle 實作

（以舊版的 DAI： Single Collateral DAI －現名 SAI 來作說明）

不可諱言，在 DeFi 世界中最重要的 Oracle 即 MakerDAO 的 ETHUSD 價格 Oracle，廣大的去中心化金融應用生態系都圍繞著 MakerDAO 與 DAI 開展。
(截至 2020/01，DeFi 總市值約 7 億美元；MKR 總市值約 5 億美元；DAI 總市值約 1 億美元)

儘管「MKR/DAI 的代幣對」與「DAI 的抵押生成機制：CDPs (Collateralized Debt Positions)」都是完全去中心化地進行，但整個 MakerDAO 系統仍有一個重大的潛在罩門：系統需要仰賴一個「Oracle」提供準確的 ETHUSD 即時幣價資訊。

註：舊版 DAI (SAI) 的抵押生成需參照 ETH 的即時幣價。假設 ETH 幣價為 150USD，則抵押一顆 ETH 最多可以生成 100 顆 DAI，抵押品的價值必須大於鑄造 DAI 的 150%，亦即幣價一但跌到 149USD 便會觸發清算機制。

由於幣價資訊來自區塊鏈外部（CoinMarketCap 即為諸多交易所之加權平均現價）因此 MakerDAO 的智慧合約必須從區塊鏈外部不斷獲取即時幣價資訊以利 CDPs 與清算作業的進行。《MakerDAO Whitepaper》

我們馬上來一探究竟牽動整個 DeFi 生態系的 MakerDAO Oracle 如何實作：

MakerDAO 的 Oracle 架構

MakerDAO 智慧合約系統運行所需要的 ETHUSD 幣價是透過一個名為「Medianizer」的 Oracle 智慧合約來提供；Medianizer 獲取最新幣價資訊的方式是藉由 14 個相互獨立的外部「Price Feed」單位通過智慧合約輸入。

幣價的即時更新方式

14 個「Price Feed」會隨時監控 MakerDAO 官方公告的「先前共識價格」，並在每當：

1. 「ETH 最新時價」與官方公告的「先前共識價格」有一定比例差距時（目前定為 1%）
2. 距離上一次的價格更新已經超過 6 個小時

以上兩個情況時，「Price Feed」將提交最新的幣價資訊給 Medianizer。

Medianizer 收到多個新幣價資訊後，將會取「所有收到幣價的中位數」作為新的「共識價格」並輸入 MakerDAO 生態系的智慧合約中。這樣的共識機制只要有超過 50% 的「Price Feed」提供正確資訊系統便能維持安全穩定。
（至多 6 個「Price Feed」相互串通餵入錯誤幣價資訊時將不會影響最終的共識價格，即未達 51% 攻擊）

至於這 14 個「Price Feed」究竟是何方神聖？
為什麼他們願意發送交易為 MakerDAO 提供幣價呢？
讓我們繼續看下去！

MakerDAO 的 Oracle 生態系運行

MakerDAO 的獨特之處在於它是一個 去中心化自治組織（D.A.O. — Decentralized Autonomous Organization），從穩定幣 DAI 的發行乃至 Oracle 都有設計去中心化的機制來運行。

Price Feeds

為 MakerDAO 生態系提供幣價資訊的「Price Feeds」將獲得 DAI 作為報酬，以此獎勵它們的服務並阻擋它們行惡意行為的意圖。
（註：目前的 DAI 獎勵是由 Maker Development Fund 基金資助，MakerDAO 規劃未來獎勵將從 Maker Protocol 的 stability fees 提撥。）

而 Price Feeds 的真面目其實是由 MKR Token 持有者投票決選出的 14 個白名單地址（已知部分為大型交易所）。

表現好的地址（有持續、準時為 MakerDAO 提供正確幣價資訊）將能夠留在白名單中賺取獎勵報酬；

表現不好的地址（偷懶沒有提供幣價資訊或提供錯誤幣價資訊）則可能馬上被 MKR Token 持有者們罷免汰換掉。

小結

以上便是核心版的 MakerDAO Oracle 生態系解析，為了避免篇幅過長及便於閱讀，有省略了部分細節。有興趣更深入了解的朋友可以在上方篇幅中的底線處找到 reference 連結。

介紹完 MakerDAO 獲取 ETHUSD 幣價資訊的 Oracle 實作方式後，可以發現 MakerDAO 需要 Oracle 餵入的是相對單純的「ETHUSD」單一資訊。然而，假設需要的是更多種類的資訊，例如：在區塊鏈上打造一個去中心化的預測市場，該如何將「球賽勝負」或是「選舉結果」等資訊餵入區塊鏈呢？

緊接著我們來介紹另一個有趣的 Oracle 實作項目：

為去中心化預測市場而生的 Oracle: Augur

Augur 是一個架構上有些複雜的預測市場平台，我們試著長話短說精要核心地介紹它。

每個人都可以在 Augur 上創建預測市場，而預測市場簡單來說就是提出一個「是非題」或是「選擇題」。我們實際透過一個範例來瞭解 Augur 的實作流程，「假設」有人在 Augur 上開立一個預測市場題目：

「2020 年台灣總統大選的當選人會是？A. 宋O瑜、B. 韓O瑜、C. 蔡O文」

直到 2020 年 1 月 11 日選舉結果出爐前，任何人都能夠在 Augur 上針對三個選項進行下注（投入以太幣）。

當結果出爐時，創建這個預測市場的人必須作為 Oracle 去將選舉結果回報給智慧合約以進行清算。

如果回報的結果是正確的，那麼本盤預測市場將在經歷一段 異議提出期間（3–10 天）的等待後完成清算，就此結束。

然而，若回報的是 錯誤的結果（例如：A. 宋O瑜當選，卻回報 B. 韓O瑜），或者是有人 對於技術細節有不同意之處（例如：1 月 11 日當天電視台已經開始開票了卻還能在 Augur 上下注）。那麼想提出異議的人能透過抵押部分的 Augur 平台治理代幣「REP」至其它的結果來進入「爭論期間」。

接著，其他的 REP Token 的持有者將作為這盤預測市場的「裁判」來投票：究竟哪個結果才是正確的？

系統會將獲得最多票數的結果視為正確結果，所有投票給正確結果的 REP Token 持有者將可以獲得獎勵，投給其它結果的人將不會獲得。
（投票結果出爐後仍然會有一段提出異議的期間，如果無異議將清算結束；若是有人想提出異議需要抵押更多的 REP Token 展開新一輪的投票。）

這樣的流程大致上如同下方這張官方製作的流程圖所示：

至此，我們便核心地介紹完了 Augur。總結來說，

1. 在 Augur 上創建預測市場的人將作為 Oracle。
2. REP Token 的持有者將作為裁判，檢視提出異議的預測市場並確保 Oracle 回報的是真實的結果。

Augur 透過這樣的獎勵機制將能讓平台變得更加值得信賴與可靠，對當中許多的技術實作細節有興趣更深入瞭解的朋友可以參考官方的 白皮書。

最後，我們來介紹以太坊上的第一個嘗試提出的去中心化 Oracle 解決方案：

去中心化 Oracle 網路：Chainlink

有別於 Augur 透過「挑戰機制」處理中心化 Oracle（個人）餵入錯誤資訊的問題。Chainlink 試圖解決 Oracle 餵入錯誤資訊的方式是導入一個由去中心化 Oracle 網路組成的「中介層：Chainlink Nodes」。

比起由 Chainlink 這個組織本身提供數據資訊會造成的中心化信任問題，Chainlink 整合了從不同數據來源獲取數據的眾多「Data Feeds（數據提供者）」來提供一個共識過的「數據資訊」，有些相似於 MakerDAO 的共識機制。

Chainlink 的 Oracle 實作方式

Chainlink 透過鏈上的「Oracle 智慧合約」與鏈外的「Chainlink 節點」實現去中心化的架構。假設鏈上的一個「DeFi DApp（智慧合約）」想要透過 Chainlink 取得 CoinMarketCap 的幣價資訊，那麼取得資訊的流程大致上是如下圖所示：

Chainlink 的 Oracle 實作流程

1. 用戶的智慧合約（DeFi DApp）發起一個鏈上的請求；
2. Chainlink 的智慧合約收到請求後在鏈上記錄下這個請求的內容；
3. Chainlink 節點內的「區塊鏈接口（Core）」抓取這個請求內容並發送給對應「外部接口（Adapter）」；
4. 「外部接口」按請求內容至外部 API（CoinMarketCap）取得數據資訊；
5. 「外部接口」將數據格式整理完成後派送給「區塊鏈接口」；
6. 「區塊鏈接口」將數據資訊回報給 Chainlink 智慧合約；
7. Chainlink 智慧合約將一至多個節點回傳的數據資訊進行一次共識並發送結果給用戶智慧合約。

Chainlink 的節點網路 Oracle 架構

Chainlink 的架構核心即為由許多的數據提供者組成的鏈外「Chainlink 節點網路」，想要成為在 Chainlink 網路中提供數據的節點必須要抵押特定量的 Chainlink 平台治理代幣「LINK」Token。使用者如果想要透過 Chainlink 來取得數據資訊時需要以 LINK 來支付費用，而這些 LINK 將會分配給提供正確數據資訊的節點們作為報酬。而提供錯誤資訊或是有其它異常行為的節點將會被扣除部分抵押的 LINK 作為懲罰。

透過這樣的方式，去中心化的 Chainlink Oracle 網路試圖透過抵押與獎懲機制來提供一個比起中心化的 Oracle 在架構上更加穩定的解決方案。

Oracle 與經濟學上的「賽局理論 Game Theory」

介紹至此，相信大家都對於 Oracle 有了基礎的概念與認識，各式各樣的 Oracle 架構要解決的都是同一個問題：「如何『安全地』把鏈外的『正確』資訊送入鏈上的智慧合約中」。而之所以要強調「安全」與「正確」，即是為了盡可能減少 Oracle 餵入錯誤資訊的動機，或是增加這麼做的成本。怎麼說呢？

我們再回到前述提到的台灣總統大選預測市場的案例來說明：
「2020 年台灣總統大選的當選人會是？A. 宋O瑜、B. 韓O瑜、C. 蔡O文」

假設這個預測市場是透過呼叫 Chainlink 來取得外部 API 資訊，而我恰好是營運 Chainlink 節點來提供這個數據資訊的人，且又剛好在 Chainlink 上只有我一個節點有提供台灣總統大選結果的 API。

假設這個預測市場中 A. 宋O瑜 的賠率最高。這邊會出現一個有趣的賽局（Game）：

如果我預期我能在這個預測市場中從 A. 宋O瑜 選項獲得的報酬價值多過我所抵押的 LINK Token 總價值，那麼我便有十足的誘因去「重注下在 A. 宋O瑜 選項上」。並在選舉結果出爐後，這個預測市場呼叫我的節點來提供數據資訊時「故意回報錯誤的 A. 宋O瑜 當選資訊」，藉此來賺取報酬。即使 Chainlink 後續發現我回報了錯誤的資訊而扣押了我所抵押的 LINK Token 作為懲罰，但我經由回報錯誤的外部資訊賺取了更高額的報酬。

透過上述的說明我們可以發現 Oracle 要解決的其實不只是技術問題，更重要的是「經濟學問題」。無論是 MakerDAO、Augur 或是 Chainlink，其實區塊鏈外部的資訊最終都仍是由「人」來回報給區塊鏈。因此，一個好的 Oracle 應該要具備以下的特性：

「隨著市場規模的擴大，Oracle 的攻擊成本也要相應的提升」

無論是球賽賭盤、保險、預測市場等各式各樣需要仰賴 Oracle 來提供外部數據資訊的服務，參與者都必須要有所認知：「一但餵入錯誤資訊的預期獲利大於成本，Oracle 就有十足的動機來這麼做，因此這個 Oracle 即處在不安全的狀態中。」

我們在參與去中心化金融與各式的區塊鏈應用時，除了注意如何操作、好不好用，當產品或平台牽涉到區塊鏈外部的資訊時，我們更應該注意這個專案的 Oracle 實作方式。

若是一個預測市場或賭盤的 Oracle 成本不會隨著賭盤總投注資金的上升而讓攻擊成本上升，那麼這個 Oracle 便存在著結構性風險。一但 Oracle 餵入錯誤資訊的成本小於能夠從賭盤獲得的利潤，將讓平台陷入 Oracle 攻擊風險當中。

在

各大專案的 Oracle 實作方式解析

我們實際帶大家來看幾個有牽涉到區塊鏈外部資訊的平台 Oracle 實作方式：

去中心化借貸平台 Compound 的 Oracle 實作

首先我們來看看大家最熟悉的「去中心化當鋪」：Compound Finance，槓桿交易的操作員可以透過在 Compound 上抵押借貸資產來做多或做空。而 Compound 需要仰賴 Oracle 來獲取即時的幣價資訊更新抵押率以進行清算。雖然號稱 新版的 Oracle 即將推出，不過截至撰文當下仍尚未啟用，應仍是以白皮書上記載的舊版架構來營運。

我們直接來看 Compound Whitepaper 上的論述：

大意：Compound 的 Price Oracle 會從前十大交易所抓取幣價資訊並進行整合。根本來說仍然是由 Compound 團隊以中心化的方式來實作。

去中心化合成資產平台 Synthetix 的 Oracle 實作

接著看到 Synthetix：以太坊上的去中心化合成資產發行協議，同時也是全世界 DeFi 領域總市值第二大的平台（截至 2019.12.31 約有價值 1.7 億美元的加密貨幣資產投入該平台，僅次於 MakerDAO）。透過抵押平台幣 SNX 可以發行出各樣的虛擬資產，如：法幣（美元、歐元、日幣等）、商品（金、銀、石油）、虛擬貨幣（BTC、ETH）等。

Synthetix 需要透過 Oracle 不斷餵入即時外部資訊來追蹤這些商品的時價，讓投資者不必真的持有外幣或黃金，也能參與這些投資標的的漲跌幅。而這樣需要眾多即時且大量外部資訊平台的 Oracle 究竟如何實作呢？我們可以在官方文件 Synthetix Litepaper 中找到相關論述：

大意是：Synthetix 的 Oracle 是由 Synthetix 的官方團隊來運作，透過演算法抓取多個數據來源整合（就是 Synthetix 團隊中心化來處理）。然而，最後提到有規劃在未來將把 Oracle 給去中心化，就在 2019 年 12 月 18 日，官方宣佈了與 Chainlink 合作的消息，未來將會透過 Chainlink 來為 Synthetix 上的各樣合成資產即時報價。

最後，我們來看另一個同樣牽涉到 Oracle 的以太坊社交博弈平台：Bethereum。

去中心化運動博弈平台 Bethereum 的 Oracle 實作

如果你有玩過 PTT 上的樂透，那你就知道它在玩什麼。簡而言之就是體育與電競賽事的博弈，與運彩不一樣的地方在於 Bethereum 上的賠率不是由莊家訂定，而是由所有的下注者共同決定的。用一場 NBA 比賽做範例說明：「2019/12/25 快艇 vs 湖人」，比賽結果只會有兩個選項「A. 湖人贏、B. 快艇贏」，當下注湖人贏的總額變多時，湖人贏的賠率就會下降；而快艇贏的賠率會上升。

好，Bethereum 平台怎麼玩不是重點（抱歉離題），重點是當這場比賽的打完，結果出爐後（快艇贏），必須要靠 Oracle 來將比賽結果資訊給餵入區塊鏈智慧合約中，好讓所有下注的總額能按比例平分給正確下注快艇贏的玩家。同樣我們可以在官方的 Bethereum Whitepaper 中找到 Oracle 的說明：

大意：Bethereum 獲取鏈外資訊的 Oracle 實作方式是會從多個數據來源搜集有效數據（反正就是 Bethereum 平台中心化處理）。不過最後有提到若結果有爭議將會退盤，也意味著在智慧合約中仍留有後門可供人操作。

結論

1. 中心化 Oracle 與信任議題

可以看到在上述三個案例中（Compound、舊版 Synthetix、Bethereum），Oracle 都是由平台方中心化地來處理，對於使用者而言其實仍然存在一定程度的風險。根本來說使用者必須相信平台為了平台名譽不會亂搞（餵入假的數據資料）。然而，如此便又回到了中心化的問題當中，使用者信賴的對象仍然是「平台營運方」，而非架構本身，實是有違去中心化的精神與真諦。

2. 觀察專案的 Oracle 實作方式

在瞭解什麼是 Oracle 之後，未來在參與去中心化金融與各式的區塊鏈應用時，除了注意平台如何操作、介面好不好用、能如何賺錢套例外，當平台牽涉到區塊鏈外部的資訊時，我們更應該注意這個專案的 Oracle 實作方式，才不會讓自己的寶貴資產陷於風險當中。

若是一個預測市場或賭盤的 Oracle 不會隨著賭盤總投注金額的上升而讓攻擊成本上升，那麼這個 Oracle 便存在著結構性風險。一但攻擊 Oracle 餵入錯誤資訊的成本小於能夠從賭盤獲得的利潤，將讓 Oracle 陷入被攻擊的風險當中，任何人有權影響 Oracle 餵入資訊的人都會有十足的犯罪動機。

至此，相信大家都已正確建立對 Oracle 的認識，目前 Oracle 其實仍是個較新的議題，不過誠如本文論述主旨：

「Oracle 要解決的不只是技術問題，亦是經濟學問題」

許多的專家仍在著手研究提出更理想的 Oracle 架構。期許未來能看到更多樣化的 Oracle 解決方案。

下一篇，我們將針對以太坊節點（Ethereum Nodes）做概論性的介紹，包含輕節點 Light Node、全節點 Full Node 與 歸檔節點 Archive Node，讓讀者能充分認識節點與其背後的運作機制。

文章連結：

全節點與輕節點：以太坊節點面面觀 <10> 文組也該知道的區塊鏈技術知識

以上，若有任何

A. 我寫得不夠清楚的地方
B. 撰寫上改進的建議
C. 希望我能夠撰寫分享的區塊鏈技術知識內容

都非常歡迎在底下留言回覆。希望我的文章能幫助到更多像我一樣想學習區塊鏈技術與知識的朋友。如果您覺得讀完有所收穫，希望能

＊ 不吝嗇給我 50 claps
（如果您覺得按 50 下手很痠，這邊剛好有個好用的：小插件）
＊ 分享本文給您的朋友們

謝謝大家！

也歡迎大家來閱讀區塊鏈技術知識系列的其它篇文章：
https://medium.com/pelith/blockchain-technical-overview-8c2a643424fa

淺談預言機 Oracle：區塊鏈與現實世界的橋樑。<9> 文組也該知道的區塊鏈技術知識 was originally published in Pelith on Medium, where people are continuing the conversation by highlighting and responding to this story.

Blockchain Technical Overview <8> Transfer of ERC20 Token

收看本系列文章的讀者，應該都對於區塊鏈的基本原理和架構有些概念，如果沒有，推薦您先去 Google 搜尋 區塊鏈、比特幣、以太坊這些關鍵字了解一下。我們將在這些基礎概念之上，來談區塊鏈的技術知識。本系列文章並不會談到太深的技術鑽研，而是希望以深入淺出的方式讓每一個想要搞懂區塊鏈技術的人都能在讀完後說出：原來如此！

本系列文章由區塊鏈技術解決方案開發公司：Pelith 編撰。內容皆經過諸位區塊鏈資深研究員及開發者校對與驗證，盡可能確保內容正確無誤，讓讀者能安心吸收正確的區塊鏈技術知識。

為什麼發送 ERC20 Token 給別人需要兩次交易？

許多人可能對此感到疑問，透過本篇文章相信能充分為您解惑。上一節 我們帶大家一窺以太坊的架構全貌並為迄今為止七篇文章做了小結。我們將在這基礎之上闡明發送 ERC20 Token 背後的技術解析。

發送以太幣

發送以太幣時其實蠻符合我們的直覺，就是把錢發給別人，別人收到這樣。然而發送 ERC20 代幣卻彷彿不是這麼單純，為什麼呢？

ERC-20 代幣的本質

首先回顧一下 上一節 提到的，ERC20 代幣只是用 ERC20 之智慧合約底下的記憶體來儲存記錄各個地址持有數量的帳本。既然對象是個智慧合約，就要再回顧一下 第二節 提到的，個人帳戶（Externally Owned Account, EOA）與 合約帳戶（Contract Account）的不同，由於智慧合約沒有主觀意識，動作皆需要由 EOA 發交易來觸發。因此當合約地址收到 ETH 外的其它代幣時，它並不會知道。因為更動的是「另一個智慧合約底下的記憶體」！

我們實際來看一個範例：

假設我想要透過去中心化交易所 Uniswap 將我持有的 82 顆 cDAI 兌換成 0.0092 顆 ETH，在技術上是如何做到的呢？

先備知識：cDAI 是我將 DAI 存入 Compound 放貸後，Compound 發回給我的 ERC20 Token。所以 cDAI 是由 Compound 管理的 cDAI 智慧合約底下之記憶體（帳本）來記錄追蹤的。

我的 Token Swap 需求在常規邏輯上是：
我把我的 cDAI token 發送給 Uniswap，Uniswap 把 ETH 發送給我。

不過事情並非這麼單純。由於 Uniswap 是去中心化，由智慧合約來運作的。因此當 Uniswap 收到了 cDAI token 時，它不像人一樣可以點開 Metamask 去查看是否有收到，確認有收到後再把 ETH 發送給我，因此需要用特殊的做法來實現這樣的流程。

我們就直接開門見山講答案

用比喻來說明的話，做法是：

1. 我先到 銀行（ERC20 Token 的智慧合約）開啟 授權，
   允許 對方（第三方智慧合約）能夠到我的戶頭
   提取 錢（ERC20 Token），並設定「能夠提取的額度」。
2. 接著我開給對方一張「寫上金額的支票」，
   讓對方拿著支票到 銀行 中提領我帳戶中的 錢。

因為對象（智慧合約）是一段程式碼，如此做法方能 讓智慧合約確認提取到 Token 並執行後續的合約邏輯操作。

因此，回到區塊鏈的世界，必須透過以下兩個交易步驟來進行：

Tx1: Approve（授權）

我必須先發一筆交易到「Compound cDAI Token 智慧合約」（銀行），
授權「Uniswap 的 cDAI to ETH 交易對智慧合約」（對方）
可以到「Compound 的 cDAI Token 智慧合約」（銀行）
提取我的「cDAI Token」（錢）。

Tx2: Swap Token（兌換）

隨後，我再發送一筆「將 cDAI 兌換為 ETH」的交易（支票）
到「Uniswap 的 cDAI to ETH 交易對智慧合約」（對方）觸發，
讓「Uniswap 的 cDAI to ETH 交易對智慧合約」（對方）
至「Compound 的 cDAI Token 智慧合約」（銀行）
提領我的 82 顆「cDAI Token」（錢）。
「Uniswap 的 cDAI to ETH 交易對智慧合約」（對方）提領到 Token（錢）後再將 0.0092 顆 ETH 發送給我。

如下方示意圖所示：

接著我們帶大家實際走一次操作流程以搞懂背後技術邏輯。

Tx1: Approve（授權）

首先，當我們來到 Uniswap 交易所，選好 Input 與 Output 的加密貨幣種類並在 Input 輸入欲兌換的數量，便可以在我欲兌換成 ETH 的 cDAI Token 旁邊看到「Unlock」的按鈕。這就是要求我進行「Tx1：授權」的操作。

點選「Unlock」按鈕後，Metamask 便會跳出「批准」的交易來讓我簽署。一但簽署後，我便批准了 Uniswap 能夠到 Compound 提領我的 cDAI 的權限。

這筆交易被確認後，我們便可以憑 Txn Hash 到 Etherscan 上找到這筆交易。可以發現這筆交易是發給「Compound 的 cDAI ERC20 Token 智慧合約」。

點進去這筆交易後，便可以看到呼叫的正是 approve 的 function。我同意了「Uniswap 的 ETH-cDAI 交易對」合約地址能夠來提領我的 cDAI，而授權的提領金額量為「最大」。

可能會有些人好奇為什麼不把 amount 設成我要兌換的量：82 就好。原因是為了便利於未來提領操作時不用再次授權，通常呼叫智慧合約的 approve 函式時都會預設為開啟最大值，這樣未來再次需要提領時就不用再次進行 approve 的操作。

然而要注意的部分是：針對「可能存在漏洞或不被信任的智慧合約」，若是仍按照預設將權限開至最大值，則將面臨 Token 遭到竊取的風險。

在完成「Tx1：Approve 授權」後，便可以看到「Unlock」的按鈕消失，並且「Swap」按鈕已能夠點選。

Tx2： Swap Token

接著便能夠來進行將我的 cDAI 兌換成 ETH 的 Swap Token 動作。

同樣透過 Metamask 來簽署完成這筆交易後，我們到 Etherscan 上追縱這筆交易：能夠發現這筆交易是從我的錢包發送給「Uniswap 的 ETH-cDAI 交易對 智慧合約」。

點進去這筆交易後可以看到在這筆交易中執行了兩件事：

1. 將 82 cDAI 從「Compound 的 cDAI 智慧合約」轉至 「Uniswap 的 ETH-cDAI 交易對合約地址」中。
2. 將 0.0092 ETH 從「Uniswap 的 ETH-cDAI 交易對合約地址」中轉給我。

接著我們可以在「Uniswap 的 ETH-cDAI 交易對合約地址」的
「Internal Txns」中看到 0.0092 ETH 轉移至我的錢包地址；以及
在「Erc20 Token Txns」中看到 82 cDAI 從「Compound 的 cDAI 智慧合約」轉移至「Uniswap 的 ETH-cDAI 交易對合約地址」中。

同時，這筆交易在「Compound 的 cDAI 智慧合約」中也可以查看到 82 cDAI 被轉移出的記錄。

結論

1. 發送 ETH 與 發送 ERC20 Token 給智慧合約有本質上的差異。ETH 是 push-based，單純把 ETH 發過去就可以。ERC20 Token 的發送則是 pull-based，讓合約去主動提取 Token。
2. 必須先發送一筆交易至 ERC20 合約進行 授權（Approve），允許某合約地址能夠至 ERC20 智慧合約提取我持有的 ERC20 Token。
3. 再發送一筆交易來觸發合約地址進行 提取 ERC20 Token 與後續的邏輯操作。

至此，相信讀者都已充分理解發送 ERC20 Token 給智慧合約背後的技術邏輯。

下一節我們將來介紹「Oracle（預言機）」，這個扮演 真實世界與區塊鏈間橋樑 的技術，並帶大家認識 MakerDAO、Compound 等大專案的實作方式。敬請期待！

以上，若有任何

A. 我寫得不夠清楚的地方
B. 撰寫上改進的建議
C. 希望我能夠撰寫分享的區塊鏈技術知識內容

都非常歡迎在底下留言回覆。希望我的文章能幫助到更多像我一樣想學習區塊鏈技術與知識的朋友。如果您覺得讀完有所收穫，也希望能
＊不吝嗇給我 Like / 50 claps
＊分享給您的朋友們
謝謝大家！

文組也該知道的區塊鏈技術知識 <8> 為何發送 Token 需要兩次交易？ was originally published in Pelith on Medium, where people are continuing the conversation by highlighting and responding to this story.

Blockchain Technical Overview <7> Structure of Blockchain (Ethereum)

收看本系列文章的讀者，應該都對於區塊鏈的基本原理和架構有些概念，如果沒有，推薦您先去 Google 搜尋 區塊鏈、比特幣、以太坊這些關鍵字了解一下。我們將在這些基礎概念之上，來談區塊鏈的技術知識。本系列文章並不會談到太深的技術鑽研，而是希望以深入淺出的方式讓每一個想要搞懂區塊鏈技術的人都能在讀完後說出：原來如此！

本系列文章由區塊鏈技術解決方案開發公司：Pelith 編撰。內容皆經過諸位區塊鏈資深研究員及開發者校對與驗證，盡可能確保內容正確無誤，讓讀者能安心吸收正確的區塊鏈技術知識。

上一節 我們帶大家核心地認識了區塊鏈架構的全貌，相信大家都更加了解區塊鏈運作的機制和原理。本篇文章我們將接續上篇來介紹 區塊鏈 2.0 以太坊－ Vitalik 如何在中本聰設計的比特幣架構上進行升級與改動，透過首度揭曉的「以太坊區塊鏈架構圖」帶大家完整認識以太坊的運作原理！

區塊鏈 2.0－以太坊 Ethereum

本篇文章的內容會在前面幾章介紹過的概念之上接續進行介紹。若您未讀過前面幾章的內容可能會有些吸收不良，建議您先行閱覽再來閱讀本篇文章。
傳送門：《區塊鏈技術知識》目錄 （建議您依序從 第 1 節 閱讀至 第 6 節）

How Ethereum Blockchain Work

以太坊虛擬機（EVM — Ethereum Virtual Machine）

介紹以太坊區塊鏈架構前必須要介紹一下「EVM」 ，EVM 是以太坊為了讓人人都能成為節點而創造的計算引擎。由於每個節點的軟硬體環境可能都不一樣，為了確保每個節能都能進行一樣的運算，於是各個節點都 透過 EVM 來執行 Ethereum 交易的狀態轉移與智能合約，以確保每一個節點都有相同的執行環境。

前言完畢，緊接著我們便來一探究竟：

以太坊交易的一生

有別於比特幣的 UTXO，以太坊是採用 Account 的架構。
由於以太坊多了智慧合約的設定，將會分成 A. B. C 三個 part 來做說明，
我們先從最單純的 Ether 轉帳交易開始看起：

A. 單純的 Ether 轉帳交易

1. 一個使用者（EOA）欲發起一筆交易。
2. 透過錢包（管理私鑰的工具）輸入交易資訊
   To: 對方接收地址；
   Amount: 欲轉移的 Ether 數量；
   Gas Price: 單位 Gas 給的手續費；（參閱 第 5 節）
   Gas Limit: 普通的 Ether 轉移交易都是 21,000 Gas，不用動；
   Input Data: 視是否要在交易中留下文字訊息。
3. 以私鑰簽署交易。
4. 廣播「加上簽名的交易封包」至鄰近的以太坊節點們。
5. 節點接收到新交易時，會先至 State Database 檢查交易發起地址是否具有足額 Ether（Balance）可做轉移，若無則該交易會即刻被丟棄。
6. 若檢查後確認有足額，則該交易會被放入到 Tx Pool 中。
   （按照 Gas Price 設的多寡由高至低排序）
7. 等待出塊的同時，各節點會
   A. 廣播接收到的交易
   B. 接收未在 Tx Pool 內的交易
8. 礦工節點們（有在用電腦算力找 nonce 值，拼出塊獎勵的節點）會撈取手續費較高的交易們，進到 EVM 運算並更改狀態值後，將已完成運算的交易們來打包成新區塊（運算中出現錯誤的交易會被丟棄），隨後用電腦算力來計算 nonce 值。
   ＊註：這邊的 nonce 值 跟前面介紹過的 以太坊地址的 nonce 值 不同（以太坊有兩個 nonce：一個是挖礦的；一個是地址的交易序次。）
   ＊註 2：運算的同時便會消耗 Gas。
9. 成功找到 nonce 值，出塊的礦工會獲得出塊獎勵及該區塊所有打包交易給的手續費。
10. 該礦工節點將新的區塊廣播至全世界的其他節點們。
11. 其他節點同步 <8660586 區塊高度（最新的區塊）>、
    <State Database>、<Tx Pool> 資料，繼續廣播與接收新交易。
12. 礦工節點再從 Tx Pool 中撈取未出塊的交易們運算並打包成新的區塊。

以上，便是一筆以太坊交易從發送到出塊會經歷的流程。緊接著我們來一探究竟智慧合約是如何部署的：

B. 部署智慧合約

我們在 第 2 節 其實有概略性的介紹過一次，此刻我們搭配示意圖更完整地來介紹一遍吧！

1. 以 Remix 或其它開發工具撰寫完成智慧合約。
2. 將原始碼編譯為 Bytecode。
3. 使用者（EOA）透過錢包（管理私鑰的工具）輸入交易資訊
   To: 0x0
   Amount: 視是否要將 Ether 打入合約中
   Gas Limit: 按照合約繁複程度決定要設多少
   Gas Price: 視交易狀況及欲出塊的時間急迫性
   Input Data: 放入合約 Bytecode
4. 以私鑰簽署交易，廣播「加上簽名的交易封包」至鄰近的以太坊節點們。
5. 節點接收到新交易時，一樣會先至 State Database 檢查交易發起地址是否具有足額 Ether（Balance）可做轉移（有些情況會把 Ether 打入合約） ，若無足額則該交易會即刻被丟棄。
6. 若檢查後確認有足額，則該交易會被放入到 Tx Pool 中。
   （按照 Gas Price 設的多寡由高至低排序）
7. 等待出塊的同時，各節點依舊會
   A. 廣播接收到的交易
   B. 接收未在 Tx Pool 內的交易
8. 礦工節點們撈取起本筆合約部署交易，進到 EVM 運算。
9. 將合約程式碼部署至 Program Code ROM，是個部署後便不能進行更動的 Read-Only Memory（唯獨記憶體）。
10. 同時，智慧合約亦可以另外使用記憶體（Memory）來儲存合約所需要紀錄的資訊。例如：一個發行 ERC-20 Token 的智慧合約，便可以使用記憶體來 紀錄各個以太坊地址所「持有 Token 數量」，追蹤各個地址的 ERC-20 Token Balance。
11. 上方步驟完成後，便會將運算後的結果（合約地址、Gas Used）寫回到該筆交易中。
12. 礦工節點們將運算完的交易們 打包成新區塊（運算中出現錯誤 或 Gas 給不夠 的交易會被丟棄），隨後用電腦算力來計算 nonce 值。
13. 成功找到 nonce 值，出塊的礦工會獲得出塊獎勵及該區塊所有打包交易給的手續費。
14. 該礦工節點將新的區塊廣播至全世界的其他節點們。
15. 其他節點同步 <8660586 區塊高度（最新的區塊）>、
    <State Database>、<Tx Pool>、<Contract Code ROM>、
    <ERC-20 Token Balance> 資料，繼續廣播與接收新交易。
16. 礦工節點再從 Tx Pool 中撈取未出塊的交易們運算並打包成新的區塊。

以上，便是一筆智慧合約部署的交易從發送到出塊會經歷的流程。
最後，我們來解析呼叫智慧合約進行操作與互動：

C. 呼叫合約進行互動

這部分我們在 第 2 節 與 第 4 節 其實也有概略性的介紹過，
此刻我們搭配示意圖，更著重在節點的部分，較完整地來介紹一遍吧！

1. 透過 DApp 介面或其它方式來呼叫智慧合約進行互動
2. 生成以下形式的交易格式：
   To: 合約地址
   Amount: 視是否要將 Ether 打入合約中
   Gas Limit: 按操作合約的繁複程度決定要設多少
   Gas Price: 視交易狀況及欲出塊的時間急迫性
   Input Data: 放入以 hex 型態表示 的「要呼叫的合約 function 與 參數」
3. 以私鑰簽署交易，廣播「加上簽名的交易封包」至鄰近的以太坊節點們。
4. 節點接收到新交易時，一樣會先至 State Database 檢查交易發起地址是否具有足額 Ether（Balance）可做轉移（如牽涉到） ，若無足額則該交易會即刻被丟棄。
5. 若檢查後確認有足額，則該交易會被放入到 Tx Pool 中。
   （按照 Gas Price 給的多寡由高至低排序）
6. 等待出塊的同時，各節點依舊會
   A. 廣播接收到的交易
   B. 接收未在 Tx Pool 內的交易
7. 礦工節點們撈取起本筆「合約操作交易」，進到 EVM 運算。
8. 根據合約地址撈出 Program Code ROM 中的合約程式碼。
9. 依照 MethodID (Function Hash) 找到合約中對應的 Function。
10. 將相關參數填入進行對應運算。
    以 ERC-20 Token 的 Transfer Function 為例，運算時便會更改相關地址的 ERC-20 Token Balance。
11. 上方步驟完成後，便會將運算後的結果（新的 Token Balance、Gas Used）寫回到該筆交易中。
12. 礦工節點們將運算完的交易們 打包成新區塊（運算中出現錯誤 或 Gas 給不夠 的交易會被丟棄），隨後用電腦算力來計算 nonce 值。
13. 成功找到 nonce 值，出塊的礦工會獲得出塊獎勵及該區塊所有打包交易給的手續費。
14. 該礦工節點將新的區塊廣播至全世界的其他節點們。
15. 其他節點同步 <8660586 區塊高度（最新的區塊）>、
    <State Database>、<Tx Pool>、<ERC-20 Token Balance> 等資料，繼續廣播與接收新交易。
16. 礦工節點再從 Tx Pool 中撈取未出塊的交易們運算並打包成新的區塊。

至此，我們便核心地介紹完了以太坊區塊鏈的架構。儘管有許多的技術細節我們此時並未完整交代也未深入著墨，但相信對於初學區塊鏈技術讀者來說應該能逐步建立起區塊鏈架構的全貌。未來我們將持續在這基礎上解析更多面向的區塊鏈技術知識，謝謝大家！

下一節，我們將來介紹「為什麼發送 ERC20 Token 需要兩次交易」這個困擾許多人的疑問，在本篇文章中會充分為您解惑，我們將闡明發送 ERC20 Token 背後的技術解析。

傳送門：文組也該知道的區塊鏈技術知識 <8> 為何發送 ERC20 Token 需要兩次交易？

以上，若有任何

A. 我寫得不夠清楚的地方
B. 撰寫上改進的建議
C. 希望我能夠撰寫分享的區塊鏈技術知識內容

都非常歡迎在底下留言回覆。希望我的文章能幫助到更多像我一樣想學習區塊鏈技術與知識的朋友。如果您覺得讀完有所收穫，也希望能
＊不吝嗇給我 Like / 50 claps
＊分享給您的朋友們
謝謝大家！

文組也該知道的區塊鏈技術知識 <7> 以太坊區塊鏈架構 was originally published in Pelith on Medium, where people are continuing the conversation by highlighting and responding to this story.

文組也該知道的區塊鏈技術知識

Presented by Pelith Inc.

區塊鏈的學習

目前的區塊鏈中文學習資源有點呈現雙峰分佈，找得到大量的入門教學跟一些很深入的文章，但中間存在一大段的鴻溝。所以我們決定開始開始寫一些「有點深入又不太難」的主題，希望藉由此來幫助到大家，讓讀者更深入認識區塊鏈相關的技術知識！

區塊鏈的學習比較不像學習任何傳統知識，可以編撰成一本厚厚的書，人們能按圖索驥循序漸進地了解全貌。由於許多環節都仍在發展中或快速變化的階段，一種不錯的學習方式可以是用點來拼出面。這也是本系列文章撰寫的方向，讓讀者每次學習一個部分的知識，經過本系列文章的逐漸累積應漸能拼湊出區塊鏈技術架構的樣貌。

前言

收看本系列文章的讀者，應該都對於區塊鏈的基本原理和架構有些概念，如果沒有，推薦您先去 Google 搜尋 區塊鏈、比特幣、以太坊 這些關鍵字了解一下。我們將在這些基礎概念之上，來談區塊鏈的技術知識。

本系列文章並不會談到太深的技術鑽研，而是希望以深入淺出的方式讓每一個想要搞懂區塊鏈技術的人都能在讀完後說出：原來如此！

本系列文章由區塊鏈技術解決方案開發公司：Pelith 編撰。內容皆經過諸位區塊鏈資深研究員及開發者校對與驗證，盡可能確保內容正確無誤，讓讀者能安心吸收正確的區塊鏈技術知識。

目錄

註：標題即為連結

<1> 從一筆交易來看ETH與BTC之異同

要了解 ETH or BTC 是如何運作，從一筆交易來切入是很好的著力點，因為幾乎所有的概念與原理都是圍繞著交易來發生的。本篇文章將從一筆普通的 ETH 交易與一筆 BTC 交易來檢視架構上的異同，藉以了解各自之運作原理。

<2> 一次搞懂以太坊智慧合約如何運作

本篇文章我們要來介紹 以太坊智慧合約。不會談到實作部分，而是希望能從實際應用場景切入來說明，讓閱讀完本文的讀者都能充分理解智慧合約的技術運作原理。

<3> 從染色幣到無頭合約的代幣演進史 《上篇》

第三節我們將來回顧區塊鏈「代幣」演進的歷史，並解析與之相關的技術。在《上篇》中我們會談到從比特幣 USDT 到以太坊 ERC-20 Token 的自定義代幣技術發展史。

<4> 從染色幣到無頭合約的代幣演進史 《下篇》

《下篇》將更著重在以太坊自定義代幣技術面的介紹，並展望到以太坊 2.0 Phase 1 相關的技術解析。

<5> 不可不知的以太坊交易打包規則

「奇怪，我的交易怎麼一直送不出去？」 相信大家或多或少都曾遇到或被問過這樣的問題。本篇我們要帶大家細看以太坊交易背後的知識與原理。

<6> 一次搞懂「區塊鏈架構」Structure of Blockchain (Bitcoin)

本篇我們將核心地介紹 中本聰設計的初代區塊鏈 比特幣 Bitcoin。藉由首創的「比特幣區塊鏈架構概念圖」讓讀者完整地建立區塊鏈技術的完整架構。

<7> 以太坊區塊鏈架構 How Ethereum Blockchain Work

我們將接續 第 6 篇，介紹 區塊鏈 2.0－ Vitalik 如何在中本聰設計的比特幣架構上進行升級與改動，同時也將首度揭曉「以太坊區塊鏈架構圖」！

<8> 為何發送 ERC20 Token 需要兩次交易？

Transfer of ERC20 Token
這個困擾許多人的疑問將在本篇文章中充分為您解惑，我們將闡明發送 ERC20 Token 背後的技術解析。

<9> 區塊鏈與現實世界間的橋樑：Oracle（預言機）

以太坊智慧合約的出現為區塊鏈的應用層面增添了非常多的可能性。然而發展至今隨著 DeFi 熱潮出現了 區塊鏈當前面臨到最大的問題：如何將現實世界的事實（如：球賽結果、天氣、航班）餵入區塊鏈上，並依結果觸發程式碼來執行後續程式邏輯。

本篇文章我們將帶大家認識幾個指標性的 Oracle 實作方式，並評析何謂好的 Oracle 機制。

<10> 全節點與輕節點：以太坊節點面面觀

在本系列過往的文章中我們逐一介紹了以太坊各個環節的運作機制，相信有在持續關注的讀者都已對以太坊技術架構有粗略的認識。

因應以太坊 2.0 的即將來臨，本篇文章將針對以太坊節點（Ethereum Nodes）做概論性的介紹，讓讀者能充分瞭解節點的運作機制。

To Be Continued…

以上，若有任何

A. 我寫得不夠清楚的地方
B. 撰寫上改進的建議
C. 希望我能夠撰寫分享的區塊鏈技術知識內容

都非常歡迎在底下留言回覆。希望我的文章能幫助到更多像我一樣想學習區塊鏈技術與知識的朋友。如果您覺得讀完有所收穫，也希望能
＊不吝嗇給我 Like / 50 claps
＊分享給您的朋友們
謝謝大家！

《區塊鏈技術知識》目錄 was originally published in Pelith on Medium, where people are continuing the conversation by highlighting and responding to this story.

收看本系列文章的讀者，應該都對於區塊鏈的基本原理和架構有些概念，如果沒有，推薦您先去 Google 搜尋 區塊鏈、比特幣、以太坊這些關鍵字了解一下。我們將在這些基礎概念之上，來談區塊鏈的技術知識。本系列文章並不會談到太深的技術鑽研，而是希望以深入淺出的方式讓每一個想要搞懂區塊鏈技術的人都能在讀完後說出：原來如此！

本系列文章由區塊鏈技術解決方案開發公司：Pelith 編撰。內容皆經過諸位區塊鏈資深研究員及開發者校對與驗證，盡可能確保內容正確無誤，讓讀者能安心吸收正確的區塊鏈技術知識。

上一節 中，我們在介紹以太坊交易打包規則時帶大家大致了解區塊鏈運作的架構，不過有些技術細節我們沒有完整地交代清楚，本篇及未來數篇文我們將更深入且完整地介紹區塊鏈技術架構，並且帶大家認識目前區塊鏈遇到的各種問題及許多專案在嘗試解決的部分！

廢話不多說，我們先從中本聰設計的初代區塊鏈 比特幣 Bitcoin 來談起：

How Bitcoin Blockchain Work

如果前面幾節大家有認真看的話，應該還記得比特幣是採用 UTXO 架構。
我們從比特幣一筆交易的一生帶大家來一探究竟區塊鏈是如何運作的：

比特幣交易的一生

1. 一個使用者欲發起一筆交易。
2. 透過錢包（管理私鑰的工具）輸入交易資訊
   （To, Amount, 手續費, OP_Return …）。
3. 以私鑰簽署交易。
4. 廣播「加上簽名的交易封包」至鄰近的比特幣節點們。
5. 節點接收到新交易時，會先至 UTXO Pool 檢查交易發起地址是否能動用足額 UTXO，若無則該交易會即刻被丟棄。
   ＊註：圖中以一個 Balance 值來做標註，但其實這個 Balance 可能是多個 UTXO 的集合，Steve 的 18 可能其實是 0.25+10.75+2+5 四個 錢堆。
6. 若檢查後確認有足額，則該交易會被放入到 Tx Pool 中。
   （按照手續費給的多寡由高至低排序）
7. 等待出塊的同時，各節點會
   A. 廣播接收到的交易
   B. 接收未在 Tx Pool 內的交易
8. 礦工節點們（有在用電腦算力找 nonce 值，拼出塊獎勵的節點）會
   撈取手續費較高的交易們來運算並打包成新區塊，
   用電腦算力計算 nonce 值。
   ＊註：這邊的 nonce 值 跟前面介紹過的 以太坊地址的 nonce 值 不同（以太坊有兩個 nonce：一個是挖礦的；一個是地址的交易序次。）
9. 成功找到找到 nonce 值，出塊的礦工會獲得出塊獎勵及該區塊所有打包交易給的手續費。
10. 該礦工節點將新的區塊廣播至全世界的其他節點們。
11. 其他節點同步 <595266 區塊高度（最新的區塊）>、<UTXO Pool>、<Tx Pool> 資料，繼續廣播與接收新交易。
12. 礦工節點再從 Tx Pool 中撈取未出塊的交易們（生成 Merkle Root ）運算並打包成新的區塊。

以上，便是區塊鏈運作的方式。

不過由於全世界可能每時每刻都有人在發起新的交易，所以以上這些過程都是 24/7/365.25 不斷在 動態運作中 的。

光憑上述 12 點其實很難清楚交代許多的技術細節，所以我們將針對幾點再做更進一步的介紹：

(3) 私鑰簽署數位簽名 Digital Signature

為什麼發送交易需要使用私鑰進行簽名？

試想一下，若是沒有這樣的機制，就無法知道交易是不是由地址的主人發出的。因此當我發送交易時，必須有機制能證明這個交易是由我本人來發出。我們先來看一段《精通比特幣》的論述：

《 精通比特幣（Mastering Bitcoin）第四章 》
私鑰可用於為交易生成指紋（數位簽名）。這個簽名只能由知道私鑰的人制作。但是，任何有權訪問公鑰和交易指紋的人都可以使用它們來驗證簽名確實是私鑰的擁有者生成的。非對稱加密的這一有用特性使任何人都可以驗證每筆交易的每個簽名，同時確保只有私鑰所有者才能生成有效的簽名。

因此，能唯一證明的機制便是：用我的私鑰生成一個「數位簽名」後，連同交易內容一起送出。節點接收到這筆加上簽名的交易時，可以用我的公鑰來驗證這個簽名是由我的私鑰所簽署的。如此來證明這個交易是由我送出的。

(5) UTXO Pool

接著，我們來介紹 UTXO Pool：所謂的區塊鏈其實就是自主網上線以來的所有歷史區塊，區塊內包含零至數筆的交易資料。而比特幣至 2019/9 為止的近 60 萬個區塊 資料大小約為 250 GB。

上方第 (5) 點，節點接收交易要檢查時，照理來說應該是要把近 60 萬個區塊資料都爬過一遍才能確認該地址可動用的餘額。然而，這麼做曠日費時，當區塊越來越多，且每一筆交易接收時都要整個掃描一遍時，會因掃描時間過長導致節點之間的同步出現問題。

因此，UTXO Pool 便出現了。作法是：用資料庫記錄一個掃描過後的最終狀態，並在這之上再依據後續區塊做更新變動。亦即把已花費的 Output 紀錄都丟棄掉，只保留最後 Unspent 的 Tx Output。如此便不用每筆交易接收時都要掃描整條區塊鏈，只要掃描去蕪存菁的 UTXO Pool 就可以了。

(10) 節點 Node

了解 UTXO Pool 後，接著來進一步介紹節點。節點是維持區塊鏈網路運作的根基，區塊鏈之所以能做到去中心化，便是因為在全世界有無數的節點在同步與備份所有的區塊資料（全交易歷史紀錄）。

(11) 節點同步（不斷刷新推算）

當我接收到一筆新的交易並驗證後，放進我的 Tx Pool 中，我會同時把這筆交易廣播給鄰近的節點們。鄰近的節點們驗證、接收並同步後也會再廣播給他們鄰近的節點們，如此將資訊以網狀廣播出去，讓各個節點之間維持一個「動態同步」的狀態。

(12) 節點不一定等於礦工

節點可以選擇要不要進行挖礦，也就是說：我可以單純的接收、同步與廣播「Block、UTXO Pool、Tx Pool」資料，只做帳本更新動作，當個稱職的傳聲筒為去中心化世界做貢獻，不花算力去打包交易、計算 nonce 拼出塊獎勵。

而這些節點們便是所謂的 Peer to Peer（P2P）Network 「點對點網路」。

以上便是核心版的區塊鏈架構，中間有許多的技術細節我們先不深入著墨。因為這是一個由淺入深的系列文，未來會逐一介紹到的！

Blockchain Demo

最後，如果想更了解區塊鏈如何運作的朋友，可以到下方這個網站去逛逛，實際體驗、操作看看區塊鏈是如何運作的！

Blockchain Demo

（https://anders.com/blockchain/）

此外，也跟大家預告一下精彩可期的未來數篇文章：

<7> 以太坊區塊鏈架構 How Ethereum Blockchain Work

（標題即為文章連結）
我們將接續本篇文章，介紹 區塊鏈 2.0－ Vitalik 如何在中本聰設計的比特幣架構上進行升級與改動，同時也將首度揭曉「以太坊區塊鏈架構圖」！

<8> 區塊鏈技術地圖 Blockchain Technical Roadmap

比特幣資深研究員「陳伯韋」五年多來的研究結晶完全公開！
我們將依區塊鏈架構清楚剖析目前區塊鏈遇到的各項問題（隱私問題、儲存問題、速度問題 等），並摘要介紹目前各個 項目／團隊 針對各項問題提出的解決方案！

<9> 去中心化金融技術解析 How Decentralized Finance (DeFi) Work

DeFi 正夯，到底在紅什麼呢？DeFi 如何解決傳統金融遇到的界線與問題呢？透過本篇文章將（盡可能）解答您心中的疑問！

以上，若有任何

A. 我寫得不夠清楚的地方
B. 撰寫上改進的建議
C. 希望我能夠撰寫分享的區塊鏈技術知識內容

都非常歡迎在底下留言回覆。希望我的文章能幫助到更多像我一樣想學習區塊鏈技術與知識的朋友。如果您覺得讀完有所收穫，也希望能
＊不吝嗇給我 Like / 50 claps
＊分享給您的朋友們
謝謝大家！

文組也該知道的區塊鏈技術知識 <6> 一次搞懂「區塊鏈架構」 was originally published in Pelith on Medium, where people are continuing the conversation by highlighting and responding to this story.

收看本系列文章的讀者，應該都對於區塊鏈的基本原理和架構有些概念，如果沒有，推薦您先去 Google 搜尋 區塊鏈、比特幣、以太坊這些關鍵字了解一下。我們將在這些基礎概念之上，來談區塊鏈的技術知識。本系列文章並不會談到太深的技術鑽研，而是希望以深入淺出的方式讓每一個想要搞懂區塊鏈技術的人都能在讀完後說出：原來如此！

奇怪，我的交易怎麼一直送不出去？

相信大家或多或少都曾遇到或被問過這樣的問題。在 第 3 篇 與 第 4 篇 文章中我們藉由區塊鏈代幣的演進史來解析 Token 背後的技術運作原理，大家對於智慧合約應該有更深一層的認識與了解。本篇我們要來帶大家細看以太坊交易背後的知識與原理：

＊究竟在我們送出交易後到出塊上鏈之間發生了哪些事？
＊為什麼以太坊會塞車？
＊交易塞車在技術上到底是發生了什麼事？
＊交易送不出去要怎麼辦？

以上這些常見的問題應該都能在本篇文章中得到解答。

以太坊交易的本質

首先，大家應該都還記得在 第一篇 中談到了以太坊交易的本質，我給你 10 Ether 不是我真的把什麼東西給了你，而是我向以太坊網絡提出了更改餘額狀態的請求，讓各個節點上紀錄的 你與我的 Ether Balance 進行更新。

然而，送出交易在技術上並不困難，區塊鏈的重點是在於打包交易並出塊的過程。如何驗證、確認交易是否有效，讓這筆交易順利發生，並讓各個節點即時更新以擁有相同的帳本，這樣打包交易並出塊的機制即「挖礦」。

以太坊交易送出至出塊的流程

透過上圖我們可以一覽

以太坊上一筆交易送出後經歷的流程：

1. 發送交易
2. 私鑰簽名
3. 交易發送至節點
4. 節點間廣播新接收交易
5. 礦工打包交易並出塊

上圖可能有些細節交代不夠清楚，我們再用下面這張圖來補充說明：

交易送出之後，會被丟進一個「交易池」裡，等待被礦工打包。
礦工從「交易池」中撈出未出塊的交易來進行打包與出塊。

因為每個區塊有大小限制，比特幣一個區塊是 1MB 的容量限制；以太坊的區塊則是以 Gas 來計算，有 800 萬 Gas 的限制。若以一筆基礎交易 21,000 Gas 來計算，一個以太坊區塊可以容納 380 筆交易。因此當「交易池」裡的交易量大時，會有許多交易沒辦法即時被打包而滯留在池子中等待。

如何挑選要撈出哪些交易？

礦工節點可以自行設置參數，不過大多數礦工都是按造手續費的多寡排序，手續費高的會優先被打包出塊；手續費低的則可能要等到天荒地老。

回顧 第一節 我們介紹過的以太坊手續費計算公式：

以太坊交易手續費公式：
Tx Fee（手續費）＝ Gas Used（燃料用量） * Gas Price（單位燃料價格）

由於 Gas Used 是由系統決定的，我們在發送交易時決定手續費多寡的決定性變因就是 Gas Price 了。下方我們以 Metamask 介面來做介紹：

在上圖左方我們可以看到系統預設有三個速度可以供選擇，不過要更近一步設定，可以點「進階選項」，便會進到上圖右方的畫面。

我們可以自行設定 Gas Price 及 調整交易的 Gas Limit。WEI 是以太坊上最小的單位（10^-18 Ether）；GWEI（10^-9 Ether）則是 1G 的 WEI。
圖中的 Gas Price 設定為 10 GWEI；Gas Limit 為 21,000。因此：

10 GWEI（單位燃料價格）* 21,000（燃料用量）= 0.00021 Ether（手續費）

Gas Limit

若是要操作智慧合約等較繁複的功能，不太確定實際的 Gas Used，也可以把 Gas Limit 調高一些，被打包時只會收取實際 Gas Used 作為手續費，多給的 Gas 會退返回來。

不過由於以太坊區塊有 800 萬 Gas 的大小限制，若把 Gas Limit 設太高，也可能產生塞不進區塊中而滯留在「交易池」裡的情況。

GWEI

至於要設多少 GWEI，我們可以到 ETH gas station 上查看即時的「交易池」狀況：

可以看到如果希望交易能盡快被確認，GWEI 可能要設到 20 以上，大約在 2 分鐘內可以被確認完成（不過通常設到 FAST，應該 15~30 秒就會被確認了）。截圖當下其實是偏塞車的情形，通常 10 GWEI 左右就可以達到 FAST（<2 mins），截圖當下卻要 20 GWEI。

這邊顯示的 Gas Price 建議，其實就是「交易池」裡的狀況：池裡有多少筆 pending 的交易、這些池裡的交易給的手續費是多少。根據這些資訊依據來呈現設的 Gas Price 估計要多少個區塊（時間）後才會被打包上鏈。

然而，許多人常遇到關於交易的問題：

我的交易怎麼一直送不出去怎麼辦？

也許是 Gas Price 設太低，或是突然有大量交易湧入等各樣的情況。這時其實有補救的方法：

加速交易

當交易由 Metamask 送出後，可以看到下方會有個「加速」的按鈕，點進去後便可以再次設定 Gas Price，設定並重新送出交易後，就可以在底下的活動紀錄看到手續費被提高了。

取消交易

除了能加速交易，其實也可以取消交易。方法便是點擊等待處理的交易，展開後可以看到「取消」的按鈕，點擊並確認後 Metamask 會向節點發送取消交易的請求，並在確認取消後收取手續費。

若發現取消交易的請求 pending 有點久，其實在下方可以看到有「加速取消」的按鈕，可以再進行進一步設定。

那麼，以上這些過程其實是發生了什麼事，技術上如何做到的呢？
答案跟我們在 第一節 談到的 nonce 有關，做法是：

再發送一個同樣 nonce 的交易

由於以太坊 nonce 的設計，會追蹤每個地址所有交易的「序次」，也就是說每個 nonce 只會有一筆交易。

加速交易

因此加速交易便是我再發送一筆同個 nonce、同樣內容的交易。因為提高了交易手續費，所以當同樣 nonce 的兩個交易都位於「交易池」中，後發的手續費較高的交易原則上會被優先打包出塊。因為每個 nonce 只能有一筆交易，先發的那筆手續費較低的交易永遠不會被打包，於是便會被系統給丟棄，因而交易失敗。

取消交易

取消交易其實也是類似的邏輯，做法是：
我再發送一筆給自己 0 Ether 的同 nonce 交易。
由於這筆交易手續費較高，會優先被打包出塊，讓原交易被系統丟棄而交易失敗，如此來達到取消交易的目的。

結論

1. 交易送出後會被丟到一個「交易池」中等待被礦工打包，決定先後順序的主要因子為「單位 Gas Price（GWEI）」給的多寡。
2. 發送交易時可以到 ETH gas station 參考即時的「交易池」狀況再來決定要設多少 GWEI 以能在預期的時間內被打包上鏈。
3. 若發現交易持續滯留在「交易池」中等待被處理，可以「加速交易」或「取消交易」。

介紹至此，大家應該都對以太坊交易的背後邏輯與打包規則有更深一層的認識了。下一節 我們將更完整且完整地介紹區塊鏈架構，帶各位讀者一同檢視中本聰設計的初代區塊鏈：比特幣 Bitcoin 是如何運作的。

傳送門：文組也該知道的區塊鏈技術知識 <6> 一次搞懂「區塊鏈架構」

以上，若有任何

A. 我寫得不夠清楚的地方
B. 撰寫上改進的建議
C. 希望我能夠撰寫分享的區塊鏈技術知識內容

都非常歡迎在底下留言回覆。希望我的文章能幫助到更多像我一樣想學習區塊鏈技術與知識的朋友。如果您覺得讀完有所收穫，也希望能
＊不吝嗇給我 Like / 50 claps
＊分享給您的朋友們
謝謝大家！

文組也該知道的區塊鏈技術知識 <5> 不可不知的以太坊交易打包規則 was originally published in Pelith on Medium, where people are continuing the conversation by highlighting and responding to this story.

Blockchain Technical Overview <4> The History of Token ( Part 2 )

收看本系列文章的讀者，應該都對於區塊鏈的基本原理和架構有些概念，如果沒有，推薦您先去 Google 搜尋 區塊鏈、比特幣、以太坊這些關鍵字了解一下。我們將在這些基礎概念之上，來談區塊鏈的技術知識。本系列文章並不會談到太深的技術鑽研，而是希望以深入淺出的方式讓每一個想要搞懂區塊鏈技術的人都能在讀完後說出：原來如此！

在《上篇》中我們談到從比特幣開始到以太坊 ERC-20 Token 出現的自定義代幣發展史。《下篇》將更著重在以太坊自定義代幣技術面的介紹，並展望到以太坊 2.0 Phase 1 相關的技術解析。

代幣轉移的成本

大家在第 1 節中應該都了解到區塊鏈加密貨幣交易必須支付手續費給礦工，那麼既然「自定義代幣」要透過區塊鏈來進行傳輸，當我要發送代幣給別人，支付手續費給礦工也是很合乎邏輯的。

接著要解釋的部分會用到許多第 2 節的概念，如果您還沒讀過，建議您先去閱讀，否則可能會有些難消化。

假設我（A）要把 10 個 Pelith Token（自定義代幣）轉給 B，其實是發生了什麼事呢？我簡單做了一張示意圖來說明。
（只做概念闡釋，省略了很多可以很複雜的中間細節）

首先要知道，在區塊鏈上發行代幣不是真的發行硬幣或發行鈔票，而是建立了一個「類 Excel 帳本」來紀錄誰擁有多少代幣。當我們進行代幣轉移時，只是更改這個帳本上格子裡的數字。

因此，當我透過智慧合約創造了 Pelith Token 時，建立了一個類似 Excel 的表格來追蹤所有 Pelith Token 持有者的持有數量，並且這些資料會以某種形式儲存備份在每一個節點中（對，就是在全節點那 200 G 左右裡）。

當我要把 10 個 Pelith Token 轉給 B 時，我必須發送一筆接收對象為合約地址的交易，礦工看到便知道我是要對智慧合約進行操作，不是一般發送 Ether 給別人的交易。並且在 Input Data 中呼叫我要操作動作的 function，輸入相對應的參數，大概會長類似下面這樣：

我要call的function格式：
function transfer(address to, uint256 value)
[從我的地址傳送 uint256 value 數量的代幣到 address to 錢包地址]

填入參數：
transfer(0xB⋯⋯, 10)
→ transfer(0xB⋯⋯, 10000000000000000000)

註：第三個參數 uint256_value 是 10 個 Pelith Token，不過因為在以太坊上沒有小數點，所以進入運算時要以 wei (10^-18，以太坊最小的單位)來進行，因此在10後面要補上18個0。

然後轉換成下面這個樣子：
0xa9059cbb000000000000000000000000B000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000003b9aca00

再放入 Input Data 中。

＊(0xB⋯⋯, 10) 這一串 function 中的參數 稱為 “Payload”（裝載的貨物）

這些 Bytecode 被礦工驗證執行後，更新了「帳本內」對應地址的 Balance，隨後連同其它交易一起打包入新的區塊中。最先找到 Nonce 獲得出塊權利的礦工廣播給其它節點，直到各節點同步完成，並確認區塊在最長區塊鏈中，便正式驗證我（A）把 10 個 Pelith Token 轉給 B 了。

而以上這些動作，其實跟交易一樣須繳些許的 Ether 手續費給礦工。當你的 ERC-20 Token 要轉移給一個新的地址持有時（假設 B 過去未曾持有過 Pelith Token），我們在「帳本中」便必須要多開一個格子來記錄並追蹤這個地址的 Balance。

要「多開一個格子」的價格是 20,000 gas ；「更改一個現有格子內的數字」的價格是 5,000 gas，在這筆交易中一共更改了 A、B 兩格，故是 10,000 gas。再加上交易的基本手續費 21,000 gas。我執行了將 10 Pelith Token 轉給 B 的動作，總共花費了 51,000 gas。

執行操作的 Gas 總花費計算：
20,000 gas ＋ 5,000*2 gas ＋ 21,000 gas ＝ 51,000 gas

手續費（Eth）＝ Gas Used * Gas Price
51,000 gas * 10 Gwei(fast) = 510,000 Gwei = 0.00051 ETH = 0.1 USD
（以 1 Ether = 200 USD 計算）
大約 3 塊台幣，便是更改一個格子大約需付出的手續費。

（如果你看不懂上面灰色框框在幹嘛，那麼你可以在 第1節 中找到資訊）

至此，我們知道了轉移 Token 須付出的手續費。如果轉移的量很大，其實金額也是有一定量的。並且，若你的 Token Transfer 交易無效，被彈掉時（例如你只有 10 個 Token 卻發了 20 個給別人），由於必須到礦工要改格子時才會觸發 error，但礦工已執行了這筆交易到觸發 error 為止的運算。故雖然交易失敗，手續費還是要付。

以太坊 2.0 與無頭合約

最近隨著以太坊 2.0 有越來越多的消息釋出，出現了一個新名詞：「無頭合約」。原本在智慧合約，當我們從 Input Data 呼叫合約中的 function 後，合約中的程式碼便會執行邏輯運算去更新「帳本」內的 Balance。然而以太坊 2.0 的 Phase 1 並沒有 EVM，無法執行合約中的邏輯部分。因此發佈的合約中的 function 會長下面這個樣子：

function transfer(address to, uint256 value) {
  }

原本 1.0 的合約 function 是長這個樣子：

function transfer(address to, uint256 value) public returns (bool) {
        _transfer(msg.sender, to, value);
        return true;
    }

這是什麼意思呢？就是當我們在 Input Data 中呼叫了合約中的 function，但 function 並不會真的去更新帳本上格子裡的 balance。因此這個合約只是個空殼，雖然看起來有東西，但實際上卻不會執行動作。

因此當我們發送 to 合約的交易，在 Input Data 中輸入了：

transfer(0xB⋯⋯, 10)

合約並不會真的更新帳本（因為根本沒有帳本的存在），也不會同步到其它的節點中。因此這些 Input Data 輸入的內容只是被當作一般的備註文字訊息被寫在 to 合約的交易中。於是呢，又回到了比特幣 Omni Layer 的做法，我必須要去爬這些所有的「便條紙」上的資訊，才會知道最新各地址的餘額狀態。也因此，我們發送呼叫這個合約的交易，因為不會進行邏輯執行，所以實際上可以省下非常多的 gas，只需要付出交易的基本手續費 21,000 gas 加上些許的文字寫入 gas 費用。

我們回顧到目前為止 4 節 的內容，可以發現區塊鏈從 1.0 的比特幣，到 2.0 的以太坊，最大的升級便是智慧合約的功能，允許開發者可以客製化開發許多需要的功能。

《下篇》結論

1. 在區塊鏈上發行代幣不是真的發行硬幣或發行鈔票，而是建立了一個「類 Excel 帳本」來紀錄誰擁有多少代幣
2. 代幣轉移時必須發送一筆接收地址為合約地址的交易，並在 Input Data 中呼叫合約中的 function 進行操作，並付出相應的運算成本給礦工。
3. 以太坊 2.0 的 Phase 1 中由於沒有邏輯執行的功能，因此智慧合約都成了「無頭合約」，讓以太坊 2.0 再次被當作如 Omni Layer 般的「便條紙」來使用。

好！介紹至此，大家應該對於區塊鏈上的代幣在技術面有更深一層的認知。下一節 我們將來介紹更多的以太坊技術細節，包括以太坊交易為何會塞車？為什麼要有區塊大小的限制？也會更清楚地說明許多前面有提到但解釋不夠清楚的地方。謝謝大家！

傳送門：文組也該知道的區塊鏈技術知識 <5> 不可不知的以太坊交易打包規則

以上，若有任何

A. 我寫得不夠清楚的地方
B. 撰寫上改進的建議
C. 希望我能夠撰寫分享的區塊鏈技術知識內容

都非常歡迎在底下留言回覆。希望我的文章能幫助到更多像我一樣想學習區塊鏈技術與知識的朋友。如果您覺得讀完有所收穫，也希望能
＊不吝嗇給我 Like / 50 claps
＊分享給您的朋友們
謝謝大家！

文組也該知道的區塊鏈技術知識 <4> 從染色幣到無頭合約的代幣演進史《下篇》 was originally published in Pelith on Medium, where people are continuing the conversation by highlighting and responding to this story.

Blockchain Technical Overview <3> The History of Token ( Part 1 )

收看本系列文章的讀者，應該都對於區塊鏈的基本原理和架構有些概念，如果沒有，推薦您先去 Google 搜尋 區塊鏈、比特幣、以太坊這些關鍵字了解一下。我們將在這些基礎概念之上，來談區塊鏈的技術知識。本系列文章並不會談到太深的技術鑽研，而是希望以深入淺出的方式讓每一個想要搞懂區塊鏈技術的人都能在讀完後說出：原來如此！

在前兩節的內容我們從交易開始認識比特幣及以太坊的基礎架構，隨後介紹了以太坊智慧合約運作的概念。第三節我們將來回顧區塊鏈「代幣」演進的歷史，並解析與之相關的技術。由於內容豐富，為避免讀者閱讀上的負擔，會分成上、下兩個篇章來闡述。

既然要談代幣，就必須先釐清代幣的定義。用比喻來說明的話，我們現實世界中有各國發行流通的法幣，如：台幣（NTD）、美金（USD）。然而，有些公司為了便於平台管理或流通便利性等因素，會發行在平台流通的「代幣」，如：湯姆熊幣、Line Points。

在區塊鏈的世界裡，其實也存在類似的概念，在公鏈上流通的加密貨幣如：比特幣（BTC）、以太幣（ETH），就像是各國的法幣，普遍被稱之為「協議代幣」（在比特幣/以太坊協議下流通的代幣）。然而，在以太坊上我們可以透過智慧合約客製化來創造出類似於代幣性質的產物，可稱之為「自定義代幣」，透過智慧合約來賦予代幣功能，類似我們傳統上理解的代幣。

「協議代幣」與「自定義代幣」我們都稱為加密貨幣（Cryptocurrency）。而「協議代幣」往往有自己的區塊鏈或類似的分散式帳本技術，不需要任何其它區塊鏈就能獨立運作。而「自定義代幣」則是利用現有的區塊鏈（絕大多數是 Ethereum），透過智慧合約或其它方式來發行及運行。

本文主要是以「自定義代幣」為主題來介紹。

2017 年的 ICO 浪潮開啟了大發幣時代，人人都能在以太坊區塊鏈上發行自己的代幣。但其實在以太坊上線之前便已有區塊鏈代幣（以下簡稱代幣）的存在。

區塊鏈代幣的起源：染色幣（Colored Coin）

代幣的歷史最早可以溯及到比特幣上的染色幣。但比特幣沒有智慧合約，要如何發幣呢？當時鑄造 Token 的做法是：我們把 1 Satoshi (10^-8個 Bitcoin) 重新定義為 1 USD。如此一來，1 Bitcoin (100 Million Satoshi ) 的價值便變成了 100M USD。然而這樣的做法必須具有公信力，因此鑄造的機構應該要抵押 100M 的 USD 來擔保這 100M 的 Satoshi 具有等值 100M USD 的價值（但沒有機制保證鑄造機構真的有抵押）。於是我們會說這些比特幣被染色了，因為它代表的不再是比特幣的帳面價值，而被賦予了新的價值意義，只是這個 Token 透過比特幣的區塊鏈網絡來進行流通。我發送給你 100 Satoshi，其實是發送給你 100 USD。

但這 100M 的染色幣要怎麼跟其它比特幣來區隔呢？於是許多鑄造商會再利用一個比特幣外部的帳本來追蹤這 100M Satoshi 的交易紀錄，如此來確認誰手上具有這些被「染色」的 Satoshi，他們有權利可以用這些 Satoshi 兌換為美金。此外，在比特幣 UTXO 的架構下，若是同時交易了染色幣與比特幣，該怎麼區分哪些是有染色的 Satoshi 呢？一種可能的做法是：一筆交易的Output 中在前的錢堆是染色幣；在後的錢堆則是比特幣。
（不了解 UTXO 架構的讀者傳送門）

以上，便是最古早鑄造的 Token 的作法。這個作法主要的缺點是：當你把這 1 顆 Bitcoin 染色，也代表你失去了這 1 Bitcoin（因為這 1 Bitcoin 被當作其它的用途了）。並且當你要交易 300 美金（ 300 Satoshi ）給別人時，卻必須付出遠大於 300 Satoshi 的手續費給礦工，所以其實很少人這樣子鑄造。在 2017 年幣價突破天際後，便幾乎沒人再這樣鑄造了。

USDT 與 Omni Layer

接下來的作法，便是由 Tether 公司發行，赫赫有名的第一代 USDT。第一代 USDT 是建構在比特幣上，採用 Omni Layer 的技術。做法是在比特幣上發送交易，然而交易本身不是重點，重點是在交易的 OP_RETURN 中寫下訊息。如：地址 A 給地址 B <10 USDT>，地址 B 便可以再給地址 C <4 USDT>、給地址 D <2 USDT>。如此不斷的接續下去，就像是把比特幣當作便條紙來使用一般，僅是利用比特幣的 OP_RETURN 內容會永久存在區塊鏈上的特性來記錄 USDT 的流通。

然而，若是一個地址 A 並沒有持有 USDT，但他卻寫下了給 B <10 USDT>，這樣具有效力嗎？於是，Omni Layer 便另外建立了一個 Explorer 來追蹤這些所有 Bitcoin 交易上 OP_RETURN 內的 Omni 訊息，藉以得知每個地址持有的 USDT。若是有地址寫下了無效的交易訊息將被自動濾掉。

以太坊 ERC-20 Token

以上便是在比特幣上發行 Token 常見的作法。接下來進入到以太坊的世界，由於智慧合約功能的出現，一切都變得簡單了些。ERC-20 Token 是至今最常見的代幣，那麼 ERC-20 是什麼？ERC-20 Token 是怎麼鑄造出來的呢？

ERC-20 是以太坊上發行代幣的協定規範，約定發行的代幣必須包含的資訊（如發行幾顆）以及代幣具有的功能（如發送與接收）和限制（如一定時間內能從錢包提領的上限）等，並且會在以太坊上建立資料庫來記錄每個地址持有的代幣數量。

舉例來說，我今天想要發行一個 ERC-20 Token，取名叫 Pelith Token。假設想發行一百萬顆，要怎麼做到呢？

用最直白的方式來說，就是要寫一個 ERC-20 代幣發行規範的智慧合約，並在發行量這段程式碼中寫一百萬顆，接著把這個智慧合約放入一筆交易的 Input Data 中，交易的接收地址填為 0x0，被礦工執行部署完成後，一百萬顆 Pelith Token 便誕生了。所以說，代幣的創造在技術上是非常容易的，無論想要發行一百萬顆、一億顆、十億顆，其實都只是智慧合約內改個數字的差別，發行量的變動成本趨近於零。所以 2017 年的 ICO 浪潮，才會出現這麼多各式各樣的 shitcoin，只要寫個智慧合約和白皮書，一個代幣就此誕生了，可以開始圈錢。啊！不是，是募資。
（不了解智慧合約架構的讀者傳送門）

真正的難處往往是代幣發行後實際的應用場景搭建和社群行銷營運，讓這個代幣被認可、讓人願意持有及應用才是最大的困難點和成本之所在。

《上篇》結論

1. 「協議代幣」往往有自己的區塊鏈或類似的分散式帳本技術，而「自定義代幣」則是利用現有的區塊鏈來發行及運行。
2. 早期比特幣上常見的代幣有改變單位定義的染色幣與把比特幣作為便條紙的 Omni Layer 兩種做法。
3. 以太坊與智慧合約的出現讓發行代幣在技術門檻上變得更簡易且更有統一的規範，然而應用場景搭建與社群行銷營運才是真正難處。

好，先分享至此，上篇中大致帶過了流變的脈絡，《下篇》我們將更著重在技術面的介紹。

傳送門：文組也該知道的區塊鏈技術知識 <4> 從染色幣到無頭合約的代幣演進史 《下篇》

以上，若有任何

A. 我寫得不夠清楚的地方
B. 撰寫上改進的建議
C. 希望我能夠撰寫分享的區塊鏈技術知識內容

都非常歡迎在底下留言回覆。希望我的文章能幫助到更多像我一樣想學習區塊鏈技術與知識的朋友。如果您覺得讀完有所收穫，也希望能
＊不吝嗇給我 Like / 50 claps
＊分享給您的朋友們
謝謝大家！

文組也該知道的區塊鏈技術知識 <3> 從染色幣到無頭合約的代幣演進史《上篇》 was originally published in Pelith on Medium, where people are continuing the conversation by highlighting and responding to this story.