How to create a permissioned blockchain?

The concept of sending money to someone without the involvement of a bank, avoiding expensive service fees may have seemed unrealistic in the past, but with the advent of blockchain technology, it has become a reality. The popularity of this technology is only growing with time- all thanks to its unique features as a digital ledger, such as transparency, immutability, and traceability. However, many still remain skeptical about the potential uses of blockchain, which is understandable given the early stages of this technology and the associated security concerns. Nonetheless, the number of people who believe in the power and potential of blockchain is constantly increasing, which points to the fact that blockchain is a promising technology that has the potential to bring about transformative outcomes in the tech sphere. According to Fortune business insight, the global blockchain market was estimated to be worth USD 4.67 billion in 2021 and is projected to rise from USD 7.18 billion in 2022 to USD 163.83 billion by 2029, with a CAGR of 56.3%. As per Gartner, the blockchain’s business value is set to soar, hitting $176 billion by 2025 and a whopping $3.1 trillion by 2030.

One of the most fascinating developments in the world of blockchain technology is the creation of permissioned blockchains. With permissioned blockchains, organizations can leverage the benefits of blockchain while maintaining control over who can access the data. This makes permissioned blockchains an ideal solution for businesses that require privacy and security.

In this article, we will discuss permissioned blockchains and offer a guide on how to build one.

• What is a permissioned blockchain?
• Permissioned vs. permissionless blockchain
• Types of consensus protocol for permissioned blockchain networks
• Benefits of using permissioned blockchains
• Use cases of permissioned blockchain
• How to create permissioned blockchains?

What is a permissioned blockchain?

A permissioned blockchain is a blockchain with its access limited to certain users or nodes. Providing limited access to a blockchain or defining permissioned users creates an additional layer of security for it. Administrators maintain an access control layer to allow certain actions to be carried out by only specific identifiable participants. The blockchain keeps track of who participates in the transactions. The network administrator can control who has access to what data in a permissioned blockchain network. Permissioned blockchains are frequently utilized in enterprises where data privacy and control are crucial.

In a permissioned blockchain, a user would require authorization from the network owner to join the network. A permissioned blockchain establishes the roles that determine what each user can access and how they can contribute to the blockchain. Users’ identities are disclosed to the network administrator to allow access to the network. It is essential to assess the needs of an organization while configuring and integrating permissioned blockchains, as it ensures that the blockchain is tailored to meet the organization’s specific requirements, providing a more efficient and effective system.

Permissioned vs. permissionless blockchain

To fully grasp the true significance of permissioned blockchains, it is also important to understand permissionless blockchains and how they differ from their permissioned counterparts. The term “permissionless” refers to the lack of censorship and gatekeepers. A permissionless blockchain enables everyone to access information and participate in the network. The original vision of Satoshi Nakamoto for the blockchain is thought to be more closely represented by permissionless blockchains. The difference between permissioned and permissionless blockchains can be understood with the following points:

Decisionmaking: In a permissioned network, administrators or owners make decisions and allow access to users who can interact with the network. The administrator can be an individual or an organization. In a permissioned network, there are established rules or protocols that govern how decisions are made within the network. These rules outline the decision-making process and specify who has the authority to execute those decisions. PBFT, FBA, etc., are a few consensus algorithms permissioned blockchains use.

In a permissionless network, decisions are often made through a decentralized process that involves all users’ participation. This means that every user on the network has an equal say in the decision-making process, and no single user or entity can control the network’s decisions.

The decentralized process used in a permissionless network is known as the consensus mechanism. The consensus mechanism is a set of rules and procedures that determine how the network participants reach an agreement on the state of the network, such as the validity of transactions and the state of the ledger. Proof of Work (PoW), Proof of Stake (PoS), and Delegated Proof of Stake (DPoS) are examples of consensus algorithms.

Decentralization: In a permissioned blockchain network, the decisions made by the network administrators, who manage different network components, influence the degree of decentralization. With nodes under the control of a single central entity, a permissioned blockchain network may be completely centralized. It might also be partially decentralized, with a higher number of nodes under the control of a dispersed group of network users.

