Ethereum

Ethereum 2.0 güncellemesiyle birlikte, Ethereum ağının hız ve ölçeklenebilirlik kazanmasını sağlayacak geliştirmelerin yapılabilmesinin önü açılmış oldu. 2024’ün ilk çeyreğinde tamamlanması planlanan Dencun güncellemesi, Ethereum 2.0 yol haritası doğrultusunda planlanmış bir güncellemedir.

Dencun Ne Demek?

Ethereum geliştirmeleri, topluluğun buluşma etkinliklerinin yapıldığı Devcon etkinliklerini misafir eden şehir isimleriyle, yıldız isimlerinin birleşiminden oluşur. Deneb yıldızı ve Cancun şehrinin birleşimiyle geliştirmenin ismi Dencun olmuştur.

Dencun Yükseltmesi Ne Zaman?

Ethereum güncellemeleri, çeşitli testlerin yapılması için öncelikle Testnet ağlarında test edilir.

Dencun güncellemesi 17 Ocak 2024 tarihinde Goerli Testnet ağına, 31 Ocak 2024 tarihinde Sepolia Testnet ağına ve 7 Şubat 2024 tarihinde ise Holesky Testnet ağına başarıyla entegre edildi. Güncellemenin Ethereum blokzincirine (mainnet) entegrasyonu 13 Mart 2024 tarihinde gerçekleşecek.

Ethereum Dencun Ne Sağlar?

Sert çatallanma (Hard Fork) yöntemiyle ağa entegrasyonu planlanan Dencun güncellemesi, içerisinde EIP-1153, EIP-4788, EIP-4844, EIP-5656, EIP-6780, EIP-7044, EIP-7045 ve EIP-7514 numaralı değişim önerilerini barındırmaktadır.

EIP (Ethereum Improval Proposal) Nedir?

EIP, Ethereum ağındaki değişiklik önerilerini temsil eder. EIP hakkında ayrıntılı bilgi için EIP Nedir? yazımıza göz atabilirsiniz

Güncellemenin Detayları

8 adet EIP önerisinden en çok merak uyandıran EIP-4844 kodlu güncellemeyle başlayarak, diğer önerilerin içeriklerine göz atalım.

• EIP-4844:

Ethereum ağı üzerinde çalışan uygulamalar ve Ethereum ağına bağlı Katman 2 (Layer 2) altyapıları, kendi platformlarına dair işlemleri Ethereum’a gönderirken ‘CallData’ adlı fonksiyonu kullanmaktadırlar. Fonksiyon, yüksek talep gördüğü için doğal olarak yüksek komisyon ücreti içerebilmekte ve platformların maliyetini yükseltebilmektedir.

EIP-4844, bu problemi çözmek için Blob adlı yeni bir işlem türünü Ethereum ağına entegre etmeyi amaçlamaktadır. Blob, klasik bir Ethereum işlemi değildir. Klasik bir işleme göre çok daha küçük (128 kb) ve zincir dışında bulunmakta, ancak içerisindeki referans kod sayesinde Ethereum blokzinciriyle senkronize şekilde çalışabilmektedir.

Blob işlemler, içerisinde barındırdığı verileri Ethereum ağındaki bloklara dahil etmek için Blob-Carrying adlı işleme ihtiyaç duymaktadırlar. Blob-Carrying işlemler, temsil ettikleri Blob’a ait verileri barındırırlar. Böylelikle Ethereum ağındaki onaylayıcılar, zincir dışındaki bu verileri okuyabilir ve doğruluğunu teyit edebilirler. Blob-Carrying olmadan, Blob işlemler Ethereum ile senkronize çalışamazlar.

Verilerin dışarıda depolanıp, Blob üzerinden Ethereum ağına getirilmesi mümkün olacağı için özellikle Katman 2 (Layer 2) altyapılarının Blob işlemlerini kullanması beklenmektedir. Böylelikle Calldata fonksiyonuna ek olarak ikinci bir alternatif oluşturulmuş ve platformların Ethereum ağında ödeyecekleri komisyon bedellerinin düşürülmesi amaçlanmıştır.

Blob işlemlerine ait komisyon bilgileri Blob-Carrying işlemi içerisinde bulunmaktadır. Onaylayıcılar, blok içerisine alacakları Blob-Carrying işlemlerinin sıralamasını, en yüksek komisyon verenden en düşük verene doğru yaparlar. Böylelikle Blob işlemler için ayrı bir komisyon fiyatının ve rekabetinin oluşması beklenmektedir.

EIP-4844 sayesinde hem Ethereum ağındaki uygulamaların hem de Katman 2 altyapıların maliyetlerinin düşürülmesi hedeflenmektedir.

