Bu makaleyi inceledikleri için Jon Charbonneau ve Conor McMenamin'e özellikle teşekkür ederiz.

Bu noktada toplamaların değil, doğrulama kurallarının güvenliğinin olduğunu hepimiz bilmeliyiz. Toplamaların "Ethereum güvenliğini" devraldığını veya "güveni en aza indirildiğini" söylediğimizde aslında demek istediğimiz, toplamalarda Ethereum onay kurallarıyla hemen hemen aynı güvenliğe sahip onay kurallarını kullanmanın mümkün olduğudur. Ancak blok kaşifleri çoğunlukla hangi onay kuralına atıfta bulunduklarına veya hangi güvenlik özelliklerini sağladıklarına ilişkin ayrıntılara girmeden yeşil bir rozet göstermeyi önemserler.

L2BEAT olarak bu sorunu çözmek ve bunu herkes için erişilebilir kılmak istiyoruz. Özellikle, çifte harcama saldırılarına karşı en güçlü doğrulama kuralı olan kesinliğe odaklanmak istiyoruz.

Onay kuralları: tutarlılık ve kullanılabilirlik

Onay kuralları, belirli varsayımlar altında bir bloğun ne zaman onaylandığını ve yeniden düzenlenmesinin olası olmadığını belirten algoritmalardır. Bir blok onaylandıktan sonra işlemleriyle ilgili işlemler yapılabilir. Örneğin bu, bir müşteriye kahve teslim etmeyi veya alıcıya bir araba teslim etmeyi içerebilir.

Farklı onay kuralları kullanıcılara farklı güvenlik garantileri verir. Bir doğrulama kuralının güvenliği tutarlılık ve kullanılabilirlikten oluşur ve büyük ölçüde temel konsensüs algoritmalarına bağlıdır:

• Tutarlılık (güvenlik): herhangi iki düğümün görünümü ağ bölümleri altında tutarlıdır.
• Kullanılabilirlik (canlılık): Düğümlerin önemli bir kısmı protokole katılmayı bıraktıktan sonra bile işlemler belirli bir süre içinde deftere dahil edilmeye devam eder.

CAP Teoremi bize, hem ağ bölümleri altında tutarlı kalan hem de dinamik katılım altında kullanılabilen bir fikir birliği algoritması tasarlamanın mümkün olmadığını söylüyor: ciddi bir ağ bölümü meydana gelirse, düğümler ya blok üretmeye devam etmeye ve tutarlılığı kaybetmeye karar verebilir ya da durup durabilir. kullanılabilirliği kaybedersiniz. Düğümlerin diğerlerinin yalnızca çevrimdışı (dinamik katılım) veya aktif ancak erişilemez (ağ bölümleri) olmalarını birbirinden ayırmasının bir yolu yoktur ve bu nedenle farklı davranmak mümkün değildir.

Eve, Bob'un çevrimdışı mı yoksa farklı bir ağ bölümünde mi olduğunu bilemez.

Nakamoto benzeri bir konsensüs kullanan Bitcoin gibi blok zincirleri canlılığı tercih eder; bu, bir ağ bölünmesi sırasında her iki tarafın da blok üretmeye devam edeceği ve bölüm çözülürse sonunda yeniden düzenleyeceği anlamına gelirken, diğerleri PBFT benzeri bir yöntem kullanan Cosmos zincirlerini sever. fikir birliği , tutarlılığı korumak için ağ bölümleri altında durun.

Ethereum'da onay kuralları

Ethereum, LMD GHOST algoritmasını kullanarak ağ bölümleri altında kullanılabilirliğe öncelik verir. Bu yaklaşım, dürüst düğümlerin zincirin ucunda farklı görüşlere sahip olabileceği ve aynı yükseklik için farklı blokları onaylayabileceği ve potansiyel olarak yeniden organizasyonlara yol açabileceği anlamına gelir.

Uygun ağ koşulları altında Ethereum, Casper FFG protokolünü kullanarak kesinlik yoluyla tutarlılık garantileri sağlamayı da amaçlamaktadır. Kesinlik, mümkün olan en güçlü doğrulama kuralıdır; düğümler, sonlandırılmış blokları hiçbir zaman yeniden düzenlemeyecek sabit kodlu bir kurala sahiptir.

Kesinleşmiş defter (yeşil) her zaman canlı defterin (mavi) ön ekidir.

İki çakışan blok sonlandırılırsa kesinlik garantileri tehlikeye girer; bu, doğrulayıcıların 1/3'ünden fazlasının kötü niyetli davranması durumunda meydana gelebilecek bir olaydır. Ancak Ethereum'da bu tür eylemler, hisselerini kaybetme gibi önemli bir cezayı da beraberinde getiriyor.

