Son zamanlarda Twitter'daki tartışmaların çoğu L2 ademi merkeziyetçiliği etrafında dönüyor. İnşa ettiğimiz Toplamalar yeterince merkeziyetsiz mi? Yoksa en azından ademi merkeziyetçilik yolunda mı? Önemli mi?
Toplama fikri basit: Zincir dışı katılımcıların, daha sonra zincir üzerinde kolayca doğrulanabilecek işlemler yapabilmelerini istiyoruz. Rollup ile taban katmanı, "güven" tabanının, yakın çevresi dışında meydana gelen etkinlikler için kullanılmasına izin verir. Karşılığında, Rollup bu güveni artırmak için küçük bir ücret (kira) öder.
Peki merkezi olmayan Toplamalara ihtiyacımız var mı?
Sezgisel cevap evet! Blok zincirini oluşturduğumuz ruh budur.
Ancak, bu sorunun cevabının basit bir evet ya da hayır olmadığına inanıyorum. Bunun yerine, ayrı ayrı analiz edilmesi gereken birden çok yönü vardır. Sonraki bölümlerde, bu soruyu üç açıdan inceleyeceğim: felsefi, teknolojik ve ekonomik. ****Bu üçü mutlaka kapsamlı veya özel değildir, ancak soruna ilişkin iyi bir genel bakış açısı sağlamalıdır. **
1. Felsefi bakış açısı
Sohbeti bir üst seviyeye taşıyarak başlayalım - ademi merkeziyetçiliği neden önemsiyoruz?
Çünkü açık yeniliği destekleyen izinsiz bir gelecek istiyoruz. Kullanıcıların herhangi bir kısıtlama olmaksızın ve tek bir varlığa güvenmeye ihtiyaç duymadan yeni şeyler oluşturabilmelerini istiyoruz.
Blockchain'in kısa tarihinde, pek çok anonim geliştirici harika şeyler inşa etti. Aslında, Bitcoin'in kendisi anonim bir varlık tarafından yaratıldı - yakında dünyadaki çoğu insanın küresel ödemeler için kullandığı para birimi olabilir! İşte izinsiz inovasyonun gücü!
Blockchain, ortak hiçbir yanı olmayan insanlarla işbirliği yapmamızı sağlıyor ve onların bu güveni kırmalarının hiçbir yolu olmadığını biliyoruz - Preston Evans
Bitcoin ve Ethereum gibi güvenilir olmayan ağların merkezi olmayan temeli, böyle bir gelecek inşa etmemize izin veriyor. O halde, Rollups gibi bu zincirlerle güven ilişkisi olan herhangi bir zincirin de merkezi olmaması gerektiği açıktır!
Aslında, ilginç ve önemli bir soruyu gündeme getiriyor:
**Eğer Rollup merkeziyetsiz değilse bu, Ethereum'un merkeziyetsiz olmadığı anlamına mı gelir? **
Buna biraz iyimser bakmanın bir yolu, izinsiz bir dünyada, toplamaların, tamamen izin verilen zincirler dahil (ancak bunlarla sınırlı olmamak üzere) istedikleri her şeyi oluşturmalarına izin verilmesi gerektiğidir - ve bu toplamanın kullanıcıları, yine de güvenlikten yararlanabilmelidir. temel katman. Temel katman dağıtıldığı ve toplama "tamamen" uygulandığı sürece izin verilen zincirlerin bile kullanımı güvenli olmalıdır ("tam olarak uygulanmış" hakkında teknik bölümde daha fazla konuşacağız).
Ancak gerçek şu ki, günümüzde çoğu toplama henüz tam uygulama aşamasına ulaşmadı ve kullanıcılara istenen düzeyde güvenlik ve güvensizlik sağlamıyor.
Peki, toplamanın doğru uygulanması neye benziyor? görelim:
2. Teknoloji
Toplama düzeyinde ademi merkeziyetçilik ve güvenlik konusunu gerçekten anlamak için, ona ilk ilkelerden bakmamız gerekir. Blockchain'in ilk ilkelerini Sreeram Kannan'dan daha iyi açıklayabilen çok kişi yoktur.
Blok zinciri, ağdaki farklı düğümlerin, defterin durumu hakkında fikir birliği sağlamak için tanımlanmış bir protokolü izlediği dağıtılmış bir defterdir. Bu düğümlerin ağı nasıl gördüklerine bağlı olarak, kendi defterlerinde ağın doğru durumunu doğrulamak için farklı kuralları olabilir.
Örneğin, Ethereum'un Gasper protokolünde iki farklı onay kuralı vardır - mevcut kural (en ağır zincire dayalı) ve nihai kural (cihaz tarafından onaylanan bloklara dayalı).
Özellikle toplamalarda, tam düğümlerin hafif istemcilerden farklı onay kuralları vardır. Geleneksel akıllı sözleşme toparlamasında (SCR), akıllı sözleşmenin (doğrulama köprüsü) kendi onay kuralları vardır. Olumsuz olaylar yoksa, bu doğrulama kuralları sonunda "tutarlılık bölgeleri" olarak adlandırılan bölgelerde çakışır. Adından da anlaşılacağı gibi, fikir birliği bölgelerinde, tüm katılımcılar ağ hakkında aynı görüşe sahiptir (ve defterlerinde aynı geçmişe sahiptir).
Tüm onay kuralları güvenliyse, hiçbir kötü şey olmaz. Sreeram'ın yukarıdaki gönderide paylaştığı gibi, bu doğrulama kurallarının güvenliğini temel olarak 5 özellik tanımlar.
Defter büyümesi - Toplama zinciri büyümeye devam etmelidir (canlılık)
Sansür Direnci - Tüm kullanıcılar tüm işlemleri temel katmana dahil edebilmelidir
Yeniden yapılandırma direnci - işlem tamamlandıktan sonra eski haline getirilmemelidir
Veri Kullanılabilirliği - İşlem verileri bir yerde yayınlanmalıdır
Geçerlilik - işlemler ve durum geçişleri geçerli olmalıdır
İlk 2 özellik birlikte sistemin "canlı" durumunu tanımlarken, son 3 özellik "güvenli" durumunu tanımlar.
Her birine farklı birleştirme aktörlerinin bakış açısından bakalım ve ademi merkeziyetçilik olmadan hangilerinin hafifletilebileceğini görelim.
Farklı aktörler, güvenlik ve canlılık için farklı mekanizmalara güvenir.
Tam düğüm:
Tam bir düğüm çalıştırıyorsanız, yayınlanan verilere erişiminiz olur ve doğrudan doğrulayabilirsiniz. Daha sonra bu verileri, işlemleri kendiniz gerçekleştirmek ve işlemlerin geçerliliğini ve bu işlemlerden sonra Toplama'nın son durumunu belirlemek için kullanabilirsiniz.
Kalan güvenlik koşulları bu nedenle aktivite özellikleri ve rekombinasyon direncidir. İkincisi için, tam düğümler, temel zincirin doğrulayıcılarına ve kullandığı fikir birliği protokolüne güvenirken, canlılık özellikleri için tam düğümler, sıralayıcıya ve Toplama uygulamalarına güvenir.
Hafif istemci:
Çoğu kullanıcı, hafif düğümlere gömülü cüzdanları kullanır veya blok zinciri verilerini elde etmek ve blok zinciri ile etkileşim kurmak için üçüncü taraf hizmetleri kullanır. Işık düğümleri çeşitli tiplerde olabilir:
Durum Doğrulayıcı - Durum geçişlerinin geçerliliğini doğrulayın
DA Doğrulayıcı - Veri kullanılabilirliğini doğrular,
**mutabakat doğrulayıcı - temel katmanın mutabakat kanıtını doğrulama veya **
tam doğrulayıcı - yukarıdakilerin tümünü doğrular
Tam doğrulayıcı bir hafif istemci çalıştırıyorsanız, veri kullanılabilirliği örneklemesi yoluyla verilerin kullanılabilir olduğunu doğrulayabilir, geçerlilik kanıtları veya sahtekarlık kanıtları aracılığıyla durum geçişlerinin geçerliliğini doğrulayabilir, ayrıca durumun temelde sonlandırıldığını doğrulayabilirsiniz. Katman mutabakatı (Ethereum'da bu, bir senkronizasyon komitesi izlenerek yapılabilir).
Kalan güvenlik koşulu canlılık özelliğidir ve hafif istemciler sıralayıcı ve toplama uygulamalarına güvenir.
Yerleşik akıllı sözleşme (doğrulama köprüsü):
Geleneksel SCR'de, bir akıllı sözleşmenin "onay kuralı", 5 güvenlik özelliğinin tümünü uygulamaktır:
Sıralayıcı değiştirme protokolü aracılığıyla defter büyümesi
Katılımı zorunlu kılarak sansüre direnin
Yeniden yapılanmaya karşı direnci yalnızca önceki durumun üzerine inşa edin
Veri kullanılabilirliği, temel katmanda DA gönderilerek elde edilir
Geçerlilik/sahtekarlık kanıtı yoluyla geçerliliğin doğrulanması
SCR'nin tam düğümleri, canlılık özelliklerini uygulamak için akıllı sözleşmelere güvenir. Temel katmandan yeniden yapılanma direncini "emerler".
Hafif düğümler, canlılık özelliklerini geliştirmek ve temel katmandan DA ve yeniden düzenleme direncini emmek için akıllı sözleşmelere güvenir. Geçerlilik kanıtını kendileri veya akıllı sözleşmeler aracılığıyla doğrulayabilirler.
SCR'nin fikir birliği, akıllı sözleşme tarafından tanımlanan kanonik zinciri takip etmektir.
**Ya Egemen Toplama? **
Egemen Toplamaların geçerlilik veya canlılık koşullarını zorlamak için akıllı sözleşmeleri (doğrulama köprüleri) yoktur. Bunun yerine, bir aşağı akış toplama düğümüne "yuvarlandıklarını" kanıtlayacaklar. Bu düğümler hala DA ve Reorg direncini temel katmandan emer.
Tıpkı SCR'de olduğu gibi, egemen toparlama düğümlerinde canlılık özelliğini zorlamak için bazı mekanizmalara ihtiyaç vardır. Kanonik zinciri tanımlamak için, p2p kanıtlarını yayınlamak gibi bağımsız mekanizmaları seçtiler.
Bütün bunların ademi merkeziyetçilikle ne ilgisi var?
İster bir akıllı sözleşme toplaması ister bağımsız bir toplama olsun, canlılık özelliği toplamanın doğru uygulanmasından gelir. Yukarıda gördüğümüz gibi, doğru bir toplama uygulaması iki önemli bileşeni içermelidir:
zorunlu dahil etme mekanizmaları ve
Sıralayıcı değiştirme protokolü
Zorunlu dahil etme, sansüre karşı direnç oluşturmaya yardımcı olur. Bu mekanizma, kullanıcıların işlemlerini doğrudan taban katmanına "zorla dahil etmelerine" olanak tanır. Toplamadaki herhangi bir kullanıcı, fonlarıyla temel katmana geri dönmeye zorlayabilir. Bu nedenle, toplama için yalnızca bir merkezi harmanlama düğümü olsa bile, yerinde olgun bir yaptırım mekanizması olduğu sürece kullanıcıları sansürleyemez.
Ama bu yeterli mi?
Kullanıcılar oturumu kapatabilse bile, bu, çoğu kullanıcının L1'e geri dönmesi durumunda kuruluşun çalışmaya devam etmek için fazla bir teşviki olmayacağı anlamına gelebilir. Ayrıca, zorunlu dahil etme mekanizması genellikle uzun bir bekleme süresine sahiptir ve ortalama bir kullanıcı için uygulanması oldukça pahalı olabilir. Bu mekanizmanın sağladığı sansür direnci tam olarak pratik (veya gerçek zamanlı) değildir. Bu durumu “zayıf sansür” olarak adlandırabiliriz.
Ardından son canlılık özniteliğimize sahibiz - genel muhasebe büyümesi
Merkezi harmanlayıcı kötü amaçlı hale gelirse, basitçe blok üretimini durdurarak özet zincirinin büyümesini durdurabilir. Böyle bir durumda, kullanıcının veya işletmenin toplamayı tekrar "canlı" hale getirmek için yapabileceği hiçbir şey yoktur.
Bu sorunu çözmek için bir sıralayıcı değiştirme protokolüne ihtiyacımız var.
Sıralayıcı değiştirme protokolünün fikri, sıralayıcı kötü niyetli bir şekilde davranırsa, toplu yönetişimin sıralayıcıyı başlatabilmesidir. Bunu başarmanın yollarından biri, merkezi sıralayıcı düğümlerini merkezi olmayan bir sıralayıcı protokolü ile değiştirmektir. Ayıklayıcı merkezi değilse ve toplamanın yapı taşlarını tekelinde tutmuyorsa, toplamayı durdurmak neredeyse imkansızdır.
Bu nedenle, kullanıcı fonları, zorunlu dahil etme mekanizması aracılığıyla Toplamalarda her zaman güvende olsa da, sağlam bir sipariş veren değiştirme protokolü oluşturmak, Toplamaları canlı tutmaya yardımcı olur ve pratik, gerçek zamanlı sansüre karşı direnç sağlar.
hepsi bu?
Pek değil. Teknik açıdan dikkate alınması gereken bir husus daha vardır:
Ya akıllı sözleşmeler birleştirilmiş bir merkezi komite tarafından yükseltilebilirse? Diyelim ki toplamalar şu anda doğru bir şekilde uygulanıyor, ancak yarın komite artık akıllı sözleşmelere ihtiyacımız olmadığını kabul ediyor, bunun yerine toplama durumunun kanıtlarını p2p ağına yayınlıyoruz.
Toplama kullanıcısı olarak böyle bir yükseltmeyi kabul etmiyorsanız, yükseltme uygulanmadan önce toplamadan çıkabilmelisiniz (yine de, bu iyi bir kullanıcı deneyimi değildir ve iş için iyi olmayabilir). Bu, "gecikmeli yönetişim güncellemeleri" yoluyla elde edilebilir. Yükseltmenin uygulanacağı bir "bildirim süresi" gibidir. Güncellemeleri kabul etmeyen kullanıcılar bildirim süresi içinde vazgeçebilirler.
Ademi merkeziyetçiliğin en uç noktası, tamamen değişmez akıllı sözleşmelere sahip olma seçeneğidir. Bu sözleşmeler herhangi bir çoklu imza cüzdanı veya başka bir komite tarafından yönetilmez ve dağıtıldıktan sonra asla yükseltilemezler.
Tabii bunun da kendine göre sorunları var. Kodda herhangi bir hata varsa veya bazı önemli olaylar akıllı sözleşmenin güncellenmesini gerektiriyorsa, toplama düğümü için tek seçenek yeni akıllı sözleşmeye geçmek ve kullanıcı fonlarını eski sözleşmede mahsur bırakmaktır.
mevcut durum
Ne yazık ki, Toplama'nın şu anki durumu, yukarıda tartıştığımız tam uygulamaya yakın değil. Toplamaların çoğu hala "eğitim çarkları" aşamasında ve doğru yapmaya çalışıyor.
L2BEAT'e göre, Fuel v1 ve DeGate, tüm aktivite ve güvenlik koşullarını sağlayacak şekilde olgunlaşan yegane iki kümedir.
3. Ekonomi
Rollup ekonomisine kullanıcılar ve Rollup operatörleri açısından bakalım:
1) Kullanıcı Deneyimi - Kullanıcılar ucuz fiyatlar almalı ve işlemler için çok uzun süre beklemek zorunda kalmamalı
2) Toplam Kar - Sıralayıcılar ve Token sahipleri için Toplama'yı çalıştırmak karlı olmalıdır
Kullanıcılar hızlı ve ucuz işlemler aldığında kullanıcı deneyimi optimize edilir.
İşlemlerin sonuçlanma hızı, temel katman bloklarının tamamlanma hızına bağlıdır. İşlemler, L1'deki veriler kesinleştiğinde nihai olarak kabul edilebilir. Bununla birlikte, tam düğümleri çalıştıran kullanıcılar, yalnızca işlemleri yürüterek ve nihai durumu belirleyerek anında kesinlik elde edebilirler.
Ancak herkesin tam bir düğüm çalıştırması pratik değildir. Bu nedenle, merkezi bir harmanlayıcı yararlıdır çünkü kullanıcılara işlemlerinin bir bloğa dahil edildiğine ve sonlandırılacağına dair "yazılı onay" sağlayabilir. Bu, çoğu kullanım durumu için yeterlidir. Bununla birlikte, kendisine karşı hareket edebilecek bir merkezi partiye güvenmeyi içerir.
Bazı sıralayıcı alternatif protokol çözümleri (ör. Toplamalara dayalı), kullanıcıların zararına bu özellikten vazgeçerken, diğer çözümler (ör. harici POS konsensüsü (ör. Espresso)) aşağıdaki Riske maruz kalmadan benzer ön onay garantileri sağlayabilir: Merkezi sıralayıcı.
Kullanıcıya maliyeti ne olacak?
Bir Toplama işleminin açık fiyatı genellikle:
L2 Gaz Maliyeti = L1 Gaz Maliyeti + Sıralayıcı Ücreti
Rasyonel hareket eden bir merkezi sipariş veren, kullanıcılara daha yüksek maliyetler yüklemek anlamına gelse bile her zaman kendi kârını maksimize etmek ister. Ancak, bunun merkezi olmayan bir tasnif mekanizmasıyla da çözülemeyeceğini belirtmekte fayda var. Merkezi olmayan bir sipariş verendeki POS düğümleri bile kendi karlarını maksimize etmek istiyor.
Aslında bu, toplamın karı harici bir ayırıcıya teslim etmek istemeyebileceği bir yanlış hizalama sorunu yaratır.
Toplama Kârı - Sıralayıcı ücretlerine ek olarak, Toplama, toplu kullanıcı işlemlerinden MEV çıkararak da kâr elde edebilir. Bu MEV'yi ilişkilendirmek genellikle zordur, çünkü siparişi verenin kendi önde giden işlemlerinden bazılarını partiye dahil edip etmediğini öğrenmek zordur.
**Toplama, harici POS mutabakatı ile değiştirilirse, bu MEV'yi harici operatörlere vereceklerdir. **
Toplamaların geliri dış mekanizmalara devretme bu sorunlarının her ikisinin de, Toplamalar ile dış mekanizmalar arasındaki, iç ve çapraz Toplama işlemlerinden kaynaklanan ücretlerin ve MEV'nin çözülebileceği “ticaret anlaşmaları” yoluyla çözülebileceğini belirtmekte fayda var. Özete geri yönlendirir.
Bununla birlikte, Jon Charbonneau'nun Modüler Zirve sırasındaki konuşmasında ve sonraki gönderilerde açıklandığı gibi, bir dizi izin verilen düğüme sipariş veren toparlama yönetim temsilcisine sahip olmak daha iyi bir fikir olabilir. Bu düğümler, stratejik olarak coğrafi olarak dağıtılmak üzere seçilebilir ve yönetişim, kötü aktörleri basitçe kovar.
**Bu, toplamaların marjları şirket içinde tutmasına izin verirken aynı zamanda merkezi ayrıştırıcıların olumsuz etkilerini hafiflettiği için iki kuş bir taş çözümü olabilir. **
Ancak bunun tersi, sıralayıcıların sınırlı rotasyonu ile sıralayıcıların miyop olmayan davranışlara sahip olabilmesidir, bu da toplama kullanıcıları pahasına tekel fiyatlandırmaya/fiyat fahiş uygulamasına yol açabilir.
Her iki durumda da, özetlemenin kullanıcılar için uygun maliyetli olması için bazı sıralayıcı değiştirme protokolünün gerekli olduğu açıktır. Bir yönetim kanıtı mı, harici bir mutabakat mekanizması mı yoksa başka bir şey mi, başka bir makale için bir tartışma.
4. Sonuç
Umarım, Toplama'nın izlediği yol ne olursa olsun, hedefin sıralayıcı değiştirme, zorla dahil etme ve gecikmeli yönetişim güncellemeleri için olgun mekanizmalarla tam bir uygulama olması gerektiği açıktır. Yalnızca zorunlu dahil etme ve gecikmeli güncellemeler olsa bile, koordinatörün merkezileştirilmiş olup olmadığına bakılmaksızın, Toplama tam olarak uygulandığında kullanıcı fonları güvendedir.
Bununla birlikte, sağlam bir sıralayıcı değiştirme protokolü, canlılık garantilerini iyileştirebilir ve potansiyel olarak Toplama kullanıcılarının ekonomisini iyileştirebilir.
View Original
The content is for reference only, not a solicitation or offer. No investment, tax, or legal advice provided. See Disclaimer for more risks disclosure.
Toplama ademi merkeziyetçiliğinin önemini üç açıdan görüntüleyin
Yazar: Shivanshu Madan; Derleyen: Huohuo/Vernacular Blockchain
Son zamanlarda Twitter'daki tartışmaların çoğu L2 ademi merkeziyetçiliği etrafında dönüyor. İnşa ettiğimiz Toplamalar yeterince merkeziyetsiz mi? Yoksa en azından ademi merkeziyetçilik yolunda mı? Önemli mi?
Toplama fikri basit: Zincir dışı katılımcıların, daha sonra zincir üzerinde kolayca doğrulanabilecek işlemler yapabilmelerini istiyoruz. Rollup ile taban katmanı, "güven" tabanının, yakın çevresi dışında meydana gelen etkinlikler için kullanılmasına izin verir. Karşılığında, Rollup bu güveni artırmak için küçük bir ücret (kira) öder.
Peki merkezi olmayan Toplamalara ihtiyacımız var mı?
Sezgisel cevap evet! Blok zincirini oluşturduğumuz ruh budur.
Ancak, bu sorunun cevabının basit bir evet ya da hayır olmadığına inanıyorum. Bunun yerine, ayrı ayrı analiz edilmesi gereken birden çok yönü vardır. Sonraki bölümlerde, bu soruyu üç açıdan inceleyeceğim: felsefi, teknolojik ve ekonomik. ****Bu üçü mutlaka kapsamlı veya özel değildir, ancak soruna ilişkin iyi bir genel bakış açısı sağlamalıdır. **
1. Felsefi bakış açısı
Sohbeti bir üst seviyeye taşıyarak başlayalım - ademi merkeziyetçiliği neden önemsiyoruz?
Çünkü açık yeniliği destekleyen izinsiz bir gelecek istiyoruz. Kullanıcıların herhangi bir kısıtlama olmaksızın ve tek bir varlığa güvenmeye ihtiyaç duymadan yeni şeyler oluşturabilmelerini istiyoruz.
Blockchain'in kısa tarihinde, pek çok anonim geliştirici harika şeyler inşa etti. Aslında, Bitcoin'in kendisi anonim bir varlık tarafından yaratıldı - yakında dünyadaki çoğu insanın küresel ödemeler için kullandığı para birimi olabilir! İşte izinsiz inovasyonun gücü!
Bitcoin ve Ethereum gibi güvenilir olmayan ağların merkezi olmayan temeli, böyle bir gelecek inşa etmemize izin veriyor. O halde, Rollups gibi bu zincirlerle güven ilişkisi olan herhangi bir zincirin de merkezi olmaması gerektiği açıktır!
Aslında, ilginç ve önemli bir soruyu gündeme getiriyor:
**Eğer Rollup merkeziyetsiz değilse bu, Ethereum'un merkeziyetsiz olmadığı anlamına mı gelir? **
Buna biraz iyimser bakmanın bir yolu, izinsiz bir dünyada, toplamaların, tamamen izin verilen zincirler dahil (ancak bunlarla sınırlı olmamak üzere) istedikleri her şeyi oluşturmalarına izin verilmesi gerektiğidir - ve bu toplamanın kullanıcıları, yine de güvenlikten yararlanabilmelidir. temel katman. Temel katman dağıtıldığı ve toplama "tamamen" uygulandığı sürece izin verilen zincirlerin bile kullanımı güvenli olmalıdır ("tam olarak uygulanmış" hakkında teknik bölümde daha fazla konuşacağız).
Ancak gerçek şu ki, günümüzde çoğu toplama henüz tam uygulama aşamasına ulaşmadı ve kullanıcılara istenen düzeyde güvenlik ve güvensizlik sağlamıyor.
Peki, toplamanın doğru uygulanması neye benziyor? görelim:
2. Teknoloji
Toplama düzeyinde ademi merkeziyetçilik ve güvenlik konusunu gerçekten anlamak için, ona ilk ilkelerden bakmamız gerekir. Blockchain'in ilk ilkelerini Sreeram Kannan'dan daha iyi açıklayabilen çok kişi yoktur.
Blok zinciri, ağdaki farklı düğümlerin, defterin durumu hakkında fikir birliği sağlamak için tanımlanmış bir protokolü izlediği dağıtılmış bir defterdir. Bu düğümlerin ağı nasıl gördüklerine bağlı olarak, kendi defterlerinde ağın doğru durumunu doğrulamak için farklı kuralları olabilir.
Örneğin, Ethereum'un Gasper protokolünde iki farklı onay kuralı vardır - mevcut kural (en ağır zincire dayalı) ve nihai kural (cihaz tarafından onaylanan bloklara dayalı).
Özellikle toplamalarda, tam düğümlerin hafif istemcilerden farklı onay kuralları vardır. Geleneksel akıllı sözleşme toparlamasında (SCR), akıllı sözleşmenin (doğrulama köprüsü) kendi onay kuralları vardır. Olumsuz olaylar yoksa, bu doğrulama kuralları sonunda "tutarlılık bölgeleri" olarak adlandırılan bölgelerde çakışır. Adından da anlaşılacağı gibi, fikir birliği bölgelerinde, tüm katılımcılar ağ hakkında aynı görüşe sahiptir (ve defterlerinde aynı geçmişe sahiptir).
Tüm onay kuralları güvenliyse, hiçbir kötü şey olmaz. Sreeram'ın yukarıdaki gönderide paylaştığı gibi, bu doğrulama kurallarının güvenliğini temel olarak 5 özellik tanımlar.
İlk 2 özellik birlikte sistemin "canlı" durumunu tanımlarken, son 3 özellik "güvenli" durumunu tanımlar.
Her birine farklı birleştirme aktörlerinin bakış açısından bakalım ve ademi merkeziyetçilik olmadan hangilerinin hafifletilebileceğini görelim.
Farklı aktörler, güvenlik ve canlılık için farklı mekanizmalara güvenir.
Tam düğüm:
Tam bir düğüm çalıştırıyorsanız, yayınlanan verilere erişiminiz olur ve doğrudan doğrulayabilirsiniz. Daha sonra bu verileri, işlemleri kendiniz gerçekleştirmek ve işlemlerin geçerliliğini ve bu işlemlerden sonra Toplama'nın son durumunu belirlemek için kullanabilirsiniz.
Kalan güvenlik koşulları bu nedenle aktivite özellikleri ve rekombinasyon direncidir. İkincisi için, tam düğümler, temel zincirin doğrulayıcılarına ve kullandığı fikir birliği protokolüne güvenirken, canlılık özellikleri için tam düğümler, sıralayıcıya ve Toplama uygulamalarına güvenir.
Hafif istemci:
Çoğu kullanıcı, hafif düğümlere gömülü cüzdanları kullanır veya blok zinciri verilerini elde etmek ve blok zinciri ile etkileşim kurmak için üçüncü taraf hizmetleri kullanır. Işık düğümleri çeşitli tiplerde olabilir:
Tam doğrulayıcı bir hafif istemci çalıştırıyorsanız, veri kullanılabilirliği örneklemesi yoluyla verilerin kullanılabilir olduğunu doğrulayabilir, geçerlilik kanıtları veya sahtekarlık kanıtları aracılığıyla durum geçişlerinin geçerliliğini doğrulayabilir, ayrıca durumun temelde sonlandırıldığını doğrulayabilirsiniz. Katman mutabakatı (Ethereum'da bu, bir senkronizasyon komitesi izlenerek yapılabilir).
Kalan güvenlik koşulu canlılık özelliğidir ve hafif istemciler sıralayıcı ve toplama uygulamalarına güvenir.
Yerleşik akıllı sözleşme (doğrulama köprüsü):
Geleneksel SCR'de, bir akıllı sözleşmenin "onay kuralı", 5 güvenlik özelliğinin tümünü uygulamaktır:
SCR'nin tam düğümleri, canlılık özelliklerini uygulamak için akıllı sözleşmelere güvenir. Temel katmandan yeniden yapılanma direncini "emerler".
Hafif düğümler, canlılık özelliklerini geliştirmek ve temel katmandan DA ve yeniden düzenleme direncini emmek için akıllı sözleşmelere güvenir. Geçerlilik kanıtını kendileri veya akıllı sözleşmeler aracılığıyla doğrulayabilirler.
SCR'nin fikir birliği, akıllı sözleşme tarafından tanımlanan kanonik zinciri takip etmektir.
**Ya Egemen Toplama? **
Egemen Toplamaların geçerlilik veya canlılık koşullarını zorlamak için akıllı sözleşmeleri (doğrulama köprüleri) yoktur. Bunun yerine, bir aşağı akış toplama düğümüne "yuvarlandıklarını" kanıtlayacaklar. Bu düğümler hala DA ve Reorg direncini temel katmandan emer.
Tıpkı SCR'de olduğu gibi, egemen toparlama düğümlerinde canlılık özelliğini zorlamak için bazı mekanizmalara ihtiyaç vardır. Kanonik zinciri tanımlamak için, p2p kanıtlarını yayınlamak gibi bağımsız mekanizmaları seçtiler.
Bütün bunların ademi merkeziyetçilikle ne ilgisi var?
İster bir akıllı sözleşme toplaması ister bağımsız bir toplama olsun, canlılık özelliği toplamanın doğru uygulanmasından gelir. Yukarıda gördüğümüz gibi, doğru bir toplama uygulaması iki önemli bileşeni içermelidir:
zorunlu dahil etme mekanizmaları ve
Sıralayıcı değiştirme protokolü
Zorunlu dahil etme, sansüre karşı direnç oluşturmaya yardımcı olur. Bu mekanizma, kullanıcıların işlemlerini doğrudan taban katmanına "zorla dahil etmelerine" olanak tanır. Toplamadaki herhangi bir kullanıcı, fonlarıyla temel katmana geri dönmeye zorlayabilir. Bu nedenle, toplama için yalnızca bir merkezi harmanlama düğümü olsa bile, yerinde olgun bir yaptırım mekanizması olduğu sürece kullanıcıları sansürleyemez.
Ama bu yeterli mi?
Kullanıcılar oturumu kapatabilse bile, bu, çoğu kullanıcının L1'e geri dönmesi durumunda kuruluşun çalışmaya devam etmek için fazla bir teşviki olmayacağı anlamına gelebilir. Ayrıca, zorunlu dahil etme mekanizması genellikle uzun bir bekleme süresine sahiptir ve ortalama bir kullanıcı için uygulanması oldukça pahalı olabilir. Bu mekanizmanın sağladığı sansür direnci tam olarak pratik (veya gerçek zamanlı) değildir. Bu durumu “zayıf sansür” olarak adlandırabiliriz.
Ardından son canlılık özniteliğimize sahibiz - genel muhasebe büyümesi
Merkezi harmanlayıcı kötü amaçlı hale gelirse, basitçe blok üretimini durdurarak özet zincirinin büyümesini durdurabilir. Böyle bir durumda, kullanıcının veya işletmenin toplamayı tekrar "canlı" hale getirmek için yapabileceği hiçbir şey yoktur.
Bu sorunu çözmek için bir sıralayıcı değiştirme protokolüne ihtiyacımız var.
Sıralayıcı değiştirme protokolünün fikri, sıralayıcı kötü niyetli bir şekilde davranırsa, toplu yönetişimin sıralayıcıyı başlatabilmesidir. Bunu başarmanın yollarından biri, merkezi sıralayıcı düğümlerini merkezi olmayan bir sıralayıcı protokolü ile değiştirmektir. Ayıklayıcı merkezi değilse ve toplamanın yapı taşlarını tekelinde tutmuyorsa, toplamayı durdurmak neredeyse imkansızdır.
Bu nedenle, kullanıcı fonları, zorunlu dahil etme mekanizması aracılığıyla Toplamalarda her zaman güvende olsa da, sağlam bir sipariş veren değiştirme protokolü oluşturmak, Toplamaları canlı tutmaya yardımcı olur ve pratik, gerçek zamanlı sansüre karşı direnç sağlar.
hepsi bu?
Pek değil. Teknik açıdan dikkate alınması gereken bir husus daha vardır:
Ya akıllı sözleşmeler birleştirilmiş bir merkezi komite tarafından yükseltilebilirse? Diyelim ki toplamalar şu anda doğru bir şekilde uygulanıyor, ancak yarın komite artık akıllı sözleşmelere ihtiyacımız olmadığını kabul ediyor, bunun yerine toplama durumunun kanıtlarını p2p ağına yayınlıyoruz.
Toplama kullanıcısı olarak böyle bir yükseltmeyi kabul etmiyorsanız, yükseltme uygulanmadan önce toplamadan çıkabilmelisiniz (yine de, bu iyi bir kullanıcı deneyimi değildir ve iş için iyi olmayabilir). Bu, "gecikmeli yönetişim güncellemeleri" yoluyla elde edilebilir. Yükseltmenin uygulanacağı bir "bildirim süresi" gibidir. Güncellemeleri kabul etmeyen kullanıcılar bildirim süresi içinde vazgeçebilirler.
Ademi merkeziyetçiliğin en uç noktası, tamamen değişmez akıllı sözleşmelere sahip olma seçeneğidir. Bu sözleşmeler herhangi bir çoklu imza cüzdanı veya başka bir komite tarafından yönetilmez ve dağıtıldıktan sonra asla yükseltilemezler.
Tabii bunun da kendine göre sorunları var. Kodda herhangi bir hata varsa veya bazı önemli olaylar akıllı sözleşmenin güncellenmesini gerektiriyorsa, toplama düğümü için tek seçenek yeni akıllı sözleşmeye geçmek ve kullanıcı fonlarını eski sözleşmede mahsur bırakmaktır.
mevcut durum
Ne yazık ki, Toplama'nın şu anki durumu, yukarıda tartıştığımız tam uygulamaya yakın değil. Toplamaların çoğu hala "eğitim çarkları" aşamasında ve doğru yapmaya çalışıyor.
L2BEAT'e göre, Fuel v1 ve DeGate, tüm aktivite ve güvenlik koşullarını sağlayacak şekilde olgunlaşan yegane iki kümedir.
3. Ekonomi
Rollup ekonomisine kullanıcılar ve Rollup operatörleri açısından bakalım:
1) Kullanıcı Deneyimi - Kullanıcılar ucuz fiyatlar almalı ve işlemler için çok uzun süre beklemek zorunda kalmamalı
2) Toplam Kar - Sıralayıcılar ve Token sahipleri için Toplama'yı çalıştırmak karlı olmalıdır
Kullanıcılar hızlı ve ucuz işlemler aldığında kullanıcı deneyimi optimize edilir.
İşlemlerin sonuçlanma hızı, temel katman bloklarının tamamlanma hızına bağlıdır. İşlemler, L1'deki veriler kesinleştiğinde nihai olarak kabul edilebilir. Bununla birlikte, tam düğümleri çalıştıran kullanıcılar, yalnızca işlemleri yürüterek ve nihai durumu belirleyerek anında kesinlik elde edebilirler.
Ancak herkesin tam bir düğüm çalıştırması pratik değildir. Bu nedenle, merkezi bir harmanlayıcı yararlıdır çünkü kullanıcılara işlemlerinin bir bloğa dahil edildiğine ve sonlandırılacağına dair "yazılı onay" sağlayabilir. Bu, çoğu kullanım durumu için yeterlidir. Bununla birlikte, kendisine karşı hareket edebilecek bir merkezi partiye güvenmeyi içerir.
Bazı sıralayıcı alternatif protokol çözümleri (ör. Toplamalara dayalı), kullanıcıların zararına bu özellikten vazgeçerken, diğer çözümler (ör. harici POS konsensüsü (ör. Espresso)) aşağıdaki Riske maruz kalmadan benzer ön onay garantileri sağlayabilir: Merkezi sıralayıcı.
Kullanıcıya maliyeti ne olacak?
Bir Toplama işleminin açık fiyatı genellikle:
L2 Gaz Maliyeti = L1 Gaz Maliyeti + Sıralayıcı Ücreti
Rasyonel hareket eden bir merkezi sipariş veren, kullanıcılara daha yüksek maliyetler yüklemek anlamına gelse bile her zaman kendi kârını maksimize etmek ister. Ancak, bunun merkezi olmayan bir tasnif mekanizmasıyla da çözülemeyeceğini belirtmekte fayda var. Merkezi olmayan bir sipariş verendeki POS düğümleri bile kendi karlarını maksimize etmek istiyor.
Aslında bu, toplamın karı harici bir ayırıcıya teslim etmek istemeyebileceği bir yanlış hizalama sorunu yaratır.
Toplama Kârı - Sıralayıcı ücretlerine ek olarak, Toplama, toplu kullanıcı işlemlerinden MEV çıkararak da kâr elde edebilir. Bu MEV'yi ilişkilendirmek genellikle zordur, çünkü siparişi verenin kendi önde giden işlemlerinden bazılarını partiye dahil edip etmediğini öğrenmek zordur.
**Toplama, harici POS mutabakatı ile değiştirilirse, bu MEV'yi harici operatörlere vereceklerdir. **
Toplamaların geliri dış mekanizmalara devretme bu sorunlarının her ikisinin de, Toplamalar ile dış mekanizmalar arasındaki, iç ve çapraz Toplama işlemlerinden kaynaklanan ücretlerin ve MEV'nin çözülebileceği “ticaret anlaşmaları” yoluyla çözülebileceğini belirtmekte fayda var. Özete geri yönlendirir.
Bununla birlikte, Jon Charbonneau'nun Modüler Zirve sırasındaki konuşmasında ve sonraki gönderilerde açıklandığı gibi, bir dizi izin verilen düğüme sipariş veren toparlama yönetim temsilcisine sahip olmak daha iyi bir fikir olabilir. Bu düğümler, stratejik olarak coğrafi olarak dağıtılmak üzere seçilebilir ve yönetişim, kötü aktörleri basitçe kovar.
**Bu, toplamaların marjları şirket içinde tutmasına izin verirken aynı zamanda merkezi ayrıştırıcıların olumsuz etkilerini hafiflettiği için iki kuş bir taş çözümü olabilir. **
Ancak bunun tersi, sıralayıcıların sınırlı rotasyonu ile sıralayıcıların miyop olmayan davranışlara sahip olabilmesidir, bu da toplama kullanıcıları pahasına tekel fiyatlandırmaya/fiyat fahiş uygulamasına yol açabilir.
Her iki durumda da, özetlemenin kullanıcılar için uygun maliyetli olması için bazı sıralayıcı değiştirme protokolünün gerekli olduğu açıktır. Bir yönetim kanıtı mı, harici bir mutabakat mekanizması mı yoksa başka bir şey mi, başka bir makale için bir tartışma.
4. Sonuç
Umarım, Toplama'nın izlediği yol ne olursa olsun, hedefin sıralayıcı değiştirme, zorla dahil etme ve gecikmeli yönetişim güncellemeleri için olgun mekanizmalarla tam bir uygulama olması gerektiği açıktır. Yalnızca zorunlu dahil etme ve gecikmeli güncellemeler olsa bile, koordinatörün merkezileştirilmiş olup olmadığına bakılmaksızın, Toplama tam olarak uygulandığında kullanıcı fonları güvendedir.
Bununla birlikte, sağlam bir sıralayıcı değiştirme protokolü, canlılık garantilerini iyileştirebilir ve potansiyel olarak Toplama kullanıcılarının ekonomisini iyileştirebilir.