4

There are a number of design patterns for contracts that already exist on Ethereum. For upgradeable contracts, one of them is the use of a Proxy Delegate contract.

My understanding is that the Proxy Delegate contract offers a number of user facing entrypoints which are then forward to a contract address which holds the main logic, the Logic contract. The Logic contract address is stored in the Proxy Delegate's storage and can be changed by a manager to point to a new Logic contract when ready to upgrade. This seems like a pattern that Tezos can use.

Tezos also supports storing a lambda (or a function). Instead of creating a proxy contract, we can store the logic of the entrypoints in lambdas in the contracts storage and retrieve them for execution when the entrypoints are called. The manager can update the stored lambdas in order to upgrade the contract.

What are the pros and cons of each approach? Are there any other contract upgrade patterns on Tezos?

1

Another way is dependency injection: the upgradable contract takes as a parameter a contract address or a lambda that is called. The caller can thus "upgrade" the original contract by varying the supplied address / lambda. The pro is also the con of this approach: it allows the the contract client to interact with the contract in ways the contract author did not imagine.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.