DEV Community: Mrityunjaya Prajapati

How Enterprise Wallet Infrastructure Actually Works: MPC, Custody Models, and Why MetaMask Was Never the Answer

Mrityunjaya Prajapati — Sat, 28 Mar 2026 14:42:06 +0000

A technical deep-dive into what it actually takes to build wallet infrastructure for banks, fintechs, and financial institutions — from key management to compliance to multi-chain architecture.

Every week I talk to developers building on-chain financial products. And almost without fail, the conversation hits the same wall: key management.

Not smart contracts. Not tokenomics. Not gas optimisation. Key management.

Because the moment you try to build a wallet product that works for a bank, a fintech, or any financial institution serving real users — you discover that the entire existing ecosystem was designed for a completely different problem. MetaMask was built for a developer who wants to interact with DeFi protocols. It was never built for a fintech serving 10 million users in Maharashtra who should never see the word "blockchain."

This article is a technical breakdown of what enterprise wallet infrastructure actually requires: the custody models, the MPC architecture, the compliance layer, and the multi-chain problem. By the end, you should be able to make an informed decision about which approach fits what you're building — and understand why most existing WaaS tools fall short.

Prerequisites
Basic familiarity with blockchain concepts (private keys, transaction signing, smart contracts). This article goes deep on architecture — if you want the non-technical business case, the link to the newsletter edition is in the footer.

Why the Old Wallet Model Was Always Wrong for Enterprise

The crypto wallet model from 2017–2023 had one fundamental design assumption: the user is also the operator. The person using the wallet is the same person who understands seed phrases, manages private keys, and accepts full responsibility for key security.

That assumption breaks immediately in any enterprise context.

A bank cannot tell its customers "here is a 24-word seed phrase, please store it safely." A fintech cannot build a product where one customer support call results in someone accidentally approving a transaction with no recourse. A corporate treasury cannot have a single employee hold the private key to $50M in on-chain assets.

The enterprise wallet problem has fundamentally different requirements:

Wallet creation at scale — millions of wallets, sub-second, no user interaction with keys
Compliance baked in — KYC, sanctions screening, spending limits, audit trails
Operational roles — treasury, compliance, support all have different access levels
Disaster recovery — if a key shard is lost, funds must be recoverable
Multi-chain — one user, multiple chains, one unified interface
Regulatory audit — every transaction signed must be attributable and logged

None of these were considerations in MetaMask's design. And that's fine — it wasn't built for this. But it means the enterprise wallet is a completely different engineering problem from the consumer wallet.

The Three Custody Models — Trade-offs You Need to Understand

Before picking an architecture, you need to choose a custody model. This decision flows downstream into every other design choice you make.

Custodial: Simple to build, dangerous at scale
In a custodial model, your company holds the private keys. The user has a database record — an account ID — and you sign transactions on their behalf. This is how early crypto exchanges worked. It's also how traditional fintech apps work (you don't hold your money in a Paytm vault; Paytm does).

Why it's tempting: Easy to build. Fast wallet creation. Full control over compliance enforcement. No key management complexity for users.

Why it breaks at enterprise scale: Your HSM or key vault becomes the single most critical system you own. A breach means every user's funds are at risk simultaneously. Regulators in most jurisdictions are also increasingly hostile to custodial crypto models — you're essentially running a bank without a banking license.

Self-custody: Correct philosophy, wrong UX
Self-custody (MetaMask, hardware wallets, seed phrases) is philosophically correct — the user controls their own keys, nobody can freeze their funds, and there's no counterparty risk. But it fails for mass-market financial products for one simple reason: users lose their keys.

The support ticket "I lost my seed phrase" has no resolution in a pure self-custody model. That's fine for a crypto-native developer. It's a catastrophic product flaw for a fintech serving 10 million retail users.

MPC: The enterprise standard
Multi-Party Computation (MPC) wallets split the private key into cryptographic shards — pieces of the key that are mathematically useless on their own but can produce a valid signature when a threshold number of shards cooperate. A common configuration is 2-of-3: any two of three key shards can produce a valid signature without the third shard ever being exposed.