On the other hand, permissionless blockchains are often decentralized. As a result, a single entity can’t alter the ledger, stop the network, or alter its protocols. This has a strong connection to the consensus protocol. To form a consensus, most users must agree on a particular decision.

Transparency: The objectives and specifications of the company or network owners administering the blockchain determine the degree of transparency in a permissioned blockchain network. While some permissioned blockchain networks may offer restricted exposure to specific parties, others may be fully private and inaccessible to anybody outside the network.

On the other hand, with a permissionless blockchain network, users have access to data, including transactional information, blocks, and the ledger. This degree of openness is a key characteristic of a decentralized network because no single central authority is regulating the information flow.

Anonymity: The nodes’ identities are known in a permissioned network because the network owners or administrators control who can access the network. Permissioned networks frequently demand users to provide identification or personal data to gain access.

On the other hand, permissionless blockchains don’t require any identification or personal data to join the network. In other words, users can generate a blockchain address, a public key, without disclosing their real identities. Also, blockchain transactions are pseudonymous, meaning that public keys are used to record transactions instead of real names or other private information.

Speed: Permissioned blockchains are typically faster than permissionless blockchains due to more centralized administration and fewer nodes. As fewer nodes agree on a transaction’s legitimacy, this also speeds up transaction processing times.

On the other hand, permissionless blockchains typically include more nodes and a more decentralized governance structure, which can slow down the consensus process. Furthermore, due to the computational resources needed to solve cryptographic puzzles, the proof-of-work consensus technique utilized by some permissionless blockchains may cause slower transaction processing times.

Types of consensus protocols for permissioned blockchain networks

Permissioned blockchains don’t use the same consensus mechanisms as permissionless blockchains. The following is a list of the consensus algorithms typically used for permissioned blockchains:

Practical Byzantine Fault Tolerance (PBFT) Consensus

Barbara Liskov and Miguel Castro first presented the consensus technique known as Practical Byzantine Fault Tolerance (PBFT) in the late 90s. PBFT was created to operate effectively in asynchronous systems. Its objective was to address issues with byzantine fault tolerance techniques (BFT) that were already in use.

PBFT aims to offer a viable Byzantine state machine replication (SMR) that continues functioning when malicious nodes are in the system. In a permissioned blockchain system with PBFT support, nodes are organized in a sequence, with one node as the primary (the leader node) and the others as secondary (or the backup nodes). It should be noted that any node in the permissioned network that qualifies can switch from secondary to primary status (typically, in the case of a primary node failure). All trustworthy nodes should contribute to applying the majority rule to decide on the blockchain’s state. In a permissioned blockchain, a PBFT operates under the restriction that the total number of malicious nodes cannot exceed one-third of all the nodes in the system. The system grows more secure as the number of trusted nodes increases.

Due to the presence of a leader node, this model resembles a “Commander and Lieutenant” style more than a pure Byzantine Generals’ Problem, where all generals are equal. Listed below are the 4 phases of this model that can be used in a permissioned blockchain:

• To initiate a service operation, a client requests the leader node.
• The request is broadcast to the backup nodes by the leader node.
• After carrying out the request, the nodes reply to the client.
• The client waits for f + 1 (where f is the maximum number of potentially flawed nodes) responses from various nodes with the same outcome. This is the result of the procedure.

Several variations were suggested and used to improve the quality and performance of PBFT for particular use cases and conditions. This approach is frequently utilized in a permissioned blockchain network backed by digital assets that don’t require a lot of capacity but handle many transactions. PBFT can be very helpful for low-latency storage systems and ensures the accuracy of the transaction records within the network.

Federated Byzantine Agreement (FBA)

With FBA systems, membership is open, control is decentralized, and each node need not be known and validated beforehand. In a permissioned blockchain network, nodes can decide which nodes to trust, and each node’s decisions lead to quorums that affect the entire system. The number of nodes necessary for a system to attain consensus is known as a quorum. FBAs employ “quorum slices.” A quorum slice is a subset of a quorum that can persuade a particular node to agree. Slices and quorums inside a permissioned blockchain network may arise dynamically since nodes have various configuration files. An idle quorum shares nodes, leading to overlapping quorums called Quorum intersection. The system produces “disjoint quorums” when quorums don’t intersect. Disjoint quorums are undesirable because they have the potential to separate and concurrently approve incompatible transactions, compromising the group’s consensus.

