Home Wiki

Jul 12, 2023

Understanding Reef
Architecture: From
Concept to Code and
Beyond!

Welcome to our in-depth analysis of the Reef Chain. In

this blog, we'll delve into the specifics of Reef Chain's
unique architecture, addressing the challenges of
scalability, interoperability, and upgradeability in the
blockchain landscape.

Background:

Blockchain technology has revamped the world of the

internet & web immensely— first introduced as a
distributed ledger, it has now evolved in multiple forms &
variants.

The current rising demand for Web3 technology created a

need in the market that the existing tech could not fulfill.
Many blockchains have tried to explore the true essence
of a decentralized and modular web in their architecture,
but the real modularity and innovation are yet to unfold,
and challenges like scalability, upgradability, and
interoperability are yet to be resolved.

To address such pressing problems of the space, Reef, the

leading Gen III Layer 1 blockchain of MENA emerged, which
incorporates a flexible, open, interoperable, and future-
proof architecture. Our modular node architecture of the
chain allows fast, seamless, and secure communication
coupled with energy-efficient consensus and scalable
infrastructure.

Reef Chain Infrastructure pushes the limits to preserve

the raw essence of the decentralized web.

Let’s understand & discuss the Node architecture of the

Reef Chain in detail.

The node architecture is the core crux and backbone of

every blockchain. The Reef Chain has a unique node
design that includes core services and libraries which can
be customized and upgraded over time. Such
functionalities ensure a future-proofing and adaptive
infrastructure module that caters to the upcoming
generational advancements & version upgrades.

The Reef Chain node is divided into two main

components- Client & Runtime, both having a
distinguished task to fulfill:
Core Client: The core client is an outer node service that
handles the network activities, which include peer
discovery, transaction request management, handling
consensus among peers, and responding to RPC calls.

Runtime: The runtime contains all the business logic that

executes the state transition function of the blockchain.
Both components have their own set of libraries and
modules comprising a unique pallet or bundle of features
& functionalities which can be upgraded over time.

Now before we shed light on these modules and libraries,

let us understand the key service and importance of
Client & Runtime. The core client is responsible for
important activities that are performed outside of runtime
or are referred to as outer node services.

Some of the most important activities that are handled by

core client services involve the following components:
 Storage: An efficient key-value storage layer.

Peer-to-peer networking: Where Rust

implementation of the libp2p network stack is
used to communicate with other network
participants.

Consensus: To communicate with network

participants to ensure they agree on the state of
the blockchain.

Remote procedure call (RPC) API: Accepts inbound

HTTP and WebSocket requests to allow blockchain
users to interact with the network.

Telemetry: Collecting & providing access to node

metrics through an embedded Prometheus server.

Execution environment: Selecting the execution

environment—WebAssembly or native Rust—for
the runtime to use, then dispatching calls to the
runtime selected.

Such features can also be changed over time, providing

room for innovation.

Whereas, the Runtime determines whether transactions

are valid or invalid and is responsible for handling changes
to the blockchain state. Requests coming from outside
come through the client into the runtime, and the runtime
is responsible for the state transition functions and
storing the resulting state. In essence, the runtime is
responsible for handling everything that happens on-
chain.

The WebAssembly (Wasm) design of Runtime enables:

Forkless Upgrades

MultiVM/Platform Compatibility & Support

Runtime Validity Checking

And much more….

Now that we have acquired a deep understanding of the

core client and runtime, let us take a deep dive into the
core libraries that are the building blocks of the client and
runtime.

Similar to the node architecture, which is composed of

two main components, libraries are also divided into three
main areas.

Library Types:
1/ Core Client Libraries for outer node services
The Core Client Libraries are mostly corresponding to their
earlier discussed activities which include
Keystore(Storage), Networking, Consensus, API, Telemetry,
and Executor. But the notable one is the service library
which starts a thread that spins up the network, client,
and extrinsic pool and also manages the communication
between them.

2/ Runtime Library & Module

Now, the interesting bundle is that of Runtime, which

includes multiple libraries comprising of but not limited to:

System: Defines low-level types for primitives,

storage items, and core functions for the Reef
Chain.

Indices: Allocates indices for newly created

accounts. An index is a short form of an address.
 Session: Allows validators to manage their session
keys, provides a function for changing the session
length, and handles session rotation.

Staking: Manages funds that have been staked by

network maintainers.

Balances: Provides functionality for handling

accounts and balances.

BABE: Extends BABE consensus by collecting on-

chain randomness from VRF outputs and
managing epoch transitions.

GRANDPA: Extends the GRANDPA consensus by

managing the GRANDPA authority set ready for the
native code.

Authority_Discovery: Retrieves the current set of

authorities, learns its own authority ID, and signs
and verifies messages to and from other
authorities.