• EIP-1153:

Ethereum ağındaki işlemler bazen birden fazla katmanın etkileşime geçmesini gerektirebiliyor. Örneğin, bir akıllı kontrat işlemi yapıldığında, bu işlem bir başka kontratı ve o da bir başka kontratı etkileyebilir. Bu tür durumlarda, katmanlar arasındaki veri iletişimini sağlamanın maliyeti yüksek olabiliyor.

EIP-1153, Transient Storage adlı yeni bir özellik getiriyor. Bu özellik, katmanlar arasındaki iletişimi geçici verilerle sağlıyor. Transient Storage verileri geçici olduğu için işlem sonrasında ağda yer kaplamıyor. Böylelikle çok katmanlı işlemlerin daha düşük komisyonlarla yapılabilmesi ve bunu yaparken de ağın ek veri yüküne maruz kalmaması hedefleniyor.

• EIP-4788:

Ethereum ağını kullanan uygulamalar, işlemlerin doğruluğunu kontrol eden onaylayıcıların kendi aralarında konsensus sağlayıp sağlamadıklarını sürekli olarak kontrol etmek zorundadırlar. Konsensus sağlanıyorsa, ağdaki verilerin güvenilir olduğu ve herhangi bir problem olmadığı anlaşılır.

Bu onayı almak için blokları birbirine bağlayan hash kodlarının uygulamalara aktarılması gerekmektedir. Ancak Ethereum’da işlemleri gerçekleştiren katman ile konsensusu sağlayan katman ayrıdır. Birbirine senkronize çalışan bu iki katman arasındaki veri iletişimi, uygulamalar için her zaman yeterince hızlı olmayabiliyor.

Ethereum ağındaki uygulamalar, konsensus durumunu daha hızlı öğrenmek için Oracle denilen veri merkezlerinden gelen verilere güvenmektedirler. Uygulamalar, tek bir merkeze güvenmemek için birden çok Oracle ile çalışsalar da bu durumun yarattığı olası riskleri çözmek için EIP-4788 geliştirilmiştir.

EIP-4788 sonrasında, ihtiyaç duyulan hash kodu, konsensus katmanında da otomatikman yayınlanacak ve tüm bu hash kodlarının bulunduğu ayrı bir akıllı kontrat oluşturulacak. Ethereum ağının konsensus durumunu onaylamak isteyen uygulamaların Oracle servislerine bağımlılığının bu şekilde azaltılması planlanmaktadır. Bu geliştirmeyle, Ethereum ağının ve ağı kullanan uygulamaların güvenlik ve sürdürülebilirliklerinin pozitif etkilenmesi beklenmektedir.

• EIP-5656:

Ethereum ağındaki bloklardaki veri yapısına efektiflik kazandırmayı amaçlayan EIP-5656, MCOPY adlı yeni bir fonksiyon getiriyor. Bu fonksiyon sayesinde verilerin kopyalanması için kullanılan mevcut kodların yaptığı işlevin tek bir kodla gerçekleştirilmesi planlanmaktadır. Bu sayede, daha az fonksiyon kullanılacağı için işlem ücretlerinin düşürülmesi bekleniyor.

• EIP-6780:

Ethereum ağındaki mevcut SELFDESTRUCT fonksiyonu, geliştiricilerin hatalı veya gereksiz verileri ağdan kaldırması için tasarlanmıştır. Ancak geliştiricilerin yaptığı hatalar, bu fonksiyonun yanlış kullanımının gelecekte istenmeyen sonuçlar oluşturabileceğini ortaya koydu.

EIP-6780, SELFDESTRUCT fonksiyonunun etkisini azaltmayı amaçlamaktadır. Güncelleme sonrasında, kontratlar oluşturulurken bu fonksiyona referans verilip verilmemesi önemli olacak. Referans vererek oluşturulan kontratlar, bu fonksiyonu kullanmaya devam edebilecekler. Referans verilmeden oluşturulan kontratlarda ise fonksiyonun işlevi bulunmayacak. Güncelleme öncesinde yazılan kontratlar ise aynı şekilde çalışmaya devam edecek ve herhangi bir değişiklik olmayacak.

SELFDESTRUCT fonksiyonunun tamamen kaldırılmamasının nedeni, geliştiricilere serbestlik sağlanmasıdır. Daha sonraki aşamalarda ağa entegre edilmesi beklenen Verkle Tree ile bu fonksiyonun tamamen işlevsiz hale getirilmesi beklenmektedir.

• EIP-7044:

