Jerry Luo, Kernel Ventures tarafından

TL;DR

1. İlk günlerde, halka açık zincirler, güvenliği ve ademi merkeziyetçiliği sağlamak için ağ genelinde düğümlerin veri tutarlılığını korumasını gerektiriyordu. Bununla birlikte, blok zinciri ekosisteminin gelişmesiyle birlikte, depolama baskısı artmaya devam ediyor ve bu da düğüm operasyonlarının merkezileşme eğilimine neden oluyor. Bu aşamada, Katman 1'in TPS'nin büyümesinden kaynaklanan depolama maliyeti sorununu acilen çözmesi gerekiyor.

2. Bu sorun karşısında, geliştiricilerin güvenlik, depolama maliyeti, veri okuma hızı ve DA katmanının çok yönlülüğünü dikkate alarak yeni bir geçmiş veri depolama şeması önermeleri gerekir.

3. Bu sorunu çözme sürecinde, Sharding, DAS, Verkle Tree, DA ara bileşenleri vb. dahil olmak üzere birçok yeni teknoloji ve fikir ortaya çıkmıştır. Veri fazlalığını azaltarak ve veri doğrulamanın verimliliğini artırarak DA katmanının depolama şemasını optimize etmeye çalıştılar.

4. Mevcut DA şeması, veri depolama konumu açısından kabaca iki kategoriye ayrılmıştır, yani ana zincir DA ve üçüncü taraf DA. Ana zincir DA, düğümler üzerindeki depolama baskısını azaltmak için verileri düzenli olarak temizleme ve veri depolamayı parçalama perspektifine dayanır. Üçüncü taraf DA tasarım gereksinimleri, depolamaya hizmet etmek ve büyük miktarda veri için makul bir çözüme sahip olmak üzere tasarlanmıştır. Bu nedenle, esas olarak tek zincirli uyumluluk ve çok zincirli uyumluluk arasında bir dengedir ve üç çözüm önerilmektedir: ana zincire özel DA, modüler DA ve depolama genel zinciri DA.

5. Ödemeye dayalı halka açık zincir, geçmiş verilerin güvenliği için son derece yüksek gereksinimlere sahiptir ve ana zinciri DA katmanı olarak kullanmak uygundur. Bununla birlikte, uzun süredir çalışan ve ağı çok sayıda madencinin çalıştırdığı halka açık zincirler için, bir konsensüs katmanı içermeyen ve güvenliği dikkate alan üçüncü taraf bir DA'nın benimsenmesi daha uygundur. Kapsamlı genel zincir, daha büyük veri kapasitesi, daha düşük maliyet ve güvenlik ile ana zincire ayrılmış DA depolamanın kullanımı için daha uygundur. Ancak çapraz zincir ihtiyacı göz önüne alındığında, modüler DA da iyi bir seçenektir.

6. Genel olarak blockchain, veri fazlalığını ve çok zincirli iş bölümünü azaltma yönünde gelişmektedir.

1. arka plan

Dağıtılmış bir defter olarak, blok zincirinin veri depolamanın güvenliğini ve ademi merkeziyetçiliğini sağlamak için geçmiş verileri tüm düğümlerde depolaması gerekir. Her durum değişikliğinin doğruluğu bir önceki durumla (işlemin kaynağı) ilgili olduğundan, işlemin doğruluğunu sağlamak için bir blok zinciri, prensip olarak, ilk işlemden mevcut işleme kadar tüm geçmişi saklamalıdır. Ethereum'u örnek alırsak, her bloğun ortalama boyutu 20 kb olarak tahmin edilse bile, mevcut Ethereum bloğunun toplam boyutu 370 GB'a ulaşmıştır ve tam bir düğümün bloğun kendisine ek olarak durum ve işlem makbuzlarını kaydetmesi gerekir. Bu kısmı sayarsak, tek bir düğümün toplam depolama hacmi 1 TB'ı aştı, bu da düğümün çalışmasını az sayıda insana yoğunlaştırdı.

Ethereum'un en son blok yüksekliği, görüntü kaynağı: Etherscan

2. DA performans metrikleri

2.1 Güvenlik

Veritabanı veya bağlantılı liste depolama yapısıyla karşılaştırıldığında, blok zincirinin değişmezliği, yeni oluşturulan verilerin geçmiş veriler aracılığıyla doğrulanabilmesi gerçeğinden gelir, bu nedenle geçmiş verilerinin güvenliğini sağlamak, DA katmanı depolamasında ilk husustur. Blok zinciri sisteminin veri güvenliğinin değerlendirilmesi için, genellikle veri fazlalığı miktarını ve veri kullanılabilirliğinin doğrulama yöntemini analiz ederiz

Yedeklilik sayısı: Blok zinciri sistemindeki verilerin yedekliliği için temel olarak aşağıdaki rolleri oynayabilir: ilk olarak, ağdaki yedeklilik sayısı daha büyükse, doğrulayıcının mevcut işlemi doğrulamak için geçmiş bir bloktaki hesap durumunu kontrol etmesi gerektiğinde, referans için en fazla sayıda örnek alabilir ve düğümlerin çoğunluğu tarafından kaydedilen verileri seçebilir. Geleneksel veritabanlarında, veriler yalnızca belirli bir düğümde anahtar-değer çiftleri biçiminde depolandığından, geçmiş verileri yalnızca tek bir düğümde değiştirmek için saldırı maliyeti son derece düşüktür ve teorik olarak konuşursak, veriler ne kadar yedekli olursa, veriler o kadar güvenilir olur. Aynı zamanda, ne kadar çok düğüm depolanırsa, verilerin kaybolma olasılığı o kadar az olur. Bu aynı zamanda Web2 oyunlarını depolayan merkezi sunucularla da karşılaştırılabilir ve tüm arka uç sunucuları kapatıldığında tam bir kapanma olacaktır. Bununla birlikte, daha fazlası daha iyi değildir, çünkü her yedeklilik ek depolama alanı getirecektir ve çok fazla veri yedekliliği sisteme aşırı depolama baskısı getirecektir ve iyi bir DA katmanı, güvenlik ve depolama verimliliği arasında bir denge kurmak için uygun bir yedeklilik yöntemi seçmelidir.

Veri kullanılabilirliği kontrolü: Yedeklilik, ağda yeterli veri kaydı olmasını sağlar, ancak kullanılacak verilerin de doğruluk ve eksiksizlik açısından doğrulanması gerekir. Bu aşamada, blok zincirinde yaygın olarak kullanılan doğrulama yöntemi, tüm ağın kaydetmesi için küçük bir kriptografik taahhüdü tutan kriptografik taahhüt algoritmasıdır ve bu taahhüt, işlem verilerinin karıştırılmasıyla elde edilir. Bir tarihsel veri parçasının gerçekliğini test etmek için, veriler aracılığıyla kriptografik vaadin geri yüklenmesi, restorasyon ile elde edilen kriptografik vaadin tüm ağın kayıtlarıyla tutarlı olup olmadığının kontrol edilmesi ve tutarlıysa doğrulamanın geçilmesi gerekir. Yaygın olarak kullanılan şifre doğrulama algoritmaları Merkle Root ve Verkle Root'tur. Yüksek güvenlikli veri kullanılabilirliği doğrulama algoritması yalnızca çok az doğrulama verisi gerektirir ve geçmiş verileri hızlı bir şekilde doğrulayabilir.

