一. 以太坊概述

以太坊（Ethereum）作為區塊鏈技術的代表性項目之一，自2015年發布以來，迅速成為全球區塊鏈行業的核心基礎設施。相比比特幣，以太坊不僅支持點對點的價值轉移，還引入了智能合約，使其能夠承載更加豐富的去中心化應用（DApps）。本文將從以太坊的基本概念、核心原理、技術架構、工作機制及其應用場景等方面展開全面探討，幫助讀者深入理解以太坊的技術優勢和實際價值。

一、以太坊的概念

1.1 以太坊是什么？

以太坊是一個開源的區塊鏈平臺，旨在為開發者提供去中心化應用開發的環境。與比特幣不同，除了提供點對點的加密貨幣交易功能外，以太坊還內置了一種編程語言（Solidity），可以用于編寫智能合約，從而實現自動化的業務邏輯執行。

1.2 以太坊的核心目標

1. 去中心化：提供一個無需第三方中介的交易和應用平臺。
2. 不可篡改：確保數據一旦上鏈無法被篡改。
3. 高效透明：通過智能合約自動執行業務邏輯，減少人為干預，提高效率。
4. 支持DApp開發：為開發者提供工具和環境，構建各類去中心化應用。

1.3 以太坊的基礎組件

• 以太幣（Ether，ETH）：以太坊網絡的原生加密貨幣，用于支付交易手續費和智能合約的執行成本。
• 智能合約：一段存儲在以太坊區塊鏈上的代碼，可以自動執行特定條件下的預設邏輯。
• 虛擬機（EVM）：以太坊虛擬機是智能合約運行的核心環境，為開發者提供了一個沙箱式的代碼執行環境。

二、以太坊的技術原理

????????對比比特幣的 “UTXO” 余額模型，以太坊使用“賬戶”余額模型。 以太坊豐富了賬戶內容，除余額外還能自定義存放任意多數據。 并利用賬戶數據的可維護性，構建智能合約賬戶。
實際上以太坊是為了實現智能合約而提煉的賬戶模型。 以賬戶為單位，安全隔離數據。 賬戶間信息相互獨立，互不干擾。 再配合以太坊虛擬機，讓智能合約沙盒運行。

以太坊作為智能合約操作平臺，將賬戶劃分為兩類：外部賬戶（EOAs）和合約賬戶（contract account）。? ? ? ? ? ? ? ??

2.1 賬戶模型

以太坊采用賬戶模型，而比特幣采用UTXO模型。以太坊的賬戶模型包含兩種類型：

外部賬戶（Externally Owned Account, EOA）：

????????類似于BTC系統中公私鑰對

????????是由我們通過私鑰創建的賬戶。 是真實世界的金融賬戶的映射，擁有該賬戶私鑰的任何人都可以控制該賬戶。 如同銀行卡，到ATM機取款時只需要密碼輸入正確即可交易。 這也是人類與以太坊賬本溝通的唯一媒介，因為以太坊中的交易需要簽名， 而只能使用擁有私有外部賬戶簽名。????

合約賬戶特點總結：????

• 擁有以太余額。
• 能發送交易，包括轉賬和執行合約代碼。
• 被私鑰控制。
• 沒有相關的可執行代碼。

合約賬戶（Contract Account, CA）：

????????合約賬戶則是含有合約代碼的賬戶。 被外部賬戶或者合約創建，合約在創建時被自動分配到一個賬戶地址， 用于存儲合約代碼以及合約部署或執行過程中產生的存儲數據。 合約賬戶地址是通過SHA3哈希算法產生，而非私鑰。 因無私鑰，因此無人可以拿合約賬戶當做外部賬戶使用。 只能通過外部賬戶來驅動合約執行合約代碼。

????????不是通過公私鑰對控制。(不能主動發起交易，以太坊規定所有的交易只能有外部賬戶才能發起，一個合約賬戶在接收到外部賬戶調用后才能發起交易或調用其他合約賬戶)其除了balance和nonce之外還有code(代碼)、storage(相關狀態-存儲)。

合約賬戶特點總結：

• 擁有以太余額。
• 有相關的可執行代碼（合約代碼）。
• 合約代碼能夠被交易或者其他合約消息調用。
• 合約代碼被執行時可再調用其他合約代碼。
• 合約代碼被執行時可執行復雜運算，可永久地改變合約內部的數據存儲。

?差異對比

綜上，下面表格列出兩類賬戶差異，合約賬戶更優于外部賬戶。 但外部賬戶是人們和以太坊溝通的唯一媒介，和合約賬戶相輔相成。

比較項	外部賬戶	合約賬戶
私鑰 private Key	有	無
余額 balance	有	有
代碼 code	無	有
多重簽名	無	有
控制方式	私鑰控制	通過外部賬戶執行合約