This is now the dominant model for enterprise wallet infrastructure and for good reason — it eliminates single points of failure while giving the operator enough control to enforce compliance.

How MPC Signing Actually Works

Understanding the mechanics of MPC is important because it determines your architecture decisions downstream. Here's the signing flow:

The key insight: the private key is never reconstructed in full at any point. MPC protocols (like GG20, DKLS, or CGGMP) use cryptographic techniques where each shard holder performs a computation on their shard, and the results are combined to produce a valid signature — without any party ever seeing a complete private key.

This is fundamentally different from a Shamir's Secret Sharing approach where shards are combined to reconstruct a key before signing. MPC signs without reconstruction, which means there is no moment of vulnerability.

// Simplified MPC wallet creation — what the API looks like
// The complexity of shard generation happens in the MPC library

const wallet = await mpcClient.createWallet({
  userId: 'user_9f2a3b',
  threshold: { signers: 2, of: 3 },
  shards: [
    { holder: 'company-hsm',   endpoint: process.env.HSM_ENDPOINT },
    { holder: 'cloud-kms',      endpoint: process.env.KMS_ENDPOINT },
    { holder: 'user-device',    deviceKey: userPublicKey }
  ],
  chains: ['ethereum', 'polygon', 'solana'],
  compliance: {
    jurisdiction: 'IN',
    kycLevel: 'full',
    spendingLimit: { daily: 100000, currency: 'INR' }
  }
});

// wallet.address is now live on all specified chains
// No seed phrase. No user key management. Sub-second creation.
console.log(wallet.addresses);
// { ethereum: '0x...', polygon: '0x...', solana: 'So...' }

The Compliance Layer — Why It Must Be in the Wallet, Not Above It

This is the architectural mistake I see most often. Teams build a wallet infrastructure layer and then bolt compliance on top — as a middleware that checks rules before passing transactions to the wallet service.

That's backwards. Compliance must be enforced at the wallet level, not above it. Here's why:

The bypass problem
If compliance is enforced in an API layer above the wallet, any internal team member or compromised service with direct wallet access can bypass it. When a regulator asks you to demonstrate your compliance controls, "we check before calling the wallet API" is not an acceptable architecture.

Enterprise wallet infrastructure needs compliance baked into the signing process itself. A transaction that violates a spending limit should fail at the wallet layer — not be rejected by middleware, not return a 403 from an API, but genuinely fail to produce a valid signature.

// Compliance rules enforced at wallet signing time — not in API middleware

class ComplianceAwareWallet {
  async sign(transaction, walletId) {

    // 1. Sanctions screening — check before signing
    const sanctionsResult = await this.sanctions.screen({
      to: transaction.to,
      lists: ['OFAC', 'UN', 'EU']
    });
    if (sanctionsResult.hit) throw new SanctionsViolationError();

    // 2. Spending limit check against daily/monthly rolling window
    const spent = await this.ledger.getDailySpend(walletId);
    if (spent + transaction.value > this.limits.daily) {
      throw new SpendingLimitError(`Daily limit: ${this.limits.daily}`);
    }

    // 3. Role check — does this signer have authority for this txn size?
    const role = await this.rbac.getRole(transaction.initiator);
    if (transaction.value > role.maxSingleTxn) {
      throw new AuthorizationError('Requires dual approval');
    }

    // 4. Only now proceed to MPC signing
    const signature = await this.mpc.sign(transaction);

    // 5. Immutable audit log — written atomically with the signature
    await this.auditLog.record({
      txnHash: transaction.hash,
      walletId, initiator: transaction.initiator,
      timestamp: Date.now(),
      complianceChecks: ['sanctions', 'spending-limit', 'rbac'],
      jurisdiction: this.config.jurisdiction
    });

    return signature;
  }
}

The Enterprise Wallet Stack — Full Architecture

Putting all the pieces together, a production enterprise wallet infrastructure looks like this:

The Multi-Chain Problem Nobody Talks About

One of the most underappreciated engineering challenges in enterprise wallet infrastructure is multi-chain support. It sounds simple — just support multiple blockchains. In practice, it's a deep architectural problem.

Different chains have different:

Account models (EVM uses accounts, Solana uses programs, UTXO chains use inputs/outputs)
Transaction formats (different serialisation, gas models, fee structures)
Nonce management approaches (EVM nonces are sequential and must be managed carefully at high throughput)
Signature schemes (ECDSA secp256k1 on Ethereum, Ed25519 on Solana — your MPC library must support both)
Finality assumptions (probabilistic on PoW, deterministic on PoS — matters for enterprise settlement)

The correct architecture is a chain adapter pattern — a common interface that your wallet service calls, with chain-specific adapters implementing the interface for each supported network.

// Chain adapter interface — implemented per chain
interface ChainAdapter {
  buildTransaction(params: TxnParams): Promise<UnsignedTxn>;
  estimateFee(txn: UnsignedTxn): Promise<FeeEstimate>;
  broadcast(signedTxn: SignedTxn): Promise<TxnHash>;
  getBalance(address: string): Promise<Balance>;
  waitForFinality(hash: TxnHash): Promise<Receipt>;
}

// Ethereum adapter — handles EVM nonce management, gas estimation
class EthereumAdapter implements ChainAdapter {
  async buildTransaction(params) {
    const nonce = await this.nonceManager.getAndIncrement(params.from);
    const gasPrice = await this.provider.getGasPrice();
    return { ...params, nonce, gasPrice, chainId: 1 };
  }
}

// Solana adapter — completely different model, Ed25519 signatures
class SolanaAdapter implements ChainAdapter {
  async buildTransaction(params) {
    const blockhash = await this.connection.getLatestBlockhash();
    // No nonces — Solana uses recent blockhash for replay protection
    return new Transaction({ ...params, recentBlockhash: blockhash.blockhash });
  }
}

Custody Model Comparison — Making the Right Choice

What MetaMask Was Actually Designed For

None of this is a criticism of MetaMask. It was designed for a specific and legitimate use case: giving a developer or crypto-native user a browser-based interface to sign transactions and interact with DeFi protocols.

For that use case, it is excellent. The problem is that the industry — particularly in the 2020–2023 period — treated it as a template for all wallet products. "Users need a wallet, MetaMask is a wallet, therefore build like MetaMask."

The wallet is not the product. Finance is the product. The wallet is how finance happens on-chain — and for most financial products, it needs to be completely invisible to the end user.

The fintech user in Maharashtra should tap "send" and the money moves. They should not know what a private key is. They should not manage a seed phrase. They should have the same expectation of reliability, support, and recourse that they have with UPI.

Building that experience requires enterprise wallet infrastructure — not a consumer crypto wallet bolted onto a fintech app.

Tools and Libraries Worth Evaluating

If you're building enterprise wallet infrastructure today, here are the main options in each category:

MPC libraries
GG20 (Zengo's implementation), DKLS (Coinbase's threshold ECDSA), Fireblocks MPC-CMP, and ZenGo-X (open source). For production, evaluate whether you want to run your own MPC nodes or use a managed service.

WaaS providers to evaluate
Tresori, Privy, Dynamic, Turnkey, Capsule, and Web3Auth all offer different trade-offs between control and convenience. Fireblocks and TreSori are more enterprise-grade with higher ACV. Evaluate based on your compliance requirements and whether you need on-premise key shards.

Compliance tooling
Chainalysis and Elliptic for transaction monitoring and sanctions screening. Persona and Sardine for KYC at wallet creation. TRM Labs for blockchain risk scoring. Most WaaS providers have integrations with at least one of these.

The Scaling Challenges to Design For

Before I close, here are the scaling problems that will hit you in production that most architecture articles don't mention:

Nonce management at high throughput. On EVM chains, nonces must be sequential and non-repeating. If you're creating thousands of transactions per second from a hot wallet, nonce management becomes a critical bottleneck. You need a distributed nonce manager with optimistic locking — not a simple database increment.

MPC latency under load. MPC signing involves multiple network round-trips between shard holders. Under high load, this latency compounds. Design your signing service to handle this asynchronously with a transaction queue — don't make users wait synchronously for MPC completion on non-urgent transactions.

