The Ultimate Guide to Permissioned Blockchain: Everything You Need to Know

Just imagine – sending money to someone else without going through a bank, and avoiding those hefty service charges. Not too long ago, this might have sounded like a fantasy. But now, thanks to the magic of blockchain technology, it’s becoming an everyday reality. 

The hype around blockchain isn’t dying down anytime soon – and for good reason. This digital ledger technology brings game-changing features to the table, like unparalleled transparency, tamper-proof records, and super slick traceability.

But hey, we get it – for some, blockchain might still sound like a buzzword. Maybe you’re a bit skeptical about the potential uses of blockchain. And that’s okay. 

After all, it’s still relatively new technology, and there are concerns around security to iron out. But here’s the thing – the camp of blockchain believers is growing daily, and the numbers suggest this isn’t just a fleeting tech trend.

Just look at the stats. According to Fortune Business Insight, the global blockchain market in 2021 was worth a cool USD 4.67 billion. Fast forward to 2022, it’s expected to rise to USD 7.18 billion, and by 2029, it’s projected to hit an eye-watering USD 163.83 billion. That’s a CAGR of 56.3%! 

Gartner also predicts that blockchain’s business value is set to skyrocket, reaching $176 billion by 2025 and an astronomical $3.1 trillion by 2030.

But let’s focus on a game-changer in blockchain: Permissioned Blockchain. It offers businesses the benefits of blockchain, but with control over data visibility. It’s perfect for those balancing blockchain’s power with privacy needs.

In this guide, we’re going to pull back the curtain on permissioned blockchains, and even show you how to create one. Let’s dive in!

What is a Perrmissioned Blockchain?

Think of a permissioned blockchain as an exclusive club in the world of blockchain technology. It’s a type of blockchain that only grants access to certain members. The major advantage here? An extra layer of security. It’s like a bouncer at the door, making sure only the right folks get inside.

So, who plays the role of the bouncer in a permissioned blockchain? That’s the network administrator. They’re in charge of the access control layer and only allow specific participants to perform certain actions. It’s like a VIP pass to a concert. 

The blockchain knows who is taking part in the transactions and the admin controls who can access what information. This makes permissioned blockchains a popular choice for businesses where privacy and control are key.

How do you get into this club? 

Well, to join a permissioned blockchain, you need an invite from the network owner. It’s not as simple as just turning up. This type of blockchain sets up roles that lay down the law about what each user can see and do on the blockchain. 

To gain access, users need to show their ID to the network administrator, almost like a secret handshake.

Before setting up a permissioned blockchain, it’s important to know what your organization needs. This ensures the blockchain can be customized to meet those specific requirements. It’s like tailoring a suit, so it fits you just right, making your system more efficient and effective. 

Now, isn’t that cool?

Advantages of Permissioned Blockchain

Alright, let’s talk about the perks of being in the permissioned blockchain club.

Smooth Sailing and Room to Grow

Permissioned blockchains are like a well-organized event. Only a specific number of nodes are allowed, so transactions run smoother and quicker. It’s like having a fast pass in an amusement park – no need to wait for a zillion nodes to give the nod.

Tailor-made for You

These blockchains can be easily customized to do the tasks you need. Think of it as your own personal assistant, there to do the jobs you’ve set. Plus, you can adjust it as your company evolves.

Transparency on Your Terms

With permissioned blockchains, you choose how transparent your network should be. This is crucial for organizations needing a dash of confidentiality with their morning coffee.

Access Control

This is a real boon for businesses wanting trust and security in their transactions. The doorkeeper, or central authority, decides who gets to join the party.

Secure your secrets

Permissioned blockchains are like a vault for sensitive data. Only a selected few can access information like personal details or login credentials. Your secrets are safe here.

Green Energy

This is a type of private blockchain that can boost energy efficiency. It’s like choosing a small gathering over a big party – fewer people mean less energy used for maintaining the network and approving transactions.

Business Booster

Permissioned blockchains offer a secure and transparent platform for businesses to operate. It’s like having a safe playground to meet your business needs while maintaining privacy.

Top-notch Security

With access limited to trusted users, permissioned blockchains aim to offer better security than their permissionless counterparts. It’s like a private party – only the folks on the guest list can join, minimizing the risk of information leaks.

Balanced Transparency

In a permissioned blockchain, not everyone can see everything. It’s like having blinds in your house – you control who sees what, making it a perfect fit for your unique needs.

Disadvantages of Permissioned Blockchain

Let’s balance the scale: The flip side of permissioned blockchains.

The Corruption Conundrum

While permissioned blockchains boast robust security due to their exclusive user list, it’s a double-edged sword. There’s always a risk that the gatekeepers might manipulate consensus. Remember, the network’s safety is as good as the users’ integrity.

The Hand of Regulation

Operating in the realm of permissioned networks, these blockchains aren’t immune to regulatory oversight. This means transactions could be curtailed or censored at any point. Freedom isn’t exactly a part of the package here.

Open to Attacks

Permissioned blockchains might appear safer with their limited validator count, but this can potentially make the network a tempting target for malicious hackers. Fewer validators could equate to more vulnerability.