In Federated Consensus, each node in the blockchain network trusts a set of nodes (quorum) that help them reach the consensus stage. The quorum uses a single block generator to carry out the process efficiently, which receives, holds, and filters all the transactions that take place in the permissioned blockchain. The generator coordinates with the quorum for the block validation process, and the quorum will verify the block and fulfill certain conditions that the administrator of the blockchain network sets. Once the block generator receives confirmation from the network, the block will get published to the permissioned blockchain network.

FBA ledger can be accurate and up-to-date without all its nodes having to concur. Instead, a quorum is established by the decisions made by each node. While a quorum slice can persuade a single node of agreement, a quorum can persuade the entire system. A node may agree to follow the decisions made by a particular quorum slice if it believes the quorum slice to be completely trustworthy. This system ensures security and transparency in the permissioned blockchain network and is perfect for use cases like real-time KYC and cross-border remittances.

Round Robin Consensus

In the Round Robin Consensus, validators participate by signing votes for blocks. Prevotes, precommits, and commits are the primary voting forms. Receiving more than two third of commits is referred to as receiving commits from a two-thirds majority of validators. The permissioned blockchain network considers a block to be committed if a two-thirds majority of validators have signed and broadcast commits for that block.

In the permissioned blockchain, when the next block is generated, round-robin consensus uses a round process. The three phases—Propose, Prevote, and Precommit—and the two extra steps, Commit and NewHeight, make up each round. Each of the three steps—Propose, Prevote, and Precommit—takes up one-third of the time allotted for a particular round. Following a slight fixed rise in time, each round gets longer than the one before it. This enables the permissioned network to eventually reach a consensus with a small number of concurrent users.

The block validation process in the round-robin consensus method is not dependent on a single participant. With this paradigm, several nodes significantly impact transaction validation and signing. This distinguishes this procedure from other consensus processes and increases its security. The voting power distribution across trusted nodes also reduces the likelihood of double-spend attacks. The commerce, financial, and supply chain industries benefit greatly from round-robin consensus mechanisms.

RAFT

The Raft consensus algorithm works on the principle that the nodes (i.e., server computers) choose a leader, and the rest of the nodes follow. Under a permissioned blockchain network, the leader replicates state transition logs among the followers, presuming that every node is reliable and free of malicious intent.

Raft’s fundamental concept was inspired by the notion that we can use the Paxos algorithm to reach consensus in a distributed setting and choose a leader. It’s interesting to note that if the permissioned blockchain network has a leader, it prevents many proposers from submitting proposals. Raft states that each node in a permissioned blockchain network can replicate a state machine (server cluster) that can remain in any of the three states: leader, candidate, or follower. A node can remain in the three above-mentioned states under normal circumstances. Any requests made to the follower node are forwarded to the leader node; only a leader can communicate with the client. A candidate for leadership may solicit votes, and a follower exclusively responds to the leader or the candidate.

The Raft algorithm breaks time into tiny periods of arbitrary duration to maintain these server statuses in a permissioned blockchain. Each term is designated by a term number, which increases monotonically. Every node maintains this term number, which is transmitted when nodes communicate. Every term begins with an election to choose the new leader. The candidates ask other server nodes (followers) for their votes to gain the majority. If nodes vote for the candidate, they elect them to lead for the remainder of the term. Split votes occur when a majority is not reached, and the term ends with no leader. Thus, there can only be one leader every term.

Benefits of using permissioned blockchains

The benefits of permissioned blockchains are:

Efficiency and scalability: One key benefit of permissioned blockchains is scalability. The number of nodes that can join a permissioned blockchain network is often restricted, which helps speed up and improve the efficiency of transactions. The consensus mechanism employed in a permissioned blockchain may be lighter and more streamlined than those used in permissionless blockchains, necessitating a sizeable number of nodes to confirm transactions.

Easy customization: Permissioned blockchains also provide the advantage of customization and can effectively perform specific tasks since they are created for specific purposes. Also, the blockchain may be quickly modified to adapt to the changing needs of the company that owns it.

