timezone
Asia/Shanghai

k66

自我介绍
- Hi我是k66，這是第二次參加共學，希望這次自己能踏實學習！
你认为你会完成本次残酷学习吗？
- 會！

Notes

2025.02.06

總費時: 約80分鐘

前置至Week0，主要在講EPS(Ethereum Protocol Study)在做什麼即使命，可提交一個表單 (https://docs.google.com/forms/d/e/1FAIpQLSdLASV5RqAQv6I2KzA6DcxkFHKcZw3YuL3S3uXfsWUiYRsKRg/viewform)告知EPS你想學的知識點。 EPS計畫會講比較深、不會教你Solidity語言或開發DApp，而是去介紹整個以太坊的架構。加入EPS成員還不能成為Ethereum Fellow，但鼓勵當成目標。

Week1

行前讀:
不可被destoyed and can't be shut down、公私鑰、隱私
論文Ethereum Berlin Ver: 2022-04-17
EIPs: EIP1是範例。
executions-specs和consensus-specs(github.com/executions-specs)(github.com/executions-apis) (github.com/consensus-specs)(github.com/consensus-apis)
eth2book
Ethereum歷史
設計原則：公共利益、中立、自由、敏捷、無風險等
EVM、State(data)、TXs(mempool)、p2p、JSON-RPC API、User/web3、Engine API、COnsensus Layer、Beacon API、validators的溝通
Implementatios - EL
- geth/go
- reth/rust
- ethereumjs/TS
- ...
Implementatios - CL
- ...
Testing
Other tests
- Benchmarking, Stress
- Shadow forks - live transition
- Client tests, unit testing
- CI/CD
流程: Idea->Reserch->Specs->Implementation->Testing->Adoption/Rejection
Coordination
- Dev calls (EL, CL, 4844, testnets, EOF...)
- EIPs - Eth Maicians, EIPIP, Cat herders, R&D Discord, Ethresear.ch
Scalability Trilemma不可能三角 - Scalable, Secure, Decentralized
EPF cohorts history四和三

2025.02.07

總費時: 約40分鐘

Week2

Matt講解程式碼，今天僅看了Block Validation和Block Building
- Block Validation: * err檢查 * for _, tx in range block.Transactions(){ res,err := vm.Run(block.Header(), tx, state) // 如果 transaction invalid那麼block也invalid } state = res * return state, nil
- Block Building: * gasUsed+=gas; * return (env,txs,state)
明天接著看Week2

2025.02.08

總費時: 約10分鐘

2025.02.09

總費時: 約10分鐘

Week2

承前一日繼續觀看影片
execution layer會跟consensus layer互動
EVM的組成(PC, stack,memory,gas memory,code,block context/tx context, state)

2025.02.10

總費時: 約20分鐘

Week3

今天講Consensus Layer
區塊鏈為什麼好? 因為有digital scarcity
那digital scarcity是什麼? scarcity是a user can't spend more coins than they have
那怎麼做到digital scarcity? Don't have a single trusted operator
如何remove a single trusted operator? 1. make digital system without a single leader 2. computattion is distributed across many nodes 3. Consensus 又稱state machine replication 4. 愈多節點(nodes)，就愈難被攻擊
Byzantine fault tolerance -> 與consensus protocols有一段歷史
Satoshi solves Byzantine General's Problem
POW and heaviest chain algorithm mean any node 最終會converge to same current state as any other

2025.02.11

總費時: 約30分鐘

Week3

承續前一日，week3影片，但我不太懂，想說之後回頭再看一遍。
- TODO [ ] 回頭再看一遍

Week4

講安全及測試
EVM testing: EEST(Ethereum/Execution Spec Test)
- test Filling: 皆為json files
- Pre-State 停在此
- Environment
- Transaction(s)
- Post-State

以下為明天:

共識層的測試: ethereum/consensus-specs
Cross-Layer(Interop) Testing: Hive, Devnet, Shadow-Forks, Testnets
安全: 淺在的issues, bugs

2025.02.12

總費時: 約50分鐘

Week4

承昨天
EVM testing: EEST(Ethereum/Execution Spec Test)
- test Filling: JSON/YAML files
- Pre-State 停在此
- Environment
- Transaction(s)
- Post-State: New smart-contracts, new/modeified code, modified storage
EVM testing: written in C++(我去Github看目前Python居多) github.com/ethereum/execution-spec-tests
EVM testing: [test Filling Execution Spec]](https://github.com/ethereum/execution-spec-tests): Python source code

TODO [ ] 之後回頭完成test Filling Execution Spec

src/和test/和opcodes和./fixtures:
- test/下有各hard fork
- opcodes/下的test_dup.py
- ./fixtures下
FuzzyVM, Go evmlab
Execution API: json-rpc
Consensus Layer Testing: Written in Python
Cross-Layer Testing, ethpandaops, kutosis-tech

2025.02.13

總費時: 約30分鐘 Week5

Ethereum Roadmap
The Merge: Beacon chain launch -> Warmup fork -> no nore PoW
Secret Leader Election: Protection againsr Denial of Service attacks, EIP 7441 - Whisk shuffling
Single SLot Finality: Main problem too many signatures(solutions: fewer validators, fewer active validators, way fewer validators+distributed validators tech, better signature aggregation)
Qauntum-proof Beacon Chain: solution: STARKs, 參考Vitalik文章
明天繼續19:13 Surge往下讀
今天有殘酷共學zoom meeting

2025.02.14

總費時: 約20分鐘 Week5

Surge: More date for rollups, all rollup data must be available on Layer1.
EIP4844
Execution Tickets

2025.02.15

2025.02.16

總費時: 約30分鐘

Week6

開發實戰
consensus specs, Python
共識層, 可執行, 可驗證, text vector generator
Add New Feature Patch: 實作在Pyspec md->release new Pyspec with text vector suite->CL clients實作且測試text vectors
如何讀?
- /specs/
  - _features
    - eip6110
    - ...
    - phase0
      - beacon-chain.md
      - deposit-contract.md
      - fork-choice.md
      - p2p-interface.md
      - validaotr.md
      - weak-subjectivity.md
如何理解CL?
- https://github.com/ethereum/annotated-spec
- https://eth2book.info
The elf in setup.py
Extend the previous hard forks
- bellatrix/beacon-chain.md }
- altair/beacon-chain.md } --> SpecBulder (transform .md to .py files) --> Bellarix/Altair beacon chain spec
- phase0/beacon-chain.md }
如何使用Pyspec?
- TODO [ ] contribute to pyspec

