Putting Blockchain (+Lightning) To Work: Swarming Systems

“Vision without action is useless. But action without vision does not know where to go or why to go there. Vision is absolutely necessary to guide and motivate action. More than that, vision, when widely shared and firmly kept in sight, brings into being new systems.” ~ Donella Meadows

This article is not another online blockchain hype story. By now, we understand that blockchain is not the revolution, it is its herald. Practically, that means that we who have already pressed the blockchain I believe button should take the lead in creating new blockchain usage cases. As blockchain advocates, how do we do that? The answers are important because it’s easier to say, than do. My take is that reflecting on potential blockchain application in one’s respective career field is likely the best conceptualization method and most fruitful path to producing credible use cases — the things we need in blockchain’s adoption across diverse sectors of the economy.

This essay looks at a usage case that integrates blockchain technologies with robotic swarming systems. Governments and militaries would likely be most interested in the combination of blockchain and swarming systems, but honestly, I’ve chosen to tread lightly on the militaristic content. While this article specifically mentions robotic swarms, I believe blockchain has utility in parallel areas, such as unmanned aircraft operation and the teaming of manned and unmanned aircraft. However, those use cases require more thought and even more writing space. Because I want to spend more time on applied blockchain, I will allocate no time toward teaching blockchain.

Here we go…

Swarming Systems, Concisely

Swarming systems are a multi-disciplinary, science driven approach to organized behavior. At bottom, robotic swarms are groups of locally interacting devices with common goals that engage in a range of collective behavior. However, the it of organic swarms, the mechanism from which the utility of robotic swarming arises, is the process of self-organization that allows a pattern of behavior for an entire organic swarm to emerge. Producing robotic swarms is less about elaborate programming of intricate behavior of each device within a robotic swarm, and more the simple rules of device-device interaction. As an illustration of the simplicity at work within organic swarms, there are typically three movement rules at work:

  1. Move in the same direction
  2. Remain close
  3. Do not hit a creature

Out of that elegant simplicity arises emergence, new behaviors produced by an aggregation of simple behaviors within simple interactions on a population level scale. Organic swarms follow simple rules without centralized control thus tending to optimize movement. Much contemporary swarming research and development effort is directed at coding nature’s swarming rules into machine behavior of swarm devices. Blockchain technology does not code swarm behavior; it can enable it.

One of the most intriguing aspects of swarms is that they can develop an interesting property, swarm intelligence. Organic swarming creatures such as birds, fish, and locusts don’t experience an enhanced intellect because they are swarming. These creatures aren’t smarter because they swarm nor, when they swarm. Instead, what is meant by swarm intelligence is something more basic. Collective problem solving is attained by the swarming tendency of social animals and insects. The implication is that swarming creatures in proximity to others leads to unique group adaptive behavior otherwise absent when creatures are not in a swarm state — observable schooling or flocking behavior. Swarm intelligence points back to the sophistication of the self-organization algorithms and mimicry at work in organic creatures.

The reasons to employ swarming systems outside of nature are not theoretical but rooted in practicality. Robotic swarms allow human operators to free themselves from direct, hands-on control of swarm systems — to evolve from man-in-the-loop to man-near and ultimately off-the-loop. This evolution in turn, allows more to be accomplished by a single operator but it also leads to another possibility: a reduction in the probabilistic incidence of U.S. military casualties. By extension, this reasoning applies to the risks tied to the use of expensive manned and unmanned platforms. Such risk points to another constraint: economics; specifically, cost. The economics of advanced aircraft for example are plottable on various acquisition/replacement cost curves each with dramatically increasing upward trajectory with the introduction of each new model or generation. In contrast, robotic swarms — guaranteed to increase in cost, need not ever approach the high capitalization economics and unit costs of advanced manned aircraft. Setting aside the economic attractiveness of swarms, the compactness and feasibility of use in every setting you could imagine outside of the cyber domain, make robotic swarms a capability with tremendous utility.

Big Idea: Integrating Swarms and Blockchain

“It is said that necessity is of the mother of invention. In practice, invention is expensive and time consuming. Alternatively, need is the father of adoption; frequently a less expensive, more rapid path to the objective.” ~ Author

Blockchain promotes a swarm’s global awareness not as a communication (waveform) technology — it’s not, but through its ledgers of data storage method. The swarm’s ledgers — lodged within each robotic swarm device — record the data that tells the story of the swarm’s operating experience baseline for every moment after it awakens to operate. The value added here is data recorded and data pushed to every swarm device to enable a consensus swarm sense of the environment. That consensus sense is the basis for unified behavior of every device in a swarm.

Another way to think about this is that each swarm is essentially a micro peer to peer network where its sensemaking combines with pre-programmed instructions and internal AI routines to enable a rudimentary sort of robotic learning. The learning is an important outcome; however, the objective of swarm learning is sufficient sense to enable safe swarm system autonomy. Greater effectiveness results when swarms publish their environmental sensemaking with other swarms, including manned, and unmanned platforms. Data collected by all manner of platforms will enrich common operating pictures and intelligence mosaics. However, the greatest benefit of blockchain integration to a swarm system is its enhanced survival, efficiency, and effectiveness.

