advantage. Uh anyways, so the target of

this um little primer, I will call you a

primer. It's not really a course, more

like a primer. It's is to teach you like

some of the principles

uh so that you can go and figure out

your own mental map of how to write

optimize solidity.

So the thing about the solid comper is

that uh because it's based on

uh ST the EVM is a stack machine. It's

not a register machine like uh x86. So a

lot of optimizations have to be written

from ground up. uh and the compiler uh

focuses on achieving correctness first

and when resources permit they might add

a bit of optimizations here and there.

So it's not as mature as like stuff like

LLBN

but you can go pretty far with what we

have right now uh if you know some

tricks.

Okay. So uh there are some

prerequistics.

It's easier to follow if you already

know how to write, test, and deploy

smart contracts in Solidity. Or at least

you have some idea of how to ask ChatGBT

or Grock to teach you maybe craft a

curriculum for you.

Okay. So when it comes to optimization,

uh I think a good meme to describe it is

is kind of like a iceberg. Like everyone

would uh normally they'll start with uh

the most basic like uncheck

uh uncheck aromatic storage packing.

S packing is one of the most uh I would

say lowest hanging and most overpowered

fruits because

in the EVM uh when you write some a new

storage slot the s

each s cost 20k gas and in the future it

might even increase because state access

is the bottleneck in the EVM.

uh then

uh you will go to stuff like maybe you

place your arguments in core data

instead of memory. You tweak the

optimization runs. Uh you somehow

use uh some kind of storage packing to

make sure the variables are in warm

storage.

You mark your functions as payable so

that it doesn't have the message dot

value not equals to zero check in the

background. Then you use efficient data

structures, learn how to avoid step too

deep, all this stuff. And uh once you

want to get past the get under the

water, which I say is in SMB,

then things start to get uh

interesting and some of these are not as

actually uh in my assembly. For example,

function selector mining uh for example.

Okay. Okay, when you write a solid

contract and it calls a function, it

goes through something called the

function dispatch and it's like a B3 uh

with each note has four uh like four

notes, four children. So if you are able

to mine a function selector with a

selector of 0x 0 then it will be the on

the left most side of the tree which

makes it very uh the most efficient to

access and some uh protocols they do

that. I think uh cot they m some kind of

function selector for their most often

used functions and it's not really uh

inite assembly thing it's more like you

understand how solidity works under the

hood some of it is uh understanding how

the memory works some of them is

understanding uh

the h case of the op codes like how to

abuse the h case of the op codes for

example if I want to zeroize a memory

region I can abuse use core data copy.

If I want uh out of gas river, I can ab

abuse return data copy out of bounds.

Some of them is uh general math tricks

like using Z3 to find magic constants.

Z3 is a Python program. uh or you can

like directly write the Z3 which is a

bit harder because uh but anyway I there

are some math in so uh that have some

kind of crazy constants and all of them

are found using uh Python Z3 and Python

Z3 can also help you uh formally verify

some kind of like if you want to write a

new fixed point M function and you're

not sure whether it works for all the

new in 56 inputs you probably will it

was help harmonos but uh if you want the

speed like harmonos has some overhead so

if you want the raw speed of the prover

you will use d3

then there are stuff like understanding

how the compiler inline the functions uh

understanding how the EVM works so and

so forth so it's like a rabbit hole

uh there are I would say you need to

understand how the compiler converts

your solidity into bite code you also

need to understand the EVM

uh like the EVM on a very uh familiar

level and it also will help a lot if you

have some kind of background experience

in like general computer science or uh

general math.

So there are some resources that I would

like to highlight. Um first is my repo

sle.org.

Most of my work uh goes into so these

days. Um you also can follow me on X.

I think the most uh top of the mind

resource is EVM.

Uh if you know what you want, you can uh

this is like a some kind of a cheat

sheet that you will use quite often. Uh

if you use enough maybe you can memorize

