Toward Blockchain-Assisted Zero-Trust Secure Communication for Decentralized UAV Swarms in GPS-Denied Environments: A Mathematical Security and Scalability Framework

1. Introduction

Swarm autonomy moves decision making away from a single ground station and toward a set of cooperating aerial agents. That architectural shift improves fault tolerance and mission continuity, but it also changes the security problem. A peer that can exchange state, formation commands, safety messages, localization evidence, or mission updates becomes part of the control surface of every other peer. The security question is therefore not only whether a packet is encrypted. A receiving UAV must decide whether the sender is an authorized member of the current swarm, whether the message is fresh, whether it belongs to the current trust epoch, whether its cryptographic evidence is valid, whether the command is compatible with local safety state, and whether a security-relevant change should be made auditable across the distributed system.

Recent UAV-security surveys emphasize that authentication, key management, replay resistance, intrusion resilience, and communication overhead are tightly coupled in resource-constrained aerial networks [1,2,3,4]. Blockchain has consequently been investigated as a decentralized trust substrate for UAV identity and coordination [5,6,7,8,9,10]. However, a direct transfer of conventional blockchain logic to swarm traffic creates a structural mismatch: telemetry and control may be generated at tens or hundreds of messages per second, whereas Byzantine consensus introduces multi-round communication whose cost grows superlinearly with the validator population. Lightweight authentication papers have therefore sought to reduce expensive cryptographic operations, batch verification cost, or on-chain state [7,8]. Recent work on UAV blockchain sharding and credit-based PBFT similarly recognizes that conventional consensus latency and message complexity can become bottlenecks [9,10].

This paper addresses a narrower and operationally important question: how can a UAV swarm obtain decentralized, tamper-evident trust without putting blockchain consensus into the real-time packet path? The central design choice is an event-sparse ledger. Ordinary telemetry, local coordination, and frequent peer-state updates remain protected by direct cryptographic sessions. Only events that change the trust model are anchored to a permissioned ledger. Examples include node admission or revocation, identity-key rotation, trust-epoch changes, firmware measurements, repeated replay or spoof detections, and selected critical command decisions.

The work is grounded in the current security behavior of an existing GPS-denied UAV swarm research platform [11]. At the inspected release baseline, the peer-authentication path uses canonical serialization and HMAC-SHA256, enforces a trust epoch, rejects stale sequence numbers, checks timestamp age, and compares authentication codes in constant time. The onboard security monitor tracks replay, spoof, authorization, control-plane, synchronization, localization, and link-quality signals; the remote-command policy applies freshness, issuer-trust, geofence, health, localization, and security-state checks before accepting commands. Firmware trust logic maintains measurements and rollback state. Importantly, the source also marks Ed25519 and post-quantum modes as placeholders rather than implemented capabilities. This distinction is preserved throughout the paper: the existing software behavior is treated as measured or inspected baseline evidence, while the blockchain and per-node asymmetric identity layer is treated as a proposed research extension.

The study is organized around four research questions.

• RQ1: What minimum set of mathematical predicates should a zero-trust UAV peer satisfy before a message or remote command is accepted?
• RQ2: How can a permissioned blockchain be used as a decentralized trust anchor without coupling every telemetry packet to consensus?
• RQ3: How do validator count, anchoring ratio, consensus-message size, and event rate affect communication and storage complexity?
• RQ4: Which security properties are supported by the current software baseline, which are guaranteed only under standard cryptographic assumptions, and which require future implementation and hardware validation?

The main contributions are as follows.

• A zero-trust swarm acceptance model that combines identity validity, integrity, freshness, monotonic sequence state, trust epoch, issuer trust, and onboard command policy into a single fail-closed decision.
• An event-sparse permissioned ledger in which blockchain records trust-changing evidence instead of carrying flight-critical telemetry.
• A per-node identity and session model using independently scoped identity keys, authenticated ephemeral key establishment, key derivation, and AEAD-protected peer traffic, thereby containing compromise more effectively than a swarm-wide shared secret.
• Mathematical models for trust dynamics, validator eligibility, Byzantine tolerance, PBFT-style message complexity, control bandwidth, ledger event rate, storage growth, energy cost, and a multi-objective anchoring policy.
• A clear evidence boundary that reports current repository security-path measurements without presenting analytical blockchain calculations as measured blockchain performance.

1.1. UAV Swarm Security Requirements

A UAV swarm combines properties of mobile ad hoc networks, cyber-physical control systems, distributed robotics, and edge computing. Security requirements therefore extend beyond confidentiality. A peer command that is confidential but replayed can still be dangerous; a fresh packet from a spoofed node is still unauthorized; an authenticated command that violates the receiving UAV’s geofence or degraded localization state may still be unsafe. Recent surveys classify attack surfaces across communication, navigation, embedded software, control, and physical layers [1,2,3,4]. In swarm networks, the decentralized topology adds peer impersonation, Sybil-style membership attacks, malicious coordination, stale-state amplification, and compromised-node propagation.

For a swarm message $m$, this paper treats the required security properties as a vector

$$\mathcal{S}\left(m\right)=\left[C\left(m\right),I\left(m\right),A\left(m\right),F\left(m\right),R\left(m\right),Z\left(m\right),P\left(m\right)\right],$$

(1)

where $C$ denotes confidentiality, $I$ integrity, $A$ source authentication, $F$ freshness, $R$ replay resistance, $Z$ authorization under the current zero-trust state, and $P$ compatibility with onboard safety policy. The addition of $P$ is essential: a cryptographically valid message is not automatically an admissible flight command.