Controlled degree of transparency: Another benefit of permissioned blockchains is the controlled level of transparency. Using permissioned blockchains, the operator can choose the right degree of network transparency based on the use case. This can be crucial for companies or other organizations that need a certain amount of confidentiality or privacy.

Access: Permissioned blockchains can be advantageous for businesses that expect high levels of trust and security in their transactions since a central authority can regulate who can access the blockchain network.

Sensitive data security: Permissioned blockchain increases the security of sensitive data, as access to data is available to a selected set of members. This involves storing personal information, login information, identity credentials, etc., in a safe network; only limited people can access these sensitive data.

Energy efficiency: In a permissioned blockchain, a sort of private blockchain, the network’s energy efficiency can be increased. To confirm and approve transactions, permissioned blockchains rely on a pre-selected number of nodes to validate transactions. The network size and transaction volume of permissioned blockchains are often less than those of public blockchains because they are typically utilized for a particular enterprise or institutional application. Less energy is needed for network upkeep and transaction validation.

Empowering business: By offering businesses a safe and open platform to perform business activities, permissioned blockchains can potentially empower them. Permissioned blockchains can provide enterprises with a more targeted and specialized approach to meeting their business demands. Permissioned blockchains give users access to safe and transparent databases that streamline business processes, cut costs, and boost efficiency, allowing businesses to work together and share data in a safe and controlled way while preserving confidentiality and privacy.

High security: Permissioned blockchains are intended to offer stronger security than permissionless blockchains by limiting access to only authorized users. Only trustworthy parties can access and use this kind of blockchain since joining and executing transactions on the network require permissions, which protects network security. Only authorized users can access the blockchain, which lowers the possibility of private information being made public. Corporations and organizations that need to protect sensitive information typically use permissioned blockchains.

Transparency: Transparency can be balanced in a permissioned blockchain to meet the organization’s or network’s unique requirements. In a permissioned blockchain, everything is not visible to everyone, and the level of access can be altered depending on need.

Use cases of permissioned blockchains

A few real-time use cases of permissioned blockchains include the following:

Supply chain management

A permissioned blockchain can offer a secure and robust mechanism to track the movement of goods from the source to the end user in supply chain management. The blockchain can help to ensure transparency and traceability of goods, lowering the risk of fraud and counterfeiting by offering information that is only accessible to permitted participants. The transaction specification, such as the date, time, place, and quantity of items moved, can be recorded by each party involved in the supply chain. There is a high level of confidence in the correctness and integrity of the data because other participants in the network users can verify it. Furthermore, a permissioned blockchain can contribute to increased efficiency and lower costs by delivering real-time visibility into the flow of commodities. With the help of the data on the blockchain, participants may streamline their processes and choose how to handle logistics and inventory more wisely. Ultimately, a permissioned blockchain’s transparency, traceability, and efficiency can make it a potent tool for enhancing supply chain management.

Healthcare

Healthcare is a sector that handles delicate and private data, including patient health records, medical histories, and personal identity information. A permissioned blockchain can offer a safe method of storing and sharing this information among authorized parties. Patients can have control over their data via a permissioned blockchain and allow access to approved parties, including doctors, hospitals, insurance companies, and researchers. By encrypting the data and limiting access to authorized individuals, the blockchain can aid in ensuring the security and privacy of patient data. Additionally, by automating procedures like the processing of insurance claims and medical invoicing, the implementation of a permissioned blockchain can assist in lowering administrative expenses and errors. This can decrease the time and expenses related to manual processes while increasing the effectiveness of the healthcare system. By providing researchers with a safe and open mechanism to communicate data, a permissioned blockchain can also help advance medical research.

Financial services

Efficiency, security, and openness are paramount in the financial services sector. A permissioned blockchain can securely perform transactions between authorized participants, and financial organizations can build a permissioned blockchain with a transparent and irreversible record of all transactions. Since everyone involved has access to the same information and can confirm the legitimacy of each transaction, this can help to avoid fraud and lower the chance of errors. Additionally, implementing a permissioned blockchain can reduce transaction costs by automating procedures like settlement and clearing. By doing so, the financial system can operate more effectively and save time and money that manual operations typically incur. Implementing a permissioned blockchain can also increase transparency in the financial service industry by giving real-time visibility into transactions and eliminating the need for intermediaries. As a result, there is less chance of disagreements or delays brought on by inconsistencies in the transaction data.

