Orijinal başlık: L1'i Basitleştirmek
Yazan: Vitalik
Ethereum, dünyanın muhasebe defteri olmayı hedefliyor: Medeniyetin varlıklarını ve kayıtlarını depolamak için bir platform ve finans, yönetim, yüksek değerli veri kimlik doğrulaması ve daha fazlası için temel bir katman. Bunun için iki koşul gerekiyor: Ölçeklenebilirlik ve dayanıklılık. Fusaka hard fork'u, katman 2 (L2) verileri için kullanılabilir alanı 10 kat artırmayı hedefliyor ve şu anda önerilen 2026 yol haritası da katman 1 (L1) için benzer şekilde önemli bir genişleme öneriyor. Aynı zamanda Ethereum birleşmeyi ve Proof of Stake mekanizmasına yükseltmeyi tamamladı, müşteri çeşitliliği hızla arttı, sıfır bilgi kanıtı (ZK Doğrulanabilirliği) doğrulanabilirliği ve kuantum hesaplama direnci üzerindeki çalışmalar da ilerledi ve çeşitli uygulamalar daha sağlam hale geldi.
Bu makale, dayanıklılığın eşit derecede önemli ancak sıklıkla hafife alınan (ve nihayetinde ölçeklenebilirliği etkileyen) bir yönüne odaklanmayı amaçlamaktadır: protokol basitliği.
Bitcoin'in en güzel yanlarından biri de protokolünün son derece basit ve zarif olmasıdır.
Blok zinciri, her biri bir önceki bloğa bir hash değeri aracılığıyla bağlanan bir dizi bloktan oluşur. Bir bloğun geçerliliği, karma değerinin ilk birkaç basamağının sıfır olup olmadığını doğrulayan bir iş kanıtı mekanizması aracılığıyla doğrulanır. Her blok, madencilik yoluyla veya önceki işlemlerin çıktısından üretilen coin'leri tüketen çok sayıda işlem içerir. Bu, Bitcoin protokolünün temel mekanizmasıdır. Ortaokulda okuyan zeki bir öğrenci bile protokolü tam olarak anlayabilir ve bir programcı yan proje olarak bunun için bir istemci bile yazabilir.
Protokolün basit tutulması, Bitcoin veya Ethereum'un küresel olarak kabul gören tarafsız bir temel katman haline gelmesi için önemli avantajlar sağlar:
- Basit protokollerin analiz edilmesi daha kolaydır, bu da protokol araştırma, geliştirme ve yönetişimine daha fazla katılımcının katılımını sağlayabilir ve aynı zamanda teknolojik tekel riskini azaltabilir.
- Protokol yapısının basitleştirilmesi, istemciler, kanıtlayıcılar, günlükleme araçları ve diğer geliştirme araçları gibi yeni altyapılarla arayüz oluşturmak için gereken geliştirme çabasını önemli ölçüde azaltır.
- Protokolün basit tasarımı uzun vadeli bakım maliyetlerini etkili bir şekilde azaltır.
- Protokol spesifikasyonlarında ve uygulamalarında ciddi zafiyet riski önemli ölçüde azalır ve sistem güvenliğinin doğrulanması kolaylaşır.
- Azaltılmış sosyal saldırı yüzeyi: Bileşenlerin düzenlenmesi, sistemin özel çıkar gruplarına yönelik sızmalara karşı savunulmasını kolaylaştırır ve genel güvenliği iyileştirir.
Tarihsel olarak, Ethereum protokol tasarımında basitlik ilkesini uygulamada sıklıkla başarısız oldu (kısmen kendi kararları nedeniyle), bu da doğrudan yüksek Ar-Ge maliyetlerine, sık güvenlik risklerine ve kapalı bir Ar-Ge kültürüne yol açtı. Bu sorunların kökeninde çoğu zaman pratikte etkisiz olduğu kanıtlanmış kısa vadeli kazanımların peşinde koşulması yatmaktadır. Bu makalede Ethereum'un önümüzdeki beş yıl içerisinde Bitcoin'e yakın bir protokol basitliğine nasıl ulaşabileceği açıklanacaktır.
Mutabakat katmanının basitleştirilmesi
3sf-mini'de (Ethereum testnet'inin kod adı) üç yuvalı kesinliği simüle etme
Yeni mutabakat katmanı çözümü (eski adıyla "Beam Chain"), Ethereum'un uzun vadeli gelişimi için en uygun mutabakat mekanizmasını oluşturmak amacıyla mutabakat teorisi, sıfır bilgi kanıtı (ZK-SNARK), staking ekonomisi vb. alanlarda son on yılın araştırma sonuçlarını entegre etmeyi amaçlıyor. Mevcut işaret zinciriyle karşılaştırıldığında, bu çözüm aşağıdaki yönlerde yansıyan önemli ölçüde basitleştirilmiş özelliklere sahiptir:
- 3 yuvalı kesinlik mimarisi yeniliği: Bağımsız yuvaların ve dönemlerin kavramsal bölünmesini ortadan kaldırır, komite rotasyon mekanizması ve senkronizasyon komitesi gibi karmaşık bileşenleri iptal eder ve protokol spesifikasyonunu büyük ölçüde basitleştirir. Çekirdek uygulaması yalnızca 200 satır kod gerektiriyor ve bu da Gasper protokolüne kıyasla neredeyse optimum bir güvenlik düzeyi sağlıyor.
- Optimize edilmiş doğrulama düğümü yönetimi: Etkin doğrulama düğümlerinin sayısı sınırlandırılarak, sistem güvenliği sağlanırken çatal seçimi kuralı daha basit bir şekilde uygulanabilir.
- Toplama protokolü yükseltmesi: STARK tabanlı toplama mekanizması, herhangi bir düğümün toplama rolünü üstlenmesine olanak tanır, toplayıcıya olan güven bağımlılığını ve tekrarlanan bit alanlarının neden olduğu kaynak israfını önler. Toplu kriptografinin kendisi nispeten karmaşık olmasına rağmen, oldukça kapsüllenmiş yapısı sistemik riski önemli ölçüde azaltır.
- P2P ağ mimarisi iyileştirmeleri: Yukarıdaki iki iyileştirme, daha basit ve daha verimli bir eşler arası ağ mimarisinin oluşturulmasını mümkün kılıyor.
- Doğrulama sürecinin yeniden yapılandırılması: Doğrulama düğümü kabul, çıkış, çekme, anahtar geçişi ve tembellik ceza mekanizmalarını yeniden tasarlarken, kod miktarını azaltın ve çekirdek parametrelerin (zayıf öznel dönem gibi) koruma mekanizmasını açıklığa kavuşturun.
- Teknik avantajlar: Konsensüs katmanının ve EVM yürütme katmanının göreceli ayrıştırma özellikleri, sürekli optimizasyon için daha fazla teknik alan sağlar. Karşılaştırıldığında, uygulama düzeyindeki benzer iyileştirmeler daha büyük zorluklarla karşı karşıyadır.
Yürütme katmanını basitleştirin
Ethereum Sanal Makinesi (EVM) karmaşıklaşmaya devam ediyor ve gereksiz olduğu kanıtlanan (ve çoğu durumda benim hatam olan) birçok komplikasyon var: giderek daha az alakalı hale gelen belirli kriptografik algoritmalar için aşırı optimize edilmiş 256 bitlik bir VM ve çok az gerçek kullanımı olan tek bir kullanım durumu için aşırı tasarlanmış önceden derlenmiş sözleşmeler.
Mevcut sorunları parça parça çözümlerle çözmeye çalışmak artık mümkün değil. SELFDESTRUCT opcode'unu kaldırmak sınırlı fayda sağlayan büyük bir çabaydı ve EOF hakkındaki son tartışmalar, bir sanal makinede artımlı değişiklikler yapmanın zorluğunu vurguladı.
Alternatif olarak, yakın zamanda daha radikal bir geçiş yolu önerdim: EVM'de orta büyüklükte (ama yine de yıkıcı) bir değişiklik yapıp bunun karşılığında 1,5 kat performans artışı elde etmek yerine, 100 katlık bir performans artışı elde etmek için doğrudan yeni ve önemli ölçüde daha iyi bir sanal makine mimarisine geçiş yapmak daha iyidir. The Merge'de olduğu gibi, yıkıcı değişikliklerin sayısını azaltıyoruz ancak her bir değişikliğin stratejik değerini artırıyoruz. Özellikle mevcut EVM’nin RISC-V mimarisiyle veya Ethereum ZK proof programının kullandığı sanal makineyle değiştirilmesi önerilmektedir. Bu dönüşüm şu sonucu doğuracaktır:
- Verimlilikte devrim niteliğinde iyileştirme: ZK proof ortamında, akıllı sözleşmeler bir yorumlayıcı yüküne ihtiyaç duymadan doğrudan hedef mimari üzerinde çalıştırılabilir. Özet veriler, performansın çoğu senaryoda 100 kattan fazla iyileştirilebileceğini gösteriyor.
- Son derece basitleştirilmiş mimari: RISC-V spesifikasyonu, EVM'ye kıyasla son derece akıcıdır ve diğer aday çözümler (örneğin Cairo) da basit özelliklere sahiptir.
- EOF'un temel avantajlarını devralır: kod segmentasyon yönetimi, daha kullanıcı dostu statik analiz desteği ve daha büyük kod kapasitesi sınırı dahil.
- Geliştirici araç zinciri genişlemesi: Solidity ve Vyper, yeni arka uç derlemeleri ekleyerek yeni mimarileri destekleyebilir; RISC-V seçilirse, ana akım dil geliştiricileri mevcut kodu doğrudan taşıyabilir.
- Önceden derlenmiş sözleşme optimizasyonu: Önceden derlenmiş işlevlerin çoğu artık gerekli olmayacak, yalnızca yüksek oranda optimize edilmiş eliptik eğri işlemleri korunacak (ki bunlar kuantum hesaplamanın geliştirilmesiyle ortadan kaldırılabilir).
Asıl zorluk, hemen uygulanabilen EOF çözümünün aksine, yeni sanal makinenin geliştiricilere fayda sağlamasının daha uzun zaman alacak olmasıdır. Kısa vadeli bir geçiş çözümü, bazı yüksek değerli EVM iyileştirmelerinin (örneğin sözleşme kod boyutu sınırının artırılması ve DUP/SWAP komut setinin optimize edilmesi) aynı anda uygulanmasıyla elde edilebilir.
Bu dönüşüm sanal makine mimarisini önemli ölçüde basitleştirecek. Temel soru şudur: Mevcut EVM ekosistemi nasıl doğru şekilde yönetilebilir?
Sanal makine geçişi için geriye dönük uyumluluk stratejisi
EVM'nin herhangi bir bölümünü basitleştirmenin (veya karmaşıklık eklemeden iyileştirmenin) en büyük zorluğu, istenen hedeflere ulaşma ile mevcut uygulamalar için geriye dönük uyumluluğu sürdürme arasındaki dengeyi sağlamaktır.
Öncelikle, tek bir istemci için bile olsa, "Ethereum kod tabanının" ne olduğunu tanımlayan tek bir standardın olmadığını açıkça belirtmek önemlidir.
Amaç yeşil alanı en aza indirmektir: Ethereum konsensüsüne katılmak için düğümlerin çalıştırması gereken mantık, mevcut durumu hesaplama, kanıt oluşturma ve doğrulama, FOCIL (not: profesyonel bir terim kısaltması olup olmadığını teyit etmek gerekir) ve "temel" blok oluşturma süreci.
Turuncu alan azaltılamaz: yürütme katmanı işlevselliği (ister sanal makine, ister önceden derlenmiş sözleşmeler veya diğer mekanizmalar olsun) protokol spesifikasyonundan kaldırılırsa veya işlevselliği değiştirilirse, geçmiş blokları işlemesi gereken istemciler bu işlevselliği korumalıdır; ancak yeni istemciler (ZK-EVM veya resmi doğrulama araçları dahil) bu kısmı tamamen göz ardı edebilir.
Yeni sarı alan: Mevcut zincir üstü veri analizi veya optimum blok oluşturma için son derece değerli olan, ancak fikir birliği mekanizmasının bir parçası olmayan kodu ifade eder. Tipik bir örnek Etherscan ve bazı blok oluşturucularının ERC-4337 kullanıcı işlemlerine verdiği destektir. Ethereum'un temel işlevleri (harici hesaplar, EOA ve desteklediği çeşitli eski işlem türleri gibi) zincir üstü RISC-V uygulamalarıyla değiştirilirse, fikir birliği kodu büyük ölçüde basitleştirilecek, ancak özel düğümlerin ayrıştırma ve işleme için yine de orijinal kodu kullanması gerekebilir.
Turuncu ve sarı alanlardaki karmaşıklık, kapsüllenmiş karmaşıklıktır ve protokolü anlamak isteyen herkes tarafından atlanabilir; Ethereum uygulamaları bunları görmezden gelmekte özgürdür. Ayrıca, bu alanlardaki kod kusurları fikir birliği riskleri oluşturmaz. Bu, yeşil alandaki kod karmaşıklığıyla karşılaştırıldığında, turuncu ve sarı alanlardaki karmaşıklığın genel sistem üzerinde önemli ölçüde daha düşük bir olumsuz etkiye sahip olduğu anlamına geliyor.
Yeşil alandaki kodun sarı alana taşınması fikri, Apple'ın Rosetta çeviri katmanı aracılığıyla uzun vadeli geriye dönük uyumluluk elde etmeye yönelik teknik çözümüne benziyor.
Yeni geliştirilen tüm önceden derlenmiş sözleşmelerin, kanonik bir zincir üstü RISC-V uygulamasını içermesi gerekmektedir. Bu adım, ekosistemin RISC-V sanal makine ortamına kademeli olarak uyum sağlamasını teşvik etmeyi amaçlamaktadır (örneğin EVM'nin RISC-V'ye geçişini ele alalım, bu çözüm EVM'nin Kahire'ye veya diğer daha iyi sanal makinelere geçişi için de geçerlidir):
- Çift sanal makineler için paralel destek: Protokol düzeyinde hem RISC-V hem de EVM sanal makinelerini yerel olarak destekler. Geliştiriciler geliştirme dilini özgürce seçebilir ve farklı sanal makinelerde yazılan sözleşmeler sorunsuz bir şekilde etkileşime girebilir.
- Önceden derlenmiş sözleşmeler aşamalı olarak değiştirilir: eliptik eğri işlemleri ve KECCAK karma algoritması hariç (aşırı performans optimizasyon gereksinimleri nedeniyle), tüm önceden derlenmiş sözleşmeler sert çatallanmalar yoluyla RISC-V uygulamasıyla değiştirilir.
- Belirli işlem şudur: orijinal önceden derlenmiş sözleşmeyi kaldırırken, adresin kodunu (DAO çatal modunu kullanarak) boş durumdan karşılık gelen RISC-V uygulamasına değiştirin. RISC-V mimarisinin oldukça basit olması nedeniyle, sadece bu adım tamamlansa bile sistemin genel karmaşıklığı azaltılmış olacaktır.
- EVM yorumlayıcısının zincir üzerinde dağıtımı: RISC-V tabanlı bir EVM yorumlayıcısı uygulayın (ZK kanıtı araç zinciri bu tür geliştirmeleri teşvik etmiştir) ve bunu akıllı sözleşme olarak zincir üzerinde dağıtın. İlk sürümden birkaç yıl sonra, mevcut EVM sözleşmeleri bu yorumlayıcı aracılığıyla yürütülecek ve böylece yeni sanal makineye sorunsuz bir geçiş sağlanacak.
Paylaşılan protokol bileşenleri aracılığıyla basitleştirme
Paylaşılan protokol bileşenleri aracılığıyla basitleştirme
4. adım tamamlandıktan sonra, birçok "EVM uygulama çözümü" hala korunacak ve blok oluşturma, geliştirici araçları ve zincir üstü veri analizi gibi senaryoları optimize etmek için kullanılacak, ancak bu uygulamalar artık temel fikir birliği spesifikasyonunun bir parçası olmayacak. O tarihte Ethereum konsensüs mekanizması "doğal olarak" yalnızca RISC-V mimarisini destekleyecek.
Paylaşılan protokol bileşenleri aracılığıyla basitleştirme
Protokolün genel karmaşıklığını azaltmanın üçüncü yolu (ve en az önemsenen yol), mümkün olduğunca protokol yığınının farklı katmanları arasında birleşik standartları paylaşmaktır. Genel olarak aynı işlevi yerine getirmek için farklı modüllerde farklı protokoller kullanmak ne gerekli ne de faydalıdır, ancak bu tasarım örüntüsü hala yaygındır. Bunun temel nedeni protokol yol haritasının farklı bölümleri arasında etkin bir koordinasyonun olmamasıdır. Aşağıda, Ethereum'un katmanlar arası bileşen yeniden kullanımının güçlendirilmesiyle basitleştirilebileceği belirli senaryolara örnekler verilmiştir.
Birleşik paylaşımlı silme kodlama çözümü
Silme kodlarının üç uygulama senaryosu:
- Veri kullanılabilirliği örneklemesi: İstemci bir bloğun yayınlanıp yayınlanmadığını doğruladığında, veri bütünlüğünü sağlamak için silme kodlamasını kullanması gerekir.
- Verimli P2P yayını: Bir düğüm, n/2 adet n parçayı aldığında bir bloğu onaylayabilir ve böylece gecikme azaltma ile yedeklilik arasında optimum dengeyi sağlayabilir.
- Dağıtılmış tarihsel depolama: Ethereum tarihsel verileri, aşağıdaki gereksinimleri karşılamak için birden fazla veri bloğuna bölünür:
- Her veri bloğu bağımsız olarak doğrulanabilir
- Herhangi bir gruptaki n/2 veri bloğu kalan n/2 veri bloğunu kurtarabilir
Bu tasarım, tek noktadaki veri kaybı riskini önemli ölçüde azaltır.
Aynı silme kodunun (Reed-Solomon kodu, rastgele doğrusal kod vb. gibi) aşağıdaki üç senaryoda kullanılması durumunda önemli avantajlar sağlanacaktır:
- Kod öz;
- Geliştirilmiş verimlilik: Bir düğümün belirli bir senaryo için parça verilerini (tüm bir blok yerine) indirmesi gerektiğinde, veriler tekrarlanan iletimi önlemek için doğrudan diğer senaryolarda kullanılabilir;
- Tüm senaryolardaki veri blokları kök karma yoluyla tekdüze bir şekilde doğrulanabilir
Farklı silme kodları kullanılıyorsa uyumluluk gerekliliklerinin karşılanması gerekir: örneğin, yatay Reed-Solomon kodları ve dikey rastgele doğrusal kodlar Veri Kullanılabilirliği Örneklemesi (DAS) parçalarında aynı anda kullanılabilir, ancak her iki kod da aynı sonlu alanda çalıştırılmalıdır.
Birleştirilmiş serileştirme biçimi
Ethereum'un mevcut serileştirme biçimi hala yarı-normalleştirilmiş bir durumdadır; veriler herhangi bir biçime yeniden serileştirilebilir ve yayılabilir; tek istisna, karma tutarlılığını sağlamak için normalleştirilmiş bir biçim gerektiren işlem imza karmalarıdır. Ancak gelecekte, serileştirme formatlarının standardizasyonunun daha da güçlendirilmesi, özellikle aşağıdaki nedenlerden dolayı gerçekleşecektir:
- Hesap soyutlaması (EIP-7701): Tam işlem içeriği sanal makine (VM) tarafından tamamen görülebilir olacaktır
- Yüksek Gaz Sınırı Senaryosu: Blok Gaz sınırı arttıkça, yürütme katmanı verilerinin bir blob yapısında depolanması gerekir
- Hesap soyutlaması (EIP-7701): Tam işlem içeriği sanal makine (VM) tarafından tamamen görülebilir olacaktır
- Yüksek Gaz Sınırı Senaryosu: Blok Gaz sınırı arttıkça, yürütme katmanı verilerinin bir blob yapısında depolanması gerekir
Bu geçiş gerçekleştiğinde, Ethereum'un üç temel katmanı için serileştirme standartlarını birleştirme fırsatına sahip olacağız: (i) yürütme katmanı, (ii) mutabakat katmanı ve (iii) akıllı sözleşme çağrısı ABI.
Aşağıdaki avantajları olan SSZ serileştirme formatının kullanılması önerilir:
- Akıllı sözleşmeler de dahil olmak üzere verimli kod çözme, 4 baytlık tasarımı ve daha az sınır koşulu işleme sayesinde hızlı bir şekilde çözülebilir
- Mutabakat katmanı yaygın olarak kullanılır ve mutabakat katmanına derinlemesine entegre edilmiştir
- Mevcut ABI'ye oldukça benzer, araç zincirini uyarlamak ve yükseltmek kolaydır
Şu anda ilgili teknik ekipler SSZ'nin kapsamlı geçişini teşvik ediyor. Sonraki yükseltme planlarında bu teknik rotanın sürdürülmesi ve mevcut başarıların genişletilmesi önerilmektedir.
Birleşik paylaşımlı ağaç yapısı
EVM'den RISC-V'ye (veya diğer akıcı sanal makine mimarilerine) geçiş yaparken, altı dallı Merkle Patricia ağacı, blok yürütme kanıtları için (normal senaryolarda bile) en büyük performans darboğazı haline gelecektir. Daha iyi bir karma işlevine dayalı ikili ağaç yapısına geçiş, kanıt verimliliğini önemli ölçüde artıracak ve hafif düğümler ve diğer uygulama senaryoları için veri depolama maliyetlerini azaltacaktır.
Bu geçişi uygularken, mutabakat katmanını ve yürütme katmanını birleştirmek için aynı ağaç yapısı eş zamanlı olarak kullanılmalıdır. Bu, Ethereum yığınının tamamının (konsensüs katmanı ve yürütme katmanı dahil) veri erişimi ve ayrıştırma için aynı kod mantığını kullanmasını sağlar.
Mevcut durumdan hedefe doğru evrimsel yol
Basitlik birçok açıdan merkeziyetsizliğe benzer ve her ikisi de sistem dayanıklılığına ulaşmanın temel ön koşullarıdır. Basitliği açıkça temel bir değer haline getirmek kültürel bir değişimi gerektirir: Basitliğin faydaları çoğu zaman hemen belli olmazken, karmaşık özelliklerin peşinden gitmenin kısa vadeli faydaları açıktır. Ancak zamanla, basitliğin avantajları daha da belirginleşecektir - Bitcoin'in gelişim tarihi bunun güçlü bir kanıtıdır.
Ethereum protokolünün tasarımının TinyGrad projesinin pratik deneyimine dayanmasını, uzun vadeli Ethereum spesifikasyonu için kod satırı sayısına net bir üst sınır konulmasını ve temel Ethereum mutabakat kodunun basitliğinin Bitcoin seviyesine yakın olmasını sağlamayı öneriyorum. Özellikle, Ethereum'un tarihsel kurallarını işlemek için ilgili kod saklanmaya devam edilebilir, ancak çekirdek fikir birliği mantığını etkilememesini sağlamak için fikir birliği kritik yolundan kesinlikle izole edilmelidir; Aynı zamanda, teknik çözümlerin seçiminde "daha basit çözümlere öncelik verme" tasarım konsepti uygulanmalı, sistemik karmaşıklığı yaymak yerine, karmaşıklığı kapsüllemeye öncelik verilmeli ve tüm tasarım kararlarının açık ve doğrulanabilir özellikler ve garantiler sağlayabilmesi sağlanarak, bütünüyle basitliğe yönelik bir teknik kültür oluşturulmalıdır.
Tüm Yorumlar