Proof of Stake lacks a fail-safe

I've discussed my various doubts about the delegated Proof of Stake a few moths back. Thinking about it some more recently, I have one more idea to add to that discussion that applies both to Proof of Stake, and distributed PoS - the lack of a fail-safe.

People criticise Proof of Work for creating centralization. Bigger miners earn more money that they invest in faster mining equipment to earn even more money and so on until there is only one entity that essentially owns the network. Everyone fears centralization in Bitcoin as it can bring about the dreaded 51% attack. However, a lot of people, including myself aren't really worried about this. Andreas Antonopoulos explained it well during the Texas Bitcoin Conference - a 51% attack isn't much of a threat any more since we can always fork the software and make the current ASICs obsolete. Just like that, any mining operation that relies on those specialized chips have it in their best interest not to attempt to be a malicious entity - they have too much to lose. While a malicious "government entity" (or anyone that wants to destroy the network at a cost) would not case about the losses, it wouldn't be able to accomplish anything regardless.

Looking at Proof of Stake, the network essentially lacks this fail-safe. If an entity controls the majority of coins in the system, they can perform a 51% attack as well. To take the network back, either one would need to abandon the PoS mining algorithm, or erase the malicious entity out of existance. However, due to the pseudonymous nature of cryptocurrencies, the attacker in question can easily shuffle their coins to new addresses and spread them around so much they become essentially indistinguishable from anyone else in the network. Tweezing them out would be hard and a lot of other people might get removed by a false-positive. As such, the network that relies on Proof of Stake cannot purge itself from a malicious attacker, like a Proof of Work network could.

Of course, a non-malicious entity wouldn't want to perform a 51% attack on the network. The attack would evaporate any value their stake would have. However, a malicious "government entity" that wished to take down a PoS network would have a much easier time doing it, since forking them out of the ledger would be much harder.

Open Riptherium - thoughts on the "ultimate" platform

Counterparty recently announced its full port of the Ethereum's turing-complete programming language into its platform. Some people are calling this the end of Ethereum and other such sensationalist things. Similarly, Ethereum and Sidechains have been heralded as the altcoin killers. It does very much look like everyone's on a lookout for "the ultimate platform". This makes it as good a time as any to share my opinions on the matter, as this topic has been rattling around my head for a few months now.

Open Riptherium - the ultimate platform

When it comes to the Crypto 2.0 platforms, we have a couple of projects innovating in three main paths:

• Variety of financial transactions
• Lead by Open Transactions and Counterparty
• Focused on delivering advanced financial transactions - contracts for difference, shorts, longs, leverage, derivatives, etc.
• Ease of money flow
• Lead by Ripple
• Focused on connecting any number of currencies together through a web of trade pairs and making the flow of capital between the currencies rapid and unobstructed
• Scripting
• Lead by Ethereum and recently Counterparty
• Focused on developing a universal programming language to execute any program or smart contract on the blockchain itself

An ideal platform would address all three aspects of the Crypto 2.0 space. Of course, those are only the main branches of the development in the space. There are a few smaller aspects that can make or brake a system. Lets discuss some of them.

The details

Coin distribution. Any decentralized system needs some means of spam prevention. This usually comes in form of transaction fees that are either paid or burned. While there are a few projects that do away with native currencies entirely (Hyperledger and Open Transactions come to mind), it is more likely than not that a Crypto 2.0 system would have a digital currency built in. A fair coin distribution model would be needed to ensure a good start to the system that doesn't unfairly benefit some people over the others. Ethereum, Mastercoin and Counterparty can be viewed as having a few distinct distribution models that are generally considered fair. Ripple on the other hand, is an example of how not to distribute tokens if you want to create a decentralized system.

Scripting. While we might not know yet what really innovative things scripting will enable in the future, it is certainly a feature that you want in your system. It can help address a lot of edge-case scenarios, from creating smart contracts, through personalized escrow, up to innovations that are barely related to money, like a distributed DNS. Scripting seems to be like the Internet in the 90s or 2000s - we know it will be a big deal, but we haven't had our Wikipedias or Facebooks yet. Ethereum and now Counterparty are leading on this front right now.

Token creation and trading. Crypto 2.0 systems are all about everyone being able to create their own tokens and trade them freely on the same network. Whether you are issuing IOUs for fiat currencies, or creating personalized tokens, you want the process to be as smooth as possible. Similarly, once the tokens are created, there needs to be an easy way to send them to anyone else on the network and to trade it for anything else on the network. Ripple does an excellent job of this. All currencies are on a level playing field and can be exchanged easily. Counterexamples would include NXT and Counterparty, for only allowing trades between the token and the native currency, and Mastercoin for charging an arbitrary fee for token creation.

Another important aspect to discuss here is whether token creation and trading is supported natively by the platform. I remember hearing Vitalik Buterin's talk on Ethereum awhile back where he was discussing scripting. The gist was, that scripting is a general purpose language - it can be used for creating any application, rather than having a set of predefined application logic. While this means that one can create any token in the system, the flip side is that one would need to code in every single functionality of a currency into that custom script - order matching, futures, demurrage, etc. As a lot of programmers can tell you - a script is never as fast as a dedicated application. This is why I think that for at least the basic currency logic (sending and exchanging money), a dedicated part of the code native to the Crypto 2.0 platform is needed to make it operate optimally. I would be very surprised if an Ethereum script could perform multi-currency hop transactions as cost-effectively as Ripple or Open Transactions. So while scripting can solve a lot of the edge-cases, I think dedicated logic for some of the currency logic is still beneficial.

Gateway incentives. Trading digital currencies is all well and good, but there are also a number of reasons to want to use traditional currencies on the system. Being able to send people USD across the glove just as fast as you can send bitcoins is a big selling feature of the 2.0s. However, those tokens need to come from somewhere - they need to be created by gateways. However, for anyone to want to go through the hassle of providing business-grade tokens, the system needs to allow them to monetize on their work. So far, only Ripple appears to have done this well through transfer fees and built-in demurrage. 

Other financial transactions. Since Crypto 2.0s are mainly about monetary transactions, allowing the users to easily tap into a variety of them is a benefit. Just like you can have distributed exchanges on the blockchains, you need distributed contracts for differences, shorting and so on. Open Transactions appear to be leading in this regard (from what I heard from one of the developers - they have implemented every kind of financial transactions) and a few platforms like Counterparty offer more than the rest.

Speed. Ideally, the system should run a lot faster than Bitcoin. A system that runs near real-time will be prepared to ones that update every 10 minutes. As always, there is a trade-off between speed and reliability. Open Transactions and Ripple are some of the fastest networks out there - OT being essentially instant, and Ripple clocking in at 2-5 seconds for a fully-confirmed operation. This is probably one of the biggest reasons against completely tying a system down to Bitcoin's blockchain like Mastercoin and Counterparty.

Security, reliability, etc. The basics you would expect from a Bitcoin successor. The network needs to be secure, the crypto needs to be strong, etc.

A good implementations. No matter how good the system is on paper, the implementation itself needs to be good as well, both for the casual users, as well as developers. While Open Transactions might have a lot of functionality, it is rather inaccessible to common people from what I heard. Counterparty, BitShares X and Ripple appear to have a good implementation in contrast.

In conclusion

In conclusion, there are a lot of features one could expect from an ideal Crypto 2.0 system. None of the current solutions appear to have all the answers yet, but a lot of them are innovating on one or more of the areas.