💿
Optimism公式Docsの要点をまとめる
はじめに
Optimismを雰囲気でやってたので公式Docをメモ程度にまとめました
- How Optimism Works
- Github
まとめ
- Optimismのtxなどのブロックチェーンを構成するデータをEthereum上のコントラクトに保存している
- Optimismのノードはそのコントラクトから情報を取得し、コントラクトのEventと同期しながらローカルで動いている
- Optimismのtxは、sequencerに渡され順番に処理される
- 現在は、Sequencerと呼ばれるOPLabsが提供するノードのみが動いている
所感
- Ethereum2.0ではLayer2はexecution layerとなり、改めてOptimismはきちんとLayer2なんだなと改めて実感できました
- 「ConsensusはEthereum、Storageはコントラクトで管理、Exusecutionはsequencer」
- ただ、現状の仕組みだとnodeが分散したときにスケールしそうにないため、execution layerといいつつも少し気持ち悪さを感じてます
How Optimism Works
Design philosophy
４つのデザインフィロソフィーを置いている
- Simplicity
- シンプルにすることで移行コストをさげ、シンプルだからこそセキュリティーも上がる
- Pragmatism
- 理論的な完成よりも利用者や開発者の必要性に重きを置く
- Sustainability
- スケーラビリティーへのショートカットではなく、長期的な持続可能性
- At the end of the day, a scalable system means nothing without the ecosystem that sustains it.
- いい言葉！
-
Optimism
Rollup Protocol
参考：https://community.optimism.io/docs/protocol/2-rollup-protocol/
-
Block storage
- CanonicalTransactionChainにOptimismのBlockは保存される
- Ethereumでの50blocksまでのreorgであれば、Optimismの堅牢性は保たれる？
-
Block production
- “sequencer”によって管理されている
- tx confirmation, state update
- L2のblockの構成と実行
- L1へのtx提出
- sequencerにはmempoolはなく、txを順次検証（十分なガス代があるか）し、ローカルのブロックに書き込んでいる
- ある程度溜まったら一気に書き込み
- どのくらいためてる？
- ある程度溜まったら一気に書き込み
- sequncerは現在、OP Labs PBCのみ
- sequencerをスキップしてL1に書き込むことも可能
- “sequencer”によって管理されている
-
Block execution
- Ethereum nodeではp2pでデータのダウンロードが行われるが、Optimism nodeの場合はCanonicalTransactionChainからダウンロードされる
- Optimism nodeの２つの役割
- DTL (Data Transport Layer)
- ≒ Ethereum Data indexer
- CanonicalTransactionChainからOptimism Blockchainを構築する
- CanonicalTransactionChainのEventでOptimismのblockを同期
- Optimism client software
- RPCとほぼ同義
- DLTの監視
- DTL (Data Transport Layer)
Bridging assets between layers
- Ethereum to Optimism
- CanonicalTransactionChainにてblockを生成するだけ
- Optimism to Ethereum
- Ethereum上のStateCommitmentChainにOptimismのコミットメントが1時間に1~2回発行される
- このコミットからOptimismのMerkleTreeを証明でき、任意のブロック高での特定のOptimismでのコントラクトのデータの検証可能なステートメントを作成できる
Contract Overview
参考：https://community.optimism.io/docs/protocol/protocol-2.0
System Overview
- Chain
- Layer1にあるコントラクト群
- Layer2のtx orderとL2-state rootsのに紐ずくコミットメントを管理している
- Verification
- 上記Chainへの書き込みが正しいかを検証する
- 書き込みが正しくないと証明されたらSequencerのbondから報酬を獲得できる
- まだ詳細は開発中
- Bridge
- L1-L2間のcross domain messageを行うコントラクト
- Predeploys
- genesis stateとして利用可能なすでにデプロイされてるコントラクト。0x42から始まる
- Ethereumのprecompilesに近いけど、solidityで書かれてる
Chain
- CanonicalTransactionChain (CTC)
-
StateCommitmentChain (SCC)
- ソース
- CTCの各txのstate rootのリストが含まれており、1:1で紐付いている
-
ChainStorageContainer
- ソース
-
RingBufferデータ構造で財利用可能なstorageを提供するもの - 不必要なstorage slotは上書きされる
- 合計３つあり、２つはCTC、一つはSCCに利用されている
Verification
- BondManagr
- Bondの管理
- faud proofの検証にかかったガス代の計算を行い、ガス代も報酬として渡す
Bridge
- L1CrossDomainMessenger
- L2CrossDomainMessenger
The Standard Bridge
cros domain messagingの一つのもうしわとしてERC20やETHのLayer間transferがある
L1→L2の場合、L1のコントラクトにトークンをデポジットして、L2でデポジットと同額をmintする
-
L1StandardBridge
- L1のdepositとL2からのwithdrawの管理
-
L2StandardBridge
- L2のdepositとL1からのwithdrawの管理
-
L2StandardTokenFactory
- L2 token contractを作成するコントラクト
- contractを作るcontractはfactoryと呼ばれる
Predeploy Contract
@eth-optimism/contractsのパッケージでpredeployを管理できる
-
OVM_L1MessageSender
- L1→L2のmessageの際に、L1でのsender addressを返す
- solidityではないみたい
- OVM_L2ToL1MessagePasser
- sentMessagesのmappingにtxhashを格納しL2のメッセージをL1で証明する際に使う
- OVM_SequencerFeeVault
- L2のtx dataをL1にcalldataとして書き込むガス代を一定額になるまでsequencerに支払われるガス代を保持するコントラクト
- 今は15ETH
- withdrawが0x00..000（sequencerに送られてる）
The Cannonical Transaction Chain (CTC) Format
Cannonical Transaction Chainに書き込むフォーマット
Batch Submitter
- ソース
- 概要
- Layer1とlocal Layer 2 nodeを監視しながら
CanonicalTransactionChainとStateCommitmentChainの主要関数の実行を行う
- Layer1とlocal Layer 2 nodeを監視しながら
- 重要な部分
-
CanonicalTransactionChain.appendSequencerBatch()の引数const batchElement = { stateRoot: block.stateRoot, timestamp: block.timestamp, blockNumber: block.transactions[0].l1BlockNumber, isSequencerTx: false, rawTransaction: undefined, } -
batchはPOLL_INTERVAL=15000でloopされている
-
Discussion