????????上面有列出多重簽名，是因為以太坊外部賬戶只由一個獨立私鑰創建，無法進行多簽。 但合約具有可編程性，可編寫符合多重簽名的邏輯，實現一個支持多簽的賬戶。

如何調用一個合約賬戶？

創建合約賬戶的時候會返回一個地址，知道這個合約的地址就可以對其調用。調用過程中，代碼不變但狀態會發生改變。

為什么要做以太坊，更換為基于賬戶的模型而不是沿襲BTC系統？
比特幣中支持每次更換賬戶，但以太坊是為了支持智能合約，而合約簽訂雙方是需要明確且較少變化的。尤其是對于合約賬戶來說，需要保持賬戶的穩定狀態。

二、帳戶創建

2.1 外部賬戶創建
當你想要創建一個帳戶時，大多數庫將生成一個隨機的私鑰。

私鑰由 64 個十六進制字符組成，可以用密碼加密保存。

例如：

fffffffffffffffffffffffffffffffebaaedce6af48a03bbfd25e8cd036415f

使用橢圓曲線數字簽名算法從私鑰生成公鑰。 通過獲取公鑰 Keccak-256 哈希的最后 20 個字節并校驗碼前面添加 0x，可以為帳戶獲取公共地址。

// PubkeyToAddress 公鑰轉地址方法
func (p *PublicKey) ToAddress() Address {
?? ?pubBytes := p.FromECDSAPub()
?? ?i := sha3.Keccak256(pubBytes[1:])[12:]
?? ?return BytesToAddress(i)
}

地址具體生成細節可參考： 以太坊地址生成

下面是使用 GETH 的 personal_newAccount 在控制臺中創建一個帳戶的例子

> personal.newAccount()
Passphrase: ?輸入賬戶密碼
Repeat passphrase: ?再次輸入賬戶密碼
"0x0dd26b4f63f9362314b708816a6aa18a04442679" ?得到賬戶地址

> personal.newAccount(123456)
"0x5942bd5c577b569e27dd789b50b7d8824fe399ea"
?

geth指令詳情可查看geth文檔

2.2 合約賬戶創建
下面是合約地址生成算法：Keccak256(rlp([sender,nonce])[12:]

// https://github.com/ethereum/go-ethereum/blob/master/crypto/crypto.go

func CreateAddress(b common.Address, nonce uint64) common.Address {
? ? data, _ := rlp.EncodeToBytes([]interface{}{b, nonce})
? ? return common.BytesToAddress(Keccak256(data)[12:])
}

因為合約由其他賬戶創建，因此將創建者地址和該交易的隨機數進行哈希后截取部分生成。

特別需要注意的是，在EIP1014中提出的另一種生成合約地址的算法。 其目的是為狀態通道提供便利，通過確定內容輸出穩定的合約地址。 在部署合約前就可以知道確切的合約地址。下面是算法方法:

keccak256( 0xff ++ address ++ salt ++ keccak256(init_code))[12:]。

// https://github.com/ethereum/go-ethereum/blob/master/crypto/crypto.go// CreateAddress2 creates an ethereum address given the address bytes, initial
// contract code hash and a salt.
func CreateAddress2(b common.Address, salt [32]byte, inithash []byte) common.Address {
?? ?return common.BytesToAddress(Keccak256([]byte{0xff}, b.Bytes(), salt[:], inithash)[12:])
}

三、賬戶數據結構

3.1 賬戶狀態

賬戶的狀態(Acccount State)描述了一個賬戶當前的情況。以太坊公鏈時時刻刻跟蹤并維護著每一個賬戶的狀態。 一個賬戶在初次接收或者發出交易后，都會形成初始狀態。隨著時間的推移，每次針對該賬戶的交易將不斷修改其狀態。

注：總結而言，每一個賬戶在數據結構上具有兩個元素：一個公開地址，一個與該地址關聯的狀態。

在程序邏輯上兩類賬戶的數據結構一致，包含四大元素：

1. nonce：已執行交易總數，用來標示該賬戶發出的交易數量；
2. balance：持幣數量，記錄用戶的以太幣余額；
3. storageRoot hash：存儲區的哈希值，指向智能合約賬戶的存儲數據區；
4. code hash：代碼區的哈希值，指向智能合約賬戶存儲的智能合約代碼。

//github.com/ethereum/go-ethereum/core/types/account.gotype Account struct {
? ? Nonce ? ?uint64
? ? Balance ?*big.Int
? ? Root ? ? common.Hash
? ? CodeHash []byte
}

?以太坊數據以賬戶為單位組織，賬戶數據的變更引起賬戶狀態變化。 從而引起以太坊狀態變化。

以太坊狀態數據：

????????基于狀態機模型，以太坊網絡已變成一個依靠礦工維護的去中心化的大型狀態機。在任意時刻，只會處于一個狀態中，全世界唯一的狀態。我們把這個狀態機，稱之為以太坊世界狀態，代表著以太坊網絡的全局狀態。??

??世界狀態(state)