2.2 Depolama Maliyetleri

Temel güvenliğin sağlanması öncülüğünde, DA katmanında ulaşılması gereken bir sonraki temel hedef, maliyetleri azaltmak ve verimliliği artırmaktır. Birincisi, depolama maliyetlerini düşürmek, yani donanım performansındaki farkı dikkate almadan, birim boyutu başına veri depolamanın neden olduğu bellek ayak izini azaltmaktır. Bu aşamada, blok zincirindeki depolama maliyetlerini azaltmanın ana yolu, verilerin etkin bir şekilde depolanmasını sağlamak ve veri yedekleme sayısını azaltmak için parçalama teknolojisini benimsemek ve ödüllü depolamayı kullanmaktır. Bununla birlikte, yukarıdaki iyileştirme yöntemlerinden depolama maliyeti ile veri güvenliği arasında bir oyun ilişkisi olduğunu ve depolama işgalinin azaltılmasının genellikle güvenlikte bir azalma anlamına geldiğini görmek zor değildir. Bu nedenle, iyi bir DA katmanının depolama maliyetini veri güvenliği ile dengelemesi gerekir. Ek olarak, DA katmanı ayrı bir genel zincir ise, veri alışverişinin ara sürecini en aza indirerek maliyeti düşürmek de gerekir ve her geçiş işleminde sonraki sorgu çağrıları için dizin verilerinin bırakılması gerekir, bu nedenle çağrı süreci ne kadar uzun olursa, o kadar fazla dizin verisi kalacak ve depolama maliyeti artacaktır. Son olarak, veri depolamanın maliyeti, verilerin dayanıklılığı ile doğrudan ilgilidir. Genel olarak, verilerin depolama maliyeti ne kadar yüksek olursa, genel zincirin verileri kalıcı olarak depolaması o kadar zor olur.

2.3 Veri okuma hızı

Maliyet düşüşü sağlandıktan sonra, bir sonraki adım, kullanılması gerektiğinde verileri DA katmanından hızlı bir şekilde çağırma yeteneği olan verimlilik kazanımlarıdır. Bu işlem iki adımdan oluşur, birincisi veri depolayan düğümleri aramaktır, bu süreç esas olarak tüm ağın veri tutarlılığını sağlayamayan genel zincir içindir, eğer genel zincir tüm ağın düğümlerinin veri senkronizasyonunu sağlamışsa, bu işlemin zaman tüketimi göz ardı edilebilir. İkinci olarak, bu aşamada Bitcoin, Ethereum ve Filecoin dahil olmak üzere ana akım blok zinciri sistemlerinde, düğüm depolama yöntemi Leveldb veritabanıdır. Leveldb'de veriler üç şekilde depolanır. Birincisi, anında yazılan verilerin memtable tipi bir dosyada saklanması ve memtable dolduğunda, dosya türünün memtable'dan immutable memtable'a değiştirilmesidir. Her iki dosya türü de bellekte saklanır, ancak Immutable Memtable dosyası artık değiştirilemez ve yalnızca ondan veri okuyabilir. IPFS ağında kullanılan sıcak depolama, verileri bu kısımda depolar ve çağrıldığında bellekten hızlı bir şekilde okunabilir, ancak sıradan bir düğümün mobil belleği genellikle gigabayt seviyesindedir, bu da yavaş yazılması kolaydır ve düğüm çöktüğünde ve diğer anormal koşullarda, bellekteki veriler kalıcı olarak kaybolacaktır. Verilerinizin kalıcı olarak saklanmasını istiyorsanız, onu bir SST dosyası olarak katı hal sürücüsüne (SSD) saklamanız gerekir, ancak önce verileri belleğe okumanız gerekir, bu da veri indeksleme hızını büyük ölçüde yavaşlatır. Son olarak, parçalı depolamaya sahip sistemler için veri geri yükleme, veri isteklerinin birden çok düğüme gönderilmesini ve geri yüklenmesini gerektirir ve bu da veri okuma hızını yavaşlatır.

Leveldb veri depolama yöntemi, görüntü kaynağı: Leveldb-handbook

2.4 DA Katman Ortaklığı

DeFi'nin gelişmesi ve CEX'lerin sorunlarıyla birlikte, merkezi olmayan varlıkların zincirler arası işlemlerine olan talep de artıyor. İster zincirler arası hash kilitleme mekanizması, ister noter veya röle zinciri olsun, iki zincirdeki geçmiş verilerin aynı anda belirlenmesi kaçınılmazdır. Bu sorunun özü, iki zincir üzerindeki verilerin ayrılmasında yatmaktadır ve farklı merkezi olmayan sistemlerde doğrudan iletişim sağlanamamaktadır. Bu nedenle, bu aşamada, birden fazla public chain'in geçmiş verilerini aynı güvenilir public chain üzerinde depolayan ve doğrulama sırasında yalnızca bu public chain'deki verileri çağırması gereken DA katmanının depolama modu değiştirilerek bir çözüm önerilmektedir. Bu, DA katmanının farklı türdeki genel zincirlerle güvenli bir iletişim yöntemi kurabilmesini gerektirir, yani DA katmanı iyi bir çok yönlülüğe sahiptir.

3. DA ile ilgili teknoloji keşfi

3.1 Parçalama

• Geleneksel bir dağıtılmış sistemde, bir dosya bir düğümde tam bir biçimde saklanmaz, ancak orijinal veriler birden çok bloğa bölünür ve her düğümde bir blok saklanır. Ve bloklar yalnızca bir düğümde depolanma eğiliminde değildir, ancak mevcut ana dağıtılmış sistemlerde genellikle 2'ye ayarlanan diğer düğümlerde uygun yedeklemelere sahip olma eğilimindedir. Bu parçalama mekanizması, tek bir düğüm üzerindeki depolama baskısını azaltabilir, sistemin toplam kapasitesini her bir düğümün depolama kapasitesinin toplamına genişletebilir ve uygun veri yedekliliği yoluyla depolama güvenliğini sağlayabilir. Bir blok zincirinde benimsenen parçalama yaklaşımı büyük ölçüde benzerdir, ancak ayrıntılarda farklılıklar vardır. Her şeyden önce, blok zincirindeki her düğüm varsayılan olarak güvenilmez olduğundan, Sharding'in uygulanması sürecinde sonraki veri gerçekliği için yedeklemek için yeterince büyük miktarda veriye ihtiyaç vardır, bu nedenle bu düğümün yedekleme sayısının 2'den çok daha fazla olması gerekir. İdeal olarak, bu depolama şemasına sahip bir blok zinciri sisteminde, toplam doğrulayıcı sayısı T ve parça sayısı N ise, yedekleme sayısı T/N olmalıdır. İkincisi, Block'un depolama prosedürüdür, geleneksel dağıtılmış sistemde daha az düğüm vardır, bu nedenle genellikle birden fazla veri bloğuna uyum sağlamak için bir düğümdür, ilki, tutarlı karma algoritması aracılığıyla verileri karma halkaya eşlemektir ve ardından her düğüm belirli bir aralıkta bir dizi veri bloğu depolar ve bir düğümün belirli bir depolamada bir depolama görevi tahsis etmediği kabul edilebilir. Blok zincirinde, her düğümün bir bloğa atanıp atanmadığı artık rastgele bir olay değil, kaçınılmaz bir olaydır ve her düğüm, bloğun orijinal verileri ve düğümün kendi bilgileri ile veri hash'inin sonucu ile parça sayısının hesaplanmasıyla tamamlanan depolama için rastgele bir blok seçecektir. Her bir veri parçasının N bloğa bölündüğünü varsayarsak, her düğümün gerçek depolama boyutu orijinal boyutun yalnızca 1/N'si kadardır. N'yi uygun şekilde ayarlayarak, büyüyen TPS ile düğümün depolama basıncı arasında bir denge sağlanabilir.

