love it. when I think about chain splits (at least ones that happen over things like tokens being frozen), I think of value being diluted and destroyed and confusion created, while some value is recovered by the parties who needed the fix… but thinking about this type of feedback loop, it seems like, paradoxically, the more chain splits that happen, the lower that economic shock could be for each individual fork. if there were chain splits daily on miniscule issues and grievances, the community should get better and better at wrapping their head around their understanding of what chains to support and why, and what that consensus around a fork means. you can never stop forks from happening, but if more and more chain splits happen all the time, then the desires and preferences of the majority of users who support the dominant chain would be reinforced and apparent, and likely the economic shocks of each split should drive lower and lower over time.
reduce fork friction with governance on layer 2 driving changes on layer 0… why not?
Depending how forky you expect the world to become, we might need to revisit EIP 155 with a v parameter of more than one byte, to ensure easier replay attack protection in a world with more than 114 ethereum forked chains.
We might also want to include a new_fork_network_id as parameter in its [EIP 867] fork proposal file.
You would want to ensure the new proposed ID was globally unique, ideally ensuring that no two forks produce the same network_id.
Any random oracle could be used, or maybe just hash( hash(proposal) + previous_block_hash)? Maybe Cosmos over to Dfinity for some random data?
I’ve added a couple governance algorithm proposals to the Strange Loop repo. Posting one at a time for easy threading:
Soft Flow
A signaling strategy for the Strange Loop hard fork framework.
Signals can take many forms, from soft, off-chain signaling like social media, to more hard commitments, like burning assets in a way that they will only be usable on a resulting chain.
Users can publish the conditions under which they would fork. This could take the form of any smart contract, as implied by the Strange Loop supportsProposal method.
The implementation of this method can have policies like “all of us or none of us”, with a list of required other accounts that should signal a similar support.
The algorithm might go like this:
The WouldSupportIf procedure:
If the account has explicitly expressed they would or would not, return that result.
Define set D, the set of accounts that the current account that requires wouldSupportIf.
Define set W, as the subset of D that either:
Would support the fork.
WouldSupportIf the caller supported the fork.
Returns true for its own wouldSupportIf procedure.
A coordination strategy for the Strange Loop hard fork framework.
An extension of Soft flow that includes on-chain enforcement.
Beyond signaling, hard economic commitments could allow accounts to unambiguously define their commitment to a particular fork.
This could be implemented by encoding wouldSupportIf logic in a smart contract that controls some collateral or asset. This asset could be a small deposit, or it could be a commitment for a contract to self destruct on one side of a fork.
For other accounts implementing wouldSupportIf flows that depend on this hard-signaling account, the account may weigh this commitment more heavily than a normal true from wouldSupportIf, since this dependency is now more grave.
This would require a revised version of the wouldSupportIf method that defines the different weight the account would give a dependency if it hard-commits in different ways to that fork proposal. Since there are different ways to hard-commit, this could be a bit complicated to implement, and would benefit from some standardization.
V can already be more than one byte. Personally, I’m a fan of changing the network id on every hard fork, no matter how uncontentious, but that’s not something we’ve historically done.
Very interesting stuff Dan - a far better read than the 999 thread
One simple question about this example (I know it is contrived and you provide some clearer and better ones in subsequent comments) but if this is one of the defaults, and a lot of people choose to use logic like this, would it not result in endless stalls?
I like the idea of user-defined liquid delegation of trust and think that the potential definitions you give there for stake holders that are required to take action likely hints at an answer
if this is one of the defaults, and a lot of people choose to use logic like this, would it not result in endless stalls?
Maybe! I’m deliberately not prescribing exact governance models here. If everyone has very high consensus thresholds set for hard forking, it’s entirely possible forks never happen, and if so, that’s a very conservative community.
But like you said, this already hints at how a pro-fork community might move forward: Either by getting key stake-holders on board, or by conceding that they are a fragment of the community to whatever extent.
My personal theory is that even with high consensus thresholds, if a dependency graph were drawn, we’d see the community right now is favorable to performance improvements, and recovery forks are contentious for a variety of reasons that could be overcome with better signaling:
Fear of forking without full community buy-in.
Fear of forking and being liable for the recovery (fear of future coersion).
Fear of centralized power making these decisions.
If people just spread their dependency graph widely, they could be very picky about what recovery forks they would ever support, and yet still potentially find cases that are supported widely enough that they happen could endorse without falling into any of these traps.
Hmm…
unknown groups of unknown actors (even not sybil protected) are voting on protocol changes.
Votes of that different voters and voter groups are summarized somehow and change will be enforced.
The groups and their constituent actors and processes could easily be knowable to the users, and registered on the blockchain. They can even be confirmed in person. That is about as known as it gets on the internet.
I would say that these groups are not as much voting on a change as they are signaling which protocol attributes they conclude fit the needs or outlook of their subscribers.
The summarized somehow isn’t as arbitrary as it may seem. It can be quite clear to the user what is happening in the groups they subscribe to.
(removed an allegory that was not relevant to my points)
First of all: The Strange Loop framework does not require any particular governance pattern, so neither voting nor anonymity nor any assumption actually applies to it. Any governance process could be opted in to by the user of a blockchain using this tool.
I think you’re critiquing what I called “Soft Flow”, a signaling governance system for Strange Loop. In response to your concerns:
It’s sybil resistant because each person would choose what other accounts they want to coordinate with.
It’s not actually “enforced” in any blockchain-wide sense, only on the individual user level.
It can be quite clear to the user what is happening in the groups they subscribe to.
I would like to see/accept this proposal exact as it was titled: a framework.
A framework that is still to be implemented into ready-to-use product, when exact all this can be’s must be provably implemented. Even a framework becomes accepted, an particular implementation must be validated later once more. No implementation of the framework should be accepted automatically just because the underlying framework was accepted.
and once more: any automatically enforcement after some boolean function mapping votes into boolean is dangerous, because it pretend to be safe and trustless, but can be easily forked out. We use word “governance”, but it is a signalling, indeed.
I totally agree, there’s a road map that needs to be executed for this to work. If I had to guess, here’s how it might unfold:
A client team with incentive to encourage a hard fork might implement “accepting on-chain hard fork proposals with client parameters” as a way to make it easier to develop the hard fork, in a community-focused way that gives users the power of choosing future forks in general, not merely supporting their own interests.
Once one client has implemented this, they should advertise their client as the client that gives the user the most control over the fork policy that their client uses, in hopes to either steal users to that client, or pressure other client developers to relinquish their own privileged decision making position by implementing support for the same.
There will probably be a friction period, either where some client devs don’t want to support this feature (either out of conviction or seeing it as a waste of time, since they may not want or need any hard forks), and so it might come down to people who have the most at stake (for example, people hoping for a funds recovery) to fund the development of this general feature for all clients.
If core client developers aren’t interested in supporting user-chosen hard fork policies, and refuse to review/merge these PRs, that might be a good reason to fork those clients, with hopes to merge after the changed version is proven stable.
IMO, any client not favorable to a user configured fork choice rule is entrenching their own power, and informed users should flock away from those clients as other alternatives emerge.
@danfinlay,
working on EIP categorisation, I found myself mentally in a structure similar to “Strange Loop”.
Are you going to Prague to EthM Gathering? Would be great to discuss more details.
Would be great to chat about this at DevCon @danfinlay. This seems to be highly applicable in a very general sense to governance research we’ve been working on at Facebook and I’d love to share vision. Thank you for putting this together, hope to meet you soon.
!