Phybr explained #1 — The Ledger

Roman Semko
Apr 16, 2019 · 10 min read

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

Image for post
Image for post

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

My realm, my rules

Open vs closed realms

Image for post
Image for post

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

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:

Image for post
Image for post
Two realms working together
  1. We create an additional “bike” object realm.
  2. 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.
  3. The participants in the bike-availability realm need also to participate in the bike realm.
  4. 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

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

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.

Image for post
Image for post

Extensions

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

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

Everything is a DAG

Image for post
Image for post
Chain of blocks or transactions in a conventional blockchain

In a more obvious DAG, such as IOTA, each transaction links two predecessors/parents, creating something called a “tangle”:

Image for post
Image for post

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”.

Image for post
Image for post
Each address in Phybr ledger has its own chain

There are clear benefits of this structure. In some, Phybr goes beyond what Nano could offer:

No conflicts

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

Stateful transactions

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

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

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

This is something that we are actively researching at this moment.

Logical links

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

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

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!

Roman Semko
SemkoDev
phybr.tech

semkodev

DLT research and development

Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch

Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and inbox. Explore

Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just $5/month. Upgrade

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store