2025.02.17

總費時: 約60分鐘

Protocol Intro，再讀一次
論文<<Ethereum: A SECURE DECENTRALISED GENERALISED TRANSACTION LEDGER BERLIN VERSION 934279c - 2022-04-07>>, by Gavin Wood
架構
共識層的RANDAO實作　(重點在於XOR運算)

import random

def generate_random_hex():
    """產生隨機16進位數"""
    return hex(random.getrandbits(16))  # 16位元隨機數

def randao_simulation(num_proposers):
    """簡易RANDAO模擬"""
    R = 0x0000  # 初始RANDAO值
    print(f"初始RANDAO值: {hex(R)}\n")

    for i in range(1, num_proposers + 1):
        proposer_random = int(generate_random_hex(), 16)
        print(f"提議者 {i} 的隨機數: {hex(proposer_random)}")

        R = R ^ proposer_random  # XOR 運算更新 RANDAO 值 <----精華！
        print(f"第 {i} 次 XOR 後的 RANDAO: {hex(R)}\n")

    return R

if __name__ == "__main__":
    num_proposers = 5  # 假設有 5 位提議者
    final_random = randao_simulation(num_proposers)
    print(f"最終的 RANDAO 隨機數: {hex(final_random)}")

2025.02.18

總費時: 約30分鐘

共識層，第二遍
scarcity: 表示不鼓勵攻擊
將系統打造成無須single leader

Practical Byzantine fault tolerance

Pre-prepare：領頭人（Primary）提出提案，並廣播給其他副本（Replicas）。
Prepare：副本們收到提案後，相互交換認可訊息（Prepare messages）。
Commit：若達到一定數量（超過 2f）同意，副本才會進入 Commit 階段，最終確認並應用提案。

f 表示系統可容忍的拜占庭錯誤節點數量。通常我們會佈建 3f+1 個節點，來保證最多 f 個是壞人或故障的情況下，整個系統仍能達成共識。

class Network:
  def __init__(self, nodes, byzantine_rate=0.0, drop_rate=0.0):
      """
      nodes: List of Node 物件
      byzantine_rate: 篡改訊息的機率 (0 ~ 1)
      drop_rate: 直接丟棄訊息的機率 (0 ~ 1)
      """
      self.nodes = nodes
      self.byzantine_rate = byzantine_rate
      self.drop_rate = drop_rate

  def broadcast(self, sender_id, message):
      # 對所有節點廣播（包含自己以外的節點）
      for node in self.nodes:
          if node.node_id == sender_id:
              continue
          
          # 機率丟棄
          if random.random() < self.drop_rate:
              continue
          
          # 機率拜占庭篡改
          tampered_message = message.copy()
          if random.random() < self.byzantine_rate:
              # 這裡隨便亂改 value 讓人混亂
              tampered_message['value'] = f"Malicious-{tampered_message['value']}"
          
          node.receive_message(tampered_message, self)
    def run_pbft_demo():
  f = 1
  total_nodes = 3 * f + 1  # 4
  
  # 建立節點
  nodes = [Node(i, total_nodes, f) for i in range(total_nodes)]
  
  # 建立網路 (可調整 byzantine_rate、drop_rate 來測試)
  network = Network(nodes, byzantine_rate=0.2, drop_rate=0.1)
  
  # 假設我們的 Primary（node_id=0）要提出提案 "Block#1"
  primary_node = nodes[0]
  proposal_value = "Block#1"
  
  print(f"Primary Node {primary_node.node_id} 廣播提案：{proposal_value}")
  primary_node._broadcast_pre_prepare(proposal_value, network)

  # 簡單地等一下看傳播結果
  # 在真正系統裡，這會是事件驅動或不斷輪詢
  for _ in range(5):
      pass  # 這裡沒做什麼，只是讓 receive_message() 都有機會執行完

  # 看結果
  for node in nodes:
      print(f"Node {node.node_id}: committed={node.committed}, value={node.current_value}")
  
  # 直接跑一下示範
  if __name__ == "__main__":
      run_pbft_demo()

2025.02.19

總費時: 約30分鐘

原https://epf.wiki/#/eps/intro連結有誤(Feb19的連結)
執行層，第二遍
從beacon到EVM到p2p都再看一遍
題外話，今天參加JAM(自己多學了L0)，也參考JAM的設計概念
- 優點: 天然的並行處理
  - 將不同應用的計算結果聚合，再一次性提交，減少交易處理負擔
  - 沒有區塊時間限制，交易處理可以持續累積，而不是等到固定的出塊時間
- 缺點: 太新
  - 應用場景不多、官方雖強調有35種程式語言，但我認為不支援EVM這點很虧(DApp項目方搬過去的意願可能會低落)
  - 經濟模型不明

2025.02.20

總費時: 約30分鐘

拜占庭容錯(多數決、重複確認、忽略惡意節點)
- 若惡意節點比普通節點來得多呢?
  - PoW -> 變很貴 -> 變難 (ETH1.0)
  - PoS -> 隨機選 (ETH2.0)
  - 多層次或分散式網路
