An Experience Report on the Design and Implementation of an Ad-hoc Blockchain Platform for Tactical Edge Applications

Editor's Notes

• #2: Presentation outline: Industry context and challenges Industry-Academia joint developed solution: Ad-hoc Blockchain Platform Industry case study and preliminary results Lessons learned
• #3: The industry context of the project is trustworthy processing and exchange of tactical information within a tactical edge environment, where tactical edge operations take place.  Tactical edge environments are characterized by dynamic and uncertainty, where participants have high-stress level and limited attention.  Tactical edge environment also presents networking challenge (so called "DDIL": Denied, Degraded, Intermittent, and Limited (bandwidth)) An example of tactical edge operation that we targeted in our project was coastal search and rescue operations.
• #4: Mission success of tactical edge operations mentioned above depends on the ability to access, process, and exchange tactical information of mission participants (e.g., deployed rescuers, forward-deployed command and control center).  Nowadays, software systems and computer networks are utilised more and more for information related purposes. In our context, this combination of computer systems and networks is called "tactical edge infrastructure" The figure shows an exemplary tactical edge infrastructure. The hardware nodes are organised into three types according to MITRE's tactical edge characterisation framework. These nodes (from the least to most resourceful) are "dismounted systems", "mobile center", and "fixed center" Dismounted systems, such as drones and mobile phones, are generally assigned to mission participants (e.g., rescuers) to provide them access to the necessary information and services to carry out there mission. For instance, the TEXAS system deployed on an Android phone forms a "dismounted system". Dismounted systems can form a cluster around a mobile center. A task group might have multiple clusters, each of which covers a group of mission participants (e.g., a platoon).  Here, we can draw parallel between tactical edge and usual edge computing paradigm: "dismounted systems" align with edge computing devices like Raspberri Pi, "mobile center" aligns with fog computing nodes, and "fixed center" aligns with cloud.
• #5: Tactical edge operation might by jointly conducted by multiple task groups from different chains of command (e.g., surf life saving, police, ambulance). These task groups brings their own tactical edge infrastructure. The challenge here is how to enable the exchange and joint processing of information across these infrastructure. An example use case is Dynamic Reference Information (also known as Dynamic Mission Data), which is about the maintenance and real-time update of a library of reference information about entities and environment of a mission. For example, the characteristics and features of a missing boat are reference information that could be updated throughout a mission, based on the input from participant. Such inputs can come from different task groups (e.g., surf life saving supplies the initial information, police might gather more information during the mission, these should be integrated and propagated across participants to improve the effectiveness of their search and rescue operation). The current solution is relying on a centralised information plane to connect the task groups and run the logic for use cases such as dynamic reference information. It is not a good solution because of three issues that I’ll mention a little later.
• #6: Another challenge is the extensibilty and adaptability of the software utilised for the exchange and processing of tactical edge information (i.e., the one that lives within the centralised information plane described in the previous slide). In our context, we call this type of software application as "tactical edge information application". Because missions differ from each other, and information needs and authorization level varies between mission participants, it's clear that we need the ability to adapt the suite of tactical edge information application to mission contexts. We also need the ability to extend that suite of application to support emerging, unplanned contexts in the future.  In other words, we need a platform rather than a one-off application. 
• #7: The goal of this project is to address the challenges above. The main idea is to build a decentralised (to address the first challenge) software platform (to address the second challenge). The next section describes the requirements and architecture of this platform.
• #9: Requirements are self explanatory. They are extracted from the characteristics of the tactical edge and the challenges mentioned above.
• #10: Our architectural design solution for each and every of the identified requirements.  In particular, we use P2P architectural style along with the blockchain technology as the software connector to realise decentralisation. We place this P2P platform directly within tactical edge.  The blockchain provides a layer of guarantee on the security and fault tolerance of the information exchange. Via blockchain's smart contract, we can also have provenance (i.e., record) about the processing and decisions (e.g., when a smart contract is used to control the update of a reference information library, we have record of how the smart contract reached the decision. Such record is embedded inside the distributed ledger itself) One of the challenge of blockchain is dealing with large data. We leverage the off-chain data storage pattern for this purpose. In particular, our platform can automatically offload heavy data payload to an off-chain storage, such as a local database or even peer-to-peer storage solutions like IPFS, and store the cryptographic hash of the data on the blockchain. This way, we can verify that the off-chain data has not been modified, whilst storing only very small hash on the blockchain. Finally, to achieve interoperability, we leverage a combination of service oriented architecture and microkernel architecture.
• #11: Conceptual view of the platform.  As you can see, every task group members host a blockchain node (either full or lightweight, depending on their resource and authorisation level).  They also run a software client called "platform node". These nodes connect to each other via the blockchain. It means that if they want to broadcast relevant tactical information, they will do so via the underlying blockchain and they access the said blockchain via a local blockchain node that they trust.  The platform nodes are also responsible for abstracting the blockchain layer. Upon this abstraction layer, services such as data storage, information processing, coordination (i.e., voting) can be established. Finally, tactical edge information appications such as dynamic reference information can be implemented. One thing to notice is that despite the logical centralisation of the service (meaning the application just interact with, say, "joint data storage" service, rather than "service on node 1"), the physical deployment of both the service and the applcation is decentralised. It means that on every platform node, there are a full (or partial) suite of services and replica of the application. It means that at any point, a user would interact with their local instance or application, service, and platform. Thanks to the blockchain, the whole stack appears to user as a logically centralised entity, whilst it is actually spread across everyone in the network.
• #12: This is the physical view of the platform. It provides a simpler and more clearer view.  The key point here is that we do not care about the underlying computer network layer, whether it is 5G, tactical data link, mesh, optical, etc. The only thing we see is the network performance characteristics (e.g., bandwidth, speed, jitter).  On top of such computer network, an ad-hoc blockchain network is deployed. It means that the transactions and other house-keeping information exchange of the blockchain, and thus its performance, depends on the performance characteristics of the underlying computer network. The platform is deployed on top of the blockchain. It means that the performance of the platform depends on the performance of the underlying blockchain network. 
• #13: This view shows the software modules within each platform node. It also shows where the tactical edge applcation such as DRI exists.  It means that we are not replacing C2 dashboard or Edge AI tactical edge applications that tactical edge actors use, but any step that involves retrieving or updating the shared tactical edge information would be outsourced to the ad-hoc blockchain platform node instead. 
• #14: The kernel is same across every platform node. The application space changes, depending on the type of application that is available on a platform node.  The wallet service encapsulates a blockchain client and a wallet, providing the ability to query a blockchain and submit transactions.  The storage service encapsulates data payload stores (e.g., IPFS client or local storage) and implements the secure offloading process for large data payloads (Section 3.2). The Cache service provides the ability to cache on-blockchain records and data payloads. We introduced the cache service to the platform because we found that the read latency from a blockchain, specifically from an Ethereum-based blockchain via the Go-Ethereum, was high and impeded the user experience from the graphical user interface at the application layer. Both layers comprise software services for interoperability.
• #15: A detailed look at the tactical edge information application. Noted that it has smart contracts (e.g., to implement the update of a reference information library), an application service (e.g., to expose REST API for invoking the smart contracts to update the reference information libirary), and an extensible suite of application client (e.g., mobile app that allows users to report new reference information update).
• #16: After analyzing the project logs, we developed the following process to assist developers in designing and developing applications for the platform.  Key thing to consider is that not every application benefits from running on the tactical edge platform. Only the part of the system that requires exchanging and updating JOINT / SHARED information should be on the platform (because blockchain is a scarce resource). After knowing which part of the data is JOINT / SHARED information, we can model the life cycle of such information as a state machine, whose state changes depending on the action of participants. Those states can be readily mapped onto smart contract variables, and state transitions (actions) can be mapped onto smart contract functions. We introduced this idea in the ProML paper. After having the smart contract, we develop application services to wrap the smart contracts, and provide new software clients if necessary.
• #17: Now that we have covered the architecture of the platform, and the architecture and development process of applications living on the platform, the last question is "how are we going to deploy the platform and application in a mission" Our approach involves a bootstrapping phase before the mission commencement, done by IT operators, ideally from all participating task groups. This process involves determining the architecture of the blockchain network (i.e., what platform / technology, who has full node, who has light weight node, who does the mining, etc.) After having the network architecture, the next step is deploy it. NVAL can help. Next, we deploy the kernel service layers Finally, we deploy the application suite. The content of this suite varies depending on the mission and even concrete participants. For example, only users having authority to update the reference information library has access to the DRI application. 
• #19: (RISE) initiative [4]: test and explore information management, exploitation, and exchange technologies in a field experiment setting. Self-explanatory.
• #20: (RISE) initiative [4]: test and explore information management, exploitation, and exchange technologies in a field experiment setting. The implementation of the use case that we have been discussing in the whole presentation.
• #21: Class diagram showing smart contract back end. Sequence diagram showing the exchange of messages between these contracts. Agent in this case is a mission participant who submits the information update.
• #22: We use this web interface to input the RI update on behalf of the mission participant during the experiment. This interface also serves as admin interface to review all the RI updates and track the status of individual object of interest
• #23: Initially, we had planned to deploy the nodes directly on designated computers and connect them via cellular network links using a virtual private network. However, we had to switch to a fall-back configuration due to weather conditions and technical challenges. As a result, all four nodes were deployed on separate cloud-based virtual machines connected via a VPN. The designated computers could control their corresponding platform nodes through a 4G uplink. Example of updates: an event such as ’Jet Ski 1 pulling the lost inflatable back to the beach to treat the patient’ would involve describing the inflatable, patient details, rescue craft and crew status, and the time associated with each action in the situation. Before each experiment, participants were assigned roles as observers and processors, which were also documented in the RI updates.
• #26: We highlight the potential of leveraging blockchain network architecture as a mean to achieve quality attribute requirements on the application layer. 
• #27: Essentially, if the system is fully decentralised, it would be difficult to govern and even set up. If we make it easy to govern and setup, we might sacrifice decentralisation. Our solution is introducing a centralised bootstrapping phase to setup the platform, but then allow the platform to operate and evolve in a decentralised manner. A future research is how to decentralise this bootstrapping phase as well.