Vitalik yeni yazısı: Ethereum, Bitcoin ile nasıl sade bir mimari gerçekleştirecek?

Orijinal Başlık: L1'i Basitleştirmek

Yazı: Vitalik

Derleyen: lenaxin, ChainCatcher

Ethereum, dünya defteri olmayı hedefliyor: uygarlık varlıklarının depolandığı ve kayıt altına alındığı bir platform, finans, yönetim, yüksek değerli veri doğrulaması gibi alanların temel katmanı. Bunun için iki koşulun sağlanması gerekiyor: ölçeklenebilirlik ve dayanıklılık. Fusaka hard fork'u, ikinci katman (L2) verilerinin kullanılabilir alanını 10 kat artırmayı hedefliyor, mevcut planlanan 2026 yol haritası da birinci katman (L1) için benzer büyük ölçekli genişletme öneriyor. Bu arada, Ethereum, hisse kanıtı mekanizmasına (Proof of Stake) geçişini tamamladı, istemci çeşitliliği hızla arttı, sıfır bilgi kanıtı (ZK Verifiability) doğrulama yeteneği ve kuantum hesaplamaya karşı dayanıklılık konusundaki çalışmalar da ilerliyor, çeşitli uygulamalar da giderek daha sağlam hale geliyor.

Bu makale, dayanıklılığın (nihayetinde ölçeklenebilirliği de etkileyeceği) bir yönüne odaklanmayı amaçlamaktadır; bu yön, önemine rağmen genellikle göz ardı edilen bir yön olan protokolün sadeliğidir.

Bitcoin'in en büyük avantajlarından biri protokolünün son derece basit ve güzel olmasıdır.

Blok zinciri, her biri bir önceki blok ile hash değeri ile bağlantılı olan bir dizi bloktan oluşur. Blokların geçerliliği, iş kanıtı mekanizması ile doğrulanır; yani hash değerinin ilk birkaç basamağının sıfır olup olmadığı kontrol edilir. Her blok, madencilik ile üretilen veya önceki işlemlerin çıktılarından gelen çeşitli işlemler içerir. Bitcoin protokolünün temel mekanizması işte budur. Hatta zeki bir ortaokul öğrencisi bu protokolü tamamen anlayabilir; programcılar ise bunu bir hobi projesi olarak istemci yazmak için bile kullanabilir.

Protokolün sadeliğini korumak, Bitcoin veya Ethereum'un küresel olarak tanınan nötr bir temel katman haline gelmesi için önemli bir avantaj sağlamaktadır:

Basit protokoller daha kolay analiz edilir, daha fazla katılımcının protokol araştırma, geliştirme ve yönetim çalışmalarına katılmasını sağlar ve aynı zamanda teknik tekel riskini azaltır.

Basitleştirilmiş protokol yapısı, yeni altyapılar (örneğin, istemci, kanıtlayıcı, günlük araçları ve diğer geliştirme araçları) ile entegrasyon için gereken geliştirme yatırımını önemli ölçüde azaltır.

Sözleşmenin sade tasarımı, uzun vadeli bakım maliyetlerini etkili bir şekilde düşürmektedir.

Protokol standartları ve bunların uygulanmasındaki ciddi güvenlik açığı riskleri önemli ölçüde azalmış ve sistem güvenliğinin doğrulanmasını kolaylaştırmıştır.

Sosyal saldırı yüzeyini azaltma: Bileşenlerin sadeleştirilmesi, sistemi özel çıkarların sızmasından korumayı kolaylaştırır ve genel güvenliği artırır.

Tarihsel olarak, Ethereum'un protokol tasarımında genellikle basitlik ilkesini uygulamada başarısız olduğu (kısmen benim kararlarımdan kaynaklanıyor) doğrudan yüksek geliştirme maliyetlerine, güvenlik açıklarının sık sık ortaya çıkmasına ve geliştirme kültürünün kapalı olmasına yol açmıştır. Bu sorunların kökeni genellikle pratikte geçersiz olduğu kanıtlanmış kısa vadeli kazançları kovalamaktan kaynaklanmaktadır. Bu makalede, önümüzdeki beş yıl içinde Ethereum'un Bitcoin'e yakın bir protokol basitliği nasıl elde edeceği açıklanacaktır.

