Future of Blockchain and Reputation Consensus
Three years ago I was already expressing my skepticism regarding the wider applicability and adoption of “peer-to-peer distributed ledgers”, widely known as “blockchains”. Half-year ago it has been pretty much confirmed by known issues with Facebook’s Libra and graceful crash of Gram(Ton) project, the announcement of the crypto-yuan, Visa crypto-dollar parent claim, then the hostile takeover of Steemit blockchain via DPOS-attack and consolidation of more than 50% of Bitcoin and Ethereum mining powers on the territory and under the jurisdiction of Celestial Empire, and finally by happy engagement of Visa with Ethereum.
Another perspective of the decentralization and multi-agent systems that I was talking about at the Decentralized OS event last month is the development of a fair and reliable reputation system based on the principle of “liquid democracy” — in the following video.
So, below we will start talking about what the future may await “distributed ledgers” (including “blockchains” and “cryptocurrencies” as special cases), in the cruel world of objective laws of nature, where everything is ruled by the nasty “law of conservation of energy”. In the end, we will consider how the future may get improved with the consensus relying on the “weighted liquid rank” reputation system.
The application of the “law of conservation” to our case of processing of cryptocurrency payments on a network of nodes of a distributed network operating on the basis of the principle of peer-2-peer (“equal to equal”) is that there are four fundamental requirements for any system of conducting financial transactions in a “distributed ledger” where succeeding in satisfying any of the four makes it problematic to satisfy all of the others. So these are the four requirements.
- Speed — the payment transaction must be executed quickly, including both the time of its execution and payment confirmation and the period after which it can not be considered as a subject to “rollback” (so-called “finality time”).
- Cheapness — the payment transaction must be cheap, which means that the extra cost (like “gas”) or commission for its execution must be significantly lower than the amount of the transaction itself.
- Security — the system for conducting transactions must be secure, that is, it must guarantee the practical impossibility of non-authorized or malicious execution of any transactions violating the regulations or blocking the conduct of other legitimate transactions.
- Decentralization — the transaction system must be independent of any individual participants, that is, its consensus must be controlled in the worst case by more than 50% of the participants or the rights that they have allocated according to the current consensus formula (Proof-of-Work, Proof-of-Stake, Delegated-Proof-of-Stake, Proof-of-Reputation and so on).
Unfortunately, the practical situation with the fulfillment of all these requirements is such that none of the existing cryptocurrency systems on the blockchain can even, in principle, satisfy these requirements to such an extent as to become accepted by the broad masses of the population for making ordinary payments, which we usually make using Visa and Mastercard. Despite the fundamental nature of the mutual inconsistency of these requirements due to the laws of the material world and strict mathematics, the best minds of the cryptocurrency community are trying to find balanced solutions of various kinds, such as “sharding”, “sidechains”, “rollups” and their variations and varieties — any of these options improve the feasibility of one or more of the requirements above at the expense of others.
For instance, if you want to “quickly” pay for a cup of coffee at a kiosk on the street, you can quickly and cheaply make a transaction due to the “optimistic rollup” by means of a pool of transactions accumulated in the “side chain”, but after a week (“finality time”) the seller of coffee might get unpleasantly surprised to find that the payment transaction was rejected because the validators retroactively found fraud in the block your transaction fell into — fortunately for you and frustrating for the seller of the coffee. Well, it is possible to reduce the “finality time” by limiting the possibility of the “rollback” of fraudulent transactions in time, but then the security of the system is compromised.
In turn, the security itself can be increased by replacing the “optimistic rollup” with more advanced cryptographic protection of transactions in the “side-chain” pool using a “Zero-Knowledge Succinct Non-Interactive Argument of Knowledge” (“ZK-SNARK”), and this removes the need to wait a couple of weeks until the validators finish their work, but the coffee will still have time to cool down during the generation of cryptographic protection for the entire pool of transactions that include your payment, and the cost of computing costs for this can slightly spoil the taste of the coffee.
Another way to increase the speed and reduce the cost of transactions in the main blockchain without placing operations in the “side-chain”, as in the examples above, is to parallelize the main blockchain into independent “shards”, where the low speed of block formation with transactions in a separate chain can be compensated by a number of independently parallel formed chains, and each chain can be formed not by all nodes of the distributed network, but only by a limited set of nodes associated with a given “shard”. This would speed up the formation of blocks at the scale of the entire blockchain. However, this way we reduce the security of the entire blockchain, making each separate “shard” more vulnerable. Also, by doing so we make the system less “distributed”, but rather “decentralized”, with the computing “cluster” consisting of a set of “shards” with the influence of individual nodes on the consensus in each particular “shard” increasing and the overall security compromised.
As a bottom line, the ultimate solution for a fast, cheap and secure system of “decentralized” transactions is a computing cluster of a finite number of “shards” with several highly reliable nodes (“trusted comrades”) responsible for transactions in this shard. Bringing the situation to the point of absurdity (from the point of view of “distribution” and ideas of “crypto-anarchism”), we can have just one really-really highly reliable node in each of the “shards”, resulting in a simple scheme of multi-server balancing of transaction processing according to the “multi-master“. In the latter case, we essentially end up with a set of servers that parallelize the processing of transactions on shared memory with counter-synchronization of transactions across the cluster. If necessary, cryptographic protection of transactions can be added to this, but in the case of ensuring “high reliability and security” of each of the servers, the extra complication with such over-protection can only be a factor that increases the overhead for the user and excessive transaction costs. Obviously, this is kind of how well-known transaction processing systems like Visa and Mastercard work.
On the other hand, an even more obvious argument is that a decentralized system for processing transactions, claiming to be at a speed not lower than that of the known payment systems mentioned above, as well as the corresponding volumes, should not only provide adequate performance of equipment at each of the nodes but also introduce additional costs for each of “extra” nodes, added in order to increase the “distribution”, plus the time and network traffic needed for “reaching consensus”, growing exponentially with the growth of the number of nodes, plus cryptographic protection in the context of public deployment and the publicity of the “distributed ledger” data itself.
There are two conclusions from this whole story.
The first, the saddest one and not a new one is that no “distributed” (all nodes are equal, no clients and servers) system, in principle, can ever compete with a “centralized” (one server for many clients) or “decentralized” (several servers in a cluster for many clients) for any of such indicators as speed, cost, and security, moreover — for all three at once.
The second and the more practical one is that if increased speed, cost, and security are possible through partial “centralized distribution” or “decentralized centralization”, then an algorithm can be provided so that the “trusted servers” are those that reflect the interests of the community — according to the principle of “liquid democracy” applied to the “distributed ledger system management”.
The “weighted liquid rank” or “liquid reputation” algorithm used to determine “trustworthy nodes” within the “distributed ledger” protocol would allow dynamically reassigning “blockchain attendants” or relaying nodes responsible for signing and verifying transactions. In addition to that, it can also allow the formation of pools of nodes responsible for separate “shards” — in the case of blockchain division in order to increase scalability in terms of speed. At the same time, scalability and level of decentralization can be determined by just two parameters of the current state of blockchain configuration — the total number of “trusted nodes” in a cluster running blockchain M and the total number of “shards” in the cluster N, so that M = K * N, where K is the number of “trusted nodes” in a separate “shard “ (M ≥ N, N≥ 1, K≥1). Obviously, the management of these parameters in real-time during the operation of the system can also be the subject of a “social contract” and be determined by the voting protocol involving all of the participants, employing the same “weighted current rating” principle during the voting process.
It is important to note that the genuine Proof-of-Reputation algorithm, suggested by us in 2017 and developed by SingulariytNET during 2018 and later in 2019 is radically different from surrogate Proof-of-Reputation, based on “external” parameters that are not related to the dynamics of transactions in the distributed system itself, and is essentially a camouflaged version of Proof-of-Authority.
An experimental version of the “weighted liquid rank” (“liquid reputation”) algorithm has been successfully tested in the SingularityNET project and implemented by the Aigents platform and is awaiting its implementation and deployment as a full Proof-of-Reputation consensus in the “distributed ledger” systems and blockchains of the future!
In the meantime, let’s try the “weighted liquid rank” algorithm for the Telegram messenger, Discourse forums, and blockchains such as Steemit, Etherum, and Golos!!!