1.2. Lightweight Authentication and Secure Communication

Han, Sui, and Wu proposed a layered secure-communication model with batch authentication for UAV swarms, targeting the computational limitations of large peer groups [7]. Other recent work has examined robust mutual authentication for decentralized drone swarms and has emphasized that inter-drone trust should not depend exclusively on a stationary base station [12]. The 2025 survey literature also highlights the increasing importance of lightweight encryption, dynamic rekeying, and post-quantum transition planning [3,4].

The present work does not propose a new primitive. Instead, it composes standard primitives around a control-systems requirement: expensive distributed trust operations should not be in the highest-rate flight-critical path. Identity signatures are therefore used for admission, rekeying, and critical evidence, while session traffic uses symmetric authenticated encryption.

1.3. Blockchain for UAV Identity and Trust

Blockchain-based UAV studies have addressed identity registration, smart-contract coordination, cross-domain authentication, access control, and GNSS-spoofing evidence [5,6,8,9,10,13]. Jiao et al. reduced dynamic identity overhead using blockchain and aggregatable subvector commitments [8]. Li et al. integrated blockchain with decentralized swarm formation control [6]. Zhong et al. used blockchain sharding for certificateless UAV identity authentication [9]. Sang et al. proposed credit-based grouping to reduce PBFT cost for swarm identity authentication [10]. These studies reinforce two points relevant here: decentralized trust is attractive for UAVs, and conventional consensus cost must be controlled.

The proposed event-sparse model is deliberately different from approaches that place frequent coordination state on chain. The ledger does not decide ordinary motion updates. It stores evidence needed to reconstruct or verify changes to the trust boundary.

1.4. Zero Trust and Safety-Critical Robotics

The fail-closed design is also consistent with classical least-privilege and complete-mediation principles [14]. Zero trust is commonly summarized as “never trust, always verify,” but in a robotic swarm the phrase must be converted into explicit runtime predicates [15]. The receiver has local context that a network gateway does not: battery margin, localization confidence, geofence status, link quality, command freshness, and current security state. Consequently, trust evaluation is distributed and contextual.

A practical implication is that the authorization relation is time varying. Let ${\mathcal{V}}_k$ denote the set of peers eligible to participate in trust decisions at security epoch $k$. A peer can be cryptographically known yet temporarily excluded from ${\mathcal{V}}_k$ because of stale firmware, repeated replay detections, clock instability, or a trust score below policy threshold.

2. Materials and Methods

2.1. Existing Software Baseline and Evidence Boundary

2.1.1. Inspected Security Baseline

The software baseline inspected for this study is the public GPS-denied UAV swarm repository at release line v2.0.0 and commit c040073969a6111f4c652d08e8de8629d70b2317 [11]. The current peer packet authentication implementation canonicalizes the packet before authentication, computes SHA-256/HMAC-SHA256, supports a configurable trust epoch, rejects a sequence number that is not strictly greater than the last accepted sequence, checks message age against a clock-skew and TTL window, and performs constant-time comparison of the provided and expected MAC. Unsigned packets are only admissible under explicit simulation or selected bench profiles.

The source defines authentication modes for HMAC-SHA256, Ed25519 placeholder, and post-quantum hybrid placeholder. The latter two paths return unsupported status in the inspected build. This is a useful boundary: the repository already contains the runtime abstractions needed for stronger identity modes, but the paper does not treat those placeholders as implemented cryptography.

The onboard SecurityRuntimeMonitor maps security observations to states such as TRUSTED, DEGRADED_LINK, AUTH_SUSPECT, PEER_SPOOF_SUSPECT, COMMAND_REPLAY_SUSPECT, CONTROL_PLANE_UNTRUSTED, ISOLATED_AUTONOMY, SAFE_RETURN, and LAND_IMMEDIATELY. The command policy checks message age, issuer trust, geofence, no-fly lock, swarm consistency, localization confidence, battery state, and whether the current security state permits remote control. This provides a useful zero-trust foundation because network authentication and flight policy are already separated.

Firmware trust logic additionally stores a firmware measurement, signer identity, rollback counter, secure-boot and bootloader-state flags, and SHA3-based manifest evidence. These features motivate ledger anchoring of trust-changing events without implying that the current firmware subsystem is blockchain-backed.

Table 1 summarizes the boundary between the implemented software baseline and the proposed high-assurance extension.

2.1.2. Shared-Secret Limitation and Per-Node Identity Motivation

A shared HMAC key is efficient and can provide strong message integrity if the secret remains confidential. It does not, however, provide compromise containment or non-repudiable per-node identity. If all peers share the same key $K_s$, compromise of one peer exposes the authentication capability of the entire swarm. The forgery domain is therefore approximately the set of all peers that possess $K_s$.

Let $\mathcal{N}$ be the swarm and $\mathcal{C}\subset \mathcal{N}$ the compromised set. Under a single shared secret, a first-order compromise-containment indicator can be written as

