Ethereum, küresel bir defter olmayı hedefliyor ve ölçeklenebilirlik ile dayanıklılığa ihtiyaç duyuyor. Bu makale, protokol basitliğinin önemine odaklanmakta ve karmaşıklığı büyük ölçüde azaltmak için konsensüs katmanını (3-slot nihaiyet, STARK toplama) ve yürütme katmanını (EVM'yi RISC-V veya benzeri bir sanal makine ile değiştirme) basitleştirmeyi önermektedir. Geriye dönük uyum stratejileri (örneğin, zincir üstü EVM yorumlayıcısı) aracılığıyla yumuşak bir geçiş önerilmektedir ve ek olarak, hata düzeltme kodlarını, serileştirme formatlarını (SSZ) ve ağaç yapılarını birleştirerek daha fazla basitlik sağlanmalıdır. Hedef, Ethereum'un konsensüs ana kodunun Bitcoin'in basitliğine yaklaşmasını sağlamak, dayanıklılığı ve katılımı artırmaktır; bu amaçla kültürel olarak basitliğe önem verilmeli ve maksimum kod satırı sayısı hedefleri belirlenmelidir.
Ethereum'un hedefi, insanlık medeniyetinin varlıklarını ve kayıtlarını depolayan, finans, yönetim, yüksek değerli veri doğrulama gibi alanlara hizmet eden küresel bir defter olmaktır. Bu, iki yönlü bir desteği gerektirir: ölçeklenebilirlik ve dayanıklılık. Fusaka hard fork planı, L2 verilerinin kullanılabilir alanını 10 kat artırmayı hedefliyor, mevcut önerilen 2026 yol haritası da L1 katmanına benzer büyük yükseltmeler getirmeyi planlıyor. Bu arada, Ethereum, hisse kanıtına (PoS) geçişini tamamladı, istemci çeşitliliği hızla arttı, sıfır bilgi (ZK) doğrulama ve kuantum dayanıklılığı araştırmaları da istikrarlı bir şekilde ilerliyor, uygulama ekosistemi giderek güçleniyor.
Bu makale, aynı zamanda önemli ama genellikle göz ardı edilen bir dayanıklılık (hatta ölçeklenebilirlik) unsuru olan: Protokolün basitliği.
Bitcoin protokolünün en etkileyici yanı zarif sadeliğidir:
Her bir bloğun bir önceki blokla hash kullanarak bağlantı kurduğu bloklardan oluşan bir zincir vardır.
Blokların geçerliliği, iş kanıtı (PoW) ile doğrulanır, yani hash değerinin ilk birkaç basamağının sıfır olup olmadığını kontrol eder.
Her blok, ya madencilik ödüllerinden ya da önceki işlem çıktılarından gelen işlemler içerir.
Bütün bunlar bu kadar! Akıllı bir lise öğrencisi bile Bitcoin protokolünün nasıl çalıştığını tamamen anlayabilir ve bir programcı bunu bir hobi projesi olarak bir istemci yazabilir.
Sözleşmenin basitliği, Bitcoin'in (ve Ethereum'un) güvenilir, tarafsız bir küresel temel katman haline gelmesi için birçok önemli avantaj sunmuştur:
1. Anlaşılması Kolay: Protokolün karmaşıklığını azaltarak daha fazla kişinin protokol araştırma, geliştirme ve yönetimine katılmasını sağlamak, teknik elit tabakasının hakimiyet riskini azaltmak.
2. Geliştirme Maliyetlerini Düşürmek: Protokolü basitleştirmek, yeni altyapı (yeni istemciler, kanıtlayıcılar, geliştirici araçları vb.) oluşturma maliyetini önemli ölçüde azaltır.
3. Bakım yükünü azaltın: Uzun vadeli anlaşmaların bakım maliyetlerini düşürün.
4. Hata Riskini Azaltma: Protokol spesifikasyonları ve uygulamaları sırasında felaket hatalarının olasılığını azaltmak ve böyle hataların bulunmadığını doğrulamayı kolaylaştırmak.
5. Saldırı yüzeyini küçültme: Protokolün karmaşık bileşenlerini azaltarak, özel çıkar grupları tarafından saldırıya uğrama riskini düşürmek.
Tarihsel olarak, Ethereum (bazen kişisel kararlarımdan dolayı) genellikle basitliği koruyamamıştır, bu da yüksek geliştirme maliyetlerine, artan güvenlik risklerine ve Ar-Ge kültürünün kapalı olmasına yol açmıştır. Bu karmaşıklık arayışının getirilerinin çoğu genellikle hayali olduğu kanıtlanmıştır. Bu makale, beş yıl sonra Ethereum'un Bitcoin'in basitliğine nasıl yaklaşacağını araştıracaktır.
Basitleştirilmiş Konsensüs Katmanı
Yeni konsensüs katmanı tasarımı (tarihte "Beacon Chain" olarak adlandırılan) son on yılda konsensüs teorisi, ZK-SNARK geliştirme, stake ekonomisi gibi alanlardaki deneyimlerden yararlanarak uzun vadede en iyi ve daha basit bir konsensüs katmanı inşa etmeyi amaçlamaktadır. Mevcut Beacon Chain ile karşılaştırıldığında, yeni tasarım belirgin şekilde basitleştirilmiştir:
1. 3-slot nihai tasarımı: Slot, dönem ve komite yeniden yapılandırması gibi kavramları ve ilgili verimli işleme mekanizmalarını (örneğin, senkronizasyon komiteleri) ortadan kaldırır. 3-slot nihai tasarımının temel uygulanması yalnızca yaklaşık 200 satır kod gerektirir ve Gasper'a kıyasla güvenlik açısından neredeyse optimumdur.
2. Aktif doğrulayıcı sayısını azaltın: Daha basit bir çatallama seçimi kuralı kullanarak uygulanmasına izin verin, güvenliği artırın.
3. STARK Tabanlı Birleştirme Protokolü: Herkes birleştirici olabilir, birleştiriciye güvenmeye veya tekrar eden alanlar için yüksek maliyetler ödemeye gerek yoktur. Birleştirme kriptografisinin karmaşıklığı yüksektir, ancak bu karmaşıklık yüksek oranda paketlenmiştir, sistematik riskler daha düşüktür.
4. P2P Yapısını Basitleştirme: Yukarıdaki faktörler, daha basit ve daha sağlam bir eşler arası ağ yapısını destekleyebilir.
5. Doğrulayıcı mekanizmasının yeniden tasarımı: Giriş, çıkış, para çekme, anahtar geçişi, inactivity leak gibi mekanizmaları içermekte, kod satır sayısını basitleştirmekte ve daha net garantiler sunmaktadır (örneğin, zayıf öznelite döngüsü).
Konsens katmanının avantajı, EVM yürütme katmanına göre nispeten bağımsız olmasıdır, bu nedenle sürekli iyileştirme için daha fazla alan vardır. Daha büyük zorluk, yürütme katmanında benzer bir basitleştirmeyi nasıl gerçekleştireceğimizdir.
Basit İcra Katmanı
EVM'nin karmaşıklığı giderek artmakta ve birçok karmaşıklığın gereksiz olduğu kanıtlanmıştır (bir kısmı kişisel karar hatalarımdan kaynaklanmaktadır): 256 bit sanal makine, artık giderek modası geçmiş belirli kriptografik biçimleri aşırı optimize etmiştir, önceden derlenmiş (precompiles) tek bir kullanım durumu için optimize edilmiş olmasına rağmen pek kullanılmamaktadır.
Bu sorunları teker teker çözmek sınırlı etki gösteriyor. Örneğin, SELFDESTRUCT opcode'unu kaldırmak büyük çaba gerektiriyor ama sadece küçük bir kazanç sağlıyor. Son zamanlarda EOF (EVM Object Format) hakkında yapılan tartışmalar da benzer zorlukları ortaya koyuyor.
Son zamanlarda daha radikal bir öneri sundum: EVM'yi orta ölçekli (ama yine de yıkıcı) değişiklikler yapmak yerine 1.5 kat fayda sağlamak için daha iyi ve daha basit bir sanal makineye geçiş yaparak 100 kat fayda sağlamak. "Birleşme" (The Merge) benzeri, yıkıcı değişikliklerin sayısını azaltıyoruz, ancak her bir değişikliği daha anlamlı hale getiriyoruz. Özellikle, EVM'nin RISC-V ile değiştirilmesini veya Ethereum'un ZK kanıtlayıcıları tarafından kullanılan başka bir sanal makineyi öneriyorum. Bu şunları getirecektir:
1. Önemli ölçüde geliştirilmiş verimlilik: Akıllı sözleşme yürütme (kanıtlayıcıda) tercüman ek yükü olmadan çalışır. Succinct'in verileri, birçok senaryoda 100 kattan fazla performans artışı olduğunu gösteriyor.
2. Basitlikte Büyük İyileşme: RISC-V standardı EVM'ye göre son derece basit, alternatifler (örneğin Cairo) de aynı şekilde sade.
3. EOF'u desteklemenin motivasyonu: Kod bölümlendirmesi, daha dostça statik analiz, daha büyük kod boyutu sınırlamaları vb.
4. Daha Fazla Geliştirici Seçenekleri: Solidity ve Vyper, yeni sanal makineye derlemek için arka uç ekleyebilir. RISC-V seçilirse, ana akım dil geliştiricileri de kodlarını bu sanal makineye kolayca taşıyabilir.
5. Çoğu önceden derlenmişin kaldırılması: Yalnızca yüksek derecede optimize edilmiş eliptik eğri işlemleri (kuantum bilgisayarlarının yaygınlaşmasıyla bunlar da ortadan kalkacak).
Ana dezavantajı, hazır EOF'dan farklı olarak, yeni sanal makinenin getirilerinin geliştiricilere ulaşmasının uzun zaman almasıdır. Bu sorunu hafifletmek için, yüksek değerli EVM iyileştirmelerini (örneğin, sözleşme kodu boyut sınırını artırma, DUP/SWAP17-32 desteği) kısa vadede uygulayabiliriz.
Bu, daha basit bir sanal makine getirecek. Temel zorluk şudur: Mevcut EVM'yi nasıl yöneteceğiz?
Sanal Makine Geçişinin Geriye Dönük Uyumluluk Stratejisi
EVM'yi basitleştirmenin (veya karmaşıklığı artırmadan geliştirme) en büyük zorluğu, hedeflerin gerçekleştirilmesi ile mevcut uygulamaların geriye dönük uyumluluğu arasında nasıl bir denge kurulacağıdır.
Öncelikle netleştirmek gerekir ki: Ethereum kod deposunun (tek bir istemcide bile) yalnızca bir tanım şekli yoktur.
Amaç, yeşil alanı mümkün olduğunca küçültmektir: Düğümün Ethereum konsensüsüne katılması için gereken mantık, mevcut durumu hesaplama, kanıtlama, doğrulama, FOCIL (çatal seçme kuralı) ve “normal” blok inşasını içerir.
Turuncu alan azaltılamaz: Eğer protokol standartları belirli bir yürütme katmanı işlevini (örneğin sanal makine, önceden derleme vb.) kaldırır veya değiştirirse, geçmiş blokları işleyen istemcilerin ilgili kodları koruması gerekir. Ancak yeni istemciler, ZK-EVM veya biçimsel kanıtlayıcılar turuncu alanı tamamen göz ardı edebilir.
Yeni sarı alan: Mevcut zinciri anlamak veya blok inşasını optimize etmek için çok değerli, ancak konsensüs mantığına ait değildir. Örneğin, Etherscan ve bazı blok inşacıları ERC-4337 kullanıcı işlemlerini desteklemektedir. Zincir üzerindeki RISC-V uygulaması ile bazı Ethereum işlevlerini (EOA ve desteklediği eski işlem türleri gibi) değiştirdiğimizde, konsensüs kodu önemli ölçüde basitleşecektir, ancak özel düğümler mevcut kodu çözümlemeye devam edebilir.
Turuncu ve sarı alanların karmaşıklığı kapsülleme karmaşıklığıdır, protokolü anlayan kişiler bu kısımları atlayabilir, Ethereum bunları göz ardı edebilir, bu alanlardaki hatalar konsensüs riski oluşturmaz. Bu nedenle, turuncu ve sarı alanların kod karmaşıklığı, yeşil alanın karmaşıklığından çok daha az zarar vericidir.
Yeşil alandan sarı alana kod taşıma yaklaşımı, Apple'ın Rosetta çeviri katmanı aracılığıyla uzun vadeli geriye dönük uyumluluğu sağlama stratejisine benzer.
Ipsilon ekibinin son makalesinden ilham alarak, aşağıdaki sanal makine değişim sürecini öneriyorum (EVM'den RISC-V'ye örnek olarak, ancak EVM'den Cairo'ya veya RISC-V'den daha iyi bir sanal makineye de uygulanabilir):
1. Yeni ön derleme talep ediliyor: Zincir üstü RISC-V uygulaması: Ekosistemin RISC-V sanal makinesine kademeli olarak uyum sağlaması.
2. Geliştirici Seçeneği Olarak RISC-V'nin Tanıtılması: Protokol hem RISC-V hem de EVM'yi destekler, iki sanal makinenin sözleşmeleri serbestçe etkileşimde bulunabilir.
3. Çoğu Önceden Derlenmişi Değiştirme: Eliptik eğri işlemleri ve KECCAK (son derece hız gerektiği için) dışında, diğer önceden derlenmişlerin yerine RISC-V uygulanacaktır. Hard fork ile önceden derlenmişler kaldırılacak ve bu adresin kodu (DAO fork'una benzer şekilde) boşluktan RISC-V uygulamasına değiştirilecektir. RISC-V sanal makinesi son derece basittir, bu aşamada durulsa bile protokolü önemli ölçüde basitleştirmiş olur.
4. RISC-V'de EVM yorumlayıcısının uygulanması: Akıllı sözleşmelerin zincire eklenmesi (çünkü ZK kanıtlayıcısının yapılması gerekiyor). İlk yayınlandıktan yıllar sonra, mevcut EVM sözleşmeleri bu yorumlayıcı ile çalıştırılır.
adım tamamlandıktan sonra, birçok "EVM uygulaması" blok inşasını, geliştirici araçlarını ve zincir analizini optimize etmek için kullanılmaya devam edecek, ancak artık temel konsensüs standartlarının bir parçası olmayacak. Ethereum konsensüsü "doğal olarak" yalnızca RISC-V'yi anlayacak.
Paylaşım Protokol Bileşenini Basitleştirme
Protokol toplam karmaşıklığını azaltmanın üçüncü yolu (aynı zamanda en az değerlendirilen) mümkün olduğunca protokol yığınındaki farklı bölümlerde ortak standartların paylaşılmasıdır. Farklı protokoller, farklı senaryolarda aynı şeyleri yapmak için genellikle hiçbir fayda sağlamaz, ancak bu model yine de sıklıkla ortaya çıkar, esasen protokol yol haritasının farklı bölümleri arasındaki iletişim eksikliği nedeniyle. İşte bileşenleri paylaşarak Ethereum'u basitleştiren birkaç somut örnek.
Birlikte Düzeltme ve Silme Kodu
Üç senaryoda düzeltici hata kodlarına ihtiyacımız var:
1. Veri Erişilebilirliği Örneklemesi: İstemci, bloğun yayımlandığını doğruladı.
2. Daha Hızlı P2P Yayını: Düğümler n/2 parça aldıktan sonra blokları kabul edebilir, gecikme ile fazlalık arasında bir denge sağlanır.
3. Dağıtık Tarihsel Depolama: Ethereum tarih verileri parça parça depolanır, her grup n/2 parça ile diğer parçalar geri getirilebilir, tek bir parçanın kaybolma riskini azaltır.
Aynı hata düzeltme kodunu (Reed-Solomon, rastgele lineer kod vb. olsun) üç farklı senaryoda kullanırsanız, aşağıdaki avantajları elde edersiniz:
1. Kod Miktarını Minimuma İndirin: Toplam kod satır sayısını azaltın.
2. Verimliliği Artırma: Eğer bir düğüm belirli bir senaryo için kısmi parçaları indiriyorsa, bu veriler diğer senaryolar için kullanılabilir.
3. Doğrulanabilirliği Sağlayın: Tüm sahne kesitleri kök doğrulamasına göre doğrulanabilir.
Farklı hata düzeltme kodları kullanılıyorsa, en azından uyumluluğun sağlanması gerekir; örneğin, veri kullanılabilirliği örneklemesi için yatay Reed-Solomon kodları ve dikey rastgele lineer kodlar aynı alanda çalışmalıdır.
Birleşik Serileştirme Formatı
Ethereum'un serileştirme formatı şu anda yalnızca kısmen katılaşmıştır, çünkü veriler herhangi bir formatta yeniden serileştirilebilir ve yayınlanabilir. İstisna, işlem imza hash'idir, bu hash'in standart bir formatta yapılması gerekir. Gelecekte, serileştirme formatının katılaşma derecesi aşağıdaki nedenlerden dolayı daha da artacaktır:
1. Tam Hesap Soyutlama (EIP-7701): İşlemin tam içeriği sanal makineye görünür.
2. Daha Yüksek Gas Limiti: İşlem katmanı verileri veri bloklarına (blobs) yerleştirilmelidir.
O tarihte, Ethereum'un üç seviyesindeki serileştirme formatını birleştirme fırsatımız olacak: yürütme katmanı, konsensüs katmanı, akıllı sözleşme çağrısı ABI.
SSZ kullanmayı öneriyorum çünkü SSZ:
Kodlaması kolay: Akıllı sözleşmeler içinde yer alır (4 baytlık tasarımı ve daha az kenar durumu nedeniyle).
Konsens katmanında yaygın olarak kullanılmıştır.
Mevcut ABI ile yüksek benzerlik: Araç uyarlaması görece basit.
SSZ'ye tam geçiş için zaten çabalar var, gelecekteki yükseltmeleri planlarken bu çabaları dikkate almalı ve sürdürmeliyiz.
Eşit Ağaç Yapısı
EVM'den RISC-V'ye (veya diğer bir seçilebilir minimum sanal makineye) geçiş yapıldığında, onaltılık Merkle Patricia ağacı, blok yürütmesini kanıtlama açısından en büyük darboğaz haline gelecektir, bu durum ortalama koşullarda bile geçerlidir. Daha iyi bir hash fonksiyonuna dayalı ikili ağaçlara geçiş, kanıtlayıcı verimliliğini önemli ölçüde artıracak ve hafif istemci gibi senaryoların veri maliyetlerini düşürecektir.
Taşınma sırasında, konsensüs katmanının aynı ağaç yapısını kullandığından emin olunmalıdır. Bu, Ethereum'un konsensüs katmanının, yürütme katmanına aynı kodla erişilmesini ve çözümlemesini sağlayacaktır.
Şu andan geleceğe
Basitlik birçok açıdan merkeziyetsizlikle benzerlik gösterir; her ikisi de dayanıklılık hedeflerinin amacıdır. Basitliğe verilen önemin açık bir şekilde ortaya konması, belirli bir kültürel dönüşüm gerektirir. Bunun faydaları genellikle ölçülmesi zor olup, ek çaba ve bazı göz alıcı işlevlerden vazgeçmenin maliyeti ise hemen görülebilir. Ancak zamanla, faydalar daha belirgin hale gelecektir - Bitcoin'in kendisi bunun mükemmel bir örneğidir.
tinygrad'ı örnek almayı öneriyorum, Ethereum'un uzun vadeli standartları için net bir maksimum kod satırı hedefi belirleyelim, böylece Ethereum'un konsensüs ana kodu Bitcoin'in basitliğine yakın hale gelsin. Ethereum'un tarihsel kurallarını işleyen kod var olmaya devam edecek, ancak bu kod konsensüs ana yolunun dışında tutulmalıdır. Aynı zamanda, daha basit çözümler seçme ilkesine bağlı kalmalı, karmaşıklığı paketleme yerine sistematik karmaşıklığı tercih etmeliyiz ve net özellikler ve garantiler sağlayan tasarım seçimleri yapmalıyız.
The content is for reference only, not a solicitation or offer. No investment, tax, or legal advice provided. See Disclaimer for more risks disclosure.
Vitalik blog yazısı: 5 yıl sonra Ethereum'u Bitcoin kadar basit hale nasıl getirebiliriz
Özet
Ethereum, küresel bir defter olmayı hedefliyor ve ölçeklenebilirlik ile dayanıklılığa ihtiyaç duyuyor. Bu makale, protokol basitliğinin önemine odaklanmakta ve karmaşıklığı büyük ölçüde azaltmak için konsensüs katmanını (3-slot nihaiyet, STARK toplama) ve yürütme katmanını (EVM'yi RISC-V veya benzeri bir sanal makine ile değiştirme) basitleştirmeyi önermektedir. Geriye dönük uyum stratejileri (örneğin, zincir üstü EVM yorumlayıcısı) aracılığıyla yumuşak bir geçiş önerilmektedir ve ek olarak, hata düzeltme kodlarını, serileştirme formatlarını (SSZ) ve ağaç yapılarını birleştirerek daha fazla basitlik sağlanmalıdır. Hedef, Ethereum'un konsensüs ana kodunun Bitcoin'in basitliğine yaklaşmasını sağlamak, dayanıklılığı ve katılımı artırmaktır; bu amaçla kültürel olarak basitliğe önem verilmeli ve maksimum kod satırı sayısı hedefleri belirlenmelidir.
Ethereum'un hedefi, insanlık medeniyetinin varlıklarını ve kayıtlarını depolayan, finans, yönetim, yüksek değerli veri doğrulama gibi alanlara hizmet eden küresel bir defter olmaktır. Bu, iki yönlü bir desteği gerektirir: ölçeklenebilirlik ve dayanıklılık. Fusaka hard fork planı, L2 verilerinin kullanılabilir alanını 10 kat artırmayı hedefliyor, mevcut önerilen 2026 yol haritası da L1 katmanına benzer büyük yükseltmeler getirmeyi planlıyor. Bu arada, Ethereum, hisse kanıtına (PoS) geçişini tamamladı, istemci çeşitliliği hızla arttı, sıfır bilgi (ZK) doğrulama ve kuantum dayanıklılığı araştırmaları da istikrarlı bir şekilde ilerliyor, uygulama ekosistemi giderek güçleniyor.
Bu makale, aynı zamanda önemli ama genellikle göz ardı edilen bir dayanıklılık (hatta ölçeklenebilirlik) unsuru olan: Protokolün basitliği.
Bitcoin protokolünün en etkileyici yanı zarif sadeliğidir:
Her bir bloğun bir önceki blokla hash kullanarak bağlantı kurduğu bloklardan oluşan bir zincir vardır.
Blokların geçerliliği, iş kanıtı (PoW) ile doğrulanır, yani hash değerinin ilk birkaç basamağının sıfır olup olmadığını kontrol eder.
Her blok, ya madencilik ödüllerinden ya da önceki işlem çıktılarından gelen işlemler içerir.
Bütün bunlar bu kadar! Akıllı bir lise öğrencisi bile Bitcoin protokolünün nasıl çalıştığını tamamen anlayabilir ve bir programcı bunu bir hobi projesi olarak bir istemci yazabilir.
Sözleşmenin basitliği, Bitcoin'in (ve Ethereum'un) güvenilir, tarafsız bir küresel temel katman haline gelmesi için birçok önemli avantaj sunmuştur:
1. Anlaşılması Kolay: Protokolün karmaşıklığını azaltarak daha fazla kişinin protokol araştırma, geliştirme ve yönetimine katılmasını sağlamak, teknik elit tabakasının hakimiyet riskini azaltmak.
2. Geliştirme Maliyetlerini Düşürmek: Protokolü basitleştirmek, yeni altyapı (yeni istemciler, kanıtlayıcılar, geliştirici araçları vb.) oluşturma maliyetini önemli ölçüde azaltır.
3. Bakım yükünü azaltın: Uzun vadeli anlaşmaların bakım maliyetlerini düşürün.
4. Hata Riskini Azaltma: Protokol spesifikasyonları ve uygulamaları sırasında felaket hatalarının olasılığını azaltmak ve böyle hataların bulunmadığını doğrulamayı kolaylaştırmak.
5. Saldırı yüzeyini küçültme: Protokolün karmaşık bileşenlerini azaltarak, özel çıkar grupları tarafından saldırıya uğrama riskini düşürmek.
Tarihsel olarak, Ethereum (bazen kişisel kararlarımdan dolayı) genellikle basitliği koruyamamıştır, bu da yüksek geliştirme maliyetlerine, artan güvenlik risklerine ve Ar-Ge kültürünün kapalı olmasına yol açmıştır. Bu karmaşıklık arayışının getirilerinin çoğu genellikle hayali olduğu kanıtlanmıştır. Bu makale, beş yıl sonra Ethereum'un Bitcoin'in basitliğine nasıl yaklaşacağını araştıracaktır.
Basitleştirilmiş Konsensüs Katmanı
Yeni konsensüs katmanı tasarımı (tarihte "Beacon Chain" olarak adlandırılan) son on yılda konsensüs teorisi, ZK-SNARK geliştirme, stake ekonomisi gibi alanlardaki deneyimlerden yararlanarak uzun vadede en iyi ve daha basit bir konsensüs katmanı inşa etmeyi amaçlamaktadır. Mevcut Beacon Chain ile karşılaştırıldığında, yeni tasarım belirgin şekilde basitleştirilmiştir:
1. 3-slot nihai tasarımı: Slot, dönem ve komite yeniden yapılandırması gibi kavramları ve ilgili verimli işleme mekanizmalarını (örneğin, senkronizasyon komiteleri) ortadan kaldırır. 3-slot nihai tasarımının temel uygulanması yalnızca yaklaşık 200 satır kod gerektirir ve Gasper'a kıyasla güvenlik açısından neredeyse optimumdur.
2. Aktif doğrulayıcı sayısını azaltın: Daha basit bir çatallama seçimi kuralı kullanarak uygulanmasına izin verin, güvenliği artırın.
3. STARK Tabanlı Birleştirme Protokolü: Herkes birleştirici olabilir, birleştiriciye güvenmeye veya tekrar eden alanlar için yüksek maliyetler ödemeye gerek yoktur. Birleştirme kriptografisinin karmaşıklığı yüksektir, ancak bu karmaşıklık yüksek oranda paketlenmiştir, sistematik riskler daha düşüktür.
4. P2P Yapısını Basitleştirme: Yukarıdaki faktörler, daha basit ve daha sağlam bir eşler arası ağ yapısını destekleyebilir.
5. Doğrulayıcı mekanizmasının yeniden tasarımı: Giriş, çıkış, para çekme, anahtar geçişi, inactivity leak gibi mekanizmaları içermekte, kod satır sayısını basitleştirmekte ve daha net garantiler sunmaktadır (örneğin, zayıf öznelite döngüsü).
Konsens katmanının avantajı, EVM yürütme katmanına göre nispeten bağımsız olmasıdır, bu nedenle sürekli iyileştirme için daha fazla alan vardır. Daha büyük zorluk, yürütme katmanında benzer bir basitleştirmeyi nasıl gerçekleştireceğimizdir.
Basit İcra Katmanı
EVM'nin karmaşıklığı giderek artmakta ve birçok karmaşıklığın gereksiz olduğu kanıtlanmıştır (bir kısmı kişisel karar hatalarımdan kaynaklanmaktadır): 256 bit sanal makine, artık giderek modası geçmiş belirli kriptografik biçimleri aşırı optimize etmiştir, önceden derlenmiş (precompiles) tek bir kullanım durumu için optimize edilmiş olmasına rağmen pek kullanılmamaktadır.
Bu sorunları teker teker çözmek sınırlı etki gösteriyor. Örneğin, SELFDESTRUCT opcode'unu kaldırmak büyük çaba gerektiriyor ama sadece küçük bir kazanç sağlıyor. Son zamanlarda EOF (EVM Object Format) hakkında yapılan tartışmalar da benzer zorlukları ortaya koyuyor.
Son zamanlarda daha radikal bir öneri sundum: EVM'yi orta ölçekli (ama yine de yıkıcı) değişiklikler yapmak yerine 1.5 kat fayda sağlamak için daha iyi ve daha basit bir sanal makineye geçiş yaparak 100 kat fayda sağlamak. "Birleşme" (The Merge) benzeri, yıkıcı değişikliklerin sayısını azaltıyoruz, ancak her bir değişikliği daha anlamlı hale getiriyoruz. Özellikle, EVM'nin RISC-V ile değiştirilmesini veya Ethereum'un ZK kanıtlayıcıları tarafından kullanılan başka bir sanal makineyi öneriyorum. Bu şunları getirecektir:
1. Önemli ölçüde geliştirilmiş verimlilik: Akıllı sözleşme yürütme (kanıtlayıcıda) tercüman ek yükü olmadan çalışır. Succinct'in verileri, birçok senaryoda 100 kattan fazla performans artışı olduğunu gösteriyor.
2. Basitlikte Büyük İyileşme: RISC-V standardı EVM'ye göre son derece basit, alternatifler (örneğin Cairo) de aynı şekilde sade.
3. EOF'u desteklemenin motivasyonu: Kod bölümlendirmesi, daha dostça statik analiz, daha büyük kod boyutu sınırlamaları vb.
4. Daha Fazla Geliştirici Seçenekleri: Solidity ve Vyper, yeni sanal makineye derlemek için arka uç ekleyebilir. RISC-V seçilirse, ana akım dil geliştiricileri de kodlarını bu sanal makineye kolayca taşıyabilir.
5. Çoğu önceden derlenmişin kaldırılması: Yalnızca yüksek derecede optimize edilmiş eliptik eğri işlemleri (kuantum bilgisayarlarının yaygınlaşmasıyla bunlar da ortadan kalkacak).
Ana dezavantajı, hazır EOF'dan farklı olarak, yeni sanal makinenin getirilerinin geliştiricilere ulaşmasının uzun zaman almasıdır. Bu sorunu hafifletmek için, yüksek değerli EVM iyileştirmelerini (örneğin, sözleşme kodu boyut sınırını artırma, DUP/SWAP17-32 desteği) kısa vadede uygulayabiliriz.
Bu, daha basit bir sanal makine getirecek. Temel zorluk şudur: Mevcut EVM'yi nasıl yöneteceğiz?
Sanal Makine Geçişinin Geriye Dönük Uyumluluk Stratejisi
EVM'yi basitleştirmenin (veya karmaşıklığı artırmadan geliştirme) en büyük zorluğu, hedeflerin gerçekleştirilmesi ile mevcut uygulamaların geriye dönük uyumluluğu arasında nasıl bir denge kurulacağıdır.
Öncelikle netleştirmek gerekir ki: Ethereum kod deposunun (tek bir istemcide bile) yalnızca bir tanım şekli yoktur.
Amaç, yeşil alanı mümkün olduğunca küçültmektir: Düğümün Ethereum konsensüsüne katılması için gereken mantık, mevcut durumu hesaplama, kanıtlama, doğrulama, FOCIL (çatal seçme kuralı) ve “normal” blok inşasını içerir.
Turuncu alan azaltılamaz: Eğer protokol standartları belirli bir yürütme katmanı işlevini (örneğin sanal makine, önceden derleme vb.) kaldırır veya değiştirirse, geçmiş blokları işleyen istemcilerin ilgili kodları koruması gerekir. Ancak yeni istemciler, ZK-EVM veya biçimsel kanıtlayıcılar turuncu alanı tamamen göz ardı edebilir.
Yeni sarı alan: Mevcut zinciri anlamak veya blok inşasını optimize etmek için çok değerli, ancak konsensüs mantığına ait değildir. Örneğin, Etherscan ve bazı blok inşacıları ERC-4337 kullanıcı işlemlerini desteklemektedir. Zincir üzerindeki RISC-V uygulaması ile bazı Ethereum işlevlerini (EOA ve desteklediği eski işlem türleri gibi) değiştirdiğimizde, konsensüs kodu önemli ölçüde basitleşecektir, ancak özel düğümler mevcut kodu çözümlemeye devam edebilir.
Turuncu ve sarı alanların karmaşıklığı kapsülleme karmaşıklığıdır, protokolü anlayan kişiler bu kısımları atlayabilir, Ethereum bunları göz ardı edebilir, bu alanlardaki hatalar konsensüs riski oluşturmaz. Bu nedenle, turuncu ve sarı alanların kod karmaşıklığı, yeşil alanın karmaşıklığından çok daha az zarar vericidir.
Yeşil alandan sarı alana kod taşıma yaklaşımı, Apple'ın Rosetta çeviri katmanı aracılığıyla uzun vadeli geriye dönük uyumluluğu sağlama stratejisine benzer.
Ipsilon ekibinin son makalesinden ilham alarak, aşağıdaki sanal makine değişim sürecini öneriyorum (EVM'den RISC-V'ye örnek olarak, ancak EVM'den Cairo'ya veya RISC-V'den daha iyi bir sanal makineye de uygulanabilir):
1. Yeni ön derleme talep ediliyor: Zincir üstü RISC-V uygulaması: Ekosistemin RISC-V sanal makinesine kademeli olarak uyum sağlaması.
2. Geliştirici Seçeneği Olarak RISC-V'nin Tanıtılması: Protokol hem RISC-V hem de EVM'yi destekler, iki sanal makinenin sözleşmeleri serbestçe etkileşimde bulunabilir.
3. Çoğu Önceden Derlenmişi Değiştirme: Eliptik eğri işlemleri ve KECCAK (son derece hız gerektiği için) dışında, diğer önceden derlenmişlerin yerine RISC-V uygulanacaktır. Hard fork ile önceden derlenmişler kaldırılacak ve bu adresin kodu (DAO fork'una benzer şekilde) boşluktan RISC-V uygulamasına değiştirilecektir. RISC-V sanal makinesi son derece basittir, bu aşamada durulsa bile protokolü önemli ölçüde basitleştirmiş olur.
4. RISC-V'de EVM yorumlayıcısının uygulanması: Akıllı sözleşmelerin zincire eklenmesi (çünkü ZK kanıtlayıcısının yapılması gerekiyor). İlk yayınlandıktan yıllar sonra, mevcut EVM sözleşmeleri bu yorumlayıcı ile çalıştırılır.
Paylaşım Protokol Bileşenini Basitleştirme
Protokol toplam karmaşıklığını azaltmanın üçüncü yolu (aynı zamanda en az değerlendirilen) mümkün olduğunca protokol yığınındaki farklı bölümlerde ortak standartların paylaşılmasıdır. Farklı protokoller, farklı senaryolarda aynı şeyleri yapmak için genellikle hiçbir fayda sağlamaz, ancak bu model yine de sıklıkla ortaya çıkar, esasen protokol yol haritasının farklı bölümleri arasındaki iletişim eksikliği nedeniyle. İşte bileşenleri paylaşarak Ethereum'u basitleştiren birkaç somut örnek.
Birlikte Düzeltme ve Silme Kodu
Üç senaryoda düzeltici hata kodlarına ihtiyacımız var:
1. Veri Erişilebilirliği Örneklemesi: İstemci, bloğun yayımlandığını doğruladı.
2. Daha Hızlı P2P Yayını: Düğümler n/2 parça aldıktan sonra blokları kabul edebilir, gecikme ile fazlalık arasında bir denge sağlanır.
3. Dağıtık Tarihsel Depolama: Ethereum tarih verileri parça parça depolanır, her grup n/2 parça ile diğer parçalar geri getirilebilir, tek bir parçanın kaybolma riskini azaltır.
Aynı hata düzeltme kodunu (Reed-Solomon, rastgele lineer kod vb. olsun) üç farklı senaryoda kullanırsanız, aşağıdaki avantajları elde edersiniz:
1. Kod Miktarını Minimuma İndirin: Toplam kod satır sayısını azaltın.
2. Verimliliği Artırma: Eğer bir düğüm belirli bir senaryo için kısmi parçaları indiriyorsa, bu veriler diğer senaryolar için kullanılabilir.
3. Doğrulanabilirliği Sağlayın: Tüm sahne kesitleri kök doğrulamasına göre doğrulanabilir.
Farklı hata düzeltme kodları kullanılıyorsa, en azından uyumluluğun sağlanması gerekir; örneğin, veri kullanılabilirliği örneklemesi için yatay Reed-Solomon kodları ve dikey rastgele lineer kodlar aynı alanda çalışmalıdır.
Birleşik Serileştirme Formatı
Ethereum'un serileştirme formatı şu anda yalnızca kısmen katılaşmıştır, çünkü veriler herhangi bir formatta yeniden serileştirilebilir ve yayınlanabilir. İstisna, işlem imza hash'idir, bu hash'in standart bir formatta yapılması gerekir. Gelecekte, serileştirme formatının katılaşma derecesi aşağıdaki nedenlerden dolayı daha da artacaktır:
1. Tam Hesap Soyutlama (EIP-7701): İşlemin tam içeriği sanal makineye görünür.
2. Daha Yüksek Gas Limiti: İşlem katmanı verileri veri bloklarına (blobs) yerleştirilmelidir.
O tarihte, Ethereum'un üç seviyesindeki serileştirme formatını birleştirme fırsatımız olacak: yürütme katmanı, konsensüs katmanı, akıllı sözleşme çağrısı ABI.
SSZ kullanmayı öneriyorum çünkü SSZ:
Kodlaması kolay: Akıllı sözleşmeler içinde yer alır (4 baytlık tasarımı ve daha az kenar durumu nedeniyle).
Konsens katmanında yaygın olarak kullanılmıştır.
Mevcut ABI ile yüksek benzerlik: Araç uyarlaması görece basit.
SSZ'ye tam geçiş için zaten çabalar var, gelecekteki yükseltmeleri planlarken bu çabaları dikkate almalı ve sürdürmeliyiz.
Eşit Ağaç Yapısı
EVM'den RISC-V'ye (veya diğer bir seçilebilir minimum sanal makineye) geçiş yapıldığında, onaltılık Merkle Patricia ağacı, blok yürütmesini kanıtlama açısından en büyük darboğaz haline gelecektir, bu durum ortalama koşullarda bile geçerlidir. Daha iyi bir hash fonksiyonuna dayalı ikili ağaçlara geçiş, kanıtlayıcı verimliliğini önemli ölçüde artıracak ve hafif istemci gibi senaryoların veri maliyetlerini düşürecektir.
Taşınma sırasında, konsensüs katmanının aynı ağaç yapısını kullandığından emin olunmalıdır. Bu, Ethereum'un konsensüs katmanının, yürütme katmanına aynı kodla erişilmesini ve çözümlemesini sağlayacaktır.
Şu andan geleceğe
Basitlik birçok açıdan merkeziyetsizlikle benzerlik gösterir; her ikisi de dayanıklılık hedeflerinin amacıdır. Basitliğe verilen önemin açık bir şekilde ortaya konması, belirli bir kültürel dönüşüm gerektirir. Bunun faydaları genellikle ölçülmesi zor olup, ek çaba ve bazı göz alıcı işlevlerden vazgeçmenin maliyeti ise hemen görülebilir. Ancak zamanla, faydalar daha belirgin hale gelecektir - Bitcoin'in kendisi bunun mükemmel bir örneğidir.
tinygrad'ı örnek almayı öneriyorum, Ethereum'un uzun vadeli standartları için net bir maksimum kod satırı hedefi belirleyelim, böylece Ethereum'un konsensüs ana kodu Bitcoin'in basitliğine yakın hale gelsin. Ethereum'un tarihsel kurallarını işleyen kod var olmaya devam edecek, ancak bu kod konsensüs ana yolunun dışında tutulmalıdır. Aynı zamanda, daha basit çözümler seçme ilkesine bağlı kalmalı, karmaşıklığı paketleme yerine sistematik karmaşıklığı tercih etmeliyiz ve net özellikler ve garantiler sağlayan tasarım seçimleri yapmalıyız.