Blockchain addresses existing asset management problems in the aviation industry (Part 2 of 3)

Our series of Marketplace Spotlight articles focus on the partners making the Yocova platform come alive and the digital aviation solutions they provide. Here we hear from Yocova partner Block Aero in the second article of their Blockchain series, and how they are making a difference in aviation.

 

Part 2: Deep dive into blockchain concepts and their practical application

In aviation industry considerable financial and human resources are allocated to managing the state and status of assets—configurations, next-due maintenance actions, certification processes, lease return checks, etc — yet because these actions often disseminate across a variety of business functions, these processes are rarely accomplished within the bounds of a single organizational entity.

Current systems, while safe and rational at a macro level, are far from efficient in reality — and have certain vulnerabilities when it comes to protecting the integrity of aircraft maintenance and associated supply-chain records.

This has driven civil aviation authorities (such as ICAO, IATA, and prominent airlines and OEMs), to begin investing time and capital into figuring out how best they can unlock the potential value blockchain technology can bring to the industry.

While exchanging data using common protocols and standards certainly helps, service contracts do not necessarily provide insights into the business processes hidden behind the contracts operated via remote systems. A request might be valid according to the contract, but invalid depending on the business processes’ current state. That means that if a formal transaction is to be conducted between multiple parties, precise correlation is required (i.e. everyone has to achieve the same state of transaction simultaneously) for values to change, and for the transaction to be completed successfully.

A prerequisite for the proper functioning of such a multi-party interaction is the absolute transparency of the process and live status reporting. It is for this reason that blockchain technology has such great appeal in managing diverse yet interdependent processes among multiple parties.

Node

A node is one of many internet-connected computers that runs the software of a blockchain network to validate transactions. When a new block is added to the chain, a node synchronizes the state of the shared ledger with all other nodes.

There are many types of nodes depending on the specific blockchain framework, but you could simplify this concept into two categories, full and light nodes:

1) Full nodes run most of the time, maintaining a copy of the shared ledger, and contribute to the stability and security of the network

2) Light nodes do not maintain their own record of the ledger, but actually store cryptographic keys that access their own accounts of value and propose transactions. Light nodes must connect to a full node before being able to interact with a blockchain

Transaction

Transactions are the smallest units in a blockchain system.

They contain data parameters that propose changes to the state of the assets recorded on the ledger. If the transactions are validated and endorsed by the nodes on the network, they are written into a new block. Otherwise, the transaction is rejected.

Block

Each block contains two types of information:

1) Application-specific information that records transactions or smart contracts with a combination of data and code executable by the nodes

2) Block header information that contains the metadata to help verify the consensus validity and context of the block within the overall chain

Distributed Ledger

Executed transactions are bundled into a chronological sequence of linked blocks where each block contains a hash of the previous block, thus giving the data structure of a blockchain its immutable characteristics. (A ‘hash’ is a function that meets the encrypted demands needed to solve for a blockchain computation)

Distributed ledgers can be considered as synchronized databases representing the current world state of all assets on a network as programmatically agreed by its participating nodes running the same consensus protocol.

Smart Contracts/Chain-Code

Smart contracts are executed by Virtual Machines (VM) or containers embedded in each node, to ensure a deterministic outcome complies with a set of encoded rules. The rules confirm that proposed transactions comply with the application-specific functionality.

In the case of virtual currency payment, a transaction must adhere to the required parameter structure (e.g. address recipient, amount) and the payer must have ownership of the virtual currency coins they want to send.

As blockchain technology has evolved, these rules could become more complex than a simple account balance reconciliation.

For example, a transaction to set the parent asset of an aircraft to an engine might be invalid as codified in the rules of an aviation blockchain — for the simple, yet perfectly logical, reason that whilst engines can be installed on aircraft, aircraft cannot be installed onto engines.

Distributed consensus (i.e. a formalised Endorsement Policy) orchestrates and validates each key state of a replicated program execution. It provides the run-time environment for verifying the outputs of the same program on decentralized nodes. Therefore, blockchain networks are also perceived as a distributed Virtual Machines (VM), and this is why a Turing Complete Protocol like that of Ethereum is called a world computer.

