Bitcoin Q&A: Why permissioned blockchains fail


“What criteria would you suggest to determine
whether a task or function is better executed…
on a permissionless blockchain, as
compared to a centralized system?”
“Do you think permissioned blockchains are
real blockchains? Do they have a role too?”
This is an interesting question, D.J.
Permissioned blockchains are blockchains, sure.
What they are not is open blockchains
or permissionless blockchains.
They are blockchains, they just don’t have any of
the interesting features we find in open blockchains.
Some of the features that people ascribe to
blockchains, are not features of [all] blockchains.
They are features of open, decentralised blockchains.
For example, immutability is [about]
recording something and having a guarantee…
that it cannot be changed [later], even if
verifiers are coerced into changing it.
Bitcoin is a system that provides
the immutability guarantee.
Even if 100% of the miners wanted to change
the blockchain, or were being coerced to do so,
they still [must] expend the proof-of-work energy, or risk
their blocks being invalidated by the rest of the system.
There is no shortcut.
Proof-of-work, and the decentralised nature of
the consensus algorithm, creates immutability.
If you have a system of federated signers,
a permissioned or private blockchain, “decentralised
ledger technology” as it is sometimes called…
Let’s say you have a group of sixteen signers:
sixteen members of a coalition, the largest participants
in a stock market or bank transfer network.
They are all federated signers.
If you serve a subpoena to all sixteen of them and say,
“You must change this transaction,” or
“Make sure [this transaction] never happens,”
“This transaction back in January was
paid to WikiLeaks and we don’t like that.”
“Here is a court order that says the transaction
never happened. Please amend your blockchain.”
The federated signers can do that; if they can
do that, then under the law they must do that.
It is no longer immutable, no longer censorship
resistant, no longer neutral, no longer borderless.
These federated signers are subject to the jurisdiction
of whichever state they are in. They can’t open it up.
It is no longer permissionless because
they [must] vet every participant.
The issue here is, once you take out the decentralized
nature of validation in the consensus algorithm,
then a lot of the things you think blockchains do —
giving you censorship-resistant, neutral, permissionless,
immutable transactions — go away.
What you have is a distributed database for recording
transactions, if the federated signers want to allow it;
something that is not immutable, censorship-resistant,
neutral, borderless, or permissionless anymore.
Is that thing useful? It depends
on what you are trying to achieve.
If the application you’re trying to achieve doesn’t need
censorship resistance, neutrality, borderless access,
or immutability, then maybe it is useful.
Of course, you [will] have other challenges.
In an environment of federated signing, you have the
problem that the signers are usually competitors.
Therefore they [will] try to tweak the system
to give [themselves] maximum advantage.
In a decentralized blockchain, the self approach (where
everyone is assumed to act purely in their self-interest)
is the basis of the game theory that makes it secure.
As long as everybody acts in their best interest,
the system is actually fair, predictable, and secure.
That is how proof-of-work works. It assumes
that everyone will act purely in their self-interest,
but because they’re constrained by the [rules of
the] system, they are forced to operate it [honestly].
[Honesty is] in their best interest.
However, in a permissioned system, if the federated
participants are acting in their own self-interest,
you have a problem because
they can be identified and coerced.
They have to participate in a collaborative manner [while
being competitors], so the incentives are misaligned.
You can see this every time you look at an industry
trying to create common standards by committee.
They may start off with good intentions.
‘Let’s make a new standard for how
we do financial exchange protocols.”
As the participants get together,
each one has a vision of what will be in their
best interest, and try to add that to the standard.
The standard gradually [becomes] more
complex because of this jockeying for position.
In the end, it is not really a standard, but a wishlist
collection and kitchen sink ‘bikeshedding’ that happens.
These standards don’t get applied in the
real world because they’re too complex.
There is too much opportunity for one
party to take advantage of another.
A classic thing you see in protocol development is…
big companies [coming] together to build a common
standard, [while their] lawyers are in the background…
filing patents for those same things,
in order to gain an unfair advantage.
This happens all the time.
You see, over decades of attempts to [make common
standards in banking, this continue to collapse.
Whenever the standard is designed by committee,
all this jockeying for position results in a mess.
Theoretically, permissioned blockchains with
federated signing based on a common standard…
would bring the industry together,
create more collaboration,
allow banks to have faster and
fairer networks for transactions.
In practice, they never get there because of
squabbling and jockeying for position internally.
They end up creating either a terrible standard
that doesn’t serve anyone’s needs,
or a standard that nobody uses because
they feel they will be at a disadvantage…
because the standard mostly
expresses somebody else’s interests.
We have seen this again and again,
most recently with R3 and their efforts to create
standardized financial services blockchains.
Again, all the prototype implementations have not
succeeded. We saw this with internet protocols too.
TCP/IP was not the obvious winner.
Today, it is clear that the internet is TCP/IP.
But back in the early ’90s, the conversation was
very different. People said TCP/IP [would be]…
an interesting — but edge — case of the information
superhighway, which would be primarily based on…
robust enterprise protocols like
the ISO, OSI, TP4 for example.
Protocols like ATM and those proposed
by IBM, Microsoft, and other [companies].
TCP/IP [was] a small corner of the information
superhighway, mostly [used by] academics.
TCP/IP wasn’t really suitable for enterprise because
it didn’t have enough features that enterprise wanted.
Where did we end up? The “information superhighway”
is a silly term that people laugh at today.
The internet is TCP/IP. You have probably never heard
of the other protocols, TP for an ATM and the OSI stack.
You probably don’t run ISDN.
Those were proposed by the telecom companies.
All of these things went to the wayside. Why?
The value [of the internet] came from open, interoperable
protocols where no one had a distinct advantage.
We [will] see the same thing happen with blockchains.

25 Comments

Add a Comment

Your email address will not be published. Required fields are marked *