Parçalamadan sonra veriler nasıl saklanır, görüntü kaynağı: Kernel Ventures

3.2 DAS(Veri Kullanılabilirliği Örneklemesi)

DAS teknolojisi, Sharding'in depolama yöntemleri açısından daha fazla optimizasyonuna dayanmaktadır. Parçalama sürecinde, düğümlerin basit rastgele depolanması nedeniyle, belirli bir blok kaybolabilir. İkinci olarak, parçalanmış veriler için, geri yükleme işlemi sırasında verilerin gerçekliğinin ve bütünlüğünün nasıl doğrulanacağı da çok önemlidir. DAS'ta, bu sorunların her ikisi de Silgi kodu ve KZG polinom taahhütleri ile ele alınır.

Silgi kodu: Ethereum'daki çok sayıda doğrulayıcı göz önüne alındığında, bir bloğun herhangi bir düğüm tarafından saklanmama olasılığı neredeyse sıfırdır, ancak teorik olarak hala böyle aşırı bir durumun meydana gelme olasılığı vardır. Bu olası depolama kaybı tehdidini azaltmak için, orijinal verileri depolama için doğrudan bloklara bölmek yerine, orijinal veriler n. dereceden bir polinomun katsayılarına eşlenir ve ardından polinom üzerinde 2n nokta alınır ve düğüm depolama için bunlardan birini rastgele seçer. Bu n. dereceden polinom için, geri yüklemek için yalnızca n+1 nokta gerekir, bu nedenle orijinal verileri geri yüklemek için düğümler tarafından blokların yalnızca yarısının seçilmesi gerekir. Silgi kodu aracılığıyla, veri depolamanın güvenliği ve ağın verileri kurtarma yeteneği iyileştirilir.

KZG Polinom Vaadi: Veri depolamanın çok önemli bir parçası, veri gerçekliğinin doğrulanmasıdır. Silgi kodu kullanmayan ağlarda, işlemi doğrulamanın çeşitli yolları vardır, ancak veri güvenliğini artırmak için yukarıdaki Silgi kodu tanıtılırsa, KZG polinom taahhütlerini kullanmak daha uygundur. KZG polinomu, tek bir bloğun içeriğini polinomlar biçiminde doğrudan doğrulamayı vaat eder, böylece polinomları ikili verilere geri yükleme ihtiyacını ortadan kaldırır ve doğrulama formu genellikle Merkle Ağacı'nınkine benzer, ancak belirli bir Yol düğümü verisi gerekmez, gerçekliğini doğrulamak için yalnızca KZG kök ve blok verilerine ihtiyaç vardır.

3.3 DA katmanı veri doğrulama modu

