Veri kullanılabilirliği çözümleri nasıl çalışır ve aralarındaki fark nedir?

Veri mevcudiyeti, blockchain genişlemesindeki ana darboğazlardan biridir.

**Yazan: **zer0kn0wledge.era

Derleyen: Kate, Marsbit

Not: Bu yazı @ChaosDAO'nun araştırmacısı olan @expctchaos Twitter'dan alınmıştır.Orijinal tweet'in içeriği MarsBit tarafından şu şekilde düzenlenmiştir:

0/ Veri Kullanılabilirliği (DA), ana ölçeklendirme darboğazıdır

Neyse ki @CelestiaOrg, @AvailProject ve @eigenlayer, DA oyununu değiştirecek ve yeni ölçeklenebilirlik düzeyleri sağlayacak

Peki nasıl çalışıyor ve #EigenDA'nın #Celestia ve #Avail gibi DA 15'ten farkı nedir?

1/ Veri kullanılabilirliği sorunlarına aşina değilseniz, lütfen veri kullanılabilirliği durumunu ayrıntılı olarak anlattığım aşağıdaki gönderime göz atın 👇

2/ Genel olarak iki tür veri işleme çözümü vardır

  • 🔷Zincir üstü DA
  • 🔷Zincir dışı DA

3/ Ve "saf geçerlilik doğrulaması", veri işlemenin zincir dışı olabileceği anlamına gelir, çünkü zincir dışı veri hizmeti sağlayıcıları herhangi bir zamanda çevrimdışı olabilir...

4/ …#StarkEx, #zkPorter ve #Arbitrum Nova, veri kullanılabilirliğini garanti etmek için bir grup tanınmış üçüncü taraf olan DAC'a dayanan doğrulama senaryolarının örnekleridir.

5/ Öte yandan #EigenDA, @CelestiaOrg ve @AvailProject, evrensel bir DA çözümü diyebileceğimiz şeylerdir.

Ancak, EigenDA ile diğer iki çözüm arasında bazı farklılıklar vardır.

6/ @CelestiaOrg'un nasıl çalıştığını öğrenmek istiyorsanız aşağıdaki bağlantıya göz atın

7/ @AvailProject'i geçmişte de ele aldım, bu yüzden daha fazlasını öğrenmek için buraya göz atın

8/ @eigenlayer hakkında bilgi tazelemeye ihtiyacınız varsa aşağıdaki konuya göz atın 👇

9/ Bugünkü gönderide @eigenlayer'ın #EigenDA ve @CelestiaOrg veya @AvailProject gibi DA L1 zincirleri arasındaki karşılaştırmaya odaklanmak istiyoruz.

10/ Ethereum tabanlı ve DA için Celestia (aka Celestium) kullanan bir toplama olduğunu varsayalım

Bu nedenle, Ethereum üzerindeki L2 sözleşmeleri, her zamanki gibi geçerlilik kanıtını veya dolandırıcılık kanıtını doğrular ve DA, Celestia tarafından sağlanır.

11/ @CelestiaOrg ve @AvailProject'te akıllı sözleşmeler veya hesaplamalar yoktur, yalnızca verilerin kullanılabilir olması garanti edilir

12/ Ama daha yakından bakalım

@CelestiaOrg'da, tx verileri L2 sıralayıcı tarafından Celestia'ya yayınlanır, Celestia doğrulayıcı, DA kanıtının Merkle kökünü imzalar, ardından doğrulama ve depolama için Ethereum'daki DA köprü sözleşmesine gönderilir

13/ DA'yı zincir üzerinde depolamaya kıyasla bu, güçlü bir DA garantisine sahip olmanın maliyetini büyük ölçüde azaltırken aynı zamanda (merkezi bir DAC yerine) Celestia'dan güvenlik garantileri sağlar.

14/ Maliyetin düşürülmesi, tüm toplama alanındaki oyunun kurallarını değiştirecektir, çünkü verileri Ethereum L1'e yayınlayarak oluşturulan çağrı verilerinin maliyeti, toplama maliyetinin %80-90'ını oluşturur.