everything but I I still can't memorize

everything. So I think uh you should

rescues is one of the top of my mind

recommendations if people ask me how to

get very very good like rescues

seriously.

Yeah.

So Jeffrey from Rescues uh he took the

Jeffrey and his team yeah he took all

the they took super a lot of effort to

write super good articles.

I I say even writing articles is

sometimes I would say

uh two to three times more difficult

than inventing new math because you need

to know how to explain it to different

levels of expertise.

There's also note guardians and also

Patrick Collins on Twitter and YouTube.

And I think this is not exhaustive.

there are a lot of more resources but uh

these are just some of the stuff I can

recall from the back of my hand.

So due to this thing being one hour and

limited effort

like I can't teach you all the tricks I

know today that's just too much.

Uh so the idea is to

tell you some principles that you can

use to find your way around

and if you know these principles maybe

you can uh invent

new tricks of your own and contribute to

ripples.

So let's begin.

Okay, first thing first is safety. Uh

because if your

if your smart contract gets wrecked uh

uh okay just don't get wrecked. It's not

a good thing.

You it's not a good experience. You'll

make people lose money. Uh you lose

reputation and you cannot sleep.

Um

okay let's say you have the safety down.

uh you also want to balance performance,

readability, maintainability. So one of

my observations experiences is that

although uh

me I am a pretty uh good inite assembly

dev and the auditors we hire are pretty

good at inite assembly but sometimes if

you have everything written in inite

assembly there's a lot of noise a lot of

code noise it distracts from the overall

high level business or application logic

So you might want to restructure our

code, make it less optimized so that uh

the human side of us don't feel so

fatic.

Yeah, you can be like super good. But

you also have to consider like others

within the limited amount of audit time.

Can they somehow uh squeeze out as many

bucks as possible? So yeah, readability

is also important, maintainability

and I won't say whether high level is

more important than low level because uh

sometimes you need to know what is in

the low level so that you can architect

your high level such that they can

synergize with each other.

Uh but yeah, you should really if you

can uh like say you're selftaught, you

didn't uh go through like some kind of

intro to algorithms class, you might

want to go through one like MIT OCW 6006

is pretty good.

Um yeah, because once you go through all

these causes, you kind of understand

like uh you it gives you more ideas,

more areas of uh inspiration.

So

I won't say like uh high level is more

important than low level. Uh but if your

high level is good actually high level

yeah you can try to brute force your way

with all these tricks but someone with a

very elegant uh math formula or elegant

optimization can write some kind of

unoptimized

code that has a lower big O complexity

and yeah

so regarding optimization uh this

The first thing is uh storage savings

are the best savings. Like if you go to

any new codebase and it's pretty

unoptimized.

The first thing you can you should

optimize is the storage because you

don't need to use assembly to optimize

storage. You can um

like use smaller variables. Instead of u

256 you use maybe u in 40 for timestamps

uh something like that.

And you will notice that uh generally

the more you optimize the code base the

flatter the paraggo front gets. This

means like uh maybe initially 90% of the

gas is spent on storage. You optimize

the storage away. Then maybe 80% of the

gas is spent on core data decoding. You

optimize that away. Then you realize

that everything is kind of flat. You

optimize this. You get maybe uh 5%

savings here and there. So diminishing

returns and at this point you might want

to say okay maybe it's enough uh I will

just keep it that way.

Sometimes uh if you're like me like you

can think of the whole thing from the

bottom up from the bite code upwards you

might intentionally deoptimize your code

so that uh yeah it's more readable.

Okay. So that comes to practical

aesthetics. Uh how much performance

versus readability.

I would say if

your that is kind of application

specific, you might want to lean towards

more regular solidity. If it's some

library

code, for example, you want to make a

new math library, a new trigonometry

library, you might want to lean more

towards inline assembly.

Yeah because

humans and also LLMs we have limited

attention

and if you want to somehow have the best

of both worlds

in a way you can see whether so has some

function that solve your needs or if it

doesn't have one uh you can make a

feature request explain your use case if

it's not too specific I might uh help

you code it.

So let me go through some examples of

how you can write optimize solidity u

without diving too deep into deny

assembly and all these examples uh they

are from account and they heavily abuse

so lady to make it optimize.

Okay. So here we have a str uh you see

all of these variables are doing 256. So

20k gas, 20k gas, 20k gas. If you want

to store this in storage is 60k gas. Uh

we don't consider like the warm storage

cost. So yeah, minimum 60k gas if you do

it the regular way. But if you somehow

uh know about this thing in so called

the bike storage and you know about this

thing called the CD compress

you can combine both of them to squeeze

this struck into a single slot for the

majority of use case like most of the

use case they'll probably use like the

uh the time stamp maybe until our end of

life

Uh it will be maybe 32 bits. Hopefully

we can see 33 bits. Um amount I think

most ERC20s uh you can fit under 64

bits.

Most ERC20s

yeah same. So 64 64

class 40

and class eight bytes for eight bits for

the length. Yeah. Everything can fit in

one slot. So you don't need to write any

assembly for this. Uh if you know so has

this uh function you can just use it to

squeeze auto pack your storage and then

you don't need to decide oh maybe uh

this one I need I need U40 this one I

need U in 25 uh 256 you just let CD

compress figure out the stuff for you

like magic.

And I think for D5 protocols that uh

want to make it as general as possible

to fit UN 256. Yeah, you can abuse this

CD compress.

Okay. So another thing about uh you can

abuse to do efficient hashing. For

example, you want to calculate a EIP 712

hash. Uh the regular way is you make a

loop, you do ADI encode key cut 256.

The problem with this is that there are

so many overheads, so many hidden

overheads that solid inserts. For

example, if you use new uh by 32 array,

Solid will make a uh will create some

code to zeroize the elements,

but we know that we don't need to

zeroize the elements because we'll be

right overwriting it in this loop. So

yeah, efficient hash lip has a function

to help you allocate an array without

zeroizing the elements.

Uh we know that uh when you use co

uh array access I

solidity will emit some

I will say out of bounds checks

and we know that uh these can never get

out of bounds because they off the loop.

So you can use uh some optimized

functions in so lady for that and

efficient hashde doesn't allocate memory

when you do hash but whereas if you do

pup 256 eB encode every time you do one

iteration it allocates new memory and

memory EVM is uh expensive is we have

something called a quadratic memory

expansion cost.

So uh if you do this without using uh

efficient hasht this loop is actually n

squ in cost.

Uh yeah so you you need to know uh what

solidity does under the hood and you see

whether solid has some functions to

help you sidestep the over overheads of

solidity.

Another

uh thing is that uh sod has some

functions uh some data types that make

your life easier. For example, the

dynamic array.

Uh one complaint many people have about

solidity is that it's not a very

friendly language because when you

allocate a array you have to know the

size ahead of time like a ancient C.

Uh with so you can use this dynamic

array and then just push push kind of

like JavaScript or Python just push it

will do the amortize resizing under the

hood

and we also have like some high level

algorithms like you can group some

so you don't need to write your fancy

groups you can just call a group sum and

all these powerful expressive functions

will hide all the complexity, all the uh

assembly tricks in the background. You

don't need to fast them. It's already

fast tested in so

yeah. So if you know like what features

So have um and how to abuse them to the

max, you can get pretty far. I I would

say you can get like ahead of

99 99% of code base out there if you

just abuse so to the max without even

writing enough assembly. Yeah, you can

pretty much abuse get ahead of 99% of

code bases.

So okay after this point uh

I might talk about some

principles or disciplines you have to

keep in mind if you want to write sole

lady style code which I think you don't

really need to for most of the time but

if you want to be a optimizer like show

off your insembly skills then you have