Key rotation without downtime. MPC keys need periodic rotation for security. Your architecture must support key rotation without interrupting wallet functionality — this requires careful state management across all shard holders simultaneously.

Chain re-org handling. When a blockchain re-organises (common on PoW chains, possible but rare on PoS), transactions you thought were confirmed can be reversed. Your finality layer must handle this gracefully — especially critical for payment settlement where you've already credited a user's account.

The operational reality
Enterprise wallet infrastructure is not a weekend project. A production-grade system with MPC, compliance, multi-chain support, and the scaling characteristics described above takes a well-resourced team 6–12 months to build properly. Evaluate WaaS providers seriously before deciding to build — the build vs buy decision here is not as obvious as it might seem.

The shift from consumer crypto wallets to enterprise wallet infrastructure is not an incremental improvement — it's a ground-up rethink of what a wallet is and who it serves. The engineering challenges are real, the compliance requirements are non-negotiable, and the UX bar is set by UPI, not by MetaMask.

If you found this useful, the next article in this series goes deep on the compliance architecture — specifically how to design jurisdiction-aware transaction rules that scale across markets without becoming a compliance nightmare to maintain.

KS Wallet as the Backbone of Cross-Chain Bridges and Interoperability

Mrityunjaya Prajapati — Sun, 24 Aug 2025 15:41:53 +0000

In the rapidly expanding Web3 ecosystem, interoperability is no longer a “nice-to-have” but a critical infrastructure requirement. Users want to seamlessly move assets, tokens, and data across multiple blockchains without friction. At the center of this challenge lies the wallet infrastructure — and this is where KS Wallet emerges as the backbone for cross-chain bridges and interoperability.

Why Wallet Infrastructure Matters for Interoperability

Most cross-chain solutions today face challenges like:

Complex UX – Multiple wallets for different chains.

Security Risks – Bridges are common targets for exploits.

High Gas Costs – Users bear complex, chain-specific fees.

Limited Monitoring – Lack of unified transaction analytics.

KS Wallet provides a multi-chain, modular wallet infrastructure that solves these challenges with self-custody, custodial, and MPC (Multi-Party Computation) models.

KS Wallet Architecture for Cross-Chain Bridges

Core Components:

Wallet Creation Layer: Generate wallets across multiple chains.

Transaction Relay Layer: Abstracts gas & routes cross-chain transactions.

Bridge Connectors: Securely interact with bridge protocols.

Monitoring & Analytics Layer: Unified visibility across chains.

Security Layer: MPC + Policy controls for enterprises.

Flow: Cross-Chain Transaction via KS Wallet

User signs transaction in KS Wallet (self-custody / custodial / MPC).
Transaction relay service handles gas abstraction (gasless option).
Bridge connector locks/mints assets on Chain A → issues wrapped asset on Chain B.
Monitoring engine logs and verifies transaction on both chains.
Analytics layer provides insights (fees, confirmation, settlement status).

Security Advantages

MPC-based Wallets – Eliminate single point of failure.
Policy-Based Controls – Enterprise-grade approval workflows.
On-Chain Transparency – Every bridge transaction traceable.
AI-driven Anomaly Detection – Early alerts on suspicious activity.

Use Cases of KS Wallet in Cross-Chain Interoperability

Bridging Stablecoins (USDC, USDT) across chains
DeFi Liquidity Transfers – Seamless movement of LP tokens between ecosystems
NFT Portability – Move game/NFT assets across L1s & L2s
Supply Chain Tokens – Multi-chain tracking of tokenized goods

Example: Multi-Chain Bridge with KS Wallet

Imagine a USDC Bridge:

User deposits USDC on Ethereum.
KS Wallet triggers bridge protocol via connectors.
Wrapped USDC minted on Polygon.
Entire flow recorded in KS Wallet analytics dashboard.

Conclusion

Cross-chain bridges are essential, but without a robust wallet infrastructure, interoperability remains fragile. KS Wallet provides the secure, scalable, and developer-friendly backbone to enable seamless multi-chain transfers with gasless transactions, analytics, and enterprise-grade security.

By abstracting complexity and ensuring transparency, KS Wallet is not just a wallet — it’s the foundation of Web3 interoperability.