Calldata maliyeti hakkında daha fazla bilgi için aşağıdaki gönderiye göz atın 👇

15/ Ama #Celestia'da ne oldu?

@CelestiaOrg'a gönderilen veri damlaları (temelde ham veri olarak) P2P ağı aracılığıyla yayılır ve veri bloğu hakkında fikir birliğine Tendermint mutabakatı kullanılarak ulaşılır

16/ Her #Celestia tam düğümü, tüm veri bloğunu indirmelidir. Bu, veri kullanılabilirliğini sağlamak için Veri Kullanılabilirliği Örneklemesini (DAS) kullanabilen hafif düğümler için farklıdır.

17/ DAS ve ışık düğümleri hakkında daha fazla bilgi için lütfen aşağıdaki gönderiyi kontrol edin

18/ DAS'a bu ileti dizisinde daha sonra geri döneceğiz, ancak şimdilik odak noktası tam düğümler üzerinde

Yayına ve veri blobları üzerinde fikir birliğine dayanan L1 tarzında davranmaya devam eden @CelestiaOrg'a geri dönelim.

19/ Bu nedenle, ağın tüm düğümlerine yüksek talepler getirir (128 MB/s indirme ve 12,5 MB/s yükleme).

Yine de, @CelestiaOrg başlangıçta, tam düğüm gereksinimleri göz önüne alındığında düşük görünen orta düzeyde bir iş hacmini (1,4 MB/sn) hedefliyordu.

20/ Ancak ağ, hafif düğümler ekleyerek verimi ölçeklendirebilir. Işık düğümleri ne kadar çok veri örnekliyorsa, blok boyutu o kadar büyük olabilir, güvenlik ve ademi merkeziyet sağlama koşulu altında olabilir.

21/ Öte yandan, @eigenlayer'ın farklı bir mimarisi var, kendine ait bir fikir birliği yok ve uçtan uca ağ yok

Peki bu nasıl çalışıyor?

İlk olarak, EigenDA düğümü, @eigenlayer sözleşmesinde $ETH'yi yeniden tahsis etmelidir. Bu nedenle, #EigenDA düğümleri, Ethereum doğrulayıcılarının bir alt kümesidir.

22/ Veri blobunu aldıktan sonra, bir DA alıcısı (dağıtıcı olarak da bilinen toplama gibi) bunu bir silme koduyla kodlar ve bir KZG taahhüdü oluşturur…

23/… kanıt boyutunun silme kodunun fazlalık oranına bağlı olduğu ve KZG'nin #EigenDA akıllı sözleşmesine olan taahhüdünü yayınladığı yer

24/ Dağıtıcı tarafından #EigenDA düğümlerine dağıtılan kodlanmış KZG taahhüdü

KZG taahhüdünü aldıktan sonra, bu düğümler bunu EigenDA akıllı sözleşmesinin KZG taahhüdü ile karşılaştırır ve onaylandıktan sonra kanıtı imzalar.

25/ Bundan sonra dağıtıcı bu imzaları tek tek toplar, toplu bir imza oluşturur ve bunu #EigenDA akıllı sözleşmesine yayınlar ve akıllı sözleşme imzayı doğrular

26/ Ancak #EigenDA düğümü, bu iş akışında kodlanmış veri blobunu depoladığını iddia eden bir kanıtı imzalarsa ve EigenDA akıllı sözleşmesi yalnızca toplu imzanın doğruluğunu onaylarsa, EigenDA düğümünün verileri gerçekten depoladığından nasıl emin olabiliriz?

27/ #EigenDA, bunu başarmak için bir emanet kanıtı yöntemi kullanıyor

Ama bir adım geri atalım ve önemli hale geldiği bu sahneye bakalım.

28/ Bazı tembel doğrulayıcıların kendilerine atanan görevleri yapmadığını varsayalım (örneğin, verilerin mevcut olduğundan emin olmak)

Bunun yerine, işi yapmış gibi davranırlar ve nihai sonuca imza atarlar (mevcut olmadığında veri kullanılabilirliğini yanlış bir şekilde bildirirler).