Consensus Algorithms

There are different kinds of consensus algorithms that provide the means through which blocks with valid transactions are propagated to the entire network. Some notable methods include:

  • Proof of Work – Node operators solve complex cryptographic puzzles for which they receive rewards in the form of coins or tokens. This is the mechanism employed by the Bitcoin blockchain and is very energy intensive
  • Proof of Stake – Node operators stake coins or tokens and receive a reward if the block is valid — conversely they are penalized by losing the stake if the block contains fraudulent transactions
  • Proof of Authority – Trustworthy validators are pre-approved and selected by network participants to act as moderators of the system. As the number of validator nodes is limited, this also makes network performance for these types of consensus algorithms highly scalable and more suitable for private, permissioned blockchains
  • Raft – A Raft is a consensus algorithm that is designed to be easy to understand. The running process of the Raft algorithm resembles an election. Specifically, each node can become a ‘candidate’ that needs to convince most voters to vote for it. Once more than half of the voters support it, it becomes the leader. Each node in the RAFT algorithm can be a candidate that sends requests to other followers. If the candidate receives more than half of the followers’ responses, the election is successful, and the candidate becomes a leader. Meanwhile, a log is copied to the followers. If the leader node is lost or goes down, the election will be replayed in accordance with the previous steps

Consensus mechanisms generally strive to achieve the following:

  • Fault tolerance — Decentralized systems should be less likely to fail accidentally because of the built-in redundancy
  • Attack resistance— Decentralized systems should be more ‘expensive’ to attack, destroy, or manipulate because they lack sensitive central points that can be attacked at a lower cost than the economic size of the surrounding system
  • Collusion resistance — It should be much harder for participants in a decentralized system to collude and act in ways that benefit them at the expense of other participants.

However, the resilience of a blockchain system design is usually determined by its ability to deliver balanced centralization and fault tolerance with latency, throughput, and overall performance

Oracles

A blockchain oracle is secure middleware that facilitates communication between blockchains and any off-chain system — such as data providers, web APIs, enterprise backends, cloud providers, IoT devices, e-signatures, payment systems, other blockchains, and more.

Oracles must operate both on and off the blockchain simultaneously. The on-chain component is for establishing a blockchain connection (to listen for requests), broadcasting data, sending proofs, extracting blockchain data, and sometimes performing computation on the blockchain. The off-chain component is for processing requests, retrieving and formatting external data, sending blockchain data to external systems, and potentially performing computation in more advanced oracle networks.

The main distinction between public and private blockchains is related to who can participate in the network, execute the consensus protocol and maintain the shared ledger.

Many blockchain variants have evolved over the years, and the terminology is often misconstrued. This is easy to do because public and private blockchain have many similarities:

  • Both are decentralized peer-to-peer networks, where each participant maintains a replicated copy of a shared append-only ledger of digitally signed transactions
  • Both maintain the ledgers in sync through a protocol referred to as consensus
  • Both provide certain guarantees on the immutability of the ledger, even when some participants are faulty or malicious

Public Blockchains

A public blockchain network is completely open, and anyone can join and participate in the network as a full node. These participants can also be anonymous. The network typically has an incentivizing mechanism to encourage more participants to join the network. Bitcoin and Ethereum are the two largest public blockchain networks in production today.

Private Blockchains

A private blockchain network requires participants to have known identities and must be validated by either the network operator or by a set of rules put in place by the network operator.

Businesses who use a private blockchain, will generally set up a permissioned network. This places restrictions on who can participate in the network, and in which types of transactions. In essence participants need permission to join. The access control mechanism can vary—existing participants could decide future entrants; an authority or authorities could issue licenses; or a consortium could make the decisions instead.

Once an entity has joined the network, it will play a role in maintaining the blockchain in a decentralized manner. Hyperledger Fabric is one of the largest frameworks of private blockchain networks in production today.

 

1.1  Hyperledger Fabric and its Key Concepts

