optimism

<div align="center"> <br /> <br /> <a href="https://optimism.io"><img alt="Optimism" src="https://yellow-cdn.veclightyear.com/835a84d5/83db8e62-582d-4e12-9e40-a06f1a144f9c.svg" width=600></a> <br /> <h3><a href="https://optimism.io">Optimism</a>是以太坊的扩展。</h3> <br /> </div>

目录

• 什么是Optimism？
• 文档
• 规范
• 社区
• 贡献
• 安全政策和漏洞报告
• 目录结构
• 开发和发布流程
  • 概述
  • 生产版本发布
  • 开发分支
• 许可证

什么是Optimism？

Optimism是一个致力于扩展以太坊技术并扩大其协调全球人员建立有效去中心化经济和治理系统能力的项目。Optimism集体开发开源软件，为可扩展区块链提供动力，并旨在解决更广泛以太坊生态系统中的关键治理和经济挑战。Optimism遵循影响力=利润的原则，即对集体产生积极影响的个人应该获得相应的利润回报。改变激励机制，你就能改变世界。

在这个仓库中，你会找到OP Stack的众多核心组件，OP Stack是由Optimism集体维护的去中心化软件堆栈，为Optimism提供动力，并构成了像OP主网和Base等区块链的骨干。OP Stack设计为积极开源——欢迎你探索、修改和扩展这些代码。

文档

• 如果你想在OP主网上构建，请参考Optimism文档
• 如果你想构建自己的基于OP Stack的区块链，请参考OP Stack指南，并确保理解本仓库的开发和发布流程

规范

OP Stack的详细规范可以在OP Stack规范仓库中找到。

社区

一般讨论最常发生在Optimism Discord上。 治理讨论也可以在Optimism治理论坛上找到。

贡献

OP Stack是一个协作项目。通过合作开发免费、开放的软件和共享标准，Optimism集体旨在防止软件开发的孤立，并迅速加速以太坊生态系统的发展。来贡献吧，共同构建未来，重新定义权力。

CONTRIBUTING.md包含了本仓库贡献过程的详细说明。确保使用开发者快速入门来正确设置你的开发环境。

如果你不确定从哪里开始，Good First Issues是寻找任务的好地方。

安全政策和漏洞报告

请参考官方的安全政策文档，了解如何报告此代码库中漏洞的详细信息。 我们鼓励赏金猎人查看Optimism Immunefi漏洞赏金计划。 Optimism Immunefi计划为范围内的关键漏洞提供高达2,000,042美元的奖励。

目录结构

<pre> ├── <a href="./docs">docs</a>：文档集合，包括审计和事后分析报告 ├── <a href="./op-batcher">op-batcher</a>：L2-批次提交器，将批次包提交到L1 ├── <a href="./op-bootnode">op-bootnode</a>：独立的op-node发现引导节点 ├── <a href="./op-chain-ops">op-chain-ops</a>：状态修复工具 ├── <a href="./op-challenger">op-challenger</a>：争议游戏挑战代理 ├── <a href="./op-e2e">op-e2e</a>：Go语言编写的所有基础组件的端到端测试 ├── <a href="./op-heartbeat">op-heartbeat</a>：心跳监控服务 ├── <a href="./op-node">op-node</a>：rollup共识层客户端 ├── <a href="./op-preimage">op-preimage</a>：预映像预言机的Go语言绑定 ├── <a href="./op-program">op-program</a>：错误证明程序 ├── <a href="./op-proposer">op-proposer</a>：L2-输出提交器，向L1提交提案 ├── <a href="./op-service">op-service</a>：通用代码库工具 ├── <a href="./op-ufm">op-ufm</a>：用于监控端到端交易延迟的模拟 ├── <a href="./op-wheel">op-wheel</a>：数据库工具 ├── <a href="./ops">ops</a>：各种运维包 ├── <a href="./ops-bedrock">ops-bedrock</a>：Bedrock开发网络工作 ├── <a href="./packages">packages</a> │ ├── <a href="./packages/contracts-bedrock">contracts-bedrock</a>：OP Stack智能合约 ├── <a href="./proxyd">proxyd</a>：可配置的RPC请求路由器和代理 ├── <a href="./specs">specs</a>：从Bedrock升级开始的rollup规范 </pre>

开发和发布流程

概述

如果你计划分叉或频繁向此仓库提交PR，请仔细阅读本节。

生产发布

生产发布始终以标签形式呈现，版本格式为<组件名称>/v<语义化版本号>。 例如，op-node的发布版本可能是op-node/v1.1.2，智能合约的发布版本可能是op-contracts/v1.0.0。 候选版本的格式为op-node/v1.1.2-rc.1。 我们总是从rc.1开始，而不是rc。

对于合约发布，请参考GitHub上特定发布的发布说明，其中会列出被发布的具体合约。并非所有合约在发布时都被视为生产就绪，许多合约仍在积极开发中。

形如v<语义化版本号>的标签，如v1.1.4，仅表示所有Go代码的发布，不包含智能合约。 这种命名方式是Go语言所要求的。 在上述列表中，这意味着这些v<语义化版本号>发布包含所有op-*组件，但不包括contracts-*组件。

op-geth将上游geth的版本嵌入其自身版本中，格式如下：vMAJOR.GETH_MAJOR GETH_MINOR GETH_PATCH.PATCH。 基本上，geth的版本是我们的次版本号。 例如，如果geth的版本是v1.12.0，对应的op-geth版本将是v1.101200.0。 注意，我们将geth的次版本号填充到三个字符，geth的补丁版本号填充到两个字符。 由于我们不能在左侧填充零，geth的主版本号不进行填充。

有关最新节点组件发布的更多信息，请参阅文档中的节点软件发布页面。

具有发布版本的完整组件集合包括：

• ci-builder
• op-batcher
• op-contracts
• op-challenger
• op-heartbeat
• op-node
• op-proposer
• op-ufm
• proxyd

所有其他组件和包应被视为仅用于开发，没有发布版本。

开发分支

主要开发分支是develop。 develop包含最新的软件，这些软件与最新的实验性网络部署保持向后兼容。 如果你正在进行向后兼容的更改，请将你的拉取请求指向develop分支。 通常情况下，packages/contracts-bedrock/src目录下的合约变更不被视为向后兼容。 对于在标签已完全部署后必须部署新合约的情况，存在一些例外。 如果你正在修改或添加合约，并且不确定应该向哪个分支提交PR，默认使用功能分支。 功能分支通常在两个项目触及相同代码而产生冲突时使用，以避免将两者合并到develop分支时发生冲突。

许可证

除非另有说明，本仓库中的所有其他文件均采用MIT许可证授权。