PANews a raportat pe 27 iulie că, ca răspuns la remarcile dezvoltatorului Ethereum Péter Szilágyi, că Ethereum devine din ce în ce mai mult „verificare descentralizată, dar control centralizat”. Vitalik Buterin poate confirma că această opinie este greșită, care tocmai a participat la Atelierul de cercetare EF de săptămâna trecută, unde au avut loc diverse discuții despre cum să minimizeze centralizarea. include:
O scufundare profundă în multi-proponeri pentru a vedea dacă rolul de constructor poate fi eliminat complet
Maximizarea puterii de includere pe liste (FOCIL)
Gândurile despre alegerea furculiței depinde de includerea tranzacției
Analiza Orbit SSF și idei pentru accelerarea implementării mecanismului Orbit, care ar putea reduce depozitul minim de peste 10 ori înainte de a face SSF
Construcție bloc distribuită pentru PeerDAS:
Analiza rețelei și optimizarea lățimii de bandă pentru PeerDAS și fullDAS
Faceți recuperarea de la 51% atacuri mai automatizată și mai puțin dependentă de „stratul social”
Asigurați-vă că listele de includere se aplică pe deplin la (i) tranzacții blob și (ii) cu abstracția conturilor native (de exemplu, EIP-7560)
Potrivit știrilor anterioare, dezvoltatorul de bază Ethereum Péter Szilágyi (karalabe.eth) a scris pe Twitter că viitoarea direcție a Ethereum, PeerDAS, intenționează să mărească dimensiunea blocului de date la 32 MB în următoarea actualizare, ceea ce va avea un impact negativ asupra producătorilor locali de blocuri. . El a subliniat că timpul de propagare a blocului Ethereum este foarte strict, cu doar 4 secunde pentru a propaga blocul în întreaga rețea. Deși PeerDAS împarte subrețelele, trebuie totuși să răspândească 32 MB de date în 4 secunde, ceea ce este o povară insuportabilă pentru nodurile de acasă.