PoS全惡意節點怎辦?
- Slashing
- 分散代幣持有
- 社群可Hard Fork
Nonce是什麼?
- 交易的Nonce
  - 防止Replay Attack
  - 確保交易順序
- 礦工的Nonce
  - PoW
  - 礦工完成驗證並得到獎勵
EVM是什麼?
- 執行智能合約
- 管理交易&狀態變更
- 計算Gas費用
EVM執行
- 交易進入網路 -> 交易被打包進區塊 -> EVM解析交易 -> 狀態更新 -> 交易完成&區塊確認
EVM Opcode
- PUSH1, ADD, MSTORE, SSTORE, CALL
Gas
- ADD(3 Gas), MSTORE(3 Gas), SSTORE(20,000), CALL(700 Gas)
EVM Client程式語言
- Geth, Nethermind, Besu, Reth
EVM怎麼運作?
- Bob用MetaMask錢包轉1顆ETH給Alice
- Bob的交易會傳送給全世界運行EVM軟體的電腦(節點)
- PoS，Staker會驗證交易是否合法
- 交易寫入區塊鏈 -> Alice收到1顆ETH，交易完成

2025.02.21

總費時: 約30分鐘

原網址錯，已去提issue: https://epf.wiki/#/eps/week5p -> https://epf.wiki/#/eps/week5
Roadmap第二次聽
Vitalik把升級過程拆成以下階段:
- Merge: PoW到PoS
- Surge: sharding提高交易速度、降低Gas Fee
- Scourge: Ethereum對抗MEV，目標減少MEV對網路的影響，讓交易排序更公平
- Verge: Verkle tree，讓節點同步更輕量(讓驗證節點負擔變小、降低心結點加入門檻)、提高網路去中心化程度。
- Purge: 簡化Ethereum狀態，減少歷史數據存儲
- Splurge: 一切完成後額外升級。EIP48944是其中一部分。

2025.02.22

總費時: 約20分鐘

EL & CL 第二次(by Hsiao-Wei, host: Josh, Mario)
安裝和執行:
TODO: 遇到make後有問題，明天再解

2025.02.23

總費時: 約20分鐘