im_online: Allows validators to gossip a heartbeat

transaction with each new session to signal that
the node is online.

Other than these libraries, Runtime comprises Modules

that can be upgraded and improved over time.
VM Module: The module that allows support to
incorporate multi-system support in Reef Chain.

3/ Primitive Libraries for underlying functions and

interfaces for communication

Currently, Reef Chain allows support for EVM, or we can

also say that it incorporates an EVM module in its runtime.
Since we now have a clear understanding of Core Client &
Runtime Libraries, we are all set to explore the most
important set of libraries called Primitive Library.

These primitive libraries enable control over underlying

operations and enable communication between the core
client services and the runtime. They provide the lowest
level of abstraction to expose interfaces that the core
client or the runtime can use to perform operations or
interact with each other.

Some of the notable ones that comprise the Reef Chain’s

Primitive Library collection are shown in the diagram
below.
Core: It offers shareable network types.

Std: It exports useful primitives from the client to

be used with any code that depends on the
runtime.

Timestamp: To set and validate timestamp with

each block where the data is provided by the
block author and verified by other validators.

API: The Reef Chain’s runtime API is the interface

between the node and the runtime

Version: Each runtime that should be executed by

Reef Chain needs to have a runtime version. The
runtime version is used to distinguish different
runtimes.

Consensus: Common utilities for building and

using consensus engine in Reef Chain, which
includes BABE & GRANDPA

Runtime: The modules of Runtime with shared

primitive type
 Authority_Discovery: It’s a Runtime API that helps
to discover authorities.

Block_Builder: The BlockBuilder API trait is that it

provides the required functionality for building a
block.

Session: It’s a core type for all sorts of session

activities.

Here, we must have developed a clear picture in our mind

with a detailed understanding of both the core
components and their functions & libraries of the Reef
Chain. Such advanced & modular architecture ensures
robust infrastructure for dApp developers.

But every blockchain is incomplete without an amazing

and reliable consensus mechanism that unlocks the
decentralized portal on the blockchain network. Reef
Chain also incorporates its consensus mechanism to
agree on the blockchain state.

Consensus
The Reef Chain utilizes the Nominated Proof-of-Stake or
NPoS Consensus mechanism to agree on the blockchain
state. NPoS combines the security of PoS with added
benefits of stakeholder voting, where only nominated
nodes are allowed to participate in block validation.

NPoS is designed to incentivize good behaviour and filter

out malicious activity on the blockchain. The consensus
mechanism comprises two separate phases:

Block authoring: the process nodes use to create

new blocks.

Block finalization: the process used to handle

forks and choose the canonical chain.

Here, the block authoring phase operates on Blind

assignment of blockchain extension or BABE, which offers
slot-based scheduling. Whereas, the Block finalization
phase is taken care of by the GRANDPA protocol, which
says that the best chain is the longest chain.
Since we are all set with architecture and the consensus
mechanism. Let us take a deep dive into one of the most
crucial aspects of a blockchain network. Cryptography
plays a key role in design as it provides the mathematical
variableness behind consensus systems, data integrity,
and user security. Reef Chain is engineered by keeping it
important to consider the computational costs of the
cryptography method, prioritizing efficiency and
processor loads. Such considerations make Blake2 an
ideal cryptographic mechanism.

Blake2 is a relatively recent hashing method that provides

equal or greater security than SHA2 while also being
significantly faster than other comparable algorithms.
While determining the exact benchmark of its speed
improvements over other hashing methods is highly
dependent on hardware specifications, the biggest
positive implication for Reef is how it heavily reduces the
amount of time and resources a new node will need in
order to sync with the chain, and to a lesser extent, lower
required time for validating.
Hereafter having a deep analysis and gaining knowledge
of every aspect of Reef Chain’s Architecture & Design.

Let’s check out the characteristics of Reef Chain in a

nutshell:
Flexible in terms of modifications as it has inbuilt
forkless auto-update functionalities. Making
upgrades fast and adaptive.

Faster throughput rates of around 465 TPS while

performing complex on-chain transfers.
 Incorporates open protocols such as libp2p and
custom jsonRPC for customizing the architecture

Support for EVM-provider, hardhat library, Remix

IDE, Reef Wallet extension etc. offers extensive
development environment.

Future proofing & customization with modular Gen

III architecture.

Conclusion:

As we wrap up our analysis of Reef Chain, we can

appreciate its forward-thinking approach to Web3
technology. Its unique features and robust architecture
demonstrate the potential of this platform to
revolutionize the decentralized web.

We hope this blog has been a helpful guide for you to get
a deep insight into the Reef Chain. Stay tuned as we have
a lot more exciting guides coming to cater to your
information needs on our ever-evolving expanding
blockchain.