Files
smom-dbis-138/terraform/phases/phase1/config/GENESIS_PREDEPLOY_INSTRUCTIONS.md
defiQUG 1fb7266469 Add Oracle Aggregator and CCIP Integration
- Introduced Aggregator.sol for Chainlink-compatible oracle functionality, including round-based updates and access control.
- Added OracleWithCCIP.sol to extend Aggregator with CCIP cross-chain messaging capabilities.
- Created .gitmodules to include OpenZeppelin contracts as a submodule.
- Developed a comprehensive deployment guide in NEXT_STEPS_COMPLETE_GUIDE.md for Phase 2 and smart contract deployment.
- Implemented Vite configuration for the orchestration portal, supporting both Vue and React frameworks.
- Added server-side logic for the Multi-Cloud Orchestration Portal, including API endpoints for environment management and monitoring.
- Created scripts for resource import and usage validation across non-US regions.
- Added tests for CCIP error handling and integration to ensure robust functionality.
- Included various new files and directories for the orchestration portal and deployment scripts.
2025-12-12 14:57:48 -08:00

4.1 KiB

Genesis Predeploy Instructions

Overview

This genesis file includes structure for predeployed contracts at specific addresses. The code fields are currently empty (0x) and need to be filled with runtime bytecode for each contract.

Contract Addresses

Pre-funded Accounts (1,000,000,000 ETH each)

  • 0xa55A4B57A91561e9df5a883D4883Bd4b1a7C4882 - 1,000,000,000 ETH
  • 0xc2d6e6981d1a415967a683d615cf97ba9bc26f0f - 1,000,000,000 ETH
  • 0x70013b4a4d15c679f8c3423ab0e5012d52c7c678 - 1,000,000,000 ETH
  • 0x4a666f96fc8764181194447a7dfdb7d471b301c8 - 1,000,000,000 ETH
  • 0x742d35Cc6634C0532925a3b844Bc9e7595f0bEb - 1 ETH

Predeployed Contracts (1,000,000 ETH each, code needs to be filled)

  1. WETH9 - 0xC02aaA39b223FE8D0A0e5C4F27eAD9083C756Cc2

    • Balance: 1,000,000 ETH
    • Code: 0x (needs runtime bytecode)
    • Storage: {} (needs storage layout)
  2. WETH10 - 0xf4BB2e28688e89fCcE3c0580D37d36A7672E8A9f

    • Balance: 1,000,000 ETH
    • Code: 0x (needs runtime bytecode)
    • Storage: {} (needs storage layout)
  3. CCIP Router - 0x80226fc0Ee2b096224EeAc085Bb9a8cba1146f7D

    • Balance: 1,000,000 ETH
    • Code: 0x (needs runtime bytecode)
    • Storage: {"0x0": "0x000000000000000000000000a55A4B57A91561e9df5a883D4883Bd4b1a7C4882"} (owner slot placeholder)
  4. CCIP WETH9 Bridge - 0x3304b747E565a97ec8AC220b0B6A1f6ffDB837e6

    • Balance: 1,000,000 ETH
    • Code: 0x (needs runtime bytecode)
    • Storage: {} (needs storage layout)
  5. CCIP WETH10 Bridge - 0x8078A09637e47Fa5Ed34F626046Ea2094a5CDE5e

    • Balance: 1,000,000 ETH
    • Code: 0x (needs runtime bytecode)
    • Storage: {} (needs storage layout)
  6. CCIP Fee Token (LINK) - 0x514910771AF9Ca656af840dff83E8264EcF986CA

    • Balance: 1,000,000 ETH
    • Code: 0x (needs runtime bytecode)
    • Storage: {} (needs storage layout)

How to Fill in Runtime Bytecode

Step 1: Get Verified Source from Etherscan

For each contract address on mainnet:

  1. Go to https://etherscan.io/address/{address}
  2. Click "Contract" tab
  3. Copy:
    • Solidity source code
    • Compiler version (e.g., v0.4.18)
    • Optimization settings

Step 2: Compile with Same Settings

Using Hardhat/Foundry/Remix:

# Example with Foundry
forge build --optimize --optimizer-runs 200

# Extract runtime bytecode from artifacts
# Look for deployedBytecode or runtimeBytecode (NOT bytecode/creationBytecode)

Step 3: Extract Runtime Bytecode

From compilation artifacts:

  • Use: deployedBytecode or runtimeBytecode
  • Do NOT use: bytecode or creationBytecode (this is constructor bytecode)

Step 4: Determine Storage Layout (if needed)

Option A: Snapshot Storage from Deployment

  1. Deploy contract on a test chain
  2. Query storage via eth_getStorageAt
  3. Copy all non-zero storage slots

Option B: Manual Slot Calculation

For standard Solidity layouts:

  • Simple values: uint256 at slot n → key is 0x...n...
  • Mappings: mapping(address => uint256) balances at slot p:
    slot = keccak256(pad32(address) || pad32(slot_index))
    

Step 5: Update Genesis File

Replace "code": "0x" with actual runtime bytecode:

"0xC02aaA39b223FE8D0A0e5C4F27eAD9083C756Cc2": {
  "balance": "0xd3c21bcecceda1000000",
  "code": "0x608060405234801561001057600080fd5b50...",
  "storage": {
    "0x0": "0x0000000000000000000000000000000000000000000000000000000000000000"
  }
}

Balance Values

  • 1 ETH = 0xde0b6b3a7640000 (1 * 10^18 wei)
  • 1,000,000 ETH = 0xd3c21bcecceda1000000 (10^6 * 10^18 wei = 10^24 wei)
  • 1,000,000,000 ETH = 0x33b2e3c9fd0803ce8000000 (10^9 * 10^18 wei = 10^27 wei)

Next Steps

  1. Choose approach: Exact clones (Option A) or minimal mocks (Option B)
  2. Get runtime bytecode for each contract
  3. Determine storage layout (if needed)
  4. Update genesis file with actual bytecode and storage
  5. Test genesis file on a local Besu node before production deployment

Notes

  • Constructors do not run at genesis
  • Only runtime bytecode is used
  • Initial state must be set via storage field
  • Storage slots must be calculated correctly for mappings and complex types