A connected factory floor doesn’t wait. A sensor picks up a temperature spike in a reactor. The control system needs to know about it immediately. Within milliseconds, not seconds. Yet the moment you try to use blockchain to lock down and verify that reading across a network of devices, something weird happens. The system itself becomes your problem.
This is the frustrating reality at the heart of the Internet of Things. Blockchain sounds brilliant on paper: absolute security through decentralisation. Instead of trusting one authority, you spread trust across a network of computers that all verify and record every transaction. Clean, elegant. But try connecting dozens of IoT devices through it and something goes wrong. The network just hiccups. Data that should move at light speed crawls. A reading that needs verifying in 50 milliseconds takes 500. Sometimes a whole second. That’s basically forever when you’re dealing with industrial systems.
Most engineers blamed the blockchain protocol. Too complex, they said. Too demanding for devices that barely have enough juice to run. But that’s not where the real problem was hiding. A research team at Chiba University in Japan, led by Kien Nguyen, found something more interesting and actually fixable: the blockchain itself isn’t the culprit. It’s the network topology. That invisible architecture of how the devices hook up to one another.
Here’s how it works. When an Ethereum node wants to send out a transaction, it doesn’t just blast it to every other node. That’d be mayhem. Instead it sends the full data to a small group of peers and just tells everyone else it exists. The problem sits in who gets picked as that group. In standard Ethereum it’s pretty much a coin flip. Random. A node just grabs neighbours more or less at random. Stick dozens of devices in there and the randomness creates a mess. Device A talks to B and C. Then B and C each talk to more nodes. Messages spread out, split apart, multiply exponentially. The same transaction bounces around the queue multiple times. Everything backs up.
“We aimed to bridge the gap between theoretical design and practical deployment of IoT-blockchain systems by identifying the fundamental causes of their high latency,” Nguyen explains. His team didn’t just point out the problem. They actually fixed it by rethinking how networks pick their peers.
The fix is called Dual Perigee, and it’s surprisingly straightforward. Instead of random connections, each node keeps an eye on its neighbours and grades them. How quickly do they actually get transactions through? How fast do they push out full blocks? Slow neighbours get marked as sluggish. Fast ones stay in the good books. Every few minutes, each node ditches its worst performers and tries new random neighbours. Eventually the network sorts itself into a speedy setup with nobody needing to boss anyone else around.
What’s really clever is how light it stays. Dual Perigee doesn’t need to know the whole network layout. It doesn’t demand loads of complex maths from every node. It just quietly watches timestamps of data already flowing through. A node noting when a transaction showed up is basically free overhead. But somehow this quiet observation, pooled across the network, creates this feedback loop that keeps improving the topology all by itself.
They put it through its paces on a simulated 50-node IoT network running Ethereum’s Proof-of-Authority consensus. The numbers were impressive. Block propagation latency (how long for a verified bundle of transactions to reach every node) dropped roughly in half. Compared to what Ethereum does by default, Dual Perigee shaved delays down by 48.54 per cent. It also beat the previous best option, original Perigee, by another 23 per cent by actually paying attention to blocks too, not just individual transactions.
But the real story isn’t in the numbers. It’s what they actually mean about how to design networks. The team tried out different theoretical topologies: Erdős-Rényi random networks, scale-free Barabási-Albert networks with hub nodes, and Random-Regular networks where every node has the same number of connections. Logically one of them should win. You’d think fully connected networks would do best, fewer hops. Maybe the scale-free ones with their natural hubs. Or the regular ones for balanced load.
None of them consistently won. That’s the paradox that made Dual Perigee necessary. A static topology just doesn’t work because real networks don’t stay static. They’re messy. Some devices are faster, some links get clogged, some sit where there’s more traffic. A topology that looks perfect when things are quiet falls apart the moment someone fires up heavy transaction traffic. Worse, different devices sitting in different physical spots basically experience different topologies. What works beautifully for one part of the network might be terrible for another.
That’s where adaptive peer selection gets interesting. Instead of betting on some ideal layout that’ll never quite fit reality, Dual Perigee lets each node keep tweaking. It’s almost like watching a network learn what works. It bends itself around the actual constraints of the physical world instead of fighting against them.
The implications spread everywhere. Smart cities want blockchain for their sensor networks. Hospitals need immutable records of device readings. Factories are moving toward cryptographic verification at every step of the supply chain. Driverless cars will be swapping safety data across wireless meshes. All these applications share a single requirement: they absolutely cannot tolerate the kinds of delays that plague blockchain-IoT integration right now.
“The proposed decentralized latency-aware peer-selection mechanism can serve as a foundation for future blockchain platforms that support real-time, mission-critical IoT services,” Nguyen says, “ultimately enabling more secure, responsive, and trustworthy digital infrastructures.” In other words, blockchain stops dragging everything down and actually becomes useful. A temperature sensor in a factory, a vital signs monitor in a hospital ward, a camera on a self-driving car. All of them could be logging live data onto a distributed ledger instantly.
The research shows there’s a path. Dual Perigee works because it’s lightweight enough for budget-constrained hardware. No special equipment needed, no central boss, nothing that demands global network knowledge. Every node just watches what it sees and makes its own calls. Then somehow all those individual decisions add up to a system that optimises itself. It’s a tiny glimpse of something bigger: maybe the smartest way to build flexible, resilient networks isn’t to blueprint them from above, but to give each part decent local information and let it figure things out.
They tested the approach on a 50-node emulated network in a tidy lab setup. But getting it working in the real world will be messier. Wireless interference messing things up. Devices appearing and vanishing as people move them around. Hardware all over the map in terms of processing power. That said, the fact it only needs basic measurements and simple maths is encouraging. Suggests it could actually scale.
One thought lingers: how did researchers miss this for so long? Years went into optimising consensus algorithms, trying to make the maths faster. The actual problem, though, was sitting right below that in the network topology, totally invisible until someone stopped and actually looked. It’s a reminder that sometimes the biggest solutions are hiding in plain sight. You just need someone stubborn enough to ask a simple question about how things really work.
That factory floor reactor is getting closer to real-time verification. The whole promise of blockchain—absolute, verifiable trust woven through a network—finally has a shot at keeping up with what’s actually needed. Systems that can’t afford to wait won’t have to.
Study link: https://ieeexplore.ieee.org/document/11301849
ScienceBlog.com has no paywalls, no sponsored content, and no agenda beyond getting the science right. Every story here is written to inform, not to impress an advertiser or push a point of view.
Good science journalism takes time — reading the papers, checking the claims, finding researchers who can put findings in context. We do that work because we think it matters.
If you find this site useful, consider supporting it with a donation. Even a few dollars a month helps keep the coverage independent and free for everyone.