????????由無數的賬戶信息組成，每個賬戶均存在一個唯一的賬戶信息。賬戶信息中存儲著賬戶余額、Nonce、合約哈希、賬戶狀態等內容，每個賬戶信息通過賬戶地址影射。 從創世狀態開始，隨著將交易作為輸入信息，在預設協議標準（條件）下將世界態推進到下一個新的狀態中。

世界狀態中存儲了哪些內容：

首先，以太坊中有兩種級別的狀態，一個是頂級的世界狀態，另一個是賬戶級的賬戶狀態。賬戶狀態中存儲賬戶信息：

1. nonce: 這個值等于由此賬戶發出的交易數量，或者由這個賬戶所創建的合約數量(當這個賬戶有關聯代碼時)。
2. balance: 表示這個賬戶賬戶余額。
3. storageRoot: 表示保存了賬戶存儲內容的 MPT 樹的根節點的哈希值。
4. codeHash: 表示賬戶的 EVM 代碼哈希值，當這個地址接收到一個消息調用時，這些代碼會被執行; 它和其它字段不同，創建后不可更改。如果 codeHash 為空，則說明該賬戶是一個簡單的外部賬戶，只存在 nonce 和 balance。

?在程序邏輯上兩類賬戶的數據結構一致：

//github.com/ethereum/go-ethereum/core/types/account.gotype Account struct {
? ? Nonce ? ?uint64
? ? Balance ?*big.Int
? ? Root ? ? common.Hash
? ? CodeHash []byte
}

?但在數據存儲上稍有不同， 因為外部賬戶無內部存儲數據和合約代碼，因此外部賬戶數據中 StateRootHash 和 CodeHash 是一個空默認值。 一旦屬于空默認值，則不會存儲對應物理數據庫中。 在程序邏輯上，存在code則為合約賬戶。 即 CodeHash 為空值時，賬戶是一個外部賬戶，否則是合約賬戶。

關于nonce,解決重放攻擊，重放攻擊解釋:

????????A向B轉賬，過一段時間，B將A的交易重新廣播一次，從而導致A賬戶被扣錢兩次。假設A給B轉錢，雙花攻擊（double spending attack）是A不誠實，重放攻擊（replay attack）是B不誠實。

????????為了防范重放攻擊，給賬戶交易添加計數器記錄該賬戶有史以來發布過多少次交易，轉賬時候將轉賬次數計入交易的內容中。?

????????如果此時如果B重放了這個交易，那么當前A的nonce至少是大于等于21，那么顯然與下一筆合法交易要比當前nonce+1不再滿足了！！
系統中全節點維護賬戶余額和該計數器的交易數，從而防止本地篡改余額或進行重放攻擊。

3.2 賬戶狀態結構

四. 以太坊的狀態樹

4.1 賬戶狀態的數據結構

以太坊采用基于賬戶的模式，系統中顯式記錄每個賬戶的余額。我們要完成的是從賬戶地址到賬戶狀態的映射，addr-->state。

在以太坊中，賬戶地址為160位，表示為40個16進制數；狀態包含了余額(balance)、交易次數(nonce),合約賬戶中還包含了code(代碼)、存儲(stroge)。

需要記住的是，在BTC和以太坊中，交易保存在區塊內部，一個區塊可以包含多個交易。通過區塊構成區塊鏈，而非交易。

直觀地來看，其本質上為Key-value鍵值對，直接可以查詢每個賬戶的狀態，所以直觀想法便用哈希表實現。若不考慮哈希碰撞，查詢直接為常數級別的查詢效率。但采用哈希表，難以提供Merkle proof。

例如：跟一個人簽合同，希望他證明他的賬戶余額有多少錢

• 一種方法是像BTC中，將哈希表的內容組織為Merkle Tree
  • 將哈希表的元素組織成一個Merkle Tree，算出根哈希值，并保存在blockheader中，只要保證根哈希值不變就能保證內容不變。
  • 但當新區塊發布，哈希表內容會改變，再次將其組織為新的Merkle Tree，如果這樣，每當產生新區塊(ETH中新區塊產生時間為10s左右)，都要重新組織Merkle Tree，很明顯這是不現實的，代價太大。
  • 而在區塊鏈中沒有這個缺點，因為比特幣系統中沒有賬戶概念，交易由區塊管理，每個Merkle Tree包含著一個區塊的所有交易，每一個區塊對應一個Merkle Tree，一旦發布就不會再改了，所以Merkle Tree不是無限增大的。而ETH中，將賬戶信息組織成Merkle Tree，很明顯其會越來越龐大。
• 第二種方法是不要哈希表了，直接使用Merkle Tree組織賬戶信息，每次修改只需要修改其中一部分即可
  • 實際中，Merkle Tree并未提供一個高效的查找和更新的方案。
  • 此外，將所有賬戶構建為一個大的Merkle Tree，為了保證所有節點的一致性和查找速度，必須進行排序，如果不排序，得到的Merkle Tree可能不一樣。
  • 為什么區塊鏈沒有這個缺點。在區塊鏈中每個人組織的塊里的交易順序是不一樣的，但是有決定權的只有有記賬權的那個人，所以順序一不一樣無所謂。
