Fusaka upgrade na de veranderingen in bandbreedte per Ethereum node type Ik deel een geweldig document dat is gevalideerd door het open-source buildersteam ethPandaOps met betrekking tot de toepassing van PeerDAS in de devnet-omgeving. (Originele tekst in de reacties) De belangrijkste upgrade van Fusaka is PeerDAS. Ethereum heeft een aparte ruimte genaamd Blob waar L2's hun rollups uitvoeren. Met de toename van het gebruik van L2 ontstaat er vraag naar een snelle uitbreiding van deze Blob-ruimte. Maar het oneindig vergroten van de Blob zal leiden tot een toename van de specificaties van Ethereum L1, wat zal resulteren in centralisatie. Daarom is Ethereum van plan om deze Blob-ruimte te sharden, zodat validators deze kunnen opslaan (Danksharding), en de tussenstap is de PeerDAS die nu wordt geïntroduceerd. Met PeerDAS kan het aantal Blobs geleidelijk worden uitgebreid, terwijl de toename van de bandbreedte van individuele nodes tot een minimum wordt beperkt. Het proces en de resultaten van de experimenten van het ethPandaOps-team zijn te vinden in de originele tekst die in de reacties is bijgevoegd. Als we alleen het conclusie-gedeelte van deze post overnemen, dan is het als volgt: Bij uitbreiding van de Blobs op het Ethereum mainnet tot 14 na Fusaka, zijn hier de vereiste specificaties en veranderingen in bandbreedte per node type. 1⃣ Supernode (staking node met meer dan 4096ETH) Supernodes moeten zich abonneren op alle 128 subnetten en moeten alle gegevens gedurende de 18 dagen dat de blob-data wordt bewaard, opslaan. Supernodes fungeren feitelijk als de "ruggengraat" van het Ethereum-netwerk en hebben de grootste P2P-bandbreedte en DA-verwerkingsbelasting. De netwerkkapaciteit is normaal gesproken meer dan 100Mb/s en moet pieken tot 400Mb/s kunnen verwerken. Over het algemeen wordt dit beheerd door een professioneel validator-team dat is gebaseerd op infrastructuur en expertise. 2⃣ Thuis-staker (solo-staker, 32ETH) Voor een solo-staker node die 32ETH stake, is het voldoende om zich alleen te abonneren op de 8 toegewezen subnetten en de subnetten van de willekeurige kolommen. Omdat ze minder dan 1/8 van de gegevens van supernodes hoeven te verwerken, zijn de vereiste specificaties aanzienlijk verminderd. Wat betreft de bandbreedte is ongeveer 25Mb/s voldoende. 3⃣ Full node (geen validator) Voor een eenvoudige full node die geen validatie uitvoert, is het voldoende om zich alleen te abonneren op 4 kolom-subnetten. Ze verwerken precies 1/32 van de gegevens van supernodes, waardoor de P2P-bandbreedte, schijfgebruik en CPU-eisen aanzienlijk verminderen. De deelname aan het netwerk kan met een zeer lage bandbreedte van 4-8Mb/s. ...