How To Install Docker on Ubuntu 20.04

Mrityunjaya Prajapati — Mon, 20 Jun 2022 15:44:24 +0000

Docker is an application that simplifies the process of managing application processes in containers. Containers run your applications in resource-isolated processes. Containers are similar to virtual machines, but they are more portable, resource-friendly, and dependent on the host operating system.

In this tutorial, we will install Docker on Ubuntu 20.04 and use basic commands to get you started.

Prerequisites

Ubuntu 20.04 Installed on 64-bit operating system
A user account with sudo privileges

Installing Docker from Official Repository

Step 1: Updating the Software Repository

sudo apt update

Step 2: Downloading Dependencies

sudo apt-get install apt-transport-https ca-certificates curl software-properties-common

Step 3: Adding Docker’s GPG Key

curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo apt-key add -

Step 4: Installing the Docker Repository

sudo add-apt-repository "deb [arch=amd64] https://download.docker.com/linux/ubuntu $(lsb_release -cs) stable"

Step 5: Installing the Latest Docker

sudo apt-get install docker-ce

Step 6: Verifying Docker Installation

docker --version

Step 7: Enable Docker Service

To start the Docker service run the following commands:

sudo systemctl start docker

Enable Docker to run at startup with:

sudo systemctl enable docker

To check the status of the service, use the command:

sudo systemctl status docker

If this tutorial helps you, please hit the Clap button or comment if you have any suggestion or feedback.

How To Install Hyperledger Fabric v2.4 on Ubuntu 20.04

Mrityunjaya Prajapati — Sun, 19 Jun 2022 18:11:51 +0000

Hyperledger Fabric is one of the leading enterprise grade blockchain platforms. In this article we will cover Prerequisites and Hyperledger Fabric v2.4 installation on Linux Ubuntu 20.04 LTS.

Step 1: Install curl, git

Install the latest version of git and curl if it is not already installed.

sudo apt update sudo apt-get install git sudo apt-get install curl

Step 2: Install Docker

Install the latest version of Docker if it is not already installed.

sudo apt-get -y install docker-compose

Once installed, confirm that the latest versions of both Docker and Docker Compose executables were installed.

docker --version Docker version 20.10.12, build 20.10.12-0ubuntu2~20.04.1

docker-compose --version docker-compose version 1.25.0, build

Make sure the Docker daemon is running.

sudo systemctl start docker

Optional: If you want the Docker daemon to start when the system starts, use the following:

sudo systemctl enable docker

Add your user to the Docker group.

sudo usermod -a -G docker <username>

Step 3: Install Golang

curl -O https://dl.google.com/go/go1.18.3.linux-amd64.tar.gz tar xvf go1.18.3.linux-amd64.tar.gz export GOPATH=$HOME/go export PATH=$PATH:$GOPATH/bin

Now, you have to open and edit you **bashrc **file. In most cases, the bashrc is a hidden file that lives in your home directory.

nano ~/.bashrc

Add following two lines, at the end of the file:

export GOPATH=$HOME/go export PATH=$PATH:$GOPATH/bin

Create new directory where you will install Hyperledger Fabric

mkdir fabric-network

Step 4: Install Hyperledger Fabric

To download a specific release, pass a version identifier for Fabric and Fabric CA Docker images. The command below demonstrates how to download the latest production releases - Fabric v2.4.4 and Fabric CA v1.5.3

curl -sSL https://bit.ly/2ysbOFE | bash -s -- <fabric_version> <fabric-ca_version>

curl -sSL https://bit.ly/2ysbOFE | bash -s -- 2.4.4 1.5.3

Download the latest release of Fabric samples, docker images, and binaries.

curl -sSL https://bit.ly/2ysbOFE | bash -s

Congrats, you have installed Hyperledger Fabric with all dependencies.

To test the our installation, we will run test network that comes with fabric-samples

cd fabric-samples/test-network ./network.sh up createChannel -ca -c mychannel -s couchdb

The above command will create a channel(mychannel) with certificate Authorities and bring up couch-db as state database.

Using following Docker command we can check all running containers

docker ps -a

You should be able to see the containers up and running.