• 第三種方法，經過排序，使用Sorted Merkle Tree可以嗎？
  • 新增賬戶，由于其地址隨機，插入Merkle Tree時候很大可能在Tree中間，發現其必須進行重構，所以Sorted Merkle Tree插入、刪除(實際上可以不刪除)的代價太大。
  • 而且其實創建賬戶沒必要讓別人知道，只有狀態改變才需要讓別人知道

既然哈希表和 Merkle Tree都不可以，實際中以太坊采取的數據結構：MPT（Merkle Patricia trie）

4.2 trie（字典樹、前綴樹）

先了解一個簡單的數據結構trie

如下為一個通過5個單詞組成的trie數據結構（只畫出key，未畫出value）

特點：

• trie中每個節點的分支數目取決于Key值中每個元素的取值范圍(圖中最多26個英文字母分叉+一個結束標志位)。以太坊中分支數目是17（16進制加一個結束標志位）
• trie查找效率取決于key的長度。實際應用中（以太坊地址長度為40）
• 理論上哈希會出現碰撞，而trie上面不會發生碰撞。
• 給定輸入，無論如何順序插入，構造的trie都是一樣的。
• 更新操作局部性較好

缺點：

• trie的存儲浪費。很多節點只存儲一個key，但其“兒子”只有一個，過于浪費。因此，為了解決這一問題，我們引入Patricia tree/trie

4.3 Patricia tree/trie

Patricia trie就是進行了路徑壓縮的trie。

壓縮后好處是樹的高度縮短，這樣訪問內存的次數大大減少，效率變高。

需要注意的是，如果新插入單詞，原本壓縮的路徑可能需要擴展開來。那么，需要考慮什么情況下路徑壓縮效果較好？樹中插入的鍵值分布較為稀疏的情況下，可見路徑壓縮效果較好。

在以太坊系統中，160位的地址存在2^160 種，該數實際上已經非常大了，和賬戶數目相比，可以認為地址這一鍵值非常稀疏。

因此，我們可以在以太坊賬戶管理種使用Patricia tree這一數據結構。

但實際上，在以太坊種使用的并非簡單的PT(Patricia tree),而是MPT(Merkle Patricia tree)。

4.4 Merkle Tree （克爾樹）和 Binary Tree（二叉樹）

區塊鏈和鏈表的區別在于區塊鏈使用哈希指針，鏈表使用普通指針。同樣，Merkle Tree 相比 Binary Tree，也是普通指針換成了哈希指針。

所以，以太坊系統中可如此，將所有賬戶狀態組織為一個Patricia tree，用路徑壓縮提高效率，將普通指針換成了哈希指針，就可以計算出一個根哈希值，這個根哈希值存儲于block header中。

根哈希值的作用：

• 第一：防止篡改，只要根哈希值不變，所有賬戶的狀態也不變。
• 第二：提供Merkle Proof，可以證明賬戶余額，輕節點進行驗證
• 第三，證明某個發生了交易的賬戶是否存在，也就是證明某個鍵值是否存在。

4.5 MPT(Modified Patricia tree)

以太坊中針對原生版的MPT(Merkle Patricia tree)進行了修改，我們稱其為MPT(Modified Patricia tree)

下圖為以太坊中使用的MPT結構示意圖。右上角表示四個賬戶(為了直觀，賬戶地址顯示較短)和其狀態(只顯示賬戶余額)。

樹中的節點分為三種，第一個是Extension Node，當發生了路徑壓縮就會有；第二個節點是Leaf Node，表示葉子節點，是最后的；第三個是Branch Node，表示分支節點。還有一個根節點，取哈希得到根哈希值，寫入塊頭。

需要注意這里的指針都是哈希指針，普通指針里面存的是下一個節點的地址，而這里的哈希指針存的是下面節點的哈希值。

每次發布新區塊，狀態樹中部分節點狀態會改變，但改變并非在原地修改，而是新建一些分支，原本狀態是保留的。

如下圖中，僅僅有新發生改變的節點才需要修改，其他未修改節點直接指向前一個區塊中的對應節點。

所以，系統中全節點并非維護一棵MPT，而是每次發布新區塊都要新建MPT，只不過大部分節點共享，只有少數發生變化的節點是要新建分支的。

為什么要保存原本狀態？為何不直接修改？

為了便于回滾。如下1中產生分叉，而后上面節點勝出，變為2中狀態。那么，下面節點中狀態的修改便需要進行回滾。

以太坊中有智能合約，理論上能實現很復雜的功能，如果不保存歷史狀態，智能合約執行完后，想推算出以前的狀態是不可能的，因此，需要維護這些歷史記錄。