Hyperledger is an open-source community managed by the Linux Foundation. It is focused on developing a suite of stable frameworks, tools and libraries for enterprise-grade blockchain deployments. There are several variants of Hyperledger in this suite—Fabric being the most widely adopted—on which networks, apps, and platforms such as the Block Aero Aviation Blockchain Platform are developed.

Assets

Assets can range from the tangible (real estate and hardware) to the intangible (contracts and intellectual property). Hyperledger Fabric provides the ability to modify assets using chaincode transactions. Assets are represented in Hyperledger Fabric as a collection of key-value pairs, with state changes recorded as transactions on a Channel ledger. Assets can be represented in binary and/or JSON form.

Chaincode

Chaincode is software defining an asset or assets, and the transaction instructions for modifying the asset(s) — in other words, it’s the business logic. Chaincode enforces the rules for reading or altering key-value pairs or other state database information. Chaincode functions execute against the ledger’s current state database and are initiated through a transaction proposal. Chaincode execution results in a set of key-value writes (write set) that can be submitted to the network and applied to the ledger on all peers.

Certificate Authority

A Fabric Certificate Authority (CA) issues the certificates for organizations to authenticate to the network. There can be one or more CAs on the network and organizations can choose to use their own CA. Additionally, client applications owned by organizations in the consortium use certificates to authenticate transaction proposals, and peers use them to endorse proposals and commit transactions to the ledger if they are valid.

Channel

A channel is a communication means used to connect the components of the network and/or the member client applications. Channels are created by generating the configuration block on the ordering service — which evaluates the validity of the channel configuration. Channels are useful because they allow for data isolation and confidentiality. Transacting organizations must be authenticated to a channel in order to interact with it. Channels are governed by the policies they are configured with. Each Channel has one ledger.

Ordering Service

A defined collective of nodes that orders transactions into a block. The ordering service exists independent of the peer processes and orders transactions on a first-come-first-serve basis for all channels on the network. The ordering service is designed to support pluggable implementations beyond the out-of-the-box SOLO and Kafka varieties. The ordering service is a common binding for the overall network — it contains the cryptographic identity material tied to each Member.

Peer Nodes

Peers are joined to channels by the organizations that own them, and there can be multiple peer nodes on channels within the network. Peers can take on multiple roles:

  • Endorsing peer – Defined by policy as specific nodes that execute smart contract transactions in simulation and return a proposal response (endorsement) to the client application
  • Committing peer – Validates blocks of ordered transactions and commits (writes/appends) the blocks to a copy of the ledger it maintains.

Because all peers maintain a copy of the ledger for every channel to which they are joined, all peers are committing peers. However, only peers specified by the endorsement policy of the smart contract can be endorsing peers. A peer may be further defined by the roles below:

  • Anchor peer – Defined in the channel configuration and is the first peer that will be discovered on the network by other organizations within a channel they are joined to 
  • Leading peer – Exists on the network to communicate with the ordering service on behalf of an organization that has multiple peers

Private Data Collections

Confidential data that is stored in a private database on each authorized peer logically separate from the channel ledger data. Access to this data is restricted to one or more organizations on a channel via a private data collection definition.

Unauthorized organizations will have a hash of the private data on the channel ledger as evidence of the transaction data. Also, for further privacy, hashes of the private data go through the Ordering-Service, not the private data itself, so this keeps private data confidential from Orderer.

World State

Also known as the ‘current state’, the world state is a component of the HyperLedger Fabric Ledger. The world state represents the latest values for all keys (assets) included in the chain transaction log. Chaincode executes transaction proposals against world state data because the world state provides direct access to the latest value of these keys rather than having to calculate them by traversing the entire transaction log.

The world state will change every time the value of a key changes (for example, when the ownership of a car – the ‘key’ – is transferred from one owner to another – i.e. the ‘value’) or when a new key is added (i.e. a car is created).

As a result, the world state is critical to a transaction flow, since the current state of a key-value pair must be known before it can be changed. Peers commit the latest values to the ledger world state for each valid transaction included in a processed block.

State Database

