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
Matt, Ansgar, and myself all used to work at Mesh (nee ConsenSys.) Now we all work for the EF.
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.
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:
AUTHCALL to fully remove the ability to sweep EOAs.AUTHCALL asWe’re not going to ship something that is unsafe for the network.
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.
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:
Speaking for myself only:
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.
I think I’m supposed to have some amount of equity. Should probably check on that… Nothing specific to 3074 though.
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.
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.
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.
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.
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?
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?
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.
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:
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:
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
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.
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?
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.
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?
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.
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”.
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.
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.
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?
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).
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.
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.
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.
Weird and very wrong take.