Congratulations, you have installed and setup Hyperledger Fabric.

If this tutorial helps you, please hit the Clap button or comment if you have any suggestion or feedback.

How to set or get default timezone in PHP

Mrityunjaya Prajapati — Tue, 14 Jun 2022 18:46:05 +0000

In this tutorial, we will explain how to set or get a default timezone in PHP. This will help you to change the default timezone for all date and time in PHP

Using php built-in function date_default_timezone_set() and date_default_timezone_get() we can set and get default timezone respectively.

You can check detail article at: https://tagstack.org/article/how-to-set-or-get-default-timezone-in-php

Are you working on any Side Project?

Mrityunjaya Prajapati — Tue, 14 Jun 2022 17:59:33 +0000

I think Side Project is not just to start your Startup, it might be for your new learning.

If you want to learn any new technology, my suggestion is that develop a mini project or MVP product. This product you can host in your Github or launch as a Startup.

If you guys have any other thoughts, please share!!

How to Install Golang on WSL/WSL2

Mrityunjaya Prajapati — Mon, 13 Jun 2022 18:30:16 +0000

One of the best feature that Windows 10 or 11 Pro support is WSL or WSL2, using this you can run any Linux OS like a windows application.

If you want to install GoLang on WSL/WSL2 and setup your development environment, please follow these steps

Check Latest Go Version

You can check latest Go Version for any OS like: Linux, macOS or Windows at https://go.dev/dl/

Install Go

At the time of writing this blog, the most recent LTS version of Go is 1.18.3.

wget https://dl.google.com/go/go1.18.3.linux-amd64.tar.gz sudo tar -xvf go1.18.3.linux-amd64.tar.gz sudo mv go /usr/local

Edit .bashrc file

You have to edit .bashrc file before making further changes, you can follow below steps to open .bashrc file

cd ~ explorer.exe .

Open .bashrc file and add following lines at the bottom and save the file.
export GOROOT=/usr/local/go export GOPATH=$HOME/go export PATH=$GOPATH/bin:$GOROOT/bin:$PATH

Refresh your terminal using **bash **command

Check Go Version

go version

Make sure it returns the same version that you installed.

How to Install Redis on Linux Server (Ubuntu 20.04)

Mrityunjaya Prajapati — Sat, 11 Jun 2022 12:56:42 +0000

What is Redis Cache

Redis is an open-source in-memory key-value data store. It can be used as a database, cache and queue. Redis supports various data structures such as Strings, Hashes, Lists, Sets, and more. Redis can provide high availability using Redis Node Cluster.

Install Redis on Ubuntu 20.04

You can install Redis on Linux Server using following commands

$sudo apt update $sudo apt install redis-server

Once the installation is done, then Redis service will start automatically. You can check the status of the Redis service using following command:

$sudo systemctl status redis-server

You will get following output

redis-server.service - Advanced key-value store Loaded: loaded (/lib/systemd/system/redis-server.service; enabled; vendor preset: enabled) Active: active (running) since Sat 2022-06-11 12:15:20 UTC; 20s ago ...

Test Redis Server Locally

To verify that everything is set up properly, you can try to ping the Redis server from your server using the redis-cli command:
redis-cli -h <REDIS_IP_ADDRESS> ping

If you are testing locally from server then, this *REDIS_IP_ADDRESS * would be 127.0.0.1

Above command should return a response of PONG

Test Redis Server Remotely

To verify that everything is set up properly, you can try to ping the Redis server from your Remote Machine using the redis-cli command:

redis-cli -h <REDIS_IP_ADDRESS> ping

REDIS_IP_ADDRESS would be your Server Public IP Address where Redis is installed.

Above command should return a response of PONG

*IMPORTANT *– Redis run on port: 6379 so you have to open this Port to communicate from Remote machine.

Deploy Nest JS App using PM2 on Linux (Ubuntu) Server

Mrityunjaya Prajapati — Sat, 11 Jun 2022 11:14:35 +0000

In this article, I will cover steps that will help you to deploy Nest JS application on Linux Server. I am using Ubuntu 20.04 LTS **during writing this article and I am assuming you have already installed **Node.js on your server.

