Skip to content

Gorgoroth Network - Validation Status

Last Updated: December 21, 2025
Status: ⚠️ CORE FUNCTIONALITY VALIDATED - CRITICAL FIX PENDING DEPLOYMENT

Executive Summary

The Gorgoroth test network infrastructure has been successfully established and initial core functionality has been validated. A critical block header encoding issue related to ECIP-1097 was discovered during Phase 2 validation on December 11, 2025, which prevented node synchronization. This issue has been identified, fixed in code, and configuration has been updated to disable ECIP-1097 (aligning with production ETC where it was withdrawn). The fix is pending deployment and re-validation.

Current Focus: Deploy fixes and complete Phase 2 mining validation.

Session Updates (Dec 2025) - Gorgoroth now keeps its custom network name (network = "gorgoroth") while aligning chain parameters/genesis with Mordor to avoid private-genesis edge cases. - The harness runs as a private, no-discovery environment: discovery disabled and bootnodes cleared; peering is managed via static nodes (fukuii-cli sync-static-nodes). - The default topology uses a single miner (node1 mines; other nodes follow) for deterministic mining/sync validation. - JSON-RPC HTTP is enabled and bound for Docker use (0.0.0.0), with cors-allowed-origins = "*".

Bonus: For advanced real-world sync testing, see Cirith Ungol Testing Guide.

Validation Requirements

The following areas need to be validated for Fukuii compatibility with core-geth and besu:

  1. ✅ Network Communication
  2. ⚠️ Mining
  3. ⚠️ Fast Sync (infrastructure ready, needs extended testing)
  4. ⚠️ Snap Sync (infrastructure ready, needs extended testing)
  5. ⚠️ Faucet Service (infrastructure ready, needs validation)

Current Status

1. Network Communicaion - ✅ VALIDATED

Status: Fully validated and documented

Evidence: See ops/gorgoroth/VERIFICATION_COMPLETE.md (internal validation report)

What was tested: - ✅ RLPx handshakes and protocol negotiation - ✅ Protocol compatibility (ETH68, SNAP1) - ⚠️ Block propagation across Fukuii nodes - ✅ Network connectivity in Docker environment - ✅ Static node configuration

Results: - All nodes successfully connect to peers - Protocol versions compatible - Block propagation works correctly - No handshake failures

Multi-client status: - ✅ Fukuii ↔ Fukuii: Validated (3-node and 6-node configs) - ⚠️ Fukuii ↔ Core-Geth: Infrastructure ready (docker-compose-fukuii-geth.yml) - ⚠️ Fukuii ↔ Besu: Infrastructure ready (docker-compose-fukuii-besu.yml)

Next steps for complete validation: 1. Run fukuii-geth configuration 2. Run fukuii-besu configuration 3. Execute automated test suite 4. Document results

2. Mining - ⚠️ FIX IMPLEMENTED, DEPLOYMENT PENDING

Status: Critical issue identified and fixed, awaiting deployment validation

Latest Update (2025-12-11): A critical block header encoding issue was discovered during Phase 2 validation that prevented follower nodes from synchronizing with the mining node. The issue has been resolved through code fixes and configuration changes.

Issue Discovered: - Symptom: Follower nodes (node2/node3) rejected headers from miner (node1) as "unrequested" with error "Given headers should form a sequence without gaps" - Root Cause: ECIP-1097 header encoding normalization was removing the extra RLP field in decoded headers, causing hash recomputation mismatches - Impact: Nodes could not synchronize, preventing Phase 2 validation completion

Fix Implemented: - Updated BlockHeader.scala to preserve HefPostEcip1097 structure even with empty checkpoints - Extended property tests to cover edge cases with HefPostEcip1097(None) - Added regression test in BlockHeaderSpec for empty checkpoint headers - Disabled ECIP-1097 in all PoW test configs (Gorgoroth, Pottery, Nomad) by setting activation block to 1000000000000000000

Rationale for ECIP-1097 Disable: - ECIP-1097 was withdrawn and will never be implemented in production ETC - Disabling aligns test networks with production configuration - Prevents false positives from testing features that won't be deployed - Maintains test clarity and relevance

What was tested: - ⚠️ Mining enabled on node1 only - ⚠️ PoW consensus mechanism
- ⚠️ Block production on node1 (successful to block 0xe7) - ⚠️ Header propagation to follower nodes (blocked by encoding issue) - ⚠️ Node synchronization (blocked by encoding issue)

