Smart contracts running on the blockchain are the most critical part of Bitpost. They control the complex business logic of the project, ensuring adherence to established rules by all users and protecting the platform against various violations. They must maintain high security and scalability, support future updates, and provide a great experience for both individual users and third-party developers. Achieving these objectives requires a well thought-out architecture, which we will delve into in today’s article.

Subsystems breakdown

While designing the smart contracts structure for Bitpost, we have figured out that they naturally organized themselves into four self-contained subsystems, with each responsible for a specific set of processes and features:

  1. Version Manager – a cohesive system enabling future upgrades of all the platform’s smart contracts.
  2. BPG Token – a standard ERC-20 token with a balances and total supply snapshot mechanism.
  3. DAO – a decentralized governance system that supports weighted voting and dividend distribution.
  4. Bitpost – the core business logic managing the logistics network and all shipments.

Each subsystem consists of one or more individual smart contracts that interact extensively with one another. However interactions between distinct subsystems are essentially minimal, as shown in the diagram below. This loose coupling ensures that each subsystem can be independently developed and evolve over time without worrying about the specific implementation details of other subsystems.

Such a structure is also justified by the need to deploy each subsystem at different times. For example, the BPG Token must be launched shortly after the presale is completed, but in order to utilize the common upgrade mechanism with the rest of the project, it requires the Version Manager to be deployed and tested beforehand. In contrast, the business logic subsystem is scheduled for deployment several months later, while the DAO subsystem requires all other subsystems to be fully operational.

Core subsystem considerations

Although the division into the other subsystems was clear and raised no doubts, we had significant concerns regarding the core business logic module. An alternative concept was to split it into two separate subsystems:

  1. Public Registry – managing hubs, couriers, and parcel lockers, along with the connections between them, their operating hours, service areas, etc.
  2. Shipment Manager – managing parcels, handling handoffs, delivery confirmations, security deposits, and rewards for network participants.

This idea is supported by the fact that, to protect user privacy, transactions with Bitpost smart contracts cannot leave any correlations between specific shipments and the parties involved in their transport. Otherwise, using just a Block Explorer, anyone could identify all the drivers and hubs handling a given shipment, gaining an approximate view of its entire route and the possibility of contacting one of them for further details. In practice, this approach means that the Public Registry and Shipment Manager can operate in complete isolation, with one paradoxical exception. The mechanism itself, protecting against such privacy-threatening transactions require tracking the addresses of each transaction sender in a shared registry for both subsystems and assigning them to the appropriate privacy zone.

As a result, another new subsystem called Zone Isolation had to be created, and the updated architecture of Bitpost’s smart contracts takes the following form:

Initially, we regarded this move as somewhat inelegant, disruptive to the clean vision of the project and excessively fragmenting it’s structure, particularly since each subsystem is intended to have its own dedicated code repository, deployment procedure, documentation, etc. Additionally, this new architecture has several general drawbacks, such as:

  • When searching for an address in Bitpost Explorer, which could be the address of a hub, driver, or locker, as well as the address of an individual shipment, it will be necessary to search through both registries sequentially. The previous architecture assumed the existence of a central registry for all contracts, mapping them to their respective object types.
  • The mechanism for automatically detecting services available to the logged-in wallet could be shared across both subsystems in the previous architecture.

A glimpse into the future

Up to this point, we have focused on designing a clear architecture for the minimal viable version of Bitpost. Ultimately, analyzing the Bitpost smart contract architecture in light of the project’s future roadmap, left no room for doubt. It turned out that Decentralized Logistics – the next phase of Bitpost, expanding its features with warehouse functionalities planned for two years later – will also rely on the Zone Isolation subsystem.

Imagine a scenario where, in the BPX Chain block explorer, we see the smart contract of a specific Bitpost shipment. There is a transaction confirming the pickup of the shipment from the sender by a particular courier. We check other transactions originating from this courier’s wallet, and it turns out that the courier also operates (or has operated in the past) a warehouse for Decentralized Logistics, with its exact geographical coordinates publicly available. Just two clicks and the package has been de-anonymized! We can be certain that it was sent from somewhere near that warehouse.

The conclusion is simple: Decentralized Logistics and other even yet unplanned extensions of Bitpost require a registry shared with the rest of the project, tracking all transaction originator wallets, assigning them to specific privacy zones, and blocking those that have led to the disclosure of unwanted data. It confirms the soundness of the second, more modular architecture, which will ultimately be implemented in Bitpost.