Kullanıcılar, en güvenli doğrulama kuralı olarak Casper FFG'yi kullanmayı ya da LMD GHOST'a güvenerek daha canlı olmayı seçebilirler. LMD GHOST için doğrulama kuralları, Bitcoin'deki k-doğrulama kuralına benzer şekilde, Güvenli Blok onay kuralında belirtildiği gibi işlemin deftere dahil edilip edilmediğine bakmaktan daha karmaşık olabilir.

Toplamalara ilişkin onay kuralları

Toplamalar prensipte Ethereum'da bulunan onay kurallarının aynısını kullanabilir. Bir işlemi toplu olarak gönderirseniz ve daha sonra aynı işlemin L1'de kesinleşmiş bir blokta yayınlandığını görürseniz, L2 işlemini de nihai olarak düşünmek isteyebilirsiniz. Hikayenin bundan çok daha karmaşık olduğu ortaya çıktı.

İşlem verileri özetleri

Ethereum'da bloklar, blok başlığında hem işlemlerin listesini hem de önerilen durum kökünü içerir. İşlemlerin yürütülmesi kökün temsil ettiği duruma yol açmıyorsa, daha sonra diğer bloklara farklı bir sırayla eklenebilecek işlemler de dahil olmak üzere tüm blok atılır.

Toplamalarda, veri yayınlama eylemleri ve kökler birbirinden ayrıldığından, karşılık gelen durum köklerinin geçerliliğine bağlı olarak işlemlerin atılmasına gerek yoktur. Bu ayrım göz önüne alındığında, iyimser toplamalardaki 7 günlük sorgulama süresi gibi ek gecikmeleri atlayarak, durum kök kesinleştirmesini beklemeden işlemlerin sonuçlandırılıp sonlandırılmadığını kontrol etmek yeterlidir.

Durum farklarının toplanması

Durum farkları, durum geçiş fonksiyonunun çıktılarıdır ve bunların gerçekten geçerli olduğunu doğrulamak için ZK kanıtını beklemek gerekir. ZK kanıtının oluşturulması zaman alır ve buna ek olarak, kanıt oluşturma ve doğrulama maliyetlerini daha iyi amorti etmek için tek bir kanıta daha fazla işlemi dahil etmek amacıyla daha fazla gecikme yapma teşviki vardır.

Kanıt toplama teknikleri, onay süreleri ile maliyet amortismanı arasındaki bu ödünleşime bir çözüm sunar: Bir toplama minimum düzeyde etkinlik yaşasa bile, aynı kanıtta daha aktif toplamalardan gelen işlemleri dahil ederek amortismandan faydalanabilir. Bu yaklaşımın bir örneği, şu anda Starknet, Paradex ve StarkEx'in dYdX ve hatta Validium'lar gibi derlemelerinden kanıtları toplayan Starkware'in SHARP'ıdır .

İşlerin karmaşıklaştığı yer

Toplama türetme spesifikasyonu

Bir toplama temel alınmazsa, toplu işlerin türetme sırası, bunları L1'de farklı bir sırada yayınlayabilecek olan toplama sıralayıcı tarafından tanımlanabilir.

Bir örnek vermek gerekirse, OP Yığın zincirleri L1'de önceki grubun karmaları kullanılarak bağlanan gruplar yayınlar. Bu grupların kronolojik sırayla yayınlanmasına gerek yoktur, bu da düğümlerin potansiyel olarak eksik işlemleri beklediği 12 saatlik bir sıralama penceresine yol açar. İşlemler yalnızca L1'de yayınlandıkları için dahil edilmiş sayılmamalıdır: Bir parti henüz kanonik parti zincirine bağlanmamışsa, farklı bir sıralamaya veya işlem kümesine sahip alternatif bir çatalın oluşturulma riski vardır.

OP Stack zincirlerinde blok süresi 2 saniyedir ve her Ethereum bloğunda 6 blok oluşur. Ethereum blokları arasındaki 6 bloktan oluşan bu gruplandırmaya "dönem" adı verilir. L1 aracılığıyla gönderilen L1'den L2'ye mesajlar, verilen L1 bloğu için karşılık gelen çağın ilk bloğunun ilk kısmına dahil edilir. Bu işlemler, sıralama penceresinin geçmesini beklemeden onaylanmış olarak değerlendirilebilirken, türetme sonrasında L2 defterindeki sıralamaları bilindiği için, önceki bir partinin eksik olması durumunda düğümlerin bu mesajları içeren blokları hesaplamaya başlamayacağını not etmek önemlidir. Bunun nedeni, durumun tam dizi olmadan hesaplanamaması ve bu nedenle durum köklerinin de L1'de yayınlanmayacağıdır.

