Ethereum protokolü, EIP-4844 ile blob işlemlerinin tanıtılmasından bu yana en önemli ölçeklendirme güncellemesinden geçiyor. Fusaka güncellemesinin bir parçası olarak PeerDAS, blob verilerini işlemenin yeni bir yolunu sunarak katman 2'ler (l2) için veri kullanılabilirliği (DA) kapasitesinde yaklaşık bir büyüklük mertebesinde artış sağlar.
Blob ölçeklendirme yol haritası hakkında daha fazlası (opens in a new tab)
Ölçeklenebilirlik
Ethereum'un vizyonu, dünyadaki herkes için erişilebilir olan tarafsız, güvenli ve merkeziyetsiz bir platform olmaktır. Ağ kullanımı arttıkça bu, ağın ölçek, güvenlik ve merkeziyetsizlik üçlemini (trilemma) dengelemeyi gerektirir. Ethereum, mevcut tasarımı içinde ağ tarafından işlenen verileri basitçe artırsaydı, merkeziyetsizliği için güvendiği düğümleri aşırı yükleme riskiyle karşı karşıya kalırdı. Ölçeklenebilirlik, ödünleşimleri (trade-offs) en aza indiren titiz bir mekanizma tasarımı gerektirir.
Bu hedefe ulaşma stratejilerinden biri, tüm işlemleri Ana Ağ üzerinde işlemek yerine çeşitli bir katman 2 ölçeklendirme çözümleri ekosistemine izin vermektir. veya toplamalar, işlemleri kendi ayrı zincirlerinde işler ve doğrulama ile güvenlik için Ethereum'u kullanır. Yalnızca güvenlik açısından kritik taahhütleri yayınlamak ve yükleri sıkıştırmak, l2'lerin Ethereum'un DA kapasitesini daha verimli kullanmasını sağlar. Buna karşılık l1, güvenlik garantilerinden ödün vermeden daha az veri taşırken, l2'ler daha düşük gaz maliyetleriyle daha fazla kullanıcıyı sisteme dahil eder. Başlangıçta l2'ler, verileri sıradan işlemlerde calldata olarak yayınlıyordu; bu da gaz için l1 işlemleriyle rekabet ediyordu ve toplu veri kullanılabilirliği için pratik değildi.
Proto-Danksharding
L2'yi ölçeklendirmeye yönelik ilk büyük adım, Proto-Danksharding'i (EIP-4844) tanıtan Dencun güncellemesiydi. Bu güncelleme, toplamalar için blob adı verilen yeni ve özel bir veri türü oluşturdu. Blob'lar veya ikili büyük nesneler (binary large objects), EVM yürütmesine ihtiyaç duymayan ve düğümlerin yalnızca sınırlı bir süre için depoladığı geçici rastgele veri parçalarıdır. Bu daha verimli işleme, l2'lerin Ethereum'a daha fazla veri yayınlamasına ve daha da ölçeklenmesine olanak tanıdı.
Ölçeklendirme için halihazırda güçlü faydaları olmasına rağmen, blob'ları kullanmak nihai hedefin yalnızca bir parçasıdır. Mevcut protokolde, ağdaki her düğümün hala her blob'u indirmesi gerekir. Darboğaz, daha yüksek blob sayılarıyla doğrudan artan indirilmesi gereken veri miktarı ile birlikte, bireysel düğümlerin ihtiyaç duyduğu bant genişliği haline gelir.
Ethereum merkeziyetsizlikten ödün vermez ve bant genişliği en hassas ayarlardan biridir. Güçlü bilgi işlem gücü, bunu karşılayabilen herkes için yaygın olarak mevcut olsa bile, gelişmiş ülkelerdeki (Almanya (opens in a new tab), Belçika (opens in a new tab), Avustralya (opens in a new tab) veya Amerika Birleşik Devletleri (opens in a new tab) gibi) oldukça kentsel şehirlerde bile yükleme bant genişliği sınırlamaları (opens in a new tab), bant genişliği gereksinimleri dikkatlice ayarlanmazsa düğümleri yalnızca veri merkezlerinden çalıştırılabilecek şekilde kısıtlayabilir.
Düğüm operatörleri, blob'lar arttıkça giderek daha yüksek bant genişliği ve disk alanı gereksinimlerine sahip olur. Blob'ların boyutu ve miktarı bu kısıtlamalarla sınırlıdır. Her blob, blok başına ortalama 6 blob ile 128 kb'a kadar veri taşıyabilir. Bu, blob'ları daha da verimli bir şekilde kullanan gelecekteki bir tasarıma doğru atılan yalnızca ilk adımdı.
Veri kullanılabilirliği örneklemesi
Veri kullanılabilirliği, zinciri bağımsız olarak doğrulamak için gereken tüm verilerin tüm ağ katılımcıları tarafından erişilebilir olduğunun garantisidir. Verilerin tam olarak yayınlandığından ve zincirin yeni durumunu veya gelen işlemleri güvene dayalı olmadan (trustlessly) doğrulamak için kullanılabileceğinden emin olmayı sağlar.
Ethereum blob'ları, l2'lerin güvenliğini sağlayan güçlü bir veri kullanılabilirliği garantisi sunar. Bunu yapmak için Ethereum düğümlerinin blob'ları bütünüyle indirmesi ve depolaması gerekir. Peki ya blob'ları ağda daha verimli bir şekilde dağıtabilir ve bu sınırlamadan kaçınabilirsek?
Verileri depolamak ve kullanılabilirliğini sağlamak için farklı bir yaklaşım veri kullanılabilirliği örneklemesidir (DAS). Ethereum çalıştıran her bilgisayarın her bir blob'u tamamen depolaması yerine DAS, merkeziyetsiz bir iş bölümü sunar. Daha küçük, yönetilebilir görevleri tüm düğüm ağına dağıtarak verileri işleme yükünü hafifletir. Blob'lar parçalara bölünür ve her düğüm, tüm düğümler arasında tekdüze rastgele dağıtım için bir mekanizma kullanarak yalnızca birkaç parça indirir.
Bu yeni bir sorunu beraberinde getirir: verilerin kullanılabilirliğini ve bütünlüğünü kanıtlamak. Bireysel düğümler yalnızca küçük parçalar tutarken ağ, verilerin kullanılabilir olduğunu ve hepsinin doğru olduğunu nasıl garanti edebilir? Kötü niyetli bir düğüm sahte veriler sunabilir ve güçlü veri kullanılabilirliği garantilerini kolayca bozabilir! İşte bu noktada kriptografi yardıma koşar.
Verilerin bütünlüğünü sağlamak için EIP-4844 halihazırda KZG taahhütleri ile uygulanmıştı. Bunlar, ağa yeni bir blob eklendiğinde oluşturulan kriptografik kanıtlardır. Her bloğa küçük bir kanıt dahil edilir ve düğümler, alınan blob'ların bloğun KZG taahhüdüne karşılık geldiğini doğrulayabilir.
DAS, bunun üzerine inşa edilen ve verilerin hem doğru hem de kullanılabilir olmasını sağlayan bir mekanizmadır. Örnekleme, bir düğümün verilerin yalnızca küçük bir bölümünü sorguladığı ve bunu taahhüde karşı doğruladığı bir süreçtir. KZG, polinom eğrisi üzerindeki herhangi bir tek noktanın doğrulanabileceği anlamına gelen bir polinom taahhüt şemasıdır. Örneklemeyi yapan istemci, polinom üzerinde yalnızca birkaç noktayı kontrol ederek verilerin kullanılabilir olduğuna dair güçlü bir olasılıksal garantiye sahip olabilir.
PeerDAS
PeerDAS (EIP-7594) (opens in a new tab), Ethereum'da DAS mekanizmasını uygulayan ve muhtemelen Birleşme'den bu yana en büyük güncellemeyi işaret eden özel bir tekliftir. PeerDAS, blob verilerini genişletmek, sütunlara bölmek ve bir alt kümeyi düğümlere dağıtmak için tasarlanmıştır.
Ethereum bunu başarmak için bazı zekice matematiksel yöntemler ödünç alır: blob verilerine Reed-Solomon tarzı silme kodlaması uygular. Blob verileri, katsayıları verileri kodlayan bir polinom olarak temsil edilir, ardından genişletilmiş bir blob oluşturmak için bu polinomu ek noktalarda değerlendirerek değerlendirme sayısını iki katına çıkarır. Eklenen bu yedeklilik, silme kurtarmasını (erasure recovery) mümkün kılar: bazı değerlendirmeler eksik olsa bile, genişletilmiş parçalar da dahil olmak üzere toplam verinin en az yarısı mevcut olduğu sürece orijinal blob yeniden oluşturulabilir.
Gerçekte, bu polinomun binlerce katsayısı vardır. KZG taahhütleri, tüm düğümler tarafından bilinen, hash gibi birkaç baytlık değerlerdir. Yeterli veri noktasına sahip her düğüm, tam bir blob veri setini verimli bir şekilde yeniden oluşturabilir (opens in a new tab).
İlginç bilgi: Aynı kodlama tekniği DVD'ler tarafından da kullanılıyordu. Bir DVD'yi çizdiğinizde, polinomun eksik parçalarını ekleyen Reed-Solomon kodlaması sayesinde oynatıcı onu hala okuyabiliyordu.
Tarihsel olarak, blok zincirlerindeki veriler, ister blok ister blob olsun, tüm düğümlere yayınlanırdı. PeerDAS'ın böl ve örnekle yaklaşımıyla, her şeyi herkese yayınlamak artık gerekli değildir. Fusaka sonrasında, mutabakat katmanı ağı dedikodu konuları/alt ağları (gossip topics/subnets) şeklinde düzenlenir: blob sütunları belirli alt ağlara atanır ve her düğüm önceden belirlenmiş alt kümelere abone olur ve yalnızca bu parçaları muhafaza eder.
PeerDAS ile genişletilmiş blob verileri, sütun adı verilen 128 parçaya bölünür. Veriler, abone oldukları belirli alt ağlardaki özel bir dedikodu protokolü aracılığıyla bu düğümlere dağıtılır. Ağdaki her normal düğüm, rastgele seçilmiş en az 8 sütun alt ağına katılır. 128 alt ağdan yalnızca 8'inden veri almak, bu varsayılan düğümün tüm verilerin yalnızca 1/16'sını aldığı anlamına gelir, ancak veriler genişletildiği için bu, orijinal verilerin 1/8'idir.
Bu, mevcut "herkes her şeyi indirir" şemasının 8 katı olan yeni bir teorik ölçeklendirme sınırına olanak tanır. Blob sütunlarına hizmet veren farklı rastgele alt ağlara abone olan düğümlerle, bunların tekdüze bir şekilde dağıtılma olasılığı çok yüksektir ve bu nedenle her veri parçası ağın bir yerinde mevcuttur. Doğrulayıcı çalıştıran düğümlerin, çalıştırdıkları her doğrulayıcı ile daha fazla alt ağa abone olmaları gerekir.
Her düğümün rastgele oluşturulmuş benzersiz bir kimliği (ID) vardır, bu normalde bağlantılar için genel kimliği olarak hizmet eder. PeerDAS'ta bu sayı, abone olması gereken rastgele alt ağ kümelerini belirlemek için kullanılır ve bu da tüm blob verilerinin tekdüze rastgele dağılımıyla sonuçlanır.
Bir düğüm orijinal verileri başarıyla yeniden oluşturduğunda, kurtarılan sütunları ağa geri dağıtarak veri boşluklarını aktif olarak iyileştirir ve genel sistem dayanıklılığını artırır. Toplam bakiyesi ≥4096 ETH olan doğrulayıcılara bağlı düğümler bir süper düğüm (supernode) olmalıdır ve bu nedenle tüm veri sütunu alt ağlarına abone olmalı ve tüm sütunları muhafaza etmelidir. Bu süper düğümler veri boşluklarını sürekli olarak iyileştirecektir. Protokolün olasılıksal olarak kendi kendini iyileştiren doğası, verilerin yalnızca bir kısmını tutan ev operatörlerini sınırlamazken güçlü kullanılabilirlik garantilerine olanak tanır.
Veri kullanılabilirliği, yukarıda açıklanan örnekleme mekanizması sayesinde blob verilerinin yalnızca küçük bir alt kümesini tutan herhangi bir düğüm tarafından onaylanabilir. Bu kullanılabilirlik zorunlu kılınmıştır: doğrulayıcılar yeni çatallanma seçimi (fork-choice) kurallarına uymalıdır, yani blokları yalnızca verilerin kullanılabilirliğini doğruladıktan sonra kabul edecek ve onlar için oy vereceklerdir.
Kullanıcılar (özellikle l2 kullanıcıları) üzerindeki doğrudan etki daha düşük ücretlerdir. Rollup verileri için 8 kat daha fazla alanla, kullanıcıların kendi zincirlerindeki işlemleri zamanla daha da ucuz hale gelir. Ancak Fusaka sonrası daha düşük ücretler zaman alacaktır ve BPO'lara bağlı olacaktır.
Yalnızca Blob Parametresi (BPO'lar)
Ağ teorik olarak 8 kat daha fazla blob işleyebilecektir, ancak blob artışları düzgün bir şekilde test edilmesi ve adım adım güvenli bir şekilde yürütülmesi gereken bir değişikliktir. Test ağları, özellikleri Ana Ağ'da dağıtmak için yeterli güveni sağlar, ancak önemli ölçüde daha yüksek sayıda blob'u etkinleştirmeden önce p2p ağının kararlılığından emin olmamız gerekir.
Ağı aşırı yüklemeden blok başına hedeflenen blob sayısını kademeli olarak artırmak için Fusaka, Yalnızca Blob Parametresi (BPO) (opens in a new tab) çatallanmalarını sunar. Geniş ekosistem koordinasyonu, anlaşma ve yazılım güncellemeleri gerektiren normal çatallanmaların aksine, BPO'lar (EIP-7892) (opens in a new tab), müdahale olmadan zaman içinde maksimum blob sayısını artıran önceden programlanmış güncellemelerdir.
Bu, Fusaka etkinleştirildikten ve PeerDAS yayına girdikten hemen sonra blob sayısının değişmeden kalacağı anlamına gelir. Geliştiriciler mekanizmanın beklendiği gibi çalıştığından ve ağı çalıştıran düğümler üzerinde olumsuz etkileri olmadığından emin olmak için izlerken, blob sayısı maksimum 48'e ulaşana kadar birkaç haftada bir ikiye katlanmaya başlayacaktır.
Gelecekteki yönelimler
PeerDAS, FullDAS'ın veya danksharding'in daha büyük bir ölçeklendirme vizyonuna doğru (opens in a new tab) atılmış sadece bir adımdır. PeerDAS her bir blob'a ayrı ayrı 1B (1D) silme kodlaması kullanırken, tam danksharding tüm blob veri matrisi boyunca daha eksiksiz bir 2B (2D) silme kodlaması şeması kullanacaktır. Verileri iki boyutta genişletmek, daha da güçlü yedeklilik özellikleri ve daha verimli yeniden oluşturma ve doğrulama yaratır. FullDAS'ı gerçekleştirmek, ek araştırmalarla birlikte önemli ağ ve protokol optimizasyonları gerektirecektir.
Daha fazla okuma
- PeerDAS: Francesco D'Amato'dan Eşler Arası Veri Kullanılabilirliği Örneklemesi (Peer Data Availability sampling) (opens in a new tab)
- Ethereum'un PeerDAS'ının Bir Dokümantasyonu (opens in a new tab)
- AGM Olmadan PeerDAS'ın Güvenliğini Kanıtlamak (opens in a new tab)
- Vitalik'in PeerDAS, etkisi ve Fusaka'yı test etme üzerine yazısı (opens in a new tab)
Sayfanın son güncellenme tarihi: 22 Nisan 2026

