In today’s increasingly complex networking environments, trust is not a static property; it must be continuously measured, verified, and shared across administrative domains. This is precisely the challenge that the CASTOR project tackles: how do you ensure that the routing decisions shaping your network traffic are made based on trustworthy, tamper-proof evidence? A key pillar of our answer lies in the CASTOR Distributed Ledger Technology (DLT) infrastructure and its Secure Oracle Layer.
Why a Blockchain?
Trust-aware routing decisions in CASTOR rely on a continuous flow of evidence: raw traces from routers, trustworthiness claims produced by Trust Assessment Frameworks, Security Service Level Agreement (SSLA) compliance outcomes, and trust policies governing each network element. This data must remain tamper-resistant, traceable, and verifiable over time, especially when shared across domains managed by different network operators. A blockchain provides exactly this: immutability and provenance guarantee that no single party can alter anything.
However, immutability alone is not enough. A ledger can ensure that data has not been changed after it was stored, but it cannot verify whether the data was truthful or valid at the time of submission. This is a fundamental challenge in any trust-sensitive system: how do you reliably consume trust evidence without blindly assuming its validity?
Enter the Secure Oracle
This is where the concept of a Secure Oracle becomes essential. In CASTOR, the Secure Oracle acts as a trusted mediation layer; a controlled “rendezvous” point where evidence is validated before being anchored on the DLT or consumed by other CASTOR components. It ensures data integrity, confidentiality of sensitive information during processing, and cryptographic attestation that the oracle logic was executed correctly within a trusted hardware environment.
After evaluating several Secure Oracle technologies, CASTOR adopted a PHALA-compatible design as its conceptual foundation. PHALA’s architecture is built around general-purpose trusted execution rather than fixed data delivery semantics, making it well suited for an environment like CASTOR where trust policies, telemetry sources, and verification mechanisms evolve dynamically. Rather than depending on a specific PHALA deployment, which is currently in architectural transition, CASTOR implements its own PHALA-like blockchain ecosystem that preserves the core properties of the model while remaining independent of specific underlying hardware assumptions.
Three Enclaves, Three Roles
At the heart of the CASTOR Secure Oracle Layer are three Trusted Execution Environment (TEE)-backed enclave workers, each with a distinct responsibility:
- The Oracle Worker operates in an event-driven manner. It listens for on-chain trigger events and, upon notification, fetches trustworthiness claims produced by Local Trust Assessment Framework (TAF) agents running on routing elements. It validates, processes, and commits these local trust assessments to the DLT acting as the primary gateway for initializing trust-related entries on-chain.
- The Computation Worker is invocation-driven, called upon by the Security Context Broker rather than on-chain events. It handles richer operations such as storing global trust evaluations from the Global TAF, anchoring SSLA compliance outcomes, and updating Trust Policies. Its decoupling from the Oracle Worker enables flexible, client-driven workflows that complement the event-based flows.
- The Data Exposure / Query Worker is an optional but forward-looking component. Its role is to manage sensitive read operations, applying privacy-preserving transformations to trust data before returning it to consumers ensuring that only the level of detail appropriate for each requester is revealed.
Trust Across Domains
A particularly innovative aspect of the CASTOR blockchain infrastructure is its Trust Exposure Layer. This layer enables the controlled sharing of trust insights between administrative domains without exposing sensitive internal network configurations. Rather than sharing raw trust evidence, the system applies query-time transformation functions that abstract the data to the minimum level required by the requesting entity from high-level trust classifications down to detailed trust vectors, depending on authorization.
This approach embodies CASTOR’s “beyond zero trust” philosophy: not only is every entity required to continuously prove its trustworthiness, but the evidence underpinning those proofs is itself managed, shared, and audited in a transparent, privacy-respecting, and cryptographically verifiable manner.
