Everyone can benefit from blockchain technology which has been tailor-made just for them.

Contents:

1. Blockchains are for everyone.
2. Bitcoin’s key takeaway point isn’t money or value. It’s the data structure.
3. Controllable = usable.
4. Scripting language + smart contract-controlled blockchain + commercial thinking = disruption ahoy.
5. You make the rules. We’ll make the tools.
6. My advice: never go full trustless.
7. TTPs can still help to achieve the crypto community’s social aims.
8. Don’t worry, crypto - you can still have tokens if you want them.

1. Blockchains are for everyone.

A. They don’t need permission. Everyone should be able to make their own protocol.

We know we’re going to take a lot of flak from some quarters of the crypto community for designing a blockchain that private individuals and organizations can control, without mining or tokens - and we accept that. But we don’t apologize.

Whether one person or one billion, we believe that anyone, anywhere, anytime should have the ability to instantly deploy their own smart contract-governed, blockchain-secure peer-to-peer architecture:

• for any application they want,
• on any parameters they wish,
• with anyone they choose,
• which is entirely free to use.

B. They don’t need to buy or sell tokens. And they don’t need to mine.

Thanks to the advent of smart contracts, Eris Industries’ Thelonious blockchain design and the Decerver, now they can - and they can get their blockchain talking to any other API or any other blockchain they like, including distributed filehosting protocols like IPFS or BitTorrent.

The GenDoug cryptographically-secure smart contract kernel allows anyone deploying a blockchain to set whatever consensus or security parameters they want, so long as they can define them - including securing the chain through “committing” rather than electricity-hungry “mining” - and allows updates of the system as time goes on, which can be effected on command without a difficult fork of their database.

People can get value from a chain perfectly fine without mining and tokens. We call this “doing useful stuff with a blockchain database,” or “crypto-utility” if you prefer. (But as it’s parameterisable, you can keep tokens and mining if you want.)

C. They know their needs better than anyone else. This includes “trusted third parties” such as financial intermediaries and application developers.

I also think it’s high time crypto enthusiasts accepted that, to some extent, trusted third parties are a necessary addition if you’re going to have a decentralised internet - and especially a blockchain-efficient financial system - that actually works.

There’s nothing wrong with trusted third parties in commercial relations. Indeed, making room for them on the blockchain makes dealing with legal rights and obligations far more efficient. In administered commercial deployments where a trusted party (or consortium thereof) will be operating a blockchain database - such as with an interbank clearing system, securities depository, or internal payroll management - a mining-driven database management model makes no sense. At all.

This is because, although the question of “trust” will have some internal dimensions, these concerns will generally be directed outward.

2. Bitcoin's key takeaway point isn't money or value. It's the data structure.

“But blockchains disintermediate financial institutions!” You argue. “That’s the cost savings! What’s your point?”

Infrastructure. That’s the point.

When you strip down a cryptocurrency application like Bitcoin and look at it as a pure technology, you see the key innovation isn’t the payments play - in our view, payments are something of a distraction. Adoption of uniform standards could achieve most of the cost savings just fine without using the blockchain.

Bitcoin provides an automated mechanism for its own particular brand of settlement. But it does this only by virtue of its blockchain database. The database, because of the manner in which it is parameterised, carries out secure transaction verification functions that currently require a lot of labour and fixed infrastructure - only Bitcoin does so without labour or fixed infrastructure.

So while blockchains are pretty good at moving money around, at Eris Industries we think they’re even better at deploying an interactive application without needing people or hardware.

The problem with the Bitcoin model, of course, is that while the protocol’s hard to break, it’s nearly impossible to fix. Your two-year-old, while playing with your iPhone, broadcasts your life savings to Japan? They’re gone. Lose your private key? It’s gone. Computer gets hacked? Gone.

3. Controllable = usable.

While Bitcoin is undoubtedly an efficient solution for the payments space, and one which (for various reasons) has appeal for very particular use-cases, blockchains are going to be way bigger than that. Bitcoin’s design generality - and its open, unregulated nature - means that, in our view, it is going to have a very hard time being accepted in mainstream commerce. This isn’t to denigrate Bitcoin in any way; it’s simply to say that it has its uses for which it is very good, and there are other uses for which it is not quite as good. And others for which it is no good at all, because it wasn’t designed for them.

Blockchains aren’t perpetual motion machines. Whether we like it or not, we always trust someone. Miner collusion to manipulate Bitcoin’s blockchain database without community consent is not some theoretical nuisance - it’s a real possibility, making the idea of a distributed system being entirely “trustless” a misnomer.

I’d rather trust people I can find when they screw up.

If we want a wider range of blockchain services in the economy - and by this, I don’t mean any political arguments for or against, but simply that we have the option, if we choose, to exercise a preference to use blockchain-secure, and blockchain-transparent, facilities instead of ones which don’t have the same functionality - we’ll get much further with TTP-administered blockchains.

4. Scripting language + smart contract-controlled blockchain + commercial thinking = disruption ahoy.

Blockchains are general-purpose, and they are software, so they will do what we tell them to do.

