BlockSDN-VC: SDN-Aided Blockchain Broadcasting

• The paper introduces BlockSDN-VC, a framework that integrates SDN with a virtual coordinate system to enhance blockchain transaction dissemination.
• It centralizes coordinate computation and relay control at an SDN controller, achieving up to 62% lower median latency and 4x faster convergence in simulations.
• Experimental results in Conflux environments show a 17% throughput gain with minimal control overhead, while ensuring robustness against adversarial attacks.

BlockSDN-VC is a transaction-broadcast framework for high-performance blockchains that combines software-defined networking (SDN) with a virtual coordinate system (VCS) in order to accelerate propagation while preserving routing consistency under network dynamics. Its central design move is to relocate coordinate computation and forwarding control from decentralized peers to an SDN controller with a global, real-time view of delays and topology. In the reported geo-distributed simulations, the framework cuts median latency by up to 62%, accelerates convergence fourfold, and keeps control-plane overhead under 3%; in a real blockchain environment based on Conflux, it improves confirmed-transaction throughput by 17% without requiring modifications to existing clients (Jia et al., 30 Sep 2025).

1. Problem setting and design rationale

Modern blockchains require fast and reliable transaction propagation to maximize both security and throughput. Conventional peer-to-peer gossip overlays, as used in systems such as Bitcoin and Ethereum, exhibit high latency because dissemination depends on random neighbor selection and iterative convergence. More recent relay schemes, including MERCURY, reduce latency by embedding peers in a virtual coordinate system and using latency-aware “early outburst” relays, but decentralized VCS maintenance remains a bottleneck because coordinates are updated slowly and independently at each node (Jia et al., 30 Sep 2025).

BlockSDN-VC is motivated by three reported deficiencies of decentralized VCS. First, convergence is slow: decentralized coordinate systems such as Vivaldi may require tens of seconds and many gossip rounds to react to churn or failures, which produces suboptimal routing. Second, coordinate maintenance is vulnerable: adversaries may forge or inflate measurements, increasing path stretch and latency. Third, the system is globally inconsistent after churn or congestion because each node computes coordinates independently. The framework addresses these issues by exploiting the fact that many modern high-throughput and permissioned blockchains in datacenters or ISPs are already deployed over SDN, where the controller can compute and distribute globally consistent coordinates and relay policies (Jia et al., 30 Sep 2025).

Within this formulation, the broadcast problem is treated as a control-plane optimization problem rather than a purely overlay-local heuristic. The consequence is a dissemination policy that is centrally computed but executed in the blockchain overlay. This shifts the optimization target from local neighbor choice to globally coordinated latency minimization, with explicit attention to path stretch, consistency, and churn response.

2. SDN-based coordinate computation and controller functions

BlockSDN-VC moves VCS maintenance entirely into the SDN control plane. SDN switches export one-way latency histograms to the controller, which maintains a sparse latency matrix and computes node coordinates by solving a weighted least-squares objective over measured links:

$$\min_{\mathbf{x}} \mathcal{E}(\mathbf{x}) = \sum_{(u,v) \in M} \frac{1}{\ell(u,v)^2} \left(\| \mathbf{x}_u - \mathbf{x}_v \| - \ell(u,v) \right)^2 .$$

The reported implementation uses $\mathbb{R}^3$, and two conjugate gradient iterations are said to be sufficient to achieve less than 3% residual error. The controller issues signed coordinate deltas only when significant change is detected, exemplified by displacement greater than 5 ms. This mechanism is intended to provide both computational efficiency and network-wide consistency (Jia et al., 30 Sep 2025).

The controller also performs forwarding control. It runs K-means on the coordinates to define geo-clusters and assigns each node a relay list of size $d_{\max}$. That list mixes in-cluster neighbors chosen by Euclidean proximity in VCS with randomly chosen out-of-cluster peers. The relay information is signed and distributed periodically. Because the forwarding state is controller-specified rather than locally inferred, all nodes operate under a uniform broadcast policy, and the reported design claims deterministic and repeatable broadcast paths as long as the controller remains available (Jia et al., 30 Sep 2025).

This architecture makes the SDN controller the authoritative source for both embedding state and relay state. A plausible implication is that BlockSDN-VC is not merely a faster neighbor-selection heuristic; it is a dissemination framework whose correctness and performance hinge on controller-mediated coherence across the overlay.

3. Relay-table construction and dissemination workflow

The relay-table construction begins with the node set $V$, clustered by K-means with

$K = \lceil \sqrt{|V|} \rceil .$

For a node $v$, the relay list $L_v$ is composed of $d_{\text{near}}$ closest in-cluster peers and $d_{\text{far}} = d_{\max} - d_{\text{near}}$ random out-of-cluster peers. The default parameters are $d_{\max} = 10$, $\mathbb{R}^3$0, and $\mathbb{R}^3$1. The construction is designed to balance low-latency local diffusion with a sparse set of “escape edges” for inter-cluster reachability and robustness (Jia et al., 30 Sep 2025).

The dissemination workflow has three stages. The first is Early Outburst (Root Outburst): the originator broadcasts to all local neighbors up to the protocol limit, exemplified as 128. This one-off large fan-out, combined with controller congestion-awareness, is intended to heat up the propagation tree quickly and trim one hop from the critical path. The second stage is Relay: subsequent hops use the controller-supplied relay list $\mathbb{R}^3$2. If a node receives a transaction from a peer in a different cluster, it triggers a cluster kick-off, immediately relaying to the $\mathbb{R}^3$3 closest in-cluster peers to accelerate intra-cluster diffusion. The third stage is Fallback: if controller updates are missing for $\mathbb{R}^3$4, nodes revert to randomizing over the peer list (Jia et al., 30 Sep 2025).

