Orjinal Metin Başlığı: "Polygon'un Yeni Ürünü Avail'i Anlama, Genişletilebilir Veri Erişilebilirlik Katmanı"
Orjinal Yazar: Polygon
Orjinal Kaynak: DeFi Avenue
Avail—Gelecekteki blok zincirlerin nasıl çalıştığına dair yepyeni bir bakış açısının önemli bir parçasıdır. Avail, veri erişilebilirliğine odaklanan genel bir, genişletilebilir bir blok zinciridir ve bağımsız zincirler, yan zincirler ve off-chain genişletme çözümleri için uygundur.
Avail, son derece güvenli matematiksel öncül kullanarak güçlü bir veri erişilebilirlik katmanı sağlar—veri erişilebilirliği denetimi için kritik yeniliklere sahip Reed-Solomon kodları kullanarak. Kate polinom bağlılığı kullanarak ikinci boyutlu bir veri erişilebilirlik planı oluşturur, hile kanıtlaması gerektirmez, dürüst çoğunluk varsayımına ihtiyaç duymaz ve veri erişilebilirliğine güven duymak için dürüst tam düğüme dayanmaz.
Avail, farklı yürütme ortamlarının kullanabileceği genel veri erişilebilirlik katmanı sağlar, örneğin bağımsız zincirler, yan zincirler ve off-chain genişletme çözümleri. Uzun vadede, bunun yürütme ortamında ve nihai uygulamada çeşitli deneylere olanak tanıyacağı ve ekip ve proje tarafından kendi güvenliğini başlatmadan büyük ölçüde destekleneceği görülmektedir. Polygon SDK, Cosmos SDK veya Substrate ile oluşturulan bir zincir, bu amaçla Avail'i kullanmaktan faydalanabilir.
Avail, işlem yürütme ve doğruluğunu konsensüs katmanından ayrıştırır, bu nedenle konsensüs yalnızca a) işlemleri sıralamak ve b) veri erişilebilirliğini garanti etmekle yükümlüdür.
· Kendi doğrulayıcı kümesini oluşturmadan ve yönetmeden doğrulayıcı güvenliğini yönlendirmek için işlem veri erişilebilirliğini garanti etmek için bağımsız bir zincir veya yan zincir ile herhangi bir yürütme ortamını etkinleştirmek.
· Avail'i bir alt katman veri erişilebilirlik katmanı olarak kullanarak Validium gibi ikinci katman (Layer 2) çözümleri, daha yüksek ölçeklenebilirlik ve işlem hacmi sunar.
2020 sonundan beri Avail üzerinde gizli araştırma yapmaktayız ve şu anda Devnet aşamasındadır. Test ağı geliştirme aşamasındadır. Sorunlar, mimari ve çözümler hakkında daha fazla ayrıntı, kod deposuna referanslar da dahil olmak üzere belgelere bakılabilir.
Günümüzde Ethereum'a benzer ekosistemde, genellikle üç tür düğüm bulunmaktadır:
· Doğrulayıcı Düğüm
· Tam Düğüm
· Hafif İstemci
Doğrulayıcı bir bloğu blok zincirine ekleyen bir düğümdür. Bu düğüm, işlem havuzundan işlemleri toplar, bunları yürütür ve bloğu oluşturmadan önce ağ üzerinde yayınlar. Blok küçük bir blok başlığı içerir; bu başlık, bloktaki işlemlerle ilgili özet ve meta verileri içerir. Ağın tam düğümleri bloğu alır ve doğruluğunu doğrulamak için bloktaki işlemleri yeniden yürütür. Hafif istemci sadece gerektiğinde komşu tam düğümlerden blok başlığı ve işlem ayrıntılarını alır. Blok başlığındaki meta veriler, hafif istemcinin aldığı işlem ayrıntılarının doğruluğunu doğrulamasını sağlar.
Bu mimari çok güvenlidir ve geniş ölçüde benimsenmiştir. Ancak ciddi uygulama kısıtlamaları bulunmaktadır. Hafif istemciler tüm bloğu indirmediğinden, verileri olmayan blokları kabul etmeye yönlendirilebilirler. Bir blok üreticisi kötü niyetli işlemleri bir bloğa ekleyebilir ve bunun tüm içeriğini ağa açıklamayabilir. Bu veri erişilebilirlik sorununa veri erişilebilirlik sorunu denir ve hafif istemcilere ciddi bir tehdit oluşturur. Daha da kötüsü, veri eksikliği geriye dönük bir hatadır ve bu da bize veri kaybı durumunda hafif istemcilere inandırıcı bir şekilde sahte kanıt sunmamızı engeller.

