Re: Hyperledger Besu Proposal is Live
|
Richard Brown <richard@...>
Hi Silas,
Thanks for this write-up; I found it helpful.
All,
I hope nobody minds my joining this discussion but I think the framing of the proposed contribution of Besu provides the opportunity for a timely technical/architectural debate. In particular, I understand that the basis of the proposed contribution (the ‘net-new capability this contribution would make to Hyperledger’, so to speak) is the Besu client’s ability to talk to the public Ethereum network – and that, by implication, this would be of value to a project whose mission is to: “create an enterprise grade, open source distributed ledger framework and code base, upon which users can build and run robust, industry-specific applications, platforms and hardware systems to support business transactions.”
I regularly see claims online that connecting a “private” or “permissioned” blockchain to a “mainnet” can provide benefits but I’ve always struggled to understand exactly what those benefits would be. The problem, I think, is that Tweets and Medium articles aren’t really the place for nuanced technical discussion. Hence why this very narrowly focused proposal in this forum is such an opportunity.
I know there can be emotion and I am obviously not unbiased so in what follows I’ll try to keep the discussion generic as I try to outline what I don’t understand – and ask for help in figuring out what I’m missing.
First – let’s check we have similar mental models. For me, the whole permissioned/permissionless thing is solely about transaction confirmation. Specifically: who are the entities that take place in the consensus forming process for a network and how is their participation decided? We often call these entities validators but I think that’s unhelpful… their primary role is transaction ordering/confirmation, not validation… validation is the responsibility of a much larger group (‘full nodes’ in most architectures). Assuming this focus on “who decides if a transaction gets confirmed or not” is at the absolute heart of things then we can tease out some distinctions.
In a ‘permissioned’ chain such as Fabric or Corda, traditional consensus theory is applied. The participants in the network agree to utilise the services of some number of actors who will collaborate to confirm transactions. These actors could be assumed to be entirely trustworthy or BFT-style assumptions may be made that some proportion could be malicious. The key point is that the number of actors is known and the network participants go to lengths to ensure the actors are not sybils, etc. And, as a result, ‘traditional’ consensus research can be applied. This approach is not without its downsides (of course) but it has an important property of importance to business: once a transaction is marked as confirmed it will stay confirmed. And it is a fault of the system if this property does not hold.
The starting point for ‘permissionless’ blockchains, by contrast – and we can trace this all the way back to Bitcoin – is that agreeing on a known set of transaction confirmers makes it impossible to build censorship-resistant networks. Bluntly, if you know who the transaction confirmers are, then so do the authorities. And so they can be shut down or pressured to censor/delete transactions. So if you have a desire to build a solution where those in authority can not prevail on transaction confirmers to bend to their will, you need a design where the set of transaction confirmers is unknown – unknown in terms of who they are and how many there are, and where they can come and go at will. This means that the consensus algorithms developed over previous decades can’t be used and Satoshi’s genius was to devise a totally new way of solving the problem. However, the rules of mathematics and computer science didn’t change with the advent of Bitcoin. Instead, a requirement was softened. That requirement was finality. If we are willing to accept the probability that a transaction could sometimes go from “confirmed” to “unconfirmed” then a whole world of possibility opens up and techniques such as Proof of Work become possible. This was an amazing insight and most of us are probably in this space today because of it and its implications.
But… this probabilistic finality situation is annoying, of course. Like I said to John Wolpert of ConsenSys on a podcast a while back, if there was a permissionless system that truly gave me finality and over which I could reason about concentration/collusion risk, etc., I’d probably be a buyer of such a thing. But there isn’t and so I can’t. It’s as if we’re in this annoying situation where there’s something we’d all like to be true… but the universe is conspiring against us to make it just not so!
Now… assuming my (hopefully not over-simplistic) model is broadly OK then we can observe a few things.
First: notice how the permissionless approach to consensus says nothing about security. It is primarily about censorship-resistance. This is especially important to note because the last ten years have shown that, whilst it is possible to build consensus systems where the participants can come and go at will without permission, the economics are such that the relevant participants are usually relatively few in number…. possibly far fewer than would participate in a robust traditional BFT cluster! Note: this is not a comment about the security of any given client implementation (I fully agree that code such as geth has clearly been battle-tested). The security question is one about how many people you have to hack to take over the consensus forming process. If there are 21 unique participants in a Fabric BFT cluster and five miners with 80+% of the hashing power for a PoW blockchain, I would submit that it would be easier to subvert the latter chain than the former. (Note: you don’t need to hack the Fabric or Geth clients to take over confirmation processing for a network… you simply need to gain control of whichever systems are controlling the miners’ infrastructures… a Linux kernel vulnerability or somebody willing to kidnap the miners’ families might be all you need). So I’m unpersuaded by security arguments for or against a permissioned or permissionless approach in terms of compromises to transaction confirmation integrity. It ultimately all comes down to whether you need censorship resistance or not.
Secondly: experience has shown us that whilst we’d like to believe the probability of a transaction reversal on permissionless chains trends asymptotically to zero quickly, in reality there are occasional events far out in the tail that make analysis and engineering extremely difficult…. eg the Ethereum Classic 100+ block reorg a while back.
So the piece I’ve always struggled with – and which I hope this discussion can help open my eyes to is: if I don’t have the need for censorship-resistance in transaction confirmation for my business problem – or if it’s an anti-requirement for my problem, what’s the argument for why I would use a permissionless chain? It strikes me that there are lots of downsides and no obvious upsides.
That said, the discussions below seem mostly to be about bridging or integrating the permissionless and permissioned worlds, as opposed to enabling business-focused use-cases to be deployed directly onto a permissionless chain. But if the discussion is primarily only about integration/bridging that then makes me scratch my head even harder. If I look at Silas’s use-cases (thanks again btw… this is the first time I’ve seen them enumerated so clearly), I’ll disregard 1) and 3) for the purposes of this discussion since I’m only really qualified to talk about the business problems I see in my work, none of which involve usage of eth.
Which leaves me with: announcements and interchain-connectivity.
With respect to interchain-connectivity (proving A happened before B on different networks), isn’t that almost a perfect example of where a permissionless chain would be the wrong choice? The two independent transactions could be reordered in the event of a reorg and it would not be a fault… it would be the system working as designed. But if you sought to overcome this by making one transaction depend on the other to force an ordering then you already have your proof of ordering and so why do you need the blockchain?
With respect to announcements, is the idea here that the public chain is being used as a way to reassure yourself that there is no newer announcement from any given party… ie that you’re looking at the most current publication about a certain topic from somebody? If so, I agree that’s a highly desirable service to have as part of a solution design if one were available. But, again, isn’t it something that a permissionless chain is singularly bad at providing? If your threat model admits the possibility that the publisher would try to deceive you about the most currently published document, wouldn’t a platform that includes probabilistic finality and treats reorgs as a normal part of business be the perfect tool to let them perform their dastardly deeds? It would seem that the correct architectural solution would be something like a widely-witnessed proof-of-existence service, such as Guardtime’s offering that publishes merkle roots in a national newspaper.
Like I said near the start, I know my position as CTO of a firm with an open source permissioned blockchain means what I write can’t be seen as unbiased. So I’ve tried my hardest to write objectively and constructively and to avoid setting up strawmen (hence the laboured permissioned/permissionless section so you can ‘see my working’).
There has been so much noise and ‘people talking past each other’ at the boundary of permissioned and permissionless chains… and so, done right, this debate could be something we look back on as a milestone in really nailing some of these concepts.
Richard
Richard G Brown | R3. | Chief Technology Officer 2 London Wall Place | Floor 12 | London | EC2Y 5AU
From: <tsc@...> on behalf of "Silas Davis via Lists.Hyperledger.Org" <silas=monax.io@...>
> The most prominent item I see is Ethereum mainnet compatibility. Could someone articulate the value of that in specific terms? I am familiar with the notion of using mainnet as a receipt log. I would like to understand other benefits and use cases for permissioned networks to link with mainnet.
This quite a big topic, but I will give some examples I like.
First its worth noting for all of these use cases what is interesting is not just being able to 'do it on mainnet' -- anyone can send transactions to Ethereum from bash -- but rather having mainnet connectivity. The strongest for of this would be that a quorum (ideally any quorum) of your validators are jointly responsible for issuing transactions (via some kind of multisig on mainnet) and checking state on return (via multisig on sidechain). Lesser forms of connectivity might be via 'trusted' third parties or even a single service (i.e. an ethereum oracle). The effect could be the same, but in the weaker forms you have thrown away much of you byzantine tolerance. Ideally you want the same threshold for state changes on the sidechain as for state changes to the relevant contracts on mainnet. If all you require is a proof that a transaction was included (i.e. account X has placed a bond) rather than joint custody of an asset (i.e. paying out from the sidechain's reserve contract - where (super-)majority of validators must agree) then you can get away without quorum at the expense of liveness. To do this kind of strong connectivity it is helpful for validators on both sides (mainnet and sidechain) to be aware of each other. This is where Pantheon could help Burrow for instance - by pushing state back to us rather than us pulling - where a Burrow chain's validators would hold accounts on mainnet, and a validator pool from mainnet would hold accounts on the burrow sidechain. This isn't something we could get go-ethereum to do, but we might persuade Pantheon to provide this intermediate layer.
1. Bond-holding and value transfer. This probably the most obvious one. Since eth is worth something you can pay people in it. In particular you may want to run micro-transactions on your chain that are secured against a bond placed on ethereum. In order to guarantee the bond you need to be able to observe that a reserve of funds are locked on mainnet, you also need to be able to atomically swap them which is where you need connectivity. For proof-of-stake chains on Burrow you can ask entities wishing to validate to store bond on mainnet, credit them with validator power on Burrow, and if necessary in the case of validator unavailability or equivocation to slash part of their bond on mainnet. We would like all of these actions to be under control of a quorum of validators on the Burrow chain. We can fudge it now, but proper connectivity is what we would like to do it well.
2. Announcement and light clients I think your receipt log example would come under this bracket. The most interesting to me is announcing state hash, validator set hash, and seed location for a Burrow (or other) network. If I am a participant or validator wanting to join a Burrow network I would like to find out a recent snapshot of the validator set (their public keys) and also how I can connect to them. I could trust, say, Monax to tell me but I'd rather use Ethereum as a public system of announcement. If the validator set hash and state hash is updated in a timely fashion, as a light client I can use it to verify merkle proofs issued by a Burrow node without trusting that Burrow node so long as the history of the state root hash was updated by a quorum of validators periodically (and >1/3 of the set hasn't changed since the last update). This is great because I don't have to validator the entire Burrow network
3. Counter-factual instantiation This language comes from 'state channels'. If we consider a sidechain as a kind of state channel with its own consensus where some counterparties can more quickly transact than they can on mainnet then they can go about their business issuing signed incremental transactions that would also be valid on mainnet. This works for micro-payments but can be generalised to any state where you have a rule that says the highest sequence number is valid. If the participants on the sidechain have a dispute they can all submit their latest transactions and an ethereum contract can adjudicate. At worst a participant on the sidechain only loses out on state since the last checkpoint they were okay with (e.g. before the sidechain suffered a sybil attack).
4. Inter-chain connectivity Suppose I have two chains A and B, each chain has a total ordering of its own transactions. If I want to establish a partial ordering between just some transactions on A and B I can do that by instituting some form of meta-consensus on mainnet. This could just be a race if it is unimportant which transaction comes first or it could be some kind of conflict resolution. For example if my chain A is managing bills of lading for shipping and wants to issue an insurance agreement (b) on my agreements network B for a consignment (a). We can transact away on A building the bill of lading and follow a formation and signing process for the agreement on B before finally submitting an transaction on mainnet that defines the insurance agreement as executed _before_ the bill of lading is accepted. The transaction 'b then a' on mainnet is a kind of stronger guarantee that you were insured before you shipped (than say timestamps) - and it's also a public record of the fact. You then only pay the price of cross-chain consensus for transactions that need to depend on each other.
I don't share all of the fervour, and I'm not quite so bullish on Ethereum (though it does have that big advantage of being a thing right now...), but I think the following blog provides quite a nice frame for thinking about possible relationships between mainnet and permissioned networks:
Silas
On Wed, 21 Aug 2019 at 20:08, Middleton, Dan <dan.middleton@...> wrote:
|
|
|