Ethereum ağ yükseltmesi Dencun testnet sürümü 17 Ocak 2024'te Goerli testnetinde başlatıldı ve Sepolia testnet 30 Ocak'ta başarıyla başlatıldı. Dencun güncellemesi gittikçe yaklaşıyor.

Holesky testnet yükseltmesinin ardından 7 Şubat'ta ana ağ yükseltmesi yapılacak. Cancun yükseltmesinin ana ağ lansmanı resmi olarak 13 Mart 2024 tarihinde belirlenmiştir.

Neredeyse her Ethereum yükseltmesine önemli piyasa trendleri eşlik ediyor. Şangay yükseltmesi olarak bilinen 12 Nisan 2023'teki son yükseltmeye bakıldığında, Proof-of-Stake (PoS) ile ilgili projelerin artan piyasa talebi ile karşılaştığı görülmektedir.

Önceki deneyimleri takip edersek, yaklaşan Dencun yükseltmesi öncesinde stratejik konumlandırma için muhtemelen fırsatlar olacaktır.

Bununla birlikte, Dencun yükseltmesinin içerdiği teknik karmaşıklık nedeniyle, "Ethereum PoW'dan PoS'a geçiyor" gibi tek bir cümleyle Şangay yükseltmesi kadar kısa ve öz bir şekilde özetlenemez. Bu karmaşıklık, stratejik konumlandırma için odak noktalarının kavranmasını zorlaştırmaktadır.

Bu nedenle, bu makale Dencun yükseltmesinin teknik detaylarını basit ve anlaşılır bir dille açıklamayı amaçlamaktadır. Bu kitap, veri kullanılabilirliği (DA), Katman 2 çözümleri ve diğer ilgili hususlarla olan bağlantılarını vurgulayarak okuyuculara bu yükseltmenin incelikleri konusunda rehberlik edecektir.

01. EIP 4484

EIP-4844, Dencun yükseltmesindeki en önemli teklif olarak öne çıkmakta ve Ethereum'un merkezi olmayan ölçeklendirme yolculuğunda önemli bir adımı işaret etmektedir.

Daha basit bir ifadeyle, mevcut Ethereum Katman 2 çözümleri, Katman 2'de gerçekleşen işlemlerin Ethereum ana ağının calldata'sına gönderilmesini gerektirmektedir. Bu çağrı verileri daha sonra düğümler tarafından Katman 2 ağındaki blokların geçerliliğini doğrulamak için kullanılır.

Bununla birlikte, işlem verilerini sıkıştırma çabalarına rağmen, Ethereum ana ağındaki yüksek depolama maliyetleriyle çarpılan Katman 2'deki önemli işlem hacmi, Katman 2 düğümlerine ve kullanıcılarına hala önemli masraflar getirdiğinden, bu yaklaşım zorlukları beraberinde getirmektedir. Tek başına bu yüksek maliyet bile kullanıcıların yan zincirlere geçmesine yol açabilir.

EIP-4844, İkili Büyük Nesne (BLOB) adı verilen yeni bir depolama alanı türü oluşturarak uygun maliyetli bir çözüm sunar. Yükseltmeden önce calldata'da depolanan işlem verilerinin yerini almak üzere "BLOB-Taşıyan İşlem" olarak bilinen yeni bir işlem türü getirmektedir. Bu yenilikçi yaklaşım, Ethereum Katman 2 ekosisteminin gaz maliyeti tasarrufu sağlamasına yardımcı olur.

BLOB Depolama Neden Uygun Maliyetlidir?

Hepimizin bildiği gibi, maliyet verimliliği genellikle bir değiş tokuşla birlikte gelir. BLOB verilerinin benzer büyüklükteki normal Ethereum çağrı verilerine kıyasla daha düşük maliyetlere neden olmasının nedeni, Ethereum Yürütme Katmanının (EL) BLOB verilerinin kendisine doğrudan erişememesidir.

Bunun yerine, EL yalnızca BLOB verilerine referanslara erişebilir ve BLOB'un gerçek verileri yalnızca Ethereum Consensus Layer (CL, işaret düğümleri olarak da bilinir) tarafından indirilebilir ve saklanabilir. BLOB verilerini depolamak için bellek ve hesaplama gereksinimleri, normal Ethereum çağrı verilerinden önemli ölçüde daha düşüktür.

Ayrıca, BLOB'un ayırt edici bir özelliği vardır - yalnızca sınırlı bir süre için (genellikle yaklaşık 18 gün) saklanabilir ve Ethereum defterinin boyutu gibi sonsuza kadar genişlemez.

BLOB Depolamanın Geçerlilik Süresi

