It is really not possible to
PUSH's arguments, one of them is
It is really not possible to
None of that makes sense. This attack vector is available to the OWNER of the contract. If my intention is to replace my own contract to nefariously do something, why on earth would I warn my users about it?
And none of this solves the problem. See my “Company XYZ” scenario above.
This is insane. I think once this vulnerability is more widely known, the Constantinople upgrade is going to make a lot of new Bitcoin programmers, unfortunately. I mean, just personally, I don’t know that I can tell my clients to build on Ethereum when I know this giant turd is floating around out there. It’s just a matter of time before this gets exploited in a big and spectacular way. Sure, my clients’ contracts will be unaffected, but Ethereum will have lost all credibility (rightly so).
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
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
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…
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.
UseCases for account abstraction
I am also really struggling to see the point of the “features” of CREATE2. It doesn’t add any significant new functionality, and makes it harder and much more hazardous for users to interact with contracts safely. The idea that a user needs to check a CREATE2 contract every time they interact with it is crazy. If my local coffee place required me to check, before opening the door, that they hadn’t installed a bear trap, I would very quickly find somewhere else to go!
I can understand why some are looking for ulterior motives for this EIP - there has been very little explanation of the reward resulting from the increased risk.
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.
Why would I ever use such a system, if the contracts can be changed?
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.
Appreciate the clarification. The point still stands that safely interacting with a contract that uses
create2 (and a following ‘create’) requires a fairly challenging audit/review process every time. I still think that this new feature will open a Pandora’s Box of side effects that will erode trust in the entire system, but it looks like it will be up to the end users to contend with this.
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
How is the audit of any contract that can be changed at-will useful?