Pectra hard forkunun 2025 yılı Mart ayında ana ağ dağıtımının başlatılması beklenmektedir. Pectra'nın güncellemesi 11 teknik protokol (EIP) içermektedir, bunlar sırasıyla:
EIP-2537: BLS12-381 Curve Operations Precompile
EIP-2935: State'te Geçmiş Blok Hash Değerlerini Saklama
EIP-6110: Zincir üstü doğrulayıcı depozitleri sağlamak
EIP-7002: Yürütme Katmanı Tetikli Çıkış
EIP-7251: the MAX_EFFECTIVE_BALANCE artırıldı
EIP-7549: committee dizinini doğrulamadan çıkarın
EIP-7623: Çağrı verisi maliyetlerini artırın
EIP-7685: Genel Yürütme Katmanı Talebi
EIP-7691: Blob Throughput Artışı
EIP-7702: EOA Hesap Kodunu Ayarla
EIP-7840: EL yapılandırma dosyasına Blob planı ekleme
Staking ile ilgili teknik protokoller
EIP-6110: BLS12-381 Eğrisel İşlem Ön Derleme
Staking işlemine katılımı basitleştirerek bekleme süresini önemli ölçüde kısaltır.
Kullanıcıların staking'e katılma şekli, yürütme katmanına 32 ETH yatırmak ve bunu olay günlüğüne kaydetmektir ve ardından konsensüs katmanı, birinin staking'e katılıp katılmadığını belirlemek için olay günlüğünün analizini gerçekleştirir ve ardından staking'e katılan kullanıcı doğrulayıcı olur.
Bununla birlikte, konsensüs katmanının doğrulayıcılarının öncelikle hangi noktada para yatıracakları konusunda fikir birliğine varmaları gerekir, aksi takdirde bazı doğrulayıcılar 5 yeni mevduat görürken, bazı doğrulayıcılar yalnızca 3 tane görecektir, bu nedenle konsensüs katmanı doğrulayıcıları, herkesin aynı yürütme katmanı bloğunu görmesini sağlamak için hangi yürütme katmanı bloğuna (eth1data) atıfta bulunacaklarına oy verecektir.
Ancak, başlangıçta, büyük hatalara yol açabilecek önemli hataları önlemek için yürütme katmanında bir çatallaşma olmamasını sağlamak için referans alınan yürütme katmanı bloğu (eth1data) yaklaşık 10 saatten önce olacaktır. Bu, önemli bir hata olduğunda, konsensüs katmanı geliştiricilerinin tepki vermek için yeterli zamanı olmasını sağlar, ancak bu aynı zamanda stakingin etkin olması için en az 10 saat beklemeyi gerektirir.
EIP-6110 teknik protokolü yürütüldükten sonra, kullanıcının sözleşmedeki rehin verileri doğrudan yürütme katmanının bir parçası haline gelecektir ve konsensüs katmanı bloğunun kendisi yürütme katmanı bloğunu içereceğinden (ancak eth1data'yı içermediğinden), konsensüs katmanı doğrulayıcılarının artık "referans yürütme katmanı bellek bloğunun aynı olduğunu onaylama" sorununu dikkate almasına gerek yoktur, konsensüs katmanı bellek bloğu doğrulayıcıların üçte ikisinden fazlası tarafından oylandığı sürece, herkes aynı yürütme katmanı bloğu üzerinde bir fikir birliğine varacaktır. Bu nedenle, rehne katıldıktan sonra, kullanıcı yürütme katmanı bellek bloğunun işlemeyi en erken yaklaşık 13 dakika içinde tamamlamasını bekleyebilir ve konsensüs katmanı istemcisi, başlangıçta stake verilerini işlemek için kullanılan karmaşık mantığı da kaldırabilir.
EIP-7002: Durumdaki Geçmiş Blok Karmalarını Kaydetme
Doğrulayıcıların çıkış ipoteği veya teminat ve gelir çekme süreçlerini iyileştirmek için kullanılabilir, doğrulayıcıların riskini azaltır.
Staking katılımı için Validator Anahtarı ve Çekilme Kimliği olmalıdır.
Doğrulayıcı Anahtar, doğrulayıcıların çalışma içeriğini doğrulamak için kullanılır; Çekme Kimliği, doğrulayıcıların işaretten çıkarken teminat ve gelirin çekileceği adresi belirlemek için kullanılır; ayrıca, şu anda işaretten çıkmak için Doğrulayıcı Anahtarı kullanmak zorunludur.
Validator Anahtarı kaybedilirse, doğrulayıcı görevini yerine getiremezsiniz ve stake çıkaramazsınız; Geri çekme Kimliği kaybedilirse, tüm stake ve kazanç kaybolur. Ayrıca, bazı kullanıcılar Lido gibi üçüncü taraf stake hizmetlerini kullanabilir, bu platformları kullandıklarında kullanıcıların Geri çekme Kimliğini kendilerinin saklamaları gerekirken, doğrulayıcı anahtarı hizmet sağlayıcı tarafından saklanır ve doğrulayıcı görevlerini yerine getirir.
EIP-7002 teknik protokolünü uygulayarak, kullanıcılar Withdrawal Kimliği'ni kullanarak "Withdraw Smart Contract" (yani 0x0c15F14308530b7CDB8460094BbB9cC28b9AaaAA'da dağıtılmış) çağırarak staking'i geri çekme (Exit) veya kısmi staking ve kazançları çekebilir, böylece üçüncü taraf staking hizmetlerinin olası risklerini azaltabilirler. Kullanıcılar, kendi stakinglerine katılırlarsa ve Validator Anahtarını kaybederlerse, bu da stakingden çıkmalarına yardımcı olabilir.
İstek içeren parametreler validator_pubkey ve miktar: validator_pubkey doğrulayıcının Doğrulayıcı (Genel) Anahtarıdır, miktar çekilmek istenen miktarı temsil eder.
Talebi başlatan Para Çekme Kimlik Bilgisi, doğrulayıcının Para Çekme Kimlik Bilgisi _pubkey olmalıdır.
Bir talep başlatmak için Para Çekme sözleşmesini ararken, gaz ücreti (ETH) mevcut para çekme talebi sayısına göre hesaplanacak, talep sayısı büyükse gaz ücreti artacaktır.
Kullanıcının Para Çekme Kimlik Bilgileri bir sözleşmeyse, mevcut ücret tutarını almak için Para Çekme sözleşmesine gidebilir ve ardından bir talep başlatabilir ve ücreti ekleyebilirsiniz; Bununla birlikte, Para Çekme Kimlik Bilgisi bir EOA hesabıysa, doğru bir ücret almanın bir yolu yoktur, bu nedenle talebin başarıyla yürütülmesini sağlamak için yalnızca zincir dışı simüle edebilir ve fazla ücreti (iade edilmeyecektir) ödeyebilirsiniz.
Not: Çekme Kimlik Bilginiz hala BLS genel anahtar biçimindeyse, önce geçiş yapmayı unutmayın ve onu EL adres biçimine dönüştürün.
EIP-7251: MAX_EFFECTIVE_BALANCE'ı EKLEME
Birçok doğrulayıcı sayısını azaltmak için teminat limitini büyük ölçüde artırabilir ve limiti aşmayan doğrulayıcılar otomatik olarak teminat gelirinden yararlanabilir.
Doğrulayıcı olmak için stake eden kullanıcılar, daha az veya daha fazla olamaz MAX_EFFECTIVE_BALANCE miktarda ETH sağlar (şu anda MAX_EFFECTIVE_BALANCE 32 ETH'dir). Bir kullanıcı stake etmek için 1024 ETH'ye sahipse, 32 kez staking'e katılabilir, 32 doğrulayıcıyı etkinleştirebilir ve 32 doğrulayıcı düğümü çalıştırabilir. Konsensüs katmanının durum verilerini büyütmenin yanı sıra, konsensüs katmanı p2p ağ katmanındaki yük daha önemlidir, çünkü her yuvada (her 12 saniyede bir) p2p ağ katmanında iletilecek ve toplanacak on binlerce doğrulayıcı imzası vardır.
EIP-7251 teknik protokolü uygulandıktan sonra, teminat alt sınırı (MIN_ACTIVATION_BALANCE) hala 32 ETH olacak, ancak üst sınır (MAX_EFFECTIVE_BALANCE) büyük ölçüde 2048 ETH olarak artacak, 32 ile 2048 arasında herhangi bir miktarda ETH teminatlayabilir, teminat getirisi elde edebilir, artık getiriyi düzenli olarak çekmeye gerek kalmadan 32 ETH biriktirip yeni bir teminata devam edebilirsiniz.
Şu anda, mevcut doğrulayıcıların önce staking'den çekilmesi ve ardından staking'i birleştirip yeniden birleştirmesi gerekmiyor, ancak yürütme katmanında yeni "mevduatları birleştirme sözleşmesini" (0x00431F263cE400f4455c2dCf564e53007Ca4bbBb'de konuşlandırılan) doğrudan kullanabilir ve doğrulayıcının Para Çekme Kredisi, mevduatın birleştirilmesi için bir talep başlatmak için sözleşmeyi çağıracaktır.
Depozito birleştirme isteğinin parametreleri source_pubkey ve target_pubkey'ı içerir: Bu iki anahtar da doğrulayıcıların Doğrulayıcı Anahtarı'dır, kaynak doğrulayıcı hedef doğrulayıcıya birleştirilecektir.
İstek çıkaran Çekilme Kimliği, kaynak doğrulayıcısının Çekilme Kimliği olmalıdır.
Birleştirme depozito sözleşmesini çağırırken başlatma isteği yaparken ücret (ETH) eklemeniz gerekir, ücret istek sayısına göre hesaplanacaktır, istek sayısı çok fazla ise ücret artacaktır.
Eğer kullanıcının Çekme Yetkilendirmesi bir akıllı sözleşme ise, mevcut işlem ücretini almak için önce depozito birleştirme sözleşmesini çağırabilir ve ardından talebi başlatıp işlem ücretini ekleyebilirsiniz; ancak Çekme Yetkilendirmesi bir EOA hesabıysa, kesin işlem ücretini almak mümkün olmayacaktır, sadece önceden zincir dışı simülasyon yaparak fazla işlem ücreti ödemeniz (geri ödenmeyecek) ve talebin başarılı bir şekilde gerçekleşmesini sağlamanız gerekecektir.
Not: Çekilme Kimliğiniz BLS genel anahtar biçimindeyse, önce EL adres biçimine dönüştürmeniz gerekmektedir.
EIP-7685: Ortak Yürütme Katmanı İsteği
CL bilgi kanalı oluşturun, böylece kullanıcılar ve staking hizmetleri doğrudan onay katmanına istek gönderebilir.
Kullanıcılar, doğrudan yürütme katmanından uzlaşma katmanına istek gönderebilirler, likidite sağlayıcıları (örneğin Lido) daha merkezi olmayan bir şekilde çalışabilir. Örneğin, önceden bahsedilen EIP-7002 çıkış işlemi isteği ve EIP-7251 birleştirme depozito isteği gibi. Bu teknik protokol olmadan, Lido kullanıcıları, uzlaşma katmanında çıkış işlemini gerçekleştirecek veya depozito birleştirecek olan Lido düğüm hizmet sağlayıcısına güvenmek zorunda kalacaklardı; bu teknik protokol sayesinde, Lido kullanıcıları, yürütme katmanında doğrudan yönetim sözleşmesi aracılığıyla istek gönderebilirler.
Bu istekler, farklı istek türlerini ayırt etmek için İstek Türü ile gelir ve farklı akıllı sözleşmeler aracılığıyla istek gönderilir, sonunda bu istekler tümü yürütme katmanının belleğine yazılır, bu nedenle uzlaşma katmanı bu bilgilere doğrudan yürütme katmanının belleği aracılığıyla erişebilir, ayrı bir çözümleme mantığı yazmaları gerekmez.
EIP-6110, EIP-7002 ve EIP-7251, EIP-7685 tarafından tanımlanan standarta göre talep edilmektedir.
EIP-6110 Staking talebi ekle: Talep Türü=0, Mevduat sözleşmesi aracılığıyla
Teknoloji Protokolü Kullanıcı Deneyimini Geliştirmek İçin
EIP-7702: EOA Hesap Kodunu Ayarlama
EOA hesabının isteğe bağlı olarak bir kontrat hesabına dönüşmesine izin vererek kullanım deneyimini büyük ölçüde artırır.
EOA hesabının bazı eksiklikleri kullanımı sırasında şunları içerir:
Özel anahtar veya kurtarma kelimesini kaydetmek ve saklamak, yeni kullanıcılar için kayıt ve kullanım eşiğini yükseltir.
EOA hesabı bir işlemde sadece bir işlemi gerçekleştirebilir, örneğin, Uniswap'te USDT'yi ETH'ye dönüştürmek istiyorsanız, önce bir işlem başlatarak USDT'yi onaylamanız ve ardından başka bir işlemle değişimi gerçekleştirmeniz gerekir.
Ayrıntılı bir izin kontrolü yapılamaz, örneğin bazı hesap işlemlerini üçüncü taraflara devretmek, kullanıcıların her detayla bizzat ilgilenmesi ve her işlemin imzalanıp işlem yapılması gereklidir.
Kurtarma mekanizması yok, sadece özel anahtarı veya hatırlatıcı kelimeyi kendiniz saklayabilirsiniz, kaybederseniz hesabın varlıklarını geri alamazsınız.
Bu bir akıllı sözleşme hesabıysa (örneğin Güvenli), yukarıdaki sorunlar çözülebilir:
Kullanıcılar, herhangi bir özel anahtar veya hatırlatıcı kelimeyi hatırlamadan, telefonlarının (veya bilgisayarlarının) güvenlik yongasındaki özel anahtarla imza atarak yetkilendirme yapabilirler veya e-posta ile de imza atabilirler veya diğer çeşitli yetkilendirme yöntemlerini kullanabilirler.
Birden çok işlemi aynı işlemde toplayarak aynı işlemde gerçekleştirebilirsiniz, önceki karmaşık DApp işlemleri sadece bir kez imzalama izni vererek, bir kez işlem yaparak tamamlanabilir.
Çok detaylı izin kontrolü olabilir, kullanıcılar üçüncü taraflara kendi hesapları üzerinde kontrol sağlayabilir, ancak aynı zamanda "hangi akıllı sözleşmelerle etkileşime girebilir", "hangi işlemleri gerçekleştiremez", "varlıkların transferinde en fazla kaç varlığın kullanılabileceği" veya "her hafta en fazla kaç işlem yapılabileceği" gibi kısıtlamaları belirleyebilir.
Bir kurtarma mekanizması ekleyebilir ve ayrıca anımsatıcı ifadenizi veya cep telefonunuzu veya e-postanızı kaybettiğinizde kurtarma mekanizması aracılığıyla hesabın varlıklarını yeni bir hesaba aktarabilirsiniz.
EIP-7702 önerisi, EOA hesaplarının sözleşme hesaplarına dönüşme yeteneği kazanmasını sağlar. Kullanıcılar, EOA özel anahtarıyla dönüşüm mesajını imzalar; imza içeriği 'Chain ID', 'dönüştürülen sözleşme adresi' ve 'EOA'nın Nonce değeri'ni içerir:
Chain ID: A zincirinin imzasının B zincirine kopyalanmasını önlemek için kullanılır. Ancak, Chain ID 0 olarak ayarlanırsa, her zincirde değişim yapılacağı anlamına gelir.
Değişmek istediğiniz sözleşme adresi: Bir Safe sözleşme adresi girerseniz, EOA hesabınız bir Safe sözleşmesine dönüşecek; boş bir adres girdiyseniz (adres(0)), değişikliği iptal etmek ve sadece EOA hesabına geri dönmek istediğinizi belirtir.
EOA'nın Nonce değeri: İmzanın tekrarlanmasını önlemek için kullanılır. Nonce değeri arttığında, orijinal imza geçersiz hale gelir.
Ancak, dikkat edilmesi gereken birkaç nokta var:
EOA özel anahtarı aynı şekilde kullanmaya devam edilebilir
Kullanıcının EOA hesabı bir akıllı sözleşmeye dönüşse bile, orijinal EOA hesabı şeklinde kullanmaya devam edebilir. Örneğin, EOA hesabınız bir Safe sözleşmesine dönüştüğünde, Safe arayüzünü kullanabilir, Safe işlem sürecini takip edebilir ve yine de orijinal EOA cüzdanınızla işlem imzalayabilirsiniz. Bununla birlikte, hesabın güvenliğinin hala o özel anahtarla sınırlı olduğu anlamına gelir.
EOA özel anahtarının güvenliği hala aynıdır
Kullanıcının EOA'sı çoklu imza haline gelse bile, EOA özel anahtarını kaybetmemişse, hesabının güvenliği daima EOA özel anahtarının güvenliği olacaktır: hala özel anahtarını veya hatırlatıcı sözcükleri iyi saklaması gerekecek, bu durum hesabının çoklu imza kadar güvenli hale gelmesine neden olmaz.
EOA hesabının Depolama Alanı biçimlendirilmemiş
Bir EOA hesabı bir sözleşmeye dönüştüğünde ve Storage'ına veri yazdığında, veriler açıkça silinmediği sürece, EOA hesabı başka bir sözleşmeye dönüştüğü veya dönüşümü iptal ettiği için Storage'a yazılan veriler biçimlendirilmeyecektir, bu nedenle geliştiriciler önceki dönüşüm sözleşmesinden kalan verileri okumamaya dikkat etmelidir, ERC-7201'e başvurabilirsiniz.
EIP-7702 süreci başlatmayı içermez.
Genel olarak, bir sözleşme hesabının, dağıtım adımının önden çalıştırılması nedeniyle hesap sahipliğinin kaybedilmesini önlemek için, hesap dağıtıldığında hesap sahibinin bilgilerini (ortak anahtar veya adres gibi) zaman uyumlu olarak yazmak için bir başlatma adımına ihtiyacı olacaktır. Bu genellikle "dağıtım + başlatma" gerçekleştirmek için sözleşme hesabını dağıtan fabrika sözleşmesi tarafından gerçekleştirilir, ancak EIP-7702, sözleşmeyi EOA'ya dağıtan bir fabrikadan ziyade doğrudan bir değişiklik olduğundan, saldırgan kullanıcının dönüştürme imzasını kopyalayabilir ve işlemi kullanıcı için dönüştürmek üzere zincire önceden gönderebilir, ancak hesabı saldırgan tarafından kontrol edilebilir olacak şekilde başlatabilir, bu nedenle geliştiricilerin EIP-7702'ye dikkat etmesi gerekir. Olası bir savunma yöntemi, başlatma işlevinde EOA hesabının imzasını kontrol etmektir, böylece öncelikli olsa bile, saldırgan başlatmayı tamamlamak için EOA hesabının imzasını oluşturamaz.
Cüzdan değişen istekleri kontrol etmelidir
Cüzdanın, kötü niyetli DApp web sitesinin kullanıcıdan bir dönüşüm işlemi imzalamasını istediğinde isteği engellemesi ve kullanıcıyı uyarması gerekmektedir. Aksi takdirde, kullanıcı kötü niyetli bir dönüşüm işlemi imzalarsa, varlıkların anında transfer edilmesine neden olabilir. İşte birkaç dönüşüm sözleşmesinin uygulama örneği:
Değiştirilmiş Güvenli Ithaca Hesabı
Ithaca Hesabı
DApp Teknoloji Protokolü
EIP-2537: BLS12-381 Eğrisel İşlem Ön Derlemesi
Maliyeti azaltın ve BLS eğrisi tabanlı sıfır bilgi kanıtı uygulamaları için daha uygun hale getirin.
EIP-2537, ucuz BLS eğrisi işlemleri sağlamak için birkaç yeni ön derleme sözleşmesi ekler ve BLS eğrilerine dayalı sıfır bilgi kanıtı uygulamaları geliştirmeyi daha uygun hale getirir.
EIP-2935: Durumdaki Geçmiş Blok Karmalarını Kaydetme
Geliştiricilerin veya düğümlerin, sistem akışkanından geçmiş bellek bloğunun karma değerini doğrudan okuyabilmelerini sağlar.
Bir geliştiricinin önceki bir bellek bloğunun içeriğini kanıtlaması gerekiyorsa, örneğin, Optimismtic Rollup sahtekarlığı sorgulaması bir işlemin önceki 1000 bellek bloğunda var olduğunu kanıtlamak isterse, sorgulayan bunu doğrudan söyleyemez.
"Please believe me, the transaction really existed before 1000 memory blocks." He has to present evidence, but there is no direct evidence to prove "These contents are included in the previous 1000 memory blocks", so he has to prove forward, block by block, in the form of a memory block 'chain', until reaching the previous 1000 memory blocks, and then prove that the transaction exists in that memory block.
△ Her bir blok bir ana bloğa işaret eder, bu nedenle tarihteki herhangi bir bloğu kanıtlayabilirsiniz.
Şu anda 10000 numaralı bir bellek bloğu olduğunu varsayalım ve sahtekarlık sorgulaması, 9000 numaralı bellek bloğunun bir X işlemine sahip olduğuna dair kanıt sağlamak istiyor, meydan okuyanın 10000 bellek bloğunun hash'i ile başlaması, önce bellek bloğu 10000'e bağlı ana bellek bloğu 9999'un hash'ini kanıtlaması ve ardından bellek bloğu 9998'i kanıtlaması gerekiyor... Bellek bloğu 9000'e kadar, bellek bloğu 9000'in içeriğinin X işlemini içermesi önerilmektedir.
EIP-2935'ten sonra, 0x0F792be4B0c0cb4DAE440Ef133E90C0eCD48CCCC'de dağıtılan bir sistem sözleşmesi olacak, depolaması en fazla 8192 önceki bellek bloğunun hash değerlerini saklayacak. Her yeni bellek bloğu oluşturulduğunda, bu sistem sözleşmesi otomatik olarak güncellenecek ve önceki bellek bloğunun hash değeri sistem sözleşmesine yazılacak (önceki 8192 bellek bloğunun hash değeri üzerine yazacak).
Optimizm Rollup dolandırıcılığına karşı bu şekilde bir meydan okuma örneğinde, meydan okuyan artık bir bellek bloğundan diğerine yavaşça kanıtlamak zorunda değil, bunun yerine doğrudan bellek bloğu 10000'in durumunu kanıtlayabilir, sistemin akıllı sözleşmesindeki belirli bir Depolama'nın (bellek bloğu 9000'e karşılık gelen) değerinin bellek bloğu 9000'ın hash değeri olduğunu. Eğer 8192'yi aşarsa, örneğin bellek bloğu 1000, en fazla bir adım daha atılacak, önce bellek bloğu 1808'in (10000-8192 =) hash değerini kanıtlamak, sonra bellek bloğu 1808'in durumunu kanıtlayarak, sistem sözleşmesindeki bellek bloğu 1000'in hash değerini kanıtlamak.
Bu aynı zamanda gelecekteki Durum Bilgisiz İstemci (Stateless Client) için de zemin hazırlıyor: Gelecekteki hafif düğümler artık tüm geçmiş bellek bloklarının başlık dosyalarını depolamak zorunda kalmayacak, bunun yerine geçmişte belirli bir bellek bloğunun hash değeri veya içeriğine ihtiyaç duyulduğunda, diğer insanlardan önceki sahtekarlık meydan okuma örneğinde olduğu gibi kanıt sunmalarını istemek yeterli olacaktır.
EIP-7623: : Çağrı verisi maliyetini artırın
Blok Gaz Sınırı'nı ve Blob Sınırı'nı artırmak için yeterli güvenli alan oluşturmak üzere çağrı verileriyle veri yayımlama maliyetini artırın.
Toplamaların veri yayınlamasına yönelik artan taleple birlikte, toplamaların verileri çok ucuz bir şekilde yerleştirmesine izin vermek için EIP-4844'te blobların kullanıma sunulmasından sonra, blob sayısını artırmak topluluğun dört gözle beklediği bir yükseltme olmuştur.
!
Yeterli sayıda doğrulayıcı, Blok Gaz Limiti'nin yükseltilmesini desteklediğini belirtiyor.
Bununla birlikte, Blok Gaz Limitini veya blob sayısını artırmak, işlem gören veri miktarı arttıkça Ethereum'un p2p ağı üzerinde daha fazla baskı oluşturacak ve bu da veri yayınlama maliyeti artmadıkça saldırganları daha verimli hale getirecektir.
EIP-7623 protokolü yayınlandıktan sonra, çağrı verilerinin maliyeti orijinal "Sıfır Bayt: 4 Gaz, Sıfır Bayt Olmayan: 16 Gaz"dan "Sıfır Bayt: 10 Gaz, Sıfır Bayt Olmayan: 40 Gaz"a 2,5 kat artacaktır.
Başlangıçta, bir saldırgan çöp verileri koymak için tüm Blok Gaz Sınırını (30M) kullandıysa, bellek bloğunun veri boyutu, yalnızca yaklaşık 100 KB'lık ortalama bellek bloğu boyutuna kıyasla yaklaşık 1,79 MB (30M / 16) olacaktır. Blok Gaz Limiti 40M'ye yükseltilirse, bir saldırgan yaklaşık 2,38 MB'lık bir bellek bloğu oluşturabilir. Çağrı verisi maliyeti 2,5 kat artırıldığında, saldırganın verimliliği 30M için maksimum 0,72 MB'a ve 40M için 0,95 MB'a düşürülecek, böylece Blok Gaz Limiti ve Blob daha güvenli bir şekilde artırılabilecek. Bununla birlikte, bu teknik protokol "veri yayınlamak için çağrı verilerini kullanmayan" genel kullanıcıyı etkilemek istemez, bu nedenle işlemin toplam gaz kullanımını hangisi daha yüksekse iki şekilde hesaplayacaktır:
İşlemin gaz kullanımını hesaplamanın orijinal yöntemi, eski çağrı verisi maliyeti ile hesaplanır: yani, çağrı verileri "Sıfır Bayt: 4 Gaz, Sıfır Bayt Olmayan: 16 Gaz" şeklinde hesaplanır ve işlemin yürütülmesi tarafından tüketilen gaz ve dağıtım sözleşmesi tarafından tüketilen gaz eklenir.
Çağrı verisi gaz miktarını hesaplamanız yeterlidir, ancak hesaplamak için yeni maliyeti kullanın: yani, çağrı verileri "Sıfır Bayt: 10 Gaz, Sıfır Bayt Olmayan: 40 Gaz" şeklinde hesaplanır, ancak yürütme tarafından tüketilen gazı veya sözleşmenin dağıtılmasıyla tüketilen gazı içermez, bu nedenle genellikle "veri yayınlamak için çağrı verilerini kullanmayan" kullanıcılar için (takas için Uniswap'a gitmek gibi), ana Gazdır Tüketim, yürütmenin bir parçasıdır ve çağrı verileri yeni bir maliyetle hesaplansa bile, yürütme tarafından tüketilen gazı aşmayacaktır, bu nedenle genel kullanıcılar etkilenmeyecektir.
Gerçekten etkilenen şey, ölçeği daha küçük Rollup olacak, çünkü Blob sabit boyutta ve sabit maliyetlidir, bu nedenle küçük Rollup'ların Blob kullanım verimliliği düşüktür, calldata kullanmak daha karlıdır, ancak EIP-7623'ten sonra, bu küçük Rollup'ların maliyeti 2.5 kat artacak, bu nedenle bunların hepsi Blob'u kullanmaya veya birlikte çalışarak bir Blob'u paylaşmaya çalışabilir.
EIP-7691: Blob İşleme Kapasitesini Artırma
Blob sayısını artırın ve toplamalara veri yayımlama için daha fazla alan ekleyin. *
EIP-7691, toplamalara daha fazla veri yayımlama alanını artırmak için blob sayısını "Hedef: 3 Blob, Maks: 6 Blob"dan "Hedef: 6 Blob, Maks: 9 Blob"a artırır.
Not: Ayrıca, Blob işlem ücreti pazarında bazı ayarlamalar yapılması gerektiğine dikkat edilmelidir, örneğin işlem ücreti ayarının yeterince anlık olmaması ve işlem ücreti tabanının çok düşük olması, ancak bu, bu teknik protokolün çözmesi gereken bir sorun değildir.
Diğer Teknik Anlaşmalar
EIP-7549: Komite endeksini doğrulamanın dışına taşı
Oyların toplanmasını kolaylaştırmak ve P2P ağı üzerindeki baskıyı azaltmak için doğrulayıcı oylamasının içeriğini ayarlayın.
Her bir doğrulayıcı, her dönemde rastgele bir komiteye atanır ve
Bellek bloğu oylamasında, her komitedeki doğrulayıcıların oyları bir araya getirilebilir, bu da P2P ağında geçen oy sayısını azaltır, ancak doğrulayıcının oyları, doğrulayıcının ait olduğu komite sayısı hakkında bilgi içerecektir, bu da farklı komitelerin oylarının, hepsi aynı bellek bloğunda oy kullansalar bile toplanamayacağı anlamına gelir.
EIP-7549, "Doğrulayıcının hangi komiteden olduğu" bilgisini oy içinden çıkararak, farklı komitelerden gelen doğrulayıcıların aynı oy içeriğinde bir araya getirilmesine olanak tanır, bu da p2p ağında iletilen oy sayısını ve p2p ağının baskısını daha da azaltır.
EIP-7840: EL yapılandırma dosyasına Blob planı ekleme
Blob parametresi için bir yapılandırma dosyası oluşturun ve yürütme katmanı düğümlerinin konsensüs katmanı düğümlerine Blob ile ilgili parametreleri sormasını engelleyin.
Blob ile ilgili parametreler şu anda konsensüs katmanı düğümlerinde depolanmaktadır, ancak yürütme katmanı düğümleri bazı durumlarda bu parametrelere ihtiyaç duyar (örneğin, RPC eth_feeHistory), bu nedenle konsensüs katmanı düğümlerine sormaları gerekir.
EIP-7840, yürütme katmanında blob ile ilgili parametreler için bir yapılandırma dosyası oluşturur ve yürütme katmanındaki düğümler, konsensüs katmanı düğümlerine sormak zorunda kalmadan bu yapılandırma dosyası aracılığıyla blob ile ilgili parametreleri doğrudan okuyabilir.
The content is for reference only, not a solicitation or offer. No investment, tax, or legal advice provided. See Disclaimer for more risks disclosure.
Ethereum Pectra Hard Fork tanıtımı
Yazar: NIC Lin, Medium
Pectra hard forkunun 2025 yılı Mart ayında ana ağ dağıtımının başlatılması beklenmektedir. Pectra'nın güncellemesi 11 teknik protokol (EIP) içermektedir, bunlar sırasıyla:
Staking ile ilgili teknik protokoller
EIP-6110: BLS12-381 Eğrisel İşlem Ön Derleme
Staking işlemine katılımı basitleştirerek bekleme süresini önemli ölçüde kısaltır.
Kullanıcıların staking'e katılma şekli, yürütme katmanına 32 ETH yatırmak ve bunu olay günlüğüne kaydetmektir ve ardından konsensüs katmanı, birinin staking'e katılıp katılmadığını belirlemek için olay günlüğünün analizini gerçekleştirir ve ardından staking'e katılan kullanıcı doğrulayıcı olur.
Bununla birlikte, konsensüs katmanının doğrulayıcılarının öncelikle hangi noktada para yatıracakları konusunda fikir birliğine varmaları gerekir, aksi takdirde bazı doğrulayıcılar 5 yeni mevduat görürken, bazı doğrulayıcılar yalnızca 3 tane görecektir, bu nedenle konsensüs katmanı doğrulayıcıları, herkesin aynı yürütme katmanı bloğunu görmesini sağlamak için hangi yürütme katmanı bloğuna (eth1data) atıfta bulunacaklarına oy verecektir.
Ancak, başlangıçta, büyük hatalara yol açabilecek önemli hataları önlemek için yürütme katmanında bir çatallaşma olmamasını sağlamak için referans alınan yürütme katmanı bloğu (eth1data) yaklaşık 10 saatten önce olacaktır. Bu, önemli bir hata olduğunda, konsensüs katmanı geliştiricilerinin tepki vermek için yeterli zamanı olmasını sağlar, ancak bu aynı zamanda stakingin etkin olması için en az 10 saat beklemeyi gerektirir.
△ CL 区块里的 10900000 eth1data，它里面记载的 Block Hash 是执行层区块 21683339，出现在它的 10 个小时以前。
EIP-6110 teknik protokolü yürütüldükten sonra, kullanıcının sözleşmedeki rehin verileri doğrudan yürütme katmanının bir parçası haline gelecektir ve konsensüs katmanı bloğunun kendisi yürütme katmanı bloğunu içereceğinden (ancak eth1data'yı içermediğinden), konsensüs katmanı doğrulayıcılarının artık "referans yürütme katmanı bellek bloğunun aynı olduğunu onaylama" sorununu dikkate almasına gerek yoktur, konsensüs katmanı bellek bloğu doğrulayıcıların üçte ikisinden fazlası tarafından oylandığı sürece, herkes aynı yürütme katmanı bloğu üzerinde bir fikir birliğine varacaktır. Bu nedenle, rehne katıldıktan sonra, kullanıcı yürütme katmanı bellek bloğunun işlemeyi en erken yaklaşık 13 dakika içinde tamamlamasını bekleyebilir ve konsensüs katmanı istemcisi, başlangıçta stake verilerini işlemek için kullanılan karmaşık mantığı da kaldırabilir.
EIP-7002: Durumdaki Geçmiş Blok Karmalarını Kaydetme
Doğrulayıcıların çıkış ipoteği veya teminat ve gelir çekme süreçlerini iyileştirmek için kullanılabilir, doğrulayıcıların riskini azaltır.
Staking katılımı için Validator Anahtarı ve Çekilme Kimliği olmalıdır.
Doğrulayıcı Anahtar, doğrulayıcıların çalışma içeriğini doğrulamak için kullanılır; Çekme Kimliği, doğrulayıcıların işaretten çıkarken teminat ve gelirin çekileceği adresi belirlemek için kullanılır; ayrıca, şu anda işaretten çıkmak için Doğrulayıcı Anahtarı kullanmak zorunludur.
Validator Anahtarı kaybedilirse, doğrulayıcı görevini yerine getiremezsiniz ve stake çıkaramazsınız; Geri çekme Kimliği kaybedilirse, tüm stake ve kazanç kaybolur. Ayrıca, bazı kullanıcılar Lido gibi üçüncü taraf stake hizmetlerini kullanabilir, bu platformları kullandıklarında kullanıcıların Geri çekme Kimliğini kendilerinin saklamaları gerekirken, doğrulayıcı anahtarı hizmet sağlayıcı tarafından saklanır ve doğrulayıcı görevlerini yerine getirir.
EIP-7002 teknik protokolünü uygulayarak, kullanıcılar Withdrawal Kimliği'ni kullanarak "Withdraw Smart Contract" (yani 0x0c15F14308530b7CDB8460094BbB9cC28b9AaaAA'da dağıtılmış) çağırarak staking'i geri çekme (Exit) veya kısmi staking ve kazançları çekebilir, böylece üçüncü taraf staking hizmetlerinin olası risklerini azaltabilirler. Kullanıcılar, kendi stakinglerine katılırlarsa ve Validator Anahtarını kaybederlerse, bu da stakingden çıkmalarına yardımcı olabilir.
Not: Çekme Kimlik Bilginiz hala BLS genel anahtar biçimindeyse, önce geçiş yapmayı unutmayın ve onu EL adres biçimine dönüştürün.
EIP-7251: MAX_EFFECTIVE_BALANCE'ı EKLEME
Birçok doğrulayıcı sayısını azaltmak için teminat limitini büyük ölçüde artırabilir ve limiti aşmayan doğrulayıcılar otomatik olarak teminat gelirinden yararlanabilir.
Doğrulayıcı olmak için stake eden kullanıcılar, daha az veya daha fazla olamaz MAX_EFFECTIVE_BALANCE miktarda ETH sağlar (şu anda MAX_EFFECTIVE_BALANCE 32 ETH'dir). Bir kullanıcı stake etmek için 1024 ETH'ye sahipse, 32 kez staking'e katılabilir, 32 doğrulayıcıyı etkinleştirebilir ve 32 doğrulayıcı düğümü çalıştırabilir. Konsensüs katmanının durum verilerini büyütmenin yanı sıra, konsensüs katmanı p2p ağ katmanındaki yük daha önemlidir, çünkü her yuvada (her 12 saniyede bir) p2p ağ katmanında iletilecek ve toplanacak on binlerce doğrulayıcı imzası vardır.
EIP-7251 teknik protokolü uygulandıktan sonra, teminat alt sınırı (MIN_ACTIVATION_BALANCE) hala 32 ETH olacak, ancak üst sınır (MAX_EFFECTIVE_BALANCE) büyük ölçüde 2048 ETH olarak artacak, 32 ile 2048 arasında herhangi bir miktarda ETH teminatlayabilir, teminat getirisi elde edebilir, artık getiriyi düzenli olarak çekmeye gerek kalmadan 32 ETH biriktirip yeni bir teminata devam edebilirsiniz.
Şu anda, mevcut doğrulayıcıların önce staking'den çekilmesi ve ardından staking'i birleştirip yeniden birleştirmesi gerekmiyor, ancak yürütme katmanında yeni "mevduatları birleştirme sözleşmesini" (0x00431F263cE400f4455c2dCf564e53007Ca4bbBb'de konuşlandırılan) doğrudan kullanabilir ve doğrulayıcının Para Çekme Kredisi, mevduatın birleştirilmesi için bir talep başlatmak için sözleşmeyi çağıracaktır.
Not: Çekilme Kimliğiniz BLS genel anahtar biçimindeyse, önce EL adres biçimine dönüştürmeniz gerekmektedir.
EIP-7685: Ortak Yürütme Katmanı İsteği
CL bilgi kanalı oluşturun, böylece kullanıcılar ve staking hizmetleri doğrudan onay katmanına istek gönderebilir.
Kullanıcılar, doğrudan yürütme katmanından uzlaşma katmanına istek gönderebilirler, likidite sağlayıcıları (örneğin Lido) daha merkezi olmayan bir şekilde çalışabilir. Örneğin, önceden bahsedilen EIP-7002 çıkış işlemi isteği ve EIP-7251 birleştirme depozito isteği gibi. Bu teknik protokol olmadan, Lido kullanıcıları, uzlaşma katmanında çıkış işlemini gerçekleştirecek veya depozito birleştirecek olan Lido düğüm hizmet sağlayıcısına güvenmek zorunda kalacaklardı; bu teknik protokol sayesinde, Lido kullanıcıları, yürütme katmanında doğrudan yönetim sözleşmesi aracılığıyla istek gönderebilirler.
Bu istekler, farklı istek türlerini ayırt etmek için İstek Türü ile gelir ve farklı akıllı sözleşmeler aracılığıyla istek gönderilir, sonunda bu istekler tümü yürütme katmanının belleğine yazılır, bu nedenle uzlaşma katmanı bu bilgilere doğrudan yürütme katmanının belleği aracılığıyla erişebilir, ayrı bir çözümleme mantığı yazmaları gerekmez.
EIP-6110, EIP-7002 ve EIP-7251, EIP-7685 tarafından tanımlanan standarta göre talep edilmektedir.
(0x00000000219ab540356cbb839cbe05303d7705fa) istek başlatıldı.
(0x0c15F14308530b7CDB8460094BbB9cC28b9AaaAA) Bir istek başlatmak.
(0x00431F263cE400f4455c2dCf564e53007Ca4bbBb) istek başlattı.
Teknoloji Protokolü Kullanıcı Deneyimini Geliştirmek İçin
EIP-7702: EOA Hesap Kodunu Ayarlama
EOA hesabının isteğe bağlı olarak bir kontrat hesabına dönüşmesine izin vererek kullanım deneyimini büyük ölçüde artırır.
EOA hesabının bazı eksiklikleri kullanımı sırasında şunları içerir:
Bu bir akıllı sözleşme hesabıysa (örneğin Güvenli), yukarıdaki sorunlar çözülebilir:
EIP-7702 önerisi, EOA hesaplarının sözleşme hesaplarına dönüşme yeteneği kazanmasını sağlar. Kullanıcılar, EOA özel anahtarıyla dönüşüm mesajını imzalar; imza içeriği 'Chain ID', 'dönüştürülen sözleşme adresi' ve 'EOA'nın Nonce değeri'ni içerir:
Ancak, dikkat edilmesi gereken birkaç nokta var:
Kullanıcının EOA hesabı bir akıllı sözleşmeye dönüşse bile, orijinal EOA hesabı şeklinde kullanmaya devam edebilir. Örneğin, EOA hesabınız bir Safe sözleşmesine dönüştüğünde, Safe arayüzünü kullanabilir, Safe işlem sürecini takip edebilir ve yine de orijinal EOA cüzdanınızla işlem imzalayabilirsiniz. Bununla birlikte, hesabın güvenliğinin hala o özel anahtarla sınırlı olduğu anlamına gelir.
Kullanıcının EOA'sı çoklu imza haline gelse bile, EOA özel anahtarını kaybetmemişse, hesabının güvenliği daima EOA özel anahtarının güvenliği olacaktır: hala özel anahtarını veya hatırlatıcı sözcükleri iyi saklaması gerekecek, bu durum hesabının çoklu imza kadar güvenli hale gelmesine neden olmaz.
Bir EOA hesabı bir sözleşmeye dönüştüğünde ve Storage'ına veri yazdığında, veriler açıkça silinmediği sürece, EOA hesabı başka bir sözleşmeye dönüştüğü veya dönüşümü iptal ettiği için Storage'a yazılan veriler biçimlendirilmeyecektir, bu nedenle geliştiriciler önceki dönüşüm sözleşmesinden kalan verileri okumamaya dikkat etmelidir, ERC-7201'e başvurabilirsiniz.
Genel olarak, bir sözleşme hesabının, dağıtım adımının önden çalıştırılması nedeniyle hesap sahipliğinin kaybedilmesini önlemek için, hesap dağıtıldığında hesap sahibinin bilgilerini (ortak anahtar veya adres gibi) zaman uyumlu olarak yazmak için bir başlatma adımına ihtiyacı olacaktır. Bu genellikle "dağıtım + başlatma" gerçekleştirmek için sözleşme hesabını dağıtan fabrika sözleşmesi tarafından gerçekleştirilir, ancak EIP-7702, sözleşmeyi EOA'ya dağıtan bir fabrikadan ziyade doğrudan bir değişiklik olduğundan, saldırgan kullanıcının dönüştürme imzasını kopyalayabilir ve işlemi kullanıcı için dönüştürmek üzere zincire önceden gönderebilir, ancak hesabı saldırgan tarafından kontrol edilebilir olacak şekilde başlatabilir, bu nedenle geliştiricilerin EIP-7702'ye dikkat etmesi gerekir. Olası bir savunma yöntemi, başlatma işlevinde EOA hesabının imzasını kontrol etmektir, böylece öncelikli olsa bile, saldırgan başlatmayı tamamlamak için EOA hesabının imzasını oluşturamaz.
Cüzdanın, kötü niyetli DApp web sitesinin kullanıcıdan bir dönüşüm işlemi imzalamasını istediğinde isteği engellemesi ve kullanıcıyı uyarması gerekmektedir. Aksi takdirde, kullanıcı kötü niyetli bir dönüşüm işlemi imzalarsa, varlıkların anında transfer edilmesine neden olabilir. İşte birkaç dönüşüm sözleşmesinin uygulama örneği:
DApp Teknoloji Protokolü
EIP-2537: BLS12-381 Eğrisel İşlem Ön Derlemesi
Maliyeti azaltın ve BLS eğrisi tabanlı sıfır bilgi kanıtı uygulamaları için daha uygun hale getirin.
EIP-2537, ucuz BLS eğrisi işlemleri sağlamak için birkaç yeni ön derleme sözleşmesi ekler ve BLS eğrilerine dayalı sıfır bilgi kanıtı uygulamaları geliştirmeyi daha uygun hale getirir.
EIP-2935: Durumdaki Geçmiş Blok Karmalarını Kaydetme
Geliştiricilerin veya düğümlerin, sistem akışkanından geçmiş bellek bloğunun karma değerini doğrudan okuyabilmelerini sağlar.
Bir geliştiricinin önceki bir bellek bloğunun içeriğini kanıtlaması gerekiyorsa, örneğin, Optimismtic Rollup sahtekarlığı sorgulaması bir işlemin önceki 1000 bellek bloğunda var olduğunu kanıtlamak isterse, sorgulayan bunu doğrudan söyleyemez.
"Please believe me, the transaction really existed before 1000 memory blocks." He has to present evidence, but there is no direct evidence to prove "These contents are included in the previous 1000 memory blocks", so he has to prove forward, block by block, in the form of a memory block 'chain', until reaching the previous 1000 memory blocks, and then prove that the transaction exists in that memory block.
△ Her bir blok bir ana bloğa işaret eder, bu nedenle tarihteki herhangi bir bloğu kanıtlayabilirsiniz.
Şu anda 10000 numaralı bir bellek bloğu olduğunu varsayalım ve sahtekarlık sorgulaması, 9000 numaralı bellek bloğunun bir X işlemine sahip olduğuna dair kanıt sağlamak istiyor, meydan okuyanın 10000 bellek bloğunun hash'i ile başlaması, önce bellek bloğu 10000'e bağlı ana bellek bloğu 9999'un hash'ini kanıtlaması ve ardından bellek bloğu 9998'i kanıtlaması gerekiyor... Bellek bloğu 9000'e kadar, bellek bloğu 9000'in içeriğinin X işlemini içermesi önerilmektedir.
EIP-2935'ten sonra, 0x0F792be4B0c0cb4DAE440Ef133E90C0eCD48CCCC'de dağıtılan bir sistem sözleşmesi olacak, depolaması en fazla 8192 önceki bellek bloğunun hash değerlerini saklayacak. Her yeni bellek bloğu oluşturulduğunda, bu sistem sözleşmesi otomatik olarak güncellenecek ve önceki bellek bloğunun hash değeri sistem sözleşmesine yazılacak (önceki 8192 bellek bloğunun hash değeri üzerine yazacak).
Optimizm Rollup dolandırıcılığına karşı bu şekilde bir meydan okuma örneğinde, meydan okuyan artık bir bellek bloğundan diğerine yavaşça kanıtlamak zorunda değil, bunun yerine doğrudan bellek bloğu 10000'in durumunu kanıtlayabilir, sistemin akıllı sözleşmesindeki belirli bir Depolama'nın (bellek bloğu 9000'e karşılık gelen) değerinin bellek bloğu 9000'ın hash değeri olduğunu. Eğer 8192'yi aşarsa, örneğin bellek bloğu 1000, en fazla bir adım daha atılacak, önce bellek bloğu 1808'in (10000-8192 =) hash değerini kanıtlamak, sonra bellek bloğu 1808'in durumunu kanıtlayarak, sistem sözleşmesindeki bellek bloğu 1000'in hash değerini kanıtlamak.
Bu aynı zamanda gelecekteki Durum Bilgisiz İstemci (Stateless Client) için de zemin hazırlıyor: Gelecekteki hafif düğümler artık tüm geçmiş bellek bloklarının başlık dosyalarını depolamak zorunda kalmayacak, bunun yerine geçmişte belirli bir bellek bloğunun hash değeri veya içeriğine ihtiyaç duyulduğunda, diğer insanlardan önceki sahtekarlık meydan okuma örneğinde olduğu gibi kanıt sunmalarını istemek yeterli olacaktır.
EIP-7623: : Çağrı verisi maliyetini artırın
Blok Gaz Sınırı'nı ve Blob Sınırı'nı artırmak için yeterli güvenli alan oluşturmak üzere çağrı verileriyle veri yayımlama maliyetini artırın.
Toplamaların veri yayınlamasına yönelik artan taleple birlikte, toplamaların verileri çok ucuz bir şekilde yerleştirmesine izin vermek için EIP-4844'te blobların kullanıma sunulmasından sonra, blob sayısını artırmak topluluğun dört gözle beklediği bir yükseltme olmuştur.
!
Yeterli sayıda doğrulayıcı, Blok Gaz Limiti'nin yükseltilmesini desteklediğini belirtiyor.
Bununla birlikte, Blok Gaz Limitini veya blob sayısını artırmak, işlem gören veri miktarı arttıkça Ethereum'un p2p ağı üzerinde daha fazla baskı oluşturacak ve bu da veri yayınlama maliyeti artmadıkça saldırganları daha verimli hale getirecektir.
EIP-7623 protokolü yayınlandıktan sonra, çağrı verilerinin maliyeti orijinal "Sıfır Bayt: 4 Gaz, Sıfır Bayt Olmayan: 16 Gaz"dan "Sıfır Bayt: 10 Gaz, Sıfır Bayt Olmayan: 40 Gaz"a 2,5 kat artacaktır.
Başlangıçta, bir saldırgan çöp verileri koymak için tüm Blok Gaz Sınırını (30M) kullandıysa, bellek bloğunun veri boyutu, yalnızca yaklaşık 100 KB'lık ortalama bellek bloğu boyutuna kıyasla yaklaşık 1,79 MB (30M / 16) olacaktır. Blok Gaz Limiti 40M'ye yükseltilirse, bir saldırgan yaklaşık 2,38 MB'lık bir bellek bloğu oluşturabilir. Çağrı verisi maliyeti 2,5 kat artırıldığında, saldırganın verimliliği 30M için maksimum 0,72 MB'a ve 40M için 0,95 MB'a düşürülecek, böylece Blok Gaz Limiti ve Blob daha güvenli bir şekilde artırılabilecek. Bununla birlikte, bu teknik protokol "veri yayınlamak için çağrı verilerini kullanmayan" genel kullanıcıyı etkilemek istemez, bu nedenle işlemin toplam gaz kullanımını hangisi daha yüksekse iki şekilde hesaplayacaktır:
Gerçekten etkilenen şey, ölçeği daha küçük Rollup olacak, çünkü Blob sabit boyutta ve sabit maliyetlidir, bu nedenle küçük Rollup'ların Blob kullanım verimliliği düşüktür, calldata kullanmak daha karlıdır, ancak EIP-7623'ten sonra, bu küçük Rollup'ların maliyeti 2.5 kat artacak, bu nedenle bunların hepsi Blob'u kullanmaya veya birlikte çalışarak bir Blob'u paylaşmaya çalışabilir.
EIP-7691: Blob İşleme Kapasitesini Artırma
EIP-7691, toplamalara daha fazla veri yayımlama alanını artırmak için blob sayısını "Hedef: 3 Blob, Maks: 6 Blob"dan "Hedef: 6 Blob, Maks: 9 Blob"a artırır.
Not: Ayrıca, Blob işlem ücreti pazarında bazı ayarlamalar yapılması gerektiğine dikkat edilmelidir, örneğin işlem ücreti ayarının yeterince anlık olmaması ve işlem ücreti tabanının çok düşük olması, ancak bu, bu teknik protokolün çözmesi gereken bir sorun değildir.
Diğer Teknik Anlaşmalar
EIP-7549: Komite endeksini doğrulamanın dışına taşı
Oyların toplanmasını kolaylaştırmak ve P2P ağı üzerindeki baskıyı azaltmak için doğrulayıcı oylamasının içeriğini ayarlayın.
Her bir doğrulayıcı, her dönemde rastgele bir komiteye atanır ve
Bellek bloğu oylamasında, her komitedeki doğrulayıcıların oyları bir araya getirilebilir, bu da P2P ağında geçen oy sayısını azaltır, ancak doğrulayıcının oyları, doğrulayıcının ait olduğu komite sayısı hakkında bilgi içerecektir, bu da farklı komitelerin oylarının, hepsi aynı bellek bloğunda oy kullansalar bile toplanamayacağı anlamına gelir.
EIP-7549, "Doğrulayıcının hangi komiteden olduğu" bilgisini oy içinden çıkararak, farklı komitelerden gelen doğrulayıcıların aynı oy içeriğinde bir araya getirilmesine olanak tanır, bu da p2p ağında iletilen oy sayısını ve p2p ağının baskısını daha da azaltır.
EIP-7840: EL yapılandırma dosyasına Blob planı ekleme
Blob parametresi için bir yapılandırma dosyası oluşturun ve yürütme katmanı düğümlerinin konsensüs katmanı düğümlerine Blob ile ilgili parametreleri sormasını engelleyin.
Blob ile ilgili parametreler şu anda konsensüs katmanı düğümlerinde depolanmaktadır, ancak yürütme katmanı düğümleri bazı durumlarda bu parametrelere ihtiyaç duyar (örneğin, RPC eth_feeHistory), bu nedenle konsensüs katmanı düğümlerine sormaları gerekir.
EIP-7840, yürütme katmanında blob ile ilgili parametreler için bir yapılandırma dosyası oluşturur ve yürütme katmanındaki düğümler, konsensüs katmanı düğümlerine sormak zorunda kalmadan bu yapılandırma dosyası aracılığıyla blob ile ilgili parametreleri doğrudan okuyabilir.