4.6 以太坊中代碼的數據結構

block header 中的數據結構

arentHash是前一區塊塊頭的哈希值。Coinbase挖出區塊的礦工的地址。

三棵樹：狀態數、交易樹、收據樹

Difficulty也需要根據需要修改

Nouce挖礦中需要猜的隨機數

區塊結構

區塊在網上真正發布時的信息

狀態樹中保存Key-value對，key就是地址，而value狀態通過RLP (Recursive Length Prefix，一種進行序列化的方法，特點是很簡單) 編碼序列號之后再進行存儲。

五.交易樹和狀態樹

每次發布區塊，區塊中的交易會組織成一棵交易樹，也是一棵Merkle tree與比特幣類似
每個交易執行完之后會產生一個收據，記錄交易的相關信息，交易樹和收據樹的結點是一一對應的。
由于以太坊智能合約執行較為復雜，通過增加收據樹，便于快速查詢執行結果。

數據結構

交易樹和收據樹都是MPT，而BTC中都采用普通的MT，MPT的好處是支持查找操作，通過鍵值沿著樹進行查找即可。對于狀態樹，查找鍵值為賬戶地址；對于交易樹和收據樹，查找鍵值為交易在發布的區塊中的序號，序號由發布區塊的結點決定。
交易樹和收據樹只把當前發布區塊的交易組織起來，而狀態樹是把系統中所有賬戶的狀態包含進去，無論這些賬戶是否與當前區塊中交易有關系。多個區塊狀態樹共享節點，只會為更改了狀態的結點新建一個分支，而交易樹和收據樹依照區塊獨立。

交易樹和收據樹的作用

• 提供Merkle proof
• 更加復雜的查找操作(例如：查找過去十天與某個智能合約有關的交易；過去十天的眾籌事件等)

Bloom?filter

支持較為高效地查找某個元素是否在某個比較大的集合中
最笨：元素遍歷，復雜度為O(n)，且輕節點沒有存儲交易列表不能使用
Bloom filter的思想：給一個大的集合，計算出一個非常緊湊的“摘要”

例：如下圖，給定一個數據集，其中含有元素a、b、c，通過一個哈希函數H()對其進行計算，將其映射到一個初始全為0的向量的某個位置，將該位置置為1。將所有元素處理完，就可以得到一個向量，則稱該向量為原集合的“摘要”。可見該“摘要”比原集合是要小很多的。
假定想要查詢一個元素d是否在集合中，假設H(d)映射到向量中的位置處值為0，說明d一定不在集合中；假設H(d)映射到向量中的位置處為1，有可能集合中確實有d，也有可能因為哈希碰撞產生誤報。

Bloom filter特點：有可能出現誤報，但不會出現漏報。
Bloom filter變種：采用一組哈希函數進行向量映射，有效避免哈希碰撞
Bloom filter不支持刪除操作，有產生碰撞的可能

ETH中的Bloom filter

每個交易完成后會產生一個收據，收據中會包含一個Bloom filter，記錄這個交易的類型、地址等其他信息，在發布的區塊的block header中也包含一個總的Bloom filter，其為該區塊中所有交易的Bloom filter的一個并集。

要查找過去十天發生的與智能合約相關的所有交易
查找時候先查找哪個塊頭中的Bloom filter有要查找的交易類型，如果塊頭中沒有，則這個區塊就不是我們要找的，如果塊頭有的話，我們繼續查找這個區塊所包含的交易的收據樹中的Bloom filter，如果存在，再查看交易進行確認；如果不存在，則說明發生了“碰撞”。

好處：通過Bloom filter這樣一個結構，快速大量過濾掉大量無關區塊，從而提高了查找效率。

補充
以太坊的運行過程，可以視為交易驅動的狀態機，狀態機的狀態是狀態樹的內容，交易是每次發布的區塊所包含的交易，通過執行當前區塊中包含的交易，驅動系統從當前狀態轉移到下一狀態。BTC我們也可以視為交易驅動的狀態機，其狀態為UTXO。問題1：A轉賬到B，有沒有可能收款賬戶不包含再狀態樹中？
可能。因為以太坊中賬戶可以節點自己產生，不需要通知其他人，只有在產生交易時才會被系統知道，此時在狀態樹中會新插入一個結點。
問題2：可否將每個區塊中狀態樹更改為只包含和區塊中交易相關的賬戶狀態？(大幅削減狀態樹大小，且和交易樹、收據樹保持一致)
不能。首先，這樣設計要查找賬戶狀態很不方便，因為不存在某個區塊包含所有狀態，在轉賬的時候因為要查找相關賬戶的狀態信息，需要從區塊依次往前查找這個賬戶的信息，如果這個賬戶很久沒有參與交易的話會需要往前查找很多區塊，其次，如果要向一個新創建賬戶轉賬，因為需要知道收款賬戶的狀態，才能給其添加金額，但由于其是新創建的賬戶，所以需要一直找到創世紀塊發現根本不存在這個賬戶，才能知道該賬戶為新建賬戶，系統中并未存儲。

