Co jest potrzebne, aby rzeczywiście uruchomić sieć Ethereum z obsługą zk i odporną na kwanty? W tym odcinku (5/6 serii Lean Ethereum) Raúl i Will z @ethereumfndn zmieniają fokus z prymitywów na integrację systemów: sieciowanie, koordynację i interoperacyjność klientów. Dyskusja koncentruje się na tym, jak podpisy odporne na kwanty i agregacja oparta na zk wpływają na warstwę sieciową i projekt protokołu end-to-end. Poruszają: – Dlaczego podpisy odporne na kwanty wprowadzają nietrywialne ograniczenia ze względu na rozmiar, wymagając przeprojektowania propagacji, agregacji i wykorzystania pasma – Rola DevNetów jako iteracyjnych środowisk integracyjnych: od podstawowej interoperacyjności → generacji podpisów → agregacji → rekurencyjnej kompozycji – Ograniczenia sieciowe w ramach EIP-7870: ograniczona przepustowość, wrażliwość na opóźnienia i potrzeba optymalizacji pod kątem „dobrego przepływu” zamiast surowej przepustowości – Przejście od burzliwej propagacji opartej na plotkach do ciągłego przepływu danych w potokach, gdzie podpisy są stopniowo agregowane w różnych topologiach sieciowych – Kompromisy w projektowaniu topologii: podsieci, hierarchiczna agregacja, redundancja i rozważania dotyczące przeciwników (np. unikanie identyfikowalnych punktów agregacji) – ETH P2P jako celowo zbudowany stos sieciowy, zastępujący ogólne komponenty libp2p mechanizmami takimi jak kodowanie erasure i strukturalne routowanie – Koordynacja między warstwami: kryptografia, implementacja klientów, sieciowanie i metryki, z wspólną obserwowalnością do oceny opóźnień, duplikacji i zbieżności finalności Obejrzyj cały odcinek