Title: Protecting_the_EIP_process_from_special_interests_
Category: Magicians

Author: defectivealtruist
Date: 2021-06-24T22:56:04.385Z

Motivation
Can we better protect the EIP process from special interests while improving the incentives for those working for the public good?
The purpose of this post is to get the ball rolling on a discussion we hope will eventually result in the equivalent of a meta EIP that  structurally improves the EIP process.

The problem: high reward for colluders, low reward for honest people
Without improvements to the current EIP process there is a danger that protocol lobbyists getting paid to serve special interests will outnumber unpaid altruistic volunteers serving the public good, leading to a tragedy of the commons.
We believe this is already a problem and that it is getting worse. We’ll start by providing some general examples, and examine in more detail a recent EIP as a case study.
We can break the problem of perverse incentives down into two related sub-problems:


High reward for getting bad EIPs in: special interests have a high incentive to lobby governance for changes that benefit them, even at the expense of the public good or other stakeholders. This can be a high stakes adversarial game, where success depends on obfuscation, collusion and misdirection. Successful protocol lobbyists could be highly motivated and well coordinated.

Low reward for promoting the public good: either by protecting from bad EIPs or by doing all the work to get good EIPs in. Both require significant talent, time and energy.  Only some of this work is intrinsically rewarding. The current process relies heavily on altruism and prestige, and it is unclear whether this will scale in proportion to the scaling rewards for successfully attacking the process.

The imbalance is a natural consequence of public choice theory (see David Friedman’s excellent original writings on the subject). The core idea is that concentrated special interests win out over diffuse public interests, sometimes even when the diffuse public interest is larger in absolute terms. A somewhat naive calculation for illustration:

$100 million gain divided by 100 colluders = $1M gain per colluder
$1 billion loss distributed across 100,000,000 million public victims= $10 loss per victim

Coordinating the defense is hard because it’s a large group, and each individual member of the group internalizes only a very small portion of the benefits of a successful defense. Special interests, on the other hand, are a concentrated interest, which each participant expecting to see a large portion of the gains from getting their proposals implemented. Hence, the attackers will be highly motivated, while the defenders suffer from a tragedy of the commons.

Testimonial: what it’s like now for honest people
"To prevent a bad proposal that someone is really motivated to push in, I have to write posts, prove my point beyond doubt, talk to people to make sure the issues get enough exposure, and I’ll probably need to stay on it, defend my research on the ACD, etc.  And I have no real incentive to do this, other than defending the ecosystem I care about.  The people on the other side are strongly motivated. They are paid to fight for their EIP, and have a lot to gain from it. How many EIPs will pass because no one is willing to put the resources to shoot them down, while the proposer is motivated to push it through?
And the same goes in the other direction. I’m often reluctant to propose EIPs that I think are good for everyone because I’m afraid  the process of pushing it past the objections at ACDs and getting it accepted would exhaust me.
And so EIPs that don’t personally benefit someone are less likely to be accepted, while EIPs proposed by companies that stand to gain are more likely."

General examples of EIPs that may benefit special interests in subtle ways
Sunlight is a good disinfectant, but whether it’s enough depends on how deeply it penetrates.
The more attention and domain expertise is required to understand how value or risk is transferred, the less resistance can be expected, and the easier it will be to get the critical mass of community sentiment required to persuade the core devs to include a change.
A blatant EIP that says “give X ETH per block to our cabal” will quickly get rejected (and, indeed, even EIP-2025, a not-obviously-malicious proposal of that type was quickly thrown out). But there are far more subtle protocol changes that can benefit some constituencies at the expense of others.
Some examples include:


Precompiles


Concentrated interest in favor: specific use case that wants a precompile

Diffuse interest against: large increase in consensus complexity, dependence on external libraries, development time delaying high-priority items (e.g., the merge)



Coin rescues or other state-intervention forks


Concentrated interest in favor: single group that wants their coins saved

Diffuse interest against: risk of chaotic split, precedent, long-term higher governance burden and controversial-fork risk due to emboldened future requests



Highly specialized in-EVM/state data structures (e.g., sorted storage slots, heaps)


Concentrated interest in favor: specific use cases (e.g., on-chain order books) that benefit from these structures

Diffuse interest against: greater consensus complexity, lower flexibility to make future changes (e.g., sorted storage slots would have prevented Vitalik’s recent Verkle tree proposal)



This is not to say that all proposals of the above categories are bad; sometimes a more concentrated gain really is on the whole greater than the widely distributed cost of a proposal. But as a general rule, we should expect the concentrated pro- side to be systematically over-represented, and the diffuse anti- side to be systematically under-represented.
The open and inclusive nature of the EIP process is currently our main defense against bad proposals. However, given that proposals may be complex and subtle in their effects it may be unsafe to rely on proposals being self evidently good or bad. An open process where everyone has access to various public forums may not in practice provide sufficient protection to balance out the perverse incentives.

Starting to explore the solution space
We’re going to try and start the conversation by proposing some principles and ideas. This list will be incomplete as the intention is to get the ball rolling, not say the final word.
We believe it’s important to recognize that making bad things harder has to be balanced with making good things easier so that we don’t end up throwing out the baby with the bathwater. We wouldn’t want to “protect” the EIP process by shutting it down.

Principles of defense we can learn from the city of Troy
Let’s use the famous trojan horse that brought down the ancient city of Troy as a metaphor.
Thanks to the open nature of the process, everyone who is paying attention can see what is trying to get through our metaphorical gates. This means an attack has to sneak past the public’s guardians in plain sight.
How do we raise the bar and make it harder to disguise attacks (e.g., the infiltrating force that opens the gates to the city) as “gifts” (e.g., a beautiful statue of a horse to decorate our city)?
For example, this may involve a combination of improvements to our processes that help us:


Better understand who is offering us gifts and what is their motivation. Who are they working for? What’s their track record? Are they friend or foe? How aligned are they with our values? Do they have conflicts of interests?

Make sure we have enough highly trained guards that are well paid and stay alert. Volunteers are great, but there’s only so much glory to be had and standing guard gets old fast.
Make it harder for attackers to lull us to sleep by hijacking our trusted institutions.
Make sure our guards can sound the alarm and draw attention to an attack that might overwhelm them. We can’t defend ourselves against attacks we don’t realize are happening.

Investigate close calls so we can iterate intelligently on our defense mechanisms while carefully balancing trade offs and avoiding knee-jerk overreactions.

Keep score to increase public awareness of who is doing a good job helping us, and who has been trying to harm us. Since our attention and resources will always be limited, we should allocate it intelligently. Leveraging reputation could be part of the solution.

Reward and honor what we want more of - benefactors and guardians of the public good, while penalizing and shaming what we want less of, those who attack us in the service of special interest.


Example ideas for making lobbying for bad proposals harder

Open bounties to incentivize permission-less research
“Given enough eyeballs, all bugs are shallow” - Linus’s law
The last line of defense before including any EIP in a network upgrade could be an open bug bounty that will pay anyone who discovers significant flaws that blocks the EIP’s inclusion as is. The reward should be at least enough to pay for an independent audit at current market rates. It should be open for long enough to give independent researchers time to find flaws.
The benefit of a bounty as a supplement to a contracted audit is that it is minimally opinionated regarding who will succeed. It’s not who you know, it’s what you know. Anyone with skill can try to claim a bounty and get compensated for success with economic and reputational rewards.
The bounty process should not only reward finding flaws in existing proposals but also alternative proposals that achieve similar benefits with a better risk/reward profile.

Post-mortem on failures and close calls
“Fool me once, shame on you. Fool me twice, shame on me”
When a bad proposal almost gets in, maximize the learning from that by funding a bounty that rewards the  best understanding of what process improvements would have maximized our margin of safety against bad proposals while minimizing the friction for good proposals.

Fund “meta audits” that watch the watchers
Reward those who watch the watchers and help the community hold auditors accountable.
One way to do this would be to post open bounties for the best “audits of auditors”. These would reward those that take a close look at what past audits missed and help the community reassess how much to trust their brands.
Consider using these “meta audits” to update a public hall of fame & shame that makes it easier to notice when auditors miss critical issues. The effect should be that when a critical issue is missed the community can reduce the “credit score” of that auditor.
Auditors have skin in the game to the degree that they are held accountable for endorsing bad proposals (e.g., explicitly or implicitly). For an efficient auditing market to form around Ethereum the reputation of auditors and the amount of business they get should be based on their performance.
Pushing auditors with low standards out creates a market opportunity for auditors with higher standards.
Achieving this is a public good and will help improve an industry otherwise prone to market failures, though it’s worth thinking carefully about how to do this to avoid introducing perverse incentives that adversely affect e.g. what EIPs auditors are willing to audit.

More transparency
“Sunlight is the best disinfectant”


Require disclosing conflicts of interests: all proposers and their supporters must disclose conflicts between their private interests and the interests of the public, or the interests of other stakeholders in the ecosystem.

Require disclosing motivation: all proposers and their supporters must disclose their motivation for participating. This means what they stand to gain if the proposal is accepted.

Require disclosing means: all proposers and their supporters should disclose who they are working for.

Whistleblowing: encourage people to provide evidence in those cases where important information is being withheld.

Accountability tracking: if evidence establishes beyond reasonable doubt (e.g., thanks to a whistleblower) that proposers and their supporters withheld information on their motivation, means or conflicts of interests, their reputation should suffer and their ability to influence the EIP process should be diminished. Similarly, exceptional positive contributors should see their reputation benefit. Some form of public tracking (e.g., badges) can be used to formalize this.


Transparency and accountability for Ethereum Foundation signalling


Make signalling explicit: In order to prevent the hijacking of the EF’s brand, the EF should publicly disclose its intention in funding work related to an EIP.
For example, it should be clear whether an EF employee authorized funding an audit in support of what they believe to be a good EIP proposal or out of concern that it may be flawed in a way they can’t put their finger on.
This will be more clear if the EF explicitly signals the former when it has the intention to support something, and the latter when it does not.


Increase personal skin in game by disentangling organizational and personal reputations: the EF is not a hive mind like “The Borg”. It is a collection of individuals with varying degrees of domain expertise. The domain experts the EF relies on to authorize signalling on the EF’s behalf should have skin in the game. The community should be able to see their faces. Their personal reputation should increase by supporting good things, and diminish from supporting bad things.



Example ideas for making more good things happen
In addition to making it more difficult for EIPs promoted by special interests to pass through unchallenged, it is also important to make it easier for truly important EIPs to make it through, even if they don’t have any special interest constituencies supporting them (e.g., EIP-2929 gas price changes) to improve anti-DoS safety that were talked about for over a year without progress before they started to be implemented).

Retroactive grants for EIPs
How much more top talent could we attract to serve the public good if it was at least (or more) economically rewarding to work on that than in the service of special intersts?
Retroactive grant models make it possible for those interested in allocating resources to the public good to solve the easier problem of evaluating impacts post-hoc instead of the harder problem of anticipating future impacts.
There’s more than one way to do this but here’s a simple approach. Each EIP could designate a proposer that will be responsible for getting the EIP all the way through to a network upgrade and distributing any retroactive grant amongst collaborators afterwards. The proposer would also track which individuals and teams made the most important contributions to that EIP, and make an allocation table representing what they consider to be a fair distribution of rewards.
Any tips (from the public, or the EF, or other grantees, or potentially revenue from selling an NFT of the EIP) would be split among the contributors according to the allocation table. If desired, the allocation table could even be tokenized, allowing an independent team to raise funds to pay for fiat or ETH-denominated expenses if they can convince the market that their EIP will succeed and be deemed valuable.

