d-bis/proxmox
4
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
Files
d6aebf3c43eefbc07d88be451f064228787571e7
proxmox/dbis_chain_138_technical_master_plan.md
defiQUG d6aebf3c43
All checks were successful
Deploy to Phoenix / deploy (push) Successful in 6s
Details
Reclassify DBIS placeholder Hyperledger CTs
2026-03-28 23:21:51 -07:00

15 KiB
Raw Blame History

DBIS Chain 138 Technical Master Plan

Purpose

This document is the governance and execution baseline for DBIS Chain 138 infrastructure. It is intentionally grounded in repo-backed and operator-verified reality, so it can be used for audits, deployment planning, and readiness decisions without confusing currently deployed, under validation, and future-state work.

The objective is to move from architecture theory to a production-grade sovereign deployment program that is evidence-based, phased, and operationally auditable.

SECTION 1 — MASTER OBJECTIVES

Primary objectives

  1. Inventory currently installed stack components and host placement.
  2. Validate actual service readiness, not just declared architecture.
  3. Standardize Proxmox VE deployment topology and preferred workload placement.
  4. Assign infrastructure ownership across ecosystem entities once governance is finalized.
  5. Define production-grade deployment and verification workflows.
  6. Track the gap between today’s footprint and sovereign target-state architecture.
  7. Produce auditable artifacts that operators can regenerate and maintain.

SECTION 2 — CURRENT STACK STATUS

Deployed now

  • Hyperledger Besu (QBFT, Chain 138)
  • Hyperledger Fabric containers and VMIDs are allocated
  • Hyperledger Indy containers and VMIDs are allocated
  • Hyperledger FireFly primary container footprint exists
  • Blockscout / explorer stack
  • Hyperledger Caliper hook and performance guidance (documentation only)

Partially deployed / under validation

  • Hyperledger FireFly:
    • primary 6200 is restored as a minimal local FireFly API footprint
    • secondary 6201 is present in inventory but currently behaves like a retired / standby shell with no valid deployment payload
  • Hyperledger Fabric:
    • 6000, 6001, 6002 are present in inventory but are now intentionally stopped as reserved placeholders
    • current app-level verification did not show active Fabric peer / orderer workloads or meaningful Fabric payloads inside those CTs
  • Hyperledger Indy:
    • 6400, 6401, 6402 are present in inventory but are now intentionally stopped as reserved placeholders
    • current app-level verification did not show active Indy node listeners or meaningful Indy payloads inside those CTs

Planned / aspirational

  • Hyperledger Aries as a proven deployed service tier
  • Hyperledger AnonCreds as an operationally verified deployed layer
  • Hyperledger Ursa as a required runtime dependency
  • Hyperledger Quilt
  • Hyperledger Avalon
  • Hyperledger Cacti as a proven live interoperability layer
  • Full multi-region sovereignized Proxmox with Ceph-backed storage and segmented production VLANs

SECTION 3 — CURRENT ENVIRONMENT DISCOVERY

Canonical discovery artifacts

The source-of-truth discovery path for current state is:

Discovery scope

Reality mapping must validate:

  1. Proxmox hosts and cluster health
  2. VMID / CT inventory versus template JSON
  3. Besu validators, sentries, and RPC tiers
  4. Explorer and public RPC availability
  5. Hyperledger CT presence and app-level readiness where possible
  6. Storage topology and current backing stores
  7. Network topology and current LAN / VLAN reality
  8. ML110 role reality versus migration plan

Required outputs

Every discovery run should produce:

  • Infrastructure inventory report
  • Service state map
  • Dependency context
  • Critical failure summary

The markdown report is evidence capture; the script exit code is the pass/fail signal.

SECTION 4 — PROXMOX VE DEPLOYMENT DESIGN

Current state

  • Current cluster footprint is smaller than the target sovereign model.
  • Current storage is primarily local ZFS / LVM-based, not Ceph-backed distributed storage.
  • Current workload placement is represented as preferred host in the planning template, not guaranteed live placement.

Target model

  • Multi-node Proxmox VE cluster with stable quorum
  • HA-aware workload placement
  • Dedicated roles for core compute, RPC exposure, identity/workflow DLT, ingress, and future storage tiers

Current interpretation rule

This plan must not describe the target sovereignized Proxmox model as already achieved. All references to HA, Ceph, dedicated storage nodes, or dedicated network nodes are roadmap items unless Phase 1 evidence proves they are already active.

SECTION 5 — NETWORK ARCHITECTURE