$${\Gamma }_{shared}=\left\{\begin{array}{ll}1,& \left|\mathcal{C}\right|=0,\\ 0,& \left|\mathcal{C}\right|\ge 1.\end{array}\right.$$

(2)

With independent per-node identity keys $K_i$, compromise of node $i$ does not reveal the signing key of node $j\ne i$ under the key-independence assumption. A simple normalized containment measure is therefore

$${\Gamma }_{node}=1-{\displaystyle \frac{\left|\mathcal{C}\right|}{\left|\mathcal{N}\right|}}.$$

(3)

This equation is not a probability of mission success; it is a structural measure showing why independent identities narrow the forgery domain.

2.1.3. Evidence Classes

To prevent analytical results from being confused with experimental measurements, four evidence classes are used.

• Implemented: directly inspected in current repository source.
• Measured: values reported by repository benchmark artifacts.
• Proposed: architecture or protocol elements not established as current implementation.
• Analytical: deterministic calculations produced from equations and explicitly stated assumptions.

Blockchain-specific latency, throughput, energy, and storage values in this paper are analytical unless otherwise stated. No physical-flight, RF-channel, hardware cryptographic accelerator, or production blockchain deployment is claimed.

2.2. Threat Model and Design Objectives

2.2.1. Adversary Model

The adversary can observe, delay, replay, inject, reorder, or modify wireless packets; can attempt to impersonate a known UAV; can introduce an unauthorized node; can compromise a bounded subset of validator nodes; and can attempt to replay previously valid commands. A compromised UAV may possess its own legitimate identity key and therefore can produce cryptographically valid but malicious traffic. The framework must consequently separate identity validity from behavioral trust.

The adversary is not assumed to break standard cryptographic primitives. Physical capture, radio jamming, GNSS interference, sensor spoofing, and side-channel extraction are considered operational threats, but only some are mitigated by the communication framework.

The modeled attack classes, primary controls, and residual limitations are summarized in Table

Table 2. Threats and intended response.

Threat	Primary control	Residual limitation
Packet modification	AEAD/HMAC integrity	Key compromise bypasses integrity for that identity
Replay	Sequence + timestamp + TTL + epoch	Requires correct persistent replay state
Peer spoofing	Per-node identity verification	Physical key theft remains possible
Rogue membership	Permissioned ledger registry	Validator compromise bounded by BFT assumption
Critical command injection	Identity + zero-trust policy + safety gate	Legitimate but compromised peer may still send harmful intent
Key rotation abuse	Ledger-anchored rotation	Consensus availability required for global update
Firmware rollback	Local rollback counter + ledger anchor	Hardware root of trust not demonstrated here
Ledger history tampering	Hash chain + BFT consensus	Requires $f<N/3$ for PBFT-style safety
RF jamming/DoS	Local autonomous fallback	Blockchain does not solve physical-layer denial

Table 2. Threats and intended response.

Threat	Primary control	Residual limitation
Packet modification	AEAD/HMAC integrity	Key compromise bypasses integrity for that identity
Replay	Sequence + timestamp + TTL + epoch	Requires correct persistent replay state
Peer spoofing	Per-node identity verification	Physical key theft remains possible
Rogue membership	Permissioned ledger registry	Validator compromise bounded by BFT assumption
Critical command injection	Identity + zero-trust policy + safety gate	Legitimate but compromised peer may still send harmful intent
Key rotation abuse	Ledger-anchored rotation	Consensus availability required for global update
Firmware rollback	Local rollback counter + ledger anchor	Hardware root of trust not demonstrated here
Ledger history tampering	Hash chain + BFT consensus	Requires $f<N/3$ for PBFT-style safety
RF jamming/DoS	Local autonomous fallback	Blockchain does not solve physical-layer denial

2.2.2. Design Objectives

The design objectives are: (i) keep flight-critical peer traffic off-chain; (ii) eliminate shared-identity dependence for high-assurance modes; (iii) fail closed on stale, replayed, epoch-mismatched, or unauthorized commands; (iv) preserve local autonomy when distributed trust becomes unavailable; (v) make trust-changing events auditable; and (vi) expose the scaling cost mathematically rather than hiding consensus overhead behind aggregate benchmark claims.

A message $m_{i\to j}$ is accepted only if all required predicates are true:

$${\mathcal{A}}_{ij}\left(m\right)=I_{id}{I}_{int}{I}_{fresh}{I}_{seq}{I}_{epoch}{I}_{trust}{I}_{policy},$$

(4)

where each indicator belongs to $\{0,1\}$. Fail-closed behavior follows directly:

$${\mathcal{A}}_{ij}\left(m\right)=0 \mathrm{if}\mathrm{any}\mathrm{required}\mathrm{predicate}\mathrm{equals}0.$$

(5)

2.3. Event-Sparse Zero-Trust Architecture

2.3.1. Two-Plane Security Architecture

The design separates a high-rate secure data plane from a lower-rate trust ledger plane. The data plane carries telemetry, formation state, peer health, and routine coordination using direct authenticated sessions. The ledger plane stores only events that change or attest trust state.

The two-plane architecture is shown in Figure 1.

Each UAV has a long-term identity key pair $\left(s{k}_i,p{k}_i\right)$. The ledger maintains the authorized mapping between node identifier, public key, current trust epoch, role, and selected firmware evidence. Peers establish ephemeral session keys after verifying identity membership. A practical realization can use Ed25519-class signatures [16], X25519 key exchange [17], HKDF-SHA256 [18], and ChaCha20-Poly1305 or an equivalent AEAD [19]. These primitives are selected as a concrete protocol profile, not as a claim that the current repository already implements them.

2.3.2. Canonical Message Binding

The current baseline already authenticates canonical serialized bytes. The same requirement is retained because ambiguous serialization can break cross-node signature verification. For packet $m$, define

$$h_m=H\left(\mathrm{c}\mathrm{a}\mathrm{n}\mathrm{o}\mathrm{n}\left(m_{body}\right)\right),$$

(6)

where $H$ is SHA-256 or another collision-resistant hash and the authentication field is excluded from the canonical payload.

The baseline follows the HMAC construction standardized in RFC 2104 [20] over a canonical payload hash compatible with SHA-256 [21]. For HMAC compatibility mode,

$${\mathrm{M}\mathrm{A}\mathrm{C}}_m={\mathrm{H}\mathrm{M}\mathrm{A}\mathrm{C}}_{K_s}\left(\mathrm{c}\mathrm{a}\mathrm{n}\mathrm{o}\mathrm{n}\left(m_{body}\right)\right).$$

(7)

For per-node identity evidence on admission or critical events,

$${\sigma }_i={\mathrm{S}\mathrm{i}\mathrm{g}\mathrm{n}}_{s{k}_i}\left(h_m\parallel e\parallel t\right),$$

(8)

where $e$ is the trust epoch and $t$ is the event time.

2.3.3. Authenticated Session Establishment

Authenticated key exchange is modeled using standard secure-channel composition principles [22]. Two peers $i$ and $j$ exchange ephemeral public keys $X_i$ and $X_j$. The shared secret is

$$Z_{ij}=\mathrm{X}25519\left(x_i,X_j\right)=\mathrm{X}25519\left(x_j,X_i\right).$$

(9)

The session key material is derived as

$$K_{ij}=\mathrm{H}\mathrm{K}\mathrm{D}\mathrm{F}\left(Z_{ij},h_{ctx},i{d}_i\parallel i{d}_j\parallel e\right).$$

(10)

Binding the trust epoch to key derivation prevents a session from silently surviving an epoch change unless policy explicitly permits it. Data-plane confidentiality and integrity are then

$$\left(c,tag\right)={\mathrm{A}\mathrm{E}\mathrm{A}\mathrm{D}.\mathrm{E}\mathrm{n}\mathrm{c}}_{K_{ij}}\left(nonce,m,aad\right),$$

(11)

with associated data containing identity, sequence, epoch, and message type.

2.3.4. Freshness, Replay, and Epoch Predicates

Let $s_m$ be the packet sequence, $s_{last}\left(i\right)$ the last accepted sequence for sender $i$, $t_m$ the sender timestamp, $t_r$ the receiver time, $TT{L}_m$ the time-to-live, and ${\Delta }_{clk}$ the accepted clock-skew margin. Freshness is

$$I_{fresh}=𝟙\left(\left|t_r-t_m\right|\le TT{L}_m+{\Delta }_{clk}\right).$$

(12)

Monotonic replay protection is

$$I_{seq}=𝟙\left(s_m>s_{last}\left(i\right)\right).$$

(13)

Trust-epoch validity is

$$I_{epoch}=𝟙\left(e_m=e_{local}\right).$$

(14)

The combined network-authentication predicate is

$$I_{net}=I_{id}{I}_{int}{I}_{fresh}{I}_{seq}{I}_{epoch}.$$

(15)

2.3.5. Onboard Command Policy

Network authentication is necessary but not sufficient. Let $T_i$ be issuer trust, $T_{min}$ the local issuer threshold, $C_{loc}$ localization confidence, $C_{min}$ the minimum localization confidence for formation control, $B$ battery percentage, and $G$ a binary geofence-safe indicator. A non-emergency command is locally admissible only if

Define the local indicator variables $I_T=𝟙\left(T_i\ge T_{min}\right)$, $I_C=𝟙\left(C_{loc}\ge C_{min}\right)$, and $I_B=𝟙\left(B\ge B_{min}\right)$. The command-policy predicate is then

$$I_{policy}=I_T{I}_C{I}_{B}G{I}_{sec}.$$

(16)

The current repository uses this general style of fail-closed local gating. A critical emergency-land command can be assigned a separate safety rule because the cost of rejecting an authentic emergency instruction may exceed the risk of ordinary remote maneuver acceptance.

2.3.6. Event-Sparse Ledger Anchoring

Let $\mathcal{M}$ be the stream of secure swarm messages and $g\left(m\right)\in \{0,1\}$ an event filter. A ledger transaction is generated only if $g\left(m\right)=1$. The filtered event set is

$$\mathcal{E}=\{m\in \mathcal{M}:g\left(m\right)=1\}.$$

(17)

Candidate events include identity registration/revocation, key rotation, trust-epoch transition, firmware measurement update, repeated replay/spoof escalation, validator-set change, and selected critical command evidence. The anchoring ratio over a window $W$ is

$${\rho }_W={\displaystyle \frac{\left|{\mathcal{E}}_W\right|}{\left|{\mathcal{M}}_W\right|}}, 0\le {\rho }_W\le 1.$$

(18)

The design goal is ${\rho }_W\ll 1$ during nominal flight. This is not a requirement that security events be rare; it is a requirement that routine telemetry must not become ledger traffic.

2.4. Mathematical Trust and Security Model

2.4.1. Tamper and Link-Integrity Scores

The inspected software baseline uses weighted heuristic security scores. Preserving its semantics, define replay, spoof, control-plane, and authorization indicators $R_i,S_i,C_i,A_i\in \{0,1\}$. A bounded tamper score is

$$u_i={\tau }_{0,i}+0.20R_i+0.25S_i+0.12C_i+0.10A_i.$$

(19)

$${\tau }_i=\mathrm{c}\mathrm{l}\mathrm{i}\mathrm{p}\left(u_i,0,1\right).$$

(20)

The coefficients are implementation policy weights rather than learned statistical parameters. A link-integrity score using link quality $q_i$, synchronization confidence $s_i$, localization confidence ${\mathcal{l}}_i$, issuer trust $u_i^{\left(t\right)}$, and peer-presence factor $p_i$ is obtained from

$$v_i=0.35q_i+0.25s_i+0.15{\mathcal{l}}_i+0.15u_i^{\left(t\right)}+0.10p_i,$$

(21)

followed by the bounded mapping

$$L_i=\mathrm{c}\mathrm{l}\mathrm{i}\mathrm{p}\left(v_i,0,1\right).$$

(22)

A composite node trust score can then be defined as

$$T_i=L_i\left(1-{\tau }_i\right).$$

(23)

This multiplicative form ensures that high communication quality does not cancel strong tamper evidence.

2.4.2. Time Evolution and Recovery

A trust system should not remain permanently degraded after one benign transient, but it should also not recover instantly after repeated attacks. Let $o_i\left(k\right)\in \left[0,1\right]$ be the quality of the current observation and $\mu \in \left(0,1\right)$ a smoothing factor. A base update is

$${\tilde{T}}_i\left(k+1\right)=\left(1-\mu \right)T_i\left(k\right)+\mu o_i\left(k\right).$$

(24)

Attack penalties ${\pi }_r,{\pi }_s,{\pi }_a,{\pi }_c$ produce

$$z_i\left(k+1\right)={\tilde{T}}_i\left(k+1\right)-{\pi }_r{R}_i-{\pi }_s{S}_i-{\pi }_a{A}_i-{\pi }_c{C}_i.$$

(25)

$$T_i\left(k+1\right)=\mathrm{c}\mathrm{l}\mathrm{i}\mathrm{p}\left(z_i\left(k+1\right),0,1\right).$$

(26)

A node is eligible for remote-command authority when

$$I_{trust}=𝟙\left(T_i\ge T_{cmd}\right).$$

(27)

and for validator duty under the stricter threshold $T_{val}$ when

$$I_{val}=𝟙\left(T_i\ge T_{val}\right)I_{fw}{I}_{epoch}, T_{val}\ge T_{cmd}.$$

(28)

Figure 2 illustrates the resulting trust response to a representative sequence of nominal and adverse security events.

2.4.3. Dynamic Validator Set

The validator set at epoch $k$ is

$${\mathcal{V}}_k=\left\{i\in \mathcal{N}:I_{val,i}\left(k\right)=1\right\}.$$

(29)

with population

$$N_k=\left|{\mathcal{V}}_k\right|.$$

(30)

For PBFT-style safety, the tolerated Byzantine count satisfies [23]

$$N_k\ge 3f_k+1.$$

(31)

The corresponding commit quorum is

$$q_k=2f_k+1.$$

(32)

If a security incident reduces $N_k$ below the configured safe validator floor, the design does not relax consensus requirements. It freezes global trust-changing commits and lets each UAV continue under local fail-safe autonomy. This choice favors safety over ledger availability.

2.4.4. Ledger Event Structure

For event $e_k$, let ${\xi }_k$ denote the canonical tuple containing node identity, event type, payload hash, trust epoch, sequence number, and event time. The event digest is

$$d_k=H\left({\xi }_k\right).$$

(33)

A chained ledger record is

$$h_k=H\left(h_{k-1}\parallel d_k\parallel r_k\right),$$

(34)

where $r_k$ is a consensus round or block identifier. If events are batched, a Merkle root can summarize a set $\{d_1,\dots ,d_b\}$:

$$R_b=\mathrm{M}\mathrm{e}\mathrm{r}\mathrm{k}\mathrm{l}\mathrm{e}\mathrm{R}\mathrm{o}\mathrm{o}\mathrm{t}\left(d_1,\dots ,d_b\right).$$

(35)

The purpose is tamper evidence and distributed agreement on trust history, not storage of high-rate sensor data.

2.5. Consensus, Communication, Storage, and Energy Models

2.5.1. PBFT-Style Communication Complexity

The permissioned-ledger analysis uses PBFT as the conservative quadratic reference model [23]; linear-communication BFT protocols such as HotStuff [24] and permissioned platforms such as Hyperledger Fabric [25] provide alternative implementation points. A conventional PBFT exchange has a primary broadcast plus prepare and commit all-to-all phases. A useful upper-bound-style message-count model for one anchored event is

$$M_{BFT}\left(N\right)=\left(N-1\right)+2N\left(N-1\right)=\left(N-1\right)\left(2N+1\right).$$

(36)

Thus

$$M_{BFT}\left(N\right)=\Theta \left(N^2\right).$$

(37)

The quadratic term is exactly why consensus must not be placed on each telemetry packet.

Figure 3 visualizes the quadratic PBFT-style control-message growth with validator count.

If each consensus control message has size $b_c$ bytes, control bytes per ledger event are

$$B_{event}\left(N\right)=M_{BFT}\left(N\right)b_c.$$

(38)

If secure swarm traffic is generated at ${\lambda }_s$ messages/s and an event fraction $\rho$ is anchored, the ledger transaction rate is

$${\lambda }_b=\rho {\lambda }_s.$$

(39)

The corresponding consensus-control bandwidth is

$${\dot{B}}_{cons}=\rho {\lambda }_s{M}_{BFT}\left(N\right)b_c.$$

(40)

For naive per-packet anchoring, $\rho =1$. Therefore the event-sparse bandwidth ratio is

$${\displaystyle \frac{{\dot{B}}_{sparse}}{{\dot{B}}_{naive}}}=\rho ,$$

(41)

and the ideal reduction factor is

$$G_B={\displaystyle \frac{1}{\rho }}.$$

(42)

Figure 4 shows the corresponding event-sparse ledger load for the analytical traffic case.

2.5.2. End-to-End Delay Separation

Real-time packet delay is modeled as

$$T_{data}=T_{queue}+T_{radio}+T_{dec}+T_{policy}+T_{local},$$

(43)

where $T_{dec}$ includes AEAD verification and $T_{policy}$ is local zero-trust evaluation. Ledger confirmation is intentionally excluded from $T_{data}$.

For a trust-changing event,

$$T_{event}=T_{filter}+T_{sign}+T_{consensus}+T_{persist}.$$

(44)

This separation is a core architectural property. A delayed ledger commit may defer a membership or key-state transition, but it does not stall already authorized telemetry exchange in the current epoch.

2.5.3. Storage Model

Let $b_e$ be average stored bytes per anchored event. Daily ledger growth is

$$S_{day}=86400\hspace{0.17em}\rho {\lambda }_s{b}_e.$$

(45)

Over $D$ days,

$$S\left(D\right)=D\hspace{0.17em}{S}_{day}.$$

(46)

Figure 5 shows how the anchoring ratio directly controls analytical ledger-storage growth.

2.5.4. Security Overhead and Energy Model

Let $T_{plain}$ denote baseline processing time and $T_{secure}$ the secured path. Relative processing overhead is

$$O_T={\displaystyle \frac{T_{secure}-T_{plain}}{T_{plain}}}\times 100\mathrm{\%}.$$

(47)

For packet rate ${\lambda }_s$, average processing energy per second is modeled as

$$E_{sec}={\lambda }_s\left(E_{aead}+E_{policy}\right)+\rho {\lambda }_s\left(E_{sign}+E_{cons}\right).$$

(48)

The incremental security energy relative to an unsecured baseline is

$$\Delta E=E_{sec}-E_{plain}.$$

(49)

Again, consensus energy is multiplied by $\rho$, which gives the event-sparse architecture its primary efficiency advantage.

2.5.5. Multi-Objective Anchoring Policy

Anchoring too frequently wastes communication and storage; anchoring too rarely delays global trust evidence. Collect normalized latency, bandwidth, storage, energy, and security-risk terms in

$$\mathbf{c}\left(\rho \right)={\left[\widehat{L},\widehat{B},\widehat{S},\widehat{E},\widehat{R}\right]}^T,$$

(50)

with nonnegative preference vector $\mathbf{w}={\left[w_L,w_B,w_S,w_E,w_R\right]}^T$. A tunable objective is

$$J\left(\rho \right)={\mathbf{w}}^T\mathbf{c}\left(\rho \right),$$

(51)

subject to

$$0<\rho \le 1, T_{event}\left(\rho \right)\le T_{trust,max}, P_{miss}\left(\rho \right)\le ϵ.$$

(52)

The optimal anchoring policy is

$${\rho }_{opt}=\mathrm{a}\mathrm{r}\mathrm{g}\underset{\rho }{\mathrm{m}\mathrm{i}\mathrm{n}}J\left(\rho \right).$$

(53)

In a deployed system, $\rho$ need not be a fixed random sampling fraction. It is more naturally induced by event semantics: every critical trust transition is anchored, while ordinary state updates are not.

2.6. Analytical Evaluation Protocol and Reproducibility

The purpose of the numerical study is to make scaling behavior concrete, not to claim measured blockchain performance. Unless stated otherwise, the analytical examples use a swarm message rate ${\lambda }_s=100$ messages/s, average stored event record $b_e=512$ bytes, and consensus control message size $b_c=192$ bytes. These sizes are engineering assumptions chosen for transparent arithmetic. They should be replaced by serialized measurements when a concrete ledger implementation is added.

Table 3 lists the parameters used for the deterministic analytical evaluation.

The analytical calculations are deterministic consequences of the stated equations and parameters. The inspected software baseline corresponds to release v2.0.0 and commit c040073969a6111f4c652d08e8de8629d70b2317. The public research artifact and replication materials are archived in Zenodo at https://doi.org/10.5281/zenodo.22092648. Blockchain-specific latency, throughput, storage, and energy values remain analytical unless explicitly labeled as repository measurements.

2.7. Use of Generative Artificial Intelligence

OpenAI ChatGPT (GPT-5.6 Sol, accessed 25 August 2026) was used during manuscript preparation to assist with language drafting, structural editing, mathematical typesetting, and document formatting. It was not used to generate experimental measurements. The author independently reviewed the technical claims, equations, numerical calculations, cited-source relationships, and final manuscript and takes full responsibility for the published content.

3. Results

3.1. Validator-Scaling Results

For representative validator counts, the BFT fault bound, quorum, and message count are calculated from the previous equations.

Table 4 reports the resulting PBFT-style validator-scaling calculations.

For $N=10$, the integer Byzantine bound is $f=3$ and the corresponding quorum is

$$q=2\left(3\right)+1=7.$$

(54)

The modeled control message count is

$$M_{BFT}\left(10\right)=\left(10-1\right)\left(2\cdot 10+1\right)=189.$$

(55)

Thus, at $b_c=192$ bytes, the modeled control traffic is 36,288 bytes per event, equivalent to approximately 35.44 KiB:

$$B_{event}\left(10\right)=189\times 192=\mathrm{36,288}.$$

(56)

With ${\lambda }_s=100$ messages/s and $\rho =0.01$, the ledger rate is one anchored event per second:

$${\lambda }_b=0.01\times 100=1.$$

(57)

The analytical consensus bandwidth is therefore approximately 35.44 KiB/s.

If every packet were anchored, $\rho =1$ and the same model gives approximately 3.46 MiB/s.

The ratio is exactly

$${\displaystyle \frac{{\dot{B}}_{sparse}}{{\dot{B}}_{naive}}}=0.01,$$

(58)

which is a $100\times$ reduction under the stated assumptions.

3.2. Ledger Storage Results

At $b_e=512$ bytes and $\rho =0.01$,

$$S_{day}=86400\times 1\times 512=\mathrm{44,236,800}.$$

(59)

This equals approximately 42.19 MiB/day. Per-packet anchoring at 100 events/s would instead produce approximately 4,218.75 MiB/day (4.12 GiB/day).

This calculation excludes block headers, indexes, state databases, replication copies, and pruning. Its purpose is to show the order-of-magnitude pressure created by event frequency.

3.3. Repository Security-Path Benchmark Baseline

The repository’s Phase 6 benchmark report includes representative wall-clock paths for telemetry serialization and swarm authentication. The reported swarm-auth path has mean 22.603 ms, p50 12.219 ms, p95 115.594 ms, and p99 124.142 ms. Telemetry serialization has mean 15.740 ms, p50 9.985 ms, p95 22.272 ms, and p99 121.210 ms. The benchmark documentation explicitly notes that these are representative harness paths rather than isolated hardware cryptographic measurements, and that process-launch effects contribute to tail behavior [11].

Figure 6 visualizes the repository security and serialization benchmark baseline used for comparison.

Table 5 reports the same repository evidence numerically and preserves its stated measurement limitations.

These measurements support the architectural decision to keep distributed consensus out of the packet path. They do not establish the latency of Ed25519, X25519, AEAD, or a future blockchain implementation.

3.4. Security Properties

3.4.1. Replay Resistance

Proposition 1. Assume the receiver maintains the last accepted sequence $s_{last}\left(i\right)$ for sender $i$, rejects $s_m\le s_{last}\left(i\right)$, enforces the time-window predicate, and does not roll replay state backward. Then an exact replay of a previously accepted packet is rejected.

Argument. A previously accepted packet has sequence $s_m\le s_{last}\left(i\right)$ after acceptance. Therefore $I_{seq}=0$ on replay, making ${\mathcal{A}}_{ij}\left(m\right)=0$ regardless of the cryptographic tag. The time predicate provides a second rejection channel for delayed replays. Persistence and crash consistency of replay state remain implementation requirements.

3.4.2. Integrity and Authenticity

For a 256-bit MAC, a generic random forgery bound after $Q$ independent attempts is approximately

$$P_{forge}\le {\displaystyle \frac{Q}{2^{256}}},$$

(60)

under the idealized assumption that the attacker has no key information and the MAC behaves as a secure pseudorandom function [20,21]. This expression is not intended as a complete protocol proof; it illustrates that operational weakness is more likely to arise from key compromise, state rollback, or policy error than from brute-force tag guessing.

For a collision-resistant 256-bit event hash, the birthday-bound collision probability after $n$ randomly distributed hashes is approximately

$$P_{coll}\approx {\displaystyle \frac{n\left(n-1\right)}{2^{257}}}.$$

(61)

3.4.3. Compromise Containment

Proposition 2. Under independent per-node identity keys, compromise of node $i$ does not by itself enable valid signatures as node $j\ne i$.

Argument. Each identity signature is verified under the public key bound to the claimed node identifier. Without $s{k}_j$, a compromised node $i$ cannot create a signature that verifies under $p{k}_j$ under the assumed unforgeability of the signature scheme. This property is absent when all peers authenticate solely with one shared HMAC secret.

The proposition does not prevent a compromised legitimate node from issuing malicious messages under its own identity. That threat is handled by behavioral trust, command policy, validator eligibility, and revocation.

3.4.4. Ledger Safety

Proposition 3. For a PBFT-style permissioned ledger with $N\ge 3f+1$, no more than $f$ Byzantine validators, authenticated channels, and correct protocol execution, conflicting trust-state commits cannot both obtain valid commit quorums [23].

This is the standard Byzantine safety condition. The paper does not claim resistance if the adversary controls one-third or more of the active validators.

3.4.5. Event-Sparsification Gain

Proposition 4. If the consensus cost per ledger event is independent of whether the event originated from a high-rate or low-rate stream, event-sparse anchoring reduces consensus traffic and base record storage by a factor $\rho$ relative to per-packet anchoring.

Argument. Both consensus bandwidth and record storage are linear in ${\lambda }_b=\rho {\lambda }_s$. Dividing the sparse expressions by their $\rho =1$ counterparts gives $\rho$.

3.4.6. Detection Metrics and Evidence Status

When the framework is experimentally evaluated under attack injection, standard classification metrics should be reported. For true positives $TP$, false negatives $FN$, false positives $FP$, and true negatives $TN$,

$$TPR={\displaystyle \frac{TP}{TP+FN}},$$

(62)

$$FPR={\displaystyle \frac{FP}{FP+TN}},$$

(63)

$$Precision={\displaystyle \frac{TP}{TP+FP}},$$

(64)

and

$$F_1={\displaystyle \frac{2\cdot Precision\cdot TPR}{Precision+TPR}}.$$

(65)

No such attack-detection rates are fabricated in this paper. They are defined here as required metrics for the future executable security evaluation.

Table 6 consolidates the claimed security properties and their evidence status.

4. Discussion

4.1. Why Blockchain Is Not the Packet Authenticator

The main architectural conclusion is that blockchain should not replace the packet authenticator. A blockchain is useful when multiple parties need a shared, tamper-evident ordering of trust changes. It is inefficient when used as a prerequisite for every routine telemetry packet. The direct data plane and the ledger plane solve different problems.

A secure data plane needs micro- to millisecond-scale cryptographic checks, bounded state, deterministic failure behavior, and no dependence on remote consensus. A trust ledger can tolerate slower confirmation because it records changes to the authorization context rather than individual control-loop samples. This separation also provides a clean degradation mode: if consensus is unavailable, existing sessions can continue under the current epoch until policy timeouts force isolation or safe return.

4.2. What Should Be Anchored

The strongest candidates for ledger anchoring are events that change who is trusted or what evidence defines a trusted node. These include admission, revocation, identity-key rotation, role or validator-set change, trust-epoch transition, firmware measurement update, and selected critical-command decisions. High-rate position, velocity, IMU, obstacle, or neighbor-state packets should remain off-chain unless an application specifically requires later forensic anchoring of a summarized digest.

A useful compromise for high-rate evidence is periodic window hashing. If $m_1,\dots ,m_w$ are packets in a window, store only

$$H_W=H\left(H\left(m_1\right)\parallel H\left(m_2\right)\parallel \dots \parallel H\left(m_w\right)\right),$$

(66)

or a Merkle root. This provides later tamper evidence without storing the packet stream itself.

4.3. Relationship to Recent Literature

Recent blockchain UAV research increasingly targets lightweight identity state, sharding, reputation-aware consensus, and batch verification [8,9,10]. The event-sparse proposal is complementary. It does not require every UAV to become a full blockchain node, nor does it require a specific consensus optimization. It reduces the arrival rate of consensus work before consensus begins. A future implementation could therefore combine event sparsification with sharding, grouped PBFT, HotStuff-style consensus, or hardware-rooted identities.

4.4. Relevance of GPS-Denied Operation to the Trust Model

In GPS-denied operation, localization confidence and timing confidence may vary independently of cryptographic validity. A swarm security model that ignores navigation state can accept a technically authentic command at a moment when the receiving vehicle cannot safely execute it. The existing software baseline already reflects this coupling by including localization, synchronization, geofence, and link-quality signals in its security and command decisions. The proposed ledger retains that principle: blockchain establishes shared evidence about trust, but onboard autonomy remains the final authority over physically safe command execution.

4.5. Limitations and Future Validation

The paper has four important limitations.

First, the blockchain layer is a proposed extension, not a measured component of the inspected repository. The numerical consensus and storage results are analytical calculations based on explicit assumptions. They must not be interpreted as deployed ledger benchmarks.

Second, the current HMAC baseline is implemented, but per-node Ed25519, X25519, AEAD, and post-quantum modes are not established as current release features. The repository explicitly marks Ed25519 and PQC modes as placeholders. A future implementation should add a real key lifecycle, node-specific credentials, persistent replay state, secure key storage, and fail-closed key rotation.

Third, the paper does not claim protection against RF jamming, physical capture, side-channel key extraction, malicious sensor data from an otherwise trusted node, or a Byzantine fraction beyond the selected consensus bound. Blockchain does not solve physical-layer denial of service.

Fourth, there is no physical-flight or radio-channel validation in this paper. A complete experimental program should add: (i) deterministic replay attack injection; (ii) packet tampering and spoofing; (iii) key-compromise and revocation tests; (iv) validator Byzantine faults; (v) ledger partition and reconnection; (vi) CPU, memory, energy, and bandwidth measurements on representative edge hardware; (vii) cross-platform crash-recovery tests for sequence and epoch state; and (viii) tethered or hardware-in-the-loop experiments before any free-flight conclusion.

A future empirical study should report not only average latency but p50/p95/p99 tails, attack-rejection metrics, ledger convergence time, state-recovery correctness, energy per authenticated packet, energy per anchored event, and the proportion of mission time spent in degraded or isolated security states.

4.6. Reproducibility and Evidence Boundary

The software baseline discussed in the paper is publicly available in the repository cited in [11]. The inspected commit is c040073969a6111f4c652d08e8de8629d70b2317. The analytical results in Table 3 and Table 4 and Figure 3, Figure 4 and Figure 5 follow directly from the equations and stated parameters; they can be reproduced without proprietary data. The repository benchmark values in Figure 6 and Table 5 are taken from the documented performance-engineering artifacts and are kept separate from the proposed blockchain calculations.

5. Conclusions

This paper presented a mathematical framework for secure decentralized UAV swarm communication in which zero-trust packet decisions and blockchain-based trust evidence operate on different timescales. The existing software baseline demonstrates that useful security semantics already exist at the edge: canonical authentication, trust epochs, freshness checks, replay rejection, security-state transitions, command-policy gating, and firmware trust records. The proposed extension strengthens identity isolation through per-node keys and adds a permissioned ledger for trust-changing evidence.

The central result is architectural rather than cryptographic: consensus should protect changes to trust, not mediate every packet. The event-sparse model makes this statement quantitative. Ledger bandwidth, storage, and energy terms become proportional to the anchoring ratio $\rho$, while PBFT-style consensus still grows as $\Theta \left(N^2\right)$ with validator count. Under the representative analytical case of ten validators, 100 swarm messages/s, a 192-byte control envelope, and a 1% anchoring ratio, consensus control traffic falls by 100-fold relative to per-packet anchoring. These calculations do not substitute for implementation benchmarks, but they identify a design region in which decentralized trust can coexist with low-latency robotic communication.

The next research step is therefore concrete: implement independent node identities and AEAD sessions, add a permissioned event ledger behind the current zero-trust policy boundary, and validate the complete system under attack injection, crash recovery, edge-hardware measurement, and eventually hardware-in-the-loop operation.