gakonst

15-20% szybsze przetwarzanie bloków Ethereum w Reth v1.5.0.

więcej wkrótce!

niejasne, dlaczego to może być niepopularne zdanie na temat CT, ale: uważam, że ciężarówka uniswap jest niesamowita.

Jeśli jesteś inżynierem Reth i pracujesz z rekruterami, śmiało skontaktuj się ze mną bezpośrednio.

Stworzyliśmy rolę inżyniera Reth jako jedną z najważniejszych ról dla przyszłości infrastruktury kryptograficznej, a w naszym portfolio mamy mnóstwo ról. Przedstawię cię.

Can you create a stablecoin out of bitcoin hashrate derivatives?

Users shouldn't pay gas fees, apps should.

NextJS example for fee sponsoring in Porto just landed (link in thread)

Frontiers by @Paradigm update! Aug 6-8 SF.

Day 2 is looking 🔥🔥🔥 .

Not 1, not 2, but 3 talks on high performance!
- "Hyperoptimizing Reth" by @ashekhirin & @Rjected
- “Scaling Ethereum's State Trie” by @brianisbland
- "Scaling Ethereum L1" by @adietrichs.

Apply below!

What's the fastest folding / IVC SNARK atm?

Does it have an optimized implementation?

Nadal szukam eksperta ds. konsensusu w zakresie urządzeń finalności opartych na stawkach dla blockchainów opartych na dowodzie pracy, punkty bonusowe, jeśli studiowałeś dowód użytecznej pracy / strukturę rynku MEV itp.

would be awesome if my crypto social graph kept it technical when things are happening in the world or stuck with democratic and peace making takes, just better given crypto is supposed to be tech for global freedom and peace

Things that are ultimately not gonna help Ethereum win for Glamsterdam: EOF, EVM64, SSZ/pureth, Available Attestations.

Need strong offense, not weak offense, and definitely not long term defense atm. Short term defense (eg repricings) are good.

RE: co powinno się stać z EL Ethereum, moje obecne zdanie jest następujące:
- Fusaka zdobywa łatwe wygrane i ustala limity podnoszenia limitu gazu.
- Glamsterdam kontynuuje powyższe podnoszenie limitu gazu, jednocześnie przeliczając na najgorsze możliwe wyniki.

Moje szalone zdanie może być takie, że po Glamsterdamie, poza dalszym przeliczaniem i podwyższaniem limitu gazu, musimy przejść do optymalizacji EL pod kątem użycia ZK, cokolwiek to może znaczyć.

Fusaka odbędzie się w tym roku i umożliwi L2 dalsze skalowanie.

Bloby pozostaną takie same przy uruchomieniu, a dzięki zaplanowanym wcześniej forkom blobów, powinny wzrosnąć do 48, miejmy nadzieję, że około Q1'26.

Będziemy nadal mierzyć i zobaczymy, jak wysoko możemy sięgnąć, narzędzia są dostępne, teraz tylko reprezentanci.

we are getting better at using AI to improve our productivity and empower the open source community.

in this PR we share the prompts where Claude successfully built a low level EVM call checker lint for Forge Lint (runs by default on forge build)

https://github.com/foundry-rs/foundry/pull/10810

What I think is important for Ethereum to win while maintaining a global node set:

1. decouple validation from block building throughout with zk. this needs making zk proving blocks in real time easier: ePBS or Delayed Execution, I don't care which. trie migrations help but imo not needed, whereas ensuring you don't prove at the end of the slot but at the start really matters.

2. decouple censorship resistance from weakest node. If you do the above, introducing low-ETH staked nodes w FOCIL who are responsible just for CR but not for the hot path block building and validation liberates us from raspberry pis for scaling but let's us continue using raspberry pis for CR

What I think is important for Ethereum to win while maintaining a global node set:

1. decouple validation from block building throughout with zk. this needs making zk proving blocks in real time easier: ePBS or Delayed Execution, I don't care which. trie migrations help but imo not needed, whereas ensuring you don't prove at the end of the slot but at the start really matters.

2. decouple censorship resistance from weakest node. If you do the above, introducing low-ETH staked nodes who are responsible just for CR but not for the hot path block building and validation liberates us from raspberry pis for scaling but let's us continue using raspberry pis for CR

I'm still baffled that the Ethereum Core Dev community does not prioritize fixing the 2 most cited problem of EVM developers per the Solidity Lang survey despite our repeated efforts:

1. Stack too Deep: yes this is a Solidity skill issue a little bit but just add a SWAP/DUP17-32 opcode range and call it a day. You will burn some opcodes. It's fine, they are meant to be used. You're gonna have another PUSH0-style mismatch, this is also fine, it's not perfect but it's fine.

2. Lift the 24KB limit. I don't really care what you do, make it 32KB, 48KB, 128KB, 256KB, 512KB, do it all at once, incrementally, price it or not but do something! Now, not next year!

If you are scaling the L1, ensuring people can write contracts without stupid errors is P0.

If the system cannot handle an extra 8KB per bytecode which is a param that was set 10yrs ago literally then there's no chance you will be able to actually scale the L1.

Fix stack too deep and bytecode size limit! For the devs!

I'm still baffled that the Ethereum Core Dev community does not prioritize fixing the 2 most cited problem of EVM developers per the Solidity Lang survey:

1. Stack too Deep: yes this is a Solidity skill issue a little bit but just add a SWAP/DUP17-32 opcode range and call it a day. You will burn some opcodes. It's fine, they are meant to be used. You're gonna have another PUSH0-style mismatch, this is also fine, it's not perfect but it's fine.

2. Lift the 24KB limit. I don't really care what you do, make it 32KB, 48KB, 128KB, 256KB, 512KB, do it all at once, incrementally, price it or not but do something! Now, not next year!

If you are scaling the L1, ensuring people can write contracts without stupid errors is P0.

If the system cannot handle an extra 8KB per bytecode which is a param that was set 10yrs ago literally then there's no chance you will be able to actually scale the L1.

Fix stack too deep and bytecode size limit! For the devs!

I'm still baffled that the Ethereum Core Dev community does not prioritize fixing the most cited problem of EVM developers per the Solidity Lang survey

1. Stack too Deep: yes this is a Solidity skill issue a little bit but just add a SWAP/DUP17-32 opcode range and call it a day. You will burn some opcodes. It's fine, they are meant to be used. You're gonna have another PUSH0-style mismatch, this is also fine, it's not perfect but it's fine.

2. Lift the 24KB limit. I don't really care what you do, make it 32KB, 48KB, 128KB, 256KB, 512KB, do it all at once, incrementally, price it or not but do something! Now, not next year!

If you are scaling the L1, ensuring people can write contracts without stupid errors is P0.

If the system cannot handle an extra 8KB per bytecode which is a param that was set 10yrs ago literally then there's no chance you will be able to actually scale the L1.

Fix stack too deep and bytecode size limit! For the devs!

Every piece of crypto infra will be touching Reth one way or another.

The most important thing for it's success is by far the OSS community. A trained group of >500 geo distributed people that have contributed to Reth and are bought into the vision and its long term success.

On a technical level, the Reth project has 3 pillars:
- Security: We get that by supporting Ethereum L1 in production staking environments. Skin in the game.
- Performance: We get that by pushing the frontier on L2s and MEV Block building. Terragas.
- Extensibility: We provide excellent APIs for modding your node without forking. Reth SDK.

So much more to do, but really proud of where we are today.