Basitleştirilmiş Konsensüs Katmanı

3sf - mini (Ethereum test ağı kod adı) içinde üç zaman dilimi sonluluğunu simüle etme

Yeni nesil konsensüs katmanı tasarımı (daha önce "Işın Zinciri" olarak adlandırılmıştır) son on yılda konsensüs teorisi, sıfır bilgi kanıtları (ZK-SNARK), staking ekonomisi gibi alanlardaki araştırma sonuçlarını birleştirmeyi amaçlamaktadır ve Ethereum için uzun vadeli gelişime yönelik en iyi konsensüs mekanizmasını inşa etmeyi hedeflemektedir. Mevcut beacon zincirine kıyasla, bu tasarım belirgin şekilde basitleştirilmiş özellikler taşımaktadır ve bu, aşağıdaki alanlarda kendini göstermektedir:

Üç zaman dilimi nihaiyeti (3-slot finality) mimarisi yeniliği: bağımsız zaman dilimi (slot) ve dönem (epoch) kavramlarının ayrımını ortadan kaldırarak, komite döngü mekanizmasını ve senkronize komiteleri gibi karmaşık bileşenleri kaldırır, protokol spesifikasyonunu önemli ölçüde basitleştirir. Temel uygulama yalnızca yaklaşık 200 satır kod gerektirir ve Gasper protokolüne göre güvenlik açısından neredeyse optimal seviyeye ulaşır.

Doğrulayıcı düğüm yönetimi optimizasyonu: Aktif doğrulayıcı düğüm sayısını sınırlayarak, çatallama seçim kurallarının (fork choice rule) daha basit bir uygulama seçeneği sunmasına olanak tanırken, sistem güvenliğini de sağlamaktadır.

Birleşim Protokolü Güncellemesi: STARK tabanlı birleştirme mekanizması, herhangi bir düğümün birleştirme rolünü üstlenmesine olanak tanır ve bu, birleştiriciye olan güven bağımlılığını ve tekrar eden bit alanlarının (bitfield) kaynak israfı sorununu ortadan kaldırır. Birleştirme kriptografisi kendisi oldukça karmaşık olmasına rağmen, yüksek düzeyde kapsülleme özelliği sistemik riski önemli ölçüde azaltır.

P2P ağ mimarisi iyileştirmesi: Yukarıdaki iki optimizasyon, daha basit ve verimli bir eşler arası ağ mimarisi oluşturma olanağı sağlamaktadır.

Doğrulama süreci yeniden yapılandırması: Doğrulama düğümünün kabulü, çıkışı, çekim, anahtar geçişi ve tembellik cezası gibi mekanizmaların yeniden tasarımı, kod miktarını azaltırken, temel parametrelerin (örneğin, zayıf öznel dönem) güvence mekanizmalarını netleştirir.

Teknik avantajlar: Konsensüs katmanı ile EVM yürütme katmanının karşılıklı ayrılma özellikleri, sürekli optimizasyon için daha büyük bir teknik alan sağlar. Buna karşılık, yürütme katmanındaki benzer iyileştirmeler daha büyük zorluklarla karşılaşmaktadır.

Basit İcra Katmanı

Ethereum Sanal Makinesi (EVM) karmaşıklığı sürekli artmakta, birçok karmaşık tasarımın gereksiz olduğu kanıtlanmıştır (birçok durumda benim karar hatalarım): belirli bir kripto algoritması için aşırı optimize edilmiş 256 bit sanal makine, bu algoritmaların günümüzde giderek önemsizleştiği; ve tek bir kullanım senaryosu için aşırı tasarlanmış önceden derlenmiş sözleşmeler, bu senaryoların gerçek kullanım oranı oldukça düşüktür.

Mevcut sorunları parçalı çözümlerle gidermeye çalışmak artık mümkün değil. SELFDESTRUCT opcode'unu kaldırmak büyük çaba gerektirirken yalnızca sınırlı fayda sağlıyor, son zamanlarda EOF hakkında yapılan tartışmalar sanal makineye kademeli değişiklik yapmanın zorluğunu daha da belirgin hale getirdi.

