Skip to content
This repository has been archived by the owner on Sep 20, 2023. It is now read-only.

ProxyFactory create2 and blackholing of funds #3392

Open
mikeshultz opened this issue Sep 14, 2019 · 5 comments
Open

ProxyFactory create2 and blackholing of funds #3392

mikeshultz opened this issue Sep 14, 2019 · 5 comments
Assignees
Labels
bug Something isn't working as intended P2 Small number of users are affected, major cosmetic issue smart contracts

Comments

@mikeshultz
Copy link
Contributor

mikeshultz commented Sep 14, 2019

This is a bit of an edge case, but does actually waste money. If a user attempts to deploy a proxy (with the same proxyfactory nonce) when one already exists, it dies. When it dies, it continues running the initializer (wrapped transaction) to 0x0000000000000000000000000000000000000000. Of course this isn't an actual contract, and if the the transaction carried any value(ETH), that value would be sent to the black hole that is 0x00..00. Example tx:

0x8a9650f337466d6d4ecda51ec95fd500d914ad5b3e5abb50eb253eea4240f4fc

1 event was fired:

topics[0] 0xa38789425dbeee0239e16ff2d2567e31720127fbc6430758c1a4efc6aef29f80 // ProxyCreation
topics[1] 0000000000000000000000000000000000000000000000000000000000000000

I propose adding a check to see if the address returned by create2 is zero to both createProxyWithNonce() and createProxyWithSenderNonce(). If it is, revert. Absolutely do not run this initializer.

if (initializer.length > 0) {
uint256 value = msg.value;
// solium-disable-next-line security/no-inline-assembly
assembly {
if eq(call(gas, proxy, value, add(initializer, 0x20), mload(initializer), 0, 0), 0) { revert(0,0) }
}
}

I think uprading will be clean. We will need to add support for multiple ProxyFactory contracts for anything that tracks events(e.g. listener). Already deployed user proxies are not affected.

@mikeshultz mikeshultz added bug Something isn't working as intended smart contracts labels Sep 14, 2019
@mikeshultz mikeshultz self-assigned this Sep 14, 2019
@micahalcorn micahalcorn added the P1 Large amount of significant user impact, a meaningful feature is broken label Sep 14, 2019
@franckc
Copy link
Contributor

franckc commented Sep 14, 2019

CC @DanielVF @nick

@DanielVF
Copy link
Collaborator

I'm in favor. It's quite painful the way it fails now - it basically fails silently. Not to mention wasting a pile of gas.

@nick
Copy link
Contributor

nick commented Sep 16, 2019

I think this works. Just need to verify that the predicted proxy address doesn't change if we start using a new proxy factory.

eg address of deployed proxy via factory 1 == deployed proxy via factory 2

@mikeshultz
Copy link
Contributor Author

Ah, that's a good note, @nick. It will undoubtedly change the address...

const create2hash = web3.utils
.soliditySha3('0xff', contracts.ProxyFactory._address, salt, creationHash)
.slice(-40)

I guess we'd have to iterate through each ProxyFactory address, compute the predicted proxy address, and check. That is a drawback, but not sure a deal breaker here.

@mikeshultz mikeshultz added P2 Small number of users are affected, major cosmetic issue and removed P1 Large amount of significant user impact, a meaningful feature is broken labels Sep 25, 2019
@mikeshultz
Copy link
Contributor Author

There seems to be more agreement that this isn't urgent, dropping to a P2.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
bug Something isn't working as intended P2 Small number of users are affected, major cosmetic issue smart contracts
Projects
None yet
Development

No branches or pull requests

5 participants