代碼中的具體數據結構

創建交易樹和收據樹

求根哈希值

Trie的數據結構

Receipt的數據結構

區塊頭的數據結構

生成Bloom filter

查詢Bloom filter中是否包含topic

六.權益證明

概念
PoS（Proof-of-Stake，權益證明） 是一種用于區塊鏈網絡的共識算法，它作為 Proof-of-Work（PoW，工作量證明） 的替代方案而出現，目的在于提升能源效率與安全性。

在 PoS 中，節點的記賬權（即產生新區塊的權利）并不是通過計算能力競爭獲得的，而是根據其在網絡中持有的代幣數量及質押時間來分配。

基本原理
質押（Staking）：

• 用戶將自己持有的代幣鎖定（質押）在網絡中作為保證金。
• 質押越多，獲得驗證資格和獎勵的機會就越大。

選出區塊提議者（Proposer）：

• 系統根據質押比例、隨機性等因素選出一名節點來“提議”新區塊。

驗證與投票：

• 其他持幣人或驗證節點對新區塊進行投票，達成共識。
• 一旦多數驗證者同意，新區塊即被添加到區塊鏈上。

獎勵與懲罰：

• 成功打包新區塊的驗證者會獲得區塊獎勵。
• 惡意節點（如雙重簽名）將被罰沒質押，稱為“slashing”。

優點

優點?? ?	描述
節能環保?? ?	不需要大量計算資源，能耗遠低于 PoW
成本門檻低?? ?	不需購買昂貴的挖礦設備，只需質押代幣
更快確認?? ?	出塊速度較快，交易確認時間更短
經濟安全性?? ?	懲罰機制讓作惡成本高昂，激勵誠實行為

缺點

缺點	描述
富者更富效應	擁有大量代幣者更容易當選，進一步獲得獎勵
長程攻擊風險	惡意節點可在過去歷史上“重建鏈”
Nothing-at-Stake	驗證者可能在多個分叉上簽名，不承擔太多風險
中心化風險	質押池或大型驗證節點可能壟斷權力

以太坊正式從工作量證明（PoW）?轉向權益證明（PoS）?的時間是?2022年9月15日，這一重大升級被稱為?“合并”（The Merge）。以下是關鍵細節：

? 1.?具體時間點

• 2022年9月15日世界標準時間（UTC）06:42:42，以太坊主網達到預設的終端總難度（TTD）58,750,000,000T，觸發了合并過程。

• 合并后，以太坊的原PoW主網與PoS信標鏈（Beacon Chain）完全整合，區塊生成和驗證正式由礦工移交至驗證者（Validators）。

💡 2.?合并的意義與核心變化

• 能源消耗降低99.95%：PoS機制無需礦工進行算力競爭，大幅減少電力需求。

• ETH發行量減少90%：合并后每日ETH發行量從約13,000枚降至約1,600枚，通縮壓力增強。

• 安全性提升：攻擊成本顯著增加，需控制全網2/3質押的ETH才可能篡改最終確定的交易。

🔧 3.?合并的背景與延遲

• 以太坊PoS升級計劃最早可追溯至2020年（信標鏈上線），但主網合并多次推遲。原定2022年6月的日期因測試未完成延至9月。

• 關鍵測試包括影子分叉（模擬主網合并）和Bellatrix升級（9月6日激活共識層準備），最終確保合并平穩進行。

?? 4.?后續影響

• 礦工退出：PoW挖礦被淘汰，部分礦工轉向以太坊經典（ETC）或支持分叉鏈ETHW56。

• 生態升級基礎：合并為以太坊后續擴容方案（如分片技術Danksharding）奠定基礎，提升交易處理能力

七.以太坊智能合約

以太坊中的智能合約（Smart Contract）?是一種運行在區塊鏈上的自動化程序，由代碼定義并強制執行合約條款。它徹底改變了傳統合約依賴第三方中介的模式，實現了“代碼即法律”的理念。以下是其核心要點詳解：

---

一、本質與核心特征

1. 自執行代碼
   當預設條件（如時間、交易觸發）滿足時，智能合約自動執行操作（如轉賬、數據更新），無需人工干預。

2. 去中心化與不可篡改
   部署后存儲在以太坊區塊鏈上，由全網節點共同驗證執行，無法被修改或停止（除非預設自毀機制）。

3. 透明公開
   代碼和交易記錄對所有用戶可見，確保可審計性。

4. 成本驅動（Gas 機制）
   每次執行需消耗?Gas（以 ETH 支付），用于補償節點計算資源消耗，防止垃圾代碼攻擊。

---

二、技術實現原理