The Key Differences: Permissioned vs Permissionless Blockchains

Permissioned blockchains and permissionless blockchains share the same foundational technologies, but their access policies are distinctly different. For instance, to interact with a permissioned blockchain, users must first obtain the necessary authorization.

Consider a bank that operates a permissioned blockchain to monitor money transfers. This blockchain, which is managed by a predefined set of nodes within the bank, is inaccessible unless you have the required permissions. 

On the contrary, a permissionless blockchain, such as a cryptocurrency mining network, permits you to participate once you’ve set up a semi-anonymous account within the network.

In essence, well-designed permissioned blockchain networks integrate an access-control layer within the blockchain nodes to manage user permissions.

Features	Permissioned Blockchain	Permissionless Blockchain
Usage	Primarily Enterprise	Public
Decentralization	Limited	Broad
Development	Often Proprietary	Usually Open Source
Transparency	High, at certain levels	Low due to user anonymity
Speed	Typically faster	Slower due to decentralization
Decision Making	Centralized by administrators	Decentralized, by all users

Despite being fundamentally similar, permissioned and permissionless blockchains have distinct differences. Let’s dive a little deeper.

Usage – Enterprise vs. Public

Permissionless blockchains, like Bitcoin, are open to the public. Anyone can join, read the blockchain, or contribute to it by mining and validating transactions. The transparency and openness of such networks are conducive to fostering trust and verification amongst their users. 

On the contrary, permissioned blockchains are typically used by businesses and enterprises. For example, a bank might deploy a permissioned blockchain to track transactions securely and privately. 

Each entity in the chain, like banks or logistics partners, has a specific role with defined permissions. The restricted access in these networks aids in controlling security, privacy, and accountability, making it particularly attractive to enterprises.

Decentralization

Permissionless blockchains are highly decentralized – they are open to anyone, and all participants share equal power. This high degree of decentralization aids in security, as it doesn’t present a single point of failure. 

However, this also introduces challenges such as slower transaction times due to the need for consensus from a larger number of nodes. 

Conversely, permissioned blockchains are less decentralized. Their operation relies on a set of predefined nodes or entities, which makes transactions faster and more efficient and introduces a degree of central control.

Development – Community vs. Proprietary

Permissionless blockchains are typically developed as open-source projects. This means that a global community of developers can contribute to and improve the code, leading to robust and well-tested systems. 

However, these systems can also be less predictable as the community makes changes. 

Permissioned blockchains, in contrast, are often proprietary and developed for a specific purpose by a single organization. This allows for control over the development process, but may also limit the diversity of input and breadth of testing.

Transparency

With permissionless blockchains, there’s a high level of transparency as any member can view all transactions on the blockchain. However, user identities are often obscured, maintaining privacy. 

In permissioned blockchains, transparency is tailored to the needs of the organization. Transactions are only visible to those with the necessary permissions, while the identities of the parties are known, which can be essential for audit and regulatory compliance purposes.

Speed

Speed and efficiency are one of the major differences between permissioned and permissionless blockchains. Permissioned blockchains are generally faster due to more centralized control and fewer nodes validating transactions. This results in a more efficient and faster validation process. 

In contrast, permissionless blockchains require consensus from a larger number of nodes, which, while adding robustness and security, can slow down transaction times.

Decision Making 

In permissioned blockchains, decision-making authority is centralized to a set of predefined administrators or owners. They can establish rules, grant access, and validate transactions. This is crucial for businesses that need control over their operations. 

In contrast, in permissionless blockchains, all network participants are involved in decision-making. This is executed through consensus algorithms, like Proof of Work or Proof of Stake. Decisions on validating transactions or adding new blocks are made collectively by the network participants.

Each type of blockchain has its unique advantages, and the choice between a permissioned or permissionless blockchain depends largely on the specific needs and objectives of the user or organization.

Can Permissioned and Permissionless Blockchains Co-exist?

The blockchain world was first introduced to us through the work of Satoshi Nakamoto, a pseudonymous entity known for kick-starting the Bitcoin revolution. 

In 2008, Nakamoto presented a decentralized solution to many of the financial sector’s problems, marking a clear divergence from the traditional centralized institutions such as banks.

The blockchain presented in Nakamoto’s white paper was permissionless, trustless, and stateless, providing a system that could prevent double-spending while maintaining transparent and readily accessible records of transactions. 

However, with the realization that blockchain technology could serve numerous applications, different iterations, including permissioned blockchains, emerged to cater to organizations favoring restricted access.

While some argue against the concept of permissioned blockchains, viewing them as ‘networks with gatekeepers’, it’s important to remember that they have their place and serve specific needs. Consider other technology debates from the 1990s:

• Cloud infrastructure vs. on-premise infrastructure
• Internet vs. intranets

The public versions of these technologies generally prevailed due to their flexibility, benefits, and lower entry barriers. Similarly, permissionless blockchains are more widely used now. But, the existence of closed technologies doesn’t negate their usefulness. They serve specific applications and use cases effectively.

The strength of permissioned blockchains lies in their efficiency. They can:

