The concepts of Usechain have to do with some key blockchain ideas, including Byzantine consensus, so it would make sense to outline what this all is about. Ok, let's discuss various things, gradually approaching the key topic of our conversation. First, there's an interesting logistical problem that includes two generals who need to attack the enemy castle simultaneously. The generals communicate with each other sending couriers, so when, for example, one is ready to attack he sends a courier to another, informing him that he's ready to attack. Then the second general receives that information, so they can begin the attack simultaneously. The problem is that when the courier delivers a message he has to pass through an enemy camp, so he can be captured, which means that the message won't be delivered. So the second general upon receiving the message sends back another courier to ensure the first general that he received the message. Then the first general can be certain that his intention to start an attack was successfully communicated. Well, but then how the second general will know that his message, in which he acknowledges that he's received the first message and ready to attack, is delivered? Like, according to this protocol, the first general is sending his intention to attack, but he will not start the attack until he receives the confirmation that his message was successfully communicated. If the second courier is captured by enemies, then the second general will start the attack while the first will stay on his positions. Theoretically, the protocol can be expanded further like, when the first general receives confirmation that the second general received the message of his intention to attack, the first general can, in turn, send confirmation that he has received that confirmation. But it doesn't improve the situation because, once again, the last courier can be captured and the last crucial confirmation will never be delivered. So synchronicity of the attack will be broken, and the attack will fail. This algorithm can be expanded indefinitely, but it always comes down to the last message and the uncertainty of the situation with it, like, whether it's delivered or not. In fact, this task cannot be solved algorithmically.
Another similar hypothetical situation involves a group of generals who need to make a decision: either to attack a castle altogether (or at least with a sufficient number of them participating in the attack) or to withhold from the attack. If they attack, but there's not enough of them supporting the attack, they'll fail. The generals communicate with each other through lieutenants who deliver messages. The problem is that part of the lieutenants can be traitors so they will deliver deliberately incorrect messages. Moreover, some of the generals can be traitors as well, so even when they receive a legitimate message about the planned attack, they'll stay at their positions, trying to make the attack fail. From a mathematical point of view, the key question here is whether there could be an algorithm, allowing to guarantee a valid consensus among the generals despite the problem of traitors. It doesn't mean that they all have to decide to attack, it can be any kind of decision, the important thing is that the majority of them need to agree on the same thing notwithstanding the proliferating disinformation and the renegades among their ranks.
The aforementioned problem is called the problem of Byzantine consensus, and it emerges in various forms in distributed systems that include a number of participants, whose behavior and intentions cannot be predicted in advance. Part of the participants can be malicious actors. The gist of the problem is how to achieve the consensus among all the members in a situation of uncertainty with limited information and the possibility that some of them are deliberately spreading disinformation. One of the key theoretical achievements of Satoshi Nakamoto is that he managed to solve this problem in its classical form. He introduced a solution to the Byzantine Consensus problem, based on another useful concept: Proof-of-Work. In a nutshell, Proof-of-Work underlying assumption is that something has to be valid if there is a significant amount of efforts invested into it. Like, for example, imagine a village, which is located near the river, and the villagers need to get access to another bank, but they cannot agree whether they want to build a bridge or to build a wharf and organize a ferry commute. So part of the villagers starts building a bridge and another part start building a wharf. Let's assume that it takes an equal amount of efforts to build a bridge and a wharf. So it means that the project that is attracting more participants, who invest more efforts into it, will be finished quicker. So, for example, if one-third of the villagers are engaged in building a wharf, and other two-thirds of the villagers are building the bridge, the bridge will be finished quicker. Which essentially proves that building a bridge was the right decision in the first place.
Note that Proof-of-Work is different from the voting process. Voting doesn't require from its participants to put hard efforts into achieving their goal. In this sense, Proof-of-work is a more reliable way of reaching a consensus since it implies that there are rational behavior and motivation. In other words, nobody will put efforts into something that won't likely to bring some kind of reward in the end. This additional condition adds the concept of incentive into the equation. Naturally, the majority of rational actors will strive for the goal that's really worth pursuing. (As opposed to voting when the decisions are often made on a whim) The implication is that the consensus achieved through the proof-of-work process is likely to be the correct one, like, if there are several courses of action, proof-of-work consensus will choose the best course of action.
So, yes, the proof-of-work is a really meaningful way to reach a consensus, somewhat guaranteeing that the majority agrees on something really sensible. The problems of this approach in the realm of cryptocurrencies are well known: they are related to the heavy overhead in terms of computational resources consumed by such system. On the blockchain, the proof-of-work concept is realized in the form of a process, in which its participants confirm valid transactions by compiling them into blocks and calculating hashes that "seal" the transactions. A couple of additional rules makes this hash calculation a difficult process, requiring advanced computing equipment and a lot of electric energy. You might ask, what point is in making this process so difficult? Well, it has to do with the aforementioned Byzantine consensus problem. The computational difficulty in this situation is the only way to guarantee that the system won't be gamed by malicious actors. Let's assume that we have valid and malicious transactions that compete to be added to the chain. We have a group of people, "miners," responsible for adding and confirming transactions. If the process of confirmation was easy, like, if it could've been done easily by a single miner we would have a situation where valid and malicious transactions have an equal chance to be added to the chain. We cannot guarantee that some of the miners are not malicious actors, trying to game the system by confirming invalid transactions. With the proof-of-work mechanism in place, transactions can only be confirmed by a concerted effort of the majority of miners. Assuming that miners don't conspire with some nefarious intent, it's safe to conclude that the majority will behave rationally and confirm only valid transactions. This certainty is based on the fact, that for the majority it's more important that the network functions properly than to extract some one-time benefit by hacking the system. Also, here's one of the principles of Game Theory at play. A miner, even if he himself has some malicious intent, doesn't know intentions of other miners. What he knows is that if he tries to game the system, he won't be able to succeed on his own. To use previous analogy, if more than a half of the villagers build a bridge, and the rest build a wharf, the bridge will be finished first, making unfinished wharf irrelevant. Similarly, on the blockchain, there might occur some temporary branching, at this point some of the miners are working to maintain a wrong chain. (A chain, containing invalid or malicious transactions) But there is a strong reason to believe that the majority will always work on the correct branch. As I mentioned above, this reason is based on two factors: first, their interest in maintaining the network in working condition, and the second is their assumption that other actors in the system are going to act rationally.
If it's still unclear why there should be any work involved (in our case those heavy computations) let's compare this system to the voting process. On the surface, it's similar, like, if the majority of participants is well-intentioned then the majority vote will likely favor valid transactions and reject any shady transactions. In fact, it's not the case. The difference is that when I participate in a vote, it doesn't cost me anything. I can vote for whatever option I fancy at the moment; if I deliberately vote to support some nefarious activities, it won't cost me anything either. In this situation the system becomes much more volatile, its members will constantly be attempting to game the system if there's any, however small, chance to succeed. In the case of proof-of-work though, any such attempt comes with a heavy cost of wasted time and resources attached. This is what makes this system stable.
This leads us to the next point of our discussion. Ok, if voting is not a viable way to solve the Byzantine problem because there are no repercussions for irresponsible voters, why not to attach the cost to the wanton and reckless voting. For example, each voter stakes some amount of money on their votes, and if somebody's vote goes against the majority vote, this person loses his stake. This will ensure that everybody would think hard before casting a vote, and, once again, here come into play this factor: If I don't know in advance how the majority is going to vote, I assume that they'll vote for the most reasonable option. In the case of the blockchain, the most reasonable option is quite obvious; it's a block, containing valid transactions. Here we come to the concept of Proof-of-Stake. Proof-of-Stake is a viable alternative to the Proof-of-Work algorithm, and it also requires much fewer resources in terms of computational and electrical power. Alas, Proof-of-Stake algorithm has also some intrinsic problems, including those related to an imbalance, produced by the situation when the system's participants with a larger amount of money have more weight in the voting process. Without getting further into technical details, it's worth mentioning that PoS algorithm has multiple implementations, differing by various additional conditions.
Thinking about new approaches to solving the Byzantine consensus problem; some of them are based on the existing classical algorithms with an additional twist. The Usechain project is a new blockchain platform, offering the concept of Mirror Identity on the blockchain. In a nutshell, the concept of Mirror Identity allows creating a link between blockchain wallet owner's identity and information related to this person in real life. The concept offers a balance between privacy and availability of personal information, sufficient, for example, for conducting KYC/AML checks and similar operations, where disclosure of a certain amount of user's personal data is unavoidable. Currently, a number of projects work in this direction, and there's already a coined term for a complex of technical ideas, related to blockchain based identification, "Sovereign Identity." One of the key concepts, the technology of Sovereign Identity heavily relies on, is "Zero-Knowledge Proof," an algorithm allowing to disclose only a minimum necessary amount of personal information, without revealing anything else. For example, if some organization needs to know if I have a driver's license, the system of Sovereign Identity will give it a yes/no type of answer without disclosing the license number. Zero-Knowledge Proof, in this case, guarantees that information provided by the system is correct. What's important, the requester doesn't need to trust the system; the correctness of data is ensured by the algorithm itself.
One particularly interesting feature of the Usechain project is its approach to the network consensus problem. We discussed before the most fundamental algorithms, PoW and PoS, designed to ensure that network's participants act in a way beneficial for the network, in the case of blockchain it means: confirming correct transactions and rejecting those incorrect or formed with malicious intent. The Usechain project developed a modification of PoW algorithm that allegedly will be as reliable as PoW but without PoW's traditional ills: slow transaction confirmation speed and excessive resource consumption. The proposed concept is called RPoW or Randomized Proof of Work. The gist of the idea is that the system adds a coefficient of "easiness" to the process of block hashing. This coefficient is randomly assigned to some of the miners. The way I understand this, it implies that the difficulty of hashing for those miners is reduced, so they have an advantage, regarding the block hash calculation. The project claims that this approach can solve the problems of heavy resource consumption and network scalability. Speaking of resource consumption, indeed, even a perfunctory look into this idea reveals that, in fact, such system won't be relying on heavy calculations anymore. This leads to a lot of implications. For example, mining rewards won't depend on the amount of computational power the miner possesses. Rather the system will pick lucky miners, allowing them to hash the block without any problems. In this situation, having expensive hardware or the whole mining farm, filled with mining equipment and cooling systems, doesn't give any advantage. In other words, anybody with any kind of computer will be able to mine blocks, but the potential profits will depend on the luck of being chosen by the algorithm. Theoretically, it upsets the balance of the classical PoW paradigm, where the correctness of the blockchain is guaranteed by the assumption that the majority of miners is always going to act reasonably. For example, if there's branching on the blockchain, the majority will work on the correct branch, making it longer faster. (as a result incorrect branch "withers") On the other hand, when the RPoW system picks a group of miners from the overall pool of miners, what chance is there that they'll suddenly conspire and decide to add the block to the wrong subchain? And, once again, for any insidious scheme to succeed in this situation, multiple randomly picked groups of miners have to repeat this subversive action over and over again. In fact, it's interesting that the other miners, facing the standard high computational difficulty of hashing, are still going to work on the puzzle as well. It means that mining farms will be competing with individual miners with a reduced level of hashing difficulty. It's hard to predict right off the bat how such system is going to work, but it seems like it creates another kind of balance based on a combination of two different mechanisms working at the same time: the classical Proof-of-Work and a system, which is more similar to the voting process than mining.
All in all, the Usechain project has a number of interesting technical ideas and proposals. Currently, there's a lot of different experimental consensus algorithms aiming at replacing Proof-of-Work, without any of them having a definitive lead. In this situation, any new idea in this area is worth noting because a new winner among consensus algorithms is yet to be named.
Starting from June 20, 2018, Usechain will conduct a token sale, aiming to distribute 45% of its supply of 20,000,000,000 UST tokens. The fundraising goal is 28,500,000 USD
Useful links
Website | ANN | Whitepaper | Telegram | Facebook | Twitter | Medium | Reddit | Github
Authored by: faragly (@popeye_the_sailor)