VWDC-10 — Byzantine-Resilient World Federation, Trust Domains, and Fault Containment
拜占庭韌性世界聯邦、信任域與故障遏制:能力分層、影響切割、部分隔離、衝突證書與安全重返
Bridge Series: Visual–World Domain Computation (VWDC) — Paper 10
Depends on: VWDC-01–09, GVSS-01–10, WDC-01–08, WDC Runtime Whitepaper, frozen RRT-20
Author: Neo.K / EveMissLab
Version: v0.1
Date: 2026-08-18
Status: Formal fault/adversary-governance paper. Capability-revocation monotonicity, trust-vector non-collapse, direct-commit containment under non-bypass enforcement, capability-cut influence containment, historical-contamination persistence, dependency blast-radius characterization, static-quorum availability loss under quarantine, conflicting-quorum assumption witness, quorum semantic-validity no-go, reentry-gate monotonicity, model-accuracy-only reentry no-go, stale-attestation no-go, probation containment, append-only trust-state lineage, and trust-governance Pareto necessity are proved under explicit hypotheses. Byzantine fault tolerance, robust federated learning, zero-trust authorization, attestation, capability security, graph cuts, and adaptive isolation are established neighboring theory/engineering and are not claimed as VWDC inventions. No strong novelty claim is made.
Keywords: Byzantine resilience, federated digital twin, world federation, zero trust, capability security, fault containment, quarantine, trust domains, reentry, attestation, BFT, WDC
Abstract
VWDC-09 established a federated shared-reality layer:
It separated local reasoning from globally coherent shared-reality mutation and introduced runtime trust states:
ACTIVE
LIMITED
PROBATION
QUARANTINED
REVOKED
VWDC-10 asks what happens when one or more federation participants are:
- faulty;
- compromised;
- malicious;
- Byzantine;
- semantically corrupted;
- credential compromised;
- evidence poisoned;
- model poisoned;
- partially unavailable.
The core principle is that trust is capability-relative.
A runtime can remain useful for one function while being untrustworthy for another.
Therefore VWDC rejects one scalar statement:
runtime is trusted.
Instead it uses a capability vector:
and a trust state:
A runtime can have:
- valid observation access;
- corrupted evidence generation;
- useful model-learning output;
- revoked certificate authority;
- no commit authority.
This makes partial quarantine possible.
The second core object is a capability/dependency influence graph:
Nodes include:
- runtime capability endpoints;
- evidence artifacts;
- learned models;
- certificates;
- proposals;
- reservation services;
- commit validators;
- physical commit sinks.
A directed edge:
means output/control from can influence under the declared federation semantics.
Let:
be compromised source nodes and:
be protected sinks such as:
- mandatory safety certificate;
- global commit authority;
- actuator command;
- shared ledger mutation.
A quarantine/revocation set:
is sufficient for future influence containment if every directed path:
intersects .
Equivalently, is an – vertex cut in the explicit influence graph.
Then in:
no new influence path from the compromised source reaches the protected sink.
This produces the canonical containment theorem:
But the theorem is deliberately forward-looking.
A quarantine enacted at time does not erase:
- poisoned training data already consumed;
- certificates already issued;
- models already trained;
- decisions already made;
- physical commits already executed.
Therefore:
Historical descendants require:
- invalidation;
- replay;
- revalidation;
- compensation;
- or explicit retention with degraded trust status.
1. Byzantine runtime model
Definition VWDC10-D1
A runtime is Byzantine over capability set:
when its behavior on those capabilities may deviate arbitrarily from the declared protocol, including:
- omission;
- equivocation;
- fabrication;
- stale replay;
- selective disclosure;
- adversarial optimization;
- credential misuse.
The model does not imply every capability of the runtime is compromised.
2. Capability layer
Canonical capabilities:
OBSERVE
EVIDENCE
LEARN
PROPOSE
CERTIFY
RESERVE
COMMIT
AUDIT
ADMIN
The first seven form the principal operational chain.
3. Capability effect set
For capability set:
define:
as the set of direct operations/effects the runtime is authorized to initiate under the federation enforcement model.
4. VWDC10-T1 — Capability-revocation monotonicity
Theorem VWDC10-T1
If:
and authorization is capability monotone, then:
Proof
Every action authorized under uses capabilities already contained in .
Removing capabilities cannot create a new direct authorized action under the monotone authorization model.
5. Interpretation
Partial quarantine can reduce the runtime's direct attack surface without deleting all useful functions.
Example:
READ_STATE = true
OBSERVE = true
SIMULATE = true
PROPOSE = false
CERTIFY = false
COMMIT = false
6. Zero-trust authorization boundary
Current 2026 agentic-security work explicitly studies runtime interception and task-based authorization for multi-turn agents so that protected resource/tool access is checked at invocation time rather than inherited indefinitely from agent identity.
Other work uses authenticated workflow boundaries with cryptographic integrity and policy enforcement around prompts, tools, data, and context.
VWDC uses the same broad principle:
7. Trust vector
Definition VWDC10-D2
Runtime trust is:
Each coordinate can carry:
TRUSTED
LIMITED
UNKNOWN
COMPROMISED
REVOKED
or calibrated confidence/attestation metadata.
8. VWDC10-N1 — One scalar trust score cannot preserve capability semantics
Counterexample
Let two runtimes have binary trust coordinates:
Both have scalar average:
But:
- A has compromised/revoked commit authority;
- B has compromised first capability but trusted commit authority.
The governance response should differ.
Therefore:
9. Trust dominance
A runtime can dominate another on one trust dimension and be worse on another.
Trust-state comparison is naturally multiobjective.
10. Direct commit containment
Suppose compromised runtime has:
Its proposals must pass an independent commit authority.
Assume:
- no bypass path exists;
- the commit authority does not treat 's own certificate as sufficient authorization;
- mandatory hard invariants are independently rechecked from trusted/current sources;
- physical actuator accepts only commit-authority commands.
11. VWDC10-T2 — No-direct-commit containment under non-bypass enforcement
Theorem VWDC10-T2
Under the assumptions above, runtime cannot directly cause a reality mutation solely through possession of its remaining local capabilities.
Proof
Every reality mutation requires a commit-authority command.
Runtime has no direct COMMIT capability and no bypass path.
Its remaining outputs can only reach reality if the independent commit authority accepts them.
Thus direct mutation by runtime authority alone is excluded.
12. Boundary
The theorem does not say the runtime is harmless.
It can still:
- poison evidence;
- manipulate a trusted model;
- deceive validators;
- trigger a software vulnerability;
- exploit an unmodeled side channel.
It separates direct authority from indirect influence.
13. VWDC10-N2 — Byzantine-resistant learning does not imply Byzantine-safe physical commit
Counterexample
A federation uses a robust aggregation algorithm that perfectly rejects poisoned gradients.
Its shared learned model is correct.
A separate commit credential is compromised and submits an unsafe actuator command.
Therefore:
The reverse non-implication also holds: secure commit does not guarantee unpoisoned learning.
14. Current Byzantine federated-learning precedent
Current work studies Byzantine-resilient federated optimization and federated multi-agent control with:
- robust aggregation;
- detection-quality weighting;
- adaptive isolation;
- protection against model manipulation.
VWDC imports those techniques only at the LEARN/EVIDENCE layers.
They do not replace shared-reality commit controls.
15. Influence graph
Definition VWDC10-D3
is a directed graph of explicit influence.
Possible nodes:
- runtime capabilities;
- datasets;
- evidence packets;
- models;
- evaluators;
- proposals;
- certificates;
- resource reservations;
- commit authority;
- actuator sinks.
Edge:
means a valid/accepted output of can influence under the declared system.
16. Compromised source set
17. Protected sink set
Examples:
- safety approval;
- authority grant;
- global ledger;
- physical commit;
- reality-facing control output.
18. Quarantine set
Quarantine removes or disables the corresponding influence vertices/roles for future operations.
19. VWDC10-T3 — Capability-cut future influence containment
Theorem VWDC10-T3
Assume all influence relevant to protected sinks is represented by directed paths in:
If every directed path from:
to:
contains at least one vertex in:
then in:
no protected sink is reachable from any compromised source.
Proof
Assume a compromised source could still reach a protected sink in the graph with removed.
That reachable path would be an – path containing no vertex.
Contradiction.
20. Containment interpretation
A partial quarantine is sufficient when it cuts every protected influence route.
It need not disable unrelated observation/simulation functions.
21. Minimum containment set
Finding the smallest set of internal capability vertices whose removal disconnects compromised source and protected sink is the classical minimum vertex-cut problem under the graph model.
VWDC does not claim graph cuts as new.
22. Side-channel boundary
If a compromised runtime has an influence route not represented in:
the theorem's guarantee fails.
Examples:
- shared memory not modeled;
- prompt/context injection through an untracked channel;
- compromised administrator;
- physical side channel.
Provenance completeness is part of fault containment.
23. Reachability blast radius
Definition VWDC10-D4
For source set :
For protected nodes only:
24. VWDC10-T4 — Dependency blast-radius characterization
Theorem VWDC10-T4
Under the explicit influence/dependency graph semantics, the set of nodes that can receive graph-mediated influence from source set is exactly:
Proof
This is the definition of directed reachability.
The operational value is that quarantine scope should be based on reachability/dependency topology, not runtime count.
25. High-centrality runtime
One runtime can have a very large blast radius if it supplies:
- common evaluator;
- common schema;
- common certificate service;
- shared model;
- authorization root.
26. VWDC10-N3 — Runtime-local compromise can have federation-wide blast radius
A runtime can be one node while:
contains nearly all federation services.
Therefore:
27. Future versus historical contamination
Let quarantine occur at:
Suppose malicious evidence was produced before and used to train model:
Removing the malicious evidence source after prevents new updates from that source.
It does not revert:
28. VWDC10-N4 — Future quarantine does not decontaminate historical descendants
Counterexample
At time 1:
At time 2:
is quarantined.
remains the same contaminated model unless:
- retrained;
- rolled back;
- repaired;
- invalidated.
Therefore:
29. Invalidation after quarantine
After identifying compromised source:
- cut future influence;
- compute historical dependency descendants;
- classify descendants:
- still valid;
- stale;
- invalid;
- replay required;
- replay from clean checkpoint when possible;
- reissue certificates;
- compensate physical effects if required.
30. Quarantine layers
Suggested:
OBSERVATION_QUARANTINE
EVIDENCE_QUARANTINE
LEARNING_QUARANTINE
PROPOSAL_QUARANTINE
CERTIFICATE_QUARANTINE
RESERVATION_QUARANTINE
COMMIT_QUARANTINE
NETWORK_QUARANTINE
FULL_REVOKE
Use the narrowest containment layer proven sufficient.
31. Quarantine monotonicity
Revoking more capabilities cannot increase the runtime's direct authorized action set by VWDC10-T1.
But it can decrease availability.
32. Validator set
Suppose static commit validator set:
required signature quorum:
After quarantine/failure, responsive authorized validators:
33. VWDC10-T5 — Static quorum availability threshold
Theorem VWDC10-T5
A -signature commit certificate cannot be formed if:
If at least responsive authorized validators are willing to sign the same valid value, a -signature certificate can be formed at the counting layer.
Proof
The first direction is cardinality.
The second follows by collecting signatures.
Network synchrony/protocol liveness are outside this counting result.
34. Safety–availability tradeoff
Aggressive quarantine can protect safety while removing enough validators/services to prevent progress.
Therefore:
35. VWDC10-N5 — Safety-preserving quarantine can destroy federation liveness
Counterexample
A federation requires:
signatures.
Three validators are currently responsive.
Quarantine one honest validator after an ambiguous alert.
Only two remain responsive.
No commit quorum can form.
The quarantine can be conservative/safety-motivated while halting progress.
36. Reconfiguration
A federation can create a new validator epoch/set after quarantine.
Reconfiguration itself must be authorized by a prior valid governance rule or a separately protected emergency authority.
Do not silently change:
- ;
- ;
- quorum threshold;
- validator identities.
37. Previous VWDC-09 quorum assumptions
For:
and quorum:
with at most Byzantine validators and honest non-equivocation, two conflicting quorum certificates for the same epoch/key cannot both exist.
38. Conflicting certificate incident
Suppose the federation observes two certificates:
for conflicting:
under the same:
- validator universe;
- epoch;
- transaction key;
- quorum rule.
Both contain:
signatures.
39. VWDC10-T6 — Conflicting-quorum assumption witness
Theorem VWDC10-T6
Under the common-universe/common-epoch interpretation above, observing two conflicting certificates implies at least one of the following stated assumptions is false:
- at most signers are Byzantine/compromised;
- honest signing keys never equivocate;
- certificate epoch/key semantics are identical and correctly verified.
Proof
If all assumptions held, VWDC-09's quorum-intersection theorem would make two conflicting certificates impossible.
The observation therefore witnesses violation of at least one assumption.
40. Operational response
A conflicting certificate is not merely another opinion.
It is a security incident requiring:
- commit halt;
- signer/epoch/key audit;
- quarantine;
- key rotation;
- ledger consistency review.
41. Quorum truth boundary
Suppose every honest validator follows the same flawed policy:
approve action if simulator score .
The simulator has a shared systematic reality error.
All validators honestly approve one harmful action.
42. VWDC10-N6 — Byzantine-safe quorum does not imply semantic/reality correctness
Counterexample
All validators are honest.
All receive the same flawed world-model output.
All sign the same semantically wrong but protocol-valid commit.
No Byzantine fault occurs.
Therefore:
Quorum protects agreement/integrity under its fault model.
RTC/safety validation protects semantic deployment validity.
43. Evidence quorum versus commit quorum
A federation can have:
- cryptographically independent signers;
- epistemically dependent evidence.
Track both.
44. Current ByzTwin precedent
Current ByzTwin-Range research integrates production-grade BFT with a digital-twin cyber-range to inject Byzantine faults and test synchrony/timing/configuration vulnerabilities under realistic operational conditions.
This directly supports continuous BFT/twin stress-testing as an engineering practice.
VWDC's trust-capability model is a governance layer above such protocol testing.
45. Attestation
A runtime can provide an integrity attestation:
Attestation can support identity/runtime integrity.
It does not prove model semantics or future honesty.
46. VWDC10-N7 — Historical attestation does not prove current integrity
Counterexample
Runtime is honestly attested at:
It is compromised at:
The old attestation remains a true statement about:
but not current state.
Therefore:
Use freshness/epoch/nonce and re-attestation policy.
47. Current attestation precedent
Current zero-trust federated-learning work combines cryptographic/TPM-style attestation with Byzantine-detection/robust-aggregation layers.
VWDC uses attestation only as one reentry/trust coordinate.
48. Reentry
A runtime moving from:
QUARANTINED
toward:
PROBATION
ACTIVE
must pass a reentry contract.
49. Reentry gate set
Suggested mandatory gates:
where:
- : identity/runtime integrity re-attestation;
- : compromised key rotation/revocation;
- : root-cause remediation;
- : historical dependency invalidation/replay;
- : fresh RTC/safety/certificate validation;
- : probation/shadow observation;
- : authority restoration approval.
50. Reentry eligible set
51. VWDC10-T7 — Reentry-gate monotonicity
Theorem VWDC10-T7
Adding a mandatory reentry gate cannot enlarge the set of runtimes eligible for full reentry.
Proof
The eligible set is an intersection.
Adding another set to an intersection cannot enlarge it.
52. VWDC10-N8 — Model accuracy alone is insufficient for authority reentry
Counterexample
A runtime has an accurate model after compromise remediation.
But its commit private key remains compromised.
An attacker can still issue apparently authorized commits.
Therefore:
53. Certificate integrity reentry
Likewise:
- good prediction;
- good benchmark score;
do not prove that:
- issued certificates were unforgeable;
- past certificates are clean;
- trust root is restored.
54. Probation state
During:
PROBATION
runtime can be allowed:
- observe;
- simulate;
- shadow-evaluate;
- submit nonbinding proposals.
It can remain denied:
- certify;
- reserve shared exclusive resource;
- commit.
55. VWDC10-T8 — Probation direct-effect containment
Theorem VWDC10-T8
Under a non-bypass capability enforcement model, if probation runtime has no:
capabilities, it cannot directly issue a commit certificate, reserve exclusive shared resource, or mutate shared reality through those protected interfaces.
Proof
These direct effects require capabilities absent from its authorized capability set.
Apply VWDC10-T1 and interface enforcement.
Indirect influence through proposals/evidence remains possible and must be validated.
56. Shadow reentry evaluation
Probation can compare:
- predictions versus current reality;
- proposals versus champion decisions;
- evidence quality;
- protocol compliance.
No direct actuation is required.
57. Reentry evidence
Reentry packet:
runtime_id
incident_id
root_cause
remediation
old_keys_revoked
new_keys
fresh_attestation
affected_descendants
replay_status
rtc_refresh
safety_refresh
probation_results
authority_approval
58. Reentry cannot erase incident history
Trust restoration creates a new trust epoch:
It does not rewrite:
59. Trust epoch lineage
Each trust transition creates a new state node:
ACTIVE_v0
→ QUARANTINED_v1
→ PROBATION_v2
→ ACTIVE_v3
60. VWDC10-T9 — Append-only trust-state lineage acyclicity
Theorem VWDC10-T9
If every trust transition creates a new node with strictly larger creation index and all lineage edges point forward, trust-state history is acyclic even when semantic labels repeat, such as:
Proof
Strictly increasing creation index forbids directed cycles.
61. Trust-state recurrence is not history recurrence
Returning to label:
ACTIVE
does not mean the runtime has returned to its old identity state.
It is a new trust epoch.
62. Trust decay
A runtime can move:
ACTIVE
→ LIMITED
without full quarantine.
Possible triggers:
- stale attestation;
- elevated anomaly score;
- expired certificate;
- incomplete dependency audit.
63. Partial quarantine decision
Choose quarantine set:
to:
- cut all unacceptable source-to-protected-sink paths;
- minimize service disruption/cost;
- preserve audit/observation where useful.
This is a constrained cut/optimization problem.
64. Quarantine cost
Each capability/node:
has cost:
A minimum-cost containment problem is:
subject to:
This is a classical weighted cut formulation.
65. VWDC10-T10 — Stronger quarantine cannot create a new graph-mediated attack path
Theorem VWDC10-T10
If:
then:
Proof
contains no vertices/edges that are absent from due to the additional removals.
Every path available under stronger quarantine was already available under weaker quarantine.
Availability can move in the opposite direction.
66. Trust recovery versus liveness
Restoring a runtime too early increases integrity risk.
Keeping it quarantined too long can increase:
- quorum failure;
- latency;
- model diversity loss;
- coverage loss.
Trust governance is a safety/availability/evidence tradeoff.
67. Learning-layer quarantine
If LEARN capability is quarantined but COMMIT remains independently protected, federation can:
- freeze model updates;
- continue validated current-policy execution.
This is often preferable to unnecessary full shutdown.
68. Certificate-layer quarantine
If CERTIFY is compromised:
- certificates issued in affected epoch become suspect;
- proposal generation can continue as nonbinding;
- independent validators may still operate.
69. Commit-layer quarantine
If COMMIT authority/key is compromised:
- shared physical mutation should fail closed;
- rotate/fence credentials;
- re-establish authority epoch;
- audit physical side effects.
Model accuracy is irrelevant to this immediate response.
70. Evidence-layer quarantine
If EVIDENCE is compromised:
- new evidence is excluded;
- historical descendants are audited;
- independent sources remain usable if provenance paths are separate.
71. Observation-layer quarantine
Compromised sensors/observation streams can poison:
- evidence;
- model;
- RTC;
- decisions.
Do not treat downstream consensus as independent confirmation if all consume the same bad observation source.
72. Multi-layer adversary
A sophisticated adversary can compromise several capabilities across different runtimes.
Source set:
should include all compromised capability nodes, not only runtime identities.
73. Identity-based quarantine insufficiency
One compromised credential may affect only one service key.
Conversely one organization account may control several runtimes.
Fault model should attach to capabilities/keys/dependencies, not only human-readable runtime names.
74. VWDC10-N9 — Runtime identity is not the minimal fault domain
Counterexample
One runtime has separate:
- evidence key;
- proposal key;
- commit key.
Only evidence key is compromised.
Full-runtime quarantine removes safe commit/proposal functions unnecessarily.
Therefore:
75. Key/capability graph
A practical federation should map:
Runtime
-> identities
-> keys
-> capabilities
-> services
-> certificates
-> protected sinks
This gives a finer containment graph.
76. Trust update
Do not update one scalar reputation only.
Update trust vector coordinates based on evidence type.
Example:
- failed attestation lowers identity/integrity trust;
- false evidence lowers evidence trust;
- equivocation lowers certificate/commit trust;
- bad prediction lowers model/predictive trust.
77. VWDC10-N10 — Evidence of one failure dimension does not identify every trust dimension
A wrong prediction can be caused by model misspecification while:
- key integrity;
- authorization;
- commit protocol;
remain correct.
A forged signature can occur while the predictive model remains accurate.
Therefore:
78. Trust vector update packet
runtime_id
trust_epoch
dimension
old_status
new_status
evidence
confidence
expiry
authority
79. Fault evidence threshold
Quarantine can be triggered by:
- cryptographic proof;
- conflicting signature;
- validated incident;
- statistical anomaly;
- external report.
Response strength should depend on evidence strength and consequence.
80. Cryptographic proof versus statistical anomaly
A proven key equivocation can justify immediate certificate/commit revocation.
A weak prediction anomaly may justify LIMITED/PROBATION rather than full revoke.
81. Conflicting evidence
Runtimes can disagree honestly due to model uncertainty.
Disagreement is not automatically Byzantine behavior.
Need fault diagnosis.
82. Byzantine accusation no-go
A participant that differs from majority can be correct.
Majority agreement can share one common-mode error.
Thus:
83. Evidence challenge
Before quarantine from semantic disagreement, possible actions:
- independent evaluator;
- replay;
- alternative backend;
- external measurement;
- cryptographic/provenance audit.
84. ByzTwin cyber-range use
A digital-twin cyber-range can deliberately inject:
- delay;
- equivocation;
- node crash;
- Byzantine messages;
- timeout misconfiguration;
to test federation response before production exposure.
85. Fault injection versus live authority
Testing runtime should not automatically hold production COMMIT capability.
Simulation/cyber-range roles remain separated from production authority.
86. Availability reserve
Maintain spare validators/services:
so quarantine does not immediately drop:
Reserve activation itself requires attestation/reconfiguration.
87. Diversity reserve
Reserves should consider common-mode dependencies:
- cloud;
- codebase;
- key authority;
- network;
- model;
- sensor.
Raw reserve count is not resilience.
88. Static quorum safety versus dynamic membership
A safe validator-set reconfiguration needs:
- epoch boundary;
- old/new set definition;
- authorization;
- replay/ledger position;
- anti-equivocation/fencing.
VWDC-10 does not design a full reconfiguration protocol.
89. Certificate epoch
Every certificate includes:
federation_epoch
validator_set_hash
transaction_key
proposal_hash
state_version
rtc_hashes
safety_hashes
90. Stale validator certificate
A valid old-epoch signature cannot authorize a new-epoch commit unless policy explicitly permits translation.
91. VWDC10-N11 — Cryptographic validity does not imply current authorization
A signature can be cryptographically valid under an expired/revoked key or old epoch.
Therefore:
92. Current authorization check
Validate:
- key;
- epoch;
- capability;
- runtime status;
- certificate scope;
- revocation status.
93. Revocation propagation
When key/capability is revoked:
- new operations fail;
- pending transactions recheck;
- historical operations remain in ledger;
- affected descendants may require audit.
94. Pending transaction invalidation
A transaction PREPARED before revocation must revalidate authority at COMMIT.
This inherits VWDC-09 commit-time revalidation.
95. Physical fencing
If actuator can receive commands from multiple authority epochs, use a monotonically increasing fencing token/epoch so stale authority commands are rejected.
This is established distributed-systems engineering.
96. Compromised actuator boundary
If the actuator itself ignores fencing/authorization, software federation guarantees cannot enforce physical authority.
The physical trust root matters.
97. Reentry levels
Suggested:
R0 REVOKED
R1 FORENSIC_ONLY
R2 READ_ONLY
R3 SHADOW_PROPOSAL
R4 LIMITED_PROPOSAL
R5 CERTIFY_PROBATION
R6 FULL_ACTIVE
Movement need not jump directly from quarantine to full authority.
98. Capability restoration ordering
A conservative ordering:
Not universal, but useful for staged reentry.
99. Reentry rollback
If probation anomaly appears:
or:
Trust-state history remains append-only.
100. Reentry promotion test
A runtime can require:
- protocol conformance;
- fresh attestation;
- independent benchmark;
- protected regression;
- evidence consistency;
- shadow commit comparison.
101. Reentry external validity
For world/model-related capabilities, refresh relevant RTCs after remediation.
Old predictive validity may not survive code/model changes.
102. Key-only remediation
If only key compromise occurred and code/model semantics are unchanged, model retraining may be unnecessary.
But certificate/authority epochs still need repair.
This illustrates capability-relative recovery.
103. Model-only remediation
If model is poisoned but commit keys are intact, rotate/retrain the model/evidence path without necessarily rotating physical authority keys.
Again: different trust dimension.
104. Byzantine evidence isolation
Malicious evidence should be tagged/revoked by provenance source.
Do not delete independent evidence from other sources merely because one runtime was compromised.
105. Shared-source caveat
If many evidence artifacts depend on one compromised sensor/model, all their descendants can be affected even across runtime boundaries.
Use dependency closure.
106. Fault-containment domain
Definition VWDC10-D5
For compromised capability set and quarantine :
Protected nodes inside this set have no remaining explicit future influence path from .
107. Containment quality vector
108. Trust-governance objective
Candidate response can be evaluated on:
109. VWDC10-T11 — Trust-governance Pareto necessity
Theorem VWDC10-T11
Every optimum of a scalar trust-governance objective strictly monotone in declared risks/costs lies on the nondominated feasible containment/recovery frontier.
Proof
Standard dominance argument.
110. No universal quarantine strength
One incident can justify:
- evidence-only quarantine;
another:
- full commit revocation.
Response is capability/fault/evidence dependent.
111. Incident classes
Suggested:
PREDICTION_FAULT
EVIDENCE_FABRICATION
MODEL_POISONING
PROPOSAL_EQUIVOCATION
CERTIFICATE_EQUIVOCATION
KEY_COMPROMISE
COMMIT_BYPASS
PROTOCOL_VIOLATION
AVAILABILITY_FAILURE
UNKNOWN
112. Fault policy matrix
Map incident class to candidate actions:
PREDICTION_FAULT
-> LIMIT_LEARN / REVALIDATE
EVIDENCE_FABRICATION
-> EVIDENCE_QUARANTINE / DESCENDANT_AUDIT
CERTIFICATE_EQUIVOCATION
-> CERTIFY_REVOKE / KEY_ROTATE / EPOCH_HALT
COMMIT_BYPASS
-> COMMIT_REVOKE / PHYSICAL_FENCE / FULL_INCIDENT
UNKNOWN
-> LIMITED / FREEZE_HIGH_RISK / DIAGNOSE
113. Fault diagnosis
Byzantine behavior can mimic:
- network delay;
- software bug;
- model drift;
- sensor corruption.
Do not overclaim adversarial intent from behavior alone.
Containment can be justified by risk without proving intent.
114. Trust status versus blame
QUARANTINED
means:
current authority is restricted because risk/certainty policy requires it.
It need not mean:
malicious intent has been proven.
115. Forensic preservation
Quarantine should preserve:
- logs;
- model hashes;
- memory/state snapshots where permitted;
- signed messages;
- certificate history;
- deployment provenance.
This supports root-cause analysis.
116. Privacy/security boundary
Forensic collection must still obey:
- privacy;
- sovereignty;
- retention;
- access-control policies.
VWDC-10 does not override them.
117. Federated sovereign autonomy
Current federated digital-twin architectures emphasize retaining local governance/autonomy while exposing controlled federation capabilities.
VWDC's capability-layer trust model fits this boundary:
federation participation does not require giving every participant every authority.
118. Cross-organization trust
Different organizations can have separate trust roots.
A federation certificate may require cross-domain policy/identity translation.
VWDC-10 does not define global PKI.
119. Trust anchor compromise
If the root authority issuing runtime identities/keys is compromised, blast radius can include every descendant identity.
This is a high-centrality trust node.
120. Root rotation
Root compromise can require federation epoch reset/rekey/re-attestation.
Historical signed records remain verifiable only under preserved incident-aware trust history.
121. Revoked signature history
A signature made before a key's compromise/revocation is not automatically forged.
Its evidential status depends on estimated compromise onset and provenance.
122. Time-bounded compromise
If forensic evidence establishes compromise interval:
operations outside it can have different trust status.
Avoid blanket historical deletion where provenance supports finer classification.
123. Unknown compromise onset
If onset is unknown, use conservative audit window.
This can enlarge blast radius.
124. Attestation and model semantics
Hardware/software attestation can prove loaded code/configuration identity.
It does not prove:
- training data correctness;
- model semantic correctness;
- reality transport validity.
Separate layers remain necessary.
125. VWDC10-N12 — Runtime integrity attestation does not imply semantic model validity
A perfectly attested runtime can faithfully execute a systematically wrong model.
Therefore:
126. Secure workflow provenance
Cryptographically authenticated workflows can strengthen integrity of:
- task;
- tool invocation;
- data/context boundaries;
- workflow dependency.
They do not replace empirical RTC validation.
127. BFT cyber-range validation
Federation should periodically test:
- delayed messages;
- conflicting proposals;
- equivocation;
- dropped validators;
- key revocation;
- stale epochs;
- quorum loss;
- dependency isolation;
- actuator fencing.
128. Fault-injection environment
Such tests should run in:
- WDC branches;
- digital-twin cyber ranges;
- staging/sandbox;
- controlled hardware-in-loop;
before production where feasible.
129. Trust fault benchmark
Construct federation with:
- 7 validators;
- assumed Byzantine bound;
- quorum 5;
- several capability layers.
Inject:
- model poison only;
- evidence fabrication;
- commit-key compromise;
- validator equivocation;
- dependency-root compromise.
Verify different containment actions.
130. Benchmark A — capability monotonicity
Revoke capabilities and verify direct authorized effect set never grows.
131. Benchmark B — scalar trust collision
Create runtimes with identical scalar trust but different commit/evidence status.
Verify policy differs.
132. Benchmark C — influence cut
Create multiple compromised-source paths to COMMIT.
Remove a cut set.
Verify protected sink unreachable.
133. Benchmark D — incomplete cut
Leave one uncut path.
Verify attack influence remains reachable.
134. Benchmark E — past contamination
Train a model on bad evidence.
Quarantine source.
Verify model remains contaminated until replay/retrain.
135. Benchmark F — quorum/liveness
Reduce responsive validators below quorum.
Verify commit liveness lost.
136. Benchmark G — conflicting quorum witness
Construct quorum sizes under and check intersection:
Attempt conflicting honest-non-equivocating certificates.
Verify impossibility.
137. Benchmark H — quorum semantic no-go
All validators sign one wrong shared-model output.
Verify agreement without reality truth.
138. Benchmark I — reentry gates
Recover model accuracy but leave old compromised key active.
Verify full reentry rejected.
139. Benchmark J — stale attestation
Attest at epoch 1.
Compromise at epoch 2.
Verify epoch-1 attestation is insufficient.
140. Benchmark K — probation containment
Allow read/propose, deny certify/commit.
Verify no direct commit operation available.
141. Benchmark L — blast radius
Compromise a high-centrality certificate root.
Compute descendant closure.
142. Benchmark M — trust-state DAG
Run:
ACTIVE
→ LIMITED
→ QUARANTINED
→ PROBATION
→ ACTIVE
Verify labels repeat but version lineage remains acyclic.
143. Benchmark N — stronger quarantine
Compare reachable protected sinks under:
Verify stronger quarantine cannot add an attack path.
144. Current literature boundary — Byzantine fault tolerance
Byzantine agreement, PBFT/BFT protocols, quorum intersection, and fault thresholds are established distributed-systems theory.
VWDC does not claim them as new.
145. Current literature boundary — Byzantine federated learning
Robust aggregation, Byzantine-resilient distributed/federated optimization, and fault-tolerant federated RL are established active fields.
VWDC does not claim Byzantine-resistant learning as new.
146. Current literature boundary — zero trust
Continuous/task-based authorization, cryptographic authentication, attestation, least privilege, and zero-trust runtime enforcement are established/current security directions.
VWDC integrates them as capability gates.
147. Current literature boundary — graph cuts
Reachability, vertex cuts, and minimum cut are classical graph theory.
VWDC uses them to state an explicit capability/fault containment semantics.
148. Candidate VWDC-specific synthesis
Subject to broader literature audit, candidate bridge-specific synthesis is:
- a capability-relative Byzantine model separating observation, evidence, learning, proposal, certificate, reservation, and commit compromise;
- vector trust state rather than a single runtime reputation scalar;
- an explicit influence graph linking capability nodes to protected reality sinks;
- graph-cut semantics for proving partial quarantine sufficient for future influence containment;
- strict separation between future containment and historical descendant decontamination;
- quarantine/liveness accounting at the federation quorum layer;
- conflicting commit certificates treated as witnesses that a stated trust/epoch/key assumption failed;
- reentry as a multi-gate contract spanning attestation, key rotation, remediation, descendant replay, RTC/safety refresh, probation, and authority;
- append-only trust epochs so reactivation never erases incident history;
- trust-response optimization over containment risk, availability, evidence retention, recovery, and reentry cost.
No strong novelty claim is made in v0.1.
149. What VWDC-10 proves
Under explicit hypotheses, VWDC-10 proves:
- capability revocation cannot enlarge a runtime's direct authorized effect set;
- one scalar trust score cannot preserve capability-specific governance distinctions;
- a runtime without COMMIT capability cannot directly mutate reality through protected interfaces when no bypass exists and commit authority independently rechecks mandatory gates;
- Byzantine-resistant learning does not imply Byzantine-safe physical commit;
- a quarantine set intersecting every explicit compromised-source path to protected sinks blocks all future graph-mediated influence to those sinks;
- graph reachability characterizes the explicit dependency blast radius;
- a single runtime compromise can have federation-wide blast radius through high-centrality dependencies;
- future quarantine does not decontaminate already-produced descendants;
- a commit quorum cannot form when fewer responsive authorized validators than the quorum threshold remain;
- safety-motivated quarantine can destroy liveness;
- two conflicting certificates under the stated common-epoch model witness failure of at least one fault/non-equivocation/epoch assumption;
- BFT agreement does not imply semantic/reality correctness;
- historical attestation does not prove current integrity after later compromise;
- adding mandatory reentry gates cannot enlarge full-reentry eligibility;
- recovered model accuracy does not establish recovered authority integrity;
- probation without certificate/reservation/commit capabilities blocks those direct protected effects under non-bypass enforcement;
- append-only trust transitions remain acyclic even when trust labels recur;
- stronger quarantine cannot create a new graph-mediated attack path;
- runtime identity need not be the minimal fault-containment unit;
- one anomaly does not identify every trust dimension;
- cryptographic signature validity does not imply current authorization;
- runtime-integrity attestation does not imply semantic world-model validity;
- every strictly monotone scalar trust-governance optimum lies on the nondominated feasible containment/recovery frontier.
150. What VWDC-10 does not prove
It does not prove:
- every influence channel is represented in the capability graph;
- a graph cut stops physical/administrative side channels;
- robust federated learning solves commit security;
- BFT quorum safety proves semantic validity;
- a static validator set remains live under arbitrary quarantine;
- a universal scalar trust score exists;
- malicious intent can always be distinguished from faults;
- hardware attestation proves model correctness;
- reentry can be automated safely in every domain;
- minimum cut is always the correct quarantine objective;
- past contamination can always be replayed away;
- full availability can always coexist with aggressive containment;
- VWDC security contracts replace professional security engineering.
151. Proposed VWDC-11
The next paper should move from adversarial containment to cross-organization sovereignty and selective federation:
Chinese:
主權世界聯邦、選擇性揭露與隱私保護信任邊界
Main questions:
- What must a runtime reveal to prove a certificate without revealing private world state?
- How should organization/domain sovereignty constrain federation capabilities?
- Can zero-knowledge/selective disclosure support RTC/certificate interoperability?
- How should private evidence influence a shared decision without becoming globally readable?
- What happens when privacy constraints conflict with auditability?
- How should data residency and jurisdiction become capability/commit constraints?
- How should a runtime exit a federation while preserving shared commit history?
- What is the minimum information required for safe shared reality coordination?
152. References
- Ali Peivand, Seyyed Mostafa Nosratabadi, Byzantine-Resilient Federated Multi-Agent Optimization Framework for Cyber-Secure Interconnected Microgrids, arXiv:2606.19080, 2026.
- Tadeu Freitas, João Soares, Rolando Martins, Trust, but Verify: ByzTwin-Range, a Digital Twin Cyber-Range for Byzantine Faults, arXiv:2604.18049, 2026.
- Christian Vergara-Marcillo et al., Integrating Heterogeneous Digital Twins in Federated Ecosystems, arXiv:2606.22791, 2026.
- Majed El Helou et al., Hybrid Inspection and Task-Based Access Control in Zero-Trust Agentic AI, arXiv:2605.02682, 2026.
- Mohan Rajagopalan, Vinay Rao, Authenticated Workflows: A Systems Approach to Protecting Agentic AI, arXiv:2602.10465, 2026.
- Samaresh Kumar Singh, Joyjit Roy, Martin So, Zero-Trust Agentic Federated Learning for Secure IIoT Defense Systems, arXiv:2512.23809, 2025.
- Lifan Zheng et al., Rethinking the Reliability of Multi-agent System: A Perspective from Byzantine Fault Tolerance, arXiv:2511.10400, 2025.
- Flint Xiaofeng Fan et al., Fault-Tolerant Federated Reinforcement Learning with Theoretical Guarantee, arXiv:2110.14074.
- Miguel Castro, Barbara Liskov, Practical Byzantine Fault Tolerance, OSDI, 1999.
- VWDC-01–09, GVSS-01–10, WDC-01–08, WDC Runtime Whitepaper, and frozen RRT-20, internal series artifacts, 2026.
153. Conclusion
VWDC-09 made many runtimes share one coherent reality-commit layer.
VWDC-10 makes that federation survivable when participants are not uniformly trustworthy.
The key move is to stop asking:
Is this runtime trusted?
and instead ask:
Trust becomes a vector.
Authority becomes capability scoped.
Fault containment becomes a graph problem.
A sufficient quarantine is a cut separating compromised capability sources from protected reality sinks.
But:
Byzantine-safe learning does not imply Byzantine-safe commit.
A commit quorum does not imply reality truth.
Old attestation does not imply current integrity.
Model accuracy does not restore compromised authority.
And returning to ACTIVE creates a new trust epoch rather than erasing the incident that caused quarantine.
The canonical VWDC-10 principle is:
This establishes capability-relative Byzantine containment and safe trust recovery for federated WDC systems.
Canonical-source policy
This file is the canonical UTF-8 source artifact.
- Canonical inline mathematics uses
$...$. - Canonical display mathematics uses
$$...$$. - No Unicode mathematical-symbol conversion is used as source normalization.
- No
unicode_escaperound trip is used. - Backslashes and delimiters are preserved literally.
- Validation is required before release.
- This paper does not merge or rename GVSS, WDC, VWDC, or RRT.