EIP 3074 as a case study
We expect this to be the most controversial part of this post, but we feel it is instructive to examine a live specimen of protocol lobbying currently in progress in the service of a powerful and highly motivated special interest - Consensys. We are watching the situation unfold with growing concern, but have so far avoided getting directly involved in this discussion on the public forums under any name.

On the precipice
Consensys’s proposal was deceptively simple and was purported to solve the important problem of gas abstraction, by creating a new type of transaction that delegates control over an EOA to a contract. This appears more powerful and dangerous than what is needed for gas abstraction. Why do it this way? From EIP 3074:
“A good analogy for the benefit this EIP provides is that it’s similar to allowing any EOA to become a smart contract wallet without deploying a contract.”
This is both insightful and potentially misleading. As Vitalik points out, rather than accomplishing account abstraction, EIP 3074 enshrines EOAs instead of helping us get beyond them.
It now seems dangerously close to getting into the next network upgrade, despite:

Critical security issues that were not discovered by two EF-commissioned audits
Being designed to benefit Consensys’s proprietary Metamask wallet at the expense of open source smart contract wallets
Centralization risks


The security flaws that almost went undiscovered
Up until a last minute intervention by the unpaid volunteer who posted “A simpler alternative to EIP 3074” on this forum, the process not only failed to catch the security problems but also failed to come up with alternatives that had potentially better risk/reward profiles and could get the purported upsides with fewer downsides.

The candid discussion that didn’t happen
At no point in the process did we have a public discussion on why promoting EIP 3074 was in Consensys’s strategic interests, or how it risked benefiting Consensys at the expense of other stakeholders like Gnosis and Argent.
We also didn’t discuss whether it was interests of the Ethereum community to tilt the playing field in Metamask’s favor, especially given that after establishing high market share they rug pulled on open source licensing, a core Ethereum value.

How did we get so close to EIP 3074 being seriously considered for inclusion in the next network upgrade?
Consensys made all the right moves. The proposal is deceptively simple on its surface. They made it easy for the core devs by implementing the client change. They lobbied for it behind the scenes, starting with their natural allies and gradually networking out to expand their circle of support.
Consensys also cleverly lobbied to position their proposal as something that EF was supporting. Consensys could have easily funded the audits by themselves, but they probably realized it would legitimize the proposal more if they could get the EF to participate, and thus leverage the EF’s trusted brand.
In various internal community calls promoting this proposal the impression conveyed was that it was endorsed by the EF and was practically a done deal. Who wants to criticize a proposal backed with the prestige of the EF?
A piece of the puzzle that is still missing is what role Consensys played in selecting the auditors, given that Least Authority ended up endorsing EIP 3074 after missing critical issues. From their report:
“We conclude that under the right conditions - wallets and invokers being implemented correctly - that this proposal is safe for use”
Promoting a false sense of security can have negative value.

How could things have played out differently?
Imagine that a year ago we had this discussion on protecting the EIP process from special interests and improved the EIP process with some of the ideas presented in this post. How could things have played out differently?

We wouldn’t rely on unpaid volunteers to catch critical security issues
If we had been routinely auditing the auditors by comparing their audit reports to what was later discovered we may have noticed Least Authority’s poor track record  and adjusted their reputation appropriately.
Ideally, the pain of visibly losing reputation in our metaphorical hall of shame would incentivize Least Authority to be more diligent with their audits. They might catch more critical issues, or at least be more cautious in providing endorsements that could come back to haunt them.
With bug bounties as the last line of defense, the situation would tend to be more self correcting as critical issues that auditors miss would be an opportunity for new auditors to make a name for themselves.
Auditors that keep missing critical issues would cease to command a premium as a source of trust and may have to switch to a different business model such as competing for bug bounties that only pay out on success.

Consensys wouldn’t have been able to hijack the EF brand


Explicit signalling: most likely EF would have clarified that it was funding the audits out of concern rather than with the intention of signalling support.


Accountable domain experts: if Consensys tried pursuading a domain expert at the EF to explicitly signal support for EIP 3074, that person would have to consider whether they were confident enough to stake their personal reputation on doing that.



Understanding motivation
First, we would have started by encouraging a candid discussion about Consensys’s motivations in promoting EIP 3074 so aggressively.
If the proposers didn’t provide full disclosure regarding their ties to Consensys we might regard them personally with suspicion. If they were honest about their affiliations but were simply not in a position to disclose Consensys’s strategic interests due to an honest lack of insight we could regard not them but their employer with suspicion and invite community members to try and fill in the gaps.
We could invite speculation on Consensys’s business interests and the goals of senior management while still believing that most of the technical people working for Consensys are good and well intentioned community members.

Better late than never
As an exercise, let’s try to take a stab at understanding Consensys’s motivation. Suppose the future belongs to smart contract wallets and we expect EOAs to be gradually phased in favor of account abstraction. This is not good for Metamask, the dominant EOA wallet owned by Consensys.

Why exactly is EIP 3074 so important to Consensys?
EIP 3074 is strategic for Consensys because it changes the rules of the games to make it possible for the proprietary Metamask wallet to leverage its position as a dominant EOA wallet to compete and possibly displace trusted open source smart contract solutions like Gnosis and Argent.
This would potentially further centralize Ethereum around Metamask.

Understanding Metamask’s strategic positioning with/without EIP 3074
How does EIP 3074 transform the red ocean of smart contract wallets into a blue ocean for Metamask?
Without EIP 3074, if Metamask wants to compete in the smart contract wallet space it has to develop a new smart contract wallet offering and then try to convince users to choose that over other more mature smart contract solutions that have empirically stood the test of time and have billions in assets under management. That’s a hard sell.
With EIP 3074, Metamask can seamlessly convert their userbase in place to a new kind of smart contract wallet (they coined “Synthetic EOA”) by having users sign a special type of transaction that delegates control to an all capable invoker contract. They control the UX, so it should be not be hard for them to do that.

One contract to rule them all
An EIP 3074 invoker contract will be as extremely security sensitive as any smart wallet contract. Assuming Consensys don’t make a catastrophic mistake, their invoker contract could gain enough Assets Under Management to provide empirical validation that it is trustworthy.
Given the sensitivity of this contract, users that are using Metamask’s invoker will be reluctant to switch to other invokers. Metamask can leverage their trusted invoker to provide their users with similar benefits to smart contract wallets without the pain or risk of migration. This way Metamask gets to lock-in users that would have eventually “graduated” to open source smart contract wallets.
To the degree that competition in the market resembles a winner take all tournament competition will be limited and we could end up centralizing Ethereum around a proprietary wallet with a natural de-facto monopoly.
From EIP 3074:
“Choosing an invoker is similar to choosing a smart contract wallet implementation. It’s important to choose one that has been thoroughly reviewed, tested, and accepted by the community as secure. We expect a few invoker designs to be utilized by most major transaction relay providers, with a few outliers that offer more novel mechanisms.”

The process that Consensys is exploiting is more of a problem than Consensys
Amongst our friends are technical people at Consensys that we like and respect. The above case study is not meant to attack anyone involved in EIP3074 personally. Good people can be misguided. They are not the problem.
Consensys itself is also not the problem. It’s a rational corporate actor trying to maximize its special interests. In that sense it is not fully aligned with Ethereum’s values, but it is not unique in this regard.
The problem is if we don’t do a better job protecting the EIP process from the special interests, EIP3074 will not be the last bad proposal that is on the verge of getting in. If our defenses don’t hold, successful attacks would embolden future attacks. In the worst case scenario, this could incentivize the creation of a well funded lobbying industry that gradually captures the EIP process.

Author: timbeiko
Date: 2021-06-25T01:52:24.731Z

@defectivealtruist thanks for your post! Lots to unpack. I’ll share some thoughts below.



 defectivealtruist:

Precompiles


I think we’ve moved to rejecting more and more precompiles based on the “diffuse interests against”, see EIP-2537 as a recent example, along with the desire to potentially do EVM384 instead. This seems to me like a clear case where there were several private interests pushing for precompiles, but it did not lead to inclusion.



 defectivealtruist:

Coin rescues or other state-intervention forks


The only occurrence of this is TheDAO fork, which I have no desire in re-hashing, but needless to say a large enough % of the community’s funds were involved that the line between private and public interests was blurred, and those who disagreed with this particular intervention got the opportunity to “exit” to ETC.



 defectivealtruist:

Highly specialized in-EVM/state data structures (e.g., sorted storage slots, heaps)


Are there any examples of EIPs for this you can share?



 defectivealtruist:

The last line of defense before including any EIP in a network upgrade could be an open bug bounty that will pay anyone who discovers significant flaws that blocks the EIP’s inclusion as is.


This already exists: https://bounty.ethereum.org/ In the past, we’ve doubled it when mainnet upgrades were happening, too. It does not fit all your criteria, but is at least a start.



 defectivealtruist:

The bounty process should not only reward finding flaws in existing proposals but also alternative proposals that achieve similar benefits with a better risk/reward profile.


This is interesting! I think the tradeoff here is that we risk grinding the process to a halt because some EIPs, especially more complex ones, will never be perfect. For example, we already tabled a few tweaks to EIP-1559 for a “v2” someday in order to ship what had been implemented/tested/audited. Not saying I’m against the idea, but we need to weigh the pros/cons.



 defectivealtruist:

When a bad proposal almost gets in, maximize the learning from that by funding a bounty that rewards the best understanding of what process improvements would have maximized our margin of safety against bad proposals while minimizing the friction for good proposals.


Agreed we should do this, and I think we’ve somehow gotten worse at them. We’ve done a few in the past, but I agree we should do more, have them be of higher quality, and publicize them more broadly. Relying on volunteers/already overworked people is probably the main blocking factor here, and likely one that can be addressed.



 defectivealtruist:

Fund “meta audits” that watch the watchers


I’m concerned this has more cons than pros. The first is that if our audits currently rely on volunteers or “altruistic” participants, putting a target on their back is likely to make them less eager to participate. IMO we need to move towards having consistent high quality audits set up before trying to go for “meta audits”.



 defectivealtruist:

Require disclosing conflicts of interests


Questions: where do you think this should be done? Some people have done it on AllCoreDevs, for example, but it doesn’t get written in the EIP. Also worth noting that the EIP process is currently open to anonymous submitters, so it may not always be possible. It is worth noting the tradeoff there.
Also curious what you think is the “bar” for conflict?



 defectivealtruist:

Require disclosing motivation


I think this tends to happen naturally, but people can still conceal bits of it. (1) and (3) probably cover what doesn’t get disclosed.



 defectivealtruist:

Require disclosing means


I can see some people not being comfortable doing that, but in general this already happens. For example, the BLAKE2b precompile was clearly stated as being pushed by people who wanted better interoperability with ZCash (even though it ultimately didn’t accomplish that…!).



 defectivealtruist:


Whistleblowing: encourage people to provide evidence in those cases where important information is being withheld.



