15021
Michael Amadi
@michaels #15021
Protocol Engineer @ OP Labs | https://amadimichael.github.io | Prev: @rareskills
325 Follower 92 Following
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 🔴
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
https://github.com/AmadiMichael/EllipticCurves
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.
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.
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
https://github.com/ethereum/solidity/issues/15211
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) 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:
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
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
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
Here's an example output when run with EOF bytecode: 0xef0001010004020001000304000400008000013050fe0bad60a7
Repo link in comments
Here's an interesting way to encode all of the supported opcodes of an EVM chain in 256 bits. This is that of Ethereum mainnet currently.
Base 2: 1110010000111111000000000000000000000000000000000000000000000000000000000000000000000000000111111111111111111111111111111111111111111111111111111111111111111111111111111111111100000111111111111111111111111111000000000000000100111111111111110000111111111111
Base 10: 103238640842065774761881656312677524192904604960857204817777740543577286447103
Base 16: 0xe43f0000000000000000001fffffffffffffffffffff07ffffff00013fff0fff
Its also easy to check if a particular `opcode` is supported, like so:
```
uint256 opcodesBitmap = 103238640842065774761881656312677524192904604960857204817777740543577286447103;
uint256 mask = shl(opcode, 0x01);
bool isSupported = and(opcodesBitmap, mask);
return isSupported;
```
Base 2: 1110010000111111000000000000000000000000000000000000000000000000000000000000000000000000000111111111111111111111111111111111111111111111111111111111111111111111111111111111111100000111111111111111111111111111000000000000000100111111111111110000111111111111
Base 10: 103238640842065774761881656312677524192904604960857204817777740543577286447103
Base 16: 0xe43f0000000000000000001fffffffffffffffffffff07ffffff00013fff0fff
Its also easy to check if a particular `opcode` is supported, like so:
```
uint256 opcodesBitmap = 103238640842065774761881656312677524192904604960857204817777740543577286447103;
uint256 mask = shl(opcode, 0x01);
bool isSupported = and(opcodesBitmap, mask);
return isSupported;
```
Officially an EOF Maxi
EOF Weekend 🔎
TIL: For addresses that do not exist, i.e.,
a) haven't sent a tx, i.e., nonce is 0 and
b) haven't been the recipient of a non-zero value tx
Their EXTCODEHASH is bytes32(0) and not keccak256(new bytes(0)) as you might expect.
...
a) haven't sent a tx, i.e., nonce is 0 and
b) haven't been the recipient of a non-zero value tx
Their EXTCODEHASH is bytes32(0) and not keccak256(new bytes(0)) as you might expect.
...
Successfully contributed to @penumbrazone summoning ceremony.
Contribution receipt: 29F27D2CAC85019D41ECECDE693FA1DE0DDABF8B64D35A89673ED31985DCA1C1
Slot: 2152
Contribution receipt: 29F27D2CAC85019D41ECECDE693FA1DE0DDABF8B64D35A89673ED31985DCA1C1
Slot: 2152
Done with it. Learning fundamentals makes higher level stuff make so much more sense. Strongly recommend.
Started yesterday...
Just finished the Self-Hosted EVM quest on Node Guardians and can't recommend it enough.
Link in comments
Link in comments
You're in her dms, I'm in her PXE. We're not the same.
Last week was my last at Rareskills. It's been a wonderful ride researching, learning, and building with brilliant colleagues!
Very grateful for the invaluable experiences and the exceptional people who made it an unforgettable part of my journey!
Very grateful for the invaluable experiences and the exceptional people who made it an unforgettable part of my journey!
With EIP-7702 what happens if the one-time code executes the selfdestruct opcode?
- Gas refund?
- More gas? Seems the better option since the nodes will still attempt to delete the code & storage at the address after
More importantly, what happens to the ETH at the address? Gets drained to the selfdestruct parameter?
- Gas refund?
- More gas? Seems the better option since the nodes will still attempt to delete the code & storage at the address after
More importantly, what happens to the ETH at the address? Gets drained to the selfdestruct parameter?
Congrats to everyone who submitted for the curta golf contest @atarpara @philogy @crypto-frens.eth 0xjustadev
Spent hours working on a constant gas solution for hours only to realize when I was done that there was a codesize gas penalty imposed 🤦🏾♂️
Thought I should still share it though
Link in comment
Spent hours working on a constant gas solution for hours only to realize when I was done that there was a codesize gas penalty imposed 🤦🏾♂️
Thought I should still share it though
Link in comment
Thrilled to have been selected as one of the recipients of Builders Grant from @base for my P256 Huff Verifier: https://warpcast.com/michaels/0x51e39e31
Grateful for the support and excited to continue building 🫡
Grateful for the support and excited to continue building 🫡
Answer:
In Solidity, when it successfully matches the first 4 bytes of calldata sent to a function selector that expects parameters, it asserts that the length of calldata is >= (4(i.e the selector) + the number of parameters * 32).
So in this case, execution reverts if the length of calldata sent is < 36 bytes.
In Solidity, when it successfully matches the first 4 bytes of calldata sent to a function selector that expects parameters, it asserts that the length of calldata is >= (4(i.e the selector) + the number of parameters * 32).
So in this case, execution reverts if the length of calldata sent is < 36 bytes.
Solidity Trivia:
Without looking at it's bytecode, does this contract have a revert path? and if so how can you trigger it?
Without looking at it's bytecode, does this contract have a revert path? and if so how can you trigger it?
In my article on Stealth Address Protocols, I mentioned the consequences of leakage of one or a combination of the 3 private keys involved in a transaction.
I've now added the POC for this to Unsafe ECC so anyone can easily play around with it.
https://github.com/AmadiMichael/UnsafeECC
I've now added the POC for this to Unsafe ECC so anyone can easily play around with it.
https://github.com/AmadiMichael/UnsafeECC
Progressive Deep Dive Into Stealth Address Protocols
Special thanks to @merkleplant for review and feedback!
https://amadimichael.notion.site/Progressive-Deep-Dive-Into-Stealth-Address-Protocols-4f4a2929329b4c7c95f1a7e37b454973
Special thanks to @merkleplant for review and feedback!
https://amadimichael.notion.site/Progressive-Deep-Dive-Into-Stealth-Address-Protocols-4f4a2929329b4c7c95f1a7e37b454973
Maybe I should rename this to ERC20Points. Built it last year before the points frenzy and couldn't think of a use case that was worth its gas overhead but maybe now I think it might actually be useful.
Link: github.com/AmadiMichael/ERC20Merit
👇
Link: github.com/AmadiMichael/ERC20Merit
👇