The paper formalizes coverage time as

$\mathbb{R}^3$5

where $\mathbb{R}^3$6 is the set of honest nodes, $\mathbb{R}^3$7 is the reception time, and $\mathbb{R}^3$8 is the injection time. It also states a relay cost bound of bandwidth per transaction $\mathbb{R}^3$9, with $d_{\max}$0. The propagation structure is described as a tree rooted at the source, with the early-outburst phase creating a wide, balanced first layer (Jia et al., 30 Sep 2025).

4. Experimental evaluation

The packet-level simulations use a 1,000-node overlay traced from Ethereum and Conflux and compare Random-8, BlockP2P, Perigee, Mercury, and BlockSDN-VC. The configuration uses $d_{\max}$1 clusters, $d_{\max}$2, $d_{\max}$3, $d_{\max}$4, and an embedding window $d_{\max}$5. Under this setup, BlockSDN-VC records the lowest median and tail propagation latencies among the reported schemes (Jia et al., 30 Sep 2025).

Scheme	Median latency (ms)	99th %ile (ms)
Random-8	2722	6410
BlockP2P-8	1987	5080
Perigee-8	1654	4230
Mercury	1312	2910
BlockSDN-VC	630	1490

The reported median-latency reduction is 62% relative to the best prior work, approximately $d_{\max}$6. Recovery from churn or congestion is reported as 4.3x faster than Mercury. Bandwidth per transaction is 1.03x, and control-plane overhead is below 3% of total bandwidth, with an example figure of 600 B per window for control updates. The paper attributes the path-stretch reduction to globally updated coordinate assignments that reduce suboptimal routing (Jia et al., 30 Sep 2025).

The real-world evaluation integrates BlockSDN-VC into a Conflux deployment comprising 96 AWS nodes across 12 regions with latency-injected overlays. In that setting, median propagation decreases from 2960 ms to 1360 ms, and the 95th percentile decreases from 5540 ms to 2270 ms. Throughput, measured as transactions packed, increases from 310 TPS to 363 TPS, corresponding to a 17% gain. Reported bandwidth increases by only 5%, which is described as within anti-spam limits. The implementation works with unmodified blockchain clients because the logic resides in an SDN app or proxy rather than in the client protocol or consensus mechanism (Jia et al., 30 Sep 2025).

5. Adversarial behavior, fault handling, and compatibility

The adversarial evaluation focuses on coordinate-level attacks, including RTT manipulation and coordinate forgery by Byzantine participants. In simulation, with up to 49% Byzantine nodes performing inflation, deflation, or oscillation attacks on the VCS, BlockSDN-VC limits median-latency increase to 32%, whereas Mercury is reported to suffer up to a 3x slowdown. Elsewhere in the description of adversarial workloads, Mercury and related schemes are said to incur up to 3x–6x higher tail latencies. The defensive mechanisms explicitly identified are controller-side clipping and validation together with random out-of-cluster “escape edges” (Jia et al., 30 Sep 2025).

The framework also specifies behavior under controller disruption. If the SDN controller is denied service or partitioned, nodes fall back to the last signed relay table, which is described as safe though possibly suboptimal. If updates time out, nodes revert to random gossip, with the claim that this is no worse than the default behavior of Bitcoin or Ethereum. This fallback path matters because the design centralizes control-plane computation; resilience therefore depends not only on ordinary overlay robustness but also on bounded degradation when the controller is unavailable (Jia et al., 30 Sep 2025).

A recurring misconception is that an SDN-assisted dissemination framework must require protocol-level modifications to blockchain clients or consensus. The reported implementation does not: no client protocol or consensus changes are needed, the SDN application is lightweight and stateless, and deployment can be incremental without interfering with client code. Another misconception is that centralizing coordinate computation implies brittle operation. The documented fallback mechanisms qualify that concern: controller availability affects optimality, but not the ability to continue broadcasting (Jia et al., 30 Sep 2025).

6. Position within BC-SDN research

Research on blockchain–SDN integration has generally emphasized the opposite direction of dependency: blockchain is used to harden SDN through immutable logging, distributed trust, access control, auditability, and smart-contract-mediated policy enforcement (Rahman et al., 2022). A representative security-oriented architecture decentralizes the SDN control plane via blockchain, records flows and events as blockchain transactions, uses BFT-based controller synchronization, and adds cryptographic mechanisms such as attribute-based encryption and blockchain-augmented controller-switch authentication (Jiasi et al., 2019).

BlockSDN-VC occupies a distinct position in this design space. Rather than using blockchain to secure SDN, it uses SDN’s global visibility and programmable control plane to accelerate blockchain transaction dissemination and to stabilize virtual-coordinate routing (Jia et al., 30 Sep 2025). This distinction is substantive. In the broader BC-SDN literature, central questions include controller trust, auditability, privacy, and inter-domain policy synchronization (Rahman et al., 2022). In BlockSDN-VC, the principal questions are propagation latency, path stretch, churn response, and robustness against coordinate manipulation (Jia et al., 30 Sep 2025).

This suggests that BlockSDN-VC is best understood as an SDN-assisted overlay-broadcast mechanism for blockchain networks already operating in controllable network environments such as datacenters or ISP settings, rather than as a general-purpose redesign of blockchain consensus. Its reported compatibility with unmodified clients and its placement of logic in an SDN app or proxy reinforce that interpretation. In that sense, the framework exemplifies a specific BC-SDN pattern: using centralized network observability to recover global consistency in a component—virtual-coordinate dissemination—that is otherwise slow, locally inconsistent, and attack-sensitive when implemented in a decentralized manner (Jia et al., 30 Sep 2025).