How to create a permissioned blockchain?

In this section, you will learn how to create a permissioned blockchain with Substrate using the node authorization pallet. You may operate a configurable group of nodes for a network using the node-authorization pallet, which is a prebuilt FRAME pallet. Peer identification is used to identify each node (PeerId). Only one account owner (AccountId) for each peer identity claims the node.

There are two methods for approving a node to join the network:

• Include the peer identifier in the chain specification file’s list of preconfigured nodes as a part of the chain’s genesis setup. To do this, you need permission from the chain’s governance mechanism or access to the Sudo pallet’s root account on the network.
• By asking that particular node for a paired peer connection. Each node’s public and private keys can be used to generate peer identifiers, which can then be used to add connections between nodes.

Before starting, verify that you have configured your environment for Substrate development by installing Rust and the Rust toolchain. Let’s now look at the steps required to create a permissioned blockchain using Substrate.

Build the node template

Open a terminal shell on your computer.

Clone the node template repository by running the following command:

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

Change to the root of the node template directory, if necessary, by running the following command:

cd substrate-node-template

Switch to a working branch for the repository if you want to save your changes by running a command similar to the following:

git switch -c my-wip-branch

Compile the node template by running the following command:

cargo build --release

The node template should compile without any errors. If you encounter issues when you compile, you can try the troubleshooting tips in Troubleshoot Rust issues.

Add the node authorization pallet

A new pallet must first have certain information added to the configuration file that the compiler uses to create the runtime binary before it can be used.

The configuration parameters and dependencies that control what gets compiled into the final binary are defined for Rust applications in Cargo.toml file. Since the Substrate runtime compiles to both a native Rust binary with standard library functions and a WebAssembly (Wasm) binary without the standard library, the Cargo.toml file manages two crucial pieces of data:

• The location and version of the importable pallets are included in the list of runtime dependencies for the importable pallets.
• The elements in each pallet must be turned on when creating a native Rust binary. You can compile the runtime to include functions, types, and primitives that are otherwise missing when you build the WebAssembly binary by enabling the standard (std) feature set from each pallet.

See Dependencies in the Cargo manual for further details on adding dependencies to Cargo.toml files. Read Features in the Cargo manual for details on enabling and managing features from dependent packages.

Add node-authorization dependencies

Thenode-authorization palette should be added to the Substrate runtime as follows:

• Launch a terminal shell and navigate to the node template’s root directory.
• In a text editor, open the runtime/Cargo.toml configuration file.
• To make the pallet-node-authorization crate available to the node template runtime, locate the [dependencies]section and add it.

