EPIC Proposal (separation of contract interfaces)

[ligi]

This is a proposal to split the EIP process in Ethereum Proposals for Interfaces of Contracts that only specify contract interfaces (think ERC #20,ERC #721,ERC #801,..) and other EIPs (no change here).
This will have the following advantages:

1. easier to find and get an overview of all contract interfaces (my current pain point)
2. can be less opinionated than changes that might fork hard -> less governance pain
3. less noise when you want to keep up to date if you are just interested in contract interfaces (could improve interoperability between projects/contracts - not all contract devs can read all EIPs)
4. maybe less potential legal problems (but IANAL!) could also help getting very talented editors back on board that just have problems with certain kind of proposals (cc @pirapira)
5. less work for editors involved in this process
6. more decentralized in a sense
7. smaller numbers - easier to remember interface numbers - when being embedded in EIP process we get into 4 digits soon
8. easier to require formal defaults like methods and events

To decease mental workload requirements for the transition we could use the old numbers - but fill the gaps (see point 7)

ERC-20 -> EPIC-20
ERC-721 -> EPIC-721
ERC-801 -> EPIC-801

Opinions and links to EIPs that could become EPIC very welcome! Was on the search for EIPs that define contract interfaces and this is possible but painful manual work - one reason for this very proposal.

[benjaminion]

Excellent idea, but might need a rename: https://github.com/ethereumproject/ECIPs

[ligi]

thanks - not sure if a rename is needed - different namespace here and collisions in 3LA/4LA are not too uncommon - by the rate 3LA/4LAs are invented as symbols for ICOs we would not have much left soon ;-)

[tmke8]

Why not split the process along the already existing axis of EIP vs ERC. EIPs would be for core protocol improvements and ERCs for everything else that developers should agree on (like contract interfaces). Separating ERCs from EIPs seems like a good idea in general.

[ligi]

would also work - but you would not get (8) and a bit less of the other advantages as this shard is a bit bigger. Also you do not get the epic name - just say ERC (sounds like someone puking) - vs ECIP ;-)

[aribo]

What about calling it EPIC (Ethereum Proposal for Interface of Contracts)?

Long name is more of a mouthful, but totally compensated by the really epic acronym. And it avoids the confusion with Ethereum Classic ECIPs.

I like the idea of the separation. It would facilitate the discussion of more fundamental issues (hard fork) and make possible two different processes/mechanisms for reaching consensus.

[Arachnid]

I agree that proposing changes to the network and proposing protocols that run on the network are different things; I'm not sure if they're different enough to warrant entirely separate systems or not.

If we do separate things, though, we should use the opportunity to sit down and reconsider the whole process on both sides.

[ligi]

If we do separate things, though, we should use the opportunity to sit down and reconsider the whole process on both sides.

Not sure about this - trying to combine actions like this can lead to not doing them. That said - we can start the ECIP process with new parameters and reconsider the process this way. If they work out in ECIP then we can apply them to EIP later in any case.

[Arachnid]

Why not call them ERCs? That's already the term for EIPs that don't modify consensus.

[ligi]

I think ERCs are intended to be broader than I would like ECIPs to be. The scope of ECIPs could be that the need to be able to have a #881 interfaceID (meaning has smart contract methods) - as far as I understand the scope of ERCs this would not be the case there.

[Arachnid]

Is there a reason for a separate process for EIPS-about-smart-contract-interfaces and other EIPs? It seems to me that both would need the same sort of process.

[veox]

Why not call them ERCs? That's already the term for EIPs that don't modify consensus.

One (weak) reason: "rebooting" the numbering.

Currently, still - and in conflict with EIP-1 - ERCs and other EIPs tend to get a number assigned ad-hoc, commonly using the number of a github issue that a PR closes. This creates gaps in the numbering, as well as draws from the same number pool. (I hoped this would be remedied by a more strict adherence to the merge-as-draft workflow.)

On this point, I disagree with leaving "already accepted" ERCs' numbers as-is:

7. smaller numbers - easier to remember interface numbers - when being embedded in EIP process we get into 4 digits soon
   (...)

To decease mental workload requirements for the transition we could use the old numbers - but fill the gaps (see point 7)

ERC-20 -> ECIP-20
(...)

The confusion caused by renaming ERC-20 to EPIC-2 is momentary: i.e., experienced by current developers only (which are not that numerous).

The confusion caused by EPIC-721 having been proposed/draft-merged years before EPIC-720 will be permanent: experienced by current and future developers, forever.

---

Is there a reason for a separate process for EIPS-about-smart-contract-interfaces and other EIPs? It seems to me that both would need the same sort of process.

Yes; however, with different processes we could also achieve separation of concerns (which, as I understand, this issue is about; is it?..).

Some people are mostly interested in the application layer: the Turing-friendly machine that we run on our Turing-complete^1 machines.

It may not strictly be the business of one machine's engineers to have decision power over the other one. Perhaps also an increased S/N ratio.

For EPICs, it might well be that competing/conflicting approaches go through the full cycle from draft to obsolete, all without danger of network-wide consensus failure (or the like). This often can't be said about those-other-EIPs.

Counter-argument: segregation promotes (self-)disempowerment, and eases the formation of cabals. Such categorisation may start out as "separation of concerns", and soon become a barrier.

