Wondering if implementation() should also include a bytes calldata parameter in the event the proxy changes which implementation to use based on the input.

Maybe this isn't a good use case for this ERC though, most proxies are 1-1 (rather than 1-many).

That's a good point @sohkai, things like ether-router would need this to work.

I think we could make implementation() required and then implementationFor(bytes calldata) an optional function for proxies in which that is relevant.

This previous ERC is worth looking at for historical context: #121 Proxy Standard. Although, I think there is some need to disambiguate the term Proxy.

This ERC seems to be specifically about "proxies that delegate their own logic to another contract".

Whereas the uPort proxy is moreso a "proxy that forwards transactions and calls from any ethereum account".

Would it make sense to call this a "Contract Proxy" or "Computational Proxy"?

I agree with @maurelian - another example of a contract that is a "proxy", but would not fit the description of this interface is the 0x TokenTransferProxy.

Perhaps the standard interface could be named ERCDelegateProxy to convey to users that a contract implementing this interface is acting specifically as a proxy that delegates business logic to another contract while still using its own storage. Contract implementations of ERCDelegateProxy could be named ForwardingDelegateProxy (for proxies that always delegate to the same contract) and UpgradeableDelegateProxy (for proxies that can swap out the implementation contract that they delegate to).

I agree on the name change to DelegateProxy, that is how we call them internally for our own implementation. Regarding other proxy types like uPort's, I think it would be beneficial for those to have a more descriptive name such as AccountProxy.

I would consider defining an EIP820 Interface.
Using the EIP820 has the advantage that the proxy does not have to implement the ERCProxy code in the same proxy contract. This will save a lot of gas in proxies that share the same code and type, because the implementation of the interface can be done by a singleton contract shared by all the proxies of the same type.

@maurelian:

I think there is some need to disambiguate the term Proxy.

@zigguratt has called the particular kind discussed here a dispatcher.

I agree with @maurelian here (and thanks, @veox). There are a couple of different things that could be called proxies. That's exactly why I referred to my implementation as a dispatcher. At the same time, it has the ability to upgrade the contract that it represents.

The idea of swapping out a contract behind a dispatcher/proxy/delegate is a dangerous one. We discussed this at ConsenSys just a couple of day ago. My take on the subject was this (not including uPort's idea of a proxy):

So in the end a proxy or dispatcher should be almost a shield around the contract that it represents, somehow ensuring that if there are any changes made to its sub-contract the changes are clear and very public. But that doesn't stop anyone from using a very simple proxy that does none of that, and at some point swaps out its sub-contract with something nefarious.

This has been on my mind since I implemented my dispatcher. There's actually no way to stop someone from acting badly with a proxy. There would have to be some sort of EVM support, I suspect.

I would love to be proven wrong, believe me.

This is a courtesy notice to let you know that the format for EIPs has been modified slightly. If you want your draft merged, you will need to make some small changes to how your EIP is formatted:

• Frontmatter is now contained between lines with only a triple dash ('---')
• Headers in the frontmatter are now lowercase.

If your PR is editing an existing EIP rather than creating a new one, this has already been done for you, and you need only rebase your PR.

In addition, a continuous build has been setup, which will check your PR against the rules for EIP formatting automatically once you update your PR. This build ensures all required headers are present, as well as performing a number of other checks.

Please rebase your PR against the latest master, and edit your PR to use the above format for frontmatter. For convenience, here's a sample header you can copy and adapt:

---
eip: <num>
title: <title>
author: <author>
type: [Standards Track|Informational|Meta]
category: [Core|Networking|Interface|ERC] (for type: Standards Track only)
status: Draft
created: <date>
---

Your comment got somewhat lost and I just saw it. Thanks for the heads-up @Arachnid, it should be good now.

Is anything more required from us before it can be merged @Arachnid?

Hi Jorge(@izqui ), the new rule is pull request can't be the "discussions-to" destination, could you mind update EIP-897 to find an official home for its discussion, given it's still in draft status?

Hi. I'm searching ABI for the implementation contract at 0x4ef5123a30e4CFeC02B3E2F5Ce97F1328B29f7de

Goodnight,

I would like to assemble a team for projects to create cryptocurrencies, tokens and Blockchain and digital banking. Partners and Partners for the Project.

Shall we talk?

CONTACT US AT SINGULARITY ASI INSTAGRAM