ProxyFactory, ProxyAdmin, Implementation Contracts, And Library Events

To whom it may concern (let’s be honest, it’s going to be Andrew @abcoathup),

I trust that you are well.

As you may recall, I’m working with the OpenZeppelin proxy contracts at the moment. I have a few questions:

  • This one is more of a sanity check on the ProxyFactory. As the proxy contract that the factory will deploy is imported into the ProxyFactory contract and then the whole thing is deployed, that means that there is no way to modify the deployable proxy contract, right? I’d just have to create and deploy a new ProxyFactory with a modified deployable proxy contract imported.

  • In the ProxyAdmin contract, there are functions that accept a proxy contract entity as a parameter. For example,

function getProxyImplementation(AdminUpgradeabilityProxy proxy) public view returns (address)

AdminUpgradeabilityProxy is imported into the ProxyAdmin contract.

How do you pass a contract as an argument from a contract? From web3.js?

I assume that from a contract, you would need to import AdminUpgradeabilityProxy and then deploy it. You then access the address for the new contract and assign that address to the AdminUpgradeabilityProxy object. And then call the getProxyImplementation function with that object. Is that right? Or do you just need an address?

From web3.js would you need an ABI json file?

  • Is an implementation (logic) contract a library? Does it have to be?

  • How do use events with libraries? I’ve seen references to defining the event in both the library and calling contract. Would you call the library with a delegatecall within a function in the contract which includes the desired event emission? What is the deal with including an event in both the library and calling contract?

I appreciate any advice or help you can offer. Cheers.


1 Like

Hi @cjd9s,

Sorry for the delay, I thought I had seen another post from you but I didn't have this post in my todo list and have only come across it now.

You could probably make your factory contract upgradeable but for simplicity it is easier to deploy a new factory. The proxy contract is unlikely to change.

You can pass the address of the contract. If you ever need an example of how to do something, I recommend having a look at the tests for OpenZeppelin Contracts:

I am not sure what you mean. An implementation contract needs to be a contract.

Are you referring to a specific library? Are the library functions inlined or is the library deployed separately. Is this related to your questions on proxies (otherwise a separate topic would be great)? Your knowledge on libraries and events sounds further along than mine.

Hi Andrew @abcoathup.

I appreciate the advice.

Yes, you’re probably right that I could make the deployable proxy contract itself upgradeable, but I’m not going to worry about that for now.

Yes, of course, the address. That makes sense. Also, looking at the tests is a good idea for seeing how things work.

As for the implementation contract, I mean does the keyword defining the contract need to be ‘contract’ or ‘library’. i.e. library SafeMath {} or contract SafeMath{}. Or could it be either?

I’m not referring to a specific library. Rather, I’m thinking about if my implementation contract is a library per the above. So the library would be deployed separately. So, my concern is emitting events when a proxy state contract delegatecalls a function from the library. I’ll see if I can learn a bit more and pass back an explanation. Cheers.


1 Like

Hi @cjd9s,

I would recommend trying to keep things simple if you can. Why do you need an external library? If you are after gas saving, would minimal proxy contracts be a better way to go.

I couldn’t see anything in the documentation about emitting events from a library.

I found an older article which describes the issue of emitting events from a library (though thinking out loud, I wonder if you could declare in an interface shared by both contract and library)

Hi Andrew @abcoathup,

I appreciate the response.

The external library is the deployed implementation contract. That’s why I was asking whether the implementation contract can be a library or normal contract in my previous post. I need an implemenation contract in the proxy architecture. In fact, I need to two; one for the contract factory logic and one for the election logic.

Unfortunately, I can’t use mininmal proxy contracts for the election state proxy contracts. Each proxy contract will also hold the election state. So, I need more than a proxy contract that forwards to the implemenation contract.

I appreciate the article. It covers some topics in which I’m interested. Unfortunately, it seems to be discussing libraries that are imported, but not inherited, into a contract and not previously deployed. Still, good info, so thanks. Cheers.


1 Like