To get that utility, you’ve got to give the TTP the right technology to deploy a blockchain system. Thelonious, in conjunction with our Decerver web browser core, allows exactly that - without having to fork Bitcoin or any other existing chain, or rely on Bitcoin’s mining network.

This makes a great deal of commercial sense. If you’re building a blockchain-secure distributed application for a company, it probably won’t be designed to protect the company’s users from the company itself - the company will do that just fine on its own, out of commercial self-interest.

Such a system will much more likely be designed to leverage (1) blockchain fault-tolerance and (2) cryptographic smart contract architecture to protect both the company and the users of the application from malicious third parties, wherever and whomever they might be. Above all, it should be designed to reduce the platform operator’s costs.

As numerous bank/retailer/credit card hacks illustrate quite vividly, people everywhere would benefit measurably from a reduction of exposure to a corporate software stack, even if they continue to be exposed to the corporate itself. Cost savings too will be passed on. For an application to be run on these lines is probably something a company’s customers want.

Similarly, when we use web applications today, we don’t necessarily want to be overly involved in its day-to-day management. For non-financial applications such as social media, I should think an application’s users would want someone who is in custody of admin permissions to be able to make tough calls as to how to update the platform. On services almost everyone uses like Facebook, I don’t really want to know whether an upgrade is going through on the back-end that makes the user experience better - I just want it to happen.

And unlike current services like Facebook, if you don’t keep your users in mind, distributed architecture makes it very inexpensive for a challenger to design something better - and supplant you.

Mind you, you could always have user-controlled application governance - as we proposed when we built Eris 0.1 - where a democratic consensus is necessary to change an application’s code.

Welcome to scripting languages married to blockchains. If you can write it, you can run it.

5. You make the rules. We'll make the tools.

What parameters are appropriate, or contract suites are appropriate, for a given application will vary on a case-by-case basis. You know your needs; we know the technology.

That’s why Thelonious is a smart contract-enabled blockchain design, not a single blockchain. We’ve built Thelonious to be an enterprise-compatible, open-ended, smart contract-enabled, and smart contract-controlled framework over which you can drape your particular problem, define it, code it, test it, solve it, and (while still benefiting from the security of public-key cryptography) improve it later on, on command.

There’s never been another blockchain design quite like it. And we’re going to keep working to make it even better.

6. My advice: never go full trustless.

Crypto folks shouldn’t balk at the idea of a blockchain administrator in commercial applications. There are many practical problems with going “full trustless” - itself a misnomer, as I mention above - as the model is unlikely to work from a legal structuring perspective for a wide range of applications, even (and perhaps especially) in finance.

For reasons I won’t get into at length here, it strikes me that setting up circumstances where cryptography is able to interfere with recourse is not going to be an attractive proposition for most mainstream corporates, public sector bodies, charities, and others - because, for them “trustlessness” isn’t a very good deal. People have rights; where the equitable remedy of rescission arises, for example, a trustless architecture would be utterly incapable of expressing that (totally discretionary, fact-dependent) situation in code. “Digital assets” have to be convertible if they’re to be tradable at par - and this necessarily requires a third party of some kind, against whom the obligation of performance of the arrangements governing the digital representation of an asset can be guaranteedly enforced by a court.

If people have one platform which protects their rights and another that doesn’t, even if there is a very small cost involved, I’ll give you three guesses which one most of them are going to choose.

7. Trusted third parties can still help to carry out the crypto community's social aims.

Interpolating a TTP into the equation is no bad thing if we want to accomplish all of the objectives Bitcoin sets out to achieve - particularly the more philanthropic ones such as financial inclusion and reduction of remittance costs.

At the moment, Bitcoin and the altcoin ecosystem are only a partial solution - although crypto-token structures can be erected in developing countries that resemble a co-operative or a credit union, they rely on cryptographic tokens with no legal basis (and hope they have a stable non-zero market exchange value), thus exposing their holders to a higher degree of volatility than holding ordinary currency usually does. If financial inclusion is the aim, this is a problem.

The difference with Eris is that if you can parameterise it, you can run it. And if you can administer it, you can create and move around enforceable obligations on it - because the trusted third party necessary to create the legal nexus for enforcement exists. So these will be real entitlements to real assets and deposits of legal tender, just like with a regular, garden-variety database used in these applications today. It’ll just be cheaper to deploy and simpler to secure.

The advantage, of course, of deploying a low-cost financial services application along these lines is that it wouldn’t merely act like a credit union. It would be one.

8. Don't worry, crypto - you can still have tokens if you want them.

But don’t worry, crypto - we’re not throwing out the baby with the bath water here. Bitcoin undoubtedly has its place in the future of commerce - we’re not trying to compete with it, just trying to address a different set of problems. We’ve included both Bitcoin and BTCD modules in the Decerver so your distributed application can talk to Bitcoin with ease and, if you want, run a full node.

Remember, Thelonious is fully parameterisable - so you can keep tokens or good, old-fashioned mining if the application calls for it. All we’re trying to do is make it so that you don’t have to.