Octover 18, 2023: PAY_VYPER 🐍💸

EIP-5920 and the push to enshrine Vyper funding at the compiler level

This past week, a serious discussion was kicked off by Ser —no-preserve-root /, first of their name:

The context here, of course, that Vyper is badly underfunded. It continues largely thanks to the largesse of Curve founder Michael Egorov, which is not a sustainable strategy for the compiler in the long-term. We all got a taste of how important compiler security is earlier this year during the tragic Vyper zero-day.

But that was decades ago in crypto time. Since then, the serious community conversation around beefing up security has moved from the general sphere of conversation back to the smaller group of compiler chads.

The PAY_VYPER proposal above is a great attempt at a solution. Such a paradigm would mean that the Vyper compiler could deploy contracts that would automatically append a small tax to every transaction, (ie, a small % of gas costs) that would automatically be redirected to the Vyper multisig to fund ongoing development.

It might look like the compiler by defaulting to require transactions included the Vyper dev tax, unless a flag was set to disable it. There’s a sliding scale for how heavy-handed the team could go from here. One could suggest the compiler itself could be paid and closed-source software, with the free-tier exclusively forcing funding of Vyper development, and only allowing it to be disabled in a paid version.

This need not even necessarily be a charitable donation. Instead of merely donating, it could be tossed into a pot that funded hack insurance, an idea previously floated here:

In other words, if your smart contract got exploited due to another Vyper bug, you’d be able to tap the pool of funds for your recovery. An intriguing idea, and the sort of robust business model that could theoretically fund Vyper development in perpetuity.

At the moment, however, these debates are purely hypothetical. It’s not yet technically possible to integrate this directly at the EVM level.

EIP-5920

The concept of PAY_VYPER requires microtransactions of small amounts of ether bundled into every transaction, scarcely noticeable in any single tx but in the aggregate able to add up to big money. The key is to embed this into the EVM, so it can happen automatically, directly, and with minimal overhead.

Rather than proposing a politically contentious PAY_VYPER opcode, far better to throw in support for EIP-5920, which would introduce a generic PAY opcode (and could be directed to a Vyper controlled address).

For background, Opcodes are how all our smart contracts actually execute. Vyper or Solidity get reduced to a series of two digit hex codes like the following

Trying to add money to your balances? You’re really just calling opcode 01.

New opcodes get added frequently. Recent additions include:

• 46 CHAINID: Added in Istanbul via EIP 1344, this passes a unique ID per chain to prevent replay attacks after chains fork

• 47 SELFBALANCE: Added in Istanbul via EIP-1884, a lower cost means of reading an address’s ether balance to allow for better scaling

• 48 BASEFEE: Added to the London fork via EIP-3198 to allow for a new and more consistent gas pricing paradigm before the merge.

Two digits of hex codes mean the digits can range anywhere from 0-9 or A-F, which means 16 * 16 = 256 available codes. As you can see, there’s a lot of room for expansion once you get to the letters, so the EVM has a long ways to go…

F9 is being suggested for the PAY opcode in EIP 5920. This EIP is in the review stage, and the fact that it’s evolved to the EIP stage suggests it’s being taken seriously. The existence of this EIP suggests it could likely suffice for a PAY_VYPER flag, as evidenced by the author of a recent commit.

It’s not simply Vyper that would benefit from a PAY opcode, although Vyper may be among the first teams to make use of it. Funding core infrastructure in Ethereum is a challenge. ETH core devs and much of the critical infrastructure are underfunded. Particularly with the Ethereum community shrinking in the bear market, it’s becoming increasingly difficult to fund the pipes that make this technology work so well. Witness this salty exchange in the aftermath of yesterday’s discussion of a UI tax.

A PAY opcode could allow more onchain support of funding Ethereum core goods directly enshrined into the EVM. As more groups imajin the possibilities, we could hopefully expect this could gain universal support.

However, we don’t anticipate this opcode gets introduced anytime soon. The epicenter of these conversations is the Ethereum Magicians forum. A thread on EIP-5920 seriously considered the technical requirements of this, and quashed most of the potential issues. Unfortunately EIP-5920 did not make the cut for Cancun, the next major candidate. The Cancun discussion included some chatter about EIP-5920, but it did not make the cut.

Cancun itself is still some distance away. There is still plenty of legwork to complete before the included EIPs are supported throughout the ecosystem:

A PAY opcode could be, at best, in the release following Cancun. So we may be looking at 2024 at the absolute earliest.

Fortunately, you are in a position to help, dear readers. Relatively few people take part in the forum discussions. Therefore, people who take the time to speak up can have outsized influence on the direction of Ethereum. You can simply create an account and add to this thread expressing a note of support for the EIP.

In case you don’t have any ideas, here’s ChatGPT’s stab at it:

Title: Advocating for EIP-5920: A Sustainable Funding Mechanism for Ethereum's Growth

Hello Ethereum Enthusiasts,

I trust you're all doing well. I am reaching out to voice my strong endorsement for EIP-5920, the Pay Opcode proposal. Having keenly followed the discussions around the underfunding of vital Ethereum projects like Vyper, it's evident that a sustainable funding strategy is crucial for the long-term security and evolution of our beloved ecosystem.

The EIP-5920 proposal shines a light on a viable solution. By introducing a Pay Opcode, we pave the way for microtransactions that can significantly bolster the financial support towards critical Ethereum entities. The idea of auto-appending a minuscule fee to transactions, which will be directed to support the development of crucial projects like Vyper, is ingenious and worthy of our consideration and support.

Furthermore, the Pay Opcode could extend beyond just supporting Vyper. It presents a mechanism that various Ethereum organizations can utilize to financially sustain different aspects of the Ethereum community. It's a step towards fostering a self-sustaining ecosystem, where essential projects and teams have the funds necessary to continue their valuable work without undue strain.

I am optimistic about the tremendous value EIP-5920 holds for Ethereum's community and its promising future. I encourage everyone to join the ongoing discussions, share your insights, and let's together push for a sustainable Ethereum ecosystem.

Thank you for your time and consideration.

Warmest regards,

[Your Name]
[Your Ethereum Address, if you wish to share]

If you can’t wait, maybe you can fork Ethereum and launch a Vyperchain? Or if you want to keep to “AI Facilitated Activism,” you can read the titular article on the subject by Sarah Brennan of Delphi. Then, consider a little activism of your own as you draft a comment to the US Treasury Department on their onerous proposal for Crypto Broker Reporting Regulations:

---

Disclaimers!