Bir alternatif olarak, yakın zamanda daha radikal bir dönüşüm yolu önerdim: EVM'yi orta ölçekli (ancak yine de yıkıcı) değişikliklerle 1.5 kat performans artışı elde etmek yerine, doğrudan tamamen yeni ve belirgin şekilde daha iyi bir sanal makine mimarisine geçiş yaparak yüz kat daha fazla performans sıçraması sağlamak. Birleşim (The Merge) gibi, yıkıcı değişikliklerin sayısını azaltarak, her bir değişikliğin stratejik değerini artırıyoruz. Özellikle, mevcut EVM'nin yerine RISC-V mimarisi veya Ethereum ZK kanıt programlarının kullandığı sanal makinenin benimsenmesini öneriyorum. Bu dönüşüm şunları getirecek:

Verimlilikte devrim niteliğinde artış: ZK kanıt ortamında, akıllı sözleşmeler hedef mimaride doğrudan çalıştırılabilir, yorumlayıcı giderlerine ihtiyaç duymadan. Succinct verileri, çoğu senaryoda performansın yüz katından fazla artabileceğini göstermektedir.

Mimari son derece sadeleştirilmiştir: RISC-V standardı, EVM'ye kıyasla oldukça basittir, diğer aday çözümler (örneğin Cairo) de sade özelliklere sahiptir.

EOF'un temel avantajlarının mirası: kod bölüm yönetimi, daha dostane statik analiz desteği ve daha büyük kod kapasite sınırları dahil.

Geliştirici araç zinciri uzantıları: Solidity ve Vyper, yeni arka uç derlemesi ile yeni mimarileri destekleyebilir; RISC-V ile ana akım dil geliştiricileri mevcut kodlarını doğrudan taşıyabilir.

Önceden derlenmiş sözleşme optimizasyonu: Çoğu önceden derlenmiş işlev artık gerekli olmayacak, yalnızca yüksek optimize edilmiş eliptik eğri hesaplamaları (kuantum bilgisayarlarının gelişimi ile birlikte yok olabilir) saklanacaktır.

Ana zorluklar şunlardır: Hemen uygulanabilir EOF planlarından farklı olarak, yeni sanal makinenin geliştiricilere fayda sağlaması daha uzun zaman alacaktır. Kısa vadeli geçiş planı olarak, yüksek değerli bazı EVM iyileştirmelerinin (örneğin, sözleşme kodu boyutu sınırının artırılması, DUP/SWAP komut setinin optimize edilmesi) senkronize bir şekilde uygulanması mümkündür.

Bu dönüşüm, sanal makine mimarisini önemli ölçüde basitleştirecektir. Temel sorun şudur: mevcut EVM ekosistemini nasıl düzgün bir şekilde ele alacağız?

Sanal makine göçünün geriye dönük uyumluluk stratejisi

EVM'nin herhangi bir kısmını basitleştirmenin (ya da karmaşıklığı artırmadan optimize etmenin) en büyük zorluğu, beklenen hedefleri gerçekleştirmek ile mevcut uygulamaların geriye dönük uyumluluğunu korumak arasındaki dengeyi nasıl sağlacağınızdır.

Öncelikle netleştirilmesi gereken bir konu var: Tek bir istemci için bile, "Ethereum kod tabanı"nın ne olduğu konusunda tek bir standart yoktur.

Amaç, yeşil alanı en aza indirmektir: yani, düğümün Ethereum konsensüsüne katılmak için çalıştırılması gereken mantığı, mevcut durumu hesaplama, kanıt oluşturma ve doğrulama, FOCIL (not: uzman terimi kısaltması olup olmadığını doğrulamak gerekir) ile "temel" blok inşa sürecini içermektedir.