Veri doğrulama, düğümden çağrılan verilerin değiştirilmemesini ve kaybolmamasını sağlar. Doğrulama sürecinde gereken veri miktarını ve hesaplama maliyetini mümkün olduğunca azaltmak için, DA katmanı şu anda ana doğrulama yöntemi olarak ağaç yapısını benimsemektedir. En basit biçim, doğrulama için tam bir ikili ağaç biçiminde kaydedilen Merkle Ağacını kullanmaktır ve yalnızca bir Merkle kökü ve alt ağacın hash değerini doğrulamak için düğüm yolunun diğer tarafında tutması gerekir ve doğrulamanın zaman karmaşıklığı O(logN) düzeyidir (sayı tabanlı değilse logN varsayılan olarak log2(N)'dir). Doğrulama süreci büyük ölçüde basitleştirilmiş olsa da, verilerin artmasıyla birlikte doğrulama sürecindeki veri miktarı genel olarak artmıştır. Doğrulama miktarını artırma sorununu çözmek için bu aşamada başka bir doğrulama yöntemi olan Verkle Tree önerilmiştir. Değer depolamaya ek olarak, Verkle Tree'deki her düğüm ayrıca bir Vektör Taahhüdü ile birlikte gelir, orijinal düğümün değeri ve bu taahhüt kanıtı aracılığıyla, diğer kardeş düğümlerin değerini çağırmadan verilerin gerçekliğini hızlı bir şekilde doğrulayabilirsiniz, bu da her doğrulama için hesaplama sayısını yalnızca sabit bir sabit olan Verkle Ağacının derinliği ile ilgili hale getirir ve böylece doğrulama hızını büyük ölçüde hızlandırır. Bununla birlikte, Vector Commitment'ın hesaplanması, tüm kardeş düğümlerin aynı katmana katılımını gerektirir, bu da veri yazma ve değiştirme maliyetini büyük ölçüde artırır. Bununla birlikte, kalıcı olarak saklanan ve kurcalanamayan geçmiş veriler için Verkle Tree son derece uygundur. Ek olarak, Merkle Ağacı ve Verkle Ağacı'nın K-ary şeklinde varyantları da vardır ve bunların özel uygulama mekanizmaları benzerdir, ancak her düğümün altındaki alt ağaçların sayısı değiştirilir ve bunların spesifik performanslarının karşılaştırılması aşağıdaki tabloda görülebilir.

Veri doğrulama yöntemleri ile zaman performansının karşılaştırılması, görüntü kaynağı: Verkle Trees

3.4 Genel DA ara yazılımı

Blok zinciri ekolojisinin sürekli genişlemesi, halka açık zincirlerin sayısında bir artışa neden oldu. Her bir halka açık zincirin kendi alanlarındaki avantajları ve yeri doldurulamaz olması nedeniyle, Layer1 halka açık zincirinin kısa sürede birleşmesi neredeyse imkansızdır. Bununla birlikte, DeFi'nin gelişmesi ve CEX'lerin sorunlarıyla birlikte, merkezi olmayan zincirler arası ticaret varlıklarına olan talep de artıyor. Sonuç olarak, zincirler arası veri alışverişlerinde güvenlik sorunlarını ortadan kaldırabilen DA katmanlı çok zincirli veri depolama, giderek daha fazla ilgi gördü. Bununla birlikte, farklı genel zincirlerden geçmiş verileri kabul etmek için, DA katmanının, zincirden veri yakalama inisiyatifini alan ve veri aktarım sürecindeki farklılıkları en aza indirmek için zincirdeki tüm verileri standart bir biçimde Arweave'e depolayabilen Arweave tabanlı bir depolama ara yazılımı olan kvye gibi veri akışlarının standartlaştırılmış depolanması ve doğrulanması için merkezi olmayan bir protokol sağlaması gerekir. Göreceli olarak konuşursak, belirli bir genel zincir için DA katmanı veri depolaması sağlama konusunda uzmanlaşmış olan Layer2, etkileşim maliyetini azaltan ve güvenliği artıran dahili paylaşım düğümleri aracılığıyla verilerle etkileşime girer, ancak nispeten büyük sınırlamalara sahiptir ve yalnızca belirli genel zincirlere hizmet sağlayabilir.

4. DA katmanlı depolama şeması

4.1 Ana zincir DA

4.1.1 sınıfı DankSharding

Bu tür bir depolama şeması için kesin bir isim yoktur ve bu tür depolama şemasının en önde gelen temsilcisi Ethereum'daki DankSharding'dir, bu nedenle bu makalede DankSharding benzeri şema kullanılmıştır. Bu tür bir çözüm, esas olarak yukarıda bahsedilen iki DA depolama teknolojisini, Sharding ve DAS'ı kullanır. İlk olarak, Parçalama verileri uygun parçalara böler ve ardından her düğümün depolama için DAS biçiminde bir veri bloğu çıkarmasına izin verir. Tüm ağda yeterli düğüm varsa, daha fazla sayıda parça N alabiliriz, böylece her düğümün depolama basıncı orijinalin yalnızca 1/N'si olur, böylece toplam depolama alanı genişlemesinin N katını elde ederiz. Aynı zamanda, aşırı durumda bir bloğun herhangi bir blokta saklanmamasını sağlamak için DankSharding, verileri Silgi Kodu kullanarak kodlar ve verilerin yalnızca yarısı tamamen geri yüklenebilir. Son olarak, veri doğrulama süreci, hızlı bir doğrulama elde etmek için Verkle ağacının yapısını ve polinom taahhüdünü kullanır.

4.1.2 Kısa süreli depolama

Ana zincirde DA için verileri işlemenin en basit yollarından biri, geçmiş verileri kısa bir süre için saklamaktır. Özünde, blok zinciri, kalıcı depolamaya ihtiyaç duymadan, tüm ağ tanıklığı öncülüğünde defterin içeriğinde değişiklikler gerçekleştirerek halka açık bir defter rolünü oynar. Solana'yı örnek alırsak, geçmiş verileri Arweave ile senkronize edilmiş olsa da, ana ağ düğümleri yalnızca son iki güne ait işlem verilerini tutar. Hesap kayıtlarına dayalı genel zincirde, her anın geçmiş verileri, hesabın blok zincirindeki son durumunu korur ve bu, bir sonraki değişiklik anı için bir doğrulama temeli sağlamak için yeterlidir. Bu süreden önce özel veri ihtiyaçları olan projeler için, bunları diğer merkezi olmayan halka açık zincirlerde veya güvenilir üçüncü taraflarca depolayabilirler. Bu, ek veri ihtiyacı olan kişilerin geçmiş veri depolama için ödeme yapması gerektiği anlamına gelir.

4.2 Üçüncü Taraf Kalkınma Ajansları

4.2.1 Ana zincire ayrılmış DA: EthStorage

Ana zincir için DA:D A katmanındaki en önemli şey veri iletiminin güvenliğidir ve bu konuda en güvenli olanı ana zincirin DA'sıdır. Bununla birlikte, ana zincir depolama, depolama alanı ve kaynaklar için rekabet ile sınırlıdır, bu nedenle ağ verilerinin miktarı hızla arttığında, verilerin uzun vadeli depolanmasını sağlamak istiyorsanız, üçüncü taraf DA daha iyi bir seçim olacaktır. Üçüncü taraf DA, ana ağ ile daha yüksek uyumluluğa sahipse, düğümlerin paylaşımını gerçekleştirebilir ve veri alışverişi sürecinde daha yüksek güvenliğe sahip olabilir. Bu nedenle, güvenliği göz önünde bulundurma öncülüğünde, ana zincire adanmış DA için büyük avantajlar olacaktır. Ethereum'u örnek alırsak, ana zincire özel DA'nın temel gereksinimlerinden biri, Ethereum verileri ve sözleşmeleriyle birlikte çalışabilirliği sağlamak için EVM ile uyumlu olabilmesidir ve temsili projeler arasında Topia, EthStorage vb. bulunur. Bunlar arasında, EthStorage şu anda uyumluluk açısından en gelişmiş olanıdır, çünkü EVM düzeyinde uyumluluğa ek olarak, Ethereum geliştirme aracı düzeyinde uyumluluk elde etmek için Remix ve Hardhat gibi Ethereum geliştirme araçlarıyla bağlantı kurmak için ilgili arayüzleri de kurar.

EthStorage: EthStorage, Ethereum'dan bağımsız bir halka açık zincirdir, ancak üzerinde çalışan düğümler Ethereum düğümlerinden daha üstündür, yani EthStorage çalıştıran düğümler aynı anda Ethereum'u da çalıştırabilir ve EthStorage doğrudan Ethereum üzerindeki işlem kodu aracılığıyla çalıştırılabilir. İndeksleme için Ethereum ana ağında yalnızca az miktarda meta veri tutan EthStorage'ın depolama modelinde, esasen Ethereum için merkezi olmayan bir veritabanı oluşturur. Mevcut çözümde EthStorage, Ethereum ana ağında bir EthStorage sözleşmesi dağıtarak Ethereum ana ağı ile EthStorage arasındaki etkileşimi uyguladı. Ethereum veri yatırmak istiyorsa, sözleşmede put() fonksiyonunu çağırması gerekir ve giriş parametreleri iki bayt değişkenli anahtardır, veriler, burada veriler yatırılacak verileri temsil eder ve anahtar, IPFS'de CID'nin varlığına benzer olarak görülebilecek Ethereum ağındaki kimliğidir. (Anahtar, veri) çifti EthStorage ağında başarıyla depolandıktan sonra, EthStorage bir kvldx oluşturacak ve bunu Ethereum'daki anahtara karşılık gelen Ethereum ana ağına geri döndürecek ve bu değer EthStorage'daki verilerin depolama adresine karşılık gelecektir, böylece büyük miktarda veri depolama sorunu artık tek bir (anahtar, kvldx) çifti depolamak için değiştirilir, bu da Ethereum ana ağının depolama maliyetini büyük ölçüde azaltır. Önceden depolanan verilere bir çağrı yapmanız gerekiyorsa, EthStorage'da get() işlevini kullanmanız ve anahtar parametresini girmeniz gerekir ve Ethereum'da depolanan kvldx aracılığıyla EthStorage'daki veriler üzerinde hızlı bir arama gerçekleştirebilirsiniz.

EthStorage sözleşmesi, görüntü kaynağı: Kernel Ventures

Düğümlerin verileri depolama şekli açısından EthStorage, Arweave'in modelinden ödünç alır. Her şeyden önce, ETH'den çok sayıda (k,v) çifti parçalanır ve her parçalama, madenciler için ödüllerin depolanması sürecinde iş yükü boyutunun adil olmasını sağlamak için her bir (k,v) çiftinin belirli boyutunda da bir sınır olan sabit sayıda (k,v) veri çifti içerir. Ödüllerin verilmesi için, düğümün veri depolayıp depolamadığını doğrulamanız gerekir. Bu süreçte EthStorage, bir parçalamayı (terabayt boyutunu) çok sayıda parçaya böler ve doğrulama için Ethereum ana ağında bir Merkle kökü tutar. Daha sonra, madencinin EthStorage'daki önceki bloğun hash'i ile rastgele bir algoritma aracılığıyla birkaç parçanın adreslerini oluşturmak için bir nonce sağlaması ve madencinin gerçekten tüm parçalamayı depoladığını kanıtlamak için bu parçaların verilerini sağlaması gerekir. Bununla birlikte, bu nonce rastgele seçilemez, aksi takdirde düğüm, doğrulamayı geçmek için yalnızca depolanan yığınına karşılık gelen uygun bir nonce seçecektir, bu nedenle bu nonce, oluşturulan yığının karıştırma ve hashing'den sonra ağ gereksinimlerini karşılamasını sağlamalıdır ve yalnızca nonce ve rastgele erişim kanıtını gönderen ilk düğüm ödülü alabilir.

4.2.2 Modüler DA: Celestia

Blockchain Modülü: Bu aşamada, Layer1 genel zinciri tarafından yürütülmesi gereken işlemler temel olarak şu dört bölüme ayrılır: (1) ağın temel mantığını tasarlamak, doğrulayıcıları belirli bir şekilde seçmek, bloklar yazmak ve ödülleri ağ bakımcılarına dağıtmak, (2) işlemleri paketlemek ve işlemek ve ilgili işlemleri yayınlamak, (3) zincire konulacak işlemleri doğrulamak ve nihai durumu belirlemek ve (4) geçmiş verileri blok zincirinde depolamak ve sürdürmek. Gerçekleştirilen işlevlere bağlı olarak, blok zincirini konsensüs katmanı, yürütme katmanı, yerleşim katmanı ve veri kullanılabilirliği katmanı (DA katmanı) olmak üzere dört modüle ayırabiliriz.

Modüler blok zinciri tasarımı: Uzun bir süredir, bu dört modül halka açık bir zincire entegre edilmiştir ve böyle bir blok zincirine monolitik blok zinciri denir. Bu form daha istikrarlı ve bakımı kolaydır, ancak aynı zamanda tek bir halka açık zincir üzerinde çok fazla baskı oluşturur. Uygulamada, bu dört modül birbirini sınırlar ve genel zincirin sınırlı bilgi işlem ve depolama kaynakları için rekabet eder. Örneğin, işleme katmanının işlem hızının artırılması, veri kullanılabilirliği katmanı üzerinde daha fazla depolama baskısı oluşturacak ve yürütme katmanının güvenliğini sağlamak, işlem işlemeyi yavaşlatan daha karmaşık kimlik doğrulama mekanizmaları gerektirecektir. Bu nedenle, halka açık zincirlerin gelişimi genellikle bu dört modül arasındaki ödünleşimlerle karşı karşıyadır. Bu halka açık zincirin performansını artırmanın darboğazını aşmak için geliştiriciler modüler bir blok zinciri şeması önerdiler. Modüler blok zincirinin temel fikri, yukarıdaki dört modülden birini veya birkaçını ayırmak ve bunları ayrı bir genel zincir uygulamasına teslim etmektir. Bu şekilde, halka açık zincirde, yalnızca işlem hızının veya depolama kapasitesinin iyileştirilmesine odaklanabilir ve blok zincirinin genel performansı üzerindeki kısa tahta etkisinin neden olduğu önceki sınırlamaları aşabilirsiniz.

Modüler DA: DA katmanını blok zinciri işinden ayırmanın ve tek bir genel zincire devretmenin karmaşık yaklaşımı, Katman 1'in büyüyen geçmiş verileri için uygun bir çözüm olarak kabul edilir. Bu alandaki keşifler hala erken aşamalarındadır ve Celestia şu anda en temsili projedir. Spesifik depolama yöntemi açısından Celestia, Danksharding'in verileri birden çok bloğa bölmek, depolama için her düğüm tarafından bir kısmını çıkarmak ve KZG polinom taahhüdü ile veri bütünlüğünü doğrulamak olan depolama yönteminden ödünç alır. Aynı zamanda Celestia, orijinal verileri bir kk matrisi biçiminde yeniden yazmak için gelişmiş 2D RS silme kodlamasını kullanır ve son olarak orijinal verilerin yalnızca %25'i kurtarılabilir. Bununla birlikte, veri parçalama depolaması esasen yalnızca tüm ağdaki düğümlerin depolama baskısını toplam veri hacmi üzerindeki bir faktörle çarpar ve düğümlerin depolama baskısı ve veri hacmi hala doğrusal büyümeyi sürdürür. Katman 1 işlem hızını artırmaya devam ettikçe, düğümlerin depolama baskısı bir gün kabul edilemez bir eşiğe ulaşabilir. Bu sorunu çözmek için, IPLD bileşeni işlenmek üzere Celestia'da tanıtıldı. Kk matrisindeki veriler için doğrudan Celestia'da değil, LL-IPFS ağında saklanır ve yalnızca IPFS'deki bu verilerin CID kodu düğümde tutulur. Bir kullanıcı geçmiş verilerin bir parçasını istediğinde, düğüm ilgili CID'yi IPLD bileşenine gönderir ve IPFS'deki ham verileri çağırmak için CID'yi kullanır. IPFS'de veri varsa, IPLD bileşenleri ve düğümleri aracılığıyla döndürülür ve değilse, döndürülemez.

Celestia verileri nasıl okunur, görüntü kaynağı: Celestia Core

Celestia: Celestia'yı örnek alırsak, Ethereum'un depolama sorununu çözmede modüler blok zincirinin uygulanmasına bir göz atabiliriz. Rollup düğümü, paketlenmiş ve doğrulanmış işlem verilerini Celestia'ya gönderecek ve verileri Celestia'da depolayacaktır, bu süreçte Celestia, verileri çok fazla farkında olmadan yalnızca depolar ve son olarak depolama alanının boyutuna göre, Rollup düğümü ilgili tia token'leri Celestia'ya depolama ücreti olarak ödeyecektir. Celstia'daki depolama, DAS'tan ve EIP4844'dakine benzer silme kodlamasından yararlanır, ancak EIP4844'deki polinom silme kodlaması 2D RS silme kodlamasına yükseltilir ve depolama güvenliği yeniden yükseltilir ve tüm işlem verilerini geri yüklemek için yalnızca %25 kırılma gerekir. Esasen, bu sadece düşük maliyetli bir POS genel zinciridir ve Ethereum'un geçmiş veri depolama sorununu çözmek istiyorsanız, Celestia ile çalışmak için birçok başka özel modüle ihtiyacınız vardır. Örneğin, toplamalar açısından, Celestia'nın resmi web sitesinde en çok önerilen toplama modlarından biri Sovereign Rollup'tır. Katman 2'deki ortak toplamalardan farklı olarak, yalnızca işlem hesaplanır ve doğrulanır, yani yürütme katmanının çalışması tamamlanır. Sovereign Rollup, Celestia'daki işlemlerin işlenmesini en aza indiren ve Celestia'nın genel güvenliği Ethereum'unkinden daha zayıf olduğunda genel işlem sürecinin güvenliğini en üst düzeye çıkarabilen tüm yürütme ve uzlaşma sürecini kapsar. Celestia'nın Ethereum ana ağında çağırdığı verilerin güvenliğini sağlamak açısından en yaygın çözüm kuantum yerçekimi köprüsü akıllı sözleşmesidir. Celestia'da depolanan veriler için bir Merkle Kökü (Veri Kullanılabilirliği Kanıtı) oluşturur ve Ethereum ana ağındaki kuantum yerçekimi köprüsü sözleşmesinde kalır ve Ethereum, Celestia'daki geçmiş verileri her çağırdığında, hash sonucunu Merkle Kökü ile karşılaştırır ve eğer öyleyse, bunun gerçekten gerçek geçmiş veriler olduğu anlamına gelir.

4.2.3 Halka açık zincir DA'yı saklayın

Ana zincirin DA teknolojisi prensibi açısından, Sharding'e benzer birçok teknoloji depolama halka açık zincirinden ödünç alınmıştır. Üçüncü taraf DA'lar arasında, bazıları, Celestia'daki belirli işlem verilerinin LL-IPFS ağına yerleştirilmesi gibi, doğrudan depolama genel zincirinin yardımıyla bazı depolama görevlerini tamamlamıştır. Üçüncü taraf DA çözümünde, Katman 1'in depolama sorununu çözmek için ayrı bir genel zincir oluşturmanın yanı sıra, daha doğrudan bir yol, büyük geçmiş verileri Katman 1'de depolamak için depolama genel zincirini doğrudan Katman 1'e bağlamaktır. Yüksek performanslı blok zincirleri için, geçmiş verilerin hacmi daha da büyüktür ve yüksek performanslı halka açık zincir Solana'nın veri boyutu, tam hızda çalışırken 4 PG'ye yakındır, bu da sıradan düğümlerin depolama aralığının tamamen ötesindedir. Solana'nın seçtiği çözüm, geçmiş verileri merkezi olmayan bir depolama ağı olan Arweave'de depolamak ve doğrulama için ana ağdaki düğümlerde yalnızca 2 günlük veri tutmaktı. Depolanan sürecin güvenliğini sağlamak için Solana ve Arweave zinciri, Solar Bridge adlı bir depolama köprüsü protokolü tasarladı. Solana düğümü tarafından doğrulanan veriler Arweave ile senkronize edilir ve ilgili etiket döndürülür. Bu etiket ile Solana düğümleri, Solana blok zincirinin geçmiş verilerini istedikleri zaman görüntüleyebilir. Arweave'de, ağdaki düğümlerin veri tutarlılığını koruması ve bunu ağın işleyişine katılmak için bir eşik olarak kullanması gerekli değildir, bunun yerine ödül depolama yöntemini benimser. Her şeyden önce, Arweave blokları oluşturmak için geleneksel bir zincir yapısı kullanmaz, daha çok bir grafik yapısı gibi kullanır. Arweave'de yeni bir blok yalnızca önceki bloğa değil, aynı zamanda rastgele oluşturulmuş bir Geri Çağırma Bloğuna da işaret eder. Bir Geri Çağırma Bloğunun tam konumu, önceki bloğunun hash'i ve blok yüksekliği ile belirlenir ve Geri Çağırma Bloğunun konumu, önceki blok çıkarılana kadar bilinmez. Bununla birlikte, yeni bloklar oluşturma sürecinde, düğümlerin belirtilen zorluğun hash'ini hesaplamak için POW mekanizmasını kullanmak için Geri Çağırma Bloğu'nun verilerine sahip olması gerekir ve yalnızca zorlukla eşleşen hash'i ilk hesaplayan madenciler ödüllendirilebilir, bu da madencileri mümkün olduğunca fazla geçmiş veri depolamaya teşvik eder. Aynı zamanda, geçmiş bir bloğu ne kadar az kişi saklarsa, düğümün bir zorluk nonce oluştururken o kadar az rakibi olur ve madencileri ağda daha az yedekli blokları depolamaya teşvik eder. Son olarak, düğümlerin verileri Arweave'de kalıcı olarak depolayabilmesini sağlamak için WildFire'ın düğüm puanlama mekanizması tanıtıldı. Düğümler, daha fazla geçmiş veriyi daha hızlı sağlayabilen düğümlerle iletişim kurma eğilimindeyken, daha düşük derecelendirmeye sahip düğümler genellikle ilk etapta en son blok ve işlem verilerine erişemezler, bu nedenle POW rekabetinde liderliği ele geçiremezler.

Arweave blokları nasıl oluşturulur, görüntü kaynağı: Arweave Yellow-Paper

5. Kapsamlı karşılaştırma

Ardından, DA performans ölçümlerinin dört boyutuna dayalı olarak beş depolama senaryosunun her birinin artılarını ve eksilerini karşılaştıracağız.

Güvenlik: Veri güvenliği sorunlarının en büyük kaynağı, dürüst olmayan düğümlerden veri iletimi ve kötü niyetli kurcalamanın neden olduğu kayıptır ve zincirler arası süreçte, iki halka açık zincirin bağımsızlığı ve durumu paylaşılmadığından, veri iletim güvenliğinin en çok etkilenen alanıdır. Ek olarak, bu aşamada özel bir DA katmanı gerektiren Katman 1, genellikle güçlü bir fikir birliği grubuna sahiptir ve kendi güvenliği, sıradan depolama genel zincirlerinden çok daha yüksek olacaktır. Bu nedenle, ana zincir DA'nın şeması daha yüksek güvenliğe sahiptir. Veri iletiminin güvenliğini sağladıktan sonraki adım, arama verilerinin güvenliğini sağlamaktır. Yalnızca işlemleri doğrulamak için kullanılan kısa vadeli geçmiş veriler dikkate alınırsa, aynı veriler geçici olarak depolanan ağdaki tüm ağ tarafından yedeklenirken, DankSharding benzeri şemadaki ortalama veri yedekleme sayısı tüm ağdaki düğüm sayısının yalnızca 1/N'si kadardır, daha fazla veri yedekliliği verilerin kaybolma olasılığını azaltabilir ve ayrıca doğrulama için daha fazla referans örneği sağlayabilir. Bu nedenle, geçici depolama daha yüksek veri güvenliğine sahip olacaktır. Üçüncü taraf DA şemasında, ana zincire özel DA, ana zincirle ortak düğümler kullanır ve veriler, zincirler arası işlem sırasında bu röle düğümleri aracılığıyla doğrudan iletilebilir, bu nedenle diğer DA çözümlerinden nispeten daha yüksek güvenliğe sahip olacaktır.

Depolama maliyeti: Depolama maliyetlerine en büyük katkı, verilerin yedeklilik miktarıdır. Ana zincir DA'nın kısa vadeli depolama çözümünde, tüm ağın düğümlerinin veri senkronizasyonu depolama için kullanılır ve yeni depolanan verilerin, en yüksek depolama maliyetine sahip olan tüm ağın düğümleri tarafından yedeklenmesi gerekir. Yüksek depolama maliyeti, bu yöntemin yalnızca yüksek TPS'li ağlarda geçici depolama için uygun olduğunu belirler. İkincisi, ana zincirde Sharding ve üçüncü taraf DA'larda Sharding dahil olmak üzere Sharding'in depolama yöntemidir. Ana zincir daha fazla düğüme sahip olma eğiliminde olduğundan, her blok için daha fazla yedekleme olacaktır, bu nedenle ana zincir parçalama çözümünün maliyeti daha yüksek olacaktır. En düşük depolama maliyeti, ödül depolama yöntemini benimseyen depolama genel zinciri DA'dır ve bu şemadaki veri yedekliliği miktarı genellikle sabit bir sabit etrafında dalgalanır. Aynı zamanda, veri güvenliğini sağlamak için ödülleri artırarak düğümleri daha az yedekleme verisi depolamaya çekmek için depolama genel zinciri DA'da dinamik bir ayarlama mekanizması da tanıtıldı.

Veri okuma hızı: Verilerin depolama hızı, esas olarak verilerin depolama alanındaki depolama konumundan, veri dizini yolundan ve verilerin düğümlerdeki dağılımından etkilenir. Bunlar arasında, verilerin düğümde depolandığı yer, hız üzerinde daha büyük bir etkiye sahiptir, çünkü verilerin bellekte veya SSD'de depolanması, okuma hızının onlarca kez değişmesine neden olabilir. Depolama genel zinciri DA, çoğunlukla SSD depolamayı benimser, çünkü zincir üzerindeki yük yalnızca DA katmanının verilerini değil, aynı zamanda kullanıcılar tarafından yüklenen videolar ve resimler gibi yüksek bellek işgaline sahip kişisel verileri de içerir. Ağ, SSD'leri depolama alanı olarak kullanmıyorsa, büyük depolama baskısına dayanmak ve uzun vadeli depolama ihtiyaçlarını karşılamak zordur. İkinci olarak, bellek içi depolama verilerini kullanan üçüncü taraf DA'lar ve ana zincir DA'ları için, üçüncü taraf DA'nın önce ana zincirde ilgili indeks verilerini araması ve ardından indeks verilerini zincir boyunca üçüncü taraf DA'ya aktarması ve verileri depolama köprüsü üzerinden döndürmesi gerekir. Buna karşılık, ana zincir Kalkınma Ajansları verileri doğrudan düğümlerden sorgulayabilir ve bu nedenle daha yüksek veri alma hızlarına sahiptir. Son olarak, ana zincir DA'nın içinde, Sharding yönteminin bloğu birden fazla düğümden çağırması ve orijinal verileri geri yüklemesi gerekir. Sonuç olarak, kısa süreli depolama, parçalama olmadan kısa süreli depolamadan daha yavaştır.

DA katmanı evrenselliği: Ana zincirin DA evrenselliği sıfıra yakındır, çünkü yetersiz depolama alanına sahip bir genel zincirden yetersiz depolama alanına sahip başka bir genel zincire veri aktarmak imkansızdır. Üçüncü taraf Kalkınma Ajanslarında, çözümün çok yönlülüğü ve belirli bir ana zincirle uyumluluğu bir çift çelişkili göstergedir. Örneğin, belirli bir ana zincir için tasarlanmış ana zincire özgü bir DA şemasında, genel zincire uyum sağlamak için düğüm türünde ve ağ konsensüs düzeyinde çok sayıda iyileştirme yapılmıştır, bu nedenle bu iyileştirmeler diğer genel zincirlerle iletişim kurarken büyük bir engel olabilir. Bununla birlikte, üçüncü taraf DA içinde, modüler DA ile karşılaştırıldığında, depolama genel zinciri DA, çok yönlülük açısından daha iyi performans gösterir. Depolama halka açık zinciri DA, daha büyük bir geliştirici topluluğuna ve farklı halka açık zincirlerin durumuna uyum sağlayabilen daha fazla genişleme tesisine sahiptir. Aynı zamanda, depolama genel zinciri DA, diğer genel zincirlerden iletilen bilgileri pasif olarak almak yerine, paket yakalama yoluyla verileri daha aktif bir şekilde elde eder. Bu nedenle, verileri kendi yöntemiyle kodlayabilir, veri akışlarının standartlaştırılmış depolamasını gerçekleştirebilir, farklı ana zincirlerden gelen veri bilgilerinin yönetimini kolaylaştırabilir ve depolama verimliliğini artırabilir.

Depolama çözümü performansının karşılaştırılması, görüntü kaynağı: Kernel Ventures

6. özet

Bu aşamadaki blok zincirleri, Kripto'dan daha kapsayıcı bir Web3'e geçiş yapıyor ve blok zincirinde çok sayıda projeden daha fazlasını getiriyor. Katman 1'de aynı anda çalışan bu kadar çok projeyi barındırmak ve Gamefi ve Socialfi projelerinin deneyimini sağlamak için, Ethereum tarafından temsil edilen Katman 1, TPS'yi iyileştirmek için Rollup'lar ve Blob'lar gibi yöntemleri benimsemiştir. Yeni ortaya çıkan blok zincirleri arasında, yüksek performanslı blok zincirlerinin sayısı da artıyor. Ancak daha yüksek TPS, yalnızca daha yüksek performans değil, aynı zamanda ağ üzerinde daha fazla depolama baskısı anlamına gelir. Devasa tarihsel veriler için, zincir üstü depolama baskısının büyümesine uyum sağlamak için bu aşamada ana zincire ve üçüncü taraflara dayalı çeşitli DA yöntemleri önerilmektedir. Her iyileştirme yönteminin artıları ve eksileri vardır ve farklı bağlamlarda farklı uygulanabilirliği vardır.

Ödeme tabanlı blok zincirleri, geçmiş verilerin güvenliği için son derece yüksek gereksinimlere sahiptir ve özellikle yüksek TPS peşinde koşmazlar. Bu tür bir halka açık zincir hala hazırlık aşamasındaysa, güvenliği sağlarken depolama kapasitesinde büyük bir artış sağlayabilen DankSharding benzeri bir depolama yöntemini benimseyebilirsiniz. Bununla birlikte, Bitcoin gibi oluşturulmuş ve çok sayıda düğüme sahip bir halka açık zincir ise, konsensüs katmanında aceleci iyileştirmeler yapmanın büyük bir riski vardır, bu nedenle güvenlik ve depolama sorunlarını hesaba katmak için zincir dışı depolamada yüksek güvenlikli ana zincir için özel bir DA benimsemek mümkündür. Ancak blok zincirinin işlevselliğinin statik değil, sürekli değiştiğini belirtmekte fayda var. Örneğin, ilk günlerde, Ethereum'un işlevleri esas olarak ödemeler ve varlıkları ve işlemleri basitçe otomatikleştirmek için akıllı sözleşmelerin kullanımı ile sınırlıydı, ancak blok zinciri bölgesinin sürekli genişlemesiyle, Ethereum'a kademeli olarak çeşitli Socialfi ve Defi projeleri eklendi ve Ethereum'un daha kapsamlı bir yönde gelişmesini sağladı. Son zamanlarda, Bitcoin üzerindeki yazıt ekolojisinin patlak vermesiyle birlikte, Bitcoin ağının işlem ücreti Ağustos ayından bu yana yaklaşık 20 kat arttı, bu da Bitcoin ağının bu aşamadaki işlem hızının işlem talebini karşılayamadığını ve tüccarların işlemin mümkün olan en kısa sürede işlenebilmesi için yalnızca işlem ücretini artırabileceğini yansıtıyor. Şimdi, Bitcoin topluluğunun, yüksek ücretleri ve yavaş işlem hızlarını kabul etmek veya işlem hızını artırmak için ağ güvenliğini azaltmak, ancak ödeme sisteminin asıl amacına aykırı olmak için bir değiş tokuş yapması gerekiyor. Bitcoin topluluğu ikincisini seçerse, artan veri baskısı karşısında ilgili depolama şemasının da ayarlanması gerekecektir.

Bitcoin ana ağ işlem ücretleri dalgalanıyor, resim kaynağı: OKLINK

Kapsamlı işlevlere sahip halka açık zincir için, daha yüksek bir TPS arayışına sahiptir ve geçmiş verilerin büyümesi daha da fazladır ve DankSharding benzeri bir çözüm benimseyerek uzun vadede TPS'nin hızlı büyümesine uyum sağlamak zordur. Bu nedenle, verileri depolama için üçüncü taraf bir DA'ya taşımak daha uygundur. Bunlar arasında, ana zincire tahsis edilen DA en yüksek uyumluluğa sahiptir ve yalnızca tek bir genel zincirin depolama sorunu dikkate alınırsa daha avantajlı olabilir. Bununla birlikte, günümüzün Layer1 halka açık zincirinde, zincirler arası varlık transferi ve veri etkileşimi de blok zinciri topluluğunun ortak bir arayışı haline geldi. Tüm blok zinciri ekosisteminin uzun vadeli gelişimini göz önünde bulundurursak, farklı halka açık zincirlerin geçmiş verilerini aynı genel zincirde depolamak, veri alışverişi ve doğrulama sürecindeki birçok güvenlik sorununu ortadan kaldırabilir, bu nedenle modüler DA ve genel zincir DA'yı saklama yolu daha iyi bir seçim olabilir. Yakın evrensellik öncülüğü altında, modüler DA, blok zincirinin DA katmanının hizmetlerini sağlamaya odaklanır ve farklı halka açık zincirlerin verilerinin makul bir şekilde sınıflandırılmasını sağlayabilen ve halka açık zincirlerin depolanmasına kıyasla daha fazla avantaja sahip olan daha rafine endeks veri yönetimi geçmiş verilerini sunar. Bununla birlikte, yukarıdaki şema, son derece riskli olan mevcut halka açık zincir üzerinde konsensüs katmanı ayarlamasının maliyetini hesaba katmamaktadır ve bir sorun olduğunda, sistemik güvenlik açıklarına yol açabilir ve halka açık zincirin topluluk fikir birliğini kaybetmesine neden olabilir. Bu nedenle, blok zinciri ölçeklendirme sürecinde geçici bir çözümse, ana zincirin en basit geçici depolaması daha uygun olabilir. Son olarak, yukarıdaki tartışmalar fiili operasyon sürecindeki performansa dayanmaktadır, ancak bir kamu zincirinin amacı kendi ekolojisini geliştirmek ve daha fazla proje tarafını ve katılımcısını çekmekse, kendi vakfı tarafından desteklenen ve finanse edilen projeleri de tercih edebilir. Örneğin, depolama genel zincir depolama şemasıyla aynı veya hatta biraz daha düşük genel performans durumunda, Ethereum topluluğu, Ethereum ekosistemini geliştirmeye devam etmek için Ethereum Vakfı tarafından desteklenen bir Layer2 projesi olarak EthStorage'ı da tercih edecektir.

Sonuç olarak, günümüz blok zincirlerinin artan karmaşıklığı, daha fazla depolama alanı gereksinimlerini de beraberinde getiriyor. Yeterli Katman 1 doğrulayıcı varsa, geçmiş verilerin tüm ağdaki tüm düğümler tarafından yedeklenmesi gerekmez ve göreceli güvenliği sağlamak için yalnızca belirli bir sayıya kadar yedeklenmesi gerekir. Aynı zamanda, halka açık zincirlerin iş bölümü, fikir birliği ve yürütmeden sorumlu Katman 1, hesaplama ve doğrulamadan sorumlu Rollup ve ardından veri depolama için ayrı bir blok zinciri kullanarak giderek daha ayrıntılı hale geliyor. Her parça, diğerlerinin performansıyla sınırlandırılmadan bir işleve odaklanabilir. Bununla birlikte, güvenlik ve verimlilik arasında bir denge sağlamak için geçmiş verilerin ne kadarının veya yüzde kaçının depolanacağı ve farklı blok zincirleri arasında güvenli birlikte çalışabilirliğin nasıl sağlanacağı, blok zinciri geliştiricilerinin düşünmesi ve sürekli iyileştirmesi gereken bir sorudur. Yatırımcılar için, Ethereum'daki ana zincire adanmış DA projesine dikkat edebilirler, çünkü Ethereum'un bu aşamada etkisini genişletmek için diğer topluluklara güvenmesine gerek kalmayacak kadar destekçisi var. Daha fazla ihtiyaç, kendi topluluklarını iyileştirmek ve geliştirmek ve Ethereum ekosistemine inmek için daha fazla proje çekmektir. Bununla birlikte, Solana ve Aptos gibi takipçi konumundaki halka açık zincirler için, tek zincirin kendisi bu kadar eksiksiz bir ekosisteme sahip değildir, bu nedenle etkisini genişletmek için devasa bir zincirler arası ekosistem oluşturmak için diğer toplulukların güçlerini birleştirmeye daha meyilli olabilir. Bu nedenle, ortaya çıkan Katman 1 için, genel üçüncü taraf Kalkınma Ajansları daha fazla ilgiyi hak ediyor.