Step 1 (Install Nest JS CLI)

Generally, we use npm i command to run all the dependencies but that will not install Nest JS so we have to manually install Nest JS CLI

$ sudo npm i -g @nestjs/cli

Step 2 (Install PM2)

If you didn’t install PM2 earlier then you have to use following command to install PM2.

$ sudo npm install pm2@latest -g

If you want to get more details about PM2 commands, then please visit url: PM2 Commands

Step 3 (Clone Code Repository)

You can clone your repo using following command and install necessary dependencies. If you want more details on Cloning, please refer article: Clone Specific Git Branch

$ git clone http://coderepo.com/projectname.git $ cd projectname $ npm install

Step 4 (Build Project)

For Nest JS app, you have to first generate a build then only you can run the project on server.

$ npm run build

Step 5 (Run Project)

If build is generated successfully then will create /dist folder under root directory. Now you can run your project using following PM2 command

$ pm2 start dist/main.js --name <application_name>

application_name you can use to give unique app name so that you can easily identify your apps in pm2 list.

There are some PM2 commands to make your application auto restart after system reboot also

$ pm2 startup systemd $ pm2 save

Conclusion

I hope this article will help you deploy your Nest JS application on Linux Server. If you liked the solution, please hit the Clap button or comment if you have any suggestion or feedback.

Hyperledger Fabric - High Level Overview

Mrityunjaya Prajapati — Sat, 11 Jun 2022 06:50:16 +0000

What is Hyperledger Fabric

Hyperledger Fabric is an open source, permissioned blockchain framework, started in 2015 by The Linux Foundation. It has modular or component-based architecture that can accommodate wide range of use cases, such as track-and-trace of supply chains, trade finance, loyalty and rewards, as well as clearing and settlement of financial assets.

What is Blockchain

As per definition Blockchain is an immutable distributed ledger that records the transaction in Decentralized environment. Blockchain technology consist of three main components: distributed ledger, consensus algorithm and smart contracts

There are 3 types of Blockchain:

Public Blockchain
Private Blockchain
Consortium Blockchain

Benefits of Hyperledger Fabric

Open Source: Hyperledger Fabric platform is an open source blockchain framework hosted by The Linux Foundation. It has an active and growing community of developers.

Permissioned network: It establishes decentralized trust in a network of known participants rather than an open network of anonymous participants. It means all participating member’s identities are known and authenticated.

Pluggable architecture: It has pluggable architecture that helps industry adoption and develop various use cases. You can easily customize any component of fabric

Developer Friendly: Developer can write smart contract on any language like: GoLang, Node.js, TypeScript so Developers don’t have learn new language to write smart contract

Hyperledger Fabric Components

Assets: An asset is anything that has value. An asset has state and ownership. Assets are represented in Hyperledger Fabric as a collection of key-value pairs.

Peers: Peers are a fundamental element of the network because they host ledgers and smart contracts. A peer executes chaincode, accesses ledger data, endorses transactions, and interfaces with applications.

Committing peers: It commits transactions and maintains the ledger & state.

Endorsing peers: It receives transactions for endorsement, and it verifies whether the transaction fulfils all the necessary and sufficient conditions. Thereby the Endorsing peer responds by granting or denying the endorsement.

Ordering service or Orderers: It approves the inclusion of blocks into the ledger. It communicates with peers and endorsing peers. It provides a shared communication channel to clients and peers over which the transaction can be broadcasted.

Channels: Channels are a logical structure formed by a collection of peers. This capability allows a group of peers to create a separate ledger of transactions. It is used to restrict access to the transaction with involved parties. It means clients only can see the messages and their associated transactions of the channels they are connected to and are unaware of other channels.

Organizations: Organizations is the container for the peers and respective certificate authorities (CA). Each organization has its own CA and a list of peers. Usually, organizations are used for physical separation of the blockchain network where each organization can set up their own physical machines and join the network.

Membership Services Provider (MSP): The MSP is implemented as a Certificate Authority to manage certificates that used to authenticate member identity and roles. It is used for verifying ownership in the network. Each certificate authority is tied to an organization.