to know uh a bit more stuff. So first

regardless you need to be familiar with

uh your tools, learn how to

debug, profile and test like get

comfortable with it. Uh for debug I

would say you can use foundaries

debugger. Uh you can use remix. There's

nothing shameful about using remix. I

use it all the time. um you have to know

how to profile like if you want to see

um the difference the guess difference

between two functions you need to

probably write two different contracts

and then uh pass in the same

inputs because uh you want to keep the

test as fair as possible. If you just

declare two functions and sometimes the

guess is so small that the function

dispatch might actually cost more than

the function you're testing itself. So

you need to uh get familiar with how to

profile your code. Well,

you don't need to remember everything.

For example, if you want to use uh inite

assembly to do your ABI encoding,

um you can use chiser or for testing to

see how solidly does it. Then you try to

mimic it uh try to copy it using your

inner assembly

and yeah just remember a few things and

figure out the rest of the fly.

So if you want to dive into inite

assembly um the first thing I'll say is

get very familiar with how solid handles

memory like the scratch space

uh the extended scratch space how do you

can abuse uh 0x40 and 0x60

safely

and how

uh memory arrays by strrus strings how

are they actually represented how are

allocated.

And you also need to know uh keep in

mind that when you go between regular

solidity and insembly,

the scrap space and free memory might be

dirty. The free memory pointer might not

be uh aligned to 32, a multiple of 32.

For example, if you ABI in code pack, it

will misalign the free memory pointer

sometimes.

And you also need to be wary that uh the

variables. For example, you pass in the

UI 160 or address into inner assembly.

Uh you need to be wary of the upper

bits. They might be dirty. And if you

assume that the upper bits are clean,

sometimes uh weird stuff will happen

which can cause bugs.

So um

you might want to know like where solid

inserts hidden overheads. For example,

if you use address core, you allocate

memory for the return data. If you use

ABI decode, you also allocates memory.

If the decoding data has some dynamic

types,

if you use target do something, this

might perform a ex code size check which

is 100 gas I think.

Yeah. Uh unless this uh function returns

a variable then it will use a return

data size to uh to check whether the

contracts exist instead of using scope

size.

Then you also need to understand the

limitations of try catch all this stuff

and

yeah

so how to build an understanding uh

I say if you really want to go into the

details to uh get a very good feel

uh of course rescues rescues is the one

of the best goes to but if you want to

DIY your experience

You can uh read some solidity contracts,

study it alongside soulmate or open

sampling. I would recommend starting

with uh examples like ERC20 because it

touches events, it touches uh

core data, it touches I think

pre-ompiles, it touches pretty much

everything events etc etc.

So I think YC20 is like uh not too

difficult to get a introduction also it

covers a lot of topics

then sometimes if you see uh ugly code

in so um you might want to question like

why is the code written in this way so

sometimes I intentionally duplicate code

because I know if I don't the compiler

might not inline it

sometimes I write the code in a way that

is not so optimized because I know that

uh this function may be caught once in

the blue moon. So instead of making it

like super gas efficient

uh for runtime and you bloat everyone's

contract uh you make everyone's contract

like super big and hit the 24 KDB limit.

Instead uh all these rarely used

functions I might write it in a way that

optimize for smaller back code size or

readability.

Then sometimes uh I might consider the

what is the most often used scenario and

optimize for that. For example the I

think the innumerable sets um most of

the time people won't store more than

three elements in their innumerable

sets. So I write the data structure in a

way that it doesn't store the indices

and the length until you exceed three

elements

and you might want to study how uh other

code base utilize so

I think this is

wow we actually uh only spent half an

hour. Yeah, if you want to know more,

you might use LLM assisted learning. Uh

there's no shame about it these days.

Like if

let me see. Oh yeah, if you follow uh

the developers on Twitter, sometimes uh

due to the

like we have to optimize for the Twitter

algo, that's why we make our post a bit

sensational.

