NewsFlash Articles Data Fundraising BlockBeats Pro

Beautiful number address can also be safe? Explain the only secure method for unlicensed multi-chain deployment

DeFi之道

Read this article in 26 Minutes

EOA hot addresses are a road to bankruptcy, while smart contract hot addresses are a road to success.

Title: Vanity Addresses

Original article by foobar

Last night's porridge, the DeFi way

With $160 million missing, Wintermute, one of the industry's most perceptive market-making funds, woke up one morning in September to find a nine-figure sum missing from an important wallet. So what caused the Wintermute burglary? This is caused by poor randomness in a flash address generator. Black Hat hackers brute force the private key from scratch. Public address pair, and then, a lot of crypto assets were just transferred.

There's also the story of Indexed Finance's heist, which took $16 million in October 2021 and then transferred the stolen funds to the indexed Indexed by 0xba5ed... The beginning address. Unbeknownst to them, this fancy number address was also affected by a nasty random bug that plagued Wintermute, and in September 2022, all the money was stolen again, going to another hacker wallet address. Thieves are ruthless.

So what's wrong with these talented developers, and what can we learn from them?

On the left is the general address for the WETH contract. On the right is a bright number address with 14 leading zeros for MEV robot optimization. The most common type of flash address is one with many leading zeros.

First, what is a vanity address (also known as vanity address)? A smart address is a public address that a user deliberately creates to be associated with his wallet or smart contract. Maybe it starts with 0x0000000, maybe it starts with 0xdeadbeef, maybe it's some other regular address. They are popular for several reasons:

1. Gas optimization:Wintermute saved $15,000 by using an EOA address with multiple leading zeros. Sound silly? A lot of people agree, but that's how EVMs work! If you have a lot of zeros in your address, then transaction gas costs can go down. So if you use a smart contract address with a lot of leading zeros, when the user is interacting with it, they're going to be happy because it's going to save them money.

The Ethereum Yellow Book describes how leading zero addresses can achieve cheaper gas

2. Agreement brand.Did you know the 1inch Token contract starts with 0x111111111... Is it?

1inch Token 合约

3. Multi-chain repeatability.In my opinion, this is a top priority and why every protocol should have a fancy address for their deployment. Your application can exist on 15 different EVM chains and have the same address everywhere! Isn't that easier for developers and users?

So when is a flash address safe?

There are two types of Ethereum addresses: externally owned accounts (EOAs) and smart contract accounts. If you use a wallet like MetaMask, each address is an EOA, which is used to sign messages and process transactions. Compare this to a smart contract account like the Uniswap contract, which people can interact with, but it can't take its own action without being triggered. To summarize, it's simple: flash addresses are not secure for EOA accounts, but they are secure for smart contract accounts.

So why is that? We'll explain this in more detail below, but it depends on how the flash number address is generated. For EOA accounts, you cycle through millions of private keys until you find one that corresponds to an aesthetically pleasing public address. However, the private key controls the money in the EOA account, so if the randomness you use to traverse the private key is broken, your entire account will be ruined. On the other hand, creating smart contract bright number addresses requires only traversing public seeds that do not grant any administrative rights to smart contracts.

This is why Wintermute failed and OpenSea succeeded -- it is not good to generate a private key in insecure memory with insecure software. But generating public seeds this way is great! So EOA hot addresses are a road to bankruptcy, and smart contract hot addresses are a road to success.

Why does the protocol need a smart address

Simpler documentation! You can point to a contract address on all chains;

User verifiable! The same contract address occurs only if and only if the bytecode is a byte by byte match;

Developer verifiable! Because the same contract address only happens when there is an exact match, you can catch small, tricky changes in the deployment script;

Easier integration! Other protocols can hardcode your contract address into their multi-link code without having to use chainid-based if statements.

Note: We are about to delve into a detailed instruction manual. This is the first time all the pieces have been put together, and we're going deeper into the technology space, targeting smart contract developers who have experience deploying smart contracts on a chain. Read on if you're interested, but don't worry about keeping up if it's not for you! Finally, there is an additional technical challenge (with rewards).

Smart contract smart number address

There is a way to generate smart contract smart number addresses that are 100% secure, no matter what kind of software you use, it doesn't matter if the iteration technique is disclosed publicly or not. It's called the CREATE2 Factory method, and not only does it provide the smart address, but it's also a foolproof way to make sure you have the same contract deployment address on multiple chains. It also allows others to deploy code on your behalf without trust, without any private key sharing or nonce assumptions.

First, a quick overview of how to choose a smart contract address. There are two deployment options, CREATE And CREATE2 . When you deploy smart contracts directly from EOAs, the default process is CREATE. The address is determined by hashing the contract creator address with the contract creator nonce. This nonce refers to how many transactions are sent from an address, so a new wallet starts at 0 and increases by 1 each time a new transaction is sent. Here's the magic formula for the smart contract addresses that CREATE deploys:

new_address = hash(sender, nonce)

Less common, but more interesting, is the smart contract address deployed with CREATE2. Here is the formula:

new_address = hash(0xFF, sender, salt, bytecode)

The former seems simpler, right? However, let's give an example of where this simplicity can be detrimental compared to the more robust CREATE2 process.

Airy Alice: Something is wrong with the multi-chain

Imagine a crypto developer named Alice creating two smart contracts: a Uniswap fork called GriddleSwap, and an NFT project called ph00ts. They are both immutable independent primitives, which means that there are no external dependencies or cross-chain bridge risks. Alice deploys GriddleSwap to Ethereum using nonce 0 and then ph00ts to Ethereum using nonce 1. Sadly, Alice has a short attention span and gets distracted on encrypted Twitter for a few minutes before deploying her work to the second largest smart contract, NT Smart Chain (BSC).

Oops! Messed up the deployment sequence!

But wait! She messed up the deployment sequence and deployed ph00ts before GriddleSwap. Since the smart contract address depends only on the creator address, and in the deployment blockchain, Ethereum gridleswap has the exact same address as BSC ph00ts! To add insult to injury, Ethereum ph00ts has the same address as BSC GriddleSwap. To think that end users will be confused is an understatement. In fact, it can be abused by malicious deployers to trick people into thinking that the contractual behavior on the chain is the same - which is a fair assumption given the same address!

Careful Alice: There will still be problems

Even though Alice is conscientious when deploying and never confuses her nonce order, there are other problems. If Alice is deployed correctly on Ethereum and BSC, but then makes an unrelated transaction on Polygon, nonce 0 has been used up. She can never deploy GriddleSwap there because her nonce has increased. Therefore, the deployer private key must be protected at all costs. If Alice divulges it, malicious saboteurs can make unrelated transactions. If Alice loses it, she also loses the ability to deploy to that address again on the new chain. This is a permanent vulnerability that relies on an honest individual to protect the private key. If Bitcoin core developers can't do it, how can the rest of us?

Solution: CREATE2

Thankfully, there is a better way to get consistent addresses across chains -- independent of the secret private key, independent of a single deployer, and resistant to deployer error along the way. Remember the formula used to find the address of the smart contract deployed with CREATE2:

new_address = hash(0xFF, sender, salt, bytecode)

The first parameter 0xFF Is a constant value that you can ignore. The second parameter (sender address) can choose in the chain of most EVM entry z0age CREATE2Factory deployment 0 x0000000000ffe8b47b3e2130213b802212439497 to remain consistent. The third parameter is the one selected by the user. salt, which we can use to find a flash address, and then hold it constant on the chain. The fourth is the contract bytecode, which serves as a useful integrity check to ensure that we are deploying exactly the same functionality across the chain. All four parameters can remain the same regardless of what any single deployer does.

Why is that better? Unlike private keys, the salt selected by the deployer can be exposed! Know that salt can deploy the contract, but has zero control over the contract assets or functions. Because it does not bind any secret information, anyone can deploy the contract to a new chain without disclosing or sharing the private key. The bytecode parameter also ensures that these new unlicensed deployments will have the same address if and only if the bytecode is the same. As a result, end users get a stronger guarantee without having to make detailed code differences.

For more in-depth overview, please refer to the science article ‌ OpenZeppelin.

Create your own smart address

Think proof-of-work (PoW) is useless after the Ethereum merger? Think again! The same GPU capabilities that help find hash primitives with a lot of leading zeros for bitcoin blocks are also excellent at finding hash primitives with a lot of leading zeros for EVM smart contracts. z0age from OpenSea (this article is thanks to his explanation) found a simple setting to create your own smart number address.

1, use vast. Ai ‌ & have spent Starting a sample GPU instance with about 2 billion attempts per second costs about 25 cents per hour:

Image: nvidia/opencl

GPU: 1x RTX 3090

Disk space to be allocated :1.83 GB

2. SSH and install rust + create2crunch

sudo apt install build-essential -y; Curl, proto '= HTTPS' - tlsv1.2 - https://sh.rustup.rs | sSf sh - s - - y; source "$HOME/.cargo/env"; git clone https://github.com/0age/create2crunch & & cd create2crunch; sed -i 's/0x4/0x40/g' src/lib.rs

3. Run Torrent search. For the environment variable, INIT_CODE_HASH is the keccak256 of the contract creation code. Can be inhere‌ find a printed sample OEM test - make sure before you consume a large amount of computational resources for the validation. LEADING should be the number of leading zeros you want, and TOTAL should be the total number of zeros you want in the contract address.

