chore: Base and Optimism deployments #84
Conversation
|
Tip 🔌 Remote MCP (Model Context Protocol) integration is now available!Pro plan users can now connect to remote MCP servers from the Integrations page. Connect with popular remote MCPs such as Notion and Linear to add more context to your reviews and chats. ✨ Finishing Touches🧪 Generate unit tests
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. 🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
SupportNeed help? Create a ticket on our support page for assistance with any issues or questions. CodeRabbit Commands (Invoked using PR/Issue comments)Type Other keywords and placeholders
CodeRabbit Configuration File (
|
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 1
🧹 Nitpick comments (4)
contracts/deployments/optimism/RealitioHomeProxyOptimism.json (1)
176-187: MIN_GAS_LIMIT constant (1,500,000): double-check headroom for messenger.sendMessage to L1.The constant seems conservative; callers fund L2 gas, so overestimation mainly affects user cost. Validate on a canary that acknowledgement/cancellation messages succeed with this limit under typical calldata sizes.
If recent OP Bedrock guidance suggests a lower safe bound, consider lowering for future deployments to reduce costs.
contracts/deployments/base/RealitioHomeProxyBase.json (3)
2-2: Same deployed address as Optimism artifact — confirm intended cross-L2 parity.If deterministic CREATE was used with the same nonce, identical addresses across Base and Optimism are expected. Please confirm this was planned (it can simplify UI configs but can confuse operators if not documented).
I can add a short README note in deployments/ to document the “same address on OP-stack L2s” rationale if helpful.
176-187: MIN_GAS_LIMIT check for Base as well.Base uses the OP messenger precompile, so the same gas limit applies. Validate that 1.5M is sufficient/excessive for Base relays too.
450-452: Deployed bytecode equality vs Optimism artifact.These bytes appear identical between Base and Optimism artifacts, which is what we want. To be certain (and to catch future drift), consider adding a CI check that asserts the deployedBytecode fields match across OP-stack L2 deployments when the source/solcInputHash are equal.
I can wire a small script in scripts/verify-bytecode-parity.sh and a lightweight CI job.
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
💡 Knowledge Base configuration:
- MCP integration is disabled by default for public repositories
- Jira integration is disabled by default for public repositories
- Linear integration is disabled by default for public repositories
You can enable these sources in your CodeRabbit configuration.
📒 Files selected for processing (2)
contracts/deployments/base/RealitioHomeProxyBase.json(1 hunks)contracts/deployments/optimism/RealitioHomeProxyOptimism.json(1 hunks)
🧰 Additional context used
🧠 Learnings (1)
📚 Learning: 2025-01-17T12:07:18.176Z
Learnt from: jaybuidl
PR: kleros/cross-chain-realitio-proxy#54
File: contracts/src/0.8/RealitioHomeProxyGnosis.sol:174-184
Timestamp: 2025-01-17T12:07:18.176Z
Learning: In RealitioHomeProxyGnosis.sol, the receiveArbitrationFailure function already follows the Checks-Effects-Interactions pattern by updating the request status before making the external call to realitio.cancelArbitration.
Applied to files:
contracts/deployments/base/RealitioHomeProxyBase.jsoncontracts/deployments/optimism/RealitioHomeProxyOptimism.json
🔇 Additional comments (8)
contracts/deployments/optimism/RealitioHomeProxyOptimism.json (5)
215-231: Public “handle” functions are intentionally unrestricted; status gating looks correct.*ABI shows handleNotifiedRequest/handleRejectedRequest as external/nonpayable without auth. That matches the design in this proxy family: anyone can advance the flow after the L2-side notify/reject, with safety enforced by request.status checks. No change requested.
Please confirm this matches the intended UX on Optimism (i.e., any caller pays L2 gas to relay to L1 via messenger.sendMessage).
Also applies to: 233-249
321-343: CEI in receiveArbitrationFailure is preserved (good).Per past learning, the implementation updates status before calling realitio.cancelArbitration. The embedded source in metadata reflects that ordering.
441-446: Constructor args sanity-check (Realitio, metadata, foreignProxy, foreignChainId).
- _realitio: 0x0eF940F7… — verify it’s the v3 Realitio on Optimism and implements notify/cancel/assign per IRealitio.
- _foreignProxy: 0xd8b33e3F… — verify it’s the L1 Foreign proxy and is live.
- metadata string includes "foreignProxy": true — this extra field is non-standard for Realitio metadata (usually tos/template_hashes). Ensure downstream clients ignore unknown keys.
- _foreignChainId: 1 — aligns with Ethereum mainnet.
Would you like a quick script to check bytecode interfaces of these addresses on their respective networks?
2-2: Duped address across Base/Optimism artifacts appears intentional but deserves a check.This contract address matches the one in contracts/deployments/base/RealitioHomeProxyBase.json. Same EOA and matching nonces across OP-stack L2s can yield identical CREATE addresses; just confirm that was deliberate to simplify off-chain config.
I can add a small repo script to diff the deployedBytecode across both artifacts to assert they’re identical.
425-440: On-chain receipt details: confirm against an explorer.Block/tx indexes and gasUsed look plausible for a create. As a final guard, verify transactionHash and contractAddress on an Optimism explorer.
contracts/deployments/base/RealitioHomeProxyBase.json (3)
215-231: Unrestricted “handle” ABI on Base mirrors Optimism — OK.*Status checks in storage gate progress and the caller funds L2 gas. Behavior parity across chains is good.
Also applies to: 233-249
441-446: Constructor args sanity-check (Base).
- _realitio: 0x2F39f464… — should be Realitio v3 on Base.
- _foreignProxy: 0x54811E11… — mainnet Foreign proxy address; confirm it’s the correct instance.
- metadata contains "foreignProxy": true — verify consumer compatibility.
- foreignChainId = 1 — OK.
425-440: Receipt/tx on Base: verify on explorer.BlockNumber 34,550,477 and gasUsed 1,166,393 look reasonable. Cross-check the tx and resulting code size against deployedBytecode.
| "notice": "Reports the answer provided by the arbitrator to a specified question." | ||
| } | ||
| }, | ||
| "version": 1 | ||
| }, | ||
| "storageLayout": { | ||
| "storage": [ | ||
| { | ||
| "astId": 21636, | ||
| "contract": "src/0.8/RealitioHomeProxyOptimism.sol:RealitioHomeProxyOptimism", | ||
| "label": "metadata", | ||
| "offset": 0, | ||
| "slot": "0", | ||
| "type": "t_string_storage" | ||
| }, | ||
| { | ||
| "astId": 21657, | ||
| "contract": "src/0.8/RealitioHomeProxyOptimism.sol:RealitioHomeProxyOptimism", | ||
| "label": "requests", | ||
| "offset": 0, | ||
| "slot": "1", | ||
| "type": "t_mapping(t_bytes32,t_mapping(t_address,t_struct(Request)21649_storage))" | ||
| }, | ||
| { | ||
| "astId": 21662, | ||
| "contract": "src/0.8/RealitioHomeProxyOptimism.sol:RealitioHomeProxyOptimism", | ||
| "label": "questionIDToRequester", | ||
| "offset": 0, | ||
| "slot": "2", | ||
| "type": "t_mapping(t_bytes32,t_address)" | ||
| } | ||
| ], | ||
| "types": { | ||
| "t_address": { | ||
| "encoding": "inplace", | ||
| "label": "address", | ||
| "numberOfBytes": "20" | ||
| }, | ||
| "t_bytes32": { | ||
| "encoding": "inplace", | ||
| "label": "bytes32", | ||
| "numberOfBytes": "32" | ||
| }, | ||
| "t_enum(Status)21643": { | ||
| "encoding": "inplace", | ||
| "label": "enum RealitioHomeProxyOptimism.Status", | ||
| "numberOfBytes": "1" | ||
| }, | ||
| "t_mapping(t_address,t_struct(Request)21649_storage)": { | ||
| "encoding": "mapping", | ||
| "key": "t_address", | ||
| "label": "mapping(address => struct RealitioHomeProxyOptimism.Request)", | ||
| "numberOfBytes": "32", | ||
| "value": "t_struct(Request)21649_storage" | ||
| }, | ||
| "t_mapping(t_bytes32,t_address)": { | ||
| "encoding": "mapping", | ||
| "key": "t_bytes32", | ||
| "label": "mapping(bytes32 => address)", | ||
| "numberOfBytes": "32", | ||
| "value": "t_address" | ||
| }, | ||
| "t_mapping(t_bytes32,t_mapping(t_address,t_struct(Request)21649_storage))": { | ||
| "encoding": "mapping", | ||
| "key": "t_bytes32", | ||
| "label": "mapping(bytes32 => mapping(address => struct RealitioHomeProxyOptimism.Request))", | ||
| "numberOfBytes": "32", | ||
| "value": "t_mapping(t_address,t_struct(Request)21649_storage)" | ||
| }, | ||
| "t_string_storage": { | ||
| "encoding": "bytes", | ||
| "label": "string", | ||
| "numberOfBytes": "32" | ||
| }, | ||
| "t_struct(Request)21649_storage": { | ||
| "encoding": "inplace", | ||
| "label": "struct RealitioHomeProxyOptimism.Request", | ||
| "members": [ | ||
| { | ||
| "astId": 21646, | ||
| "contract": "src/0.8/RealitioHomeProxyOptimism.sol:RealitioHomeProxyOptimism", | ||
| "label": "status", | ||
| "offset": 0, | ||
| "slot": "0", | ||
| "type": "t_enum(Status)21643" | ||
| }, | ||
| { | ||
| "astId": 21648, | ||
| "contract": "src/0.8/RealitioHomeProxyOptimism.sol:RealitioHomeProxyOptimism", | ||
| "label": "arbitratorAnswer", | ||
| "offset": 0, | ||
| "slot": "1", | ||
| "type": "t_bytes32" | ||
| } | ||
| ], | ||
| "numberOfBytes": "64" | ||
| } | ||
| } | ||
| } | ||
| } |
There was a problem hiding this comment.
💡 Verification agent
🧩 Analysis chain
Quick repo-side verification script to validate both artifacts.
Run this to check deployedBytecode parity and surface address/arg differences:
🏁 Script executed:
#!/usr/bin/env bash
set -euo pipefail
OPT_FILE="contracts/deployments/optimism/RealitioHomeProxyOptimism.json"
BASE_FILE="contracts/deployments/base/RealitioHomeProxyBase.json"
echo "Addresses:"
jq -r '.address' "$OPT_FILE" "$BASE_FILE"
echo "Constructor args (realitio, foreignProxy, foreignChainId):"
jq -r '[.args[0], .args[2], .args[3]] | @tsv' "$OPT_FILE"
jq -r '[.args[0], .args[2], .args[3]] | @tsv' "$BASE_FILE"
echo "Deployed bytecode SHA-256:"
sha256sum <(jq -r '.deployedBytecode' "$OPT_FILE") <(jq -r '.deployedBytecode' "$BASE_FILE")
echo "solcInputHash:"
jq -r '.solcInputHash' "$OPT_FILE" "$BASE_FILE"
echo "ABIs equal?:"
diff -q <(jq -c '.abi' "$OPT_FILE") <(jq -c '.abi' "$BASE_FILE") && echo "Yes" || echo "No"
echo "Done."Length of output: 1289
🏁 Script executed:
#!/usr/bin/env bash
set -euo pipefail
OPT_FILE="contracts/deployments/optimism/RealitioHomeProxyOptimism.json"
BASE_FILE="contracts/deployments/base/RealitioHomeProxyBase.json"
echo "Addresses:"
jq -r '.address' "$OPT_FILE" "$BASE_FILE"
echo -e "\nConstructor args (realitio, foreignProxy, foreignChainId):"
jq -r '[.args[0], .args[2], .args[3]] | @tsv' "$OPT_FILE"
jq -r '[.args[0], .args[2], .args[3]] | @tsv' "$BASE_FILE"
echo -e "\nBytecode identical?"
if diff -q <(jq -r '.deployedBytecode' "$OPT_FILE") <(jq -r '.deployedBytecode' "$BASE_FILE"); then
echo "Yes"
else
echo "No"
fi
echo -e "\nsolcInputHash:"
jq -r '.solcInputHash' "$OPT_FILE"
jq -r '.solcInputHash' "$BASE_FILE"
echo -e "\nABIs identical?"
if diff -q <(jq -c '.abi' "$OPT_FILE") <(jq -c '.abi' "$BASE_FILE"); then
echo "Yes"
else
echo "No"
fiLength of output: 1882
Artifacts mismatch between base and Optimism deployments
The quick verification script reveals several inconsistencies between contracts/deployments/optimism/RealitioHomeProxyOptimism.json and contracts/deployments/base/RealitioHomeProxyBase.json:
-
Addresses
• Both files reference the same deployed address:
0x5AFa42b30955f137e10f89dfb5EF1542a186F90e -
Constructor arguments (realitio, foreignProxy, foreignChainId)
• Optimism JSON:
– realitio: 0x0eF940F7f053a2eF5D6578841072488aF0c7d89A
– foreignProxy: 0xd8b33e3F5426dB753D1C6c78b43d5151970cd928
– foreignChainId: 1
• Base JSON:
– realitio: 0x2F39f464d16402Ca3D8527dA89617b73DE2F60e8
– foreignProxy: 0x54811E1157CCc2BE68Ce4CC850e5ab3382fe627F
– foreignChainId: 1 -
Deployed bytecode
• The rawdeployedBytecodestrings differ (despite identicalsolcInputHash) -
ABI
• Theabiarrays are not byte-for-byte identical
Next steps:
• Confirm whether the base deployment artifact is intended to mirror the Optimism one.
• If so, update RealitioHomeProxyBase.json to match the actual Optimism deployment (constructor args, ABI, bytecode).
• Otherwise, document and justify the differences in the repository’s README or deployment guide.
🤖 Prompt for AI Agents
In contracts/deployments/base/RealitioHomeProxyBase.json (lines 1-715) the
artifact contents (constructor args: realitio, foreignProxy, foreignChainId;
deployedBytecode; abi) do not match the Optimism deployment artifact — summary:
artifact mismatch between base and optimism deployments. If the base artifact is
supposed to mirror the Optimism deployment, replace the Base JSON fields with
the actual Optimism artifact values (address, args array, abi, bytecode,
deployedBytecode, metadata/solc hashes as necessary) ensuring constructor args
match Optimism (realitio 0x0eF94..., foreignProxy 0xd8b33e..., foreignChainId 1)
and verify solcInputHash/metadata align; otherwise, add a clear
README/deployments note explaining why the Base artifact differs and include
provenance (which network/address each artifact corresponds to) and a link to
the canonical Optimism artifact for auditors.
Summary by CodeRabbit
New Features
Chores