As mentioned elsewhere, a lot of work is also being done on decentralizing the oracles. Like PoW / PoS protection, this raises the cost of an oracle attack high enough to reduce the risk to acceptable levels for more sensitive applications.

To do anything more meaningful, code needs to interact with the real world. And this is generally the point at which blockchain apps lose all of their purported benefits, like decentralization, immutability, reliability and so on.

Asset issuance, voting, wills, identity/reputation systems, land registries.

Fundamentally, a blockchain is just public, transparent immutable data history. Of the above sample cases, all it takes is for the powers to be to recognize the data as a reflection of the real world; which is a barrier outside of the technology.

And sidenote, decentralized oracles will literally tie outside world to the blockchain.

All of which reach beyond the blockchain. No-one is going to care that a 'smart contract' says that Alice owns a plot of land when Bob holds the real-world deeds.

The real world and the blockchain can only be linked when, as you say, 'the powers that be' decide to recognise the data. But then you've lost all of the advantages that the blockchain was claimed to possess. For example, if we need an entity to recognise that the land registry smart contract is valid, there's no more decentralization, and we might as well let that entity store the land registry in their own simple database. The blockchain becomes pointless and wasteful.

That's a very wide brush stroke to paint. You just have to analyze each use case independently.

In the same example of land registry, just a transparent history is a huge value add when dealing with corrupt government officials. Here's a case study https://s3.amazonaws.com/ipri2016/casestudy_collindres.pdf . Voting transparency even with the government as the part of centralization is a huge value add imo.

Further, even allowing centralization in certain points, like a SpaceX IPO (which should def be centralized), allows whoever holds a share to make arbitrary, trustless mediums and rules of exchange.

With Ethereum, one way to do it is to make the voting weight non-transferable, meaning to give someone else your vote you'd need to give your private key.

It would be of course crazy to do that; like giving someone your bank card and PIN number to give them cash.

The terminology seems to have changed to mean any system that provides external data to ethereum contracts.

https://medium.com/@signal_capital/https-medium-com-signal-c...

> Several data providers respond to this service agreement with a bid in the form of a data reply — when enough data providers have responded, the majority response is taken (or average depending on the request), outliers are removed, and data is fed into the contract.

What's to stop me from setting up 10,000 different data providers that initially provide good data to get a good reputation score, but then slowly corrupt them over time? It doesn't matter how many data providers you average if I can set up millions of them in seconds. I don't see any way to solve Sybil attacks here.

This is false. Where did you get that impression?

https://en.m.wikipedia.org/wiki/InterPlanetary_File_System

In 2014, the IPFS protocol took advantage of the Bitcoin blockchain protocol and network infrastructure in order to store unalterable data, remove duplicated files across the network, and obtain address information for accessing storage nodes to search for files in the network.

https://cointelegraph.com/news/ipfs-protocol-selects-ethereu...

https://mobile.twitter.com/Alex_Amsel/status/778440701902139...

IPFS itself has never had any cryptocurrency integration, although there are external services that store your data on their IPFS nodes in exchange for Bitcoin.

(source: https://filecoin.io/blog/update-2017-q4/ and I'm on the IPFS team)

There will also likely be a small amount fo LINK required to start a node with enough reputation to gain assignments which would also increase the cost of a Sybil attack.

So, a prisoner's dilemma situation here? If one person objects, everyone loses their money? Who gets the payment? Are the coins permanently burned? If so, seems harsh in the face of accidents. If not, seems open to abuse if someone could be both the smart contract creator and a data provider. I create 100 data providers, and a smart contract, and when I detect someone new has joined my pool, cause them to lose their coins which are sent to me.

> There will also likely be a small amount of LINK required to start a node with enough reputation to gain assignments which would also increase the cost of a Sybil attack.

Ah, so an economic majority that successfully scams others and acquires a mass of tokens can use them to launch more data providers.

What do you mean by this?

For the sake of example, imagine this is a market that is being used to trade fishing rights for a region off Iceland.

Each of the five has a holding of Consortium Coin on this chain. This give them voting power in any decisions that have to be made of the chain. None of the second-grade members have any Consortium Coin.

The second-grade members trade in Fish Coin and Boat Coin.

Each of the five operates an oracle feeding to the consortium. It provides fisheries stocking data, and records of dock inspections of member boats. Each piece of incoming oracle data is signed to indicate that it is backed by the Consortium Coin holdings of the operator (proof-of-stake).

A simple election/raft algorithm decides that Oracle advice is true once it passes a threshold of so-much Consortium Coin.

There are contracts signed in western countries where the five firms are listed. These contracts say - essentially - that they will operate in good faith on the chain. (If they did not, they could be sued in the usual way).

There is a direct line out of this chain into the regulator, who runs analysis algorithms against the reported behaviour, and compares that to their independent mechanisms.

Bribery could still exist off-chain. But that is not new, and we do alright at protecting against that through current systems of governance. In this scenario, the thing your proof of stake is protecting against is a non-consortium blockchain member setting up a rogue oracle.

Why is this valuable? If ppl get the model right, you can run sophisticated markets like this without any civil servants being involved. It may turn out to be policy-wonk heaven. You can cut the size of the civil service, and yet have much more nuanced regulation, and better game-theory for operating markets.

Next: a social network going where people indicate trust of one another, and act as semi-guarantors for people they have vouched for.

Next: operate sections of the legal and judicial system over the chain.

Human actions captured on a cheap, secure, distributed ledger.

So what does the blockchain add? Why can't this be a database set up by the consortium?

If the blockchain community gets the contract/language issues sorted out, a small dev team could knock out a first-stage system like the fisheries system in three months and in two layers of technology (contracts, oracles). It would be trivial to operate and resilient to server failure (less-so the oracles). Ten years later, it would still be just the same two layers of code.

In this world, contracts make custom APIs obsolete. There is a new career path for a developer who lives and breathes async contract code.

The way of implementing such a system now is db-centric. Business problems tend to be event-driven, but databases are not. So we need many more layers of technology: ERD, stored procedures, 'backend', partner API, hosting complexity, business continuity complexity, further layers to assist support and deployment and API onboarding.

The database company takes on a life of its own, it is expensive to fund and delivers a bad customer experience.

So the thing that blockchain adds: you will able to reliably build significant systems with two-person teams in domains where we currently struggle to do adequate work with firms of twenty or forty people. We will be able to engage with more complex domains than we can at the moment, and there will be network effects from this.

My focus is multiple-host, centralised async systems. I think this is the future, and that databases will be marginalised. Comment here elsewhere gives more details.

I may turn out to be wrong. In that case, we will end up in the kind of blockchain world described in my earlier comments. I suspect it will hinge on whether it is possible to create a good-enough high-level language.