COTI Development Best Practices — How To Read Our Code and GitHub

Published in

COTI

7 min readFeb 6, 2020

Introduction

This document overview the development and coding practices we use at COTI and outline some of the main aspects related to our coding process, versioning, public and private GitHub, repositories and community engagement.

At the core of COTI’s infrastructure lies the Trustchain infrastructure, a proprietary consensus algorithm based on machine learning, which dramatically decreases transaction costs and increases processing speed by assigning trust scores to transactions and clustering it in chains.

The Trustchain infrastructure lies on a multi-DAG (directed acyclic graph) data structure, which works in tandem to drive up scalability. The DAG model provides COTI with the framework for exceptional performance and efficient transaction processing. There are multitudes of token types and uses, which are worthwhile to implement atop the COTI DAG infrastructure.

COTI Coding Practices

What’s our coding process?

The COTI coding process uses two types of repositories: private and public. As a common practice, we use git Rebase workflow (as opposed to pull request and merge) to maintain a clean tree for our git repositories in the public version.

After finishing the development of a feature on our private GitHub, we squash small commits to make the work history much cleaner and understandable and rebase on top of other branches. This rewrites the git history and decreases the number of commits. This is also the reason why in our public repository we do not have any pull requests.

For example, if you take a look at ‘coti-node’ repository ‘multi_currency_dev’ branch. There are some gap without any commit (e.g. between commit bcd40868241503eb008953c030664a0e2d02e4df — reformat code

And commit c0c2ee448931a91522d632eb43c54d8c421fc14b — getTokenMintingFee)

But, if you take a look at the latter, this commit is comprised of multiple squashed commits and handles 40 modified files, 33 added files and 1 renamed file.

The reason for adopting these practices is to make the process of deployment of the code to our public repository and to our MainNet more sustainable while always maintaining working and tested code branches and commits.

Versioning/Releases

You can find our releases in each node repository with the exception of ‘coti-node’ which is used for dev purposes. You can find the version in the branches of most node repositories (except storage and history node). For now, we have two releases — v.1.0.0.RELEASE and v.1.0.1.RELEASE. If someone would like to take a look at a previous version, they can change to the release branches.

It is also important to note that we are currently working on versioning management.

When do we post to public/private repositories?

Everything developed in coti-node can be seen by everyone mostly in a delay of some days until it is mirrored. For coti-node development we currently use our private cotitech-io/coti-node repository, we have a master and dev branches. Generally, for each new feature, we open another branch and every team member who’s working on that feature opens another personal branch (dev_name/branch_name) which in turn is rebased onto dev and onto master.

After code review and testing of the changes we periodically mirror our private cotitech-io/coti-node into public coti-io/coti-node and updates each public node repository which are only for release purposes.

It is important to note that we also have other private repositories, and we often shift our development efforts to those repositories according to business requirements.

Development languages

Most of COTI’s codebase is written in Java and Javascript.

For static code analysis, we use sonar lint in our java ide, es lint for js.

Most application and service layer code is written in: NodeJS and React

Code analysis

We use Codacy for static code analysis for our repositories.

Code Coverage

Testing is an integral part of our development lifecycle and is a vital part of our software quality. It can be measured using metrics called Code coverage. Code coverage is a measurement of how many lines/blocks of your code are executed while the automated tests are running.

Analysing our code using external tools will show you that COTI’s codebase includes a significant amount of test cases. It indicates that the COTI team is serious about the quality of our software and engage in best practices of software development.

What do we have in the private libraries

As part of our business and adoption strategy, we have created several services and applications which are used by merchants and companies to seemingly integrate with our infrastructure and ease the process of deploying solutions on our network. Some of them consist of:

KYC 3rd party integration
Credit Card payment gateway integration
Liquidity providers for interoperability and processing cross platform tokens
Integration with traditional payment gateway and banks to implement instant settlement from crypto->fiat, fiat->crypto
COTI-X — exchange implementation and integration

What’s under development and still not available in GitHub?

Everything developed in coti-node can be seen by everyone mostly in a delay of some days until it is mirrored. Some of the current development efforts which are not yet available on GitHub consist of:

MultiDAG — wallet integration + token deployment application
pBFT work on our improved consensus and pBFT research and developments
History nodes — full integration with history nodes are still in development
Custom made 3rd party merchant integration
DAG data structure improvement for synchronization and scalability.

Dev Community Engagement

Currently, there isn’t any outside contribution thus there haven’t been any pull requests on our public repositories. We recognize the importance of open source contributions and engagement with the development community. As an initial step, we recently made all our nodes repositories public and engage with the dev community on our Discord channel. We also plan to open a COTI dev telegram and we have made our GitHub repositories more welcoming by providing README files and precise instructions. We welcome the community to contact us and ask as many dev/technical questions.

As part of testing our infrastructure, we have opened our network for TestNet node operators as well as several node operators already running our full node source code. In addition, we have recently introduced our bug bounty program and testing incentive plans to get more developers to engage with our code base.

COTI GitHub Repositories

The COTI project has 16 repositories in total with 21 collaborators.

The COTI development ecosystem consists of:

All of COTI public code is available at https://github.com/coti-io

COTI-node repository

COTI node is the development repository for COTI’s DAG-based distributed ledger. It is comprised of a basenode (which provides the base functionality for all COTI nodes) and all other COTI nodes.

Coti-zerospend-server, coti-history-node, coti-dsp-node, coti-fullnode, coti-trustscore-node, coti-storage-node, coti-financial-server, coti-nodemanager — These repositories are for release and are not being used for development. These repositories are regularly updated from coti-node repository and where the versioning/release can be found.

These repositories include all of our infrastructure implementation, trustchain protocol, consensus, multiDAG and consist of more than 35K lines of code.

COTI-encryption-library

coti-encryption-library is a public library which can be used for integration with our blockchain, monitoring, and developing functionalities. It consists of an API for integrating with full nodes and can be used to build custom made wallet, exchange app or any other dApp on top of infrastructure.

COTI wallet repositories

The repository contains the client side COTI wallet React code + A rendering server (express).

COTI services/apps repositories

coti-exchange-app — A Node.js (Sails.js v1 based) microservice, handling all communications with a coti full node. The app exposes restful API endpoints that can be used by exchanges to:
Monitor transactions, address balances (For example for identifying deposits and confirming withdrawals)
Send transactions (Withdrawals)
Generate wallet addresses (For example for issuing a wallet address per each exchange customer)
crypto-gateway — COTI crypto payment application used for processing BTC, ETH, ADA and integrating it into ecommerce websites.
crypto-shop — COTI Pay integration demonstration site.

Summary

COTI development complies with coding best practices while making sure that our public GitHub always maintains a cleaner and understandable version of our code. As we move forward with our development we will continue to improve our private/public interconnection as well as improve our management for handling new features, bug fixes and release numbering while still adopting more of the open-source guidelines and best practices and implement them as part of our workflow.