Var Olan Blockchain Polygon Karşılaştırması
Karşılaştırıldığında, Avail bu sorunu çözmek için farklı bir yaklaşım benimser—uygulama durumunu doğrulamaz, bunun yerine yayınlanan işlem verilerinin erişilebilirliğine ve işlem sırasına odaklanır. Ortak fikre sahip bir blok sadece arkasındaki veri erişilebilir olduğunda geçerli kabul edilir. Bu, blok üreticilerinin blok başlığını yayınlamakla birlikte arkasındaki veriyi açıklamadığı durumları engellemek için yapılmıştır; bu durumda istemciler, uygulama durumunu hesaplamak için gereken işlemleri okuyamaz.
Avail, blok doğrulaması sorununu veri erişilebilirlik doğrulamasına indirger; bu, sabit maliyetle etkin bir şekilde yapılabilen veri erişilebilirlik denetimini içerir. Veri erişilebilirlik denetimi, hata düzeltme kodunu kullanır ve büyük ölçüde veri yedeklemesi tasarımında kullanılır.
Veri erişilebilirlik denetimi, her hafif istemcinin zincirdeki her bloktan çok az rastgele blok örneği almasını gerektirir. Bir grup hafif istemci bu şekilde tüm blok zincirini toplu olarak örnekleme yapabilir. Torrent gibi bir p2p dosya paylaşım sistemi gibi sistemlerde olduğu gibi, farklı düğümlerin genellikle yalnızca dosyanın belirli kısımlarını sakladığı bir modeldir.
Lütfen bu tekniklerin Ethereum 2.0 ve Celestia (önceden LazyLedger olarak bilinmekte) gibi sistemlerde yaygın bir şekilde kullanılacağını unutmayın.
Bu durum ayrıca ilginç bir sonuca yol açmıştır: ağda bulunan mutabakat dışı düğüm sayısı ne kadar fazlaysa, güvenli bir şekilde sahip olabileceğiniz blok büyüklüğü (ve işlem kapasitesi) o kadar büyük olur. Bu, ağda mutabakat dışı düğümlerin ağın işlem kapasitesine ve güvenliğine katkıda bulunabileceği anlamına gelir.
Avail tarafından kullanılan KZG taahhüt tabanlı şemada, üç ana özellik bulunmaktadır:
· Veri gereksizliği, blok üretenin bloğun herhangi bir kısmını gizlemesini zorlaştırır.
· Sahtekarlıksızlık, doğru silme kodunu garanti eder
· Vektör taahhüdü, tam düğümlerin hafif düğümleri işlemleri içerdiğine ikna etmesine izin verir.
Basitçe söylemek gerekirse, bir bloktaki tüm veriler bir 2D matrise düzenlenir. Veri gereksizliği eklemek için matrisin her sütununu silme koduyla silerek orijinal sütunun boyutunu ikiye katlarız. Her satırı göndermek için Kate taahhüdü kullanılır ve taahhüt blok başlığında bulunur. Bu şema, veri gizleme girişimlerini kolayca yakalayabilir çünkü yalnızca blok başlığına erişebilen herhangi bir hafif istemci, matrisin rastgele bir hücresini sorgulayabilir ve blok başlığına dayalı kısa bir kanıt alabilir (Kate taahhüfünün yardımıyla). Veri gereksizliği, bir blok üreticinin bloğun büyük bir kısmını gizlemesini zorunlu kılar, hatta yalnızca tek bir işlemi gizlemek istese bile, rastgele örneklemeyle kolayca yakalanmasını sağlar. Sahtekarlık kanıtına ihtiyaç duymamamızın nedeni, Kate taahhüdünün kısıtlayıcı olmasıdır, bu da bir blok üreticinin yanlış taahhüt oluşturmasını sağlamak ve bunun tespit edilememesini yapayalnız ve uygulanabilir olmaktan çok uzaktır. Ayrıca, KZG taahhüt şemasının homomorfik özelliklerinden yararlanarak geniş bir satırın taahhütünü hesaplamak mümkündür.

