EVIL NODES RESISTANCE
TRANSACTIONS / S
Phybr is a set of tools and technologies developed and patented by SemkoDev. They can be used to build DLT-solutions for IoT: Industry 4.0 and innovative consumer applications. Phybr includes two main products:
The nodeware is the heart of the technology. It is meant to be modifiable and extensible, and run even on low-end IoT devices. PhybrNodeware consists currently of four different layers. These layers could be used independently as tools in 3rd-party solutions:
- PhybrNetwork – smart auto-peering, a significant improvement of our “Nelson” open-source project, that we have built for the Tangle and that is currently used by a vast majority of DAG nodes.
- PhybrConsensus – this is what we earlier codenamed “Nikita”: an unbeatable, highly performant and secure consensus solution for DLTs (regardless of the underlying data layer or structure, e.g. DAGs etc.). The consensus does not rely on the classic unsustainable PoW-approaches, it can resist a variety of attacks with more than 90+% of evil nodes in the network, it is highly performant and scalable.
- PhybrLedger – A highly flexible multi-token ledger, that integrates automatic economic clusters (that can split or unite), allows flexible snapshots- and storage-strategies, and facilitates endless scalability for the corresponding DLT applications.
- PhybrExtensions – a highly flexible extension mechanism is our answer to smart contracts; it is API-based and completely technology-agnostic: we will make it extremely easy for businesses and developers to develop and launch distributed applications in any technology they like.
The Nodeware has a layered architecture meant to make it extremely modifiable and extensible for any business use-case and device.
The current state of DLTs is that you usually have the possibility to pick two of these three advantages:
- Complete decentralization
- Security / Data Integrity
- Performance / Scalability
There is no open DLT that truly excels is all three dimensions. We see it as a critical path for any DLT to reach a high standard in all these three dimensions, if this technology aspires to survive long-term and find a broad application in different use-cases.
Currently many DLTs with open networks fail already when it comes to true decentralization. Either there are some sort of “coordinators” or central authority nodes that help to find consensus, or there are PoW-based mining farms that lead to the same result: centralized consensus in the hands of those who have the most resources (did you know that China has over 80% hash rate in Bitcoin DLT?). Our approach is to make consensus totally independent of hash rate and independent of centralized authorities.
Imagine DLT-based presidential elections in a country A. Perhaps another country B’s interest to manipulate those results would be significant enough to invest huge resources and overpower the hash rate of honest nodes. The importance of true decentralization, that is independent of resources, is paramount and the first line of defense against a range of attacks, abuses of power, corruption and failures (human and technical).
We have a way to improve the security of the decentralized ledger with certain dynamic network formation protocols leading to an impressive antifragile system. At the node level the system is simple and robust, providing few “moving parts” that can be exploited. At the network level we reach unique dynamics that can resist a variety of attacks even when overpowered tenfold by evil nodes. We also like a range of approaches to quantum security, that we are currently testing (in any case we implement static addresses for the ledger).
Finally, it is our objective to make a ledger performant on low-end IoT devices, but at the same time the network to be scalable to infinity through an automatic dynamic system of economic clusters.
Apart from these objectives, we are working on a DLT that should make it easy for any business use-case to be ported to a DLT application.
Phybr, pronounced like “fiber”, comes from the idea of creating a dynamic virtual “fiber” that flows between devices (regardless if only a dozen or several billions of nodes) and creates an unassailable reasoning of truth among them. This is the core of PhybrConsensus.
In fact, PhybrConsensus is a generic approach that is not specific to any DLT. It could also be applied to things that are not related to DLT / blockchains at all.
Our convictions are based on a decade of developing B2B software for a myriad of businesses in different industries.
We know that a new technology only prevails in business use-cases if it is easy to integrate into existing systems. The easiness for integration depends on how easy-to-use, flexible and permissive the technology is. This is why we work on a product that is simple to modify and to extend, and where the vision for “smart contracts” is an open API that is not bound to any new “programming language”. We are sceptical of any over-engineered approaches to “smart contracts”. The businesses and developers should use the tools and tech that they already have and feel comfortable with. This is essential for rapid adoption and growth of any technology among B2B applications.
Furthermore, we believe in solid foundations. It is far better to have a core product that excels mercilessly in a smaller range of rock solid basis features, before building anything on top. This is the reason why we see it with great criticism when other DLTs try to catch up with Ethereum’s smart contracts, even though they have not got a proper decentralization or scalability concept yet. It is like building castles on sand.
Our approach is to concentrate on the research of the fundamentals first – on thorough development and testing of Phybr’s basic features. We believe in a product with a rock solid foundation that is flexible and strong enough to hold any construction of any shape on top. Our vision is that some layers of the PhybrNodeware could be easily used by other DLTs as a wrapper, so that they could concentrate on ledger-specific tasks. This is why Phybr’s top priorities are the PhybrNetwork and PhybrConsensus.
Finally, we believe in agile development and rapid prototyping. PoC projects have the absolute priority – feedback from real-world use-cases and businesses is essential for success. As a software company we are valued for our speed and the quality of the delivered products.
Yes. We are huge supporters of open source projects. A range of other DLT projects like wallets (Romeo) and auto-peering tools (Nelson) have been released to the Community as OS tools. It is our strong belief that, to ensure absolute trust in a DLT, all of its parts should be completely transparent and open for anybody to check and to improve.
The source code of Phybr products and libraries will be released at the same time or before the binaries are offered to the Community. In the first PoC applications however, as long as they are not public, the code will be available only to PoC-partners.
We also welcome independent developers to join our effort. The architecture and business model of Phybr should facilitate independent developers to also profit financially from their work on Phybr-related software for businesses.
No, our research goes beyond blockchain and DAG technologies. For example, PhybrConsensus could be used in open distributed environments where nodes have no underlying DLT applications at all.
Phybr tech is in no way related to the great work done by the Tangle developers.
Yes. We have a clear roadmap and successfully completed tests that show how PhybrConsensus and PhybrNetwork could be used for DAGs, with minimal or no changes to the protocol. DAG nodeware could be used as a data layer that is wrapped by these Phybr layers. Furthermore, PhybrExtensions could become a viable and easy-to-use alternative to other over-engineered approaches to “smart contracts”.
In any case we explore the possibilities of offering the Community an alternative independent DAG nodeware that delivers most of the advantages of Phybr. Powered by Phybr.
The whitepaper and other publications will be offered in 2019. Our current aim are several proof-of-concept projects in different industries. Furthermore, we are working on a set of patents (partially already applied for) that have a clear priority, before any technical details can be published.
We enter partnerships with companies to implement PoCs and production-ready DLT applications. Furthermore, we intend to license parts of Phybr to other DLTs or projects that want to benefit from the range of advantages that Phybr technologies can offer.
Our main objective are the real-world applications, especially business use-cases from Industry 4.0. With almost a decade of experience in the development of B2B solutions, we have discovered a multitude of different problems that DLTs can solve.
We believe in organic growth and that the usage of a technology should drive its growth, not the other way around. It is not our priority at this moment to launch a speculative cryptocurrency to finance our short-term necessities. A solid and highly usable technological foundation and its application in real-world solutions is by far more important.
Our focus right now is proving the viability of our technology in different real-world applications, which will drive its organic growth.
Short answer: ICO is not our priority and not within our plans.
- We have been working through 200+ academic papers related to our R&D topics.
- We have created the first concepts, tests and implementations for PhybrConsensus and PhybrNetwork
- We have applied for the first patent and have started to work on several other applications
- We have been planning upcoming PoC projects.
2019 and 2020 will be exciting years! The speculation on the crypto-markets seems to calm down, but the race of the best DLTs for B2B implementations has just begun! The markets will wipe out mediocre solutions no matter how big their current capitalization might be. Only a few fundamental distributed technologies – that are truly decentralized, performant, secure and easy to integrate – will reach a broad implementation.
This is where Phybr intends to play a role. In the coming 1-2 years, we plan to:
- Participate in a range of B2B proof-of-concept projects and bring Phybr to production level; the first PoC starts as early as January 2019
- Apply for a series of patents in a range of different countries (in progress)
- Release a whitepaper about Phybr’s technologies
- Explore ways for an alternative independent DAG nodeware powered by Phybr; light, flexible, extensible, performant and secure
- Continue with our fundamental research of the distributed technologies of Phybr
If you already know our work, then you know our speed and dedication.
The greek letter Φ is used as a symbol for golden ratio, a constant describing the natural balance of things. While this ratio seems anything but balanced, if you add the factor of time and dynamics, you will see the beauty of a natural order unfold. We believe in three maxims:
- An unbalanced system can be exploited.
- The bigger and more complex a system is, the harder it is to balance it.
- A dynamically balanced system is hard to exploit, independently of its size and complexity.
We believe in interdisciplinary approaches. There is nothing new under the sun, as it is told. If you have a problem to solve, chances are that the nature has solved it somehow, somewhere. We borrow different concepts from other disciplines to create something really astonishing!
This is just a teaser. More info on the PhybrConsensus will be released as soon as possible.
The next generation of Nelson auto-peering is meant to improve on security and performance of the dynamic neighboring. It also adds support for clusters, paving the way for boundless scalability.
The consensus is a small, but powerful protocol/algorithm. It allows the network nodes to find truth within a few seconds. It is also designed to withstand burst attacks when the adversary controls an overpowering amount of resources. All while having the flexibility of clustering.
Given that the PhybrConsensus does not have many requirements for the ledger structure, we can focus our whole attention on its speed, its usability in the real-world applications and its easiness of use. From our past research, we have a viable way to:
- Through its unique structure, make the ledger reflect perfectly the business flows and use-cases. The blocks/transactions are not connected arbitrarily just to confirm the previous one, but the relations reflect real business processes. The whole ledger becomes like a big digital twin for whole business operations. Plot it on a screen and you will have a map of what happened when and why.
- Make it snapshottable at any point. Each transaction is stateful. This means that a node can cut the ledger at any point as it seems fit for its purposes. It can store data selectively, only keeping the current state for information it does not need.
- Make it quantum resistant while having static addresses.
- Make it resistant to spam attacks, even when the adversary has huge resources lined up for the task.
- Create a multi-token ledger, while allowing the main token to maintain its value and usefulness.
- Create a dual-token system, where not just value transfers can be reflected, but also indivisible rights.
- Create a possession and ownership rights, where a right token can be lended (think of a temporary, revocable right to open a door or drive a car).
- Make the transactions universally free, while allowing certain tokens to define whether they want to have fees.
- Make the transactions loadable with data, allowing simple information transfers.
- Make the development and maintenance of the technology and its infrastructure sustainable, despite the fee-less transactions.
The extensions are arbitrary programs running on top of the core ledger technology. Think of the extension as a “smart contract” running on specific node “types” and dealing with specific tokens. As long as the extension follows the rules of the base protocol, it is free to define its own logic on top of it.
This logic can be installed and executed selectively on the nodes that require it. The energy control unit (ECU) node in an hotel does not need to run a bike-rental “smart contract”. The bike logic is installed on the bike nodes only. The consensus makes sure that it is executed correctly without the need to run it on all the nodes in the network. This is separation of concerns.
The extensions communicate through a simple API with the underlying protocol/ledger and can be written in any language, allowing faster and easier adoption.