Protecting the EIP process from special interests + examples & case study

Process Improvement
7

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?

8

Sufficiently advanced lobbying is indistinguishable from grassroots initiatives.

1 Like
9

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

10

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

2 Likes
11

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:

  1. Being more explicit about Ethereum’s values of decentralization, censorship-resistance, open source and open standards and campaigning in their support.
  2. 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?
  3. Amending the EIP process to invite more criticism by adding sections such as conflicts of interest, winners & losers.
1 Like
12

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.

13

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?

2 Likes
14

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!

15

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?

16

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.

17

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.

1 Like
18

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.

  1. 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.

  2. 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.

  3. 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?

19

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.

20

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.

21

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

22

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

1 Like
23

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.

3 Likes
24

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:

  1. We have to remove sending value with AUTHCALL to fully remove the ability to sweep EOAs.
  2. 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.

3 Likes
25

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.

26

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:

  1. 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?
  2. 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?
  3. 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
1 Like