Orijinal başlık: Aşama 1 ve aşama 2'nin ne zaman mantıklı olduğu matematiği
Orijinal yazar: Vitalik Buterin
Orijinal çevirmen: Wenser, Odaily Planet Daily
Editörün notu: Ethereum toplama güvenliğinin üç aşaması hakkındaki tartışma her zaman Ethereum ekolojik topluluğunun odak noktası olmuştur. Bu durum sadece Ethereum ana ağının ve L2 ağının operasyonel istikrarıyla ilgili değil, aynı zamanda L2 ağının gerçek geliştirme durumuyla da ilgilidir. Ethereum topluluğunun bir üyesi olan Daniel Wang, yakın zamanda X platformunda L2 ağının 2. aşaması için #BattleTested isim etiketini önerdi. Sadece mevcut kodu ve yapılandırması Ethereum ana ağında 6 aydan uzun süredir çevrimiçi olan ve toplam kilitli değeri (TVL) 100 milyon ABD dolarından fazla ve en az 50 milyon ABD doları değerinde ETH ve büyük stablecoin'leri barındıran L2 ağlarının bu unvanı elde edebileceğine inanıyor. "Zincir üstü hayaletlerin" ortaya çıkmasını önlemek için başlık dinamik olarak değerlendirilir. Ethereum'un kurucu ortağı Vitalik, daha sonra soruya detaylı bir yanıt vererek görüşlerini Odaily Planet Daily tarafından derlendi:
Ethereum toplama güvenliğinin üç aşaması, güvenlik komitesinin güvensiz (yani saf kriptografik veya oyun teorisi) bileşenleri ne zaman kapsayabileceğine göre belirlenebilir:
· Aşama 0:Güvenlik komitesi tam kontrole sahiptir. Bir ispat sistemi mevcut olabilir (Optimizm veya ZK modu), ancak güvenlik komitesi bunu basit çoğunluk oyuyla bozabilir. Bu nedenle sertifikasyon sistemi yalnızca "danışmanlık niteliğindedir".
· Aşama 1:Güvenlik Komitesinin operasyonel sistemi kapsayabilmesi için %75 (en az 6/8) onayına ihtiyacı vardır. Birincil organizasyonun dışında bir yeter sayı engelleme alt kümesi (örneğin ≥ 3) bulunmalıdır. Dolayısıyla ispat sistemini kontrol etmenin zorluğu nispeten yüksektir, ancak aşılamaz değildir.
· Aşama 2:Güvenlik komitesi yalnızca kanıtlanabilir hata durumlarında harekete geçebilir. Örneğin, kanıtlanabilir bir hata, iki yedekli kanıt sisteminin (örneğin OP ve ZK) birbirini çeliştirmesi olabilir. İspatlanabilir bir hata varsa, önerilen cevaplardan yalnızca birini seçebilir: bir mekanizmaya keyfi olarak cevap veremez.
Güvenlik Komitesi'nin farklı aşamalarda sahip olduğu "oy paylarını" temsil etmek için aşağıdaki tabloyu kullanabiliriz:

Üç aşamada yönetim oylama yapısı
Önemli bir soru şudur: L2 ağının 0. aşamadan 1. aşamaya ve 1. aşamadan 2. aşamaya geçişi için en uygun zaman nedir?
Hemen 2. Aşamaya geçmemek için tek geçerli neden, kanıt sistemine tam olarak güvenememenizdir. Bu anlaşılabilir bir endişedir: Sistem büyük bir kod gövdesinden oluşur ve bu kodda bir güvenlik açığı varsa, bir saldırgan tüm kullanıcıların parasını çalabilir. Kanıt sistemine ne kadar çok güvenirseniz (veya tam tersi, güvenlik komitesine ne kadar az güvenirseniz), tüm ağ ekosistemini bir sonraki aşamaya o kadar çok taşımak istersiniz.
Aslında bunu basitleştirilmiş bir matematiksel model kullanarak niceliklendirebiliriz. Öncelikle varsayımları sıralayalım: · Güvenlik komitesinin her üyesinin “bireysel başarısızlık” olasılığı %10’dur; · Canlılık hatalarını (sözleşmeleri imzalamayı reddetme veya anahtarların bulunmaması) ve güvenlik hatalarını (yanlış bir şeyi imzalama veya anahtarların hacklenmesi) eşit derecede olası olarak değerlendiriyoruz. Uygulamada, yalnızca bir "başarısız" sınıf varsayıyoruz; burada "başarısız" bir Güvenlik Konseyi üyesi hem yanlış şeylere imza atmış hem de doğru şeylerde ilerlemeye onay vermemiştir; · 0. aşamada Güvenlik Konseyinin karar kriteri 4/7, 1. aşamada ise 6/8'dir; · Tek bir genel kanıt sisteminin varlığını varsayıyoruz (Güvenlik Konseyi'nin iki taraf arasında fikir ayrılığı olduğunda çıkmazı çözebileceği 2/3 tasarım mekanizmasının aksine). Dolayısıyla 2. aşamada bir güvenlik komitesinin varlığı artık söz konusu değildir.
Bu varsayımlar altında, doğrulama sisteminin çökme olasılığı göz önüne alındığında, L2 ağının çökme olasılığını en aza indirmek istiyoruz.
Bunu binom dağılımını kullanarak yapabiliriz:
· Güvenlik konseyi üyelerinin her birinin %10 bağımsız başarısızlık şansı varsa, o zaman 7 kişiden en az 4'ünün başarısız olma olasılığı ∑= 47( 7 )∗ 0,1 ∗ 0,97 −= 0,002728'dir. Bu nedenle, aşama 0'daki entegre sistemin sabit %0,2728'lik bir başarısızlık olasılığı vardır.
· Aşama 1 entegrasyonu, kanıt sistemi başarısız olursa ve güvenlik komitesi doğrulama mekanizması ≥ 3 kez başarısız olursa ve ağ hesaplama kapsamına ulaşamazsa (olasılık ∑= 38( 8 )∗ 0,1 ∗ 0,98 −= 0,03809179 kanıt sistemi arıza oranının katıdır) veya güvenlik komitesi 6 veya daha fazla kez başarısız olursa ve kendisini yanlış bir hesaplama yanıtı üretmeye zorlayabilirse (sabit olasılık ∑= 68( 8 )∗ 0,1 ∗ 0,98 −= 0,00002341) de başarısız olabilir;
· 2. Aşama birleştirme başarısızlığının olasılığı, kanıtlama sisteminin başarısız olma olasılığıyla tutarlıdır.
Aşağıda bir grafikte sunulmuştur:

L2 ağının farklı aşamalarında kanıt sisteminin arızalanma olasılığı
Yukarıda tahmin edildiği gibi, kanıt sisteminin kalitesi arttıkça, optimum aşama 0. aşamadan 1. aşamaya ve ardından 1. aşamadan 2. aşamaya kayar. 0. aşama kalitesinde bir kanıt sistemiyle bir 2. aşama ağı çalıştırmak en kötü olası sonuçtur.
Şimdi, yukarıdaki basitleştirilmiş modeldeki varsayımların mükemmel olmadığını unutmayın:
· Gerçekte, güvenlik komitesi üyeleri tamamen bağımsız değildir ve "ortak mod hataları" vardır: gizlice anlaşabilirler veya aynı zorlamaya veya bilgisayar korsanı saldırısına maruz kalabilirler, vb. Birincil organizasyonun dışında bir yeter sayı bloğu alt kümesinin gerekli kılınması bunu önlemek için tasarlanmıştır, ancak yine de mükemmel değildir.
· İspat sistemi, birden fazla bağımsız sistemden oluşabilir (bunu önceki blog yazılarımda savundum). Bu durumda, (i) sistemin çöktüğünün kanıtlanma olasılığı çok düşüktür ve (ii) güvenlik komitesi, anlaşmazlıkların çözümünde anahtar rol oynadığı için 2. Aşamada bile önemlidir.
Her iki argüman da 1. ve 2. Aşamaların grafikte gösterildiğinden daha cazip olduğunu ileri sürüyor.
Matematiğe inanıyorsanız, o zaman 1. Aşamanın varlığı neredeyse hiçbir zaman haklı gösterilemez: Doğrudan 1. Aşamaya geçmelisiniz. Duyduğum ana itiraz şu: Kritik bir hata meydana gelirse, bunu düzeltmek için 8 güvenlik komitesi üyesinden 6'sından hızlıca imza almak zor olabilir. Ancak basit bir çözüm var: Herhangi bir güvenlik komitesi üyesine, geri çekilmeleri 1-2 hafta erteleme yetkisi verin, böylece diğerlerine (düzeltici) eylemde bulunmaları için yeterli zaman tanıyın.
Ancak aynı zamanda, özellikle 2. Aşamaya geçiş çalışması, temeldeki kanıt sisteminin güçlendirilmesine yönelik çalışma pahasına yapılıyorsa, 2. Aşamaya çok erken geçmek bir hata olacaktır. İdeal olarak, L2Beat gibi veri sağlayıcıları sistem denetimlerinin ve olgunluk ölçümlerinin kanıtını (tüm toplu ölçümler yerine sistem uygulamalarının kanıtını, böylece bunları yeniden kullanabiliriz) eşlik eden gösteri aşamalarıyla birlikte sunmalıdır.
BlockBeats Resmi Topluluğuna Katılın:
Telegram Abonelik Grubu: https://t.me/theblockbeats
Telegram Sohbet Grubu: https://t.me/BlockBeats_App
Twitter Resmi Hesabı: https://twitter.com/BlockBeatsAsia