Current network reality

  • Primary active management / services LAN is 192.168.11.0/24
  • Public ingress is fronted through NPMplus / edge services
  • RPC exposure is already tiered across core, public, private, named, and thirdweb-facing nodes

Target network layers

  1. Management network
  2. Storage replication network
  3. Blockchain validator / P2P network
  4. Identity / workflow DLT network
  5. Public access / DMZ network
  6. Validator-only restricted paths

Status

  • Public access and RPC role separation exist in practice.
  • Full sovereign segmentation with dedicated VLANs and zero-trust internal routing remains roadmap work.

SECTION 6 — ENTITY ASSIGNMENT MODEL

Governance model

The entity-assignment model remains valid as a target governance structure:

  • DBIS Core Authority
  • Central Banks
  • International Financial Institutions
  • Regional Operators

Current status

  • Entity ownership for many deployed workloads is still TBD in the operational matrix.
  • Until governance assigns final owners, operator documentation must keep those fields explicitly marked as TBD rather than inventing ownership.

The executable placement artifact is:

SECTION 7 — VM AND CONTAINER DESIGN

Current status by workload family

Deployed now

  • Settlement / Besu VM family
  • Explorer / observability family
  • Ingress / proxy family
  • Application and DBIS-support workloads

Partially deployed / under validation

  • Workflow VM / CT family for FireFly
  • Institutional VM / CT family for Fabric
  • Identity VM / CT family for Indy

Planned / aspirational

  • Identity VM template that includes proven Aries + AnonCreds runtime
  • Interoperability VM template for true Hyperledger Cacti usage

Implementation rule

Template language in this plan must map to actual repo artifacts and actual VMIDs, not hypothetical inventory.

SECTION 8 — STORAGE ARCHITECTURE

Current state

  • Current guest storage is backed by local Proxmox storage pools.
  • Ceph-backed distributed storage is not yet an achieved platform baseline.

Target state

  • Ceph or equivalent distributed storage tier
  • Snapshot-aware backup strategy by workload class
  • Archive and audit retention policy

Roadmap artifact

SECTION 9 — SECURITY ARCHITECTURE

Current baseline

  • Chain 138 validator, sentry, and RPC tiering exists as an operational pattern.
  • Public RPC capability validation is now script-backed.
  • Explorer and wallet metadata are now explicitly documented and verifiable.

Target-state controls

  • HSM-backed key management
  • stronger secrets segregation
  • certificate hierarchy and operator MFA
  • formalized tier-to-tier firewall policy

Status

These remain partially implemented and must not be represented as fully complete without separate evidence.

SECTION 10 — GOVERNANCE ARCHITECTURE

Target

  • validator governance across multiple entities
  • admission control
  • key rotation
  • emergency controls

Current state

  • Chain 138 validator topology exists
  • final multi-entity validator governance assignment is still pending

This section remains a target architecture section, not a statement of fully executed governance.

SECTION 11 — FIREFLY WORKFLOW ARCHITECTURE

Current state

  • FireFly primary footprint exists and now exposes a local API again.
  • Current restored 6200 configuration is a minimal local gateway profile for stability and API availability.
  • Full multiparty FireFly workflow behavior across blockchain, shared storage, and data exchange is not yet evidenced as healthy in the current container deployment.

Program objective

Use FireFly as the workflow layer only after:

  1. primary and secondary footprint are clearly defined
  2. connector/plugin model is explicit
  3. upstream blockchain and shared-storage dependencies are validated

SECTION 12 — CROSS-CHAIN INTEROPERABILITY DESIGN

Current state

  • CCIP relay and Chain 138 cross-chain infrastructure exist in the broader stack.
  • Hyperledger Cacti is not currently proven as the live interoperability engine for DBIS in this environment.

Planning rule

This plan must refer to Cacti as future / optional until a deployed and validated Cacti environment is evidenced in discovery artifacts.

SECTION 13 — DEVSECOPS PIPELINE

Required execution model

  1. Source control
  2. Build / validation
  3. Security and config review
  4. Service verification
  5. Deployment
  6. Monitoring and readiness evidence

Repo-backed implementation

  • discovery scripts
  • RPC health checks
  • route / explorer verification
  • operator runbooks
  • submodule hygiene and deployment docs

The pipeline is partially implemented via scripts and runbooks; it is not yet a single unified CI/CD system for every DBIS workload.

SECTION 14 — PERFORMANCE VALIDATION

Current state

  • Hyperledger Caliper is not vendored in this repo.
  • A documented performance hook exists instead of a committed benchmark harness.

Canonical artifact

Interpretation rule

