The more I learn about Crypto 2.0, the more excited I get about it, but on the other hand the more I realise just how nascent it is, and the need for compromise between today’s rails and Crypto 2.0 rails, and compromise between different emerging architectures.
I am starting to notice patterns of attributes and their dimensions that differentiate the various platforms, and the choice of compromises along a multitude of these attribute dimensions may have profound implications on the future architecture of finance.
permission-ed versus permission-less ledgers
I have already talked about one of the attributes in the Mining Rights blog – permission-ed versus permission-less ledgers. It looks like right now permission-ed ledgers offer an easier route to clearly identify both the miners and transaction issuers, so legally speaking a better fit for existing financial services, and have better latency as proof of work in not required – hence likely to be adopted first.
plaintext pseudo-anonmous transactions versus cyphertext transactions
Once homomorphic encryption is added to blockchains, a new dimension will emerge – plaintext pseudo-anonmous transactions versus cyphertext transactions, where the source, destination and contents of transaction are all encrypted, still verified by all, but readable only by private key holders. Protocols like ZeroCash are already making inroads today, see the Transaction Privacy blog.
identity and credentials
Yet another dimension is identity and credentials. Bitcoin for instance is pseudo-anonomous i.e. it has no in-protocol feature to relate a public wallet address identity to a legal entity, or better still assure without disclosing legal identity that the pseudonym has been attested by a reputable and trusted entity as having required credentials e.g. KYC checks. There are hacks to get closer though – see Simple Attestations blog.
As some dimensions develop, they may make others mute. For instance, permission-ed ledgers may not be required if platforms emerge that support
- quorum-slice consensus thus avoiding proof-of-work energy waste and latency issues but still featuring un-restricted access
- cyphertext transactions thus removing need for closed networks to ensure privacy
- credential attested pseudo-identies thus providing legal recognition
to Bitcoin or not to Bitcoin – that is the question
Then there is the question of whether you back off to Bitcoin or not. Many argue that Bitcoin has gained critical mass and there is no point in using something else – you can use colored coins and middleware solutions like Counterparty and Omni Layer to build on top.
I think there is significant risk with this approach as Bitcoin uses game theory and economic incentives to prevent attack, but if Bitcoin’s market capitalisation becomes much higher than face value, as coins are coloured, it may create new attack vectors that break the balance. Then again, I can see the attraction of building on top of Bitcoin too.
single versus multi asset chains
One dimension I wanted to discuss further in this blog is the number of assets a chain has been designed to support. IMO, Bitcoin is inherently a single-asset blockchain, supporting only the Bitcoin virtual crypto currency. For now let’s ignore colored coins and how they alter that statement, as they were never mentioned in the original white paper.
Although Bitcoin allows for custom scripts that open up possibility for use cases other than crypto currencies, they are not Turing complete i.e. no loops – a design decision to prevent an attack on the network by using an infinite loop transaction.
In fact most logic is fixed at protocol level e.g. currency issuance, consensus etc. A further restriction is that most miners will only accept five types of script, again to protect against rogue script attacks.
Something like Ethereum on the other hand is a multi-asset blockchain by design as it supports the ability to create smart contracts a.k.a. distributed applications with custom logic, thus enabling modelling and creation of, in principle, any kind of financial or other instrument. To support this complexity, such platforms have to support Turing complete scripts.
Support for Turing complete logic can be provided in different ways. Ethereum allows you to upload a custom distributed app and start using it without modifying verification servers. Omni Layer provides a middle-ware tier that allows for business logic plug-ins, that must be installed and upgraded as appropriate on all verification servers. Others fork Bitcoin or other platforms and provide altcoins.
Eris takes this even further and allows you to work against different types of distributed ledgers for its persistence layer, unlike Ethereum that bundles smart contract execution and storage into one. This means that you can execute your code against either a permission-ed or permission-less ledger as appropriate for your use case.
Then there is the middle ground, let’s call it asset-class chains e.g. NXT, Ripple, Stellar. These chains may support one or more asset classes e.g. multiple types of loyalty coins, or fiat pegged proxy currencies. They may have one or more templates for an asset class, and as long as you are happy with the built in business logic, you can in effect instantiate a variant of them for your own purposes.
From an operational cost point of view, personally I am more drawn to multi-asset chains as the potential need to mine hundreds of different chains and dealing with side chain pegging etc., something that has been talked about but is very nascent, makes me think will have high overheads.
One of the downsides of a single multi-asset chain is risk concentration. Not the traditional operational risk associated with a central operator, there is none, but risk of protocol defects effecting all financial instruments. That said, much of the modern banking and indeed the world already relies on common sets of Internet protocols.
The other downside I can think of is performance. Multi-asset chains have to by default be generic and not optimised for specific use-cases, whilst single-asset and asset-class ones can be optimised. Protocol or plugin code can be run outside of a safe VM where custom code is executed, something not possible with distributed apps, as VM guarantees isolation and protection against rogue code.
Take Ripple and Stellar – they have created a decentralised exchange capability using order books, and implemented it as part of the core protocol. Same order book concept could be implemented in Ethereum as a distributed app. I have not tested performance, but I would assume Ripple and Stellar will be faster.
So it may be that higher frequency use cases will have to use protocol or plugin centric solutions, at least until distributed app platforms get fast enough.