Turuncu alan küçültülemez: Eğer gerçekleştirme katmanı fonksiyonları (ister sanal makine, önceden derlenmiş sözleşme ya da diğer mekanizmalar) protokol spesifikasyonundan çıkarılır veya fonksiyonlarında değişiklikler olursa, geçmiş blokları işleyen istemcilerin bu fonksiyonu koruması gerekir; ancak yeni istemciler (ZK-EVM veya biçimsel doğrulama araçları dahil) bu kısmı tamamen göz ardı edebilir.

Yeni sarı alan: Mevcut zincir üzerindeki veri analizi veya en iyi blok inşası için son derece değerli olan, ancak konsensüs mekanizmasına ait olmayan kodu ifade eder. Tipik örnekler arasında Etherscan ve bazı blok inşaatçıların ERC-4337 kullanıcı işlemlerini desteklemesi yer alır. Ethereum'un temel işlevlerinin (örneğin, harici hesap EOA ve desteklenen her türlü eski işlem türü) zincir üzerindeki RISC-V uygulaması ile değiştirilmesi durumunda, konsensüs kodu önemli ölçüde basitleşecektir, ancak özel düğümlerin hâlâ orijinal kodu analiz ve işleme için kullanması gerekebilir.

Turuncu ve sarı alanların karmaşıklığı, kapsayıcılık karmaşıklığına aittir; protokolü anlamak isteyen herkes bu kısımları atlayabilir. Ethereum uygulama çözümleri de bunları göz ardı etme özgürlüğüne sahiptir. Ayrıca, bu alanlardaki kod hataları konsensüs riski yaratmaz. Bu, yeşil alanın kod karmaşıklığına kıyasla, turuncu ve sarı alanların karmaşıklığının sistemin geneline olan olumsuz etkisinin belirgin şekilde daha düşük olduğu anlamına gelir.

Kodun yeşil alandan sarı alana taşınma düşüncesi, Apple'ın Rosetta çeviri katmanı aracılığıyla uzun vadeli geriye dönük uyumluluğu sağlama teknolojik çözümüne benzer.

