This is the first article in a series that will gradually explain the Phybr technology. I will start with the most important part for the daily use — the distributed ledger.
The realms
Phybr is not a single ledger meant to scale globally, but a framework which allows spawning of new sub-ledgers for specific purposes. Each of these sub-ledgers is called “realm”:
Each realm can be considered a separate ledger with its own token, genesis transaction and rules. It does not necessarily need any connection to other realms. Hence, an independent sealed-off realm could be launched in a tiny cluster of servers without any knowledge of the rest of the realms.
Launching of a realm is as easy as creating a new genesis address and giving your token/realm a new name. This does not take more than two minutes. A bike rental company in my home city could create a realm for all of its 2000+ bikes to publish their locations and availability, accept payments and “lend” itself to a user. It does not need to know anything about other realms. All the bikes care about is their own small realm.
It is important to note that a node can participate in more than one realm simultaneously. There is only hardware limit how many transactions the node can handle in a given time frame.
Token = realm
Since each new realm creates a new token type, realm name is simultaneously the new token’s name.
My realm, my rules
Each realm can have its own rules and configurations, for example:
Open vs closed realms
A realm can be open to the outside, where new nodes can easily join the realm cluster and actively participate.
But it can also be configured to be a closed cluster, where each node is required a special permission from the realm’s authority. Without permission, no outside node can access the realm.
A company tracking its shipping containers might want to use the distributed ledger to track its assets, but still hide the information from the public.
A read-only access is also possible, which will be discussed further below.
Object vs value realms
Value realms are used to transfer value of monetary nature. The value can be divided into smaller pieces, represented by decimal places. So, if you have 128 Phi tokens on your account, it is completely valid to send a transaction of 11,333343 Phi tokens to another address.
However, when creating the realm, you can also configure it to manage objects, instead of values. Object tokens represent a right or permission to do something and are not divisible. Each object/right is a whole number.
To illustrate this on our bike rental example:
Imagine an open “bike-availability” realm where each bike is a node and posts its location and availability to the realm. Additionally, any client node can join the network to get these updates.
What if a client node pretends to be a bike node and spams with false, non-existent bike locations? How to prevent that? There are multiple way to solve this, one being the object tokens:
- We create an additional “bike” object realm.
- The genesis address transfers to each bike’s address one bike token (digital twin, anyone?), which represent the right for the bike-account’s holder to behave like a bike.
- The participants in the bike-availability realm need also to participate in the bike realm.
- For transactions in the “bike-availability” realm to be valid, the same address has to hold at least one bike token in the “bike” realm. This logic can be defined in the bike-availability realm’s extension (more on this later).
There is also another way that Phybr offers:
Realms with KYC addresses
The realms could be configured so that the first transaction on any new address has to be signed by the realm’s authority. This becomes a necessity in business areas where KYC process is a requirement due to the local laws or sensitivity of the business.
In our bike example, we could skip the “bike” realm and simply configure the “bike-availability” realm to use KYC addresses. This way only the signed bike addresses would be able to post new transactions in this realm, since clients would not own any valid KYC address. Any transaction from an unverified non-KYC address would simply be marked as invalid.
If you combine KYC addresses with an open realm you could have a read-only environment where only authorised addresses can edit, while anyone can read the ledger.
Transfer vs lending
This is another interesting concept applied to object realms in Phybr. An object token owner can “ lend” the token to another address for a limited period of time.
Imagine a lock on an AirBnB apartment’s door. The right to open/close the lock can be “lent” to a user for a specific time, so that the user can use this right to open the lock by making and signing a transaction on the “airbnb-door-lock” realm. Instead of transferring the right, which might never be returned, the lent right can be revoked at a predefined time.
Another example is our bike rental company that is using “bike” object tokens from the example above. Imagine that the bike’s private key becomes compromised. Anyone holding the bike token could start spamming wrong bike info on the ledger.
However, if the token was not owned by the bike in the first place, the token owner could revoke it at any time, preventing or limiting its misuse.
Extensions
Each realm and the participating nodes could run extensions on top of the basic Phybr implementation. These extensions can decide, for example, when a transaction should be considered valid or automate certain processes when an event happens on the realm’s ledger (such as opening a lock).
You could consider the extensions to be realm-specific “smart contracts”. These extensions are currently not limited to any technology, and could be plugged into the node through a set of RPC calls.
One of the extension’s use cases could be:
Transactions with fees
For a transaction to be considered valid, a realm’s extension might require that the user does a second, small transaction to a fixed address or one derived from the extension’s logic.
Phybr at its core is completely fee-less. But an extension could change it for any realm. Phybr just offers a tiny, solid basis. Anything else on top can be configured for the realm’s purposes.
The ledger
Let’s move to the ledger itself and the advantages it provides. Interestingly, I realised only two months ago that the basis of the ledger’s structure is very similar to “Nano” when reading their whitepaper. While Phybr’s ledger goes beyond that structure, it gave us a little more confidence. We are not the only ones in town who realised its benefits. Hats off to Nano!
Everything is a DAG
A conventional blockchain, strictly speaking, is the simplest form of a directed acyclic graph (DAG). A child block is linking its parent, creating a one-dimensional chain of blocks:
In a more obvious DAG, such as IOTA, each transaction links two predecessors/parents, creating something called a “tangle”:
The tangle has clear advantage over the conventional blockchain. There is less competition to become the next link in the chain. In IOTA, in certain situations (as with the old coordinator) some valid transactions were left behind, simply because they were not referenced by any other transaction. But still, the probability to be included is much higher than it would have been on a single chain.
Generally, one could say that the breadth of the graph is the bottleneck for its performance. The higher the transaction rate, the more obvious this problem becomes.
Phybr, just like Nano, minimises this problem by creating a separate chain for each address. This structure is called a “lattice”.
There are clear benefits of this structure. In some, Phybr goes beyond what Nano could offer:
No conflicts
Each address posts to its own chain. Each transaction on the chain is incrementally indexed (see the picture above). If there is a conflict on a chain, it can only be provoked by the chain’s owner. In KYC address realms, even without any consensus mechanism, one could warn or / and block the complete address chain if it is found creating too many conflicting situations.
If more than one transaction with the same address and index exists, it can be marked as dubious and require longer time to get confirmed (even if just as a penalty). This logic can be fine-tuned by the realm’s extensions.
Zero fees — data transactions
As mentioned earlier, there are no fees by default imposed in Phybr. Each transaction can hold a tiny block of data, making it a viable medium to securely store sensor data in a distributed way.
Stateful transactions
Each transaction holds the current state and balance of the address. It does not simply say:
Transfer X tokens from A to B
Instead:
Address A, index N: Transfer X tokens to B and the new balance is Y.
This means that the size of each transaction is a little bigger than it should be. While the storage space and bandwidth capacities become cheaper and bigger, this additional overhead is nothing compared to its benefits:
Versatile snapshots
The stateful transactions mean that you could cut the history of any address chain at any position, while still retaining the proof of the current balance.
A tiny node could opt to just keeping the “transactions horizon” (the latest transaction for each address), mercilessly pruning the rest of the history. Or it could decide to keep the history for a few addresses it uses, while removing the rest.
Syncing new nodes
The stateful transactions also mean that a new node does not necessarily need to download the whole realm’s history to be in sync with the rest of the realm.
When an unknown address chain is needed, the node could simply ask for the current address state (basically, the latest transaction) from its neighbours and mark it as valid/confirmed once the “conviction” state is reached. (The logic behind conviction will be discussed in a following article).
It does not need the whole history, although it could try to get one, if it still exists. Old realms might have no nodes left that “remember” the genesis, making the convictions the only way to securely sync the new nodes.
Sharding
Since each account is a separate chain, it could be possible to logically shard the database across multiple nodes, where the transactions from one account never get split across multiple nodes and a node could be responsible for a specific set of accounts.
This is something that we are actively researching at this moment.
Logical links
Each transaction on an address chain has at least one link, the parent transaction on the same chain. But it can also have additional links, even cross-realm links. Either soft or hard links: the knowledge and validity of the linked transaction is optional (soft) or required (hard).
It depends on the use-case and the realm’s extensions, what transactions (apart of the parent transaction) are linked. The logic behind those links is mostly of a business nature: the Phybr ledger clearly reflects the business processes. You could print the realm(s) graph(s) and read what happened when and why.
It has clear advantages for auditing and monitoring of the processes happening within the realm(s).
Multiple signature methods on the same ledger
Currently, we have implemented one of the smallest and fastest signature methods (Schnorr). However, Phybr’s structure allows to easily add more methods, when they become a necessity.
While we are currently monitoring a promising, quantum-resistant private key encryption method. It might not be ready before the first quantum computers start appearing that pose a threat to the currently used signature method.
For this reason, Phybr supports adding of new signature methods, such as hash-based one-time signatures with a static address. Multiple signature methods can co-exist in the ledger, giving the users time to migrate their accounts from old signature type to the new one, without disruptions to the ledger’s functionality. This is an important point to make the ledger adaptable in the future, no matter how cryptography evolves.
At this point, while the quantum threat is still just a speculation, we decided to use the fastest method for performance sake.
Current state of development
The basic ledger functionality is implemented and is currently being tested in combination with the rest of the modules.
There are still a few things on the roadmap such as lending, KYC addresses and extensions that are not implemented, yet. While not being difficult, they need time to be developed and tested. Our main priority is to get the basis right. The rest will follow shortly after.
The next articles will dive deeper into Phybr network, consensus and smart PoW. Subscribe on Medium to keep updated!
To get notified about bigger development milestones, you can subscribe to our newsletter at https://phybr.tech.
Thanks for reading!
