Design and implement decentralized systems such as Blockhains is one of the tougher task in computing science and development. It involves strong knowledges such as node discovery, multi-threading programming, fast-data processing, scalable data storages, etc.

At Uniris, we have developed a complete decentralized and highly-scalabled solution including distributed systems, P2P network, limitless storages, smart contract interpreter and evolving cryptography by providing a new innovative, secured Blockchain and focused on mankind by make easier the interactions without omit the eco-environment around.

All these wonderfuls and top-edge technology aspects add a new layer of complexity and requires to deal with technical and business issues by providing a strong research and development approach backed by architectural best practices and patterns.


Deal with complexity

Uniris innovates in a many domains: transaction chain, multi dimensional sharding, decentralized ID and keys, etc. by patents and strong technical specifications.

To design a good architecture solution, we needed to tackle the complexity , by tearing down the barriers between business and technical and increased the understanding and the communication by applying the Domain Driven Design and its principles such as an ubiquitous language and a pair built model with business and technical experts.
So we had a strong communication with patent owner, business developers to be able to define good architectural and technical specifications.

By applying the Domain Driven Design, we were able to have a single and unify model around us splitted by fragments into multiples models:

  • Transaction processing
  • Transaction validation
  • Consensus
  • Smart contracts

Multiple models are important in huge system such as Blockchain, or distributed system. When models are combined, the software becomes often buggy, difficult to understand, unreliable. A confusion in the team communication can appear, and the system become not so clear.

Using bounded contexts we can ensure explicit set which the model must apply by defining specific part of an application: code, database schemas, technical specifications, … This strategic design enforces team understanding and interaction using a same vision and success in the expected goal to reach.


Flexibily and agility

Domain Driven Design comes also with the idea to have an evolving model and needs. To accomplish this, an agile approach is often used (i.e. Scrum methodology).

But when we are dealing with complex software engineering and system design, a flexible software architecture is required. Sofwares often  suffers about  technical debts and cost of maintability.

To avoid this, at Uniris, we decided to use the Hexagonal architecture (or Port/Adapters).

The idea is to improve the maintability and to reduce the time spent on the code base evolving by require less work on the long-term vision.

Hexagonal architecture structure

Each external sides of the hexagone represents a way that our system can communicate with other systems

The core of the hexagone define the domain of the application which  is technology independant.


In our case external sides can be either a client, a peer in distributed system or a database. The big advantage of this approach is the flexibility you can make by changing or add technologies. In agile process, over the sprints we may have to adapt the choice of implementations or technologies and more again in complex subjects as Blockchain or decentralized systems.

The application core — defined in the center of the hexagone —  is a good fit with the Domain Driven Design approach because the domain is isolated and the implementation of the external sides does not alterate the business logic.

Whatever the database or networking technology used, the modal remains independant and isolated from the choice made on the architecture. The model will remain the same.

This approach defines , what’s is called elsewhere, a losed-coupled system making easier integration, testing, evolving and understanding.


Going further: Decentralized domains

Inspiring by the losed-coupled vision or micro-service approach, we designed an architecture which tends to answer for maintability, understanding and stability also. Our domain remains independant of any implementation details. This approach works well in centralized systems but when we want to be fully decentralized we need to think about the idea to expend and to evolve the system over the time and over contributors (inside or outside).

We decided to go  further at Uniris by bringing decentralized models into the core of our systems.

Blockchains are suffering a lot about their governance, the implementation choices, will lead to forks and destabilize networks. Why this happens ?

While most of decentralized systems and blockchains tends to be decentralized by the protocol, their implementation is not. Softwares are designed to evolved in decentralized manner.
Take for instance the code repository, all blockchains are Github or Gitlab for hosting and receive contributions, discussion and decision become off-chain and governance is not really well managed. Therefore, the codebase is mostly hosted on centralized system and reloaing of new features must be done manually.
So we cannot ensure each node have the level of features and support the latest patch.

Uniris network enables hot swapping of any part of the systems and supports on-chain governance to evolve on a decentralized and open-source manner.
Every thing aims to be on chain including code source and governance rules.

Thanks to the transaction chains and smart contracts we are able to first make easy the upgrade of each modules and two audit and rewards any contributor (onchain) to any changes.

With this advanced feature, we can bring the hexagonal architecture and domain driven design into a next level and be able to swap any implementations (domain or infrastructure) according to the governance requirements from the network.

Because our consensus ARCH (Atomic Rotating Commitment Heuristic) involves Atomic and Heuristic, with this approach we can ensure than every nodes has the latest version of its code based on heuristic algorthims and can respect the atomic commitment to provide 99,99999999% of confidence.