• Facilitate swift and secure trading among members within a closed group.
• Provide a unified reference point for risk management, compliance, and other critical organizational teams.
• Help eliminate unnecessary paperwork.

In certain business contexts, permissioned blockchains may be more suitable. Their restricted access allows for less complex algorithms compared to permissionless blockchains, leading to more energy-efficient data and transaction processing. 

Moreover, consensus can be achieved more quickly due to a smaller validation group.

Drawing a line between the internet and intranets can further clarify this point. While the internet serves a broader population, intranets continue to hold value within organizations, aiding communication, collaboration, and secure storage of confidential files.

In conclusion, both permissionless and permissioned blockchains can coexist. Each serves distinct purposes, meeting the diverse needs of users and organizations across the globe.

Which Blockchain is Suitable for Your DApp: Permissioned or Permissionless?

Determining the ideal blockchain for your Decentralized Application (DApp) involves considering various factors and the unique attributes of both permissioned and permissionless blockchains. Below we explore some key areas to help guide your decision.

Censorship and Transparency

If privacy and transparency are your DApp’s top priorities, permissionless blockchains are a superior choice. 

They provide an equal and anonymous platform for all users, where each transaction is openly visible. This openness prevents potential censorship by administrators. 

On the other hand, permissioned blockchains pose risks as a single entity with control could manipulate data, disrupting the consensus algorithm for personal gain.

Commercial Use

Permissioned blockchains have shown great potential in commercial spaces such as the Non-Fungible Token (NFT) market. Upon purchasing an NFT, users gain access to a permissioned blockchain that might offer exclusive privileges. 

As these blockchains are regulated and private, businesses have the liberty to choose who gains access, making them more business-friendly.

Performance and Security

Permissioned blockchains typically perform faster than their permissionless counterparts due to the controlled number of users. 

However, they might fall short in security compared to permissionless blockchains, which require every transaction or block to be validated before being added. 

While permissioned blockchains can enact security measures, they often don’t match the effectiveness of those on permissionless blockchains.

Community Contributions and Ecosystems

Companies like Facebook, Amazon, Apple, Netflix, and Google (FAANG), along with Ethereum Layer 2 platforms, have found success with open-source models. 

Open-sourcing your DApp’s source code allows worldwide developers to provide reviews, updates, and ideas, accelerating development and technology evolution. 

Permissionless blockchains are especially suitable for this model, allowing for voting, fundraising programs, and cryptocurrency-based compensation for contributors.

Energy Usage

According to a study by MoneySuperMarket, a single Bitcoin transaction, operating on a permissionless blockchain, consumes enough energy to power a home for more than a month. 

While permissionless blockchains provide robust security through mining and validating blocks, they are energy-intensive and challenging to scale due to a constantly growing user base and transaction volume.

Web Customization and Flexibility

DApps on permissioned blockchains are typically easier to customize and tailor to their user base due to their smaller size and the presence of dedicated administrators. Implementing updates and improvements to the platform’s specific needs is more streamlined, as it doesn’t require a voting process.

Different Types of Consensus Protocols for Permissioned Blockchain Networks

Choosing the right consensus algorithm for permissioned blockchain networks is a key decision that impacts the performance and reliability of the system. 

Let’s check out several consensus mechanisms often employed in permissioned blockchains: Practical Byzantine Fault Tolerance (PBFT), Federated Byzantine Agreement (FBA), Round Robin, and Raft.

1. Practical Byzantine Fault Tolerance (PBFT) Consensus

First introduced in the late 1990s by Barbara Liskov and Miguel Castro, PBFT was developed to function effectively within asynchronous systems and improve upon existing Byzantine fault tolerance (BFT) techniques. PBFT’s aim is to establish a functioning Byzantine state machine replication (SMR) that operates even in the presence of malicious nodes.

In a PBFT-supported permissioned blockchain system, nodes are sequenced with a primary node (or leader) and secondary (backup) nodes. Any qualifying node in the network can shift from secondary to primary status, often during a primary node failure. 

PBFT relies on trustworthy nodes to implement majority rule, determining the state of the blockchain. PBFT’s security grows as the number of trusted nodes increases, given the assumption that the total number of malicious nodes mustn’t surpass one-third of the system’s nodes.

PBFT’s operation mirrors a “Commander and Lieutenant” dynamic more than a pure Byzantine Generals’ Problem where all generals are equal. The consensus process in PBFT comprises four stages:

• A client initiates a service operation by requesting the leader node.
• The leader node broadcasts this request to the backup nodes.
• After executing the request, the nodes reply to the client.
• The client waits for responses from different nodes with the same result, and this outcome becomes the process’s result.

PBFT is suitable for permissioned blockchain networks that don’t need high capacity but handle numerous transactions. Its implementation aids low-latency storage systems and ensures transaction records’ accuracy within the network.

2. Federated Byzantine Agreement (FBA):

The FBA system operates with open membership, decentralized control, and the ability for nodes to choose who to trust. In FBA, nodes’ decisions lead to quorums, affecting the entire system. 

