楽観主義は低コストで超高速のイーサリアムL2ブロックチェーンですが、それだけではありません。
楽観主義は、感情=利益の公理(集団へのプラスの影響は個人への利益で報われるべきであるという原則)を遵守するために相互に有益な協定によって団結したコミュニティ、企業、市民のバンドである楽観主義集団の技術的基盤です。 私たちは、今日の暗号エコシステムが直面している最も重要な調整の失敗のいくつかを解決しようとしています。私たちは特に、エコシステムが大きく依存している公共財とインフラストラクチャのための持続可能な資金の流れを作り出すことに重点を置いていますが、これまでのところ十分な報酬を得ることができませんでした。楽観的なビジョンをチェックして、私たちが何をしているのかについてもっと理解していただければ幸いです。
楽観主義の上に構築したい場合は、楽観主義コミュニティハブの広範なドキュメントをご覧ください。 楽観主義を構築したい場合は、プロトコル仕様を確認してください。
一般的な議論は、楽観主義の不和で最も頻繁に行われます。 ガバナンスに関する議論は、楽観主義ガバナンスフォーラムでもご覧いただけます。
貢献プロセスの概要については、CONTRIBUTING.md をお読みください。 開発者クイックスタートを使用して、楽観主義モノレポの作業を開始するための開発環境を設定します。 次に、良い最初の問題のリストをチェックして、取り組むのに楽しいものを見つけてください!
このコードベースの脆弱性を報告する方法の詳細については、正規のセキュリティポリシードキュメントを参照してください。 バウンティハンターは、Immunefiバグバウンティプログラムをチェックすることをお勧めします。 対象となる重大な脆弱性に対して最大 $2,000,042 を提供し、最大のバグ報奨金を支払います。
楽観主義は現在、Bedrockと呼ばれる次のメジャーアップグレードの準備をしています。 Bedrockは、楽観主義が内部でどのように機能するかを大幅に刷新し、楽観主義をこれまでで最も速く、最も安価で、最も信頼性の高いロールアップにするのに役立ちます。 Bedrock アップグレードの詳細な仕様は、このリポジトリの specs フォルダーにあります。
このリポジトリ内のかなりの数のパッケージとフォルダーはBedrockアップグレードの一部であり、現在本番環境では実行されていないことに注意してください。 以下の「ディレクトリ構造」セクションを参照して、現在本番環境で実行されているパッケージと、Bedrockアップグレードの一部として使用することを目的としたパッケージを理解してください。
~~ Production ~~ ├── packages │ ├── common-ts: Common tools for building apps in TypeScript │ ├── contracts: L1 and L2 smart contracts for Optimism │ ├── contracts-periphery: Peripheral contracts for Optimism │ ├── core-utils: Low-level utilities that make building Optimism easier │ ├── data-transport-layer: Service for indexing Optimism-related L1 data │ ├── chain-mon: Chain monitoring services │ ├── fault-detector: Service for detecting Sequencer faults │ ├── message-relayer: Tool for automatically relaying L1<>L2 messages in development │ ├── replica-healthcheck: Service for monitoring the health of a replica node │ └── sdk: provides a set of tools for interacting with Optimism ├── batch-submitter: Service for submitting batches of transactions and results to L1 ├── bss-core: Core batch-submitter logic and utilities ├── gas-oracle: Service for updating L1 gas prices on L2 ├── indexer: indexes and syncs transactions ├── infra/op-replica: Deployment examples and resources for running an Optimism replica ├── integration-tests: Various integration tests for the Optimism network ├── l2geth: Optimism client software, a fork of geth v1.9.10 (deprecated for BEDROCK upgrade) ├── l2geth-exporter: A prometheus exporter to collect/serve metrics from an L2 geth node ├── op-exporter: A prometheus exporter to collect/serve metrics from an Optimism node ├── proxyd: Configurable RPC request router and proxy ├── technical-documents: audits and post-mortem documents ~~ BEDROCK upgrade - Not production-ready yet, part of next major upgrade ~~ ├── packages │ └── contracts-bedrock: Bedrock smart contracts. To be merged with ./packages/contracts. ├── op-bindings: Go bindings for Bedrock smart contracts. ├── op-batcher: L2-Batch Submitter, submits bundles of batches to L1 ├── op-e2e: End-to-End testing of all bedrock components in Go ├── op-node: rollup consensus-layer client. ├── op-proposer: L2-Output Submitter, submits proposals to L1 ├── ops-bedrock: Bedrock devnet work └── specs: Specs of the rollup starting at the Bedrock upgrade
枝 | 地位 |
---|---|
主人 | メインネットに展開する予定のときからPRを受け入れます。develop |
開ける | ブランチからの OR と互換性のある PR を受け入れます。master release/X.X.X |
リリース/X.X.X | すべての変更、特に と との後方互換性のない変更の PR を受け入れます。develop master |
通常、この Git 分岐モデルに従います。 このリポジトリに頻繁にPRを行うことを計画している場合は、リンク先の投稿をお読みください(たとえば、Optimismで/一緒に働いている人々)。
当社の生産支店は. ブランチには、最新の「安定版」リリースのコードが含まれています。 更新元は常にブランチから行われます。 ブランチを更新するのは、楽観主義メインネット内にコードをデプロイする場合にのみです。 更新プロセスは、ブランチをブランチにマージする PR の形をとります。
master
master
master
develop
master
develop
develop
master
私たちの主要な開発部門は開発
です。 最新の実験的なネットワーク展開との下位互換性を維持する最新のソフトウェアが含まれています。
下位互換性のある変更を行う場合は、プルリクエストを .
develop
develop
パッケージ/コントラクト/コントラクト内のコントラクトへの変更は、通常、後方互換性があるとは見なされず、リリース候補ブランチに対して行う必要があります
。
このルールには、リリース候補ブランチがすでに完全にデプロイされた後に新しいコントラクトを絶対にデプロイする必要がある場合には、いくつかの例外があります。
コントラクトを変更または追加していて、PR を行うブランチがわからない場合は、既定で最新のリリース候補ブランチを使用します。
リリース候補ブランチについては、以下を参照してください。
マークされたブランチは、リリース候補ブランチです。 下位互換性のない変更、および内のコントラクトに対するすべての変更は、リリース候補ブランチに送信する必要があります。 リリース候補は、完全に展開されると、にマージされます。 デプロイの途中の場合、複数のアクティブなブランチがある場合があります。 上記の「アクティブなブランチ」セクションの表を参照して、ターゲットとする適切なブランチを見つけてください。
release/X.X.X
packages/contracts/contracts
develop
master
release/X.X.X
変更セットを使用して、パッケージに新しいリリースのマークを付けます。 コミットをブランチにマージするときに、変更によってパッケージの新しいバージョンをリリースする必要がある場合は、変更セットファイルを含める必要があります。
develop
変更セットを追加するには、このモノレポのルートでコマンドを実行します。 リリースするパッケージ、リリースの範囲 (メジャー、マイナー、またはパッチ)、およびリリースの理由を選択するための小さなプロンプトが表示されます。 変更セットファイル内のコメントは、パッケージの変更ログに自動的に含まれます。
yarn changeset
リリースは、次のプロセスを使用してトリガーできます。
develop
master
Version Packages
Version Packages
master
develop
develop
develop
master
2 番目の PR をブランチにマージすると、プロセスの開始時にブランチ内の変更セット ファイルのセットに従って、パッケージがそれぞれの場所に自動的にリリースされます。 このプロセスは、同期が崩れないように、リストされているとおりに実行してください。
master
develop
develop
master
注: リリース プロセス中にマージされた変更セット ファイルを含む PR は、変更セットで問題を引き起こし、修正するために手動による介入が必要になる場合があります。 アクティブなリリース中に PR を開発にマージしないことを強くお勧めします。
develop
ゴーイーサリアム
からl2geth
という名前でフォークされたコードは、元のライセンスに従ってGNU GPLv3の下でライセンスされています。
このリポジトリ内の他のすべてのファイルは、特に明記されていない限り、MITライセンスの下でライセンスされています。