d-bis/smom-dbis-138
4
0
Fork 0
Code Issues Pull Requests Actions 5 Packages Projects Releases Wiki Activity
Files
a780eff7c5215a6c2415ee8e7fcb9a765a7c7b29
smom-dbis-138/docs/deployment/36-REGION-BLUEPRINT.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

8.0 KiB
Raw Blame History

36-Region Global Deployment Blueprint

Overview

This document defines the latency-aware and balanced 36-region global deployment blueprint for the DeFi Oracle Meta Mainnet (ChainID 138).

Design Principles:

  • Latency-aware: Regions grouped into low-latency "rings" for consensus optimization
  • Balanced: Even geographic distribution across all continents
  • Quota-optimized: All regions within 10 vCPU per region limit
  • Practical: All regions are non-US commercial Azure regions

🌍 36-Region Workload Set (Non-US Commercial)

Geographic Distribution

Europe (14 regions)

  • West Europe (westeurope) - Primary
  • North Europe (northeurope) - Primary
  • UK South (uksouth) - Primary
  • UK West (ukwest)
  • France Central (francecentral) - Primary
  • Germany West Central (germanywestcentral) - Primary
  • Switzerland North (switzerlandnorth) - Primary
  • Sweden Central (swedencentral)
  • Norway East (norwayeast)
  • Poland Central (polandcentral)
  • Spain Central (spaincentral)
  • Italy North (italynorth)
  • Austria East (austriaeast)
  • Belgium Central (belgiumcentral)

Asia Pacific incl. India (13 regions)

  • East Asia (eastasia) - Primary
  • Southeast Asia (southeastasia) - Primary
  • Japan East (japaneast) - Primary
  • Japan West (japanwest)
  • Korea Central (koreacentral)
  • Korea South (koreasouth)
  • Australia East (australiaeast) - Primary
  • Australia Southeast (australiasoutheast)
  • New Zealand North (newzealandnorth)
  • Central India (centralindia) - Primary
  • West India (westindia)
  • Indonesia Central (indonesiacentral)
  • Malaysia West (malaysiawest)

Middle East (3 regions)

  • UAE North (uaenorth)
  • Qatar Central (qatarcentral)
  • Israel Central (israelcentral)

Americas (Non-US) (5 regions)

  • Canada Central (canadacentral) - Primary
  • Canada East (canadaeast)
  • Brazil South (brazilsouth)
  • Chile Central (chilecentral)
  • Mexico Central (mexicocentral)

Africa (1 region)

  • South Africa North (southafricanorth)

Total: 14 + 13 + 3 + 5 + 1 = 36 regions ✅

🎯 Latency-Aware Architecture

The 36 regions are organized into four low-latency rings:

Ring 1: Europe (14 regions)

  • Very tight RTT between NL, IE, DE, FR, UK, etc.
  • Primary regions: West Europe, North Europe, France Central, Germany West Central, UK South, Switzerland North
  • Suitable for fast consensus rounds

Ring 2: Asia Pacific (13 regions)

  • Japan–Korea–SE Asia–India–Australia cluster
  • Primary regions: East Asia, Southeast Asia, Japan East, Australia East, Central India
  • Optimized for APAC region performance

Ring 3: Middle East + Africa (4 regions)

  • UAE, Qatar, Israel, South Africa
  • Provides regional coverage and backup validators

Ring 4: Americas Non-US (5 regions)

  • Canada, Brazil, Chile, Mexico
  • Primary region: Canada Central
  • Western hemisphere coverage

Consensus Strategy

  • 60-70% of producing validators in Europe + Asia rings (lower latency)
  • 30-40% geo-distributed backup validators across all rings
  • Block times: 2-4s (QBFT/IBFT2) with geo-aware committee selection

📋 Node Distribution Blueprint

Design Rules

  • Each node = 2 vCPUs
  • Each region must stay ≤ 10 vCPUs
  • Even, supportable patterns across all regions

Allocation Strategy

Every region: 2 System Nodes

  • 2 × 2 vCPUs = 4 vCPUs per region

Validators:

  • 12 "primary" regions: 2 Validators each (4 vCPUs)
  • Remaining 24 regions: 1 Validator each (2 vCPUs)

Per-Region Totals

Primary 12 regions:

  • 2 System + 2 Validators = 4 VMs, 8 vCPUs ✅