KZG Taahhüt Şeması
Burada Avail'in oluşturduğu ana özellikleri belirtsek de kısmi veri alımı ve işbirlikçi kullanılabilirlik güvencesi gibi diğer özellikler de bulunmaktadır. Detayları burada atladık ve bunları gelecek yazılarda tekrar ele alacağız.
Şimdi, bir örnek verme ve pratik kullanım senaryosunu çalıştırma zamanı olabilir. Yeni bir uygulamanın, uygulamaya özgü bağımsız bir zinciri barındırmak istediğini varsayalım. Uygulama, yeni bir PoS zincirini başlatmak için Polygon SDK veya benzer bir çerçeve (Cosmos SDK veya Substrate gibi) kullanır ve iş mantığını içine yerleştirir. Ancak, yeterli güvenliği sağlamak için doğrulayıcıların caydırıcılığını sağlama konusunda bir başlangıç sorunuyla karşı karşıyadır.
Bu durumu önlemek için, İşlem Sıralaması ve Veri Erişilebilirliği için Avail kullanır. Uygulama kullanıcıları, Polygon SDK zincirine işlem gönderir, bu işlemler otomatik olarak Avail'e yönlendirilir ve orada siparişlenir. Sıralı işlemler bir (veya daha fazla) operatör tarafından toplanır ve iş mantığına göre nihai uygulama durumu oluşturulur. Uygulama kullanıcıları, sıralı verilerin kullanılabilir olduğundan emin olabilir ve istedikleri zaman uygulama durumunu yeniden oluşturabilir, böylece Avail'in sağladığı güçlü güvenlik garantisine sahip bir zinciri kullanabilirler.
Yukarıdaki örnek, Avail'i güvenli bir şekilde sağlamak için kullanılan yeni bağımsız zinciri tartışmaktadır, ancak bu platform geneldir ve mevcut herhangi bir zincir de veri erişilebilirliğini sağlamak için kullanılabilir. Bir sonraki bölümde, Avail'in Ethereum'un mevcut toplu çözümlemesine nasıl yardımcı olduğuna kısaca değineceğiz.
Optimistik Rollup, ZK Rollup ve Validiums gibi çeşitli Ethereum Layer 2 çözümleri önerilmiştir. Bu çözümler, işlemi zincir altına taşırken uygulama doğrulamasını ve verinin zincir üstündeki erişilebilirliğini sağlar. Zincir altı yürütme tabanlı mimari, işlem hacmini arttırsa da, hala Ethereum gibi ana zincirin işleyebileceği veri miktarıyla sınırlıdır. Çünkü yürütme zincir dışında gerçekleşse de, doğrulama veya anlaşmazlık çözümü katı bir şekilde zincir üstünde gerçekleşir. İşlem verileri, gelecekte yeniden oluşturulabilirlik için Ethereum'a calldata olarak sunulur. Bu son derece önemlidir.
Optimistik Rollup durumunda, operatör yanlış işlemleri gönderebilir ve ardından bir kısmı blok zincirini geri alabilir. Böylece, sistemdeki diğer tam düğümler, gönderilen beyanın doğru olup olmadığını doğrulayamaz. Veri eksikliği nedeniyle, yanlış beyanın gerçekten geçersiz olduğunu kanıtlayacak herhangi bir sahtekarlık kanıtı/tartışma üretemezler.
Sıfır Bilgiye Dayalı Rollup durumunda, ZKP Dirençliliği kabul edilen işlemlerin geçerli olduğunu garanti eder. Bununla birlikte, böyle bir güvenceye sahip olsak bile, işlemi destekleyen verilerin açıklanmaması ciddi yan etkilere neden olabilir.
Bu durum, diğer doğrulayıcıların sistemdeki mevcut durumu hesaplayamamasına ve kullanıcıların tanıklığa (görünen kanıtlar) erişime sahip olmadıkları için sistem dışında bırakılmalarına ve bakiyelerinin dondurulmasına neden olabilir.
Daha yüksek işlem kapasitesine ulaşmak için, yalnızca yürütmenin dışında olması gerektiğini değil, aynı zamanda veri erişilebilirliğini sağlamak için ölçeklenebilir bir veri barındırma katmanına da ihtiyacımız olduğunu fark ettik.
Bu tür bir blokzincir tasarımı aşağıdaki bölümleri ele almalıdır:
· Veri Barındırma ve Sıralama: Bu bölüm işlem verilerini alacak ve bunları sıralayacak, hiçbir yürütme gerektirmeyecek. Daha sonra veriyi depolayacak ve dağıtık bir şekilde tam veri erişilebilirliğini sağlayacak. Bu, Avail için kritik bir unsurdur.
· Yürütme: Yürütme bileşeni, Avail'den sıralanmış işlemleri almalı ve bunları uygulamalıdır. Bir kontrol noktası/beyan/kanıt oluşturmalı ve bunu veri doğrulama katmanına sunmalıdır. Buna yürütme katmanı diyoruz.
· Doğrulama/Anlaşmazlık Çözümü: Bu bölüm sistemdeki kilit zincire temellendirilmiştir. Tasarımın güvenliği, bu bölümün dirençliliğine ve güvenlik özelliklerine bağlıdır. Yürütme katmanının sunduğu kontrol noktası/beyan/kanıtlar, yalnızca erişilebilir veri olduğunda sistemde geçerli durum geçişlerini kabul etmek için bu katman tarafından işlenir. Buna veri doğrulama katmanı diyoruz.
Orijinal Makale Bağlantısı
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