For those who are just tuning in to our updates (better late than never!), the team has finished with the Research and Discovery phase and has bravely stepped into the Proof of Concept phase.
The key aim of this phase is to make a workable PoSv2 blockchain prototype which is, as you might expect, no easy task.
Now let’s check out what they’ve done so far.
Getting down to the nitty-gritty
Since the onset of this phase, they’ve worked on the first iteration of the blockchain software from scratch while sticking to a straightforward peer-to-peer network paradigm.
After some time, the team realized something: they’ve discovered that some requirements need to be additionally specified in the PoSv2 (Proof of Stake version 2) analysis, and more descriptions added to clarify the specifications.
This wasn’t a blocker for the team, as they’ve made significant progress in the preliminary work leading up to the creation of the first blockchain prototype.
The major components were designed and implemented — e.g., Network, Mempool, Wallet, Storage, Blocks, Accounts, and the first part of the Consensus engine.
If you consider yourself a crypto connoisseur and you are curious about the development details, here’s a list of functionalities that were realized.
Network
So, what was done regarding the network?
The team worked on:
- Adding data serialization and deserialization (bincode);
- Posting a message (gossip), sending a message, receiving a message, etc.;
- Introducing bootstrap node;
- Introducing channels for connecting various software modules, for example, communication and data exchange between mempool and network threads;
- Adding a request/response functionality to the network manager;
- Network enhancement.
For those who are interested in going even further in-depth, here are some additional explanations. Introducing bootstrap nodes means allowing them to exchange routing tables of already connected nodes to the new node, accelerating the process of nodes discovering themselves. Regarding the request/response functionality, it is utilized for block synchronization and, in some situations, consensus because it allows nodes to request data from one other and get responses. As for the work done on network enhancement, it consisted of reducing the need for bootstrap nodes in the local network by enabling mDNS discovery for nodes in the local network (for testing and development purposes).
Mempool
Let’s start by defining a mempool (memory + pool) — it’s a mechanism for storing information on unconfirmed transactions. Basically, it’s a waiting room for transactions that have not yet been included in a block.
Regarding this component, the team boasts enabling fundamental functions like add, remove, prune, etc., and storing data to each node. They also worked on establishing channels for module communication (network – mempool connection), and they added transaction verification which is a checking process that the signature is valid and the sent amount is available in the account balance.
Wallet
How are things going with the wallet?
For the purpose of creating a cryptographic key pair, the wallet generates a mnemonic phrase and a cryptographic seed. A private key is used to sign a transaction, while the public key checks the transaction’s signature. The block producer signs a block using the private key, and the verification of the block signature is done by using a public key.
All is well on the wallet side!
Storage
In terms of storage, here are some strategic decisions that the team made:
- Using RocksDB to implement a storage system;
- Dividing data into columns to improve the database read and write process;
- Adding a mechanism to serialize and insert a single value into the database;
- Adding a method for reading data from a database and deserializing a single value;
- Including a technique for iterating through key/value pairs from the database while sorting them.
Blocks
What work was done on the blocks?
- Implementation of block structures with transaction headers carrying information on the block itself, such as the previous block hash, transaction headers’ hashes (Merkle roots), the block’s current height, the block proposer’s signature, etc.;
- Publishing newly created blocks to other peers in the network;
- Verifying block validity (verifying block header data);
- Genesis block creation – initializing the state of new nodes in the network;
- Storing of valid blocks into the database;
- Node synchronization implementation.
In order to join and take part in the consensus, a new node must first build a genesis block from its local configuration and then download and update any existing network blocks (become a validator of newly proposed blocks).
For those who are baffled by all the terminology, “genesis block” is the first block recorded on a blockchain.
Account
Now, we come to one of the parts most significant to most users — their account.
The team created their test accounts, and for now, they’ve added account balances to enable sending transactions. Balances were added through the completion of the Genesis block. Things are looking good!
Consensus (first part)
As mentioned, the team got down to the first part of the consensus engine as well. This includes:
- Initiator of the block proposer (manual for now);
- Requesting the committee a vote in favor of the block;
- Verifying inbound voting requests;
- The transmitted block is validated;
- Voting in favor of the block in response to the request vote;
- Responding only to the leader.
The next steps
As the project moves forward, it naturally increases in complexity, so the code base is updated constantly. But this is day-to-day stuff for our team. They’ve told us that in the coming weeks, the implementation of the Consensus model will take precedence.
The report for this period concludes here but don’t worry, the team continues at full speed – until next time!