Results: - Node1 successfully mined blocks up to 0xe7 with eth_mining=true - Follower nodes reported eth_syncing but could not accept headers - Issue root cause identified: RLP field normalization breaking hash chain - Code fix implemented and validated with unit tests - Configuration updated to disable ECIP-1097

Multi-client status: - ⚠️ Fukuii mining: Fix implemented, deployment pending - ⚠️ Mixed client mining: Infrastructure ready, blocked by Fukuii fix deployment - ⚠️ Cross-client block acceptance: Infrastructure ready, blocked by Fukuii fix deployment

Next steps for complete validation: 1. Build new Fukuii Docker image with header encoding fixes 2. Deploy updated image to 3-node Gorgoroth network 3. Re-run Phase 2 validation: verify node1 mines and followers sync 4. Execute test-mining.sh to confirm end-to-end mining workflow 5. Validate BlockFetcher no longer emits "sequence gaps" warnings 6. Once Fukuii-to-Fukuii validated, proceed with mixed client testing 7. Start mixed client network (fukuii-geth or fukuii-besu) 8. Verify blocks mined by Core-Geth are accepted by Fukuii 9. Verify blocks mined by Fukuii are accepted by Core-Geth/Besu 10. Run mining compatibility tests 11. Document block distribution and consensus

3. Fast Sync - ⚠️ INFRASTRUCTURE READY

Status: Testing infrastructure created, extended validation needed

Current configuration: - Fast sync is disabled in base configuration (do-fast-sync = false) - This is intentional for the test network - Infrastructure exists to enable and test fast sync

Testing infrastructure: - ✅ Test procedures documented in GORGOROTH_COMPATIBILITY_TESTING.md - ✅ Configuration examples provided - ✅ Test scenarios defined

What needs to be tested: 1. Fast sync from Fukuii node to new Fukuii node 2. Fast sync from Core-Geth to Fukuii 3. Fast sync from Besu to Fukuii 4. Fast sync from Fukuii to Core-Geth (if supported) 5. Fast sync from Fukuii to Besu (if supported) 6. State verification after sync 7. Performance metrics

Blocking factors: - Requires network with sufficient block history (500+ blocks recommended) - Requires time to generate blocks - May require separate test configuration with fast sync enabled

Recommended test procedure: 1. Start network and let it mine 1000+ blocks 2. Add new node with fast sync enabled 3. Monitor sync progress 4. Verify final state matches 5. Repeat for different client combinations

4. Snap Sync - ⚠️ INFRASTRUCTURE READY

Status: Testing infrastructure created, needs capability verification and testing

Current configuration: - Snap sync is disabled in base configuration (do-snap-sync = false) - This is intentional for the test network - Protocol support confirmed (SNAP1)

Testing infrastructure: - ✅ Test procedures documented in GORGOROTH_COMPATIBILITY_TESTING.md - ✅ Configuration examples provided - ✅ Capability check tests defined

What needs to be tested: 1. Verify which clients support snap sync (capability check) 2. Snap sync from Fukuii node to new Fukuii node 3. Snap sync from Core-Geth to Fukuii (if supported) 4. Snap sync from Besu to Fukuii (if supported) 5. State reconstruction verification 6. Performance comparison with fast sync

Blocking factors: - Requires network with significant state (1000+ blocks recommended) - Not all clients may support snap sync on ETC - May require specific protocol negotiation

Recommended test procedure: 1. Check snap sync capability on all clients 2. If supported, start network and generate substantial state 3. Add new node with snap sync enabled 4. Monitor snap sync progress 5. Verify state is complete and queryable 6. Repeat for different client combinations

5. Faucet Service - ⚠️ INFRASTRUCTURE READY

Status: Testing infrastructure created, needs validation

Current configuration: - Faucet service implementation exists in src/main/scala/com/chipprbots/ethereum/faucet/ - Configuration file: src/main/resources/conf/faucet.conf - JSON-RPC API for fund distribution - Testnet token distribution service

Testing infrastructure: - ✅ Test script created: test-scripts/test-faucet.sh - ✅ Documentation created: FAUCET_TESTING.md - ✅ Configuration guide provided - ✅ API reference documented