以下為安裝&執行第一支pyspec程式
承昨天，解決make test問題(影片16'54"寫make install_test但事實上我到github只有make test，install_test可能是之前版本的)
安裝時遇到報錯

No module named uv
make: *** [Makefile:76: pyspec] Error 1

解法:

pip install uvicorn # 裝uvicorn還不是uv，昨天我卡在此
python -m uvicorn main:app --reload

跑test有點費CPU、記憶體效能

(i7-4代、16G DDR3、windows11開WSL2)

2025.02.24

總費時: 約50分鐘

EL(執行層)&CL(共識層)
- EL: 負責處理交易與智能合約執行，管理狀態(帳戶餘額、智能合約狀態)並打包區塊。
- CL: 負責區塊驗證與共識機制(PoS, 提名驗證等)，確保網路安全與一致性。
pyspec test: yield 'pre', state -> yeild 'blocks', [signed_block] -> yield 'post', state
講師建議想貢獻可從pyspec開始
黃皮書(Yellow Paper) 2014 建立by Gavin Wood
Yellow Paper有蠻多缺點->所以改用eels
eels 缺點: 須懂python, verbose
eels 優點: more verbose but easy to understand
Core EIP: Python-style psuedocode, Not it can be actual Python
sync in chain, Passes the ethereum/tests
範例: https://github.com/ethereum/execution-specs/tree/forks/cancun
- 執行arithmetic.py

2025.02.25

總費時: 約60分鐘

執行層架構(by dragonrakita, host: Josh, Mario)
why reth? A: 更快(比起Geth)、更安全(避免記憶體漏洞)
dragonrakita分享，他是REVM維護者
0.1.0-alpha1->0.2.0beta.4
cancun shipped
Reth是由Paradigm開發的EL(以太坊執行層)客戶端，用Rust編寫。目的高效且安全、取代Geth(Go-Ethereum)這類EL。
Reth專注在EL、非CL。
rough component flow
1. Enigine啟動: 是核心，穢語jsonrpc、revm、consensus互動。
2. 交易區塊的處理
  - PayloadBulder: 建立交易打包(payload)給區塊使用。
  - TxPool是管理已接受到但尚未被打包進區塊的交易，Ethereum的DoS保護。
3. 區塊同步與儲存
  - Pinpeline: 處理2種狀態，同步與下載，讓節點保持最新狀態。
  - Downloader: 從其他節點下載區塊與交易資料。
  - Provider: 管理資料存取，確保節點能查詢區塊與交易歷史。
4. 區塊鏈結構管理
  - BlockchainTree: 更靠近末端，管理鏈的不同分支(forks)
  - database: 儲存完整的區塊、交易及數據狀態。
5. 網路通訊
  - p2p: 負責節點之間的通訊，例如同步區塊、交易廣播等。

2025.02.26

總費時: 約60分鐘

承昨天執行層影片
Q:同步有什麼區別? 歷史同步就是同步歷史已驗證的區塊、實時同步是自共識層的區塊
看reth程式碼: evm.rs, start-loop, send-loop
repo內有些東西不用可以被刪掉 <-- 可能可以貢獻處
共識層架構 by Paul(共識層的Senior Staff), hort(Josh, Mario)
共識層的drivers
- Consensus-spec
- Execution-api: 和執行層的介面
- Standard REST API's (beacon-api, keymanager-api, builder-api)
- CLient team direction (e.g. Teku)
Teku
- Teku想成為client choice
- Wriutten in Java
- Fairly extensive metrics
- Focus on testing (unit, intergration, system)
- TODO:明天延續

2025.02.27

總費時: 約50分鐘

週會可能要分享，先弄個測試
make test會跑超久(如果報錯可參考我02.23筆記)

先理解Phase0(ETH2.0開始), Altair, Bellatrix(The Merge), Capella, Deneb, Electra(開發中), Fulu(開發中)

hello_beacon.py(影片範例，基於Bellatrix(The Merge)版本)

程式碼

from eth2spec.bellatrix import mainnet as spec # 使用的是 Bellatrix 版本的共識規範（Ethereum Consensus Spec）
hello = b"Hello World" # b: btye string，graffiti需以32bytes儲存
body = spec.BeaconBlockBody(
    graffiti=hello + b'\0' * (32 - len(hello)) # 補齊長度至32bytes，長度不足就補b`\0`(NULL bytes)
)
block = spec.BeaconBlock(body=body)
print(block.body.graffiti.decode("utf-8")) # 轉成人類看得懂的字串

執行結果

test_hello_beacon.py

程式碼

  @with_all_phases
  @spec_state_test
  def test_empty_block_transition(spec, state):
      pre_slot = state.slot
      pre_eth1_votes = len(state.eth1_data_votes)
      pre_mix = spec.get_randao_mix(state, spec.get_current_epoch(state))
  
      yield 'pre', state  # 記錄測試前的狀態
  
      # 📌 準備下一個 slot 的空區塊
      block = build_empty_block_for_next_slot(spec, state)
      signed_block = state_transition_and_sign_block(spec, state, block)
  
      yield 'blocks', [signed_block]  # 記錄區塊
  
      yield 'post', state  # 記錄測試後的狀態
  
      # ✅ 進行測試驗證
      assert len(state.eth1_data_votes) == pre_eth1_votes + 1
      assert spec.get_block_root_at_slot(state, pre_slot) == signed_block.message.parent_root
      assert spec.get_randao_mix(state, spec.get_current_epoch(state)) != pre_mix

執行結果

How to貢獻至pyspec?

2025.02.28

總費時: 約30分鐘

昨天共學的線上分享，Chloe分享的ephemery測試網試跑(聽說這比較輕量)
裝ephemery需先裝geth和lighthouse(信標鏈客戶端，我用Rust裝)

2025.03.01

總費時: 約30分鐘

Verkle
動機
- zk-friendly L1
  - remove complex data-structure(MPT)
  - remove heavy use of non-zk-friendly hashes
Merkle Patricia Tree->Verkle Tree
Verkle Tree = Vector Commitment + Merkle Tree
EIP 6800

2025.03.02

總費時: 約30分鐘

研究roadmap

The Merge（合併）
- ✅ 已完成：合併（Merge）、權益證明共識（Beacon Chain）。
- 🔜 未來計劃：提高去中心化（增加驗證者數量）。增強抗量子攻擊能力（理想量子安全簽名）。
The Surge（擴展）
- 🛠 開發中:
  - EIP-4844（Proto-Danksharding）：降低 L2 交易成本，提高 Rollup 效能。
  - Optimistic Rollup / ZK-EVMs：擴大 Rollup 應用，提高交易速度。
- 🔜 未來計劃：
  - 全面推動 Rollup Scaling。
  - 去信任驗證（No training wheels），讓 Rollup 不再依賴中心化驗證者。
The Scourge（防範中心化）
- 🛠 進行中的研究：
  - MEV 緩解機制（Extra MEV protection markets）。
  - PBS（Proposer-Builder Separation）：防止驗證者操縱區塊排序。
  - 分散式區塊建構（Distributed block building）。
- 🔜 未來計劃：
  - 最小化 MEV 損害（Age-layer MEV minimization）。
  - 探索去信任執行市場（Explore execution markets）。
The Verge（驗證簡化）
- ✅ 已解決大部分 EVM 狀態問題。
- 🛠 進行中的研究：
  - SNARK / STARK 技術：讓驗證變得更快、更高效。
  - Verkle Trees：提升區塊鏈的狀態存儲效率。
- 🔜 未來計劃：
  - EVM 驗證簡化（Fully SNARKed Ethereum）。
  - 抗量子 SNARKs（Quantum-safe SNARKs）。
The Purge（清理技術債務）

✅ 已完成：
- EIP-4444（歷史數據存儲簡化）。
- Ban SELFDESTRUCT（禁用 SELFDESTRUCT 指令）。
🔜 未來計劃：
- 減少存儲需求（State expiry）。
- 移除舊 LOG 類型（LOG reform）。
- 序列化統一（Serialization harmonization）。

The Splurge（修正所有問題）
- ✅ 已完成：
  - EIP-1559（改進交易費機制）。
  - EIP-4337（帳戶抽象）。
- 🔜 未來計劃：
  - 進一步提升 EVM 效能（EOF、EVM improvements）。
  - 最終端記憶體回收（Endgame deterministic mempools）。
  - 更好的隨機數（VDFs）。

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

k66.md

k66.md

k66

Notes

2025.02.06

2025.02.07

2025.02.08

2025.02.09

2025.02.10

2025.02.11

2025.02.12

2025.02.13

2025.02.14

2025.02.15

2025.02.16

2025.02.17

2025.02.18

2025.02.19

2025.02.20

2025.02.21

2025.02.22

2025.02.23

2025.02.24

2025.02.25

2025.02.26

2025.02.27

2025.02.28

2025.03.01

2025.03.02

Files

k66.md

Latest commit

History

k66.md

File metadata and controls

k66

Notes

2025.02.06

2025.02.07

2025.02.08

2025.02.09

2025.02.10

2025.02.11

2025.02.12

2025.02.13

2025.02.14

2025.02.15

2025.02.16

2025.02.17

2025.02.18

2025.02.19

2025.02.20

2025.02.21

2025.02.22

2025.02.23

2025.02.24

2025.02.25

2025.02.26

2025.02.27

2025.02.28

2025.03.01

2025.03.02