This is the first article in the Bitpost Internals series, where we explain various problems and confusions that arise while working on the project and the ways we managed to solve them. Today we will focus on the most crucial decision for the entire project, namely choosing the right architecture that will allow us to implement all the project assumptions.
Concept 1: Dedicated custom blockchain
As soon as the Bitpost project was born, we considered implementing it as a dedicated blockchain with some custom transaction types implementing all the business processes such as creating a parcel, registering a hub, acceptance of the pickup order, etc. We were inspired by the Helium (HNT) project, that, although for a completely different purpose, implements very similar geographic algorithms to those needed by Bitpost. However, after analyzing all the pros and cons, we rejected this idea, and even the Helium project abandoned its own blockchain in favor of smart contracts running on the Solana blockchain.
One of the disadvantages of this architecture was the long time that would have to be spent on implementing the entire ecosystem around the custom blockchain. Instead of focusing on the actual work on Bitpost’s business logic, we would have to create and develop a lot of custom software: nodes, desktop wallets, mobile wallets, browser wallets, block explorers, development tools, etc.
In addition, we continued to struggle with how to deal with sensitive data such as addresses of sender and recipient of all parcels. Storing this data on a public blockchain would make it available to everyone forever that is absolutely unacceptable. The decision was simple: we couldn’t create Bitpost this way.
Concept 2: P2P network and a billing token
The next concept was to implement the Bitpost as a peer-to-peer network running in parallel to some simple, forked blockchain or even a regular token that would be used only for payments, without any smart features. Each user would install the client software that connects to other peers, synchronizes with the network and exchanges messages with them in accordance with the Bitpost business logic. The P2P client would connect to the Bitpost coin wallet through some RPC interface and make transactions as needed. Sensitive data, such as the address of the recipient of the parcel, would be propagated through the P2P network in encrypted form, and for example only the courier delivering the given parcel would have the key to decrypt it.
This architecture effectively solves mentioned problems of the first one. Unfortunately it has its own new drawbacks, even more serious ones. First of all, a regular P2P network that is not using the blockchain technology does not provide the Byzantine Fault Tolerance. By modifying his client, a hostile user can propagate falsified data across the network to achieve private benefits or simply cause a breakdown.
Without the blockchain, there is also a problem of achieving consensus on the state of the network between nodes. Any delays in forwarding messages between peers would cause the network state to be slightly different on each node. For example, a node that still did not receive information that one of the hubs was closed by its owner could still route shipments through this hub, while for another node such a route would be invalid.
Moreover, we had some concerns about user experience with this architecture. Bitpost in this form would require the P2P client software on each customer device. Every time the user would like to use the application, they would have to wait for it to synchronize with the network. Additionally the local database would take up a lot of disk space, so mobile devices would probably not be able to handle the network node at all and they would have to use some more centralized solution.
Concept 3: Smart contracts and off-chain communication
We came back to the idea of implementing Bitpost fully on the blockchain. However, this time, instead of a custom blockchain, we decided to implement Bitpost as Solidity smart contracts running on the private EVM chain. Additionally, some off-chain communication layer was to be created for exchanging private data.
The entire business logic of Bitpost was to be implemented as Solidity smart contracts and that didn’t turn out to be a good idea. Why? Primarily due to the complicated geographical calculations that smart contracts would have to perform. Querying the big spatial database, finding the shortest path from point A to point B, coordinates, degrees, radians… These are not things that EVM deal well with. Accurate calculations consume too much gas, and less accurate ones are… too inaccurate.
Yet another issue related to the privacy has arisen. The idea behind the Bitpost project was to be like the Tor network for physical parcels instead of network packets:
(…) with one click you can send a parcel in such a way that no one on the world knows the address of the sender and recipient at the same time, and figuring it out is technically impossible. The sender does not know who the recipient is, the recipient does not know who the sender is, and each member of the Bitpost network along the way knows only from which other member they received it and to whom they should hand it over.
Using the architecture discussed here, it’s impossible to achieve. The implementation of the entire Bitpost logic on the blockchain means that each party involved in the transport of a parcel must transact with the smart contract of a given parcel. The shipping fee paid by the parcel sender must be divided into equal parts and paid out to the wallets of all couriers and hubs who handled this parcel and each of these wallets is associated with a record in the public registry of Bitpost infrastructure. As a result, even though the most sensitive data is sent off-chain, anyone can trace the approximate route of any parcel and then there is just one step to complete deanonymization of the user.
Although the final Bitpost architecture changed once again, at this stage the idea of BPX Chain and Synapse Network were born. Today these subordinate projects are completed and fully operational and will be used by the final implementation of Bitpost.
The final decision
After many months of research and hundreds of hours spent on analyzing every possible scenario, we have developed the final architecture of the Bitpost project.
We have decided to stay with the concept number 3 but we’ve moved the entire process of determining shipment routes (and therefore most of the complex geographic calculations) to the client devices. The Bitpost protocol will not verify the correctness of these routes in any way, but actually it’s not as bad as it may seem. First of all, affecting a route change does not provide any tangible benefits to the user who would do so. There is still no way to steal a shipment without suffering financial consequences or preventing it from reaching the recipient. The protocol will remain vulnerable to modifications on the route, but this only applies to the very next hop. In practice, this means that the operator of Bitpost hub in Berlin can make that a parcel addressed to Amsterdam passes through the hub in Hamburg even though Bitpost’s algorithms designated the route through Hannover, but they couldn’t make that the parcel ends up for example in Italy.
To fulfill our Tor-like vision, we have introduced what we call the Zone Isolation. Bitpost network participants will be required to have 2 separate wallets connected to the Bitpost dApp. One of them will be used to register their service, e.g. a hub, in the public registry – this is the public zone. The latter will be used for interacting with parcel contracts, locking collaterals and collecting profits (private zone). A wallet that makes a transaction in a given zone even once will be etternally assigned to this zone and any further transactions in the opposite zone will be reverted. The proposed solution ensures that it will not be possible to associate a specific shipment with the public record of party handling it by examining transactions on the blockchain.
Thanks to several compromises and improvements, most of the drawbacks has been eliminated and all crucial project assumptions can be fulfilled. Development work is ongoing and we are all eagerly waiting for the first working version of Bitpost.