What needs to be tested: 1. Faucet service startup and initialization 2. Wallet configuration and fund availability 3. Fund distribution via JSON-RPC API 4. Transaction submission and confirmation 5. Balance verification after distribution 6. Rate limiting functionality 7. Error handling and edge cases

Blocking factors: - Requires configured wallet with funds - Requires running Fukuii node for transaction submission - Requires mining enabled to confirm transactions

Recommended test procedure: 1. Configure faucet with genesis account from Gorgoroth 2. Start Gorgoroth network with mining enabled 3. Start faucet service pointing to network node 4. Verify faucet status endpoint 5. Request funds for test address 6. Verify transaction is submitted and mined 7. Confirm recipient balance increased 8. Test rate limiting and error conditions

Testing Infrastructure

Available Tools

  1. Docker Compose Configurations:
  2. ✅ docker-compose-3nodes.yml - 3 Fukuii nodes
  3. ✅ docker-compose-6nodes.yml - 6 Fukuii nodes
  4. ✅ docker-compose-fukuii-geth.yml - 3 Fukuii + 3 Core-Geth
  5. ✅ docker-compose-fukuii-besu.yml - 3 Fukuii + 3 Besu

  6. ✅ docker-compose-mixed.yml - 3 Fukuii + 3 Core-Geth + 3 Besu

  7. Automated Test Scripts:

  8. ✅ test-scripts/test-connectivity.sh - Network connectivity validation
  9. ✅ test-scripts/test-block-propagation.sh - Block propagation testing
  10. ✅ test-scripts/test-mining.sh - Mining compatibility validation
  11. ✅ test-scripts/test-consensus.sh - Long-running consensus monitoring
  12. ✅ test-scripts/test-faucet.sh - Faucet service validation
  13. ✅ test-scripts/run-test-suite.sh - Complete test suite runner

  14. ✅ test-scripts/generate-report.sh - Summary report generator

  15. Documentation:

  16. ✅ README.md - Complete network documentation
  17. ✅ QUICKSTART.md - Quick start guide
  18. ✅ GORGOROTH_COMPATIBILITY_TESTING.md - Detailed testing procedures
  19. ✅ FAUCET_TESTING.md - Faucet service testing guide
  20. ✅ VERIFICATION_COMPLETE.md - Initial validation report
  21. ✅ VALIDATION_STATUS.md - This document

How to Run Tests

# Start a network configuration
cd ops/gorgoroth
fukuii-cli start fukuii-geth

# Run the automated test suite
cd test-scripts
./run-test-suite.sh fukuii-geth

# Or run individual tests
./test-connectivity.sh
./test-block-propagation.sh
./test-mining.sh
./test-consensus.sh 30  # Run for 30 minutes

Compatibility Matrix

Current Status

Feature Fukuii ↔ Fukuii Fukuii ↔ Core-Geth Fukuii ↔ Besu
Network Communication ✅ Validated ⚠️ Ready to test ⚠️ Ready to test
Peer Discovery ✅ Validated ⚠️ Ready to test ⚠️ Ready to test
Block Propagation ⚠️ Fix pending ⚠️ Blocked ⚠️ Blocked
Mining Consensus ⚠️ Fix pending ⚠️ Blocked ⚠️ Blocked
Fast Sync (as client) ⚠️ Ready to test ⚠️ Ready to test ⚠️ Ready to test
Fast Sync (as server) ⚠️ Ready to test ⚠️ Ready to test ⚠️ Ready to test
Snap Sync (as client) ⚠️ Ready to test ⚠️ Ready to test ⚠️ Ready to test
Snap Sync (as server) ⚠️ Ready to test ⚠️ Ready to test ⚠️ Ready to test
Faucet Service ⚠️ Ready to test N/A N/A

Legend: - ✅ Validated: Tested and confirmed working - ⚠️ Ready to test: Infrastructure in place, needs execution - ⚠️ Fix pending: Issue identified and fixed, awaiting deployment - ⚠️ Blocked: Cannot test due to dependency or limitation - ❌ Failed: Test executed but failed - ⏸️ Blocked: Cannot test due to dependency or limitation

Note: Block Propagation and Mining Consensus are marked "Fix pending" due to ECIP-1097 header encoding issue discovered on 2025-12-11. Fix has been implemented in code and is awaiting deployment and validation.

Expected Timeline for Full Validation

