Bin

Best Way to Deploy Contract on Multi Chains

bin-6@newsletter.paragraph.com (Bin) — Sun, 10 Nov 2024 12:02:55 GMT

How does you contract address comes from? What is the best way to deploy same address on different EVM chains?

Here is the answer:

Keyless + Factory

TL, DR

When the goal is to deploy your contracts to the same addresses on multiple blockchains, fewer factors affecting deployment addresses make it easier to achieve
Create is related to wallet address and nocne. Create2 is influenced by address of factory, salt, and bytecode. Create3 is affected by salt and factory address, not influenced by bytecode
Keyless does not need to maintain the wallet address of the deployment factory

Contract Creation

We have three ways to deploy contract, create and create2 are EVM codes and create3 is not.

Create

address = keccak256(rlp([sender_address,sender_nonce]))[12:]

address is determined by the sender and sender nonce.

And here is the opcode:

create(vaule,offset,size);

If want to keep addresses are same on different EVM chains, addresses should not be associated with nonce.

Create2

By create2, contract can be calculated:

address = keccak256(0xff + sender_address + salt + keccak256(initialisation_code))[12:]

sender_address is usually contract factory address.

So the contract is influenced by: address of factory, salt, and contract bytecode. It's possible to know the contract's address on blockchain before it's deployed.

opcode:

create2(vaule,offset,size,salt) => address //return address 0 if failed

In order to keep the addresses consistent, the fewer influencing factors, the better. So we want to get rid of the influence of bytecode.

Create3

CREATE3 is a way to use CREATE and CREATE2 in combination such that bytecode no longer affects the deployment address. Is not an EVM opcode.

Contract calculation depends on address of factory and salt.

How to achieve it?

address proxy;
/// @solidity memory-safe-assembly
assembly {
    // Deploy a new contract with our pre-made bytecode via CREATE2.
    // We start 32 bytes into the code to avoid copying the byte length.
    proxy := create2(0, add(proxyChildBytecode, 32), mload(proxyChildBytecode), salt)
}
require(proxy != address(0), "DEPLOYMENT_FAILED");

deployed = getDeployed(salt);
(bool success, ) = proxy.call{value: value}(creationCode);

Deploy a new contract with our pre-made bytecode via CREATE2, so we can ensure the factory contract
Deploy actually contract by the factory contract deployed via CREATE2, and the nonce is always 1.
(Notice: Factory nonce is 1 rather than 0 of EOA)

At this point, we can deploy the same contract address on different EVM chains, and the address is only affected by salt

Notice: The creation code is contract bytecode that you want to deploy. If you want to deploy an upgradable contract, the bytecode is ERC1967 Contract bytecode with its constructor:
abi.encodePacked(ERC1967bytecode + abi.encode())
Here initData is ERC1967 data. And if the contract is UUPS type, you have to call initialize() when deploying the contract. So the initData will be encoded by initialize()

Now here is another question: we still have to preserve the private key that controls the address safely. the EOA that deploys the factory. Is there a way that don't need to regardless of this?

Keyless

What is keyless address?

Keyless means no one owns the private key of the address.

Understanding transaction in Ethereum

We need to understand ethereum tx again. A simple ethereum tx format:

{
  nonce: "0x00",
  chainID:"1",
  gasPrice: "0x09184e72a000",
  gasLimit: "0x27100",
  to: "0x0000000000000000000000000000000000000000",
  value: "0x01",
  data: "0x7f7465737432000000000000000000000000000000000000000000000000000000600057",
  sig:{r,s,v}
}

Network using ecrecover function to get signer address and get gasFee

addressRecovered = ecrecover(Transaction, v, r, s);

Here is the point that it doesn't matter who forwards the transaction to network because the address executing the transaction is the one recovered from the transaction

Usage of Keyless

Even with the alteration of v, r, and s values to randomly generated values, the transaction will not be considered as “invalid”. It will still be executed successfully from the recovered address. The entire process of deploying a contract is:

Generate the tx by field with random value for r,s and data (bytecode of the factory cotract)
Recover the address by "ecrecover" and fund that address
Serialize and broadcast the transaction to the network. And can also get the address of contract that will be created
Deploy business contract by factory that deployed by keyless

By using this method, there is no need to safeguard a private key or need to be concerned about nonce. The nonce of keyless is always zero

Seaport contract (opensea contract) is deployed in this way.

https://github.com/ProjectOpenSea/seaport/blob/main/docs/Deployment.md

End. we can deploy the same contract address on different EVM chains, and the address is only affected by salt, and we don’t need to manage the private key of EOA that deploy the factory contract.

Just need to keep factory bytecode and salt is enough.

And here is the code example of factory deployment:

https://x.com/bloom_cry/status/1861602210964218131

Send me message to get the full code example of factory + keyless deployment!

Inflation Attack and Defense in ERC4626

bin-6@newsletter.paragraph.com (Bin) — Sun, 03 Nov 2024 06:48:54 GMT

Background

What is ERC4626?

ERC4626 is an extension of ERC20 that proposes a standard interface for token vaults, offering functionality for depositing, withdrawing tokens and reading balance.

contract ERC4626 is ERC20, IERC4626 {}

The main functions implemented are

Deposit assets(e.g. USDC) get shares token

