Posledních pár týdnů jsem nesdílel mnoho aktualizací o @ethrex_client, našem @class_lambda @ethereum L1 exekučním klientovi a ZK L2 stacku. Sledujte @ethrex_client a dozvíte se více o všem, co děláme. V L1 již úspěšně provozujeme testovací sítě Ethereum a v L2 provozujeme testovací sítě pro identitu a aplikace DeFi, pro které a s partnery a které vytváříme. Upřímně věřím, že jsme blízko k tomu, abychom měli nejjednodušší kódovou základnu a zásobník pro údržbu, upgrade a úpravy v Ethereu. Tohoto bodu bychom se nemohli dostat bez kontroly kódu @NethermindEth a @go_ethereum S mými partnery @rj_aligned, @fran_aligned z @alignedlayer a @SantiDiPaolo @AguuMg z @PolFinance_ se chystáme vydat jeden z prvních whitepaperů o RWA L2s, který bude poháněn Ethrexem a @alignedlayer. Chystáme mnoho dalších, ale z tohoto jsem obzvláště nadšený, protože překlene velmi zajímavý případ použití TradFi a DeFi. Jako poradce a partnery jsme získali některé z nejsilnějších týmů v oboru. Těším se, až se s vámi o tomto projektu podělím více. Aktualizace L1 Pracujeme na mnoha frontách. Vylepšili jsme pozorovatelnost pomocí Grafany, odstranili nepoužívané funkce, abychom zjednodušili základ kódu, a přidali jsme podporu pro koncový bod "engine_getBlobsV1". Seznam změn: feat(l1): Koncový bod požadavku engine_getBlobsV1 (#3636) Chore(L1): Odebrání podpory redB (#4103) Refaktor (L1): Odebrání nepotřebných USIZES z blockchainové bedny (#4110) Oprava (L1): Odstraněn zbytečný klon stavu (#4117) Oprava (L1): Použijte správný obrázek Dockeru k roztočení localnetů. (#4131) Chore(L1): Přidejte čas bloku na řídicí panel Grafana. (#4112) fix(l1): odečte časy čtení DB od provádění bloku. (#4051) chore(l1): vylepšení metriky. (#4118) Chore (LEVM): Zlepšení organizace nového spouštěče testů LEVM (#3958) L2 V souladu s naším minimalistickým přístupem jsme odstranili značné množství kódu z nepoužívaných L2 databází. Pokračujeme ve zjednodušování kódové základny a eliminaci mrtvého kódu. Kromě toho byl CI stabilizován po opravě chyby související s cenami plynu. Benchmarking L2 provádíme na dvou frontách: - Náklady na údržbu L2 sítě: Ladíme parametry L2 simulací různých scénářů s různým transakčním zatížením a konfiguracemi sítě. Cílem je určit přibližné náklady na provizi za údržbu na transakci, které musí uživatelé nést, aby síť dosáhla soběstačnosti. - Izolované benchmarky generování důkazu o provedení bloků: Pomocí nástroje ethrex-replay dokazujeme bloky z Hoodi, Sepolia a Mainnet, abychom identifikovali potenciální chyby v kódové základně a změřili výkon našeho proveru. Na straně ethrex-replay je nástroj dostatečně stabilní a máme infrastrukturu nastavenou tak, aby pravidelně přehrávala provádění bloků a důkazů veřejných sítí. Nyní řešíme chyby, které se objevily během těchto běhů. Některé chyby pramení z logických chyb v ethrexu, zatímco jiné souvisejí s využitím paměti. Ty první jsou většinou vyřešeny a v těch druhých dosahujeme významného pokroku. Začali jsme se také zabývat @ziskvm a @0xLita ZKVM pro potenciální krátkodobou integraci. Již nyní podporujeme @RiscZero a @SuccinctLabs. Tento týden jsme sloučili PR, které stabilizuje ethrex-replay, což nám umožňuje identifikovat a vyřešit dvě chyby v ethrexu. Tyto opravy byly také sloučeny. První chyba se týkala okrajového případu v naší předkompilaci ecrecovery, kde konkrétní vstup způsobil selhání provádění kvůli nesouladu plynu. Po důkladném prošetření jsme problém vystopovali až do oficiální knihovny secp256k1 s opravou SP1. Vyřešili jsme to migrací na knihovnu k256 s opravou SP1. Druhá chyba pramenila z nesprávného předpokladu o bitové délce typu usize v části kódové základny. Abychom podobným problémům předešli, provedli jsme komplexní revizi základu kódu a odeslali několik žádostí o přijetí změn, abychom omezili využití usize na dva konkrétní případy: indexování a scénáře omezené rozhraním API nebo knihovnou. Kromě toho přidáváme podporu pro spouštění testovacích sad EF, včetně blockchainových a stavových testů, s SP1, abychom rozšířili naše testovací pokrytí a zajistili robustnost v různých scénářích provádění. Po vyřešení těchto chyb již k problémům nedochází. Úspěšně přehráváme nové bloky Hoodi a Sepolia a provádění bloků Mainnet se výrazně zlepšilo, přičemž úspěšnost provádění SP1 vzrostla z 1/10 na 6/10. Tento pokrok otevírá cestu k řešení zbývajících problémů s nedávnými přehráními bloků: chyby z důvodu nedostatku paměti během provádění bloku v zkVM SP1 a problémy s výkonem při provádění a dokazování. Abychom tyto problémy vyřešili, nastavili jsme bednu nástroje pro profilování paměti pomocí bedny Jemalloc. Pracujeme také na podpoře přehrávání historických bloků. MVP pro tuto funkci je v konceptu žádosti o přijetí změn a funguje dobře s klienty ethrex, reth a geth, ale dochází k problémům s klienty nethermind. Před vydáním první verze se snažíme optimalizovat požadavky RPC tak, aby bylo zajištěno přesné stahování dat o blocích, a to i při použití bezplatných poskytovatelů RPC pro většinu bloků. Vylepšení DevEx: - Opravili jsme naše binární sestavení tak, aby již nevyžadovala CUDA jako výchozí závislost na určitých operačních systémech a architekturách. Tato oprava je součástí nejnovější verze. - Bylo předloženo PR k aktualizaci verze ethrexu v rexu, čímž je zajištěna kompatibilita s nejnovějšími změnami v ethrexu L2. - Začali jsme vyvíjet novou záložku pro monitor ethrex L2 ve vývojovém prostředí. Na této kartě se zobrazí informace relevantní pro vývojáře, jako je seznam bohatých účtů a adresy kontraktů L1 a L2. Seznam změn: - refaktor (L2): nahrazeny rozdílové konstanty stavu usize. - REATURE(L1,L2): Nakonfigurovaný Ethrex-Replay pro profilování paměti. - Refactor(L1): Odstraněno zbytečné používání USIZE v Blockchain Crate (související s opravou chyby). - Feature(L1,L2): přidány nové příkazy do kopie spuštění. - Fix (LEVM): Vyřešeny problémy související s 32bitovou architekturou (související s opravou chyby). - Refactor(LEVM): Aktualizována implementace ECCrePp pro použití K256 místo Secp256K1 (související s opravou chyby). - ci(l1,l2): oddělil sestavení GPU a přijal cíl x86-64-v2. Představení Tento týden jsme se dále zaměřili na spotřebu procesoru a benchmarky. Pokud jde o spotřebu procesoru, identifikovali jsme 2 různé případy, jeden, kdy je vytváření bloků přítomno, a druhý, kde není. Upřednostňujeme ty bez vytváření bloků, protože jsou vždy přítomny a ovlivňují další snahy (jako je snap sync). Pokud jsme to zkoumali, je to zcela související s p2p. V tomto ohledu budeme pokračovat v našem úsilí Pokud jde o benchmarky, po našem vylepšení výkonu modexpu v minulém týdnu jsme se zaměřili na některá zjištěná vylepšení, jako je codecopy a související operace, stejně jako signextend, mulmod a addmod. Budeme se i nadále zaměřovat na spotřebu procesoru a výkon testů, které jsme identifikovali jako další kroky pro možná vylepšení, jako jsou přenosy eth a další operační kódy levm.