---

It might be that I'm playing devil's advocate above.

---

^1: (sans infinite tape)

[veox]

@ligi:

Excellent idea, but might need a rename: https://github.com/ethereumproject/ECIPs

thanks - not sure if a rename is needed - different namespace here and collisions in 3LA/4LA are not too uncommon - by the rate 3LA/4LAs are invented as symbols for ICOs we would not have much left soon ;-)

IMO a search engine query for ethereum ecip <X> should not return results for two different proposals, in two similar projects.

(It likely wouldn't, by way of search engine filtering. Still, "query-bombing" is not nice.)

Besides, Ethereum Proposal for Improving Contracts isn't really that much of a mouthful; and EPIC is much easier to pronounce than ECIP.

---

EDIT: CLIP has also been proposed below, which might be even better for its IP suffix.

[ligi]

IMO a search engine query for ethereum ecip should not return results for two different proposals, in two similar projects.

Good argument i am happy with changing to EPIC - but for Ethereum Proposal for Interface of Contracts as @aribo suggested - not Ethereum Proposal for Improving Contracts as you just stated. I think the interface aspect is quite important. We need systems that interface well with each other IMHO.

[ligi]

just changed to EPIC as the argument of @veox convinced me and a lot of people like the name as it seems when looking at the emojis here: #896 (comment)

[maurelian]

I'd suggest Contract Layer Improvement Proposal. I think "contract layer" is appropriately general, and I like sticking with the xIP pattern that the community is familiar with.

I didn't realize this EIP existed, or I would have include ECIP and EPIC in this poll: https://twitter.com/maurelian_/status/968714675507679233

Lastly, I do have some concern that this divides protocol work from the contract too starkly. New opcodes and other protocol features that impact on the features available to contract authors are relevant to both.

[ligi]

I didn't realize this EIP existed, or I would have include ECIP and EPIC in this poll: https://twitter.com/maurelian_/status/968714675507679233

thanks - yea I need to sharpen my skills in getting ideas out so people are aware of them - trying my best - posted it on reddit, twitter and akasha - but seems I need to do more here ;-)
But I am also happy about CLIP - as you see above I am not that attached to the name - my main wish is that this monolith gets split to make thins more effective.

Lastly, I do have some concern that this divides protocol work from the contract too starkly. New opcodes and other protocol features that impact on the features available to contract authors are relevant to both.

Can you elaborate on your concerns here? As both processes should still be open the split does not hinder people to follow both. I do not yet see a drawback in splitting it.

EDIT: would also be interested in how you would scope CLIPs - I would love a scope that limits it to interfaces - means it needs to result in a #881 interface id

[maurelian]

It's not a well thought out concern, your point that people can follow both is a good one.

A similar concern though is related to moderation. I imagine that it would be more work for the moderators of this repo to moderate two very active _IP repos.

@Souptacular, how would you feel about it?

[jamesray1]

Alternatively you can just have a new label for EPIC, and then you can search via labels in the pull requests. For EIPs that are final and merged into the repo, you could have a sub-folder in the EIPs folder for EPIC. You would not be able to limit email notifications to EPIC with this method, however. But I don't think that is a big disadvantage. You could just have notifications set to watching or ignore and check in from time to time.

I think I would prefer this option as then all EIPs are in the one repo. Additionally splitting EPIC/CLIPs up into a separate repo would set a precedent that others may push for, then you get more fragmentation.

[ligi]

I think just labels would not get us all the advantages I listed in the initial post. I do not see the disadvantages in fragmentation here - would rather call it modularisation - has a better connotation ..-)

[Arachnid]

I'm more or less coming around to this idea (though personally I prefer SLIP over EPIC).

[hjorthjort]

Alternatively you can just have a new label for EPIC, and then you can search via labels in the pull requests. For EIPs that are final and merged into the repo, you could have a sub-folder in the EIPs folder for EPIC. You would not be able to limit email notifications to EPIC with this method, however. But I don't think that is a big disadvantage. You could just have notifications set to watching or ignore and check in from time to time.

I like this. It would be the first step of a migration anyway. We can start by labelling all the CLIPs/EPICs as such, ensure there is clear agreement on what falls into that category, and pick up the discussion from there. Such a labelling would be immediately value creating and non-invasive. It woul also clarify further discussion since we would know what number of EIPs we are talking about, their spread, etc.

Overall I'm very much in favor of splitting. The common interfaces that clients would want to implement and the protocol layer changes seem mostly separate.

Wrt numbering, why fill in the gaps? Keep counting from the highest number in each repo. It avoids the confusion of out-of-order CLIPs/EPICs, which I think is worse than the high numbers.

[JhonnyJason]

What is the current state on this one?

[MicahZoltu]

It comes up in the EIPIP meetings from time to time, but it currently isn't a priority.

[github-actions]

There has been no activity on this issue for two months. It will be closed in a week if no further activity occurs. If you would like to move this EIP forward, please respond to any outstanding feedback or add a comment indicating that you have addressed all required feedback and are ready for a review.

[github-actions]

This issue was closed due to inactivity. If you are still pursuing it, feel free to reopen it and respond to any feedback or request a review in a comment.