Tüm yeni geliştirilen önceden derlenmiş sözleşmelerin standart bir zincir üstü RISC-V uygulaması içermesi gerekmektedir. Bu adım, ekosistemin RISC-V sanal makine ortamına (EVM'den RISC-V'ye geçiş örneği gibi, bu çözüm aynı zamanda EVM'den Cairo veya diğer daha iyi sanal makineler için geçişe de uygundur) aşamalı olarak uyum sağlamasını teşvik etmeyi amaçlamaktadır:

Çift sanal makine paralel desteği: Protokol seviyesinde hem RISC-V hem de EVM sanal makinelerini yerel olarak destekler. Geliştiriciler, geliştirme dili olarak serbestçe seçim yapabilir; farklı sanal makinelerle yazılmış akitler sorunsuz bir etkileşim gerçekleştirebilir.

Önceden derlenmiş sözleşmelerin aşamalı olarak değiştirilmesi: Performans gereksinimleri için son derece optimize edilen eliptik eğri hesaplamaları ve KECCAK hash algoritması dışında, tüm önceden derlenmiş sözleşmeler RISC-V uygulaması ile sert çatal yoluyla değiştirilmiştir.

Uygulama şu şekildedir: Orijinal önceden derlenmiş sözleşme kaldırılırken, bu adresin kodu (DAO çatallama modu kullanılarak) boş durumdan karşılık gelen RISC-V uygulamasına değiştirilir. RISC-V mimarisinin yüksek derecede sade olması nedeniyle, bu adım sadece tamamlanmış olsa bile, sistemin genel karmaşıklığı yine de azalacaktır.

EVM yorumlayıcı zincir üstü dağıtım: RISC-V tabanlı EVM yorumlayıcısının uygulanması (ZK kanıt araç zinciri bu tür geliştirmeleri teşvik etmiştir) ve bunun akıllı sözleşme olarak zincir üstüne dağıtılması. İlk sürüm yayınlandıktan birkaç yıl sonra, mevcut EVM sözleşmeleri bu yorumlayıcı aracılığıyla çalıştırılacak ve böylece yeni sanal makineye sorunsuz bir geçiş sağlanacaktır.

Paylaşım protokol bileşenleri aracılığıyla basitleştirme sağlanır

Dördüncü adım tamamlandıktan sonra, birçok "EVM uygulama çözümü" hala mevcut olacak ve blok inşası, geliştirici araçları ve zincir üzerindeki veri analizi gibi senaryoları optimize etmek için kullanılacaktır, ancak bu uygulamalar artık temel konsensüs standartlarının bir parçası olmayacaktır. O zaman, Ethereum konsensüs mekanizması "yerel" olarak yalnızca RISC-V mimarisini destekleyecektir.

Paylaşım protokol bileşenleri aracılığıyla basitleştirme sağlama

Protokolün genel karmaşıklığını azaltmanın üçüncü yolu (ve en çok göz ardı edilen yol) mümkün olduğunca farklı protokol yığın katmanları arasında ortak standartlar paylaşmaktır. Genel olarak, farklı modüllerde aynı işlevi gerçekleştirmek için farklı protokol uygulamalarını kullanmak ne gereksizdir ne de faydalıdır, ancak bu tür tasarım kalıpları hala yaygın olarak bulunmaktadır; bunun başlıca nedeni, protokol yol haritasının farklı bölümleri arasında etkili bir işbirliğinin eksikliğidir. Aşağıda, bileşenlerin katmanlar arası yeniden kullanımını güçlendirerek Ethereum'u basitleştirmek için somut senaryo örnekleri verilmiştir.

Birlikte Paylaşılan Silme Kodu Çözümü

Düzeltme-kodlarının üç tür uygulama senaryosu:

Veri kullanılabilirliği örnekleme: İstemci, blokların yayımlandığını doğrularken hata düzeltme kodları kullanmalı ve veri bütünlüğünü sağlamalıdır.

Verimli P2P Yayın: Düğüm, n parçadan n/2 parça aldığında bloğu onaylayabilir, gecikme azaltma ile yedeklilik arasında en iyi dengeyi sağlar.

Dağıtık Tarihsel Depolama: Ethereum tarih verileri birden fazla veri bloğuna bölünmüştür, şunları karşılamak için:

Her veri bloğu bağımsız olarak doğrulanabilir

Herhangi bir grup içinde n/2 veri bloğu, kalan n/2 veri bloğunu kurtarmak için yeterlidir.

Bu tasarım, tek noktalı veri kaybı riskini önemli ölçüde azaltmaktadır.

Aşağıdaki üç senaryoda aynı hata düzeltme kodunun (Reed-Solomon kodu, rastgele lineer kodlar vb. gibi) kullanılması önemli avantajlar sağlayacaktır:

Kod sadeleştirme;

Verimlilik Artışı: Bir düğüm belirli bir senaryo nedeniyle parçalı verileri (tam blok yerine) indirmesi gerektiğinde, bu veriler diğer senaryolar için doğrudan kullanılabilir, böylece tekrar iletimden kaçınılır;

Tüm senaryolardaki veri blokları, kök hash ile birleştirilmiş bir şekilde doğrulanabilir.

Farklı hata düzeltme kodları kullanılıyorsa, uyumluluk gereksinimlerini karşılamalıdır: Örneğin, veri kullanılabilirliği örnekleme (DAS) parçalarında hem yatay Reed-Solomon kodu hem de dikey rastgele lineer kod aynı sonlu alan üzerinde hesaplanmalıdır.

Birleştirilmiş Serileştirme Formatı

Mevcut Ethereum'un serileştirme formatı yarı standart bir durumda - veriler herhangi bir formata yeniden serileştirilebilir ve dağıtılabilir, tek istisna, işlem imzası hash'idir, bu senaryoda hash tutarlılığını sağlamak için standart bir format kullanılmalıdır. Ancak gelecekte, serileştirme formatının standartlaştırılma derecesi daha da güçlenecek, başlıca nedenler şunlardır:

Hesap Soyutlama (EIP-7701): Tam işlem içeriği sanal makine (VM) tarafından tamamen görünür olacak.

Yüksek Gas sınır senaryoları: Blok Gas üst sınırının artmasıyla birlikte, yürütme katmanı verileri blob yapısına depolanmalıdır.

Bu dönüşüm gerçekleştiğinde, Ethereum'un üç ana katmanının serileştirme standartlarını birleştirmek için bu fırsatı değerlendirebiliriz: (i) yürütme katmanı (ii) konsensüs katmanı (iii) akıllı sözleşme çağrısı ABI

SSZ serileştirme formatının benimsenmesi önerilir, SSZ'nin aşağıdaki avantajları vardır:

Verimliliği artırmak için, akıllı sözleşmeler dahil olmak üzere sahneler hızlı bir şekilde çözülebilir; bu, 4 baytlık tasarımına ve daha az sınır durumu işleme bağlıdır.

Konsens katmanı geniş bir şekilde uygulanmakta ve konsens katmanında derin entegrasyon sağlanmıştır.

Mevcut ABI'ye yüksek derecede benzer, bu da araç zinciri uyumunu ve yükseltmesini kolaylaştırır.

Şu anda ilgili teknik ekipler SSZ'nin tam geçiş çalışmalarını ilerletiyor. Gelecek yükseltme planlarında bu teknik yolun sürdürülmesi ve mevcut başarılar üzerine genişleme yapılması önerilir.

Birleşik Paylaşılan Ağaç Yapısı

EVM'den RISC-V'ye (veya diğer basit sanal makine mimarilerine) geçildiğinde, altı dallı Merkle Patricia ağacı blok yürütme kanıtının en büyük performans darboğazı haline gelecektir (bu, normal senaryolar için de geçerlidir). Daha iyi bir hash fonksiyonuna dayalı ikili ağaç yapısına geçmek, kanıt verimliliğini önemli ölçüde artıracak ve hafif düğümler ile diğer uygulama senaryoları için veri depolama maliyetlerini azaltacaktır.

Bu geçişi gerçekleştirirken, konsensüs katmanı ile yürütme katmanının birliğini sağlamak için aynı ağaç yapısının senkronize bir şekilde kullanılmasına dikkat edilmelidir. Bu, Ethereum yığınının (konsensüs katmanı ve yürütme katmanı dahil) veri erişimi ve çözümlemesi için aynı kod mantığını kullanmasını garanti edecektir.

Mevcut durumdan hedefe evrim yolu

Basitlik, birçok açıdan merkeziyetsizlik ile benzerlik taşır; her ikisi de sistemin dayanıklılığını sağlamak için temel bir ön koşuldur. Basitliği bir temel değer olarak net bir şekilde belirlemek, kültürel bir değişimi gerektirir: getirileri genellikle anında görünmezken, karmaşık işlevlerin kısa vadede sağladığı getiriler açıktır. Ancak zaman geçtikçe, basitliğin avantajları giderek daha belirgin hale gelecektir - Bitcoin'in gelişim süreci bu görüşün güçlü bir kanıtıdır.

Ethereum protokol tasarımında TinyGrad projesinin pratik deneyiminden yararlanmayı öneriyorum. Uzun vadeli Ethereum standartları için net bir kod satırı üst sınırı hedefi belirlemek, Ethereum konsensüsünün kritik kodunun basitlik seviyesini Bitcoin seviyesine yaklaştırmayı hedeflemektedir. Özellikle, Ethereum'un tarihsel kurallarına ilişkin kodlar korunmaya devam edilebilir, ancak bunlar kesinlikle konsensüs kritik yolunun dışına izole edilmelidir, böylece temel konsensüs mantığını etkilemez; aynı zamanda, teknik çözüm seçiminde "daha basit çözümleri tercih etme" tasarım felsefesi benimsenmeli, karmaşıklığın kapsüllenmesi öncelikli olmalı ve sistematik karmaşıklığın yayılmasından kaçınılmalıdır. Tüm tasarım kararlarının net ve doğrulanabilir özellikler ve garantiler sunması sağlanmalı, böylece genel olarak basitliğe odaklanan bir teknik kültür oluşturulmalıdır.

View Original
The content is for reference only, not a solicitation or offer. No investment, tax, or legal advice provided. See Disclaimer for more risks disclosure.
  • Reward
  • Comment
  • Share
Comment
0/400
No comments
  • Pin