Re: Hyperledger Besu Proposal is Live
Silas Davis
Okay this is interesting, thanks Richard. Firstly: > 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. I substantially agree with your premises so I'll only pick up one ones I would adjust or challenge. > 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! There is clearly an awkward level of centralisation in bitcoin mining pools, but I'm not aware of any good evidence on how concentrated that power is. Also in a permissionless system if centralisation becomes a problem it _is_ possible for more hashing power to come online - without any permission from existing validators unlike the permissioned case. > First: notice how the permissionless approach to consensus says nothing about security. It is primarily about censorship-resistance. Having the possibility of an unbounded validator set does say something about security - this is effectively related to being permissionless (and also requires asynchronicity with eventual agreement). > It is primarily about censorship-resistance. Censorship-resistance sounds rather more fringe than network neutrality -- which is also what it is -- which is a useful feature of a public network. Let's also put aside debates about the current levels of centralisation of PoW networks and assume we can use the laws of physics and economics to achieve some distribution of validator power with a permissionless chain that avoids collusion better than any authority-based chain. I'm not saying I know the optimal way to do this, but I don't find it unreasonable. If you have such a system then I believe you can make it more tamper resistant than any other chain. And if so it makes sense to start discovery of the world state from there. Thus the layer 1 to layer 2 idea. It's still only as good as the information stored there and by whom, but at least you can trust its the least likely system to have had its history rewritten. In principle. > 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? I don't think I was very clear here. I had two situations in mind. Firstly where you want an ordering between a and b but you _don't care_ what it is. Not proving a happened before b, but just establish an order by letting them race. The point is not that you prove one happened before the other, but for some reason it is important that the world agrees that there _is an ordering_ for those events. For example we may want to take the first 10 pairs of such events, they can be data-wise unrelated but it is important they have a canonical order across all sidechains. I'll admit that in some circumstances you would be able canonicalise base on convention, e.g. by sorting for example, but they still need to be shared somewhere. You may also have some reduction step (as in map-reduce) and that has to happen the same way for everyone. I posit a public chain is a good place for that. Secondly and I think more importantly, consider two transactions that initially do not depend on each other (they come from separate blockchains), but in some grander scheme _ought_ to depend on one another, and you want to establish that ordering (or more generally the combination/result of them). The decision on how they should depend on each other, or indeed how a set of initially independent transactions ought to depend on each other, is a service provide by mainnet (or perhaps just the 'next chain up'; let's call it the 'reducing chain'). This may involve some kind of resolution among a batch of transactions/state updates. I may shoot myself in the foot here, but let me try and expand the contrivance of my shipping/insurance example I gave previously. Suppose we have 3 separate networks - one concerned with chartering vessels, one concerned with insuring things, and once concerned with shipping goods. Suppose each works independently (<hand-wave>efficiency</hand-wave>) producing streams of: boats that are available of different capacities, packages of risk category/money allocations with which to insure things, and palettes of goods of different values and fragilities respectively. At least these are the resultant transactions they choose to escalate to the reducing chain (they presumably have lots of other supporting transactions in their own domains that they keep to themselves). On our reducing chain we have a smart contract concerned with a tripartite matching of boats, insurance, and goods. Presumably this contract would look a bit like a bid/offer system but with some potentially complicated rules. This would be an example of the reducing chain establishing an ordering and a matching via a resolution mechanism. What I'm describing is just a tree-shaped structure of chains or a hub-and-spoke model. It is not at all specific to permissionless chains (it's what Tendermint's Cosmos proposal entails for example). My argument is if we think this tree-shaped way of connecting chains makes sense, then trees terminate at a root, and that root is logically mainnet. As above, my premise ought to have been not that we have an existing data dependency, but we would like to establish one (if this naturally falls out of your problem, then yay we do not need to pay for consensus as you say). We may even not know which other dependencies are relevant (on mainnet) - we just fire our externally relevant transactions into coordination contracts on the reducing chain. > 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? I think systems with probabilistic finality do not treat reorgs as a normal part of business at all. I think they consider that a fork. If they are working as intended under the assumption of number byzantine actors, then after a sufficient number of blocks state can be considered final since probability of reversal goes off like a Poisson distribution. You may have to wait a while depending on block times. Just like you can effectively rely on uuids not colliding. If your hash function is broken that's a different question. I'm also not saying that current consensus networks aren't broken (as you allude to with centralisation), but if their assumptions are actually met then it should work. Being broken is not a normal state of affairs. > 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? Yes I agree, this is exactly the domain of synchronous or partially synchronous consensus. Though, for the purposes of announcing state root and validator hashes it is good enough that we know everyone will see the same value tagged with a particular height when they do eventually see it, and we don't really care about propagation time. If they are trying to verify these values for a height later than that they can see, they will just wait. I think this generalises to checking any state sidechain that is viewstamped by height. I happen to think this is a very powerful pattern. > as opposed to enabling business-focused use-cases to be deployed directly onto a permissionless chain. (sorry for mangling the order of your original statements here, but it suits me better :) ) Not everyone feels this way, but I certainly do. For the record I don't think anything very interesting happens on mainnet in this world view (which is why Ethereum as a 'world computer' doesn't chime with me at all), I think it is mostly a dumb system of record, largely consisting of opaque hash identifiers with some smart contracts doing a few things at the margins. Thanks for the opportunity to think about and discuss these things. I definitely don't have finality on most of these topics -- I'm not even that far down the asymptote -- so I appreciate the discussion. Silas
On Fri, 23 Aug 2019 at 12:12, Richard G Brown (R3) via Lists.Hyperledger.Org <richard=r3.com@...> wrote:
|
|