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

Orijinal yazar: Vitalik Buterin

Orijinal çeviri: GaryMa, Wu Blockchain Diyor

Özet

Ethereum, ölçeklenebilirlik ve dayanıklılık gerektiren küresel bir muhasebe defteri olmayı hedefliyor. Bu makale protokol basitliğinin önemine odaklanıyor ve fikir birliği katmanını (3 yuvalı kesinlik, STARK toplama) ve yürütme katmanını (EVM'yi RISC-V veya benzeri sanal makinelerle değiştirme) basitleştirerek karmaşıklığı, geliştirme maliyetlerini, hata risklerini ve saldırı yüzeylerini önemli ölçüde azaltmayı öneriyor. Geçişin geriye dönük uyumlu stratejiler (zincir üstü EVM yorumlayıcısı gibi) aracılığıyla yumuşatılması ve daha fazla basitleştirme için silme kodlarının, serileştirme biçimlerinin (SSZ) ve ağaç yapılarının birleştirilmesi önerilir. Amaç, Ethereum'un fikir birliği açısından kritik kodunu Bitcoin'in sadeliğine yakın hale getirmek, dayanıklılığı ve katılımı artırmak ve sadeliğe değer veren ve maksimum kod satırı hedefi koyan bir kültüre ihtiyaç duymaktır.

Ethereum'un hedefi küresel bir muhasebe defteri haline gelmektir: İnsan medeniyetinin varlıklarını ve kayıtlarını depolamak için bir platform, finans, yönetim ve yüksek değerli veri doğrulama alanlarına hizmet eder. Bunun için iki açıdan desteğe ihtiyaç var: Ölçeklenebilirlik ve dayanıklılık. Fusaka hard fork'unun L2 verileri için kullanılabilir alanı 10 kat artırması planlanırken, şu anda önerilen 2026 yol haritasının L1 katmanına da benzer şekilde büyük artışlar getirmesi bekleniyor. Aynı zamanda Ethereum, Proof of Stake'e (PoS) geçişini tamamladı, müşteri çeşitliliği hızla arttı, sıfır bilgi (ZK) doğrulaması ve kuantum direnç araştırmaları da istikrarlı bir şekilde ilerliyor ve uygulama ekosistemi giderek daha sağlam hale geliyor.

Bu makale, dayanıklılık (ve hatta ölçeklenebilirlik) açısından eşit derecede önemli ancak sıklıkla hafife alınan bir faktöre odaklanmayı amaçlamaktadır: Protokol basitliği.

Bitcoin protokolünün en şaşırtıcı yanı zarif sadeliğidir:

1. Bloklardan oluşan bir zincir vardır, her blok bir önceki bloğa bir hash aracılığıyla bağlanır.

2. Bloğun geçerliliği, karma değerinin ilk birkaç basamağının sıfır olup olmadığını kontrol eden İş Kanıtı (PoW) ile doğrulanır.

3. Her blokta işlemler yer alır ve işlemlerde harcanan coin'ler ya madencilik ödüllerinden ya da önceki işlem çıktılarından gelir.

Hepsi bu kadar! Bitcoin protokolünün nasıl çalıştığını zeki bir lise öğrencisi bile tam olarak anlayabilir ve bir programcı yan proje olarak bir istemci bile yazabilir. Protokolün basitliği, Bitcoin'e (ve Ethereum'a) güvenilir, tarafsız ve küresel bir temel katman olarak bir dizi önemli avantaj sağlıyor:

1. Anlaşılması kolay: Protokolün karmaşıklığını azaltın, daha fazla kişinin protokol araştırmasına, geliştirilmesine ve yönetimine katılmasını sağlayın ve teknik elit tarafından yönetilme riskini azaltın.

2. Geliştirme maliyetlerini azaltın: Protokolün basitleştirilmesi, yeni altyapı (yeni istemciler, kanıtlayıcılar, geliştirici araçları vb.) oluşturmanın maliyetini büyük ölçüde azaltır.

3. Bakım yükünü azaltın: Uzun vadeli anlaşma bakımının maliyetini azaltın.

4. Hata riskini azaltın:Protokol spesifikasyonlarında ve uygulamalarında felaket düzeyinde hatalar oluşma olasılığını azaltın ve bu tür hataların olmadığının doğrulanmasını kolaylaştırın.

5. Saldırı yüzeyini azaltın:Protokolün karmaşık bileşenlerini azaltın ve özel çıkar grupları tarafından saldırıya uğrama riskini azaltın.

Tarihsel olarak, Ethereum (ve bazen de kişisel kararlarım nedeniyle) işleri basit tutmada sıklıkla başarısız oldu; bu da aşırı geliştirme maliyetlerine, artan güvenlik risklerine ve bu karmaşıklıkların peşinden gitmekten elde edilen kazanımların çoğu zaman yanıltıcı olduğu kanıtlanan kapalı bir Ar-Ge kültürüne yol açtı. Bu makalede, Ethereum'un beş yıl sonra Bitcoin'in sadeliğine nasıl yaklaşacağı incelenecektir.

Basitleştirilmiş Mutabakat Katmanı

Yeni mutabakat katmanı tasarımı (tarihsel olarak "işaret zinciri" olarak adlandırılır), uzun vadeli optimum ve daha basit bir mutabakat katmanı oluşturmak için mutabakat teorisi, ZK-SNARK geliştirme, stake ekonomisi ve diğer alanlardaki son on yıllık deneyimden yararlanmayı amaçlamaktadır. Mevcut işaret zinciriyle karşılaştırıldığında, yeni tasarım önemli ölçüde basitleştirilmiştir:

1. 3 yuvalı kesinlik tasarımı: Yuvalar, dönemler, komite yeniden organizasyonu ve ilgili verimli işleme mekanizmaları (senkronizasyon komiteleri gibi) gibi kavramları kaldırın. 3-slotlu kesinliğin temel bir uygulaması yalnızca 200 satır kod alır ve Gasper'a kıyasla neredeyse optimum güvenliğe sahiptir.

2. Etkin doğrulayıcıların sayısını azaltın: Daha basit çatal seçimi kuralı uygulamalarına olanak tanır ve güvenliği artırır.

3. STARK tabanlı toplama protokolü: Herkes toplayıcıya güvenmek veya yinelenen bit alanları için yüksek ücretler ödemek zorunda kalmadan toplayıcı olabilir. Toplu kriptografi daha karmaşıktır, ancak karmaşıklığı oldukça kapsüllenmiştir ve sistemsel risk daha düşüktür.

4. P2P mimarisini basitleştirin: Yukarıdaki faktörler daha basit ve daha sağlam bir eşler arası ağ mimarisini destekleyebilir.

5. Doğrulayıcı mekanizmayı yeniden tasarlayın: Giriş, çıkış, çekme, anahtar dönüşümü, hareketsizlik sızıntısı ve diğer mekanizmaları dahil ederek, kod satırı sayısını basitleştirin ve daha net garantiler (zayıf öznellik döngüsü gibi) sağlayın.

Uzlaşma katmanının avantajı, EVM yürütme katmanından nispeten bağımsız olmasıdır, bu nedenle sürekli iyileştirme için çok fazla alan vardır. Daha büyük zorluk, benzer bir basitleştirmeyi uygulama düzeyinde başarmaktır.

Yürütme Katmanının Basitleştirilmesi

EVM karmaşıklık açısından büyüdü ve bu karmaşıklığın büyük bir kısmının gereksiz olduğu kanıtlandı (kısmen benim kendi kötü kararlarım yüzünden): 256 bitlik VM, artık giderek daha az kullanılan belirli bir kriptografi biçimi için aşırı optimize edilmişti ve ön derlemeler tek bir kullanım durumu için optimize edilmişti ancak nadiren kullanılıyordu.

Bu sorunları tek tek çözmenin etkisi sınırlı olacaktır. Örneğin, SELFDESTRUCT opcode'unu kaldırmak çok büyük bir çabaydı ama çok az fayda sağladı. Son zamanlarda EOF (EVM Nesne Biçimi) üzerine yapılan tartışmalar da benzer zorlukları göstermektedir.

Yakın zamanda daha radikal bir çözüm önerdim: EVM'de orta büyüklükte (ama yine de yıkıcı) değişiklikler yaparak 1,5 katlık bir fayda elde etmek yerine, daha iyi ve daha basit bir VM'ye geçiş yapabilir ve 100 katlık bir fayda elde edebiliriz. The Merge'e benzer şekilde, yıkıcı değişikliklerin sayısını azaltıyoruz ancak her değişikliği daha anlamlı hale getiriyoruz. Özellikle EVM'yi RISC-V veya Ethereum ZK prover'ı tarafından kullanılan başka bir sanal makine ile değiştirmeyi öneriyorum. Bu şunları sağlayacaktır:

1. Önemli verimlilik artışı: Akıllı sözleşme yürütme (kanıtlayıcıda) yorumlayıcı yükü gerektirmez ve doğrudan çalışır. Succinct'in verileri, performansın birçok senaryoda 100 kattan fazla iyileştirilebileceğini gösteriyor.

2. Önemli ölçüde iyileştirilmiş basitlik: RISC-V spesifikasyonu, EVM ile karşılaştırıldığında son derece basittir ve Cairo gibi alternatifler de aynı derecede basittir.

3. EOF'u desteklemenin motivasyonları:Kod bölümlendirme, daha kullanıcı dostu statik analiz, daha büyük kod boyutu sınırı vb.

4. Daha fazla geliştirici seçeneği:Solidity ve Vyper, yeni sanal makinelere derleme yapmak için arka uçlar ekleyebilir. RISC-V'yi seçerseniz, ana akım dil geliştiricileri de kodlarını bu sanal makineye kolayca taşıyabilirler.

5. Ön derlemelerin çoğunu kaldırın: Muhtemelen yalnızca yüksek oranda optimize edilmiş eliptik eğri işlemleri korunacaktır (kuantum bilgisayarlar popüler hale geldikten sonra bunlar bile ortadan kalkacaktır).

Başlıca dezavantajı, kullanıma hazır EOF'un aksine, yeni bir VM'nin avantajlarının geliştiricilere yansımasının daha uzun sürmesidir. Kısa vadede yüksek değerli EVM iyileştirmeleri uygulayarak (sözleşme kod boyutu sınırlarını artırmak ve DUP/SWAP17–32'yi desteklemek gibi) bu sorunu hafifletebiliriz.

Bu daha basit bir sanal makine ile sonuçlanacaktır. Temel zorluk şu: Mevcut EVM ile nasıl başa çıkılır?

Sanal makine geçişi için geriye dönük uyumluluk stratejisi

EVM'yi basitleştirmedeki (veya karmaşıklığı artırmadan iyileştirmedeki) en büyük zorluk, hedef uygulamanın mevcut uygulamaların geriye dönük uyumluluğu ile nasıl dengeleneceğidir.

· Öncelikle Ethereum kod tabanını tanımlamanın tek bir yolu olmadığının (tek bir istemci içinde bile) açıklığa kavuşturulması gerekir.

· Amaç, Ethereum konsensüsüne katılmak için düğümlerin ihtiyaç duyduğu mantık olan yeşil alanı en aza indirmektir; buna mevcut durum hesaplaması, kanıt, doğrulama, FOCIL (çatal seçim kuralı) ve "normal" blok inşası dahildir.

· Turuncu alan azaltılamaz: Protokol belirtimi bir yürütme katmanı işlevini (sanal makine, ön derleme vb. gibi) kaldırır veya değiştirirse, geçmiş blokları işleyen istemci yine de ilgili kodu korumak zorundadır. Ancak yeni müşteriler, ZK-EVM veya resmi kanıtlayıcılar turuncu alanı tamamen göz ardı edebilirler.

· Yeni eklenen sarı alan: Mevcut zinciri anlamak veya blok yapısını optimize etmek için çok değerlidir, ancak fikir birliği mantığına ait değildir. Örneğin Etherscan ve bazı blok oluşturucuları ERC-4337 kullanıcı işlemlerini destekler. Ethereum'un bazı işlevlerini (EOA ve desteklediği eski işlem türleri gibi) zincir üstü RISC-V uygulamalarıyla değiştirirsek, fikir birliği kodu önemli ölçüde basitleştirilecek, ancak özel düğümler ayrıştırma için orijinal kodu kullanmaya devam edebilir.

· Turuncu ve sarı alanlardaki karmaşıklık kapsülleme karmaşıklığıdır. Protokolü anlayan kişiler bu kısımları atlayabilir ve Ethereum uygulamaları bunları görmezden gelebilir. Bu alanlarda yapılacak hatalar konsensüs risklerine yol açmayacaktır. Bu nedenle turuncu ve sarı alanlardaki kod karmaşıklığı, yeşil alandaki karmaşıklığa göre çok daha az zararlıdır.

Kodları yeşil alandan sarı alana taşıma fikri, Apple'ın Rosetta çeviri katmanı aracılığıyla uzun vadeli geriye dönük uyumluluğu sağlama stratejisine benziyor. Ipsilon ekibinin yakın zamanda yayınladığı makaleden esinlenerek, aşağıdaki VM değiştirme sürecini öneriyorum (örnek olarak EVM'den RISC-V'ye geçişi kullanıyorum, ancak bu süreç EVM'den Cairo'ya veya RISC-V'den daha iyi bir VM'ye geçiş için de kullanılabilir):

1. Zincir üstü RISC-V uygulaması sağlamak için yeni ön derleme gerektirin: Ekosistemin RISC-V sanal makinesine kademeli olarak uyum sağlamasına izin verin.

2. RISC-V'yi geliştirici seçeneği olarak tanıtıyoruz:Protokol hem RISC-V'yi hem de EVM'yi destekliyor ve iki sanal makinenin sözleşmeleri serbestçe etkileşime girebiliyor.

3. Çoğu ön derlemeyi değiştir:Eliptik eğri işlemleri ve KECCAK (aşırı hız ihtiyacı nedeniyle) hariç, diğer ön derlemeler RISC-V uygulamalarıyla değiştirilir. Ön derleme, sert bir çatallanma yoluyla kaldırıldı ve o adresteki kod (DAO çatallanmasına benzer şekilde) hiçbir şeyden RISC-V uygulamasına değiştirildi. RISC-V sanal makinesi son derece basittir ve burada durmak bile protokolü basitleştirecektir.

4. EVM yorumlayıcısını RISC-V'de uygulayın:Akıllı sözleşme olarak zincir üzerinde (ZK kanıtlayıcı gereksinimi nedeniyle zaten yapıldı). İlk sürümden birkaç yıl sonra, mevcut EVM sözleşmeleri bu yorumlayıcı aracılığıyla çalıştırılıyor.

4. adım tamamlandıktan sonra, birçok "EVM uygulaması" blok oluşturmayı, geliştirici araçlarını ve zincir analizini optimize etmek için kullanılmaya devam edecek, ancak artık temel fikir birliği spesifikasyonunun bir parçası olmayacak. Ethereum konsensüsü "doğal olarak" yalnızca RISC-V'yi anlayacaktır.

Paylaşılan protokol bileşenleriyle basitleştirme

Protokolün genel karmaşıklığını azaltmanın üçüncü yolu (ve en az önemsenen yol), protokol yığınının farklı bölümlerinde mümkün olduğunca birleşik standartları paylaşmaktır. Farklı bağlamlarda aynı şeyi yapan farklı protokollerin olması genellikle yardımcı olmaz, ancak bu model yine de sıklıkla ortaya çıkar; çoğunlukla protokol yol haritasının farklı bölümleri arasındaki iletişim eksikliğinden kaynaklanır. Ethereum'u paylaşımlı bileşenler aracılığıyla basitleştirmeye yönelik birkaç somut örnek şöyle:

Birleşik Silme Kodu

Üç senaryoda silme kodlarına ihtiyacımız var:

1. Veri kullanılabilirliği örneklemesi: İstemci bloğun yayınlandığını doğrular.

2. Daha hızlı P2P yayını: Bir düğüm, n/2 parçayı aldıktan sonra bir bloğu kabul edebilir ve böylece gecikme ile yedeklilik arasında bir denge elde edebilir.

3. Dağıtılmış tarihsel depolama: Ethereum tarihsel verileri parçalar halinde saklanır ve n/2 parçadan oluşan her grup kalan parçaları geri yükleyebilir ve tek bir parçayı kaybetme riskini azaltabilir.

Üç senaryoda da aynı silme kodunun (Reed-Solomon, rastgele doğrusal kod vb.) kullanılması durumunda aşağıdaki avantajlar elde edilecektir:

1. Kod miktarını en aza indirin:Toplam kod satırı sayısını azaltın.

2. Verimliliği artırın:Bir düğüm bir sahne için kısmi bir parçayı indirirse, bu veriler diğer sahneler için kullanılabilir.

3. Doğrulanabilirliği Sağlayın:Tüm sahne bölümleri köke göre doğrulanabilir.

Farklı silme kodları kullanılıyorsa en azından uyumluluk sağlanmalıdır; örneğin, veri kullanılabilirliği örneklemesi için yatay Reed-Solomon kodu ve dikey rastgele doğrusal kod aynı alanda çalışır.

Birleşik serileştirme biçimi

Ethereum'un serileştirme biçimi şu anda yalnızca kısmen sağlamlaştırılmış durumda, çünkü veriler herhangi bir biçimde yeniden serileştirilebilir ve yayınlanabilir. Bunun tek istisnası, standart bir formatta karma haline getirilmesi gereken işlem imzası karmasıdır. Gelecekte, serileştirme formatının sağlamlaştırılması aşağıdaki nedenlerden dolayı daha da iyileştirilecektir: 1. Tam hesap soyutlaması (EIP-7701): İşlemin tam içeriği sanal makine tarafından görülebilir.

2. Daha Yüksek Gas sınırı:Yürütme katmanı verilerinin veri bloklarına (blob'lara) yerleştirilmesi gerekir.

O zamana kadar, Ethereum'un üç seviyesinin serileştirme formatlarını birleştirme fırsatına sahip olacağız: yürütme katmanı, fikir birliği katmanı ve akıllı sözleşme çağrısı ABI.

SSZ'yi kullanmayı öneriyorum çünkü SSZ:

1. Kolay çözülür: Akıllı sözleşmelere dahildir (4 bayt tabanlı tasarımı ve daha az uç durum nedeniyle).

2. Konsensüs katmanında yaygın olarak kullanılmaktadır.

3. Mevcut ABI'ye oldukça benzer: Araç uyarlaması nispeten basittir.

SSZ'ye tam geçiş için çabalar var ve gelecekteki yükseltmeleri planlarken bu çabaları dikkate almalı ve sürdürmeliyiz.

Birleşik Ağaç Yapısı

EVM'den RISC-V'ye (veya diğer isteğe bağlı minimal sanal makineye) geçiş yapılıyorsa, onaltılık Merkle Patricia ağacı, ortalama durumda bile, kanıt bloğu yürütme için en büyük darboğaz haline gelecektir. Daha iyi bir karma işlevine dayalı ikili bir ağaca geçiş yapmak, hafif istemciler gibi senaryolarda veri maliyetlerini azaltırken kanıtlayıcı verimliliğini önemli ölçüde artıracaktır. Göç ederken konsensüs katmanının aynı ağaç yapısını kullandığından emin olmalısınız. Bu, Ethereum'un fikir birliği katmanının ve yürütme katmanının aynı kod aracılığıyla erişilebilir ve ayrıştırılabilir olmasını sağlayacaktır.

Şimdiden Geleceğe

Basitlik birçok yönden merkeziyetsizliğe benzer ve her ikisi de dayanıklılık hedefinin öncüsüdür. Sadeliğe açıkça değer vermek belli bir kültürel değişimi gerektirir. Faydalarını ölçmek çoğu zaman zorken, ekstra çaba göstermenin ve bazı harika özelliklerden vazgeçmenin maliyeti anında ortaya çıkıyor. Ancak zamanla faydaları giderek daha önemli hale geliyor; Bitcoin'in kendisi bunun mükemmel bir örneği.

Tinygrad'ın yolunu takip etmeyi ve Ethereum'un uzun vadeli spesifikasyonları için açık bir maksimum kod satırı hedefi belirlemeyi, böylece Ethereum'un fikir birliğine dayalı kritik kodunu Bitcoin'in sadeliğine yakınlaştırmayı öneriyorum. Ethereum'un tarihsel kurallarını işleyen kod var olmaya devam edecek ancak fikir birliği kritik yolunun dışına yerleştirilmelidir. Aynı zamanda daha basit çözümü seçme felsefesini savunmalı, sistemik karmaşıklıktan ziyade kapsülleme karmaşıklığına öncelik vermeli ve net özellikler ve garantiler sağlayan tasarım seçimleri yapmalıyız.

Orijinal bağlantı