Figure 1 is a simplified taxonomy of increasing levels of swarm automation. Note that the lowest LOA, manual operation is humans flying the swarm — providing full-time flight commands. In contrast, the highest LOA is full autonomy where the swarm operates fully independent of human command. Progressing from manual operation to full autonomy, the human-swarm interaction decreases while swarm independence increases. Manual operation is man-in-the-loop while the human moves incrementally farther from direct control; ultimately, to man-off-the-loop at swarm full autonomy. Blockchain enables the entire LOA range through elevated swarm awareness and something akin to rapidly accumulated agent memory fueled by the constant inflow of ledger stored data processed by pre-existing deep learning and situational rapid learning, both federated throughout the swarm.

Swarm communication links (wi-fi, LAN, etc.) do not scale easily with large swarms and/or multiple swarms. Furthermore, at higher LOAs, operator remoteness (man-off-the-loop distance) benefits from specifically designed data waveforms to reduce latency that enables timely operational inputs and outputs. Because of the possibility of disrupted communication links with robotic swarms, a workaround has been to designate certain swarm devices to perform the role of that swarm’s data synchronizer — a swarm leader. However, blockchain’s ledger ensures that all devices possess the same swarm data picture eliminating the need for a swarm leader role — it becomes one less exploitable swarm vulnerability.

One example of enhanced efficiency not discussed so far is a swarm’s operating transition from one state to another. As noted earlier, swarming is complex behavior based on simple rules; however, it is the timing of the invocation of a given rule that in turn controls the timing of state transitions. As shown in Figure 2, organic swarms shift, sometimes rapidly through one of four states: translating, ring, hybrid, or rotating. Computed consensus, aided by device memory capacity and constantly building global awareness — rather than the simple rules observed in nature, could become the basis for a robotic swarm’s more efficient transition state. Thus, machine swarm transition states, initially slower in the swarm’s opening moments of operation than what is commonly observed in bird murmuration or fish schooling, can be outcomes of deliberate swarm thinking rather than reactive thinking to a rapid onset event.

The takeaway is that the data stored in the robotic swarm’s data ledgers forms a record not only of collected data but a shared pool of data that informs learning within each device. But the learning is not automatic nor does Lightning technology (discussed below) confer learning. Instead, the swarm’s consensus data is used by the decision-making and behavioral algorithmic in each swarm device. As those algorithmic process data inputs, a key output is when it is appropriate for that device and the ones around it to transition to a situationally more ideal machine swarm state. The device data ledgers perform another vital function, they prevent swarm disorder by monitoring for indications of random agent phase transition that itself is a common reaction in organic swarm behavior to a rapid-onset event. In other words, the distributed data can prevent a descent into chaotic robot swarm motion that depletes device power levels and shortens the swarm’s operating life.

Data ledgers can also work to mitigate the potential for machine data saturation that would prevent timely swarm phase transitions or in a worst-case scenario, degrade, disrupt, and disable the robotic swarm. Rather than the paralysis or saturation that comes with every device sending its own signal to an external operator, the machine swarm does not exclusively rely on what a few swarm devices see, but a consensus view. This goes hand in hand with time-delay effects that can cause swarm instability. The Lightning protocol (below) could mitigate the disruptive effect of time delay by cross-tying individual agent AI motion signals to aid the rapid formation of consensus robotic swarm motion that accelerates as the swarm accumulates more operating experience (memory via federated data).

How could the integration of swarming and blockchain be accomplished? While blockchain’s lack of a trust management requirement changes the structure of networks, the blockchain 1.0 technology that underlies Bitcoin suffers from a limitation that can undercut swarm system flexibility: scalability. Here is an illustration of that limitation: each Bitcoin (blockchain 1.0) block is ~ 1.6 GB that in turn produces an annual Bitcoin ecosystem data output of ~ 87 TB that points to a problem. If every person in the U.S. and Europe had access to Bitcoin and conducted just four Bitcoin transactions daily, each transaction block would increase to ~ 6 GB while yielding ~ 1 TB/daily; 365 TB annually. Could that much data be produced in a network that is connected to robotic swarms? Perhaps, and to work with that memory volume would increase swarm device cost and hamper flexibility. Another technological approach is necessary, one that eases memory demand but does not throw out the blockchain (+ Lightning) baby with its beneficial bath water. An alternative exists.

In late 2012, a pair of German researchers published an academic paper on what would later become known as the payments channel concept. Several years later their foundational work yielded a new blockchain variant known as the Lightning Network. Lightning is a direct sender to receiver linkage that speeds up the message rate nearly two orders of magnitude from blockchain 1.0’s (Bitcoin’s) ten-minute verification cycle. Lightning’s performance overcomes another significant blockchain 1.0 limitation for some use cases: latency. Practically speaking, in networks using Lightning, most transactions do not make it to the main blockchain. Lightning’s direct, off-the-main-chain connections are best thought of as channels. Lightning’s logic encodes any object; image, text, full motion video, etc. Each object is encoded in a 256-bit length hash expression along with a paired code. The paired code is what the final terminal recipient possesses to decode the hash sequence to see the data payload (object) in its native form.