uh we hide information nuggets inside

sheet post. Yeah. So you might want to

use a llm to make the learning curve

more gentle or if you prefer like uh a

more entertaining style you can like

see what developers post on Twitter but

then you will get a lot of uh a lot of

views here and there also.

Yeah. So I think that's pretty much it.

Let me see any questions people asking.

>> Um so I actually do have a question by

the way. Um have you been using any LLM

just to like optimize code or do you

even as of now do you use any AI tools

to like write smart contracts or

optimize it? Oh yeah, I I actually do

but uh I do in a very old school boomer

way. Um let let me exit this screen so

that I can go to so lady and show you

the example.

>> Mhm.

>> Oh yeah, we already in so Okay. So

are you able to see the screen? I'm

sharing the screen.

>> Yes. Yes. Yes. Under lady. Okay. So

let's go to one of the recent PRs.

Sh my my computer is lagging.

Please don't hang.

Okay.

Well, luckily it's not hanging. Okay.

Let's go. Uh uh

base 58.

I think this is a

one of the examples where

the LLM is pretty useful. So for

example, okay, I tell you what is this

PR about first. So base 58 uh base 58.

So, Solana address uh Bitcoin address

they use this encoding scheme called the

base 58. Uh

yeah, basically base 58 has some kind of

alphabets.

Uh yeah, the alphabets are here. 1 2 3 4

blah blah blah blah. Yeah, there's no I

down here. The I is replaced by one.

There's no L. So they try to make it uh

so-called human friendly so that uh

people don't typos and it ends up with

this very

compute unfriendly encoding scheme and

initially the way to do this is uh doing

it character by character like you

encode it character by character because

to do to encode a base 58 you

essentially have to do uh arbitrary

precision

integer math.

Mhm.

>> And

the the implementation Open Zeppelin

came up with at first is based off some

go implement go implementation which

operates character by character.

Uh and I was like this doesn't really

use the EVM to the fullest potential. So

the first thing uh I did is like I asked

I talked about the high level details

with chat GBT

and then I asked it to create a Python

uh reference.

Uh initially I asked it for like 64

bits.

Okay. I asked you to create a C

reference first. a C reference using 64

bit integers

64T and after that I asked it to uh do

it in Python using 24 U248

because uh

okay 2 48 bits is the maximum uh number

that can be safely

multiplied without overflowing uh for

base 58. So u 248 max multiply by 58 you

will still fit under u26 that's why I

use 248.

Yeah. So I asked the chat GPD to write

in a in a language he's more familiar in

which he has more data in and then I

asked it to tweak some parts such that I

know exactly uh how to convert into SMB

easier.

Yeah. So the idea the idea is uh don't

directly ask your LLM to produce the E9

assembly. It will probably fail and

it'll probably make some hideous bugs

that you cannot debug. So you start with

something that is more comfortable in

and then you slowly uh shape the

probabilities such that you nudge it

towards uh it's some I would say it's

kind of like asking your intern to do uh

step by step and but if you think it's

kind of like activating the weights in a

sequence that makes it more likely that

you will end up with a nice answer nice

final result.

So yeah,

you create a Python pseudo code. After

that, I convert it to assembly and then

I ask the chat GPT to double check my

work. I would say LMS are very good at

double-checking your work. Although they

might make some false positives,

I would say if you know what you need to

look for, LLM will be very good. So to a

senior deaf who knows like okay

obviously this this thing doesn't work

because it will overflow the LM LM might

not move it. it might produce some uh

thing that will overflow it and don't

realize that it actually happens because

the LM cannot simulate uh the

compilation and the running of solidity.

So you have to look out for this stuff

if you know everything you write it then

you just ask the LLM.

Yeah, you can consider it like a person

who helps you double check code, but

then you also have to scrutinize uh what

it tells you with what you know because

you know you have access to foundry and

you know you have all these background

information that you haven't

communicated to. So you have more