Current state data is stored in a state database for efficient reads and queries from chaincode. Supported databases include levelDB and couchDB.

Credit: Linux Foundation

 1.2  Block Aero Aviation Blockchain Platform

Block Aero provides a framework for sharing blocks (of airworthiness, technical, and commercial data for aircraft, engines, and components) among collaborating organizations — with security, version control, and privacy.

Authorized users with the required permissions can upload, download, view and edit documents and data. The platform promotes secure and fast access to aviation data, while ensuring that no commercially sensitive information is available to competitors or other unauthorized parties.

Block Aero data permissions are determined according to a permission matrix based on a combination of organization type, org-asset relationship, transaction role, data block type, and data block field — as configured on the Hyperledger Fabric based Aviation Blockchain Network.

Data Blocks

Organizations create and append data blocks to assets building up several chains of information that help people answer the important questions of who owned, who operated, and the method of compliance for determining initial and continued airworthiness was maintained throughout the asset total lifecycle.

Standardize Data Flow with Digitized Documents

Block Aero applies structured document definitions in accordance with authority endorsed industry data standards to replace the typical unstructured documents in use today.

However, the platform can support scanned PDF files as well as XLS, XML, CSV, or JSON formats to give flexibility for the disparate IT capabilities of each network participant.

On-Chain Electronic Part Certificate Form Generator

With digitized assets and permissioned sharing, Block Aero facilitates the move away from legacy workflows where PDFs are sent by email or file sharing links from a single organization’s repository to a consistent and cryptographically secure, inter-organizational view of workflow, documentation, and asset status.

This dispenses with costly, repetitive, and error-prone manual inputs, reconciling, and lack of trust that are prevalent in existing, disconnected systems. Figure 18: Block Aero Transaction Module Screenshot

Transactions – Standardize Workflow with Digital Threads of Data Blocks

Existing consortiums and alliances can design and deploy multi-party transactions— assets transact faster with data that is precise and accessible to all relevant stakeholders.

Block Aero provides real-time transaction management for exchanging aviation data and documents between the entities that are involved in production, MRO, trading, financing, or certification of assets.

Organizations using Block Aero can easily update or determine the status of assets through the Transaction Module user-interface, or by integrating Block Aero data with existing systems.

System Interoperability

Block Aero has been developed to be adaptable and easy to use—as such the Aviation Blockchain Network can also be accessed via the web with or without integration.

Users can engage with essential platform features including transactions, assets, and document access through a secure SSO web application no matter what stage of digital competency the network participant has currently reached.

Digital transformation requires the optimization of people, processes, and tools. Fully embedded and integrated digital solution for PLM, ERP, and MES functions with minimal use of paper documentation is the ultimate goal—and this is highly synergistic with blockchain.

 Using Block Aero with API Integration

ERP and M&E systems can be synchronized with the Block Aero platform by making use of the External Data Sources API.

The data pushed on-chain can then be staged for inter-organizational validations or stored in the asset profile for immutability and traceability.

Block Aero integrates with enterprise in-house systems via non-proprietary, publicly available APIs that are designed specifically for ease of set-up and use.

Block Aero uses Swagger for its APIs, which is a common framework for documenting REST APIs.

The Block Aero External Data Source API enables aviation data from credentialed organizations to come on-chain, which makes it possible to receive live updates of asset status, transaction events, inventory, or IOT sensor feeds to your blockchain aviation assets.

Credentialed organisations use APIs to automate the flow of data between your ERP and M&E systems to the blockchain and select global partners collaboratively creating more value for all asset stakeholders.

Our next issue will publish Part 3 of this series and focus upon monetisation of digital assets. Find out more about Block Aero please visit their Storefront on Yocova .

Leave a Reply

Your email address will not be published. Required fields are marked *

What's happening on Twitter?

Yocova

Priority Boarding

Fill out this form and our team here at Yocova will guide you through the set up to get access to aviations premium community platform.

"*" indicates required fields

Confirmation*
Signup
This field is for validation purposes and should be left unchanged.

Yocova is committed to the respect and safeguarding of all personal data provided. Please view our privacy policy.