export FACTORY="0x0000000000ffe8b47b3e2130213b802212439497"; export CALLER="0x0000000000000000000000000000000000000000"; export INIT_CODE_HASH="0xabc... def"; export LEADING=5; export TOTAL=7; cargo run --release $FACTORY $CALLER $INIT_CODE_HASH 0 $LEADING $TOTAL

When z0age first released his repo, it was able to run 1.9 billion attempts per second on the aforementioned vastAI hardware. Since then vectorization has gone crazy on certain OpenGL kernels, and I've observed 2.15 billion attempts per second. This means that it takes 256^5/(2150000000 * 60) ~= 8 minutes to find a 5-leading zero-byte address, 256^6/(2150000000 * 3600) ~= 36 hours to find a 6-leading zero-byte address, Finding a 7-leading zero-byte address takes 256^7/(2150000000 * 86400) ~= 387 days. Note that one byte is equal to two hexadecimal characters, so a 5-leading byte address will have 10 zeros. Of course, such searches can be fully parallelized, and the actual probability of success will follow the Poisson distribution over time.

Deploy the CREATE2 factory

Astute readers might have noticed that CREATE2 Factory on all the chain already exists in the 0 x0000000000ffe8b47b3e2130213b802212439497. It's a bit of a chicken-and-egg problem, how does consistent address deployment depend on consistent address deployment?

When I first learned about this method, I thought it was just a private key held by someone smarter than me (the "Careful Alice" scenario above). But it's actually much more robust than that! ENS founder Nick Johnson's "Keyless transaction" approach takes advantage of the fact that you can recover a public address from any transaction signature without knowing the corresponding private key that signed it. Thus, you can create a transaction (" Deploy a create2 factory ") and then invent a forged signature for it, such as a signature consisting only of 2's. The private key to this forged signature exists, but no one knows what it is. But we can restore the public address corresponding to the keyless signature, send it some ETH, and then commit the signed transaction to the memory pool. Although this method is obscure, it is a valid transaction, and is actually the only valid transaction that can be sent from this public address.

And the result? Anyone can deploy a factory onto a new chain without any proprietary information, while preventing malicious actors from causing damage. Creating a single-purpose EOA that can deploy only one transaction is a very clever technique.

The specific address and contract created during a keyless transaction

This can be done with three simple "forge cast" commands. The bytecode is too long to copy here, but you can follow the instructions in the https://github.com/ProjectOpenSea/seaport/blob/main/docs/Deployment.md ‌, Deploy CREATE2 Factory without permission on any chain of your choice!

Of course, if it's already deployed, there's no need to deploy it again.

Side note: The IP-155 requirement is bad

简短的尝试来支持我的 L1 治理冒险行为，请随意跳过。EIP-155‌ 是 Vitalik 于 2016 年提出的一项提案，其引入了「链 ID」的概念以防止重放攻击（replay attacks）。每条链都有自己的唯一标识符——以太坊是 1，BSC 是 56，Polygon 是 137——这些标识符将包含在已签名的交易中以防止重放攻击，它很快被以太坊采用，而其他所有 EVM 链都跟着采用了这个提案。这很好，但问题来了，当选择几条链，例如 Evmos 最近决定明确禁止 EIP-155 前的交易‌，在奇怪的理由下，它可以防止一个操作错误，即 Optimism 将 2000 万 OP Token 发送到 Wintermute 不存在的一个多重签名（是的，又是他们）地址，声称拥有但从未初始化。但是，禁用 155 之前的交易会显著破坏一整套跨链部署，例如 CREATE2 factory 以及 Seaport 等领先项目。这些治理提案应该立即回滚，像这样的保护细节应该来自钱包而不是共识层。如果多链是未来，那么这些不必要的限制，将是顶级项目部署在你的区块链上的巨大障碍。

Fun stuff: Deployment bounty

Today https://delegate.cash is deployed in 7 different EVM chains (Ethereum, Polygon, Optimism, Celo, Avalanche, Fantom, and Arbitrum) and 7 test networks corresponding to these chains. All of these contracts address is the same: 0 x00000000000076a84fef008cdabe6409d2fe638b.

Is that enough? No, we need more chains. Because delegatecash is an independent primitive with zero dependencies, this means that the risk of multiple chains is effectively zero. This is an unalloyed benefit! Therefore, for the top 5 delegatecash smart contract deployable and verified to the new chain and corresponding test net, I will award a 100 USDC bonus!

You need tohere‌ deployment scripts in the open source repository is used. This may require deploying the CREATE2 Factory (if it doesn't exist) and don't forget Etherscan validation! Happy deployment and enjoy experiential learning!