context in your head than what the LLM

has.

Yeah. So human LM hybrid

>> so don't really rely on the LLM it's

there just to like do a double check you

still need all those uh practices all

those optimization but chopdity can help

or AI tool any AI tool can like help you

verify that

>> yeah one one thing I uh one of my

critique about uh like agents like CL is

that you can't really uh guide

>> the path like the chain of thought when

you ask it something yeah it produce a

chain of thought but you can't actually

say hold on I I see you making some

wrong move down there can can I stop you

and guide you through another path I

think it's going to be better you can't

can't do that right so

I I still prefer the old school way like

you can really

have a more hands on how to guide the

LLM to towards

the solution.

>> Okay.

Interesting.

Okay. Super cool. Uh I don't see any

questions in the comments as such. But

do you have any example of like most

optimized contract like any DeFi

contract, any NFT contract?

>> Uh I think Do you think

>> C4 is probably the most ridiculously

optimized uh marketplace contract out

there

>> which

>> um C Open Cot is the most ridiculously

optimized.

>> Uh let me see.

>> Okay. Uh for

Soul Lady.

Okay. There are some contracts in so

that I will say is quite uh evil

evenly optimized.

>> Uh okay, let's let's start with uh bite

code proxies. Uh

so for example

li

where is it

lead clone.

So the thing about it clone is that uh

okay let's start with clone first. Uh D

clone is a for that allows you to deploy

minimal proxies. Minimal proxies

sometimes we call it clones and this

clone they are kind of handwritten.

Um,

oh, oh my god, my my GitHub is this this

file is so big that the ren the

rendering is breaking. Okay, anyway,

let's go back.

Yeah, I think this is gem.

Okay, so this

this uh stuff down here is the entire

back code for the clone contract.

uh you don't need to

okay this giant comment is just to

explain how this uh how the by code

works and the stack

operations so that you can manually

trace through to see how it works

then there are some stuff like uh

signature checker loop okay so we know

that it is possible to handcraft B code

contracts.

So we push that to the next level. Uh in

signature checker date uh we have this

thing called uh

ERC 6492 checker

there is some

contract down here.

This contract is

super ridiculous.

Let's see. Let's see.

Okay,

let's go to SC.

Okay. Okay. Nice.

is like

open.

Okay, let me close the pro.

So basically uh this contract is another

handcrafted bike code I would say uh

it's not exactly fully handcrafted

because I use U. U is a like a dialect

of it's a restricted uh I would say it's

a sub language of solid. It's an

intermediate form. So I I wrote the U

code down here. Okay. And then I use

some uh

I actually forgot how I wrote this but

this contract is written in a way such

that the code size

is

I abused code size. Code size is the two

G of code. I abuse it such that

uh the code size is used as a variable

to

for M store.

Yeah. What's this? What's this code size

exactly? I forgot. But anyway. Okay.

Yeah. And another thing is I think

there's an address somewhere. Uh

address. Where's the address?

Oh yeah. Here. 25 line 25 that there's

something called the address.

If you

go back to the solid iceberg, you see

this contract totally hits all the hits

a few of the lowest deepest uh stuff.

For example, two guest op code abuse,

create two address abuse, manual bite

code uh bite code crafting.

Yeah, it's one of the most uh

ridiculously uh

disgusting contracts out there.

Basically, I use the create to address

to store the function selector required

by

the ERC1271

and somehow craft the contract to have a

code size that

uh that can be used as a argument.

Yeah, this is uh I don't think you

should really do uh do this kind of

stuff in if you're not used to it. Like

this is once in the blue moon. You know

that you only need to write this once

and I don't think anyone has to write it

again.

>> Yeah, this is amazing.

any other DeFi contracts that you think

of recently uh that you have been

reading or anything that you want to

share?

I haven't been uh diving into uh DeFi

like recently. So um okay, most of my

time right now is working on uh smart

accounts especially the code code base.