[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 line imports the dependency pallet-node-authorization and configures the crate with the following settings:

• When the runtime is being compiled, the pallet features are not, by default, enabled.
• The crate’s version identifier.
• The location of the pallet-node-authorizationcrate’s repository.
• A branch to use to get the crate.

To ensure that all pallets are compatible with one another, you should utilize the same branch and version information for all of them. Compiler issues may occur if pallets from separate branches are used. This example shows how to add pallets if the other pallets use branch = “polkadot-v0.9.28″in the Cargo.tomlfile.

Add the pallet-node-authorization/std features to the list of features to enable when compiling the runtime.

[features]
default = ['std']
std = [
 ...
 "pallet-node-authorization/std",    # add this line
 ...
]

This line specifies that the stdfeatures set should be compiled by default for this runtime. The std features from all pallets specified as dependencies are enabled when the runtime is built with the stdfeature set. The Build process for additional details on how the runtime is created as a native Rust binary includes the standard library and a WebAssembly binary that uses the no_std feature.

When you compile the runtime binary, you can encounter cannot locate function issues if you fail to update the features section in the Cargo.toml file.

Check that the new dependencies resolve correctly by running the following command:

cargo check -p node-template-runtime --release

Add an administrative rule

To simulate governance, you can set up the pallet to use the EnsureRootprivileged function, which can be called via the Sudo pallet. The node template comes with the Sudo pallet by default, allowing you to place calls using the root-level administrative account. You can employ more realistic governance-based checks in a production setting.

To enable the EnsureRoot rule in your runtime:

1. Launch a text editor and navigate to the file runtime/src/lib.rs
2. Add the following line to the document:

use frame_system::EnsureRoot;

Implement the Config trait

Config is a Rust trait that exists in every pallet. The Config trait determines the parameters and type requirements for the pallet.

Most pallet-specific code needed to add a pallet is implemented using the Config trait. Any pallet’s Rust documentation or source code can be used to evaluate the implementation requirements for that pallet. For instance, consult the Rust documentation for pallet_node_authorization::Config. to understand what you need to implement for the Configtrait in the node-authorization pallet.

For your runtime to use the node-authorization pallet:

• Open the runtime/src/lib.rs file in a text editor.
• Add the parameter_types section for the pallet using the following code:

parameter_types! {
 pub const MaxWellKnownNodes: u32 = 8;
 pub const MaxPeerIdLength: u32 = 128;
}

• Add the impl section for the Config trait for the pallet using the following code:

impl pallet_node_authorization::Config for Runtime {
 type RuntimeEvent = RuntimeEvent;
 type MaxWellKnownNodes = MaxWellKnownNodes;
 type MaxPeerIdLength = MaxPeerIdLength;
 type AddOrigin = EnsureRoot;
 type RemoveOrigin = EnsureRoot;
 type SwapOrigin = EnsureRoot;
 type ResetOrigin = EnsureRoot;
 type WeightInfo = ();
}

• Add the pallet to the construct_runtime macro with the following line of code:

construct_runtime!(
pub enum Runtime where
   Block = Block,
   NodeBlock = opaque::Block,
   UncheckedExtrinsic = UncheckedExtrinsic
 {
   /*** Add This Line ***/
   NodeAuthorization: pallet_node_authorization::{Pallet, Call, Storage, Event, Config},
 }
);

• Save the changes and close the file.
• Check that the configuration can compile by running the following command:

cargo check -p node-template-runtime --release

Add genesis storage for authorized nodes

The peer identifiers and account identifiers require some further settings before the network can be launched to employ node authorization. For instance, to get the PeerId’s bytes, you must add a new dependency for the bs58 library in the node/Cargo.tomlfile because the PeerId is encoded in bs58 format. The approved nodes are linked to predetermined accounts to maintain simplicity.

For approved nodes, configure Genesis storage as follows:

• In a text editor, open the node/Cargo.tomlfile.
• Find the [dependencies] section and include the bs58 library in the node template.

[dependencies]
bs58 = { version = "0.4.0" }

• Save the changes and close the file.
• In the text editor, open the node/src/chain_spec.rs file.
• Add genesis storage for authorized nodes to join the network using the following code:

use sp_core::OpaquePeerId; // A struct wraps Vec to represent the node `PeerId`.
use node_template_runtime::NodeAuthorizationConfig; // The genesis config that serves the pallet.

• Locate the testnet_genesis function that configures the initial storage state for FRAME modules. For example:

/// Configure initial storage state for FRAME modules.
fn testnet_genesis(
 wasm_binary: &[u8],
 initial_authorities: Vec<(AuraId, GrandpaId)>,
 root_key: AccountId,
 endowed_accounts: Vec,
 _enable_println: bool,
 ) -> GenesisConfig {

• Within the GenesisConfig declaration, add the following code block:

 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()
     ),
   ],
 },

NodeAuthorizationConfig in this code has a nodes property, a vector with a tuple of two elements. The OpaquePeerId is the first item in the tuple. Using the bs58::decode procedure, the human-readable PeerId, such as 12D3KooWBmAwcd4PJNJvfV89HwE48nwkRmAgo8Vy3uQEyNNHBox2 is transformed into bytes. The AccountId, which stands for the node’s owner, is the tuple’s second element. In this case, the preconfigured Alice and Bob are denoted as endowed accounts [0] and [1].

1. Save changes and close the file.

Verify that the node compiles

You are now prepared to check to see if the node compiles after finishing the code changes.

To compile the node:

• If necessary, navigate to the substrate-node-template directory’s root:
• Compile the node by running the following command:

cargo build --release

You can continue if there are no syntax errors. Run the cargo build command again after fixing errors using the compile output guidance.