組件	作用
以太坊虛擬機 (EVM)	智能合約的運行環境，確保代碼在所有節點執行結果一致。
Solidity 語言	以太坊主流開發語言（類 JavaScript），用于編寫合約邏輯。
合約地址	合約部署后生成唯一地址（類似銀行賬戶），用戶通過地址調用合約功能。
狀態存儲	合約可讀寫區塊鏈上的永久存儲空間（Storage），或臨時內存（Memory）。

??示例流程：
用戶 A 調用“支付合約” → 合約驗證 A 是否轉賬 1 ETH → 自動向用戶 B 轉賬 1 ETH → 交易記錄上鏈。

---

三、核心應用場景

領域	典型案例
DeFi	去中心化交易所（Uniswap）、借貸協議（Aave）、穩定幣（DAI）。
NFT	生成（ERC-721）、交易（OpenSea）、版權管理合約。
DAO	基于投票合約管理組織資金與規則（如 ConstitutionDAO）。
供應鏈	追蹤商品流轉（如 IBM Food Trust）。
游戲	游戲資產確權（Axie Infinity）、自動分發獎勵。

---

四、優勢與挑戰

優勢	挑戰
去信任化：無需依賴中介	代碼漏洞風險：一旦部署無法修復（如 2016 The DAO 被黑損失 6000 萬美元）
降低成本：減少人工審核	法律灰色地帶：代碼是否具備法律效力仍存爭議
高效透明：執行過程可追溯	Gas 費用波動：網絡擁堵時執行成本劇增
創新潛力：支撐 Web3 生態	復雜性：開發需精通密碼學與區塊鏈安全

---

五、與傳統合約的對比

特性	智能合約	傳統合約
執行方式	自動觸發，無人工干預	依賴法院/仲裁機構強制執行
信任基礎	代碼與數學原理	法律體系與第三方權威
修改權限	不可篡改（除非預設升級邏輯）	雙方協商后可修訂
透明度	鏈上完全公開	通常保密
成本結構	一次性部署 Gas + 調用費用	律師費、公證費、時間成本

---

六、安全須知

1. 審計必選
   部署前需經專業公司（如 CertiK, OpenZeppelin）審計代碼，避免重入攻擊、整數溢出等漏洞。

2. 權限控制
   關鍵函數應設置權限（如?onlyOwner），防止未授權調用。

3. 緊急開關
   高風險合約需設計暫停機制（Circuit Breaker），應對突發風險。

---

總結

以太坊的智能合約是區塊鏈技術的革命性應用，通過代碼自動化執行協議，構建了去中心化金融、NFT、DAO 等萬億級生態。盡管面臨安全與法律挑戰，其“無需信任”的核心邏輯正重塑商業協作范式。
下一階段演進：隨著以太坊擴容（如 Layer2）和零知識證明（ZK-SNARKs）的發展，智能合約將向更高效率、更強隱私性進化。

八.TheDAO

TheDAO（Decentralized Autonomous Organization，去中心化自治組織）是以太坊歷史上具有里程碑意義但最終失敗的項目，它既是區塊鏈治理的早期實驗，也是引發以太坊硬分叉的關鍵事件。以下是綜合梳理：

---

???1. 基本定義與核心機制

• 去中心化自治組織：TheDAO旨在通過智能合約實現完全代碼驅動的組織管理，無需傳統公司結構。參與者通過購買DAO代幣（以ETH兌換）獲得投票權，共同決策資金使用（如投資項目）。

• 技術基礎：基于以太坊智能合約，規則透明且自動執行，目標是成為“去中心化的風險投資基金”。

---

📅?2. 歷史背景與規模

• 眾籌紀錄：2016年4月啟動，28天內籌集1200萬ETH（占當時以太坊流通量的14%），價值約1.5億美元，參與超1.1萬人，成為史上最大眾籌項目。

• 理想愿景：由區塊鏈公司Slock.it發起，試圖顛覆傳統風投模式，實現“集體民主投資”。

---

???3. 黑客攻擊事件（2016年6月17日）

• 漏洞利用：黑客利用智能合約中splitDAO函數的遞歸調用漏洞，在未更新賬戶余額前重復提取資金，并結合“資產轉移規避銷毀”的漏洞，盜取360萬ETH（時值約5000萬美元）。

• 安全預警失效：早在攻擊前，以太坊開發者Vlad Zamfir等人多次警告合約風險，但未被重視。

---

???4. 社區應對與硬分叉

• 緊急措施：

  • 軟分叉嘗試：提議凍結TheDAO相關交易，但因漏洞導致網絡可能被DoS攻擊而失敗。

  • 白帽行動：黑客組織“羅賓漢”復制攻擊手法轉移剩余資金至安全地址。

• 硬分叉爭議：

  • 支持派（87%投票通過）：認為需挽回用戶損失，避免系統性信任危機。

  • 反對派：主張“代碼即法律”，堅持區塊鏈不可篡改性，反對人為干預

