Michael Amadi

@michaels

95 Following

217 Followers

Michael Amadi pfp

Happy to share that I'm joining @ OPLabsPBC as a Protocol Engineer. Excited to collaborate with some of the brightest minds to help scale Ethereum and build the future 🔴

9 replies

8 recasts

82 reactions

Michael Amadi pfp

Why does solidity make you have to choose between the upside of function overloading and the compile time type safety of abi encodeCall? You just can't have both

1 reply

0 recast

4 reactions

Michael Amadi pfp

For scenarios when you'd not want the code hash to affect the resultant address and the runtimecode is less than 3.6KB. This is more optimal than Create3.

0 reply

0 recast

1 reaction

Michael Amadi pfp

Introducing Create3s: Cheaper Create3 deployments for small sized contracts. Create3s is up to 35K gas cheaper than Create3 for contracts sized <= ~3.6KB. The smaller the bytecode, the more gas saved. For how this works, here is the link to the repository. https://github.com/AmadiMichael/Create3s

2 replies

6 recasts

46 reactions

Michael Amadi pfp

Also the amount of child contracts is the nonce - 1 since contracts have a default nonce of 1 when deployed.

0 reply

0 recast

2 reactions

Michael Amadi pfp

0 reply

0 recast

1 reaction

Michael Amadi pfp

0 reply

0 recast

0 reaction

Michael Amadi pfp

0 reply

0 recast

1 reaction

Michael Amadi pfp

Thanks, my mistake 😅

0 reply

0 recast

1 reaction

Michael Amadi pfp

Found an elliptic curve lib I was writing from scratch last year but didn't have the time to work much on it. I spent the weekend completing it. It's not as optimized as standard cryptography libs, but I can say it's way faster than it was initially. https://github.com/AmadiMichael/EllipticCurves

1 reply

0 recast

9 reactions

Michael Amadi pfp

Gist: https://gist.github.com/AmadiMichael/dab482d9273d86bbb20febdbca1f8be3

0 reply

0 recast

1 reaction

Michael Amadi pfp

Wrote a generic (over the number of `bitsPerIteration`) Strauss Shamir impl. The space complexity is O(2 ** 2n), where n is the bitsPerIteration. Because of this, it's important to find a balance between gas cost per iteration and memory expansion cost that comes with reducing the number of iterations by storing precomputed values in memory. OpenZeppelin for example, uses 2 bits per iteration for their P256 verifier. This example uses scalar numbers for simplicity but would also work if used with EC points and operations.

2 replies

0 recast

3 reactions

Michael Amadi pfp

0 reply

0 recast

1 reaction

Michael Amadi pfp

Okay, issue raised. Maybe native bytecode linking (like huffidity) will be possible with EOF Solidity... any feedback is appreciated and welcome https://github.com/ethereum/solidity/issues/15211

1 reply

1 recast

4 reactions

Michael Amadi pfp

2) Inline assembly execution calling solidity functions with CALLF: Currently in solidity its not possible to call your contracts' solidity function while in an assembly or an assembly block's function from another assembly block. With EOF, it would be a nice feature if a shared functionality can be set as a code section and hence can be callable via CALLF from any inline assembly block within that contract.

0 reply

0 recast

2 reactions

Michael Amadi pfp

``` contract A { CodeSection huffCode = CodeSection(0x0101e4, 3, 1, 3); // when used in code, huffCode is a constant that holds the code section index of the variable and not the struct defined above. function b(uint256 _a, uint256 _b, uint256 _c) external view returns(uint256 _d) { _d = huffCode_a, _b, _c); } // OR function c(uint256 _a, uint256 _b, uint256 _c) external view returns(uint256 _d) { assembly { // in inline assembly, huffCode is the code section index of huffCode. The solidity version above does this under the hood. _d := callf(huffCode, _a, _b, _c) } } } ``` Also since memory is shared between code sections, similar to inline assembly the concept of memory safe code sections would also be a thing.

1 reply

0 recast

2 reactions

Michael Amadi pfp

EOF-Solidity feature requests: 1) Native support for Code Section types: Defined as a struct of 4 fields: bytecode, num of inputs, num of outputs and max stack height. This is to be defined at the contract level and must be known at compile time so that it can be validated and compiled together with the solidity code. Then within any function, the code section can be called via solidity or inline assembly and outputs are to be consumed. This feature enables using custom bytecode e.g hyper optimized hand written bytecode or from another compiler be used within solidity. Example with unchecked add 3 bytecode in comments:

1 reply

0 recast

3 reactions

Michael Amadi pfp

Improved it a bit. Here's an example of parsing a factory contract that creates another contract. This example is cool because it shows how nested container sections are encoded. - The first command parses the factory contracts eof bytecode - The second command copies the bytecode of the factory's first and only container (which is the init container of the contract to be deployed) and parses it, - The third command copies the bytecode of the init container's first and only container (which is the eof bytecode the init container will return as the runtime code of the contract to be deployed). https://github.com/AmadiMichael/EOF-Bytecode-Parser

0 reply

0 recast

3 reactions

Michael Amadi pfp

Repo: https://github.com/AmadiMichael/EOF-Bytecode-Parser

0 reply

0 recast

1 reaction

Michael Amadi pfp

Spent yesterday evening making an EOF bytecode parser with some header invariant validation based on the specs. Also using this to get back into rust. Here's an example output when run with EOF bytecode: 0xef0001010004020001000304000400008000013050fe0bad60a7 Repo link in comments

1 reply

0 recast

4 reactions