Identify account keys to use

The nodes connected to the Alice and Bob accounts in the Genesis storage have already been set up. The subkey application allows you to generate and inspect your keys and inspect the keys connected to specified accounts. However, if you use the subkey generate-node-key command, your peer identifier and node key will be produced randomly and will not be the same as the keys used in this example. You can use the following keys for each account because we use preconfigured and well-known node keys.

Alice

Bob

The other two development accounts, Charlie and Dave don’t have any peer identities or well-known node keys specified in the genesis setup. You can access these accounts with the following keys for demonstration purposes.

Charlie

Dave

You can copy the node key and use the subkey inspect-node-key to check the peer IDs for Charlie and Dave. For instance, use a command like the one below to save Charlie’s node key to a file called charlie-node-key:

echo -n "3a9d5b35b9fb4c42aafadeca046f6bf56107bd2579687f069b42646684b94d9e" > charlie-node-key

You can then run the following command to verify the peer identifier:

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

The command displays the peer identifier for the Charlie node:

12D3KooWJvyP3VJYymTqG7eH4PM5rN4T2agk5cdNCfNymAqwqcvZ

If you create node keys for your account, you should save the peer identification to a file so that you may later feed it to subkey inspect-node-key or other commands.

Launch network nodes

The permissioned network may now be launched, and other nodes can be allowed to join using the node keys and peer identifiers for the predefined accounts.

You will launch four nodes in this course. All three of the nodes that are linked to predefined accounts are permitted to author and validate blocks. The fourth node is a sub-node that can only access a certain node’s data with the consent of that node’s owner.

Start the first node

To establish the first node, you can use the –alice commands shortcut for –name alice –validator since you have set up genesis storage to use the well-known node keys for Alice and Bob.

Initiate the first node by:

1. If required, launch a terminal window on your computer.
2. Go to the root directory where the Substrate node template was built.
3. 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

The –node-key option in this command specifies the key to be used for a secure network connection. The human-readable PeerId is likewise created internally using this key, as demonstrated in the previous section.

As you might have noticed, the command-line options used are:

1. For a local testnet, use the flag –chain=local (not the –devflag!).
2. –alice will give node the name Alice and turn it into a validator that can create and end blocks.
3. To designate a port for peer-to-peer communication, use –port
4. To assign a listening port for WebSocket connections, use –ws-port

Start the second node

The –bob command shortcut for –name bob –validator can be used to launch the second node.

To start the second node:

1. Activate a fresh terminal window on your computer.
2. Go to the root directory where the Substrate node template was built.
3. 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

You should start to see new blocks being authored and finalized in both terminal logs when both nodes have already been started.

Add a third node to the list of well-known nodes

The third node can be launched with the –name charlie command. The node-authorization pallet uses an off-chain worker to set up node connections. You must provide the command-line option to allow the off-chain worker since the third node is not a well-known node, and it will have the fourth node in the network configured as a read-only sub-node.

To start the third node:

1. Activate a fresh terminal window on your machine.
2. Go to the root directory where the Substrate node template was built.
3. Run the below-mentioned 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

You should observe that there are no connected peers for the node once it has started. The node has to have explicit authorization to connect because this is a permissioned network. The genesis chain_spec.rs file contained the configuration for the Alice and Bob nodes. A call to the Sudo pallet must be made manually to add additional nodes.

Authorize access for the third node

Here we are using the Sudo pallet for governance. Therefore, you can use the Sudo pallet to call the addWellKnownNode function provided by node-authorization pallet to add the third node. You can use the Polkadot/Substrate Portal application to keep things simple to access the Sudo pallet.

1. Open the Polkadot/Substrate Portal in a browser.
2. When you click Developer, choose Sudo.
3. Select addWellKnownNode under nodeAuthorization (node, owner).
4. Copy and paste the hex-encoded peer identifier for the node owned by Charlie after the required 0x prefix.
5. Make Charlie the owner of the node.
6. Click Submit Sudo.

Note that the Alice development account is the default root administrative account used as the sudo origin for this call in Authorize transaction; then click Sign and Submit.

To examine the most recent transactions, pick Explorer under Network and click.

