test__codesize() to be removed. We cannot use codesize anymore. Not really a dealbreaker.
_brutalizeMemory(). We will simply have to spam keccak256 and mcopy.
Have all the etch functions for factories and escape hatches.
Transpiling
Identify a list of problematic contracts and easy contracts. Sort them from most problematic to least.
Hit the most problematic contracts first.
Escape hatches
All to be deployed via Nick's factory:
EXTCODECOPY, EXTCODESIZE
CREATE
Reverts with returndata upon failure. Returns the address otherwise.
CREATE2
Reverts with returndata upon failure. Returns the address otherwise.
Since Nick's doesn't return the address, we will just have to make our own factory.
SELFDESTRUCT to force send Ether
Takes in address.
Reverts with empty data upon failure. Returns true otherwise.
Gas limited CALL
Forwards value.
Returns/Reverts with all returndata.
Gas limited STATICCALL
Returns/Reverts with all returndata.
I think it's best that we make a separate repo while devving these escape hatches. Doesn't need npm.
Notes
All addresses passed in to EXTCALL, EXTDELEGATECALL, EXTDELEGATECALL must have upper 96 bits cleaned. Also, their behavior are different.
Hand translation might not be that hard. We can use functions to encapsulate if it looks better.
Transpilation
We might define an eof/src and eof/test directory. These directories are intentionally not in src or test, so that when people install Solady for use in a regular Solidity project, they still can compile hassle free.
I'm thinking if it might be better if we keep the EOF stuff in Solady:
Aggregate traffic into Solady.
It keeps the diffing easier.
Say if we put the stuff in Soledge, and someone who wants to use the tstore libs on a non EOF project (which we expect most users to), they might run into compilation hassles.
I'd also like to reserve Soledge for the worse case scenario where Solidity becomes a completely different language in the future (in a bad way), and Soledge will have to exist to add support for that.
I feel that some stuff might not be fit for automatic transpilation. We'll know it when we get there.
A lot of the code will be a one-time transpilation. There are also many devious edge cases. A hand-transpilation approach might be overall more effort efficient even in the long run. Additionally, hand-transpiling will allow us to perform EOF specific hand-optimizations if time permits.
Effort estimate
1 week to craft, mine vanity address, and deploy escape hatches.
1 week to refactor the test base contracts TestPlus.sol, Brutalizer.sol, SoladyTest.sol, Test.sol.
1 week to refactor the original test contracts to avoid using banned opcodes.
2 weeks of porting the contracts to EOF.
These will be full-time efforts.
Priorities
Our top priority is drop-in compatibility with EOF Solidity compiler.
We'll just go with full code-reuse style. We do NOT need inline anything.
In fact, I have a feel that contracts with more code reuse are better suited for EOF, with the subroutine stuff.
LibClone might actually have lesser SLOCs with rampant code reuse.
Regression
Going forward, Solady's legacy code will still be at the forefront of cutting edge features.
We will need to have some discipline on keeping the EOF quickly up to parity with the non-EOF code, but if resources are limited, we will just create a new backlog issue on porting it to EOF.
https://github.com/ithacaxyz/odyssey-examples/tree/main/chapter1/eof
Primer
EOF disables a number of opcodes. Right now, if your contract contains any of those it will get compiled but will not be deployable.
The banned opcodes are:
CODESIZE
,CODECOPY
,EXTCODESIZE
,EXTCODECOPY
,EXTCODEHASH
.JUMP
,JUMPI
,PC
.GAS
,GASLIMIT
,GASPRICE
.CREATE
,CALL
,DELEGATECALL
,CREATE2
,STATICCALL
.SELFDESTRUCT
,CALLCODE
.Plan
Test with
forge test --eof
.Tests
test__codesize()
to be removed. We cannot usecodesize
anymore. Not really a dealbreaker._brutalizeMemory()
. We will simply have to spamkeccak256
andmcopy
.Transpiling
Escape hatches
All to be deployed via Nick's factory:
EXTCODECOPY
,EXTCODESIZE
CREATE
CREATE2
SELFDESTRUCT
to force send EtherGas limited
CALL
Gas limited
STATICCALL
I think it's best that we make a separate repo while devving these escape hatches. Doesn't need npm.
Notes
All addresses passed in to
EXTCALL
,EXTDELEGATECALL
,EXTDELEGATECALL
must have upper 96 bits cleaned. Also, their behavior are different.Hand translation might not be that hard. We can use functions to encapsulate if it looks better.
Transpilation
We might define an
eof/src
andeof/test
directory. These directories are intentionally not insrc
ortest
, so that when people install Solady for use in a regular Solidity project, they still can compile hassle free.I'm thinking if it might be better if we keep the EOF stuff in Solady:
tstore
libs on a non EOF project (which we expect most users to), they might run into compilation hassles.I feel that some stuff might not be fit for automatic transpilation. We'll know it when we get there.
A lot of the code will be a one-time transpilation. There are also many devious edge cases. A hand-transpilation approach might be overall more effort efficient even in the long run. Additionally, hand-transpiling will allow us to perform EOF specific hand-optimizations if time permits.
Effort estimate
TestPlus.sol
,Brutalizer.sol
,SoladyTest.sol
,Test.sol
.These will be full-time efforts.
Priorities
Our top priority is drop-in compatibility with EOF Solidity compiler.
We'll just go with full code-reuse style. We do NOT need inline anything.
In fact, I have a feel that contracts with more code reuse are better suited for EOF, with the subroutine stuff.
LibClone might actually have lesser SLOCs with rampant code reuse.
Regression
Going forward, Solady's legacy code will still be at the forefront of cutting edge features.
We will need to have some discipline on keeping the EOF quickly up to parity with the non-EOF code, but if resources are limited, we will just create a new backlog issue on porting it to EOF.
File analysis