gakonst

15-20 % rychlejší zpracování Ethereum bloků na Reth v1.5.0.

více přichází!

nejasné, proč by to mohl být nepopulární názor na CT, ale: myslím, že uniswap truck je úžasný.

Pokud jste inženýr Reth a pracujete s náboráři, neváhejte se na mě obrátit přímo.

Vytvořili jsme roli inženýra Reth jako jednu z nejdůležitějších rolí pro budoucnost kryptoinfrastruktury a máme spoustu rolí v portfoliu. Představím vás.

Můžete vytvořit stablecoin z derivátů hashrate bitcoinu?

Uživatelé by neměli platit poplatky za plyn, aplikace by měly.

Příklad NextJS pro sponzorování poplatků v Portu právě dorazil (odkaz v vlákno)

Frontiers od @Paradigm aktualizace! 6.-8. srpna SF.

Den 2 vypadá 🔥🔥🔥 .

Ne jeden, ne dva, ale tři přednášky o vysokém výkonu!
- "Hyperoptimalizace Reth" od @ashekhirin a @Rjected
- „Škálování stavového Trie Ethereum“ od @brianisbland
- "Škálování Ethereum L1" od @adietrichs.

Přihlaste se níže!

Jaký je nejrychlejší folding / IVC SNARK v současnosti?

Má optimalizovanou implementaci?

Stále hledáme odborníka na konsensus ohledně gadgetů pro konečnost na základě podílu pro blockchainy s důkazem o práci, bonusové body, pokud jste studovali důkaz užitečné práce / struktura trhu MEV atd.

bylo by skvělé, kdyby moje krypto sociální grafika zůstávala technická, když se ve světě něco děje, nebo se držela demokratických a mírotvorcích názorů, prostě lépe, vzhledem k tomu, že krypto má být technologií pro globální svobodu a mír

Věci, které nakonec nepomohou Ethereu vyhrát v Glamsterdamu: EOF, EVM64, SSZ/pureth, dostupné atestace.

Potřebujeme silnou ofenzivu, ne slabou ofenzivu, a rozhodně ne dlouhodobou obranu. Krátkodobá obrana (např. přecenění) je dobrá.

RE: co by mělo být s Ethereum's EL, můj aktuální názor je:
- Fusaka dosahuje snadných vítězství a nastavuje stropy pro zvyšování limitu plynu.
- Glamsterdam pokračuje ve zvyšování limitu plynu a přehodnocení na základě nejhorších možných výsledků.

Můj bláznivý názor může být, že po Glamsterdamu, kromě dalšího přehodnocení a zvyšování limitu plynu, musíme přejít k optimalizaci EL pro použití ZK, cokoliv to může znamenat.

Fusaka se letos uskuteční a umožní L2s dále škálovat.

Bloby zůstanou při spuštění stejné a s předem naplánovanými forky pouze blobů se doufá, že se dostanou až na 48 kolem Q1'26.

Budeme pokračovat v měření a uvidíme, jak vysoko se dostaneme, nástroje jsou k dispozici, teď už jen zástupci.

zlepšujeme se v používání AI k zvyšování naší produktivity a posilování komunity otevřeného zdroje.

v této PR sdílíme výzvy, kde Claude úspěšně vytvořil kontroler pro EVM volání pro Forge Lint (běží ve výchozím nastavení při sestavení forge)

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

Co považuji za důležité, aby Ethereum zvítězilo, zatímco si udržuje globální sadu uzlů:

1. oddělit validaci od budování bloků pomocí zk. To vyžaduje usnadnění vytváření zk důkazů v reálném čase: ePBS nebo Zpožděné provádění, je mi jedno, které. migrace trie pomáhají, ale podle mého názoru nejsou nezbytné, zatímco zajištění, že neprokazujete na konci slotu, ale na začátku, opravdu záleží.

2. oddělit odolnost vůči cenzuře od nejslabšího uzlu. Pokud uděláte výše uvedené, zavedení uzlů s nízkým stakem ETH s FOCIL, kteří jsou zodpovědní pouze za CR, ale ne za budování a validaci bloků horké cesty, nás osvobozuje od raspberry pi pro škálování, ale umožňuje nám i nadále používat raspberry pi pro CR.

Co považuji za důležité, aby Ethereum vyhrálo při zachování globální sady uzlů:

1. oddělit validaci od stavby bloků pomocí zk. Je třeba usnadnit zk prokazování bloků v reálném čase: ePBS nebo Odložené vykonání, je mi jedno, které. Migrace trie pomáhají, ale podle mého názoru nejsou nutné, zatímco zajištění, že neprokazujete na konci slotu, ale na začátku, opravdu záleží.