Ethereum 2.0 sonrasında ağa ETH kilitleyerek (stake) hem ağın güvenliğine katkı sağlamak hem de pasif gelir elde etmek mümkün hale geldi. ETH kilitleme süreci, teknik bilgisi olmayan kullanıcılar için karmaşık ve tehlikeli olabileceği için bu süreci otomatik hale getiren altyapılar oluşturuldu.

Ağa ETH kilitlemek isteyen kullanıcılar, bu servisleri kullandığında kilitlemek istediği bakiyeyi yönetmesi için aracı olan tarafa güvenmek zorundadır. Güven problemini aşmak amacıyla, ağdaki kilitli tokenleri yönetmek için gerekli olan ‘imzalama anahtarı’ aracının cüzdanında saklanırken, kilitli ETH’leri çekmek için gerekli olan anahtar kullanıcının cüzdanında muhafaza edilmektedir. Böylelikle tokenleri cüzdana geri çekme yetkisi kullanıcının elinde bulunmaktadır.

Bu sisteme rağmen güven probleminde ek geliştirmelere ihtiyaç vardır. Çünkü, kullanıcı kilitli tokenlerini çekmek için anahtarını kullandığında, öncelikle aracının bu isteği kabul edip ağdaki kilitli tokenler için çekme isteğini başlatması gereklidir. Aracının isteği kabul etmeme ve işlemleri başlatmama riskini ortadan kaldırmak için ek bir mekanizma oluşturulmuştur.

Bu mekanizma, kilitli tokenler aracıya devredilirken daha önceden imzalanıp hazırlanmış para çekim isteklerinin kullanıcıya devredilmesini içerir. Böylelikle, aracı işlemi dikkate almasa bile aracının anahtarıyla imzalanmış işlem isteği kullanıcıda olur ve kilitli tokenlerini geri alabilir.

EIP-7044, kullanıcılara verilen bu önceden imzalı onayların, Dencun güncellemesi sonrasında da işlerliğini korumasını sağlamayı amaçlamaktadır. Dencun güncellemesi, sert çatallanma ile ağa entegre edileceği için bu tür onaylar normalde işlevini yitirecekti. EIP-7044 sayesinde kullanıcıların mağdur olmaması ve platformların karmaşa içerisine girmemesi hedeflenmektedir.

• EIP-7045:

Ethereum ağındaki işlemlerin bloklara işlenmesi ve blokların birbirlerine eklenmesi görevini ağdaki onaylayıcılar üstlenir. Onaylayıcılar, onayladıkları işlemlerin ve blokların doğruluğunu teyit ederler, bir nevi oy verirler. Sıradaki blok seçilirken, en çok onay alan blok seçilir.

EIP-7045, sıradaki blok belirlenirken onaylayıcılara ek olarak 1 oy hakkı daha tanımlanmasını sağlıyor. Böylelikle, onay sayılarının artmasıyla, en çok oyu alan blok seçiminin daha geniş bir kümede yapılması planlanmıştır. Kümenin genişlemesi, seçimin daha hızlı yapılmasını sağlayacağı için ağın hızının artması hedeflenmiştir.

Ethereum ağında, her 32 slotluk (30.000 blok) bölüm Epoch olarak adlandırılır ve zamanlamalar genellikle Epoch cinsinden belirlenir. Bu güncellemeyi Epoch cinsinden anlatmak gerekirse, normalde Epoch başına 32 oy hakkı olan onaylayıcılar, güncelleme sonrasında arzu ederlerse Epoch başına 64 oy kullanabilecekler.

• EIP-7514:

Ethereum ağında, işlemleri onaylamak için ağa dahil olmak isteyen yeni onaylayıcılar, bir sonraki Epoch’u beklemek zorundadır. Her bir Epoch’da minimum 3 yeni onaylayıcı sürece dahil olabilir. Üst sınır ise kademeli şekilde artmaktadır ve herhangi bir limite sahip değildir.

Onaylayıcı sayısının fazla olması, ağın merkeziyetsizliğini ve verilerin doğruluğunu arttırdığı gibi, onaylayıcı sayısındaki devasa artışlar ağı şişirmeye ve karmaşıklıkların yaşanmasına sebep olabilmektedir.

EIP-7514, her bir Epoch’da sürece dahil olabilecek onaylayıcı sayısını 8 ile sınırlamayı hedeflemektedir. Böylelikle, mevcut üst limit artışına izin verilmeyecek ve Epoch içerisindeki onaylayıcı artışı tahmin edilebilir seviyelerde olacaktır. Ağda yaşanabilecek olası karmaşıklıkların önceden tespitinin yapılması ve gerektiğinde kapasiteyle ilgili önlemlerin alınabilmesi hedeflenmektedir.