LibrumCHAIN is the next generation blockchain technology that is revolutionizing the tokenization of assets. GreenChain was contracted to develop their blockchain system. They have already launched their platform.
Librumchain uses Proof-of-Authority as the core consensus. The core blockchain nodes which run on a cloud-based decentralized network operate with Proof-of-Authority consensus. These nodes run the ERC20 smart contracts for different tokens in the blockchain. The transaction execution and block generation happens with the Proof-of-Authrity blockchian nodes. We have designed the functions of the Proof-of-Athority nodes with microservices-based architecture. The blockchain functions in a node
implemented as small microservices with a single responsibility principle. There are three main
microservices in Proof-Of-Authority nodes in the Librumchain,
1. Aplos service
2. Lokka service
3. Storage service
Aplos service is the smart contract service in Librumchain. The smart contracts are implemented on Scala functional programming languages based Akka actor framework. This service exposes HTTP and gRPC based APIs for clients to interact with the smart contract functions. The transaction handling of the smart contracts happens with “Validate-Execute” real-time blockchain architecture. Lokka service
handles the block generation functions. One Lokka service will be generated blocks and others approved
that block based on the majority vote Proof-of-Authority consensus. 3) Storage service is the asset
storage of the Librumchain. We have implemented the storage service with CockroachDB geo-distributed
SQL database. The architecture of the different services in the Librumchain is depicted below.
The blocks generated in the Proof-of-Authority network are published into the IPFS peer-to-peer decentralized storage. We are using IPFS as the block storage in the Librumchain. The block that is generated in the IPFS endowed into a JSON object and written to a file. This file will be published in the IPFS. IPFS having the single point of failure issue. To prevent the single point of failure issue, we have used IPFS Cluster. When adding a block to the IPFS it returns the IPFS CID. This CID will be pinned and replicated into multiple IPFS nodes to prevent the single point of failure. This pinning and pin replication happens via IPFS Cluster. We have deployed a multi node IPFS Cluster along with the blockchain network.
Each Proof-of-Authority blockchain node runs its own IPFS node. These nodes are connected with IPFS Cluster. We have publicly exposed the IPFS storage to outside/byzantine parties. Any party can get the block and verify the transactions from the IPFS. When building the blockchain on IPFS, we have injected previous blocks IPFS CID into the current block header as the previous block. The structure of the block which is stored in the IPFS shown below.