Other 24 regions:

  • 2 System + 1 Validator = 3 VMs, 6 vCPUs ✅

📊 Primary Regions (2 Validators Each - 8 vCPUs)

Region Geography System Nodes Validator Nodes Total VMs Total vCPUs
West Europe Europe 2 2 4 8
North Europe Europe 2 2 4 8
France Central Europe 2 2 4 8
Germany West Central Europe 2 2 4 8
UK South Europe 2 2 4 8
Switzerland North Europe 2 2 4 8
East Asia APAC 2 2 4 8
Southeast Asia APAC 2 2 4 8
Japan East APAC 2 2 4 8
Australia East APAC 2 2 4 8
Central India APAC 2 2 4 8
Canada Central Americas 2 2 4 8

Subtotal (Primary 12):

  • System Nodes: 12 × 2 = 24
  • Validator Nodes: 12 × 2 = 24
  • Total VMs: 12 × 4 = 48
  • Total vCPUs: 48 × 2 = 96

📊 Remaining Regions (1 Validator Each - 6 vCPUs)

All of these get: 2 System, 1 Validator → 3 VMs, 6 vCPUs.

Region Geography System Nodes Validator Nodes Total VMs Total vCPUs
UK West Europe 2 1 3 6
Sweden Central Europe 2 1 3 6
Norway East Europe 2 1 3 6
Poland Central Europe 2 1 3 6
Spain Central Europe 2 1 3 6
Italy North Europe 2 1 3 6
Austria East Europe 2 1 3 6
Belgium Central Europe 2 1 3 6
Japan West APAC 2 1 3 6
Korea Central APAC 2 1 3 6
Korea South APAC 2 1 3 6
Australia Southeast APAC 2 1 3 6
New Zealand North APAC 2 1 3 6
West India APAC 2 1 3 6
Indonesia Central APAC 2 1 3 6
Malaysia West APAC 2 1 3 6
UAE North Middle East 2 1 3 6
Qatar Central Middle East 2 1 3 6
Israel Central Middle East 2 1 3 6
Canada East Americas 2 1 3 6
Brazil South Americas 2 1 3 6
Chile Central Americas 2 1 3 6
Mexico Central Americas 2 1 3 6
South Africa North Africa 2 1 3 6

Subtotal (Remaining 24):

  • System Nodes: 24 × 2 = 48
  • Validator Nodes: 24 × 1 = 24
  • Total VMs: 24 × 3 = 72
  • Total vCPUs: 72 × 2 = 144

🔚 Global Totals (36 Regions)

  • System Nodes: 24 + 48 = 72 ✅
  • Validator Nodes: 24 + 24 = 48 ✅
  • Total VMs: 48 + 72 = 120 ✅
  • Total vCPUs: 96 + 144 = 240 ✅
  • All regions ≤ 8 vCPUs (< 10 quota limit) ✅

⚙️ West Europe Admin-Only Variant

If West Europe should be purely for admin/control plane (no workload nodes):

Re-allocation Strategy

  1. Set West Europe to 0/0 (no System/Validator nodes)
  2. Re-assign its nodes:
    • +1 System +1 Validator → North Europe (8 → 10 vCPUs)
    • +1 System +1 Validator → Belgium Central (6 → 10 vCPUs)

Updated Totals (Admin Variant)

Region System Nodes Validator Nodes Total vCPUs
West Europe 0 0 0 (admin only)
North Europe 3 3 12 ❌ (exceeds quota)
Belgium Central 3 2 10 ✅

Note: North Europe would exceed 10 vCPU limit. Alternative allocation needed.

Better Re-allocation:

  • +1 System +1 Validator → Belgium Central (6 → 10 vCPUs)
  • +1 System +1 Validator → Netherlands (if available) or split:
    • +1 System → Sweden Central (6 → 8 vCPUs)
    • +1 Validator → Poland Central (6 → 8 vCPUs)

🎯 Next Steps

  1. Map Kubernetes clusters & pod densities onto this 36-region layout
  2. Define QBFT/IBFT2 geo-aware committee configuration:
    • Primary regions (60-70% producing validators)
    • Secondary regions (30-40% backup validators)
    • Latency-optimized consensus rounds
  3. Create Terraform configuration for all 36 regions
  4. Generate deployment scripts with region-specific configurations
  5. Implement geo-aware validator selection logic

📝 References

Reference in New Issue View Git Blame Copy Permalink