Blockchain'in kalıcı defterinin aksine BLOB'lar 4.096 epok ya da yaklaşık 18 gün boyunca kullanılabilen geçici depolama alanlarıdır.

Süre dolduktan sonra, çoğu mutabakat istemcisi BLOB'daki belirli verileri alamayacaktır. Bununla birlikte, önceki varlığının kanıtı KZG taahhütleri şeklinde ana ağda kalacak ve Ethereum ana ağında kalıcı olarak saklanacaktır.

Neden 18 gün? Bu, depolama maliyeti ile etkinlik arasında bir değiş tokuştur.

Her şeyden önce, bu yükseltmenin en sezgisel faydalanıcılarını, iyimser toparlamaları (Arbitrum ve Optimism gibi) göz önünde bulundurmalıyız, çünkü Optimistic Rollups'ta 7 günlük bir Sahtekarlık Kanıtı zaman penceresi vardır. Blob'da depolanan işlem verileri, Optimistic Rollups'ın bir meydan okuma başlatırken tam olarak ihtiyaç duyduğu şeydir.

Bu nedenle, Blob'un geçerlilik süresi Optimistic Rollups Fraud Proof'un erişilebilir olmasını sağlamalıdır. Basitlik adına, Ethereum topluluğu 12'nin gücüne 2'yi seçti (4.096 epok 2^12'den türetilir ve bir epok yaklaşık 6,4 dakikadır).

BLOB Taşıyan İşlem ve BLOB

Bu ikisi arasındaki ilişkiyi anlamak, BLOB'ların veri kullanılabilirliğindeki (DA) rolünü anlamak açısından önemlidir.

İlki genel EIP-4484 önerisidir ve yeni bir işlem türüdür, ikincisi ise katman 2 işlemleri için geçici bir depolama yeri olarak anlaşılabilir.

İkisi arasındaki ilişki, ilkindeki verilerin çoğunun (katman 2 işlem verileri) ikincisinde depolandığı şeklinde anlaşılabilir. Kalan veriler, yani BLOB veri taahhüdü, ana ağın calldata'sında saklanacaktır. Başka bir deyişle, vaatler EVM tarafından okunabilir.

Taahhüt, BLOB'daki tüm işlemlerin bir Merkle ağacına dönüştürülmesi olarak düşünülebilir ve daha sonra sözleşme tarafından yalnızca Merkle köküne, yani Taahhüde erişilebilir.

Bu akıllıca başarılabilir: EVM BLOB'un belirli içeriğini bilemese de, EVM sözleşmesi Taahhüdü bilerek işlem verilerinin gerçekliğini doğrulayabilir.

02. BLOB ve Katman 2 Arasındaki İlişki

Rollup teknolojisi, Ethereum ana ağına veri yükleyerek veri kullanılabilirliği (DA) sağlar, ancak L1'in akıllı sözleşmelerinin yüklenen bu verileri doğrudan okuması veya doğrulaması amaçlanmamıştır.

İşlem verilerinin L1'e yüklenmesinin amacı basitçe tüm katılımcıların verileri görüntülemesine olanak sağlamaktır.

Dencun yükseltmesinden önce, yukarıda belirtildiği gibi, Optimistic Rollups işlem verilerini calldata olarak Ethereum'a yayınlayacaktır. Bu nedenle, herhangi biri bu işlem bilgilerini durumu yeniden üretmek ve Katman 2 ağının doğruluğunu doğrulamak için kullanabilir.

Toplama işlem verilerinin ucuz, açık ve şeffaf olması gerektiğini görmek zor değildir. Calldata, özellikle Katman 2 için işlem verilerini depolamak için iyi bir yer değildir ve BLOB-Taşıyan İşlem, Toplama için özel olarak üretilmiştir.

Bu noktada, işlem verilerinin önemini merak edebilirsiniz.

Gerçekte, işlem verileri yalnızca belirli senaryolarda kullanılır:

• Güven varsayımına dayanan İyimser Toplama için sahtekârlık olasılığı vardır. Bu gibi durumlarda, rollup tarafından yüklenen işlem kayıtları kullanışlı hale gelir ve kullanıcıların dolandırıcılık kanıtlarını başlatmasını sağlar.
• ZK Toplama için, sıfır bilgi kanıtı durum güncellemesinin doğru olduğunu kanıtlamıştır. Verilerin yüklenmesi yalnızca kullanıcıların tüm durumu kendi başlarına hesaplamalarına izin vermek içindir. Katman 2 düğümü düzgün çalışamadığında, eksiksiz bir L2 durum ağacı gerektiren kaçış kapağı mekanizması etkinleştirilir. Bu konu, bu makalenin son bölümünde ele alınacaktır.

Bu durum, işlem verilerinin sözleşmeler tarafından fiili kullanımının çok sınırlı olduğu anlamına gelmektedir. Optimistic Rollup'ın dolandırıcılık kanıtlarında bile, yalnızca işlem verilerinin belirli bir anda "var olduğunun" kanıtlanması gerekir ve her işlemin ayrıntılarını ana ağda önceden saklamaya gerek yoktur.

İşlem verilerini BLOB'a yerleştirerek, sözleşmeler tarafından erişilemez olmasına rağmen, ana ağ sözleşmesi BLOB'un taahhüdünü saklayabilir.

Sahteciliği kanıtlama mekanizması gelecekte belirli bir işleme ihtiyaç duyarsa, eşleştiği sürece bu işlemin verilerini sağlamak sözleşmeyi ikna edebilir ve sahteciliği kanıtlama mekanizması için işlem verilerini sağlayabilir.

Bu sadece işlem verilerinin açıklığından ve şeffaflığından yararlanmakla kalmaz, aynı zamanda tüm verileri sözleşmeye önceden girmenin büyük gaz maliyetini de önler.

Yalnızca taahhüdün kaydedilmesiyle işlem verileri doğrulanabilir hale gelirken maliyetler de büyük ölçüde optimize edilir. Bu, Rollup teknolojisini kullanarak işlem verilerini yüklemek için akıllı ve etkili bir çözümdür.

Dencun'un gerçek çalışmasında, Celestia'ya benzer Merkle ağacının taahhüt oluşturmak için kullanılmadığı, ancak KZG (Kate-Zaverucha-Goldberg, Polynomial Commitment) algoritmasının kullanıldığı belirtilmelidir.

Merkle ağacı ispatı ile karşılaştırıldığında, KZG İspatı oluşturma süreci nispeten karmaşıktır, ancak doğrulama hacmi daha küçüktür ve doğrulama adımları daha basittir. Ancak dezavantajı, güvenilir ayarlar gerektirmesidir (ceremony.ethereum.org, artık sona ermiştir) ve kuantum hesaplama saldırılarını önleme yeteneğine sahip değildir (Dencun Version Hash yöntemini kullanır ve gerekirse diğer doğrulama yöntemleri değiştirilebilir).

Şu anda popüler olan DA projesi Celestia için Merkle ağacının bir varyantını kullanmaktadır. KZG'nin aksine, bir dereceye kadar düğümlerin bütünlüğüne dayanır, ancak ağın merkezi olmayan doğasını koruyarak düğümler arasındaki hesaplama kaynağı eşiğini düşürmeye yardımcı olur.

03. Dencun'daki Fırsatlar

EIP-4844, Katman 2 için maliyetleri azaltıp verimliliği artırırken, güvenlik risklerini de artırıyor ve bu da yeni fırsatları beraberinde getiriyor.

Bunun nedenini anlamak için, yukarıda bahsedilen kaçış kapağı mekanizmasına veya zorla geri çekilme mekanizmasına geri dönmemiz gerekiyor.

Katman 2 düğümü devre dışı bırakıldığında, bu mekanizma kullanıcı fonlarının güvenli bir şekilde ana ağa iade edilmesini sağlayabilir. Bu mekanizmayı etkinleştirmek için ön koşul, kullanıcının Katman 2'nin tüm durum ağacını elde etmesi gerektiğidir.

Normal koşullar altında, kullanıcıların veri talep etmek için yalnızca bir Katman 2 tam düğümü bulmaları, merkle kanıtı oluşturmaları ve ardından para çekme işlemlerinin meşruiyetini kanıtlamak için bunu ana ağ sözleşmesine göndermeleri gerekir.

Ancak kullanıcının L2'den çıkmak için kaçış kapağı mekanizmasını etkinleştirmek istediğini unutmayın çünkü L2 düğümleri kötü niyetli davranmıştır. Böyle bir durumda, düğümlerden istedikleri verileri alamama olasılıkları yüksektir.

Bu, Vitalik'in sıklıkla veri saklama saldırısı olarak adlandırdığı şeydir.

EIP-4844'ten önce, kalıcı Katman 2 kayıtları ana ağa kaydedilirdi. Hiçbir Katman 2 düğümü tam zincir dışı durum sağlayamadığında, kullanıcılar tam bir düğümü kendileri dağıtabilir.

Bu tam düğüm, Ethereum ana ağı aracılığıyla ana ağdaki Katman 2 sıralayıcı tarafından yayınlanan tüm geçmiş verileri elde edebilir. Kullanıcılar gerekli Merkle kanıtını oluşturabilir ve L2 varlık çekimini güvenli bir şekilde tamamlamak için kanıtı ana ağdaki sözleşmeye gönderebilir.

EIP-4844'ten sonra, Katman 2 verileri yalnızca Ethereum tam düğümlerinin BLOB'unda bulunur ve 18 günden önceki geçmiş veriler otomatik olarak silinir.

Bu nedenle, ana ağı senkronize ederek tüm durum ağacını elde etmek için önceki paragraftaki yöntem artık uygulanabilir değildir. Katman 2'nin tüm durum ağacını elde etmek istiyorsanız, yalnızca tüm Ethereum BLOB verilerini (18 gün sonra otomatik olarak silinmiş olması gerekir) depolayan üçüncü taraf ana ağ düğümlerine veya Katman 2 yerel düğümlerine (nadirdir) güvenebilirsiniz.

EIP-4844 yayına girdikten sonra, kullanıcıların Katman 2'nin tüm durum ağacını tamamen güvenilir bir şekilde elde etmeleri çok zor olacaktır.

Kullanıcıların Katman 2 durum ağacını elde etmeleri için istikrarlı bir yol olmadan, aşırı koşullar altında zorla geri çekme işlemlerini gerçekleştiremezler. Bu nedenle EIP-4844, Katman 2 için bir ölçüde güvenlik eksikliği haline gelmiştir.

Bu güvenlik eksikliğini telafi etmek için, pozitif bir ekonomik döngüye sahip, güvenilir bir depolama çözümüne ihtiyacımız var. Buradaki depolama, esas olarak Ethereum'daki verilerin güvene dayalı olmayan bir şekilde tutulması anlamına gelmektedir; bu da geçmişteki depolama alanından farklıdır çünkü bu durumda "güvene dayalı olmayan" bir anahtar kelime vardır.

Ethstorage güvenilmezlik sorununu çözebilir ve Ethereum Vakfı'ndan iki tur fon almıştır.

Aslında bu konsept, Dencun güncellemesinin getirdiği potansiyeli gerçekten karşılayabilir ve dikkatimizi çekmeye değer.

Ethstorage'ın en sezgisel önemi, DA BLOB'un kullanılabilir süresini tamamen merkezi olmayan bir şekilde uzatabilmesi ve EIP-4844'ten sonra Katman 2 güvenliğinin eksikliklerini telafi edebilmesidir.

Ayrıca, mevcut L2 çözümlerinin çoğu temel olarak Ethereum'un hesaplama gücünü ölçeklendirmeye, yani TPS'yi artırmaya odaklanmaktadır. Ancak, özellikle NFTs ve DeFi gibi dApp'lerin popülerliği nedeniyle Ethereum ana ağında büyük miktarda verinin güvenli bir şekilde depolanmasına yönelik talep artmıştır.

Örneğin, zincir üzerindeki NFT'lerin depolanmasına yönelik talep çok büyüktür, çünkü kullanıcılar yalnızca NFT sözleşmelerinin tokenlarına değil, aynı zamanda zincir üzerindeki görüntüye de sahiptir. Ethstorage, bu görüntülerin üçüncü bir tarafta saklanmasıyla ortaya çıkan ek güven sorunlarını çözebilir.

Son olarak Ethstorage, merkezi olmayan dApp'lerin ön uç ihtiyaçlarını da çözebilir. Şu anda mevcut çözümler öncelikle merkezi sunucular tarafından barındırılmaktadır (DNS ile). Bu kurulum, web sitelerini sansüre ve Tornado Cash gibi olaylarda görüldüğü gibi DNS ele geçirme, web sitesi korsanlığı veya sunucu çökmeleri gibi diğer sorunlara karşı savunmasız hale getirir.

Ethstorage hala ilk test aşamasındadır ve bu yolun beklentileri konusunda iyimser olan kullanıcılar deneyebilir.

Sorumluluk Reddi：

1. Bu makale[Biteye]'dan yeniden basılmıştır, Tüm telif hakları orijinal yazar[Biteye]'a aittir. Bu baskıya itirazınız varsa, lütfen Gate Learn ekibiyle iletişime geçin, onlar bu konuyu derhal ele alacaklardır.
2. Sorumluluk Reddi: Bu makalede ifade edilen görüş ve fikirler yalnızca yazara aittir ve herhangi bir yatırım tavsiyesi teşkil etmez.
3. Makalenin diğer dillere çevirisi Gate Learn ekibi tarafından yapılmaktadır. Belirtilmediği sürece, çevrilen makalelerin kopyalanması, dağıtılması veya intihal edilmesi yasaktır.