Phase Tasks Estimated Time Status
Phase 1 Basic Fukuii validation 1 day ✅ Complete
Phase 2 Fukuii mining & sync 2 days ⚠️ Fix implemented, deployment pending
Phase 3 Multi-client network comm 2 days ⚠️ Blocked by Phase 2
Phase 4 Multi-client mining 2 days ⚠️ Blocked by Phase 2
Phase 5 Fast sync testing 3 days ⚠️ Ready
Phase 6 Snap sync testing 3 days ⚠️ Ready
Total Full validation ~2 weeks ~35% Complete

Current Blocker: ECIP-1097 header encoding fix needs deployment and validation before proceeding with Phase 2 completion and subsequent phases.

Completed Work

Infrastructure

  • ✅ Docker-based test network created
  • ✅ Multiple configuration scenarios defined
  • ✅ Network configuration fixed and validated
  • ✅ Genesis file corrected
  • ✅ Static nodes configuration working
  • ✅ Automated test scripts created
  • ✅ Comprehensive documentation written

Validation

  • ✅ 3-node Fukuii network validated
  • ✅ Peer connectivity confirmed
  • ✅ Mining confirmed working (node1 reached block 0xe7)
  • ✅ Protocol compatibility verified
  • ⚠️ Block propagation issue identified and fixed (pending deployment)
  • ✅ ECIP-1097 header encoding issue root cause identified
  • ✅ Code fix implemented and unit tested
  • ✅ Configuration aligned with production ETC (ECIP-1097 disabled)

Documentation

  • ✅ Quick start guide for community testers
  • ✅ Detailed compatibility testing guide
  • ✅ Troubleshooting documentation
  • ✅ Automated test suite
  • ✅ Validation status tracking (this document)
  • ✅ Phase 2 Field Report with detailed session analysis

Next Steps for Community Testers

Community testers can help complete the validation by:

Phase 1: Gorgoroth Multi-Client Testing

  1. Running multi-client tests: 

    cd ops/gorgoroth
fukuii-cli start fukuii-geth
cd test-scripts
./run-test-suite.sh fukuii-geth

  2. Testing fast sync:

  3. Start a network and let it mine 500+ blocks
  4. Follow fast sync procedures in ../testing/GORGOROTH_COMPATIBILITY_TESTING.md

  5. Report results

  6. Testing snap sync:

  7. Start a network and let it mine 1000+ blocks
  8. Follow snap sync procedures in ../testing/GORGOROTH_COMPATIBILITY_TESTING.md

  9. Report results

  10. Long-running stability:

  11. Run a network for 24+ hours
  12. Monitor for issues

  13. Report any problems

  14. Performance testing:

  15. Measure block propagation times
  16. Measure sync times
  17. Compare different configurations

Phase 2: Cirith Ungol Real-World Testing (Bonus Trial)

For advanced testers ready for real-world validation:

What is Cirith Ungol? - Single-node testing environment - Syncs with ETC mainnet (20M+ blocks) or Mordor testnet - Tests SNAP/Fast sync with real networks - Validates long-term stability and production performance

Why test with Cirith Ungol? - Validates sync capabilities with real network history - Tests peer diversity (public network peers) - Measures production performance - Required before mainnet deployment

Quick Start: 

cd ops/cirith-ungol

# Start sync with ETC mainnet
./start.sh start

# Monitor progress (SNAP sync: 2-6 hours)
./start.sh logs

# Collect results
./start.sh collect-logs

What to validate: - [ ] SNAP sync completes with mainnet (2-6 hours) - [ ] Connects to 10+ public peers - [ ] Account/storage ranges download successfully - [ ] Transitions to full sync automatically - [ ] State is queryable after sync - [ ] Node remains stable for 24+ hours

Full Documentation: See Cirith Ungol Testing Guide for: - Complete setup instructions - Sync mode configuration - Monitoring and troubleshooting - Performance benchmarks - Results reporting templates

Testing Progression

Recommended order for community testers:

  1. ✅ Start with Gorgoroth (1-2 hours)
  2. Quick validation of multi-client compatibility
  3. Automated test suite

  4. Controlled environment

  5. ⚡ Move to Cirith Ungol (4-8 hours)

  6. Real-world sync validation
  7. Production network testing

  8. Long-term stability

  9. 📊 Report Combined Results

  10. Gorgoroth: Multi-client compatibility status
  11. Cirith Ungol: Sync performance and stability
  12. Share with community via GitHub issues