Bunun sonucu olarak yalnızca zincir üzerindeki verilerin incelenmesi, L1 onay sürelerini takip etmek için yeterli değildir. Toplama düğümü yazılımının kendisini inceleyerek L2 bloklarının L1 verilerinden nasıl türetildiğini anlamak da gereklidir.

İzin verilen işlevler

Scroll, işlem verilerini yayınlayan bir ZK toplamasıdır; bu, prensipte kişinin işlemlerinin nihai olduğunu düşünmek için ZK kanıtını beklemesine gerek olmadığı anlamına gelir. Henüz kanıtlanmamış partileri silmek için bir işlev uygulamamış olsalardı bu doğru olurdu.

https://etherscan.io/address/0x2e07f0fba71709bb5e1f045b02152e45b451d75f#code#F1#L260

Aynı durum durum farklarını yayınlayan toplamalar için de geçerli olabilir: zkSync Era ve zkSync Lite'ın durum farklarını göndermek için üç adımlı bir süreci vardır: ilk önce verileri herhangi bir kanıt olmadan işleme koyarlar, ardından onlar için bir kanıt sağlarlar ve ardından 24 saatlik bir gecikmeden sonra , kök, para çekme işlemlerini gerçekleştirmek için yürütülmeye hazır hale gelir. Teorik olarak, bir kanıt sağlandığında işlemlerin sırası sabittir, dolayısıyla yürütme gecikmesinin geçmesini beklemek gerekmez. Ancak zkSync bu blokları geri döndürebilir:

https://etherscan.io/address/0x7Ed066718Dfb1b2B04D94780Eca92b67ECF3330b#code#F10#L425

zkSync Era'da hiçbir blok geri döndürülmezken, zkSync Lite'ta bu 8 kez gerçekleşti.

Kesinlik gözlemlenebilirliği

Toplu kayıt durumu farkları işlem verilerini göndermediğinden, bir işlemin gerçekten dahil edildiğini nasıl takip edebiliriz? Evet, hesap nonce'leri gibi etkileri takip edebiliriz, ancak genel durum karmaşıklaşıyor. Bir ay önce şu soruyu sordum:

Gelen yanıtlardan bazılarına göz atalım:

Bu, sıralayıcının size yanıt vermeye istekli olması ve ona güvenmeniz durumunda işe yarayan bir çözümdür. Ya olmazsa? Ya öyle olsa ama ona güvenmiyorsanız? İddianın doğru olduğunu nasıl doğrularsınız?

En sevdiğim cevap.

Burada gerçekten işe yarayan bir çözüm önerildi:

Bu işe yararken, durum farklarını kullanmaya yönelik teknik kararın uygulama mantığına sızdığı anlamına gelir; bu, bir toplama EVM eşdeğeri olsa bile projelerin sözleşmelerini bu değerlendirmeye uyarlaması gerektiği anlamına gelir.

Kısmi bir çözüm, bir işlem kökünü yayınlamak ve bunların geçerliliğini ZK kanıtı içinde doğrulamaktır. Bu durumda bile, gerekli Merkle yolunu elde etmek için sıralayıcıya güvenmek gerekir; bu, saygın merkezi sıralayıcılar için makul olabilir, ancak izinsiz bir ortamda daha yanıltıcı hale gelir.

Canlılık metrikleri

Toplama işlemlerinin kesinleşmesine kadar geçen süreyi takip etmeye yönelik ilk adım olarak L2BEAT'te, özellikle işlem grupları (varsa) ve durum kökleri arasındaki aralıklar olmak üzere canlılık ölçümlerini izlemeye başladık. Bunun mantığı, örneğin bir toplamanın L1 ile ayda yalnızca bir kez etkileşime girmesi durumunda kullanıcıların nihai sonuca ulaşma süresinin dakikalar mertebesinde olmasını bekleyemeyeceğidir. Canlılık ölçümleri, kesinliğe kadar geçen süre için bir alt sınır göstergesi olarak düşünülebilir: Bir işlem verileri toplaması, toplu işlemleri iki dakikada bir yayınlıyorsa ve L2 işlemlerinin dağılımının tekdüze olduğu varsayılırsa, kesinliğe kadar beklenen süre bir dakikadan az değildir. .

ZkSync Era (durum güncellemeleri) ve OP Ana Ağı (tx grupları) için izlediğimiz bazı veri örnekleri aşağıda verilmiştir:

Eylül ayı için zkSync Era canlılık ölçümleri.

