As the Aztec Labs team makes progress on developing the Aztec network and the number of teams and developers working on the network grows, it would be helpful to formalize the process about how ideas go from discussions to specifications. This would also be helpful for creating and maintaining the single source of truth for specs, community processes, and other Aztec standards, similar to how the EIP process does this for Ethereum.
Here is a proposal for that process. Feel free to comment directly in the document with questions or ideas or reply in this thread.
This proposal is heavily inspired by the EIP process used by Ethereum, but aims to be lighter-weight while the Aztec community is smaller and easier to coordinate. This process can be expanded upon and refined in the future–this is merely a starting point.
I don’t know a ton about Aztec or its governance, so treat this as an uninformed opinion, but one thing I’d recommend is not defaulting to adopt the EIP process wholesale. A lot of its quirks evolved from Ethereum-specific constraints. For example, does it make sense for your app-level standards to use the same process as protocol-level ones? Or, is this flow chart really what you want to start with
Obviously, you also don’t want to fully reinvent the wheel. It’s just worth taking the time to think about where the process maps the best and worst to your community/tech/etc. One example of a project who did a good job of “forking” EIPs and adapting them to their context recently is Farcaster.
Thanks for the feedback Tim, and the pointer to farcaster’s process.
I like how simple their process is:
Idea → Draft → Review → Finalized or Rejected
I actually really like the diagram we took from the EIP process, but I get your point that it covers cases that we haven’t run into yet, and probably want to come up with solutions specific to this network and community as we run into them.
Perhaps we start with a simpler process focused on protocol standards, since the execution environment is not yet set in stone. We can discuss/define the process for application level standards once we have an execution environment and decide if it makes sense to fold into the same process. @spalladino raised a similar point previously.
Right, I think that’s the core of it. I’m not saying our diagram is “bad”, but just that it evolved based on context-specific Ethereum L1 stuff that may or may not apply to Aztec.
Also, another big tension on the Ethereum side has been whether EIPs should serve only as a standardization process, or as a part of the network upgrade process itself. We still haven’t fully resolved that, see this repo for more context
[moving this to another reply due to the link limit]
Finally, on the purely spec level, Ethereum also is kind of a mess right now: there’s the (out of date) yellow paper, EIPs, python specs (canonical for CL, “new” for EL), and testing repos. I’ve written a bit about how I’d like it to evolve here (see “Post-Merge Upgrade Process ”).
I drafted a revised AZIP process, you can find it here.
It still significantly resembles EIP-1, but trims out much of the process and several of the categories. In the proposal, the overall format of an AZIP still closely resembles an EIP. The idea is that we can start with a simpler process with fewer categories and add more as needed.
The gist of the simplified process is that AZIPs will proceed through the following steps:
Idea → Draft → Review → Final
Ideas are discussed in this forum before being submitted as a PR to a Github repo where they may be merged in as Draft by an Editor. They will proceed through the process in the Github repo.
An AZIP may be moved to Cancelled at any point after it has been accepted as Draft. You can read more about the status terms here.
There are also fewer categories, namely Informational, Core and Standard AZIPs.
Barring any serious concerns about the revised process, I will create a Github repo for AZIPs and open a PR for the proposed process.
!
”).