Performance benchmarking is planned and documented, but not yet a routine automated readiness gate.

SECTION 15 — MONITORING AND OBSERVABILITY

Deployed now

  • Explorer / Blockscout
  • Besu RPC health verification
  • operational checks and route verification scripts

Partially deployed / under validation

  • Hyperledger-side service health beyond CT status
  • unified status reporting for the broader DLT stack

SECTION 16 — DISASTER RECOVERY DESIGN

Target state

  • RPO / RTO by workload tier
  • cross-site replication
  • cold / standby recovery paths

Current state

DR remains a program requirement, not a fully evidenced completed deployment capability.

SECTION 17 — PRODUCTION DEPLOYMENT WORKFLOW

Phase 1 — Reality mapping

Canonical implementation:

Phase 2 — Sovereignization roadmap

Canonical implementation:

Phase 3 — Liveness and production-simulation wrapper

Canonical implementation:

SECTION 18 — END-TO-END PRODUCTION FLOW

Reference flow

  1. Identity issued
  2. Credential verified
  3. Workflow triggered
  4. Settlement executed
  5. Cross-chain sync
  6. Compliance recorded
  7. Final settlement confirmed

Current interpretation

This is the target business flow. Current automation verifies only selected infrastructure slices of that flow:

  • Besu liveness
  • optional FireFly HTTP
  • operator-guided manual follow-ups for Indy / Fabric / CCIP

It must not be represented as fully automated end-to-end execution today.

SECTION 19 — EXECUTION DIRECTIVES

Cursor / operators should execute the following in order:

  1. Run Phase 1 discovery and review the critical failure summary.
  2. Reconcile node-role matrix conflicts, especially duplicate IP planning entries.
  3. Validate live Hyperledger CTs at the app layer, not only CT status.
  4. Track sovereignization gaps in the Phase 2 roadmap.
  5. Run the Phase 3 liveness wrapper and manual follow-ups.
  6. Produce or refresh readiness evidence.

These directives must map to repo scripts and docs, not hypothetical tooling.

SECTION 20 — EXPECTED DELIVERABLES

The executable deliverables in this repository are:

  1. Infrastructure inventory report
  2. Node role assignment map
  3. Phase 2 sovereignization roadmap
  4. Phase 3 liveness simulation runbook
  5. Caliper performance hook
  6. Operator readiness checklist

Separate security compliance and benchmark reports remain future deliverables unless explicitly generated.

SECTION 21 — CURRENT GAPS

Infrastructure gaps

  • FireFly secondary 6201 is currently stopped and should be treated as retired / standby until intentionally rebuilt.
  • Fabric CTs are present in inventory, but current app-level verification did not prove active Fabric peer or orderer services and did not show meaningful Fabric payloads; they are now intentionally stopped as reserved placeholders.
  • Indy CTs are present in inventory, but current app-level verification did not prove active Indy validator listeners and did not show meaningful Indy payloads; they are now intentionally stopped as reserved placeholders.
  • The current per-node app-level evidence table is maintained in docs/03-deployment/DBIS_HYPERLEDGER_RUNTIME_STATUS.md.

Platform gaps

  • Ceph-backed distributed storage is still roadmap work.
  • Full VLAN / sovereign network segmentation is still roadmap work.
  • Final entity ownership assignments remain incomplete.

Planning gaps

  • Future-state architecture items must remain clearly labeled as planned, not deployed.

SECTION 22 — IMPLEMENTATION ARTIFACTS

Executable counterparts in this repository:

Deliverable Location
Node Role Matrix docs/02-architecture/DBIS_NODE_ROLE_MATRIX.md
Phase 1 discovery scripts/verify/run-phase1-discovery.sh, docs/03-deployment/PHASE1_DISCOVERY_RUNBOOK.md, reports/phase1-discovery/
Phase 2 roadmap docs/02-architecture/DBIS_PHASE2_PROXMOX_SOVEREIGNIZATION_ROADMAP.md
Phase 3 liveness wrapper scripts/verify/run-dbis-phase3-e2e-simulation.sh, docs/03-deployment/DBIS_PHASE3_E2E_PRODUCTION_SIMULATION_RUNBOOK.md
Production gate docs/03-deployment/DBIS_PHASES_1_TO_3_PRODUCTION_GATE.md
Caliper hook docs/03-deployment/CALIPER_CHAIN138_PERF_HOOK.md, scripts/verify/print-caliper-chain138-stub.sh
Operator readiness checklist docs/00-meta/OPERATOR_READY_CHECKLIST.md section 10
Reference in New Issue View Git Blame Copy Permalink