DEV Community: Dmitry Zakharov

How to Add a New Pool to Uniswap V3

Dmitry Zakharov — Sat, 23 Sep 2023 13:36:31 +0000

Intro

Many existing projects use the third version of a well-known Uniswap protocol as Oracle to get the current price for many assets. Uniswap V3 can also be used in one of the strategies like yearn or harvest strategies as a pool of liquidity, which can create profits for your deposit through time. Some projects also add integration with Uniswap V3 to increase user experience and make users' lives a little bit easier. In all of these scenarios, it is crucial to check how the poisoned pool, which can be added by a hacker to uniswap can affect the protocol. To check this scenario, we create a test in the hardhat environment.

Adding liquidity pool to UniswapV3

The code snippet in the hardhat testing environment is presented below. All necessary notes to the code are given as well.

const tokenFactory = await ethers.getContractFactory("EvilToken");
const evilToken = await tokenFactory.connect(deployer).deploy();
const positionManager = await ethers.getContractAt('INonfungiblePositionManager', "0xC36442b4a4522E871399CD717aBDD847Ab11FE88");
const WETH = await ethers.getContractAt('IWETH', addresses.tokens.WETH);
// call approve for tokens before adding a new pool
call approveawait WETH.connect(deployer).approve(positionManager.address, ethers.utils.parseEther('0.1'), {gasPrice: 0});
await evilToken.connect(deployer).approve(positionManager.address, ethers.utils.parseEther('100'), {gasPrice: 0});
let multiCallParams = [
// first call
"0x13ead562" + // encoded function signature ( createAndInitializePoolIfNecessary(address, address, uint24, uint160) )
"000000000000000000000000" + evilToken.address.toLowerCase().substring(2) + // token1 address
"000000000000000000000000" +  WETH.address.toLowerCase().substring(2) + // token2 address
"00000000000000000000000000000000000000000000000000000000000001f4" + // fee
"000000000000000000000000000000000000000005b96aabfac7cdc4b3b58fc2", // sqrtPriceX96
// second call
"0x88316456" + // encoded function signature ( mint((address,address,uint24,int24,int24,uint256,uint256,uint256,uint256,address,uint256)) )
"000000000000000000000000" + evilToken.address.toLowerCase().substring(2) + // token1 address
"000000000000000000000000" +  WETH.address.toLowerCase().substring(2) + // token2 address
"00000000000000000000000000000000000000000000000000000000000001f4" + // fee
"fffffffffffffffffffffffffffffffffffffffffffffffffffffffffff89f0e" + // tick lower
"0000000000000000000000000000000000000000000000000000000000010dd8" + // tick upper
"00000000000000000000000000000000000000000000000ad5a4b6712c4647c3" + // amount 1 desired
"000000000000000000000000000000000000000000000000016345785d8a0000" + // amount 2 desired
"00000000000000000000000000000000000000000000000acebaf563cd50439c" + // min amount 1 expected
"000000000000000000000000000000000000000000000000016261cfc3291456" + // min amount 2 expected 
"000000000000000000000000" + signer3.address.toLowerCase().substring(2) + // deployer address "00000000000000000000000000000000000000000000000000000000610bb8b6" // deadline
];
// adding a new liquidity pool through the position manager
await positionManager.connect(deployer).multicall(multiCallParams, {gasPrice: 0});

In this test, EvilToken is a standard ERC20 token that can be minted or burned by the deployer, positionManager is one of Uniswap V3 ecosystem's smart contracts which gives access to adding new pools of liquidity, WETH is a token representing wrapped ether. multiCallParams is an array of bytes which contains all necessary parameters to deploy a new liquidity pool. It is worth saying that some of the parameters used in multiCallParams cannot be easily calculated, like sqrtPriceX96 or tick_lower. To calculate these parameters, you can use a Uniswap V3 dApp in the ropsten network. It is very easy to calculate these parameters through dApp. First, you create a new liquidity pool in dApp with parameters that you want to use, and then you just decompile your transaction in ropsten etherscan and get values of the necessary parameters in byte representation.

How to Change the Bytecode of an Already Deployed Smart Contract

Dmitry Zakharov — Sat, 23 Sep 2023 13:25:09 +0000

Intro

Developing smart contracts with the Solidity or Vyper programming language always leads to creating some tests in a special environment. Currently, in order to deploy newly created smart contracts in testnet several tools exist, the most popular of which are hardhat, Ape, Boa, and foundry. In this note, we will discuss how you can change the bytecode of a smart contract already deployed on mainnet and, therefore in testnet. This can be useful if you want to change some logic for test purposes or if you want to change prices in oracles, as in a case that will be discussed below.

