Vitalik, Ethereum L1'i basitleştirmeyi ve protokolü beş yıl içinde Bitcoin kadar basit hale getirmeyi hedefliyor

BlockBeats, Ethereum'un kurucu ortağı Vitalik Buterin'in 3 Mayıs'ta Ethereum'un amacının bir "dünya muhasebe defteri" olmak olduğunu belirten bir blog yazısı yayınladığını bildirdi: medeniyet varlıklarını ve kayıtlarını depolamak için bir platform ve finans, yönetim ve yüksek değerli veri doğrulaması için temel bir katman. Bunun için iki şeye ihtiyaç var: Ölçeklenebilirlik ve dayanıklılık. Bu yazının amacı, dayanıklılığın (ve nihayetinde ölçeklenebilirliğin) son derece önemli, ancak kolayca hafife alınan bir yönüne odaklanmaktır: protokol basitliği. Bitcoin'in en güzel yanlarından biri protokol tasarımının son derece basit ve zarif olmasıdır. Protokolün basit tutulması Bitcoin veya Ethereum'un güvenilir, tarafsız ve küresel olarak güvenilen bir altyapı katmanı olmasına yardımcı olur. Ethereum geçmişte bu konuda sık sık yetersiz kalmıştı ve bu yazıda Ethereum'un önümüzdeki beş yıl içinde Bitcoin kadar özlü hale nasıl gelebileceğini tartışacağız.

Basitleştirilmiş mutabakat katmanı: Yeni mutabakat katmanı (eski adıyla "Beam Chain"), son on yılda mutabakat teorisi, ZK-SNARK geliştirme, hisse ispatı ekonomisi ve diğer alanlarda edindiğimiz tüm deneyimi, Ethereum için uzun vadeli en uygun mutabakat katmanını oluşturmak amacıyla uygulamayı hedefliyor. Bu konsensüs katmanının avantajı, mevcut işaret zincirinden çok daha basit olmasıdır.

Yürütme katmanını basitleştirin: EVM karmaşıklık açısından büyüdü ve bu karmaşıklığın çoğunun gereksiz olduğu kanıtlandı (birçok durumda benim hatam) ve EVM'nin RISC-V veya Ethereum ZK kanıtlayıcıları yazabilen başka bir sanal makine ile değiştirilmesi önerildi.

Tynygrad projesinin yaklaşımından ders çıkarılarak Ethereum'un uzun vadeli teknik spesifikasyonları için "maksimum kod satır numarası hedefi" belirlenmesi önerilir. Amaç, Ethereum'daki fikir birliğine dayalı anahtar kodların Bitcoin'in sadeliğine olabildiğince yakın olmasını sağlamaktır. Ethereum'un tarihsel kural işlemesini içeren kod kalacak, ancak fikir birliği kritik yolunun dışında tutulmalıdır. Aynı zamanda, genel tasarım felsefemizde şu ilkeleri de uygulamalıyız: Mümkün olduğunda daha basit çözümlere öncelik vermeli, "sistemik karmaşıklık" yerine "kapsüllenmiş karmaşıklığı" tercih etmeli ve tasarım kararlarında açık ve doğrulanabilir özelliklere ve garantilere sahip çözümlere öncelik vermeliyiz.