2. oddělit odpor k cenzuře od nejslabšího uzlu. Pokud uděláte výše uvedené, zavedení uzlů s nízkým stakem ETH, kteří jsou odpovědní pouze za CR, ale ne za budování bloků a validaci v horké cestě, nás osvobozuje od raspberry pi pro škálování, ale umožňuje nám pokračovat v používání raspberry pi pro CR.

Stále mě udivuje, že komunitě vývojářů Ethereum Core Dev nezáleží na opravě dvou nejčastěji citovaných problémů vývojářů EVM podle průzkumu Solidity Lang, navzdory našim opakovaným snahám:

1. Příliš hluboká zásobník: Ano, to je trochu problém dovedností Solidity, ale stačí přidat rozsah opcode SWAP/DUP17-32 a je to. Spálíte nějaké opcode. To je v pořádku, mají být používány. Budete mít další nesoulad ve stylu PUSH0, to je také v pořádku, není to dokonalé, ale je to v pořádku.

2. Zvyšte limit 24KB. Opravdu mi nezáleží na tom, co uděláte, udělejte to 32KB, 48KB, 128KB, 256KB, 512KB, udělejte to všechno najednou, postupně, cenu nastavte nebo ne, ale udělejte něco! Teď, ne příští rok!

Pokud škálujete L1, zajištění, že lidé mohou psát smlouvy bez hloupých chyb, je P0.

Pokud systém nemůže zvládnout dodatečných 8KB na bytecode, což je parametr, který byl nastaven před 10 lety, pak není šance, že budete schopni skutečně škálovat L1.

Opravit příliš hlubokou zásobník a limit velikosti bytecode! Pro vývojáře!

Stále mě překvapuje, že komunita vývojářů Ethereum Core Dev nepřikládá prioritu opravě 2 nejčastěji citovaných problémů vývojářů EVM podle průzkumu Solidity Lang:

1. Příliš hluboká zásobník: ano, to je trochu problém dovednosti Solidity, ale prostě přidejte rozsah opcode SWAP/DUP17-32 a hotovo. Spálíte nějaké opcode. To je v pořádku, mají být používány. Budete mít další nesoulad jako PUSH0, to je také v pořádku, není to dokonalé, ale je to v pořádku.

2. Zvyšte limit 24KB. Opravdu mě nezajímá, co uděláte, udělejte to 32KB, 48KB, 128KB, 256KB, 512KB, udělejte to všechno najednou, postupně, ohodnoťte to nebo ne, ale udělejte něco! Teď, ne příští rok!

Pokud škálujete L1, zajištění toho, aby lidé mohli psát smlouvy bez hloupých chyb, je P0.

Pokud systém nedokáže zvládnout dalších 8KB na bytecode, což je parametr, který byl nastaven před 10 lety, pak není šance, že skutečně dokážete škálovat L1.

Opravit příliš hlubokou zásobník a limit velikosti bytecode! Pro vývojáře!

Stále mě udivuje, že komunita vývojářů Ethereum Core neprioritizuje opravu nejcitovanějšího problému vývojářů EVM podle průzkumu Solidity Lang

1. Příliš hluboká zásobník: ano, to je trochu problém dovedností Solidity, ale stačí přidat rozsah opkódů SWAP/DUP17-32 a je to. Spálíte nějaké opkódy. To je v pořádku, mají být použity. Budete mít další nesoulad jako u PUSH0, to je také v pořádku, není to dokonalé, ale je to v pořádku.

2. Zvyšte limit 24KB. Opravdu mi nezáleží na tom, co uděláte, udělejte to 32KB, 48KB, 128KB, 256KB, 512KB, udělejte to všechno najednou, postupně, stanovte cenu nebo ne, ale něco udělejte! Teď, ne příští rok!

Pokud škálujete L1, zajistit, aby lidé mohli psát smlouvy bez hloupých chyb, je P0.

Pokud systém nedokáže zpracovat dalších 8KB na bytový kód, což je parametr, který byl nastaven před 10 lety doslova, pak není šance, že budete moci skutečně škálovat L1.

Opravit příliš hluboký zásobník a limit velikosti bytového kódu! Pro vývojáře!

Každý kus kryptoinfrastruktury se dotkne Reth jedním nebo jiným způsobem.

Nejdůležitější věcí pro jeho úspěch je bezpochyby OSS komunita. Vyškolená skupina více než 500 geograficky rozptýlených lidí, kteří přispěli k Reth a věří v jeho vizi a dlouhodobý úspěch.

Na technické úrovni má projekt Reth 3 pilíře:
- Bezpečnost: Toho dosahujeme podporou Ethereum L1 v produkčních stakingových prostředích. Skin in the game.
- Výkon: Toho dosahujeme posouváním hranic na L2 a MEV Block building. Terragas.
- Rozšiřitelnost: Poskytujeme vynikající API pro modifikaci vaší uzlu bez forkování. Reth SDK.

Je toho ještě mnohem víc, co dělat, ale jsme opravdu hrdí na to, kde jsme dnes.