FBA’s hallmark is the use of “quorum slices,” which are subsets of a quorum that can convince a single node to agree. These quorum slices and quorums may emerge dynamically, enabling flexible consensus building in a network.

Each node in an FBA-backed permissioned blockchain trusts a set of nodes (a quorum) that assists in reaching consensus. The quorum employs a single block generator that efficiently handles and filters all transactions in the blockchain. 

This generator collaborates with the quorum for block validation, adhering to specific conditions the blockchain administrator sets. Once the network verifies the block, it is published to the blockchain network.

FBA consensus ensures security and transparency, making it ideal for use cases like real-time Know Your Customer (KYC) processes and cross-border remittances.

3. Round Robin Consensus

Round Robin Consensus operates with validators who sign votes for blocks in the form of prevotes, precommits, and commits. A block is considered committed when it receives commits from a two-thirds majority of validators.

This consensus mechanism employs a round-based process for generating the next block, with each round composed of three phases (Propose, Prevote, and Precommit) and two additional steps (Commit and NewHeight). 

Each phase consumes a third of the total round time, gradually increasing as the rounds progress. The transaction validation and signing processes involve multiple nodes, enhancing the protocol’s security and reducing the chances of double-spend attacks.

The Round Robin Consensus is advantageous for commerce, financial, and supply chain industries due to its distributed validation process and resilience against fraudulent transactions.

4. Raft Consensus

Originating from the Paxos consensus algorithm, Raft is a leader-based consensus mechanism often utilized in permissioned blockchain networks. In a Raft consensus system, nodes elect a leader, and the remaining nodes (followers) take cues from this leader. 

The leader is responsible for replicating state transition logs amongst the followers, operating under the assumption that every node is reliable and free from malicious intentions.

Understanding Raft in a nutshell:

• Term Duration: The fundamental concept of Raft splits time into small, arbitrary intervals, each identified by an incrementing term number. Every node keeps track of this term number, which is shared when nodes communicate.
• Election Process: Each term starts with an election for a new leader. Candidates for leadership ask for votes from other server nodes (followers) to get a majority.
• Leadership Criteria: If nodes back the candidate, they lead for that term. Without a majority, the term ends leaderless, known as a split vote. In any term, there’s just one leader.
• Node Roles: Typically, a node in a Raft-enabled permissioned blockchain network takes on one of three roles: leader, candidate, or follower. Any request to a follower node gets passed to the leader.
• Leader’s Role: The leader is the main link to the client. Meanwhile, a candidate seeks votes, and a follower interacts only with the leader or candidate.
• Determination of Leader: Raft’s algorithm clearly defines how to pick the leader in a distributed network, enhancing reliability and clarity for nodes.

The emphasis on a leader-focused consensus model is evident when there’s a need for strong consistency and high reliability. In the grand scheme of permissioned blockchains, each consensus protocol addresses unique requirements. 

PBFT prioritizes systems with low latency, FBA offers decentralized consensus with flexibility, Round Robin zeroes in on distributed validation, while Raft is all about the leader-centric consensus model. When picking a consensus protocol, remember to weigh the demands of your blockchain network.

Use Cases of Permissioned Blockchains

Permissioned blockchains offer significant advantages for various sectors due to their security, transparency, and controlled access. Here are expanded examples of use cases:

1. Supply Chain Management

With the rise of global commerce, tracking the movement of goods has become complex. A permissioned blockchain can provide an efficient solution by enabling a secure, robust mechanism to trace products from their origin to the customer. 

The transparency of the blockchain reduces the risk of fraud and counterfeit goods because each transaction is visible to authorized participants.

For example, in a shipment process, every detail such as the date, time, location, and quantity of items transferred can be logged into the blockchain system by each party involved. This creates a transparent and verifiable chain of custody for goods.

Furthermore, permissioned blockchains can enhance operational efficiency by providing real-time visibility into the flow of goods, helping businesses optimize their logistics and inventory management. 

For instance, if a bottleneck is identified in the supply chain, it can be immediately addressed to prevent further delays. The recorded data can also be used for forecasting and planning, ultimately leading to cost reductions.

2. Healthcare

The healthcare industry handles highly sensitive data including patient health records, medical histories, and personal identification information. 

A permissioned blockchain can create a secure, decentralized database for storing and sharing these data among trusted parties, thus ensuring patient privacy. 

Patients can control access to their records, allowing only authorized entities like physicians, hospitals, insurers, and researchers to access their information.

A permissioned blockchain can also automate administrative procedures such as processing insurance claims or handling medical billing. 

This not only reduces administrative costs and errors but also improves patient satisfaction by expediting services. 

Lastly, a secure and transparent data sharing platform provided by the blockchain can promote collaborative medical research, potentially leading to new breakthroughs.

3. Financial Services

The financial sector requires maximum security, efficiency, and transparency. Permissioned blockchains can fulfill these requirements by facilitating secure transactions between approved parties. 

By creating an immutable and transparent record of all transactions, the blockchain system can significantly reduce the potential for fraud and discrepancies.

Further, implementing permissioned blockchains can automate routine processes such as settlement and clearing, resulting in cost savings and reduced processing time. 

