ENGINEERING BLOG SERIES
Can Upgradeable smart contracts be considered decentralized?
Blockchain and Ethereum are often thought of as decentralized, but recently there has been an increase in projects that seem centralized at first glance, using an architecture called the Proxy Pattern to make smart contracts upgradeable.
The larger and more complex a program becomes, the more it needs to be upgradeable in terms of bug fixes and feature additions, but it also seems to be moving away from a decentralized implementation.
I examined the architecture of Aave, Compound, and Uniswap, the leading DeFi (decentralized finance) providers, to see what kind of architecture they use to make their smart contracts upgradeable, and how they balance decentralization. I would like to examine whether Upgradeable smart contracts can be said to be decentralized or not.
What is Upgradeable?
First of all, as a basic rule, smart contracts cannot be updated once deployed on Ethereum. However, it is possible to create smart contracts with apparently upgradeable behavior by introducing an architecture called the Proxy Pattern.
The Proxy Pattern is a pattern in which a proxy contract exists between the main implementation contract and the user. The user accesses the Proxy contract, and the Proxy contract forwards the transaction to the main implementation contract that contains the logic. In this implementation pattern, the Proxy contract remains unchanged and always has the same address, but the implementation contract that the Proxy contract refers to can be changed to another implementation contract, so that the overall contract can be considered to be Upgradeable. This makes it possible to regard the contract as an Upgradeable contract as a whole.
In addition, the Proxy Pattern uses the delegatecall mechanism, so that the data is stored in the Proxy contract and the logic executed is the implementation contract’s methods, so the contract does not lose data even if the referenced implementation contract is changed.
Upgradability of Aave
First, let’s investigate Aave.
There are several types of Proxy patterns, and Aave uses the Transparent Proxy pattern. The characteristic of this pattern is that the Proxy contract has an update function for the implemented contract. Since the Proxy contract itself is not upgradeable, the contract update process itself is not deleted when the contract is updated.
Therefore, once a contract is deployed with this pattern, the deployed contract will remain Upgradeable.
Let’s look at the actual contract. Aave uses Openzeppelin to implement Proxy contracts.
https://github.com/aave/aave-v3-core/blob/master/contracts/protocol/libraries/aave-upgradeability/BaseImmutableAdminUpgradeabilityProxy.sol
The Proxy contract has an upgradeTo function that updates the address of the implementing contract, and it is clear that only Admin can execute this function.
Next, let’s check out Aave’s Admin. In Aave, there is a contract called LendingPoolAddressesProvider.sol that manages the deployment of the Proxy contract and updates the implementation. (In v3, it is PoolAddressesProvider.sol)
The Admin of the contract deployed by this contract is the address of this contract itself. In other words, the Admin of the main implementation of Aave, such as the Pool contract, is called LeadingPoolAddressesProvider.sol.
In addition, only the contract owner can execute the methods for deploying and updating the implementation of the LendingPoolAddressesProvider.sol. If you check the actual deployed contract below, you will see that this contract owner is the AaveGovernanceV2.sol contract.
https://etherscan.io/address/0xb53c1a33016b2dc2ff3653530bff1848a515c8c5#readContract
This AaveGovernanceV2.sol manages voting and proposals with governance tokens and manages the update flow. The specific flow is as follows:
- Registration of proposals
- Exercise of voting rights
- Execution of the transaction
Even when updating a specific contract, the first step is a proposal vote.
In other words, although Aave contracts are upgradeable, they cannot be freely updated by the development team, and are managed by the community.
In summary, Aave is decentralized through the use of governance tokens.
Upgradability of Compound
Next, I investigate Compound.
Compound does not use common Proxy patterns such as Transparent Proxy or UUPS Proxy, but uses its own contract called Unitroller.sol, which is responsible for the main processing of Compound and Comptroller.sol, which is responsible for the main processing of Compound, is made Upgradeable by it.
First, let’s look at Unitroller.sol.
https://github.com/compound-finance/compound-protocol/blob/master/contracts/Unitroller.sol
The contract has a function called _setPendingImplementation and a function called _acceptImplementation.
Contract updates are performed using these functions as follows
- Call the _setPendingImplementation function to register the address of the new implementation contract.
- Call the _acceptImplementation function to update Comptroller.sol with the implementation contract registered in step 1 above.
One characteristic here is that the _acceptImplementation function is called by Comptroller.sol, which is an implemented contract. This means that the contract updating process exists in the contract to be updated, so the contract updating process is also subject to Upgradeable.
Therefore, in the future, it is possible to remove the process of updating the contract when updating the implemented contract, and make oneself a non-Upgradeable contract.
As a result, this unique implementation of Compound has the same characteristics as the UUPS Proxy Pattern shown in the figure below.
Next, let’s investigate the Admin that can execute the _setPendingImplementation function. Checking Comptroller.sol in Etherscan, you will see that the Admin is a contract called Timelock.sol.
https://etherscan.io/address/0x3d9819210A31b4961b30EF54bE2aeD79B9c9Cd3B#readContract
Timelock.sol is a contract that queues, manages, and executes changes proposed or approved by the Governance.sol contract.
Therefore, while the current Compound contract is Upgradeable, the flow of updates is managed by Governance.sol, which, like Aave, seems to have decentralized authority through governance tokens.
Upgradability of Uniswap
Finally, I investigate Uniswap.
Uiswap has a governance token called UNI.
This governance token uses contracts such as Timelock.sol and Governance.sol, which were forked from Compound, so the management authority is decentralized using the same architecture as Compound.
https://github.com/Uniswap/governance
However, the Uniswap contracts themselves are not upgradeable like Aave or Compound, and even with decentralized administrative privileges, only limited configuration changes, such as fee settings, can be made. This means that bug fixes and functionality cannot be added later.
For this reason, Uniswap has been deployed as separate contracts (V1, V2, V3) each time a major contract update is made.
From the reasons above, it can be said that Uniswap contracts are completely decentralized applications because they are not upgradable and their privileges are also decentralized with governance tokens.
Conclusion
Aave, Compound, and Uniswap all have one thing in common: their management authority is decentralized through governance tokens.
If the administration authority is decentralized, even if a contract is upgradable, it can be said that even an upgradable contract is decentralized because it is fully guaranteed programmatically that the contract will be updated only by a proposal and vote by the community, even if the contract is upgradable.
Conversely, even if the contract is not Upgradable, if the administration authority is not decentralized, the contract may not be decentralized because the administrator can execute anything, depending on the implementation.
For example, in a BCG (blockchain game), it may not be decentralized because the administrator has strong authority to adjust parameters, mint items, etc.
In conclusion,
Q: Can Upgradeable smart contracts be said to be decentralized?
A: Yes, if the management rights are decentralized, such as by means of governance tokens.
However, in the blockchain world, it is always “Don’t Trust. Verify”.
Please do not trust this article, but check the actual contract by yourself and “Don’t Trust. Verify”.
Aave: https://github.com/aave
Compound: https://github.com/compound-finance
Uniswap: https://github.com/Uniswap
