15e2d615 (main)
and
547c6d0d (PR)
+1 -1
+1 -1
{
"architectureImage": "opstack-rollup-superchain-opfp-kailua",
"dataAvailability": [
{
"name": "All data required for proofs is published on chain",
"description": "All the data that is used to construct the system state is published on chain in the form of cheap blobs or calldata. This ensures that it will be available for enough time.",
"risks": [],
"references": [
{
"title": "Derivation: Batch submission - OP Mainnet specs",
"url": "https://github.com/ethereum-optimism/specs/blob/main/specs/protocol/derivation.md#batch-submission"
},
{
"title": "BatchInbox - address",
"url": "https://etherscan.io/address/0x3A75346f81302aAc0333FB5DCDD407e12A6CfA83#code"
},
{
"title": "OptimismPortal2.sol - source code, depositTransaction function",
"url": "https://etherscan.io/address/0xB250566074B3c0f1B109A531A83f3d9B1a579273#code"
}
]
}
],
"exitMechanisms": [
{
"name": "Regular exits",
"description": "The user initiates the withdrawal by submitting a regular transaction on this chain. When a state root containing such transaction is settled, the funds become available for withdrawal on L1 after 1d. Withdrawal inclusion can be proven before state root settlement, but a 1d period has to pass before it becomes actionable. The process of state root settlement takes a challenge period of at least 3d to complete. Finally the user submits an L1 transaction to claim the funds. This transaction requires a merkle proof.",
"risks": [],
"references": [
{
"title": "OptimismPortal2.sol - Etherscan source code, proveWithdrawalTransaction function",
"url": "https://etherscan.io/address/0xB250566074B3c0f1B109A531A83f3d9B1a579273#code"
},
{
"title": "OptimismPortal2.sol - Etherscan source code, finalizeWithdrawalTransaction function",
"url": "https://etherscan.io/address/0xB250566074B3c0f1B109A531A83f3d9B1a579273#code"
}
]
},
{
"name": "Forced messaging",
"description": "If the user experiences censorship from the operator with regular L2->L1 messaging they can submit their messages directly on L1. The system is then obliged to service this request or halt all messages, including forced withdrawals from L1 and regular messages initiated on L2. Once the force operation is submitted and if the request is serviced, the operation follows the flow of a regular message.",
"risks": [],
"references": [
{
"title": "Forced withdrawal from an OP Stack blockchain",
"url": "https://docs.optimism.io/stack/transactions/forced-transaction"
}
]
}
],
"forceTransactions": {
"name": "Users can force any transaction",
"description": "Because the state of the system is based on transactions submitted on the underlying host chain and anyone can submit their transactions there it allows the users to circumvent censorship by interacting with the smart contract on the host chain directly.",
"risks": [],
"references": [
{
"title": "Sequencing Window - OP Mainnet Specs",
"url": "https://github.com/ethereum-optimism/optimism/blob/51eeb76efeb32b3df3e978f311188aa29f5e3e94/specs/glossary.md#sequencing-window"
},
{
"title": "OptimismPortal2.sol - source code, depositTransaction function",
"url": "https://etherscan.io/address/0xB250566074B3c0f1B109A531A83f3d9B1a579273#code"
}
]
},
"operator": {
"name": "The system has a centralized operator",
"description": "The operator is the only entity that can propose blocks. A live and trustworthy operator is vital to the health of the system.",
"risks": [
{
"category": "MEV can be extracted if",
"text": "the operator exploits their centralized position and frontruns user transactions."
}
],
"references": []
},
"otherConsiderations": [
{
"name": "EVM compatible smart contracts are supported",
"description": "OP stack chains are pursuing the EVM Equivalence model. No changes to smart contracts are required regardless of the language they are written in, i.e. anything deployed on L1 can be deployed on L2.",
"risks": [],
"references": [
{
"title": "Introducing EVM Equivalence",
"url": "https://medium.com/ethereum-optimism/introducing-evm-equivalence-5c2021deb306"
}
]
}
],
"stateValidation": {
"categories": [
{
"title": "State root proposals",
"description": "Proposers submit state roots as children of any (possibly unresolved) previous state root proposal, by calling the `propose()` function in the KailuaTreasury. A parent state root can have multiple conflicting children, composing a tournament. Each proposer requires to lock a bond, currently set to 0.5 ETH, that can be slashed if any proposal made by them is proven incorrect via a fault proof or a conflicting validity proof. The bond can be withdrawn once the proposer has no more pending proposals that need to be resolved and was not eliminated.\n\nProposals consist of a state root and a reference to their parent and implicitly challenge any sibling proposals who have the same parent. A proposal asserts that the proposed state root constitutes a valid state transition from the parent's state root. To offer efficient zk fault proofs, each proposal must include 3600 intermediate state commitments, each spanning 6 L2 blocks. \n\nProposals target sequential tournament epochs of currently 3600 * 6 L2 blocks. A tournament with a resolved parent tournament, a single child- and no conflicting sibling proposals can be resolved after 3d. \n\nThe **Vanguard** is a privileged actor who can always make the first child proposal on a parent state root. They can, in the worst case, delay each tournament for up to 1mo by not making this first proposal. Sibling proposals made after the Vanguard's initial one or after the 1mo vanguardAdvantage in each tournament are permissionless.",
"references": [
{
"title": "'Sequencing' - Kailua Docs",
"url": "https://boundless-xyz.github.io/kailua/design.html#sequencing"
},
{
"title": "Vanguard - Kailua Docs",
"url": "https://boundless-xyz.github.io/kailua/parameters.html#vanguard-advantage"
}
]
},
{
"title": "Challenges",
"description": "\nAny conflicting sibling proposals within a tournament that are made within the 3d challenge period of a proposal they are challenging, delay resolving the tournament until sufficient ZK proofs are published to leave one single tournament survivor.\n\nIn the tree of proposed state roots, each parent node can have multiple children. These children are indirectly challenging each other in a tournament, which can only be resolved if but a single child survives. A state root can be resolved if it is **the only remaining proposal** due to any combination of the following elimination methods: \n1. the proposal's challenge period of 3d has ended before a conflicting proposal was made\n2. the proposal is proven correct with a full validity proof (invalidates all conflicting proposals)\n3. a conflicting sibling proposal is proven faulty\n\nProving any of the 3600 intermediate state commitments in a proposal faulty invalidates the entire proposal. Proving a proposal valid invalidates all conflicting siblings. Pruning of a tournament's children happens strictly chronologically, which guarantees that the first faulty proposal of a given proposer is always pruned first. When pruned, an invalid proposal leads to the elimination of its proposer, which invalidates all their subsequent proposals, slashes their bond, and disallows future proposals by the same address. A slashed bond is transferred to an address chosen by the prover who caused the slashing.\n\nA single remaining child in a tournament can be 'resolved' and will be finalized and usable for withdrawals after an execution delay of 1d (time for the Guardian to manually blacklist malicious state roots).",
"references": [
{
"url": "https://docs.boundless.network/developers/kailua/quick-start",
"title": "Disputes - Kailua Docs"
}
]
},
{
"title": "Validity proofs",
"description": "Validity proofs and fault proofs both must be accompanied by a ZK proof that ensures that the new state was derived by correctly applying a series of valid user transactions to the previous state. These proofs are then verified on Ethereum by a smart contract.\n\nThe Kailua state validation system is primarily optimistically resolved, so no validity proofs are required in the happy case. But two different zk proofs on unresolved state roots are possible and permissionless: The proveValidity() function proves a state root proposal's full validity, automatically invalidating all conflicting sibling proposals. proveOutputFault() allows any actor to eliminate a state root proposal for which they can prove that any of the 3600 intermediate state transitions in the proposal are not correct. Both are zk proofs of validity, although one is used as an efficient fault proof to invalidate a single conflicting state transition.",
"references": [
{
"url": "https://risczero.com/blog/kailua-how-it-works",
"title": "Risc0 Kailua Docs"
},
{
"url": "https://github.com/risc0/risc0-ethereum/blob/main/contracts/version-management-design.md",
"title": "Verifier upgrade and deprecation - Kailua Docs"
}
],
"risks": [
{
"category": "Funds can be stolen if",
"text": "the validity proof cryptography is broken or implemented incorrectly."
},
{
"category": "Funds can be stolen if",
"text": "no challenger checks the published state"
"text": "no challenger checks the published state."
},
{
"category": "Funds can be stolen if",
"text": "the proposer routes proof verification through a malicious or faulty verifier by specifying an unsafe route selector."
},
{
"category": "Funds can be frozen if",
"text": "a verifier needed for a given proof is paused by its permissioned owner."
}
]
}
]
},
"stateValidationImage": "kailua"
}+1 -1
+1 -1
{
"architectureImage": "opstack-optimium-superchain-opfp",
"dataAvailability": [
{
"name": "Data is posted to EigenDA",
"description": "Transactions roots are posted onchain and the full data is posted on EigenDA. The sequencer is publishing data to EigenDA v2. Since the DACert Verifier is not used, availability of the data is not verified against EigenDA operators, meaning that the Sequencer can single-handedly publish unavailable commitments. If EigenDA becomes unavailable, the sequencer falls back to Ethereum.",
"risks": [
{
"category": "Funds can be lost if",
"text": "the sequencer posts an unavailable transaction root.",
"isCritical": true
},
{
"category": "Funds can be lost if",
"text": "the data is not available on the external provider.",
"isCritical": true
}
],
"references": [
{
"title": "EigenDA Docs - Overview",
"url": "https://docs.eigenda.xyz/overview"
},
{
"title": "Derivation: Batch submission - OP Mainnet specs",
"url": "https://github.com/ethereum-optimism/specs/blob/main/specs/protocol/derivation.md#batch-submission"
},
{
"title": "BatchInbox - address",
"url": "https://etherscan.io/address/0xfF000000000000000000000000000000000000FF#code"
},
{
"title": "OptimismPortal2.sol - source code, depositTransaction function",
"url": "https://etherscan.io/address/0x29174FC953F163452093aFa9eE3904168C74b2E7#code"
}
]
}
],
"exitMechanisms": [
{
"name": "Regular exits",
"description": "The user initiates the withdrawal by submitting a regular transaction on this chain. When a state root containing such transaction is settled, the funds become available for withdrawal on L1 after 8h. Withdrawal inclusion can be proven before state root settlement, but a 8h period has to pass before it becomes actionable. The process of state root settlement takes a challenge period of at least 18h to complete. Finally the user submits an L1 transaction to claim the funds. This transaction requires a merkle proof.",
"risks": [],
"references": [
{
"title": "OptimismPortal2.sol - Etherscan source code, proveWithdrawalTransaction function",
"url": "https://etherscan.io/address/0x29174FC953F163452093aFa9eE3904168C74b2E7#code"
},
{
"title": "OptimismPortal2.sol - Etherscan source code, finalizeWithdrawalTransaction function",
"url": "https://etherscan.io/address/0x29174FC953F163452093aFa9eE3904168C74b2E7#code"
}
]
},
{
"name": "Forced messaging",
"description": "If the user experiences censorship from the operator with regular L2->L1 messaging they can submit their messages directly on L1. The system is then obliged to service this request or halt all messages, including forced withdrawals from L1 and regular messages initiated on L2. Once the force operation is submitted and if the request is serviced, the operation follows the flow of a regular message.",
"risks": [],
"references": [
{
"title": "Forced withdrawal from an OP Stack blockchain",
"url": "https://docs.optimism.io/stack/transactions/forced-transaction"
}
]
}
],
"forceTransactions": {
"name": "Users can force any transaction",
"description": "Because the state of the system is based on transactions submitted on the underlying host chain and anyone can submit their transactions there it allows the users to circumvent censorship by interacting with the smart contract on the host chain directly.",
"risks": [],
"references": [
{
"title": "Sequencing Window - OP Mainnet Specs",
"url": "https://github.com/ethereum-optimism/optimism/blob/51eeb76efeb32b3df3e978f311188aa29f5e3e94/specs/glossary.md#sequencing-window"
},
{
"title": "OptimismPortal2.sol - source code, depositTransaction function",
"url": "https://etherscan.io/address/0x29174FC953F163452093aFa9eE3904168C74b2E7#code"
}
]
},
"operator": {
"name": "The system has a centralized operator",
"description": "The operator is the only entity that can propose blocks. A live and trustworthy operator is vital to the health of the system.",
"risks": [
{
"category": "MEV can be extracted if",
"text": "the operator exploits their centralized position and frontruns user transactions."
}
],
"references": []
},
"otherConsiderations": [
{
"name": "Solana Virtual Machine is supported",
"description": "OP stack chains are usually pursuing the EVM Equivalence model. But Soon implements the rust-based Solana virtual machine (SVM) which uses parallel processing.",
"risks": [],
"references": [
{
"title": "Soon Docs - Decoupled SVM",
"url": "https://docs.soo.network/introduction/decoupled-svm"
}
]
}
],
"stateValidation": {
"categories": [
{
"title": "State root proposals",
"description": "Proposers submit state roots as children of any (possibly unresolved) previous state root proposal, by calling the `propose()` function in the KailuaTreasury. A parent state root can have multiple conflicting children, composing a tournament. Each proposer requires to lock a bond, currently set to 0.01 ETH, that can be slashed if any proposal made by them is proven incorrect via a fault proof or a conflicting validity proof. The bond can be withdrawn once the proposer has no more pending proposals that need to be resolved and was not eliminated.\n\nProposals consist of a state root and a reference to their parent and implicitly challenge any sibling proposals who have the same parent. A proposal asserts that the proposed state root constitutes a valid state transition from the parent's state root. To offer efficient zk fault proofs, each proposal must include 100 intermediate state commitments, each spanning 50 L2 blocks.\n\nProposals target sequential tournament epochs of currently 100 * 50 L2 blocks. A tournament with a resolved parent tournament, a single child- and no conflicting sibling proposals can be resolved after 18h.",
"references": [
{
"title": "'Sequencing' - Kailua Docs",
"url": "https://boundless-xyz.github.io/kailua/design.html#sequencing"
}
]
},
{
"title": "Challenges",
"description": "\nAny conflicting sibling proposals within a tournament that are made within the 18h challenge period of a proposal they are challenging, delay resolving the tournament until sufficient ZK proofs are published to leave one single tournament survivor.\n\nIn the tree of proposed state roots, each parent node can have multiple children. These children are indirectly challenging each other in a tournament, which can only be resolved if but a single child survives. A state root can be resolved if it is **the only remaining proposal** due to any combination of the following elimination methods:\n1. the proposal's challenge period of 18h has ended before a conflicting proposal was made\n2. the proposal is proven correct with a full validity proof (invalidates all conflicting proposals)\n3. a conflicting sibling proposal is proven faulty\n\nProving any of the 100 intermediate state commitments in a proposal faulty invalidates the entire proposal. Proving a proposal valid invalidates all conflicting siblings. Pruning of a tournament's children happens strictly chronologically, which guarantees that the first faulty proposal of a given proposer is always pruned first. When pruned, an invalid proposal leads to the elimination of its proposer, which invalidates all their subsequent proposals, slashes their bond, and disallows future proposals by the same address. A slashed bond is transferred to an address chosen by the prover who caused the slashing.\n\nA single remaining child in a tournament can be 'resolved' and will be finalized and usable for withdrawals after an execution delay of 8h (time for the Guardian to manually blacklist malicious state roots).",
"references": [
{
"url": "https://docs.boundless.network/developers/kailua/quick-start",
"title": "Disputes - Kailua Docs"
}
]
},
{
"title": "Validity proofs",
"description": "Validity proofs and fault proofs both must be accompanied by a ZK proof that ensures that the new state was derived by correctly applying a series of valid user transactions to the previous state. These proofs are then verified on Ethereum by a smart contract.\n\nThe Kailua state validation system is primarily optimistically resolved, so no validity proofs are required in the happy case. But two different zk proofs on unresolved state roots are possible and permissionless: The proveValidity() function proves a state root proposal's full validity, automatically invalidating all conflicting sibling proposals. proveOutputFault() allows any actor to eliminate a state root proposal for which they can prove that any of the 100 intermediate state transitions in the proposal are not correct. Both are zk proofs of validity, although one is used as an efficient fault proof to invalidate a single conflicting state transition.",
"references": [
{
"url": "https://github.com/soonlabs/kailua-soon",
"title": "SOON Kailua - GitHub"
},
{
"url": "https://risczero.com/blog/kailua-how-it-works",
"title": "Risc0 Kailua Docs"
},
{
"url": "https://github.com/risc0/risc0-ethereum/blob/main/contracts/version-management-design.md",
"title": "Verifier upgrade and deprecation - Kailua Docs"
}
],
"risks": [
{
"category": "Funds can be stolen if",
"text": "the validity proof cryptography is broken or implemented incorrectly."
},
{
"category": "Funds can be stolen if",
"text": "no challenger checks the published state"
"text": "no challenger checks the published state."
},
{
"category": "Funds can be stolen if",
"text": "the proposer routes proof verification through a malicious or faulty verifier by specifying an unsafe route selector."
},
{
"category": "Funds can be frozen if",
"text": "a verifier needed for a given proof is paused by its permissioned owner."
}
]
}
]
}
}