Strongly against this. When it is important enough, it happens naturally. The EIP process is already quite taxing to participate in, and having people feel like they have a target on their back throughout will likely prevent people from contributing.



 defectivealtruist:

Transparency and accountability for Ethereum Foundation signalling


This is a big can of worms which in practice doesn’t seem like the core problem to me (in the spirit of your post: I am a contractor with the EF). Open to change the process based on the community’s requests, but that’s the extent of my comments.



 defectivealtruist:

Retroactive grants for EIPs


Strongly agree with this! I am working on something like this at the moment and, interestingly enough, the biggest pushback I’ve gotten is that it can lead to more capture of the EIP process, or at least the perception of “special interests funding changes”. I still think on net it is a good thing, but it is worth mentioning that this can easily go “against” a lot of the principles that you list.



 defectivealtruist:

EIP 3074 as a case study


(Disclosure: ex-ConsenSys employee) One meta-error in your analysis here is overestimating the amount of coordination within ConsenSys (specifically the two different orgs which the 3074 champions and MetaMask belong to). Won’t dwell on it because it could very well be that individuals are closely coordinated and future orgs may be more aligned, but worth mentioning.



 defectivealtruist:

It now seems dangerously close to getting into the next network upgrade, despite:


This is false. It has been discussed as potentially being included, but there were never formal conversations about inclusion.



 defectivealtruist:


Critical security issues that were not discovered by two EF-commissioned audits



I think we have a pretty good track record of taking EIPs out if there are security concerns, even if they are brought up late in the process. See Istanbul/St-Peterburg for example, or more recently EIP-2537 being removed from Berlin.



 defectivealtruist:

EIP 3074 was in Consensys’s strategic interests, or how it risked benefiting Consensys at the expense of other stakeholders like Gnosis and Argent.


This is a bit harder. That “scope” of discussion is not really a part of the EIP process. Perhaps we could include it more explicitly, and obviously Gnosis or Argent would be free to share their thoughts about the EIP in the current process. There is just not really a concept of “strategic analysis” for EIPs.



 defectivealtruist:

The problem is if we don’t do a better job protecting the EIP process from the special interests, EIP3074 will not be the last bad proposal that is on the verge of getting in. If our defenses don’t hold, successful attacks would embolden future attacks. In the worst case scenario, this could incentivize the creation of a well funded lobbying industry that gradually captures the EIP process.


I agree that this is likely to get worse, but one counterbalancing force I see is that as the community grows, getting consensus on any change becomes harder, which naturally leads to protocol ossification. There are several proposals that could have been possible 4-5 years ago that likely are not today, and I suspect the same will be true in the future. I think this is a feature and not a bug.
Again, thank you for sharing all of this. I’d be happy to support and help anyone who wants to propose specific changes to the process and get them adopted. If you want to do this, I would encourage you to also review past changes to the EIP process and their success or failure. My #1 bit of advice would be to try and do things iteratively vs. proposing a “complete overhaul”. If you can find the 1-2 things you think will be most impactful, it is easier to get buy in for those, see them work, and add 1-2 more, vs. trying to do 3-5 changes at once.

Author: CryptoBlockchainTech
Date: 2021-06-25T03:49:33.403Z

I agree 1000% with moving away from a system that is easily exploited by the few and powerful as this was needed a long time ago to prevent the proliferation of ASICs on the network and preventing Consensys from installing their own people into the 1559 implementation process to ensure smooth implementation…ahem, ex Consensys employees.
Good luck to you but moving to POS will be 100x more difficult to stop special interests from corrupting the process as this is the very nature of POS. POS ensures those with the most skin in the game have the loudest voices, which if you look at who some of the the biggest stakers are…exchanges.
It is only going to get more difficult going forward to ensure Ethereum remains a truly decentralized entity. This is a much needed start to a problem that has been around for a long time and is only now coming to the forefront where it is easier to see.

Author: vbuterin
Date: 2021-07-03T15:47:23.122Z

timbeiko:




 defectivealtruist:

Highly specialized in-EVM/state data structures (e.g., sorted storage slots, heaps)


Are there any examples of EIPs for this you can share?


I think the OP’s intent was to list classes of potential “good for concentrated interest, bad for public interest” ideas in general, including things that haven’t been proposed yet but might conceivably be in the future. That said, from the early days of Ethereum I do remember multiple instances of things in that category being proposed. Particuarly:

There were discussions in 2014 about adding “next empty storage slot” and “prev empty storage slot” opcodes, which would have allowed Ethereum contracts to maintain and operate over sorted data structures without the tree-on-top-of-a-tree hacks that are required today. The idea was eventually scrapped because developers intuitively realized that something with the interface of a hashmap can be implemented far more easily than something with the interface of a search tree.
Early on we were considering looking into adding priority queue data structures to the EVM so we could efficiently implement on-chain order books (Bitshares had on-chain order books and there was a desire to have an equivalent), but this was scrapped due to complexity
Proposals for enshrined ERC20 tokens (this was shot down quickly, because of the “if you can do it without enshrined protocol features, you should do it without enshrined protocol features” principle)

None of this made it to EIP stage, because it was the 2014-15 era and the community was small enough to keep track of proposals informally. But it is a good example of things that were successfully averted by a pro-simplicity/minimalism norm!

Author: SamWilsn
Date: 2021-07-03T22:46:03.625Z

We’ve held two community calls (though I can only find the recording for one at the moment) to discuss with groups outside of ConsenSys, and the feedback has generally been positive. I’d hardly call them “internal.” Maybe it’s time to hold a third?
This is perhaps off-the-main-topic of this post, but I’d be really interested in discussing (and possibly co-authoring a post on) the specifics of centralization risks and how EIP-3074 benefits ConsenSys/MetaMask over other wallets. My Telegram & Discord handles are the same as this account here, or we can figure out some other method of communication if need be!

Author: pedrouid
Date: 2021-07-04T15:23:42.954Z

As author of WalletConnect protocol, one of the alternative wallet providers to Metamask, I could not be happier to see EIP-3074 being included in the next hard fork
Sponsored Transactions are going to completely change wallet UX for Ethereum positively in so many ways.
I can’t wrap my head around how the OP found this EIP to put Metamask in advantage over any other wallet.
Meta-transactions have been researched and developed for years and even current Smart Contract Wallets would benefit from EIP-3074.
I’m not interested in who sponsored or funded the research and development of EIP-3074. The spec speaks for itself and it will be IMO the most impactful EIP to mainstream adoption

Author: cmagan
Date: 2021-07-08T12:19:49.030Z

Isn’t it all about the subjective definition of “good” and “bad” EIPs?
I think it is generally positive that there are many stakeholders each with his own self interests.
Sometimes, someone can try to promote an EIP that benefits himself more that it benefits others (or even hurts others).
Then it is the responsibility of others to point it out - but they might be many “little guys” that don’t understand or have enough economic interest in the matter.
So my takeaway is that transparency and accessibility are the most important and hard to corrupt mechanisms that might help more people to get involved and keep the process aligned with their interests.
How should we make reliable and transparent information about EIPs as available and accessible to many people?
How those people would be able to express their preference in a sibyl resistant way?

Author: fulldecent
Date: 2022-04-13T02:15:58.645Z

Sufficiently advanced lobbying is indistinguishable from grassroots initiatives.

Author: dtedesco1
Date: 2022-04-13T12:55:45.674Z

Yet is either necessarily good or bad? Ay, there’s the rub.

Author: gcolvin
Date: 2022-05-05T15:03:34.234Z

pedrouid:

The spec speaks for itself…


Exactly.  We are evaluating technical specifications, not their provenance.

Author: MrSilly
Date: 2024-04-12T06:25:20.992Z

Without a fight, the decentralized censorship-resistant vision of Ethereum has little chance of winning against the work of deep pockets on a pragmatic core dev community that doesn’t seem that hard to infiltrate or persuade to go against those values. A few things that might still make a difference:

Being more explicit about Ethereum’s values of decentralization, censorship-resistance, open source and open standards and campaigning in their support.
A critical examination of the implicit governance that has filled the vacuum from the absence of any formal process. Is it right to just count votes by core devs? If so, who counts as a core dev and how do we prevent special interests from stuffing ACD with their people?
Amending the EIP process to invite more criticism by adding sections such as conflicts of interest, winners & losers.

Author: MrSilly
Date: 2024-04-12T07:19:49.057Z

How do defend Ethereum from the threat of retroactive bribes?
Airdrops can be used for retroactive bribes. Building on the OP’s example, imagine a de facto natural monopoly is created around Metamask’s invoker contract post EIP 3074 getting in. This could logically follow from the circumstances without any nefarious intentions: invoker contracts are extremely security sensitive, so it would make sense for Metamask and other wallets to whitelist them with extreme prejudice, to avoid users being tricked into delegating their wallets to a malicious invoker. As the largest EOA wallet Metamask’s invoker is likely going to get the most traction. It will have the largest AUM. The larger its AUM the more trusted the contract is going to be, because the AUM serves as a natural bounty. The larger the bounty, the more confidence we can have the contract is safe, because the incentive to compromise has not materialized.
It would be safest for this contract to be immutable, and I’m hoping this turns out to be true for the first versions of it, given the security implications. But let’s consider what happens if down the road, after enough confidence has been built up, an upgradeable version of the invoker contract is launched. Naturally, you couldn’t have the upgrade capability controlled by a centralized multi-sig. That would be unsafe. So we could end up with a governance token. One that controls one of the most important contracts in the ecosystem, with the largest AUM other than the beacon chain. It might be worth a lot. Maybe billions. We’ll have airdrops, possibly  rewarding everyone who supported the consensus changes required for all of this to happen. They would be celebrated as retroactive grants for public goods instead of a reward for promoting a special interest. Nobody has to even promise anything in advance or act in bad faith. The incentives around this are similar to the revolving doors between government regulators and private industry.  The expectation of a lucrative high paying job after your public service ends can be enough to align those working in the public sector with the private sector. No bribe needs to be offered or accepted. No laws broken.
The possibility of using airdrops this way makes it harder to protect governance against special interests. I am a little reluctant to point this out but probably this is something those working to promote special interests are smart enough to figure out for themselves. I’ve come around to thinking it is better to talk about this openly so we can think about possible mitigations and have the motivation to implement them.
A conflicts of interest section in the EIP might help somewhat. They’re standard in the academic world. In the meantime, until we make that improvement to the EIP process, perhaps asking openly anyone who is campaigning for an EIP whether they have any upside (eg equity) or expectation of receiving upside (eg informal promise) to the example outcome?
Exposure or expectation of upside wouldn’t necessarily be a dealbreaker that makes your arguments in favor of an EIP invalid, but the extra information gives the other participants in the discussion the ability to account for the possibility of some motivated reasoning being in play. We’ve done this implicitly for things like EIP-999 but it isn’t always going to be that obvious.

Author: MrSilly
Date: 2024-04-12T08:16:44.207Z

timbeiko:

I think we have a pretty good track record of taking EIPs out if there are security concerns, even if they are brought up late in the process. See Istanbul/St-Peterburg for example, or more recently EIP-2537 being removed from Berlin.