• 分叉執行（2016年7月20日）：

  • 以太坊在第192萬個區塊執行硬分叉，將被盜資金強制退回新合約，允許投資者贖回ETH。

  • 分裂結果：反對者維護原鏈，形成以太坊經典（ETC），黑客所盜資金在該鏈仍有效。

---

💎?5. 影響與遺產

• 技術反思：

  • 暴露智能合約安全風險，推動形式化驗證、審計工具發展（如OpenZeppelin）。

  • 促成Solidity語言改進與安全最佳實踐（如“檢查-生效-交互”模式防重入攻擊）。

• 治理啟示：

  • 挑戰“完全去中心化”理想，揭示緊急情況下社區決策與鏈上干預的必要性。

  • DAO概念重生：2020年后涌現憲法DAO、LinksDAO等項目，聚焦明確目標與安全設計，脫離TheDAO陰影。

• 市場影響：

  • 短期導致ETH價格暴跌30%，但長期助推以太坊生態成熟。

  • ETC作為“原則捍衛者”延續運行，但市值遠低于ETH。

---

💎 總結

TheDAO是以太坊早期一場烏托邦式的社會實驗，它因安全漏洞崩塌，卻深刻重塑了區塊鏈的發展軌跡：技術上催生了智能合約安全范式，治理上揭示了代碼與人性規則的沖突平衡，生態上間接孕育了今日DAO經濟的百花齊放。其興衰警示后人：去中心化愿景需扎根于穩健的工程與包容的治理。

九.美鏈

以太坊美鏈（Beauty Chain，簡稱BEC）是2018年基于以太坊發行的代幣項目，旨在構建去中心化的“美麗產業生態鏈”，但因安全漏洞事件引發巨大爭議并最終失敗。以下是其核心要點解析：

---

???一、項目定位與技術基礎

1. 生態愿景
   美鏈試圖整合美容產業上下游資源（內容生產者、商家、用戶等），通過區塊鏈技術激勵生態貢獻，例如用戶分享美容內容或數據可獲得BEC代幣獎勵。

2. 技術實現

   • 作為ERC-20代幣，運行于以太坊虛擬機（EVM），無獨立區塊鏈。

   • 代幣轉賬、發行均通過智能合約函數調用完成，賬戶余額存儲在以太坊狀態樹的存儲節點中。

---

💥?二、安全漏洞事件（2018年4月）

1. 漏洞觸發點
   關鍵函數?batchTransfer?用于批量轉賬，但未使用安全數學庫（如SafeMath），導致整數溢出漏洞：

   solidity

   uint256 amount = uint256(cnt) * _value;  // 若_value極大，乘法溢出使amount歸零

   • 攻擊者構造參數使?amount?溢出為0，僅扣除調用者極少代幣，卻向接收地址轉入巨額BEC（例：單筆轉出天文數字代幣）。

2. 攻擊結果

   • 大量BEC被憑空增發，代幣價格24小時內暴跌近100%，市值從近50億美元幾近歸零。

   • 交易所緊急暫停提幣并回滾交易，避免黑客套現。

---

🧾?三、代幣經濟與爭議

關鍵問題	詳情
代幣分配高度集中	70億總量中，前4個地址持有99.93%，普通用戶持幣量微乎其微。
無公募/私募環節	代幣直接由團隊控制，市場流通代幣來源不明，疑似團隊操縱。
與美圖公司的模糊關系	代幣名“BEC”與美圖旗下錢包“Bec”同名，蔡文勝（美圖董事長）投資了首發交易所OKEx，但美圖官方聲明“僅為海外推廣合作”。

---

???四、安全事件的行業教訓

1. 代碼審計必要性
   漏洞源于未采用SafeMath的乘法校驗（加/減函數已使用），暴露開發者對溢出風險的忽視。

2. 溢出防護實踐
   SafeMath庫通過assert(c / a == b)檢測乘法溢出，成為此后智能合約開發的標準實踐。

3. 中心化操控風險
   代幣高度集中+無透明分配機制，削弱了去中心化主張，凸顯代幣經濟模型設計缺陷。

---

💎?五、事件后續與影響

• 市場信任崩塌：BEC事件與The DAO攻擊并列，成為以太坊智能合約安全的經典反面案例。

• 監管警示：加速交易所對代幣審計的要求，推動ERC-20項目強化安全實踐（如強制第三方審計）。

• 項目結局：美鏈生態未落地，代幣歸零后團隊消失，成為“空氣幣”典型。

---

總結

美鏈（BEC）是以太坊ERC-20代幣早期泡沫化的縮影：其技術漏洞暴露了智能合約開發的安全性短板，代幣集中化揭示了項目方操控風險，而與美圖的曖昧關聯則反映市場炒作亂象。盡管其“美麗生態”愿景具創新性，但安全與管理失控終致失敗，為行業留下深刻風控啟示：代碼審計非選項而是必需，代幣分配透明是信任根基。