True. I meant if you want to check it in a contract you should check that the byte is 0xff but also that it is not part of a PUSH.
This comment makes no sense to me. If I create a scam contract on the ETH network I obviously donât tell my users about it. Should we hard fork out all scams such as a contract which simply forwards all ETH to my address while I promote it as a dex or something?
If you interact with a contract it is your job to make sure the contract does what you expect it to do. If itâs a scam, you donât use the contract. I honestly donât see where all this negativity comes from. EVM needs to be handled with care - see for example re-entrancies which are not trivial and it is logical that a new programmer does not think about the possibility of a re-entrancy.
If you use CREATE2 you need to think about these attack vectors. I donât see any problems with it. If people want to move to Blockstream then thatâs their own choice.
Iâm sorry, but thatâs just not how the real world works. People donât trust the network because they verified the contract bytecode (how would that even work after CREATE2? you do that before EVERY contract call? What about transaction ordering?)
People trust the network because billions of dollars that could have been stolen werenât. The minute thatâs not true anymore â which this âfeatureâ makes about 1000x more likely â and Ethereum becomes a footnote in the Big Book of Bitcoin History.
Ok. If it is part of PUSH, what does it mean? Would forbid it or will you check if there any JUMP going to 0xff?
One more usecase: currently you are fine to send a Tx even if your client is not fully synced. If you know your nonce and has evaluated the contract before, of course.
Even not explicit: we have âaudit once, trust manyâ in our social contract now.
It will not work any moreâŚ
1 Like
What if we introduce a fail-fast target codebase check in transaction call? Check codebase if doesnt match - fail.
Looks like a use of Account Abstraction.
Generally, when you have to start working around your own features, you know youâve left the barn. 
I think a better solution is to retain immutability as a feature of Ethereum.
But just to see if I understand what youâre saying, you would submit something like a hash with every transaction and if the source code doesnât match that hash you revert? I would like that solution if it could also account for linked contract addresses (which is a matter of state, not source code). If you could verify the contract source hasnât changed and the linked libs havenât changed, I could see that being a decent feature.
1 Like
CREATE2 makes it possible to instantiate contracts at deterministic addresses, so you can refer to them with certainty in the off-chain world as though they are created but without the requirement of instantiating them on-chain.
It improves the architecture of layer-2 solutions (e.g. counterfactually-instantiated contracts) and the privacy of certain deployments â e.g. parties can agree off-chain on a multi-sig contract and proceed on sending money to its deterministically-computed address without actually deploying the contract on-chain, thus making it impossible for any external observer to determine whether that address belongs to an external account or to a contract. The contract will of course need to be deployed before its logic can be enacted by the network, but this can happen at a later time (i.e. withdrawal, closing the state channel).
Another use case might be contract upgradeability (in the legit scenario, the creator of a contract could destroy it and deploy an updated version at the same address), but for this one I guess the inherent immutability and security trade-offs are obvious and have been already pointed out above.
2 Likes
Because you review the init code of the contract and also the code which deploys the actual contract. From there you can prove that the contract cannot be changed. Of course if this is a feature of the contract you can also prove that it can be changed, and can show on what factors this depends.
I think the problem might be that you misunderstood the security implication. A contract deployed by the create2 operation cannot have its code changed. The only contracts that can have their code changed are contracts deployed by create by a contract deployed by create2. There is no reason other than plans to later modify the code for that deployment scheme to ever occur.
As Iâve explained above, thatâs not true in any practical, real-world sense.
This is a real problem, guys. And is this the right forum to be addressing this?
⌠which will produce a worthless audit, since the contract can be changed at any time. There is no such thing as âsafely interacting with a contract that uses create2â. Even if my audit and my transaction occurred at the same instant in time, we can never be sure of transaction ordering, so a âreplace my contractâ transaction very well may be in between.
You mean like if Iâm planning a heist?
No contract deployed with create2 can have its code changed. The only contracts that can have their code changed are contracts deployed by create.
1 Like
How is the audit of any contract that can be changed at-will useful?
An audit can tell you if a contract can have its code changed, who can change the code, how they can change it, and what the code can be changed to.
Contracts being able to have their code change has always been possible, and this just provides a new way to do it.
Can you link me your explanation? I cannot find it. I would like to see a real world scenario where somehow you cannot prove that redeployments are not possible.
Can you explain this a little better? I was under the impression that CREATE2 was the opcode to redeploy a contract at a specific address with âupgraded codeâ. If you cannot have any code changed, the all CREATE2 is good for is redeploying the same smart contract to the same address ⌠?
Thanks in advance!
create2 contracts can also have their code changed, if the init code permits it.
Yes, you can safely interact with a CREATE2 contract, you just need to validate some new things:
- Prove that there is no way to destroy the contract, then nothing is different from an audit with a
CREATEd contract - OR, prove that the init code always produces the exact same bytecode. This should be possible for many/most âhonestâ use cases. You still need to determine if âzombie contractsâ are a problem in your scenario (where the same contract pops up after it has been destroyed).
2 Likes
This is like talking to a brick wall.
âProve that there is no way to destroy the contractâ What if thatâs not true?
âOR, prove that the init code always produces the exact same bytecode.â What if thatâs not true either?
âThis should be possible for many/most âhonestâ use cases.â WTF? Weâre not talking about âhonestâ use cases, weâre talking about people pulling a fast one, which this makes 1000x more likely.
This is full-blown Twilight Zone territory.