Tim, didn’t ACD just vote to include EIP 3074 despite it opening up a denial of service attack by breaking the DoS protection we have for EIP-4844 BLOBs? Can the existing governance process claim to be pretty good at addressing security concerns when instead of relying on a careful auditing process you end up bringing it to a vote after discussing security concerns on the call itself? How can we expect anyone to have the ability to understand a complex issue on the fly like that?
It seems somewhat unsafe to rely on the ability and willingness of individual contributors like Yoav to highlight issues with a proposal while also relying on the ability of others on that call to evaluate those arguments right before its brought to a vote. It’s unserious to do things that way. Security vulnerabilities are not mitigated by having more of whomever counts as a core dev vote in favor of them. Doing things this way not only risks letting in a proposal that exposes the network to attack but also risks delegitimizing ACD as a governance venue that can be taken seriously by the community.
As an alternative, perhaps we should consider for contentious proposals a more formal and rigorous evaluation process that includes auditing and a request for comments from the community on all aspects?

Author: SamWilsn
Date: 2024-04-12T14:46:39.714Z

Liraz Siri:

evaluation process that includes auditing and a request for comments


That’s a great idea! We can have a body of editors that ensure the quality of documents, a forum for discussing the proposals, and a comment period to make sure the community has a chance to contribute. Since it’s a process for making suggestions to make the blockchain better, let’s call it the Ethereum Improvement Proposal process, or EIPs for short!

Author: MrSilly
Date: 2024-04-13T00:35:47.207Z

Liraz Siri:

evaluation process that includes auditing and a request for comments


Perhaps not carefully worded enough. How about  “security evaluation process that includes auditing and a request for comments by the auditors on potential security problems”.
Is that more clear now?

Author: MrSilly
Date: 2024-04-13T01:37:15.611Z

gcolvin:

We are evaluating technical specifications, not their provenance.


If “we” were perfectly trustworthy and “evaluating” was straightforward then yes provenance wouldn’t matter.
In the real world, both “we” and “evaluating” will be impacted by special interests.
“Evaluating” correctly requires domain expertise and attention, neither of which is equally distributed. Expert opinions can also be bought and if you don’t dive deep enough it can be hard to tell a trustworthy authority from one that isn’t. How safe is it to give an equal vote to people who are not equally informed and equally attentive? How would making governance decisions this way not devolve into “you scratch my back I scratch yours” politics?
Regarding “we” what measures do we currently have in place to prevent special interests from influencing who is on the de facto committee of core devs that is asked yay or nay on a CFI?
To believe this is not worthy of a serious discussion supposes that the controls around who gets a vote are either perfect or imperfect but good enough to resist pressures from special interests with deep pockets. I don’t think we have good reason to believe either. If you’re a big corporation that stands to gain billions from a change to consensus is it really that hard to hire core devs? Or perhaps send your protocol lobbyists to infiltrate client teams and influence them from the inside? If the other devs are not too opinionated about the consensus change that is being lobbied for the lobbyist might end up representing that team. If it’s a prestigious team, the lobbyist could end up with the power to essentially veto consensus changes that don’t align with the lobbyists agenda, because for example, they solve problems the lobbyist claims to care about in ways that don’t benefit his sponsors. In the background the lobbyist would be coordinating behind the scenes to form alliances with other players so ACD calls are basically done deals. In the foreground there would be a meme factory that would out-campaign everyone else to manufacture consent or at least its appearance. Campaigns would play on the prejudices of the community, claiming its all about giving power to the people rather than promoting tirelessly in the service of special interests. They’d play to the fears of other core devs (eg “core devs don’t care about users!”).
My point is as soon as there is enough money at stake from capturing governance provenance matters because it ties back to incentives. We may no longer be in the environment where naive social conventions work best and everyone can be assumed to be acting in good faith. If someone is a protocol lobbyists it could help to know who they’re working for. Again, this doesn’t mean the proposal is bad. A scientist working for a corporation can still produce good science and have integrity, but as soon as they start responding to criticism with memes on X and politics, they’re no longer doing science and we can’t pretend they’re not motivated by something other than truth.

Author: SamWilsn
Date: 2024-04-13T02:57:42.315Z

The foremost experts on Ethereum security are likely the same people working on the client software, who are the same people deciding which proposals to accept. Auditors who can do better are rare and presumably expensive. Requiring these external audits as part of the process would be extremely unfair to EIP authors without deep pockets.

On a more personal note, I want to express my apologies for the sarcasm. This is a touchy thread for me.

Author: MrSilly
Date: 2024-04-13T07:14:14.002Z

No need to apologize. I understand this subject has been contentious for quite some time so bound to surface some difficult emotions. Still appreciated though.


For sure some of the people who understand the protocol best are working for the client teams, but the skillset required for implementing and maintaining a high quality client does not necessarily intersect perfectly with the skills for excelling in protocol design and security. It would be a happy coincidence if it does, but we shouldn’t rely on that. I think that’s why we have a research team. If we didn’t need them it would be more efficient for the client teams to just sort out implementation details between themselves.


It’s now standard in this space to have separate people audit and develop contracts. We can expect contract developers to also have a very deep intimate understanding of the security concerns for their contracts, but we find it still essential to bring in auditors to take a fresh look because a security focused team that specializes in auditing  can still add value. They’ve seen many more examples of how mistakes happen. Also, it can be easy to overlook subtle issues in something you’ve been working on for a while. What you intend the code to do can easily be confused with what the code actually does and developers are holding these intentions in their mind more strongly than external auditors.


I agree that it would be onerous to expect EIP authors to fund the auditing for protocol amendments. It’s hard to even source the talent, let alone pay for it. My expectation would be that the auditing would be funded by the same sources that fund client teams. We also don’t expect EIP authors to fund the implementations of their protocol amendments to all clients, though we’re happy when they submit patches. If auditing is a best practice for contract amendments that effect only one project, why shouldn’t it be the best practice for protocol amendments that risk effecting the whole network?

Author: potuz
Date: 2024-04-14T16:47:20.873Z

Liraz Siri:

It seems somewhat unsafe to rely on the ability and willingness of individual contributors like Yoav to highlight issues with a proposal while also relying on the ability of others on that call to evaluate those arguments right before its brought to a vote.


This does resonate with me. It seemed weird that this discussion wasn’t really closed before the call. Specially given that Yoav had already highlighted this issue in the previous ACDE, and this issue was discussed minimally on Discord after that ACDE 2 weeks ago. I am far from being an expert or even knowledgeable on the topic, but from the little I saw in the discussions in Discord I didn’t see an actual reply to the DOS of blob transaction invalidation being cheap to carry with 3074.

Author: MrSilly
Date: 2024-04-15T04:05:29.342Z

It’s just what you would expect if the ACDE is a formality and the meat of the discussion happens elsewhere between the client teams in private, without other stakeholders or pesky critics around. The way we’re doing things now, they’re the only stakeholder that has a vote anyway. I think this has to change.

Author: MrSilly
Date: 2024-04-16T05:08:56.180Z

timbeiko:

Questions: where do you think this should be done? Some people have done it on AllCoreDevs, for example, but it doesn’t get written in the EIP. Also worth noting that the EIP process is currently open to anonymous submitters, so it may not always be possible. It is worth noting the tradeoff there.
Also curious what you think is the “bar” for conflict?


Wouldn’t it be a good idea to have a conflicts of interest section in the EIP itself? I’d also have a winners and losers section discussing second order effects of the proposal on different players in the ecosystem.
IMHO, bar for conflict of interest would be is the company you work for stands to win more than other network participants. If it is on the winning side of this, the community should take that into account

Author: SamWilsn
Date: 2024-04-16T16:33:06.237Z

MrSilly:

Wouldn’t it be a good idea to have a conflicts of interest section in the EIP itself?


Matt, Ansgar, and myself all used to work at Mesh (nee ConsenSys.) Now we all work for the EF.

Author: eawosika
Date: 2024-04-16T19:47:51.924Z

It’s nice to think about disclosing conflicts of interests, but I’m wondering if this is something that happens with other standards bodies in the wild (e.g., Rust RFCs or the IETF)? Also, why is this conversation only starting because EIP-3074 got included in a fork?
It feels disingenuous to push a narrative that EIP-3074 is being pushed forward because some company stands to benefit. ERC-6900 is mainly bootstrapped by Alchemy. ERC-7579 is bootstrapped by Rhinestone, OKX, ZeroDev, and a number of companies I cannot remember at this time. ERC-7521 is bootstrapped by Essential Builders. ERC-7683 is bootstrapped by Uniswap and Across. ERC-7281 is bootstrapped by core contributors from Connext. ERC-2612 was bootstrapped by Uniswap and played well into the design for Uniswap V2 IIRC.
These are just the few examples I remember, and I’m sure there are more out there. The main point, however, is that no one is raising up hell and calling for a revolution in the EIP process because “X company is in favor of this proposal because it just happens to benefit them.” The community is in favor of these proposals because they offer something meaningful to the ecosystem–we’re looking at specifications, not their provenance as @gcolvin mentioned.
And if anyone was really interested in shaping the EIP process to be “fair” and “transparent”, you can do more practical things–like sign up to be an EIP editor (IIRC EIP editors have been calling for contributors for a long time now, but no one seems to have heard them) or attend ACDE meetings or participate in Ethereum R&D Discord conversations. It’s easy to take the moral high ground and criticize without accepting or understanding that the core devs you speak of and the EIP editors you’re trying to malign are humans (not robots) and operate under very real constraints.
Everyone seems to have their version of a conspiracy theory about what happens in the Ethereum R&D process, and your argument is hardly any different from the ones I’ve seen on crypto-Twitter. You can’t care about making things right only in “special situations” (e.g., when you don’t agree with the decision to go forward with a particular proposal); you need to show up in the other situations as well.
Ethereum isn’t a bunch of virtuous people doing virtuous things–it’s various groups of people with often competing interests and divergent opinions. The only reason Ethereum has had more luck than other open-source projects is its ability to align the interests of everyone involved–even when those interests conflict. That’s the “Ethereum alignment” meme that gets thrown around; most open-source projects are either unable to attract meaningful activity (e.g., because the odds of building a monetized protocol on top of the stack are low), or they sell out completely to well-capitalized actors. Ethereum has managed to navigate both extremes, and the core developers deserve some credit for that.
It’s also important to stop pretending like any of the other protocols that initially criticized EIP-3074 were more concerned about users than their businesses (i.e., stop trying to frame this as a “good vs. evil” debate).  Here’s a Twitter post from Argent’s co-founder telling startups in the account abstraction space they need to do “emergency meetings” and readjust business strategies now that EIP-3074 freely provides some of the features they planned to monetize. That’s literally the first and only post where someone admitted initial opposition to EIP-3074 may also have to do with what they think it might mean for their financial interests (this came up a lot during the issuance curve debate too).
More transparency is never a bad idea, but I’d like to see an effort at transparency that’s not motivated by ulterior motives. You suggest Metamask’s approval of EIP-3074 is nefarious because “EIP-3074 benefits EOAs and Metamask is the most popular EOA wallet”. But pray tell, is Metamask a non-profit? In what school of business is it illegal to support a proposal if it benefits your project? Why can’t I say “smart wallet providers like Argent and Safe supporting ERC-4337 is evil because they wouldn’t be supporting the proposal if it didn’t benefit their businesses”? (Full disclosure: I worked at Consensys previously, but left the company a long time ago like @SamWilsn and co; if you like to think I spent an hour on writing a post to defend a company I no longer work for (or have shares in), be my guest.)
There are dozens of proposals out there–many of which you and I are likely unaware of–that were bootstrapped and supported by projects who felt the need to contribute positively to the ecosystem, even while they operate as entities intent on extracting value. IIRC EIP-1153 may never have made it into a fork, despite offering enormous value to the ecosystem, if Uniswap and other teams hadn’t lent their support to refining the prototype and pushing for the proposal. Should EIP-1153 be declared a Uniswap creation, then?
A “conflicts of interest” section does nothing, except to (probably) raise the barrier to participation in the EIP process. Everyone is going to be on the defensive because the folks in crypto are adept at making up plausible conspiracies and generally taking every opportunity to dog-whistle and malign reputations–if that’s what it takes to advance our agenda.
“Created an EIP/ERC that has the remote chance of benefitting your project (even though other projects will also reap the value and the biggest winners are the users)? That’s right. We won’t accept your EIP because you’re not saintly scholar who has zero conflicts of interests.” Maybe that’s exaggerating things a bit, but that’s the only way to justify calling for a conflict of interests section in EIPs because you assume it’d have prevented EIP-3074 from going in.
There’s really no way to end this post, except to say we should be more charitable and criticize constructively. People like @timbeiko are doing what (ideally) 5-6 people should be doing–but you don’t find them complaining. Adding in hostile criticism (I see @SamWilsn already describes the thread as being touchy) just makes everyone’s job harder and doesn’t benefit the community in any way.

