RE immutability: The code is preserved in the transaction payload, which can be read and analyzed like any other.
I’d recommend that if this were adopted, wallets flag transactions to the target address with a warning message; it’d also be worth writing up a spec for a new RPC endpoint that wallets can support which accepts, say, a list of operations, and leaves it to the wallet to compose the bytecode. That way, the wallet can provide the user with a useful list of operations instead of an opaque blob to sign.
SELFDESTRUCT requires special-casing either way; without storage you still need to make sure it doesn’t zero out the nonce.
True, but I don’t believe any of those are mature enough to say whether they’re an issue or not.
I’m onboard with the idea of prohibiting
SELFDESTRUCT, though I’d like to hear from implementers which option is simplest. I still don’t think there’s a compelling reason to prohibit storage access.
I really don’t think “we can’t think of a use-case right now” is a good reason to create a new special-case to prohibit something; we should prohibit something only if it’s reasonably likely to introduce complication to clients, or have security implications.
In that event, should we specify instead that the
to field should be a single byte, similar to contract creation, rather than a 20-byte address?
Unlike that, this executes in the context of the EOA, which allows it to make use of resources owned by the EOA. A contract-creation TX is unable to operate on resources owned by its creator.