About 10 days ago we have started our professional year of 2019 and are already working on the preliminary Proof-of-Concept of our Phybr technology, which will give us the financial support to continue our R&D this year and beyond.
As described on our phybr.tech website, there are four parts of Phybr:
- Consensus: a system that allows the nodes within the network to agree on a single statement among multiple contradictory statements.
- Network: “Nelson 2.0” auto-peering system, which supports clustering, has less requirements and is more stable and secure.
- Ledger: A relational DLT that allows mapping whole business processes, creating “digital twins” from simple object, right and procedures to entire organisations.
- Extensions: Something very similar to smart contracts.
Consensus and the underlying foundation are, without doubt, the most important part of Phybr (and probably of any DLT for that matter). It allows us much more flexibility in designing a Ledger without having all the baggage required for the Consensus. This way, we can create a tool tailored for the businesses’ needs and not tailor the businesses issues to fit a specific tool.
Given the flexibility of the Consensus, it could be theoretically applied to other DLTs. We have spent a bigger part of October/November 2018 to prove that it is a viable solution for DAGs like IOTA. And we are still convinced that it is the best one — at least of what we have seen so far.
We have applied for patents to secure the work we have done so far and the first patent confirmations should be ready in March. At that point we will be able to give more details about how our Consensus work. However, without going into much detail, we are able to outline how it would in IOTA and other DAGs. Let’s start.
Life is ambiguous.
The details on how the Phybr Consensus work will be published in the upcoming months. The basic function needed to explain the implementation proposal for IOTA is, however, not a big secret:
Given a set of contradictory statements, chose one and make sure that everyone else selected the same one.
In case of a distributed ledger, a statement would be a transaction. A contradictory statement is, for example, a double-spend transaction.
This is a problem from the “complex domain”, for those familiar with the Cynefin Framework, where no right answer exists. This is where Phybr Consensus does its magic. So how can it be applied to a DAG?
Milestones and blocks
“Think a hundred times before you take a decision, but once that decision is taken, stand by it as one man.”
― Muhammad Ali Jinnah
Since there is already the concept of milestones, we could easily reuse it for the sake of Consensus. The milestones are currently created by the centralised Coordinator. Even if the coordinator is decentralised, in our opinion, it is not enough to contend for the name of a “distributed ledger”.
What if every node could be a “coordinator”?
If you look at a DAG, you could say that the newly confirmed transactions by a milestone form a block of transactions. Each milestone separates the previous block from the next one.
In the end, it is not much different from the conventional blockchain, only that there are multiple references from one block to the previous one. And that the transactions inside the block are linked/referenced in a certain way.
There are certain rules that could be agreed upon regarding these blocks. For example:
- Each transaction in a new block should not contradict the previous block.
- The milestone delimiting the block should not reference, directly or indirectly, contradictory transactions.
- The height (from the genesis block) of the next milestone should depend on the network speed during the previous X blocks and is pre-defined and pre-agreed in the previous “parent” milestone.
- If the milestone at the specified height is a transaction that is not at index zero in the bundle, the first transaction of that bundle should be used.
- The milestone with the most transactions/value/weight should be selected.
If each node follows these rules to determine the next milestone, they would end up with at most a handful of milestone candidates. Which candidate is selected by the whole network in the end, can be determined using the Phybr Consensus. The procedure at each node would be as follows:
Milestone selection steps
- After the DAG reached a certain height, select all transactions of the height as specified in the previous milestone.
- Filter out transactions that contradict or reference contradictory transactions.
- If the result is empty, decrease the height and start from (1)
- If the transaction is not the first in the bundle, select the first one in the bundle.
- If there are several candidates left, select one with the highest value.
This value could be the amount of new referenced transactions; the total value of those transactions; maybe using the “age” of transactions, favouring older ones so that no valid unconfirmed “tip” would be left behind ever again.
- Determine the perceived past speed of the network and, using a formula, calculate the height of the next milestone.
- Mark your candidate as milestone, with the height information about the next milestone. If several milestone candidates are still possible after the previous steps, chose the one with earliest timestamp, alphabetical precedence of the hash or any other similar, commonly agreed criteria.
- With your peers, reach a consensus on what candidate should be used globally, in case there are different opinions from other peers.
Each node is turned into a coordinator!
The milestones are linked, directly or indirectly, forming a chain of milestones. The consensus “weight” for a milestone could be cumulative. This means that the weight of new milestones increases the cumulative weight of preceding milestones.
Since the Phybr Consensus does not rely on Proof-of-Work, it is extremely hard to forsake the previous milestone. It is basically impossible to forsake the last two milestones. Hence, any transaction approved by 3 or more milestones is confirmed for good.
The dynamic height selection for the next milestone allows confirmations at regular time intervals, independently of the network’s speed: be it 3 TX/s or 3000 TX/s. If the nodes at a given sub-tangle agree to issue the milestones each 10 seconds, any transaction would be confirmed within 10 seconds and be indisputable within another 20.
Have a coffee? Pay and go within 5 seconds on average. Buying a car? Might be a good idea to wait 20–30 seconds longer. More confirmations = higher security.
What about clusters?
Back in November we have tested this concept with clusters. Imagine a set of nodes that “fork” the chain of milestones, creating a new one that only they agree upon. The first “forked” milestone could be the genesis for that set of nodes. These nodes would follow the new chain, creating a new sub-tangle.
This sub-tangle could be merged partially or completely back into the previous one, as long as there are no contradictions. Otherwise, any attempt to “link” both tangles would fail, for the nodes would simply ignore such transactions.
How hard would it be to implement?
Our proposal defined two layers:
- The data layer, which is basically the current IRI or Hercules implementation.
- The meta layer, which would take care of the milestones, consensus, etc.
Data layer
The data layer, be it IRI or Hercules, would require minimal changes. Instead of relying on the milestones from the coordinator, it would query the meta-layer for the milestones and provide the DAG data for milestone analysis.
Meta layer
This layer has own communication channels and could work pretty much independently from the data layer. If the nodes generate milestones each 10 seconds, the communication overhead would be minimal (much less than one additional message per second).
Moreover it could integrate automatic peering for its own purposes and for the data layer. Given the lightweight communication for consensus purposes, the meta-layer could maintain a fair amount of connections with other peers for Consensus while limiting the amount of connections for data layer to 3.
This would minimise the bandwidth usage dramatically as compared with Nelson 2.0, while maintaining even higher protection against eclipsing and sybil attacks thanks to the meta-layer.
Small nodes on the edge of the network could opt for “passive” consensus, where they query preselected nodes for current milestones, without having to actively participate in milestone creation and Consensus. This would open doors to tiny nodes that only track past X minutes worth of tangle history, while being completely in sync with the rest of the network.
What is the way forward?
My aim with this article was to share the work we have done in past months regarding the application of Phybr Consensus to DAGs. We haven’t forgotten and we keep experimenting.
We never discarded the possibility to use Phybr with IOTA or any other DLT. However, our current priority is to keep our work sustainable with Phybr Ledger. A community endeavour to integrate the Phybr Consensus on the basis of Hercules node could happen eventually.
Time will tell.
Roman