Author: matt
Date: 2024-04-17T19:24:27.395Z

As I said on discord, the attack Yoav describes is possible today on mainnet by invalidating pending blob txs with private txs to block builders. What 3074 does is make this attack cheaper and easier. It is not clear how much of a problem this attack is because 1) it costs the attacker real money and 2) does put them at risk of having their blob txs included in reorgs.
No client teams voiced this a concern on this matter. I think the only reasonable path forward is to implement the feature and attempt these attacks on devnets. There were several additional mechanisms discussed which would resolve this if we find it to be an issue:

We have to remove sending value with AUTHCALL to fully remove the ability to sweep EOAs.
Add a new tx type which statically declares which accounts it will AUTHCALL as

We’re not going to ship something that is unsafe for the network.

Author: thogard
Date: 2024-04-18T02:07:41.400Z

If user access to an opcode is expected to be permissioned and gatekept by centralized off-chain entities (wallet companies) rather than used permissionlessly by builders then the opcode is not ready to be deployed in production on a system aspiring to be permissionless. Either users should maintain their own invoker permissioning or the protocol should enshrine it.  If the largest wallet thinks that EIP-3074 isn’t safe enough for app contracts to use without the wallet’s permission then that implies that the wallets don’t think it’s ready for deployment.
The conflict of interest issue is strong - it’s hard to reconcile the belief of some wallet companies the EIP is both safe enough to deploy yet simultaneously too unsafe to be permissionless.

Author: MrSilly
Date: 2024-04-18T04:59:30.136Z

SamWilsn:

Matt, Ansgar, and myself all used to work at Mesh (nee ConsenSys.) Now we all work for the EF.


That’s not necessarily exclusive though. You can work for EF and still work for someone else in parallel. EF doesn’t ask. It also doesn’t ask if you have exposure to upside in the form of equity, which many people left Consensys with.
A few questions:

Would you be ok with disclosing whether any EIP 3074 campaigners are still receiving income from Consensys or any Consensys affiliated company in parallel with working at EF?
Would you be ok with disclosing whether any EIP 3074 campaigners have equity grants in Consensys/Metamask, or if you’ve been promised anything conditional on EIP 3074 getting it?
Are you guys willing to publicly commit to burning any airdropped Metamask tokens? I believe Metamask’s invoker will likely have billions in AUM, and stands a good chance of becoming a natural monopoly. See how to defend Ethereum from the threat of retroactive bribes

Author: SamWilsn
Date: 2024-04-18T05:10:24.730Z

Speaking for myself only:



 MrSilly:

Would you be ok with disclosing whether any of you are still receiving income from Consensys or any Consensys affiliated company in parallel with working at EF?


I am paid by my corporation, of which I am the only shareholder. That corporation has only been paid by four sources: the EF, the EF’s ecosystem support program (for WTF), Brave (for WTF), and the Protocol Guild.
I am not receiving any funds from ConsenSys or Mesh or whatever they go by now, though I have applied to MetaMask Grants for some funding for WTF.



 MrSilly:

Would you be ok with disclosing whether any EIP 3074 campaigners have equity grants in Consensys/Metamask, or if you’ve been promised anything conditional on EIP 3074 getting it?


I think I’m supposed to have some amount of equity. Should probably check on that… Nothing specific to 3074 though.



 MrSilly:

Are you guys willing to publicly commit to burning any airdropped Metamask tokens?


If I get a larger share because of 3074, sure I’ll burn that part. If I get it for being an EIP Editor, or other contributions unrelated to 3074, no.

Author: MrSilly
Date: 2024-04-18T05:22:31.961Z

eawosika:

Here’s a Twitter post  from Argent’s co-founder telling startups in the account abstraction space they need to do “emergency meetings” and readjust business strategies now that EIP-3074 freely provides some of the features they planned to monetize.


Argent hasn’t been involved helping with the ERC 4337 full account abstraction development effort.
Telling startups that they need to pivot away from full account abstraction is probably quite counterproductive to the account abstraction effort. I believe they’re trying to be helpful, but it goes to show the kind of second order effects we can expect from implementing half measures such as EIP 3074.

Author: matt
Date: 2024-04-18T15:11:17.350Z

MrSilly:

why ACD didn’t defer the inclusion vote until after discussing the security problems and possibly waiting for an audit?


The security problems had been discussed. The question of “AA future” has been discussed ad nauseam over the past few years. The core devs wanted make a UX improvement on L1 in prague because the community has been demanding it and they found 3074 to alleviate the problems in a simple way.
The concern of DoS w.r.t. blobs was also discussed. It is a problem which exists on mainnet today. It’s not clear how much worse 3074 will make it. There are potential solutions, but we have to implement it first and run tests live on devnets. If it is too great of an issue we will remove 3074.
We can’t forever block proposals on hypothetical problems. It’s good that we’re making progress and will see soon if there is a DoS issue.



 MrSilly:

why weren’t the opinions of more stakeholders considered? Have we handed over governance to the execution client devs? I can understand how they might like how simple EIP 3074 is for execution clients to implement, but it has not so simple consequences for everyone. Are their opinions the only ones that count? I ask because there are quite a few stakeholders that think EIP 3074 is a bad idea.


There were several community members who joined ACD to make positive statements about 3074. If there were people who felt it was the wrong thing to do, they did not make their stance known. I have told this to the Safe team. I personally messaged them to let them know we would be discussing these topics so if they wanted to make a statement at that time they could have.
Obviously the community’s opinion counts. If they don’t want 3074 or think it is not a positive direction they should say so. It would have been better to do this months ago while we were discussing the possibility of 3074 inclusion, but it is still valid now. The only people who voiced dissent on ACD was the 4337 team and Vitalik. The core devs decided that wasn’t enough to block the proposal.
I think those who wish 3074 not be included should focus on presenting technical concerns to ACD instead of making accusations about the intentions of the authors of the proposal.

Author: shemnon
Date: 2024-04-18T19:23:32.494Z

matt:

There were several community members who joined ACD to make positive statements about 3074. If there were people who felt it was the wrong thing to do, they did not make their stance known.


Users of the features we are discussing expressing their support/opposition to a potential feature should never be wrong, regardless of venue.  How can we possibly build the “right” thing without feedback?

Author: matt
Date: 2024-04-18T19:43:05.147Z

I don’t really understand your point? I’m saying there was little to no opposition from smart contract wallet teams, dapps, etc about 3074 on ACD, but there was quite a bit of positive support.
How can we possibly build the “right” thing without feedback?

Author: shemnon
Date: 2024-04-18T20:18:29.809Z

I was concurring with the subtext: having people outside “the process” give feedback within the process is not capture in and of itself.  In fact, we need such feedback.  So having MM come on ACDE and say what they said was not, in itself, capture. It contributed positively to the process. I believe there was a general call and any wallet provider could have come on and said the same thing, that would not, in itself, have been capture either.

Author: thogard
Date: 2024-04-18T22:49:28.075Z

There seems to be a misunderstanding over the term “conflict of interest.”
Intuitively, a conflict of interest occurs when an individual has an interest that conflicts with their duties.  It’s straightforward, but note that one does not have to perform any action for a conflict of interests to occur.  They simply have to have an interest.
Conflicts of interest happen all the time.  They are not inherrently bad - they just warrant special consideration.  In most situations, when a conflict of interest is present, the conflicted individual will 1. disclose the conflict, and 2. recuse themselves from the duty.
Some real world examples:

A stock broker receives a “buy” order from a client looking to buy a stock the broker just purchased for themself.  The stock broker has a conflict of interest.  The stock broker discloses the conflict of interest and refers the client to another broker.
A judge is assigned to preside over a case in which the plaintiff is their spouse.  The judge has a conflict of interest. The judge discloses this and recuses themself from the case.
A politician is voting on a bill that can award a government contract to a company that they are a partial owner of.  The politician has a conflict of interest.. The politician discloses the conflict and abstains from the vote.

These are extremely straightforward examples from outside of DeFi.  In the stock broker’s case, failure to disclose and recuse would result in the broker losing their license.  In the judge’s and politician’s cases, failure to disclose and recuse would likely lead to criminal charges.
In this case, Sam has disclosed that he has consensys equity. Sam is an honest person. Sam is a good person. But Sam also has an undeniable conflict of interest. Having a conflict of interest does not make Sam a bad person.  In fact, quite the opposite - we know he’s honest because he did the right thing by disclosing it.  I assume that Matt is in a similar situation and is similarly a good and honest actor.
Laws surrounding conflicts of interest don’t exist because we think everyone may be corrupt and duplicitous.  The laws exist because these conflicts can manifest in a variety of subtle ways. Even if we could read someone’s mind to know if they are intentionally acting against their duty to enrich themselves, governments would still want conflict of interest laws because unconscious biases can be overwhelmingly strong.
All we know so far is:

Metamask stands to potentially benefit from this, should they so desire.
There’s a conflict of interest, and
Matt and Sam are honest people for disclosing it.

Note that I understand that Metamask does not desire to abuse their white list capabilities. But, in much the same way that a 3074 AUTH could be abused in the future if the contract is upgrade, Metamask could abuse this whitelisting power in the future if they decided to.
To protect everyone from biases both conscious or unconscious, we should strive to enact a conflict of interest policy that is, at a minimum, as rigorous as one would find in finance, legal, and governmental bodies. Personally, I view DeFi as an combination of all three… but all three have robust conflict of interest policies for a reason. Those policies did not evolve in a vacuum. I think it would be a shame if Ethereum’s protections from conflicts of interest are less robust than TradFi’s or the US governments.
For reference, US Congress passed a criminal conflict of interest law, 18 U.S.C. § 208, which prohibits you from working on an assignment in some situations - even if you know you can be objective and even if your supervisor wants you to work on it.
link to code (sorry - can’t post links): govinfo .gov/content/pkg/USCODE-2012-title18/html/USCODE-2012-title18-partI-chap11.htm