Real-time visibility into transactions can also increase transparency, eliminating the need for intermediaries and reducing disputes caused by data inconsistencies.

Additional Possible Use Cases 

Education

Permissioned blockchains can play a significant role in the education sector, particularly for credential verification. 

Educational institutions can issue digital diplomas or certificates that are recorded on the blockchain, creating an immutable and easily verifiable record of academic achievements. This can prevent diploma fraud and streamline the hiring process for employers.

Real Estate

Permissioned blockchains can transform real estate transactions by creating an immutable record of property deeds and ownership history. 

This can significantly reduce fraudulent transactions and disputes over property ownership. 

It can also streamline real estate transactions by eliminating the need for intermediaries, resulting in faster and more efficient processes.

Energy

In the energy sector, permissioned blockchains can facilitate peer-to-peer energy trading by allowing producers to sell their excess energy directly to consumers. 

This can foster the development of a decentralized energy grid, increase energy efficiency, and promote the use of renewable energy sources.

How to Create a Permissioned Blockchain

In this section, we’ll guide you through the process of creating a permissioned blockchain using Substrate and the node authorization pallet. The node authorization pallet is a pre-built FRAME pallet that allows you to manage a configurable group of nodes in your network.

To begin, you’ll need to choose one of two methods for approving nodes to join the network:

• Including the peer identifier in the chain specification file: This method involves adding the peer identifier to the list of preconfigured nodes in the chain specification file during the genesis setup. However, keep in mind that you’ll require permission from the chain’s governance mechanism or access to the Sudo pallet’s root account on the network to do this.

• Establishing a paired peer connection: The second method involves requesting a paired peer connection from the specific node you want to add. Each node has its own set of public and private keys, which can be used to generate peer identifiers. These identifiers are then used to establish connections between nodes.

Before you start, ensure that you have set up your development environment for Substrate by installing Rust and the Rust toolchain. Now, let’s dive into the steps required to create a permissioned blockchain using Substrate.

Step 1: Build the Node Template

To begin, open a terminal shell on your computer and clone the node template repository by running the following command:

git clone https://github.com/substrate-developer-hub/substrate-node-template

If needed, navigate to the root directory of the node template by running:

cd substrate-node-template

If you prefer to work on a separate branch to save your changes, create and switch to a working branch using a command similar to this:

git switch -c my-wip-branch

Next, compile the node template by running the following command:

cargo build –release

Make sure the node template compiles without any errors. If you encounter any issues during compilation, you can refer to troubleshooting tips for Rust.

Step 2: Add the node Authorization Pallet & Dependencies

Before you can use the node authorization pallet in the Substrate runtime, you need to make some changes to the configuration files.

Open the Cargo.toml configuration file located in the runtime directory of the node template using a text editor.

Within the [dependencies] section, add the following code to make the pallet-node-authorization crate available to the node template runtime:

