The situation is actually much worse than this: You can write a harmless looking contract – let’s say a token wrapper or a uniswap clone – and use a collision to deploy it to an address that’s also an EOA. You deploy the contract, and after user funds have poured in (trusting the functionality according to the immutable contract code) you can steal everything using the EOA key.
We (me, @chfast, @gumb0, @hugo-dc) have been working on the address space extension topic the past two weeks. It seems to open up a lot of questions. First we have created a hopefully more comprehensive specification based on this forum and explored questions (they are listed in the latter part of the document): ASE (Address Space Extension) with Translation Map - HackMD
Posting it now in case someone else is working on this too – it would be nice to collaborate to find answers more quickly. We expect to update this document as we go next week. Any feedback is welcome, but be prepared the content is in flux.
There are some differences to the description in this forum, which are listed as bullet points. One difference is we removed references to epochs in the document, and just state bytes 1-5 are reserved and must be zero (i.e it would be epoch 0). This is meant to help decoupling this proposal from state expiry in the sense it could be introduced earlier and independently.
We are now working on some new ideas and analysis of some concerns we have identified.
We have published this collection of concerns here: Issues with ASE (with a translation map) - HackMD
It is a very long list and some points are more developed than others.
1 Like
32 bytes new addr:
0-11 Byte : EVM/contract internal ID
12-31 Byte : old 20 Byte Addr
Is there still an intention to continue with this proposal?
I still think it is necessary for some improvements that many would like to see on Ethereum. However, we were never able to come to agreement on the least worst way to do the migration. All options come with consequences/costs.
1 Like
We were evaluating something on these lines; there is a type named FunctionType that consists of 4 bytes function hash plus 20 bytes address (4 + 20). This means that maximum an address can be (within the current 32 byte limitation) is 28 bytes.
Above proposal needs to account for this FunctionType as well.
(See lines 124 o 126)
Blockquote
// A function type is simply the address with the function selection signature at the end.
//
// readFunctionType enforces that standard by always presenting it as a 24-array (address + sig = 24 bytes)
func readFunctionType(t Type, word byte) (funcTy [24]byte, err error) {