How to create a permissioned blockchain.pdf

1/14
April 3, 2023
How to create a permissioned blockchain?
leewayhertz.com/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?
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

2/14
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.

3/14
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.

4/14
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

5/14
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.
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.

6/14
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

7/14
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
{

8/14
/*** 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()

9/14
),
],
},
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
Key type Key value
Node key c12b6d18942f5ee8528c8e2baf4e147b5c5c18710926ea492d09cbd9f6c9f82a
Peer identifier generated
from the node key
12D3KooWBmAwcd4PJNJvfV89HwE48nwkRmAgo8Vy3uQEyNNHBox2
Peer identifier decoded to
hex
0x0024080112201ce5f00ef6e89374afb625f1ae4c1546d31234e87e3c3f51a62b91dd6bfa57df
Bob
Key type Key value
Node key 6ce3be907dbcabf20a9a5a60a712b4256a54196000a8ed4050d352bc113f8c58
from the node key
12D3KooWQYV9dGMFoRzNStwpXztXaBUjtPqi6aU76ZgUriHhKust
Peer identifier decoded
to hex
0x002408011220dacde7714d8551f674b8bb4b54239383c76a2b286fa436e93b2b7eb226bf4de7
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
Key type Key value
Node key 3a9d5b35b9fb4c42aafadeca046f6bf56107bd2579687f069b42646684b94d9e

10/14
from the node key
12D3KooWJvyP3VJYymTqG7eH4PM5rN4T2agk5cdNCfNymAqwqcvZ
Peer identifier decoded
to hex
0x002408011220876a7b4984f98006dc8d666e28b60de307309835d775e7755cc770328cdacf2e
Dave
Key type Key value
Node key a99331ff4f0e0a0434a6263da0a5823ea3afcfffe590c9f3014e6cf620f2b19a
from the node key
12D3KooWPHWFrfaJzxPnqnAYAoRUyAHHKqACmEycGTVmeVhQYuZN
Peer identifier decoded to
hex
0x002408011220c81bc1d7057a1511eb9496f056f6f53cdfe0e14c8bd5ffca47c70a8d76c1326d
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

11/14
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.
3. Use the following command to launch the second node:
--chain=local
--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.
3. Run the below-mentioned command to launch the third node:
--chain=local
--name charlie
--node-key=3a9d5b35b9fb4c42aafadeca046f6bf56107bd2579687f069b42646684b94d9e
--port 30335
--ws-port=9946
--offchain-worker always

12/14
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:
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.
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.
Launch the sub-node

13/14
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.
3. Use the following command to launch the sub-node:
--chain=local
--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.
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.
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.

How to create a permissioned blockchain.pdf

Recommended

Recommended

More Related Content

Similar to How to create a permissioned blockchain.pdf

Similar to How to create a permissioned blockchain.pdf (20)

More from StephenAmell4

More from StephenAmell4 (20)

Recently uploaded

Recently uploaded (20)

How to create a permissioned blockchain.pdf