29/ Kavramsal olarak, velayet kanıtı, dolandırıcılık kanıtı gibidir:

Akıllı sözleşme tarafından doğrulanacak olan #EigenDA akıllı sözleşmesine herkes bir kanıt (doğrulayıcı tembel) sunabilir

29/ Tembel doğrulayıcı, doğrulama başarılı olursa kesilir (çünkü bu nesnel olarak atfedilebilir bir hatadır)

30/ Konsensüs ne olacak?

@CelestiaOrg, tek yuva kesinliği olan mutabakat protokolü olarak Tendermint'i kullanır. Yani, bir blok #Celestia mutabakatını geçtiğinde, iş biter. Bu, kesinliğin temel olarak blok süresi (15 saniye) kadar hızlı olduğu anlamına gelir.

31/ @AvailProject kesinlik elde etmek için protokol bileşimini kullanır. BABE, olasılıksal kesinliğe sahip bir blok üretim mekanizmasıdır ve GRANDPA, nihai bir cihazdır. GRANDPA blokları tek bir yuvada tamamlayabilirken, aynı zamanda bir turda birden fazla bloğu da tamamlayabilir.

32/ @eigenlayer, Ethereum üzerinde bir dizi akıllı sözleşme olduğundan, veri kullanılabilirliğini kanıtlamak için toplu sözleşmeye iletilmesi gereken veriler için Ethereum ile aynı sonuçlandırma süresini (12 - 15 dakika) devralır.

33/ Bununla birlikte, toplama @eigenlayer kullanıyorsa, kullanılan mutabakat mekanizmasına vb. bağlı olarak daha hızlı yapılabilir.

Ek olarak, @eigenlayer'ın yeniden paylaşım doğrulayıcıları tarafından güvence altına alınan ara katman yazılımı, örneğin EigenSettle, kesinlik ön onayına olanak tanıyan güçlü ekonomik güvenlik garantileri sağlayabilir. Ancak kesin kesinlik garantileri hala Ethereum L1'den gelmektedir.

34/ Veri Kullanılabilirliği Örnekleme Kavramlarını Yeniden Ziyaret Etme Zamanı

Çoğu blok zincirinde, düğümlerin verilerin kullanılabilirliğini doğrulamak için tüm işlem verilerini indirmesi gerekir. Bunun yarattığı sorun, blok boyutu arttıkça doğrulanması gereken veri düğümlerinin sayısının da artmasıdır.

35/ Veri Kullanılabilirliği Örneklemesi (DAS), hafif düğümlerin blok verilerinin yalnızca küçük bir bölümünü indirerek veri kullanılabilirliğini doğrulamasına izin veren bir tekniktir.

36/ Bu, geçersiz blokları (yalnızca DA ve konsensüs) doğrulayabilmeleri için hafif düğümlere güvenlik sağlar ve blok zincirinin, düğüm gereksinimlerini artırmadan veri kullanılabilirliğini ölçeklendirmesine izin verir.

37/ DAS, en az bir dürüst tam düğüm ve yeterli sayıda hafif istemci gerektirir

38/ Ancak hafif düğümlerin güvenliği nasıl sağlanır?

Geleneksel hafif istemciler, yalnızca blok başlıklarını doğruladıkları için tam düğümlere kıyasla daha zayıf güvenlik varsayımlarına sahiptir.

Bu nedenle, hafif istemciler, blok üreticilerinin dürüst olmayan bir çoğunluğu tarafından geçersiz bir bloğun üretilip üretilmediğini tespit edemez.

39/ Veri kullanılabilirliği örneklemesine sahip hafif düğümler güvenlik açısından yükseltilir, çünkü DA katmanı yalnızca fikir birliği ve veri kullanılabilirliği yaparsa geçersiz blokların üretilip üretilmediğini doğrulayabilirler.

40/ Hem @CelestiaOrg hem de @AvailProject veri kullanılabilirliği örneklemesine sahip olacak, böylece hafif düğümleri güveni en aza indirilmiş güvenliğe sahip olacak.