Eylül ayına ait OP Mainnet canlılık ölçümleri.

Tahmin edildiği gibi, ZK kanıtlarının oluşturulması zaman aldığından ve tek bir kanıta daha fazla işlem dahil etme teşviki bulunduğundan zkSync Era, OP Mainnet'ten daha kötü canlılık ölçümlerine sahiptir. Önceki bölümlerde tartıştığımız gibi, canlılık metriklerinin doğrudan kesinlik değerlendirmelerine dönüşmediğini akılda tutmak önemlidir: en kötü durumda, OP Mainnet'in sıralama penceresi nedeniyle aslında daha yüksek bir kesinliğe ulaşma süresi vardır.

Artık L2BEAT'teki çoğu toplamanın canlılık ölçümlerini keşfedebilirsiniz:

Canlılığı izlemenin sınırlamaları

Canlılık, kesinliğin alt sınır göstergesi olarak görülse de bazen çok kötü bir gösterge olabilir. Blok süresi 4 saniye olan bir toplama düşünün; bu, her Ethereum bloğu için 3 toplama bloğunun olduğu anlamına gelir. Toplama operatörü, L1 bloğu başına yalnızca iki L2 bloğu yayınlıyorsa, Ethereum'un bakış açısına göre toplama çok canlı olsa bile, L2 yumuşak onaylarının giderek daha gerisinde kalacak ve kesinliğe ulaşma süresi giderek daha da kötüleşecektir. Bu aşırı bir senaryo olsa da, toplamaların hesaba katılması gereken bir şey.

Pratik bir örnek Starknet'tir: Durum güncellemeleri arasında ortalama 32 saniye gözlemlesek de, kesinliğe kadar geçen süre aslında 6 saate yakındır:

Kaynak: starkscan.co

Bunun nedeni Starknet'in L1'deki her L2 bloğu için bir durum kök güncellemesi yayınlamasıdır. Ancak bunu yapmak için, genellikle yaklaşık her 30 dakikada bir yayınlanan bir SHARP kanıtına başvurmaları gerekir. Ek olarak, bu kanıtlar L2 yumuşak onaylı zincirin ucunun yaklaşık 6 saat gerisindedir.

Yumuşak onaylar

Yumuşak onaylar, güvenlik garantileri pahasına L2'de daha kısa onay süreleri elde etmek için kullanılan onay kurallarıdır. Şu anda, her durumda, yumuşak onaylar, merkezi operatörün L1'e farklı iletiler göndermemesi konusunda güvenildiğini ima ediyor. Yanlış yazılım doğrulamaları atfedilebilir hatalardır, bu nedenle sıralayıcıların zincir dışı veya zincir içi kesinti itibarını izlemeye yönelik mekanizmalar uygulanabilir. Nethermind ile işbirliği içinde, bu güvenlik özelliklerini tahmin etmeyi ve herhangi bir anda risk altındaki değer miktarını takip etmeyi planlıyoruz.

Solda: Kesme mekanizmasıyla güvence altına alınan yumuşak onaylar olması durumunda Starknet'e yönelik ekonomik garantiler. Sağ: zaman içinde yeniden düzenlenme riski taşıyan toplam değer.

İleriye gidiyor

Kesinliğe kadar geçen süreyi takip etmek karmaşık bir iştir. İlk adımımız, ZK toplamaları için kanıt gönderimi aralıklarını izlemektir; bu, durum kök gönderimleri arasındaki aralıklarla karşılaştırıldığında kesinliğe kadar geçen sürede daha yüksek bir alt sınır empoze eder. Bunu takiben, her proje için geçmiş verileri gösteren grafikler sunmayı planlıyoruz. Daha sonra araştırmamız, nihai sonuca kadar geçen süre için nihai olarak gerçek zamanlı ölçümler elde etmek için dikkate alınması gereken tüm ek mekanizmalara odaklanacaktır. Bizi izlemeye devam edin!

Yasal Uyarı:

1. Bu makale [orta]'dan yeniden basılmıştır. Tüm telif hakları orijinal yazara [Luca Donno] aittir. Bu yeniden basıma itirazlarınız varsa lütfen Gate Learn ekibiyle iletişime geçin; onlar konuyu hemen halledeceklerdir.
2. Sorumluluk Reddi: Bu makalede ifade edilen görüş ve görüşler yalnızca yazara aittir ve herhangi bir yatırım tavsiyesi teşkil etmez.
3. Makalenin diğer dillere çevirileri Gate Learn ekibi tarafından yapılır. Aksi belirtilmedikçe tercüme edilen makalelerin kopyalanması, dağıtılması veya intihal edilmesi yasaktır.