I submitted a fix to the eth_estimateGas on go-ethereum https://github.com/ethereum/go-ethereum/pull/21751
@rmeissner so this is what you suggest?
contract ERC2470 {
fallback() external payable {
deploy(msg.data, 0);
}
function deploy(bytes memory _initCode, bytes32 _salt)
public
payable
returns (address payable createdContract)
{
assembly {
createdContract := create2(callvalue(), add(_initCode, 0x20), mload(_initCode), _salt)
}
require(createdContract != address(0), "ERC2470: CREATE2 failed");
}
}
Anything else you want to add?
This seems wrong, because with âpayableâ creations some contracts might deploy something different, however this can already be achieved by using other transaction parameters like gas limit or gas price.
So I might allow this and just add to security considerations that when a contract accepts value at creation, it should also work when msg.value is zero, or execute the same procedure regardless of value in constructor.
1 Like
So, the 100 gas bid for this contract feels âhighâ, but in practice isnât high enough :(. In fact, it is below the minimum gas bid for Avalanche, and so this contract cannot be deployed to their C-chain at all. It is sadly too late to fix this EIP over this, but Iâm going to assert the bid should have been 500, with the argument that geth actually used to (and sort of still does?) have a maximum gas suggestion limit of 500, which makes this that schilling point for âa lot of gasâ.
(This also happens to be greater than the weirdly-hardcoded gas limit on Avalanche C-chain, which is 470. FWIW, I do not consider Avalancheâs design here reasonable, and have an issue filed at https://github.com/ava-labs/coreth/issues/40; but, even so, I am still sad that EIP2470 went with what feels like an arbitrary 100 instead of seeing the existing 500 limit, particularly as the gas bid on Ethereum itself was up towards 500 for quite a bit of time this year.)
What Iâm currently intending to do is to deploy a variant of EIP2470 to all of the chains Iâm working with that uses the exact same transaction as the one in EIP2470 but with 500 instead of 100 as the gas bid (as I figure that that is the schilling point for such a contract, given the further existence of EIP2470; this is of course throwing away the 00s optimization, but it isnât even clear to me what that was gaining us, as the non-0s in that address donât cost anything, right?).
That said, I actually ended up coming to this thread because of a link I found in that issue that was filed about gas cost estimation, so Iâm guessing that I should probably deploy that deterministic-deployment-proxy project instead, if it is in fact fixing that issue. (Sadly, I see it is also using 100 Gwei. Is there something Iâm missing for why 100 Gwei is considered firmly âenough a-lot-of-gas that the idea that a currency would need more would be preposterousâ?)
What we should have used? gasPrice at 1000 Gwei?
In ETH chain, currently there are times where you could deploy it.
The reason 100 was choosen is because 1820 used it, and 1820 probably choosed it because the normal gas prices at that time were like 10gwei.
What we should have used? gasPrice at 1000 Gwei?
I made an explicit argumentâseemingly ignored ;Pâthat the schelling point (which to me is a very useful way of analyzing this question) is â500 Gweiâ due to what as-far-as-I-know continues to be a soft cap (and which certainly used to be a pretty hard cap) in geth at that value (and, in the few months since my writing that, Iâve only become more convinced of this based on actually seeing the weird behavior that happens as the network pushes up towards 500 Gwei).
Do you have any idea on how to let this fee open?
I can update the EIP to use 500 gwei for the final interation, but I am not sure if there wont be another new chain or new situation where 500 gwei wont work 
Do you have any idea on how to let this fee open?
FWIW, I (at least) donât: techniques surrounding hacks on top of CREATE and CREATE2 seem to fundamentally require predicting the future, as the gas bid has to be signed. I donât think this is quite âhopelessâ to do âpretty wellâ, as if the price of gas is going up typically the price of the coin will go up as well, seeing that the primarily utility of the coin is to pay for gas; and I think that the common standard of 10^18 decimals combined with psychological price points surrounding new coin launches caps the low end of gas fees somewhat.
But it is of course still easy to come up with mechanisms and scenarios where any âreasonable priceââwhich is maybe at least vaguely important to consider: Orchid paid thousands of dollars to deploy the aforementioned Gnosis contract on RSK, as the coin on their chain is Bitcoin, now at ~$50k (so, fwiw, if anyone wants to use a factory across a number of chains: I have one for you to use, and we will even help deploy it places)⌠but if it had been hundreds or even tens of thousands, we probably would not have ;Pâis going to just not be workable.
I do have a suggestion, though! One might argue that, to the extent to which this is considered functionality the platform âshould haveââand the existence of EIP-1820, which developers currently are unable to deploy on Avalanche, as even their âlower as of last weekâ minimum gas price of 225 nanoAVAX is too high, seems to argue for given that it is a dependency of other standardsâthe platform needs to provide a guaranteed way to do this: it should either be specified as a hardcoded address or as a new CREATE3 instruction.
In the world where this is CREATE3, it should be pretty clear how it would work⌠but it would now require getting implementation buy in from all of the chains to add itâand it is kind of feeling like the ship has sailed as of mid-2020: new feature are going to be hard to rely uponâbut, in a world where it were a hardcoded address, then Nickâs method could merely be a fallback. Like, AFAIK nothing prevents there from being a special case on (for example) Avalanche to have this factoryâs creation be either a one-off special case or even a built-in.
Hey @3esmit this EIP is quite interesting, any update to it, OR do you know of Singleton Factory that we can use today has been deployed across the majority of chains?
1 Like
There is one deficiency of this EIP, and that it doesnât revert on failure.
This means you canât even estimate its gas usage.
It does use a standard ABI encoding, which makes it slightly easier to use from solidity than the deterministic deployment proxy.
Not sure that this makes it a better candidate to be a standard, though.
Axelarâs CREATE2 factory has similiar code and has reverts: axelar-gmp-sdk-solidity/contracts/deploy/ConstAddressDeployer.sol at main ¡ axelarnetwork/axelar-gmp-sdk-solidity ¡ GitHub
Theyâve deployed it to a number of blockchains. Hereâs their guide: Axelar Documentation
These days I find the âCREATE3â method much more interesting, as contract bytecode is not used to calculate the address.
It would be great if both methods were part of Ethereum, so that we wouldnât have to do the keyless deployment of the factory contract on multiple blockchains. Keyless deployment is best practice but now getting more difficult due to chainId enforcement by nodes.
We really need a solution to EIP-155 enforcement.
hey 3esmit! iâm taking a close look at AA and see that originally there was a relatively high probability of using this eip to implement a standard account creation factory compatible with other eips like 4337. would love to learn more about how those convos progressed and ultimately why the outcome was moving this proposal to stagnant. lmk how might be best to chat.
Yes, non-EIP155 deployment is tricky on new networks, but I think that adding a new opcode (or precompile) for that purpose is an overkill: it is much simpler to do a ânonstandard state changeâ for those networks and deploy the deterministic deployerâŚ
(actually, this is exactly what âBaseâ did, and I think other networks too, to have the deployer available)