├── .William-02-02.assets ├── .zkSync.assets │ └── 163238089532675.jpg ├── 0-1BXeSvoajrHNAD_.png ├── 50.png ├── EIP4844.md ├── image-20250106133525233.png ├── image-20250108215836301.png ├── image-20250110221523916.png ├── image-20250110224052958.png ├── image-20250112183357908.png ├── image-20250112183546766.png ├── image-20250113222030006.png ├── image-20250117165038619.png ├── image-20250120220328489.png ├── image-20250124232734999.png ├── image-20250124233237900.png ├── imageurl=%2F_next%2Fstatic%2Fmedia%2Fhow-retro-funding-works.9368ab75.png ├── imageurl=%2F_next%2Fstatic%2Fmedia%2Fsuperchain-diag.7fc0979f.png ├── zkSync.md ├── 交易流程.md └── 机制说明.md ├── .github └── workflows │ └── ReopBot.yml ├── .gitignore ├── 183Aaros.md ├── 8280998.md ├── A3438.md ├── Alexliwenhao.md ├── CHENFANGC.md ├── CJC824.md ├── ChinesePaladin61.md ├── ChoeyGit.md ├── Coooder-Crypto.md ├── DasNarrenschiff.md ├── Dfbb7879.md ├── HeliosLz.md ├── JacksonStack.md ├── LunaWang5209.md ├── MRzzz-cyber.md ├── MagicalBridge.md ├── Marcus-Chen98.md ├── README.md ├── StarryDesert.md ├── StarryDeserts_assets └── 代币议院和公民议院具体协作图示.png ├── Template.md ├── Thogsloc.md ├── Tianxibi-web3.md ├── William-02-02.md ├── YiShengYouNi.md ├── Zhangdajiang.md ├── amandakelake.md ├── brucexu-eth.md ├── brucexu-eth_assets ├── image-1.png ├── image-2.png ├── image-3.png ├── image-4.png ├── image-5.png └── image.png ├── btcnice.md ├── bxmyzzbc.md ├── chendafu2573.md ├── chenziyu-bxy.md ├── cherry-yl-sh.md ├── debugzhao.md ├── foresteru.md ├── goudanxiaokui.md ├── gpteth.md ├── image.png ├── iossocket.md ├── jiubate888.md ├── jjeejj.md ├── luffythink.md ├── partypill.md ├── pillowtalk-Qy.md ├── punkcanyang.md ├── qiaopengjun5162.md ├── snaildarter.md ├── sonedigo.md ├── stualan.md ├── sync_status_readme.py ├── verygud-0.md ├── wuyanhui.md ├── wyeeeh.md ├── yiwen4.md ├── yoow4536.md ├── zedz.md └── zhengjunhe.md /.William-02-02.assets/.zkSync.assets/163238089532675.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/IntensiveCoLearning/Optimism/3cd922710daa7d7c64a8cf1524512f82a78d2d12/.William-02-02.assets/.zkSync.assets/163238089532675.jpg -------------------------------------------------------------------------------- /.William-02-02.assets/0-1BXeSvoajrHNAD_.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/IntensiveCoLearning/Optimism/3cd922710daa7d7c64a8cf1524512f82a78d2d12/.William-02-02.assets/0-1BXeSvoajrHNAD_.png -------------------------------------------------------------------------------- /.William-02-02.assets/50.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/IntensiveCoLearning/Optimism/3cd922710daa7d7c64a8cf1524512f82a78d2d12/.William-02-02.assets/50.png -------------------------------------------------------------------------------- /.William-02-02.assets/EIP4844.md: -------------------------------------------------------------------------------- 1 | ### **EIP-4844 的关键概念** 2 | 3 | EIP-4844 提出了 **Blob** 的概念。Blob 是一类特定格式的数据，和常规的以太坊交易数据不同，它可以更高效地存储和传输数据。EIP-4844 允许将 Blob 数据以 **交易的形式** 通过以太坊网络传递，并为 **Layer 2** 网络提供存储空间。 4 | 5 | #### 1. **Blob 数据** 6 | 7 | Blob 是一种 **大容量、廉价的存储方式**，其目的是将大量数据（如 Rollup 中的数据）压缩并传输。Blob 的特点包括： 8 | 9 | - **存储方式高效**：Blob 数据可以比以太坊常规数据更加高效地存储，从而减少了存储和传输的费用。 10 | - **不直接参与计算**：Blob 数据的存储和处理在计算上更加简化，它并不直接参与以太坊状态的计算。 11 | 12 | #### 2. **Shard Blob Transactions** 13 | 14 | Shard Blob Transactions 是新的交易类型，允许 **Rollup** 将大量的数据存储为 **Blob**，而不是直接将其作为 **交易数据** 存储在以太坊主链上。每个这样的交易可以携带多个 **Blob**，并且会根据一定的规则存储在网络中。这种方式会极大地减少 **数据存储和验证的成本**。 15 | 16 | #### 3. **与以太坊主链的互动** 17 | 18 | EIP-4844 使得 **Blob 数据** 可以存储在以太坊网络上，但与以太坊当前的状态更新无关。Blob 数据并不会影响以太坊的状态计算，它们的主要作用是作为一个数据传输层，供 **Rollup** 使用。在以太坊主链上，Blob 数据与普通交易相比，它的存储成本会低得多，从而为 Layer 2 的 Rollup 提供了 **更低的费用**。 19 | 20 | #### 4. **交易和费用** 21 | 22 | EIP-4844 通过为 Blob 数据创建独立的 **交易类型** 来减少费用： 23 | 24 | - **Blob 交易费用**：Blob 数据会有 **低于普通交易的存储费用**，使得 Rollup 可以更加廉价地向以太坊主链提交数据。 25 | - **Gas 消耗**：Blob 交易的 gas 费用会根据数据的大小而变化，并且它的费用结构设计比普通交易要便宜，从而让 Layer 2 的运营更加经济。 26 | 27 | ### **EIP-4844 的优势** 28 | 29 | 1. **大幅降低 Layer 2 的成本**： 30 | - 通过将大量数据作为 Blob 存储，可以降低 Rollup 中的数据传输成本，极大地降低了交易费用。特别是在数据较大的情况下，EIP-4844 会比当前的以太坊交易更为高效。 31 | 2. **支持未来分片技术**： 32 | - Blob 数据的设计为以太坊未来的 **分片（Sharding）** 提供了支持。分片将允许以太坊网络的不同部分并行处理交易，而 Blob 数据的引入为这些并行交易提供了优化的数据存储方式。 33 | 3. **提高吞吐量**： 34 | - EIP-4844 使得以太坊网络能够以 **更低的成本** 扩展，特别是在支持 Rollup 的情况下，网络的吞吐量会显著提高。 35 | 4. **增强 Rollup 性能**： 36 | - Optimistic Rollup 和 ZK-Rollup 都需要大量的交易数据来验证和最终确认交易，通过支持 Blob 数据，EIP-4844 能够有效提高这些网络的效率。 37 | 5. **简化验证**： 38 | - Blob 数据被设计为更加简单的格式，它不直接影响以太坊的状态计算，因此验证过程将更加高效，减少了对计算资源的需求。 39 | 40 | ### **EIP-4844 与分片的关系** 41 | 42 | EIP-4844 为分片（Sharding）技术的实施做出了重要的准备： 43 | 44 | - **分片存储的过渡**：Blob 数据的存储方式为以太坊分片做了技术准备。通过优化 Blob 存储和处理，分片之后每个分片可以独立存储不同的数据，并通过类似的方式来降低交易费用。 45 | - **为未来的 Shard 提供数据存储方案**：Blob 数据在设计上与未来的分片架构兼容，使得以太坊分片能够更加高效地存储和管理数据。 46 | 47 | ### **EIP-4844 的挑战和考虑** 48 | 49 | 尽管 EIP-4844 具有很多潜力，但也面临一些挑战和考虑因素： 50 | 51 | - **复杂的实现**：引入 Blob 数据和新的交易类型需要大量的基础设施和协议升级，这需要 Ethereum 社区和开发者的广泛合作。 52 | - **安全性**：随着数据存储结构的改变，需要确保 Blob 数据的存储和传输不会影响以太坊的整体安全性。 53 | - **升级过程**：EIP-4844 需要与以太坊的其他升级（如 EIP-1559、分片等）协调实施，因此其实施过程可能会非常复杂。 -------------------------------------------------------------------------------- /.William-02-02.assets/image-20250106133525233.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/IntensiveCoLearning/Optimism/3cd922710daa7d7c64a8cf1524512f82a78d2d12/.William-02-02.assets/image-20250106133525233.png -------------------------------------------------------------------------------- /.William-02-02.assets/image-20250108215836301.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/IntensiveCoLearning/Optimism/3cd922710daa7d7c64a8cf1524512f82a78d2d12/.William-02-02.assets/image-20250108215836301.png -------------------------------------------------------------------------------- /.William-02-02.assets/image-20250110221523916.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/IntensiveCoLearning/Optimism/3cd922710daa7d7c64a8cf1524512f82a78d2d12/.William-02-02.assets/image-20250110221523916.png -------------------------------------------------------------------------------- /.William-02-02.assets/image-20250110224052958.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/IntensiveCoLearning/Optimism/3cd922710daa7d7c64a8cf1524512f82a78d2d12/.William-02-02.assets/image-20250110224052958.png -------------------------------------------------------------------------------- /.William-02-02.assets/image-20250112183357908.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/IntensiveCoLearning/Optimism/3cd922710daa7d7c64a8cf1524512f82a78d2d12/.William-02-02.assets/image-20250112183357908.png -------------------------------------------------------------------------------- /.William-02-02.assets/image-20250112183546766.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/IntensiveCoLearning/Optimism/3cd922710daa7d7c64a8cf1524512f82a78d2d12/.William-02-02.assets/image-20250112183546766.png -------------------------------------------------------------------------------- /.William-02-02.assets/image-20250113222030006.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/IntensiveCoLearning/Optimism/3cd922710daa7d7c64a8cf1524512f82a78d2d12/.William-02-02.assets/image-20250113222030006.png -------------------------------------------------------------------------------- /.William-02-02.assets/image-20250117165038619.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/IntensiveCoLearning/Optimism/3cd922710daa7d7c64a8cf1524512f82a78d2d12/.William-02-02.assets/image-20250117165038619.png -------------------------------------------------------------------------------- /.William-02-02.assets/image-20250120220328489.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/IntensiveCoLearning/Optimism/3cd922710daa7d7c64a8cf1524512f82a78d2d12/.William-02-02.assets/image-20250120220328489.png -------------------------------------------------------------------------------- /.William-02-02.assets/image-20250124232734999.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/IntensiveCoLearning/Optimism/3cd922710daa7d7c64a8cf1524512f82a78d2d12/.William-02-02.assets/image-20250124232734999.png -------------------------------------------------------------------------------- /.William-02-02.assets/image-20250124233237900.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/IntensiveCoLearning/Optimism/3cd922710daa7d7c64a8cf1524512f82a78d2d12/.William-02-02.assets/image-20250124233237900.png -------------------------------------------------------------------------------- /.William-02-02.assets/imageurl=%2F_next%2Fstatic%2Fmedia%2Fhow-retro-funding-works.9368ab75.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/IntensiveCoLearning/Optimism/3cd922710daa7d7c64a8cf1524512f82a78d2d12/.William-02-02.assets/imageurl=%2F_next%2Fstatic%2Fmedia%2Fhow-retro-funding-works.9368ab75.png -------------------------------------------------------------------------------- /.William-02-02.assets/imageurl=%2F_next%2Fstatic%2Fmedia%2Fsuperchain-diag.7fc0979f.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/IntensiveCoLearning/Optimism/3cd922710daa7d7c64a8cf1524512f82a78d2d12/.William-02-02.assets/imageurl=%2F_next%2Fstatic%2Fmedia%2Fsuperchain-diag.7fc0979f.png -------------------------------------------------------------------------------- /.William-02-02.assets/zkSync.md: -------------------------------------------------------------------------------- 1 | **zkSync的整体架构工作过程** 2 | 3 | ![img](./.zkSync.assets/163238089532675.jpg) 4 | 5 | 6 | 7 | Watcher 负责监控 zkSync 合约交易，Sender发送 zkSync 智能合约的交易，而 MemPool 负责收集交易。 8 | 9 | 整个过程会产生两种交易：L1交易和L2交易。 10 | 11 | Block Proposer 将交易打包，并更改世界状态( Plasma State )。在世界状态更改后，通过Block Committer 生成证明需要的信息。具体到存款和转账流程如下： 12 | 13 | **存款** 14 | 15 | 1、用户调用 L1 zkSync 智能合约存储资金，该交易发生在 L1； 16 | 17 | 2、Watcher 监控 L1 存款交易，当交易发生时则会放入 Mempool 中，该过程一般会经过 10个区块确认，但实际使用中，可能需要更长时间 L1 的充币交易才会在 L2 中生效； 18 | 19 | 3、Block Proposer 处理 Mempool 交易打包，并提交 State Keeper 更新账本，充币交易的状态随之变化。 20 | 21 | **转账** 22 | 23 | 1、当用户想要使用 L2 低成本快速转账时，调用 zkSync API 提交转账交易； 24 | 25 | 2、交易同样会按照流程 Mempool --> Block Proposer --> State Keeper 进行流转； 26 | 27 | 3、最终 State Keeper 通知 Block Commiter 收集生成零知识证明所需信息，调用 PlonK 证明系统生成零知识证明后，借助 Sender 将存款和转账等交易数据，以及将对应的零知识证明提交到 L1 的 zkSync 智能合约验证，等待 L1 交易确认后，Watcher 会通知 L2 更新交易状态为最终确认。 28 | 29 | 30 | 31 | zkSync 采用PlonK零知识证明系统，其中包括 Prover Server 和 Proving Client，在电路设计上，非常巧妙的将交易分割成一个个小的通用处理单元（ Operation ）。 32 | 33 | 一个 Operation 对应的证明电路逻辑支持所有可能交易的 Operation 逻辑。多个有关联的 Operation 电路组成交易电路。 34 | 35 | 多个交易的电路再组合成区块电路。从而，在固定大小的区块中也能包含不同组合的交易。zkSync 开源了 PlonK 算法的验证电路，能进行多个 PlonK 证明。 36 | 37 | 相关代码链接如下： 38 | 39 | https://github.com/matter-labs/recursive_aggregation_circuit 40 | 41 | 而在整个充币和转账过程中，zkSync 并不需要独立生成新账户，zkSync 的 L2 账户和 L1 账户是一一对应的，“共享”一份私钥，准确的说，L1 的私钥的 ECDSA 签名的结果作为 L2 账户的私钥。 42 | 43 | 这样在使用的时候很方便，我们直接使用 L1 的地址就可以在 L2上 完成充币，转账或者提币的操作。 -------------------------------------------------------------------------------- /.William-02-02.assets/交易流程.md: -------------------------------------------------------------------------------- 1 | ### **1. Optimism 处理交易：** 2 | 3 | - **交易处理**：Optimism 网络上的交易首先在子链（Optimism Layer 2）上被处理。每笔交易会引起 Optimism 上的 **用户状态** 或 **智能合约状态** 发生变化（例如账户余额变化、合约变量变化等）。 4 | - **状态树更新**：所有这些状态变化（用户账户、合约状态等）会在 Optimism 中通过 **Merkle 树** 组织起来。每次交易后，子链会计算一个新的 **状态根**，即这个状态树的根哈希（**Merkle Root**）。 5 | 6 | ### **2. 状态根的提交：** 7 | 8 | - **状态根的生成**：Optimism 会在新区块中计算出一个新的 **状态根**，这个状态根代表了 Optimism 子链上所有账户和合约的最新状态。状态根是通过 **Merkle 树** 计算得出的，它只保留了最新的状态，不需要保存每笔交易的详细信息。 9 | - **提交到以太坊主链**：每个新区块结束时，Optimism 会将 **状态根** 提交到 **以太坊主链**。这是通过一个专门的 **合约**（通常是 L1-to-L2 桥接合约）实现的，该合约存储 Optimism 网络的状态根并提供验证功能。 10 | 11 | ### **3. 主链验证状态根：** 12 | 13 | - **以太坊主链的作用**：以太坊主链并不直接处理 Optimism 上的每笔交易，而是通过接收 Optimism 提交的 **状态根** 来验证 Optimism 子链的状态。主链通过智能合约验证这些状态根是否合法，确保子链的数据没有被篡改。 14 | 15 | - 例如，当 Optimism 提交一个区块的状态根时，主链会验证这个状态根是否符合先前的状态根，并确保状态转移是合理的（例如，没有发生非法的账户余额更改）。 16 | 17 | - **验证流程**：一旦以太坊主链收到状态根，它会检查这个状态根与先前的状态根是否匹配。如果匹配，说明 Optimism 上的状态变化是有效的。如果有任何不一致（例如，篡改或错误的状态变更），其他节点可以通过 **挑战机制** 提交 **欺诈证明**（Fraud Proof）。 18 | 19 | ### **4. 挑战机制（Fraud Proof）：** 20 | 21 | - **欺诈证明**：如果 Optimism 上的状态根提交不符合预期，或者发生了不合法的交易，其他参与者可以在挑战期内提出 **欺诈证明**。 22 | 23 | - 这意味着，如果某个状态根的提交不合法（例如包含了错误的状态变更），任何人都可以对其提出质疑，提交欺诈证明来挑战。 24 | 25 | - **挑战的目的**：挑战成功后，会纠正不合法的状态转移，并确保 Optimism 上的状态根和交易历史是正确的。 26 | 27 | ### **5. 交易信息的处理与同步：** 28 | 29 | - **交易信息的存储**：Optimism 网络本身不会在每个区块中直接存储所有交易的详细信息，而是通过 **状态根** 来记录所有状态变更。只有在特定情况下（例如退出或者挑战时），才会暴露详细的交易信息。 30 | - **交易信息与状态根的关系**： 31 | 32 | - 交易本身是通过计算状态根来验证的。每次交易更新了用户的状态或合约的状态，Optimism 会计算一个新的状态根，并将其提交到以太坊主链。 33 | - 如果以太坊主链验证了状态根是有效的，它不会存储交易的详细信息，只是确保 Optimism 上的所有状态变化是合法的。 34 | - **挑战后**：如果有交易被挑战并证明为不合法，则相关的交易信息会被揭示出来，并被同步回以太坊主链，最终纠正错误的状态。 35 | 36 | ### **6. 数据可用性与状态更新：** 37 | 38 | - **数据可用性**：在 **Optimism** 中，状态根的提交确保了 **数据的可用性**。但 **详细的交易数据** 仅在出现 **挑战** 或 **退出** 时才会被完全揭示给主链，以避免存储过多的冗余数据。 39 | - **状态根的作用**：状态根不仅仅是一个摘要，它代表了 **Optimism** 子链上的所有账户和合约的状态，是以太坊主链验证 **L2 状态** 的核心工具。 40 | 41 | ### **总结：** 42 | 43 | - **交易处理与状态根**：Optimism 在子链上处理交易，并通过计算 **状态根** 来表示这些交易引发的状态变化。 44 | - **状态根提交到以太坊主链**：这些状态根被提交到以太坊主链，主链通过智能合约验证其合法性，而不是存储每笔交易。 45 | - **挑战机制**：如果提交的状态根不合法，其他用户可以发起 **挑战**，提交 **欺诈证明** 来纠正错误。 46 | - **交易信息的同步**：只有在 **挑战成功** 或 **退出** 时，交易的详细信息才会被完全同步到以太坊主链。 -------------------------------------------------------------------------------- /.William-02-02.assets/机制说明.md: -------------------------------------------------------------------------------- 1 | ### 1. **乐观假设（Optimistic Assumption）** 2 | 3 | - **基本原则：** 在 Optimism 中，交易默认是有效的。即 OP 节点将交易批量处理后，认为这些交易是合法的，并将交易结果（如状态根）提交到 Layer 1（以太坊）网络上。 4 | - **不立即验证：** 节点不需要立即验证每一笔交易，而是信任提交的交易是正确的，除非有人挑战它们的有效性。 5 | 6 | ### 2. **欺诈证明机制（Fraud Proof）** 7 | 8 | - **核心机制：** 如果某个交易被认为无效，任何人（例如验证者或挑战者）可以通过提供 **欺诈证明**（Fraud Proof）来证明该交易的错误。 9 | - **提交挑战：** 如果有人怀疑某个交易在 Layer 2 上是无效的（比如因为错误的状态转移或者不符合协议规则），他们可以发起挑战，并通过欺诈证明机制提交挑战。 10 | - 验证过程： 11 | - 一旦提交了欺诈证明，**Layer 1** 上的智能合约将开始验证该证明。 12 | - 通过对比计算 Layer 2 上的交易历史和状态变化，智能合约会判断该交易是否有效。 13 | - 如果证明交易无效，提交该交易的 OP 节点会被惩罚（例如，扣除质押的资金），并回滚无效的交易。 14 | - 这个过程通常是由 **挑战者** 提供的证据来驱动的，而不是由所有节点实时执行验证。 15 | 16 | ### 3. **状态根和批次提交（State Root and Batch Submission）** 17 | 18 | - **状态根：** 每当 Layer 2 上的交易执行时，都会产生一个新的 **状态根**（State Root），它是对所有状态（例如用户账户余额、智能合约状态等）的一种加密摘要。 19 | - **提交到 Layer 1：** Optimism 将这批交易的状态根和相关数据提交到 **以太坊 Layer 1** 网络。这意味着，尽管 OP 节点在 Layer 2 上进行交易处理，但所有的交易结果最终都被写入到以太坊主网中，保证了交易的不可篡改性。 20 | - **状态验证：** Layer 1 的智能合约会存储并验证这些状态根，确保交易数据的正确性。如果有问题，欺诈证明机制会启动，进行纠正。 21 | 22 | ------ 23 | 24 | ### 4. **周期性审核和挑战窗口** 25 | 26 | - **挑战窗口：** Optimism 中有一个 **挑战窗口**（通常为 1 周或其他设定的时间段），在这个期间内，任何人都可以对已提交的交易批次提出挑战。 27 | - **审核机制：** 通过这个挑战窗口，社区成员或者其他节点可以对提交的交易进行审查，确保没有不合法的交易进入 Layer 2 网络。 28 | 29 | ### 5. **去中心化和激励机制** 30 | 31 | - **去中心化参与：** Optimism 鼓励社区和验证者节点参与验证工作。通过去中心化的方式，更多的验证者可以参与到交易的验证和状态检查中，提高整个系统的透明度和正确性。 32 | - **激励机制：** 挑战成功的节点或参与者通常会获得奖励，而挑战失败的节点会失去质押的资金。这种激励机制促使节点保持诚实和正确。 33 | 34 | ------ 35 | 36 | ### 6. **共识机制** 37 | 38 | - **以太坊作为最终保证：** 虽然 Optimism 通过乐观假设进行交易处理，但由于最终所有交易数据都提交到以太坊主网（Layer 1），因此以太坊的共识机制（例如 Proof of Stake）为整个过程提供了最终的安全保证。 39 | - **错误回滚：** 如果 Layer 2 上发生严重的错误或欺诈行为，提交到 Layer 1 的交易数据会触发挑战和纠正，确保最终的交易是正确的。 40 | 41 | ------ 42 | 43 | ### 总结： 44 | 45 | **Optimism 节点**（OP 节点）保证链上交易正确性的方法是通过 **乐观假设**和 **欺诈证明机制** 来完成的。交易默认是有效的，只有在有人提出挑战时，才会通过 **欺诈证明** 进行验证。通过这种机制，Optimism 能够在保持高效性和低成本的同时，利用 **以太坊 Layer 1** 的安全性来确保交易的最终正确性。 -------------------------------------------------------------------------------- /.github/workflows/ReopBot.yml: -------------------------------------------------------------------------------- 1 | name: Repo Management 2 | 3 | on: 4 | pull_request_target: 5 | types: [closed] 6 | schedule: 7 | - cron: "0 0 * * *" # 每天午夜运行 8 | push: 9 | branches: [main] # 每次推送到main分支时也运行 10 | 11 | permissions: 12 | contents: write 13 | pull-requests: write 14 | 15 | jobs: 16 | invite-contributor: 17 | runs-on: ubuntu-latest 18 | if: github.event_name == 'pull_request_target' && github.event.pull_request.merged == true 19 | steps: 20 | - name: Invite contributor 21 | id: invite-contributor 22 | uses: actions/github-script@v6 23 | with: 24 | github-token: ${{ secrets.PAT_WITH_INVITE_PERMISSIONS }} 25 | script: | 26 | const { owner, repo } = context.repo; 27 | const username = context.payload.pull_request.user.login; 28 | 29 | console.log(`Checking if ${username} is already a collaborator...`); 30 | 31 | try { 32 | const { data: permissionLevel } = await github.rest.repos.getCollaboratorPermissionLevel({ 33 | owner, 34 | repo, 35 | username, 36 | }); 37 | 38 | if (permissionLevel.permission === 'admin' || permissionLevel.permission === 'write') { 39 | console.log(`${username} is already a collaborator with sufficient permissions.`); 40 | return; 41 | } 42 | 43 | console.log(`${username} is a collaborator but needs permission update.`); 44 | } catch (error) { 45 | if (error.status !== 404) { 46 | console.error(`Error checking collaborator status: ${error.message}`); 47 | throw error; 48 | } 49 | console.log(`${username} is not a collaborator.`); 50 | } 51 | 52 | try { 53 | console.log(`Inviting ${username} as a collaborator...`); 54 | const response = await github.rest.repos.addCollaborator({ 55 | owner, 56 | repo, 57 | username, 58 | permission: 'push' 59 | }); 60 | 61 | if (response.status === 201) { 62 | console.log(`Invitation sent to ${username} as a collaborator with push permission.`); 63 | core.setOutput('invitation_sent', 'true'); 64 | } else if (response.status === 204) { 65 | console.log(`${username}'s permissions updated to push.`); 66 | core.setOutput('invitation_sent', 'false'); 67 | } 68 | } catch (error) { 69 | console.error(`Error inviting/updating collaborator: ${error.message}`); 70 | core.setFailed(`Error inviting/updating collaborator: ${error.message}`); 71 | } 72 | 73 | - name: Comment on PR 74 | if: steps.invite-contributor.outputs.invitation_sent == 'true' 75 | uses: actions/github-script@v6 76 | with: 77 | github-token: ${{ secrets.GITHUB_TOKEN }} 78 | script: | 79 | const { owner, repo } = context.repo; 80 | const issue_number = context.payload.pull_request.number; 81 | const username = context.payload.pull_request.user.login; 82 | try { 83 | await github.rest.issues.createComment({ 84 | owner, 85 | repo, 86 | issue_number, 87 | body: `Thanks for your contribution, @${username}! You've been invited as a collaborator with push permissions. Please check your email for the invitation.` 88 | }); 89 | console.log(`Comment posted on PR #${issue_number}`); 90 | } catch (error) { 91 | console.error(`Error posting comment: ${error.message}`); 92 | core.setFailed(`Error posting comment: ${error.message}`); 93 | } 94 | 95 | update-readme: 96 | runs-on: ubuntu-latest 97 | if: github.event_name == 'schedule' || github.event_name == 'push' 98 | steps: 99 | - uses: actions/checkout@v2 100 | - name: Set up Python 101 | uses: actions/setup-python@v2 102 | with: 103 | python-version: "3.x" 104 | - name: Install dependencies 105 | run: | 106 | python -m pip install --upgrade pip 107 | pip install PyGithub pytz 108 | - name: Update README 109 | env: 110 | GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }} 111 | START_DATE: ${{ vars.START_DATE }} 112 | END_DATE: ${{vars.END_DATE }} 113 | FILE_SUFFIX: ${{vars.FILE_SUFFIX}} 114 | FIELD_NAME: ${{vars.FIELD_NAME}} 115 | run: python sync_status_readme.py 116 | - name: Check for changes 117 | id: git-check 118 | run: | 119 | git diff --exit-code README.md || echo "modified=true" >> $GITHUB_OUTPUT 120 | - name: Commit changes 121 | if: steps.git-check.outputs.modified == 'true' 122 | run: | 123 | git config --local user.email "action@github.com" 124 | git config --local user.name "GitHub Action" 125 | git add README.md 126 | git commit -m "Update commit status table" 127 | git push 128 | 129 | notify-api: 130 | runs-on: ubuntu-latest 131 | if: github.event_name == 'pull_request_target' && github.event.pull_request.merged == true || github.event_name == 'push' 132 | steps: 133 | - name: Setup Node.js 134 | uses: actions/setup-node@v3 135 | with: 136 | node-version: "16" 137 | 138 | - name: Install axios 139 | run: npm install axios 140 | 141 | - name: Call API 142 | uses: actions/github-script@v6 143 | with: 144 | github-token: ${{ secrets.GITHUB_TOKEN }} 145 | script: | 146 | const axios = require('axios'); 147 | const commit_sha = context.sha; 148 | const { owner, repo } = context.repo; 149 | 150 | try { 151 | const { data: commit } = await github.rest.repos.getCommit({ 152 | owner, 153 | repo, 154 | ref: commit_sha 155 | }); 156 | 157 | // Get user details 158 | const { data: user } = await github.rest.users.getByUsername({ 159 | username: commit.author.login 160 | }); 161 | 162 | 163 | // Output information 164 | console.log('Commit Author Information:'); 165 | console.log('------------------------'); 166 | console.log(`Name: ${commit.commit.author.name}`); 167 | console.log(`Email: ${commit.commit.author.email}`); 168 | console.log(`GitHub Username: ${commit.author.login}`); 169 | console.log(`User ID: ${user.id}`); 170 | console.log(`Account Type: ${user.type}`); 171 | console.log(`Created At: ${user.created_at}`); 172 | 173 | const response = await axios.get(`https://api.intensivecolearn.ing/api/programs/createByRepo/${owner}/${repo}`); 174 | 175 | console.log('API response:', response.data); 176 | 177 | const updateUserNotesResp = await axios.get(`https://api.intensivecolearn.ing/api/programs/updateStudynotes?owner=${owner}&repo=${repo}&userGitId=${user.id}`); 178 | 179 | console.log('updateUserNotesRespAPI response:', updateUserNotesResp.data); 180 | 181 | } catch (error) { 182 | console.error('Error calling API:', error.message); 183 | core.setFailed(`Error calling API: ${error.message}`); 184 | } 185 | -------------------------------------------------------------------------------- /.gitignore: -------------------------------------------------------------------------------- 1 | 2 | .codegpt 3 | .vscode 4 | -------------------------------------------------------------------------------- /183Aaros.md: -------------------------------------------------------------------------------- 1 | timezone: Asia/Shanghai 2 | --- 3 | 4 | > 请在上边的 timezone 添加你的当地时区，这会有助于你的打卡状态的自动化更新，如果没有添加，默认为北京时间 UTC+8 时区 5 | > 时区请参考以下列表，请移除 # 以后的内容 6 | 7 | timezone: Pacific/Honolulu # 夏威夷-阿留申标准时间 (UTC-10) 8 | 9 | timezone: America/Anchorage # 阿拉斯加标准时间 (UTC-9) 10 | 11 | timezone: America/Los_Angeles # 太平洋标准时间 (UTC-8) 12 | 13 | timezone: America/Denver # 山地标准时间 (UTC-7) 14 | 15 | timezone: America/Chicago # 中部标准时间 (UTC-6) 16 | 17 | timezone: America/New_York # 东部标准时间 (UTC-5) 18 | 19 | timezone: America/Halifax # 大西洋标准时间 (UTC-4) 20 | 21 | timezone: America/St_Johns # 纽芬兰标准时间 (UTC-3:30) 22 | 23 | timezone: America/Sao_Paulo # 巴西利亚时间 (UTC-3) 24 | 25 | timezone: Atlantic/Azores # 亚速尔群岛时间 (UTC-1) 26 | 27 | timezone: Europe/London # 格林威治标准时间 (UTC+0) 28 | 29 | timezone: Europe/Berlin # 中欧标准时间 (UTC+1) 30 | 31 | timezone: Europe/Helsinki # 东欧标准时间 (UTC+2) 32 | 33 | timezone: Europe/Moscow # 莫斯科标准时间 (UTC+3) 34 | 35 | timezone: Asia/Dubai # 海湾标准时间 (UTC+4) 36 | 37 | timezone: Asia/Kolkata # 印度标准时间 (UTC+5:30) 38 | 39 | timezone: Asia/Dhaka # 孟加拉国标准时间 (UTC+6) 40 | 41 | timezone: Asia/Bangkok # 中南半岛时间 (UTC+7) 42 | 43 | timezone: Asia/Shanghai # 中国标准时间 (UTC+8) 44 | 45 | timezone: Asia/Tokyo # 日本标准时间 (UTC+9) 46 | 47 | timezone: Australia/Sydney # 澳大利亚东部标准时间 (UTC+10) 48 | 49 | timezone: Pacific/Auckland # 新西兰标准时间 (UTC+12) 50 | 51 | --- 52 | 53 | # {183Aaros} 54 | 55 | 1. About me: Hey, I'm 183Aaros, a member of OPCN and one of the tutors of the OP co-learning this time. I'm delighted to learn the fundamentals of OP together with everyone here. Here's my personal web if you're interested in know more about me :) -> 183aaros.notion.site 56 | 2. About Notes: trying to use md grammar after 2-3 days 57 | 3. Yes 58 | 59 | ## Notes 60 | 61 | 62 | 63 | ### 2025.01.06 64 | 65 | Optimism Co-learning Notes, day1: 66 | 67 | #### OP and OP Rollup 68 | 69 | Dedication: 70 | scaling Ethereum's tech 71 | expanding its ability 72 | coordinape ppl world-wide to build decentralised economies+governance systems 73 | 74 | Principle: 75 | impact=profit 76 | 77 | OP Collective: 78 | Builds open-source software 79 | 80 | OP Stack: 81 | decentralised software stack 82 | backbone of blockchains i.e. OP Mainnet& base 83 | 84 | OP Rollups: 85 | Leverage the consensus mechanism of L1 86 | 87 | #### Block 88 | 89 | Block storage: 90 | using non-contract address(for min gas) on ETH 91 | write in compressed format 92 | transaction anti-censorship via EIP-4844 blobs 93 | inherits ETH availability& integrity 94 | 95 | Biobiography: 96 | https://specs.optimism.io/ 97 | 98 | ### 2025.01.07 99 | 100 | Key takeaway: 101 | 102 | #### OP Mainnet Transaction fee 103 | Transaction fee [Execution Gas Fee(Base fee, Priority fee), L1 Data Fee] 104 | 105 | #### L1 Data Fee，Ecotone: 106 | (1)tx_compressed_size = [(count_zero_bytes(tx_data)*4 + count_non_zero_bytes(tx_data)*16)] / 16 107 | 108 | (2) 109 | weighted_gas_price = 16*base_fee_scalar*base_fee + blob_base_fee_scalar*blob_base_fee 110 | 111 | L1 Data Fee, Ecotone = (1) * (2) 112 | 113 | #### L1 Data Fee，Fjord 114 | L1 Data Fee，Fjord(FastLZ-compressed size, base fee/ blob base fee): 115 | 116 | (1) estimatedSizeScaled = max(minTransactionSize * 1e6, intercept + fastlzCoef*fastlzSize) 117 | 118 | (2)l1FeeScaled = baseFeeScalar*l1BaseFee*16 + blobFeeScalar*l1BlobBaseFee 119 | 120 | where both scalars are scaled by 1e6, 121 | 122 | thus, 123 | 124 | L1cost = (1)*(2)/1e12 125 | 126 | #### Biobiography: 127 | https://docs.optimism.io/stack/transactions/fees 128 | 129 | ### 2025.01.08 130 | 131 | Key takeaway: 132 | 133 | Stage 0 - Full training wheels, still an source available software allows reconstruction of the state. 134 | 135 | - rollup 136 | - state roots 137 | - provide DA (data availability) on L1 138 | - reconstructiion of state source available 139 | 140 | Stage 1 - Limited ~, governed by smart contract, council implementation for security. 141 | 142 | - proper proof system 143 | - fraud proof 144 | - user may exit without oper's coordination 145 | - 7 days exit window 146 | - 50% of the security council participants from external 147 | 148 | Stage 2 - No ~, final stage, no council. 149 | 150 | - permissionless 151 | - 30 days exit window 152 | - Security Council restricted to errors detected 153 | 154 | ### 2025.01.09 155 | The learning material today I choose from, has head back to VB's original articles on scaling, which inspring the design of Optimism. 156 | 157 | Key takeaway: (mainly focus the aspect of VB's analytical framework) 158 | 159 | Some prior background - Blockchain scaling/decentralised/safety triangle dillema etc. 160 | 161 | Identify the problem 162 | - the consensus architectures rely on every node processing every transaction 163 | 164 | When it comes to soluions, one particular thing that really stand out is, 165 | VB has assessed many factors even potential growth model and how would these model choices could end up with. 166 | i.e. Batching vs. other solutions, in a sense of the comparison of a linea growth model solution vs. exponential growth model, but with a trade-off (i.e. ETH 2.0, a trade-off of the dev cycle). 167 | 168 | At the very last part of the article, VB has mentioned shadow chain, we can see the idea that inspired Optimism Rollups. From the analytical thinking side, he identified the trade-offs, and can also see how his analytical framework constructs the original version of L2 solution that temporarily compromises, but better for solving the trilemma in the long run. 169 | 170 | #### Biobiography: 171 | Buterin, V. (2014) 'Scalability, Part 1: Building on Top', Vitalik Buterin's Blog, 17 September 2014. 172 | https://blog.ethereum.org/2014/09/17/scalability-part-1-building-top 173 | 174 | ### 2025.01.10 175 | 休息 176 | 177 | ### 2025.01.11 178 | 179 | #### Optimism Collective 180 | - a collective of companies + communities + citizens working together 181 | - to reward publicgood 182 | - build a sustainable future for Ethereum 183 | 184 | #### Vision 185 | - standardization 186 | - Supechain scales 187 | - governance protect security 188 | - governance creates flywheel of sustainable growth and dev 189 | 190 | #### Mission 191 | - to create an internet that benefits all and is owned by none 192 | 193 | #### Governance 194 | - digital democratic governance consists of 2 houses 195 | - Token house: submitting, deliberating, voting on various types of governance proposals. 196 | - vote directly 197 | - delegate 198 | - Citizen house: 1 person = 1 vote, also responsible for RPGF (Retro Funding); 199 | - reduce concentration of power 200 | - safeguard against capture of Token House (whales etc.) 201 | - Allocate resources for long-term benefit 202 | 203 | #### Biobiography: 204 | Citizens House section: https://community.optimism.io/citizens-house/citizen-house-overview 205 | 206 | #### What's next? 207 | Understand how Token house and citizen house works in a more in-depth aspect. 208 | 209 | Sources: 210 | 1. The Collective’s Operating Manual 211 | https://github.com/ethereum-optimism/OPerating-manual/blob/main/manual.md#valid-proposal-types 212 | 213 | 2. The Collective’s Working Constitution 214 | https://gov.optimism.io/t/working-constitution-of-the-optimism-collective/55 215 | 216 | 3. Identity and Reputation: Foundation within the Collective 217 | https://community.optimism.io/identity/identity-and-rep 218 | 219 | 4. Decentralization Milestone 220 | https://docs.google.com/spreadsheets/d/1IpL0oTd3AgNBu_eWdjP9EjbQfZjq-_Nd3yU1H2ke3vY/edit?gid=0#gid=0 221 | 222 | 5. Decision Diagram Working Model 223 | https://www.figma.com/board/iXqyKmLJeBeplKpJBHDI7G/PUBLIC%3A-Optimism-Decision-Diagram-Working-Model?node-id=0-1&node-type=canvas&t=QLiz1uM1DepwYyHy-0 224 | 225 | #### 2025.01.15 226 | 227 | - Key Governance Structure 228 | The Optimism Collective employs a unique two-house governance system: 229 | 230 | Token House: Comprised of OP token holders 231 | Responsible for: 232 | Submitting governance proposals 233 | Deliberating on proposals 234 | Voting on various governance matters 235 | 236 | Citizens' House: Composed of Optimism Citizens 237 | Primary functions: 238 | - Allocating retroactive public goods funding 239 | - Voting on proposal vetoes 240 | - Providing a check-and-balance mechanism 241 | - Governance Process 242 | - Proposal Lifecycle 243 | -Three-week cycle for most proposals 244 | -Weeks 1-2: Feedback and review period 245 | -Week 3: Voting period 246 | 247 | Key Requirements 248 | 249 | Proposals must be: 250 | Submitted to the Governance Forum 251 | - Marked with [Draft] initially 252 | Require approval from: 253 | - 4 top 100 delegates (Token House) 254 | - 4 Citizens (Citizens' House) 255 | 256 | Voting Mechanics 257 | Token House Voting 258 | Quorum: 30% of votable OP supply 259 | Approval Threshold: 51-76% of votes (varies by proposal type) 260 | 261 | Citizens' House Voting 262 | Based on percentage of total Citizens 263 | Includes veto rights for certain proposals 264 | Valid Proposal Types 265 | 266 | Retroactive Public Goods Funding (Retro Funding) 267 | A unique mechanism where Citizens vote to reward impactful public goods projects through: 268 | 269 | #### 2025.01.16 270 | Revised and re-orgnised notes for 271 | https://github.com/ethereum-optimism/OPerating-manual/blob/main/manual.md 272 | 273 | Key takeaway 274 | 275 | Governance Architecture 276 | - Two-House System: Token House and Citizens' House 277 | - Purpose: Decentralized, democratic blockchain governance 278 | - Unique Feature: Bicameral structure with mutual oversight 279 | 280 | Token House 281 | - Composition: OP token holders 282 | - Responsibilities: 283 | Submit governance proposals 284 | Vote on protocol upgrades 285 | Manage treasury decisions 286 | Voting Mechanism: Direct voting or delegation 287 | 288 | Citizens' House 289 | - Core Function: Retroactive Public Goods Funding 290 | - Key Characteristics: 291 | Temporary citizenship 292 | Veto power over Token House proposals 293 | Rewards impactful public goods projects 294 | 295 | Governance Process 296 | - Cycle: Three-week structured approach 297 | Weeks 1-2: Community feedback 298 | Week 3: Formal voting 299 | - Approval Requirements: 300 | Delegate/Citizen endorsements 301 | Specific quorum thresholds 302 | Transparent review process 303 | 304 | 305 | -------------------------------------------------------------------------------- /8280998.md: -------------------------------------------------------------------------------- 1 | --- 2 | timezone: Asia/Shanghai 3 | --- 4 | 5 | > 请在上边的 timezone 添加你的当地时区，这会有助于你的打卡状态的自动化更新，如果没有添加，默认为北京时间 UTC+8 时区 6 | > 时区请参考以下列表，请移除 # 以后的内容 7 | 8 | timezone: Pacific/Honolulu # 夏威夷-阿留申标准时间 (UTC-10) 9 | 10 | timezone: America/Anchorage # 阿拉斯加标准时间 (UTC-9) 11 | 12 | timezone: America/Los_Angeles # 太平洋标准时间 (UTC-8) 13 | 14 | timezone: America/Denver # 山地标准时间 (UTC-7) 15 | 16 | timezone: America/Chicago # 中部标准时间 (UTC-6) 17 | 18 | timezone: America/New_York # 东部标准时间 (UTC-5) 19 | 20 | timezone: America/Halifax # 大西洋标准时间 (UTC-4) 21 | 22 | timezone: America/St_Johns # 纽芬兰标准时间 (UTC-3:30) 23 | 24 | timezone: America/Sao_Paulo # 巴西利亚时间 (UTC-3) 25 | 26 | timezone: Atlantic/Azores # 亚速尔群岛时间 (UTC-1) 27 | 28 | timezone: Europe/London # 格林威治标准时间 (UTC+0) 29 | 30 | timezone: Europe/Berlin # 中欧标准时间 (UTC+1) 31 | 32 | timezone: Europe/Helsinki # 东欧标准时间 (UTC+2) 33 | 34 | timezone: Europe/Moscow # 莫斯科标准时间 (UTC+3) 35 | 36 | timezone: Asia/Dubai # 海湾标准时间 (UTC+4) 37 | 38 | timezone: Asia/Kolkata # 印度标准时间 (UTC+5:30) 39 | 40 | timezone: Asia/Dhaka # 孟加拉国标准时间 (UTC+6) 41 | 42 | timezone: Asia/Bangkok # 中南半岛时间 (UTC+7) 43 | 44 | timezone: Asia/Shanghai # 中国标准时间 (UTC+8) 45 | 46 | timezone: Asia/Tokyo # 日本标准时间 (UTC+9) 47 | 48 | timezone: Australia/Sydney # 澳大利亚东部标准时间 (UTC+10) 49 | 50 | timezone: Pacific/Auckland # 新西兰标准时间 (UTC+12) 51 | 52 | --- 53 | 54 | # {8280998} 55 | 56 | 1. 自我介绍 代码新手 57 | 58 | 2. 你认为你会完成本次残酷学习吗？ 会 59 | 60 | ## Notes 61 | 62 | 63 | 64 | ### 2025.01.06 65 | 66 | 笔记内容 67 | 68 | ### 2024.07.12 69 | 70 | 71 | -------------------------------------------------------------------------------- /A3438.md: -------------------------------------------------------------------------------- 1 | --- 2 | timezone: Asia/Shanghai 3 | --- 4 | 5 | > 请在上边的 timezone 添加你的当地时区，这会有助于你的打卡状态的自动化更新，如果没有添加，默认为北京时间 UTC+8 时区 6 | > 时区请参考以下列表，请移除 # 以后的内容 7 | 8 | timezone: Pacific/Honolulu # 夏威夷-阿留申标准时间 (UTC-10) 9 | 10 | timezone: America/Anchorage # 阿拉斯加标准时间 (UTC-9) 11 | 12 | timezone: America/Los_Angeles # 太平洋标准时间 (UTC-8) 13 | 14 | timezone: America/Denver # 山地标准时间 (UTC-7) 15 | 16 | timezone: America/Chicago # 中部标准时间 (UTC-6) 17 | 18 | timezone: America/New_York # 东部标准时间 (UTC-5) 19 | 20 | timezone: America/Halifax # 大西洋标准时间 (UTC-4) 21 | 22 | timezone: America/St_Johns # 纽芬兰标准时间 (UTC-3:30) 23 | 24 | timezone: America/Sao_Paulo # 巴西利亚时间 (UTC-3) 25 | 26 | timezone: Atlantic/Azores # 亚速尔群岛时间 (UTC-1) 27 | 28 | timezone: Europe/London # 格林威治标准时间 (UTC+0) 29 | 30 | timezone: Europe/Berlin # 中欧标准时间 (UTC+1) 31 | 32 | timezone: Europe/Helsinki # 东欧标准时间 (UTC+2) 33 | 34 | timezone: Europe/Moscow # 莫斯科标准时间 (UTC+3) 35 | 36 | timezone: Asia/Dubai # 海湾标准时间 (UTC+4) 37 | 38 | timezone: Asia/Kolkata # 印度标准时间 (UTC+5:30) 39 | 40 | timezone: Asia/Dhaka # 孟加拉国标准时间 (UTC+6) 41 | 42 | timezone: Asia/Bangkok # 中南半岛时间 (UTC+7) 43 | 44 | timezone: Asia/Shanghai # 中国标准时间 (UTC+8) 45 | 46 | timezone: Asia/Tokyo # 日本标准时间 (UTC+9) 47 | 48 | timezone: Australia/Sydney # 澳大利亚东部标准时间 (UTC+10) 49 | 50 | timezone: Pacific/Auckland # 新西兰标准时间 (UTC+12) 51 | 52 | --- 53 | 54 | # {A3438} 55 | 56 | 1. 自我介绍 57 | 对OP运作原理非常感兴趣，想通过本次学习加深对OP的理解 58 | 2. 你认为你会完成本次残酷学习吗？ 59 | 轻轻松松 60 | 61 | ## Notes 62 | 63 | 64 | 65 | ### 2024.07.11 66 | 67 | 笔记内容 68 | 69 | ### 2024.07.12 70 | 71 | 72 | -------------------------------------------------------------------------------- /Alexliwenhao.md: -------------------------------------------------------------------------------- 1 | --- 2 | timezone: Asia/Shanghai # 中国标准时间 (UTC+8) 3 | --- 4 | 5 | > 请在上边的 timezone 添加你的当地时区，这会有助于你的打卡状态的自动化更新，如果没有添加，默认为北京时间 UTC+8 时区 6 | > 时区请参考以下列表，请移除 # 以后的内容 7 | 8 | timezone: Pacific/Honolulu # 夏威夷-阿留申标准时间 (UTC-10) 9 | 10 | timezone: America/Anchorage # 阿拉斯加标准时间 (UTC-9) 11 | 12 | timezone: America/Los_Angeles # 太平洋标准时间 (UTC-8) 13 | 14 | timezone: America/Denver # 山地标准时间 (UTC-7) 15 | 16 | timezone: America/Chicago # 中部标准时间 (UTC-6) 17 | 18 | timezone: America/New_York # 东部标准时间 (UTC-5) 19 | 20 | timezone: America/Halifax # 大西洋标准时间 (UTC-4) 21 | 22 | timezone: America/St_Johns # 纽芬兰标准时间 (UTC-3:30) 23 | 24 | timezone: America/Sao_Paulo # 巴西利亚时间 (UTC-3) 25 | 26 | timezone: Atlantic/Azores # 亚速尔群岛时间 (UTC-1) 27 | 28 | timezone: Europe/London # 格林威治标准时间 (UTC+0) 29 | 30 | timezone: Europe/Berlin # 中欧标准时间 (UTC+1) 31 | 32 | timezone: Europe/Helsinki # 东欧标准时间 (UTC+2) 33 | 34 | timezone: Europe/Moscow # 莫斯科标准时间 (UTC+3) 35 | 36 | timezone: Asia/Dubai # 海湾标准时间 (UTC+4) 37 | 38 | timezone: Asia/Kolkata # 印度标准时间 (UTC+5:30) 39 | 40 | timezone: Asia/Dhaka # 孟加拉国标准时间 (UTC+6) 41 | 42 | timezone: Asia/Bangkok # 中南半岛时间 (UTC+7) 43 | 44 | timezone: Asia/Shanghai # 中国标准时间 (UTC+8) 45 | 46 | timezone: Asia/Tokyo # 日本标准时间 (UTC+9) 47 | 48 | timezone: Australia/Sydney # 澳大利亚东部标准时间 (UTC+10) 49 | 50 | timezone: Pacific/Auckland # 新西兰标准时间 (UTC+12) 51 | 52 | --- 53 | 54 | # {Alexliwenhao} 55 | 56 | 1. 自我介绍 57 | 大家好，我是 Alex，来自中国，是一名web2开发工程师。我热爱编程，喜欢挑战自我，不断学习新技术。我期待在这次残酷学习中，能够与大家共同进步，互相学习，共同成长。 58 | 59 | 2. 你认为你会完成本次残酷学习吗？ 60 | 我会，我相信我可以完成这次残酷学习。我对 Web3 生态感兴趣，想要转型web3, 并且对区块链技术有浓厚兴趣。有丰富的编程经验。我相信，只要我坚持不懈，努力学习，我一定能够完成这次残酷学习，并取得优异的成绩。 61 | 62 | ## Notes 63 | 64 | 65 | 66 | ### 2025.01.06 67 | 68 | 笔记内容 69 | 70 | ### 2025.01.07 71 | 72 | 笔记内容 73 | 74 | ### 2025.01.08 75 | 76 | 笔记内容 77 | 78 | ### 2025.01.09 79 | 80 | 笔记内容 81 | 82 | ### 2025.01.10 83 | 84 | 笔记内容 85 | 86 | ### 2025.01.11 87 | 88 | 笔记内容 89 | 90 | ### 2025.01.12 91 | 92 | 笔记内容 93 | 94 | ### 2025.01.13 95 | 96 | 笔记内容 97 | 98 | ### 2025.01.14 99 | 100 | 笔记内容 101 | 102 | ### 2025.01.15 103 | 104 | 笔记内容 105 | 106 | ### 2025.01.16 107 | 108 | 笔记内容 109 | 110 | ### 2025.01.17 111 | 112 | 笔记内容 113 | 114 | ### 2025.01.18 115 | 116 | 笔记内容 117 | 118 | ### 2025.01.19 119 | 120 | 笔记内容 121 | 122 | ### 2025.01.20 123 | 124 | 笔记内容 125 | 126 | ### 2025.01.21 127 | 128 | 笔记内容 129 | 130 | ### 2025.01.22 131 | 132 | 笔记内容 133 | 134 | ### 2025.01.23 135 | 136 | 笔记内容 137 | 138 | ### 2025.01.24 139 | 140 | 笔记内容 141 | 142 | ### 2025.01.25 143 | 144 | 笔记内容 145 | 146 | ### 2025.01.26 147 | 148 | 笔记内容 149 | 150 | 151 | -------------------------------------------------------------------------------- /CHENFANGC.md: -------------------------------------------------------------------------------- 1 | --- 2 | timezone: Asia/Shanghai 3 | --- 4 | 5 | > 请在上边的 timezone 添加你的当地时区，这会有助于你的打卡状态的自动化更新，如果没有添加，默认为北京时间 UTC+8 时区 6 | > 时区请参考以下列表，请移除 # 以后的内容 7 | 8 | timezone: Pacific/Honolulu # 夏威夷-阿留申标准时间 (UTC-10) 9 | 10 | timezone: America/Anchorage # 阿拉斯加标准时间 (UTC-9) 11 | 12 | timezone: America/Los_Angeles # 太平洋标准时间 (UTC-8) 13 | 14 | timezone: America/Denver # 山地标准时间 (UTC-7) 15 | 16 | timezone: America/Chicago # 中部标准时间 (UTC-6) 17 | 18 | timezone: America/New_York # 东部标准时间 (UTC-5) 19 | 20 | timezone: America/Halifax # 大西洋标准时间 (UTC-4) 21 | 22 | timezone: America/St_Johns # 纽芬兰标准时间 (UTC-3:30) 23 | 24 | timezone: America/Sao_Paulo # 巴西利亚时间 (UTC-3) 25 | 26 | timezone: Atlantic/Azores # 亚速尔群岛时间 (UTC-1) 27 | 28 | timezone: Europe/London # 格林威治标准时间 (UTC+0) 29 | 30 | timezone: Europe/Berlin # 中欧标准时间 (UTC+1) 31 | 32 | timezone: Europe/Helsinki # 东欧标准时间 (UTC+2) 33 | 34 | timezone: Europe/Moscow # 莫斯科标准时间 (UTC+3) 35 | 36 | timezone: Asia/Dubai # 海湾标准时间 (UTC+4) 37 | 38 | timezone: Asia/Kolkata # 印度标准时间 (UTC+5:30) 39 | 40 | timezone: Asia/Dhaka # 孟加拉国标准时间 (UTC+6) 41 | 42 | timezone: Asia/Bangkok # 中南半岛时间 (UTC+7) 43 | 44 | timezone: Asia/Shanghai # 中国标准时间 (UTC+8) 45 | 46 | timezone: Asia/Tokyo # 日本标准时间 (UTC+9) 47 | 48 | timezone: Australia/Sydney # 澳大利亚东部标准时间 (UTC+10) 49 | 50 | timezone: Pacific/Auckland # 新西兰标准时间 (UTC+12) 51 | 52 | --- 53 | 54 | # Cora 55 | 56 | 1. 自我介绍 57 | I'm Cora, a web front-end engineer, currently working on an AI project. 58 | 2. 你认为你会完成本次残酷学习吗？ 59 | of course 60 | 61 | ## Notes 62 | 63 | 64 | 65 | ### 2025.01.06 66 | 67 | 阅读文档内容[Layer2 扩容方案](https://docs.optimism.io/stack/rollup/overview) 68 | 69 | ### 2025.01.07 70 | 71 | 阅读文档内容[Optimism 与其他 Layer 2 的比较](https://learnblockchain.cn/article/3703) 72 | 73 | ### 2025.01.08 74 | 75 | 阅读文档内容[Stage 的介绍](https://medium.com/l2beat/introducing-stages-a-framework-to-evaluate-rollups-maturity-d290bb22befe) 76 | 77 | ### 2025.01.09 78 | 79 | 阅读文档内容[治理理念](https://community.optimism.io/welcome/welcome-overview) 80 | 81 | ### 2025.01.10 82 | 83 | 阅读文档内容[投票机制](https://github.com/ethereum-optimism/OPerating-manual/blob/main/manual.md) 84 | 85 | ### 2025.01.13 86 | 87 | 阅读文档内容[委员会](https://gov.optimism.io/search?q=council) 88 | 89 | ### 2025.01.14 90 | 91 | 阅读文档内容[RetroPGF](https://community.optimism.io/citizens-house/how-retro-funding-works) 92 | 93 | Optimism 的追溯性公共物品资助（Retro Funding）基于“影响力等于利润”的理念，旨在奖励对生态系统产生积极影响的项目。该机制认为，回顾过去的有用成果比预测未来更容易达成共识。因此，公民议会（Citizens’ House）成员会将协议的盈余收入或部分代币分配给他们认为对 Optimism 集体和 Superchain 有积极贡献的项目。 94 | 95 | 这种奖励机制激励人们构建有利于 Optimism 集体的公共物品，促进生态系统的建设、学习和连接，从而推动应用使用并增加对区块空间的需求。通过可持续地资助公共物品，集体能够创造一个丰富的生态系统和更好的经济环境。 96 | 97 | Retro Funding 还为公共物品项目提供了可能的退出流动性，打开了对这些项目进行早期投资的市场。这意味着建设者可以在不直接产生收入的情况下因其积极贡献而获得奖励，或根据项目的早期潜力筹集启动资金。 98 | 99 | Retro Funding 是一个长期实验，旨在构建 Optimism 期望的未来。集体将定期进行 Retro Funding 轮次，每次都有所不同。这一过程需要社区的参与来发展和完善。例如，第一轮在 2021 年底进行，分配了 100 万美元给 58 个项目；第二轮在 2023 年第一季度进行，分配了 1000 万 OP 代币给 195 个项目；第三轮在 2023 年第四季度进行，分配了 3000 万 OP 代币给 501 个项目。第四轮计划在 2024 年第二或第三季度进行，奖励对 Optimism 成功做出贡献的链上建设者。 100 | 101 | Retro Funding 的实验框架包括三个核心部分： 102 | 103 | 1. **影响范围界定**：集体应该资助什么？如何定义和决定？ 104 | 105 | 2. **影响评分**：公民议会如何评估影响？使用什么单位、流程或工具？ 106 | 107 | 3. **影响结算**：投票如何进行？ 108 | 109 | 在最初的几轮 Retro Funding 中，Optimism 基金会将在社区的反馈下决定范围和投票机制。最终，关于资助内容、资金额度和投票方式的决定权将交由公民议会，并由代币议会（Token House）进行制衡。随着时间的推移，集体计划扩大 Retro Funding 的范围，支持超越 Optimism 生态系统的公共物品生产。为实现这一目标，我们必须通过定期实验来完善 Retro Funding 所使用的工具和流程。 110 | 111 | 此外，Optimism 集体正在从大范围的轮次过渡到更集中、更小规模的轮次，以提高建设者的可预测性和投票过程的效率。这种转变旨在更好地驱动和衡量建设者行为，根据范围调整轮次设计，并确定优先级。在 2024 年，Retro Funding 将专注于试验小范围的轮次，并暂停执行大范围的轮次。 112 | 113 | 总的来说，Retro Funding 通过奖励过去的有益贡献，激励建设者为 Optimism 集体和更广泛的区块链生态系统创造价值。这一机制的持续实验和优化，旨在实现公共利益与个人利润的统一，推动生态系统的可持续发展。 114 | 115 | ### 2025.01.15 116 | 117 | RetroPGF 获奖项目，查看了 top1 项目，该项目是一个基于 Polygon 区块链的 NFT 项目。该项目旨在通过发行独特的非同质化代币（NFT），为用户提供特定的数字资产或权益。用户可以通过参与该项目，获取这些独特的 NFT，进而享有相应的数字权益或收藏价值。 118 | 119 | ### 2025.01.16 120 | 121 | Optimism 的 Superchain 是一个由多个 Layer 2（L2）链组成的网络，这些链被称为 OP 链（OP Chains），它们共享安全性、通信层和开源技术栈（OP Stack）。与传统的多链设计不同，Superchain 中的这些链是标准化的，旨在作为可互换的资源使用。这使得开发者能够构建针对整个 Superchain 的应用程序，而无需关注底层运行的具体链。 122 | 123 | **Superchain 的主要特性：** 124 | 125 | 1. **共享的 Layer 1（L1）区块链**：提供所有 OP 链交易的全局排序，确保一致性和协调性。 126 | 127 | 2. **共享的桥接机制**：为所有 OP 链提供标准化的安全属性，简化跨链交互。 128 | 129 | 3. **低成本的 OP 链部署**：使得在 OP 链上的部署和交易无需承担在 L1 上进行交易的高额费用。 130 | 131 | 4. **可配置的 OP 链选项**：允许 OP 链配置其数据可用性提供者、排序者地址等，提供灵活性。 132 | 133 | 5. **安全的交易和跨链消息传递**：确保用户能够在 OP 链之间安全地迁移状态。 134 | 135 | **从 Optimism 到 Superchain 的升级路径：** 136 | 137 | 在 Bedrock 版本之后，为实现 Superchain 的初步形态，需要进行以下更改： 138 | 139 | 1. **将 Bedrock 桥接升级为链工厂**：通过在 L1 上引入 SystemConfig 合约，将 L2 链的配置信息上链，包括生成唯一的链 ID、关键配置值（如区块 Gas 限制）等。这使得可以通过链工厂部署配置和所需的合约，甚至通过 CREATE2 实现确定性的合约地址，从而实现虚拟免费的链部署，并使链继承标准的安全属性。 140 | 141 | 2. **引入共享的通信层**：为了实现 OP 链之间的无缝交互，需要一个共享的通信层，允许跨链消息传递和状态迁移。这将进一步增强 Superchain 的互操作性和用户体验。 142 | 143 | 3. **实施去中心化治理**：Superchain 的成功依赖于去中心化的治理结构，确保所有参与者都有发言权，并共同维护网络的安全和发展。这可以通过引入公民议会（Citizens' House）和代币持有者议会（Token House）等机制来实现。 144 | 145 | **Superchain 的愿景：** 146 | 147 | Superchain 的目标是将 OP 主网（OP Mainnet）和其他链合并为一个统一的 OP 链网络，提供可扩展且去中心化的计算资源。通过将链视为可互换的计算资源，开发者可以构建跨链应用程序，而无需引入系统性风险或承担新链部署的高昂成本。这种链的抽象化使得可以将这个互操作的链网络视为一个整体，即 Superchain。 148 | 149 | 目前，Superchain 仍处于概念和开发阶段，其实际实现将取决于 Optimism Collective 的广泛贡献。随着技术的进步和社区的参与，Superchain 有望成为实现可扩展、去中心化计算的关键一步。 150 | 151 | **参考资料：** 152 | 153 | - Superchain 解释：https://docs.optimism.io/superchain/superchain-explainer 154 | 155 | - OP Stack 入门：https://docs.optimism.io/stack/getting-started 156 | 157 | - Optimism 文档：https://docs.optimism.io/ 158 | 159 | - Optimism 官网：https://www.optimism.io/ 160 | 161 | - Optimism 社区：https://community.optimism.io/ 162 | 163 | ### 2025.01.17 164 | 165 | 听 ZhouQi 老师的分享：https://www.youtube.com/watch?v=VGxzUxryiqE 166 | 167 | ### 2025.01.18 168 | 169 | Optimism 是一个极大地促进 Ethereum 可范围性和用户体验的 Layer 2 可扩展解决方案。它基于 Optimistic Rollup 技术构建。通过将大量交易紧凑地合并并在 Ethereum 上查证一些关键信息，Optimism 可以大大降低运营成本。本笔记将总结 Optimism 的起步指南，以便创建者和应用开发者快速上手。 170 | 171 | 基础概念 172 | 173 | 1. 介绍 Optimism 174 | 175 | Optimism 是屏蔽上下文构造和进行警告确认的最终安全方案。其重要特性包括： 176 | 177 | 高度兼容现有 Ethereum 应用和工具，包括智能合约。 178 | 179 | 以优化结构和减少 Layer 1 输入为目标，达到运行成本的最大化优化。 180 | 181 | 支持公共利益的开放性。 182 | 183 | 2. 优势 184 | 185 | Optimism 拥有以下优势： 186 | 187 | 以用户为核心：与 Ethereum 高度兼容，充分利用现有应用和工具。 188 | 189 | 应用带来体验优化：大量减少涉及成本，为应用和用户提供性价比更高的服务。 190 | 191 | 适用的加密和检验机制：通过涉及成本和核心警告，确保安全性和选择权。 192 | 193 | 3. Optimistic Rollup 194 | 195 | Optimistic Rollup 依赖于“想信举警”，即比较应用之间不透明性和代理局限。它通过保存带有检验机制的存货，确保安全与放垂功能。 196 | 197 | ### 2025.01.19 198 | 199 | 实践步骤 200 | 201 | 1. 环境准备 202 | 203 | 在实现 Optimism 应用之前，需要下列工具： 204 | 205 | 安装 Node.js (v14 以上)和 npm，完善环境构建： 206 | 207 | ``` 208 | node -v 209 | npm -v 210 | ``` 211 | 212 | 使用 Truffle 或 Hardhat 进行智能合约开发与部署。 213 | 214 | 利用 Remix IDE 快速测试和调试智能合约。 215 | 216 | 2. 部署和测试应用 217 | 218 | 在 Optimism 上开发和测试应用的基本流程包括： 219 | 220 | 设置开发环境： 221 | 安装必要的库和工具，例如 @ethereum-optimism/contracts，并配置 Hardhat 项目。 222 | 223 | npm install --save-dev @ethereum-optimism/contracts 224 | 225 | 编写和编译智能合约： 226 | 使用 Solidity 编写智能合约，并使用 Hardhat 或 Truffle 编译。 227 | 228 | npx hardhat compile 229 | 230 | 部署到 Optimism 网络： 231 | 配置网络信息，例如 Optimism Goerli 测试网，并部署合约。 232 | 233 | ``` 234 | module.exports = { 235 | networks: { 236 | optimismGoerli: { 237 | url: "https://goerli.optimism.io", 238 | accounts: [""] 239 | } 240 | } 241 | }; 242 | ``` 243 | 244 | 然后运行部署脚本： 245 | 246 | ``` 247 | npx hardhat run scripts/deploy.js --network optimismGoerli 248 | ``` 249 | 250 | 测试应用功能： 251 | 使用 Optimism 的工具，例如 Optimism Explorer，验证合约是否正确部署并运行。 252 | 253 | 3. 迁移现有应用到 Optimism 254 | 255 | 将现有的 Ethereum 应用迁移到 Optimism 通常只需做少量更改： 256 | 257 | 升级合约部署工具：支持 Optimism 的网络。 258 | 259 | 配置交易参数：确保使用 Optimism 的 gas 参数。 260 | 261 | 测试和验证：通过模拟器或测试网验证功能是否正常。 262 | 263 | 4. 调试和优化 264 | 265 | 使用 Optimism 提供的调试工具，例如 Debugging Proxies，分析交易和性能。 266 | 267 | 优化智能合约逻辑以适应 Rollup 模式，减少不必要的操作。 268 | 269 | ### 2025.01.20 270 | 271 | 查看项目[Bitget](https://www.superchain.eco/ecosystem-projects/bitget) 272 | 273 | ### 2025.01.22 274 | 275 | 查看项目[Rainbow Wallet](https://www.superchain.eco/ecosystem-projects/rainbow-wallet) 276 | 277 | Rainbow Wallet 是一款非托管的以太坊钱包，旨在简化数字资产管理和与去中心化应用（dApps）的交互。它支持 iOS、Android 平台，并提供浏览器扩展，功能丰富，适合初学者和有经验的用户。 278 | 279 | **主要功能：** 280 | 281 | - **以太坊名称服务（ENS）集成：** 允许用户将复杂的钱包地址替换为易于识别的可读名称，减少错误，简化交易过程。 282 | 283 | - **内置代币交换：** 用户可以直接在应用内进行代币交换，无需依赖外部平台。 284 | 285 | - **NFT 支持：** 用户可以在钱包中管理和展示他们的非同质化代币（NFT）收藏。 286 | 287 | **价值主张：** 288 | 289 | Rainbow Wallet 通过提供无缝的界面来管理基于以太坊的资产，提升了 Web3 体验。其对 ENS 的支持使用户能够用可读名称替换复杂的钱包地址，减少错误，简化交易。 290 | 291 | **治理与代币经济学：** 292 | 293 | Rainbow Wallet 没有正式的治理流程，也没有原生代币。 294 | 295 | **融资历史：** 296 | 297 | - 2020 年，完成了 150 万美元的种子轮融资。 298 | 299 | - 2021 年，完成了 1800 万美元的 A 轮融资。 300 | 301 | **用户评价：** 302 | 303 | 根据 App Store 的评价，Rainbow Wallet 在台湾地区的评分为 4.9（满分 5 分），用户普遍对其设计和易用性表示满意。 304 | 305 | **优缺点分析：** 306 | 307 | **优点：** 308 | 309 | - 支持以太坊和 EVM 兼容链，如 Polygon、Optimism、Arbitrum 等。 310 | 311 | - 支持 Web3，可连接去中心化应用、DeFi 工具、NFT 市场等。 312 | 313 | - 提供移动应用程序，适用于 iOS 和 Android。 314 | 315 | - 完全免费使用/下载。 316 | 317 | - 开源，代码透明。 318 | 319 | **缺点：** 320 | 321 | - 不支持比特币、Cosmos 生态系统、Polkadot 生态系统、Tron、Algorand 等。 322 | 323 | - 没有独立的桌面应用程序。 324 | 325 | - 不支持作为浏览器扩展使用，因此不支持 Chrome、Firefox、Edge、Opera 等浏览器。 326 | 327 | **安全性：** 328 | 329 | Rainbow Wallet 是一个非托管钱包，用户完全控制他们的私钥和资产。此外，Rainbow Wallet 是开源的，代码透明，用户可以查看和验证其安全性。 330 | 331 | **总结：** 332 | 333 | Rainbow Wallet 是一款功能丰富且用户友好的以太坊钱包，适合希望简化数字资产管理和与 dApps 交互的用户。其对 ENS 的支持、内置代币交换和 NFT 管理功能，使其在众多以太坊钱包中脱颖而出。 334 | 335 | ### 2025.01.23 336 | 337 | 查看项目[Sky Strife](https://www.superchain.eco/ecosystem-projects/sky-strife) 338 | 339 | Sky Strife 是由 Lattice 团队开发的一款全链实时战略游戏（RTS），旨在为玩家提供独特且沉浸式的多人在线战斗竞技场体验，强调战略玩法和角色定制。 340 | 341 | **游戏概述** 342 | 343 | Sky Strife 完全运行在区块链上，利用 MUD 引擎构建，确保游戏逻辑和数据的透明性和不可篡改性。 ([Medium](https://medium.com/%40awchangelog/sky-strife%E6%B8%B8%E6%88%8F%E6%94%BB%E7%95%A5-cn-c2e9fb7e247b?utm_source=chatgpt.com))游戏的核心资源是名为 Orbs 的 ERC-20 代币，玩家通过消耗 Orbs 创建比赛，并根据比赛结果获得相应的奖励。 344 | 345 | **主要功能** 346 | 347 | 1. **全链架构**：Sky Strife 的所有游戏逻辑和数据都存储在区块链上，确保了游戏的透明性和公平性。这种全链设计使得游戏的每一个动作和事件都可被验证，增强了玩家对游戏的信任。 ([Medium](https://medium.com/%40awchangelog/sky-strife%E6%B8%B8%E6%88%8F%E6%94%BB%E7%95%A5-cn-c2e9fb7e247b?utm_source=chatgpt.com)) 348 | 349 | 2. **实时战略玩法**：不同于大多数全链游戏采用的回合制机制，Sky Strife 提供了实时战略体验，玩家需要在瞬息万变的战场上快速做出决策，增加了游戏的挑战性和趣味性。 ([ChainCatcher](https://www.chaincatcher.com/article/2126296?utm_source=chatgpt.com)) 350 | 351 | 3. **角色定制**：玩家可以根据自己的策略和喜好，自定义角色的技能和装备，打造独一无二的游戏角色，增强了游戏的深度和可玩性。 352 | 353 | **代币经济学** 354 | 355 | Sky Strife 的核心资源是 Orbs，总供应量固定为 1 亿枚，全部铸造并存储在名为 Sky Pool 的智能合约中。玩家每创建一场比赛需要消耗 100 枚 Orbs，比赛结束后，系统根据玩家的排名和最近的比赛活动，从 Sky Pool 中向获胜者发放奖励。这种设计确保了 Orbs 的稀缺性和价值稳定性。 356 | 357 | **季票（Season Pass）** 358 | 359 | Sky Strife 引入了季票机制，每个赛季开始前，玩家可以购买季票以获得特定的游戏特权。例如，在 Season 0 赛季中，季票售价为 0.03 ETH，持有者可以创建私人游戏、使用专属英雄和地图，以及参与专属对战。需要注意的是，每个季票仅在当前赛季有效，无法跨赛季使用。 ([Medium](https://medium.com/%40funblocksfun/sky-strife-season-0%E8%B5%9B%E5%AD%A3%E6%9B%B4%E6%96%B0%E5%86%85%E5%AE%B9%E9%80%9F%E8%A7%88-33c63e6c2da8?utm_source=chatgpt.com)) 360 | 361 | **治理结构** 362 | 363 | 目前，Sky Strife 尚未建立正式的治理流程。游戏的开发和管理由 Lattice 团队负责，团队资金来源于 0xPARC 基金会和 Optimism 基金会等组织的资助。 364 | 365 | **市场表现** 366 | 367 | Sky Strife 于 2024 年 5 月上线 Redstone 主网。截至目前，游戏已产生超过 1000 场对战，注册玩家数达到 798 人。这种活跃度显示了玩家对全链实时战略游戏的浓厚兴趣。 ([Bitget](https://www.bitgetapps.com/zh-CN/news/detail/12560603989352?utm_source=chatgpt.com)) 368 | 369 | **用户体验与风险提示** 370 | 371 | 作为一款全链游戏，Sky Strife 提供了透明、公平且不可篡改的游戏体验。然而，玩家在参与游戏时应注意区块链交易可能带来的延迟和交易费用。此外，游戏内的代币经济学可能涉及复杂的金融机制，建议玩家在参与前充分了解相关规则，理性参与，避免过度投入。 372 | 373 | **总结** 374 | 375 | Sky Strife 通过将实时战略玩法与区块链技术相结合，创造了一个独特且引人入胜的游戏生态系统。其全链架构确保了游戏的透明性和公平性，丰富的玩法和角色定制选项为玩家提供了多样化的体验。然而，玩家在参与时应保持谨慎，充分了解游戏机制和潜在风险，以获得最佳的游戏体验。 376 | 377 | ### 2025.01.24 378 | 379 | 听分享会议，主题：如何玩转欺诈证明 380 | 381 | ### 2025.01.26 382 | 383 | ```markdown 384 | # Uniswap 学习笔记 385 | 386 | ## 一、Uniswap 简介 387 | 388 | Uniswap 是一个基于以太坊网络的去中心化交易所（DEX）协议，采用自动化做市商（AMM）模型，为用户提供无需信任的代币交易方式。它以简化的设计和高效的流动性机制成为去中心化金融（DeFi）的重要组成部分。 389 | 390 | --- 391 | 392 | ## 二、核心功能与机制 393 | 394 | ### 1. 自动化做市商（AMM） 395 | 396 | - Uniswap 不依赖传统订单簿，而是通过智能合约维护代币池。 397 | - 用户可以在池中任意买卖代币，价格由公式 \( x \times y = k \) 决定。 398 | 399 | ### 2. 集中式流动性 400 | 401 | - 最新版本支持流动性提供者（LP）在特定价格区间内提供流动性。 402 | - 提高资金效率，降低无常损失（impermanent loss）的风险。 403 | 404 | ### 3. 代币经济学 405 | 406 | - **原生代币**：UNI，总供应量上限为 10 亿。 407 | - **用途**： 408 | - 治理投票：持有者可参与协议升级和重要决策。 409 | - 添加流动性或支付交易费用。 410 | - **通胀机制**：四年后每年以 2% 通胀率增发，支持长期发展。 411 | 412 | --- 413 | 414 | ## 三、治理流程 415 | 416 | Uniswap 的治理由 UNI 持有者主导，通过以下流程实现： 417 | 418 | 1. **温度检查** 419 | 420 | - 在治理论坛提出初步想法，需获得至少 25,000 UNI 的支持进入下一阶段。 421 | 422 | 2. **共识检查** 423 | 424 | - 提交详细提案，讨论并进行投票。 425 | 426 | 3. **正式提案** 427 | - 提案人需持有至少 250 万 UNI。 428 | - 通过治理门户提交提案，需经过： 429 | - 2 天投票延迟期 430 | - 7 天投票期，需获得总供应量的 4% 支持 431 | - 2 天时间锁定期后执行。 432 | 433 | --- 434 | 435 | ## 四、资金来源与发展 436 | 437 | ### 1. 资金来源 438 | 439 | - 2018 年获得以太坊基金会 10 万美元赠款。 440 | - 2019 年获得由 Paradigm 领投的 180 万美元种子轮融资。 441 | 442 | ### 2. 发展历程 443 | 444 | - 2024 年 10 月推出专用第二层网络 **Unichain**，基于 Optimism OP Stack 构建，进一步优化 DeFi 体验。 445 | 446 | --- 447 | 448 | ## 五、Unichain 的特点 449 | 450 | ### 1. 性能优化 451 | 452 | - 基于乐观汇总（Optimistic Rollup），实现高效交易和低成本。 453 | - **Flashblocks** 技术：200-250 毫秒区块时间，减少延迟。 454 | 455 | ### 2. 跨链互操作性 456 | 457 | - 与 Superchain 集成，支持跨汇总的流动性无缝移动。 458 | 459 | ### 3. 治理机制 460 | 461 | - 采用去中心化验证网络（UVN）。 462 | - 验证者通过质押 UNI 参与治理和网络保护。 463 | 464 | ### 4. 用户保护 465 | 466 | - 引入可信恢复机制，自动移除失败交易，节约用户费用。 467 | - 集成 Rollup Boost，保护用户免受最大可提取价值（MEV）影响。 468 | 469 | --- 470 | 471 | ## 六、未来影响 472 | 473 | ### 1. 效率提升 474 | 475 | - Uniswap 的创新，如集中式流动性和 Unichain 的推出，为 DeFi 用户提供更高效的体验。 476 | 477 | ### 2. 增强互操作性 478 | 479 | - 通过与 Superchain 集成，实现跨链资产流动，为 DeFi 生态扩展带来更多可能性。 480 | 481 | ### 3. 社区驱动的可持续发展 482 | 483 | - 强调社区治理和代币激励，促进生态系统健康成长。 484 | 485 | --- 486 | 487 | ## 七、总结 488 | 489 | Uniswap 以其创新的流动性提供方式、强大的社区治理模式和专注用户体验的技术优化，成为 DeFi 领域的先驱。通过推出 Unichain 等新功能，Uniswap 不仅在交易效率和成本方面取得突破，还增强了去中心化金融生态的整体可达性与安全性。 490 | ``` 491 | 492 | 493 | -------------------------------------------------------------------------------- /ChoeyGit.md: -------------------------------------------------------------------------------- 1 | --- 2 | timezone: Asia/Shanghai 3 | --- 4 | 5 | > 请在上边的 timezone 添加你的当地时区，这会有助于你的打卡状态的自动化更新，如果没有添加，默认为北京时间 UTC+8 时区 6 | > 时区请参考以下列表，请移除 # 以后的内容 7 | 8 | timezone: Pacific/Honolulu # 夏威夷-阿留申标准时间 (UTC-10) 9 | 10 | timezone: America/Anchorage # 阿拉斯加标准时间 (UTC-9) 11 | 12 | timezone: America/Los_Angeles # 太平洋标准时间 (UTC-8) 13 | 14 | timezone: America/Denver # 山地标准时间 (UTC-7) 15 | 16 | timezone: America/Chicago # 中部标准时间 (UTC-6) 17 | 18 | timezone: America/New_York # 东部标准时间 (UTC-5) 19 | 20 | timezone: America/Halifax # 大西洋标准时间 (UTC-4) 21 | 22 | timezone: America/St_Johns # 纽芬兰标准时间 (UTC-3:30) 23 | 24 | timezone: America/Sao_Paulo # 巴西利亚时间 (UTC-3) 25 | 26 | timezone: Atlantic/Azores # 亚速尔群岛时间 (UTC-1) 27 | 28 | timezone: Europe/London # 格林威治标准时间 (UTC+0) 29 | 30 | timezone: Europe/Berlin # 中欧标准时间 (UTC+1) 31 | 32 | timezone: Europe/Helsinki # 东欧标准时间 (UTC+2) 33 | 34 | timezone: Europe/Moscow # 莫斯科标准时间 (UTC+3) 35 | 36 | timezone: Asia/Dubai # 海湾标准时间 (UTC+4) 37 | 38 | timezone: Asia/Kolkata # 印度标准时间 (UTC+5:30) 39 | 40 | timezone: Asia/Dhaka # 孟加拉国标准时间 (UTC+6) 41 | 42 | timezone: Asia/Bangkok # 中南半岛时间 (UTC+7) 43 | 44 | timezone: Asia/Shanghai # 中国标准时间 (UTC+8) 45 | 46 | timezone: Asia/Tokyo # 日本标准时间 (UTC+9) 47 | 48 | timezone: Australia/Sydney # 澳大利亚东部标准时间 (UTC+10) 49 | 50 | timezone: Pacific/Auckland # 新西兰标准时间 (UTC+12) 51 | 52 | --- 53 | 54 | # {DongChoeyGit/董卓杰} 55 | 56 | 1. Working hard to be a Web3 builder、Eterpay Web3 department manager、Bankless DAO member、Bankless CNmember、LeapOnchain Channel builder、Lil Nounser 57 | 58 | 2. 是的，我会完成本次残酷共学 59 | 60 | ## Notes 61 | 62 | 63 | 64 | ### 2025.01.06 65 | 66 | Optimism 的核心是帮助来自世界各地的人在中心化经济背景下利用它的 Optimistic Rollup 技术以及 Optimism 的 Tokenomics 搭建社区的治理体系。它的 Rollup 机制跟随着以太坊的共识作为核心思想，这个选择由于跟随主链的共识避免产生新共识造成的分叉，在一定程度上为其提供了足够的安全性。 67 | 68 | ### 2025.01.07 69 | 70 | 在 Optimism 的迭代更新“Bedrock”后，使用了一种非合约地址保存到以太坊的方式来减少 L1 的 gas fee，具体是将数据以压缩格式打包储存，使用 EIP-4844 的 blobs 作为实现路径。该路径的设计可以做到保持数据不可修改性同时，保证了可用性与完整性，更重要的是区块以压缩的格式写入 L1 极大减少了交易成本。 71 | 72 | ### 2025.01.08 73 | 74 | Optimism “块” 的生产机制：Optimism 基金会是目前 OP Mainnet 上唯一的区块生产者，根据 Optimism 的 “Bedrock” 升级的内容，区块的生产由 sequencer 单一负责，完成交易的确认、状态的更新、L2 区块的构建与执行以及将用户交易数据提交到 L1。在 sequencer 设置了私有的内存池，以此规避 MEV 带来的问题。sequencer 没两秒生成一个区块，不管区块中是否包含交易。在 Optimism 中交易有两种提交的方式：1.直接提交：该方式成本较低，但缺乏抗审查性。2.提交到相应的 L2 区块中，这种方式提供了抗审查性。sequencer 必须同时要处理 L1 中的合法交易，以保持数据的一致性。 75 | 76 | ### 2025.01.09 77 | 78 | Optimism 的区块执行引擎通过 op-geth 的组建实现的，主要通过两种机制接收：1.点对点的网络更新方式。2.节点的 Rollup。 79 | Optimism允许在L1和L2之间发送消息，实现ETH和ERC20代币的转移。标准桥功能支持从以太坊存入代币到OP Mainnet及提取回以太坊。 80 | 从以太坊到OP Mainnet的交易称为存款，使用L1CrossDomainMessenger或L1StandardBridge。从OP Mainnet到以太坊的提款分为三个阶段，包括初始化提款、提交证明和完成提款。 81 | 82 | ### 2025.01.10 83 | 84 | Optimism 的故障证明机制 85 | 在 Optimism 中使用状态承诺发布到以太坊主链，但是一一种待定状态，没有直接的有效证明。这种待定状态称之为挑战窗口（7 天时间），在此时间内如果没有人对更新的状态有异议，则会被视为最终确认状态，一旦进入最终确认状态，以太坊智能合约将会执行接收。当挑战窗口期间有人有异议，可以对承诺发出挑战，通过“故障证明”将其无效化。如果挑战成功则会从状态承诺链中移除，并可能被另一个提议的承诺替换。需要注意的是，成功的挑战不会回滚OP主网本身，只会影响已发布的状态承诺。交易的顺序和OP主网的状态不会因故障证明挑战而改变。故障证明过程目前正在进行重大重构，这是由于2021年11月11日EVM等效性更新的副作用。 86 | 87 | ### 2025.01.13 88 | 89 | Layer 2：是一種在區塊鏈主網（Layer 1）之上運行的解決方案，旨在提高交易速度和降低成本。 90 | 四種主要的 Layer 2 解決方案： 91 | 92 | Plasma：通過創建子鏈來處理交易，減少主鏈的負擔。 93 | 交易成本 —— Plasma 的交易成本相對較低，因為它通過子鏈處理大量交易，減少了主鏈的負擔。 94 | 成本結構 —— 用戶在子鏈上進行交易時，通常只需支付少量的手續費，這使得 Plasma 成為高頻交易的經濟選擇。 95 | 注意事項 —— 然而，當用戶需要從子鏈退出時，可能需要支付額外的成本，這取決於退出的複雜性和時間。 96 | 97 | Rollups：將多筆交易打包，然後提交到主鏈，分為 zk-Rollups 和 Optimistic Rollups。 98 | 交易成本：Rollups（特別是 zk-Rollups）通常提供非常低的交易成本，因為它們能夠將多筆交易打包並一次性提交到主鏈。 99 | 成本結構：Optimistic Rollups 的交易成本也相對較低，但由於需要進行欺詐證明，可能會在某些情況下增加額外的成本。 100 | 效率：整體而言，Rollups 的效率使其成為許多應用的首選，尤其是在需要高吞吐量的情況下。 101 | 102 | State Channels：允許用戶在私下進行多次交易，最終只將結果提交到主鏈。 103 | 交易成本：State Channels 的交易成本非常低，因為大部分交易是在私下進行的，只有最終結果需要提交到主鏈。 104 | 成本結構：用戶只需在開啟和關閉通道時支付手續費，這使得它們在頻繁交易的場景中非常經濟。 105 | 限制：不過，這種模式的成本效益主要適用於需要多次交易的情況，對於單次交易的場景則不太適合。 106 | 107 | Sidechains：獨立的區塊鏈，與主鏈互動，能夠自定義共識機制。 108 | 交易成本：Sidechains 的交易成本可以根據其設計和共識機制的不同而有所變化。 109 | 成本結構：一般來說，Sidechains 的交易成本相對於主鏈會有所降低，但具體成本取決於其運行的效率和設計。 110 | 靈活性：由於 Sidechains 可以自定義共識機制，這使得它們在某些情況下能夠提供更具競爭力的交易成本。 111 | 112 | ### 2025.01.14 113 | 114 | 四種提高交易速度與降低交易成本的 Layer 2 解決方案的優缺點的總結與分析： 115 | 116 | Plasma 117 | 優點： 118 | 擴展性：Plasma 可以通過創建多個子鏈來處理大量交易，顯著提高交易吞吐量。 119 | 安全性：由於子鏈的交易最終會提交到主鏈，這樣可以利用主鏈的安全性。 120 | 缺點： 121 | 複雜性：Plasma 的設計和實現相對複雜，開發者需要處理多個子鏈的狀態和安全性。 122 | 退出機制：用戶在需要從子鏈退出時，可能需要等待一段時間，這會影響用戶體驗。 123 | 124 | Rollups 125 | 優點： 126 | 高效性：Rollups 可以將大量交易打包，減少提交到主鏈的頻率，從而降低交易成本。 127 | 即時性：特別是 zk-Rollups，能夠提供即時的交易確認，提升用戶體驗。 128 | 缺點： 129 | 計算負擔：Optimistic Rollups 需要在主鏈上進行欺詐證明，這可能導致延遲。 130 | 技術挑戰：zk-Rollups 的實現需要複雜的數學證明，對開發者的技術要求較高。 131 | 132 | State Channels 133 | 優點： 134 | 快速交易：用戶可以在私下進行多次交易，無需每次都提交到主鏈，這樣可以實現即時交易。 135 | 低成本：由於大部分交易不需要上鏈，交易成本大幅降低。 136 | 缺點： 137 | 使用限制：State Channels 適合頻繁交易的場景，但不適合所有類型的交易。 138 | 通道管理：用戶需要管理通道的開啟和關閉，這可能增加操作的複雜性。 139 | 140 | Sidechains 141 | 優點： 142 | 靈活性：Sidechains 可以自定義共識機制和功能，適應不同的應用需求。 143 | 獨立性：Sidechains 可以獨立於主鏈運行，減少主鏈的負擔。 144 | 缺點： 145 | 安全性問題：Sidechains 的安全性依賴於其自身的共識機制，可能不如主鏈安全。 146 | 互操作性：與主鏈的交互可能會帶來額外的複雜性，影響用戶體驗。 147 | 總結 148 | 149 | ### 2025.01.16 150 | 151 | Rollups 是扩展以太坊的一种有前途的解决方案，但在早期阶段通常依赖于中心化控制的“训练轮”。这些训练轮在系统更新和修复错误时是必要的，但最终需要去除，以便 rollups 能够完全继承基础层的安全性。 152 | 新框架，该框架将 rollups 分为三个阶段，基于它们对“训练轮”的依赖程度： 153 | 154 | State 0 （完整训练） 155 | 1.Rollup 由运营者有效管理。2.必须自称为 rollup，并在 L1 上发布状态根。3.必须确保数据可用性，并提供能够从 L1 数据重建 L2 状态的软件。 156 | 157 | State 1（有限训练） 158 | 1.Rollup 开始由智能合约治理，但可能仍有安全委员会以处理潜在的错误。2.实现完整的证明系统，允许至少 5 个外部参与者提交欺诈证明。3.用户可以在没有运营者协调的情况下独立退出，且在不良升级情况下至少有 7 天的退出时间。 159 | 160 | State 2（无需训练） 161 | 1.Rollup 完全由智能合约管理，欺诈证明系统是无权限的。2.用户在不良升级情况下至少有 30 天的退出时间。3.安全委员会的作用仅限于处理可在链上裁决的错误。 162 | 163 | ### 2025.01.17 164 | 165 | State 0 要求： 166 | 1.项目必须自称为 rollup。2.L2 状态根必须在L1上发布。3.必须确保数据可用性，并提供重建 L2 状态的软件。 167 | 168 | State 1 要求： 169 | 1.使用适当的证明系统。2.至少有 5 个外部参与者可以提交欺诈证明。3.用户可以独立退出，且在不良升级情况下至少有 7 天的退出时间。4.安全委员会必须通过多签设置，确保多样性和透明度。 170 | 171 | State 2 要求： 172 | 1.欺诈证明系统必须是无权限的。2.用户在不良升级情况下至少有 30 天的退出时间。3.安全委员会的作用仅限于处理链上检测到的错误。 173 | 174 | 未来的發展思路： 175 | 该框架旨在为 rollups 的成熟度讨论提供参考，并激励项目在其路线图中关注特定的安全措施。文章呼吁社区对框架的某些方面进行讨论，以便每个项目能够表达其在改善阶段评估方面的立场，从而促进对特定风险因素的结构化辩论。 176 | 177 | ### 2025.01.19 178 | 179 | Optimism Collective是一个由公司、社区和公民组成的团体，旨在奖励公共产品并为以太坊的可持续未来而努力。该组织的核心理念是通过支持公共产品的开发和维护，促进生态系统的健康发展。 180 | 181 | 使命与愿景：Optimism Collective 的目标是通过激励机制来支持公共产品，确保以太坊生态系统的长期可持续性。他们相信，健康的公共产品能够创造一个繁荣且有价值的生态系统。 182 | 183 | 治理结构：1.该组织采用去中心化的治理模式，允许社区成员参与决策过程。2.通过透明的治理机制，确保所有利益相关者的声音都能被听到。 184 | 185 | 激励机制：1.Optimism Collective 设计了一系列激励措施，以鼓励开发者和用户参与公共产品的建设。2.这些激励措施包括代币奖励和其他形式的支持。 186 | 187 | 社区参与：1.强调社区在推动公共产品发展中的重要性，鼓励更多人参与到生态系统中来。2.通过教育和资源共享，提升社区成员的参与感和归属感。 188 | 189 | -------------------------------------------------------------------------------- /Coooder-Crypto.md: -------------------------------------------------------------------------------- 1 | --- 2 | timezone: Asia/Shanghai 3 | --- 4 | 5 | # {Coooder} 6 | 7 | 1. 自我介绍 8 | 我是 Coooder, 一直有接触 OP 相关的内容，但是没有系统性地学习过，想借助这个机会来学习一下 9 | 10 | 2. 你认为你会完成本次残酷学习吗？ 11 | 会 12 | 13 | ## Notes 14 | 15 | 16 | 17 | ### 2025.01.06 18 | 19 | 今天学习了这个文章：https://docs.optimism.io/stack/rollup/overview 20 | 21 | ### 2024.07.12 22 | 23 | 24 | -------------------------------------------------------------------------------- /DasNarrenschiff.md: -------------------------------------------------------------------------------- 1 | --- 2 | timezone: Asia/Shanghai 3 | --- 4 | # loxia 5 | 6 | https://x.com/Loxia_in_Tj 7 | 8 | ## Notes 9 | 10 | 11 | 12 | ### 2025.01.06 13 | 14 | Superchain 速览 15 | 16 | 愿景：通过标准化和模块化的技术栈，实现跨链数据和资产的无缝流转，同时共享以太坊的安全性和资源。 17 | 18 | Superchain 内的每条链都需要将排序器总收入或利润的 15% 支付给 Optimism Collective，旨在聚合 L2/L3s 的流动性，引导形成网络效应。 19 | 20 | - ERC-7802 对 SuperChain 交易的影响。 21 | - **提升跨链交易效率：**ERC-7802 通过标准化的跨链接口（如 `crosschainMint` 和 `crosschainBurn`），简化了资产在 Superchain 生态系统中的转移流程。用户不再需要依赖复杂的跨链桥或多重签名验证，而是可以直接通过统一的接口完成资产转移。这种标准化设计显著提升了跨链交易的效率，减少了操作步骤和等待时间。 22 | - **区块延迟**：Superchain 的原生互操作性使得资产转移的延迟降至 1 个区块，极大提高了资本效率。 23 | - **无需资产包装**：ERC-7802 避免了传统跨链桥中常见的资产包装（Wrapped Token）问题，用户可以直接使用原生代币进行跨链操作。 24 | - **增强资本效率：**ERC-7802 通过“销毁-铸造”机制（Burn-Mint）实现了跨链资产的无缝转移，避免了传统跨链桥中流动性池的资产锁定问题。这使得资产可以在 Superchain 生态中自由流动，最大化利用效率。 25 | - **聚合流动性**：Superchain ERC20（基于 ERC-7802 的实现）允许资产在不同链之间共享流动性，减少了流动性碎片化问题。例如，1M usd 的资产可以在 Superchain 的所有链上使用，而不需要在每条链上分别锁定资金。 26 | - **降低链间+运营成本**：通过优化链间通信和资源利用，ERC-7802 减少了跨链交易的成本，吸引了更多用户和开发者参与 Superchain 生态。 27 | 28 | 并且 ERC-7802 的模块化设计将跨链逻辑从代币合约中分离出来，开发者只需关注代币的基本功能，而无需处理复杂的跨链实现细节。标准化的跨链接口也减少了中间环节，降低了跨链桥被攻击的风险。 29 | 30 | - Base 在生态、治理和协作层面更深地绑定 SuperChain 的整体框架意味着什么？ 31 | - Base 通过收入共享协议向 Optimism 支付 2.5% 的排序器收入或 15% 的利润，同时获得 1.18 亿 OP 代币（分六年支付），用于生态激励和治理参与，OP 和 Base 在战略利益上将长期绑定。 32 | - Base 将参与 Optimism 提出的“Law of Chains”治理框架，与 Superchain 实现更硬性的绑定。 33 | - Base 将作为实践“Law of Chains”治理框架的良好示范，以吸引更多链和开发者加入。 34 | - Base 的治理权限将逐步转移至由全球独立社区成员组成的安全理事会，推动 Superchain 的去中心化进程，Base 将在安全理事会中拥有部分治理权限，但其投票权限不超过总权限的 9% 35 | - OP 无疑是目前 L2 生态中最去中心化和最具生态多样性的，Base 依托 Coinbase 和相关经验可以为 OP 拓展更多现实世界的可能性，而 Base 也需要 OP 的去中心化治理/运营模式，及经验。 36 | 37 | ### 2025.01.09 38 | 39 | ## Retro Funding 的演变 40 | 41 | Retro Funding 的历史： 42 | 43 | 在早期的 Retro Funding 中，追溯的只包含公共物品，例如 RetroPGF 3 的目标： 44 | 45 | > *“Optimism 的追溯性公共物品资助（Retroactive Public Goods Funding, RetroPGF）的目标是通过追溯性分配奖励，实现“**影响力=利润**”的原则——即对集体的积极影响应转化为个人的利润。这一原则作为北极星，激励创建一个更具生产力和可持续性的经济体系。* 46 | > 47 | 48 | > ***影响力**：表示贡献者为 Optimism 集体创造的价值。* 49 | > 50 | 51 | > ***利润**：表示贡献者从 Optimism 集体中提取的价值。* 52 | > 53 | 54 | > ***差距**：表示贡献者的影响力与利润之间的差异。* 55 | > 56 | > 57 | > *（例如：影响力 - 利润 = 差距）* 58 | > 59 | 60 | > *RetroPGF 填补了贡献者的影响力与利润之间的差距，从而实现“**影响力=利润**”的状态。”* 61 | > 62 | 63 | Retroactive Public Goods Funding 1 ~ 3（回溯性公共物品激励） 资助了很多优秀的公共物品，如 RPGF 2 中的 ZachXBT，ZashXBT 是加密货币领域的“无面侦探”，通过链上分析技术揭露骗局、追踪被盗资金，为行业透明度和安全性做出了巨大贡献，这些贡献没有直接激励网络增长，但却对整个集体产生了非常积极的影响力，使整个网络更稳健。所以 OP 的 Citizen House 中的徽章持有者会投票给 ZachXBT，ZachXBT 在 RPGF 2 中获得了近 19 万 OP 64 | 65 | 而在 Retro Funding 4 中，社区考虑到之前三轮 RPGF 缺乏对 OP 网络实际使用者的支持（在 RPGF 3 中只分配了 5% 的奖励给到网络实际使用量中前 20% 的使用者），尤其缺乏对 Superchain 上开发者增长的支持，并且 OP 社区的徽章持有者对 Retro Funding 的可持续性提出了担忧，在 Retro Funding 的 1~3 轮次，Retro Funding 依赖 850M OP 的回溯性公共物品资助（RPGF）来发放奖励。 66 | 67 | 在 Retro Funding 的第 4 轮次及之后，Retro Funding 将逐渐转向依赖协议盈余收入作为奖励来源，而之前的协议盈余收入不足以维持回溯性公共物品资助，所以 Retro Funding 在鼓励公共物品创新之外，还肩负起了直接激励网络增长的任务，**于是 Retro Funding 在第 4 轮次时首次提出对链上贡献者的资助（Onchain Builder）**，以激励开发者增长和网络活动的增加。 68 | 69 | 在 Retro Funding 4 中，Retro Funding 开始首次资助如 DeFi 类的与链上直接贡献（影响力）有关的项目，与前几轮不同，在 RF4 及之后的轮次 RF 开始着重于激励影响力本身的增长，即使受资助的项目本身不缺乏资金。 70 | 71 | Retro Funding 5 主要激励了对 OP Stack 的生态工具类项目（Utility），如集成和负载测试基础设施、运行 Optimism 节点的脚本、RaaS 提供商、OP Stack 教程与文档。Retro Funding 6 则专注于治理类别的激励，主要奖励那些在 **治理基础设施、治理分析** 和 **治理领导力** 有突出贡献的项目**。** 72 | 73 | Retro Funding S7‘s 3 main points: 74 | 75 | 1. Retro Funding: S7 Missions 76 | - 聚焦于以数据驱动的影响力衡量，并采用以人为中心的方法。这些任务（Missions）的选择旨在让集体能够准确衡量一部分重要贡献。 77 | - 整个集体围绕共同任务框架的对齐将确保所有代币分配计划的协调运作。 78 | - 评估算法定义了任务产出和结果的衡量方式。它可以包括人类定性评估和数据驱动的定量测量。奖励通过在某个或多个测量日期运行评估算法来分配。追溯资助任务中使用的评估算法将根据选定公民的反馈在整个追溯资助计划中不断演进。 79 | - （像是 Deep Funding 的尝试） 80 | 2. Retro Funding: Onchain Builders (8M OP Max) 81 | - 链上建设者奖励那些通过跨链互操作性推动资产转移的项目，这些项目通过在符合条件的OP链上扩展超级链来实现。 82 | - 评估算法的衡量标准： 83 | - SuperChain 采用率的增长 84 | - 高质量的链上价值（例如，TVL） 85 | - 跨链互操作性的支持与采用 86 | - 二月开始进行评估，奖励每月发放。 87 | 3. Retro Funding: Dev Tooling (8M OP Max) 88 | - 奖励那些支持建设者在 SuperChain 上开发链上应用的工具链软件，如编译器、库和调试器。 89 | - 评估算法的衡量标准： 90 | - 链上建设者的采用率。 91 | - 工具在链上应用开发中的重要性。 92 | - 支持建设者在 SuperChain 跨链互操作性采用的组件。 93 | - 二月开始进行评估，奖励每月发放。 94 | 95 | 96 | ### 2025.01.10 97 | 98 | Pending research link list: 99 | 100 | https://docs.contributionism.io/contributionism/characteristics/cooperative-and-competitive-environments 101 | 102 | https://mirror.xyz/optimismcn.eth/uJcBF6kl9UwUFOjCt6SnmkZBz_CUsK-W8debwVUnv6g 103 | 104 | Accelerated Decentralization Proposal For Optimism (GFX labs) 105 | https://gov.optimism.io/t/accelerated-decentralization-proposal-for-optimism/8875 106 | 107 | Insightful philosophical perspectives on governance (polynya) 108 | https://polynya.mirror.xyz/ 109 | 110 | Delegate nodes to learn: 111 | 112 | https://optimism.curiahub.xyz/delegate/delegate.l2beat.eth 113 | 114 | https://optimism.curiahub.xyz/delegate/joxes.eth 115 | 116 | https://optimism.curiahub.xyz/delegate/opmichael.eth 117 | 118 | https://vote.optimism.io/delegates/0x5d36a202687fd6bd0f670545334bf0b4827cc1e 119 | 120 | https://david.truong.vc/ 121 | 122 | seed gov 123 | 124 | 125 | 126 | ### 2025.01.11 127 | 128 | OP 社区对于 Retro Funding 7 治理改制的担忧： 129 | 130 | - 缺乏对非开发者的支持 * 3 131 | - 反复出现一个声音：“缺乏对治理研究者的支持”，并认为去中心化治理相关的专业度是 OP 在市场中的重要竞争力，治理的去中心化，利益分离，多样性固然重要，但直接表达，多少有些“职业政客”为自己的经济利益/话语权发声之嫌疑，LXDAO 治理组在输出观点时，需要尽量避免出现这个嫌疑。 132 | - **季度主题的完全轮动/转变会不利于长期耕耘在某一重要领域的开发者 * 2** 133 | - 刚刚结束的RPGF 6 非常注重治理。重要的是要有一个涵盖整个链上领域的愿景，即开发者、社区/链上用户、艺术、流动性/现实世界资产提供者、治理等。 134 | - 可以在关注季度主题的同时，不限制对其他领域的支持。与其缩小范围，或许我们可以考虑调整分配或找到一个更有意义的平衡点。 135 | - Dev Tooling 类别的定义不清晰 * 1 136 | - 社区对评估算法的纠偏权力 * 1 137 | - 对改制细节缺乏的疑问，导致无法评估这些机制本身是否正确 * 1 138 | - L2Beat 成员发言 139 | 140 | 具体的细节将在第7季正式开始前分享！公民将选择一个评估算法，该算法将随着时间的推移运行并定期进行支付（具体周期我交给Jonas来确认）。将会有机制确保算法被定期监控和改进，如果出现与预期结果的显著偏差，公民可能会被要求重新评估选择。 141 | 142 | 这对那些不懂编码和建设的人来说是不公平的。治理应该是第一位的，链上活动也是。 143 | 144 | 我相信2025年追溯资助向数据驱动的影响力衡量转变，对于奖励Optimism生态系统中有意义的贡献非常重要。对于链上建设者来说，专注于跨链资产转移和超级链采用将有助于推动增长并提高互操作性。开发者工具计划将通过提供促进跨链互操作性应用的关键工具来支持链上建设者，这对生态系统的扩展至关重要。我很高兴能参与公民投票过程，帮助塑造评估算法，并确保我们奖励那些为增长、采用和互操作性做出贡献的项目。 145 | 146 | 首先，我想声明，我在这里是以个人身份作为徽章持有者发表评论，而不是作为L2BEAT的代表。 147 | 148 | 我倾向于投票支持第7季的意图，但反对这两个追溯资助任务。 149 | 150 | 我不支持这些任务的原因是，目前它们缺乏任何细节，使我们无法评估这些机制是否正确。虽然我可以想象支持某些机制，但我也可能坚决反对其他机制，更不用说分配的金额应该取决于机制和符合该轮次的预期项目数量。目前，这两个金额只是一个没有任何理由的任意数字。 151 | 152 | 举个例子，虽然我可以想象链上建设者任务的分配可以基于链上指标自动完成，但我首先想分析我们将考虑哪些指标，以及如何防止鲸鱼简单地“耕种”这些奖励（我们在许多协议中已经多次看到这种情况）。 153 | 154 | 另一方面，我没有看到任何可以合理分配开发者工具任务奖励的指标。这是一个“人气竞赛”方法实际上有意义的类别——有影响力和价值的工具应该在开发者社区中广为人知，尽管它们可能不一定容易被客观衡量。另一方面，那些可以客观衡量的东西可能并不一定是我们想通过追溯资助奖励的。 155 | 156 | 我们在上一次L2BEAT办公时间中讨论了这一点，讨论中提出的一个关于我们如何看待该任务评估方法的想法是这样的： 157 | 158 | 首先，我们建立一个（比如有门槛的、仅限邀请以防止垃圾信息）Optimism开发者社区——作为概念验证，它可以只是一个TG群组。 159 | 在这个群组中，我们鼓励开发者分享他们使用不同开发工具的经验——这是资格的基础，同时也为其他人提供了工具发现机制。 160 | 每个周期，我们允许开发者投票选出他们认为最有影响力的开发工具。 161 | 我们认识到，在这个群组中，每个声音可能不应该平等，因为有经验丰富和较少的开发者，以及有更多或更少Optimism背景/关注的开发者。因此，每个开发者可以有10个“点”自行分配，另外10个“点”必须“给”其他开发者。 162 | 开发者将他们拥有的点（自己的+收到的）分配给他们认为最值得支持的项目。 163 | 我们每个周期（比如每个月）重复这个过程。 164 | 我并不是说这应该是最终机制，这只是30分钟头脑风暴的结果。但这是一个我个人愿意支持的追溯机制。另一方面，我不会支持一些更“客观”的机制，比如Github提交和/或星标。 165 | 166 | 因此，我认为在讨论具体的评估机制之前，决定是否采用这些追溯资助任务还为时过早，尤其是这些分配。我认为我们目前不需要急于做出决定。但如果我们承诺支持这些任务，我们将在后期被迫选择某种机制，即使我们不喜欢任何提出的机制。 167 | 168 | 我想感谢@wildmolasses @LauNaMu @brichis和@Jrocki（希望我没有漏掉任何人，如果漏掉了请见谅）在L2BEAT办公时间中与我们讨论这个话题。 169 | 170 | - **以增长为激励的 Retro Funding: Onchain Builders 无法保证除经济增长之外的积极影响 * 4** 171 | - 这并不是公共物品的激励，这会为 RF 及整个 OP 带来不好的影响（RF4 中有类似教训，需要展开下） 172 | - 难以防御 farming 173 | - 强烈感觉到追溯资助已经失去了它的“灵魂”，我们停止探索**生态系统繁荣**所需的其他更微妙的问题。这正是拥有多样化的徽章持有者的优势所在。 174 | - Retro Funding 正在变成另一个增长资助计划，这并不是一件坏事，但鉴于 Token House 的优先事项是短期收益，可能最适合由他们来评估。 175 | - **支持 Retro Funding: Dev Tooling * 4** 176 | - 资金和轮次主题已经在 2024 年承诺过。 177 | - 开源开发者工具（其中许多是公共物品）能够加快开发周期，为互操作性和 SuperChain 生态系统的增长带来非常积极的连锁反应。 178 | - 确实应该 Funding 增长，但是我们要不忘初心 * 1 179 | - 当某些东西从叙事和执行（我们的日常行动）中消失时，很难再将它们带回来。 180 | - 如果我们真的希望Optimism成为技术乐观主义世界的推动者，并保持其注意力溢价或其他战略身份优势，我们应该保留一些机制： 181 | - 包容性：继续吸引并奖励新来者。 182 | - 公共物品资助：让 Optimism 召唤的凤凰成为战略增长与有意识地构建更好的网络和世界共存的地方。尽管我们将更多资金用于增长，但让我们继续支持公共物品和现实世界的影响，即使这方面的预算要小得多。可以将其视为企业的社会责任。ENS 就是一个很好的例子。 183 | 184 | 关于社区已有担忧的官方反馈： 185 | 186 | - 对分配算法的继续试验是正确的：**实验带来清晰度，**在现实世界中迭代将揭示我们仅通过讨论无法发现的洞察。第1个月的评估与第6个月相比会显得非常幼稚。但向前推进使我们能够收集数据、测试假设并不断改进。 187 | - 仍需要激励 Onchain Builders 的增长：**机会成本，**这个行业发展迅速，Optimism 也必须如此——尤其是在当前市场环境和竞争格局下。RF 旨在激励建设者为 Optimism 工作。等待达成完美机制的共识可能会延迟这一战略，并失去吸引更多建设者加入 SuperChain 的势头。 188 | - **通过保障措施管理风险**：对指标被操纵或优化错误激励的担忧是合理的，并且会一直存在。我们的角色是从这些风险中学习并加以缓解。我认为这个提案包含了合理的保障措施。每月小轮次的概念让我感到兴奋，因为每一轮都提供了收集反馈并迭代改进评估过程的机会。每个类别的追溯资助总额在本季被限制在800万OP（不是每月），这比RF4的投入要少——而且如果结果不令人满意，治理层没有义务完全分配这些资金。我也认为可以考虑一种故障保护机制，比如标记在短时间内发生剧烈变化的结果（例如，潜在的操纵行为）。 189 | - 指标相关的细节 190 | 191 | 关于指标的话题，我也想分享一下我们OSO在数据方面为帮助集体所做的优先工作： 192 | 193 | 对于开发者工具，我们一直在开发捕捉库或工具链依赖图的模型——本质上是使用特定工具的链上建设者的下游活动。同样的数据模型正在支持@wildmolasses提到的deepfunding实验，Vitalik也在支持。顺便说一句，这是我们一年前写的关于这个话题的博客文章。 194 | 195 | 对于链上建设者，我们预计这一轮的指标将与RF4大不相同。我们整合了新的链和数据源，并正在与OP Labs数据团队密切合作，开发合约和地址标签的共享模型。此外，我预计这些指标将快速迭代，因为互操作性将从测量角度引入各种新的挑战和机遇。 196 | 197 | 为了设定预期： 198 | 199 | 我们在OSO的角色是连接公共数据集并提供服务于Optimism目标的指标。我们不能在真空中完成这项工作。持续的输入和反馈对于确保我们衡量对集体最重要的事情至关重要。 200 | 201 | 这些指标一开始就会完美无缺吗？不会。 202 | 其中一些指标会引起分歧吗？很可能。 203 | 是否需要点对点反馈、来自高背景开发者的结构化输入以及定性衡量？绝对需要。 204 | 205 | 这就是工作。说起来容易，但始终如一地做起来很难。 206 | 207 | - Discord 上关于 RPGF 4 的讨论 208 | 209 | **TimDaub | Kiwi News — 17/12/2024 下午 4:42** 210 | 211 | 我认为在下一轮链上建设者资助中，应该有一个选择或某种形式的协商机制，决定谁可以认领某个合约。我们长期以来一直基于Zora的ERC721标准开发NFT合约，而Zora是该合约的官方部署者。然而，我不认同Zora将其在RetroPGF 4中获得的大部分资金（本应用于链上建设者）用于他们的收藏者和创作者。在我看来，这是对他们分配资金的滥用。我们是一个符合OP Retro 4资格的链上建设者，也是少数使用Zora链上API的人之一。然而，我们现在感到非常失望，因为Zora将本应属于链上建设者的资金转给了收藏者和创作者。而在OP方面，我们不被允许认领NFT合约，因为Zora想要认领它，因此我们在Retro PGF 4中获得的OP减少了。 212 | 213 | **TimDaub | Kiwi News — 17/12/2024 下午 4:42** 214 | 215 | 我在Deepfunding Telegram频道中也提到过：在我看来，RetroPGF应该包括一个自我承诺，要求资金接收者以“大致相同的标准”将收到的追溯资金传递给其他人。这将创造一个更深层次的资金流动，资金将从OP流向其他符合条件的人。我认为这也将澄清VC资助项目的资格问题。同时，这也将确保收到的追溯资金尽可能保留其指定用途。 216 | 217 | 作为一个成功使用这种概念的案例，可以参考GPL3许可证的理念，它要求所有基于GPL3许可项目的衍生作品也必须使用GPL3许可，从而创建了一个病毒式传播的GPL3许可的公共知识产权体系。 218 | 219 | 如果这种资金接收者的自我承诺是强制性的，Zora就会找到符合OP标准的“链上建设者”项目合作伙伴，并将资金分配给他们。抱歉，但我实在看不出“一个铸造NFT的人”如何符合OP Retro 4中定义的“链上建设者”。话虽如此，这种自我承诺在第4轮中并不是强制性的，所以我想Zora可以随意使用这些资金？ 220 | 221 | ### 2025.01.12 222 | 223 | Optimism Retro Funding 投票机制对恶意行为的抵抗能力： 224 | https://mirror.xyz/optimismcn.eth/xfffo45OHL955PvtKRzBzUhHoKJ0uQAbs_mh-qqkGR4 225 | 226 | ### 2025.01.13 227 | 228 | 今天把 Retro Funding 的介绍文章整理出来了： 229 | 230 | https://lxdao.notion.site/OP-Retro-Funding-fe83c6e1ed9e448bae0916b389154cea?pvs=4 231 | 232 | ### 2025.01.14 233 | 234 | 今天把 OP Delegate 的操作流程梳理了一下： 235 | 236 | https://lxdao.notion.site/Delegate-c32df61a41eb4ab6839fcacbf3a61d2f?pvs=4 237 | 238 | ### 2025.01.15 239 | 240 | https://mirror.xyz/optimismcn.eth/xfffo45OHL955PvtKRzBzUhHoKJ0uQAbs_mh-qqkGR4 241 | 242 | https://fullydoxxed.com/deep-funding-will-transform-open-source-from-donation-based-to-fully-paid/ 243 | 244 | 245 | ### 2025.01.16 246 | 247 | 今天在策划 Deep Funding 的访谈选题，翻了两个已有的访谈，记录了些有趣的观点： 248 | 249 | Deep Funding 想解决的核心问题：对正外部性的价值量化：假设你为社会创造了比你能够捕获的更多价值，AI 能否准确测量这种差异？然后我们可以弥补这种差异并解决问题。（这和 OP 里面 RetroPGF 的愿景非常像：影响力 = 收入） 250 | 251 | Deep Funding 的一个应用：在 Optimism、Gitcoin 和 Octant 轮次开始之前预测结果，比如现在 Octant 轮次正在进行，想象一个开放竞赛，AI 预测谁会得到多少钱，然后轮次结束后，我们看看哪个模型是获胜模型。所以这也是现有分配机制的一个简单插件。一个公共物品资助的 Polymarket 252 | 253 | Deep Funding 的另一个应用：应用于 Twitter 的社区笔记。当你发布一些虚假推文时，你会得到社区笔记，说这条推文是假的。但社区笔记的主要问题是它需要太长时间。有时甚至需要 24 小时才能在一个虚假推文上得到社区笔记。如果我们有很多 AI 预测一条推文是否会成为虚假推文，并在 24 小时后由人类投票确认为虚假推文并添加社区笔记，我们可以开发一个类似的排行榜，显示哪些 AI 在预测虚假推文方面更准确。这将使我们能够减少获得社区笔记所需的时间。 254 | 255 | Deep Funding 的整个想法，与 Optimism 不同，在 Optimism 中，每个 Badge Holder 直接分发 RPGF 的钱，而在深度资金中，有一个间接层。这也是为什么 Deep Funding 不需要数量。即使有 100 个陪审员做出 3,000 次好的决定，这些决定也可以应用到整个 10,000 个依赖关系的图中。所以有一些数学工作，Deep Funding 需要多少比较才能选择一个好的模型。但更大的想法是让人类投票很少，让模型为很多依赖关系赋予权重。不要要求人类为很多依赖关系投票，因为这通常不会有好结果。 256 | 257 | 还有几个有趣的问题： 258 | 1. 我们如何决定谁有权被 AI 评级或评判？ 259 | - 控制准入权 260 | 2. 如何超越星标数量来衡量代码的真实价值？ 261 | - “在这个排名中，我看到 Remix 有很多 GitHub 星标，因为前端代码与人们有直接互动，而且前端代码非常健壮。他们可以轻松地为单个页面编写 1,000 行代码，但这可能只需要一两天。但对于后端代码，尤其是基础设施和加密库、ZK 库，它们非常消耗工程师的资源。所以我们需要更多地关注那些难以编写且更智能的代码。” 262 | 3. 如何有算法来检测那些缺乏维护的依赖项，这些依赖项需要更多的人工智能来维护，如果不加以处理会带来巨大风险。 263 | - “关注依赖项的可替代性，如果它不存在，你的生活会变得多困难？我们的目标是找到那个内布拉斯加的随机家伙。”（很重要的 OpenSSL 只有两个“几乎透明”的人来维护，当他俩不再维护，整个网络面临了巨大的风险） 264 | 265 | ### 2025.01.18 266 | 267 | https://docs.google.com/spreadsheets/d/1Ul8iMTsOFUKUmqz6MK0zpgt8Ki8tFtoWKGlwXj-Op34/edit?gid=1179446718#gid=1179446718 268 | 269 | https://docs.google.com/spreadsheets/d/1IpL0oTd3AgNBu_eWdjP9EjbQfZjq-_Nd3yU1H2ke3vY/edit?gid=1115302678#gid=1115302678 270 | 271 | ### 2025.01.19 272 | 273 | https://mirror.xyz/optimismcn.eth/xfffo45OHL955PvtKRzBzUhHoKJ0uQAbs_mh-qqkGR4 274 | ：Optimism Retro Funding 投票机制对恶意行为的抵抗能力 275 | 276 | 有趣的点： 277 | 278 | 1. RPGF 3 中采用“规定人数中位数”方法分配，设置参与评选的最低票数和资金，并且设置标准化的中位数如 10000，25000，50000，100000，这导致了前 100 个项目中约 30% 的项目都获得了相同的分配，对名单的依赖可能无意中引起了选民的冷漠，Badge holders 投票表决尽可能多的项目，通常没有尽职调查，只是为了达到投票门槛。这种投票方法可以看作是实现法定人数的尝试，而不是评估每个项目的优缺点的真正努力，这样的标准可能会造成一种中位数陷阱，处于中位数的大部分项目得到的分配并不客观。 279 | 280 | 2. 在文章内提到的 GovXS 列出的五项针对恶意行为的评估指标中（最大可提取值（Maximum Extractable Value），选民可提取价值（Voter Extractable Value），稳健性，贿赂成本，控制成本），唯一抽象的指标是“稳健性”，给出的定义是“该指标考察不同的投票规则如何应对个人投票行为的变化，以及这些规则对投票中的轻微操纵有多敏感。”，这个稳健性的定义其实适用于蛮多治理场景的，需要有稳健性的思维底线。 281 | 282 | 283 | ### 2025.01.20 284 | 285 | https://gov.optimism.io/t/season-7-cfc-membership/9131 286 | 287 | ### 2025.01.21 288 | 289 | OP 社区会议 @Discord 290 | 291 | - 讨论重点 292 | - **Supersim 的介绍和使用** 293 | - Supersim 是 Optimism 的超级链模拟器（Super Chain Simulator）。 294 | - 它允许开发者运行两条本地链，并通过超级链间隔（Super Chain Interval）连接它们。 295 | - 主要用途是在正式上线前测试中断（interrupt）功能，确保跨链交互的稳定性和可靠性。 296 | - Supersim 的推出被认为是一个非常令人兴奋的工具，特别是在测试跨链交互和中断处理方面。 297 | - **如何使用 Supersim 进行本地链的测试？** 298 | - 开发者可以通过 Supersim 模拟两条本地链的交互，测试跨链消息传递、资产转移等功能。 299 | - 它特别适合用于测试中断场景，例如当一条链出现问题时，另一条链如何响应。 300 | - 讨论中提到，Supersim 的文档虽然目前不够美观，但开发者可以通过实际操作来熟悉其功能。 301 | - **文档目前不够美观，如何改进？** 302 | - 讨论中提到，Supersim 的文档目前看起来“丑陋”（原文用了“gross”这个词），但团队正在努力改进其外观。 303 | - 改进的目标是让文档更易于阅读和理解，特别是对于新开发者。 304 | - 虽然没有具体提到改进的技术细节，但可以推测团队可能会采用更清晰的排版、更好的代码示例和更直观的图示。 305 | - **如何创建更多的跨链资产转移？** 306 | - 使用 interop 在不同链之间发送资产。 307 | - 构建跨链应用，让用户能够轻松地在不同链之间转移资产。 308 | - 目标是让跨链交互变得像单链交互一样简单。 309 | - **如何构建跨链套利机器人？** 310 | - 讨论中提到，跨链套利的一个主要挑战是确保机器人在有机会的链上不会耗尽资金。 311 | - 使用 intro 可以轻松地在不同链之间转移资产，从而解决资金平衡问题。 312 | - 开发者可以构建一个跨链套利机器人，利用 intro 在不同链之间快速转移资产，捕捉套利机会。 313 | - **Optimism 今年的社交使命是推动开发者社区的成长和创新。** 314 | 315 | ### 2025.01.22 316 | 317 | Superchain 指数，标记了对不同 Superchain 的分类，评级和收入细节： 318 | https://www.superchain.eco/superchain-index 319 | 320 | superscan, 浏览 Superscan 间的交易： 321 | https://thesuperscan.io/ 322 | 323 | ### 2025.01.23 324 | 325 | Retro Funding 更新了 S7 的目的细节，以下是要点总结，S7 将会是很具有代表性的 AI 参与治理的一季 RF： 326 | 327 | 摘要：提出多个评估算法。徽章持有者使用批准投票来决定应用哪个评估算法。选定算法的创建者负责根据专家反馈进行迭代改进。 328 | 329 | ### 治理过程 330 | 331 | 提案与投票：多个评估算法被提出，徽章持有者通过投票选择其中一个。初始投票需要30%的法定人数和51%的批准门槛。 332 | 333 | 迭代改进：选定算法的创建者负责根据专家反馈进行迭代改进，除非迭代大幅改变战略方向，否则不需要额外的治理批准。 334 | 335 | ### 反馈与协作 336 | 337 | 反馈机制：来自领域专家的反馈是算法改进的关键。反馈可以是定性的（如书面建议）或定量的（如偏好排名）。 338 | 339 | 协作机会：社区成员可以通过提出指标、支持数据源、分析算法性能等方式参与算法的开发。 340 | 341 | ### 预算分配 342 | 343 | 预算分配方式：预算在指定的测量日期之间平均分配。未来可能会根据每个测量期间的影响力动态调整预算。 344 | 345 | ### 故障保护与审查 346 | 347 | 故障保护：如果中位数项目的结果在测量期间差异很大，评估算法的应用可能会被暂停，以防止操纵。 348 | 349 | 申请审查：目标是尽量减少人工审查，但在必要时，基金会会请求 govNERDs 协助。 350 | 351 | ### 2025.01.24 352 | 353 | 今天看了一下 Superchain 黑马 INK，Ink 是 Kraken 推出的 Layer 2 解决方案，Superchain 是 Stage 评级就像是一种准入认证，在 Coinbase 之后又深度连接了 Kraken 从 RWA 到去中心化的世界里（区块链上）。 354 | 355 | 关于互操作性的研究和 RPGF 如何激励互操作性的研究可以从 Ink 和 Base 的实际用例展开思考： 356 | 357 | Ink 的互操作性实践：Fault Proofs 功能，允许用户独立审查和质疑跨链交易，增强了互操作性的安全性和透明性。 358 | 359 | 明天详细研究下。 360 | 361 | ### 2025.01.25 362 | 363 | https://www.chaincatcher.com/article/2088168 364 | 365 | https://mirror.xyz/optimismcn.eth/CvGXTALKqVxVZ4UK_dJ0DUFUQe00rUwVYZ-3_IF2rbE 366 | 367 | 368 | ### 2025.01.26 369 | 370 | 371 | 372 | 373 | 374 | 375 | 376 | 377 | -------------------------------------------------------------------------------- /Dfbb7879.md: -------------------------------------------------------------------------------- 1 | --- 2 | timezone: Asia/Shanghai 3 | --- 4 | 5 | > 请在上边的 timezone 添加你的当地时区，这会有助于你的打卡状态的自动化更新，如果没有添加，默认为北京时间 UTC+8 时区 6 | > 时区请参考以下列表，请移除 # 以后的内容 7 | 8 | timezone: Pacific/Honolulu # 夏威夷-阿留申标准时间 (UTC-10) 9 | 10 | timezone: America/Anchorage # 阿拉斯加标准时间 (UTC-9) 11 | 12 | timezone: America/Los_Angeles # 太平洋标准时间 (UTC-8) 13 | 14 | timezone: America/Denver # 山地标准时间 (UTC-7) 15 | 16 | timezone: America/Chicago # 中部标准时间 (UTC-6) 17 | 18 | timezone: America/New_York # 东部标准时间 (UTC-5) 19 | 20 | timezone: America/Halifax # 大西洋标准时间 (UTC-4) 21 | 22 | timezone: America/St_Johns # 纽芬兰标准时间 (UTC-3:30) 23 | 24 | timezone: America/Sao_Paulo # 巴西利亚时间 (UTC-3) 25 | 26 | timezone: Atlantic/Azores # 亚速尔群岛时间 (UTC-1) 27 | 28 | timezone: Europe/London # 格林威治标准时间 (UTC+0) 29 | 30 | timezone: Europe/Berlin # 中欧标准时间 (UTC+1) 31 | 32 | timezone: Europe/Helsinki # 东欧标准时间 (UTC+2) 33 | 34 | timezone: Europe/Moscow # 莫斯科标准时间 (UTC+3) 35 | 36 | timezone: Asia/Dubai # 海湾标准时间 (UTC+4) 37 | 38 | timezone: Asia/Kolkata # 印度标准时间 (UTC+5:30) 39 | 40 | timezone: Asia/Dhaka # 孟加拉国标准时间 (UTC+6) 41 | 42 | timezone: Asia/Bangkok # 中南半岛时间 (UTC+7) 43 | 44 | timezone: Asia/Shanghai # 中国标准时间 (UTC+8) 45 | 46 | timezone: Asia/Tokyo # 日本标准时间 (UTC+9) 47 | 48 | timezone: Australia/Sydney # 澳大利亚东部标准时间 (UTC+10) 49 | 50 | timezone: Pacific/Auckland # 新西兰标准时间 (UTC+12) 51 | 52 | --- 53 | 54 | # {Dfbb7879} 55 | 56 | 1. 自我介绍 57 | 热爱区块链，想通过本次学习进一步了解OP生态和运作原理 58 | 3. 你认为你会完成本次残酷学习吗？ 59 | 会的 60 | 61 | ## Notes 62 | 63 | 64 | 65 | ### 2025.01.06 66 | Optimistic Rollup是一种依赖于 Layer 1（L1）区块链的 Layer 2（L2）扩展解决方案。它通过利用 L1 区块链（如以太坊）的共识机制（PoW 或 PoS），而非自建共识机制，来保证安全性。 67 | 在 Optimism 主网上，L1 区块链为以太坊，L2 继承了其安全性和数据可用性保障。 68 | 在 Bedrock 体系中，L2 区块通过非合约地址（如 0xff00...0010）保存至以太坊主网，使用 EIP-4844 提议的 blob 数据结构以降低 L1 交易费用。 69 | L1 区块不可篡改或审查，确保了数据完整性和可用性。 70 | 为了节省成本，提交至 L1 的区块以压缩格式存储。 71 | Optimism 支持在 L2（如 OP 主网）与 L1（如以太坊主网）之间传递消息，实现 ETH 和 ERC20 代币的跨层转移。 72 | L1 → L2：存款 73 | 使用 L1CrossDomainMessenger 或 L1StandardBridge。 74 | 存款交易会在对应“epoch”的第一个 L2 区块中被记录。 75 | L2 → L1：提款 76 | 初始化提款交易（L2）。 77 | 等待输出根提交到 L1，并通过 proveWithdrawalTransaction 提交提款证明。 78 | 等待挑战期（主网通常为 7 天）后，完成提款。 79 | 状态承诺机制：在 L1 上发布状态承诺，无需直接验证。在挑战窗口（7 天）内，若无人挑战，该承诺即被视为最终确定。 80 | 故障证明：如果承诺被挑战，可通过故障证明使其无效，但这不会回滚 OP 主网的交易和状态，仅影响 L1 上的承诺链。 81 | Optimism 的设计通过乐观汇总协议实现了扩展性、安全性和低成本交易。其核心在于将 L2 的计算和存储负载从以太坊主网转移，同时继承以太坊的安全特性，非常适合需要高效扩展的区块链应用场景。 82 | ### 2025.01.07 83 | 随着去中心化金融（DeFi）和非同质化代币（NFT）生态的迅速发展，区块链的吞吐量和交易成本问题变得日益突出。以太坊作为目前最流行的智能合约平台，面临着每秒处理能力不足（TPS < 20）的瓶颈，导致了网络拥堵和Gas费用的急剧上升。为了克服这些挑战，Layer 2（L2）扩容技术应运而生，并且已经成为以太坊生态系统中最为重要的关注点之一。 84 | 85 | 一、Layer 2扩容技术简介 86 | Layer 2扩容技术是指建立在主链（Layer 1）之上的二层协议，能够显著提高区块链的吞吐量，同时保持主链的安全性和去中心化特性。主流的Layer 2扩容方案有四种： 87 | 88 | Optimistic Rollup 89 | ZK Rollup 90 | Plasma 91 | Validium 92 | 二、Layer 2技术的优势 93 | 提高吞吐量 94 | 95 | 在以太坊主链上，由于每秒交易量有限，随着用户的增多，交易拥堵成为普遍问题。Layer 2通过将大部分交易移到二层网络处理，可以大幅提升吞吐量。 96 | 降低交易费用 97 | 98 | 通过将交易批量处理在二层，Layer 2减少了对以太坊主链的依赖，从而降低了交易的Gas费用。 99 | 更高的可扩展性 100 | 101 | 以太坊主链虽然在安全性和去中心化上表现出色，但在扩展性上受限。Layer 2提供了更高的灵活性，支持更多的交易和复杂操作。 102 | 激励机制与空投机会 103 | 104 | 参与Layer 2网络的用户，除了享受更低费用和更高速度外，还可能通过项目方提供的激励措施（如空投）获得额外奖励。 105 | 三、主要的Layer 2解决方案 106 | 1. Optimistic Rollup 107 | Optimistic Rollup（OR）是目前最为流行的扩容技术之一。它的核心思想是通过“假设”交易是合法的，先将其提交到Layer 2，之后再由验证节点在一定时间内验证其正确性。OR的优势在于简单性，主要的挑战是验证延迟和欺诈证明机制。 108 | 109 | 优点：相对较为简单，已被多项目采用（如Optimism、Arbitrum）。 110 | 缺点：交易延迟较高，存在欺诈证明的时间窗口。 111 | 2. ZK Rollup 112 | ZK Rollup（Zero Knowledge Rollup）利用零知识证明的技术，将交易信息压缩成一个有效的证明，提交到以太坊主链。由于交易数据不完全上传主链，ZK Rollup可以极大提高吞吐量和降低费用。 113 | 114 | 优点：极高的可扩展性和交易速度，具有更低的Gas费用。 115 | 缺点：实现技术复杂，且在现阶段，开发工具和生态支持还不完善。 116 | 根据计算，ZK Rollup的优势体现在： 117 | 118 | ETH转账：ZK Rollup的可扩展性提升了100倍。 119 | ERC-20代币和DeFi交易：对于像Uniswap这类需要处理复杂合约交易的应用，ZK Rollup的拓展性能提高超过400倍。 120 | 3. Plasma 121 | Plasma是一种较早期的Layer 2扩容解决方案，它通过将交易移到子链进行处理，从而减轻主链的负担。Plasma的工作原理是使用更小的子链作为扩展，最终通过周期性的汇总数据回到以太坊主链。 122 | 123 | 优点：易于实现，支持大规模的资产转移。 124 | 缺点：子链的安全性问题较为突出，用户需要定期进行退出操作。 125 | 4. Validium 126 | Validium与ZK Rollup类似，但它将数据存储在外部链上，而不是以太坊主链。这使得Validium可以处理大量数据和交易，但其牺牲了部分安全性。 127 | 128 | 优点：更高的吞吐量，适合处理大量数据和交易。 129 | 缺点：安全性较弱，依赖于外部的数据存储链。 130 | 四、交易费用与扩展性对比 131 | 以太坊的Gas费用和网络吞吐量是Layer 2扩容技术设计的核心驱动力。在现有的以太坊网络中，由于Gas费用的波动，交易成本时常过高，影响了用户的体验和应用的可用性。 132 | 133 | ZK Rollup的交易费用相对较低，且能够支持更高的TPS（每秒交易数）。以ZK Rollup为例，在理想状态下，每个批次的交易可以达到11,818 TPS，而传统的以太坊主链最多只能处理101 TPS。 134 | Optimistic Rollup的交易吞吐量和费用略逊色于ZK Rollup，但在实现复杂度上较为简单，且生态逐步扩展。 135 | Plasma和Validium则分别适用于不同类型的应用，虽然交易费用较低，但存在安全性问题。 136 | 五、未来展望：EIP-4488与EIP-4844 137 | 以太坊网络正在不断进行升级，EIP-4488和EIP-4844等提案旨在通过优化Gas费用和网络负载，进一步提升Rollup的成本效益。 138 | 139 | EIP-4488：通过限制数据存储量，减少Gas费用，改善Layer 2的性能。 140 | EIP-4844：专门为Rollup设计的一种数据传输格式，能够显著降低Rollup的操作成本。 141 | 六、总结 142 | 以太坊Layer 2扩容技术是解决当前以太坊网络交易费用过高和吞吐量不足的关键手段。通过采用Optimistic Rollup、ZK Rollup等方案，Layer 2能够在保证以太坊网络安全性和去中心化的前提下，显著提升交易效率和降低成本。未来随着更多EIP提案的实施，Layer 2将继续发挥重要作用，为更多用户和应用提供支持。 143 | 144 | ### 2025.01.08 145 | 1. zkSync 2.0 交易费用分析 146 | (1) 普通交易费用 147 | 在 zkSync 2.0 中，交易费用的构成可以分为链上费用和链下费用。例如： 148 | 普通交易总成本： 149 | 链上费用：0.002 u 150 | 链下费用：0.068 u 151 | 总费用：0.07 u 152 | 交易接收者为新地址的总成本： 153 | 链上费用：0.005 u 154 | 链下费用：0.20865 u 155 | 总费用：0.21365 u 156 | Swap 总成本： 157 | 链上费用：0.005 u 158 | 链下费用：0.1667 u 159 | 总费用：0.1672 u 160 | (2) 影响交易地板价的因素 161 | zkSync 的交易地板价与 ETH 主网 calldata 的费用 密切相关。未来的 EIP4488 计划将大大降低 calldata 的费用，尤其是非零字节数据的费用从 16 gas 降至 3 gas。这一变动预计会大大减少 zkSync 等 Rollup 类型的 L2 解决方案的交易费用。 162 | (3) 费用支付方式 163 | 在 zkSync 中，支持 "无气体交易"，即用户在进行交易时，可以使用交易中涉及的代币（如 DAI）支付交易费用，而无需持有 ETH 或其他代币。这种机制简化了用户体验，使得代币持有者可以直接通过所持有的资产完成交易，而不需要额外的资金准备。 164 | (4) zkPorter 交易费用 165 | zkPorter 是 zkSync 2.0 中的一个新功能，旨在降低交易费用。zkPorter 将一部分数据存储从链上转移至链下，因此无需依赖链上数据可用性，从而显著降低交易成本。据官方文档预测，zkPorter 的交易费用可低至 1 到 3 美分。 166 | zkPorter 的关键特点在于： 167 | 支持与 ZK Rollup 无缝互操作。 168 | zkPorter 账户 的费用显著低于 Rollup 账户，具体来说，用户在 zkPorter 上进行交易的费用可低于 0.03 美元。 169 | zkPorter 的数据可用性由 zkSync 代币持有者（监护人）保证，采用 PoS 机制进行权益证明，从而保障其数据安全。 170 | 2. Arbitrum Gas 机制 171 | Arbitrum 是另一种流行的 L2 解决方案，利用 Optimistic Rollup 技术。Arbitrum 的交易费用受多种因素影响，包括： 172 | L2 执行费：每个 Arbitrum 交易都需要为其计算和存储付费。费用的计算方式与以太坊类似，按交易使用的 gas 数量和附带的 gas 价格来计算。 173 | 费用结构： 174 | 交易费用的计算公式为： 175 | makefile 176 | 复制代码 177 | l2_execution_fee = transaction_gas_price * l2_gas_used 178 | 在 Arbitrum 中，L1 数据费用是一个额外的成本来源。这是由于 Arbitrum 上的所有交易需要在以太坊主网提交数据以确保其安全性。 179 | 3. Optimism Gas 机制 180 | 与 Arbitrum 类似，Optimism 也采用了 Optimistic Rollup 技术，因此其交易费用包含以下两部分： 181 | (1) L2 执行费 182 | 与以太坊类似，Optimism 上的交易同样需要为计算和存储付费。每笔交易的费用由交易的 gas 数量与附带的 gas 价格相乘得到。 183 | (2) L1 数据费用 184 | Optimism 的交易不仅在其 L2 网络上执行，还需要将相关数据发布到以太坊主网。这一过程涉及到 L1 数据费用，是 Optimism 特有的成本项，主要由以下几个因素决定： 185 | 以太坊当前的 gas 价格； 186 | 将交易数据发布到以太坊的 gas 成本； 187 | 交易的字节大小（与交易数据的长度成正比）； 188 | 固定的 2100 gas 固定费用； 189 | 动态的间接费用。 190 | 由于以太坊的 gas 成本较高，L1 数据费用通常会占据 Optimism 交易总费用的较大部分。 191 | ### 2025.01.09 192 | 在区块链技术的发展过程中，Rollup（滚动聚合）已经成为一种备受关注的扩容方案，尤其是在以太坊网络中。Rollup 通过将交易数据压缩并在Layer 1（L1）上发布，以实现更高效的交易处理，同时保持一定的安全性。然而，Rollup 系统的开发通常需要经过一个由中心化控制主导的阶段，这一阶段被称为“训练轮”阶段。这个阶段允许开发者在一个受控的环境中进行系统更新和漏洞修复。 193 | 194 | 随着技术的发展，Rollup 需要逐渐去除这些“训练轮”，以充分继承基础层（L1）的安全性。为了指导这一过渡过程，Vitalik Buterin 提出了一个逐步过渡的框架，并根据不同的去中心化程度，将 Rollup 分为三个阶段。 195 | 196 | Rollup 三个发展阶段 197 | Stage 0 — 完全训练轮： 在这个阶段，Rollup 系统仍然由少数运营者控制。虽然存在源代码可用的软件，可以通过在 L1 上发布的数据来重建系统状态，但 Rollup 本身并没有完全去中心化。该阶段的关键特征是，Rollup 的操作和管理完全依赖于运营者的控制。 198 | 199 | Stage 1 — 有限训练轮： 随着 Rollup 逐渐过渡到由智能合约管理，**Security Council（安全委员会）**可能依然存在，负责解决潜在的错误或漏洞。这个阶段的特点是，Rollup 开始实现完全的欺诈证明系统（fraud proofs）和去中心化的欺诈证明提交机制。此外，用户也可以在没有运营者协调的情况下退出系统。尽管 Security Council 在此阶段提供了安全保障，但其权力可能带来一定的风险，尤其是当治理不透明时。 200 | 201 | Stage 2 — 无训练轮： 这是最终阶段，Rollup 完全由智能合约管理。在这个阶段，欺诈证明系统是无许可的，用户可以在不受治理攻击威胁的情况下退出系统。Security Council 的作用仅限于处理链上能够裁定的正确性错误，不再干预 Rollup 的日常运行。此时，Rollup 达到完全的去中心化，能够独立运行并受到以太坊主链的保护。 202 | 203 | 背景与动机 204 | 这一框架的提出源于Vitalik Buterin在2022年11月对以太坊 Rollup 发展路径的初步构想。他认为，Rollup 系统的去中心化过程并不是一蹴而就的，而是一个逐步过渡的过程。然而，随着讨论的深入，大家逐渐意识到，一个简单的评级系统无法充分表达每个 Rollup 系统的复杂性和细节。不同的项目可能采取不同的路线实现去中心化，因此需要一个更精确的框架来评估 Rollup 的成熟度。 205 | 206 | 框架设计与更新 207 | 为了有效评估不同 Rollup 的发展阶段，我们对原有的评级系统进行了更新。通过结合 Vitalik 提出的三个阶段框架，并明确了一些关键参数（如最小退出窗口、Security Council 阈值和欺诈证明白名单大小），我们力求提供一个既简单易懂，又具备足够细节的评估系统。 208 | 209 | 这个框架不仅为公众提供了清晰的理解，还为开发者和社区提供了更加准确的标准，帮助他们评估一个 Rollup 是否已达到去中心化的要求。虽然这一框架目前还在不断演进，我们相信它将成为未来深入讨论的基础。 210 | ### 2025.01.10 211 | ### 2025.01.11 212 | ### 2025.01.12 213 | 在区块链技术不断发展的过程中，Rollup 作为一种可信最小化的扩展解决方案，已成为以太坊扩容的重要方法。然而，在这些系统的发展早期阶段，通常需要一种被称为“训练轮”（training wheels）的集中式控制机制，用于系统更新和漏洞修复。在 Rollup 的成熟过程中，移除这些“训练轮”是必要的，以便它们能够完全继承底层以太坊的安全性。 214 | 215 | 以下是一种基于 Vitalik 提出的里程碑概念的新框架，旨在对 Rollup 的成熟度进行分类。此框架将 Rollup 分为三个阶段： 216 | 217 | 第一阶段：完全训练轮（Stage 0 — Full Training Wheels） 218 | 核心特点： 219 | Rollup 的运行主要由运营方控制。 220 | 提供源代码开放的软件，可以从发布在 L1 上的数据中重建状态。 221 | 用于验证状态根是否与提议的状态根一致。 222 | 第二阶段：有限训练轮（Stage 1 — Limited Training Wheels） 223 | 过渡性特征： 224 | Rollup 的管理转移至智能合约，但仍设有安全委员会（Security Council）。 225 | 技术改进： 226 | 全功能证明系统上线。 227 | 验证欺诈证明的流程去中心化。 228 | 用户可以在无需运营方协调的情况下退出系统。 229 | 安全委员会的角色： 230 | 提供应急支持，修复潜在漏洞。 231 | 存在一定的风险，因为安全委员会仍然拥有权力。 232 | 第三阶段：完全去中心化（Stage 2 — No Training Wheels） 233 | 最终目标： 234 | Rollup 的管理完全由智能合约负责。 235 | 验证欺诈证明的过程完全无权限化（permissionless）。 236 | 用户保护： 237 | 用户可在面临不受欢迎的升级时拥有充足的退出时间。 238 | 安全委员会的作用： 239 | 仅限于解决可以链上裁决的安全性问题。 240 | 防范治理攻击，保护用户资产。 241 | ### 2025.01.13 242 | 欺诈证明系统是否为无许可制？ 243 | 无许可性要求 244 | 欺诈证明系统应完全去中心化，开放给所有人，而不仅限于特定的白名单参与者。这意味着任何人都可以提交欺诈证明，从而避免系统被少数实体控制，并确保整个社区的共同监督。 245 | 无许可的设计有助于提高系统的透明性与可信性，符合以太坊生态系统去中心化的基本理念。 246 | 是否提供至少 30 天的退出时间以应对不想要的升级？ 247 | 退出时间要求 248 | 系统在进行升级（包括由去中心化自治组织 DAO 发起的升级）时，应为用户提供至少 30 天的退出时间。这段时间允许用户在不同意系统重大变更时，有足够时间撤回资产。 249 | 例外情况 250 | 如果存在链上漏洞检测机制（例如，发现两个有效但矛盾的零知识证明），可以立即进行升级，以快速修复漏洞。 251 | 安全委员会的权力限制 252 | 在 Rollup 系统的最终阶段，安全委员会的干预能力应受到严格限制，仅可处理可裁定的健全性错误（例如严重漏洞）。 253 | 这样做有助于减少对中心化实体的信任，使系统更加去中心化。 254 | 例如，在 Polygon zkEVM 合约中，如果检测到两个不同的有效证明使用相同批次提交，Rollup 将进入“紧急模式”。 255 | 目标 256 | 通过限制安全委员会的作用，系统逐步接近“信任最小化”的理想状态，让代码成为最终的权威。 257 | 框架作用 258 | 该框架旨在成为讨论 Rollup 成熟度的参考点，并激励项目专注于其路线图中的特定安全措施。 259 | 促进社区讨论 260 | 希望通过这一框架，项目方能围绕某些具体风险因素展开讨论，表达其改进计划，从而推动社区对“以太坊保障”的系统评估更加结构化。 261 | ### 2025.01.14 262 | Optimism Collective 简介 263 | Optimism Collective 是一个由公司、社区和公民组成的联盟，致力于奖励公共产品并为以太坊构建可持续的未来。其核心目标是通过合作实现一个人人受益、无人拥有的互联网。 264 | Superchain 产品愿景 265 | Optimism Collective 的核心产品是 Superchain，其目标是打造一个标准化、高效且可扩展的链生态系统。 266 | 链的标准化 267 | 标化提高了去中心化和组合性的规模化能力。 268 | 初期与长期扩展 269 | 初期由 15-50 条链组成，提供一体化的用户体验。 270 | 长期扩展至 1000+ 条链，成为一个超级生态。 271 | 治理的核心作用 272 | 安全保护：治理机制确保 Superchain 的安全性。 273 | 可持续增长：通过治理驱动生态发展和创新。 274 | Impact=Profit 原则 275 | Optimism Collective 的经济原则可以概括为 Impact=Profit，即影响力等于收益。 276 | 使命：创建一个利益共享的互联网生态系统。 277 | 经济模式：通过奖励有影响力的行为和成果，引导经济价值的增长。 278 | 未来愿景：这种模式被称为“Ether's Phoenix（以太之凤）”。 279 | 治理模式概述 280 | Optimism Collective 采用实验性和敏捷性的治理方式，旨在通过不断迭代建立一个经得起时间考验的系统。 281 | 双院制治理结构 282 | 治由两个院组成，形成一个双院制（bicameral）的治理体系： 283 | Token House（代币院） 284 | 由 OP 代币持有者组成，通过提交、讨论和投票参与治理。 285 | 成员可以直接投票，也可以将投票权委托给他人。 286 | 投票范围详见《操作手册》。 287 | Citizens' House（公民院） 288 | 基于声誉的“一人一票”治理实验，主要负责 追溯公共产品资金分配（Retro Funding）。 289 | Retro Funding 的核心理念：过去的贡献更容易达成共识。奖励已经产生的积极影响，而非未来的预测。 290 | Retro Funding 机制 291 | 作为 Collective 的主要经济引擎，Retro Funding 用于奖励那些为 Collective 和 Superchain 创造积极影响的人。 292 | 详细信息可访问 retrofunding.optimism.io。 293 | 身份与声誉 294 | 公民院的身份和声誉体系是确保公平和信任的关键。 295 | 具体内容请参考身份与声誉部分。 296 | 297 | 298 | -------------------------------------------------------------------------------- /LunaWang5209.md: -------------------------------------------------------------------------------- 1 | --- 2 | timezone: Asia/Shanghai 3 | --- 4 | 5 | > 请在上边的 timezone 添加你的当地时区，这会有助于你的打卡状态的自动化更新，如果没有添加，默认为北京时间 UTC+8 时区 6 | > 时区请参考以下列表，请移除 # 以后的内容 7 | 8 | timezone: Pacific/Honolulu # 夏威夷-阿留申标准时间 (UTC-10) 9 | 10 | timezone: America/Anchorage # 阿拉斯加标准时间 (UTC-9) 11 | 12 | timezone: America/Los_Angeles # 太平洋标准时间 (UTC-8) 13 | 14 | timezone: America/Denver # 山地标准时间 (UTC-7) 15 | 16 | timezone: America/Chicago # 中部标准时间 (UTC-6) 17 | 18 | timezone: America/New_York # 东部标准时间 (UTC-5) 19 | 20 | timezone: America/Halifax # 大西洋标准时间 (UTC-4) 21 | 22 | timezone: America/St_Johns # 纽芬兰标准时间 (UTC-3:30) 23 | 24 | timezone: America/Sao_Paulo # 巴西利亚时间 (UTC-3) 25 | 26 | timezone: Atlantic/Azores # 亚速尔群岛时间 (UTC-1) 27 | 28 | timezone: Europe/London # 格林威治标准时间 (UTC+0) 29 | 30 | timezone: Europe/Berlin # 中欧标准时间 (UTC+1) 31 | 32 | timezone: Europe/Helsinki # 东欧标准时间 (UTC+2) 33 | 34 | timezone: Europe/Moscow # 莫斯科标准时间 (UTC+3) 35 | 36 | timezone: Asia/Dubai # 海湾标准时间 (UTC+4) 37 | 38 | timezone: Asia/Kolkata # 印度标准时间 (UTC+5:30) 39 | 40 | timezone: Asia/Dhaka # 孟加拉国标准时间 (UTC+6) 41 | 42 | timezone: Asia/Bangkok # 中南半岛时间 (UTC+7) 43 | 44 | timezone: Asia/Shanghai # 中国标准时间 (UTC+8) 45 | 46 | timezone: Asia/Tokyo # 日本标准时间 (UTC+9) 47 | 48 | timezone: Australia/Sydney # 澳大利亚东部标准时间 (UTC+10) 49 | 50 | timezone: Pacific/Auckland # 新西兰标准时间 (UTC+12) 51 | 52 | --- 53 | 54 | # {古忆} 55 | 56 | 1. 自我介绍 57 | 币圈老韭菜 58 | 59 | 2. 你认为你会完成本次残酷学习吗？ 60 | 会 61 | 62 | ## Notes 63 | 64 | 65 | 66 | ### 2025.01.06 67 | 68 | 1. 核心概念 69 | Optimistic Rollup是一种扩展以太坊的 L2 技术，利用以太坊（L1）的安全性，而无需独立的共识机制。通过在 L1 上发布压缩数据，提供高效且经济的交易处理能力。在 L1 上提交状态的同时，不立即验证其有效性，而是提供一个挑战窗口，如果无人质疑则状态最终确定。 70 | Optimism是基于 Optimistic Rollup 的 L2 网络。它通过与以太坊的深度集成，提供快速、低成本的交易解决方案，同时保留了以太坊的安全性。 71 | 72 | 2. 主要机制 73 | 74 | 2.1 区块存储 75 | 在 Optimism 的 Bedrock 架构中，L2 区块以压缩格式写入以太坊，以减少写入成本。使用 EIP-4844 blob 技术，确保数据一旦提交到 L1，就无法被篡改或审查。 76 | 77 | 2.2 区块生成: 78 | 排序器：负责提供交易确认和状态更新，构建并执行 L2 区块，将用户交易提交到 L1。区块生产速度：每两秒生成一个区块。 79 | 交易提交方式：直接提交到排序器：成本低，但缺乏抗审查性。通过 L1 提交：确保抗审查性，通过 "epoch" 与 L1 关联。 80 | 当前由 Optimism Foundation 运行唯一的排序器。 81 | 82 | 2.3 区块执行 83 | 执行引擎通过点对点网络或从 L1 同步区块更新状态。 84 | Rollup 节点：从 L1 中派生 L2 区块，确保抗审查性。 85 | 86 | ### 2025.01.07 87 | 88 | 什么是 Derivation Pipeline？ 89 | Derivation Pipeline 是 OP Stack 协议的核心部分，负责处理和验证交易。它通过对 Sequencer 提交的交易和批次推导出一致的状态，确保区块链的安全和完整。 90 | 91 | 主要功能 92 | 批次提交与排序：将交易整理成批次，并提交到 Layer 1（L1）进行确认和最终记录。 93 | 安全头与非安全区块：安全头——已在 L1 确认的最新状态。非安全区块——已排序但未在 L1 确认的交易。 94 | 重组与恢复：如果排序窗口（如 12 小时）过期仍未确认批次，会回滚未确认的区块，并用默认空区块继续处理新交易。 95 | 96 | 排序窗口： 97 | 定义交易从提交到确认的最大时间。超过窗口时间会触发回滚机制，清除未确认的交易。 98 | 示例：12 小时窗口：过期后回滚未确认交易，用默认区块推进网络。24 小时窗口：延长时间，但可能增加资源消耗和处理难度。 99 | 100 | ### 2025.01.08 101 | 102 | Sequencer 是 OP Stack 链的“交易调度员”，负责接收、排序并将 L2 的交易发布到 L1。如果它出问题，交易处理可能受影响，但用户仍然有办法解决。 103 | Sequencer 故障主要分两种： 104 | 完全停机：Sequencer 无法接收或处理交易，网络看起来“卡住”了。比如软件漏洞或云服务故障会导致这种情况。用户可以绕过它，直接向 L1 上的 OptimismPortal 合约提交交易，保证交易被处理。 105 | 交提交故障：Sequencer 能接收和处理交易，但无法将交易发布到 L1。短时间内用户感受不明显，但如果问题持续，可能导致链状态回滚或重组。解决方法同样是通过 OptimismPortal 合约提交交易。 106 | OptimismPortal 合约是关键：这是 L1 上的一个智能合约，允许用户直接提交 L2 交易，绕过 Sequencer。它支持所有类型的交易，并且这些交易在 L2 上看起来与 Sequencer 提交的交易完全一样。 107 | 108 | ### 2025.01.09 109 | L2 扩容解决方案及成本分析 110 | 111 | 一、背景 112 | • 以太坊网络发展迅速（DeFi、NFT），但因低TPS和高Gas费用导致网络拥堵。 113 | • ETH 2.0扩容需时间，L2解决方案是中短期内解决以太坊低效率问题的关键。 114 | 115 | 二、L2 优势： 116 | • 更高的速度和更低的费用； 117 | • 可能获得激励和空投； 118 | • 保持以太坊的安全性和完整性。 119 | 120 | 三、L2 的主要技术方案 121 | 1.Optimistic Rollup 122 | 2.ZK Rollup 123 | 3.Plasma 124 | 4. Validium 125 | 126 | 四、交易费用对比： 127 | 1.ZK Rollup 128 | • 链下成本：基于硬件（如生成零知识证明），每笔交易约0.001美元。 129 | • 链上成本：用于验证和状态更新，依赖以太坊Gas费用，但比直接在以太坊上交易便宜很多。 130 | • 总成本： 普通转账：0.07美元 ； 接收新地址：0.213美元 ；Swap交易：0.167美元 131 | ZK Rollup特点： 132 | • 压缩效率极高，普通ETH转账TPS可提升100倍以上，复杂交易（如Uniswap）可提升400倍以上。 133 | • 随着EIP-4488等改进提案，成本可能下降至当前的1/5。 134 | 135 | 2.zkPorter 136 | • 与ZK Rollup不同，数据可用性链下处理，大幅降低成本。 137 | • 交易成本约为1-3美分，适合高频、低成本的应用场景。 138 | 139 | 3.Optimistic Rollup 140 | • 成本构成： L2执行费：基于交易使用的Gas量和L2 Gas价格； L1数据费：用于向以太坊提交数据，约占总费用的大部分。 141 | • 特点：成本较ZK Rollup稍高，适合某些特定用例。 142 | 143 | 4.Arbitrum 144 | • 成本依赖于具体交互方式，Gas机制和Optimism类似。 145 | 146 | 147 | 148 | ### 2025.01.10 149 | L2 是以太坊扩展的关键： 150 | • 提供更高的吞吐量； 151 | • 降低交易成本，改善用户体验； 152 | • 保留以太坊的安全性。 153 | 154 | 方案优劣势： 155 | • ZK Rollup：交易成本低、安全性高、压缩效率优，适合大多数场景。 156 | • zkPorter：成本更低，适合高频低值交易。 157 | • Optimistic Rollup/Arbitrum：成本适中，但性能略逊于ZK Rollup。 未来更多应用将迁移到L2，推动区块链的大规模应用！ 158 | 159 | ### 2025.01.11 160 | 161 | 评估Rollup成熟度的Stages框架 162 | 背景 163 | Rollup是一种信任最小化的以太坊扩展方案，但初期通常依赖“训练轮”来进行系统更新和修复。 164 | 随着Rollup的发展，需逐步移除“训练轮”以实现完全去中心化。 165 | L2BEAT基于Vitalik Buterin的提案，提出了一个三阶段框架，用于评估Rollup的成熟度。 166 | 167 | Stages框架 168 | Stage 0：完全训练轮 169 | 定义：Rollup由运营方完全控制。 170 | 要求： 171 | 1.项目自称为Rollup。 172 | 2.L2状态根在L1上发布。 173 | 3.数据在L1上提供可用性。 174 | 4.提供开源软件以从L1数据重建L2状态。 175 | 176 | Stage 1：有限训练轮 177 | 定义：治理由智能合约主导，但仍有“安全委员会”应对潜在问题。 178 | 要求： 179 | 1.实施有效的证明系统（如欺诈证明或零知识证明）。 180 | 2.至少5名外部参与者可提交欺诈证明。 181 | 3.用户无需运营者协调即可退出。 182 | 4.用户在升级前至少有7天退出时间（排除安全委员会干预）。 183 | 5.安全委员会由至少8名成员组成，50%需为外部人员。 184 | 185 | Stage 2：无训练轮 186 | 定义：完全由智能合约控制，去中心化且无需信任。 187 | 要求： 188 | 1.欺诈证明系统完全开放。 189 | 2.用户在升级前至少有30天退出时间。 190 | 3.安全委员会仅限于处理链上检测到的严重错误。 191 | 192 | ### 2025.01.12 193 | 请假 194 | 195 | 196 | ### 2025.01.13 197 | 请假 198 | 199 | ### 2025.01.14 200 | # 学习笔记：Optimism Collective 和 Superchain 201 | 202 | ### 1. **Optimism Collective 的概述** 203 | 204 | - **Optimism Collective** 是由公司、社区和公民组成的合作组织，旨在通过奖励公共利益，建设以太坊的可持续未来。 205 | - 核心目标是构建 **Superchain**，通过协作实现去中心化和可组合性，同时保护网络安全并推动增长。 206 | 207 | ### 2. **Superchain 产品愿景** 208 | 209 | - **标准化**：统一链的规则，支持大规模去中心化和可组合性。 210 | - **扩展性**：从 15-50 条链扩展到 1000+，用户体验如单一链。 211 | - **治理保障**：通过治理机制确保安全和可持续发展。 212 | 213 | ### 3. **核心原则：Impact=Profit** 214 | 215 | - **目标**：构建一个无主但为所有人服务的互联网。 216 | - **方法**：通过奖励创造积极影响的行为，推动新的经济模式 **Ether’s Phoenix**。 217 | 218 | ### 4. **双院制治理** 219 | 220 | ##### 4.1 **Token House** 221 | 222 | - 由 OP 代币持有者组成，负责提交、讨论和投票治理提案。 223 | - 支持直接投票或委托投票权。 224 | 225 | ##### 4.2 **Citizens' House** 226 | 227 | - 基于声誉的一人一票系统，专注于 **Retro Funding**，奖励对 Collective 和 Superchain 有贡献的行为。 228 | 229 | **协作模式**：两院共同推动 Collective 愿景，通过分工和制衡优化决策。 230 | 231 | ### 5. **关键文件** 232 | 233 | - **工作宪法**：定义 Collective 的治理原则（2022 年制定）。 234 | - **操作手册**：记录治理流程，随 Collective 发展动态更新。 235 | - **去中心化模型**：概述去中心化阶段和治理决策流程。 236 | 237 | ### 2025.01.15 238 | 239 | 治理工具 ​ • Token House Governance Contract：用于提交和投票治理提案的链上投票合约。 • Optimism Governance Portal：代币持有者用以委托和投票的前端界面。 • Citizens’ House Snapshot Space：供Citizens投票否决Token House提案的界面。 • Optimism Forum：讨论和审议治理提案的论坛。 • Discord：非正式讨论和反馈的社群平台。 • Github：管理基金申请。 • Charmverse：Optimism Grants Council的协作平台。 ​ 提案类型和流程 治理提案分为以下类型，需遵循三周的投票周期： 三周周期 • **每周时间：周四19:00 GMT到次周三19:00 GMT** 1. 第1-2周：草案阶段 ◦ 提案需发布在Optimism Forum中，标记为Draft。 ◦ 作者需积极回应社区成员（包括代表和Citizens）的反馈。 ◦ 在第二周结束前，治理管理员会创建Voting Cycle Roundup汇总帖，仅收录满足投票条件的提案。 ◦ 条件： ■ Token House提案需获得前100名代表中至少4位明确批准。 ■ Citizens’ House提案需获得至少4位Citizens批准。 ■ 基金申请由特定委员会审议，不需获得批准。 ◦ 获批提案需将标题改为Final并提交至Voting Cycle Roundup。 2. 第3周：投票阶段 ◦ 所有符合条件的提案进入投票。 ◦ Token House提案需满足以下条件： ■ 法定人数：参与投票的OP数量占可投票OP总量的一定比例。 ■ 批准阈值：赞成票占所有赞成和反对票的比例达到一定值。 ◦ Citizens’ House提案类似，投票通过需满足特定的法定人数和批准阈值。 ◦ 投票结果通过Optimism Governance Portal或Snapshot Space发布。 ​ 否决程序 • Citizens’ House的否决权： ◦ 对Token House批准的协议升级提案具有否决权。 ◦ 否决期为Token House投票结束后的一周。 ◦ 否决需要达到指定的否决阈值（以总投票权的百分比计算）。 • Token House的否决权： ◦ 可否决Citizens’ House批准的提案，遵循相同的规则。 否决具有重要影响，仅在提案被认为是恶意或被破坏时适用。 240 | 241 | ### 2025.01.16 242 | Retro Funding是Citizens' House治理的一部分，旨在通过追溯性公共物品资助（Retro Funding）奖励那些对社会产生重大影响的公共物品项目。 243 | Retro Funding过程 244 | 1. 范围定义：确定奖励总额和影响范围。 245 | 2. 项目申请创建：项目被邀请创建申请，填写在Retro Funding申请管理系统中。 246 | 3. 申请审查：对项目的申请进行审核，确保符合申请规则。 247 | 4. 投票：向拥有有效AttestationStation条目的Citizens收集投票，并进行计票。 248 | 5. 奖励发放：根据Citizens' House投票的加权平均数，确定并分配奖励。 249 | 6. 合规性：基金会会收集项目信息，确保以符合KYC（了解你的客户）规定的方式发放资金。 250 | 251 | 治理过程的实施遵循《操作手册》中的规定，并由Optimism基金会负责监督和执行。基金会确保治理程序的顺利进行，保障集体成员能够积极参与。 252 | 管理服务： 253 | • 提案审核：确保提交的治理提案有效并符合规定。 254 | • 不当提案移除：移除那些具有欺诈性、垃圾信息、诽谤、仇恨或与集体价值不符的提案。 255 | • 投票监控：监控投票过程，确保法定人数和批准阈值得到满足。 256 | • 相互矛盾的提案管理：处理同时提交或紧接提交的相互矛盾的提案。 257 | • 网络维护管理：应急修复或回滚网络升级，必要时无需治理投票。 258 | 259 | 一旦治理提案获得批准，基金会将审核其安全性、合规性，并决定是否可以执行。如果提案符合要求，基金会将积极推进实施。如果提案不符合要求，基金会可选择将提案退回修改，或者进行有条件实施，并向集体解释原因。 260 | 261 | 基金会的角色在未来将逐步去中心化，计划让治理逐步从基金会转移到更加去中心化的组织中。 262 | 263 | ### 2025.01.17 264 | 265 | Retro Funding是一种基于过去的贡献比未来的贡献更容易评估的思想进行的资助机制。其核心理念是，回顾性地奖励那些已经对Optimism 集体以及Superchain做出积极贡献的项目。通过这种方式，Optimism生态系统能够建立一个更加稳健和可持续的公共产品基础，激励更多人做出有益的贡献。 266 | 267 | 核心概念与原则 268 | 269 | 1. Impact=Profit： Optimism的核心价值观是影响=利润，即通过对集体的积极影响获得与之成比例的利润。这意味着在Optimism生态系统内，越是能够带来积极影响的项目，就应该获得更多的奖励。 270 | 2. 回溯性资助的机制： • 目标：通过回顾性地资助过去贡献巨大的公共产品，激励更多人致力于公共产品的建设。 • 激励：这为构建公共产品的开发者提供了强大的动力，尤其是在没有直接收入的情况下，他们依然能够获得奖励，进而促进应用的使用和区块空间需求的增加。 271 | 3. 飞轮效应： Retro Funding的另一个好处是为公共产品项目提供了潜在的退出流动性，这为早期投资提供了市场。开发者不仅可以获得奖励，还可以利用项目的潜力吸引资本注入，帮助项目成长。 272 | 273 | ### 2025.01.18 274 | 275 | Retro Funding是一个持续实验的过程，旨在通过周期性的资助回合，构建一个更加丰富和可持续的生态系统。每一轮资助都会有不同的侧重点和资助流程，最终目标是推动Optimism Collective的长期发展。 276 | 277 | Retro Funding有三个核心组成部分，每个部分都提供了广泛的实验空间： 278 | 1. 影响范围： • 关键问题：集体应该资助哪些项目？这些项目的影响力如何定义和评估？ • 决策过程：如何决定哪些项目值得资助？这些决策将随着时间推移不断优化。 279 | 2. 影响评分： • 关键问题：如何评估项目的影响？使用什么单位、过程或工具来进行评分？ • 影响评分是Retro Funding的一项核心活动，它帮助Citizens’ House在每一轮资助中做出决策。 3. 影响结算： • 关键问题：投票是如何进行的？ • 影响结算环节确保资助的资金和奖励分配公平且透明。 280 | 281 | 未来展望 282 | 1. 开放的元治理： 初期阶段，Optimism Foundation（Optimism基金会）会在社区的帮助下决定资助的范围和投票机制。但随着时间的推移，这些决定将逐渐交由Citizens’ House来制定，并受到Token House的检查和平衡。 283 | 2. 扩展公共产品资助的范围： 在后续的回合中，Retro Funding的目标是扩大资助范围，不仅支持Optimism生态系统内的公共产品，还支持跨越更多生态系统的公共产品。 通过不断优化和实验，Retro Funding将推动更加丰富、灵活的公共产品资助生态，最终形成一个长期可持续的公共产品建设模式。 284 | 285 | Retro Funding是一种创新的公共产品资助机制，采用回溯性的方式为过去做出积极贡献的项目提供奖励。它为开发者提供了没有直接收入但仍能获得奖励的机会，进而激励更多优质公共产品的建设。这种机制将不断实验和完善，以期形成一个更加健康和繁荣的生态系统。 286 | 287 | ### 2025.01.19 288 | 请假 289 | 290 | ### 2025.01.20 291 | 292 | Superchain 是 OP Stack 的下一个主要可扩展性改进，旨在通过共享桥接、去中心化治理、升级、通信层等多项功能，创建一个由多个链组成的网络。Superchain 将 OP 主网与其他链合并成一个统一的网络，称为 OP 链，推动去中心化和可扩展计算的实现。 293 | 目前，Superchain 是一个概念和正在进行的项目，尚未完全实现。文档描述了 Superchain 的可扩展性愿景、概念以及 OP Stack 所需的更改。 294 | 295 | ### 2025.01.21 296 | 297 | 298 | ### 区块链技术现状：不够支撑去中心化网络： 299 | 300 | 区块链的初衷是构建去中心化的网络，用无需信任的协议代替传统的中心化机构。但扩展性问题一直限制了区块链的发展。 扩展性问题从比特币白皮书发表之初就被指出了，但十多年过去，问题仍未解决。 301 | 302 | 303 | ### 如果扩展性问题解决了，会有什么好处？ 304 | 305 | 1. 开发者的解放：不再担心后端基础设施，区块链保证正确的执行、可扩展性和应用的高可用性。 306 | 307 | 2. 超强的组合性：在链上的智能合约共享执行环境，比传统 REST API 更高效，应用之间更容易协作。 308 | 309 | 3. 降低开发成本：开发者无需为用户支付基础设施费用，解锁更多变现策略。 小型开发者也能参与开发热门应用，不再受资金限制。 310 | 311 | 4. 新型互联网体验：开发者无需传统后端开发，只需专注产品。 普通开发者也能轻松使用区块链，区块链技术成为所有开发者的工具箱核心。 312 | 313 | 5. 用户数据安全与可验证性：应用上链后，用户的数据、身份和声誉都是加密可验证的。 用户可以跨应用使用统一的声誉系统（如用于投票、贷款或担保），完全掌控自己的数据。 314 | 315 | 316 | 如果扩展性问题被解决，区块链可能彻底改变互联网，变成每个应用都能用的核心技术。 317 | 318 | 319 | ### Superchain 架构：解决区块链扩展性问题 320 | 321 | superchain 是对区块链扩展性的未来愿景。 322 | 323 | 它是一个多年的开发方向，目标是通过新的技术架构解决扩展性瓶颈。 324 | 325 | 326 | ### 2025.01.22 327 | ### 1.水平扩展需要多个链 328 | 329 | 水平扩展性 是指通过增加资源来处理更多的事务量。 330 | 331 | 区块链实现水平扩展性需要运行多个链，因为单条链的计算能力有限。 332 | 333 | 每条链的工作原理： 334 | 335 | • 有一个初始状态。 336 | 337 | • 通过交易执行状态转换。 338 | 339 | • 数据被加密承诺并可由普通电脑和网络独立同步。 340 | 341 | 342 | ### 2.传统多链架构的局限性 传统多链系统面临两个大问题： 343 | 344 | 安全风险叠加： • 每新增一条链，就会引入一个新的安全模型。 • 多条链一起运行时，系统性的安全风险不断累积。 345 | 346 | 高启动成本： • 每个链都需要自己的验证节点和区块生产者，这非常昂贵。 347 | 348 | 349 | ### 3.Superchain 的改进方法 350 | 351 | Superchain 通过共享一个主链（L1链）作为 “真相的来源” 来解决上述问题： 352 | 353 | • 所有链（称为 L2链）共享同一个安全模型，降低系统性风险。 354 | 355 | • 新增链无需新的验证节点，因为所有 L2 链都依赖 L1 的共识机制。 356 | 357 | ### 2025.01.23 358 | 尽管 Superchain 提供了很多强大的功能，但仍然存在一些挑战，如跨链交易的延迟和不支持原子跨链交易。为了解决这些问题，未来将引入以下技术： 359 | 多重证明安全性：解决撤回声明依赖受信任链验证者的问题。 360 | 低延迟 L2 到 L2 消息传递：通过模组化证明系统提供低延迟的跨链通讯。 361 | 同步跨链交易：通过共享的序列化协议，支持原子性跨链交易。 362 | 替代数据可用性层 (Alt-DA)：通过扩展 L1 数据可用性，支持更加高效的事务数据存储。 363 | 多链应用框架：帮助开发者构建跨多个 OP 链的可扩展应用，简化用户管理和智能合约开发。 364 | 365 | ### 2025.01.24 366 | 367 | OP Stack 是一个标准化的、共享的、开源的开发栈，支持Optimism，且由Optimism Collective 维护。它构成了Optimism的核心，主要用于创建和管理L2区块链。 368 | 它是为以太坊和 Op 生态系统服务的公共产品。它的目标是简化L2区块链的创建过程，并通过共享的标准来避免重复开发相同的软件。随着Superchain概念的推出，OP Stack 的目标是支持在更大范围内的跨链互操作性。 369 | 370 | ### 2025.01.25 371 | 372 | 373 | ### 2025.01.26 374 | 375 | 376 | 377 | -------------------------------------------------------------------------------- /MagicalBridge.md: -------------------------------------------------------------------------------- 1 | --- 2 | timezone: Asia/Shanghai 3 | --- 4 | 5 | > 请在上边的 timezone 添加你的当地时区，这会有助于你的打卡状态的自动化更新，如果没有添加，默认为北京时间 UTC+8 时区 6 | > 时区请参考以下列表，请移除 # 以后的内容 7 | 8 | timezone: Pacific/Honolulu # 夏威夷-阿留申标准时间 (UTC-10) 9 | 10 | timezone: America/Anchorage # 阿拉斯加标准时间 (UTC-9) 11 | 12 | timezone: America/Los_Angeles # 太平洋标准时间 (UTC-8) 13 | 14 | timezone: America/Denver # 山地标准时间 (UTC-7) 15 | 16 | timezone: America/Chicago # 中部标准时间 (UTC-6) 17 | 18 | timezone: America/New_York # 东部标准时间 (UTC-5) 19 | 20 | timezone: America/Halifax # 大西洋标准时间 (UTC-4) 21 | 22 | timezone: America/St_Johns # 纽芬兰标准时间 (UTC-3:30) 23 | 24 | timezone: America/Sao_Paulo # 巴西利亚时间 (UTC-3) 25 | 26 | timezone: Atlantic/Azores # 亚速尔群岛时间 (UTC-1) 27 | 28 | timezone: Europe/London # 格林威治标准时间 (UTC+0) 29 | 30 | timezone: Europe/Berlin # 中欧标准时间 (UTC+1) 31 | 32 | timezone: Europe/Helsinki # 东欧标准时间 (UTC+2) 33 | 34 | timezone: Europe/Moscow # 莫斯科标准时间 (UTC+3) 35 | 36 | timezone: Asia/Dubai # 海湾标准时间 (UTC+4) 37 | 38 | timezone: Asia/Kolkata # 印度标准时间 (UTC+5:30) 39 | 40 | timezone: Asia/Dhaka # 孟加拉国标准时间 (UTC+6) 41 | 42 | timezone: Asia/Bangkok # 中南半岛时间 (UTC+7) 43 | 44 | timezone: Asia/Shanghai # 中国标准时间 (UTC+8) 45 | 46 | timezone: Asia/Tokyo # 日本标准时间 (UTC+9) 47 | 48 | timezone: Australia/Sydney # 澳大利亚东部标准时间 (UTC+10) 49 | 50 | timezone: Pacific/Auckland # 新西兰标准时间 (UTC+12) 51 | 52 | --- 53 | 54 | # Louis 55 | 56 | 1. 自我介绍 57 | My name is louis and I am a blockchain development engineer 58 | 59 | 2. 你认为你会完成本次残酷学习吗？ 60 | I believe that I can complete the study task 61 | 62 | ## Notes 63 | 64 | 65 | 66 | ### 2025.01.06 67 | 68 | Optimism 是一种“乐观型 Rollup”，即以太坊的 Layer 2 扩展解决方案，通过利用以太坊的安全性来提高交易吞吐量并降低费用。 与传统区块链不同，乐观型 Rollup 默认假设交易是有效的，只有在出现挑战时才执行计算，从而显著提高效率。 69 | 70 | **乐观型 Rollup 的关键组成部分：** 71 | 72 | - **区块存储：**在 Bedrock 版本中，Optimism 使用非合约地址（0xff00...0010）在以太坊上存储 Layer 2（L2）区块，以最小化 gas 费用。 这些区块作为交易提交，使用 EIP-4844 blobs，一旦包含在具有足够验证的区块中，即可确保数据的可用性和完整性。 这种设计使 Optimism 继承了以太坊的安全保证。 73 | 74 | - **区块生产：**一个称为“排序者”的实体负责区块生产。 排序者提供交易确认，构建和执行 L2 区块，并将用户交易提交到 Layer 1（L1）。 在 Bedrock 中，排序者拥有一个私有内存池，以防止矿工可提取价值（MEV）机会。 无论交易量如何，每两秒生成一个区块。 75 | 76 | - **区块执行：**交易在 L2 链上执行，结果定期发布到以太坊。 这种方法减少了以太坊的计算负担，同时保持安全性。 77 | 78 | - **资产桥接：**用户可以使用桥接将 ETH 和代币在以太坊和 Optimism 之间转移。 从以太坊移动资产到 Optimism 涉及在以太坊的合约中锁定代币，并在 Optimism 上铸造相应的代币。 相反的过程涉及在 Optimism 上销毁代币，并在以太坊上解锁它们。 79 | 80 | - **故障证明：**Optimism 采用一种挑战机制，默认假设交易是有效的，除非被证明无效。 如果有人发现无效交易，可以提交故障证明进行挑战。 该系统在无需对每笔交易进行链上计算的情况下确保正确性。 81 | 82 | 通过利用这些机制，Optimism 在保持以太坊的安全性和去中心化的同时，实现了更高的可扩展性和更低的费用。 83 | 84 | ### 2025.01.07 85 | Layer 2扩容技术是为解决区块链主网（Layer 1）交易拥堵和高手续费等问题而发展起来的，通过将部分交易从主网转移到二层网络进行处理，实现了在不改变主网底层协议的基础上提升区块链的性能。常见的Layer 2扩容技术如下： 86 | 87 | #### State Channels 88 | - 原理：允许用户在链下建立通道进行多次交易，只在通道开启和关闭时将交易结果记录在主链上，期间的交易状态在链下维护。 89 | - 优点：交易速度快，可实现即时确认；交易成本低，因为大量交易无需上链。 90 | - 缺点：通道内的资金有一定的锁定时间；安全性依赖于参与者的信用和智能合约的安全性。 91 | - 应用：主要应用于高频小额交易场景，如支付、微交易等。 92 | 93 | #### Sidechains 94 | - 原理：与主链平行的独立区块链，通过双向锚定技术实现与主链的资产转移和交互。侧链有自己的共识机制和交易处理能力，可独立处理交易。 95 | - 优点：具有较高的灵活性，可根据需求定制侧链的功能和参数；能实现一定程度的扩容，缓解主链压力。 96 | - 缺点：跨链交互的安全性和复杂性较高；侧链的安全性和主链存在一定的耦合性。 97 | - 应用：可用于实现特定的业务逻辑或功能，如隐私交易、游戏等。 98 | 99 | #### zk-Rollups 100 | - 原理：将多个链下交易打包成一个批次，生成一个零知识证明，然后将证明和交易摘要提交到主链。主链只需验证零知识证明的有效性，即可确认整个批次交易的合法性。 101 | - 优点：数据可用性和安全性高，主链可验证交易的有效性；隐私性好，零知识证明可隐藏交易细节。 102 | - 缺点：技术实现复杂，对开发者要求高；证明生成和验证的计算成本较高。 103 | - 应用：适用于对隐私和安全性要求较高的场景，如金融交易、身份认证等。 104 | 105 | #### Optimistic Rollups 106 | - 原理：假设所有提交到Layer 2的交易都是合法的，先将交易结果快速更新到Layer 2，并将交易数据压缩后提交到主链。在一定的挑战期内，如果有用户发现交易存在问题，可发起挑战，通过智能合约进行验证和处理。 107 | - 优点：兼容性好，易于与现有以太坊生态系统集成；交易速度较快，可实现快速确认。 108 | - 缺点：挑战期内存在一定的安全风险；交易最终确认时间较长。 109 | - 应用：广泛应用于以太坊Layer 2解决方案，如Optimism、Arbitrum等。 110 | 111 | 112 | ### 2025.01.08 113 | 114 | 先介绍optimism Gas 机制 optimism 交易中的两个成本来源：L2 执行费和 L1 数据/安全费。 115 | 116 | L2执行费: 117 | optimism在L2中的交易收费和在以太坊上交易一样收取gas费，用作计算和储存的需求，每一笔交易都会支付一定的gas费，计算公式： 118 | L2_execution_fee = transaction_gas_price * L2_gas_used 119 | transaction_gas_price：L2网络上的gas价格，通常以 Gwei 为单位。 120 | l2_gas_used：交易在L2上的消耗数量，每个操作，比如转账，存储，调用合约等，都会消耗不同的gas，操作越多gas费越高。 121 | 122 | L1 数据费: 123 | Optimism 与以太坊不同，因为 Optimism 上的所有交易也都发布到以太坊。此步骤对于 Optimism 的安全属性至关重要，因为这意味着同步 Optimism 节点所需的所有数据始终在以太坊上公开可用。这就是使 Optimism 成为 L2 的原因。 124 | Optimism 上的用户必须支付向以太坊提交交易的费用。称之为L1 数据费用 ，这是 Optimism（和其他 L2）与以太坊之间的主要差异。由于以太坊上的 gas 成本非常昂贵，因此 L1 数据费用通常会在 Optimism 上占据交易的总成本。该费用基于四个因素： 125 | 126 | 以太坊当前的gas价格。 127 | 将交易发布到以太坊的 gas 成本。这交易长度的大小（以字节为单位）成比例。 128 | 以gas计价的固定费用。当前设置为 2100。 129 | 一种动态的间接费用，按固定数字支付的 L1 费用。当前设置为 1.24。 130 | 131 | L1数据费计算公式： 132 | L1_data_fee = L1_gas_price * (tx_data_gas + fixed_overhead) * dynamic_overhead 133 | L1_gas_price：以太坊主网的 Gas 价格，通常以 Gwei 为单位。 134 | tx_data_gas：交易数据所需的 Gas，表示将 L2 上的交易数据提交到 L1 时消耗的 Gas。 135 | fixed_overhead：固定的开销，包括 L2 网络在提交数据时的固定成本，如签名验证、批次处理等。 136 | dynamic_overhead：动态开销，表示网络的负载和 L1 上的拥堵情况对 Gas 消耗的影响。 137 | 138 | 固定费用（例如：提交批次时的签名验证、Merkle 树计算等），这些成本不会随交易数量变化。 139 | 动态费用则是因为L1的网络情况，有时拥堵，那么提交批次的费用就可能变高。 140 | 141 | 因此，L2执行费+L1数据费才是一个交易的总共费用。 142 | total_fee = l2_execution_fee + l1_data_fee 143 | 144 | 提交数据费的好处是，将一些重要信息同步到L1中，比如状态根，提交到L1后，所有人都可以查看交易，帮助用户发现不诚实者，并发起挑战。 145 | 146 | ### 2025.01.09 147 | 148 | 149 | 学习目标：今天深入学习和搞懂故障证明 150 | 151 | ### 为什么 Optimism 要做故障(欺诈)证明 152 | 153 | 简单来说：故障证明是一种旨在取代安全委员会的去中心化机制。请记住，Optimism 是一种乐观的汇总，这意味着它假设所有交易都是有效的，除非证明相反。故障证明提供了证明交易无效的工具。 154 | 155 | Optimistic Rollups 依靠以下三个因素的组合来确保安全性； 156 | 157 | 乐观汇总机制：此机制假设一批交易中的所有交易都是有效的，除非另有证明。它允许更快、更便宜的交易，但引入了欺诈活动的风险。 158 | 159 | 七天挑战期：这一时期是一个至关重要的安全网。它允许任何人挑战状态根的有效性。如果挑战成功，乐观链可以回滚到之前的有效状态。 160 | 161 | 乐观安全委员会：一组值得信赖的实体，负责监督网络并做出关键决策。在挑战期间出现问题时，它们充当后盾。 162 | 163 | 164 | 传统上，安理会负责质疑和解决欺诈交易纠纷。虽然这种集中式方法有效，但它引入了潜在的故障点并引发了对信任的担忧。为了解决这个问题，Optimism 引入了故障证明。 165 | 166 | 167 | ![image](https://github.com/user-attachments/assets/2f0632b8-6224-42b0-99fa-dd531950e86a) 168 | 169 | 170 | 这个图可以看出来，当一个不诚实的提案者提出来时，其他诚实的节点会提出提案去挑战不诚实节点的提案 171 | 172 | 交易批处理 173 | 174 | 分组交易：将用户发起的交易集合收集起来并组合成一个单元。此批处理过程大大减少了以太坊主网上需要处理的数据量。 175 | 176 | 效率提升：通过同时处理多个交易，Optimism 可以优化计算资源的使用，从而缩短交易时间并降低成本。 177 | 178 | 州根提交 179 | 180 | 快照创建：在处理一批交易后，Optimism 会生成一个状态根，它本质上是一个加密哈希，代表特定时间点区块链的整个状态。 181 | 数据压缩：状态根简洁地表示区块链的数据，大大减少了需要传输到以太坊的信息量。 182 | 以太坊交互：计算出的状态根被提交到以太坊主网，并记录在区块链上。 183 | 184 | 挑战期 185 | 186 | 争议窗口：提交状态根后会建立一个指定的时间范围，在此期间任何人都可以质疑其有效性。 187 | 激励：为了鼓励参与，成功识别和挑战欺诈性国家根源的个人通常会获得奖励或激励。 188 | 安全机制：此期限充当安全网，允许在错误变为永久性错误之前检测并纠正错误。 189 | 190 | 191 | 争议游戏 192 | 193 | 挑战发起：如果有人认为状态根不正确，他们可以通过提供错误的证据来发起争议。 194 | 提交证明：挑战者必须提交一份欺诈证明，即证明状态根无效的数据。 195 | 验证过程：Optimism 网络随后进入争议解决过程，在此过程中评估防欺诈的有效性。 196 | 197 | 198 | 199 | 200 | 201 | ### Stage 标准 202 | Stage 标准：这里面其实比较重要的原因是 Vitalik 提到的这个 Rollup 里程碑的初步框架，在之前的 Rollup 推出中，几乎所有项目都采用一种模式，即使用临时训练轮：当项目技术尚不成熟时，项目会尽早启动，以便生态系统开始形成，但并非完全依赖其欺诈证明或 ZK 证明，而是采用某种多重签名，能够在代码出现错误时强制执行特定结果。 203 | Vitalik 根据 Rollup 对辅助工具的依赖程度，将 Rollup 分为三个不同的阶段： 204 | 205 | 第 0 阶段 — 全面训练：在此阶段，rollup 由操作员有效运行。不过，有一个源可用软件，可以根据 L1 上发布的数据重建状态，用于将状态根与提议的根进行比较。 206 | 207 | 第 1 阶段 — 有限的训练轮：在此阶段，rollup 过渡到由智能合约管理。但是，可能会保留一个安全委员会来解决潜在的错误。此阶段的特点是实施功能齐全的证明系统、分散欺诈证明提交，并提供无需运营商协调的用户退出。由多元化参与者组成的安全委员会提供了安全网，但其权力也带来了潜在风险。 208 | 209 | 第 2 阶段 — 无需训练：这是 Rollup 完全由智能合约管理的最后阶段。此时，防欺诈系统无需许可，如果出现不必要的升级，用户有充足的时间退出。安理会的作用严格限于解决可以在链上裁决的健全性错误，并保护用户免受治理攻击。 210 | 211 | 212 | Optimism 为了实现 Stage 1 阶段，即必须有一个正在运行的欺诈证明或有效性证明方案，该方案具有实际权力来接受或拒绝哪些状态根被汇总合约所接受。 213 | 214 | 215 | ### 链运营商（其他基于 OP Stack 开发的 L2）应该留出多少 ETH 来运行故障证明系统？ 216 | 运行 FP 的名义运营成本（即假设没有无效提案或恶意行为者）将取决于初始债券的设定FaultDisputeGame和发布提案的频率。假设 OP Mainnet 参数每小时发布一次提案，即每小时 0.08 ETH。假设争议窗口为 7 天，您将需要大约 14 ETH（包括 gas 成本）来提出提案。如果链使用与 OP Mainnet 类似的 FP 部署配置，建议坚持使用 0.08 ETH 的初始债券。 217 | 然而，运营 FP 链本身的资本要求远大于 14 ETH。使用 FP 保护其链的运营商必须愿意投入大量 ETH 来保护链。有人可能会认为资本要求不值得，而只使用许可的 FP 系统。在故障证明的后期阶段，资本要求将得到改善，使其更适用于较小的链。 218 | 219 | 220 | ### referencce 221 | https://dev.to/modenetworkl2/what-is-optimism-faultproofs-db7(故障证明) 222 | https://docs.optimism.io/stack/fault-proofs/explainer 223 | 224 | ### Next Step 225 | 了解一下 Vitalik 提出 Stage 阶段的历程，以前发生过那些不合规的情况，以及目前达到 stage 阶段的一些 L2 226 | 227 | 228 | -------------------------------------------------------------------------------- /Marcus-Chen98.md: -------------------------------------------------------------------------------- 1 | --- 2 | timezone: Asia/Shanghai 3 | --- 4 | 5 | 6 | --- 7 | 8 | # {Marcus-Chen} 9 | 10 | 1. 我是一个汽车行业的研究员，之前做过一段时间的投资研究工作，现在转到汽车行业做战略咨询，一直想了解web3的试解 11 | 12 | 2. 我希望每天下班后花1-2个小时，完成这次学习，也让自己养成学习知识的习惯，希望能完成 13 | 14 | ## Notes 15 | 16 | 17 | 18 | ### 2025.01.06 19 | **OP是什么** 20 | 首先OP rullup是一种乐观汇总，是以太坊的 Layer 2 扩展解决方案，旨在提高交易吞吐量并降低费用。其核心思想是将大量交易在链下执行，然后将交易数据打包提交到以太坊主链。 21 | 默认情况下，这些交易被视为有效，只有在有人提出质疑时，才会通过欺诈证明机制进行验证，挑战期（通常为 7天），成功的挑战不会回滚 OP 主网本身，只会回滚已发布的关于链状态的承诺。 交易顺序和 OP 主网的状态因防故障质询而保持不变。 22 | （当然还有一种验证方式是Zero-Knowledge Proof，会将多笔交易打包在一起，并发布到 Layer 1 区块链上，同时还会发布一个验证计算有效性的证明） 23 | **单轮交互** 24 | OP是单轮交互的，发布数据的一方只在遭遇质疑会和挑战者进行一次证明交互，减少了大量交互带来的成本，而**Arbitrum**是*多轮交互*的，通过反复交互验证缩小争议范围能够更好地支持复杂的智能合约，并提高系统的安全性 25 | 26 | ### 2025.01.07 27 | OP网络的核心参与者： 28 | 29 | Users（用户）： 30 | 指普通的用户或应用开发者，他们与 Layer 2 (L2) 网络交互。 31 | 用户可以： 32 | 提交交易到 Sequencers（排序者）。 33 | 通过 Layer 1 (Ethereum L1) 进行存款或取款操作。 34 | 35 | Sequencers（排序者）： 36 | 负责接收用户提交的交易并对交易进行排序。 37 | 他们的职责包括： 38 | 接收交易并生成 L2 区块。 39 | 提交交易批次到 Ethereum L1 以获得最终性。 40 | 实时向网络广播交易的更新。 41 | 42 | Verifiers（验证者）： 43 | 主要作用是验证 Sequencers 提交的输出结果。 44 | 他们会： 45 | 从 Ethereum L1 获取交易批次或存款数据。 46 | 验证输出提案是否正确，并在必要时发起挑战 47 | 48 | **不同Layer2扩容方案运行环境与技术对比：** 49 | - Ethereum (Layer 1)：作为基准环境，不使用任何扩容技术。 50 | - ZK Rollup：采用零知识证明技术，交易验证快速，但计算成本较高。 51 | - ZK Porter：结合 ZK Rollup 和 Validium 技术，将部分数据存储在链下，提高扩展性。 52 | - Optimism：采用 Optimistic Rollup 技术，假设交易有效，仅在必要时进行欺诈证明。 53 | - Arbitrum：同样基于 Optimistic Rollup，但使用多轮欺诈证明，适合复杂智能合约。 54 | - AnyTrust：基于 Plasma 和 zkport 技术，更适合对数据隐私有更高需求的场景。 55 | 56 | ### 2025.01.08 57 | **OP Stack** 是一组标准化的组件和工具，开发者可以用它来搭建自己的区块链或扩容方案 58 | OP Stack 的结构可以分为多个模块，以下是一些核心组件： 59 | 60 | Execution Layer（执行层）： 61 | 负责运行智能合约和处理交易。 62 | 类似以太坊的 EVM（以太坊虚拟机），OP Stack 支持与 EVM 完全兼容的操作。 63 | 64 | Consensus Layer（共识层）： 65 | 确定交易的顺序和确认。 66 | 在 Optimism 中，Sequencer 是负责排序交易的核心角色。→Sequencer（*时间顺序、GAS费用优先、批次优化*）定期将已排序和打包的交易批次提交到以太坊（Layer 1），确认交易（提交内容为（*1交易批次数据*、*2状态根*）） 67 | 68 | Settlement Layer（结算层）： 69 | 管理与 Layer 1 的交互，例如提交批次交易和欺诈证明。 70 | 提供了跨 Layer 2 和 Layer 1 的安全保障。 71 | 72 | Data Availability Layer（数据可用性层）： 73 | 记录交易数据并确保所有验证者都能访问。 74 | OP Stack 目前依赖以太坊的 Layer 1 提供数据可用性 75 | 76 | **L1 Smart Contract** 77 | 78 | 1、L1StandardBridge： 79 | - 提供标准的资产桥接功能（ERC20、ETH 等），负责管理资产的存款和提款。 80 | - 支持发送和接收跨层消息。 81 | 82 | 2、L1ERC721Bridge： 83 | - 类似于 L1StandardBridge，但专门用于 NFT 的桥接。 84 | - 允许用户将 NFT 存入或提取到 Layer 1 或 Layer 2。 85 | 86 | 3、L1CrossDomainMessenger： 87 | - 负责 Layer 1 和 Layer 2 之间的消息传递。 88 | - 确保不同层之间的信息是同步的，例如交易完成或存款成功。 89 | 90 | 4、OptimismPortal： 91 | - 是系统的入口和核心交互点。 92 | - 提供了状态查询、提案验证等功能，同时支持暂停/恢复系统操作。 93 | 94 | 5、DisputeGameFactory： 95 | - 用于生成和管理争议游戏（Dispute Game）。 96 | - 挑战者可以通过此模块验证 Layer 2 的状态根是否正确。 97 | 98 | 6、FaultDisputeGame： 99 | - 管理具体的争议实例，用于防止 Layer 2 的欺诈状态被提交。 100 | 101 | 7、SuperchainConfig 和 SystemConfig： 102 | - 配置整个系统的参数，例如区块时间、Gas 费用等。 103 | 104 | 8、AnchorStateRegistry： 105 | - 用于存储和更新锚定状态（Anchor States），确保 Layer 1 和 Layer 2 的状态一致。 106 | 107 | 9、DelayedWETH： 108 | - 管理延迟提款的 WETH，可能是为了增加额外的安全性或优化流程。 109 | 110 | 10、BatchInbox Address： 111 | - 存储已提交的交易批次，用于 Layer 1 的验证和管理 112 | 113 | **举例：从用户交互到争议解决的全流程--以ERC20代币为例** 114 | 115 | *Step 1: 用户发起存款* 116 | 117 | - 用户通过钱包向 Layer 1 的 L1StandardBridge 发起存款请求。 118 | - 资产锁定：ERC20 代币在 L1 被锁定，并通过 L1StandardBridge 通知 Layer 2。 119 | 120 | *Step 2: L1 向 Layer 2 通知* 121 | 122 | - L1CrossDomainMessenger 接收存款事件，将消息传递给 Layer 2。 123 | - Layer 2 的 Sequencer（排序器）根据存款事件更新 Layer 2 的状态，为用户创建等量的 Layer 2 代币。 124 | 125 | *Step 3: 用户在 Layer 2 中发起交易* 126 | 127 | - 用户使用 Layer 2 的资产进行交易。 128 | - Layer 2 的 Sequencer 收集这些交易，并生成一个批次。 129 | 130 | *Step 4: Batcher 打包交易* 131 | 132 | - Batcher 将 Layer 2 的交易批次发送到 Layer 1，通过 Batch Inbox Address 存储。 133 | - 作用：这些批次被作为 Layer 2 状态的证据存储在 Layer 1。 134 | 135 | *Step 5: 验证或争议* 136 | - 如果验证者认为提交的交易批次或状态根有错误，他们可以通过 DisputeGameFactory 发起争议。 137 | 138 | *争议解决：* 139 | - FaultDisputeGame 启动验证流程。 140 | - 如果确认错误，系统将回滚状态并惩罚提交错误状态的角色。 141 | 142 | *Step 6: 系统安全管理* 143 | - 如果出现重大异常，Guardian 可以通过 OptimismPortal 暂停系统操作，防止进一步损害。 144 | 145 | **资产操作（存款/提现）** 通过 **L1 Bridge**模块完成。 146 | 147 | **交易批次管理** 通过 **Batcher 和 Batch Inbox Address**实现。 148 | 149 | **跨层通信** 依靠 **L1CrossDomainMessenger**。 150 | 151 | **争议解决** 由 **FaultDisputeGame** 保障系统安全性。 152 | 153 | **系统安全** 由 **Guardian** 提供紧急保护 154 | 155 | ### 2025.01.09 156 | 157 | **Stage 0: Minimal Trust Assumptions（最小信任假设）** 158 | 159 | - Rollup 的安全性主要依赖 Layer 1（例如以太坊）的保障，但仍需要信任某些中心化的角色。 160 | - Sequencer（排序者）是中心化的，通常由单个实体控制。 161 | - 数据可用性完全依赖于 Layer 1。 162 | 163 | **Stage 1: Permissionless Validators（无许可验证者）** 164 | 165 | - 任何人都可以成为验证者，验证 Rollup 的交易和状态。 166 | - 通过引入争议解决机制（Fault Proof 或 Validity Proof）来确保数据的正确性。*验证者的加入无须许可，任何人都可以运行验证节点* 167 | - 数据验证和存储依然依赖 Layer 1。 168 | - 169 | **Stage 2: Full Decentralization（完全去中心化）** 170 | 171 | - Rollup 实现完全去中心化，Sequencer、验证者、数据存储都无需信任中心化实体。 172 | - Layer 2 生态具备独立性，最大化保障用户和开发者的权益。 173 | - *Sequencer 去中心化：允许多个 Sequencer 并行运行，解决单点故障问题。多个 Sequencer 通过共识机制协作排序交易。* 174 | 175 | **Optimism 当前所处阶段：Stage 0，Optimism 正在开发去中心化 Sequencer 和无许可验证机制，目标是逐步向 Stage 1 和 Stage 2 过渡。** 176 | **zkSync 已逐步接近 Stage 1，其 Validity Proof 系统允许无许可验证** 177 | **目前没有任何 Rollup 达到 Stage 2** 178 | 179 | **Rollup 如何依赖 Layer 1：** 180 | - Rollup 使用 Layer 1 作为最终的裁判。所有状态更新（如余额变化）都必须通过 Layer 1 的验证机制来确认。· 181 | - 如果 Rollup 层有任何问题（如 Sequencer 恶意操作），用户可以通过 Layer 1 上的数据恢复状态· 182 | 183 | **当前大多数 Rollup（如 Optimism 和 Arbitrum）使用单个中心化的 Sequencer。通常由一个公司或组织运行（例如 Optimism 的 Sequencer 是由 Optimism Foundation 控制的）。** 184 | 185 | **stage 0存在问题** 186 | - 验证交易和状态的机制（如Fault Proof）是由中心化团队维护，普通用户无法直接参与验证 187 | - Rollup 的治理（如升级智能合约或修改 Sequencer 配置）可能需要中心化团队进行人工操作，*但仍需要信任团队不会滥用权限。* 188 | 189 | ### 2025.01.10 190 | 191 | **治理理念旨在创建一个由社区、公司和公民共同参与的数字民主治理模式，称为 Optimism Collective**，**核心理念是Impact = Profit** 192 | 193 | **Optimism 采用双院制治理体系（Token House + Citizens' House）** 194 | - Token House：负责提交、讨论和投票各类治理提案。代币持有者可以直接投票，或将投票权委托给他人。 195 | - Citizens' House：基于声誉的“一人一票”治理实验。 负责追溯性公共产品资金（Retroactive Public Goods Funding，简称 Retro Funding）。该机制旨在奖励那些对集体和超级链（Superchain）产生积极影响的贡献者。 196 | 197 | 198 | ### 2025.01.11 199 | 200 | ### 2025.01.12 201 | 202 | **根据不同的提案类型确定不同的投票机制和否决机制** 203 | 204 | ### 2025.02.07 205 | 206 | 笔记内容 207 | 208 | ### 2024.07.12 209 | 210 | 211 | -------------------------------------------------------------------------------- /StarryDeserts_assets/代币议院和公民议院具体协作图示.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/IntensiveCoLearning/Optimism/3cd922710daa7d7c64a8cf1524512f82a78d2d12/StarryDeserts_assets/代币议院和公民议院具体协作图示.png -------------------------------------------------------------------------------- /Template.md: -------------------------------------------------------------------------------- 1 | --- 2 | timezone: Asia/Shanghai 3 | --- 4 | 5 | > 请在上边的 timezone 添加你的当地时区，这会有助于你的打卡状态的自动化更新，如果没有添加，默认为北京时间 UTC+8 时区 6 | > 时区请参考以下列表，请移除 # 以后的内容 7 | 8 | timezone: Pacific/Honolulu # 夏威夷-阿留申标准时间 (UTC-10) 9 | 10 | timezone: America/Anchorage # 阿拉斯加标准时间 (UTC-9) 11 | 12 | timezone: America/Los_Angeles # 太平洋标准时间 (UTC-8) 13 | 14 | timezone: America/Denver # 山地标准时间 (UTC-7) 15 | 16 | timezone: America/Chicago # 中部标准时间 (UTC-6) 17 | 18 | timezone: America/New_York # 东部标准时间 (UTC-5) 19 | 20 | timezone: America/Halifax # 大西洋标准时间 (UTC-4) 21 | 22 | timezone: America/St_Johns # 纽芬兰标准时间 (UTC-3:30) 23 | 24 | timezone: America/Sao_Paulo # 巴西利亚时间 (UTC-3) 25 | 26 | timezone: Atlantic/Azores # 亚速尔群岛时间 (UTC-1) 27 | 28 | timezone: Europe/London # 格林威治标准时间 (UTC+0) 29 | 30 | timezone: Europe/Berlin # 中欧标准时间 (UTC+1) 31 | 32 | timezone: Europe/Helsinki # 东欧标准时间 (UTC+2) 33 | 34 | timezone: Europe/Moscow # 莫斯科标准时间 (UTC+3) 35 | 36 | timezone: Asia/Dubai # 海湾标准时间 (UTC+4) 37 | 38 | timezone: Asia/Kolkata # 印度标准时间 (UTC+5:30) 39 | 40 | timezone: Asia/Dhaka # 孟加拉国标准时间 (UTC+6) 41 | 42 | timezone: Asia/Bangkok # 中南半岛时间 (UTC+7) 43 | 44 | timezone: Asia/Shanghai # 中国标准时间 (UTC+8) 45 | 46 | timezone: Asia/Tokyo # 日本标准时间 (UTC+9) 47 | 48 | timezone: Australia/Sydney # 澳大利亚东部标准时间 (UTC+10) 49 | 50 | timezone: Pacific/Auckland # 新西兰标准时间 (UTC+12) 51 | 52 | --- 53 | 54 | # {你的名字} 55 | 56 | 1. 自我介绍 57 | 58 | 2. 你认为你会完成本次残酷学习吗？ 59 | 60 | ## Notes 61 | 62 | 63 | 64 | ### 2025.01.06 65 | 66 | 笔记内容 67 | 68 | ### 2024.07.12 69 | 70 | 71 | -------------------------------------------------------------------------------- /Tianxibi-web3.md: -------------------------------------------------------------------------------- 1 | --- 2 | timezone: Asia/Shanghai 3 | --- 4 | 5 | > 请在上边的 timezone 添加你的当地时区，这会有助于你的打卡状态的自动化更新，如果没有添加，默认为北京时间 UTC+8 时区 6 | > 时区请参考以下列表，请移除 # 以后的内容 7 | 8 | timezone: Pacific/Honolulu # 夏威夷-阿留申标准时间 (UTC-10) 9 | 10 | timezone: America/Anchorage # 阿拉斯加标准时间 (UTC-9) 11 | 12 | timezone: America/Los_Angeles # 太平洋标准时间 (UTC-8) 13 | 14 | timezone: America/Denver # 山地标准时间 (UTC-7) 15 | 16 | timezone: America/Chicago # 中部标准时间 (UTC-6) 17 | 18 | timezone: America/New_York # 东部标准时间 (UTC-5) 19 | 20 | timezone: America/Halifax # 大西洋标准时间 (UTC-4) 21 | 22 | timezone: America/St_Johns # 纽芬兰标准时间 (UTC-3:30) 23 | 24 | timezone: America/Sao_Paulo # 巴西利亚时间 (UTC-3) 25 | 26 | timezone: Atlantic/Azores # 亚速尔群岛时间 (UTC-1) 27 | 28 | timezone: Europe/London # 格林威治标准时间 (UTC+0) 29 | 30 | timezone: Europe/Berlin # 中欧标准时间 (UTC+1) 31 | 32 | timezone: Europe/Helsinki # 东欧标准时间 (UTC+2) 33 | 34 | timezone: Europe/Moscow # 莫斯科标准时间 (UTC+3) 35 | 36 | timezone: Asia/Dubai # 海湾标准时间 (UTC+4) 37 | 38 | timezone: Asia/Kolkata # 印度标准时间 (UTC+5:30) 39 | 40 | timezone: Asia/Dhaka # 孟加拉国标准时间 (UTC+6) 41 | 42 | timezone: Asia/Bangkok # 中南半岛时间 (UTC+7) 43 | 44 | timezone: Asia/Shanghai # 中国标准时间 (UTC+8) 45 | 46 | timezone: Asia/Tokyo # 日本标准时间 (UTC+9) 47 | 48 | timezone: Australia/Sydney # 澳大利亚东部标准时间 (UTC+10) 49 | 50 | timezone: Pacific/Auckland # 新西兰标准时间 (UTC+12) 51 | 52 | --- 53 | 54 | # {田喜碧} 55 | 56 | 1. 我于今年开始接触 Web3，期间参与过 NFT 相关工作。我一直从事视觉设计工作，若社区有物料更新需求，我很乐意提供帮助。我期望能在边学边做中深入熟悉这个领域，进而为 LXDAO 贡献自己的力量。我还参加过在曼谷举办的 Devcon 以及 LXDAO Coordination Day 活动 57 | 58 | 2. 会认真学习并完成这次的残酷共学，补足自己在web3领域缺失的板块，希望通过这次学习能为组织的未来发展做出贡献。 59 | 60 | ## Notes 61 | 62 | 63 | 64 | ### 2025.01.06 65 | 66 | 关于Optimistic Rollup 67 | 1.理解 Optimistic Rollup 是如何依赖于以太坊等“父”区块链的安全性来运行的。 68 | 2.了解 Optimism 作为 Optimistic Rollup 的具体实现及其设计目标。 69 | 3.Optimism 是一种“Optimistic Rollup”，利用以太坊的共识机制，而不提供自己的机制 70 | 71 | ### 2025.01.07 72 | “纪元”和序列号标识，首个块包含对应L1块中的存款，以防排序器忽略合法交易 73 | 非合约池可和EIP-4844的blob格式在以太坊上存储L2区块，以降低交易成本。交易可以在直接提交或L1上提交的存款两种方式到达排序器，通过L2“纪元”和序列号标识，首个块包含对应L1块中的存款，以防排序器忽略合法交易。乐观基金是在OP Mainnet对区块生产的控制。 74 | 75 | ### 2025.01.08 76 | 块执行：通过与其他执行引擎的对等网络同步状态，能够有效地处理块，同时利用以太坊的安全性。 77 | 层间桥接：设计允许用户在 L2 和 L1 之间发送任意消息，实现 ETH 或代币的转移。在 OP Mainnet 中使用，允许代币从以太坊存入 OP Mainnet ，并从 OP Mainnet 提取回以太坊，相互切换。 78 | 以太坊迁移至 OP 主网：从以太坊 L1 到 OP 主网 L2 的交易，在交易中形成规范区块链的一部分。 79 | OP 主网迁移至以太坊：提款过程确保了用户在 OP 主网和以太坊之间安全地转移资产，通过链下监控和故障挑战机制，增强了提款的安全性和可靠性。 80 | 81 | ### 2025.01.09 82 | 在 Optimistic Rollup 中，状态承诺发布到 L1（如以太坊），无需有效性证明。承诺在 7 天的“挑战窗口”内待定，若无质疑则视为最终承诺，最终承诺后，以太坊智能合约可安全接受提款证明。 83 | 若承诺被质疑，可通过“过错证明”使其无效，成功挑战后将被替换，挑战不会回滚 OP Mainnet，仅影响状态承诺，交易顺序和状态不变，因 EVM 等效性，故障验证流程正在重大更新。 84 | 85 | ### 2025.01.10 86 | 了解了以太坊当前的价格、区块gas上限、gas费用和平均出块时间，这些因素影响交易的效率和成本。认识到ZK Rollup在ETH转账和ERC20代币转账中的显著扩展性优势，尤其是在高并发交易时的表现。认识到ZK Rollup和Optimistic Rollup在以太坊生态系统中的重要性及其对提高交易效率和降低成本的影响，这些知识对理解去中心化金融（DeFi）和NFT等领域的应用非常有帮助。 87 | 88 | ### 2025.01.11 89 | 1.验证者需支付以太坊 gas 来验证 SNARK。每笔交易额外支付约 0.4k gas 来发布状态 ，这部分成本是变量，取决于以太坊网络当前的 gas 价格，相较于普通 ETH/ERC20 转账，链上部分的成本便宜几个数量级。 90 | 2.ZK Rollup 的交易地板价依赖于以太坊主网的 gas 费用。使用 ZK Rollup 的频率越高，费用越低，用户的状态数更新越多，ZK 支付给 Layer 1 的 gas 费用相对变少，但并未平摊至用户。 91 | 交易地板价与ETH主网的calldata费用密切相关，Calldata费用是指在以太坊网络中，用户在执行交易或调用智能合约时，所需支付的费用，特别是与数据传输相关的费用，直接影响智能合约的调用和Layer 2解决方案的经济性。通过降低这些费用，可以提高以太坊网络的可扩展性和用户体验，对Layer 2的TPS（每秒交易量）影响显著，有利于Layer 2的Rollup。 92 | 3.zkSync支持用户交易DAI稳定币时，用户无需持有ETH或其他代币，只需支付一小部分DAI作为费用。 93 | 94 | ### 2025.01.13 95 | ZK Rollup：具有链上数据可用性。 96 | zkPorter：具有链下数据可用性。 97 | 这两部分可组合和互操作，ZK Rollup 端的合约和账户可以与 zkPorter 端的账户无缝交互。 98 | zkPorter 账户的数据可用性由 zkSync 代币持有者（监护人）保护。zkSync 的 PoS 比其他系统更安全，监护人无法窃取资金，只能冻结 zkPorter 状态。 99 | 用户角度：zkPorter 账户的费用减少了 100 倍。例如：zkPorter 账户可以以低于 0.03 美元的费用进行交换。 100 | 101 | ### 2025.01.14 102 | 用户在 Optimism 上的交易需要支付与计算和存储相关的 gas 费用。 103 | 所有 Optimism 上的交易都需要发布到以太坊，称为 L1 数据费用，Optimism 的交易成本主要由 L2 执行费和 L1 数据费组成，这是 Optimism 与以太坊之间的主要差异，以太坊的 gas 成本较高，L1 数据费用通常占交易总成本的主要部分。 104 | 105 | ### 2025.01.15 106 | 随着越来越多的应用程序（如DeFi、NFT、DAO）接入区块链，用户采用和交易量将呈指数级增长，Layer 2是目前以太坊扩展的最佳解决方案，提供高吞吐量和更低费用，同时利用Layer 1的安全性。 107 | zk Rollup：交易费用最低，部分或极限TPS更快，最大扩展性得到显著提高，并且安全性有保障。 108 | zkporter：次于zk Rollup，其他解决方案的交易费用有所降低，但仍不及zk Rollup。 109 | 110 | ### 2025.01.16 111 | Rollup的开发通常经历一个集中控制阶段，称为“训练轮”，以便在受控环境中进行系统更新和错误修复. 112 | 新框架的引入 113 | 第0阶段：Rollup由操作员有效运行，使用源可用软件根据L1上发布的数据重建状态，以便比较状态根与提议的根。 114 | 第1阶段：Rollup过渡到由智能合约管理，可能保留安全委员会以解决潜在错误。 115 | 第2阶段：Rollup完全由智能合约管理，防欺诈系统无需许可，用户有充足时间在不必要的升级时退出，安理会的角色限于解决可以在链上裁决的健全性错误，并保护用户免受治理攻击。 116 | 117 | ### 2025.01.17 118 | 每个阶段的具体要求和条件 119 | 0 阶段要求：L2 状态根的发布必须在 L1 上发布状态根，以支持提现功能，提供能够重建 L2 状态的 Rollup 节点软件，增强透明度和信任度。 120 | 第一阶段的要求：项目需要使用证明系统来验证状态根的正确性，至少需要 5 位外部参与者能够提交欺诈证明，用户应能在没有运营商协调的情况下独立提款，用户若不同意不想要的升级，需至少有 7 天的时间退出，安全委员会需由至少 8 名参与者组成，并设定 50% 的共识门槛，确保多样性和透明度。 121 | 第 2 阶段要求：欺诈证明系统应完全开放，任何人都可以提交证明，用户在不想要的升级情况下，需至少有 30 天的时间退出，安理会的干预应限制在检测到链上错误的情况下，以增强系统去中心化和降低对安理会的信任需求。 122 | 123 | ### 2025.01.19 124 | 超级链产品实现去中心化和可组合性，和确保超级链的安全性，通过治理促进增长和发展。 125 | 影响=利润：影响与利润同等重要的关系，创建一个人人受益的互联网。奖励影响力，称为未来的以太凤凰。 126 | 疑问：查看了“以太凤凰”的资料，可以理解为“以太凤凰”是建立一个支持公共物品的系统吗？ 127 | 128 | ### 2025.01.20 129 | 治理方法：是由乐观主义集体和超级链采用实验性和敏捷的方法，强调持续迭代，以建立一个持久的系统。 130 | 治理结构：集体的数字民主治理模式由代币院和公民院组成，形成两院制治理体系，避免代币治理中的常见问题，并实现相互制衡。 131 | 代币之家： 132 | 1.乐观集体的治理从 OP 代币和代币之家的推出开始。 133 | 2.OP 持有者作为代币之家成员，负责提交、审议和投票治理提案。 134 | 3.OP 持有者可以选择直接投票或将投票权委托给他人。 135 | 4.代币之家对操作手册中列出的提案类型进行投票。 136 | 公民之家： 137 | 1.公民之家是一项基于声誉的一人一票治理的大规模实验，负责追溯性公共物品资助（追溯资助）。 138 | 2.追溯基金是集体的主要经济引擎，旨在奖励在集体和超级链中产生积极影响的人，就过去有用的事物达成一致比就未来可能有用的事物达成一致更容易。 139 | 疑问：不是很明白未来轮次的概念 140 | 141 | ### 2025.01.21 142 | 代币之家和公民之家通过分工合作推动集体愿景的实现，体现了组织内部协作的重要性。 143 | 通过去中心化里程碑模型和决策图模型，可以更好地理解如何规划和推进去中心化治理，确保每个阶段的工作有明确方向。去中心化模型和决策图模型提供了方向性指导，而不是固定的规则，强调了治理设计的灵活性和适应性。 144 | 145 | ### 2025.01.22 146 | 乐观治理的主要工具： 147 | Token House 治理合约：用于链上投票的合约，所有符合条件的 Token House 提案都在此提交投票。 148 | Optimism 治理门户：前端界面，帮助 Token House 成员委托和投票 OP。 149 | 公民院快照空间：公民院成员投票提案的前端界面。 150 | 乐观论坛：讨论和审议治理建议的平台。 151 | Discord：非正式治理讨论和反馈的渠道。 152 | Github：用于管理资助任务的公共仓库。 153 | Charmverse：社区主导的乐观资助委员会所在地。 154 | 155 | 治理工具的动态发展： 156 | 工具和用途可能随时间演变，例如： 157 | 开发新的用户界面，专注于治理委员会的需求。 158 | 当前投票由治理合约在链上进行，但成功的投票由 Optimism 基金会实施，这种集中化管理未来可能会改变。 159 | 160 | 乐观治理工具包通过链上合约、前端界面和社区互动平台的结合，实现了高效的治理支持，同时展现了治理工具的动态发展和去中心化目标的逐步推进。 161 | 162 | -------------------------------------------------------------------------------- /amandakelake.md: -------------------------------------------------------------------------------- 1 | --- 2 | timezone: Asia/Shanghai 3 | --- 4 | 5 | > 请在上边的 timezone 添加你的当地时区，这会有助于你的打卡状态的自动化更新，如果没有添加，默认为北京时间 UTC+8 时区 6 | > 时区请参考以下列表，请移除 # 以后的内容 7 | 8 | timezone: Asia/Shanghai 9 | 10 | --- 11 | 12 | # amandakelake 13 | 14 | 1. 自我介绍 15 | 16 | 大家好，我是LGC，对OP比较感兴趣，希望通过这次共学，理解和认识 Optimism 的生态和相关信息知识，加深对 layer2 的理解 17 | 18 | 2. 你认为你会完成本次残酷学习吗？ 19 | 20 | 会的！ 21 | 22 | ## Notes 23 | 24 | 25 | 26 | ### 2025.01.06 27 | 28 | #### Layer2 29 | 30 | ##### layer2基础概念 31 | [What is layer 2?](https://ethereum.org/zh/layer-2/learn/) 32 | 区块链有三个理想属性：decentralized、secure、scalable （三元悖论） 33 | 34 | ==The main goal of scalability is to increase transaction speed (faster finality), and transaction throughput (high transactions per second), without sacrificing decentralization or security== 35 | 36 | 以太坊当前面临的问题：低吞吐量（每秒15~30笔交易）、高gas费用、用户体验差。Layer2 的目标是通过将交易从主链转移到 Layer2 网络来解决这些问题 37 | 38 | [What is layer 2?](https://ethereum.org/zh/layer-2/learn/) 39 | https://vitalik.eth.limo/general/2021/01/05/rollup.html Vitalik 详细解释了 Rollup 技术，包括 Optimistic Rollup 和 ZK-Rollup 的区别 40 | 41 | ##### L2技术类型 42 | 43 | * rollup 44 | * Optimistic rollups：乐观汇总，使用欺诈证明 45 | * ZK rollups：使用有效性证明 46 | * state channels （状态通道） 47 | * plasma 48 | 49 | #### **OP Stack Overview** 50 | 51 | [Vision - Optimism Official Blog](https://optimism.io/vision) 52 | [Getting started with the OP Stack](https://docs.optimism.io/stack/getting-started) 53 | 54 | The OP Stack is development stack thats powers Optimism，as Optimism evolves，so will the OP Stack. 55 | 56 | Optimism Bedrock is the current iteration of the OP Stack. 57 | 58 | The OP Stack of today was built to support [the Optimism Superchain](https://docs.optimism.io/superchain/superchain-explainer) (a proposed network of L2s) 59 | 60 | ##### OP Rollup 61 | [OP Rollup 扩容方案](https://docs.optimism.io/stack/rollup/overview) 62 | 63 | * 区块存储：L2 区块保存到以太坊区块链中的一个非合约地址中`0xff00000000000000000000000000000000000010`，借此来降低L1 gas费用 64 | * 区块是EIP-4844 blob 提交，无法修改或审查，这就是 OP Mainnet 继承以太坊的可用性和完整性保证的方式 65 | * 区块生产：由`sequencer`单一管理 66 | * **Fault proofs** （故障证明）：challenge window持续7天 67 | 68 | ### 2025.01.07 69 | 70 | #### Layer2 解决方案对比 71 | 72 | 由于以太坊网络拥堵导致 gas fee 大幅上涨（每秒 15～30 笔交易），Layer2 的解决方案目前主要聚焦在解决网络面临的低效率问题，同时仍能保持以太坊区块链的完整性 73 | 74 | 目前主要有四种技术方案：Optimistic Rollup、ZK Rollup、Plasma、Validium 75 | 76 | * ZK Rollup 和 Optimistic Rollup 都是将交易数据压缩后存储在主链上，通过主链验证交易的有效性，从而实现扩容 77 | * Plasma 和 Validium 则是将交易数据存储在链下，通过主链验证交易的有效性，从而实现扩容 78 | 79 | 普通转账 ETH 需要字节数 112 左右，ZK 压缩为 12个字节，OP 系压缩为 78.4 左右 80 | 81 | #### Gas 费用 82 | 83 | * ZK Sync 每笔交易的成本由 2 个部分组成 84 | * 链下部分（存储+证明者成本）：状态存储和 SNARK（零知识证明）生成的成本（这部分依赖于硬件资源的使用，因此是不变的。我们的基准估计每次转账约为 0.001 美元。） 85 | * 链上部分（GAS 成本）：对于每个zkSync 区块，验证者必须支付以太坊 gas 来验证 SNARK，另外每笔交易额外支付约 0.4k gas 来发布状态（链上部分是一个变量，取决于以太坊网络中当前的 gas 价格。但是，这部分比普通 ETH/ERC20 转账的成本要便宜几个数量级。） 86 | 87 | * Optimistic Rollup 每笔交易的成本由L2 执行费和L1 数据费组成 88 | * L2 执行费：每笔 L2 交易都会支付一定的 执行费用 （等同于以太坊的收费方式） 89 | * L1 数据费：Optimism 上的所有交易也都发布到以太坊，此步骤对于 Optimism 的安全属性至关重要，因为这意味着同步 Optimism 节点所需的所有数据始终在以太坊上公开可用（受以太坊当前的gas价格影响） 90 | 91 | [一文了解Layer2的四大解决方案交易成本对比](https://learnblockchain.cn/article/3703#4、optimism%20Gas%20机制) 92 | 93 | 94 | -------------------------------------------------------------------------------- /brucexu-eth_assets/image-1.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/IntensiveCoLearning/Optimism/3cd922710daa7d7c64a8cf1524512f82a78d2d12/brucexu-eth_assets/image-1.png -------------------------------------------------------------------------------- /brucexu-eth_assets/image-2.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/IntensiveCoLearning/Optimism/3cd922710daa7d7c64a8cf1524512f82a78d2d12/brucexu-eth_assets/image-2.png -------------------------------------------------------------------------------- /brucexu-eth_assets/image-3.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/IntensiveCoLearning/Optimism/3cd922710daa7d7c64a8cf1524512f82a78d2d12/brucexu-eth_assets/image-3.png -------------------------------------------------------------------------------- /brucexu-eth_assets/image-4.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/IntensiveCoLearning/Optimism/3cd922710daa7d7c64a8cf1524512f82a78d2d12/brucexu-eth_assets/image-4.png -------------------------------------------------------------------------------- /brucexu-eth_assets/image-5.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/IntensiveCoLearning/Optimism/3cd922710daa7d7c64a8cf1524512f82a78d2d12/brucexu-eth_assets/image-5.png -------------------------------------------------------------------------------- /brucexu-eth_assets/image.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/IntensiveCoLearning/Optimism/3cd922710daa7d7c64a8cf1524512f82a78d2d12/brucexu-eth_assets/image.png -------------------------------------------------------------------------------- /btcnice.md: -------------------------------------------------------------------------------- 1 | --- 2 | timezone: Asia/Shanghai 3 | --- 4 | 5 | > 请在上边的 timezone 添加你的当地时区，这会有助于你的打卡状态的自动化更新，如果没有添加，默认为北京时间 UTC+8 时区 6 | > 时区请参考以下列表，请移除 # 以后的内容 7 | 8 | timezone: Pacific/Honolulu # 夏威夷-阿留申标准时间 (UTC-10) 9 | 10 | timezone: America/Anchorage # 阿拉斯加标准时间 (UTC-9) 11 | 12 | timezone: America/Los_Angeles # 太平洋标准时间 (UTC-8) 13 | 14 | timezone: America/Denver # 山地标准时间 (UTC-7) 15 | 16 | timezone: America/Chicago # 中部标准时间 (UTC-6) 17 | 18 | timezone: America/New_York # 东部标准时间 (UTC-5) 19 | 20 | timezone: America/Halifax # 大西洋标准时间 (UTC-4) 21 | 22 | timezone: America/St_Johns # 纽芬兰标准时间 (UTC-3:30) 23 | 24 | timezone: America/Sao_Paulo # 巴西利亚时间 (UTC-3) 25 | 26 | timezone: Atlantic/Azores # 亚速尔群岛时间 (UTC-1) 27 | 28 | timezone: Europe/London # 格林威治标准时间 (UTC+0) 29 | 30 | timezone: Europe/Berlin # 中欧标准时间 (UTC+1) 31 | 32 | timezone: Europe/Helsinki # 东欧标准时间 (UTC+2) 33 | 34 | timezone: Europe/Moscow # 莫斯科标准时间 (UTC+3) 35 | 36 | timezone: Asia/Dubai # 海湾标准时间 (UTC+4) 37 | 38 | timezone: Asia/Kolkata # 印度标准时间 (UTC+5:30) 39 | 40 | timezone: Asia/Dhaka # 孟加拉国标准时间 (UTC+6) 41 | 42 | timezone: Asia/Bangkok # 中南半岛时间 (UTC+7) 43 | 44 | timezone: Asia/Shanghai # 中国标准时间 (UTC+8) 45 | 46 | timezone: Asia/Tokyo # 日本标准时间 (UTC+9) 47 | 48 | timezone: Australia/Sydney # 澳大利亚东部标准时间 (UTC+10) 49 | 50 | timezone: Pacific/Auckland # 新西兰标准时间 (UTC+12) 51 | 52 | --- 53 | 54 | # Felix.Chen 55 | 56 | 1. 散修初级程序员 57 | 58 | 2. 你认为你会完成本次残酷学习吗？ 59 | 应该能行 60 | 61 | ## Notes 62 | 63 | 64 | 65 | ### 2025.01.06 66 | 67 | 笔记内容 68 | 69 | ### 2024.07.12 70 | 71 | 72 | -------------------------------------------------------------------------------- /bxmyzzbc.md: -------------------------------------------------------------------------------- 1 | --- 2 | timezone: Asia/Shanghai 3 | --- 4 | 5 | > 请在上边的 timezone 添加你的当地时区，这会有助于你的打卡状态的自动化更新，如果没有添加，默认为北京时间 UTC+8 时区 6 | > 时区请参考以下列表，请移除 # 以后的内容 7 | 8 | timezone: Pacific/Honolulu # 夏威夷-阿留申标准时间 (UTC-10) 9 | 10 | timezone: America/Anchorage # 阿拉斯加标准时间 (UTC-9) 11 | 12 | timezone: America/Los_Angeles # 太平洋标准时间 (UTC-8) 13 | 14 | timezone: America/Denver # 山地标准时间 (UTC-7) 15 | 16 | timezone: America/Chicago # 中部标准时间 (UTC-6) 17 | 18 | timezone: America/New_York # 东部标准时间 (UTC-5) 19 | 20 | timezone: America/Halifax # 大西洋标准时间 (UTC-4) 21 | 22 | timezone: America/St_Johns # 纽芬兰标准时间 (UTC-3:30) 23 | 24 | timezone: America/Sao_Paulo # 巴西利亚时间 (UTC-3) 25 | 26 | timezone: Atlantic/Azores # 亚速尔群岛时间 (UTC-1) 27 | 28 | timezone: Europe/London # 格林威治标准时间 (UTC+0) 29 | 30 | timezone: Europe/Berlin # 中欧标准时间 (UTC+1) 31 | 32 | timezone: Europe/Helsinki # 东欧标准时间 (UTC+2) 33 | 34 | timezone: Europe/Moscow # 莫斯科标准时间 (UTC+3) 35 | 36 | timezone: Asia/Dubai # 海湾标准时间 (UTC+4) 37 | 38 | timezone: Asia/Kolkata # 印度标准时间 (UTC+5:30) 39 | 40 | timezone: Asia/Dhaka # 孟加拉国标准时间 (UTC+6) 41 | 42 | timezone: Asia/Bangkok # 中南半岛时间 (UTC+7) 43 | 44 | timezone: Asia/Shanghai # 中国标准时间 (UTC+8) 45 | 46 | timezone: Asia/Tokyo # 日本标准时间 (UTC+9) 47 | 48 | timezone: Australia/Sydney # 澳大利亚东部标准时间 (UTC+10) 49 | 50 | timezone: Pacific/Auckland # 新西兰标准时间 (UTC+12) 51 | 52 | --- 53 | 54 | # {你的名字} yuhui 55 | 56 | 1. 自我介绍 newcomer 57 | 58 | 2. 你认为你会完成本次残酷学习吗？ 会的 59 | 60 | ## Notes 61 | 62 | 63 | 64 | ### 2025.01.06 65 | 66 | 笔记内容 67 | 68 | ### 2024.07.12 69 | 70 | 71 | -------------------------------------------------------------------------------- /chendafu2573.md: -------------------------------------------------------------------------------- 1 | --- 2 | timezone: Asia/Shanghai 3 | --- 4 | 5 | 6 | 7 | --- 8 | 9 | # {chendafu} 10 | 11 | 1. 自我介绍 12 | 新手 13 | 2. 你认为你会完成本次残酷学习吗？ 14 | 会 15 | ## Notes 16 | 17 | 18 | 19 | ### 2025.01.06 20 | 21 | 笔记内容 22 | Layer 2 扩容：Optimism 通过在以太坊主链之外运行智能合约，实现了扩容和降低 Gas 费用的能力。 23 | Optimistic Rollups：Optimism 使用了一种称为 Optimistic Rollups 的技术，允许将多个交易聚合成一个批次，并在链下执行，这样可以显著提高交易速度和降低成本。 24 | sequencer：Optimism 使用一个称为 Sequencer 的组件来聚合和排序交易，然后将它们提交到链上。 25 | 验证者：Optimism 允许任何人成为验证者，验证交易的正确性并确保 Sequencer 的行为。 26 | 以太坊主链：Optimism 的状态根（state root）被提交到以太坊主链上，确保了 Optimism 链的安全性和去中心化性。 27 | EVM 兼容：Optimism 支持以太坊虚拟机（EVM），这意味着以太坊上的智能合约可以无缝迁移到 Optimism 链上 28 | Optimistic Rollups：Optimism 使用了一种为 Optimistic Rollups的技术。这种技术通过将多个交易打包成一個批次，并会在二层进行处理，然后将结果提交到主网上。这样减少的交易量，提高了效率用户也降低了gas的费用能力。 29 | ### 2025.01.07 30 | 我以为没会议就不打卡 31 | ### 2025.01.08 32 | 补打 33 | ### 2025.01.09 34 | 打卡签到，今后按时参加会议查看书签 35 | ### 2025.01.10 36 | 打卡 37 | ### 2025.01.10 38 | 缺席 39 | ### 2025.01.12 40 | 打卡 41 | ### 2025.01.13 42 | 缺席 43 | ### 2025.01.14 44 | 打卡 45 | ### 2025.01.15 46 | ### 2025.01.16 47 | ### 2025.01.17 48 | ### 2025.01.18 49 | ### 2024.07.12 50 | 51 | 52 | -------------------------------------------------------------------------------- /cherry-yl-sh.md: -------------------------------------------------------------------------------- 1 | --- 2 | timezone: Asia/Shanghai 3 | --- 4 | --- 5 | 6 | # Dylanyang 7 | 8 | 1. 自我介绍 9 | dylanyang 全栈开发 10 | 11 | 2. 你认为你会完成本次残酷学习吗？ 12 | 会完成，通过学习更深入的了解 Optimism 13 | 14 | ## Notes 15 | 16 | 17 | 18 | ### 2025.01.06 19 | 20 | 笔记内容 21 | 22 | ### 2025.01.07 23 | op基础知识学习 24 | 25 | 26 | -------------------------------------------------------------------------------- /debugzhao.md: -------------------------------------------------------------------------------- 1 | --- 2 | timezone: Asia/Shanghai 3 | --- 4 | 5 | # Tyson 6 | 7 | 1. web3 newcomer，受够了web2枯燥的CRUD工作，共同进步共同成长。 8 | 2. 一定会的！ 9 | 10 | ## Notes 11 | 12 | 13 | 14 | ### 2025.01.06 15 | 16 | #### 区块链层级介绍 17 | 18 | 区块链技术能够实现去中心化、安全可靠的数据存储和交易。区块链技术由多个层级组成，每个层级都有其特定的目的和功能。包括Layer1、Layer2 和 Layer3。 19 | 20 | - layer1 21 | 22 | Layer1 是区块链的基础层，它负责处理区块链网络中的所有交易和数据存储。例如，比特币、莱特币和以太坊都是 Layer1 区块链。 23 | 24 | Layer1 区块链通常采用**共识算法**来实现分布式共识。这些共识算法包括**`工作量证明`**（Proof of Work, PoW）、`权益证明`（Proof of Stake, PoS）和`委托权益证明`（Delegated Proof of Stake, DPoS）等。 25 | 26 | - layer2 27 | 28 | Layer2 是建立在 Layer1 区块链之上的第三方协议，**旨在提高区块链网络的性能**。它通过智能合约设计的规则进行**`仲裁`**，以经济激励的形式将信任传递到 Layer2。 29 | 目前常见的 Layer2 解决方案包括**`状态通道`**（State Channels）、**`侧链`**（Sidechains）、**`等离子体`**（Plasma）和 **`Roll Up`** 等。这些解决方案都旨在通过在**链下进行交易来提高区块链网络的性能**。 30 | 31 | - layer3 32 | 33 | Layer3 代表了基于区块链的应用程序，例如去中心化金融（DeFi）应用、游戏或分布式存储应用。这些应用程序通常建立在 Layer1 和 Layer2 的基础之上，并利用区块链技术实现安全可靠的数据存储和交易。 34 | 35 | #### Layer1难以扩容的问题 36 | 37 | Layer 1网络普遍存在**难以扩容**的问题。面对日益增长的交易需求，比特币和其他大型区块链都在力图加快交易的处理速度。比特币使用的工作量证明(PoW)共识机制需要大量计算资源。PoW兼顾了去中心化和安全性，但在交易高峰期，网络运行速度仍会下降，从而导致交易确认时间延长，费用上涨。 38 | 39 | 多年以来，区块链开发人员一直在研究可拓展性解决方案，但是至今仍未就最优替代方案达成一致。Layer 1扩容的可选方案包括： 40 | 41 | - 扩大区块规模，使每个区块能够处理更多交易。 42 | 43 | - 更改共识机制。即将上线的以太坊2.0版本就采用了这一方案。 44 | 45 | - 实施分片 46 | 47 | 分片是一种常见的Layer 1扩展解决方案，可用于增加交易的吞吐量。这是一种数据库分割技术，可以应用于区块链的分布式账本。**网络连同上面的节点一起被分割成不同的分片，以此平摊工作量并提升交易速度。**每个分片处理整个网络的一部分活动，即每个分片都有自己负责的交易、自己的节点和独立的区块。 48 | 分片后，无需在每个节点上保存完整的区块链副本。每个节点会将完成的工作写入主链，实时共享本地数据，包括地址余额和其他关键参数。 49 | 50 | 改进Layer 1需要大费一番周折。很多情况下，不是所有网络用户都会同意这样的变更。这么做可能会导致社区分裂，甚至发生硬分叉。2017年比特币分裂出比特币现金就是**`硬分叉`**的后果。 51 | 52 | Layer 1存在一些无法突破的瓶颈。由于受到技术限制，区块链主网很难或几乎不可能实施某些变更。例如，以太坊正在升级过渡到权益证明(PoS)系统，但是整个流程已耗时数年。 53 | 由于可扩展性问题，Layer 1本身并不适合某些用例。比特币网络的交易流程耗时过长，现实中不可能在网络上运行任何区块链游戏。但是，游戏的开发人员可能仍然想利用Layer 1的安全性和去中心化属性。那么，**最佳办法就是在这一网络上构建Layer 2解决方案**。 54 | 55 | #### 什么是Layer2？ 56 | 57 | Layer 2（第二层）是指在区块链技术和网络协议中用于扩展基础区块链（Layer 1）的解决方案。**其目的是提高交易速度、降低交易费用，并增强网络的可扩展性和效率**。Layer 2 通过在**主链之外处理大量交易，然后将结果批量提交到主链**，从而减轻主链的负担。以下是 Layer 2 的一些关键特点和技术： 58 | 59 | - 扩展性 60 | 61 | Layer 2 解决方案可以处理更多的交易量，从而缓解 Layer 1（如以太坊和比特币）上的拥堵问题。 62 | 63 | - 成本降低 64 | 65 | 通过在链下处理交易，Layer 2 可以显著降低用户的交易费用。 66 | 67 | - 提高速度 68 | 69 | 由于交易不需要在主链上逐一确认，Layer 2 可以大幅提高交易处理速度。 70 | 71 | - 安全性 72 | 73 | 尽管交易在链下处理，但 Layer 2 解决方案仍依赖于主链的安全性来保证最终的交易结果是可信和不可篡改的。 74 | 75 | ##### Layer2解决方案 76 | 77 | - 状态通道 78 | 79 | 这种方法允许两方或多方在链下进行多次交易，只在交易结束时将最终状态提交到区块链。一个典型的例子是闪电网络（Lightning Network），主要用于比特币。 80 | 81 | - 侧链 82 | 83 | 侧链是一条独立的区块链，使用其自身的共识机制，但通过双向锚定与主链（母链）连接。侧链可以自由地实现不同的功能和优化，同时主链依旧保持其主要的安全和稳定性。 84 | 85 | - Rollups 86 | 87 | Rollups 通过将大量交易打包到一个单一交易中，并将其提交到主链。这种方法可以分为两种类型：乐观 Rollups（Optimistic Rollups）和零知识 Rollups（zk-Rollups）。 88 | 89 | - Op Rollups 90 | 91 | 假设交易是有效的，只有在有争议时才进行验证 92 | 93 | - Zk Rollups 94 | 95 | 通过零知识证明技术，在提交交易数据的同时，保证其正确性。 96 | 97 | - Plasma 98 | 99 | Plasma 是一种框架，允许创建多层的子链结构，每层都可以处理大量的交易。尽管其理论基础较强，但在实际应用中面临一定的挑战。 100 | 101 | ##### 闪电网络 102 | 103 | 闪电网络就是一个著名的示例。在流量高峰期要花费数小时才能在比特币网络上完成一笔交易。而闪电网络允许用户在主链下使用比特币进行快速支付，稍后再将余额提交至主链。这样可以将所有人的交易汇总成一份最终记录，从而节省时间和资源。 104 | 105 | #### Optimistic rollups 106 | 107 | Optimistic Rollups 是一种扩展以太坊网络的 Layer 2 解决方案，通过在 Layer 2 处理大部分计算和交易，同时利用以太坊的安全性来验证这些交易。其核心特点包括： 108 | 109 | - 通过乐观假设提高效率： 110 | 111 | 默认假设交易是有效的，只在必要时运行欺诈证明（Fraud Proof）来验证交易的正确性。 112 | 113 | 减少了重复计算，提升了吞吐量和效率。 114 | 115 | - 安全性依赖以太坊 116 | 117 | Optimistic Rollups 的安全性建立在以太坊 Layer 1 的基础上。所有 Layer 2 的状态都被提交到以太坊，确保数据可用性和抗审查性。 118 | 119 | - 欺诈证明机制 120 | 121 | 提供了一种仲裁机制，允许用户对不正确的交易进行仲裁，如果交易被发现无效，系统将回滚并修正状态。 122 | 123 | - 数据可用性 124 | 125 | 所有交易数据都发布到以太坊 Layer 1，以确保任何人都可以独立验证 Rollup 的状态。 126 | 127 | - 适用场景 128 | 129 | Optimistic Rollups 适合 DeFi 等需要较高安全性和较低交易费用的应用。 130 | 131 | #### ref 132 | 133 | - [区块链层级layer0，layer1，layer2，layer3？](https://juejin.cn/post/7255475756322979897) 134 | - [什么是区块链中的Layer 1？](https://academy.binance.com/zh/articles/what-is-layer-1-in-blockchain) 135 | - [Layer2 的基本概念和主流项目分析](https://learnblockchain.cn/article/8163) 136 | 137 | ### 2025.01.07 138 | 139 | 以太坊目前的账户体系分为外部账户（EOA）和合约账户（CA），其中 EOA 功能简单但限制较多，而 CA 尽管功能强大，但使用复杂且门槛较高。账户抽象通过引入智能合约和统一入口机制，旨在改善用户体验，弥补传统账户体系的不足。 140 | 141 | EIP-4337 的核心机制包括一个名为 **EntryPoint** 的合约，用于处理账户抽象逻辑；**UserOperation** 对象作为标准化的交易数据结构；以及 **Bundler（捆绑器）**，用于聚合多个用户操作以提高性能。这些机制共同实现了灵活的 Gas 费支付方式、支持多签名与权限管理、提供账户恢复功能、以及优化 dApp 交互体验的目标。例如，用户可以使用 ERC-20 代币支付 Gas，设置更复杂的权限规则，或通过社交账号操作钱包。 142 | 143 | 账户抽象带来了诸多优势，例如降低 Web3 使用门槛、增强安全性、提供更强的账户功能和简化开发者与用户之间的交互。然而，它也面临技术复杂性、安全风险以及生态推广难度等挑战。尽管如此，EIP-4337 已经在链游、DeFi 和社交钱包等场景中展现出广泛的应用潜力，为以太坊生态的未来发展奠定了坚实基础。 144 | 145 | ### 2025.01.08 146 | 147 | **Stages** 的框架，用于评估 **Rollups** 技术的成熟度。Stage提供一个系统化的方法来衡量不同 **Layer 2 Rollups** 的发展阶段，以便开发者、投资者和区块链生态系统的其他参与者可以更好地了解每个 Rollup 的进展、风险和潜力。 148 | 149 | 随着以太坊的 **Layer 2** 解决方案不断发展，Rollup 技术逐渐成为主流，它们承载着大量交易并向以太坊主链提供扩展性。然而，不同的 Rollup 项目在技术实现和安全性方面存在差异，因此，如何评估这些项目的成熟度变得尤为重要。为了填补这一空白，**Stages** 框架应运而生。 150 | 151 | **Stages 框架的目的** 152 | 153 | **Stages** 框架的目的是通过量化 Rollups 的发展阶段，为开发者和社区提供一套标准化的衡量工具。框架依据不同的标准对 Rollups 进行评分，进而评估它们的成熟度和可靠性。文章特别指出，Rollups 在从 **实验性** 阶段向 **成熟商业化** 阶段过渡时面临不同的挑战和机遇，因此框架提供了不同的发展阶段划分。 154 | 155 | **框架的结构** 156 | 157 | 框架将 Rollups 的发展分为以下几个阶段： 158 | 159 | **Stage 0：实验性阶段** 160 | 161 | 这个阶段的 Rollup 项目通常处于试验阶段，尚未广泛投入生产环境。技术尚不成熟，存在较高的风险和不确定性，主要用于研究和原型验证。 162 | 163 | **Stage 1：测试阶段** 164 | 165 | Rollup 进入测试阶段，进行一定规模的实验验证。虽然它们可能在小范围内成功运行，但依然存在许多技术不确定性和潜在的安全问题。开发者正在测试其扩展性和可操作性。 166 | 167 | **Stage 2：早期生产阶段** 168 | 169 | Rollup 开始进入较为稳定的生产环境，并在一些真实的交易中发挥作用。此时，它们的扩展性和稳定性有所提高，但依然可能存在不小的风险，尤其是在处理大量交易时。 170 | 171 | **Stage 3：成熟阶段** 172 | 173 | Rollup 技术在这个阶段已获得广泛认可并成功应用于生产环境。它们具有较高的可用性、可靠性和扩展性，已解决大部分安全性和性能问题，能够承载大量交易。 174 | 175 | **Stage 4：商业化阶段** 176 | 177 | 这是 Rollup 技术发展的最终阶段，已经完全成熟并投入到商业应用中。它们能够处理复杂的应用场景，且具备高水平的安全性、低成本和高效能，完全符合企业级需求。 178 | 179 | **框架的目标** 180 | 181 | 通过使用 **Stages** 框架，社区能够更透明地了解每个 Rollup 在不同发展阶段的成熟度。这对于项目投资者、开发者以及生态系统其他成员来说至关重要，因为他们可以根据 Rollup 的发展阶段来评估风险、规划业务战略和选择合适的技术平台。 182 | 183 | 通过 **Stages** 框架强调了 Rollups 技术在不同发展阶段的变化，尤其是从实验性到商业化的过程。随着 Rollups 技术的逐步成熟，整个区块链生态系统将能够更好地应对扩展性和性能挑战。文章呼吁整个社区积极参与评估和推动这些技术的演进，以确保区块链的未来更加可持续和高效。 184 | 185 | ### 2025.01.09 186 | 187 | 188 | -------------------------------------------------------------------------------- /goudanxiaokui.md: -------------------------------------------------------------------------------- 1 | --- 2 | timezone: Asia/Shanghai 3 | --- 4 | 5 | > 请在上边的 timezone 添加你的当地时区，这会有助于你的打卡状态的自动化更新，如果没有添加，默认为北京时间 UTC+8 时区 6 | > 时区请参考以下列表，请移除 # 以后的内容 7 | 8 | timezone: Pacific/Honolulu # 夏威夷-阿留申标准时间 (UTC-10) 9 | 10 | timezone: America/Anchorage # 阿拉斯加标准时间 (UTC-9) 11 | 12 | timezone: America/Los_Angeles # 太平洋标准时间 (UTC-8) 13 | 14 | timezone: America/Denver # 山地标准时间 (UTC-7) 15 | 16 | timezone: America/Chicago # 中部标准时间 (UTC-6) 17 | 18 | timezone: America/New_York # 东部标准时间 (UTC-5) 19 | 20 | timezone: America/Halifax # 大西洋标准时间 (UTC-4) 21 | 22 | timezone: America/St_Johns # 纽芬兰标准时间 (UTC-3:30) 23 | 24 | timezone: America/Sao_Paulo # 巴西利亚时间 (UTC-3) 25 | 26 | timezone: Atlantic/Azores # 亚速尔群岛时间 (UTC-1) 27 | 28 | timezone: Europe/London # 格林威治标准时间 (UTC+0) 29 | 30 | timezone: Europe/Berlin # 中欧标准时间 (UTC+1) 31 | 32 | timezone: Europe/Helsinki # 东欧标准时间 (UTC+2) 33 | 34 | timezone: Europe/Moscow # 莫斯科标准时间 (UTC+3) 35 | 36 | timezone: Asia/Dubai # 海湾标准时间 (UTC+4) 37 | 38 | timezone: Asia/Kolkata # 印度标准时间 (UTC+5:30) 39 | 40 | timezone: Asia/Dhaka # 孟加拉国标准时间 (UTC+6) 41 | 42 | timezone: Asia/Bangkok # 中南半岛时间 (UTC+7) 43 | 44 | timezone: Asia/Shanghai # 中国标准时间 (UTC+8) 45 | 46 | timezone: Asia/Tokyo # 日本标准时间 (UTC+9) 47 | 48 | timezone: Australia/Sydney # 澳大利亚东部标准时间 (UTC+10) 49 | 50 | timezone: Pacific/Auckland # 新西兰标准时间 (UTC+12) 51 | 52 | --- 53 | 54 | # {你的名字} 55 | 56 | 1. goudanxiaokui 57 | 58 | 2. 你认为你会完成本次残酷学习吗？ yes 59 | 60 | ## Notes 61 | 62 | 63 | 64 | ### 2025.01.06 65 | 66 | 笔记内容 67 | 68 | ### 2024.07.12 69 | 70 | 71 | -------------------------------------------------------------------------------- /gpteth.md: -------------------------------------------------------------------------------- 1 | --- 2 | timezone: Asia/Shanghai 3 | --- 4 | 5 | > 请在上边的 timezone 添加你的当地时区，这会有助于你的打卡状态的自动化更新，如果没有添加，默认为北京时间 UTC+8 时区 6 | > 时区请参考以下列表，请移除 # 以后的内容 7 | 8 | timezone: Pacific/Honolulu # 夏威夷-阿留申标准时间 (UTC-10) 9 | 10 | timezone: America/Anchorage # 阿拉斯加标准时间 (UTC-9) 11 | 12 | timezone: America/Los_Angeles # 太平洋标准时间 (UTC-8) 13 | 14 | timezone: America/Denver # 山地标准时间 (UTC-7) 15 | 16 | timezone: America/Chicago # 中部标准时间 (UTC-6) 17 | 18 | timezone: America/New_York # 东部标准时间 (UTC-5) 19 | 20 | timezone: America/Halifax # 大西洋标准时间 (UTC-4) 21 | 22 | timezone: America/St_Johns # 纽芬兰标准时间 (UTC-3:30) 23 | 24 | timezone: America/Sao_Paulo # 巴西利亚时间 (UTC-3) 25 | 26 | timezone: Atlantic/Azores # 亚速尔群岛时间 (UTC-1) 27 | 28 | timezone: Europe/London # 格林威治标准时间 (UTC+0) 29 | 30 | timezone: Europe/Berlin # 中欧标准时间 (UTC+1) 31 | 32 | timezone: Europe/Helsinki # 东欧标准时间 (UTC+2) 33 | 34 | timezone: Europe/Moscow # 莫斯科标准时间 (UTC+3) 35 | 36 | timezone: Asia/Dubai # 海湾标准时间 (UTC+4) 37 | 38 | timezone: Asia/Kolkata # 印度标准时间 (UTC+5:30) 39 | 40 | timezone: Asia/Dhaka # 孟加拉国标准时间 (UTC+6) 41 | 42 | timezone: Asia/Bangkok # 中南半岛时间 (UTC+7) 43 | 44 | timezone: Asia/Shanghai # 中国标准时间 (UTC+8) 45 | 46 | timezone: Asia/Tokyo # 日本标准时间 (UTC+9) 47 | 48 | timezone: Australia/Sydney # 澳大利亚东部标准时间 (UTC+10) 49 | 50 | timezone: Pacific/Auckland # 新西兰标准时间 (UTC+12) 51 | 52 | --- 53 | 54 | # Alan 55 | 56 | 1. 工作经验: 5年 57 | 技术栈: Solidity Golang 58 | 59 | 多年web3智能合约开发经验，用Solidity开发过EVM生态DEFI、 NFT 、Dapp，对区块链特别感兴趣，想参加共学做出好的项目 60 | 2. 你认为你会完成本次残酷学习吗？ 61 | 会完成共学，之前搭建过公链，有过相关经验 62 | 63 | ## Notes 64 | 65 | 66 | 67 | ### 2024.07.11 68 | 69 | 笔记内容 70 | 71 | ### 2024.07.12 72 | 73 | 74 | -------------------------------------------------------------------------------- /image.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/IntensiveCoLearning/Optimism/3cd922710daa7d7c64a8cf1524512f82a78d2d12/image.png -------------------------------------------------------------------------------- /jiubate888.md: -------------------------------------------------------------------------------- 1 | 2 | --- 3 | 4 | # 九巴特 5 | 6 | 1. 自我介绍 7 | 我是一个加密爱好者，由于不会代码，每次看到共学会退避三尺，这次鼓起勇气来了。 8 | 3. 你认为你会完成本次残酷学习吗？ 9 | 会 10 | 11 | ## Notes 12 | 13 | 14 | 15 | ### 2025.01.06 16 | 今日学习第1天： 17 | Layer2 扩容方案: https://docs.optimism.io/stack/rollup/overview 18 | 19 | 1.传统的“多链”架构方法存在两个基本问题： 20 | 21 | 每条链都会引入一种新的安全模型，随着新链被引入生态系统，系统性风险也会随之增加。（相关链接） 22 | 新链的启动成本很高，因为它们需要新的验证器集和区块生产者。 23 | 注：降低风险，降低成本。 24 | 25 | 2.想到一个问题，如果超级op框架下自定义gas,手续费与sol链上的手续费相比？ 26 | 假设arb系统上的链，与op上的链相当，选取ape链上交易一笔，则手续费是0.006283U，而sol链上是0.03732U，可以得出一个简单结论，在便宜这块，sol的竞争优势将消失。 27 | 28 | 3.在Blockspace 和 Standard Rollup 章程里，自定义 gas 代币链是标准的吗？不是，标准链必须使用以太坊作为其 gas 代币，那么问题来了，这样做的目的是什么，有什么好处，现阶段这样，还是以后都是？ 29 | 30 | 4.将交易发布到超级链是不可扩展的，因为交易数据必须提交到容量有限的 L1.建议的解决方案:目前，L1 数据可用性(DA)的扩展程度还不足以支持互联网级别的扩展。但是，可以使用 Plasma 协议来扩展 0P 链可访问的数据可用性。 31 | 问题:若是Plasma 与零知识证明，结合扩展会有什么效果?得到一下答案 32 | 33 | 截屏2025-01-06 11 11 12 34 | 35 | 5.在设计理念原则，有几句很喜欢的话，简单性、实用性、可持续性，Optimism 倾向于尽可能使用现有的经过实战检验的以太坊代码和基础设施，尽管 Optimism 充满了理想主义，但其背后的设计过程最终还是由实用主义驱动。核心 Optimism 团队有现实世界的限制，基于 Optimism 构建的项目有现实世界的需求，使用 Optimism 的用户有现实世界的问题。Optimism 的设计理念优先考虑用户和开发人员的需求，而不是理论上的完美。有时最好的解决方案并不是最漂亮的解决方案。 36 | 注：有时候，有效远比正确更重要。 37 | 38 | 39 | ### 2025.01.07 40 | 学习第2天： 41 | 今天学习Optimism 与其他 Layer 2 的比较：https://learnblockchain.cn/article/3703 42 | 43 | 1.二层继承了以太坊的安全性，那么只专注扩展性，和去中心化，这样就破解了区块链三角困境，一个很好的思路。 44 | 45 | 2.看到一个图如下 46 | 截屏2025-01-07 10 50 24 47 | 48 | 然后用了chantGPT帮我理解概念 49 | Validity Proofs，英文单词的意思，Validity有效性，指某些事物合法的，正确，符合逻辑，Proofs，证明，指用来证明事物的真实性，有效性，合起来叫有效性证明。通过数学来证明，这里的数学是ZK——Proofs零知识证明。 50 | 51 | Fault Proofs 英文单词Fault是错误过失的意思，合起来是错误了，怎么证明，称为欺诈证明。 52 | 有效证明，跟欺诈证明的目的是什么，解决纷争，追求交易的正确性。 53 | 54 | 在有效性证明里，交易数据可以放在链上，也可以放在链下，链上叫ZK—rollup,链下validium,有效的链下数据存储，前者交易数据完全在链上，后者交易数据在链下，而状态根在链上。 55 | Volition 英文的意思，是主观的，自由选择，在这里是用户自由选择，将数据存储到链上，或者链下。 56 | 57 | Plasma 欺诈证明里的一种方式，将交易数据状态根，提交到以太主网，而optimistic,将整个交易数据提交到以太主网，那么这里面有个问题，plasma在7天窗口挑战期，交易数据能否调出来验证，是一个问题，而V神最近提出，这个交易数据，可以用零知识证明来解决。很有意思的事，期待后面的走向。 58 | 59 | Plasma若是加上，零知识证明，会解决什么问题，零知识证明（ZK Proofs）解决了 Plasma 的关键问题之一：数据可用性问题 和 状态更新的正确性验证问题。 60 | 61 | 3.今天的学习很愉快，chantGPT帮我梳理了很多问题。 62 | 63 | 64 | 65 | ### 2025.01.08 66 | 67 | 学习第3天： 68 | 今天学习Stage 的介绍：https://medium.com/l2beat/introducing-stages-a-framework-to-evaluate-rollups-maturity-d290bb22befe 69 | 70 | 1.stage的意思，事物发展的阶段，等级，在这里就是一个判断框架，目的就是来判断评估 Rollups 项目，处于那个阶段，以便让用户知道，它的去中心化程度。分为以下三个阶段： 71 | 72 | 第0️⃣阶段：由操作员运行，有一个开源可用软件。 73 | 74 | 第1️⃣阶段：由操作员运行，升级为智能合约运行，保留一个安全委员会，解决少部分问题，OP是用的故障证明。 75 | 76 | 第2️⃣阶段：完全由智能合约运行，安全委员会非必要不干涉，除了重大问题。 77 | 78 | 这三个阶段，从0️⃣到2️⃣，将人操作干涉，逐渐不断缩小，交给代码，体验到了，代码的力量。 79 | 80 | 81 | 2.在l2beat网站上，选取了前排名52个项目里，处于第0️⃣阶段的有42个，处于第1️⃣阶段的有2个，处于第2️⃣阶段有3个。 82 | 83 | 84 | 截屏2025-01-08 11 28 23 85 | 86 | 87 | 3.在OP系统里，有四个项目，用了故障证明，一个是base，OP主网，swell，lnk,其余的都没用，swll与lnk刚加入，就使用了，说明使用的难度不大，uni 也承诺上线就使用，可能其他项目不重视这个，在他们眼里，这不是什么紧急的事，不知道我的看法对不对？ 88 | 89 | ### 2025.01.09 90 | 91 | 92 | 学习第4天，今天学习有关零知识证明的知识. 93 | 94 | 1.ZK（或是ZKP）全称Zero-knowledge proof,即零知识证明，它是一种方法，目的呢是，通过该方法，证明者可以向另一方验证者证明一个事实，不需要透露该事实的具体信息。这个脑补了一下，感觉很有意思。相应的带来好处，是保护隐私，还有一个是解决验证难的问题。 95 | 96 | 2.ZK-SNARK全写Zero-Knowledge Succinct Non-Interactive Argument of Knowledge，其中succinct是简洁的意思，Non-Interactive，其中Non,是非，不的意思，而Interactive是交互的意思，合起来是非交互式的。Argument是论证的意思，总体合起来就是，零知识证明里的一种简洁非交互式的知识论证。注意它只是其中一种，零知识证明构造的方法。 97 | 98 | 3.ZK-SNAEKs到ZK-STARKs,这里的s代表可扩展的，ZK-STARKs是前面的升级版本，这里的字母T代表透明性，比起ZK-SNAEKs,效率更高，理论上强十倍，更加去中心化，还可以抗量子特性，但相应的有个缺点，就是技术相对来说新一点。实现难度比较大，做个简单类比，相当于欺诈证明，与有效证明的关系。ZK-SNAEKs是目前通用的证明算法，而ZK-STARKs目前技术不够成熟，是特用的证明算法，目前使用ZK-STARKs的项目有StarkWare ,POlygon Miden等。 99 | 100 | 4.zkEVM其实是运行在L2层的类EVM虚拟机器，因此更为精确的说法是Zero Knowledge virtual Machine,Virtual 是虚拟的意思，zkvm,只不过大家强调其兼容以太坊而称为zkEVM,现有项目也在考虑逐渐放弃了为特定应用程序而做优化，而升级支持运行通运合约即zkEVM Rollup.因此ZKEVM Rollup虽然作为ZK Rollup的下位概念，在大部分情况下，提起ZK Rollup时变指zkEVM rollup. 101 | 102 | 5.总结，好好理解吸收这些概念，才能知道这些项目方在干嘛。 103 | 104 | 105 | ### 2025.01.10 106 | 107 | 学习第5天，今天学习有关blob扩容与Flashblocks 。 108 | 109 | 1.今天早上回看 OP Labs 产品主管 Sam McIngvale 将与 Token Relations 的 Jacquelyn Melinek 一起深入讨论 Optimism 的 2025 年产品路线图，里面提到blob扩容，我就好奇查了一下。 110 | blob 扩容是一种新的交易类型，这种交易类型，可以为以太坊提供一个额外的外挂数据库，这种交易是为rollup量身制定的，rollup的数据以Blob的形式上传至以太坊，额外的数据空间可以是rollup实现更高的tps和更低的成本，同时也将原本rollup占据的区块空间释放给更多的用户。由于Blob的数据是临时存储的，数量的暴增并不会对节点的储存性能造成越来约越重的负担。 111 | 112 | 2.在最新的以太升级计划中，将三个块升级为六个，那么他的TPS会翻倍，目前二层的tps如下图。 113 | 114 | 115 | 截屏2025-01-10 16 52 24 116 | 117 | 那么最高的base也就会达到143.28，在这场高性能竞争中，缓解了不少。 118 | 119 | 3.Vitalik Buterin：确实需要在以太坊核心开发中更好地确定优先级，优先支持 blob 扩容。 120 | 121 | 122 | 123 | 截屏2025-01-10 17 16 16 124 | 125 | 126 | 127 | 128 | 129 | 130 | 4.Flashblocks 该协议允许矿工和验证者透明地交易区块内的交易顺序，从而减少MEV导致的不公平性和乱象，250 毫秒的 Flashblocks：这一模块提供极快的确认时间，同时引入了原生的回退保护机制，防止由于交易失败引发的重复费用。同时，Flashblocks 还大幅提升了 Gas 吞吐量，使得用户在繁忙的网络环境中仍能以较低的成本完成交易；2）可验证的优先级排序：每个 Flashblock 内的交易将根据可验证的优先级进行排序。这不仅提供了更强的用户保障，还允许应用内部化 MEV，从而减少外部 MEV 提取对网络的冲击，进一步提升了整体的市场效率。若是uni链上线，将有十倍的升级体验。 131 | 132 | 5.总结，明显的感觉到，市场的竞争激烈，我在想技术，有没有护城河，若是没有的话，那么到底什么是项目方的护城河呢？ 133 | 134 | ### 2025.01.11 135 | 136 | 137 | 学习第6天，今天想了解一下，二层 op arb zksync stark 创始人团队情况。 138 | 139 | 140 | 1. Optimism： 由一组以太坊开发人员创建，创始人包括 Jinglan Wang、Ben Jones 和 Karl Floersch。 141 | 142 | Jinglan Wang 拥有计算机科学背景，曾在谷歌和 Uber 工作过。她是经验丰富的区块链布道者。在 MIT 时期加入了学校的比特币俱乐部，开启了自己的加密之旅，后来又到纳斯达克担任区块链产品经理，并创立了贸易融资公司 Eximchain。之后，她又和 Jeremy Gardner 共同创立了区块链教育网络 The Blockchain Education Network，帮助全球各地的学校组建区块链俱乐部。 143 | 144 | Ben Jones 是一名软件工程师，拥有在以太坊上构建去中心化应用程序的经验。他在空闲时常以自己的艺名 Weird ETH Yankovic 制作一些基于以太坊的模仿歌曲，也是團隊中的艺术家。 145 | 146 | Karl Floersch目前是CEO，研究员和开发人员，曾参与过多个以太坊项目，包括以太坊 2.0。 是以太坊基金会的 OG 开发者，他爱好冥想和即兴饶舌，从小受到印度教的熏陶，通过冥想来思考和感悟一些事情，用饶舌表达自己当下的感受我。 147 | 148 | 顺便在 youtube 找到了采访Jinglan Wang和 Karl Floersch 的视频，顺便截了个图。 149 | 150 | 截屏2025-01-11 12 35 03 151 | 152 | 2.Offchain Labs： 153 | Ed Felten 是 Offchain Labs 的联合创始人兼首席科学家。除了在 Offchain Labs 担任职务之外，Ed 也是普林斯顿大学的教授，近 30 年来他一直在普林斯顿大学为学生提供计算机科学和公共事务方面的教育. 154 | 155 | Steven Goldfeder 是 Offchain Labs 的联合创始人兼首席执行官，此前他在普林斯顿大学获得了博士学位后进入 Google 工作。 156 | 157 | Harry Kalodner 是 Arbitrum / Offchain Labs 的联合创始人兼首席技术官。他在美国普林斯顿大学获得计算机科学博士学位。 158 | 159 | 160 | 截屏2025-01-11 13 01 34 161 | 162 | 163 | 3.zksync ：Alex Gluchowski 是 Matter Labs 的联合创始人兼首席执行官，他正在使用零知识证明扩展以太坊。 在此之前，他是香港 Entropy Labs 的研发总监，专注于以太坊研发，Alex 拥有柏林工业大学的计算机科学硕士学位。 164 | 165 | Marcin Michalski目前是负责 ZKsync 首席协议架构师。在此之前，他在 NEAR Blockchain 负责协议开发。 166 | 167 | Meghan Hughes 是 Matter Labs 首席营销官，此前是 Solana 基金会市场副总裁。她毕业于西蒙斯大学。 168 | 169 | 170 | 截屏2025-01-11 16 27 38 171 | 172 | 173 | 4.StarkWare ： 174 | Eli Ben-Sasson：Co-Founder & 首席科学家，以色列理工学院计算机专业的教授。Zcash 的创始科学家，zkSNARKs 的发明者。 175 | 176 | Alessandro Chiesa：Co-Founder & 首席科学家，加州大学伯克利分校计算机专业的教授。Zcash 的创始科学家，zk-SNARKs 的联合发明者，libsnark 的核心开发者。 177 | Uri Kolodny：Co-Founder & CEO，Uri 是一个商业经验丰富、善于合作的连续创业者。 178 | 179 | Michael Riabzev：Co-Founder & 首席架构师。以色利理工学院的博士，曾在 Intel、IBM 工作。 180 | 181 | Oren Katz：工程副总裁。Hebrew 大学计算机专业毕业，Tel Aviv MBA，20 年经验的资深工程师。 182 | 183 | 截屏2025-01-11 16 35 58 184 | 185 | 5.个人的感悟，他们都很优秀，目前的顶级大佬，都对加密改变这个世界着迷，为加密世界添砖加瓦，对于我个人，不太懂技术，我个人更偏向于年轻的创业者，觉着他们有更多充沛的精力，思想包袱少，带着羞涩的纯粹性，更能贴近这个时代。 186 | 187 | ### 2025.01.12 188 | 189 | 今天学习第7天，目的是要了解，bolb扩容，会给以太坊带来的问题，及相应的解决办法。 190 | 191 | 1.按照V神的路线规划，若是中期目标每槽是16MB，如果结合汇总数据压缩的改进，我们将获得约58000TPS。那么显然会带来以下问题？ 192 | 193 | a.节点负担过大，在数据存储上还是数据同步上，使得以太坊节点过大，而导致以太坊的中心化程度降低。 194 | 195 | b.数据可用性问题，如果节点不去下载全部bolb数据，就会面临数据可用性的问题，因为数据不在链上开放且随时访问，如果对某个交易数据存疑，发起挑战，那么拿不到原始数据，就无法证明这个数据是有问题的。所以要解决数据的可用性问题，就必须得保证数据的随时开放且可以访问。 196 | 197 | 2.数据可用性采样： 198 | 引入数据可用采样性，目的是来降低节点负担过大，同时保证了数据的可用性。 199 | 200 | 数据可用采样性DAS，它的思想是将blob中的数据切割成数据碎片，并且让节点由下载bolb数据转变为随机抽查blob数据碎片，让blob的数据碎片分散在以太坊的每个节点中，但是完整的blob数据却保存在整个以太坊中，前提是节点需要足够多且去中心化。 201 | 202 | 3.为了实现数据可用性采样（DAS）采用了两个技术：纠删码（erasure Coidng )和KZG多项式承诺（KZG Commitment 这里的KZG是来自三密码学家名字的首字母，即 Katz, Zeldovich, 和 Gennaro，他们提出了这一概念)。 203 | 204 | a.纠删码，是一种编码容错技术，使用纠删码切割数据可以使得所有以太坊上节点在拥有50%以上的数据碎片情况下，就可以还原出原始数据，这样大大的降低了数据缺失的概率。 205 | 206 | b.KZG多项式承诺，是一种密码学技术，通常用于零知识证明和其他加密协议，目的是来证明这个数据碎片，来源于blob的原始数据，所以负责编码的角色还需要生成一个KZG多项式承诺，来证明这个纠删码的数据碎片确实是原始数据的一部分。 207 | 208 | 4.danksharding（这个英文单词的意思是，太坊研究员Dankrad Feis提出来的分片技术形式命名的），是初始分片方案sharding1.0方案的升级版本，使用了一套新的分片思路去解决以太坊的扩容问题，即围绕着Layer2的rollup进行扩容的分片方案，这套新的分片方案可以在不大量增加节点负担，且保证去中心化和安全性的同时，解决可扩展性问题，同时解决了MEV带来的负面影响。 209 | 210 | 211 | ### 2025.01.13 212 | 213 | 今日学习第8天： 214 | 治理理念：https://community.optimism.io/welcome/welcome-overview 215 | 216 | 1.乐观主义集体，由公司，社区，公司组成的团体，并为以太坊打造可持续的未来。继承了以太坊的上层意志。 217 | 218 | 2.乐观主义集体受互惠互利的契约约束，可以用“影响=利润”的公理来概括。这里的影响=利润，该如何理解呢？ 219 | 220 | 截屏2025-01-13 12 25 50 221 | 222 | 对于上图中复古资金奖励，换成追溯资金奖励。 223 | 224 | 225 | 3.追溯性公共物品资助：维塔利克·布特林的倡导 226 | Vitalik 在其博客和演讲中多次提到关于资助公共物品的问题，尤其是在区块链生态系统中。传统资助模式（如捐赠或前瞻性资助）常面临的问题是： 227 | 228 | 难以预测项目成功的可能性：前期资助时，项目是否能够实现目标存在不确定性。 229 | 230 | 激励不对齐：开发者更关注如何获得资金，而非创造长期价值。 231 | 232 | Vitalik 提出了“追溯性资助”的想法，认为可以通过回顾历史上为公共利益做出巨大贡献的个人或项目，给予奖励，从而鼓励开发者在未来为社区创造更大价值。这种机制能够更好地激励长期主义者，同时解决短期投机行为的问题。 233 | 234 | 4.集体的数字民主治理模式由两院组成：代币院和公民院。这两院形成两院制治理体系，两院制设计旨在帮助集体做出更好的决策，避免基于代币的治理体系中常见的陷阱，并进行制衡。 235 | 236 | a.代币院：作为代币之家成员，OP 持有者负责提交、审议和投票各类治理提案。在履行这些职能时，OP 持有者可以直接投票，也可以将其 OP 投票权委托给其他人。 237 | 238 | b.公民之家：公民之家是一项基于声誉的一人一票治理的大规模实验，并负责追溯性公共物品资助（追溯资助）。 239 | 240 | 追溯基金是集体的主要经济引擎，奖励那些在集体和超级链中产生积极影响的人。追溯基金基于一个简单的想法，即更容易就过去有用的东西达成一致，而不是就未来可能有用的东西达成一致。 241 | 242 | 5.追求利润之上的追求，在以太坊.OP这看到了。 243 | 244 | ### 2025.01.14 245 | 246 | 今日学习第9天： 247 | 248 | 投票机制：https://github.com/ethereum-optimism/OPerating-manual/blob/main/manual.md 249 | 250 | 1.乐观主义集体由两个院系管理，即象征院和公民院。两院均通过治理提案做出决定。提案通过投票程序接受或拒绝。任何人都可以向治理提交提案。提案必须是下列有效提案类型之一，并且必须遵循此处描述的投票程序。 251 | 252 | 2.Token House 治理的主要工具目前是： 253 | 254 | Token House 治理合约： Token House 治理提案的链上投票合约。所有符合条件的 Token House 治理提案均在此提交投票。 255 | Optimism 治理门户：一个前端界面，使 Token House 成员能够在链上委托和投票他们的 OP。 256 | 公民院快照空间：一个前端界面，使公民院成员能够否决象征性议院提案。 257 | 乐观论坛：讨论和审议治理建议的平台。 258 | Discord：用于非正式治理讨论和反馈。 259 | Github：资助（任务请求）通过这个公共 Github 仓库中的问题进行管理。 260 | Charmverse：社区主导的乐观资助委员会所在地。 261 | 262 | 3.提案流程——投票流程——任务补助金——反馈和审查——投票——否决程序。 263 | 264 | 4.有效提案类型 265 | 所有 v0.3 治理提案必须属于以下类别之一： 266 | 267 | 治理基金 268 | 协议或州长升级 269 | 通货膨胀调整 270 | 董事罢免 271 | 财政拨款 272 | 违反行为准则 273 | 代表罢免 274 | 代表性结构溶解 275 | 权利保护 276 | 选举 277 | 批准 278 | 反思期（元治理） 279 | 280 | 5.公民院治理包括追溯公共物品资助（追溯资助），其涉及一系列“轮次”的投票和支出。在每一轮追溯中，公民院都会投票追溯奖励那些产生重大影响的公共物品项目。 281 | 282 | 6.在学习这一环节，对治理缺乏感觉，有种生疏感。 283 | 284 | 285 | ### 2025.01.15 286 | 287 | - 今日第10天学习： 288 | 289 | 1.委员会：https://gov.optimism.io/search?q=council 290 | 291 | 逛了一下OP主体治理论坛： 292 | 293 | 看到了OP中文力量社区： 294 | 295 | 截屏2025-01-15 15 23 20 296 | 297 | 截屏2025-01-15 15 23 41 298 | 299 | 300 | 2. Soneium 愿景： 301 | 截屏2025-01-15 15 29 14 302 | 303 | 里面有句话，乐观地扩展以太坊：与超级链的使命一致，Soneium 为以太坊的可扩展性、互操作性和可访问性做出了贡献，继承了以太坊的正当性。 304 | 305 | 306 | 307 | 3.安全理事会：安全理事会的目标是将 OP 主网的管理密钥，以及最终将超级链中的所有 OP 链，移交给对 Optimism 治理负责的一组公共的、分散的个人参与者。 308 | 309 | 310 | 311 | 截屏2025-01-15 15 47 15 312 | 313 | - 安全理事会自我提名：L2BEAT 314 | 315 | ### 2025.01.16 316 | 317 | 今日第11天学习： 318 | 319 | RetroPGF：https://community.optimism.io/citizens-house/how-retro-funding-works 320 | 321 | 1.理念：过去有用的东西达成一致，就比未来有用的东西达成一致更容易，“影响=利润”的核心。对集体的积极影响应该按比例奖励给个人利润。 322 | 323 | 影响力：表示贡献者为 Optimism 集体创造的价值。 324 | 325 | 利润：表示贡献者从 Optimism 集体中提取的价值。 326 | 327 | 差距：表示贡献者的影响力与利润之间的差异。 328 | 329 | （例如：影响力 - 利润 = 差距） 330 | 331 | RetroPGF 填补了贡献者的影响力与利润之间的差距，从而实现「影响力 = 利润」的状态。 332 | 333 | 334 | 335 | ### 2025.01.17 336 | 337 | 今日第12天学习： 338 | 339 | RetroPGF 获奖项目：https://round6.retrolist.app/ 340 | 341 | 1.刚刚参加了Qi Zhou的分享会，确实好的不营利的项目，得追溯资助，否则很难存活下去，让我有了直观的感受。 342 | 343 | 2.建设一个项目，维护一个项目很难，能买得起车，加不起油，是个难题。 344 | 345 | 3.洞察用户的需求，满足用户，给用户保姆式服务。 346 | 347 | 4.好的东西，有些是滞后的，需要时间，前人栽树，后人乘凉，不寻求短期回报。 348 | 349 | 5.人与人之间，思维的碰撞，跟人与人工智能之间的碰撞，是两种体验，如同吃手擀面跟机器面的区别。 350 | 351 | 6.Done is always better than perfect 这句话，感觉是写给我自己的，去做去熏陶，每天熏陶一点，时间久了，就熏成了，而不是去追求完美，追求完美的结果，就是止步不前。 352 | 353 | 354 | ### 2025.01.18 355 | 356 | 今日第13天学习： 357 | 358 | 1.有个感受，影响力=利润，那么这个影响力，换算成钱，那也有一定的相应价值，meme币，就是这个影响力所折算出来的价值，当然这个价值，是动态变化的。 359 | 360 | 2.万物皆可发币 361 | 362 | 截屏2025-01-18 21 37 01 363 | 364 | 365 | 截屏2025-01-18 21 36 43 366 | 367 | 3.这个真的很有趣 368 | 369 | ### 2025.01.19 370 | 371 | 今日第14天学习： 372 | 373 | 1.OP代币，如何赋能，查着了解了一下： 374 | 375 | 在Mint Ventures研究文章里，布局坎昆升级，OP和ARB谁是更佳选择？有这样的答案： 376 | 377 | 截屏2025-01-19 18 15 16 378 | 379 | 去中心化排序器上线后，抵押直接赋能。 380 | 381 | 2.目前在论坛里 ，也提案： 382 | 383 | 提案目标： 384 | 385 | 可持续网络增长：调整通货膨胀率以支持持续的生态系统扩张，同时防止代币供应过剩。 386 | 387 | 参与者激励：确保验证者、开发人员和其他网络参与者获得足够的奖励，以保持较高的参与度和活跃度。 388 | 389 | 经济稳定性：通过使通货膨胀与生态系统的需求和效用保持一致来防止代币价值贬值。 390 | 391 | 治理协调：利用分散治理来实施和监督通货膨胀政策。 392 | 393 | 其中很有趣我个人感兴趣的观点，就是提出最高年通胀率，例如代币总供应量的 5%，以保持可控的增长。 394 | 395 | 3.目前代币不赋能的话，造成持币者，机会成本的损失，目前感觉不舒服，拿着的话，不太大涨，抛了又舍不得，因为喜欢这个项目，有点两难选择。 396 | 397 | ### 2025.01.20 398 | 399 | 今日学习第15天： 400 | 401 | 1.超级链的概念：一个共享桥接、去中心化治理、升级、通信层等的链网络——全部建立在 OP Stack 上。 402 | 403 | 2.扩展性愿景：今天看到一篇文章，Blob空间不足，以太坊L2也在崩溃边缘？作者是gauthamzzz，polynomialfi 联合创始人，里面的观点是： 404 | 405 | . Blob 空间即将达到极限 406 | 407 | • 6 个月内将迎来下一个危机 408 | 409 | • 迫切需要扩展解决方案 410 | 411 | • 每个 L2 用户都受到影响 412 | 413 | 414 | 415 | 如果你希望以太坊扩展，这就是需要关注的战斗。 416 | 417 | 目前市场的现状，主要矛盾是性能扩展不足的问题，有种火烧眉毛的感觉，这是一场攻坚战。sol的存在，缓解了用户，对这种刚性需求。长期来看，也算是一种临时缓解手段。 418 | 419 | 3.区块链的可扩展性将从根本上实现互联网的去中心化，并使创建横向可扩展、安全且去中心化的 Web 应用程序变得容易。我在细细理解这句话，横向扩展，那么什么算是好的项目呢？ 420 | 好的区块项目=安全性+去中心化+一定的性能+满足用户的需求，这里用户的需求，是核心，如何低成本的满足用户的需求，就会获得用户的青睐，在牛市，是首要任务。 421 | 422 | 4.Alt-Data 可用性层 — Alt-DA 协议:这个是干嘛的？来扩展 OP 链可访问的数据可用性，该协议允许其他 DA 提供商补充较为有限的 L1 DA。 423 | 424 | 为什么要引进呢？因为将交易发布到超级链是不可扩展的，因为交易数据必须提交到容量有限的 L1。 425 | 426 | 交易数据在 L1 上提交但不直接提供给 L1 的链，具有数据可用性挑战回退。 427 | 428 | 由于哈希能够将任意大小的数据缩减为恒定大小的承诺，并且能够并行化交易数据哈希，因此可以使用 Alt-DA DA 实现数据承诺的近乎完美的水平可扩展性。这意味着可以将游戏或社交媒体等大规模可扩展的应用程序放在 Alt-DA 链上。 429 | 430 | 431 | 5.存在即合理，不可否认，抛弃偏见。 432 | 433 | 434 | ### 2025.01.21 435 | 436 | 今日学习第16天： 437 | 438 | OP Stack 基本概述 439 | 440 | 1.OP Stack 是一套为 Optimism 提供支持的软件——目前以 OP Mainnet 背后的软件的形式出现，最终以 Optimism Superchain 及其治理的形式出现。 441 | 442 | 这里该如何理解呢，OP Stack 个人视作模块工具箱，这里的工具，可以为想加入 Optimism Superchain的去组合定制一条二层链，其中OP Mainnet就是其中的一条二层链，好多个类似的这样二层链组合的集合，就是 Optimism Superchain。 443 | 444 | ![image-18](https://github.com/user-attachments/assets/ca41ae23-025d-464f-be9a-ea1e0efbb425) 445 | 446 | 2.OP Stack，那么这个箱子里有什么呢？ 447 | 448 | 数据可用性，测序，单序列发生器，多序列发生器，推导，汇总，索引器，执行，以太坊虚拟机，沉降层，基于证明的故障证明，防错乐观结算，有效性证明结算，治理，多重签名合约，治理代币。 449 | 450 | 3.关于layer2与layer3之间的定义，找到下图。 451 | 452 | 453 | 截屏2025-01-21 18 09 09 454 | 455 | 456 | 457 | 4.官方如何，将技术性的东西，简单通俗化讲给用户，用户一听马上就明白，这样有利于传播。 458 | 459 | ### 2025.01.22 460 | 461 | 今日学习第17天： 462 | 463 | 体验和分析一下 Superchain 项目： 464 | 465 | 1.今天是小年，在我这是祭灶日，有点节日喜庆的味道，正好看到了OP更新了品牌定位，符合我对，OP的期待，OP主网现在成了超级链里的其中一份子，op则代表整个超级链。 466 | 467 | 截屏2025-01-22 16 50 53 468 | 469 | 2.目前在超级链上，给我的影响中，OP主网，BASE，UNI，在就想不起来，有啥能打的。 470 | 471 | 3.看到V神与大佬之间互战，当利益与理想冲突时，该怎么选择？ 472 | 473 | 从时间框架来说：短期利益，与长期利益的冲突，能够不被短期诱惑，隔绝压力，以平常心回归到事物本质，保持一定的定力，这个实在是太难得了，我呢在现实中，常常被干扰，随风漂泊。值得一辈子学习。 474 | 475 | ### 2025.01.23 476 | 477 | 今日学习第18天： 478 | 479 | 想了想，学习点啥呢，心里又诸多不爽，那就这期跑题了，跟随心里，谈一点心理学上的东西，想到那，写到那。 480 | 481 | 1.父母对孩子有高期待，就会过分干涉孩子的事，会破坏孩子的自我体验，这样孩子就会犯错率提高，导致父母再次干涉纠正孩子，孩子会越无能，越无能越干涉，进入恶性循坏，直到父母与子女爆发强烈的冲突。 482 | 483 | 2.处在这样的环境里，人与人之间，会陷入负和博弈，争夺控制权，以达到某种平衡，不博弈的话，自我会损失更严重，就像竹笼里的螃蟹，互相扒拉，谁也爬不出来。 484 | 485 | 3.这种环境里，没有赢家，只能逃离，找到适合生存的环境，圈子不对，努力白费，寻找有正和博弈思维的人共处。 486 | 487 | ### 2025.01.24 488 | 489 | 今日学习第19天： 490 | 491 | 学习超级链里的：Unichain 492 | 493 | 1.Unichain 是专为 DeFi 构建的 L2，专门用于 OP Stack。Unichain 是 Superchain 实现互操作性的一部分，并将支持与 Superchain 互操作兼容的 ERC20。Uniswap Labs 还与 Flashbots 合作开发一种新的基于 TEE 的区块生成器，将 Unichain 确认时间从 1 秒缩短到 250 毫秒。 494 | 495 | 那么问题来了，基于 TEE 的区块生成器，这个该怎么理解？ 496 | 可信执行环境(Trusted Execution Environment，TEE)作为区块链安全领域的重要技术，近年来在业内引起了广泛关注。可信执行环境(TEE)是一种通过硬件和软件结合来提供安全计算环境的技术。它通过在设备中创建一个隔离的"安全区"，确保只有经过验证的应用程序可以在此环境中执行敏感数据的处理，防止未授权的访问或篡改。TEE 技术的核心是利用 TEE 的硬件隔离特性，在不影响区块链去中心化属性的前提下，保障关键计算和数据的安全。 497 | 498 | 2.即时交易：整体上基于 Op Stack 进行构建，同时与 Flashbots 合作开发出一个称之为可验证区块构建（Verifiable Block Building）的功能。主要是将一个区块进一步划分为这四个子区块（Flashblocks），这样进一步加速状态更新，缩短了有效区块时间，整体出块时间缩短为 0.25 秒；同时 Unichain 整体使用 TEE（受信执行环境），将排序和区块构建进行分离，一方面可以优先排序，另一个方面对 MEV 征税，内化 MEV 收入。TEE 和 Flashblocks 的结合实际上使得整个交易速度和安全性取得了一个相对平衡，但是这也同时对网络和技术提出了比较高的要求。 499 | 500 | 3.降低成本和更加去中心化：Unichain 的验证网络整体又节点运营者构成的去中心化网络，成为验证者必须质押 UNI 代币，按照质押量获得奖励，每次区块验证会根据 UNI 质押权重进行选择。换言之 Unichain 主要是利用中心化验证和可验证区块的结合，进一步实现排序透明度，而整个交易执行环节放在 Unichain 上则可以实现交易成本的大幅降低。 501 | 502 | ### 2025.01.25 503 | 504 | 今日学习第20天： 505 | 506 | 1.看到文章，Futarchy 与治理相遇：乐观主义和 Uniswap 基金会，推出了一项实验，将信息金融应用到，项目治理中，感觉这个很有趣。 507 | 508 | 2.我们将启动由 Butter 推动的两个平行实验，向两个社区开放： 509 | 510 | 对于乐观治理：这是一场预测竞赛，预测者可以用游戏币投票，通过准确预测赠款授予者的影响来获得 OP 奖励，预测者最终将决定哪些团队获得赠款。 511 | 512 | 对于 Uniswap 治理：有条件资金市场 (CFM)，预测者可以存入 USDC 并通过预测结果获得奖励，最终决定如何资助团队以推动 Unichain 上的借贷协议增长。 513 | 514 | 3.按照我的通俗理解，就是用真金白银去押注，这样会让押注者，用心搜集资料，群策群力，给出最合理的决策。那么这里用的思维模型是什么呢，是不是用的贝叶斯定律，然后金融化了，感 515 | 觉这个很有趣，这个问题，留给老师解答。 516 | 517 | 4.感谢Marcus提供给我的V神论文。 518 | 519 | 520 | 521 | ### 2025.01.26 522 | 523 | 今日是学习的最后一天：做个复盘总结 524 | 525 | 1.当我看到OP残酷公学时，内心有两股力量，第一股力量，我是感兴趣的，想探究一下OP的魅力，第二股力量，我的内心是抗拒的，一个原因是不会代码，第二个是不会英语，得靠翻译软件，这两股力量在博弈，后来听币友说，不会代码也可以学，于是动力大于阻力，索性就参加了。这让我学会了一件事，就是如何有效的降低阻力，相对得就是增加了动力，而不是一味的去增加动力。 526 | 527 | 2.面对复杂的东西，不易理解的术语概念，可以让自己慢下来，增加时长，慢慢去理解，人的大脑对于不熟悉不理解的事物，天生具有恐惧抗拒感，可以换个近义词，或者做个简单的类比，把它通俗化，转化成自己熟悉的词语，这样便可以更好的理解。 528 | 529 | 3.去表达，去提问，那怕这个问题多么幼稚，那么也在证明，你在思考，只要思考了，远比找到答案更重要，最怕就是自己没有思考，而是去复制粘贴。 530 | 531 | 4.学完之后，过几天内容就会忘了，这个不重要，重要的是如何学习，在学习中，体验那种突然打通的快感，这个更重要。有的人喜欢事后 ，去过分总结，寻找不足，我个人更偏向于，寻找满意的地方，体验事后的快乐。让自己快乐，是向前走的驱动力之一。 532 | 533 | 5.以太坊带来的一个好处，去中心化，安全性，有了这两样，就会给用户建设者带来安全感，这个东西很重要，是作为人而言，最基本也重要的需求之一，有了安全感，人才会静下心来，做长期有价值的事，做个简单的类比，如果楼房，在怎么漂亮，你住着感觉不到安全，你就无法幸福的去生活工作，那么你住一段时间，肯定会搬离。 534 | 535 | 6.那么OP做的事，可见就有多么重要了，这也是我喜欢OP项目的原因，在做正确的事，在朝着正确的方向走，不过这个事有点难度，这个难度，便是它以后的护城河，路漫漫其修远兮，OP将上下而求索。 536 | 537 | 7.支持以太坊，支持OP，我到底在支持什么，就是让生存在区块链世界中的人们，可以安全地自由的去生活，享受这里面的乐趣。 538 | 539 | 8.上面的话，也是写给我自己的，写的过程，完成了跟自己的一次对话，让我有种愉悦感。 540 | 541 | 9.感谢OP这次残酷公学，感谢两位助教，感谢群里的伙伴，你们都很优秀，热心帮我解答了好多问题，跟你们在一起很快乐。 542 | 543 | ### 2025.01.27 544 | 545 | 546 | 547 | 548 | -------------------------------------------------------------------------------- /jjeejj.md: -------------------------------------------------------------------------------- 1 | --- 2 | timezone: Asia/Shanghai 3 | --- 4 | 5 | > 请在上边的 timezone 添加你的当地时区，这会有助于你的打卡状态的自动化更新，如果没有添加，默认为北京时间 UTC+8 时区 6 | > 时区请参考以下列表，请移除 # 以后的内容 7 | 8 | timezone: Pacific/Honolulu # 夏威夷-阿留申标准时间 (UTC-10) 9 | 10 | timezone: America/Anchorage # 阿拉斯加标准时间 (UTC-9) 11 | 12 | timezone: America/Los_Angeles # 太平洋标准时间 (UTC-8) 13 | 14 | timezone: America/Denver # 山地标准时间 (UTC-7) 15 | 16 | timezone: America/Chicago # 中部标准时间 (UTC-6) 17 | 18 | timezone: America/New_York # 东部标准时间 (UTC-5) 19 | 20 | timezone: America/Halifax # 大西洋标准时间 (UTC-4) 21 | 22 | timezone: America/St_Johns # 纽芬兰标准时间 (UTC-3:30) 23 | 24 | timezone: America/Sao_Paulo # 巴西利亚时间 (UTC-3) 25 | 26 | timezone: Atlantic/Azores # 亚速尔群岛时间 (UTC-1) 27 | 28 | timezone: Europe/London # 格林威治标准时间 (UTC+0) 29 | 30 | timezone: Europe/Berlin # 中欧标准时间 (UTC+1) 31 | 32 | timezone: Europe/Helsinki # 东欧标准时间 (UTC+2) 33 | 34 | timezone: Europe/Moscow # 莫斯科标准时间 (UTC+3) 35 | 36 | timezone: Asia/Dubai # 海湾标准时间 (UTC+4) 37 | 38 | timezone: Asia/Kolkata # 印度标准时间 (UTC+5:30) 39 | 40 | timezone: Asia/Dhaka # 孟加拉国标准时间 (UTC+6) 41 | 42 | timezone: Asia/Bangkok # 中南半岛时间 (UTC+7) 43 | 44 | timezone: Asia/Shanghai # 中国标准时间 (UTC+8) 45 | 46 | timezone: Asia/Tokyo # 日本标准时间 (UTC+9) 47 | 48 | timezone: Australia/Sydney # 澳大利亚东部标准时间 (UTC+10) 49 | 50 | timezone: Pacific/Auckland # 新西兰标准时间 (UTC+12) 51 | 52 | --- 53 | 54 | # {你的名字} 55 | 56 | 1. 奕 iyi: 一名 后端 Golang、Node.js、Rust 开发者; 合约 ETH、Arb、Solana 开发者。进入 web3 行业 2 年 57 | 2. 你认为你会完成本次残酷学习吗？会 58 | 59 | ## Notes 60 | 61 | 62 | 63 | ### 2024.07.11 64 | 65 | 笔记内容 66 | 67 | ### 2025.01.06 68 | 69 | 1. 初步了解了 Optimism layer2。存款、取款 是通过 bridge 来完成的，存款很快就可以完成，取款需要 challenge period 给出时间挑战时间来验证交易是否有效 70 | 2. 目前还不知道 和 Arb 的 区别, 待后续进一步学习 71 | 72 | ### 2025.01.07 73 | 74 | 1. 对比了 Optimism 和 Arbitrum 区别 75 | 1. 都是使用了 Optimistic Rollup 来实现：假设某事为有效，直至其被证伪 76 | 2. 解决争议的方式不一样： 77 | 1. Optimism 会在 EVM 运行每笔交易，不能处理超过 EVM gas limit 的交易 78 | 2. Arbitrum 会经过多伦协商，将最后单步的断言发给 EVM 进行验证， 消耗更少的 gas 79 | 3. Optimism 解决争议的方式 更加简单，更加快速 80 | 81 | ### 2025.01.08 82 | 83 | 1. 学习了 文章 https://medium.com/l2beat/introducing-stages-a-framework-to-evaluate-rollups-maturity-d290bb22befe 引入了 Stage 的概念 来判断 rollup 的 成熟程度 84 | 1. Stage 0 还在中心化管理 85 | 2. Stage 1 过度到智能合约管理，但是安理会可以独自解决潜在的错误 86 | 3. Stage 2 完全由智能合约管理 87 | 88 | ### 2025.01.09 89 | 90 | 1. 阅读外部文章：Op 完全兼容 EVM ,严格执行 以太坊黄皮书，任何基于 Geth 编写的代码 都可以无需修改运行再 OP 上 91 | 2. 当运行验证节点，验证器在发现欺诈时会自动提交欺诈证明 92 | 93 | ### 2025.01.10 94 | 95 | 1. 阅读 https://community.optimism.io/welcome/welcome-overview 治理理念 96 | 1. 由 company 、communities、citizens 组成 的 collective 97 | 2. Superchain 标准化，推进了链的发展 98 | 3. 治理模型有 2 部分组成：Token house and Citizens’ House, 2 院治理体系 99 | 100 | ### 2025.01.11 101 | 102 | 1. 今天 看了下 Token house 和 Citizens’ House 2 院治理体 有什么区别， 分别刻意投票什么，没有特明白，希望可以解答一下 103 | 104 | ### 2025.01.12 105 | 106 | 1. 阅读 Superchain 基本介绍：https://docs.optimism.io/stack/explainer 107 | 1. Superchain 本质上是一个由多个采用 Optimism 的 OP Stack 构建的第二层（L2）区块链网络组成的集合 108 | 2. 把 OP 主网 和 其他链 合并到一个 统一的 OP 链中 (chains within the Superchain) 109 | 3. 相互之间是可以通信，标准的通信协议，共享的通信基础设置 110 | 4. 去中心化的需要，目前还不能完全满足，但是是可以实现的 111 | 5. Superchain 可以水平扩展多个链 112 | 113 | ### 2025.01.13 114 | 115 | 1. 阅读 https://docs.optimism.io/stack/getting-started 116 | 1. OP Stack 的基本概念：当前的核心是运行 L2 区块链的基础设施 117 | 2. OP Stack 是可持续发展的 118 | 119 | ### 2025.01.14 120 | 121 | 1. 看了 这个地址 https://www.superchain.eco/projects 有 100 个 superchain 项目，正好 100，是只收录这么多吗？ 122 | 2. 比较看好 Name Service,未来的基础设施。 找到了一个 SPACE ID Mode Name Service 项目，但是官网打不开 遗憾 123 | 124 | ### 2025.01.15 125 | 126 | 1. 推荐一个 玩转以太坊 L2 之 Op Stack https://www.bilibili.com/video/BV1vW4y1F75Z 127 | 128 | ### 2025.01.16 129 | 130 | 1. deploy you app get start https://docs.optimism.io/builders/app-developers/quick-start 131 | 132 | ### 2025.01.17 133 | 134 | 1. 今天想在 Superchain Faucet: https://console.optimism.io/faucet?utm_source=scaffoldop 领点水 部署合约，使用邮箱登录的时候, 一直提示 检查是否是真人，登录好久登不不上去。 135 | 136 | ![alt text](https://pic.wenjunjiang.com/202501172157416.png) 137 | 138 | ### 2025.01.18 139 | 140 | 1. 学习视频: 【OP 残酷共学：OP 建设之路】 https://www.youtube.com/watch?v=VGxzUxryiqE&ab_channel=LXDAO 141 | 1. 维护一个链比构建一个链难得多 142 | 2. 构建一个链，需要考虑很多方面，比如：有不同且有实际使用的功能、bridge security 等等 143 | 144 | ### 2025.01.19 145 | 146 | 1. 今天了解到 依托 coinbase 的 Base 链 ，竟然是使用 OP Stack 来构建的，而且已经加入的 Superchain 中了，牛 147 | 148 | ### 2025.01.20 149 | 150 | 1. Superchain Bridges：https://app.optimism.io/bridge/deposit 第三方服务商提供的，可以在 以 OP Stack 为基础构建链之间相互转账 151 | 1. https://www.brid.gg/op-mainnet 152 | 2. https://superbridge.app/optimism 153 | 154 | ### 2025.01.21 155 | 156 | 1. 在 Superchain 上面的 app 类型还挺还挺全的: Defi、NFT、Bridge、On-Ramp、Wallet、Infra、DAO 157 | 158 | ### 2025.01.22 159 | 160 | 1. 今天再看 optimistic.etherscan.io 的时候 想到： 有没有一个地方 可以看所有 加入 SuperChain 的链的信息，各种交易，而且可以看到各种链跨链交易的信息的关联关系 【想法，点子】 161 | 162 | ### 2025.01.24 163 | 164 | 1. 今天就一句话：**believe in somETHing** 165 | 166 | ### 2025.01.25 167 | 168 | 1. 不知道后面该学习啥了，X 上关注一波 Web3 相关的账号，后面多逛逛 169 | 170 | ### 2025.01.26 171 | 172 | 1. 最后一天了，收个尾. 祝大家新年快乐 173 | 174 | 175 | -------------------------------------------------------------------------------- /luffythink.md: -------------------------------------------------------------------------------- 1 | --- 2 | timezone: Asia/Shanghai 3 | --- 4 | 5 | # Oscar 6 | 7 | 1. A eco-lifelong learner. To surf🏄‍♀️ better in the Web3 world. Enjoy this challenging vibe and become cooler 🆒. 8 | 2. 你认为你会完成本次残酷学习吗？ Yes. 9 | 10 | ## Notes 11 | 12 | 13 | 14 | ### 2025.01.06 15 | 16 | 学习主题：Optimism 的基本概念 17 | 18 | - Optimism 使用的是OP Rollup，这是一种比较花哨的说法，指的是一个区块链，它利用另一个“父”区块链的安全保障。具体来说，OP Rollup 利用其父链（以太坊）的共识机制（例如工作量证明 PoW 或权益证明 PoS），而不是构建自己的共识机制。 19 | 20 | - Optimism 的核心在于一个基本假设：**大多数交易都是诚实的**。该系统基于这样的假设：提交到Rollup的交易是有效的。这种“乐观”的方法与其他 Layer-2 解决方案（如 ZK-Rollups）相比，最大限度地减少了计算开销，因为它不需要为每笔交易生成计算成本高昂的有效性证明。在Rollup的背景下，Optimism 的核心思想是用速度和成本效率来权衡立即验证，依靠激励系统和欺诈证明来确保系统的完整性。这是速度/成本和安全性之间的平衡。一些关键概念： 21 | * **Rollup：** Rollup 是一种 Layer-2 扩容解决方案，它在链下处理交易，然后将这些交易的汇总记录提交到主链（Layer-1）上。这减少了主链上的拥塞和交易费用。 22 | * **Optimistic Rollup** 处理交易时不会立即验证。在证明无效之前，它们被假定为有效。这使得交易更快更便宜。 23 | * **欺诈证明：** 如果有人提交了欺诈交易，任何人都可以通过提交*欺诈证明*来挑战它。该证明证明了交易的无效性，系统会撤销欺诈交易。提交欺诈证明的激励通常是奖励制度。 24 | * **挑战期：** 在交易批次提交到 Layer-1 区块链后，有一个时间窗口（挑战期）。在此期间，任何人都可以提交欺诈证明来挑战该批次中交易的有效性。如果在此期间没有提交欺诈证明，则该批次被视为最终确定。 25 | * **Sequencer：** 一个中心实体（或一组实体），称为排序器，负责排序和捆绑 Optimistic Rollup要处理的交易。排序器的作用至关重要，其潜在的恶意行为是系统设计和安全性的关键考虑因素。 26 | 27 | - OP Rollups 与 ZK-Rollups 区别： 28 | 29 | - **ZK-Rollups：** 这些使用零知识证明来密码学地证明交易的有效性，而无需透露交易细节。这提供了更高的安全级别，并且不依赖于挑战期。 30 | - **Optimistic Rollups：** 这些依赖于诚实行为的假设和欺诈证明机制。这通常比 ZK-Rollups 更快更便宜，但如果排序器是恶意的或欺诈交易没有及时挑战，则安全性较低。 31 | 32 | ### 2025.01.07 33 | 34 | 学习主题：Layer2 扩容方案 https://docs.optimism.io/stack/rollup/overview 35 | 36 | - OP Stack 是为 Optimism 提供支持的一套软件——目前以 OP 主网背后的软件实现的形式出现，最终将以 Optimism 超级链及其治理的形式出现。它由Optimism Collective维护，但是正变得越来越社区化，相关权利和职责正逐步向社区下放。随着超级链概念的出现，对于 Optimism 来说，轻松支持安全创建可在拟议的超级链生态系统中互操作的新链变得越来越重要。 因此，OP Stack 主要专注于创建一个共享的、高质量的、完全开源的系统，用于**创建新的 L2 区块链**。 通过协调共享标准，Optimism Collective可以避免在孤岛中重复构建相同的软件。 37 | - **OP Stack可以被视为软件组件，可以帮助定义 Optimism 生态系统的特定层，也可以充当现有层中的模块。** 尽管 OP Stack 当前的核心是运行 L2 区块链的基础设施，但 OP Stack 理论上可以扩展到底层区块链之上的层，包括区块浏览器、消息传递机制、治理系统等工具。 38 | 39 | ### 2025.01.08 40 | 41 | 学习主题：Superchain https://docs.optimism.io/stack/explainer 42 | 43 | - Superchain超级链是Optimism Collective 对 OP 未来发展方向的远景规划。具有超强可扩展性的去中心化计算能力是发展超级链的原始动力。 44 | 45 | - 超级链是一个 L2 链网络，称为 OP Chains，共享安全性、通信层和开源技术堆栈(未来也就是OP Stack)。然而，与多链设计不同，这些链是标准化的，旨在用作可互换的资源。这使得开发人员能够构建以整个超级链为目标的应用程序，并抽象出应用程序运行的底层链。 46 | 47 | ### 2025.01.10 48 | 49 | 学习主题：Stage 的介绍 https://medium.com/l2beat/introducing-stages-a-framework-to-evaluate-rollups-maturity-d290bb22befe 50 | 51 | 在不断发展的区块链技术领域，Rollup 已经成为以信任最小化方式扩展以太坊的有前景的解决方案。然而，这些系统的开发通常涉及一个中心化控制阶段，通常被称为“辅助轮”，这允许在受控环境中进行系统更新和错误修复。 52 | 53 | 虽然在早期阶段是必要的，“辅助轮”最终应该被移除，以便 Rollup 能充分继承底层的安全特性。为了指导这一过渡，引入了一个新的框架，其灵感来自 Vitalik 提出的里程碑，该框架根据 Rollup 对这些“辅助轮”的依赖程度将其分为三个不同的阶段： 54 | 55 | **阶段 0——完全依赖辅助轮：**在这个阶段，Rollup 有效地由运营商运行。尽管如此，仍然存在一个源代码公开的软件，允许根据 L1 上发布的数据重建状态，用于将状态根与建议的状态根进行比较。 56 | 57 | **阶段 1——有限依赖辅助轮：**在这个阶段，Rollup 向由智能合约治理过渡。然而，安全委员会可能仍然存在以解决潜在的错误。这个阶段的特点是实现了完全功能的证明系统、欺诈证明提交的去中心化以及无需运营商协调即可进行用户退出。安全委员会由各种各样的参与者组成，提供安全保障，但其权力也构成潜在风险。 58 | 59 | **阶段 2——无辅助轮：**这是最终阶段，Rollup 完全由智能合约管理。此时，欺诈证明系统是无需许可的，并且在发生意外升级的情况下，用户有充足的时间退出。安全委员会的角色严格限于处理可在链上裁决的健全性错误，并且用户受到保护，免受治理攻击。 60 | 61 | ### 2025.01.11 62 | 63 | 学习主题：https://learnblockchain.cn/article/3703 64 | 65 | 目前主要有四种技术方案：Optimistic Rollup、ZK Rollup、Plasma、Validium。每种方案都在安全、可扩展性、开发复杂性和去中心化之间进行权衡。“最佳”方案取决于项目的具体需求和优先级。ZK Rollup通常以其高安全性和快速最终确认而闻名，而Optimistic Rollup则被认为更易于开发。Plasma提供灵活性，但安全性更复杂。Validium为了提高速度牺牲了完全的去中心化。 66 | 67 | ### 2025.01.13 68 | 69 | 学习主题：治理理念 https://community.optimism.io/welcome/welcome-overview 70 | 71 | Optimism Collective 旨在通过构建一个由标准化链组成的可扩展超级链，并结合创新的“影响即利润”的经济模型和双重议院治理结构（Token House 和 Citizens' House），来创建一个更去中心化、更安全、更可持续的以太坊生态系统。其治理机制仍在不断迭代和完善中，并通过一系列文件来指导其发展。 Retro Funding 是其核心经济机制，奖励对生态系统做出贡献的个人和项目。 72 | 73 | 治理文件: 74 | 75 | - 《工作宪法》([Working Constitution](https://gov.optimism.io/t/working-constitution-of-the-optimism-collective/55)): 概述 Collective 的治理条款和原则。 76 | - 《运作手册》([Operating Manual](https://github.com/ethereum-optimism/OPerating-manual/blob/main/manual.md)): 描述 Token House 的当前治理流程，会随着 Collective 的发展而演变。 77 | 78 | ### 2025.01.14 79 | 80 | 学习主题：投票机制 https://github.com/ethereum-optimism/OPerating-manual/blob/main/manual.md 81 | 82 | Optimism Collective 的治理由两院组成：代币持有者议院 (Token House) 和公民议院 (Citizens’ House)。 83 | 84 | - 在代币持有者议院中，OP 持有者负责提交、审议和投票各种 Optimism Collective 治理提案。他们可以通过直接投票（在将其 OP 投票权委托给自己地址后）或将其 OP 投票权委托给符合条件的第三方来进行投票。拥有委托 OP 投票权的地址被称为“代表”。 85 | 86 | - 在公民议院中，Optimism 公民负责通过名为“追溯性公共产品资助”（Retro Funding）的流程向公共产品建设者分配奖励。参与 Retro Funding 3 并通过 AttestationStation 智能合约中的条目进行标记的徽章持有者现在是公民。公民身份目前是临时的。公民还负责对升级提案的否决进行投票。 87 | 88 | 所有代币持有者议院和公民议院的代表都应负责任地行使权力，并遵守 [Rules of Engagement](https://gov.optimism.io/t/rules-of-engagement-2-0/5728) and [Optimist Expectations](https://gov.optimism.io/t/optimist-expectations/7241). 89 | 90 | 代币持有者议院治理的主要工具目前包括： 91 | 92 | - **代币持有者议院治理合约 (Token House Governance Contract):** 代币持有者议院治理提案的链上投票合约。所有符合条件的代币持有者议院治理提案都将在此提交投票。 93 | - **Optimism 治理门户网站 (Optimism Governance Portal):** 一个前端界面，使代币持有者议院成员能够委托和投票他们的 OP。 94 | - **公民议院 Snapshot 空间 (The Citizens’ House Snapshot Space):** 一个前端界面，使公民议院成员能够否决代币持有者议院的提案。 95 | - **Optimism 论坛 (The Optimism Forum):** 一个讨论和审议治理提案的平台。 96 | - **Discord:** 用于非正式的治理讨论和反馈。 97 | - **Github:** 拨款（使命请求）通过此公共 github 存储库中的问题进行管理。 98 | - **Charmverse:** 社区主导的 Optimism 拨款委员会的所在地。 99 | 100 | 随着治理的演变，这些工具或其用途可能会随着时间而改变。例如，将来可能会开发专门用于治理委员会的其他用户界面。同样，虽然投票目前通过治理合约在链上进行，但成功的投票目前由 Optimism 基金会管理和实施，这种情况不应无限期持续下去。 101 | 102 | ### 2025.01.15 103 | 104 | 学习主题：投票机制 https://github.com/ethereum-optimism/OPerating-manual/blob/main/manual.md 105 | 106 | 了解委员会 https://gov.optimism.io/search?q=council 107 | 108 | - [Code of Conduct Council](https://gov.optimism.io/t/code-of-conduct-council-season-6-retrospective/9286) 109 | - [Security Council ](https://gov.optimism.io/t/security-council-communication-thread/7726) 110 | - [Grants **Council**](https://gov.optimism.io/t/grants-council-season-3-launch/4833) 111 | 112 | **Process TLDR** 113 | 114 | - Proposals are reviewed over a three week voting cycle. 115 | - If you’re submitting a grant application, you’ll need to submit your application as outlined on each individual Mission Request in [github.](https://github.com/ethereum-optimism/ecosystem-contributions/issues?q=is%3Aissue) 116 | - For all other proposal types, you may draft a proposal based on [this](https://gov.optimism.io/t/standard-proposal-template-optimism-token-house/5443) template and post it on the Forum with [Draft] in the title for feedback. Delegates and/or Citizens will provide feedback on your proposal in the forum. Use your judgment to incorporate feedback. 117 | - Once your non-grant proposal has been approved by four top 100 delegates or four Citizens add a link to your proposal to the Voting Cycle Roundup thread by the last day of Week 2 and update the title from [Draft] to [Final]. These proposals will move on to Week 3 voting. Proposals initiated by the Foundation do not require approvals. 118 | - Protocol or Governor Upgrades approved by the Token House, must also pass the Citizens’ House Veto Procedure, as outlined in the Veto Procedure section above, before they are considered officially approved. 119 | - The Security Council will enact officially approved Protocol or Governor Upgrades. The Optimism Foundation will facilitate the administration of all other approved proposals, including by distributing any approved OP grants. The Foundation will be in touch to collect additional information from your project in order to execute the proposal or grant, including information to perform KYC. 120 | - If your proposal is passed, the Optimism Foundation will facilitate its administration, including by distributing any approved OP grants. The Foundation will be in touch to collect additional information from your project in order to execute the proposal or grant, including information to perform KYC. 121 | - If your proposal fails, you can make a new proposal in the next cycle specifying how you have incorporated significant changes from your first proposal. 122 | 123 | **The Citizens’ House also manages the allocation of Retro Funding:** 124 | 125 | - Citizenship is currently temporary, with the Retro Funding 3 Citizens recorded via entries in the AttestationStation. 126 | - Retro Funding rounds occur in intervals and according to a predefined process, which currently includes phases for scoping, application creation, application review, voting, and disbursements. The Foundation will collect information from projects in order to distribute the grant, including information to perform KYC. 127 | 128 | ### 2025.01.16 129 | 130 | 学习主题：RetroPGF https://community.optimism.io/citizens-house/how-retro-funding-works 131 | 132 | 回溯式公共产品资助（Retro Funding）基于这样一个理念：相较于预测未来哪些项目有用，评估过去哪些项目有用更容易达成共识。这是一系列实验，Optimism Collective 的公民议会成员将剩余协议收入或 Retro Funding 代币分配的一部分，分配给那些他们认为对 Optimism Collective 和整个超级链产生了积极影响的项目。这是 Optimism “影响=利润”价值观的核心：**对集体产生积极影响应该与个人获得的利润成比例地奖励。** 133 | 134 | 这些奖励为人们构建有益于 Optimism Collective 的公共产品创造了强大的激励。其累积效应是一个更容易构建、学习和连接的生态系统，进而推动应用程序的使用并产生对区块空间的更多需求。通过可持续地资助公共产品，集体可以创建一个丰富的生态系统和更好的经济。 135 | 136 | ![](https://community.optimism.io/_next/image?url=%2F_next%2Fstatic%2Fmedia%2Fhow-retro-funding-works.9368ab75.png&w=3840&q=75) 137 | 138 | **对实验的承诺：奖励影响** 139 | 140 | 回溯式资助是对构建未来乐观主义者想要看到的未来的长期押注。集体将定期进行回溯式资助，每一轮都与上一轮不同。这是一个新兴的过程，需要社区参与才能发展和完善。 141 | 142 | - 回溯式资助第一轮于 2021 年底进行，向 58 个项目分配了 100 万美元。 143 | - 回溯式资助第二轮于 2023 年第一季度进行，向 195 个项目分配了 1000 万个 OP 代币。 144 | - 回溯式资助第三轮于 2023 年第四季度进行，向 501 个项目分配了 3000 万个 OP 代币。 145 | - 回溯式资助第四轮将于 2024 年第二/三季度进行，将奖励为 Optimism 的成功做出贡献的链上建设者。 146 | - 可在 [retrofunding.optimism.io](http://retrofunding.optimism.io/) 注册参与未来的轮次。 147 | 148 | **实验框架** 149 | 150 | 回溯式资助具有三个核心组成部分，每个部分都有大量的实验空间： 151 | 152 | - **影响范围界定：**集体应该资助什么？如何定义和决定？ 153 | - **影响评分：**公民议院如何评估影响？我们使用什么单位、流程或工具？ 154 | - **影响结算：**投票如何运作？ 155 | 156 | 在最初几轮回溯式资助中，Optimism 基金会将根据社区的意见决定范围和投票机制。最终，关于资助什么、资助多少以及如何投票的变量将由公民议院决定，并由代币议院进行制衡。您可以在此处阅读有关开放元治理路径的更多信息。随着时间的推移，集体旨在扩大回溯式资助的范围，以支持在 Optimism 生态系统之外生产公共产品。为了实现这一目标，我们必须根据定期的实验来改进回溯式资助中使用的工具和流程。 157 | 158 | ### 2025.01.17 159 | 160 | 学习主题：RetroPGF 获奖项目https://round6.retrolist.app/ 161 | 162 | Positive impact to the community should be rewarded with profit to the builder. 163 | 164 | - Governance Infra & Tooling 46 165 | - Governance Analytics 22 166 | - Leadership 20 167 | 168 | 乐观治理词汇表：[Optimism Governance Glossary - Get Started 🌱 - Optimism Collective](https://gov.optimism.io/t/optimism-governance-glossary/9407) 169 | 170 | - **反捕获委员会 (Anticapture Commission)**：反捕获委员会的职责是防止 Token House 被任何单一利益相关方或利益相关群体所控制。该委员会由具有重大影响力的个人代表组成，当发现利益相关群体之间的权力失衡时，它会向 Citizens’ House 发出警告。反捕获委员会使用来自治理基金的 1000 万 OP 进行投票，适用于所有可能受到 Citizens’ House 否决的提案。[了解更多](https://github.com/ethereum-optimism/OPerating-manual/blob/main/Anticapture Commission Charter v2.0.md) 171 | 172 | - **公民 (Citizen)**：公民是 Collective 的个人人类利益相关者，包括建设者、用户和社区成员。这些人群与项目价值观保持一致，并关注 Collective 的长期利益。公民拥有对协议升级的否决权，并将逐渐负责更多的治理决策。[了解更多](https://community.optimism.io/citizens-house/citizen-house-overview) 173 | 174 | - **Collective 反馈委员会 (Collective Feedback Commission)**：Collective 反馈委员会是一个实验性计划，旨在促进基金会与高背景贡献者之间在治理系统设计上的协作。目标是开发一个“核心治理计划 (Core Governance Program)”，以便 Collective 能够在未来承担元治理职责。委员会由活跃的公民和代表组成，受邀者基于其在相关领域的贡献和专业知识，通过基金会签发的认证证明。[了解更多](https://gov.optimism.io/t/the-collective-feedback-commission-the-next-iteration/9113) 175 | 176 | - **代表 (Delegate)**：代表构成了 Token House，他们负责对影响 Collective 的提案（如 OP Stack 升级、委员会成员选举、目标预算等）进行投票。他们由 OP 代币持有者委任，代表持有者做出治理决策。[查看代表](https://vote.optimism.io/delegates) 177 | 178 | - **开发者顾问委员会 (Developer Advisory Board)**：开发者顾问委员会由一群开发者组成，负责为技术提案提供反馈和指导。他们确保技术专业知识为治理决策提供依据，特别是在技术去中心化方面。委员会成员由 Token House 代表选举产生。[了解更多](https://github.com/ethereum-optimism/OPerating-manual/blob/main/Developer Advisory Board Charter v1.1.md) 179 | 180 | - **拨款委员会 (Grants Council)**：拨款委员会负责提议拨款预算、审核拨款申请并选择拨款接收者。成员对治理基金拨款流程拥有完整的决策权。委员会成员由 Token House 代表选举产生。[了解更多](https://github.com/ethereum-optimism/OPerating-manual/blob/main/Grants Council Charter v0.1.md) 181 | 182 | - **OP Stack 接近度排名 (OP Stack Proximity Ranking)**：这一实验性排名基于开发者和代码库与 OP Stack 代码库的接近程度进行评估。通过 GitHub 事件数据和双向信任图，应用 EigenTrust 和 Hubs & Authorities 算法的变体。信任通过用户行为（如星标、分叉）和贡献（如合并的 PR）构建。评分涵盖超过 3 万个代码库和 2000 个组织。OP Stack 接近度排名是与 OpenRank 和 Open Source Observer 合作开发的。[查看 OpenRank 文档](https://docs.openrank.com/integrations/github-developers-and-repo-ranking) 183 | 184 | - **安全委员会 (Security Council)**：安全委员会是一个去中心化的个人行动者小组，负责执行 Superchain 的共享升级。主要职能包括实施治理批准的协议升级和角色变更，并在紧急情况下独立行动以维护网络安全。委员会成员由 Token House 代表选举产生，并根据技术能力、声誉、地域多样性以及与 Optimistic Vision 的一致性进行评估。[了解更多](https://github.com/ethereum-optimism/OPerating-manual/blob/main/Security Council Charter v0.1.md) 185 | 186 | - **前 100 代表 (Top 100 Delegate)**：前 100 代表是拥有最多投票权的 Token House 前 100 名代表。[查看代表](https://vote.optimism.io/delegates) 187 | 188 | - **里程碑与指标委员会 (Milestones and Metrics Council)**：里程碑与指标委员会负责衡量获得拨款的项目是否完成里程碑任务，并向拨款委员会选出的接收者发放拨款。委员会成员由 Token House 代表选举产生。[了解更多](https://github.com/ethereum-optimism/OPerating-manual/blob/main/Milestones and Metrics Council Charter v0.1.md) 189 | 190 | ### 2025.01.20 191 | 192 | 学习主题：Superchain 基本介绍 https://docs.optimism.io/stack/explainer 193 | 194 | 超级链的概念：一个共享桥接、去中心化治理、升级、通信层等等的链网络——所有这些都构建在OP Stack之上。超级链的启动将把OP主网和其他链合并成一个统一的OP链网络（即超级链中的链），标志着向为世界带来可扩展和去中心化计算迈出的重要一步。 195 | 196 | Optimism 的超级链旨在通过创建一个共享安全、通信层和开源技术栈的 L2 链网络来解决区块链的可扩展性问题。 虽然超级链的发布将是一个重要的里程碑，但仍需解决一些关键痛点，例如依赖可信证明者、跨链交易速度慢和异步性、L1 的容量限制、缺乏易于使用的开发和钱包工具等。 解决这些问题将使构建复杂 Web2 应用的去中心化替代方案成为可能，最终实现完全可扩展的区块链愿景。 197 | 198 | Superchain 致力于通过**标准化和模块化的技术栈**（OP Stack）来实现跨链数据和资产的无缝流转，同时共享以太坊的安全和资源，从而在 L2/L3 多链世界中形成规模化网络效应。 199 | 200 | Superchain 内的每条链都需要将排序器（Sequencer）总收入或利润的 15% 支付给 **Optimism Collective**，以在多链之间聚合流动性并引导形成更大网络效应。 201 | 202 | ### 2025.01.21 203 | 204 | 学习主题：OP Stack 基本概述 https://docs.optimism.io/stack/getting-started 205 | 206 | OP Stack是驱动Optimism的软件集合——目前以OP主网背后的软件形式存在，最终将以Optimism超级链及其治理的形式存在。随着超级链概念的出现，Optimism轻松支持在拟议的超级链生态系统中互操作的新链的安全创建变得越来越重要。因此，OP Stack主要关注于创建一个共享的、高质量的和完全开源的系统，用于创建新的L2区块链。通过协调共享标准，Optimism Collective可以避免重复地在孤岛中重建相同的软件。 207 | 208 | OP Stack大大简化了创建L2区块链的过程，但重要的是要注意，这并没有从根本上定义OP Stack是什么。OP Stack是所有驱动Optimism的软件。随着Optimism的发展，OP Stack也将发展。OP Stack可以被认为是软件组件，这些组件要么帮助定义Optimism生态系统的特定层，要么作为现有层中的模块发挥作用。 209 | 210 | OP Stack当前的核心是运行L2区块链的基础设施，但理论上OP Stack扩展到底层区块链之上的层，包括区块浏览器、消息传递机制、治理系统等工具。**层通常在堆栈底部（如数据可用性层）定义得更严格，但在堆栈顶部（如治理层）定义得更宽松。** 211 | 212 | OP Stack是一个不断发展的概念。随着Optimism的发展，OP Stack也将发展。今天，OP Stack的Bedrock版本简化了部署新的L2 Rollup的过程。随着对堆栈工作的继续，插入和配置不同的模块应该会更容易。随着超级链开始成形，OP Stack可以与其一起发展，以包含允许不同链无缝互操作的消息传递基础设施。最终，OP Stack将成为Optimism所需的东西。 213 | 214 | ### 2025.01.22 215 | 216 | 学习主题：体验和分析一下 Superchain 项目 https://www.superchain.eco/projects 217 | 218 | [DeFiLlama](https://www.superchain.eco/ecosystem-projects/defillama) 是一个自筹资金的开源平台，提供超过 240 个区块链上 3000 多个DeFi项目的实时、透明数据。它没有正式的治理结构和原生代币，依靠 grants for funding 。其价值主张是通过社区协作，为用户提供准确和全面的 DeFi 分析数据。 219 | 220 | DefiLlama 的主要功能包括： 221 | 222 | - **实时数据：** DefiLlama 持续更新其数据，提供关于 DeFi 项目的最新信息。 223 | - **多链支持：** 它支持许多不同的区块链，包括以太坊、币安智能链、Polygon 等。 224 | - **全面数据：** 它提供各种 DeFi 项目指标，例如 TVL、交易量、流动性、代币价格等。 225 | - **开源：** DefiLlama 的代码是开源的，这允许社区贡献和审核其数据。 226 | - **易于使用：** 其网站和 API 设计直观易用，方便用户访问和使用数据。需要注意的是，DefiLlama 的数据依赖于各个 DeFi 项目提供的 API，因此数据的准确性和完整性取决于这些 API 的质量。 227 | 228 | ### 2025.01.23 229 | 230 | 学习主题：了解 Superchain Eco 超级链指数 https://www.superchain.eco/superchain-index 231 | 232 | 旨在为以太坊生态系统提供清晰的链状态可视化。该指数根据链的配置和标准性，将链分为三种状态： 233 | 234 | 1. 绿色链：完全符合标准要求，使用最新治理批准的 OP Stack 版本，由安全委员会管理桥接升级。 235 | 2. 黄色链：标准配置，但仍在完成最终升级或安全委员会迁移。 236 | 3. 灰色链：使用旧版本或偏离标准配置，但仍为生态系统做出贡献。 237 | 238 | 关键重点： 239 | 240 | - 仅绿色和黄色链构成"Superchain" 241 | - 灰色链可以通过逐步调整达到标准要求 242 | - Season 7 将仅支持标准化和安全委员会的链 243 | - 目标是促进生态系统互操作性和标准化 244 | 245 | 目前只看到 OP Mainnet 处于 Stage1 阶段，大多数还是 Stage 0 阶段。 246 | 247 | ### 2025.01.24 248 | 249 | 学习主题： [Superchain 指标](https://s.foresightnews.pro/article/detail/70608) 250 | 251 | 为了将这一探索建立在看得见的数据的基础上指向 Superchain 主导地位的关键指标： 252 | 253 | - 生态系统增长率：Superchain 的开发活动同比增长了 200%。 254 | - 互操作性里程碑：Superchain 内部跨链交易的确认时间减少了 30%，大大增强了用户体验。 255 | - 经济对齐：收入共享模式已经通过参与链为 Optimism 网络注入了超过 5000 万美元，推动了进一步的发展。 256 | - 安全性增强：**模块化 OP Stack 支持快速部署安全升级，与孤立的 L2 解决方案相比**，漏洞减少 40%。 257 | - 用户采用：Superchain 网络在累计用户维度仅在上季度就实现了 100 万用户的增长。 258 | 259 | Op-stack 主要的rollup由两个服务来承担： 260 | 261 | - op-batcher：负责将每隔一段时间读取sequencer上的交易内容，rollup到链上DA 262 | - op-proposer：负责将交易状态rollup到合约。 263 | 264 | ![image.png](https://img.learnblockchain.cn/attachments/2024/06/15fp0ZQ6665ddad8ca47c.png) 265 | 266 | 267 | 268 | ### 2025.01.26 269 | 270 | OP 残酷共学小结：很多知识还需消化 271 | 272 | - 从 Optimism 的基本概念，理解了 Layer2 如何作为以太坊的扩容方案，有效缓解主网拥堵和高昂的 gas 费用。 重点了解了 Optimism Rollups 的技术原理，以及其与其他 Layer2 解决方案的差异。 了解了 Optimism 的发展 Stage 阶段，以及每个阶段的目标和里程碑。同时也了解了 Optimism 的 Tokenomics，包括 OP 代币的用途、分配机制和未来发展规划。 273 | - 学习了 Optimism 的治理理念，了解了其投票机制，以及由 Citizens' House 和 Token House 组成的议会构成。 尤其是 Optimism 的核心机制 RetroPGF，即回溯式公共产品资助，理解其如何激励公共产品建设并促进生态系统发展。 274 | - 基于 Op Stack 模块化，了解其各个组成部分和功能，以及如何简化 L2 区块链的创建和部署。最后是对 Optimism 的 Superchain 生态进行了学习，了解其愿景和目标，以及如何通过 OP Stack 来构建一个安全、可扩展和互联互通的超级链网络。 275 | 276 | 超级链是去中心化技术的复兴，超级链是当今 L2 扩展解决方案中不可否认的领军者，但要走的路还很长。相信随着超级链的网络效应持续扩大，它的吸引力将使其他替代解决方案越来越难以转移创新流和用户采用。非常期待。 277 | 278 | 279 | 280 | 281 | -------------------------------------------------------------------------------- /pillowtalk-Qy.md: -------------------------------------------------------------------------------- 1 | --- 2 | timezone: Asia/Shanghai 3 | --- 4 | 5 | > 请在上边的 timezone 添加你的当地时区，这会有助于你的打卡状态的自动化更新，如果没有添加，默认为北京时间 UTC+8 时区 6 | > 时区请参考以下列表，请移除 # 以后的内容 7 | 8 | timezone: Pacific/Honolulu # 夏威夷-阿留申标准时间 (UTC-10) 9 | 10 | timezone: America/Anchorage # 阿拉斯加标准时间 (UTC-9) 11 | 12 | timezone: America/Los_Angeles # 太平洋标准时间 (UTC-8) 13 | 14 | timezone: America/Denver # 山地标准时间 (UTC-7) 15 | 16 | timezone: America/Chicago # 中部标准时间 (UTC-6) 17 | 18 | timezone: America/New_York # 东部标准时间 (UTC-5) 19 | 20 | timezone: America/Halifax # 大西洋标准时间 (UTC-4) 21 | 22 | timezone: America/St_Johns # 纽芬兰标准时间 (UTC-3:30) 23 | 24 | timezone: America/Sao_Paulo # 巴西利亚时间 (UTC-3) 25 | 26 | timezone: Atlantic/Azores # 亚速尔群岛时间 (UTC-1) 27 | 28 | timezone: Europe/London # 格林威治标准时间 (UTC+0) 29 | 30 | timezone: Europe/Berlin # 中欧标准时间 (UTC+1) 31 | 32 | timezone: Europe/Helsinki # 东欧标准时间 (UTC+2) 33 | 34 | timezone: Europe/Moscow # 莫斯科标准时间 (UTC+3) 35 | 36 | timezone: Asia/Dubai # 海湾标准时间 (UTC+4) 37 | 38 | timezone: Asia/Kolkata # 印度标准时间 (UTC+5:30) 39 | 40 | timezone: Asia/Dhaka # 孟加拉国标准时间 (UTC+6) 41 | 42 | timezone: Asia/Bangkok # 中南半岛时间 (UTC+7) 43 | 44 | timezone: Asia/Shanghai # 中国标准时间 (UTC+8) 45 | 46 | timezone: Asia/Tokyo # 日本标准时间 (UTC+9) 47 | 48 | timezone: Australia/Sydney # 澳大利亚东部标准时间 (UTC+10) 49 | 50 | timezone: Pacific/Auckland # 新西兰标准时间 (UTC+12) 51 | 52 | --- 53 | 54 | # {Qy} 55 | 56 | 1. 自我介绍：我是Qy 57 | 58 | 2. 你认为你会完成本次残酷学习吗？会的 59 | 60 | ## Notes 61 | 62 | 63 | 64 | ### 2025.01.06 65 | 66 | 1.在 Bedrock 中，sequencer 确实有一个内存池，类似于以太坊的 L1，但内存池是私有的，以避免为 MEV 提供机会。在 OP 主网中，每两秒生成一次区块，无论它们是空的（没有交易）、用交易填充到区块 gas 限制，还是介于两者之间。 67 | 交易通过两种方式到达排序器： 68 | a.交易直接提交给排序器。这些交易的提交成本要低得多，因为它们不需要单独的 L1 交易。然而，它们无法抗审查，因为排序器是唯一知道它们的参与者。 69 | 70 | b.在 L1 上提交的交易（称为存款）包含在相应的 L2 块中的链中。每个 L2 块都由“纪元”（它对应的 L1 块，通常在 L2 块之前几分钟发生）及其在该纪元内的序列号标识。纪元的第一个块包括它对应的 L1 块中发生的所有存款。如果序列器试图忽略合法的 L1 交易，它最终会得到与验证者不一致的状态，就像序列器试图通过其他方式伪造状态一样。这为 OP Mainnet 提供了 L1 以太坊级别的审查阻力。 71 | 72 | 2.Optimism 的设计目的是让用户可以在 L2（OP Mainnet、OP Sepolia 等）和底层 L1（以太坊主网、Sepolia 等）上的智能合约之间发送任意消息。这使得在两个网络之间转移 ETH 或代币（包括 ERC20 代币）成为可能。这种通信发生的确切机制因消息发送的方向而异。OP Mainnet 在标准桥中使用此功能，允许用户将代币从以太坊存入 OP Mainnet，并允许将相同的代币从 OP Mainnet 提取回以太坊。 73 | 74 | 3.故障证明 75 | a.在 Optimistic Rollup 中，状态承诺会发布到 L1（OP 主网的情况下为以太坊），而无需任何直接证明这些承诺的有效性。相反，这些承诺在一段时间内（称为“挑战窗口”）被视为待定。如果提议的状态承诺在挑战窗口期间（目前设置为 7 天）没有受到质疑，则该承诺被视为最终承诺。一旦承诺被视为最终承诺，以太坊上的智能合约就可以安全地接受基于该承诺的有关 OP 主网状态的提款证明。 76 | 77 | b.当国家承诺受到质疑时，可以通过“过错证明”（以前称为“欺诈证明”）使其无效) 流程。如果成功挑战了承诺，则将其从列表中移除，StateCommitmentChain最终由另一个提议的承诺替换。需要注意的是，成功的挑战不会回滚 OP Mainnet 本身，只会回滚已发布的有关链状态的承诺。交易的顺序和 OP Mainnet 的状态不会因故障证明挑战而改变。 78 | 79 | ### 2024.01.06 80 | 81 | ### 2025.01.07 82 | 83 | 笔记内容 84 | 85 | ### 2024.01.07 86 | 87 | ### 2025.01.08 88 | 89 | 批量提交和排序：交易由排序器收集并排序成批次。然后，这些批次被提交到第 1 层 (L1) 进行最终确认并纳入区块链。 90 | 安全头和不安全块：派生管道维护两种类型的头：安全头和不安全头。安全头表示 L1 上最新的确认状态，而不安全块是已排序但尚未在 L1 上确认的块。 91 | 重组和恢复：如果超出排序窗口（通常为 12 小时），而 L1 上未发现有效批次，则管道将恢复该期间的所有不安全区块。然后，管道使用除存款外为空的默认区块继续运行，从而使网络恢复并继续处理新交易。 92 | 93 | ### 2024.01.08 94 | 95 | ### 2025.01.09 96 | 97 | 笔记内容 98 | 99 | ### 2024.01.09 100 | 101 | ### 2025.01.10 102 | 103 | 笔记内容 104 | 105 | ### 2024.01.10 106 | 107 | ### 2025.01.11 108 | 109 | 笔记内容 110 | 111 | ### 2024.01.11 112 | 113 | ### 2025.01.12 114 | 115 | 笔记内容 116 | 117 | ### 2024.01.12 118 | 119 | ### 2025.01.13 120 | 121 | 笔记内容 122 | 123 | ### 2024.01.13 124 | 125 | ### 2025.01.14 126 | 127 | 笔记内容 128 | 129 | ### 2024.01.14 130 | 131 | ### 2025.01.15 132 | 133 | 笔记内容 134 | 135 | ### 2024.01.15 136 | 137 | ### 2025.01.16 138 | 139 | 笔记内容 140 | 141 | ### 2024.01.16 142 | 143 | ### 2025.01.17 144 | 145 | 笔记内容 146 | 147 | ### 2024.01.17 148 | 149 | 150 | -------------------------------------------------------------------------------- /qiaopengjun5162.md: -------------------------------------------------------------------------------- 1 | --- 2 | timezone: Asia/Shanghai # 中国标准时间 (UTC+8) 3 | --- 4 | 5 | > 请在上边的 timezone 添加你的当地时区，这会有助于你的打卡状态的自动化更新，如果没有添加，默认为北京时间 UTC+8 时区 6 | > 时区请参考以下列表，请移除 # 以后的内容 7 | 8 | timezone: Pacific/Honolulu # 夏威夷-阿留申标准时间 (UTC-10) 9 | 10 | timezone: America/Anchorage # 阿拉斯加标准时间 (UTC-9) 11 | 12 | timezone: America/Los_Angeles # 太平洋标准时间 (UTC-8) 13 | 14 | timezone: America/Denver # 山地标准时间 (UTC-7) 15 | 16 | timezone: America/Chicago # 中部标准时间 (UTC-6) 17 | 18 | timezone: America/New_York # 东部标准时间 (UTC-5) 19 | 20 | timezone: America/Halifax # 大西洋标准时间 (UTC-4) 21 | 22 | timezone: America/St_Johns # 纽芬兰标准时间 (UTC-3:30) 23 | 24 | timezone: America/Sao_Paulo # 巴西利亚时间 (UTC-3) 25 | 26 | timezone: Atlantic/Azores # 亚速尔群岛时间 (UTC-1) 27 | 28 | timezone: Europe/London # 格林威治标准时间 (UTC+0) 29 | 30 | timezone: Europe/Berlin # 中欧标准时间 (UTC+1) 31 | 32 | timezone: Europe/Helsinki # 东欧标准时间 (UTC+2) 33 | 34 | timezone: Europe/Moscow # 莫斯科标准时间 (UTC+3) 35 | 36 | timezone: Asia/Dubai # 海湾标准时间 (UTC+4) 37 | 38 | timezone: Asia/Kolkata # 印度标准时间 (UTC+5:30) 39 | 40 | timezone: Asia/Dhaka # 孟加拉国标准时间 (UTC+6) 41 | 42 | timezone: Asia/Bangkok # 中南半岛时间 (UTC+7) 43 | 44 | timezone: Asia/Shanghai # 中国标准时间 (UTC+8) 45 | 46 | timezone: Asia/Tokyo # 日本标准时间 (UTC+9) 47 | 48 | timezone: Australia/Sydney # 澳大利亚东部标准时间 (UTC+10) 49 | 50 | timezone: Pacific/Auckland # 新西兰标准时间 (UTC+12) 51 | 52 | --- 53 | 54 | # {你的名字} 55 | 56 | 1. 自我介绍 57 | 大家好，我是 Paxon Qiao，来自中国，是一名Web3开发工程师。我热爱编程，喜欢挑战自我，不断学习新技术。我期待在这次残酷学习中，能够与大家共同进步，互相学习，共同成长。 58 | 59 | 2. 你认为你会完成本次残酷学习吗？ 60 | 我会，我相信我可以完成这次残酷学习。我对 Web3 生态感兴趣，对 blockchain 技术有所涉�及，并且有丰富的编程经验。我相信，只要我坚持不懈，努力学习，我一定能够完成这次残酷学习，并取得优异的成绩。 61 | 62 | ## Notes 63 | 64 | 65 | 66 | ### 2025.01.06 67 | 68 | Rollups 通过将大量交易打包到一个单一交易中，并将其提交到主链。这种方法可以分为两种类型：乐观 Rollups（Optimistic Rollups）和零知识 Rollups（zk-Rollups）。 69 | 70 | - Op Rollups：假设交易是有效的，只有在有争议时才进行验证 71 | - Zk Rollups：通过零知识证明技术，在提交交易数据的同时，保证其正确性。 72 | 73 | ### 2025.01.07 74 | 75 | Optimistic Rollups 是一种基于承诺链（commit chain）和执行链（execution chain）的 Layer2 扩展方案。它将大量交易数据存储在链外的执行链上，并定期将执行结果提交到链上的承诺链中。通过链外计算和链上争议解决机制，Optimistic Rollups 实现了高性能的智能合约执行，同时保留了以太坊的去中心化特性。 76 | 77 | ### 2025.01.08 78 | 79 | Op-stack 主要由 op-node, op-geth, op-batcher, op-proposer, CrossDomainMessenger, OptimismPortal, Bridge contracts 和 L2OutputOracle contract 等角色组成 80 | 81 | ### 2025.01.09 82 | 83 | Op-stack 的 rollup 由两个服务来承担 84 | 85 | op-batcher 服务：主要职责是负责将交易数据提交到 Layer1 的 EOA 地址 86 | op-proposer 服务：主要职责是负责将交易状态提交到 Layer1 的 L2OutputOracle 合约 87 | 88 | ### 2025.01.10 89 | 90 | 信使合约的主要功能是跨链通信，核心方法位 sendMessage 与 relayMessage； 91 | sendMessage: 将包裹的消息从源链发送到目标链上，维护自增的 msgNonce, 确报跨链消息的唯一性和安全性 92 | relayMessage: 将源链发过来的消息在目标链上构建 MsgHash 对比，确保消息的一致性之后在目前链上调度执行该消息 在 op-stack 中在 L1 和 L2 层分别有 93 | L1CrossDomainMessenger 94 | L2CrossDomainMessenger 继承自 CrossDomainMessenger 合约，来承载跨链通信 95 | 96 | ### 2025.01.11 97 | 98 | Optimism 是以太坊的第 2 层 （L2） 扩展解决方案，旨在以低廉的成本提供闪电般的交易速度。旨在推动以太坊的愿景，通过透明和可持续的区块链实现去中心化，为公众创造利益。 99 | 100 | 作为 L2，Optimism 建立在以太坊架构之上。因此，它相当于以太坊虚拟机，是以太坊主层的最小延伸。通过这种方式，开发者和加密货币用户能够以低费用享受快速交易，同时享受以太坊架构的安全性。 101 | 102 | Optimism 现旨在通过一个名为 Superchain 的平台进一步增强其可扩展性，该平台由基于 OP Stack 构建的链网络组成，该网络将其 OP 主网与其他 L2 链合并。作为超级链，Optimism 旨在打造可互操作且可组合的生态系统，简化 L2s 的集成。 103 | 104 | ### 2025.01.12 105 | 106 | 用户调用 SDK 获取提现交易的状态，若状态为 READY_TO_PROVE, 说明交易可以进行证明； 用户可以调用 SDK 的 proveMessage 去进行交易的证明，或者直接 call OptimismPortal 合约 proveWithdrawalTransaction 方法进行交易的证明，当证明交易产生之后，等到交易过了挑战期，交易状态会变成 READY_FOR_RELAY；这个时候用户可以调用 SDK 的 finalizeMessage 方法进行资金的 Claim, 也可以直接调用 OptimismPortal 合约的 finalizeWithdrawalTransaction 方法进行资金的 Claim。 107 | 108 | ### 2025.01.13 109 | 110 | 充值交易会调用到 depositTransaction; depositTransaction 会抛出 TransactionDeposited 事件，事件里面携带信息如下 emit TransactionDeposited(from, _to, DEPOSIT_VERSION, opaqueData); op-node 监听到该合约事件之后，会在二层去执行充值交易 111 | 112 | ### 2025.01.14 113 | 114 | Rollup : 115 | 116 | 1. 提交交易数据到DA 117 | 2. 提交交易状态到L1 118 | 119 | ### 2025.01.15 120 | 121 | 排序器（Sequencer）是以太坊扩容方案 Rollup 中的核心组件之一，负责对交易进行排序，并执行区块创建、交易接受、交易排序、交易执行以及交易数据提交等相关任务。 122 | Sequencer：交易排序器 123 | 交易落块 124 | 第一笔交易是充值的交易 125 | verifier：交易验证器 126 | 127 | ### 2025.01.16 128 | 129 | verifier：交易验证器 130 | 根据交易生成证明，验证交易是否有效，如果无效则提交到以太坊上验证 131 | 132 | ### 2025.01.17 133 | 134 | RPC: 转发用户发送的交易，提供对外的服务 135 | ZK Prover：零知识证明器，生成证明 op-code 电路 链下交易证明生成器 136 | 137 | ### 2025.01.18 138 | 139 | Sequencer：交易排序器 提交交易数据到DA, 提交交易状态到L1 140 | verifier：交易验证器 链下交易证明生成器 141 | 142 | ### 2025.01.19 143 | 144 | ZK Prover：零知识证明器，生成证明 op-code 电路 链下交易证明生成器 145 | DA: 数据 availability layer 146 | 纠删码：纠删码是一种数据编码技术，用于对数据进行编码，以减少数据丢失的概率。 147 | bls 签名：bls 签名是一种签名算法，它使用一对密钥对（公钥和私钥）来对数据进行签名。聚合签名是一种签名技术，它允许多个签名者对同一数据进行签名，并使用这些签名来验证数据的完整性和真实性。 148 | 共识：共识是一种协议，它定义了如何确定一个网络中的成员是否一致。 149 | 重新质押：重新质押是一种机制，它允许用户在网络中重新质押其质押的代币，以获得更多的奖励。 150 | kzg 证明：kzg 证明是一种零知识证明技术，它允许用户对数据进行签名，而不需要公开数据。 151 | 152 | ### 2025.01.20 153 | 154 | DAC 155 | 以太坊 2.0 LSD Eigenlayer 重新质押 继承了以太坊的共识安全性，实现了对智能合约的透明性，并允许用户重新质押其质押的代币以获得更多的奖励。 156 | ovm Op-stack 157 | Optimism 是以太坊的第 2 层（L2）扩展解决方案，旨在以低廉的成本提供闪电般的交易速度。Optimism 通过在以太坊架构之上构建一个名为 Superchain 的平台，将 OP 主网与其他 L2 链合并，从而实现可互操作且可组合的生态系统，简化 L2s 的集成。 158 | ovm 159 | ctc scc 160 | batch-submitted 161 | sequencer proposal dtt 162 | l2 geth(seq) verifier rpc 163 | 164 | ### 2025.01.21 165 | 166 | 同步充值数据 167 | 同步交易数据 168 | 状态通道 169 | 侧链 170 | 侧链是一条独立的链 171 | Rollups 172 | 173 | Layer2 174 | 扩展性 175 | 成本降低 176 | 提高速度 177 | 安全性 178 | 179 | ### 2025.01.22 180 | 181 | DataAvailabilityChallenge 数据挑战 EIP4844 182 | mantle/manta L2OutputOracle 183 | DisputeGameFactory 欺诈挑战 184 | OptimismPortal2 185 | L1CrossDomainMessenger 信使合约 186 | L1StandardBridge 桥 187 | 188 | op-batcher 服务：负责将交易数据提交到 DA EIP4844 DataAvailabilityChallenge 189 | op-proposer 服务：负责将交易状态定期提交到 Layer1 的 L2OutputOracle 合约 190 | Sequencer：交易排序器 提交交易数据到DA, 提交交易状态到L1 191 | op-node：监听同步 l1 区块 192 | op-geth 193 | engineAPI 194 | 195 | Verifier：交易验证器 链下交易证明生成器 196 | RPC 197 | 数据炸弹（Data Bomb）通常指的是一种恶意软件或攻击手段，它通过在数据中嵌入恶意代码或指令，导致在特定条件下触发并执行这些代码，从而造成数据损坏、系统崩溃或其他不良后果。数据炸弹可以在特定时间、特定事件或特定条件下被激活，给系统带来潜在的威胁。 198 | 在某些情况下，数据炸弹也可以指代一种数据结构或算法的设计缺陷，导致在处理数据时出现性能问题或资源耗尽的情况。 199 | 200 | op-node 是 Optimism 的一个核心组件，负责处理 Layer 2 的交易和状态更新。它监听以太坊主链（Layer 1）上的事件，并在 Layer 2 上执行相应的操作。op-node 主要负责将交易数据提交到 Layer 1 的地址，并处理与 Layer 2 相关的所有事务。 201 | 202 | op-geth 是 Optimism 的一个以太坊客户端，基于 Go-Ethereum（Geth）构建。它用于支持 Optimism 的 Layer 2 解决方案，提供与以太坊主链的交互能力。op-geth 处理与以太坊网络的连接，执行智能合约，并支持 Optimism 的特定功能。 203 | 204 | Sequence 是交易处理的一个重要概念，而 op-node 和 op-geth 是实现这一概念的具体技术组件。 205 | 206 | ### 2025.01.23 207 | 208 | 链下模块协同找到不一样 OpCode 209 | 进行要 rollup 的 start 和 end 的组合，allUnsafeBlocks = &inclusiveBlockRange{newSyncStatus.SafeL2.Number + 1, newSyncStatus.UnsafeL2.Number} 210 | 若历史的块都处理完成了，直接返回 allUnsafeBlocks 即可 211 | 判断上一次没有 rollup 区块，这种情况需要清理 state, 处理 channel 和队列的 safe block 处理 212 | 213 | ### 2025.01.24 214 | 215 | op-batcher 会从 op-node syncStatus, 从 op-geth syncData 获取数据，然后进行打包，打包完成之后，会调用 op-node 的 submitBatch 方法，将打包好的数据提交到 DA 216 | 217 | ### 2025.01.25 218 | 219 | 把数据提交到 EIP4844 220 | safe 221 | unsafe 222 | finalize 223 | 数据摘要 224 | 提交数据承诺 欺诈证明 7天 225 | 226 | ### 2025.01.26 227 | 228 | op-batcher 会从 op-node syncStatus, 从 op-geth syncData 获取数据，然后进行打包，打包完成之后，会调用 op-node 的 submitBatch 方法，将打包好的数据提交到 DA 229 | Rollup Services 运行在 L2 上，负责处理 L2 上的交易和状态更新。它与 L1 的交互通过 RPC 协议进行，并通过引擎 API 与 L1 的引擎节点进行通信。Rollup Services 主要负责将交易数据提交到 L1 的地址，并处理与 L2 相关的所有事务。 230 | 充值交易会调用到 depositTransaction; depositTransaction 会抛出 TransactionDeposited 事件，事件里面携带信息如下 emit TransactionDeposited(from, _to, DEPOSIT_VERSION, opaqueData); op-node 监听到该合约事件之后，会在二层去执行充值交易 231 | 提现交易会调用到 withdrawTransaction; withdrawTransaction 会抛出 WithdrawalInitiated 事件，事件里面携带信息如下 emit WithdrawalInitiated(from, _to,_amount); op-node 监听到该合约事件之后，会在二层去执行提现交易 232 | 233 | 234 | -------------------------------------------------------------------------------- /stualan.md: -------------------------------------------------------------------------------- 1 | # {stualan} 2 | 3 | 1. 一个web3技术学习者 4 | 2. 你认为你会完成本次残酷学习吗？会，学习op中的设计思想和一些治理相关的内容 5 | 6 | ## Notes 7 | 8 | 9 | 10 | ### 2025.01.06 11 | 12 | - 阅读[OP Rollup设计](https://docs.optimism.io/stack/rollup/overview)理念文档 13 | --- 14 | 15 | ## **Optimism Rollup 概述** 16 | 17 | Optimism Rollup 是一种 Layer 2 扩展解决方案，旨在提高以太坊的可扩展性，同时保持与以太坊主网的高度安全性和兼容性。它通过将交易批量处理并压缩后提交到以太坊主网，显著降低了交易成本并提高了吞吐量。 18 | 19 | --- 20 | 21 | ### **核心概念** 22 | 23 | 1. **Rollup 技术** 24 | - Rollup 是一种 Layer 2 扩展技术，将大量交易数据压缩后提交到以太坊主网。 25 | - 交易执行在链下进行，但数据存储在链上，确保安全性和透明性。 26 | - Optimism 使用 **Optimistic Rollup**，默认假设所有交易有效，除非有人提交欺诈证明。 27 | 28 | 2. **Optimistic Rollup 的特点** 29 | - **低成本**：通过批量处理交易，减少以太坊主网的 Gas 费用。 30 | - **高吞吐量**：链下执行交易，显著提高交易处理速度。 31 | - **安全性**：依赖以太坊主网的安全性，通过欺诈证明机制确保交易有效性。 32 | 33 | 3. **欺诈证明（Fraud Proof）** 34 | - 如果有人提交无效交易，其他节点可以生成欺诈证明，挑战该交易。 35 | - 挑战成功后，无效交易会被回滚，恶意行为者会受到惩罚。 36 | 37 | 4. **EVM 等效性** 38 | - Optimism Rollup 完全兼容以太坊虚拟机（EVM），开发者可以无缝迁移以太坊 DApp。 39 | - 支持所有以太坊工具和基础设施（如 MetaMask、Truffle 等）。 40 | 41 | --- 42 | 43 | ### **Optimism Rollup 的架构** 44 | 45 | 1. **Sequencer（排序器）** 46 | - 负责接收用户交易，排序并批量提交到以太坊主网。 47 | - 提供即时交易确认，优化用户体验。 48 | 49 | 2. **Verifier（验证者）** 50 | - 验证链下交易的有效性，确保与以太坊主网状态一致。 51 | - 在发现无效交易时生成欺诈证明。 52 | 53 | 3. **数据可用性** 54 | - 所有交易数据都存储在以太坊主网上，确保透明性和可验证性。 55 | - 即使 Layer 2 节点离线，用户也可以从主网恢复数据。 56 | 57 | 4. **跨链通信** 58 | - 通过 **L1 和 L2 之间的消息传递**，实现资产和数据的跨链转移。 59 | - 用户可以将资产从以太坊主网存入 Optimism Rollup，或从 Rollup 提现到主网。 60 | 61 | 62 | ### **Optimism Rollup 的优势** 63 | 64 | 1. **低成本** 65 | - 通过批量处理和压缩交易，显著降低 Gas 费用。 66 | - 适合高频交易和小额支付场景。 67 | 68 | 2. **高兼容性** 69 | - 完全兼容以太坊 EVM，开发者无需修改代码即可迁移 DApp。 70 | - 支持现有以太坊工具和基础设施。 71 | 72 | 3. **安全性** 73 | - 依赖以太坊主网的安全性，通过欺诈证明机制确保交易有效性。 74 | - 数据存储在链上，确保透明性和可验证性。 75 | 76 | 4. **用户体验** 77 | - 提供即时交易确认，减少用户等待时间。 78 | - 支持跨链资产转移，方便用户操作。 79 | --- 80 | 81 | ### **Optimism Rollup 的挑战** 82 | 83 | 1. **挑战期延迟** 84 | - 提现到以太坊主网需要等待挑战期结束（通常 7 天）。 85 | - 可能影响用户体验。 86 | 87 | 2. **中心化风险** 88 | - Sequencer 目前由 Optimism 团队运营，存在一定的中心化风险。 89 | - 未来计划引入去中心化 Sequencer。 90 | 91 | 3. **欺诈证明复杂性** 92 | - 欺诈证明机制需要复杂的实现和验证。 93 | - 可能增加开发和维护成本。 94 | 95 | ### 2025.01.07 96 | --- 97 | ### **Optimism Rollup 的工作流程** 98 | 99 | 1. **交易提交** 100 | - 用户将交易发送到 Optimism Rollup 的 Sequencer。 101 | - Sequencer 对交易进行排序并生成批次。 102 | 103 | 2. **批次提交** 104 | - Sequencer 将交易批次压缩后提交到以太坊主网。 105 | - 主网存储交易数据，确保数据可用性。 106 | 107 | 3. **状态更新** 108 | - 交易在链下执行，生成新的状态根。 109 | - 状态根提交到以太坊主网，更新 Layer 2 状态。 110 | 111 | 4. **欺诈证明挑战期** 112 | - 提交的状态根进入挑战期（通常为 7 天）。 113 | - 在此期间，任何人都可以提交欺诈证明，挑战无效交易。 114 | 115 | 5. **最终确认** 116 | - 如果挑战期内无人挑战，状态根被最终确认。 117 | - 如果有挑战，以太坊主网会仲裁并决定是否回滚交易。 118 | --- 119 | 120 | ### 2025.01.08 121 | Layer-2 扩容方案旨在解决以太坊主网的拥堵和高 Gas 费问题。目前主要有四种 Layer-2 解决方案，它们在交易成本、安全性、速度等方面各有优劣。以下分别介绍这四种方案的交易成本： 122 | 123 | **1. Optimistic Rollup ** 124 | 125 | * **工作原理：** 乐观 Rollup 将大量交易在链下打包和执行，然后将交易数据（calldata）和状态根发布到以太坊主链。它“乐观地”假设交易是有效的，并通过欺诈证明机制来处理无效交易。 126 | * **交易成本：** 127 | * **L2 Gas 费（链下）：** 非常低，因为交易主要在链下执行。 128 | * **L1 Gas 费（链上）：** 主要成本是 calldata 的 Gas 费，用于将压缩后的交易数据发布到以太坊主链。因此，L1 Gas 费受以太坊主链 Gas Price 的影响较大。 129 | * **总 Gas 费：** `总 Gas 费 = L2 Gas 费 + L1 Gas 费`。总费用通常比以太坊主网低很多，但仍然会受到以太坊主网 Gas Price 的波动影响。 130 | * **影响 L1 Gas 费的因素：** 131 | * **Calldata 大小：** 交易数据越多，calldata 越大，L1 Gas 费越高。 132 | * **以太坊主链 Gas Price：** 主网 Gas Price 越高，L1 Gas 费越高。 133 | * **批量处理效率：** 将更多 L2 交易打包成一个 L1 交易可以分摊 L1 Gas 费。 134 | * **代表项目：** Arbitrum、Optimism。 135 | 136 | **2. ZK Rollup（零知识Rollup）** 137 | 138 | * **工作原理：** ZK Rollup 在链下执行交易，并生成一个简洁的零知识证明（zk-SNARK 或 zk-STARK），证明这些交易的有效性。这个证明会被发布到以太坊主链，验证者无需重新执行所有交易即可验证其有效性。 139 | * **交易成本：** 140 | * **L2 Gas 费（链下）：** 也很低。 141 | * **L1 Gas 费（链上）：** 主要成本是发布零知识证明的 Gas 费。虽然证明本身比 calldata 小得多，但生成证明的计算成本较高。 142 | * **总 Gas 费：** 通常比 Optimistic Rollup 更低，尤其是在交易量较大时。 143 | * **优势：** 安全性更高，因为不需要等待期和欺诈证明。 144 | * **劣势：** 开发难度较高，通用性不如 Optimistic Rollup。 145 | * **代表项目：** zkSync、StarkNet。 146 | 147 | **3. Validium** 148 | 149 | * **工作原理：** Validium 与 ZK Rollup 类似，也使用零知识证明来验证链下交易的有效性。但不同之处在于，Validium 将交易数据存储在链下，而不是像 ZK Rollup 那样存储在链上。 150 | * **交易成本：** 151 | * **L2 Gas 费（链下）：** 非常低。 152 | * **L1 Gas 费（链上）：** 极低，因为只需在链上发布证明，而无需发布交易数据。 153 | * **优势：** 交易成本最低。 154 | * **劣势：** 数据可用性存在一定风险，因为数据存储在链下，如果数据提供者出现问题，可能会导致用户无法访问自己的资产。 155 | * **适用场景：** 适合对安全性要求不高，但对成本非常敏感的应用，例如游戏、支付等。 156 | * **代表项目：** StarkEx。 157 | 158 | **4. Plasma** 159 | 160 | * **工作原理：** Plasma 使用一种“子链”结构，将交易放在独立的子链上执行，并通过默克尔树将子链的状态根锚定到以太坊主链。 161 | * **交易成本：** 162 | * **L2 Gas 费（链下）：** 较低。 163 | * **L1 Gas 费（链上）：** 用于将子链的状态根提交到主链，成本相对较低。 164 | * **劣势：** 提款需要较长的等待期（挑战期），并且在某些情况下可能需要用户进行数据可用性证明，这会增加复杂性。 165 | * **应用受限：** 由于其固有的局限性，Plasma 的应用范围相对有限，主要用于简单的支付和代币转移。 166 | * **目前使用较少** 167 | 168 | **四种方案的交易成本对比（大致排序，具体数值会根据网络状况变化）：** 169 | 170 | Validium < ZK Rollup < Optimistic Rollup < 以太坊主网 171 | 172 | ### 2025.01.09 173 | 通过阅读 [资料](https://medium.com/l2beat/introducing-stages-a-framework-to-evaluate-rollups-maturity-d290bb22befe) 构想经过三个阶段 174 | - Stage 0 — Full Training Wheels: At this stage, the rollup is effectively run by the operators. Still, there is an source-available software that allows for the reconstruction of the state from the data posted on L1, used to compare state roots with the proposed ones. 175 | - Stage 1 — Limited Training Wheels: In this stage, the rollup transitions to being governed by smart contracts. However, a Security Council might remain in place to address potential bugs. This stage is characterized by the implementation of a fully functional proof system, decentralization of fraud proof submission, and provision for user exits without operator coordination. The Security Council, comprised of a diverse set of participants, provides a safety net, but its power also poses a potential risk. 176 | - Stage 2 — No Training Wheels: This is the final stage where the rollup becomes fully managed by smart contracts. At this point, the fraud proof system is permissionless, and users are given ample time to exit in the event of unwanted upgrades. The Security Council’s role is strictly confined to addressing soundness errors that can be adjudicated on-chain, and users are protected from governance attacks. 177 | ### 2025.01.10 178 | - 学习OP的代币智力体系 179 | - optimism collective的治理由token house和citizen house组成，两者相互制衡 180 | ### 2025.01.11 181 | - 周六请假 182 | ### 2025.01.12 183 | - 周日请假 184 | ### 2025.01.13 185 | - 代币议院（Token House） 186 | - 成员构成：OP 代币持有者或其委托的代表，通过代币投票权参与治理。 187 | 188 | - 核心职责： 189 | 190 | - 协议升级（如智能合约修改、通胀率调整）； 191 | 192 | - 治理基金分配（支持生态发展项目）； 193 | 194 | - 罢免基金会董事或否决核心文件变更。 195 | 196 | - 投票机制：代币投票需满足法定人数（如30%总可投票供应量）和特定通过门槛（例如协议升级需76%支持率） 197 | ### 2025.01.14 198 | - 公民议院（Citizen's House） 199 | - 成员构成：通过参与 RetroPGF（追溯公共物品资助）获得临时公民身份的社区成员，采用“一人一票”制。 200 | - 核心职责： 201 | - 分配 RetroPGF 资金，奖励对生态有贡献的公共物品项目； 202 | - 对代币议院通过的协议升级或通胀调整提案行使否决权（需30%公民投票反对） 203 | ### 2025.01.15 204 | - 代币功能 205 | 206 | 1. 治理权：OP 持有者可投票决定协议发展方向，包括资金分配、技术升级等； 207 | 208 | 2. 经济激励：通过 RetroPGF 和空投奖励生态贡献者，形成“影响=利润”的飞轮效应； 209 | 210 | 3. 治理基金：初始代币供应的25%用于生态激励，支持开发者与社区项目 211 | ### 2025.01.16 212 | - 代币分配 213 | 214 | 1. 初始供应：42.9亿枚 OP，年通胀率2%2； 215 | 216 | 2. 分配比例： 217 | 218 | - 生态系统基金（25%）、追溯公共物品资金（20%）、用户空投（19%）、核心贡献者（19%）、投资者（17%）213； 219 | 220 | - 空投策略：通过多轮空投奖励早期用户、DAO参与者和跨链用户，例如2024年第五季向5.4万个地址分发1000万枚 OP 221 | ### 2025.01.17 222 | 223 | #### 治理流程与决策机制 224 | 1. **提案周期** 225 | - **三周制**：每项提案需经历草案讨论（两周）和投票期（一周），投票期需满足法定人数与通过阈值； 226 | - **特殊提案**：紧急维护类提案可采用“乐观投票”机制，缩短决策时间。 227 | 228 | 2. **提案类型与要求** 229 | | 提案类型 | 发起方 | 通过条件 | 否决权归属 | 230 | |------------------------|--------------|------------------------------|------------------| 231 | | 协议升级 | 代币议院 | 76%支持率 + 30%法定人数 | 公民议院 | 232 | | RetroPGF资金分配 | 公民议院 | 简单加权投票制 | 无 | 233 | | 治理基金使用 | 代币议院 | 51%支持率 + 30%法定人数 | 无 | 234 | 235 | 3. **去中心化工具** 236 | - **Optimism治理门户**：提供链上投票与委托功能； 237 | - **Snapshot空间**：公民议院投票平台； 238 | - **论坛与Discord**：社区讨论与提案反馈。 239 | 240 | 241 | ### 2025.01.18 242 | - 周六请假 243 | # 2025.01.19 244 | - 周日请假 245 | 246 | # 2025.1.20 247 | 248 | - 本周学习[RetroPFG](https://community.optimism.io/citizens-house/how-retro-funding-works)机制 249 | 250 | ### **RetroPGF 的核心机制与目标** 251 | **1. 定义与原则** 252 | RetroPGF（Retroactive Public Goods Funding）是 Optimism 生态系统中的一种资金分配机制，旨在通过 **事后奖励** 的方式，对已证明对 Optimism 或以太坊生态系统产生积极影响的公共物品项目进行资助。其核心理念是 **“影响力=利润”**，即贡献者的社会价值应转化为经济收益，从而激励更多人参与公共物品建设。 253 | 254 | **2. 目标** 255 | - **填补市场失灵**：传统公共物品（如开源工具、教育内容）因缺乏盈利模式常被资本忽视，RetroPGF 提供可持续的退出机制，吸引私有资本投入。 256 | - **促进生态增长**：通过资助基础设施、工具和教育项目，降低用户参与 Optimism 生态的门槛，形成“公共物品→生态繁荣→更多资助”的飞轮效应。 257 | 258 | # 2025.1.21 259 | 260 | ### **治理架构与流程** 261 | **1. 两院制治理结构** 262 | Optimism 的治理由 **代币议院（Token House）** 和 **公民议院（Citizen House）** 共同主导，形成资本与价值观的平衡： 263 | - **代币议院**：由 OP 代币持有者组成，负责批准资金池（如 RetroPGF 3 分配了 3000 万 OP）及协议升级，投票权重与代币持有量挂钩。 264 | - **公民议院**：由社区推荐的“公民”组成（如 RetroPGF 3 有 146 位公民），采用“一人一票”原则，负责具体资金分配，避免财阀统治。 265 | 266 | **2. 资助流程** 267 | 1. **提名与申请**：任何人均可提名符合资助范围的项目（如工具开发、内容创作），需在治理论坛提交申请并说明影响力。 268 | 2. **审核与投票**：公民通过工具（如 OpenSource Observer）评估项目数据，并借助 Pairwise 等工具进行对比投票。投票结果需结合定量指标（如链上数据）与定性判断（如社区价值）。 269 | 3. **资金发放**：通过 KYC 验证的项目将直接获得 OP 代币奖励。例如，RetroPGF 3 在 2024 年 1 月完成 3000 万 OP 的分配。 270 | 271 | 272 | # 2025.1.22 273 | 274 | ### **资金模型与分配演变** 275 | **1. 资金来源** 276 | - **初始代币分配**：Optimism 初始代币的 20% 专用于 RetroPGF。 277 | - **协议收入**：Superchain 成员需将 15% 的排序器收入或利润上交，作为长期资金池。 278 | - **通胀机制**：OP 代币年通胀率 2%，部分用于补充资金。 279 | 280 | **2. 资助方向迭代** 281 | - **早期阶段**：聚焦纯公共物品（如 ZachXBT 的反欺诈贡献），强调社会影响力而非直接增长。 282 | - **后期阶段（如 RetroPGF 7）**：引入 **任务导向型资助**（Missions），结合数据算法与人工评估，重点支持： 283 | - **链上建设者（Onchain Builders）**：激励跨链互操作性项目，评估标准包括 Superchain 采用率、TVL 增长等。 284 | - **开发工具（Dev Tooling）**：资助提升 OP Stack 效率的工具（如编译器、调试器），需避免与早期资助重复。 285 | 286 | # 2025.1.23 287 | 288 | ### **OP Stack 的定义与定位** 289 | OP Stack 是 **Optimism Collective** 推出的标准化、开源模块化开发框架，旨在简化以太坊 Layer 2（L2）及 Layer 3（L3）区块链的构建，并推动形成互联互通的 **超级链（Superchain）** 网络。其核心目标是通过模块化设计，解决区块链扩展性、互操作性和碎片化问题。 290 | 291 | - **模块化架构**：OP Stack 将区块链的不同功能层（执行层、数据可用性层、结算层等）解耦为独立模块，开发者可自由组合或替换模块（如切换数据可用性方案或虚拟机），满足特定需求。 292 | - **标准化与开源**：所有模块遵循统一标准且完全开源，支持开发者协作迭代，避免重复造轮子。 293 | 294 | 295 | # 2025.1.24 296 | 297 | ### **核心组件与技术特性** 298 | #### **关键组件** 299 | 1. **执行层**：默认基于以太坊虚拟机（EVM），支持替换为其他虚拟机（如 FuelVM）。 300 | 2. **数据可用性层**：可选择以太坊、Celestia 或其他 DA 方案，降低成本。 301 | 3. **结算层**：依赖以太坊主网确保最终性，未来可能支持多结算层。 302 | 4. **治理与工具**：包括区块浏览器、跨链通信协议等。 303 | 304 | #### **技术亮点** 305 | - **Bedrock 升级**：优化了交易批处理效率，引入 **SystemConfig 合约**，允许通过 L1 智能合约定义 L2 链的配置（如 Gas 限制、排序器地址），实现链的标准化部署。 306 | - **确定性地址生成**：通过 CREATE2 生成与链配置对应的合约地址，简化跨链交互。 307 | - **模块化排序器**：支持自定义排序模型（如轮询、竞价排序），推动去中心化。 308 | - **Plasma 模式与自定义 Gas 代币**：允许开发者选择 DA 层并自定义 Gas 代币，降低用户成本。 309 | 310 | # 2025.1.25 311 | Bedrock 是 Optimism OP Stack 的一次重大架构升级，旨在提高性能、降低成本和增强安全性。它通过以下几个主要方式降低了交易成本： 312 | 313 | 1. **更高效的数据压缩：** 这是 Bedrock 降低成本的最主要因素。Rollup 的主要成本是将交易数据（calldata）发布到以太坊主链。Bedrock 采用了更先进的数据压缩技术，减少了需要发布到 L1 的数据量，从而直接降低了 calldata 的 Gas 费用。 314 | 315 | * **差异编码（Delta encoding）：** Bedrock 使用差异编码来压缩状态更新。它只发布状态变化的差异部分，而不是完整的状态数据，从而大幅减少了数据量。 316 | * **更有效的数据格式：** Bedrock 使用了更紧凑的数据格式，进一步减少了数据大小。 317 | 318 | 2. **优化的执行层：** Bedrock 对执行层进行了优化，提高了交易处理效率，减少了 L2 上的 Gas 消耗。虽然 L2 Gas 费在总成本中占比相对较小，但优化执行层仍然有助于降低总体成本。 319 | 320 | 3. **降低 L1 开销：** 除了压缩 calldata，Bedrock 还通过其他方式减少了 L1 上的开销： 321 | 322 | * **更少的 L1 操作：** Bedrock 减少了在 L1 上执行的操作数量，例如提交状态根的频率等，从而降低了 L1 Gas 费用。 323 | * **规范化的执行客户端**: Bedrock 升级后，OP Rollup 的执行客户端与以太坊的执行客户端更加接近。这使得可以复用以太坊客户端的各种优化，从而降低成本。 324 | 325 | 4. **共享排序器 (未来展望):** 虽然目前 Bedrock 还没有完全实现共享排序器，但这是 OP Stack 的长期目标。通过共享排序器，多个 OP Chain 可以共享同一个排序器来处理交易，从而大幅降低排序成本，并提高效率和增强安全性。 326 | 327 | **总结来说，Bedrock 主要通过以下方式降低交易成本：** 328 | 329 | * **大幅减少需要发布到 L1 的数据量（通过更高效的数据压缩）。** 330 | * **优化 L2 执行层，减少 L2 Gas 消耗。** 331 | * **减少 L1 上的操作数量。** 332 | * **未来通过共享排序器进一步降低成本。** 333 | 334 | 通过这些改进，Bedrock 显著降低了 Optimism 用户的交易成本，使其更具竞争力。根据一些测试和实际数据，Bedrock 可以将交易 Gas 费降低 40% 甚至更多。这使得 Optimism 成为进行小额交易和频繁交互的更经济的选择。 335 | 336 | 337 | 338 | # 2025.1.26 339 | 340 | - OP Stack 的设计目标之一就是提高用户体验，简化用户与 Layer-2 的交互。 341 | 342 | * **EVM 等效性：** OP Stack 旨在尽可能地与以太坊虚拟机（EVM）兼容。这意味着以太坊上的智能合约和工具可以相对容易地迁移到 OP Chain 上，用户可以使用熟悉的钱包和工具进行交互。这大大降低了用户的使用门槛。 343 | * **低交易成本：** 如前所述，Bedrock 升级显著降低了交易成本，使得在 OP Chain 上进行交易更加经济实惠，从而提升了用户体验。 344 | * **快速交易确认：** OP Chain 的区块生成速度比以太坊主网更快，交易确认时间更短，用户可以更快地完成交易。 345 | * **桥接和跨链互操作性：** OP Stack 致力于实现不同 OP Chain 之间的无缝互操作。通过标准化的消息传递格式和桥接机制，用户可以方便地在不同的 OP Chain 之间转移资产和数据，从而提高了用户体验和生态系统的流动性。 346 | * **易于使用的工具和基础设施：** OP Stack 的目标是提供易于使用的开发工具和基础设施，例如钱包、区块浏览器、开发框架等，从而方便用户和开发者使用 OP Chain。 347 | * **抽象证明层**: OP Stack 在将资金结算到另一条链时，对证明层进行了抽象。只要证明层满足证明 API，就可以被插入到系统中，而不会对用户体验产生任何影响。这使得 Optimism 有可能适应更新的证明系统。 348 | 349 | 350 | 351 | -------------------------------------------------------------------------------- /wuyanhui.md: -------------------------------------------------------------------------------- 1 | --- 2 | timezone: Asia/Shanghai 3 | --- 4 | 5 | > 请在上边的 timezone 添加你的当地时区，这会有助于你的打卡状态的自动化更新，如果没有添加，默认为北京时间 UTC+8 时区 6 | > 时区请参考以下列表，请移除 # 以后的内容 7 | 8 | timezone: Pacific/Honolulu # 夏威夷-阿留申标准时间 (UTC-10) 9 | 10 | timezone: America/Anchorage # 阿拉斯加标准时间 (UTC-9) 11 | 12 | timezone: America/Los_Angeles # 太平洋标准时间 (UTC-8) 13 | 14 | timezone: America/Denver # 山地标准时间 (UTC-7) 15 | 16 | timezone: America/Chicago # 中部标准时间 (UTC-6) 17 | 18 | timezone: America/New_York # 东部标准时间 (UTC-5) 19 | 20 | timezone: America/Halifax # 大西洋标准时间 (UTC-4) 21 | 22 | timezone: America/St_Johns # 纽芬兰标准时间 (UTC-3:30) 23 | 24 | timezone: America/Sao_Paulo # 巴西利亚时间 (UTC-3) 25 | 26 | timezone: Atlantic/Azores # 亚速尔群岛时间 (UTC-1) 27 | 28 | timezone: Europe/London # 格林威治标准时间 (UTC+0) 29 | 30 | timezone: Europe/Berlin # 中欧标准时间 (UTC+1) 31 | 32 | timezone: Europe/Helsinki # 东欧标准时间 (UTC+2) 33 | 34 | timezone: Europe/Moscow # 莫斯科标准时间 (UTC+3) 35 | 36 | timezone: Asia/Dubai # 海湾标准时间 (UTC+4) 37 | 38 | timezone: Asia/Kolkata # 印度标准时间 (UTC+5:30) 39 | 40 | timezone: Asia/Dhaka # 孟加拉国标准时间 (UTC+6) 41 | 42 | timezone: Asia/Bangkok # 中南半岛时间 (UTC+7) 43 | 44 | timezone: Asia/Shanghai # 中国标准时间 (UTC+8) 45 | 46 | timezone: Asia/Tokyo # 日本标准时间 (UTC+9) 47 | 48 | timezone: Australia/Sydney # 澳大利亚东部标准时间 (UTC+10) 49 | 50 | timezone: Pacific/Auckland # 新西兰标准时间 (UTC+12) 51 | 52 | --- 53 | 54 | # wuyanhui 55 | 56 | 1. 自我介绍 57 | 一名web2资深，刚入行web3半年 58 | 59 | 3. 你认为你会完成本次残酷学习吗？ 60 | 非常期待这一次的学习，保证完成任务！ 61 | 62 | ## Notes 63 | 64 | 65 | 66 | ### 2025.01.06 67 | 68 | 1. 学习 Optimism 的基本概念，为什么会出现 Optimism 69 | 什么是 Optimism？ 70 | Optimism 是一种基于以太坊的 Layer 2 解决方案，旨在提高以太坊的交易速度并降低交易费用，同时保持以太坊主网的安全性和去中心化特性。它通过 Optimistic Rollups 技术将大部分计算和数据存储从以太坊主网移到 Layer 2，从而缓解主网的拥堵问题。 71 | 为什么会出现 Optimism？ 72 | Optimism 主要是为了解决以太坊主网在大规模使用时遇到的以下问题： 73 | 1. 高昂的交易费用（Gas费） 74 | 以太坊主网的交易费用随着网络负载的增加而急剧上升，尤其在 DeFi 和 NFT 活跃时，普通用户难以负担高额费用。 75 | 2. 低交易吞吐量（TPS, Transactions Per Second） 76 | 以太坊主网的 TPS 约为 15-30，这在面对大规模用户时显得不够用，导致交易延迟和用户体验下降。 77 | 3. 网络拥堵 78 | 当网络交易量激增时，主网变得极为拥堵，用户需要支付更高的 Gas 费以加速交易确认。 79 | Optimism 的目标 80 | ● 降低交易费用 81 | 通过将大量的计算和数据移至 Layer 2，用户可以享受显著降低的交易费用。 82 | ● 提高交易速度 83 | 在 Layer 2 上，交易的处理速度比主网快得多，适合对延迟敏感的应用（如 DeFi、NFT 市场等）。 84 | ● 增强以太坊的可扩展性 85 | 帮助以太坊应对更多用户和应用场景，为 Web3 生态提供更好的基础设施。 86 | 87 | 88 | 2. Layer 2 扩容方案有哪些，解决了哪些问题 89 | Layer 2 是指构建在以太坊主网（Layer 1）之上的扩展解决方案，旨在提高以太坊网络的性能，主要包括以下方案： 90 | 1. Rollups 91 | Rollups 是目前最广泛应用的 Layer 2 扩容方案，它们将大量交易汇总（Rollup）到一个批次中，并将交易数据提交到以太坊主网。 92 | ● Optimistic Rollups（如 Optimism、Arbitrum） 93 | ○ 工作原理：假设所有交易都是有效的，只有在发现欺诈时才进行验证。 94 | ○ 解决的问题：提高 TPS，降低 Gas 费。 95 | ○ 缺点：存在欺诈挑战期（通常为 1 周）。 96 | ● ZK-Rollups（如 zkSync、StarkNet） 97 | ○ 工作原理：通过生成零知识证明，直接证明交易的有效性。 98 | ○ 解决的问题：更快的结算时间和更低的 Gas 费。 99 | ○ 缺点：实现复杂度较高。 100 | 2. State Channels 101 | State Channels 允许用户在链下直接进行交易，最终将结果提交到链上。 102 | ● 解决的问题：减少链上交互次数，提高交易速度并降低费用。 103 | ● 缺点：需要用户保持在线，适用于特定场景（如支付渠道）。 104 | 3. Plasma 105 | Plasma 使用子链（Child Chain）处理大量交易，定期将摘要提交到主网。 106 | ● 解决的问题：通过将大量交易从主网移到子链来提高吞吐量。 107 | ● 缺点：退出过程较慢，适用于简单的转账场景。 108 | 4. Validium 109 | Validium 类似于 ZK-Rollups，但将数据存储在链下。 110 | ● 解决的问题：提供高吞吐量和低费用，同时保护用户隐私。 111 | ● 缺点：需要信任外部数据存储。 112 | 113 | 114 | 3. Optimistic Rollups 是什么，解决了哪些问题 115 | Optimistic Rollups 的定义 116 | Optimistic Rollups 是一种基于“乐观假设”的扩容技术。在 Optimistic Rollups 中，所有提交的交易默认被认为是有效的，除非有用户提出欺诈证明（Fraud Proof），以此来减少交易验证的计算量。 117 | 工作原理 118 | 1. 批量处理交易：Optimistic Rollups 将数千笔交易打包成一个批次，并将其压缩后的数据提交到以太坊主网。 119 | 2. 乐观假设：假设所有交易都是正确的，因此无需逐笔验证。 120 | 3. 欺诈挑战期：在一定时间内（如 7 天），任何人都可以提交欺诈证明。如果证明成功，Rollup 批次将被回滚，恶意验证者会被罚款。 121 | Optimistic Rollups 解决了哪些问题？ 122 | 1. 降低交易费用 123 | Rollups 的批量处理显著降低了用户需要支付的 Gas 费。 124 | 2. 提高交易吞吐量 125 | 每秒可处理数千笔交易，相比以太坊主网的 15-30 TPS，有了巨大的提升。 126 | 3. 减轻主网负担 127 | 通过将大部分计算和存储移至 Layer 2，减少了主网的拥堵。 128 | 4. 增强去中心化 129 | 相比其他扩容方案（如侧链），Optimistic Rollups 保留了以太坊主网的安全性和去中心化特性。 130 | ### 2024.07.12 131 | 132 | 133 | -------------------------------------------------------------------------------- /yiwen4.md: -------------------------------------------------------------------------------- 1 | --- 2 | timezone: Asia/Shanghai 3 | --- 4 | 5 | > 请在上边的 timezone 添加你的当地时区，这会有助于你的打卡状态的自动化更新，如果没有添加，默认为北京时间 UTC+8 时区 6 | > 时区请参考以下列表，请移除 # 以后的内容 7 | 8 | timezone: Pacific/Honolulu # 夏威夷-阿留申标准时间 (UTC-10) 9 | 10 | timezone: America/Anchorage # 阿拉斯加标准时间 (UTC-9) 11 | 12 | timezone: America/Los_Angeles # 太平洋标准时间 (UTC-8) 13 | 14 | timezone: America/Denver # 山地标准时间 (UTC-7) 15 | 16 | timezone: America/Chicago # 中部标准时间 (UTC-6) 17 | 18 | timezone: America/New_York # 东部标准时间 (UTC-5) 19 | 20 | timezone: America/Halifax # 大西洋标准时间 (UTC-4) 21 | 22 | timezone: America/St_Johns # 纽芬兰标准时间 (UTC-3:30) 23 | 24 | timezone: America/Sao_Paulo # 巴西利亚时间 (UTC-3) 25 | 26 | timezone: Atlantic/Azores # 亚速尔群岛时间 (UTC-1) 27 | 28 | timezone: Europe/London # 格林威治标准时间 (UTC+0) 29 | 30 | timezone: Europe/Berlin # 中欧标准时间 (UTC+1) 31 | 32 | timezone: Europe/Helsinki # 东欧标准时间 (UTC+2) 33 | 34 | timezone: Europe/Moscow # 莫斯科标准时间 (UTC+3) 35 | 36 | timezone: Asia/Dubai # 海湾标准时间 (UTC+4) 37 | 38 | timezone: Asia/Kolkata # 印度标准时间 (UTC+5:30) 39 | 40 | timezone: Asia/Dhaka # 孟加拉国标准时间 (UTC+6) 41 | 42 | timezone: Asia/Bangkok # 中南半岛时间 (UTC+7) 43 | 44 | timezone: Asia/Shanghai # 中国标准时间 (UTC+8) 45 | 46 | timezone: Asia/Tokyo # 日本标准时间 (UTC+9) 47 | 48 | timezone: Australia/Sydney # 澳大利亚东部标准时间 (UTC+10) 49 | 50 | timezone: Pacific/Auckland # 新西兰标准时间 (UTC+12) 51 | 52 | --- 53 | 54 | # {你的名字} 55 | 56 | 1. yiwen4 57 | 58 | 2. 你认为你会完成本次残酷学习吗？也许 59 | 60 | ## Notes 61 | 62 | 63 | 64 | ### 2025.01.06 65 | 66 | 笔记内容 67 | 68 | ### 2024.07.12 69 | 70 | 71 | -------------------------------------------------------------------------------- /yoow4536.md: -------------------------------------------------------------------------------- 1 | --- 2 | timezone: Asia/Shanghai 3 | --- 4 | 5 | > 请在上边的 timezone 添加你的当地时区，这会有助于你的打卡状态的自动化更新，如果没有添加，默认为北京时间 UTC+8 时区 6 | > 时区请参考以下列表，请移除 # 以后的内容 7 | 8 | timezone: Pacific/Honolulu # 夏威夷-阿留申标准时间 (UTC-10) 9 | 10 | timezone: America/Anchorage # 阿拉斯加标准时间 (UTC-9) 11 | 12 | timezone: America/Los_Angeles # 太平洋标准时间 (UTC-8) 13 | 14 | timezone: America/Denver # 山地标准时间 (UTC-7) 15 | 16 | timezone: America/Chicago # 中部标准时间 (UTC-6) 17 | 18 | timezone: America/New_York # 东部标准时间 (UTC-5) 19 | 20 | timezone: America/Halifax # 大西洋标准时间 (UTC-4) 21 | 22 | timezone: America/St_Johns # 纽芬兰标准时间 (UTC-3:30) 23 | 24 | timezone: America/Sao_Paulo # 巴西利亚时间 (UTC-3) 25 | 26 | timezone: Atlantic/Azores # 亚速尔群岛时间 (UTC-1) 27 | 28 | timezone: Europe/London # 格林威治标准时间 (UTC+0) 29 | 30 | timezone: Europe/Berlin # 中欧标准时间 (UTC+1) 31 | 32 | timezone: Europe/Helsinki # 东欧标准时间 (UTC+2) 33 | 34 | timezone: Europe/Moscow # 莫斯科标准时间 (UTC+3) 35 | 36 | timezone: Asia/Dubai # 海湾标准时间 (UTC+4) 37 | 38 | timezone: Asia/Kolkata # 印度标准时间 (UTC+5:30) 39 | 40 | timezone: Asia/Dhaka # 孟加拉国标准时间 (UTC+6) 41 | 42 | timezone: Asia/Bangkok # 中南半岛时间 (UTC+7) 43 | 44 | timezone: Asia/Shanghai # 中国标准时间 (UTC+8) 45 | 46 | timezone: Asia/Tokyo # 日本标准时间 (UTC+9) 47 | 48 | timezone: Australia/Sydney # 澳大利亚东部标准时间 (UTC+10) 49 | 50 | timezone: Pacific/Auckland # 新西兰标准时间 (UTC+12) 51 | 52 | --- 53 | 54 | # yoow4536 55 | 56 | 1. 自我介绍：区块链菜鸡 57 | 58 | 2. 你认为你会完成本次残酷学习吗？ 59 | 能 60 | 61 | ## Notes 62 | 63 | 64 | 65 | ### 2025.01.06 66 | 67 | 笔记内容 68 | 69 | ### 2024.07.12 70 | 71 | 72 | -------------------------------------------------------------------------------- /zhengjunhe.md: -------------------------------------------------------------------------------- 1 | --- 2 | timezone: Asia/Shanghai 3 | --- 4 | 5 | --- 6 | 7 | # power he 8 | 9 | 1. 自我介绍: 区块链老兵，具有从事区块链开发8年的经验 10 | 11 | 2. 你认为你会完成本次残酷学习吗？是的 12 | 13 | ## Notes 14 | 15 | 16 | 17 | ### 2025.01.06 18 | 19 | 基本介绍:Optimism 是一个利用 optimistic rollup 技术的的以太坊 L2 解决方案，目的是解决以太坊吞吐量不高，交易成本过高的问题，同时又保证了安全性和去中心化 20 | 21 | 区块链不可能三角：在区块链不可能三角中，去中心化，安全性和高 TPS，是不可能三角，以太坊足够安全，也具有去中心化，但是牺牲了吞吐量，而 Optimism 牺牲了哪方面，从而解决了以太坊的问题呢，在我看来是牺牲了一部分的去中心化，以为 Optimism 的共识层是基于以太坊的，其实是略微牺牲了一部分去中心化，但是保证了足够高的吞吐量 22 | 23 | 大规模应用：同时，Layer2 被认为是以太坊大规模应用的重要一步，没有人会因为一次交互而负担超过 10 刀甚至 100 刀以上的 Gas 费，在通过 EIP 4844 之后，Optimism 上交互一次的成本已经达到了小于 0.01 美金，在未来，大规模应用应该会逐渐爆发 24 | 25 | Optimism 采取了 Optimistic rollup 的机制 26 | 27 | Rollup 概念：将大量交易数据“打包”并压缩后提交到以太坊主网（Layer 1）(以太坊计算是一笔交易都多节点一起同步，Rollup 类似是把一笔交易里面打包多笔交易，提交给以太坊主网) 28 | “Optimistic”设计：默认假设所有交易都是有效的，只有在有人提出争议时才进行验证。这种设计减少了计算量，提升了效率。（7 天验证有效期这个其实我目前还有一些问题，如何保证一些最基础的诚实节点，或者说如何从利益设计上解决这些问题，我看到了故障证明的设计，明天学习故障证明） 29 | 30 | 以太坊兼容性 31 | 32 | EVM 等效性：Optimism 100% 兼容以太坊虚拟机（EVM），支持以太坊上的所有智能合约和工具。 33 | 开发者友好：开发者可以将现有的以太坊应用无缝迁移到 Optimism，无需重新编写代码。 34 | 35 | 安全性 36 | 37 | 所有数据都存储在以太坊主网，确保数据的完整性和可用性。 38 | 使用欺诈证明（Fraud Proof）机制检测并惩罚恶意行为。 39 | 40 | 经济性 41 | 42 | 大幅降低交易费用，通常比以太坊主网便宜 10-100 倍（通过 EIP 4844 之后，这个应该是便宜 1000 倍了） 43 | 通过高效的 Rollup 压缩技术，优化了存储和 gas 使用。 44 | 45 | 46 | 47 | 48 | ### Optimistic rollups 的演变历史 49 | Layer2 的存在是是为了解决以太坊吞吐量不大的问题，以太坊目前的处理速度限制在每秒约 15-20 笔交易，这降低了短期内扩展以处理更多用户的可能性。这个问题存在的主要原因是以太坊的共识机制需要许多对等节点来验证区块链状态的每次更新 50 | 而这是很难满足大规模应用的，在之前， 51 | 在 Optimistic rollups 之前，有一个 Plsma 的扩容方案，Plsma 的扩容方案在 Optimistic rollups 推出之前，一直都是以太坊的重要扩容方案，Polygon 之前也是沿用 plsma 的设计 52 | 53 | Plasma 是一种链下扩展方案，利用子链（或称 Plasma 链）处理大部分交易，同时仅将必要的信息提交到以太坊主网。 54 | 55 | 工作原理 56 | 子链结构：Plasma 链是独立的区块链，定期将“状态摘要”提交到以太坊主网。 57 | 安全性依赖主网：通过以太坊主网的共识机制和数据可用性，确保 Plasma 子链的安全性。 58 | 交易处理：用户在 Plasma 子链上进行交易，只有在需要结算或争议时才回到主网。 59 | 退出机制：用户通过“挑战期”（Challenge Period）来确保资金安全，避免恶意行为。 60 | 61 | 优点 62 | 高吞吐量：交易大部分在子链完成，主网压力小。 63 | 成本低：相比主网，子链上的交易费用更低。 64 | 65 | 缺点 66 | 数据可用性问题：如果子链运营者恶意，可能导致数据丢失。 67 | 通用性低：Plasma 更适合简单支付和转账，不擅长复杂智能合约。 68 | 用户体验不佳：退出主网时需要等待挑战期，可能长达数天。 69 | 70 | 71 | ![image](https://github.com/user-attachments/assets/e86821bd-6509-464a-8df9-9cf48604ddcf) 72 | 73 | Plasma 上并不能跑 Uniswap，为了解决这个问题，Plasma Group 推出了 Optimistic rollups 74 | 75 | 由于 Plasma 子链 (Child Chain) 架构的一大缺点，就是在 L2 和 L1 层之间转移资金的耗时很长，有时用户甚至需要等上 1 周之久。这也使得像 Uniswap 这样的通用型智能合约无法运用在 Plasma 上。尽管 Ben 带领技术团队做了很多尝试，但「跑 Uniswap」的问题始终没有被解决。 76 | 77 | 就这样，Plasma Group 被自己亲手培养出的独角兽给难住了，Plasma 这个曾经被视为以太坊扩容「EndGame」的方案，也似乎走进了技术死胡同。现在，Plasma Group 的三位「扩容性先驱」必须找出新的解决方案。 78 | 79 | Optimistic rollups 的论文来源是 Vitalik 2014 年发布的一篇论文，里面提到了 Shadow chain 的概念（有点类似于比特币的闪电网络），从而推出了 Optimistic Rollup 80 | 81 | Optimistic Rollup 借鉴了 Plasma 的设计，但牺牲了其几乎无限的扩容性，以运行被叫做 OVM (Optimistic Virtual Machine) 的 EVM 兼容虚拟机，这也使 Optimistic Rollup 能够运行以太坊上能够运行的所有应用。 82 | 83 | 这一次，团队总算解决了 Plasma 面对的终极问题——OR 可以跑 Uniswap 了！ 84 | 85 | 86 | 工作原理 87 | 88 | Rollup 机制：Optimism Rollups 将交易数据和状态变化压缩后提交到以太坊主网，同时借助欺诈证明（Fraud Proof）来确保状态的正确性。 89 | 数据可用性：所有交易数据都会发布到以太坊主网，确保完整的数据可用性。 90 | 兼容性：与以太坊的 EVM（以太坊虚拟机）完全兼容，因此支持所有以太坊智能合约和工具。 91 | 92 | 优点 93 | 94 | 高通用性：可以运行复杂的智能合约。 95 | 安全性强：所有数据都存储在以太坊主网，保证数据可用性。 96 | 用户体验较好：相比 Plasma，退出时间短（通常几分钟到几小时）。 97 | 98 | 缺点 99 | 100 | 成本较高：由于 Rollup 仍需要将所有数据提交到主网，成本比 Plasma 高。 101 | 欺诈证明延迟：在极端情况下，欺诈证明可能需要一定时间。 102 | 103 | 104 | ### Next Step 105 | 1. 研究一下故障证明 106 | 2. 研究一下 Plasma 的实现原理，以及和 Optimistic rollups 的更进一步的区别 107 | 3. 精读一下 Vitalik 2014 年的文章：https://blog.ethereum.org/2014/09/17/scalability-part-1-building-top 108 | 109 | 110 | ### Reference 111 | https://blog.ethereum.org/2014/09/17/scalability-part-1-building-top (Vitalik: Shadow Chain) 112 | 113 | https://foresightnews.pro/article/detail/5893 (Optimisic rollup 成长史) 114 | 115 | https://ethereum.org/en/developers/docs/scaling/plasma/ 116 | 117 | https://ethereum.org/en/developers/docs/scaling/optimistic-rollups/ 118 | 119 | ### 2025.01.07 120 | 121 | 122 | --------------------------------------------------------------------------------