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.
This commit is contained in:
defiQUG
192
docs/architecture/NETWORK.md
Normal file
192
docs/architecture/NETWORK.md
Normal file
@@ -0,0 +1,192 @@
|
||||
# Network Configuration
|
||||
|
||||
## Network Topology
|
||||
|
||||
The DeFi Oracle Meta Mainnet uses a tiered architecture with validators, sentries, and RPC nodes.
|
||||
|
||||
### Validators
|
||||
|
||||
- **Count**: 4+ validators
|
||||
- **Location**: Private subnets, no public IPs
|
||||
- **Peering**: Only to sentries (via static-nodes.json)
|
||||
- **Consensus**: IBFT 2.0
|
||||
- **RPC**: Disabled for security
|
||||
|
||||
### Sentries
|
||||
|
||||
- **Count**: 3-5 sentries
|
||||
- **Location**: Public subnets
|
||||
- **Peering**: To validators and other sentries
|
||||
- **P2P Port**: 30303 (TCP/UDP)
|
||||
- **RPC**: Limited, internal only
|
||||
|
||||
### RPC Nodes
|
||||
|
||||
- **Count**: 3-5 RPC nodes
|
||||
- **Location**: DMZ subnet
|
||||
- **P2P**: Disabled
|
||||
- **RPC**: Public HTTPS JSON-RPC
|
||||
- **Sync Mode**: SNAP (or FULL/ARCHIVE)
|
||||
|
||||
## Peering Configuration
|
||||
|
||||
### Static Nodes
|
||||
|
||||
Static nodes are configured in `static-nodes.json`:
|
||||
|
||||
```json
|
||||
[
|
||||
"enode://<validator-1-public-key>@<validator-1-ip>:30303",
|
||||
"enode://<validator-2-public-key>@<validator-2-ip>:30303",
|
||||
"enode://<sentry-1-public-key>@<sentry-1-ip>:30303",
|
||||
"enode://<sentry-2-public-key>@<sentry-2-ip>:30303"
|
||||
]
|
||||
```
|
||||
|
||||
### Bootnodes
|
||||
|
||||
Bootnodes are configured via environment variables or config maps. Validators use sentries as bootnodes.
|
||||
|
||||
## Network Security
|
||||
|
||||
### Network Security Groups (NSGs)
|
||||
|
||||
#### Validators
|
||||
- Allow internal communication (10.0.0.0/16)
|
||||
- Deny all other traffic
|
||||
|
||||
#### Sentries
|
||||
- Allow P2P (30303 TCP/UDP) from any
|
||||
- Allow internal communication (10.0.0.0/16)
|
||||
|
||||
#### RPC Nodes
|
||||
- Allow HTTPS (443) from any
|
||||
- Allow HTTP (80) from any (redirect to HTTPS)
|
||||
- Allow internal communication (10.0.0.0/16)
|
||||
|
||||
## Permissioning
|
||||
|
||||
### Node Permissioning
|
||||
|
||||
Node permissioning is configured via `permissions-nodes.toml`:
|
||||
|
||||
```toml
|
||||
nodes-allowlist=[
|
||||
"enode://<node-public-key>@<node-ip>:30303"
|
||||
]
|
||||
```
|
||||
|
||||
### Account Permissioning
|
||||
|
||||
Account permissioning is configured via `permissions-accounts.toml`:
|
||||
|
||||
```toml
|
||||
accounts-allowlist=[
|
||||
"0x742d35Cc6634C0532925a3b844Bc9e7595f0bEb"
|
||||
]
|
||||
```
|
||||
|
||||
## IBFT 2.0 Configuration
|
||||
|
||||
### Genesis Parameters
|
||||
|
||||
- **ChainID**: 138
|
||||
- **Block Period**: 2 seconds
|
||||
- **Epoch Length**: 30,000 blocks
|
||||
- **Request Timeout**: 10 seconds
|
||||
- **Gas Limit**: ~30,000,000
|
||||
|
||||
### Validator Set
|
||||
|
||||
Validators are specified in the genesis `extraData` field. The validator set can be updated via IBFT transitions.
|
||||
|
||||
### Consensus Parameters
|
||||
|
||||
- **Block Time**: ~2 seconds
|
||||
- **Finality**: Immediate (BFT)
|
||||
- **Validator Count**: 4+ validators
|
||||
- **Fault Tolerance**: (N-1)/3
|
||||
|
||||
## Network Monitoring
|
||||
|
||||
### Peer Count
|
||||
|
||||
Monitor peer count to ensure network connectivity:
|
||||
- Validators should have 2+ peers (sentries)
|
||||
- Sentries should have 5+ peers (validators + sentries)
|
||||
- RPC nodes have 0 peers (P2P disabled)
|
||||
|
||||
### Block Production
|
||||
|
||||
Monitor block production to ensure consensus is working:
|
||||
- Block time should be ~2 seconds
|
||||
- Block lag should be ≤2 blocks
|
||||
- Chain should not stall for >20 seconds
|
||||
|
||||
### Network Topology
|
||||
|
||||
Monitor network topology to ensure proper peering:
|
||||
- Validators should only peer to sentries
|
||||
- Sentries should peer to validators and other sentries
|
||||
- RPC nodes should have no P2P connections
|
||||
|
||||
## Troubleshooting
|
||||
|
||||
### Nodes Not Peering
|
||||
|
||||
1. Check network connectivity
|
||||
2. Verify static-nodes.json configuration
|
||||
3. Check firewall rules (NSGs)
|
||||
4. Verify node keys are correct
|
||||
|
||||
### Block Production Issues
|
||||
|
||||
1. Check validator keys are correct
|
||||
2. Verify genesis file matches across all nodes
|
||||
3. Check consensus parameters
|
||||
4. Review validator logs
|
||||
|
||||
### Network Partition
|
||||
|
||||
1. Identify partitioned nodes
|
||||
2. Check network connectivity
|
||||
3. Verify peering configuration
|
||||
4. Restart nodes if necessary
|
||||
|
||||
## Network Updates
|
||||
|
||||
### Adding Validators
|
||||
|
||||
1. Generate validator key
|
||||
2. Update genesis extraData (requires transition)
|
||||
3. Add validator to static-nodes.json
|
||||
4. Restart validators and sentries
|
||||
|
||||
### Removing Validators
|
||||
|
||||
1. Remove validator from static-nodes.json
|
||||
2. Update genesis extraData (requires transition)
|
||||
3. Restart validators and sentries
|
||||
|
||||
### Updating Consensus Parameters
|
||||
|
||||
1. Create IBFT transition block
|
||||
2. Update block period, epoch length, or request timeout
|
||||
3. All validators must accept the transition
|
||||
|
||||
## Network Maintenance
|
||||
|
||||
### Regular Maintenance
|
||||
|
||||
- Monitor peer count daily
|
||||
- Review block production weekly
|
||||
- Check network topology monthly
|
||||
- Update node software quarterly
|
||||
|
||||
### Emergency Procedures
|
||||
|
||||
- Network partition: Identify and reconnect nodes
|
||||
- Validator failure: Remove failed validator
|
||||
- Chain stall: Restart validators
|
||||
- Security incident: Isolate affected nodes
|
||||
|
||||
Reference in New Issue
Block a user