>> Yeah.

>> Yeah. So

Okay.

>> Sorry.

>> Yeah. Go ahead. Go ahead.

>> Yeah. So, I was I'm going to say that uh

this contract Yeah. It abuses solely to

the maximum, but it's ridiculous. Uh the

amount of so abuse is

quite heavy. Um the the reason why this

thing is fast is because so is fast.

Yeah. Um

but there are some parts that we we

can't outsource so some parts we have to

>> write E9 SMB and pretty much the storage

in this account is very optimal. Um so

we use E9 for things like calls because

when you call maybe solid allocates

memory in the background you perform all

the redundant checks. Yeah.

Very interesting. Also, I wanted to talk

about CLZ op code. So,

>> oh yeah, the CLZ code.

>> Switch my screen. Yeah. Can you see my

screen?

>> Wait, should I stop sharing?

>> Uh, should be fine. But you can see my

screen right?

>> Let me let me check your check your

iPad.

Oh, yeah. I I'm seeing your screen from

my iPad.

>> Yes.

>> So what is CLZ of code? I mean a lot of

people don't know it. So just give uh a

brief intro what exactly it is and how

it's going to like optimize smart

contracts.

>> Okay. Um

let's go.

So um

CLZ is essentially uh a form of log to

uh log two to logarithm to it's not the

limit out code it's the log two log two

as in math base to log okay

I think it's somewhere here where is it

le bit yeah bit let's see so this thing

is

This not uh CL. Ah, this is CLZ.

So this chunk of code here is CLZ.

>> Mhm.

>> Um what are the use case bit maps you

want to find the next set bit I think

uh thick math. If you have some uh

something like a uni V3 or V4 and you

want to find the next thick uh you can

use this thing.

Uh if you don't use this thing uh you

might write a loop which is um

if else if else which is not efficient.

Okay it's not efficient. Uh so this is

like the most efficient way you can

write it right now in solidity and there

are some problems with this code. Okay

it's efficient. Uh the op codes here

yeah is is safe is uh formally verified

etc. But the thing is you see these op

codes are big.

So every time you call a CLZ it your

contracts has to have to store all these

all these junk you know

and it's I would say it's pretty uh

commonly used algorithm

for example

uh previously we talked about uh CD

compress using CD compress to compress

your strs in to store in storage let's

go to deep zip okay

then I can show you

more practical example.

For example, uh in we use CD compress.

>> Yeah.

>> Uh to compress the strct such that we

can fit into one storage slot.

Essentially we have CZ in CD compress.

Oh wait, wait. Sh I forgot. I am

>> yeah your screen is visible.

>> Okay. Yeah. So CD compressor has count

leading zero bytes which is a

specialization of CLZ. Okay. Because I

know I don't need to count the exact

number of zero leading bits. Uh so I

count the number of zero leading byes so

I can remove a few op codes.

Essentially, I still have to do this uh

all this fancy junk down here

which is

which which cause bite code you know all

this occupies bite code and people say

yeah we are keeping the spirus dragon

limit it's because of all these giant

magic constants you know all these giant

constants we are pushing the contracts

we are making the contracts fat

and all these cost guess gas every time

we do this this This is another

specialization is count the number of

leading zero bytes.

Yeah, all this cost guess. Uh

so let's say if you have a CLZ down here

like right here right now if you have

this magic op code we can throw away all

these constants uh each iteration maybe

will drop from

uh drop by I think in this case it will

be around 100 gas. Yeah, each iteration

will cost 100 gas less. And this thing

can be so efficient that you might not

want to manually pack your trucks ever

again. You might just call zip CD

compress. Uh in fact, right now this is

almost on parity with uh manual packing.

Like maybe the overhead of calling CD

compress is like uh a few hundred

guests.

I would say that's negligible compared

to uh SO or Stor. But with CZ, this

thing is like

>> Yeah, it makes it's almost no