You should see the Charlie node connecting to the alice and bob nodes and beginning to sync blocks after the transaction has been included in the block. The mDNS discovery technique, enabled by default in a local network, can be used to locate the three nodes. Ensure that any local firewalls are set up to permit mDNS.

You should disable it using the command-line option –no-mdnsif your nodes are not connected to the same local network.

Allow connections from a sub-node

Because this is a permissioned network, Charlie must configure his node to allow the connection from the node owned by Dave. You can use the Polkadot/Substrate Portal application to grant this permission.

This network’s fourth node won’t be used as a validator or included in the list of well-known nodes. Although it is a sub-node of the charlie node, the fourth node is held by the dave user account. Only by connecting to the node held by the charlie parent node can the sub-node access the network. It’s crucial to remember that the parent node is in charge of every sub-node that grants permission to connect to the network. The parent node owner manages access if the parent node needs to be deleted or audited.

As this is a permissioned network, Charlie needs to set up his node to permit connections from Dave’s node. To grant this access, use the Polkadot/Substrate Portal application.

To allow the sub-node to access the network:

1. Open the Polkadot/Substrate Portal in a browser.
2. Choose Extrinsics by clicking Developer.
3. Select nodeAuthorization and select addConnections(node, connections).
4. Copy and paste the hex-encoded peer identifier for the node owned by Charlie after the required 0x prefix.
5. For the connections parameter, copy and paste the hex-encoded peer identifier for the node owned by Dave after the required 0x prefix, then click Submit Transaction.
6. Review the transaction details, then click Sign and Submit.

Claim the sub-node

The node administrator should claim the peer identifier for his node before initiating the sub-node. You can submit a transaction to claim the node that belongs to the dave account using the Polkadot/Substrate Portal program.

1. Open the Polkadot/Substrate Portal in a browser.
2. Click Developer and select Extrinsics.
3. Select nodeAuthorization and select claimNode(node).
4. Copy and paste the hex-encoded peer identifier for the node owned by Dave after the required 0x prefix, then click Submit Transaction.
5. Review the transaction details, then click Sign and Submit.

Launch the sub-node

You can launch the sub-node after claiming the node peer identifier.

To launch the sub-node:

1. Open a fresh terminal window on your machine.
2. Go to the root directory where the Substrate node template was built.
3. Use 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

Allow connections to the sub-node

A network with four nodes exists at this point. You must set up the sub-node to accept connections from Charlie’s parent node to allow it to participate. The procedures are the same as those you did to permit connections from Dave’s node.

1. Open the Polkadot/Substrate Portal in a browser.
2. Click Developer and select Extrinsics.
3. Select nodeAuthorization and select addConnections(node, connections).
4. Copy and paste the hex-encoded peer identifier for the node owned by Dave after the required 0x prefix.
5. For the connections parameter, copy and paste the hex-encoded peer identifier for the node owned by Charlie after the required 0x prefix, then click Submit Transaction.
6. Review the transaction details, then click Sign and Submit.

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

Keys required to submit transactions

It’s important to remember that any account can be used to sign and submit transactions impacting other nodes’ behavior. On the other hand, to sign and submit a transaction that impacts a node you do not own:

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

All nodes have access to the signing keys for the development account. As a result, using an account to act on behalf of Charlie or Dave, you could sign and submit transactions that impacted any connected node. Node operators would most likely only have access to their node keys if you were developing a permissioned network for a real-world application, and node owner accounts would be required to sign and submit transactions that pertain to the node where they had control of the signature key.

Endnote

Permissioned blockchains offer a secure and transparent way to manage and verify transactions among trusted parties. With its centralized control and access restrictions, permissioned blockchains provide greater efficiency and privacy while maintaining the system’s integrity. The technology is being adopted by various industries, including finance, healthcare, and supply chain management, to streamline processes and reduce costs. While there are challenges to implementing and maintaining a permissioned blockchain, such as ensuring consensus and managing governance, the potential benefits make it a promising solution for businesses and organizations looking to enhance their operations. As technology continues to evolve and mature, we can expect to see even greater adoption and innovation in the field of permissioned blockchains.

Want to create a permissioned blockchain? Connect with our experts at LeewayHertz for the development and deployment of your permissioned blockchain.