Merge branch 'main' of https://github.com/IntensiveCoLearning/Ethereu…

…m-Protocol-Fellowship

CHENFANGC.md

@@ -180,4 +180,9 @@ EOA 可以发起交易，交易类型包括：
 
 安全和活跃的保证是以太坊去中心化基础设施的核心。形式化验证在验证以下各项的正确性方面起着关键作用
 
+### 2025.02.13
+
+- week 2 视频观看完成，深入研究以太坊的执行层。深入探讨 Lightclient 的 EL 内部结构。
+- 阅读了关于 EVM 的一些介绍。https://www.evm.codes/about
+
 <!-- Content_END -->

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，打卡过了这些内容，但是扩展的是一点没看，总算搞的差不多了，明天把错过的两次会议回看下～
+
 <!-- Content_END -->

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底层原理。
 
 <!-- Content_END -->

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.
+
 <!-- Content_END -->

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
 <!-- Content_END -->

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
 
 <!-- Content_END -->