difference. It might be even faster than

manually packing your struts.

>> Awesome. Uh there is one question that I

can see. Um what optimizations do you

suggest for AMMS?

>> AMMS?

>> Yeah, it depends what kind of EMM you

have. uh

>> is it a cl or like that kind of that

curve type? So depends on what kind of

curve you're using.

>> Uh

okay, first your math libraries have to

be efficient. Uh

I would say uh the fixed point meth lip

here is pretty efficient.

M

>> and then I I recall in uni V3 or V4 they

have all those giant magic constants. Um

those I think it's pretty much uh that

part is pretty much optimized to the

near the limit already. Uh it's just

that maybe some functions can be inline

further. For example, if you call the

CLZ, although I wrote it in like a

branchless form so that it tends to get

inline, sometimes the compiler just

refused to inline and when the compiler

refused to inline, you'll incur a

internal function call overhead which is

like a push then uh jump and something.

So depend on how many arguments it can

be around

60 guess which is quite irritating. So

for example, you want to call this uh

183 guess. See how that the function

internal function call over here like 60

guess which is irritating.

Yeah. If you call in a loop then there

it will be even more uh

it'll be more irritating.

Yeah. So you just I think you have to

profile it depends on your code base

because uh depending on your code base

solidity might choose to not inline some

functions

like if it detects oh your maybe your

contract is over hitting the spirit I

might not want to this thing.

Yeah.

>> All right. Um other than that I really

don't see any questions in the comments.

Um so I think we will wrap it up but at

the end do you have any other tips or

anything you want to conclude with?

Uh I I would say that um

to get good like super duper good like

top few% good you probably have to be

you probably have to get some background

knowledge. For example uh this

okay this function I'm looking at the

lawn what is by this legendary guy

called Remo

and

there's a whole

He wrote a whole series of articles of

like how he used like Chevy chef

approximation to come up with all this

stuff.

>> Yeah. So if you want to like create new

math uh create new algorithms

uh you might need to go beyond knowing

how to uh like abuse EVM outputs. You

might have to like go to more

traditional

areas and then import the ideas from

there.

[Music]

>> Yeah, thanks. Um, in the comments

someone is saying that everyone's brain

has now melted. So, this was an amazing

session.

>> Yeah. So, for example, wait. Oh, there

are six more minutes. Okay. One recent

function I I wrote some somewhere.

What's the function? Let me see. Scroll

mouse square root. Uh for example, mouse

square root. Okay.

Also called a geometric mean. So if your

math is pretty uh like if you come from

at least you didn't forget your

undergrad math lessons uh you might

recall that yeah if you

you want to find a square root

essentially this function is trying to

find a square root of a 512 512 bit

number

uh to the accurate to the way. Yeah, the

stuff here is really accurate to

um

you have to do this thing called a baby

nonion method and

the thing about baby nonion is that if

you start at the overestimate it

converges super fast but if somehow your

initial guess is a underestimate

uh it converges super slowly. So using

this knowledge you can like craft some

very good heristics that enable your

starting guest to be very uh very

conducive to the baby nomian network

method. Yeah it's like knowing all these

kind of uh like recurring what you learn

in uh undergrad or probably in grad

school. Yeah that can help you quite a

lot.

>> Yeah.

>> Yeah.

Cool. Um, awesome. Then let's conclude

the session. I hope everyone liked it.

The re recording will be available on

YouTube so you can like re-watch it. I

will also upload it upload it again on

YouTube so you guys can watch it. This

was an amazing session and if you guys

are new to like the crypto ecosystem,

you can go to Alchemy University. We

have a lot of courses where you can just

start learning and start building. And

then at alchemy also we have a lot of

blogs on solidity on how to build

onchain applications. So you can check

that out and all the sources that also

vector mentioned in his presentation uh

you can check those out as well. Okay

awesome. Thank you so much sir.

>> Thank you.

>> Yeah.