Author: matt
Date: 2024-04-18T23:21:44.422Z

You don’t seem to understand how EIPs get accepted into hard forks.
It’s irrelevant if we have a conflict of interest. We didn’t vote for the EIP to be included in the fork. It was accepted unanimously by all client teams. It’s their duty to evaluate proposals on their own merit. And they did that.

Author: eawosika
Date: 2024-04-19T19:32:21.390Z

Perhaps it’s worth pointing out that Ethereum is an open-source project, not TradFi and definitely not the US government. If someone builds an application on top of an open-source protocol and makes money off it, that’s not the business of developers working on the open-source protocol.
You’re overindexing on the fact that Metamask stands to benefit from EIP-3074, but conveniently leave out historical instances where a core EIP was passed and one or more companies/startups built something that made them money on top of the framework introduced by said EIP. I call it overindexing because the only way Consensys’ remote involvement in the development of EIP-3074 can be attracting this much scrutiny is likely because you think Metamask is a monopoly and, somehow, protocol developers are enabling the monopoly by introducing an EIP that allows wallets to whitelist certain applications before users interact with them (even if MM has said whitelisting is for security reasons).
The “credible neutrality” principle goes both ways: Ethereum doesn’t explicitly favor perceived incumbents or perceived new entrants–doing any of that is a slippery slope that’s rarely had good outcomes, especially when implemented in top-down fashion. Metamask is one out of the dozens of wallets (possibly more) out there who stand to benefit from EIP-3074, which isn’t surprising because this is a protocol-level specification that’s agnostic to how anyone decides to implement or use it (just like people started companies after ERC-4337 appeared, I expect the same will happen).
Yes, something like centralization of stake in one staking pool is a problem because it poses a threat to the protocol itself, so exploring solutions to even the playing field and protect the protocol from capture from a single protocol. That’s a totally different situation and not comparable to whatever risk you think is going to appear because Metamask chooses to implement a whitelist.
“Conflict of interests” works in traditional settings because you have a thousand different people in the same institution–if X says I have conflict of interest, Y picks up the slack. Core developers are a small group of people taking on multi-year engineering plans (Matt and Sam have been at EIP-3074 for years!), not some cushy R&D lab overflowing with researchers. Maybe you should also ask: “Am I really being realistic right now, or am I letting my biases and convictions cloud my judgement right now?”
But even if it were possible to implement a conflict of interest policy, it simply is not necessary because the current policy of requiring multiple, uncoordinated client teams to reach consensus on the inclusion of EIPs into forks already provides a sufficient system of checks and balances. I don’t think you realize that client teams pushed back at EIP-3074 for four years; if EIP-3074 was a terrible proposal, none of the authors could’ve forced it through if they tried.
“Conflict of interests” is useful in situations when checks and balances don’t exist. If a judge gives a judgement, no one else can challenge that decision–in other words, the judicial process is subject to capture by one person who has ulterior motives. I know juries have power, too, but let’s roll with the example to show a case where checks and balances aren’t really visible.
However, the ACDE is not one or two people making decisions about what gets implemented in a fork; perhaps you should attend the next ACDE meeting to get a first-hand experience of how the process works. If one person had a “perceived” conflict of interest, there’s little they could do because we’ll assume the other 99% don’t have any visible conflicts of interest, and have as much weight in the decision-making process (so their collective weight exceeds that of a minority pursuing their interests). So, enacting an overengineered conflict-of-interest policy adds nothing, except for introducing the problem of getting people to work on stuff (and the number of people working on stuff is already low!).
Your company can have a problem with Metamask, but that’s between your company and Metamask. The core developers working on the protocol are ultimately thinking about users, not the granularities of market forces and capitalist competition. EIP-3074 (like any other EIP) has nothing to do with Metamask–we can even imagine a world in which Metamask didn’t exist and EIP-3074 still makes into a fork. If that world is plausible, why does anyone seem to have an issue with Metamask benefiting (in isolation) from EIP-3074?

Author: MrSilly
Date: 2024-04-24T06:01:05.983Z

matt:

I’m saying there was little to no opposition from smart contract wallet teams, dapps, etc about 3074 on ACD, but there was quite a bit of positive support.


I collected some dissenting opinions at the end of EIP 3074 is unsafe, unnecessary, puts user funds at risk while fragmenting UX liquidity and the wallet stack by the founders of Argent, Gnosis, and the CTO of Ledger.
At least some of the “popular support” was from devs who didn’t understand that in practice, the power of EIP 3074 would only be in the hands of the very few “whitelisted” invokers (eg MetaMask) because it is so incredibly unsafe to authorize anyone else to even pay for your gas with EIP 3074’s all or nothing security model.



 matt:

How can we possibly build the “right” thing without feedback?


Do you really want to build the right thing or do you just want to win? If you want the best arguments to win, why do you vote on having the ACD breakout call on the future of AA when the architect of AA can’t make it to the call? Why do you take advantage of the AA team not being able to make it to Istanbul to FUD AA as slow and complex? Why don’t you invite the AA team to the backroom conversations where you speak with the authority of the majority execution client with the other execution client teams?

Author: MrSilly
Date: 2024-04-24T06:15:39.400Z

thogard:

Matt and Sam are honest people for disclosing it.


Sam has gone on the record about his conflicts of interest. Matt AKA lightclient has not. Matt has played a much more aggressive and active role promoting EIP 3074, including abusing Geth’s power and authority behind the scenes to muscle past objections.
Apologies if I appear to be questioning the motivations of anyone that supported EIP 3074. I am sure almost everyone did that in good faith. But it’s that “almost” that gets me. If it sounds like I am entertaining financial motives being at play it is because I don’t understand where the energy to tirelessly campaign for EIP 3074 by hook and by crook comes from.
I don’t understand how good faith actors would be willing to go as far as exploiting Ethereum’s client diversity problem by throwing Geth’s weight around. Is “might makes right” the kind of culture we want?
I think we should be willing to ask these questions because refusing to entertain the idea that we may have bad actors amongst us makes it easier for bad actors to have their way. Of course, we also need to be careful not to take this to paranoid extremes.
I invite Matt to tell me I’m just being a silly conspiracy theorist thinking he may be motivated by financial interests. To clarify that he is not currently employed by Metamask/Consensys while also working for Geth, or otherwise exposed to the potential billions in upside for Metamask/Consensys from EIP 3074 getting in. That he has not been promised an airdrop of Metamask’s governance tokens and is perfectly willing to declare that he will be burning any such tokens they receive in the future if EIP 3074 gets in and the invoker gets tokenized.
To be clear, we should reject EIP 3074 because it’s a bad idea, not because we are unhappy with the campaign backing it.
On the other hand, how this campaign got through ACD is instructive for understanding where we need to beef up our defenses against capture. Without client diversity it doesn’t take a nation state to capture Ethereum governance and get contentious changes in, it just takes one person speaking for the majority client team in backroom sessions with the other execution client devs, critics are not invited.

Author: MrSilly
Date: 2024-04-24T07:16:00.678Z

matt:

The core devs wanted make a UX improvement on L1 in prague because the community has been demanding it and they found 3074 to alleviate the problems in a simple way.


Let’s unpack that because I think you may be misrepresenting what actually happened and the role you played. You appear to be trying to convey the impression that you played the role of a dispassionate observer trying to figure out what the “core devs” want. That’s disingenuous. Shortly after you joined the Geth team you somehow start speaking on their behalf. Others like Peter can’t be reached. EIP 3074 wouldn’t have gotten this far if you hadn’t taken advantage of Geth’s position  to campaign for EIP 3074. Behind the scenes you exploited Geth’s position as the majority client to FUD work on the native account abstraction roadmap, discouraging contributors saying Geth will never accept their commits and saying Geth won’t support EIPs that provide the functionality of EIP 3074 without the baggage.
You’re a smart guy. You sound very reasonable in public, but your actions and the difference between what you say in public and how you act in private tells a more nuanced story. You exploited Ethereum’s client diversity problem to assert Geth’s power to essentially veto safer alternatives to EIP 3074. You directly influence other client teams who don’t want to waste their time working on things Geth won’t support.
If you don’t want to be accused of having bad intentions, it’s best to avoid misrepresenting what actually happened and tucking away all the backroom politics into this neat consensus of the “core devs”.



 matt:

Obviously the community’s opinion counts. If they don’t want 3074 or think it is not a positive direction they should say so. It would have been better to do this months ago while we were discussing the possibility of 3074 inclusion, but it is still valid now. The only people who voiced dissent on ACD was the 4337 team and Vitalik.


Do you think disagreement by those actually working on account abstraction and the founder of Ethereum should give us enough pause to actively pull in other stakeholders into the process and get their opinions as opposed to hoping they insert themselves? Participating in governance discussions can be intimidated to outsiders. This is true even when the chief advocate for an EIP isn’t lobbying for it from inside Geth, FUDing AA as something that will never happen while playing an active role in obstructing it.

Author: MrSilly
Date: 2024-04-24T07:27:22.653Z

eawosika:

But even if it were possible to implement a conflict of interest policy, it simply is not necessary because the current policy of requiring multiple, uncoordinated client teams to reach consensus on the inclusion of EIPs into forks already provides a sufficient system of checks and balances.


Why don’t you ask the execution client devs how uncoordinated they’ve been in the decision to vote in favor of EIP 3074 and what role Matt played, speaking in those backroom discussions with the authority and power of Geth?
Even if there was no backroom coordination that gave the person representing the majority client inordinate influence, we’d still have the problem of client teams not being the only stakeholder that should have a say, especially on contentious decisions.
In practice, execution client teams are the only stakeholder with a vote on ACD. We never officially decided on this, it’s not written down anywhere, but nobody objected too much before so that’s the way it is now. There’s no other step so what’s voted in on ACD gets into the next hard fork by default.
Ethereum has a governance problem that encourages populist messaging in public and behind-closed-doors negotiations amongst a very limited set of stakeholders in private.
Good governance would pit the best arguments from a range of stakeholders against one another in front of people who are both capable and willing to take the time to understand them.
Bad governance would shy away from the unpleasantness of debate and let a self selecting core dev club vote on it. The real discussion/negotiation happens behind closed doors with a curated selection of voices (critics not invited) so by the time it reaches the public call it’s a done deal negotiated between the client teams, led by whomever happens to be speaking for the majority client.

Author: matt
Date: 2024-04-24T17:07:19.247Z

Since this is getting personal, it feels a little unfair that many reading this exchange don’t know who you are @MrSilly. So for context:
Your company created the Ethereum Gas Station Network (GSN) and you are one of co-authors of ERC-2771. ERC-4337 is the spiritual successor (in design and personnel) to ERC-2271. You worked (work?) closely and are friends with the ERC-4337 team.
Is this a fair description?



 MrSilly:

Airdrops can be used for retroactive bribes.


You’ll notice I have never once asked if there is a conflict of interest by you or ERC-4337 team. If RIP-7560 goes live on L1 or L2, I would think you and ERC-4337 team would certainly be a prime candidate for a retroactive airdrop. In fact, the ERC-4337 team has already earned around 309k OP (~$750,000 USD) for their work.
Ask yourself internally if you have a conflict of interest due to your work on ERC-2771 and ERC-4337 or your friendship with the team. I think you’ll come to the same answer as me: it’s not about money or friendships, you want the best thing for Ethereum.
I trust that despite our technical disagreements, you and the ERC-4337 are simply working towards what you believe is best for Ethereum. It seems reasonable to expect the same respect in return.
If you have something more substantial than vague accusations about retro airdrop farming or a secret financial agreement with Consensys, I implore you to make those concerns known (whether it is regarding me, or any other core dev).



 MrSilly:

I invite Matt to tell me I’m just being a silly conspiracy theorist thinking he may be motivated by financial interests. To clarify that he is not currently employed by Metamask/Consensys while also working for Geth, or otherwise exposed to the potential billions in upside for Metamask/Consensys from EIP 3074 getting in. That he has not been promised an airdrop of Metamask’s governance tokens and is perfectly willing to declare that he will be burning any such tokens they receive in the future if EIP 3074 gets in and the invoker gets tokenized.


It’s pointless for me to state my financial interests publicly without a system to enforce correctness, as you’d have to trust my word for it. Feel free to ping me or my employer privately if you want to discuss further.
For completeness, I can say–and hopefully you / the readers can trust my word for it–that I don’t have a financial interest in EIP-3074 being accepted beyond the possibility of RPGF and a small amount of ConsenSys Mesh stock options (likely expired at this point?) which would have a small allocation of ConsenSys shares.
There is no promised airdop or agreement with ConsenSys / MetaMask. I’m not sure I’m willing to declare I would burn tokens awarded for the development of EIP-3074. If that’s an issue I would be interested in discussing separately at another time, but in general 1) I prefer that companies award ProtocolGuild over individual core devs 2) the RPGF mechanism was designed to reward people who generate a lot of value for the community by developing public goods. That’s the case for ERC-4337, it may be the case for EIP-3074.



 MrSilly:

Do you think disagreement by those actually working on account abstraction and the founder of Ethereum should give us enough pause to actively pull in other stakeholders into the process and get their opinions as opposed to hoping they insert themselves? Participating in governance discussions can be intimidated to outsiders. This is true even when the chief advocate for an EIP isn’t lobbying for it from inside Geth, FUDing AA as something that will never happen while playing an active role in obstructing it.


It’s really strange you’re making an appeal to authority here. You can just say Vitalik’s name, it already carries enough merit on its own.
He and “the architect of AA” don’t dictate how the protocol evolves. They get to make proposals just like anyone else and the client teams can review the proposals and decide what makes sense to them. They had ample opportunity to present native account abstraction to client teams and they had ample opportunity to present cases against EIP-3074. In the end, the client teams weighed the available information and made the decision to accept 3074.
Right now the ERC-4337 team is working in isolation from client teams on the future roadmap for native account abstraction and are just expecting them to simply accept whatever they propose. That’s just not how the process works. I think if they would spend more time engaging with client teams, they might come up with a proposal that is more amenable to being included on L1.
I have personally discussed 7560 internally within geth, I have talked to devs on different client teams, as well as some developers of EVM-compatible rollups and as far as I could gather, there is no much support for RIP-7560.



 MrSilly:

Why don’t you ask the execution client devs how uncoordinated they’ve been in the decision to vote in favor of EIP 3074 and what role Matt played, speaking in those backroom discussions with the authority and power of Geth? How did execution client teams that opposed EIP 3074 for years suddenly come to see the light?


You are alluding to the fact that you have knowledge that I did something inappropriate in backroom discussions with my power. Why don’t you state specific occurrences you find problematic instead of making vague accusations? I am pretty confident that I have acted appropriately publicly and privately in all discussions regarding all the AA proposals, but maybe we can discuss some specific situations.



 MrSilly:

The real discussion/negotiation happens behind closed doors with a curated selection of voices (critics not invited) so by the time it reaches the public call it’s a done deal negotiated between the client teams, led by whomever happens to be speaking for the majority client.


Weird and very wrong take.

Author: MrSilly
Date: 2024-04-25T17:09:23.394Z

matt:

Since this is getting personal, it feels a little unfair that many reading this exchange don’t know who you are @MrSilly. So for context:


My apologies, I would have preferred not to make it personal but I don’t know how to point out that an easy to capture governance process is being exploited by a social engineering campaign without also pointing out the social engineer orchestrating it.
Regarding the attempted false equivalence, anyone who clicked on my account could see my full real name. My real name being there is no accident. That’s also my real face in the profile photo. As I told your friends a couple of years ago, I wrote the OP that you said you found offensive under the defectivealtruist pseudonym. I wrote it because I was worried by the success of the previous social engineering campaign to promote EIP 3074 when you were still working at Consensys. This is when you implied EF was endorsing the proposal, when it just provided a grant to split the cost of the dedaub report with Consensys. The OP wasn’t because some mean person had a grudge against you, it was a response to how you hijacked the legitimacy of the EF deceitfully to manufacture consensus in 2021.



 matt:

Your company created the Ethereum Gas Station Network (GSN) and you are one of co-authors of ERC-2771


That startup shut down in 2019. The product was an enterprise wallet. GSN was a small piece of missing infrastructure we decided to release as a public good. Putting time and money into a public good was probably one of the reasons the startup failed.
Some of people that worked on GSN are working on 4337 now, but I am not one of them.



 matt:

ERC-4337 is the spiritual successor (in design and personnel) to ERC-2271


No, this is a bad analogy. 2771 just standardized the meta tx encoding for embedding the  msg.sender. Calling it a predecessor to 4337 is like calling Unicode a predecessor to SMTP.
4337 was designed by Yoav and Vitalik, building on Vitalik’s idea of leveraging private mempools and some of Yoav’s learnings from the GSN.



 matt:

If RIP-7560 goes live on L1 or L2, I would think you and ERC-4337 team would certainly be a prime candidate for a retroactive airdrop


Sorry no. I didn’t get any part of the OP airdrops and I don’t expect posting my concerns on EM to warrant any future retroactive grants. FWIW, I was campaigning for the idea of retroactive grants way back, which you can also see a hint of in the OP, but I never benefited from them financially. I’m now somewhat concerned that they also pose a risk to the integrity of governance when used as retroactive bribes.



 matt:

Ask yourself internally if you have a conflict of interest due to your work on ERC-2771 and ERC-4337 or your friendship with the team. I think you’ll come to the same answer as me: it’s not about money or friendships, you want the best thing for Ethereum.


I respect my friends who have chosen to work on a public good instead of a for-profit venture, but I’m not speaking up for them. I also don’t care about Ethereum in the sense that I think it is worthwhile to declare my loyalty to it as a tribal brand. I care about the values I thought Ethereum was supposed to embody. Open source, open standards, decentralisation, permission less, censorship resistance. Work on 4337 is aligned with those values so I support it. I hope in the future to contribute more to aligning Ethereum with these values. I also care about good security design.



 matt:

I’m not sure I’m willing to declare I would burn tokens awarded for the development of EIP-3074.


Given your championing of 3074 how would you rate your chances of making a life changing amount of money when Metamask tokenizes an invoker with billions of AUM? True, even if you promised publicly to burn the tokens we would still have to trust your word but that doesn’t make it worthless. You’re still publicly committing to it. If you don’t believe we should take this seriously because you are not going to be making a life changing amount of money anyway then you’re not giving up anything by committing to it. If you’re not willing to commit even to the hard to enforce honor system version of this, why should anyone dismiss as conspiratorial nonsense the possibility that you’re motivated by financial gain?



 matt:

He and “the architect of AA” don’t dictate how the protocol evolves.


This is a straw man. You’re too eager to respond with populist anti elite rhetoric. I asked what should be sufficient criteria for identifying when proposals are contentious, not who should dictate how the protocol evolves. Given how you’ve leveraged the authority of the majority client, the dominant actor in the exclusive committee of execution client devs that are the only stakeholder with a vote on ACD,  you have a much better claim of leading a shadowy dictatorial elite than Vitalik. Yet he’s not the one coordinating populist anti-elitist meme campaigns on Twitter, you are. I don’t trust Vitalik as an authority, I trust him as someone’s who’s values I respect who’s also pretty smart. You on the other hand seem to have a track record, even on this thread of attempting to exploit information assymetries to  deceive and manipulate. It’s a pattern of behaviour that I find disturbing and alarming given that we don’t have strong protections around governance. It’s like seeing a fox in a hen house.

Author: eawosika
Date: 2024-04-25T17:43:53.246Z

MrSilly:

Given your championing of 3074 how would you rate your chances of making a life changing amount of money when Metamask tokenizes an invoker with billions of AUM?


You should stop, really. At this point, you obviously have an axe to grind and EIP-3074 is giving you the perfect opportunity to do it. I hate dismissing criticisms out of hand because “the world’s greatest fool may say it’s shining, but that don’t make it sunny outside” (i.e., even the most unbelievable criticism might have some element of truth to it).
But you have simply strayed way too far into ad hominem territory that I’m wondering if you read your messages before sending them. Right now, I wouldn’t know if I was on 4chan reading spiteful comments from anonymous posters and keyboard warriors or reading posts on a forum dedicated to objective, technical discussions.

Author: matt
Date: 2024-04-25T17:51:17.303Z

MrSilly:

I wrote the OP that you said you found offensive under the defectivealtruist pseudonym


This is news to me. I didn’t engage with this post back then because it was a strange conspiracy theory by a random anon account.



 MrSilly:

Given how you’ve leveraged the authority of the majority client


If there are core devs who feel this way, feel free to post here or message me privately and we can discuss. I have not received any complaints about how I’ve handled 3074 except from you.
–
Look, your entire argument is based on accusations. I’m not going to continue debating in circles with you. I don’t know why you’re so upset about this proposal or why you feel it important to attack me personally without any evidence of wrongdoing, but in the process of doing so you are also negating all the work and discussions from other core devs who have discussed, accepted, and implemented the proposal over the past few months.

Author: eawosika
Date: 2024-04-25T17:55:00.886Z

MrSilly:

It’s like seeing a fox in a hen house.


The only fox in the hen house is someone who restarts an old and dead debate just because it happens to feed on the paranoia people have around Ethereum’s governance process. Like I told the other person raising hell on Twitter and accusing core developers and Consensys of colluding to force through EIP-3074, “you’re not a saint or Luke Skywalker fighting against Darth Vader and the forces of evil”.
I’ve read the argument again, and even now, it’s clear you think you’re on a crusade to save Ethereum’s governance process from the people who’d turn it into something else. But you actually aren’t achieving that goal here. If you cares enough, maybe you’d have become more active in the ACDE process a long, long time ago. What better way to ensure folks don’t corrupt governance if you have boots on the ground?
But, your grouse isn’t with the ACD as much as it is with EIP-3074 and the people working on it. I definitely don’t have context, but the only people who keep up their conspiracy theories for years usually do it out of revenge or payback for some perceived slight. I don’t know who pissed you off, but you certainly need to take care of that separately and avoid projecting your negative feelings on the world and hurting good people in the process.

Author: MrSilly
Date: 2024-04-25T18:23:25.187Z

eawosika:

Right now, I wouldn’t know if I was on 4chan reading spiteful comments from anonymous posters and keyboard warriors or reading posts on a forum dedicated to objective, technical discussions.


