Ethereum, küresel bir defter olmayı hedefliyor ve ölçeklenebilirlik ve esnekliğe ihtiyaç duyuyor. Bu makale, protokol basitliğinin önemine odaklanmakta ve konsensüs katmanını (3 yuvalı kesinlik, STARK toplama) ve yürütme katmanını (EVM'yi RISC-V veya benzeri sanal makinelerle değiştirerek) basitleştirerek karmaşıklığı, geliştirme maliyetlerini, hata riskini ve saldırı yüzeyini önemli ölçüde azaltmayı önermektedir. Zincir üstü EVM yorumlayıcıları gibi geriye dönük uyumluluk stratejilerine geçişin kolaylaştırılması ve daha fazla basitleştirme için silme kodlaması, serileştirme formatı (SSZ) ve ağaç yapısının birleştirilmesi önerilir. Amaç, Ethereum konsensüsünün anahtar kodunu Bitcoin'in basitliğine yaklaştırmak, esnekliği ve katılımı artırmak ve basitliğe ve maksimum sayıda kod satırı hedefine kültürel bir odaklanma gerektirmektir.
Ethereum'un hedefi, insanlık medeniyeti varlıklarını ve kayıtlarını depolayan bir küresel defter olmaktır; finans, yönetim, yüksek değerli veri doğrulama gibi alanlara hizmet etmektedir. Bu, iki alanda destek gerektirir: ölçeklenebilirlik ve dayanıklılık. Fusaka sert çatallama planı, L2 verilerinin kullanılabilir alanını 10 kat artıracakken, mevcut önerilen 2026 yol haritası da L1 katmanına benzer büyük bir artış getirmeyi planlamaktadır. Bu arada, Ethereum, hisse kanıtına (PoS) geçişini tamamladı ve istemci çeşitliliği hızla artmakta, sıfır bilgi (ZK) doğrulama, kuantum dayanıklılığı araştırmaları da istikrarlı bir şekilde ilerlemekte, uygulama ekosistemi giderek sağlamlaşmaktadır.
Bu makale, aynı derecede önemli ama genellikle göz ardı edilen bir dayanıklılık (ve hatta ölçeklenebilirlik) unsuru olan: protokolün basitliğine odaklanmayı amaçlamaktadır.
Bitcoin protokolünün en etkileyici yönü, zarif sadeliğidir:
Bloklardan oluşan bir zincir vardır, her blok bir önceki blok ile hash ile bağlanır.
Blokların geçerliliği, hash değerinin başındaki birkaç basamağın sıfır olup olmadığını kontrol eden iş kanıtı (PoW) ile doğrulanır.
Her blok, işlemler içerir; işlemler için harcanan coinler ya madencilik ödüllerinden ya da önceki işlem çıktılarından gelir.
Hepsi bu kadar! Hatta zeki bir lise öğrencisi bile Bitcoin protokolünün nasıl çalıştığını tam olarak anlayabilirken, bir programcı bunu hobi projesi olarak bir istemci yazabilir.
Protokolün basitliği, Bitcoin'in (ve Ethereum'un) güvenilir, tarafsız bir küresel temel katman olmasına birçok önemli avantaj getirmiştir:
Anlaşılması kolay: Protokolün karmaşıklığını azaltarak daha fazla kişinin protokol araştırmalarına, geliştirmelerine ve yönetimine katılmasını sağlamak, teknik elitlerin hakimiyet riskiyi azaltmak.
Geliştirme maliyetlerini düşürmek: Protokolü basitleştirmek, yeni altyapı (yeni istemci, kanıtlayıcı, geliştirici araçları vb.) oluşturma maliyetlerini önemli ölçüde azaltır.
Bakım yükünü azaltma: Uzun vadeli sözleşme bakım maliyetlerini düşürmek.
Hata riskini azaltma: Protokol standartları ve uygulamalarında felaket hatalarının meydana gelme olasılığını düşürmek ve bu tür hataların mevcut olmadığını doğrulamayı kolaylaştırmak.
Saldırı yüzeyini küçültmek: 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 geliştirme maliyetlerinin çok yüksek olmasına, güvenlik risklerinin artmasına ve Ar-Ge kültürünün kapalı olmasına yol açmıştır ve bu karmaşıklık arayışının getirileri 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ı inceleyecektir.
Basitleştirilmiş Konsensüs Katmanı
Yeni konsensüs katmanı tasarımı (tarihsel olarak "işaret zinciri" olarak adlandırılır), son on yılda konsensüs teorisi, ZK-SNARK geliştirme, staking ekonomisi gibi alanlardaki deneyimlerden yararlanarak, uzun vadede en iyi ve daha basit bir konsensüs katmanı inşa etmeyi amaçlamaktadır. Mevcut işaret zincirine kıyasla, yeni tasarım önemli ölçüde basitleştirilmiştir:
3-slot nihai tasarımı: slot, dönem, komite yeniden yapılandırması gibi kavramların ve ilgili verimli işleme mekanizmalarının (örneğin senkronizasyon komiteleri) kaldırılması. 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 optimaldir.
Aktif doğrulayıcı sayısını azaltmak: Daha basit çatal seçim kurallarının uygulanmasına izin vererek güvenliği artırmak.
STARK'a dayalı toplama protokolü: Herkes toplayıcı olabilir, toplayıcıya güvenmeye veya tekrar eden alanlar için yüksek maliyetler ödemeye gerek yoktur. Toplama kriptografisinin karmaşıklığı yüksektir, ancak bu karmaşıklık yüksek derecede paketlenmiştir, sistemik risk daha düşüktür.
P2P mimarisini basitleştirme: Yukarıda belirtilen faktörler, daha basit ve daha sağlam bir eşler arası ağ mimarisini destekleyebilir.
Doğrulayıcı mekanizmasının yeniden tasarımı: Katılım, çıkış, para çekme, anahtar dönüşümü, faaliyetsizlik sızıntısı gibi mekanizmaları içerir; kod satır sayısını basitleştirir ve daha net garantiler sağlar (örneğin, zayıf öznelite döngüsü).
Konsens katmanının avantajı, EVM yürütme katmanından görece bağımsız olmasıdır, bu nedenle sürekli iyileştirme için daha fazla alan vardır. Daha büyük zorluk ise yürütme katmanında benzer bir basitleştirmenin nasıl gerçekleştirileceğidir.
Basitleştirilmiş İcra Katmanı
EVM'nin karmaşıklığı giderek artıyor ve birçok karmaşıklığın gereksiz olduğu kanıtlandı (bir kısmı benim kişisel karar hatalarımdan kaynaklanıyor): 256 bit sanal makine, artık yavaş yavaş eskiye dönmeye başlayan belirli kriptografik formları aşırı optimize etti, önceden derlenmiş (precompiles) tek bir kullanım durumu için optimize edildi fakat nadiren kullanılıyor.
Bu sorunları tek tek çözmenin etkisi sınırlıdır. Örneğin, SELFDESTRUCT opcode'unu kaldırmak büyük çaba gerektirir, ancak yalnızca küçük faydalar sağlar. Son zamanlarda EOF (EVM Object Format) hakkında yapılan tartışmalar da benzer zorlukları göstermektedir.
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 kazanç elde etmek için daha iyi, daha basit bir sanal makineye geçiş yaparak 100 kat kazanç elde etmeyi tercih edelim. "Birleşme" (The Merge) gibi, yıkıcı değişikliklerin sayısını azaltıyoruz, ancak her değişikliğin daha anlamlı olmasını sağlıyoruz. Özellikle, EVM'nin RISC-V ile değiştirilmesini veya Ethereum ZK kanıtlayıcılarının kullandığı başka bir sanal makineyi öneriyorum. Bu, şunları getirecektir:
Verimlilikte büyük artış: Akıllı sözleşmelerin yürütülmesi (kanıtlayıcıda) yorumlayıcı giderleri olmadan doğrudan çalışır. Succinct'in verileri birçok senaryoda performansın 100 katından fazla artabileceğini gösteriyor.
Basitlikte büyük iyileştirme: RISC-V standardı EVM'ye göre son derece basit ve alternatifler (örneğin Cairo) de aynı şekilde sade.
EOF'u desteklemenin motivasyonu: kod bölümlendirme, daha dostça statik analiz, daha büyük kod boyutu sınırları vb.
Daha fazla geliştirici seçeneği: Solidity ve Vyper, yeni sanal makineye derlemek için arka uç ekleyebilir. RISC-V'yi seçerseniz, ana akım dil geliştiricileri de kodlarını bu sanal makineye kolayca taşıyabilir.
Çoğu önceden derlenmiş olanı kaldırın: Yüksek derecede optimize edilmiş eliptik eğri işlemlerini korumak mümkün olabilir (kuantum bilgisayarların yaygınlaşmasından sonra bunlar da kaybolacak).
Ana dezavantaj, hazır EOF ile karşılaştırıldığında, yeni sanal makinenin kazançlarının geliştiricilere ulaşmasının uzun zaman almasıdır. Bu sorunu hafifletmek için, kısa vadede yüksek değerli EVM iyileştirmeleri (örneğin, sözleşme kodu boyutu sınırını artırmak, DUP/SWAP17–32'yi desteklemek) 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 iyileştirmenin) 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ştirilmesi gereken bir şey var: Ethereum kod tabanı (tek bir istemci içinde bile) yalnızca bir tanım şekline sahip değildir.
Hedef, 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 hesaplamayı, kanıtlamayı, doğrulamayı, FOCIL (çatallama seçme kuralları) ve "normal" blok inşasını içerir.
Turuncu alan azaltılamaz: Eğer protokol standardı belirli bir yürütme katmanı işlevini (örneğin sanal makine, önceden derlenmiş gibi) kaldırır veya değiştirirse, geçmiş blokları işleyen istemcilerin ilgili kodu tutması gerekir. Ancak yeni istemciler, ZK-EVM veya biçimsel kanıtlayıcılar turuncu alanı tamamen göz ardı edebilir.
Yeni eklenen sarı alan: mevcut zinciri anlamak veya blok inşasını optimize etmek için çok değerlidir, ancak konsensüs mantığına ait değildir. Örneğin, Etherscan ve bazı blok inşacıları ERC-4337 kullanıcı işlemlerini destekler. Eğer bazı Ethereum işlevlerini (örneğin, EOA ve desteklediği eski işlem türleri) zincir üzerindeki RISC-V uygulamasıyla değiştirirsek, konsensüs kodu önemli ölçüde basitleşecektir, ancak özel düğümler hâlâ orijinal kodu çözümlemek için kullanmaya devam edebilir.
Turuncu ve sarı alanların karmaşıklığı, karmaşıklığı kapsama alanıdır; protokolü anlayan kişiler bu kısımları atlayabilir, Ethereum bunları göz ardı edebilir, bu alanlardaki hatalar konsensüs riski doğurmaz. Bu nedenle, turuncu ve sarı alanların kod karmaşıklığı, yeşil alanın karmaşıklığından çok daha az tehlikelidir.
Yeşil alandan sarı alana kod taşımak için izlenen yaklaşım, Apple'ın Rosetta çeviri katmanı aracılığıyla uzun vadeli geriye dönük uyumluluğu sağlamaya yönelik stratejisine benzer.
Ipsilon ekibinin son makalelerinden 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):
Yeni ön derlemenin zincir üzerindeki RISC-V uygulamasını sağlaması gerekmektedir: Ekosistemin RISC-V sanal makinesine aşamalı olarak uyum sağlaması.
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şebilir.
Çoğu önceden derlenmiş kodun değiştirilmesi: Eliptik eğri işlemleri ve KECCAK (aşırı hız gerektirdiği için) dışındaki diğer önceden derlenmiş kodlar RISC-V ile değiştirilmiştir. Hard fork ile önceden derlenmiş kod kaldırılmış ve bu adresin kodu (DAO fork'una benzer şekilde) boşluktan RISC-V uygulamasına değiştirilmiştir. RISC-V sanal makinesi son derece basittir, bu noktada durmak bile protokolü net bir şekilde basitleştirir.
RISC-V'de EVM yorumlayıcısını uygulamak: Akıllı sözleşmelerin zincire eklenmesi (ZK kanıtlayıcının gerekli olduğu nedeniyle). İlk birkaç yılın ardından, mevcut EVM sözleşmeleri bu yorumlayıcı aracılığıyla çalıştırılır.
adımın tamamlanmasının ardından birçok "EVM uygulaması" hâlâ blok inşasını, geliştirici araçlarını ve zincir analizini optimize etmek için kullanılacak, ancak artık temel konsensüs spesifikasyonlarının bir parçası olmayacak. Ethereum konsensüsü, "yerel olarak" yalnızca RISC-V'yi anlayacak.
Paylaşım protokol bileşenlerini basitleştirerek
Protokolün toplam karmaşıklığını azaltmanın üçüncü yolu (aynı zamanda en hafife alınan) mümkün olduğunca protokol yığını farklı bölümlerinde ortak standartların paylaşılmasıdır. Farklı protokoller, farklı senaryolarda aynı şeyleri yapmak için genellikle faydasızdır, ancak bu model yine de sıkça ortaya çıkmaktadır, esasen protokol yol haritasının farklı bölümleri arasında iletişim eksikliği nedeniyle. Aşağıda, bileşenleri paylaşarak Ethereum'u basitleştirmenin birkaç somut örneği bulunmaktadır.
Birleşik Silme Kodları
Üç senaryoda hata düzeltme koduna ihtiyacımız var:
Veri kullanılabilirliği örnekleme: İstemci, blokların yayımlandığını doğrular.
Daha hızlı P2P yayın: Düğüm, blokları kabul etmek için n/2 parça aldıktan sonra, gecikme ile fazlalık arasında bir denge kurar.
Dağıtık tarihsel depolama: Ethereum tarih verileri parça parça depolanır, her grup n/2 parça ile geri kalan parçalar kurtarılabilir, bu da tek bir parçanın kaybolma riskini azaltır.
Aynı hata düzeltme kodunun (Reed-Solomon, rastgele lineer kodlar vb. olsun) üç senaryoda kullanılması durumunda aşağıdaki avantajlar elde edilecektir:
Kod miktarını en aza indirin: Toplam kod satır sayısını azaltın.
Verimliliği artırma: Eğer bir düğüm belirli bir senaryo için bazı parçaları indiriyorsa, bu veriler diğer senaryolar için kullanılabilir.
Doğrulanabilirliği sağlamak: Tüm senaryoların parçaları 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 örneklemesinin yatay Reed-Solomon kodu ile dikey rastgele lineer kodun aynı alanda çalışması.
Birleştirilmiş Serileştirme Formatı
Ethereum'un serileştirme formatı şu anda yalnızca kısmen katılaşmıştır, çünkü veriler her türlü formatta yeniden serileştirilebilir ve yayınlanabilir. Tek istisna, işlem imzası hash'idir; bu, belirli bir formatta hash'lenmesi gerekir. Gelecekte, serileştirme formatının katılaşma derecesi aşağıdaki nedenlerden dolayı daha da artacaktır:
Tam Hesap Soyutlaması (EIP-7701): İşlemin tam içeriği sanal makineye görünür.
Daha yüksek Gas limiti: İşlem katmanı verileri veri bloklarına (blob'lar) yerleştirilmelidir.
O zaman, Ethereum'un üç katmanının serileştirme formatını birleştirme fırsatına sahip olacağız: yürütme katmanı, konsensüs katmanı, akıllı sözleşme çağrısı ABI.
SSZ kullanılmasını öneriyorum çünkü SSZ:
Kolay çözümleme: Akıllı sözleşme içinde dahil edilmiştir (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 derecede benzerlik: Araçların uyarlanması oldukça basit.
SSZ'ye tam geçiş için zaten çabalar var, gelecekteki güncellemeleri planlarken bu çabaları dikkate almalı ve sürdürmeliyiz.
Birleşik Ağaç Yapısı
EVM'den RISC-V'ye (veya diğer seçilebilir minimum sanal makineler) geçiş yapıldığında, onaltılık Merkle Patricia ağacı, blok yürütmesini kanıtlamanın en büyük darboğazı olacaktır, ortalama durumda bile. Daha iyi bir hash fonksiyonuna dayanan ikili ağaçlara geçiş, kanıtlayıcı verimliliğini önemli ölçüde artıracak ve hafif istemci gibi senaryoların veri maliyetlerini azaltacaktır.
Göç 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şilebilmesini ve çözümlenebilmesini sağlayacaktır.
Şu andan geleceğe
Basitlik, birçok açıdan merkeziyetsizlik ile benzerdir; her ikisi de dayanıklılık hedeflerinin üst akışıdır. Basitliğin belirgin bir şekilde önemsenmesi, belirli bir kültürel değişim gerektirir. Elde edilecek faydalar genellikle ölçülmesi zor olmakla birlikte, ek çaba ve bazı göz alıcı özelliklerden vazgeçmenin maliyeti hemen hissedilir. Ancak zamanla, faydalar giderek daha belirgin hale gelecektir — Bitcoin 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 kritik kodu Bitcoin'in sadeliğine daha yakın olsun. Ethereum'un tarihsel kural kodları var olmaya devam edecek, ancak bunlar konsensüs kritik yolunun dışında tutulmalı. Aynı zamanda, daha basit çözümleri seçme ilkesini benimsemeli, karmaşıklığı paketlemeyi sistematik karmaşıklık yerine öncelikli olarak tercih etmeli ve net özellikler ve garantiler sunan 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 Getiririz
Yazar | Vitalik Buterin
Derleme | GaryMa Wu, blok zincirini söyledi
Orijinal bağlantı:
Özet
Ethereum, küresel bir defter olmayı hedefliyor ve ölçeklenebilirlik ve esnekliğe ihtiyaç duyuyor. Bu makale, protokol basitliğinin önemine odaklanmakta ve konsensüs katmanını (3 yuvalı kesinlik, STARK toplama) ve yürütme katmanını (EVM'yi RISC-V veya benzeri sanal makinelerle değiştirerek) basitleştirerek karmaşıklığı, geliştirme maliyetlerini, hata riskini ve saldırı yüzeyini önemli ölçüde azaltmayı önermektedir. Zincir üstü EVM yorumlayıcıları gibi geriye dönük uyumluluk stratejilerine geçişin kolaylaştırılması ve daha fazla basitleştirme için silme kodlaması, serileştirme formatı (SSZ) ve ağaç yapısının birleştirilmesi önerilir. Amaç, Ethereum konsensüsünün anahtar kodunu Bitcoin'in basitliğine yaklaştırmak, esnekliği ve katılımı artırmak ve basitliğe ve maksimum sayıda kod satırı hedefine kültürel bir odaklanma gerektirmektir.
Ethereum'un hedefi, insanlık medeniyeti varlıklarını ve kayıtlarını depolayan bir küresel defter olmaktır; finans, yönetim, yüksek değerli veri doğrulama gibi alanlara hizmet etmektedir. Bu, iki alanda destek gerektirir: ölçeklenebilirlik ve dayanıklılık. Fusaka sert çatallama planı, L2 verilerinin kullanılabilir alanını 10 kat artıracakken, mevcut önerilen 2026 yol haritası da L1 katmanına benzer büyük bir artış getirmeyi planlamaktadır. Bu arada, Ethereum, hisse kanıtına (PoS) geçişini tamamladı ve istemci çeşitliliği hızla artmakta, sıfır bilgi (ZK) doğrulama, kuantum dayanıklılığı araştırmaları da istikrarlı bir şekilde ilerlemekte, uygulama ekosistemi giderek sağlamlaşmaktadır.
Bu makale, aynı derecede önemli ama genellikle göz ardı edilen bir dayanıklılık (ve hatta ölçeklenebilirlik) unsuru olan: protokolün basitliğine odaklanmayı amaçlamaktadır.
Bitcoin protokolünün en etkileyici yönü, zarif sadeliğidir:
Bloklardan oluşan bir zincir vardır, her blok bir önceki blok ile hash ile bağlanır.
Blokların geçerliliği, hash değerinin başındaki birkaç basamağın sıfır olup olmadığını kontrol eden iş kanıtı (PoW) ile doğrulanır.
Her blok, işlemler içerir; işlemler için harcanan coinler ya madencilik ödüllerinden ya da önceki işlem çıktılarından gelir.
Hepsi bu kadar! Hatta zeki bir lise öğrencisi bile Bitcoin protokolünün nasıl çalıştığını tam olarak anlayabilirken, bir programcı bunu hobi projesi olarak bir istemci yazabilir.
Protokolün basitliği, Bitcoin'in (ve Ethereum'un) güvenilir, tarafsız bir küresel temel katman olmasına birçok önemli avantaj getirmiştir:
Anlaşılması kolay: Protokolün karmaşıklığını azaltarak daha fazla kişinin protokol araştırmalarına, geliştirmelerine ve yönetimine katılmasını sağlamak, teknik elitlerin hakimiyet riskiyi azaltmak.
Geliştirme maliyetlerini düşürmek: Protokolü basitleştirmek, yeni altyapı (yeni istemci, kanıtlayıcı, geliştirici araçları vb.) oluşturma maliyetlerini önemli ölçüde azaltır.
Bakım yükünü azaltma: Uzun vadeli sözleşme bakım maliyetlerini düşürmek.
Hata riskini azaltma: Protokol standartları ve uygulamalarında felaket hatalarının meydana gelme olasılığını düşürmek ve bu tür hataların mevcut olmadığını doğrulamayı kolaylaştırmak.
Saldırı yüzeyini küçültmek: 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 geliştirme maliyetlerinin çok yüksek olmasına, güvenlik risklerinin artmasına ve Ar-Ge kültürünün kapalı olmasına yol açmıştır ve bu karmaşıklık arayışının getirileri 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ı inceleyecektir.
Basitleştirilmiş Konsensüs Katmanı
Yeni konsensüs katmanı tasarımı (tarihsel olarak "işaret zinciri" olarak adlandırılır), son on yılda konsensüs teorisi, ZK-SNARK geliştirme, staking ekonomisi gibi alanlardaki deneyimlerden yararlanarak, uzun vadede en iyi ve daha basit bir konsensüs katmanı inşa etmeyi amaçlamaktadır. Mevcut işaret zincirine kıyasla, yeni tasarım önemli ölçüde basitleştirilmiştir:
3-slot nihai tasarımı: slot, dönem, komite yeniden yapılandırması gibi kavramların ve ilgili verimli işleme mekanizmalarının (örneğin senkronizasyon komiteleri) kaldırılması. 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 optimaldir.
Aktif doğrulayıcı sayısını azaltmak: Daha basit çatal seçim kurallarının uygulanmasına izin vererek güvenliği artırmak.
STARK'a dayalı toplama protokolü: Herkes toplayıcı olabilir, toplayıcıya güvenmeye veya tekrar eden alanlar için yüksek maliyetler ödemeye gerek yoktur. Toplama kriptografisinin karmaşıklığı yüksektir, ancak bu karmaşıklık yüksek derecede paketlenmiştir, sistemik risk daha düşüktür.
P2P mimarisini basitleştirme: Yukarıda belirtilen faktörler, daha basit ve daha sağlam bir eşler arası ağ mimarisini destekleyebilir.
Doğrulayıcı mekanizmasının yeniden tasarımı: Katılım, çıkış, para çekme, anahtar dönüşümü, faaliyetsizlik sızıntısı gibi mekanizmaları içerir; kod satır sayısını basitleştirir ve daha net garantiler sağlar (örneğin, zayıf öznelite döngüsü).
Konsens katmanının avantajı, EVM yürütme katmanından görece bağımsız olmasıdır, bu nedenle sürekli iyileştirme için daha fazla alan vardır. Daha büyük zorluk ise yürütme katmanında benzer bir basitleştirmenin nasıl gerçekleştirileceğidir.
Basitleştirilmiş İcra Katmanı
EVM'nin karmaşıklığı giderek artıyor ve birçok karmaşıklığın gereksiz olduğu kanıtlandı (bir kısmı benim kişisel karar hatalarımdan kaynaklanıyor): 256 bit sanal makine, artık yavaş yavaş eskiye dönmeye başlayan belirli kriptografik formları aşırı optimize etti, önceden derlenmiş (precompiles) tek bir kullanım durumu için optimize edildi fakat nadiren kullanılıyor.
Bu sorunları tek tek çözmenin etkisi sınırlıdır. Örneğin, SELFDESTRUCT opcode'unu kaldırmak büyük çaba gerektirir, ancak yalnızca küçük faydalar sağlar. Son zamanlarda EOF (EVM Object Format) hakkında yapılan tartışmalar da benzer zorlukları göstermektedir.
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 kazanç elde etmek için daha iyi, daha basit bir sanal makineye geçiş yaparak 100 kat kazanç elde etmeyi tercih edelim. "Birleşme" (The Merge) gibi, yıkıcı değişikliklerin sayısını azaltıyoruz, ancak her değişikliğin daha anlamlı olmasını sağlıyoruz. Özellikle, EVM'nin RISC-V ile değiştirilmesini veya Ethereum ZK kanıtlayıcılarının kullandığı başka bir sanal makineyi öneriyorum. Bu, şunları getirecektir:
Verimlilikte büyük artış: Akıllı sözleşmelerin yürütülmesi (kanıtlayıcıda) yorumlayıcı giderleri olmadan doğrudan çalışır. Succinct'in verileri birçok senaryoda performansın 100 katından fazla artabileceğini gösteriyor.
Basitlikte büyük iyileştirme: RISC-V standardı EVM'ye göre son derece basit ve alternatifler (örneğin Cairo) de aynı şekilde sade.
EOF'u desteklemenin motivasyonu: kod bölümlendirme, daha dostça statik analiz, daha büyük kod boyutu sınırları vb.
Daha fazla geliştirici seçeneği: Solidity ve Vyper, yeni sanal makineye derlemek için arka uç ekleyebilir. RISC-V'yi seçerseniz, ana akım dil geliştiricileri de kodlarını bu sanal makineye kolayca taşıyabilir.
Çoğu önceden derlenmiş olanı kaldırın: Yüksek derecede optimize edilmiş eliptik eğri işlemlerini korumak mümkün olabilir (kuantum bilgisayarların yaygınlaşmasından sonra bunlar da kaybolacak).
Ana dezavantaj, hazır EOF ile karşılaştırıldığında, yeni sanal makinenin kazançlarının geliştiricilere ulaşmasının uzun zaman almasıdır. Bu sorunu hafifletmek için, kısa vadede yüksek değerli EVM iyileştirmeleri (örneğin, sözleşme kodu boyutu sınırını artırmak, DUP/SWAP17–32'yi desteklemek) 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 iyileştirmenin) 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ştirilmesi gereken bir şey var: Ethereum kod tabanı (tek bir istemci içinde bile) yalnızca bir tanım şekline sahip değildir.
Hedef, 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 hesaplamayı, kanıtlamayı, doğrulamayı, FOCIL (çatallama seçme kuralları) ve "normal" blok inşasını içerir.
Turuncu alan azaltılamaz: Eğer protokol standardı belirli bir yürütme katmanı işlevini (örneğin sanal makine, önceden derlenmiş gibi) kaldırır veya değiştirirse, geçmiş blokları işleyen istemcilerin ilgili kodu tutması gerekir. Ancak yeni istemciler, ZK-EVM veya biçimsel kanıtlayıcılar turuncu alanı tamamen göz ardı edebilir.
Yeni eklenen sarı alan: mevcut zinciri anlamak veya blok inşasını optimize etmek için çok değerlidir, ancak konsensüs mantığına ait değildir. Örneğin, Etherscan ve bazı blok inşacıları ERC-4337 kullanıcı işlemlerini destekler. Eğer bazı Ethereum işlevlerini (örneğin, EOA ve desteklediği eski işlem türleri) zincir üzerindeki RISC-V uygulamasıyla değiştirirsek, konsensüs kodu önemli ölçüde basitleşecektir, ancak özel düğümler hâlâ orijinal kodu çözümlemek için kullanmaya devam edebilir.
Turuncu ve sarı alanların karmaşıklığı, karmaşıklığı kapsama alanıdır; protokolü anlayan kişiler bu kısımları atlayabilir, Ethereum bunları göz ardı edebilir, bu alanlardaki hatalar konsensüs riski doğurmaz. Bu nedenle, turuncu ve sarı alanların kod karmaşıklığı, yeşil alanın karmaşıklığından çok daha az tehlikelidir.
Yeşil alandan sarı alana kod taşımak için izlenen yaklaşım, Apple'ın Rosetta çeviri katmanı aracılığıyla uzun vadeli geriye dönük uyumluluğu sağlamaya yönelik stratejisine benzer.
Ipsilon ekibinin son makalelerinden 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):
Yeni ön derlemenin zincir üzerindeki RISC-V uygulamasını sağlaması gerekmektedir: Ekosistemin RISC-V sanal makinesine aşamalı olarak uyum sağlaması.
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şebilir.
Çoğu önceden derlenmiş kodun değiştirilmesi: Eliptik eğri işlemleri ve KECCAK (aşırı hız gerektirdiği için) dışındaki diğer önceden derlenmiş kodlar RISC-V ile değiştirilmiştir. Hard fork ile önceden derlenmiş kod kaldırılmış ve bu adresin kodu (DAO fork'una benzer şekilde) boşluktan RISC-V uygulamasına değiştirilmiştir. RISC-V sanal makinesi son derece basittir, bu noktada durmak bile protokolü net bir şekilde basitleştirir.
RISC-V'de EVM yorumlayıcısını uygulamak: Akıllı sözleşmelerin zincire eklenmesi (ZK kanıtlayıcının gerekli olduğu nedeniyle). İlk birkaç yılın ardından, mevcut EVM sözleşmeleri bu yorumlayıcı aracılığıyla çalıştırılır.
adımın tamamlanmasının ardından birçok "EVM uygulaması" hâlâ blok inşasını, geliştirici araçlarını ve zincir analizini optimize etmek için kullanılacak, ancak artık temel konsensüs spesifikasyonlarının bir parçası olmayacak. Ethereum konsensüsü, "yerel olarak" yalnızca RISC-V'yi anlayacak.
Paylaşım protokol bileşenlerini basitleştirerek
Protokolün toplam karmaşıklığını azaltmanın üçüncü yolu (aynı zamanda en hafife alınan) mümkün olduğunca protokol yığını farklı bölümlerinde ortak standartların paylaşılmasıdır. Farklı protokoller, farklı senaryolarda aynı şeyleri yapmak için genellikle faydasızdır, ancak bu model yine de sıkça ortaya çıkmaktadır, esasen protokol yol haritasının farklı bölümleri arasında iletişim eksikliği nedeniyle. Aşağıda, bileşenleri paylaşarak Ethereum'u basitleştirmenin birkaç somut örneği bulunmaktadır.
Birleşik Silme Kodları
Üç senaryoda hata düzeltme koduna ihtiyacımız var:
Veri kullanılabilirliği örnekleme: İstemci, blokların yayımlandığını doğrular.
Daha hızlı P2P yayın: Düğüm, blokları kabul etmek için n/2 parça aldıktan sonra, gecikme ile fazlalık arasında bir denge kurar.
Dağıtık tarihsel depolama: Ethereum tarih verileri parça parça depolanır, her grup n/2 parça ile geri kalan parçalar kurtarılabilir, bu da tek bir parçanın kaybolma riskini azaltır.
Aynı hata düzeltme kodunun (Reed-Solomon, rastgele lineer kodlar vb. olsun) üç senaryoda kullanılması durumunda aşağıdaki avantajlar elde edilecektir:
Kod miktarını en aza indirin: Toplam kod satır sayısını azaltın.
Verimliliği artırma: Eğer bir düğüm belirli bir senaryo için bazı parçaları indiriyorsa, bu veriler diğer senaryolar için kullanılabilir.
Doğrulanabilirliği sağlamak: Tüm senaryoların parçaları 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 örneklemesinin yatay Reed-Solomon kodu ile dikey rastgele lineer kodun aynı alanda çalışması.
Birleştirilmiş Serileştirme Formatı
Ethereum'un serileştirme formatı şu anda yalnızca kısmen katılaşmıştır, çünkü veriler her türlü formatta yeniden serileştirilebilir ve yayınlanabilir. Tek istisna, işlem imzası hash'idir; bu, belirli bir formatta hash'lenmesi gerekir. Gelecekte, serileştirme formatının katılaşma derecesi aşağıdaki nedenlerden dolayı daha da artacaktır:
Tam Hesap Soyutlaması (EIP-7701): İşlemin tam içeriği sanal makineye görünür.
Daha yüksek Gas limiti: İşlem katmanı verileri veri bloklarına (blob'lar) yerleştirilmelidir.
O zaman, Ethereum'un üç katmanının serileştirme formatını birleştirme fırsatına sahip olacağız: yürütme katmanı, konsensüs katmanı, akıllı sözleşme çağrısı ABI.
SSZ kullanılmasını öneriyorum çünkü SSZ:
Kolay çözümleme: Akıllı sözleşme içinde dahil edilmiştir (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 derecede benzerlik: Araçların uyarlanması oldukça basit.
SSZ'ye tam geçiş için zaten çabalar var, gelecekteki güncellemeleri planlarken bu çabaları dikkate almalı ve sürdürmeliyiz.
Birleşik Ağaç Yapısı
EVM'den RISC-V'ye (veya diğer seçilebilir minimum sanal makineler) geçiş yapıldığında, onaltılık Merkle Patricia ağacı, blok yürütmesini kanıtlamanın en büyük darboğazı olacaktır, ortalama durumda bile. Daha iyi bir hash fonksiyonuna dayanan ikili ağaçlara geçiş, kanıtlayıcı verimliliğini önemli ölçüde artıracak ve hafif istemci gibi senaryoların veri maliyetlerini azaltacaktır.
Göç 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şilebilmesini ve çözümlenebilmesini sağlayacaktır.
Şu andan geleceğe
Basitlik, birçok açıdan merkeziyetsizlik ile benzerdir; her ikisi de dayanıklılık hedeflerinin üst akışıdır. Basitliğin belirgin bir şekilde önemsenmesi, belirli bir kültürel değişim gerektirir. Elde edilecek faydalar genellikle ölçülmesi zor olmakla birlikte, ek çaba ve bazı göz alıcı özelliklerden vazgeçmenin maliyeti hemen hissedilir. Ancak zamanla, faydalar giderek daha belirgin hale gelecektir — Bitcoin 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 kritik kodu Bitcoin'in sadeliğine daha yakın olsun. Ethereum'un tarihsel kural kodları var olmaya devam edecek, ancak bunlar konsensüs kritik yolunun dışında tutulmalı. Aynı zamanda, daha basit çözümleri seçme ilkesini benimsemeli, karmaşıklığı paketlemeyi sistematik karmaşıklık yerine öncelikli olarak tercih etmeli ve net özellikler ve garantiler sunan tasarım seçimleri yapmalıyız.