[dependencies] pallet-node-authorization = { default-features = false, version = “4.0.0-dev”, git = “https://github.com/paritytech/substrate.git”, branch = “polkadot-v0.9.28” }

This code imports the pallet-node-authorization dependency and configures it with the specified version and repository details.

Next, add the “pallet-node-authorization/std” feature to the list of enabled features under the [features] section:

[features] default = [‘std’] std = [ … “pallet-node-authorization/std”, # add this line … ]

Enabling this feature ensures that the standard features of the node authorization pallet are compiled when building the runtime.

To verify that the new dependencies resolve correctly, run the following command in the terminal:

cargo check -p node-template-runtime –release

This command checks if the node template’s runtime compiles successfully with the added dependencies.

Step 3: Add an Administrative Rule

Open the ‘runtime/src/lib.rs’ file in a text editor.

Add the following line to import the ‘EnsureRoot’ function from the ‘frame_system’ module:

use frame_system::EnsureRoot;

Implement the ‘Config’ trait for the node authorization pallet:

parameter_types! {

    pub const MaxWellKnownNodes: u32 = 8;

    pub const MaxPeerIdLength: u32 = 128;

}

impl pallet_node_authorization::Config for Runtime {

    type RuntimeEvent = RuntimeEvent;

    type MaxWellKnownNodes = MaxWellKnownNodes;

    type MaxPeerIdLength = MaxPeerIdLength;

    type AddOrigin = EnsureRoot<AccountId>;

    type RemoveOrigin = EnsureRoot<AccountId>;

    type SwapOrigin = EnsureRoot<AccountId>;

    type ResetOrigin = EnsureRoot<AccountId>;

    type WeightInfo = ();

}

Add the ‘NodeAuthorization’ pallet to the ‘construct_runtime’ macro in the ‘runtime/src/lib.rs’ file:

construct_runtime!(

    pub enum Runtime where

        Block = Block,

        NodeBlock = opaque::Block,

        UncheckedExtrinsic = UncheckedExtrinsic

    {

        // …other pallets…

        NodeAuthorization: pallet_node_authorization::{Pallet, Call, Storage, Event, Config},

    }

);

Save the changes and close the file.

Run the following command to check if the configuration can compile without errors:

cargo check -p node-template-runtime –release

Step 4: Add Genesis Storage for Authorized Nodes

Open the ‘node/Cargo.toml’ file in a text editor.

Find the ‘[dependencies]’ section and add the ‘bs58’ library as a dependency:

[dependencies]

bs58 = { version = “0.4.0” }

Save the changes and close the file.

Open the ‘node/src/chain_spec.rs’ file in a text editor.

Import the necessary modules:

use sp_core::OpaquePeerId;

use node_template_runtime::NodeAuthorizationConfig;

Locate the testnet_genesis function within the chain_spec.rs file.

Add the following code block to configure genesis storage for authorized nodes:

node_authorization: NodeAuthorizationConfig {

    nodes: vec![

        (

            OpaquePeerId(bs58::decode(“12D3KooWBmAwcd4PJNJvfV89HwE48nwkRmAgo8Vy3uQEyNNHBox2”).into_vec().unwrap()),

            endowed_accounts[0].clone()

        ),

        (

            OpaquePeerId(bs58::decode(“12D3KooWQYV9dGMFoRzNStwpXztXaBUjtPqi6aU76ZgUriHhKust”).into_vec().unwrap()),

            endowed_accounts[1].clone()

        ),

    ],

},

In this code block, the ‘NodeAuthorizationConfig’ structure defines the ‘nodes’ property as a vector containing tuples. Each tuple consists of two elements: the ‘OpaquePeerId’ which represents the node’s PeerId transformed from the bs58-encoded string, and the associated ‘AccountId’ representing the node’s owner. 

In this example, the preconfigured Alice and Bob accounts are used as endowed accounts [0] and [1], respectively.

Save the changes and close the file.

Step 4: Verify Node Compilation

To ensure that the node compiles without any issues, follow these steps:

If necessary, navigate to the root directory of the substrate-node-template.

Compile the node by running the following command:

cargo build –release

If there are no syntax errors, you can proceed. If any errors occur, review the compile output and fix the errors accordingly.

Step 5:Identify Account Keys to Use

To participate in the network, you need to have account keys for each node. In the case of the predefined accounts, we already have the necessary keys. Here are the account keys for Alice, Bob, Charlie, and Dave:

Alice

Key Type	Key Value
Node Key	c12b6d18942f5ee8528c8e2baf4e147b5c5c18710926ea492d09cbd9f6c9f82a
Peer Identifier (Generated from Node Key)	12D3KooWBmAwcd4PJNJvfV89HwE48nwkRmAgo8Vy3uQEyNNHBox2
Peer Identifier (Decoded to Hex)	0x0024080112201ce5f00ef6e89374afb625f1ae4c1546d31234e87e3c3f51a62b91dd6bfa57df

Bob

Key Type	Key Value
Node Key	6ce3be907dbcabf20a9a5a60a712b4256a54196000a8ed4050d352bc113f8c58
Peer Identifier (Generated from Node Key)	12D3KooWQYV9dGMFoRzNStwpXztXaBUjtPqi6aU76ZgUriHhKust
Peer Identifier (Decoded to Hex)	0x002408011220dacde7714d8551f674b8bb4b54239383c76a2b286fa436e93b2b7eb226bf4de7

Charlie

Key Type	Key Value
Node Key	3a9d5b35b9fb4c42aafadeca046f6bf56107bd2579687f069b42646684b94d9e
Peer Identifier (Generated from Node Key)	12D3KooWJvyP3VJYymTqG7eH4PM5rN4T2agk5cdNCfNymAqwqcvZ
Peer Identifier (Decoded to Hex)	0x002408011220876a7b4984f98006dc8d666e28b60de307309835d775e7755cc770328cdacf2e

Dave

Key Type	Key Value
Node Key	a99331ff4f0e0a0434a6263da0a5823ea3afcfffe590c9f3014e6cf620f2b19a
Peer Identifier (Generated from Node Key)	12D3KooWPHWFrfaJzxPnqnAYAoRUyAHHKqACmEycGTVmeVhQYuZN
Peer Identifier (Decoded to Hex)	0x002408011220c81bc1d7057a1511eb9496f056f6f53cdfe0e14c8bd5ffca47c70a8d76c1326d

You can use these keys for the respective accounts to authenticate and participate in the network.

If you want to verify the peer identifiers for Charlie and Dave, you can use the subkey command-line tool. Here’s an example of how to save Charlie’s node key to a file called “charlie-node-key” and check the peer identifier:

Open a terminal window.

Run the following command to save Charlie’s node key to the file:

echo -n “3a9d5b35b9fb4c42aafadeca046f6bf56107bd2579687f069b42646684b94d9e” > charlie-node-key

To verify the peer identifier, run the following command:

./subkey inspect-node-key –file charlie-node-key

This command will display the peer identifier for the Charlie node, which should be:

12D3KooWJvyP3VJYymTqG7eH4PM5rN4T2agk5cdNCfNymAqwqcvZ

It’s important to save the peer identification to a file if you create node keys for your account. This way, you can use it for future reference or for other commands that require the peer identifier.

Step 5: Launch Network Nodes

Now, we can proceed with launching the network nodes and allowing other nodes to join using the node keys and peer identifiers for the predefined accounts. 

In this course, we will be launching four nodes, where three of them are linked to predefined accounts and are permitted to author and validate blocks, while the fourth node is a sub-node with limited access. Let’s start by launching the nodes:

Start the first node:

• If needed, open a terminal window on your computer.
• Navigate to the root directory where the Substrate node template was built.
• Use the following command to launch the first node:

./target/release/node-template \

–chain=local \

–base-path /tmp/validator1 \

–alice \

–node-key=c12b6d18942f5ee8528c8e2baf4e147b5c5c18710926ea492d09cbd9f6c9f82a \

–port 30333 \

–ws-port 9944

Start the Second Node:

• Open a new terminal window on your computer.
• Navigate to the root directory where the Substrate node template was built.
• Use the following command to launch the second node:

./target/release/node-template \

–chain=local \

–base-path /tmp/validator2 \

–bob \

–node-key=6ce3be907dbcabf20a9a5a60a712b4256a54196000a8ed4050d352bc113f8c58 \

–bootnodes /ip4/127.0.0.1/tcp/30333/p2p/12D3KooWBmAwcd4PJNJvfV89HwE48nwkRmAgo8Vy3uQEyNNHBox2 \

–port 30334 \

–ws-port 9945

Add a Third Node to the List of Well-known Nodes:

• Open a new terminal window on your machine.
• Navigate to the root directory where the Substrate node template was built.
• Run the following command to launch the third node:

./target/release/node-template \

–chain=local \

–base-path /tmp/validator3 \

–name charlie \

–node-key=3a9d5b35b9fb4c42aafadeca046f6bf56107bd2579687f069b42646684b94d9e \

–port 30335 \

–ws-port 9946 \

–offchain-worker always

After launching the third node, you will notice that there are no connected peers initially. This is because the node needs explicit authorization to connect since it’s a permissioned network. 

In the genesis ‘chain_spec.rs’ file, the configuration for the Alice and Bob nodes was specified. To add additional nodes, a manual call to the Sudo pallet must be made.

That’s it! You have successfully launched the network nodes, and they are ready to interact with each other.

Step 6: Authorize Access for the Third Node

To authorize the third node, which is owned by Charlie, we will use the Sudo pallet for governance. Follow these steps to add the third node using the Polkadot/Substrate Portal application:

• Open the Polkadot/Substrate Portal in your browser.
• Click on “Developer” and choose “Sudo”.
• Select the “addWellKnownNode” function under “nodeAuthorization (node, owner)”.
• Paste the hex-encoded peer identifier for Charlie’s node after the required 0x prefix.
• Set Charlie as the owner of the node.
• Click “Submit Sudo”.
• In the “Authorize” transaction, you will see that the Alice development account is the default root administrative account used as the sudo origin. Click “Sign and Submit” to confirm the transaction.

You can check the most recent transactions by selecting “Explorer” under “Network”.

After the transaction is included in a block, you should see the Charlie node connecting to the Alice and Bob nodes and starting to sync blocks. 

If you are using a local network, the mDNS discovery technique, which is enabled by default, will allow the nodes to locate each other. Make sure that any local firewalls are configured to allow mDNS. 

If your nodes are not connected to the same local network, you can disable mDNS using the command-line option –no-mdns.

Step 7: Allow Connections from a Sub-node

In a permissioned network, Charlie needs to configure his node to allow connections from Dave’s sub-node. Follow these steps using the Polkadot/Substrate Portal application:

• Open the Polkadot/Substrate Portal in your browser.
• Click on “Developer” and select “Extrinsics”.
• Choose “nodeAuthorization” and select “addConnections(node, connections)”.
• Paste the hex-encoded peer identifier for Charlie’s node after the required 0x prefix.
• For the “connections” parameter, paste the hex-encoded peer identifier for Dave’s node after the required 0x prefix.
• Click “Submit Transaction” to initiate the connection.
• Review the transaction details, then click “Sign and Submit” to confirm the transaction.

Step 8: Claim the Sub-node

Before starting the sub-node owned by Dave, the node administrator needs to claim the peer identifier for Dave’s node. Use the Polkadot/Substrate Portal application to submit the transaction:

• Open the Polkadot/Substrate Portal in your browser.
• Click on “Developer” and select “Extrinsics”.
• Choose “nodeAuthorization” and select “claimNode(node)”.
• Paste the hex-encoded peer identifier for Dave’s node after the required 0x prefix.
• Click “Submit Transaction” to claim the node.
• Review the transaction details, then click “Sign and Submit” to confirm the transaction.

By following these steps, you have authorized access for the third node, allowed connections from Dave’s sub-node, and claimed the sub-node. Now, the network is set up to function with the authorized nodes and their connections.

Step 9: Launch the Sub-node

After claiming the node peer identifier for Dave’s sub-node, you can proceed to launch the sub-node using the following steps:

• Open a new terminal window on your machine.
• Navigate to the root directory where the Substrate node template was built.
• Execute the following command to launch the sub-node:

./target/release/node-template \

–chain=local \

–base-path /tmp/validator4 \

–name dave \

–node-key=a99331ff4f0e0a0434a6263da0a5823ea3afcfffe590c9f3014e6cf620f2b19a \

–port 30336 \

–ws-port 9947 \

–offchain-worker always

Step 10: Allow Connections to the Sub-node

To enable connections to the sub-node from Charlie’s parent node, follow these steps using the Polkadot/Substrate Portal application:

• Open the Polkadot/Substrate Portal in your browser.
• Click on “Developer” and select “Extrinsics”.
• Choose “nodeAuthorization” and select “addConnections(node, connections)”.
• Copy and paste the hex-encoded peer identifier for Dave’s node after the required 0x prefix.
• For the “connections” parameter, copy and paste the hex-encoded peer identifier for Charlie’s node after the required 0x prefix.
• Click “Submit Transaction” to allow connections to the sub-node.
• Review the transaction details, then click “Sign and Submit” to confirm the transaction.

You should now observe that the sub-node is syncing blocks from the chain and has only one peer, which is Charlie’s node. If the sub-node doesn’t connect to its peer node immediately, try stopping and restarting the sub-node.

Step 11: Keys Required to Submit Transactions

It’s important to note that any account can be used to sign and submit transactions that impact the behavior of other nodes. However, to sign and submit a transaction that affects a node you do not own, the following conditions must be met:

• The transaction must reference chain data.
• The signature key for an account with the necessary origin must be accessible in the Keystore.

In this case, all nodes have access to the signing keys for the development account. This means that using an account to act on behalf of Charlie or Dave, you can sign and submit transactions that impact any connected node. 

In a real-world application for a permissioned network, node operators would typically only have access to their node keys. 

Node owner accounts would be required to sign and submit transactions that pertain to the node where they have control of the signature key.

Challenges of Permissioned Solutions

Implementing permissioned blockchain solutions comes with its fair share of challenges. Let’s take a closer look at some of the key challenges businesses face when developing permissioned networks.

Integration Challenges

One significant challenge in implementing permissioned solutions is the integration of various systems, particularly when relying on APIs for communication. 

To simplify integration, tools like Rhombus, Chainlink, and Oraclize can be utilized. These tools provide efficient connectivity and facilitate seamless integration of services.

Data Privacy Concerns

Privacy is a critical consideration, particularly for regulated industries. Meeting specific privacy requirements becomes essential to ensure data confidentiality. 

Platforms like Quorum and Aztec are excellent choices for developing permissioned blockchains that offer robust privacy features.

Data Access Efficiency

Accessing information within a permissioned blockchain can sometimes be slower compared to public blockchains. To address this challenge, solutions like The Graph can be employed. 

The Graph enables easy access to data through APIs and smart contracts, significantly improving data retrieval efficiency.

Optimal Data Storage

Choosing the right data storage approach is crucial, especially when dealing with a large volume of data on the blockchain. While there are multiple ways to store data, not all of them are optimal for scalability and performance. 

Utilizing data storage solutions such as IPFS Private Network, BigchainDB, or AWS Quantum Ledger ensures efficient and secure data storage on the blockchain.

Participant Identity Management

Managing participant identities can pose challenges in a permissioned network where identities are already known. This can impact consensus computations and create complexities. 

To address this challenge, leveraging identity protocols and solutions designed for decentralized applications, such as Azure BaaS or uPort, can simplify participant identity management and enhance overall network efficiency.

List of Best Permissioned Blockchains

Permissioned networks play a vital role in various industries, offering significant benefits to sectors such as finance and supply chain management. When it comes to choosing the best permissioned blockchains, a few standout solutions come to mind. 

Let’s take a brief look at three of the top choices.

1. Hyperledger Fabric

Hyperledger Fabric Framework, maintained by the Linux Foundation, is a popular choice among developers. Its modular architecture allows for flexible solution development, enabling seamless integration with different services.

Smart contracts, referred to as “chaincode,” embody the system’s logic, making it a powerful platform for building permissioned networks. To explore more about Hyperledger, check out our detailed coverage.

2. Quorum

Developed by JP Morgan, Quorum is an enterprise-focused Ethereum blockchain specifically designed for the financial industry. It offers robust features tailored to meet the unique requirements of financial institutions.

3. Corda

Corda is an open-source blockchain platform that empowers businesses to create interoperable blockchain networks. Its value lies in providing seamless connectivity and collaboration between various entities within a network. 

With its focus on business requirements, Corda delivers tangible benefits to organizations exploring permissioned blockchain solutions.

Conclusion

In conclusion, permissioned blockchains like Hyperledger Fabric, Quorum, and Corda provide powerful solutions for industries looking to tap into the potential of distributed ledger technology. 

To fully leverage the benefits of permissioned blockchain networks, businesses require the expertise and support of a reliable technology partner. That’s where Websioft comes in. 

As a leading provider of permissioned blockchain solutions, Websioft offers customized services to help businesses implement and optimize their permissioned networks. 

Get in touch with us today to discover how Websioft can assist you in unlocking the true potential of permissioned blockchains for your organization. Together, let’s revolutionize your industry with secure and efficient blockchain solutions.