Lightning’s channels can be single-use, limited use, or ongoing use. Moreover, the Lightning protocol contains coding that enables multi-hop paths of data exchange — the very feature needed to send/receive data to and from swarms. The memory requirements of Lightning protocol data transactions are a fraction of the size of blockchain’s average data block size. For example, a typical Lightning data channel block is ~ 135 MB — an order magnitude smaller and more consistent with the likely memory and computation throughput constraints of swarm devices and other power limited tactical computing machines.

Lightning’s coding structure is explained in “The Bitcoin Lightning Network: Scalable Off-Chain Instant Payments,” published in 2016. Space here does not permit detailed discussion of the coding and logic that allows Lightning to create random or specified paths from senders to receivers. However, there are two points to bear in mind: first, Lightning could run on the same network infrastructure running blockchain but would not interfere with main chain transactions because of differences in data block message headers that cause the blockchain machines to disregard a Lightning data block, and vice versa. Second, in field application, human-robotic swarm interface would primarily utilize Lightning. In the specific matter of swarm collected data, the multi-hop feature of Lightning enables users to access and download data while allowing for control commands to the swarm consistent with that swarm’s mission level of autonomy.

As with nearly all forward thinking technological concepts, people will ask for a description of the artificial intelligence (AI) within robotic swarms and how that AI is to be used? Stepping outside of this conversation for a moment, AI conversation writ large must shift from faddish preoccupation to the concrete: what is AI to do, why, and how? So, in a vision that integrates swarm and blockchain, AI needs a few unsexy things like a data collection structure — blockchain can be that structure. The requirement for such structure is seen in the upstream requirement for a data foundation before AI and machine learning can generate meaningful behavior at the device level. The next thing that Lightning would do with machine swarm collected data is federate it among all devices. AI can perform another vital function — data cleaning; algorithms embedded within swarm devices sanity checking their collected data before transmitting it to the swarm. When all these processes are complete, the robotic swarm — even if operating autonomously and more importantly if it is — could sum its environmental sense-making plus its decision-making algorithm outputs to identify, attain consensus, then implement ideal swarm behavior in a given situation. However, the most important statement about AI in this concept has little to do with blockchain (and Lightning) but everything to do with what Andrew Ng terms the upcoming split in machine deep learning; a form of learning that blockchain integrated swarms must assimilate. To interpret Andrew’s work then place it within this article, swarms enabled by Lightning could utilize a variant of AI that does not stress deep, narrow intelligence; rather, adaptable automation common to swarms in nature.

Organic swarms are self-organizing systems whose key attribute are abilities to exhibit emergent behavior. In a complex sense, to further foster emergence in robotic swarm behavior — giving it the ability to self-organize, even innovate — AI should liberate the machine swarm from the constraints of swarm leader/follower models to open up higher levels of autonomy behavior. Swarming activities that benefit from AI and Lightning include robotic swarm protection through improved vigilance, diluted probability of attack, and orchestrated maneuvering defense. In fact, the ability of machine swarms to saturate even the most sophisticated defenses with hundreds, perhaps thousands of entities, may be the most effective way of mitigating the threat they pose to many other unmanned and manned systems.

All of this brings us to a robotic swarm’s final moments; as the swarm’s machine devices begin to go dark. The swarm generates a final data block based on internal device clocks; the device’s mortality block. The mortality block signals the demise of that robotic swarm’s tactical life, provides a signoff to any networks it is subscribed, shares the swarm’s last collected data block, and offers that final block to other aircraft and machine swarms still in the air, on the land, or under water.

Blockchain + Swarming Systems. What Got Better?

“The present has been colonized by the future.” ~ Anon.

Integrating blockchain and Lightning technologies with machine swarming systems could cultivate a range of advantages not limited to: 1) global awareness that promotes real-time emergence and adaptation, 2) coherence in machine swarm automation, and 3) a tamper-proof data distribution protocol. This essay’s vision is that robotic swarming systems powered by blockchain and Lightning could produce a new pivot point for governments, the U.S. military, etc. by first bridging then blurring some of the traditional lines that delineate the boundaries between air, land, sea, space, and cyberspace. What could swarms do better with embedded blockchain and Lightning technology? Missions such as surveillance, reconnaissance, intelligence gathering, or sensor relay that are currently accomplished by other things.

There’s probably one more thing that I ought to mention: the perception that this article militarizes blockchain or Lightning. I could be wrong, but I don’t see that. Here, blockchain and Lightning are being no more militarized than computers. Like data writ large, I see blockchain and Lightning as ideas that can and should be used in many places, ways. But, I respectfully acknowledge the question of technology’s purpose is valid and should be asked.

In closing, this was a concept to integrate blockchain, Lightning, and machine swarming systems. This article was not a set of assembly instructions nor a thorough airing of every idea that needs to be considered to use blockchain in this way. For blockchain including Lightning to grow more, we’ve got to carve out the usage cases. Not every case will be executable; that’s not the point. Blockchain advocates must pitch ideas — more of them, to see what sticks and become tomorrow’s breakout concept.

Leave a comment if you have a question, idea, or criticism.

And, please leave a clap. Thanks!