| timezone | Asia/Shanghai |
|---|
- 智能合约开发者 想要学习协议层的知识
- 你认为你会完成本次残酷学习吗？会
笔记内容
We publish our code so that our fellow Cypherpunks may practice and play with it. Our code is free for all to use, worldwide. We don’t much care if you don’t approve of the software we write. We know that software can’t be destroyed and that a widely dispersed system can’t be shut down. 看了UNIX系统的档案 伟大的软件总是与开源文化息息相关。以太坊的开放、独立和协作开发文化深深植根于 FOSS， 这种文化是以太坊的基石，也是以太坊最大的不可替代性。 以太坊协议设计的基本哲学：简单性、通用性、模块化、无歧视性、敏捷性
Consensus Layer： process_execution_payload 验证执行层的区块是否合法，共识层和执行层通过Engine API进行通信，CL没有验证区块的能力，会将execution payloads通过notify_new_payload函数发送到EL，EL会执行状态转移的函数(STF) 代码 Excution layer (EL):
先验证区块头，再执行一遍交易，最后返回更新后的stateDB
- Environment: incl. Timestamps, block number, previous block, base fee, etc.
- Tx pool: Maintain the list of txns, ordered by their value
- StateDB
通过pool.Pop()方法获取当前内存池中gas费用最高的交易执行，重复这一过程直到达到gas limit。最后调用finalize方法产出最终的区块
engine_exchangeCapabilities: Used to exchange the Engine API methods supported by each client.
engine_forkchoiceUpdatedV2: Updates the fork choice of the Execution Layer Client. Also used to start a payload build process.
engine_getPayloadV2: Used to retrieve an execution_payload from a build process started in a past engine_forkchoiceUpdatedV2 call.
engine_newPayloadV2: Used by the consensus layer client to send an execution_payload to the execution layer client for it to validate it.
What's Byzantine fault tolerance (BFT)? • Byzantine fault tolerance (BFT) is the property of a system that is able to resist the class of failures derived from the Byzantine Generals' Problem. This means that a BFT system is able to continue operating even if some of the nodes fail or act maliciously.
Two-phase commit (2PC)
Make attestation: i.e. Validator makes cryptographic signature over the state of the chain Different types of attestations • LMD GHOST vote: Validator attests to the beacon chain head • Casper FFG vote: Validator attests to the checkpoint in its current epoch
Every 12 seconds there will be a new slot, and every slot will have a block. A slot is like the block time, but slots can be empty slot分为三个阶段 paradigm blog
Each epoch has 32 slots. The reason behind creating the epoch is to reduce the
frequency of consensus processing, so that it doesn't need to happen in every slot
Allow block proposer to outsource block construction, so that validators can continue running on consumer-grade hardware without missing out MEV exposed
https://medium.com/@jamaltheatlantean/what-is-gasper-20f6697d3dc6
Gasper结合了**Casper FFG（Friendly Finality Gadget）和LMD-GHOST（Latest Message Driven - Greediest Heaviest Observed SubTree）
▪ Validators within the network will be randomly shuffled under different committees. ▪ Each validator will make one attestation per epoch. The exact slot the validator is assigned is determined by the protocol through RANDAO. 出于安全考虑，每个 slot 至少有 128 名验证者的委员会。攻击者控制委员会 2/3 的概率不到万亿分之一。
▪ Finality means that a tx is part of a block that can't change. ▪ Justification: When an epoch ends, if its checkpoint has gathered a 2/3 supermajority, the checkpoint gets justified. ▪ Finality: When a checkpoint is justified, the previous checkpoint that is already justified becomes finalized
A checkpoint is a block in the first slot of an epoch. If there is no such block, then the checkpoint is the preceding most recent block. There is always one checkpoint block per epoch. A block can be the checkpoint for multiple epochs.
When casting an LMD GHOST vote, a validator also votes for the checkpoint in its current epoch, called the target. This vote is called a Casper FFG vote, and also includes a prior checkpoint, called the source. In the diagram, a validator in Epoch 1 voted for a source checkpoint of the genesis block, and a target checkpoint of the block at Slot 64. In Epoch 2, the same validator voted for the same checkpoints. Only validators assigned to a slot cast an LMD GHOST vote for that slot. However, all validators cast FFG votes for each epoch checkpoint. Casper FFG 主要负责区块链的最终确定性（finality），确保一旦一个区块被认为是最终的，它就不会被更改。这通过在每个周期（称为epoch）结束时执行检查点来实现。
An attestation contains both an LMD GHOST vote and an FFG vote. Optimally, all validators submit one attestation per epoch. An attestation has 32 slot chances for inclusion on-chain. This means a validator may have two attestations included on-chain in a single epoch. Validators are rewarded the most when their attestation is included on-chain at their assigned slot; later inclusion is a decaying reward. To give validators time to prepare, they are assigned to committees one epoch in advance. Proposers are only assigned to slots once the epoch starts. Nonetheless, secret leader election research aims to mitigate attacks or bribing of proposers
(very) brief overview of MEV ePBS / Inclusion Lists / MEV Burn Max EB, Stake capping
Verkle Trees SNARKify everything
【EIP-4444](https://eips.ethereum.org/EIPS/eip-4444) Protocol simplifications
EIP-1559 endgame Account Abstraction Deep cryptography
node: https://ethereum.org/en/developers/docs/nodes-and-clients/node-architecture/
开始阅读源码
https://github.com/sigp/lighthouse
https://github.com/paradigmxyz/reth
https://github.com/ethereum/consensus-specs/blob/dev/ssz/simple-serialize.md
无符号整数：包括 uint8、uint16、uint32、uint64、uint128 和 uint256，以小端字节序（little-endian）编码。 布尔值：True 编码为 0x01，False 编码为 0x00，占用 1 字节。 字节：单个 byte（8 位），直接存储。
容器（Container）：类似于结构体，包含多个字段，每个字段可以是基本类型或复合类型。字段按定义顺序序列化。 向量（Vector）：固定长度的同类型元素数组，记为 Vector[T, N]，其中 T 是元素类型，N 是长度。 列表（List）：可变长度的同类型元素数组，记为 List[T, N]，其中 N 是最大长度限制。 联合类型（Union）（较少使用）：支持多种类型的选择，包含一个选择器（selector）和对应的值
基本类型和固定长度复合类型（如 Vector）直接按顺序拼接。 示例： uint32(1234) 编码为 [0xd2, 0x04, 0x00, 0x00]（小端字节序）。 Vector[uint16, 3] [1, 2, 3] 编码为 [0x01, 0x00, 0x02, 0x00, 0x03, 0x00]。
对于 List 或包含可变长度字段的 Container，SSZ 使用偏移量机制： 偏移量部分：记录每个可变长度元素在序列化数据中的起始位置，用 4 字节的 uint32 表示。 数据部分：实际的可变长度数据依次拼接在偏移量之后。 示例： Container {a: uint32, b: List[uint32, 8]}，值为 {a: 5, b: [1, 2]}： 序列化为 [0x05, 0x00, 0x00, 0x00, 0x08, 0x00, 0x00, 0x00, 0x01, 0x00, 0x00, 0x00, 0x02, 0x00, 0x00, 0x00]。 前 4 字节是 a 的值，后 4 字节是 b 的偏移量（指向第 8 字节），之后是 b 的内容。
基本类型的 Merkleization
对于基本类型（如 uint32、uint64），直接序列化后补零至 32 字节，作为单一叶节点。 示例：uint32(1234)： 序列化为 [0xd2, 0x04, 0x00, 0x00]（4 字节）。 补零为 [0xd2, 0x04, 0x00, 0x00, 0x00, ..., 0x00]（32 字节）。 哈希树根 = SHA-256([0xd2, 0x04, 0x00, 0x00, 0x00, ..., 0x00])。
固定长度复合类型（Vector、Container）
序列化后按 32 字节分块，构建 Merkle 树。 示例：Vector[uint32, 2] [1, 2]： 序列化为 [0x01, 0x00, 0x00, 0x00, 0x02, 0x00, 0x00, 0x00]（8 字节）。 补零为 [0x01, 0x00, 0x00, 0x00, 0x02, 0x00, 0x00, 0x00, 0x00, ..., 0x00]（32 字节）。 单一叶节点，哈希树根 = SHA-256(上述 32 字节)。
可变长度类型（List）
序列化后分块，计算数据部分的根哈希，然后混合长度。 示例：List[uint32, 8] [1, 2]： 序列化为 [0x01, 0x00, 0x00, 0x00, 0x02, 0x00, 0x00, 0x00]（8 字节）。 补零为 [0x01, 0x00, 0x00, 0x00, 0x02, 0x00, 0x00, 0x00, 0x00, ..., 0x00]（32 字节）。 数据根 = SHA-256(上述 32 字节)。 长度 8 编码为 [0x08, 0x00, 0x00, 0x00, 0x00, ..., 0x00]（32 字节）。 最终哈希树根 = SHA-256(数据根 || 长度)。
容器（Container）
容器字段按顺序序列化，固定长度字段直接拼接，可变长度字段用偏移量指向实际数据。 每个字段的 Merkleization 是独立的，最终哈希树根由所有字段的哈希树根组合而成。
https://github.com/paradigmxyz/revm-inspectors
https://lighthouse-book.sigmaprime.io/slashing-protection.html
a. 数据结构：BeaconState 定义：src/beacon_state.rs 内容： slot：当前槽位（时间单位，12秒/槽）。 validators：验证者列表（状态、余额等）。 latest_block_header：最新区块头。 state_roots：历史状态根（用于验证）。 作用：作为信标链的全局状态，所有操作都基于此更新。 b. 时间推进：Slot Processing 位置：state_processing/per_slot_processing.rs 逻辑： 检查当前槽是否需要更新（state.slot += 1）。 更新 RANDAO（随机种子，由验证者提供）。 处理验证者状态（例如，标记不活跃的验证者）。 目的：确保时间推进，即使没有新区块也能更新状态。 c. 区块处理：Block Processing 位置：state_processing/per_block_processing.rs