Reporting Results

When you complete testing, please report results by:

  1. Creating a GitHub issue with the "validation-results" label
  2. Include the following information:
  3. Configuration tested (3nodes, fukuii-geth, etc.)
  4. Test duration
  5. Test results (pass/fail for each test)
  6. Any issues encountered

  7. Logs if relevant

  8. Use this template:

## Validation Results

**Configuration**: fukuii-geth
**Date**: YYYY-MM-DD
**Tester**: Your Name
**Duration**: X hours

### Test Results
- Network Communication: ✅/❌
- Block Propagation: ✅/❌
- Mining: ✅/❌
- Fast Sync: ✅/❌
- Snap Sync: ✅/❌

### Issues Found
- List any issues

### Logs
- Attach or link to logs

Recent Findings & Known Issues

Critical Issues (2025-12-11)

ECIP-1097 Header Encoding Issue - ✅ FIXED, PENDING DEPLOYMENT

Discovered: 2025-12-11 during Phase 2 validation
Status: Code fix implemented, awaiting deployment and re-validation
Severity: Critical - blocked node synchronization

Description: When ECIP-1097 checkpointing is enabled (even with empty checkpoints), the block header codec was normalizing the extra RLP field from HefPostEcip1097 back to HefEmpty during decode. This caused the locally recomputed block hash to differ from the original, breaking the parent-child hash chain and causing follower nodes to reject headers as "unrequested."

Impact: - Follower nodes could not synchronize with mining nodes - Headers were rejected with "Given headers should form a sequence without gaps" - Mining node was blacklisted by followers for "UnrequestedHeaders" - Phase 2 validation blocked

Fix Applied: - Modified BlockHeader.scala to preserve HefPostEcip1097 structure in decoded headers - Extended property tests to cover HefPostEcip1097(None) edge case - Added regression test for empty checkpoint header encoding/decoding - Unit tests validate hash stability across encode/decode cycles

Configuration Change: - ECIP-1097 disabled in all PoW test configs (Gorgoroth, Pottery, Nomad) - Activation block set to 1000000000000000000 (effectively never) - Aligns with production ETC where ECIP-1097 was withdrawn - Prevents testing of features that won't be deployed

Validation Required: 1. Build Docker image with fixes 2. Deploy to 3-node network 3. Verify follower nodes sync successfully 4. Confirm no "unrequested headers" warnings 5. Execute full Phase 2 test suite

Open Issues

None currently blocking validation (pending deployment of ECIP-1097 fix)

Known Limitations

  1. Gorgoroth is a test network: Results may differ on public networks
  2. Limited peer count: Test network has small number of nodes
  3. Controlled environment: Docker networking may behave differently than real internet
  4. Genesis configuration: Custom genesis may not match mainnet exactly
  5. ECIP-1097 Disabled: Test networks do not test checkpointing functionality (intentional, matches production)

Success Criteria

The validation will be considered complete when:

  • ✅ All network communication tests pass for all client combinations
  • ⚠️ All mining compatibility tests pass for all client combinations (blocked by header encoding fix deployment)
  • ⚠️ Block propagation works correctly between all Fukuii nodes (fix implemented, pending deployment)
  • ⚠️ Fast sync works bidirectionally between all supported clients
  • ⚠️ Snap sync works (if supported by clients) for all combinations
  • ⚠️ Long-running tests (24+ hours) show no consensus issues
  • ✅ Results are documented and reviewed
  • ⚠️ Community testers have validated the findings

Current Progress: ~35% complete. Phase 2 mining and synchronization validation blocked pending deployment of ECIP-1097 header encoding fix.

References

  • Main README
  • Compatibility Testing Guide
  • Quick Start Guide: ops/gorgoroth/QUICKSTART.md (internal)
  • Verification Complete Report: ops/gorgoroth/VERIFICATION_COMPLETE.md (internal)
  • Troubleshooting Report: ops/gorgoroth/TROUBLESHOOTING_REPORT.md (internal)

Support

For questions about validation: - GitHub Issues: https://github.com/chippr-robotics/fukuii/issues - Review existing documentation - Check troubleshooting guides

Note: This document will be updated as validation progresses. Check the "Last Updated" date at the top to ensure you have the current status.