Behold: The router contract that can be generated to handle over 4000 function selectors! 🤩 And not an ounce of Solidity was used. No sir, we're diving into EVM opcodes with this one! 🔥🔥 If you want to improve your low-level knowledge of how the EVM works, ima bout to give a break down on this awesome contract and how it works at a very high level 🤓 Let's dig in 👇👇👇 The first two lines is the deploy code 🚀 When you deploy a contract to an Ethereum chain, you don't just upload the contract body – you also upload the deployment bytecode. The EVM runs your deployment code and then throws it away (this is why you don't have access to constructors in Solidity btw). Your deployment code can do whatever you want, but it MUST AT LEAST RETURN the body of your contract – in other words, the runtime code of your contract. This is what gets persisted onchain. The (init-runtime-code) macro above simply generates a standard 15 bytes of opcodes that does this returning. It involves copying bytecode into memory, and then returning it. Next up we have some definitions: `def` is a macro defining a custom macro. Macros are nifty Trim features that convert one text to another. Makes for some really clean code. Here we're defining what we call "registers". Most VMs have registers, but the EVM doesn't. Not a problem; we simply decide to use the first few words of memory to put some working, named data. This technique makes our code WAY simpler, as we don't have to manipulate and memorize the state of the stack, instead we can just MSTORE and MLOAD. Next up, some init code. Check the faded out code right under \$input. This is a very standard technique of loading the 4 byte function selector into memory. This is the function that the caller wants to call, and the function we want to search for in our binary search. If you don't know what function selectors are, head over to @LearnEVM and fix yourself up! Now for the main body: This is the heart of the contract body. It uses a binary search to find the function selector within the hardcoded function data we have at the bottom of the contract. The star of this show is CODECOPY, which allows you to load bytes of your own contract bytecode into memory. Extremely cool feature! So yeah, if the search finds a matching selector, then it loads the correct module and delegates to it. Otherwise, it reverts. Since Twitter only allows 4 images on a post, let's skip over the DELEGATECALL code – something quite standard that you can find info on elsewhere – and jump into the hardcoded function data: This is the beauty to behold! When you write raw bytes like this, Trim leaves it exactly as you wrote it, literal verbatim at that position in your contract body. The way we've set things up, the contract's execution never actually gets to this point (it returns or reverts before it). In other words, this is literal raw data sitting in our contract bytecode! And our search code – using CODECOPY – treats it like a database 😍 As you can probably imagine at this point, adding functions and modules to this contract has a very small cost. All you need to do is: - Add 4 bytes for the selector - Add 1 byte for the module index - Add 20 bytes for the module address – ONLY if it's not already present! 🔥🔥🔥 And that's it! This little guy can support up to 256 modules and 4000 function selectors. Tweaked a bit, it could hold more modules and fewer selectors, if that's what you really need. Either way, we've got a beautiful piece of code, written in a beautiful little language for the EVM (if I don't say so myself 🤓) That's all for now, folks! ---- P. S. You may have noticed that this contract does not have Diamond Loupe functions that are required by the EIP-2535 spec. This is true. Although this router generator is already useful on its own, adding these functions is what I plan to do next. In theory, it shouldn't add much code to the body of the contract... (in fact, if you wanted to, you could delegate call to another hardcoded contract with the diamond loupe functions. Since these functions are only really used offchain, it would be an appealing option. But a project requirement of @usecannon was that these contracts should be self-contained, so that's the context we're working with) ...and it definitely won't add any gas costs to the runtime – assuming the selector you're calling is one that the contract expects. Check out @LearnEVM and @0xMacroSecurity for deeper dives into this fun micro world of EVM opcodes. Until next time! xitter.cf/0xgib/status/187775866…

I'm extremely excited to introduce Trim – a newly updated, tiny language for writing highly optimized smart contracts for the EVM! 🤓 But why Trim? Let's just say there's a... "solidity-shaped" reason behind it 🧐 It all started with a curious engagement with @usecannon...

EVM opcodes are so back new thing coming soon 👀