41/ Bu, Ethereum ve @eigenlayer'dan farklı

#EIP4844 ile Ethereum'un veri kullanılabilirliği örneklemesi yoktur, bu nedenle hafif istemcileri, güveni en aza indirilmiş güvenliğe sahip olmayacaktır.

42/ Ethereum da kendi akıllı sözleşme ortamına sahip olduğu için, hafif müşterilerin de çoğu dürüstlük varsayımına güvenmek yerine yürütmeyi (sahtekarlık veya geçerlilik kanıtı yoluyla) doğrulaması gerekir.

43/ @eigenlayer (bir DAS olmadığı sürece) hafif istemci, eğer destekleniyorsa, yeniden paylaşım yapan düğümlerin dürüst bir çoğunluğuna güvenecektir.

Bu nedenle, #EigenDA'nın güvenliği temel olarak Ethereum doğrulayıcı setine dayanır, Ethereum slashing primitifini devralır ve DA'nın ekonomik güvenliğini sağlar.

44/ Yani #EigenDA'ya daha fazla paydaş katılımı daha fazla güvenlik anlamına geliyor. Düğüm gereksinimlerinin azaltılması, daha iyi yerelleşmeye de katkıda bulunur

45/ Silme kodlaması, veri kullanılabilirliği örneklemesini sağlayan önemli bir mekanizmadır. Silme kodlaması, verilerin ek kopyalarını oluşturarak blokları genişletir. Ek veriler, örnekleme işlemi için daha güçlü güvenlik garantileri sağlayarak fazlalık oluşturur

46/ Ancak, düğümler ağı bozmak için verileri yanlış kodlamaya çalışabilir. Bu saldırıya karşı savunma yapmak için, düğümlerin kodlamanın doğru olduğunu doğrulamak için bir yola ihtiyacı vardır - kanıtların devreye girdiği yer burasıdır.

47/ Ethereum, @eigenlayer ve @AvailProject, blokların doğru şekilde kodlandığından emin olmak için bir geçerlilik kanıtı şeması kullanır. Fikir, zk toplaması tarafından kullanılan geçerlilik kanıtlarına benzer. @eigenlayer bunu daha önce bu başlıkta tartıştı

48/ Bir blok oluşturulduğunda, doğrulayıcı, bloğun doğru şekilde kodlandığını kanıtlamak için KZG kanıtını kullanarak düğüm tarafından doğrulanan verilere bir taahhütte bulunmalıdır.

49/ KZG ispatları için taahhütler oluşturmak, blok üreticileri için daha fazla hesaplama yükü gerektirse de, bloklar küçük olduğunda, taahhütler oluşturmak çok fazla ek yük getirmez. Ancak bu değişti...

50/… bloklar büyüdükçe, KZG ispat taahhüdünün yükü çok daha fazladır

Bu nedenle, bu taahhütleri oluşturmaktan sorumlu düğüm tipi daha yüksek donanım gereksinimlerine sahip olabilir.

51/ Öte yandan @CelestiaOrg, silme kodlaması için dolandırıcılık kanıtları uygular. Bu nedenle, #Celestia düğümlerinin blokların doğru şekilde kodlanıp kodlanmadığını kontrol etmesi gerekmez. doğru olduğunu varsayıyorlar

52/ Avantajı, blok üreticilerinin silme kodlu taahhütler üretme gibi pahalı işleri yapmasına gerek kalmamasıdır.

Ancak bir değiş tokuş vardır, çünkü hafif düğümlerin bir bloğun doğru şekilde kodlandığını varsaymadan ve kendi görüşlerine göre tamamlamadan önce kısa bir süre beklemeleri gerekir.

53/ Dolandırıcılığa dayanıklı ve geçerliliğe dayanıklı kodlama şemaları arasındaki temel fark, taahhüt oluşturmak için düğüm ek yükü ile hafif düğümler için gecikme süresi arasındaki değiş tokuştur.

54/ Bu tablo karşılaştırmayı güzel bir şekilde özetlemektedir.

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.
  • Reward
  • Comment
  • Share
Comment
0/400
No comments
  • Pin