Smart contract: Hyperledger Fabric smart contracts are called chaincode. Chaincode is program that defines assets and related transactions; it contains the business logic of the system. Chaincode can be invoked whenever an application needs to interact with the ledger, Chaincode can be written in Golang or Node.js.

source: IBM

Hyperledger Fabric Workflow

1. Creating of Transaction Proposal: Imagine a trade, such as a deal between an two parties. The life of this transaction begins with its inception by a peer node. The client connects to a Hyperledger Fabric network using the Node.js or Java SDK. Using the SDK API, the client creates a transaction proposal and sends it to the endorsing peer for verification

2. Endorsement of transaction: Each endorsing peer executes the proposal (a function defined within the chaincode) and returns the negative or positive response. The responses and results from the chaincode are returned to the client.

3. Submission to orderer peers: If the transaction is endorsed, the client submits the transaction to the ordering service (group of ordering peers/nodes), which uses consensus to order the transaction into a block within the ledger. Otherwise, the transaction is cancelled.

4. Commitment of transaction: Once ordered, the stored transaction block is sent to all of the peers as part of the channel. This serves as a final validation step before changes are actually made to the ledger. There may be more than one transaction stored within one of these blocks.

5. Submission to ledger: Once the transaction(s) within the block sent back to the peers is ratified and finalized, the block is written into the ledger.

source: IBM

Conclusion

I tried to cover high level overview of Hyperledger fabric. In next articles, will cover technical architecture and chaincode request flow. Hyperledger Fabric can be used for Private or Consortium based Blockchain solutions that gives the flexibility to develop good enterprise grade solutions around Blockchain Technology.

If you liked the overview, please hit the Clap button or comment if you have any suggestion or feedback.

How to convert a PEM file to PPK format

Mrityunjaya Prajapati — Wed, 01 Jun 2022 18:57:20 +0000

If you are using AWS EC2 instances with Linux OS, then you will always generate the access keys in a PEM (Privacy Enhanced Mail) format.

If you are using PuTTY to connect EC2 instances then it asks for PPK format, in this case you have convert your PEM file into PPK format.

You have to follow following steps to convert PEM format to PPK format using PuTTYGen:

Download PuTTYGen from puttygen.com
Open PuTTYGen and click the Load button
Set the filetype to . so the AWS PEM file is visible
Select your PEM file and PuTTYGen will import it
Click Save Private Key and PuTTYGen will convert the PEM to a PPK file

How to Connect EC2 from PuTTY

You have to enter your EC2 Hostname or IP Address and in host Textbox
Go To SSH sidebar menu and upload your PPK file
It will open Terminal Window and authenticate your certificate and Machine
Once you Authentication done then you can enter your username: ubuntu is default username for EC2 instance

Conclusion

PEM to PPK conversion is one of the most important activity if you are using EC2 instance.

If you liked the solution, please hit the Clap button or comment if you have any suggestion or feedback.

How to Clone a Specific Git Branch

Mrityunjaya Prajapati — Tue, 31 May 2022 07:21:24 +0000

What is Git

Git is a distributed version control system designed to track changes to a project (code) in software development. It is intended to enforce coordination, collaboration, speed, and efficiency among developers.

GitHub, on the other hand, is a web-based hosting service for version control using Git.

How to clone a Git Repository

Git Clone https://github.com/deadwin19/nest-rest-mongo-boilerplate.git

This gives you access to all branches in this repository and you can easily toggle between different branches and see the files.

You can use following command to change your local branch

git branch -a

How to Clone a Specific Branch

Option One

git clone --branch <branchname> <remote-repo-url>

git clone -b <branchname> <remote-repo-url>

With Option One, you will fetch all the branches in the repository but checkout to the one that you specified, and that branch becomes the configured local branch for git push and git pull.

Option Two

git clone --branch <branchname> --single-branch <remote-repo-url>

git clone -b <branchname> --single-branch <remote-repo-url>

Above step performs the same action as option one, except that it will only fetch files from the specified branch without fetching other branches.

Conclusion

Git Clone for Single Branch saves good amount of disk space specially when you have to work on only specific branch.

If you liked the solution, please hit the Clap button or comment if you have any suggestion or feedback.