Updating bytecode of an already deployed smart contract

To prepare these tests, we used this article as an example. First of all, you need to install hardhat > 2.4.0 via npm or yarn. Next, you must add a copy of the smart contract code you want to change in your project repo. A little tip before we start discussing the code: if you use blockGasLimit in hardhat config, you must tune it right so that tests would execute (in our case, we simply removed this parameter from config). Add all necessary changes to this code and deploy it to testnet via ethers.getContractFactory() like this:

const oracles = await ethers.getContractFactory("AaveOracle");
const oracle = await oracles.deploy(
      ["0x6B175474E89094C44Da98b954EedeAC495271d0F"], 
      ["0x773616E4d11A78F511299002da57A0a94577F1f4"], 
      "0x5B09E578cfEAa23F1b11127A658855434e4F3e09", 
      WETH.address,
    );

In the code above, we have AaveOracle, which contains all code from Aave Oracle with small additions, and WETH.address, which is simply a string with wrapped ETH in Ethereum mainnet (0xC02aaA39b223FE8D0A0e5C4F27eAD9083C756Cc2). The first parameter in the deploy function is an array of assets, which is used in oracle (in our case, it is an array of 1 asset == DAI address 0x6B175474E89094C44Da98b954EedeAC495271d0F). The second parameter is an array of data feeds (in our case, it is chainlink's data feed for DAI/ETH 0x773616E4d11A78F511299002da57A0a94577F1f4). The third parameter is a fallback oracle (in our case, it is simply Aave fallback oracle 0x5B09E578cfEAa23F1b11127A658855434e4F3e09). After all these steps are taken, you can use the hardhat function eth_getCode() to get the bytecode of your newly deployed smart contract, and after that, you must use eth_setCode() to add this code to the contract address in testnet:

const code = await hre.network.provider.send("eth_getCode", [
        oracle.address,
    ]);
await hre.network.provider.send("hardhat_setCode", [
      "0xA50ba011c48153De246E5192C8f9258A2ba79Ca9",
      code,
    ]);

In the code above, we get the bytecode of our deployed contract and set it to Aave Oracle, which has the address 0xA50ba011c48153De246E5192C8f9258A2ba79Ca9.

How to Fork Mainnet for Testing

Dmitry Zakharov — Sat, 23 Sep 2023 13:09:24 +0000

Intro

One of the most exciting features of DeFi is interoperability, which allows constructing protocols using deployed smart contracts as base blocks for your protocol (e.g., Yearn Strategies). As a matter of fact, interoperability is one of the reasons why DeFi protocols are referred to as legos. Just like Lego blocks, you have to find the right way to fit two DeFi protocols together for specific use cases.
Developers have two options for testing smart contracts that integrate with at least one existing protocol: creating a mock that implements all necessary functions of an already deployed smart contract or using mainnet forking for tests. Mocks can mask very dangerous problems because they usually copy only the needed function from real contracts, which can lead to incorrect mock work. That's why we strongly recommend using mocks only if it is crucial. In all other cases, you can use mainnet forking.

Mainnet forking in hardhat

In this article, we will discuss how to set up your hardhat project for mainnet forking. First of all, you must have an Infura or Alchemy API key to use a RPC node to fork the state of the specific block. After getting an API key from one of the RPC providers, you need to change your config file like this:

const CHAIN_IDS = {
  hardhat: 31337, // chain ID for hardhat testing
};
module.exports = {
  networks: {
    hardhat: {
      chainId: CHAIN_IDS.hardhat,
      forking: {
        // Using Alchemy
        url: `https://eth-mainnet.alchemyapi.io/v2/${ALCHEMY_KEY}`, // url to RPC node, ${ALCHEMY_KEY} - must be your API key
        // Using Infura
        // url: `https://mainnet.infura.io/v3/${INFURA_KEY}`, // ${INFURA_KEY} - must be your API key
        blockNumber: 12821000, // a specific block number with which you want to work
      },
    },
    ... // you can also add more necessary information to your config
  }
}

After adding this to your hardhat.config.js file, you can use all necessary information from the specific block. For example, you can impersonate an address and use some tokens from a random address to test your function (it is very useful when you need a rare NFT to test one of your functions), or you can call any function from any contract only by adding a needed interface to your project. Some tips for working with a mainnet fork in a hardhat test are presented in the example below.

// Function which allows to convert any address to the signer, which can sign transactions in a test
const impersonateAddress = async (address) => {
  const hre = require('hardhat');
  await hre.network.provider.request({
    method: 'hardhat_impersonateAccount',
    params: [address],
  });
  const signer = await ethers.provider.getSigner(address);
  signer.address = signer._address;
  return signer;
};
// Function to increase time in mainnet fork
async function increaseTime(value) {
  if (!ethers.BigNumber.isBigNumber(value)) {
    value = ethers.BigNumber.from(value);
  }
  await ethers.provider.send('evm_increaseTime', [value.toNumber()]);
  await ethers.provider.send('evm_mine');
}
// Construction to get any contract as an object by its interface and address in blockchain
// It is necessary to note that you must add an interface to your project
const WETH = await ethers.getContractAt('IWETH', wethAddress);

Account Abstraction. Auditor's View

Dmitry Zakharov — Sat, 23 Sep 2023 12:42:46 +0000

Introduction

EIP-4337 offers a unique approach to Account Abstraction, effectively bypassing the need for alterations to the consensus layer. The architecture of EIP-4337 mirrors the transactions mempool functionality within a high-level system, giving the way for a more flexible and dynamic processing model. The central actors in this system are the users and the Bundlers that operate through a specialized p2p network of clients with implemented UserOperationPool.
In this setup, users send UserOperation objects to UserOperationPool. Acting as transaction builders, Bundlers listen in this mempool and combine UserOperation objects into a single bundle transaction, which is then sent to the EntryPoint smart contract. This EntryPoint smart contract serves as a processing hub, executing the UserOperation objects and deploying custom Account smart contracts implementing a specified interface.
The deployed Account smart contracts have a role that extends beyond merely the storage of assets. They handle nonces and signature validation, presenting opportunities for using custom logic in the operations process and the utilization of assets. Further enhancing the versatility of EIP-4337, the protocol enables the use of specific Paymaster actors to handle gas payments in inner transaction execution. This addition allows for customizing gas payment methods based on various conditions, such as payment in ERC-20 tokens to the Paymaster.
The overall architecture and logic of EIP-4337 have been detailed in the proposal by Vitalik Buterin et al.

Possible Ways of Integration

Integration of paymasters

The first and main part of ERC-4337 that can be used in some DeFi projects is the integrated paymaster taking care of a gas cost. It can use another way to cover gas costs (like ERC-20 tokens) or just sponsor gas prices to make the protocol more attractive.
All protocols trying to integrate a paymaster should consider DOS. If someone finds a way to sponsor their transaction without fair compensation, they can drain the paymaster’s stake. Let's assume some new ERC-20 token compensates the gas cost for any transfer. This can be exploited by an attacker transferring tokens back and forth: the paymaster will be quickly left without funds.
The paymaster can be used by DEXes (like Uniswap) to exchange ERC-20 tokens without having native tokens. If token A is exchanged for token B, the amount of A for the exchange can be decreased to the gas cost equivalent. Furthermore, ERC-20 tokens can be exchanged for wrapped native tokens immediately unwrapped and sent to the user’s account.
The important moment of such a use case is slippage. The minimum amount of B should be calculated considering gas price compensation. Incorrectly modified slippage will lead to a constant revert or can be used by MEV-bots to steal some of a user's funds.
NTF markets (like OpenSea) can give the ability to artists to mint NFTs without having native tokens. An artist or institution can pay with a bank card officially to a marketplace. After that, the protocol whitelists users in paymaster, allowing them to deploy a collection without diving into crypto, just through UI. Markets can even sponsor gas payments to help some cultural institutions or to attract more well-known artists.

Regular operations

Recurrent operations and subscriptions are other features of ERC-4337 that can add new functionalities to a DeFi project. Of course, such ability should be supported by an abstract account realization: wallet contracts should be able to validate such kind of UserOperations.
Regular investments can be used in Aave, Compound, and other lending platforms. Users may set some monthly transfer of funds to the protocol. Tokens will be constantly lent, giving profit and improving the health factor of users' debt. It’s also possible to auto-approve some money if the health factor becomes lower than some value.
It’s also possible to add a setting of orders in DEXes or other trading platforms without a preliminary funds transfer from the user's balance. Users can set some conditions when approval for some ERC-20 token is given. So, the order will be executed by trading protocol only if these conditions are met, and the user has enough balance.
It’s important to pay maximum attention to details of such regular or triggered approvals (approved amount, who can transfer tokens, and periodicity of auto-approval). It’s both the responsibility of a protocol owner and a user.

Limitations

Despite its revolutionary approach to Ethereum account management, EIP-4337 still encounters several inherent limitations. These constraints stem from various factors such as potential griefing and DoS attacks, the necessity for an isolated validation process of UserOperations, and the decentralized nature of the overall system:

Gas Constraints in Validation Process: The design of EIP-4337 imposes limitations on the validation process. To safeguard against excessive gas consumption and potential griefing, high-cost validation algorithms cannot be implemented into Account smart contracts. Bundlers are allowed to exclude UserOperation objects from a bundle if the gas limit parameter for the validation process is set too high.
Independence of the Validation Process: The validation process for Accounts and Paymasters grouped into a single bundle must remain independent, implying that they cannot call Accounts associated with other UserOperations or access the same storage slots. This restriction ensures that the consistency of validation does not depend on the order of UserOperation objects within the bundle transaction. Consequently, the usage of BeaconProxy is limited, and Accounts linked to the same Beacon cannot be included in one bundle.
Restrictions on Storage Access: Accounts and Paymasters can only read the storage slots associated with their address. To reduce the possibility of DoS and griefing attacks, a staking mechanism has been introduced. If the Paymaster validation process accesses storage associated with other addresses, it must stake a specified amount of assets. This stake can be unstaked anytime after a fixed delay.
Whitelisting of the Paymasters: The client implements a Throttle and Ban mechanism to determine Paymasters whose validation processes fail after being included into the bundle. In simpler terms, this targets Paymasters with inconsistent validation functions. If a Paymaster repeatedly fails after being included in the bundle (more frequently than a predefined parameter of client or Bundler), the Bundler may decrease the priority of operation or even ban operations that employ this Paymaster for a period of time.
Delay between UserOperationPool and Chain Mempool: The UserOperation object is included in UserOperationPool before it's added within the bundle transaction to the chain mempool. It means that between sending the operation to the mempool and including the related bundle transaction in the block, a significant amount of time can pass. To mitigate late operation processing, the Account validation function returns a validUntil parameter, enabling Bundlers to avoid using outdated UserOperation objects.
Opcode Restrictions: EIP-4337 requires the validation processes to be independent of block and transaction states to maintain consistency between validation simulation and execution of the bundle transaction. This restriction mandates Bundlers to ensure that validateUserOp method of Accounts and validatePaymasterUserOp of Paymasters don't use specific opcodes (GASPRICE, GASLIMIT, DIFFICULTY, TIMESTAMP, BASEFEE, BLOCKHASH, NUMBER, SELFBALANCE, BALANCE, ORIGIN, GAS, CREATE, CREATE2, COINBASE, SELFDESTRUCT). Exceptions are made for GAS if followed by one of the call opcodes.
Deployment Costs: Every Account smart contract must be deployed before utilization. If extrapolated to millions of Accounts, the deployment costs could be significant. However, these costs can be mitigated through EIP-1167 (minimal proxy contract), which facilitates cheaper contract creation costs.
Replication Attack Defense: To defend from replication attacks, EIP-4337 requires that UserOperation validation depend on chainId, nonce, and msg.sender (which is the EntryPoint smart contract).

Security Risks

The implementation of EIP-4337 brings several risks to the forefront. These risks relate to the potential vulnerabilities in custom signature verification methods in Account smart contracts, the potential of griefing, constraints on integration with certain projects, and the crucial need for comprehensive auditing:

Custom Signature Verification Risks: The ability for Account smart contracts under EIP-4337 to employ custom signature verification can potentially introduce security vulnerabilities. These custom verification methods may be less secure than the standard ECDSA algorithm on the secp256k1 curve used for transaction signatures in Ethereum, leading to increased vulnerability risks.
Griefing: Despite precautions, the potential griefing persists in EIP-4337. For instance, a malicious actor could frontrun the bundle transaction, changing the state of multiple Accounts and causing the validation process to fail after consuming a significant amount of gas.
Project Integration Constraints: The structure of EIP-4337, where each Account is a smart contract, imposes integration constraints with projects using the isContract() modifier. This restriction essentially prohibits anything other than EOA message senders from using these projects.
Necessity for Auditing: Given potential security vulnerabilities in the Account and the Paymaster, it's imperative that they are rigorously audited to ensure the overall system's security.
Bundler's Extracted Value: Bundlers can replay the operations of users included in the UserOperationPool, potentially frontrunning arbitrage opportunities. This risk can be mitigated by implementing the client as a trusted third party, much like the FlashBots project does, thereby guaranteeing the security of operations for both users and Bundlers or direct block producers.

Conclusion

EIP-4337 offers a groundbreaking approach to Ethereum transaction management, offering flexibility in handling assets and gas payments. Some applications of ERC-4337 can make existing DeFi protocols more convenient and flexible. However, its implementation must be considered with a clear understanding of the inherent limitations and risks. A thoughtful balance between taking advantage of this innovative protocol and ensuring comprehensive security measures can make EIP-4337 a significant milestone in the Ethereum ecosystem.