Thoughts on EIP 1538?

It seems like the Upgrade pattern takes some pages out of this book here - what are your folk’s thoughts on this EIP for “transparent contracts”?

1 Like

Hi @realisation,

OpenZeppelin SDK uses the “unstructured storage” proxy pattern for upgradeability.

OpenZeppelin Labs included a number of experiments with upgradeability, one of which was vtable.

As per the draft, the inspiration for ERC1538 was OpenZeppelin Labs upgradeability_with_vtable.

The draft has comments from some of the OpenZeppelin team.
I suggest reading this comment in particular:

https://github.com/ethereum/EIPs/issues/1538#issuecomment-437918634
Hey @mudgen! Santiago from ZeppelinOS here. Just got the time to review the proposal. Looks pretty solid, and thanks a lot for picking up the vtable experiment and pushing it forward!!

FWIW, for the current version of ZeppelinOS, we decided to go with a more simple approach (a proxy that delegates to a single address) since it removes a few complications when coding upgradeable contracts (such as having to coordinate storage, or not being able to share internal functions). But we do envision supporting other upgradeability patterns in the future, and it’s nice to see the community pushing for alternatives :slight_smile:

An improvement I’d strongly suggest is using unstructured storage for storing the contract owner and the delegates. This removes the need for any implementation contract to extend from a UpgradeStorage base contract. From our experience, the fewer requirements you impose on your users, the better the chances for adoption.

As for allowing users to decide which version of each function they want to call (which was mentioned in the last comments), I’m not very sold on the idea to be honest: I feel it may open the door to certain incompatible calls in a wider system. I’d keep it simple for the time being, until we have a better understanding of this pattern.

Also, I’m not sure this implementation does prevent the selector clashing exploit, as was mentioned before. Registering a delegate which has a different function name but the same function identifier as updateContract may end up in accidentally removing upgradeability. I’d be particularly careful in protecting that function.

Last but not least, we have a clash on the naming itself! We are pushing for the transparent proxy naming from ZeppelinOS to describe proxies that are indistinguishable from the implementation for anyone but their owner. You can read more about that here, and we’ll be probably releasing a blogpost soon. I’d suggest renaming this proposal to something that better describes its main selling points, which to me are being able to upgrade functions individually, and having the proxy dispatch to the correct implementation. I personally like vtable , but that’s just because I came up with that name and are somewhat attached to it :stuck_out_tongue:

I moved to #general as assume this is more of a discussion.

1 Like

I also asked Nick Mudgen via Twitter if he is still working on this EIP:

1 Like