Note that you are commenting on a post titled “Protecting the EIP process from special interests”, which is in the process improvement category. I posted my technical concerns separately.
Protecting governance from special interests is a hard problem and it is going to get harder, especially the way things currently work. I agree it’s unpleasant, but so is the barking of any watchdog. I also believe that pointing out the lack of checks and balances around the ACDs committee power is dangerous. For one it risks the “core devs” closing ranks. On the other hand, it risks explaining vulnerabilities in governance to other actors with the resources to exploit it. I just happen to believe the risk of nobody barking is greater than the risk of barking. This won’t be fixed by barking alone, but if everyone keeps pretending we don’t have a problem, it’s harder to motivate the kind of energy required to make hard changes. Rainbows and unicorns won’t cut it in an adversarial environment, but the motivation to prioritize this vs everything else we could be working on relies on believing that governance is vulnerable to adversaries.
How do you get the community to take a vulnerability seriously without discussing the details of the exploit? How do you discuss the details of the exploit on a loosely defined social process without discussing the people involved and how things work in practice? Who benefits from shadowy ambiguity and subtle innuendo?
Back in the real world, lobbying is a massive multi billion dollar influence industry. As soon as there’s enough money at stake, dismissing the threat of lobbying as the stuff of 4chan conspiracies is naive.

Author: MrSilly
Date: 2024-04-25T18:49:31.215Z

eawosika:

The only fox in the hen house is someone who restarts an old and dead debate just because it happens to feed on the paranoia people have around Ethereum’s governance process.


I restarted this thread because the threat I originally highlighted materialised. Not only the general threat but also the specific example I used as a case study. But sure, feel free to dismiss this as agitation for the sake of making trouble.



 eawosika:

If you cares enough, maybe you’d have become more active in the ACDE process a long, long time ago


Who knows, maybe, but my understanding of the governance process was that improving it would require a massive insider coordination effort like the kind Trent did with the protocol guild. The stories I heard on how hard it was to coordinate even simpler pre-protocol guild effort like the EIP-1559 NFT convinced me I wasn’t the right person for that job. I can’t stand politics. I understand they’re a necessary evil, but it takes a kind of diplomatic personality to be good at that sort of thing that I clearly don’t have. As you can see my style of communication is direct to the point of being offensive to the friends of the people I criticise.
I wish I could contribute more, and maybe I’ll figure out how in the future but in the meantime explaining the problems as I see them is what I know how to do. You can dismiss that as a valid contribution, you can argue it may be counterproductive and if you do you’ll be in the company of some of my best friends in the space. If it ends up a net positive it will be because of the efforts of others.



 eawosika:

“you’re not a saint or Luke Skywalker fighting against Darth Vader and the forces of evil”.


I’m sure they appreciated your condescension, but sure I concede everyone wants to be the hero of their own story.



 eawosika:

the only people who keep up their conspiracy theories for years usually do it out of revenge or payback for some perceived slight


If I’m just trying  to get revenge for some perceived slight, why did I disengage for 3 years after posting about it once in 2021? How does this heuristic of spotting the madman who grinds his axe for years out of spite apply to someone who has been observing quietly and restraining himself from making further comments hoping that the system would defend itself?
I suspect calling someone a conspiracy theorist acts as a mental stop sign. “Move along now nothing to see here”. What are you so eager to prevent people from thinking about?

Author: MrSilly
Date: 2024-04-27T14:07:02.075Z

matt:

This is news to me


I was going to tell you in person over breakfast, and possibly add an apology for hurting your feelings but you were too busy dissing EF, infinite gardens and subtraction as obvious BS.



 matt:

I didn’t engage with this post back then because it was a strange conspiracy theory by a random anon account.


The whole post was a strange conspiracy theory or the case study pointing out that pretty much everyone working on EIP 3074 had conflicts of interest and stood to gain financially from Metamask’s success? You hold equity in Consensys. What other jewels are in there? Do you really need a conspiratorial mindset to believe people respond to incentives? Isn’t that economics 101?
I did later regret putting it all in one post. If the EIP 3074 campaign example was posted separately, the general point about Ethereum governance needing to defend itself against an increasingly adversarial environment may have attracted more discussion. Why would lobbying not be a problem given that the conditions here match up with public choice theory? Everywhere else the conditions match up there’s a problem.
Core Devs say the core Devs will decide, when many of us are still confused about who decides who is a core dev. Even if we assume this self coronating, self selecting committee is trustworthy today, why should we trust it to be trustworthy tomorrow? Is it impossible to buy a client team? What prevents interested parties from hiring core Devs to look out for their interests? If you can buy client teams and hire the only people who can vote, how is Ethereum governance not for sale? How does this not collapse into plutocracy?
Is it possible for someone who’s not a client dev to explain why we should be ok with handing over Ethereum governance to a tiny group of backend developers? Why  should we just trust them to make the right calls, not merely on obscure matters of client optimization but even on strategic matters such as the UX roadmap and a sweeping change to the EOA security model?



 matt:

If there are core devs who feel this way, feel free to post here or message me privately and we can discuss. I have not received any complaints about how I’ve handled 3074 except from you.



Who counts as a core dev?
Can you understand why speaking for the majority client makes people less likely to tell you what they really think to your face? Good thing I’m not planning on proposing any EIPs soon

Author: thogard
Date: 2024-04-27T22:33:09.565Z

MrSilly:

Is it possible for someone who’s not a client dev to explain why we should be ok with handing over Ethereum governance to a tiny group of backend developers?


I don’t think this is an optimal governance process, but I want to point out that it’s not a matter of “handing over” the governance… the clients have that power by default. Hard forks are implemented by the clients, and if a client doesn’t implement an EIP then any validators who use that client would therefore also not implement the EIP.
It’s high friction for Proof of Stake validators to change clients - for the large, custodial operations it usually involves an expensive audit process and the alteration of service level agreements with their top stakers / depositors… thus, the client teams are de facto voting proxies for the validators.
It’s also important to note that due to the nature of hard forks, client teams can’t effectively compete over EIP support in order to “win over” validators from other client teams.  While a scenario in which validators choose clients based on EIP support is theoretically possible, it’s fundamentally unsustainable in the long term because the losing client would become irrelevant by being on the wrong side of the next fork… plus, that competition would lead to decreased client diversity and significantly decreased safety for validators during forks… and that’s not even bringing USDC, tether, or other asset-backed actors into the equation. 
If we were to campaign to take the EIP-annointing power away from the client teams, the alternative solution would have to be holistic, transparent, and probably by the client teams via the social layer… because, to be blunt, if all the client teams want to do a hard fork then there’s not really anything that anyone else can do about it.

Author: MrSilly
Date: 2024-04-30T10:00:10.286Z

thogard:

If we were to campaign to take the EIP-annointing power away from the client teams, the alternative solution would have to be holistic, transparent, and probably by the client teams via the social layer…


There are many improvements we can make to the governance process, but the priority right now should be to resist the attempted overthrow of emergent consensus as Ethereum’s de facto governance model. A new authority has asserted itself and it needs to be challenged.
Up until the recent EIP 3074 inclusion vote, it was widely understood that improvements to the Ethereum network require reaching broad agreement on changes to the protocol. This “emergent consensus” process was similar in principle to how consensus emerges amongst mathematicians on the validity of new proofs, or scientists on the validity of new theories. It was fail-close.
EIP 3074 was the first time client devs voted on ACD to dismiss the concerns of a broad range of other stakeholders. They did this using the lowest form of legitimacy:

Legitimacy by brute force: someone convinces everyone that they are powerful enough to impose their will and resisting them will be very hard. This drives most people to submit because each person expects that everyone else will be too scared to resist as well.

They dismissed the objections of Vitalik, the EF’s account abstraction team, and many other ecosystem participants who disagree that EIP 3074 is a good idea on a technical level or that it should be prioritized over features Ethereum needs for censorship resistance such as inclusion lists, which had to be excluded because it is incompatible with EIP 3074. They also dismissed the stakeholders protesting that it is unfair for the client devs to tilt the playing field in the favor of the largest EOA wallet at the expense of developers of other wallets, intent networks, parallel EVMs, etc. Critics that pointed out that almost everyone pushing for EIP 3074 had conflicts of interests were dismissed as conspiracy theorists. The campaigners didn’t disclose their conflict of interests until they were called out and asked directly. They also didn’t abstain from voting on ACD.
The governance process we had 3 years ago rejected a well coordinated campaign to lobby for EIP 3074’s inclusion. Since then we’ve gotten a lot closer to full account abstraction. If it wasn’t a good idea back then, how is it a good idea now? What changed? The ideas didn’t change. There’s still no path from EIP 3074 to account abstraction. It’s still a kludgy insecure mess that puts user funds at risk, gives Metamask an unfair advantage and risks breaking the network. If you’ve seen how the sausage is made, it is hard to escape the impression that what changed was the governance process got more politicized after EIP 3074 campaigners weaponized their influence over an overly centralized client development process.
Also note,  that though Ethereum made a lot of progress towards full account abstraction we would have made more progress if not for the active obstruction efforts that started shortly after the EIP 3074 champion moved from Consensys to the contractor maintaining the Geth client.



 thogard:

I don’t think this is an optimal governance process, but I want to point out that it’s not a matter of “handing over” the governance… the clients have that power by default. Hard forks are implemented by the clients, and if a client doesn’t implement an EIP then any validators who use that client would therefore also not implement the EIP.


Client devs don’t have control over governance by default, otherwise they’d be able to rewrite the ledger at will, fork the EF treasury into a DAO under their control, introduce block rewards to fund themselves, etc. There have been previous attempts by duplicitous “core devs” to appeal to the prejudices of client devs to do just that. Nothing prevented them from updating the repos. They failed because those changes were contentious, and it was hard for contentious changes to get the critical mass of legitimacy needed to support a network upgrade.
If client development is overly centralized, it only takes one contractor to prevent the network from changing in ways the contractor doesn’t like (e.g EOF, AA roadmap) by refusing to implement them or just dragging their feet. Centralized development gives a handful of devs the power to essentially veto EIPs, even if there’s a wide base of agreement amongst all the other stakeholders. If they have to sign off on changes, they can stall arbitrary developments, which gives them a lot more power than other participants, including other minority client teams.
Let’s say we we’re not worried about them using this power to negotiate for an ever larger share of public goods funding. Let’s say we are ok with assuming they would be perfectly benevolent, perfectly trustworthy forever. That they could never be bought. Wouldn’t we still be worried about them making honest mistakes and nobody being in a position to check them?
“That which we are permitted to administer we mistakenly believe we own.”

Author: MrSilly
Date: 2024-06-29T03:19:47.098Z

After mulling my involvement over, I feel like I owe the 3074 team an apology for  making it personal and questioning their integrity.
There’s a saying, you shall know the seeds by their fruits. I’m not happy with the collateral damage around the 3074 debate. Assuming good faith is easier said than done, but in retrospect I feel like I should have tried harder to disagree in a more positive, community affirming way. That’s something I’ll work on moving forward.
FWIW, in addition to making the discussion unnecessarily toxic and bringing out the worst in everyone, I’ve realized making it personal risks backfiring by making it harder for people to change their mind. People can let go of an idea more easily than they can let go of their reputation, or their social/tribal affiliations. Also, accusing people of being hostiles is a pretty reliable way of summoning hostility, even if it wasn’t there before. It’s self fulfulling in  a bad way.
Sorry.