Currently, I am working on EVM-compatible custom blockchain project, which has almost the same JSON RPC endpoints with
Unfortunately, ZeppelinOS not working on that custom chain because
Proxy class (in
ZWeb3.getStorageAt() to get
admin address and
implementation address, and this method uses
eth_getStorageAt JSON RPC internally - one that is not supported on custom chain.
From my understanding,
Proxy class represents
AdminUpgradeabilityProxy contract, which has
implementation() methods for exactly same purpose.
So here’s my question, why
Proxy class uses
getStorageAt(), not calls method of
Hello @bebeerd! Thanks for using ZeppelinOS! Hopefully you can find a way to make it work for your network.
As for your question, I’m not entirely sure, but maybe @spalladino would know!
Thanks for bringing this one up @IvanTheGreatDev, and welcome @bebeerd to the forum! The
Proxy class relies on getStorageAt since the
implementation are only callable from the proxy admin address (see here for more info on why this is necessary). If you try to call any of those methods from another account, the call will be proxied to the implementation contract, and will probably fail.
This could be patched by assuming that the proxy’s admin is never changed outside the zOS CLI, and forcing the
proxy.implementation() call to be made
from: adminAddress, but it is less robust than the current solution.
I’m curious though: which chain are you working with, that does not support this method?
Thanks for your quick response!
I thought that this behaviour is not intended that
implementation() is accessible only with
admin address as you said, and accessing it with
getStorageAt appears to me as something like a quick fix that will be rewritten - but forgotten… I feel this is not appropriate because this doesn’t follow design; this appears to me not necessary.
Anyway, If it was intended then it is ok, I can find a workaround
PS. @spalladino I’m not a member of that chain - I’m just using it - you can look into: https://loomx.io