function deposit(uint256 assets, address receiver) external returns (uint256 shares);
function mint(uint256 shares, address receiver) external returns (uint256 assets);

Redeem share token, get assets

function withdraw(uint256 assets, address receiver, address owner) external returns (uint256 shares);
function redeem(uint256 shares, address receiver, address owner) external returns (uint256 assets);

Share and amount conversion ratio

function convertToShares(uint256 assets) external view returns (uint256 shares);
function convertToAssets(uint256 shares) external view returns (uint256 assets);

There is a formula between share and amount:

$$\frac{share}{totalShare} = \frac{asset}{totalAsset}$$

Here share is user should get share amount, asset is the asset amount that user deposit or withdraw to the vault. Determine the ratio between asset and share.

Inflation Attack

Let's consider a scenario

Initially, totalAssets and totalShares are 0
The attacker deposits 1 token, gets the shareReceived = 1 (totalShares = 1 )
User plan to deposit 1000 tokens
The Attacker transfer 1000 tokens before user, changes the totalAssets to 1001
User deposit 1000 tokens, get the shareReceived = 1 * 1000 / 1001 = 0.999001 = 0 , vault state: totalAssets = 1001 + 1000 = 2001, totalShares = 1
The attack redeem 1 share to get 2001 tokens

How does this happen? Attacker can manipulate the denominator by increasing it, causing users to receive less share than expected since rounding down.

Let's analyze it according Inflation attack , Assuming

After donation of attack, that rate of this vault is

$$\frac{a_0}{a_0+a_1}$$

to dilute that deposit to 0 share, just need to ensure that

Using $$a_0$$is 1 and $$a_1$$is u is enough. So attacker only needs u+1 to perform attack

Defense Method

Ensure that the initial state is by owner

If the initial assets in the vault are not zero, the cost of attacker is expensive. Even without other defense methods, assume the owner deposits 1000 assets into the vault.

userShare = totalyShare(1000) * assetAmount(1000) / totalAsset(1000 + x)

attacker needs to make (x + 1000) greater than 10^6, so x = 10^-1000

Control totalAsset internal instead of balanceof()

Another reason for the success of the attack is that the attacker can transfer assets（donation） into the contract, thus diluting the share.

Keep track of assets held by the vault internally, rather than rely on the balanceOf function. This way, the donated assets cannot influence the vault's internal accounting.

Decimals offset approach used in YieldBox

YieldBox add a decimal offset in totalShare, means that 1 asset is not according to 1 share.

function _toShares(
    uint256 amount,
    uint256 totalShares_,
    uint256 totalAmount,
    bool roundUp
) internal pure returns (uint256 share) {
    // To prevent reseting the ratio due to withdrawal of all shares, we start with
    // 1 amount/1e8 shares already burned. This also starts with a 1 : 1e8 ratio which
    // functions like 8 decimal fixed point math. This prevents ratio attacks or inaccuracy
    // due to 'gifting' or rebasing tokens. (Up to a certain degree)
    totalAmount++;
    totalShares_ += 1e8;

    // Calculte the shares using te current amount to share ratio
    share = (amount * totalShares_) / totalAmount;

    // Default is to round down (Solidity), round up if required
    if (roundUp && (share * totalAmount) / totalShares_ < amount) {
        share++;
    }
}

Openzeppelin

Oz proposes defense based on YieldBox, It consists of two parts: virtual shares and decimals offset

The formula above becomes:

$$\frac{share}{totalShare + 10^{decimal}} = \frac{assetAmount}{totalAsset + 1}$$

Decimal means we can use more decimal places to represent the shares. e.g. Decimal is 3, 1 assets 对应1000 share
totalAsset + 1 instead of totalAsset means we give a virtual asset to the vault

And here is the implementation of openzeppelin after v4.9 according to the formula above

function _convertToShares(uint256 assets, Math.Rounding rounding) internal view virtual returns (uint256) {
    return assets.mulDiv(totalSupply() + 10 ** _decimalsOffset(), totalAssets() + 1, rounding);
}

Let's see if we don't have decimal, if the above attack can succeed. Now we have：

$$\frac{share}{totalShare + 1} = \frac{assetAmount}{totalAsset + 1}$$

Initially, totalAssets and totalShares are 0
The attacker deposits 1 token, gets the shareReceived = 1 * 1 / 1 = 1 (totalShares = 1 )
User plan to deposit 1000 assets
For making user receive 0 share, attacker need to transfer x assets before user $$share < 1$$ => $$\frac{2000}{1 + totalAssets} < 1$$ => $$totalAssets >1999$$ Thus, the minimum x should be 1999. The total assets of the vault is 2000
User deposit 1000 assets, get the shareReceived = 1000 * (1 + 1) / 2001 = 0， vault state: totalAssets = 3000, totalShares = 1
Attack redeem 1 share, receive token amount = 1 * (3001) / (1 + 1 ) = 1500

We can see that even though without decimal, attacker still loses 500 assets. If user doesn't deposit, the loss is at least equal to the user’s deposit（1000）. So the virtual shares and assets make this attack non-profitable for the attacker.

Actually, the donation of attack has to suffer more loss , to ensure that user can not get share if decimal is not zero.

Here is a program that I wrote to test: