Project specification

[jondubois]

Project description

A postgres adapter for the LDPoS chain module which allows it to persist transactions, blocks, accounts, votes and multisignature groups to Postgres.

Overview

LDPoS is a simple and lightweight DPoS blockchain which uses a hash-based signature scheme (Lamport OTS with Merkle Signature Scheme) which is believed to be resistant to potential quantum computing attacks. LDPoS has the following features:

• DPoS
• Stateful signature scheme which allows a user to change their wallet passphrase. Could also be used to transfer ownership of an account without revealing private keys.
• Dynamic multisignature groups; multisig accounts can add and remove members over time provided that there is consensus within the group.
• Compatible with Lisk DEX - https://ldex.trading/
• Simple consensus algorithm which supports instant finality (blocks can never be rolled back after they are processed).
• Deflationary; no forging rewards aside from transaction fees (shared between all block signers).
• Dynamic fees.

This module implements the Lisk custom module specification (LIP5) and is designed to run inside LDEM (Lisk/Leasehold Decentralized Exchange Manager). LDEM a controller/process manager for running different blockchain modules on multiple processes in order to make use all available CPU cores.

Other features of LDEM

• Exposes channels which allow modules to efficiently communicate with each other.
• Manages configuration for each module instance.
• Provides an update scheduling mechanism for applying major updates in a decentralized way.
• Allows a module's code to be used as a template to spawn multiple instances with different configs.

We expect to run LDPoS on Leasehold core nodes initially: https://github.com/Leasehold/leasehold-core - This will allow us to use the existing Leasehold network infrastructure. Installation is just a matter of doing npm install then adding an entry to a config file.

Deliverables

• Design a database schema which uses as few tables as necessary. Suggested tables: accounts, votes, blocks, transactions, delegates, multisig_memberships (feel free to use alternative naming convention).
• An adapter which creates all the necessary tables when initialized for the first time and exposes the necessary methods to allow the LDPoS module to read and write data to and from the Postgres database as needed.

Background work

This repo contains a PostgresDAL class (https://github.com/Leasehold/ldpos-postgres-dal/blob/master/index.js) which declares most of the relevant methods (but not yet implemented):

There is also a mocha integration test script inside the test/ directory which can be used.

You can git clone the LDPoS Chain repo https://github.com/Leasehold/ldpos-chain then npm install the dependencies then npm run test to run the tests to get an idea for how the LDPoS chain module will work.

When running the tests, the LDPoS module uses a mock class as the Data Access Layer: https://github.com/Leasehold/ldpos-chain/blob/master/test/utils/dal.js - For errors, it throws an Error object with custom name and type properties. You can run the tests and log the arguments and return values of the mock class methods to understand what kinds of inputs and outputs the postgres adapter needs to support.

Additional requirements

• Use async/await (no callbacks or then blocks).
• Make sure that Errors (exceptions) thrown from each method are consistent with those thrown by the mock DAL class methods here (use the same name and type properties): https://github.com/Leasehold/ldpos-chain/blob/master/test/utils/dal.js
• Do not add new dependencies unless absolutely necessary. Only add dependencies that you trust or if you know the author personally. Assume that any dependency which you don't control or from an unknown author is a vulnerability.
• Use whatever conventions (database table names, column names, variable names...) makes the most sense for JavaScript/Node.js and Postgres combo.
• Plain JavaScript; currently there is no build step used in any other part of the project so it's better to keep it simple. TypeScript can make it tricky to do remote debugging of the source code over SSH which is a common occurrence for decentralized projects.
• As simple as possible; no complex abstractions. Just raw SQL queries executed via pg-promise would be ideal. No need for fancy database ORM entities.
• Works out of the box. The adapter initializes the database and tables at the beginning if they don't already exist.
• Indexed for fast reads with support for ordering based on relevant fields such as timetamp (for blocks and transactions), height (for blocks), id, balance (for accounts), ...
• The LDPoS module was designed so that all write operations are idempotent so database transactions should not be necessary. Keep SQL queries as simple as possible (but also efficient).

[sacOO7]

@jondubois I will need a schema for tables accounts, votes, blocks, transactions, delegates, multisig_memberships Currently, as a part of code, it's difficult to find data models and respective types for fields. It will be great if I can get model attributes along with their types.

[sacOO7]

Also, if you can provide sample JSON data for each table, will be really helpful. I can use it for seeding in the database for running on the local and seeding purpose.

[sacOO7]

Link to DB Spec Document = https://gist.github.com/jondubois/22581a5ab6b6bd64d8385fbc2a17d5db