diff --git a/CHENFANGC.md b/CHENFANGC.md
index 155d857..7f57369 100644
--- a/CHENFANGC.md
+++ b/CHENFANGC.md
@@ -185,4 +185,8 @@ EOA 可以发起交易,交易类型包括:
- week 2 视频观看完成,深入研究以太坊的执行层。深入探讨 Lightclient 的 EL 内部结构。
- 阅读了关于 EVM 的一些介绍。https://www.evm.codes/about
+### 2025.02.14
+
+观看 [Town Hall 的回放](https://youtu.be/7L1270CWjXw)
+
diff --git a/Coooder-Crypto.md b/Coooder-Crypto.md
index 21a5324..111534f 100644
--- a/Coooder-Crypto.md
+++ b/Coooder-Crypto.md
@@ -186,4 +186,126 @@ timezone: Asia/Shanghai
https://epf.wiki/#/wiki/EL/block-production 这里的代码实例都点进去大概看了下
然后看了数据结构、交易、RPC 相关的内容。这些东西之前都有简单了解过,这次相对系统地重新学习了一下。感觉整体的理解更深了。收获很多!
+
+### 2025.02.11
+
+## 今天做了什么
+1. 看完了共识层的介绍部分
+
+### 共识层概述
+共识协议的主要目标是构建一个在不可靠基础设施上运行的可靠分布式系统。以太坊的共识层旨在确保全球数万个独立节点保持同步,所有节点的账本状态必须完全一致。
+
+#### 拜占庭容错 (BFT)
+拜占庭容错是分布式系统的一种特性,即使部分组件失效或恶意行为,系统仍能正常运行。这在去中心化网络中尤为重要。
+
+#### 工作量证明 (PoW) 和权益证明 (PoS)
+PoW 和 PoS 并非共识协议,而是支持共识协议的机制,主要用于防止女巫攻击。
+PoW 通过计算工作量来赋予区块链权重,而 PoS 则通过质押的价值来赋予权重。
+以太坊的 PoS 转型
+以太坊在 2022 年 9 月 15 日完成了从 PoW 到 PoS 的转型(称为“合并”)。
+**Beacon Chain(信标链)**成为新的共识层,负责处理区块和验证者的管理。
+PoS 的优点包括更高的能源效率和可扩展性。
+
+#### 信标链和验证者
+验证者:通过质押至少 32 ETH 成为验证者,负责提议和验证区块。
+插槽和纪元:每个插槽为 12 秒,每 32 个插槽组成一个纪元。
+委员会:验证者被分组到委员会中,确保验证过程的去中心化和安全性。
+
+#### 奖励与惩罚
+验证者通过正确的投票和行为获得奖励。
+不活跃或恶意行为会导致罚款,严重违规(如双重提议)会被削减质押(Slashing)。
+
+#### 最终性和检查点
+每个纪元结束时生成检查点,获得 2/3 超级多数投票的检查点会被“最终化”,确保区块链状态不可逆。
+
+#### 以太坊的未来
+信标链的引入为以太坊提供了更高的可扩展性和去中心化能力,目前已有超过 100 万个活跃验证者。
+
+
+### 2025.02.12
+
+## 今天做了什么
+1. 看完了客户端结构部分
+
+### 以太坊共识层架构
+以太坊的共识协议结合了两个独立的共识协议:LMD GHOST 和 Casper FFG,它们共同被称为 Gasper。
+
+#### Gasper 的作用
+LMD GHOST 提供了活性(liveness),确保链能够持续运行并定期生成新区块。然而,它容易出现分叉,并且在形式上并不完全安全。
+Casper FFG 提供了安全性(safety),通过定期最终确定(finalize)区块链,防止长时间的链回滚。
+通过结合这两种协议,Gasper 实现了以太坊的共识机制:
+
+LMD GHOST 确保链条不断向前推进。
+Casper FFG 确保链条的稳定性,通过最终确定区块来保护链条。
+这种组合使以太坊在网络条件良好的情况下,既能保持活性又能保证安全性。然而,在网络分区等极端情况下,以太坊更倾向于优先保证活性,即链条继续增长,即使可能会在安全性上出现问题。
+
+#### 共识层的主要组件
+##### 信标节点(Beacon Node):
+使用客户端软件来协调以太坊的权益证明(Proof-of-Stake)共识。
+示例客户端包括 Prysm、Teku、Lighthouse 和 Nimbus。
+信标节点与其他信标节点、本地执行节点以及本地验证器通信。
+
+##### 验证器(Validator):
+验证器客户端是允许用户在以太坊共识层中质押 32 ETH 的软件。
+验证器在权益证明系统中提议区块,取代了工作量证明中的矿工。
+验证器仅与本地信标节点通信,信标节点会指导验证器并将其工作广播到网络中。
+
+#### 共识层的职责
+维护共识链(信标链):处理从其他节点接收到的共识区块(信标区块)和证明(attestations)。
+与执行层(EL)通信:共识客户端通过本地 RPC 连接(Engine-API)与执行客户端通信。
+共识客户端向执行客户端提供指令。
+执行客户端将交易捆绑成交易包并传递给共识客户端,以包含在信标区块中。
+
+### 状态转换
+在区块链中,状态转换函数是核心。每个节点维护一个状态,反映其对世界的看法。通过应用区块,节点更新其状态。
+
+#### 信标链的状态转换:
+信标链是基于插槽(slot)驱动的,而非区块驱动。
+状态更新取决于插槽的进展,而不依赖于区块的存在。
+状态转换包括:
+
+每插槽转换:更新插槽状态。
+每区块转换:处理区块并更新状态。
+每纪元转换:在每个纪元开始时进行状态更新。
+
+#### 安全性与活性
+安全性:确保“坏事永远不会发生”,例如防止双花或最终确定冲突的检查点。
+活性:确保“好事最终会发生”,即区块链能够持续添加新区块,不会陷入死锁。
+
+以太坊的共识协议在良好的网络条件下,力求同时提供安全性和活性。然而,在网络分区等情况下,以太坊更倾向于优先保证活性,即链条继续增长,即使可能会在安全性上出现问题。
+
+
+### 2025.02.13
+
+## 今天做了什么
+1. 看完了客户端结构部分
+
+### 弱主观性
+在信息理论和区块链的背景下,“客观性”和“主观性”有着不同的定义:
+- 客观性:如果一条信息的正确性可以完全验证,则它是客观的。
+- 主观性:如果一条信息的正确性无法完全验证(需要一定程度的信任),则它是主观的。
+在以太坊合并(The Merge)之前,客户端可以通过从创世区块开始验证每个区块的历史,从而客观地验证整个区块链的正确性。然而,合并后,以太坊引入了新的共识机制(权益证明,Proof-of-Stake),并将共识层(CL)与执行层(EL)逻辑上分离。这种变化使得基于创世区块的同步变得“不安全”,从而引入了“弱主观性”。
+
+#### 弱主观性中的同步
+在弱主观性中,同步机制与传统的全节点同步有以下几个主要区别:
+
+##### 同步方向的改变
+在信标链(Beacon Chain)中,同步方向被反转。节点从弱主观性检查点开始回填区块,直到创世区块,而不是从创世区块向前同步。
+
+##### 信任锚点的主观性
+由于链的历史在某些条件下可能被更改,同步目标(即弱主观性检查点)无法被完全客观验证。因此,同步目标需要通过可信渠道(如离线方式)共享,而不是通过以太坊的点对点网络。
+
+##### 时间因素的影响
+如果节点长时间未同步,可能会受到攻击(例如,足够多的验证者退出并重新投票以创建分叉历史)。这种时间窗口被称为“弱主观性周期”。如果同步时间过长,目标检查点可能会变得过时。
+
+#### 弱主观性同步的步骤
+- 从可信渠道获取弱主观性检查点。
+- 从检查点回填区块至创世区块。
+- 更新执行链的目标头部。
+- 乐观地跟随链的最新头部,同时持续更新目标头部。
+- 执行层完成同步后,验证共识层的插槽,节点即可被视为完全同步。
+
+## 一些想法
+这两天被一个专利折磨坏了hhh,打卡过了这些内容,但是扩展的是一点没看,总算搞的差不多了,明天把错过的两次会议回看下~
+
diff --git a/Echocipher.md b/Echocipher.md
index 67450ca..b305e99 100644
--- a/Echocipher.md
+++ b/Echocipher.md
@@ -25,4 +25,32 @@ Yes!!!
5. 以太坊建立了成熟的生态系统:De-FI
6. 更好的节点硬件=更好的以太坊性能。
+### 2025.02.14
+
+#### 区块链定义
+
+通过多个区块组成链条,每个区块包含一组交易信息,并与前一个区块通过Hash进行连接,该链条被保存在所有分布式网络的节点,只要有一个节点可以工作,整个区块链数据就是安全的。
+要想修改区块链中的信息,必须半数以上的节点同意
+相比传统网络,区块链核心特点为:数据难以篡改,去中心化
+
+#### 区块链工作流程
+
+1. 创建交易
+2. 交易验证
+3. 交易打包成区块
+4. 区块广播
+
+共识机制:解决分布式的节点之间怎么达成共识的问题,各个区块链平台都有一个节点共同遵守的算法协议,这便是共识机制。常见的共识机制有比特币所使用的 POW(工作量证明)、以太坊使用的POS(权益证明)
+
+工作量证明(PoW):矿工节点通过解决复杂的数学问题来竞争区块的添加权,解决问题最快的节点将区块添加到区块链中,并获得比特币奖励
+权益证明(PoS):PoS 有很多变种,在 Pos 中,质押一定数量的代币可成为验证者,网络通过一定的随机算法从验证者中选出出块的验证者
+
+#### 区块链解决问题
+
+1. 中心化控制问题
+2. 隐私和数据安全问题
+3. 高昂的中介成本
+4. 缺乏透明度
+5. 内容审查和限制
+
diff --git a/JeasonZhang.md b/JeasonZhang.md
index 32f9025..9464574 100644
--- a/JeasonZhang.md
+++ b/JeasonZhang.md
@@ -706,6 +706,92 @@ docker run -d -p 9000:9000 -p 9001:9001 -v /data/lighthouse:/root/.lighthouse \
### 2025.02.13
-##### **EPF WIKI WEEK6**
+##### **EPF WIKI WEEK6: Consensus and Execution spec**
+
+#### **I. 核心学习目标**
+
+**主题**: 共识层与执行层技术规范深度解析
+**目标**: 掌握规范实现原理,参与协议改进提案(EIP)开发。
+
+------
+
+#### **II. 课程大纲重点**
+
+##### **1. 共识层规范(CL Specs)**
+
+- Gasper协议实现:
+ - 结合LMD-GHOST分叉选择规则与Casper FFG最终性机制
+ - 状态转换逻辑:见证打包、检查点证明、验证者奖惩
+- Python参考实现:
+ - [共识层规范代码库](https://github.com/ethereum/consensus-specs)
+ - 测试框架:通过`pytest`验证区块生成与状态转换
+- 关键测试场景:
+ - 分叉场景模拟(7节点网络测试)
+ - 罚没条件触发验证(双重签名检测)
+
+##### **2. 执行层规范(EELS)**
+
+- EVM对象格式(EOF):
+ - 分离代码与数据段,优化合约存储结构
+ - 支持版本化合约部署(向后兼容)
+- 操作码扩展实践:
+ - 在[execution-specs](https://github.com/ethereum/execution-specs)中添加自定义操作码
+ - 生成一致性测试向量(JSON测试用例)
+- 黄皮书对照:
+ - 状态转换函数的数学形式化验证
+ - Gas计算模型与预编译合约实现
+
+------
+
+#### **III. 关键学习资源**
+
+##### **必读材料**:
+
+- [EELS规范解析](https://blog.ethereum.org/2023/08/29/eel-spec):执行层演进逻辑
+- [Vitalik注释版规范](https://github.com/ethereum/annotated-spec):协议设计思想解读
+
+##### **实践指南**:
+
+- 共识层开发:
+
+ ```python
+ # 测试分叉场景
+ def test_multiple_forks():
+ genesis_state = initialize_beacon_state()
+ fork1_blocks = generate_alt_chain(genesis_state, length=3)
+ fork2_blocks = generate_alt_chain(genesis_state, length=5)
+ assert get_head(fork1_blocks) != get_head(fork2_blocks)
+ ```
+
+- 执行层扩展:
+
+ - 修改`src/ethereum/[frontier|homestead]/vm/opcodes.py`
+ - 在`tests/[frontier|homestead]/test_opcodes.py`添加测试
+
+------
+
+#### **IV. 技术术语对照**
+
+| 英文术语 | 中文解释 |
+| -------------------- | ---------------------- |
+| LMD-GHOST | 最新消息驱动的最重子树 |
+| Casper FFG | 友好最终性小工具 |
+| EOF | EVM对象格式 |
+| Precompiled Contract | 预编译合约 |
+
+------
+
+#### **V. 实践建议**
+
+1. **共识层实验**:
+ - 修改`beacon-chain.md`中的`process_attestation`逻辑
+ - 运行`make test`验证状态转换正确性
+2. **执行层扩展**:
+ - 添加`OP_CALLDATA`操作码实现数据直接访问
+ - 生成并提交EIP草案至[EIPs仓库](https://github.com/ethereum/EIPs)
+
+------
+
+通过本课程的系统学习,开发者将具备直接参与以太坊核心协议开发的能力。建议结合[Eth2 Book](https://eth2book.info)深化共识层知识,通过[黄皮书教程](https://ethereum.org/en/developers/tutorials/yellow-paper-evm/)理解EVM底层原理。
diff --git a/LouisTsai-Csie.md b/LouisTsai-Csie.md
index 84bf108..bfd7211 100644
--- a/LouisTsai-Csie.md
+++ b/LouisTsai-Csie.md
@@ -31,4 +31,7 @@ Today, start learning some fundamentals for Pectra's next upgrade, which will in
### 2025.02.10
Watching the video for introducing the EOF and some examples in the update: https://www.youtube.com/watch?v=WKVgCoNp39g.
+### 2025.02.13
+Watch this video to learn stack validation algorithm in EOF upgrade: https://www.youtube.com/watch?v=80szRrNW0MM It is hard to learn purely from EIP, but the video demonstration is clear.
+
diff --git a/Lvista.md b/Lvista.md
index 6636950..c140958 100644
--- a/Lvista.md
+++ b/Lvista.md
@@ -359,4 +359,19 @@ a committee, [with each person randomly sitting in power](# "随机坐庄").
### 2025.02.13
+#### Stakers and Validators
+
+1. Stakers(质押者):
+ Stakers like "capitalist", wich mean those who holding "money".
+ - Everyone can become a staker.
+ - If you have ETH over 32, such as 55, you can stake all, the part of 32 is to activate one validator,
+ and the remain is to activate another one. Of course, you will get the all reward from the 32-voted one,
+ and get the part from the another one.
+ - If you have ETH less than 32, you can also stake into a pool to activate a validator and get the part
+ reward.
+2. Validators(验证者):
+ The only requirement to become a validator is the certain "money"(ETH)
+ - You should become a staker before validator(Means that holding ETH in fact)
+
+### 2025.02.14
diff --git a/PubYuCHe.md b/PubYuCHe.md
index 828b29b..dc451b8 100644
--- a/PubYuCHe.md
+++ b/PubYuCHe.md
@@ -90,6 +90,75 @@ Process 函數:
狀態轉移機制: Geth 使用 state_processor 來完成狀態轉移。這個過程將每筆交易依次執行,更新狀態資料庫,並計算出新的狀態。
後續更新: 當所有交易都處理完畢後,系統會更新其他關鍵指標,最終把區塊的最終狀態寫入區塊鏈,確保區塊成為鏈上歷史的一部分。
-### 2025.02.12
+### 2025.02.13
+
+Digital scarcity
+區塊鏈創造了一種製造數位稀缺性的方法,這在以前是難以實現的。
+因此,數位稀缺性的這個特性可以用於在數位領域模擬各種實體資產,例如:貨幣、代幣、產權等等。
+
+製造數位稀缺性的方法:創建具有稀缺性的數位貨幣的示例
+目標: 創建具有稀缺性的數位貨幣
+單位: 代幣 (Coins)
+稀缺性: 任何時候都只有 N 個代幣。並且用戶不能花費超過他們擁有的代幣。
+需要移除單一信任營運商並最小化信任。
+在任何時間點,即使有一些節點輸出錯誤,只要大多數節點對輸出狀態有相同的看法,協議就可以達成共識並繼續運行。
+
+Byzantine fault tolerance
+分散式網路處理拜占庭容錯(BFT)。
+如果更多節點帶來更高的安全性,那麼我們會希望擁有更多的節點。然而,在開放和分散式的系統中,節點可能存在問題(例如:硬體故障、訊息遺失、錯誤、攻擊等),這會導致與共識不同的錯誤輸出。
+拜占庭容錯(BFT)是一個系統的屬性,它能夠抵抗源自拜占庭將軍問題的故障類別。這意味著即使一些節點發生故障或惡意行為,BFT 系統也能夠繼續運行。
+因此,我們需要有一定的容錯能力,使系統能夠持續運行。
+
+Bitcoin 實BFT
+比特幣被認為是第一個解決拜占庭將軍問題的方案。
+該系統可以擴展到無限的節點數量。
+開放和無需許可的參與。
+使用 PoW 機制來達成共識(Bitcoin)
+
+比特幣的狀態機複製
+輸入: 交易 (Tx)(組織在區塊中),用於花費比特幣。
+輸出: 比特幣賬本的當前狀態。
+使用密碼學來減少可能的狀態空間
+數位簽章: 使用密碼學來驗證交易的真實性。
+父哈希: 每個新區塊都必須包含前一個區塊的哈希值。
+
+以太坊從 PoW 轉向 PoS
+PoW -> PoS 的本質
+從女巫攻擊保護的外生信號(工作量)轉變為系統內的內生信號(權益)。
+
+背後的考量
+1. 對 PoW 的能源使用擔憂。
+2. 對 PoW 的激勵擔憂:與 PoW 相比,PoS 的協議內信號允許懲罰和獎勵。
+以太坊共識機制
+驗證者 (Validators): 協議內共識參與者。
+- 成為共識驗證者
+- 用戶需要鎖定 32 個 ETH 並將其發送到 EVM 中的存款合約,這將在 CL 層(共識層)中被看到。
+責任
+- 進行證明 (attestation): 即驗證者對鏈的狀態進行密碼學簽名。
+不同類型的證明
+ - LMD GHOST 投票: 驗證者證明信標鏈的頭部 (beacon chain head)。
+ - Casper FFG 投票: 驗證者證明當前 epoch 中的檢查點 (checkpoint)。
+
+關鍵概念
+1. Slot (槽位)
+ 每 12 秒鐘會產生一個新的槽位,每個槽位都會有一個區塊。
+在每個槽位內,它被分為 3 個階段,每個階段消耗 4 秒。而一個槽位中最關鍵的時刻是在 t=4 秒時的證明 (attestation) 截止時間。(Paradigm 博客)
+
+3. Epoch (時代/紀元)
+ 每個時代 (epoch) 有 32 個槽位。創建時代背後的原因是為了降低共識處理的頻率,這樣就不需要在每個槽位都發生共識處理。
+較重的處理通常在時代邊界完成,包括:罰沒 (slashing)、獎勵資訊等。
+時代邊界區塊 (Epoch Boundary Blocks, EBB) 也可以被認為與檢查點 (checkpoints) 同義。(The Beacon Chain Ethereum 2.0 explainer)
+
+4. Committee (委員會)
+網路內的驗證者將被隨機分配到不同的委員會中。
+每個驗證者在每個時代 (epoch) 會進行一次證明 (attestation)。驗證者被分配到的確切槽位是由協議通過 RANDAO 決定的。
+
+5. Finality (最終性)
+最終性意味著一筆交易 (tx) 是一個區塊的一部分,而這個區塊是不可更改的。
+Justification (驗證/確認): 當一個時代 (epoch) 結束時,如果其檢查點 (checkpoint) 收集了 2/3 超過三分之二的多數投票,則該檢查點將被驗證 (justified)。
+Finality (最終性): 當一個檢查點 (checkpoint) 被驗證 (justified) 時,前一個已經被驗證 (justified) 的檢查點就變成最終的 (finalized)。
+
+
+### 2025.02.14
diff --git a/README.md b/README.md
index 2ce426d..1670754 100644
--- a/README.md
+++ b/README.md
@@ -101,92 +101,92 @@ Telegram:https://t.me/ETHPandaOrg/5427
| Name | 2.06 | 2.07 | 2.08 | 2.09 | 2.10 | 2.11 | 2.12 | 2.13 | 2.14 | 2.15 | 2.16 | 2.17 | 2.18 | 2.19 | 2.20 | 2.21 | 2.22 | 2.23 | 2.24 | 2.25 | 2.26 | 2.27 | 2.28 | 3.01 | 3.02 |
| ------------- | ---- | ---- | ---- | ---- | ---- | ---- | ---- | ---- | ---- | ---- | ---- | ---- | ---- | ---- | ---- | ---- | ---- | ---- | ---- | ---- | ---- | ---- | ---- | ---- | ---- |
-| [brucexu-eth](https://github.com/IntensiveCoLearning/Ethereum-Protocol-Fellowship/blob/main/brucexu-eth.md) | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | | | | | | | | | | | | | | | | | |
-| [PayFv](https://github.com/IntensiveCoLearning/Ethereum-Protocol-Fellowship/blob/main/PayFv.md) | ⭕️ | ✅ | ✅ | ⭕️ | ✅ | ⭕️ | ⭕️ | | | | | | | | | | | | | | | | | | |
-| [chloezhu010](https://github.com/IntensiveCoLearning/Ethereum-Protocol-Fellowship/blob/main/chloezhu010.md) | ✅ | ✅ | ⭕️ | ⭕️ | ✅ | ✅ | ✅ | | | | | | | | | | | | | | | | | | |
+| [brucexu-eth](https://github.com/IntensiveCoLearning/Ethereum-Protocol-Fellowship/blob/main/brucexu-eth.md) | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ⭕️ | | | | | | | | | | | | | | | | |
+| [PayFv](https://github.com/IntensiveCoLearning/Ethereum-Protocol-Fellowship/blob/main/PayFv.md) | ⭕️ | ✅ | ✅ | ⭕️ | ✅ | ⭕️ | ⭕️ | ❌ | | | | | | | | | | | | | | | | | |
+| [chloezhu010](https://github.com/IntensiveCoLearning/Ethereum-Protocol-Fellowship/blob/main/chloezhu010.md) | ✅ | ✅ | ⭕️ | ⭕️ | ✅ | ✅ | ✅ | ✅ | | | | | | | | | | | | | | | | | |
| [coratann](https://github.com/IntensiveCoLearning/Ethereum-Protocol-Fellowship/blob/main/coratann.md) | ⭕️ | ⭕️ | ❌ | | | | | | | | | | | | | | | | | | | | | | |
-| [luffythink](https://github.com/IntensiveCoLearning/Ethereum-Protocol-Fellowship/blob/main/luffythink.md) | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | | | | | | | | | | | | | | | | | | |
+| [luffythink](https://github.com/IntensiveCoLearning/Ethereum-Protocol-Fellowship/blob/main/luffythink.md) | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | | | | | | | | | | | | | | | | |
| [Henry](https://github.com/IntensiveCoLearning/Ethereum-Protocol-Fellowship/blob/main/Henry.md) | ✅ | ✅ | ✅ | ✅ | ⭕️ | ⭕️ | ❌ | | | | | | | | | | | | | | | | | | |
-| [d0d0d9](https://github.com/IntensiveCoLearning/Ethereum-Protocol-Fellowship/blob/main/d0d0d9.md) | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | | | | | | | | | | | | | | | | | | |
-| [henryleo](https://github.com/IntensiveCoLearning/Ethereum-Protocol-Fellowship/blob/main/henryleo.md) | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | | | | | | | | | | | | | | | | | | |
-| [zhouCode](https://github.com/IntensiveCoLearning/Ethereum-Protocol-Fellowship/blob/main/zhouCode.md) | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | | | | | | | | | | | | | | | | | |
-| [mrmign](https://github.com/IntensiveCoLearning/Ethereum-Protocol-Fellowship/blob/main/mrmign.md) | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | | | | | | | | | | | | | | | | | |
-| [ghx1104](https://github.com/IntensiveCoLearning/Ethereum-Protocol-Fellowship/blob/main/ghx1104.md) | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | | | | | | | | | | | | | | | | | | |
-| [Coooder-Crypto](https://github.com/IntensiveCoLearning/Ethereum-Protocol-Fellowship/blob/main/Coooder-Crypto.md) | ✅ | ✅ | ✅ | ✅ | ✅ | ⭕️ | ⭕️ | | | | | | | | | | | | | | | | | | |
-| [rayjun](https://github.com/IntensiveCoLearning/Ethereum-Protocol-Fellowship/blob/main/rayjun.md) | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | | | | | | | | | | | | | | | | | |
+| [d0d0d9](https://github.com/IntensiveCoLearning/Ethereum-Protocol-Fellowship/blob/main/d0d0d9.md) | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ⭕️ | | | | | | | | | | | | | | | | | |
+| [henryleo](https://github.com/IntensiveCoLearning/Ethereum-Protocol-Fellowship/blob/main/henryleo.md) | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ⭕️ | ✅ | | | | | | | | | | | | | | | | |
+| [zhouCode](https://github.com/IntensiveCoLearning/Ethereum-Protocol-Fellowship/blob/main/zhouCode.md) | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | | | | | | | | | | | | | | | | |
+| [mrmign](https://github.com/IntensiveCoLearning/Ethereum-Protocol-Fellowship/blob/main/mrmign.md) | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | | | | | | | | | | | | | | | | |
+| [ghx1104](https://github.com/IntensiveCoLearning/Ethereum-Protocol-Fellowship/blob/main/ghx1104.md) | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ⭕️ | ✅ | | | | | | | | | | | | | | | | |
+| [Coooder-Crypto](https://github.com/IntensiveCoLearning/Ethereum-Protocol-Fellowship/blob/main/Coooder-Crypto.md) | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | | | | | | | | | | | | | | | | | |
+| [rayjun](https://github.com/IntensiveCoLearning/Ethereum-Protocol-Fellowship/blob/main/rayjun.md) | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | | | | | | | | | | | | | | | | |
| [CJC824](https://github.com/IntensiveCoLearning/Ethereum-Protocol-Fellowship/blob/main/CJC824.md) | ⭕️ | ⭕️ | ❌ | | | | | | | | | | | | | | | | | | | | | | |
| [William-02-02](https://github.com/IntensiveCoLearning/Ethereum-Protocol-Fellowship/blob/main/William-02-02.md) | ⭕️ | ⭕️ | ❌ | | | | | | | | | | | | | | | | | | | | | | |
-| [hotoo](https://github.com/IntensiveCoLearning/Ethereum-Protocol-Fellowship/blob/main/hotoo.md) | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ⭕️ | | | | | | | | | | | | | | | | | | |
+| [hotoo](https://github.com/IntensiveCoLearning/Ethereum-Protocol-Fellowship/blob/main/hotoo.md) | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ⭕️ | ✅ | | | | | | | | | | | | | | | | | |
| [JoscelynFarr](https://github.com/IntensiveCoLearning/Ethereum-Protocol-Fellowship/blob/main/JoscelynFarr.md) | ⭕️ | ⭕️ | ❌ | | | | | | | | | | | | | | | | | | | | | | |
| [cherry-yl-sh](https://github.com/IntensiveCoLearning/Ethereum-Protocol-Fellowship/blob/main/cherry-yl-sh.md) | ✅ | ⭕️ | ⭕️ | ✅ | ⭕️ | ⭕️ | ❌ | | | | | | | | | | | | | | | | | | |
-| [HeliosLz](https://github.com/IntensiveCoLearning/Ethereum-Protocol-Fellowship/blob/main/HeliosLz.md) | ⭕️ | ⭕️ | ✅ | ✅ | ✅ | ✅ | ✅ | | | | | | | | | | | | | | | | | | |
-| [lllapland](https://github.com/IntensiveCoLearning/Ethereum-Protocol-Fellowship/blob/main/lllapland.md) | ✅ | ✅ | ⭕️ | ✅ | ✅ | ✅ | ✅ | | | | | | | | | | | | | | | | | | |
+| [HeliosLz](https://github.com/IntensiveCoLearning/Ethereum-Protocol-Fellowship/blob/main/HeliosLz.md) | ⭕️ | ⭕️ | ✅ | ✅ | ✅ | ✅ | ✅ | ⭕️ | | | | | | | | | | | | | | | | | |
+| [lllapland](https://github.com/IntensiveCoLearning/Ethereum-Protocol-Fellowship/blob/main/lllapland.md) | ✅ | ✅ | ⭕️ | ✅ | ✅ | ✅ | ✅ | ✅ | | | | | | | | | | | | | | | | | |
| [passer-byzhang](https://github.com/IntensiveCoLearning/Ethereum-Protocol-Fellowship/blob/main/passer-byzhang.md) | ⭕️ | ⭕️ | ❌ | | | | | | | | | | | | | | | | | | | | | | |
| [StillFantastic](https://github.com/IntensiveCoLearning/Ethereum-Protocol-Fellowship/blob/main/StillFantastic.md) | ⭕️ | ✅ | ⭕️ | ✅ | ⭕️ | ⭕️ | ❌ | | | | | | | | | | | | | | | | | | |
| [debugzhao](https://github.com/IntensiveCoLearning/Ethereum-Protocol-Fellowship/blob/main/debugzhao.md) | ✅ | ⭕️ | ⭕️ | ❌ | | | | | | | | | | | | | | | | | | | | | |
-| [StarryDeserts](https://github.com/IntensiveCoLearning/Ethereum-Protocol-Fellowship/blob/main/StarryDeserts.md) | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | | | | | | | | | | | | | | | | | |
-| [KieSun](https://github.com/IntensiveCoLearning/Ethereum-Protocol-Fellowship/blob/main/KieSun.md) | ✅ | ✅ | ✅ | ✅ | ✅ | ⭕️ | ✅ | | | | | | | | | | | | | | | | | | |
-| [k66](https://github.com/IntensiveCoLearning/Ethereum-Protocol-Fellowship/blob/main/k66.md) | ✅ | ✅ | ⭕️ | ✅ | ✅ | ✅ | ✅ | | | | | | | | | | | | | | | | | | |
+| [StarryDeserts](https://github.com/IntensiveCoLearning/Ethereum-Protocol-Fellowship/blob/main/StarryDeserts.md) | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | | | | | | | | | | | | | | | | | |
+| [KieSun](https://github.com/IntensiveCoLearning/Ethereum-Protocol-Fellowship/blob/main/KieSun.md) | ✅ | ✅ | ✅ | ✅ | ✅ | ⭕️ | ✅ | ⭕️ | | | | | | | | | | | | | | | | | |
+| [k66](https://github.com/IntensiveCoLearning/Ethereum-Protocol-Fellowship/blob/main/k66.md) | ✅ | ✅ | ⭕️ | ✅ | ✅ | ✅ | ✅ | ✅ | | | | | | | | | | | | | | | | | |
| [DVDguzhou](https://github.com/IntensiveCoLearning/Ethereum-Protocol-Fellowship/blob/main/DVDguzhou.md) | ✅ | ⭕️ | ⭕️ | ❌ | | | | | | | | | | | | | | | | | | | | | |
| [armada2013](https://github.com/IntensiveCoLearning/Ethereum-Protocol-Fellowship/blob/main/armada2013.md) | ⭕️ | ⭕️ | ❌ | | | | | | | | | | | | | | | | | | | | | | |
-| [realgu](https://github.com/IntensiveCoLearning/Ethereum-Protocol-Fellowship/blob/main/realgu.md) | ✅ | ✅ | ⭕️ | ✅ | ✅ | ✅ | ✅ | | | | | | | | | | | | | | | | | | |
+| [realgu](https://github.com/IntensiveCoLearning/Ethereum-Protocol-Fellowship/blob/main/realgu.md) | ✅ | ✅ | ⭕️ | ✅ | ✅ | ✅ | ✅ | ⭕️ | | | | | | | | | | | | | | | | | |
| [Eizz0](https://github.com/IntensiveCoLearning/Ethereum-Protocol-Fellowship/blob/main/Eizz0.md) | ✅ | ✅ | ✅ | ⭕️ | ⭕️ | ⭕️ | ❌ | | | | | | | | | | | | | | | | | | |
-| [kernel1983](https://github.com/IntensiveCoLearning/Ethereum-Protocol-Fellowship/blob/main/kernel1983.md) | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | | | | | | | | | | | | | | | | | |
-| [JC13043DB](https://github.com/IntensiveCoLearning/Ethereum-Protocol-Fellowship/blob/main/JC13043DB.md) | ✅ | ⭕️ | ⭕️ | ✅ | ✅ | ⭕️ | ⭕️ | | | | | | | | | | | | | | | | | | |
+| [kernel1983](https://github.com/IntensiveCoLearning/Ethereum-Protocol-Fellowship/blob/main/kernel1983.md) | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | | | | | | | | | | | | | | | | |
+| [JC13043DB](https://github.com/IntensiveCoLearning/Ethereum-Protocol-Fellowship/blob/main/JC13043DB.md) | ✅ | ⭕️ | ⭕️ | ✅ | ✅ | ⭕️ | ⭕️ | ❌ | | | | | | | | | | | | | | | | | |
| [GuoyangLiu24](https://github.com/IntensiveCoLearning/Ethereum-Protocol-Fellowship/blob/main/GuoyangLiu24.md) | ⭕️ | ⭕️ | ❌ | | | | | | | | | | | | | | | | | | | | | | |
-| [cooper](https://github.com/IntensiveCoLearning/Ethereum-Protocol-Fellowship/blob/main/cooper.md) | ⭕️ | ✅ | ✅ | ✅ | ✅ | ⭕️ | ✅ | | | | | | | | | | | | | | | | | | |
+| [cooper](https://github.com/IntensiveCoLearning/Ethereum-Protocol-Fellowship/blob/main/cooper.md) | ⭕️ | ✅ | ✅ | ✅ | ✅ | ⭕️ | ✅ | ⭕️ | | | | | | | | | | | | | | | | | |
| [chyyynh](https://github.com/IntensiveCoLearning/Ethereum-Protocol-Fellowship/blob/main/chyyynh.md) | ⭕️ | ⭕️ | ❌ | | | | | | | | | | | | | | | | | | | | | | |
| [frankmint2024](https://github.com/IntensiveCoLearning/Ethereum-Protocol-Fellowship/blob/main/frankmint2024.md) | ✅ | ⭕️ | ✅ | ⭕️ | ⭕️ | ⭕️ | ❌ | | | | | | | | | | | | | | | | | | |
| [Amberrrrrr](https://github.com/IntensiveCoLearning/Ethereum-Protocol-Fellowship/blob/main/Amberrrrrr.md) | ✅ | ✅ | ⭕️ | ⭕️ | ⭕️ | ⭕️ | ❌ | | | | | | | | | | | | | | | | | | |
-| [yahsinhuangtw](https://github.com/IntensiveCoLearning/Ethereum-Protocol-Fellowship/blob/main/yahsinhuangtw.md) | ✅ | ✅ | ✅ | ⭕️ | ✅ | ⭕️ | ✅ | | | | | | | | | | | | | | | | | | |
+| [yahsinhuangtw](https://github.com/IntensiveCoLearning/Ethereum-Protocol-Fellowship/blob/main/yahsinhuangtw.md) | ✅ | ✅ | ✅ | ⭕️ | ✅ | ⭕️ | ✅ | ✅ | ✅ | | | | | | | | | | | | | | | | |
| [0xKarl98](https://github.com/IntensiveCoLearning/Ethereum-Protocol-Fellowship/blob/main/0xKarl98.md) | ⭕️ | ⭕️ | ❌ | | | | | | | | | | | | | | | | | | | | | | |
-| [marvelshan](https://github.com/IntensiveCoLearning/Ethereum-Protocol-Fellowship/blob/main/marvelshan.md) | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | | | | | | | | | | | | | | | | | | |
+| [marvelshan](https://github.com/IntensiveCoLearning/Ethereum-Protocol-Fellowship/blob/main/marvelshan.md) | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ⭕️ | ✅ | | | | | | | | | | | | | | | | |
| [rogers3333](https://github.com/IntensiveCoLearning/Ethereum-Protocol-Fellowship/blob/main/rogers3333.md) | ✅ | ⭕️ | ⭕️ | ❌ | | | | | | | | | | | | | | | | | | | | | |
| [deporter](https://github.com/IntensiveCoLearning/Ethereum-Protocol-Fellowship/blob/main/deporter.md) | ⭕️ | ⭕️ | ❌ | | | | | | | | | | | | | | | | | | | | | | |
-| [LouisTsai-Csie](https://github.com/IntensiveCoLearning/Ethereum-Protocol-Fellowship/blob/main/LouisTsai-Csie.md) | ✅ | ✅ | ✅ | ✅ | ✅ | ⭕️ | ⭕️ | | | | | | | | | | | | | | | | | | |
-| [kidneyweakx](https://github.com/IntensiveCoLearning/Ethereum-Protocol-Fellowship/blob/main/kidneyweakx.md) | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | | | | | | | | | | | | | | | | | | |
+| [LouisTsai-Csie](https://github.com/IntensiveCoLearning/Ethereum-Protocol-Fellowship/blob/main/LouisTsai-Csie.md) | ✅ | ✅ | ✅ | ✅ | ✅ | ⭕️ | ⭕️ | ✅ | | | | | | | | | | | | | | | | | |
+| [kidneyweakx](https://github.com/IntensiveCoLearning/Ethereum-Protocol-Fellowship/blob/main/kidneyweakx.md) | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | | | | | | | | | | | | | | | | | |
| [keroro520](https://github.com/IntensiveCoLearning/Ethereum-Protocol-Fellowship/blob/main/keroro520.md) | ⭕️ | ⭕️ | ❌ | | | | | | | | | | | | | | | | | | | | | | |
| [huangyan0914](https://github.com/IntensiveCoLearning/Ethereum-Protocol-Fellowship/blob/main/huangyan0914.md) | ✅ | ✅ | ✅ | ✅ | ⭕️ | ⭕️ | ❌ | | | | | | | | | | | | | | | | | | |
| [0xNezha](https://github.com/IntensiveCoLearning/Ethereum-Protocol-Fellowship/blob/main/0xNezha.md) | ✅ | ⭕️ | ⭕️ | ❌ | | | | | | | | | | | | | | | | | | | | | |
| [Garyamour](https://github.com/IntensiveCoLearning/Ethereum-Protocol-Fellowship/blob/main/Garyamour.md) | ⭕️ | ⭕️ | ❌ | | | | | | | | | | | | | | | | | | | | | | |
| [huahuahua1223](https://github.com/IntensiveCoLearning/Ethereum-Protocol-Fellowship/blob/main/huahuahua1223.md) | ⭕️ | ⭕️ | ❌ | | | | | | | | | | | | | | | | | | | | | | |
-| [dethan3](https://github.com/IntensiveCoLearning/Ethereum-Protocol-Fellowship/blob/main/dethan3.md) | ✅ | ✅ | ✅ | ⭕️ | ✅ | ✅ | ✅ | | | | | | | | | | | | | | | | | | |
+| [dethan3](https://github.com/IntensiveCoLearning/Ethereum-Protocol-Fellowship/blob/main/dethan3.md) | ✅ | ✅ | ✅ | ⭕️ | ✅ | ✅ | ✅ | ⭕️ | | | | | | | | | | | | | | | | | |
| [Azleal](https://github.com/IntensiveCoLearning/Ethereum-Protocol-Fellowship/blob/main/Azleal.md) | ⭕️ | ⭕️ | ❌ | | | | | | | | | | | | | | | | | | | | | | |
-| [jjeejj](https://github.com/IntensiveCoLearning/Ethereum-Protocol-Fellowship/blob/main/jjeejj.md) | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | | | | | | | | | | | | | | | | | | |
+| [jjeejj](https://github.com/IntensiveCoLearning/Ethereum-Protocol-Fellowship/blob/main/jjeejj.md) | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | | | | | | | | | | | | | | | | | |
| [buctor41](https://github.com/IntensiveCoLearning/Ethereum-Protocol-Fellowship/blob/main/buctor41.md) | ✅ | ✅ | ⭕️ | ⭕️ | ⭕️ | ⭕️ | ❌ | | | | | | | | | | | | | | | | | | |
-| [zhwindy](https://github.com/IntensiveCoLearning/Ethereum-Protocol-Fellowship/blob/main/zhwindy.md) | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | | | | | | | | | | | | | | | | | | |
-| [rectinajh](https://github.com/IntensiveCoLearning/Ethereum-Protocol-Fellowship/blob/main/rectinajh.md) | ✅ | ✅ | ✅ | ⭕️ | ✅ | ✅ | ✅ | | | | | | | | | | | | | | | | | | |
+| [zhwindy](https://github.com/IntensiveCoLearning/Ethereum-Protocol-Fellowship/blob/main/zhwindy.md) | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | | | | | | | | | | | | | | | | | |
+| [rectinajh](https://github.com/IntensiveCoLearning/Ethereum-Protocol-Fellowship/blob/main/rectinajh.md) | ✅ | ✅ | ✅ | ⭕️ | ✅ | ✅ | ✅ | ✅ | ✅ | | | | | | | | | | | | | | | | |
| [letsgoexplore](https://github.com/IntensiveCoLearning/Ethereum-Protocol-Fellowship/blob/main/letsgoexplore.md) | ⭕️ | ⭕️ | ❌ | | | | | | | | | | | | | | | | | | | | | | |
-| [Lvista](https://github.com/IntensiveCoLearning/Ethereum-Protocol-Fellowship/blob/main/Lvista.md) | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | | | | | | | | | | | | | | | | | | |
+| [Lvista](https://github.com/IntensiveCoLearning/Ethereum-Protocol-Fellowship/blob/main/Lvista.md) | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | | | | | | | | | | | | | | | | | |
| [lanpan999](https://github.com/IntensiveCoLearning/Ethereum-Protocol-Fellowship/blob/main/lanpan999.md) | ⭕️ | ⭕️ | ❌ | | | | | | | | | | | | | | | | | | | | | | |
-| [liuxulife](https://github.com/IntensiveCoLearning/Ethereum-Protocol-Fellowship/blob/main/liuxulife.md) | ✅ | ✅ | ✅ | ✅ | ⭕️ | ⭕️ | ❌ | | | | | | | | | | | | | | | | | | |
-| [CHENFANGC](https://github.com/IntensiveCoLearning/Ethereum-Protocol-Fellowship/blob/main/CHENFANGC.md) | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | | | | | | | | | | | | | | | | | |
-| [ppatrick007](https://github.com/IntensiveCoLearning/Ethereum-Protocol-Fellowship/blob/main/ppatrick007.md) | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | | | | | | | | | | | | | | | | | | |
-| [zt2](https://github.com/IntensiveCoLearning/Ethereum-Protocol-Fellowship/blob/main/zt2.md) | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | | | | | | | | | | | | | | | | | | |
+| [liuxulife](https://github.com/IntensiveCoLearning/Ethereum-Protocol-Fellowship/blob/main/liuxulife.md) | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ⭕️ | | | | | | | | | | | | | | | | | |
+| [CHENFANGC](https://github.com/IntensiveCoLearning/Ethereum-Protocol-Fellowship/blob/main/CHENFANGC.md) | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | | | | | | | | | | | | | | | | |
+| [ppatrick007](https://github.com/IntensiveCoLearning/Ethereum-Protocol-Fellowship/blob/main/ppatrick007.md) | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | | | | | | | | | | | | | | | | | |
+| [zt2](https://github.com/IntensiveCoLearning/Ethereum-Protocol-Fellowship/blob/main/zt2.md) | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ⭕️ | | | | | | | | | | | | | | | | | |
| [yiwen4](https://github.com/IntensiveCoLearning/Ethereum-Protocol-Fellowship/blob/main/yiwen4.md) | ✅ | ⭕️ | ⭕️ | ❌ | | | | | | | | | | | | | | | | | | | | | |
| [affe](https://github.com/IntensiveCoLearning/Ethereum-Protocol-Fellowship/blob/main/affe.md) | ⭕️ | ⭕️ | ❌ | | | | | | | | | | | | | | | | | | | | | | |
-| [dundun930326](https://github.com/IntensiveCoLearning/Ethereum-Protocol-Fellowship/blob/main/dundun930326.md) | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | | | | | | | | | | | | | | | | | |
+| [dundun930326](https://github.com/IntensiveCoLearning/Ethereum-Protocol-Fellowship/blob/main/dundun930326.md) | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | | | | | | | | | | | | | | | | |
| [Echocipher](https://github.com/IntensiveCoLearning/Ethereum-Protocol-Fellowship/blob/main/Echocipher.md) | ✅ | ⭕️ | ⭕️ | ❌ | | | | | | | | | | | | | | | | | | | | | |
-| [poyucheese](https://github.com/IntensiveCoLearning/Ethereum-Protocol-Fellowship/blob/main/poyucheese.md) | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | | | | | | | | | | | | | | | | | | |
-| [amandakelake](https://github.com/IntensiveCoLearning/Ethereum-Protocol-Fellowship/blob/main/amandakelake.md) | ✅ | ✅ | ✅ | ⭕️ | ✅ | ✅ | ✅ | | | | | | | | | | | | | | | | | | |
+| [poyucheese](https://github.com/IntensiveCoLearning/Ethereum-Protocol-Fellowship/blob/main/poyucheese.md) | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | | | | | | | | | | | | | | | | | |
+| [amandakelake](https://github.com/IntensiveCoLearning/Ethereum-Protocol-Fellowship/blob/main/amandakelake.md) | ✅ | ✅ | ✅ | ⭕️ | ✅ | ✅ | ✅ | ⭕️ | | | | | | | | | | | | | | | | | |
| [ALiangNe](https://github.com/IntensiveCoLearning/Ethereum-Protocol-Fellowship/blob/main/ALiangNe.md) | ⭕️ | ⭕️ | ❌ | | | | | | | | | | | | | | | | | | | | | | |
-| [tienshaoku](https://github.com/IntensiveCoLearning/Ethereum-Protocol-Fellowship/blob/main/tienshaoku.md) | ✅ | ✅ | ✅ | ⭕️ | ⭕️ | ⭕️ | ✅ | | | | | | | | | | | | | | | | | | |
-| [tannerang](https://github.com/IntensiveCoLearning/Ethereum-Protocol-Fellowship/blob/main/tannerang.md) | ✅ | ⭕️ | ✅ | ⭕️ | ✅ | ✅ | ✅ | | | | | | | | | | | | | | | | | | |
-| [dixia](https://github.com/IntensiveCoLearning/Ethereum-Protocol-Fellowship/blob/main/dixia.md) | ✅ | ✅ | ✅ | ⭕️ | ✅ | ✅ | ✅ | | | | | | | | | | | | | | | | | | |
+| [tienshaoku](https://github.com/IntensiveCoLearning/Ethereum-Protocol-Fellowship/blob/main/tienshaoku.md) | ✅ | ✅ | ✅ | ⭕️ | ⭕️ | ⭕️ | ✅ | ❌ | | | | | | | | | | | | | | | | | |
+| [tannerang](https://github.com/IntensiveCoLearning/Ethereum-Protocol-Fellowship/blob/main/tannerang.md) | ✅ | ⭕️ | ✅ | ⭕️ | ✅ | ✅ | ✅ | ⭕️ | | | | | | | | | | | | | | | | | |
+| [dixia](https://github.com/IntensiveCoLearning/Ethereum-Protocol-Fellowship/blob/main/dixia.md) | ✅ | ✅ | ✅ | ⭕️ | ✅ | ✅ | ✅ | ✅ | | | | | | | | | | | | | | | | | |
| [dajuguan](https://github.com/IntensiveCoLearning/Ethereum-Protocol-Fellowship/blob/main/dajuguan.md) | ✅ | ✅ | ✅ | ⭕️ | ⭕️ | ⭕️ | ❌ | | | | | | | | | | | | | | | | | | |
| [timfaner](https://github.com/IntensiveCoLearning/Ethereum-Protocol-Fellowship/blob/main/timfaner.md) | ✅ | ⭕️ | ⭕️ | ❌ | | | | | | | | | | | | | | | | | | | | | |
-| [JeasonZhang](https://github.com/IntensiveCoLearning/Ethereum-Protocol-Fellowship/blob/main/JeasonZhang.md) | ✅ | ⭕️ | ⭕️ | ✅ | ✅ | ✅ | ✅ | ✅ | | | | | | | | | | | | | | | | | |
+| [JeasonZhang](https://github.com/IntensiveCoLearning/Ethereum-Protocol-Fellowship/blob/main/JeasonZhang.md) | ✅ | ⭕️ | ⭕️ | ✅ | ✅ | ✅ | ✅ | ✅ | | | | | | | | | | | | | | | | | |
| [LikKee](https://github.com/IntensiveCoLearning/Ethereum-Protocol-Fellowship/blob/main/LikKee.md) | ⭕️ | ⭕️ | ❌ | | | | | | | | | | | | | | | | | | | | | | |
-| [phoebe-dot](https://github.com/IntensiveCoLearning/Ethereum-Protocol-Fellowship/blob/main/phoebe-dot.md) | ✅ | ✅ | ✅ | ✅ | ⭕️ | ⭕️ | ✅ | | | | | | | | | | | | | | | | | | |
-| [PubYuCHe](https://github.com/IntensiveCoLearning/Ethereum-Protocol-Fellowship/blob/main/PubYuCHe.md) | ✅ | ✅ | ⭕️ | ⭕️ | ⭕️ | ✅ | ⭕️ | | | | | | | | | | | | | | | | | | |
+| [phoebe-dot](https://github.com/IntensiveCoLearning/Ethereum-Protocol-Fellowship/blob/main/phoebe-dot.md) | ✅ | ✅ | ✅ | ✅ | ⭕️ | ⭕️ | ✅ | ✅ | ✅ | | | | | | | | | | | | | | | | |
+| [PubYuCHe](https://github.com/IntensiveCoLearning/Ethereum-Protocol-Fellowship/blob/main/PubYuCHe.md) | ✅ | ✅ | ⭕️ | ⭕️ | ⭕️ | ✅ | ⭕️ | ✅ | | | | | | | | | | | | | | | | | |
| [evanwu](https://github.com/IntensiveCoLearning/Ethereum-Protocol-Fellowship/blob/main/evanwu.md) | ✅ | ⭕️ | ⭕️ | ❌ | | | | | | | | | | | | | | | | | | | | | |
| [lknxt1995](https://github.com/IntensiveCoLearning/Ethereum-Protocol-Fellowship/blob/main/lknxt1995.md) | ✅ | ⭕️ | ⭕️ | ❌ | | | | | | | | | | | | | | | | | | | | | |
| [nooma42](https://github.com/IntensiveCoLearning/Ethereum-Protocol-Fellowship/blob/main/nooma42.md) | ✅ | ⭕️ | ⭕️ | ✅ | ⭕️ | ⭕️ | ❌ | | | | | | | | | | | | | | | | | | |
| [eddy8](https://github.com/IntensiveCoLearning/Ethereum-Protocol-Fellowship/blob/main/eddy8.md) | ⭕️ | ⭕️ | ❌ | | | | | | | | | | | | | | | | | | | | | | |
-| [yenchihliao](https://github.com/IntensiveCoLearning/Ethereum-Protocol-Fellowship/blob/main/yenchihliao.md) | ⭕️ | ⭕️ | ✅ | ✅ | ✅ | ✅ | ✅ | | | | | | | | | | | | | | | | | | |
+| [yenchihliao](https://github.com/IntensiveCoLearning/Ethereum-Protocol-Fellowship/blob/main/yenchihliao.md) | ⭕️ | ⭕️ | ✅ | ✅ | ✅ | ✅ | ✅ | ⭕️ | | | | | | | | | | | | | | | | | |
| [DasNarrenschiff](https://github.com/IntensiveCoLearning/Ethereum-Protocol-Fellowship/blob/main/DasNarrenschiff.md) | ✅ | ⭕️ | ⭕️ | ✅ | ⭕️ | ⭕️ | ❌ | | | | | | | | | | | | | | | | | | |
-| [awsomecty](https://github.com/IntensiveCoLearning/Ethereum-Protocol-Fellowship/blob/main/awsomecty.md) | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | | | | | | | | | | | | | | | | | | |
-| [devbards](https://github.com/IntensiveCoLearning/Ethereum-Protocol-Fellowship/blob/main/devbards.md) | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | | | | | | | | | | | | | | | | | | |
+| [awsomecty](https://github.com/IntensiveCoLearning/Ethereum-Protocol-Fellowship/blob/main/awsomecty.md) | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ⭕️ | | | | | | | | | | | | | | | | | |
+| [devbards](https://github.com/IntensiveCoLearning/Ethereum-Protocol-Fellowship/blob/main/devbards.md) | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ⭕️ | | | | | | | | | | | | | | | | | |
| [StellaWang5209](https://github.com/IntensiveCoLearning/Ethereum-Protocol-Fellowship/blob/main/StellaWang5209.md) | ⭕️ | ⭕️ | ❌ | | | | | | | | | | | | | | | | | | | | | | |
| [pillowtalk-Qy](https://github.com/IntensiveCoLearning/Ethereum-Protocol-Fellowship/blob/main/pillowtalk-Qy.md) | ⭕️ | ⭕️ | ❌ | | | | | | | | | | | | | | | | | | | | | | |
| [yoona333](https://github.com/IntensiveCoLearning/Ethereum-Protocol-Fellowship/blob/main/yoona333.md) | ⭕️ | ⭕️ | ❌ | | | | | | | | | | | | | | | | | | | | | | |
@@ -671,6 +671,43 @@ Telegram:https://t.me/ETHPandaOrg/5427
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
diff --git a/brucexu-eth.md b/brucexu-eth.md
index e5e1b77..c5ab453 100644
--- a/brucexu-eth.md
+++ b/brucexu-eth.md
@@ -279,6 +279,113 @@ TODO 明天把整个区块的所有信息和内容过一下 https://etherscan.io
TODO randao
TODO withdrawals 提款工作原理?
+## https://epf.wiki/#/eps/week2
+
+LevelDB is a fast key-value storage library written at Google that provides an ordered mapping from string keys to string values.
+
+一个原始的 block 数据(deneb):
+
+```
+{
+ "slot": "8631513",
+ "proposer_index": "1124880",
+ "parent_root": "0x5a585679198d1bae7f337f987496d22c9f0db95fb1bcd4d8069a74be0e76a5ae",
+ "state_root": "0x855b6335a3b955443fb14111738881680817a2de050a1e2534904ce2ddd8e5e0",
+ "body": {
+ "randao_reveal": "0x8c290463d6e68154d171deeca3a4d8d8fa276c72e9c34094f8b6bf89e551e99d63162e362a936b628af4840d69b10c24191e892d0a282bb5358a5669f44e42b627ebeb63fd6467c7aad62636a348b5f4edfb8ce01650e4d079339d9dc5700f05",
+ "eth1_data": {
+ "deposit_root": "0x636ab1747c976fe08cf337b437ccbb5f543e0d0c6b5d70097c3ab7737c1748d5",
+ "deposit_count": "1342638",
+ "block_hash": "0x429813f0390a9e104740e8a24ebb83ac03929dff4a9702385f2bf24391ba754b"
+ },
+ "graffiti": "0x526f636b617761795820496e6672610000000000000000000000000000000000",
+ "proposer_slashings": [],
+ "attester_slashings": [],
+ "attestations": [
+ {
+ "aggregation_bits": "0xffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff7f",
+ "data": {
+ "slot": "8631512",
+ "index": "19",
+ "beacon_block_root": "0x5a585679198d1bae7f337f987496d22c9f0db95fb1bcd4d8069a74be0e76a5ae",
+ "source": {
+ "epoch": "269733",
+ "root": "0x508880ef7fe7cac1a601bcb00868cc41a523497b34d85fb71dc338f891eb049b"
+ },
+ "target": {
+ "epoch": "269734",
+ "root": "0x89926ca6add36803c7239a78f78af0fb91df932f8af2ac34d4cf89998ea3ec68"
+ }
+ },
+ "signature": "0x903146f136e4df8200be0229eb96bc9a2409d04763df61ebba51f54cfbd9eca2c88274cb94828c2705bff1454c50322e03372883c2dd47ee329cd17a3653f44314fa8693c73fa2097f622e7f2e163f7b7cb688aebad93e14c273d406743ec7ad"
+ },
+ {
+ "aggregation_bits": "0xffffffffffbfffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff7f",
+ "data": {
+ "slot": "8631512",
+ "index": "27",
+ "beacon_block_root": "0x5a585679198d1bae7f337f987496d22c9f0db95fb1bcd4d8069a74be0e76a5ae",
+ "source": {
+ "epoch": "269733",
+ "root": "0x508880ef7fe7cac1a601bcb00868cc41a523497b34d85fb71dc338f891eb049b"
+ },
+ "target": {
+ "epoch": "269734",
+ "root": "0x89926ca6add36803c7239a78f78af0fb91df932f8af2ac34d4cf89998ea3ec68"
+ }
+ },
+ "signature": "0x99d3c97b5036025d1b30ac32efd469a815269e2575a7525b1cc8323db85556aef7af7464d965ab9b6ee1804005436a0b05faf870cb213dff04552ddffcfe355987d35201e58dce3897c0de27a19016321fba9ac346452755ae9340f60cea895d"
+ }
+ ],
+ "deposits": [],
+ "voluntary_exits": [],
+ "sync_aggregate": {
+ "sync_committee_bits": "0xfffffffffffffffeffffffffffffffffffbffffffffffffffffffdfffffffbffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff",
+ "sync_committee_signature": "0xae953c135ac95f1cd669a8caf9e89770483bdf3dbf138b2dfdd76198e9baac00ab4d807b518ebfa9e665a8a78dab9c210ff7a073b85fef1e75ccd49f0747c73fe850f9e87c63985f9bf5d795c28474c4ea67716e194a320382c6d9e560aebc9e"
+ },
+ "execution_payload": {
+ "parent_hash": "0x5cb0f2822e542e2c6fbc0099aa8f996509c178bfaa634e04b728add8da42c65d",
+ "fee_recipient": "0x95222290dd7278aa3ddd389cc1e1d165cc4bafe5",
+ "state_root": "0xca4e0ab986d29ee5bddd8b4b9d9481e90d7bbd1ce7ee9e0d077c89ba03cdcf32",
+ "receipts_root": "0x09fdee17a2dafb2328798f9e47b44e50a5a8e5d9951929afa51f70fc222846c2",
+ "logs_bloom": "0xbffdca4be5945bfbba8a8ed5eadb7ff2dcefce7f6cb67b94cf81ad38dc9a943b76e541efe10b2768ded9de385ffdd9596b79a4ecffbafd407ffca3453cff2d9ebf7f57ffe3069abb7eebf66eddc460ecd9ef7ded9c67de1b1ccb7ce9e9f9cf7e3fdcdc2fbe974ae2be4cd35271d47b5bda4459fde93d3f0bead5c558997b18386ef38ff77e234f6eb7cda7d47bee4ab6b273b8f9ffb37d5be6ffb7dac9ffbd36ffc6eb33ffaa7f832f264dc5f9966fed1fc7c0fdf6fb719e7fb39b6e38dddfe3defbde6a7668fb7f2166e79fb8df91adbd73545fbf3ae59caeedf7df6937fc5039fafaff21fd720fd9f5d6a3e85798e0d7abde86f3a6afff6383fb0beefcdc0f",
+ "prev_randao": "0xb48f684132ba484557c07ea6964d6b3841607a44a540a24dd31cbbccb14f06a5",
+ "block_number": "19431837",
+ "gas_limit": "30000000",
+ "gas_used": "28138718",
+ "timestamp": "1710402179",
+ "extra_data": "0x6265617665726275696c642e6f7267",
+ "base_fee_per_gas": "44330915133",
+ "block_hash": "0x4cf7d9108fc01b50023ab7cab9b372a96068fddcadec551630393b65acb1f34c",
+ "transactions": [
+ "0x02f904b40183222e6b80850a5254153d8303adab946b75d8af000000e20b7a7ddf000ba900b4009a808509bafeda9db83a7f381ce270557c1f68cfb577b856766310bf8b47fd9ce8d11a5b113a7a922aea89288d8c91777beecc68df4a17151df102bbfc4140e8c3d5e806f90407f8bc94e485e2f1bab389c08721b291f6b59780fec83fd7f8a5a0ddf68a16e33fcf794c93d34148c2e2c4391f4f3f27ff7a52703ddbcdb5c569f0a0b39e9ba92c3c47c76d4f70e3bc9c3270ab78d2592718d377c8f5433a34d3470aa09edbdabec2e16ca41f1efb3c19f5f3d18c604847272628636ea866af352b901ca09bb3e24e1534bce24e9896f3377327d742d6c1d430477b7ebc070c2eb64e3147a0000000000000000000000000000000000000000000000000000000000000000bf859941ce270557c1f68cfb577b856766310bf8b47fd9cf842a0b39e9ba92c3c47c76d4f70e3bc9c3270ab78d2592718d377c8f5433a34d3470aa094fe3377ad59f5716da176e7699b06460ce5b4208f8313f3d26113b1cf3d3170f8dd947054b0f980a7eb5b3a6b3446f3c947d80162775cf8c6a00000000000000000000000000000000000000000000000000000000000000007a00000000000000000000000000000000000000000000000000000000000000009a0000000000000000000000000000000000000000000000000000000000000000aa0000000000000000000000000000000000000000000000000000000000000000ca00000000000000000000000000000000000000000000000000000000000000008a00000000000000000000000000000000000000000000000000000000000000006f85994c02aaa39b223fe8d0a0e5c4f27ead9083c756cc2f842a0051234925bf172ac8e2ccbd292c65330169d67445a0966551f13a5df19bb9321a012231cd4c753cb5530a43a74c45106c24765e6f81dc8927d4f4be7e53315d5a8f8bc94a0b86991c6218b36c1d19d4a2e9eb0ce3606eb48f8a5a0d2764b6d304d6875dc1632274f53a7d27047ae66fe20f57cce9fb878c86ccdeaa010d6a54a4754c8869d6886b5f5d7fbfa5b4522237ea5c60d11bc4e7a1ff9390ba07050c9e0f4ca769c69bd3a8ef740bc37934f8e2c036e5a723fd8ee048ed3f8c3a00000000000000000000000000000000000000000000000000000000000000001a0154bb98efc83b034ad81fbf23cc88c9737739df170c146ea18e8113dac893665d69443506849d7c04f9138d1a2050bbf3a0c054402ddc0f8dd947a922aea89288d8c91777beecc68df4a17151df1f8c6a00000000000000000000000000000000000000000000000000000000000000008a00000000000000000000000000000000000000000000000000000000000000006a00000000000000000000000000000000000000000000000000000000000000007a00000000000000000000000000000000000000000000000000000000000000009a0000000000000000000000000000000000000000000000000000000000000000aa0000000000000000000000000000000000000000000000000000000000000000c80a0bc7a0020d84346ad4ffdce908fbf7291f7f7f251a6381bd43583f02606a05471a04acbaeb9886f864bc654123665b91e527623fd2a9225e1371e061ecf5fa4dbf8",
+ "0x02f9017501829a308502540be400850f8839d18083061a80947a250d5630b4cf539739df2c5dacb4c659f2488d80b9010438ed17390000000000000000000000000000000000000003221ceed0394f7b8ef2b12118000000000000000000000000000000000000000000000000213a0fe9640f2a2d00000000000000000000000000000000000000000000000000000000000000a00000000000000000000000001d283807630ffb876a5d78b8e0788e491449f2410000000000000000000000000000000000000000000000000000018e3bee84e100000000000000000000000000000000000000000000000000000000000000020000000000000000000000001ce270557c1f68cfb577b856766310bf8b47fd9c000000000000000000000000c02aaa39b223fe8d0a0e5c4f27ead9083c756cc2c001a036e76fbcbc86dd2d6fe3d37e65ca3e83aec7259a850b28686fece7105c1d2a24a06c4b4d44d359c9360b8ebf2554eacae621824441f00d99275be3bfd01f554239",
+ "0x02f87201830bbc2a80850a5254153d827d0094388c818ca8b9251b393131c08a736a67ccb19297880185a6d6be627f3280c080a038cbd7a4589d49f061b88da94c6d16e085faed4ea61f60a744d781bea95862a3a061eb4b1dc235a3fdb04c589150326d7e49089439428c22ced7bc7ddb559edd37"
+ ],
+ "withdrawals": [
+ {
+ "index": "38350022",
+ "validator_index": "171011",
+ "address": "0x8626354048f90faafc212c07ec7f3613406b1b32",
+ "amount": "18545672"
+ },
+ {
+ "index": "38350023",
+ "validator_index": "171012",
+ "address": "0x8626354048f90faafc212c07ec7f3613406b1b32",
+ "amount": "18561699"
+ }
+ ],
+ "blob_gas_used": "131072",
+ "excess_blob_gas": "0"
+ },
+ "bls_to_execution_changes": [],
+ "blob_kzg_commitments": [
+ "0x97d62d4572935295f909f243714201d9221215bfcc91af6546d28d2e52040577a77957256c530ca25974f6a814511b1a"
+ ]
+ }
+}
+```
diff --git a/chloezhu010.md b/chloezhu010.md
index edebb14..a80753d 100644
--- a/chloezhu010.md
+++ b/chloezhu010.md
@@ -226,6 +226,6 @@ timezone: Europe/Berlin
- simple serialize is a serialization format designed specifically for eth2
- encode & decode data structure in a more efficient, type-aware, optimized for merkleization style
### 2025.02.13
-
+Update the notes on mindmap: https://ab9jvcjkej.feishu.cn/mindnotes/IfABbVTMfmg5IFnqinEcmcDqnFe#mindmap
diff --git a/dixia.md b/dixia.md
index 13d8bea..fd1dbbe 100644
--- a/dixia.md
+++ b/dixia.md
@@ -141,4 +141,8 @@ keep reading https://eth2book.info/capella/part2/consensus/preliminaries/#fork-c
Execution layer validate cryptographic perspective of safty and together with consensus layer it make sure the validation rule (cryptographic rule ) are follow (safty) and working (liveness)?
+### 2025.02.13
+
+read more about fork choice rules particular about casper & LMD GHOST
+
\ No newline at end of file
diff --git a/dundun930326.md b/dundun930326.md
index fea26d9..9063901 100644
--- a/dundun930326.md
+++ b/dundun930326.md
@@ -305,8 +305,59 @@ TODO : responsibility、p2p、snap
- 協議中設有多種方法以確保數據正確性,並利用弱主觀性檢查點驗證下載的狀態資料。
---
+### 2025.02.14
+今天看了共識層,用GPT整理了一些重點。
+### 中心化 vs. 分散式運作
-這個總結重點整理了區塊驗證、區塊構建以及相關底層技術(STF、EVM、P2P)的核心概念與流程,幫助你快速回顧整個內容的邏輯與細節。
+• 單一信任運營者模式
+ – 一台伺服器依照協議運作,但用戶必須完全信任這個單一運營者,否則容易發生重複花費等問題。
+
+• 分散式節點運作
+ – 多個節點共同計算並複製狀態(state machine replication),達成共識,無需信任單一第三方。
+ – 即使部分節點出現錯誤或惡意行為,只要大部分節點保持一致,整體系統依然能穩定運作。
+
+### 拜占庭容錯 (BFT) 與共識
+• 為何需要BFT?
+ – 在開放分散式系統中,節點可能因硬體故障、網路延遲、程式錯誤或攻擊而出現不一致的情況。
+ – BFT機制可以讓系統在部分節點失效或惡意的情況下,仍能正確達成共識。
+
+• 兩階段提交 (2PC) 範例
+ – 第一階段(Prepare):某節點詢問其他節點是否能接受某筆交易,當達到2/3超多數確認後,進入下一階段。
+ – 第二階段(Commit):節點根據結果決定提交或中止該筆交易,最終使所有正確節點達成同一狀態。
+
+• 實用型拜占庭容錯 (PBFT)
+ – PBFT允許系統在少數節點惡意情況下達成共識。
+ – 缺點:在節點數量增加時,通信複雜度迅速上升,也容易遭遇Sybil攻擊(單一實體操控大量節點)。
+
+### PoS
+• Validator(驗證者)的角色
+ – 成為驗證者需要質押32 ETH,並在以太坊的存款合約中進行登記
+ – 驗證者需定期對區塊鏈狀態進行「簽名」確認,包括:
+ ○ LMD-GHOST投票:對Beacon鏈的區塊頭進行認可
+ ○ Casper-FFG投票:在每個epoch的checkpoint上進行確認
+
+• 基本時間單位與組織結構
+ – Slot:每12秒產生一個slot,每個slot內部劃分為三個階段(每階段約4秒),其中4秒為關鍵的簽名截止時間
+ – Epoch:由32個slot組成,用來降低共識處理頻率,重負任務(如懲罰與獎勵發放)通常在epoch邊界執行
+ – Committee:驗證者會在不同epoch中隨機分組,每位驗證者在其被分配的slot中完成一次簽名
+
+• 最終性(Finality)的概念
+ – 當一個checkpoint獲得2/3超多數確認後,其狀態即被認定為「justified」,隨後上一個已justified的checkpoint就會被「finalized」,意味著交易不可逆轉
+
+• 共識算法Gasper
+ – 結合了Casper-FFG與LMD-GHOST,用來確定最終的區塊鏈分支,幫助新節點同步正確鏈
+
+### 其他重要概念與未來方向
+
+• 提議者與構建者分離(PBS)
+ – 為解決MEV問題(驗證者藉由交易排序獲利),PBS允許區塊提議者將區塊構建外包給專業團隊,從而降低對高端硬體的依賴,維持網路去中心化
+
+• 單slot最終性 (SSF) 與單秘密領導者選舉 (SSLE)
+ – SSF目標是在一個slot內達到最終性
+ – SSLE則希望在slot內秘密選出區塊提議者,進一步提高安全性和抗操控能力
+
+• 最大有效餘額 (Max Effective Balance)
+ – 探討如何提高每位驗證者的有效質押金額(目前設定為32 ETH),以期進一步提升系統的安全性和效能
diff --git a/ghx1104.md b/ghx1104.md
index bc75e59..e552c06 100644
--- a/ghx1104.md
+++ b/ghx1104.md
@@ -490,4 +490,31 @@ EELS 可能涉及的内容包括:
Sam Wilson 可能会讨论如何加强执行层安全性,以确保以太坊网络能够处理更多的交易负载,同时保护用户和验证者免受潜在的攻击。
+### 2025.02.14
+
+#### week6
+
+### **1. Ethereum Scalability**
+**以太坊的可扩展性** 是指其在处理大量交易和智能合约时的能力。随着用户和应用的增加,传统的单链架构面临瓶颈,导致网络拥堵和交易费用飙升。提高以太坊的可扩展性是为了支持更多的应用、提高交易吞吐量,并保持低费用。
+
+---
+
+### **2. History of Sharding and Path Forward**
+**分片(Sharding)** 是一种将区块链网络分成多个独立的分片(Shards)来并行处理交易的技术。以太坊的分片计划可以显著提高网络的处理能力,减少单个节点的负担。
+
+- **历史**:最初,分片概念是在以太坊 2.0 的设计中提出的,目标是将每个分片当作独立的链来执行,处理和存储交易。通过分片,网络的负载可以被平衡,提升总体吞吐量。
+
+- **未来路径**:以太坊正在逐步实现分片,首先通过 **Rollups**(如 zk-Rollups 和 OP-Rollups)来提高扩展性,然后在未来逐步推出分片技术,使每个分片可以独立处理事务。
+
+---
+
+### **3. Data Availability**
+**数据可用性(Data Availability)** 是分片和扩展方案中的一个重要问题。它确保链上的数据对所有验证者可用且可访问。分片网络中的节点需要确保他们可以访问到其他分片的数据,以便正确地验证和参与共识。
+
+- **挑战**:如果某个分片的数据不可用,可能导致分片停滞或分裂,影响网络的稳定性和安全性。
+- **解决方案**:以太坊通过 **数据可用性采样(Data Availability Sampling)** 等技术来确保即使只有一部分节点获取数据,其他节点也能通过验证和快速同步来确保数据可用性。
+
+---
+
+
diff --git a/henryleo.md b/henryleo.md
index 65f8cdd..d96d2c2 100644
--- a/henryleo.md
+++ b/henryleo.md
@@ -102,6 +102,8 @@ Symmetric-key algorithm 对称密钥算法,这类型的加密算法被称为sy
**比特币网络中交易记录的非对称加密**
每个账户有一个公钥(pk)和一个私钥(sk),转账记录是一个明文的信息,其中唯一的交易编号,这个信息通过**签名函数**生成一个Digtal Signature电子签名(也许是一个哈希),并可以将其与信息和公钥以及另一个**验证函数**验证真伪。
+
+
**Merkle tree**
@@ -110,16 +112,21 @@ Merkle Tree是一种数据结构,将已有的交易记录通过哈希散列函
- 其次,按交易的先后顺序将其哈希两两拼接,再次计算哈希,如`H0_0+H0_1=>H0`、`H1_0+H1_1=>H1`,这样我们就把四笔交易的信息压缩为两个哈希
- 第三,将H0和H1拼接并计算哈希,得到一个Merkle root,完成压缩
- 最后,将Merkle root放入比特币网络的Block Header区块标头中
+
+
**比特币网络解决账本的中心化问题的方法——工作量证明**
Proof of Work (PoW) 工作量证明是一种方法,其核心理念是**“信任最多工作量的结果”**,在区块链的世界里,这意味着矿工/参与者信任最长的那条区块链。
+
+
要解释这一点首先要介绍工作量的来源,也是散列函数计算哈希导致的。首先先介绍比特币区块标头的数据结构:前一个区块的哈希值(Prev Hash,又称哈希指针)+随机数(Nonce)+在上文中我们描述的由Merkle tree压缩的当前区块的交易记录+时间戳。比特币的工作量来源于这个随机数,这是因为网络鼓励矿工去找到一个随机数使得整个区块标头经过散列函数(SHA256)计算后的哈希值**前若干位**为0,例如`0000000000000000000ec8769a995429b85e6301c97fa76de6fb9bc5162b27de`
同时,比特币网络要求大约十分钟出一个块,这意味着随机数前导0的数量是动态的,当矿工算力变强,前导0的数量要求会更高,反之更少。
那么“信任最多工作量的结果”是什么意思呢?假设有恶意者试图使用假的交易记录蒙骗其他人,那他会构建一个假的Merkle tree和一个Nonce合并Prev Hash和时间戳发送给其他所有人,**且大家一定会接受!这是因为它满足要求**(前一个区块的哈希值正确、足够的前导0以及符合要求的时间戳);但有其他矿工同时在工作,他们大概率不是同谋,所以他们有真的交易记录也会生成一个符合要求的区块标头,其他人也会接受,这时,所有人拥有两份不同且同样长度的区块链,这也就是所谓“冲突”。随着下一个十分钟,新的区块出来,为了实现攻击恶意者必须超过其他所有人计算出正确的随机值,一旦有人抢先,那么其他矿工将会受到一个不同与恶意者发布的且长度更长的区块链,届时攻击将失败。因此,恶意者必须在随后N个区块内保持领先,但根据研究,若恶意者不拥有超过网络50%总算力将无法实现攻击,这就是著名的“51攻击”。
+
但十分钟出一个区块的限制导致了交易手续费昂贵且效能不足,这也就是以太坊和其他公链谈及的“Scaling 扩容”问题
@@ -207,4 +214,27 @@ BitTorrent 旨在解决依赖中心化服务器下载大文件导致的网络堵
- [以太坊账户|EF](https://ethereum.org/zh/developers/docs/accounts/)
+### 2025.02.14
+#### 防止Replay 重放攻击
+以太坊网络和比特币网络防止重放攻击的方式不同。比特币网络通过交易标头的时间戳而以太坊依靠Nonce。
+
+对于比特币网络,因为任何一个矿工都可以从前一个区块读取某一笔交易的信息,假设没有时间戳,
+一笔交易虽然被签名了,恶意的矿工虽然没有私钥,但它只需要将这个签名后的信息广播到新的区块就可以反复执行该笔交易,
+因为签名是真的,验证函数会回传True。
+
+但有了时间戳,假设A想要攻击B,最快只能在区块确认他收款之后进行,也就是他获得B的签名之后。这时A广播他获得的签名会发生什么?
+答案是会被区块拒绝,**因为时间戳显示它来自上一个区块**(~10min/block)。
+
+而以太坊通过Nonce防止重放攻击。以太坊中Nonce是一个账户的交易计数,
+**执行层会优先执行同一个账户Nonce较小的交易(TX2会在TX1被接受或取消之后才会进行处理),
+且同一Nonce的交易只会执行一次(优先费高的)**
+
+先让我们忽略Gas fee的问题,假设发送者想做坏事,他有一个ETH,先发送一个ETH(`TX1`),
+后又发送一个ETH(`TX2`),`TX2`会被拒绝,因为他账户不足;
+他不服气,复制了一份`TX1`再广播一次(记为`TX1'`,假设此时TX1还没被接受),
+但`TX1`或`TX1'`会直接被拒绝,因为只会接受一次Nonce等于1的交易。
+
+这下他十分生气,决定做接收者并且再做坏事,当他母亲给他打生活费时,他复制了这笔交易企图获得更多,、
+但也被拒绝了,因为交易中包含了**区块编号**,改变好已经被打包过了!
+
diff --git a/hotoo.md b/hotoo.md
index 1b415e7..a6a3a06 100644
--- a/hotoo.md
+++ b/hotoo.md
@@ -66,7 +66,10 @@ timezone: Asia/Shanghai
### 2025.02.13
> 周四
-笔记内容
+- https://epf.wiki/#/eps/week7-dev
+- Reth docs https://paradigmxyz.github.io/reth/
+- Intro to Reth by Georgios https://www.youtube.com/watch?v=zntRpCKHyDc
+- Deeper insight by Dragan https://www.youtube.com/watch?v=pxhq7YrySRM
### 2025.02.14
> 周五
diff --git a/jjeejj.md b/jjeejj.md
index 42f8f69..65c302e 100644
--- a/jjeejj.md
+++ b/jjeejj.md
@@ -109,5 +109,14 @@ timezone: Pacific/Auckland # 新西兰标准时间 (UTC+12)
1. Week4: 主要讲测试和安全方面
1. 存在很多工具,都没有用过啊,感觉有点头大
+### 2025.02.13
+
+1. 今天发现 下面的 Protocol Wiki 对应上面的每一周的内容
+2. 今天发现 再 ETH 架构图里面 有一个 Beacon APIS 的东西,一组 HTTP API 接口。 总得来说 就是把共识层相关的能力和数据通过 API 接口暴露出去
+ 1. 可以查询链上数据:最新区块信息,查询验证者状态等
+ 2. 提交验证者的证明、提交区块的提议
+ 3. 监控和调试
+ 4. 治理和配置
+
diff --git a/k66.md b/k66.md
index 9af1702..c613171 100644
--- a/k66.md
+++ b/k66.md
@@ -126,7 +126,7 @@ Week3
Week3
+ 承續前一日,week3影片,但我不太懂,想說之後回頭再看一遍。
- - [ ] 回頭再看一遍
+ - TODO [ ] 回頭再看一遍
Week4
+ 講安全及測試
@@ -157,7 +157,7 @@ Week4
+ [EVM testing](https://github.com/ethereum/tests): 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

-- [ ] 之後回頭完成[test Filling Execution Spec](](https://github.com/ethereum/execution-spec-tests))
+- TODO [ ] 之後回頭完成[test Filling Execution Spec](](https://github.com/ethereum/execution-spec-tests))
+ `src/`和`test/`和`opcodes`和`./fixtures`:
- test/下有各hard fork
- opcodes/下的test_dup.py
@@ -167,5 +167,18 @@ Week4
+ [Consensus Layer Testing](https://github.com/ethereum/consensus-specs/tests): Written in Python
+ [Cross-Layer Testing](https://github.com/ethereum/hive), [ethpandaops](https://github.com/ethpandaops/assertoor), [kutosis-tech](https://github.com/kutosis-tech/ethereum-package/)
+### 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文章](https://hackmd.io/@vbuterin/stark_aggregation)
+
++ 明天繼續19:13 Surge往下讀
++ 今天有殘酷共學zoom meeting
+
diff --git a/kernel1983.md b/kernel1983.md
index 4dcc887..33bfcef 100644
--- a/kernel1983.md
+++ b/kernel1983.md
@@ -130,4 +130,9 @@ EVM 在执行中必须访问全局状态,如果是默克尔根或者 Verkle
学习BLS的过程中,重新理解一下pairing https://epf.wiki/#/wiki/Cryptography/bls?id=how-bls-works 看看经典的 pairing 可以设计什么有意思的方案。
+### 2025.02.14
+
+发现 https://github.com/ethereum/execution-specs/tree/master/src/ethereum 里面有一些宝库,有完整的所有 fork 的 python 实现,并且这个是权威的。
+这个应该就是 py-evm 的各个版本快照。找时间运行一下,看看需不需要魔改。
+
diff --git a/kidneyweakx.md b/kidneyweakx.md
index 897aaa2..2001910 100644
--- a/kidneyweakx.md
+++ b/kidneyweakx.md
@@ -69,4 +69,7 @@ EL Client 今天看的相對比較熟,之前玩過 quorum 和 besu 設計挺
# 2025.02.12
EVM 這篇教學不錯,有圖解很詳細,不過我還要多看看下面的 ref
+
+# 2025.02.13
+開始看 ref 最近的心得都比較少...
\ No newline at end of file
diff --git a/liuxulife.md b/liuxulife.md
index 39c0650..22c2e81 100644
--- a/liuxulife.md
+++ b/liuxulife.md
@@ -35,4 +35,28 @@ timezone: Asia/Shanghai
### 2025.02.09
EIP-4844,也称为 proto-danksharding,是 Deneb/Cancun 硬分叉的一部分。它为以太坊引入了数据可用性层,允许在区块链上临时存储任意数据。这种以这种方式存储的任意数据称为 blob,每个块可以有 3 ~ 6 个 blob sidecar(blob 的包装器)。EIP-4844 标志着以太坊迈向分片和可扩展性的第一步,使第 2 层解决方案 (L2) 能够使用此数据可用性层来降低 gas 费用并处理更多交易。
+### 2025.02.10
+如何在以太坊权益证明中执行交易
+发起交易:用户通过钱包工具签署交易,设定燃料费(小费给验证者,基础费被销毁),并通过节点提交至以太坊网络。
+验证交易:节点检查交易有效性(余额足够、签名正确),通过后存入本地待处理交易池(内存池),并广播给全网节点。部分高级用户会绕过广播,直接将交易发送给专业区块构建者以优化收益(如利用MEV策略)。
+打包区块:当前时隙的随机选中的验证节点(提议者)将内存池交易打包为“执行负载”,生成状态变更数据,并封装到包含共识信息的“信标区块”中。
+全网验证:其他节点收到新区块后,在本地重新执行交易以验证有效性。验证者确认区块合法后,将其加入自身数据库,并基于多数共识(分叉规则)认可其为链上新头区块。
+最终确认:交易需在两个连续时段(检查点)间获得超过66%质押以太坊的共识验证,方可视为不可逆的“最终确定”状态。检查点机制确保网络周期性达成全局一致。
+
+### 2025.02.11
+权益证明相较于工作量证明有如下一些优点:
+能效更高 – 无需在工作量证明计算中使用大量能源
+门槛更低、硬件要求下降 – 无需购买高性能硬件以便获得创建新区块的机会
+中心化风险降低 – 权益证明应该可以增加保护网络安全的节点
+
+### 2025.02.12
+• Phase0 – 未来升级的准备阶段,引入主要的信标链状态和权益证明(PoS)设计。大多数基础规范在这个硬分叉中建立。
+• Altair – 继续为从工作量证明(PoW)迁移到权益证明(PoS)做准备。这个硬分叉引入了轻客户端协议和“同步委员会”,这是一个由 512 个验证器在每个“同步委员会周期”(约 1 天)中伪随机选择的特殊子集。这些验证器不断签署新的信标区块头,使得“外部”的轻客户端能够以显著简化的复杂度验证共识状态。
+• Bellatrix – 这个硬分叉标志着正式转向权益证明,使用在早期硬分叉中引入的规范。它作为“合并”的“开启”开关。
+• Capella – 这个硬分叉启用了验证器的提现,这在之前的版本中是禁用的。它通过允许验证器提取奖励,最终确定了以太坊 PoS 的完整经济模型。
+• Deneb – 在撰写本文时最新的硬分叉(2025 年 1 月)。它将信标区块根添加到以太坊虚拟机(EVM),这是跨链证明以太坊共识的重要变化,并更改了一些与证明和激活/退出限制相关的值。
+• Electra – 一个未来的硬分叉,将验证器的最大有效余额从 32 ETH 增加到 2048 ETH,允许整合许多冗余的验证器。此外,它引入了对存款和提现的重大更改,使其更快、更灵活。
+• Fulu – 目前正在建设中。
+
+
diff --git a/lllapland.md b/lllapland.md
index 071b676..4190290 100644
--- a/lllapland.md
+++ b/lllapland.md
@@ -257,9 +257,16 @@ https://epf.wiki/#/eps/week3
- etc.
+### 2025.02.13
+https://epf.wiki/#/eps/week4
-
+#### Execution Layer Testing
+#### Consensus Layer Testing
+#### Cross-Layer (interop) Testing
+#### Security
+---
+(不行……困飞了,今天虚假签到一下……我是有听了15分钟的课的,但是感觉啥也没记下来噗……)
diff --git a/luffythink.md b/luffythink.md
index c6ce225..fb31696 100644
--- a/luffythink.md
+++ b/luffythink.md
@@ -117,4 +117,39 @@ EPF 学习小组是一个实时网络研讨会式项目,由两个阶段组成
- LMD-GHOST 和 Casper FFG:PoS 机制支持的核心协议。
- 新共识机制:PoS 下的共识是通过质押、验证者的证明以及随机选择区块提议者和委员会的算法来实现的,以确保网络保持安全并高效地处理交易。
+### 2025.02.13
+**学习主题:Beacon Chain as Consensus Manager**
+- Validators as PoS Participants
+ - Staking ETH
+ - Proposing Blocks
+ - Attesting Blocks
+- Committees and Randomness
+
+
+
+
+
+
+
+### 2025.02.14
+**学习主题:Beacon Chain**
+
+- **Design for Scalability and L2 Solutions (EIP-4844 and Blobs):** EIP-4844 (proto-danksharding) addresses Ethereum's scalability needs by introducing Blobs, enabling a separate data availability layer.
+
+- **Validators as the Core Participants:** Central to PoS are validators, who replace miners. Validators stake ETH and are tasked with proposing and attesting to blocks, ensuring the network’s integrity.
+
+- **Validator Selection and Committees:** Validators are pseudo-randomly chosen as block proposers. They are also organized into committees for attestation and validation duties. This randomization is secured using RANDAO and VDF, and also offers advantages from a scaling mechanism to ensure better chain validation due to size limits.There are mechanisms are put in place to help regulate the number of active validators, such as limiting the number of validations and rewards/penalties.
+
+- **Attestation as Voting Mechanism:** Each validator attests, or vote, to the blocks they see as the correct one with this, a new type of way to provide security is created.
+
+- **Checkpoints and Finality:** The blocks on the chain become valid and secure with two thirds majority vote.
+
+- **Storage costs:** In Ethereum, storing the information from 1 chain creates long term costs. All blob data is designed to be stored temporarily on the chain.
+
+- **Incentives and Disincentives (Rewards and Penalties):** The core principle of Ethereum's PoS relies on incentivizing honest behavior and punishing malicious actors.
+
+- **Epochs and Slots:** The system operates based on slots and epochs, to help regulate the chain and implement PoS.
+
+- **Validator Lifecycle Management:** They are subject to the system's rewards and penalties, are monitored for malicious behavior, have their movements monitored, and are all recorded in the state of the network.
+
diff --git a/marvelshan.md b/marvelshan.md
index bc01a63..3a1d025 100644
--- a/marvelshan.md
+++ b/marvelshan.md
@@ -660,5 +660,76 @@ Reth引入了執行擴展(Execution Extensions,簡稱ExEx),這是一個
### 2025.02.13
+### 2025.02.14
+
+### 交易(Transaction)筆記
+
+#### 定義
+交易是由外部帳戶發出的加密簽名指令,透過 JSON-RPC 廣播至整個網絡。
+
+#### 交易包含的欄位
+
+1. **Nonce(交易計數)**
+ - 這是一個整數值,等於發送者已發送的交易數量。
+ - 作用:
+ - **防止重放攻擊**:由於每筆交易的 Nonce 是唯一的,EVM 會拒絕已存在的交易,防止惡意重播交易。
+ - **決定智能合約地址**:在創建合約時,Nonce 與發送者地址一起決定合約帳戶的地址。
+ - **替換交易**:如果交易因為低 Gas 價格而卡住,可發送相同 Nonce 但更高 Gas 價格的新交易來取代舊交易。但是否成功取決於礦工與網絡條件。
+
+2. **Gas Price(燃料價格)**
+ - 這是一個整數值,表示每單位 Gas 需要支付的 Wei 數量。
+ - 1 ETH = \(10^{18}\) Wei。
+ - Gas Price 決定了交易的優先級,越高的 Gas Price 越可能被礦工優先打包進區塊。
+
+3. **Gas Limit(燃料上限)**
+ - 這是一個整數值,代表此交易執行時允許消耗的最大 Gas 數量。
+ - 如果執行時 Gas 消耗超過 Gas Limit,交易會失敗。
+
+4. **To(接收者地址)**
+ - 這是一個 20 字節的地址,表示此交易的接收者。
+ - `to` 欄位也決定了交易的模式或目的,例如發送 ETH 或部署智能合約。
+
+#### **TestRPC(本地私有區塊鏈)**
+✅ **優點**:
+- 無需同步區塊鏈,啟動快,幾乎無磁碟需求。
+- 測試Ether無限制,可自行挖礦獲取獎勵。
+- 只有你一個用戶,環境可控。
+- 沒有其他合約影響測試結果。
+
+❌ **缺點**:
+- 缺少真實區塊鏈的交易競爭與排序機制。
+- 挖礦預測性強,無法測試公開網路的不確定性。
+- 需自行部署所有依賴的智能合約與庫。
+- 不能重現公共合約及其地址來測試特定場景。
+
+---
+
+#### **以太坊客戶端運行(Geth & Parity)**
+**完整節點運行條件**:
+- **最低需求**:2核CPU、80GB SSD、4GB RAM(HDD需8GB)、8+ MBit/sec網速。
+- **推薦配置**:4核以上CPU、16GB RAM、500GB SSD、25+ MBit/sec網速。
+
+🔹 **Geth(Go-Ethereum)**:
+- 以Go語言編寫,官方支持度高。
+- **安裝方式**:GitHub獲取原始碼 ➝ `make geth` 編譯 ➝ `geth version` 檢查。
+- **快速同步模式**(`--fast`)可減少區塊驗證時間。
+
+🔹 **Parity**:
+- 以Rust語言開發,運行效率高。
+- **安裝方式**:GitHub獲取原始碼 ➝ `cargo build` 編譯 ➝ `parity --version` 檢查。
+- **快速同步**(舊版`--warp`,1.6+ 版本自動啟用)。
+
+---
+
+#### **以太坊區塊鏈同步與JSON-RPC**
+- **完整同步**:下載並驗證所有區塊與交易,較慢但數據完整。
+- **快速同步**:僅同步最新區塊,提升速度但省略歷史驗證。
+- **JSON-RPC API**:
+ - 用於與以太坊網絡交互的標準接口(HTTP 8545)。
+ - 限制本地訪問,提高安全性,可用於智能合約調用與交易管理。
+
+參考:
+
+[蜜蜂書第三章](https://cypherpunks-core.github.io/ethereumbook_zh/)
diff --git a/mrmign.md b/mrmign.md
index 0247f06..7be7057 100644
--- a/mrmign.md
+++ b/mrmign.md
@@ -261,7 +261,17 @@ Learn [Inevitable Ethereum - World Computer](https://inevitableeth.com/home/ethe
- Contentious Hard Fork
- Malicious hard fork
### 2025.02.14
-
+- Accounts over UTXOs
+ - UTXO: an unspent transaction output is a distinctive element in a subset of digital currency models. A UTXO represents a certain amount of cryptocurrency that has been authorized by a sender and is available to be spent by a recipient.
+ - Benefits of Accounts
+ - Space Saving.
+ - Great fungibility
+ - Simplicity
+ - Weakness
+ - in order to prevent replay attacks, every transaction must have a nonce.
+ - account keeps track of the nonces used and only accept a transaction if its nonce is 1 after the last nonce used.
+- Merkle Patricia Trie(MPT)
+ - A Merkle-Patricia trie is deterministic and cryptographically verifiable
### 2025.02.15
### 2025.02.16
diff --git a/phoebe-dot.md b/phoebe-dot.md
index 17b03a2..7f2cfdd 100644
--- a/phoebe-dot.md
+++ b/phoebe-dot.md
@@ -67,6 +67,23 @@ Note
### 2025.02.13
+reading a paper Ethereum Data Structures from KAMIL JEZEK, University of Sydney... move forward hardly 😎
+
+### 2025.02.14
+
+finished read the paper
+ Ethereum Protocol Studies 2025 Town Hall
+
+### 2025.02.15
+
+Note
+
+### 2025.02.16
+
+Note
+
+### 2025.02.17
+
Note
diff --git a/poyucheese.md b/poyucheese.md
index e3f9fc5..a4f656d 100644
--- a/poyucheese.md
+++ b/poyucheese.md
@@ -82,4 +82,23 @@ week 4 是有關 Ethereum 測試的內容。
- 用於確保 Ethereum 執行客戶端的正確性,避免因實作差異導致的鏈分叉,需要 EVM testing 進行測試,為客戶端提供相同 pre-state (賬戶餘額、nonce、合約代碼和存儲)、環境、輸入 (交易) 、規則,預期得到相同的 post-state。
- Test Filling 可以跨客戶端執行,確保所有實作遵循相同的行為。
+### 2025.02.13
+
+#### [SGweek4](https://epf.wiki/#/eps/week4)
+
+##### EVM 測試格式
+
+- 狀態測試(State Testing):
+ - 透過比對狀態根(State Root)來驗證不同客戶端的結果是否一致。
+ - 狀態根是一種加密計算結果,可確保狀態完整性。
+
+- 模糊測試(Fuzzy Differential State Testing):
+ - 使用工具 FuzzyVM 在交易中加入隨機智能合約代碼,測試不同客戶端是否仍能保持相同的狀態根。
+
+- 區塊鏈測試(Blockchain Testing):
+ - 測試不僅限於 EVM 執行,還包括 1559 費用機制等完整區塊驗證。
+
+- 區塊鏈負測試(Blockchain Negative Testing):
+ - 插入無效區塊,檢查客戶端是否能正確拒絕此區塊並 revert 到先前的有效區塊。
+
diff --git a/ppatrick007.md b/ppatrick007.md
index 345e74b..2e48bd1 100644
--- a/ppatrick007.md
+++ b/ppatrick007.md
@@ -205,12 +205,29 @@ Hi, 我是国内一名理科研究生,会一些编程语言,平时科研主
### 2025.02.12
-# 第七天打卡
-
今天总结了前几天的内容,重点回顾了共识层(Consensus Layer)和执行层(Execution Layer)的规范和基础知识。
没有接触到新的技术内容,主要是通过前几天的学习材料进行巩固和整理。通过对规范的理解和总结,我对以太坊协议的各个部分有了更加系统的认识。
-
在接下来的学习中,将继续深化对协议各层次的理解,并准备好进入更深入的技术分析阶段。
+### 2025.02.13
+
+今天继续学习了Upgrading Ethereum书中共识协议的相关内容,主要总结了以下几个部分:
+
+## 1. 共识协议的基础
+共识协议是建立可靠分布式系统的基础。其目标是让多个节点在不可靠的环境下达成一致,形成单一的交易历史。每个节点维护一个账本,确保所有账本内容一致,达成一致并迅速确认。
+
+## 2. 区块链的基本概念
+区块链的基本单位是“区块”,每个区块包含交易数据,并通过特定的规则链接到前一个区块,形成区块链。每个区块的选择和排序由“区块领导者”决定,区块领导者是通过特定的共识机制(如工作量证明、权益证明等)选举出来的。
+
+## 3. 分叉与分叉选择规则
+在真实的网络环境中,区块链可能出现“分叉”现象,即多个区块链分支并存。区块链协议通过分叉选择规则来确定最终被认可的链。这一规则确保所有正确的节点最终会达成一致,选择一个唯一的线性链。
+
+## 4. 算法背景
+讨论了“拜占庭将军问题”和实际解决方案,比如PBFT和Nakamoto共识。PBFT能够确保协议的“安全性”,但在异步网络中失去活跃性,而Nakamoto共识则允许分叉,注重“活跃性”而非“安全性”。
+
+## 5. 工作量证明与权益证明
+虽然工作量证明(PoW)和权益证明(PoS)都被称为共识协议,但实际上它们并不是独立的共识协议,而是支持共识协议的机制,确保系统具有抗Sybil攻击的能力。
+
+
diff --git a/rayjun.md b/rayjun.md
index 4b7ed5f..2f1830c 100644
--- a/rayjun.md
+++ b/rayjun.md
@@ -265,5 +265,39 @@ EVM 中有一些关键的组件:
- 被 slashed 退出,需要等待 36 天左右才能提款
- 正常退出,27 小时左右就可以提款
+### 2025-02-14
+- 分叉选择机制:LMD GHOST + Casper FFG
+ - Casper FFG 确定检查点,确保已经 Finality 的检查点永远不会撤销
+ - LMD GHOST 会确定当前最新的区块应该基于哪个分支去构建,基于哪个分支的累加投票数量去决定
+ - 所有正常运行的节点都会根据同一条链追溯到 Genesis 区块
+ - 由于网络延迟等问题,节点可能会对最新的几个区块进行重组,几回到之前的某个区块,重新开始同步区块,而废弃已经构建了的几个区块
+ - 在共识系统了,有两个概念很重要:Safety 和 Liveness
+ - Safety:它保证一致性,意味着所有诚实节点应该始终就区块链的状态达成一致
+ - Liveness:确保区块链可以持续产生新的区块
+ - Safety 和 Liveness 对应 CAP 中的一致性和可用性,所以当区块链网络出现问题时,一致性就很难得到保证了,这样就保证了可用性和分区容忍性,但这样做的结果就是让链分叉
+ - LMD GHOST 保证 Liveness,Casper FFG 通过定期确定 Checkpoint 来保证 Safety,保护区块链不被逆转
+- 控制流程:
+ - 但共识客户端不是 Block Proposer 时
+ - 通过 Gossip 协议接收一个区块
+ - 验证区块的有效性
+ - 将区块中的交易发送到执行层
+ - 执行层执行交易并验证区块状态
+ - 执行层将验证数据发回共识层
+ - 共识层将区块添加到区块链并对其进行证明,并通过网络广播该证明
+ - 但共识客户端作为 Block Proposer
+ - 收到成为下一个区块生产者的通知
+ - 调用客户端中创建区块的创建方法
+ - 执行层访问交易内存池
+ - 执行层将交易打包层区块,并执行交易,生成区块 hash
+ - 共识客户端就交易和区块 hash 驾到信标链区块
+ - 共识客户端通过 gossip 协议广播这个区块
+ - 其他客户端验证这个区块并为它提供投票证明
+ - 一旦得到足够多的 Validator 的证明,改区块就会被添加到链的头部,得到证明和完成最终性(Finality)
+- 网络层
+ - libp2p 作为点对点协议
+ - discv5 作为对等发现
+ - libp2p-noise 用作加密
+ - SSZ 作为序列化协议
+ - Snappy 作为压缩协议
diff --git a/rectinajh.md b/rectinajh.md
index a4136bd..139c208 100644
--- a/rectinajh.md
+++ b/rectinajh.md
@@ -40,4 +40,12 @@ https://epf.wiki/#/wiki/EL/el-specs
### 2025.02.12
今天学习执行层客户端的架构设计
https://epf.wiki/#/wiki/EL/el-architecture
+
+### 2025.02.13
+今天学习不同的客户端,不同开发语言的实现,不同平台比如联盟链和公链平台的客户端实现
+https://epf.wiki/#/wiki/EL/el-clients
+
+### 2025.02.14
+今天学习evm层
+https://epf.wiki/#/wiki/EL/evm
diff --git a/yahsinhuangtw.md b/yahsinhuangtw.md
index 32f017e..f4f83ec 100644
--- a/yahsinhuangtw.md
+++ b/yahsinhuangtw.md
@@ -62,4 +62,36 @@ https://youtu.be/UihMqcj-cqc?si=MqL3ac9Xg30LPJmE
還有一段提到 EIP-7702 這個改進,最關鍵的改動是,之後 EOA 可以搖身一變成合約。老師文中舉例,如果你填一個 Safe 合約地址,那你的 EOA 就會變身成為 Safe 合約。
+### 2025.02.13
+晚上殘酷學習時間,聽完整整一個半小時的 matt 老師報告(Study Group Week 2 | Execution Layer)https://epf.wiki/#/eps/week2
+覺得老師好厲害,可以這樣邊打字邊解釋說明很多細節。同時也感覺到整個系統的複雜性。
+
+
+
+### 2025.02.14
+
+今晚的殘酷學習時間聽了 Alex Stokes 老師怎麼介紹「狀態機複製 State machine replication」概念。https://en.wikipedia.org/wiki/State_machine_replication
+
+很多年前,曾經和 Alex 老師有一面之緣,簡單打過招呼,可能是在 2019 年澳洲雪梨的那次。記得當時他沒有留鬍子,看起來很年輕,有種獨特的優雅氣質。現在好像全然變一個人的樣子,似乎個人風格有變化,覺得有點奇妙。
+
+
+
+以下這邊開始就是我邊聽邊打字出來的內容,一方面練習英文聽力,一方面期望進一步強化 狀態機複製 State machine replication 的概念理解。
+
+Ethereum Consensus Layer | Alex Stokes | Week 3
+https://www.youtube.com/live/FqKjWYt6yWk?si=w0jmYFctZtqgVG7G
+
+https://epf.wiki/#/eps/week3
+
+One topic being discussed by the lecturer, Alex Stokes, was the concept of consensus via “state machine replication.” The following are his words introducing this concept in about 2 minutes (lecture video time 20:13–21:39).
+
+This concept is called “state machine replication.” The “replication” here refers to the fact that we have multiple nodes in the system; they essentially all duplicate the same work. This is like an input log to get the same output. In particular, this is what we mean by consensus: every node in the system should eventually agree on the outputs.
+
+You write your program or protocol as a deterministic function of the inputs. Imagine then that if you have an honest node, they’re going to run the same function on the same inputs, and they have to get the same output, right? This is assuming there are no bugs or anything in the protocol. For the same set of inputs, you get the same output.
+
+This is useful to get rid of our single trusted operator because as the number of nodes increases, this becomes harder to attack. Rather than exploring a bug on one node and taking down the whole system, you now have to attack, say, two or three, or maybe all of them. And there’s this notion of a majority in the system. This is really what we mean when we say consensus: at any point in time, there should be some majority of nodes that all have the same view, the same output, or the same state.
+
+When they do this, then, even if some of the nodes are faulty, you still have a majority of them saying, "This is the state of the world." So, the idea is that it becomes much harder now to attack our system as we have more nodes who are doing the same thing.
+
+
diff --git a/zhouCode.md b/zhouCode.md
index 78270a8..d939d32 100644
--- a/zhouCode.md
+++ b/zhouCode.md
@@ -635,4 +635,50 @@ func build(env Environment, pool txpool.Pool, state state.StateDB) (types.Block,
- **数据目录与网络配置**:指定数据存储路径及网络参数(如`--datadir`和`--network`)
- **同步模式**:解释全同步(Full Sync)与快照同步(Snap Sync)的区别
- **JWT认证**:配置执行层与共识层通信的JWT密钥
+
+### 2025.02.14
+
+开始实践
+
+#### 尝试建立私链
+
+[ethpandaops/ethereum-package:一个 Kurtosis 包,用于部署私有、可移植和模块化的以太坊开发网 --- ethpandaops/ethereum-package: A Kurtosis package that deploys a private, portable, and modular Ethereum devnet](https://github.com/ethpandaops/ethereum-package)
+
+#### Quickstart 快速入门
+
+1. [Install Docker & start the Docker Daemon if you haven't done so already](https://docs.docker.com/get-docker/)
+
+2. [Install the Kurtosis CLI, or upgrade it to the latest version if it's already installed](https://docs.kurtosis.com/install)
+
+3. Run the package with default configurations from the command line:
+
+ ```
+ kurtosis run --enclave my-testnet github.com/ethpandaops/ethereum-package
+ ```
+
+#### Run with your own configuration
+
+Kurtosis packages are parameterizable, meaning you can customize your network and its behavior to suit your needs by storing parameters in a file that you can pass in at runtime like so:
+
+```
+kurtosis run --enclave my-testnet github.com/ethpandaops/ethereum-package --args-file network_params.yaml
+```
+
+Where `network_params.yaml` contains the parameters for your network in your home directory.
+
+#### Run on Kubernetes
+
+Kurtosis packages work the same way over Docker or on Kubernetes. Please visit our [Kubernetes docs](https://docs.kurtosis.com/k8s) to learn how to spin up a private testnet on a Kubernetes cluster.
+
+#### Considerations for Running on a Public Testnet with a Cloud Provider
+
+When running on a public testnet using a cloud provider's Kubernetes cluster, there are a few important factors to consider:
+
+1. State Growth: The growth of the state might be faster than anticipated. This could potentially lead to issues if the default parameters become insufficient over time. It's important to monitor state growth and adjust parameters as necessary.
+2. Persistent Storage Speed: Most cloud providers provision their Kubernetes clusters with relatively slow persistent storage by default. This can cause performance issues, particularly with Execution Layer (EL) clients.
+3. Network Syncing: The disk speed provided by cloud providers may not be sufficient to sync with networks that have high demands, such as the mainnet. This could lead to syncing issues and delays.
+
+To mitigate these issues, you can use the `el_volume_size` and `cl_volume_size` flags to override the default settings locally. This allows you to allocate more storage to the EL and CL clients, which can help accommodate faster state growth and improve syncing performance. However, keep in mind that increasing the volume size may also increase your cloud provider costs. Always monitor your usage and adjust as necessary to balance performance and cost.
+
+For optimal performance, we recommend using a cloud provider that allows you to provision Kubernetes clusters with fast persistent storage or self hosting your own Kubernetes cluster with fast persistent storage.