! [DA Ölçeklenebilirliği: Avail'in Mevcut Durumu] (https://img-cdn.gateio.im/webp-social/moments-7f230462a9-d4e2f4e2b4-dd1a6f-cd5cc0.webp)
Kullanıcılar Avail'i zincir tasarımlarına entegre etmeye başladıkça, genellikle şu soru ortaya çıkıyor: "Avail kaç işlem gerçekleştirebilir?" Bu yazıda, iki zincirin mevcut mimarisine dayalı olarak Ethereum ve Avail'in verimini karşılaştıracağız.
Bu, Avail'in mevcut performansını ve yakın ve uzun vadede ölçeklendirme yeteneğini tartışacak olan Avail ölçeklenebilirliği serisinin ilkidir.
Ethereum'a Karşı Boşuna
Ethereum'un blokları 1.875 MB'a kadar veri tutabilir ve yaklaşık 13 saniyelik bir blok süresine sahip olabilir. Ancak, Ethereum'un blokları genellikle doldurulmaz. Hemen hemen her blok, gaz limitine ulaştığı için verinin üst sınırına ulaşmayacaktır, çünkü hem yürütme hem de uzlaşma gaz tüketir. Sonuç olarak, her blokta depolanan veri miktarı değişkendir.
Yürütme, ödeme ve veri kullanılabilirliğini aynı blokta birleştirme ihtiyacı, tek bir blok zinciri mimarisinde merkezi bir sorundur. L2 rollup'ları, yürütme işlemlerinin tek bir zincir üzerinde gerçekleştirilmesine izin vererek modüler blok zincirleri için hareketi başlattı ve zincirin blokları yürütmeye adandı. Avail, veri kullanılabilirliğini de ayıran modüler bir tasarım benimseyerek bir adım daha ileri gidiyor ve bir zincirin bloklarının veri kullanılabilirliğine ayrılmasına izin veriyor.
! [DA Ölçeklenebilirliği: Avail'in Mevcut Durumu] (https://img-cdn.gateio.im/webp-social/moments-7f230462a9-60a64e927d-dd1a6f-cd5cc0.webp)
Şu anda, Avail'in blok süresi 20 saniyedir ve her blok yaklaşık 2 MB veri tutabilir. Ortalama işlem boyutunun 250 bayt olduğunu varsayarsak, her bir Avail bloğu bugün yaklaşık 8.400 işlem tutabilir (saniyede 420 işlem).
Dahası, Avail blokları her zaman depolama sınırına kadar doldurabilir ve gerektiğinde boyutu artırabilir. Gerektiğinde blok başına işlem sayısını 500.000'in (saniyede 25.000 işlem) üzerine çıkarmak için hızlı bir şekilde ayarlanabilen bir dizi kaldıracımız var.
Verimi artırabilir miyiz?
Verimi (özellikle saniye başına işlem sayısını) artırmak için, zincirin mimarlarının blok boyutunu artırması veya blok süresini azaltması gerekir.
Zincire eklenmek için her bloğun taahhütler oluşturması, kanıtlar oluşturması, bunları yayması ve diğer tüm düğümlerin bu kanıtları doğrulamasını sağlaması gerekir. Bu adımlar her zaman zaman alır, bu da blokların oluşturulması ve onaylanması için geçen süreye doğal bir üst sınır koyar.
Bu nedenle, blok süresini basitçe bir saniyeye indiremeyiz. Bu, taahhütler oluşturmak, kanıtlar oluşturmak ve bu parçaları ağdaki tüm katılımcılara yaymak için yeterli zamana sahip değildir. Teorik bir saniyelik blok süresinde, her ağ katılımcısı bir anda taahhütler ve kanıtlar üretebilen en güçlü makineyi çalıştırsa bile, darboğaz verilerin yayılmasında yatmaktadır. İnternet hızı sınırlamaları nedeniyle ağ, tüm blok düğümlerini yeterince hızlı bir şekilde bildiremez. Bu nedenle, blok süresinin, fikir birliğine varıldıktan sonra verilerin ağa dağıtılmasına izin verecek kadar yüksek olduğundan emin olmalıyız.
Tersine, blok boyutunu artırarak, yani her blokta içerebileceğimiz veri miktarını artırarak verimi artırmak da mümkündür.
Mevcut Mimari: Zincire bir blok ekleyin
İlk olarak, zincire bir blok eklemek için gereken adımlara bakalım. Her bloğu zincire eklemek için gereken üç ana adım vardır. Bu, bir blok oluşturmak, yaymak ve doğrulamak için geçen süreyi içerir.
! [DA Ölçeklenebilirliği: Avail'in Mevcut Durumu] (https://img-cdn.gateio.im/webp-social/moments-7f230462a9-8d735187bc-dd1a6f-cd5cc0.webp)
1. Blok oluşturma
Bu adım, Avail işlemlerini toplamak ve sıralamak, taahhütler oluşturmak ve veri matrisini ölçeklendirmek (silme kodlaması) için gereken süreyi içerir.
Blok oluşturma, bir blok oluşturmak için gereken süreyi ölçer, çünkü bu her zaman en azından biraz zaman alacaktır. Bu nedenle, sadece en iyi durumdaki zamanı değil, aynı zamanda farklı makinelerdeki ortalama durumu ve en kötü durumdaki zamanı da hesaba katmalıyız.
Yeni blokların oluşturulmasına katılabilecek en zayıf makine, ortalama olarak performans sınırına ulaşan makinedir. Tüm yavaş makineler, daha hızlı makinelere yetişemedikleri için sonunda geride kalacaklar.
2. Yayılma gecikmesi
Yayılma gecikmesi, bir bloğun bir üreticiden doğrulayıcıya ve eşler arası bir ağa yayılması için geçen sürenin bir ölçüsüdür.
Şu anda Avail'in blok boyutu 2 MB'dir. Mevcut 20 saniyelik blok süresi sınırı içinde, böyle bir blok boyutu yayılabilir. Daha büyük blok boyutları, yayılmayı zorlaştırır.
Örneğin, Avail'i 128 MB'lık bir bloğu destekleyecek şekilde artırırsak, hesaplama ölçeklendirilebilir (yaklaşık 7 saniye). Ancak darboğaz, bu blokları ağa göndermek ve indirmek için gereken süre haline gelir.
Eşler arası bir ağ üzerinden 5 saniyede dünyaya 128 MB'lık bir blok göndermek, şu anda ulaşılabilir olanın sınırı olabilir.
128 MB sınırının veri kullanılabilirliği veya taahhüt senaryomuzla hiçbir ilgisi yoktur, daha çok iletişim bant genişliği sınırlamaları meselesidir.
Yayılma gecikmesini hesaba katma ihtiyacı, bize Avail'in mevcut teorik blok boyutu sınırını verir.
3. Blok doğrulama
Katılımcı doğrulayıcılar, bir kez yayıldıktan sonra, blok öneren tarafından kendilerine sağlanan bloklara güvenmekle kalmaz, aynı zamanda üretilen bloğun gerçekten üretici tarafından talep edilen verileri içerdiğini doğrulamaları gerekir.
Bu üç adım arasında belli bir gerilim var. Tüm doğrulayıcıları güçlü makineler haline getirebilir ve aynı veri merkezinde mükemmel bir ağ ile sıkı bir şekilde birbirine bağlanabiliriz - bu, üretim ve doğrulama süresini azaltacak ve çok daha fazla veri yaymamıza izin verecektir. Ancak, farklı katılımcı türlerine sahip merkezi olmayan, çeşitli bir ağa sahip olmak istediğimiz için bu ideal bir yaklaşım değildir.
Bunun yerine, verimdeki artış, Avail zincirine blok eklemek için gereken adımların ve hangi adımların optimize edilebileceğinin anlaşılmasıyla sağlanacaktır.
! [DA Ölçeklenebilirliği: Avail'in Mevcut Durumu] (https://img-cdn.gateio.im/webp-social/moments-7f230462a9-1d534dd1ad-dd1a6f-cd5cc0.webp)
Şu anda, Avail kullanan doğrulayıcılar tüm bloğu alır ve bloğu doğrulamak için teklif sahibi tarafından oluşturulan tüm taahhütleri kopyalar. Bu, blok üreticilerinin ve tüm doğrulayıcıların yukarıdaki grafikteki adımların her birini gerçekleştirmesi gerektiği anlamına gelir.
Tek bir blok zincirinde, her doğrulayıcının tüm bloğu yeniden oluşturması varsayılan uygulamadır. Ancak, işlemlerin yürütülmediği Avary gibi bir zincirde bu yeniden oluşturma gerekli değildir. Bu nedenle, Avail'i optimize edebilmemizin bir yolu, doğrulayıcıların blokları yeniden yapılandırmak yerine örnekleme yoluyla kendi veri kullanılabilirliği garantilerini elde etmelerine izin vermektir. Bu, doğrulayıcılar için tüm taahhütleri tekrarlamalarını gerektirmekten daha az kaynak yoğundur. Gelecekteki bir makalede bununla ilgili daha fazla bilgi.
Araştırmacı veri kullanılabilirliği örneklemesi nasıl çalışır?
Avail'de, hafif istemciler verilerin kullanılabilirliğini doğrulamak için üç temel araç kullanır: örnekler, taahhütler ve kanıtlar.
Şu anda hafif istemciler, Avail ağından belirli bir hücrenin değerini ve ilişkili geçerlilik kanıtını talep eden örnek işlemler gerçekleştirmektedir. Ne kadar çok örnek alırlarsa, tüm verilerin mevcut olduğundan o kadar emin olurlar.
Taahhütler, blok teklif edenler tarafından oluşturulur ve bir Avail bloğundaki tüm veri satırını özetler. (İpucu: Bu, bu serinin ilerleyen bölümlerinde optimize edeceğimiz adımdır.) ）
Ağdaki her hücre bir kanıt oluşturur. Hafif istemciler, kendilerine sağlanan hücrelerin değerlerinin doğru olduğunu doğrulamak için onayları ve vaatleri kullanır.
Bu araçları kullanarak, hafif istemci daha sonra üç adım gerçekleştirir.
Karar: Gerekli kullanılabilirlik güveni, hafif istemci yürütmesi için örnek sayısını belirler. %99,95'ten fazla kullanılabilirlik garantisi elde etmek için çok fazla örneğe (8-30 örnek) ihtiyaç duymazlar.
İndir: Hafif istemci daha sonra bu örnekleri ve bunlarla ilişkili kanıtları talep eder ve bunları ağdan indirir (tam düğüm veya başka bir hafif istemci).
Doğrulama: Blok başlığındaki vaade bakarlar (hafif istemciler için her zaman erişilebilir) ve her hücrenin kanıtını vaade göre doğrularlar.
Yalnızca bununla, hafif istemciler, bloğun içeriğinin çoğunu indirmek zorunda kalmadan bir bloktaki tüm verilerin kullanılabilirliğini onaylayabilir. Hafif istemciler tarafından atılan diğer adımlar da Avail'in güvenliğine katkıda bulunur, ancak burada listelenmemiştir. Örneğin, hafif istemciler, ihtiyaç duymaları durumunda indirdikleri örnekleri ve provaları diğer hafif istemcilerle paylaşabilirler. Ancak bu, hafif istemcilerin veri kullanılabilirliğini onaylama prosedürüdür!
Bu serinin ikinci bölümünde, kısa vadede Avail verimini artırmanın yollarını keşfedeceğiz. Avail'in önümüzdeki yıl herhangi bir ağın ihtiyaçlarını karşılayabileceğine neden inandığımızı ve önümüzdeki yılların zorluklarını karşılamak için ağı nasıl geliştirebileceğimizi açıklayacağız.
View Original
This page may contain third-party content, which is provided for information purposes only (not representations/warranties) and should not be considered as an endorsement of its views by Gate, nor as financial or professional advice. See Disclaimer for details.
DA ölçeklenebilirliği: Avail'in mevcut durumu
! [DA Ölçeklenebilirliği: Avail'in Mevcut Durumu] (https://img-cdn.gateio.im/webp-social/moments-7f230462a9-d4e2f4e2b4-dd1a6f-cd5cc0.webp)
Kullanıcılar Avail'i zincir tasarımlarına entegre etmeye başladıkça, genellikle şu soru ortaya çıkıyor: "Avail kaç işlem gerçekleştirebilir?" Bu yazıda, iki zincirin mevcut mimarisine dayalı olarak Ethereum ve Avail'in verimini karşılaştıracağız.
Bu, Avail'in mevcut performansını ve yakın ve uzun vadede ölçeklendirme yeteneğini tartışacak olan Avail ölçeklenebilirliği serisinin ilkidir.
Ethereum'a Karşı Boşuna
Ethereum'un blokları 1.875 MB'a kadar veri tutabilir ve yaklaşık 13 saniyelik bir blok süresine sahip olabilir. Ancak, Ethereum'un blokları genellikle doldurulmaz. Hemen hemen her blok, gaz limitine ulaştığı için verinin üst sınırına ulaşmayacaktır, çünkü hem yürütme hem de uzlaşma gaz tüketir. Sonuç olarak, her blokta depolanan veri miktarı değişkendir.
Yürütme, ödeme ve veri kullanılabilirliğini aynı blokta birleştirme ihtiyacı, tek bir blok zinciri mimarisinde merkezi bir sorundur. L2 rollup'ları, yürütme işlemlerinin tek bir zincir üzerinde gerçekleştirilmesine izin vererek modüler blok zincirleri için hareketi başlattı ve zincirin blokları yürütmeye adandı. Avail, veri kullanılabilirliğini de ayıran modüler bir tasarım benimseyerek bir adım daha ileri gidiyor ve bir zincirin bloklarının veri kullanılabilirliğine ayrılmasına izin veriyor.
! [DA Ölçeklenebilirliği: Avail'in Mevcut Durumu] (https://img-cdn.gateio.im/webp-social/moments-7f230462a9-60a64e927d-dd1a6f-cd5cc0.webp)
Şu anda, Avail'in blok süresi 20 saniyedir ve her blok yaklaşık 2 MB veri tutabilir. Ortalama işlem boyutunun 250 bayt olduğunu varsayarsak, her bir Avail bloğu bugün yaklaşık 8.400 işlem tutabilir (saniyede 420 işlem).
Dahası, Avail blokları her zaman depolama sınırına kadar doldurabilir ve gerektiğinde boyutu artırabilir. Gerektiğinde blok başına işlem sayısını 500.000'in (saniyede 25.000 işlem) üzerine çıkarmak için hızlı bir şekilde ayarlanabilen bir dizi kaldıracımız var.
Verimi artırabilir miyiz?
Verimi (özellikle saniye başına işlem sayısını) artırmak için, zincirin mimarlarının blok boyutunu artırması veya blok süresini azaltması gerekir.
Zincire eklenmek için her bloğun taahhütler oluşturması, kanıtlar oluşturması, bunları yayması ve diğer tüm düğümlerin bu kanıtları doğrulamasını sağlaması gerekir. Bu adımlar her zaman zaman alır, bu da blokların oluşturulması ve onaylanması için geçen süreye doğal bir üst sınır koyar.
Bu nedenle, blok süresini basitçe bir saniyeye indiremeyiz. Bu, taahhütler oluşturmak, kanıtlar oluşturmak ve bu parçaları ağdaki tüm katılımcılara yaymak için yeterli zamana sahip değildir. Teorik bir saniyelik blok süresinde, her ağ katılımcısı bir anda taahhütler ve kanıtlar üretebilen en güçlü makineyi çalıştırsa bile, darboğaz verilerin yayılmasında yatmaktadır. İnternet hızı sınırlamaları nedeniyle ağ, tüm blok düğümlerini yeterince hızlı bir şekilde bildiremez. Bu nedenle, blok süresinin, fikir birliğine varıldıktan sonra verilerin ağa dağıtılmasına izin verecek kadar yüksek olduğundan emin olmalıyız.
Tersine, blok boyutunu artırarak, yani her blokta içerebileceğimiz veri miktarını artırarak verimi artırmak da mümkündür.
Mevcut Mimari: Zincire bir blok ekleyin
İlk olarak, zincire bir blok eklemek için gereken adımlara bakalım. Her bloğu zincire eklemek için gereken üç ana adım vardır. Bu, bir blok oluşturmak, yaymak ve doğrulamak için geçen süreyi içerir.
! [DA Ölçeklenebilirliği: Avail'in Mevcut Durumu] (https://img-cdn.gateio.im/webp-social/moments-7f230462a9-8d735187bc-dd1a6f-cd5cc0.webp)
1. Blok oluşturma
Bu adım, Avail işlemlerini toplamak ve sıralamak, taahhütler oluşturmak ve veri matrisini ölçeklendirmek (silme kodlaması) için gereken süreyi içerir.
Blok oluşturma, bir blok oluşturmak için gereken süreyi ölçer, çünkü bu her zaman en azından biraz zaman alacaktır. Bu nedenle, sadece en iyi durumdaki zamanı değil, aynı zamanda farklı makinelerdeki ortalama durumu ve en kötü durumdaki zamanı da hesaba katmalıyız.
Yeni blokların oluşturulmasına katılabilecek en zayıf makine, ortalama olarak performans sınırına ulaşan makinedir. Tüm yavaş makineler, daha hızlı makinelere yetişemedikleri için sonunda geride kalacaklar.
2. Yayılma gecikmesi
Yayılma gecikmesi, bir bloğun bir üreticiden doğrulayıcıya ve eşler arası bir ağa yayılması için geçen sürenin bir ölçüsüdür.
Şu anda Avail'in blok boyutu 2 MB'dir. Mevcut 20 saniyelik blok süresi sınırı içinde, böyle bir blok boyutu yayılabilir. Daha büyük blok boyutları, yayılmayı zorlaştırır.
Örneğin, Avail'i 128 MB'lık bir bloğu destekleyecek şekilde artırırsak, hesaplama ölçeklendirilebilir (yaklaşık 7 saniye). Ancak darboğaz, bu blokları ağa göndermek ve indirmek için gereken süre haline gelir.
Eşler arası bir ağ üzerinden 5 saniyede dünyaya 128 MB'lık bir blok göndermek, şu anda ulaşılabilir olanın sınırı olabilir.
128 MB sınırının veri kullanılabilirliği veya taahhüt senaryomuzla hiçbir ilgisi yoktur, daha çok iletişim bant genişliği sınırlamaları meselesidir.
Yayılma gecikmesini hesaba katma ihtiyacı, bize Avail'in mevcut teorik blok boyutu sınırını verir.
3. Blok doğrulama
Katılımcı doğrulayıcılar, bir kez yayıldıktan sonra, blok öneren tarafından kendilerine sağlanan bloklara güvenmekle kalmaz, aynı zamanda üretilen bloğun gerçekten üretici tarafından talep edilen verileri içerdiğini doğrulamaları gerekir.
Bu üç adım arasında belli bir gerilim var. Tüm doğrulayıcıları güçlü makineler haline getirebilir ve aynı veri merkezinde mükemmel bir ağ ile sıkı bir şekilde birbirine bağlanabiliriz - bu, üretim ve doğrulama süresini azaltacak ve çok daha fazla veri yaymamıza izin verecektir. Ancak, farklı katılımcı türlerine sahip merkezi olmayan, çeşitli bir ağa sahip olmak istediğimiz için bu ideal bir yaklaşım değildir.
Bunun yerine, verimdeki artış, Avail zincirine blok eklemek için gereken adımların ve hangi adımların optimize edilebileceğinin anlaşılmasıyla sağlanacaktır.
! [DA Ölçeklenebilirliği: Avail'in Mevcut Durumu] (https://img-cdn.gateio.im/webp-social/moments-7f230462a9-1d534dd1ad-dd1a6f-cd5cc0.webp)
Şu anda, Avail kullanan doğrulayıcılar tüm bloğu alır ve bloğu doğrulamak için teklif sahibi tarafından oluşturulan tüm taahhütleri kopyalar. Bu, blok üreticilerinin ve tüm doğrulayıcıların yukarıdaki grafikteki adımların her birini gerçekleştirmesi gerektiği anlamına gelir.
Tek bir blok zincirinde, her doğrulayıcının tüm bloğu yeniden oluşturması varsayılan uygulamadır. Ancak, işlemlerin yürütülmediği Avary gibi bir zincirde bu yeniden oluşturma gerekli değildir. Bu nedenle, Avail'i optimize edebilmemizin bir yolu, doğrulayıcıların blokları yeniden yapılandırmak yerine örnekleme yoluyla kendi veri kullanılabilirliği garantilerini elde etmelerine izin vermektir. Bu, doğrulayıcılar için tüm taahhütleri tekrarlamalarını gerektirmekten daha az kaynak yoğundur. Gelecekteki bir makalede bununla ilgili daha fazla bilgi.
Araştırmacı veri kullanılabilirliği örneklemesi nasıl çalışır?
Avail'de, hafif istemciler verilerin kullanılabilirliğini doğrulamak için üç temel araç kullanır: örnekler, taahhütler ve kanıtlar.
Bu araçları kullanarak, hafif istemci daha sonra üç adım gerçekleştirir.
Yalnızca bununla, hafif istemciler, bloğun içeriğinin çoğunu indirmek zorunda kalmadan bir bloktaki tüm verilerin kullanılabilirliğini onaylayabilir. Hafif istemciler tarafından atılan diğer adımlar da Avail'in güvenliğine katkıda bulunur, ancak burada listelenmemiştir. Örneğin, hafif istemciler, ihtiyaç duymaları durumunda indirdikleri örnekleri ve provaları diğer hafif istemcilerle paylaşabilirler. Ancak bu, hafif istemcilerin veri kullanılabilirliğini onaylama prosedürüdür!
Bu serinin ikinci bölümünde, kısa vadede Avail verimini artırmanın yollarını keşfedeceğiz. Avail'in önümüzdeki yıl herhangi bir ağın ihtiyaçlarını karşılayabileceğine neden inandığımızı ve önümüzdeki yılların zorluklarını karşılamak için ağı nasıl geliştirebileceğimizi açıklayacağız.