Önceki makalemizde Ethereum doğrulayıcısının yaşam döngüsünü detaylı bir şekilde inceledik ve yaklaşan Electra hard fork ile ilgili birçok yönü tartıştık. Şimdi, yaklaşan Electra ve Prague güncellemelerindeki değişikliklere odaklanma ve detaylı bir şekilde açıklama zamanı geldi.
Ethereum 2.0 'Proof of Stake' hard fork history is complex. It started with adding the beacon chain to the existing execution layer, while the execution layer still maintained proof of work consensus (Phase0 and Altair hard forks). Then, in the Bellatrix hard fork, PoS was fully activated (although withdrawals were not enabled). Subsequently, the Capella hard fork allowed for withdrawals, completing the validator lifecycle. The recent Deneb hard fork (part of the Deneb/Cancun upgrade) made minor revisions to the beacon chain parameters, such as the inclusion of proof-of-time windows, handling voluntary exits, and validator rotation limits. The main changes in Deneb occurred in the execution layer, introducing blob transactions, blob gas, KZG commitments for blobs, and deprecating the SELFDESTRUCT operation.
Şu anda, Prague/Electra (yani Pectra) hard fork, yürütme ve konsensüs katmanına önemli bir güncelleme getirdi. Lido projesinin denetçileri olarak, özellikle bu hard fork'ta konsensüs ve staking ile ilgili değişikliklere odaklanıyoruz. Ancak, Prague'daki yürütme katmanındaki değişiklikleri göz ardı edemeyiz, çünkü bunlar Ethereum ağını ve doğrulayıcıları etkileyen önemli özellikleri içerir. Bu değişikliklerin detaylarına derinlemesine inelim.
Pectra'nın daha yüksek düzeyde genel bir bakışı
Electra, işaret katmanına birçok özellik ekledi. Başlıca güncellemeler şunları içerir:
Doğrulayıcıların geçerli denge aralığının 32 ila 2048 ETH arasında değişebilmesine izin verilir (sabit 32 ETH değil).
Doğrulayıcıların ikinci seviye "çekme" belgeleri aracılığıyla çıkış yapmalarına izin verilir (aktif doğrulayıcı anahtarına artık gerek yoktur).
Eth1 yatırımlarının işlenmesi için beacon katmanı yöntemi değiştirildi (artık yatırım sözleşmesinden etkinlik çözümlemesi yapılmıyor).
Geleneksel Eth1 sözleşmelerinden gelen talepleri işlemek için beacon katmanında Electra ön depozito yöntemine benzer yeni bir genel çerçeve eklendi.
Bu arada, Prag'da yürütme katmanına şu değişiklikler getirildi:
BLS12-381 eğrisini destekleyen yeni bir ön derlenmiş akıllı sözleşme, yaygın olan BN254 eğrisi dışında zkSNARK kanıtlarını doğrulamak için.
Bir yeni sistem sözleşmesi, 8192 tane geçmiş blok karmaşasını depolamak ve erişmek için kullanılır (durumsuz istemci için çok faydalı).
Calldata gaz maliyetini artırarak blok boyutunu azaltmak ve projelerin calldata yoğun işlemlerini (örneğin rollup) Dencun tarafından tanıtılan bloblara taşımalarını teşvik etmek için.
Her Eth1 blok için daha fazla blob desteği ve bu sayıları okumak için bir API sağlar.
EOA'ların (Harici Sahip Hesapları) kendi hesap kodlarına sahip olmalarına izin verilerek, multicalls gibi işlemleri gerçekleştirebilecekleri veya işlemleri başka adreslere devredebilecekleri şekilde EOA'ların yapabilecekleri işlemler önemli ölçüde genişletildi.
Daha fazla tartışma için, ilgili Ethereum İyileştirme Önerisi (EIP)'yi referans alalım.
EIP-7251: MAX_EFFECTIVE_BALANCE arttırıldı
EIP-7002: Yürütme Katmanı Tetiklenebilir Çıkış
EIP-6110: Zincir Üstünde Doğrulayıcıların Yatırım Yapması
EIP-7549: Komite dizinini ispat dışına çıkarın
EIP-7685: Genel Yürütme Katmanı Talebi
EIP-2537: Ön derleme BLS12-381 eğrisi işlemleri
EIP-2935: Tarih blok karma geçmişini durumda saklama
EIP-7623: Calldata maliyetini artırma
EIP-7691: blok verimliliği arttırıldı
EIP-7840: EL yapılandırma dosyasına blob planlaması ekle
EIP-7702: EOA Hesap Kodunu Ayarlama
Bu EIP'lerin bazıları çoğunlukla konsensüs (beacon) katmanını, diğerleri ise yürütme katmanını ilgilendirmektedir. Bazıları iki katmanı da kapsar çünkü bazı işlemler (örneğin, depozito ve çekme) konsensüs ve yürütme katmanları arasında senkron değişiklik gerektirir. Bu karşılıklı bağımlılık nedeniyle, Electra ve Prague'yi ayırmak pratik değildir, bu nedenle her bir EIP'yi sırayla gözden geçireceğiz ve etkilenen Ethereum bileşenlerini belirleyeceğiz.
EIP-7251: MAX_EFFECTIVE_BALANCE EKLEME
Referans: EIP-7251
İlk Phase0 sert çatalından bu yana, Ethereum'un proof of stake'e hazırlanması için, Electra'ya kadar, validatorların maksimum etkin bakiyesi sabitlenmiş 32 ETH olarak belirlenmiştir. Validatorları etkinleştirmek için en az spec.min_activation_balance (32 ETH) gerekir. Etkinleştikten sonra, validatorlar bu maksimum etkin bakiyeden başlar ancak etkin bakiyelerini spec.ejection_balance (16 ETH) seviyesine düşürebilir ve bu eşiğe ulaşıldığında atılabilirler. Bu "minimum" mantık Electra'da aynen devam ederken, şimdi spec.max_effective_balance 2048 ETH'ye yükseltilmiştir. Bu nedenle, validatorlar 32 ile 2048 ETH arasında bir depozito yaparak etkinleştirilebilir, tüm bu miktarlar etkin bakiyelerine katkıda bulunacaktır. Bu değişiklik, "32ETH- stake"den "stake"ye geçişi işaret ediyor.
Bu değişken geçerli bakiye şu anda kullanılacaktır:
Blok önericisi olma olasılığını artırın, geçerli bakiye ile doğru orantılıdır
Olasılığı artırmak, senkronizasyon komitesi üyesi olmak için, geçerli bakiye ile orantılıdır.
Kesinti oranlarını ve pasif cezaları hesaplama temel olarak
İlk iki etkinlik, doğrulayıcılar için en karlı işlemlerdir. Bu nedenle, Electra'dan sonra, yüksek miktarda staking yapan doğrulayıcılar blok önerme ve senkronizasyon komitesine daha sık katılacaklar ve frekansları geçerli bakiyeleriyle orantılı olacaktır.
Başka bir etkisi azaltmayla ilgilidir. Tüm kesinti cezaları doğrulayıcının geçerli bakiyesi ile orantılıdır:
'Hemen' ve 'Gecikme' kesinti cezası, yüksek miktarda staking yapan doğrulayıcılar için daha büyük.
Yüksek miktarda teminatı olan azaltılmış doğrulayıcılarla birlikte, 'güvenlik' azaltma cezası da daha büyük olur, çünkü toplam teminatın 'azaltılmış' kısmı daha büyüktür.
Yüksek geçerli bakiyeye sahip olan doğrulayıcıların raporlayanları daha büyük oranda azaltılmış staking alır.
Electra, azaltma oranına yönelik değişiklikler de sunmuş, azaltılan doğrulayıcı bakiyesinin bir kısmını tanımlamış ve bildiren kişi tarafından alınmıştır.
Sonraki şey geçersizlik etkisidir. Bir doğrulayıcı aktifken (ispatlama veya teklif) çevrimdışı olduğunda, geçersizlik puanı birikir ve her dönemde geçersizlik cezası uygulanır. Bu cezalar ayrıca doğrulayıcının geçerli bakiyesiyle orantılıdır.
Geçerli bakiyenin artması nedeniyle doğrulayıcıların "değiştirme sınırlaması" da değişti. Ethereum'un "Electra'dan önceki" versiyonunda doğrulayıcılar genellikle aynı geçerli bakiyeye sahiptir ve çıkış değiştirme sınırlaması "bir döngü içinde toplam stakingin 1/65536'sından fazlasının çıkış yapamaz" şeklinde tanımlanır. Bu, aynı stakinge sahip doğrulayıcıların "sabit" bir çıkış miktarı oluşturur. Ancak, "Electra'dan sonra" sadece birkaç "balina"nın çıkabileceği durumlar ortaya çıkabilir çünkü bunlar toplam stakingin önemli bir kısmını temsil eder.
Başka bir düşünce, bir tek doğrulayıcı örneği üzerinde birçok doğrulayıcı anahtarının dönüşümüdür. Büyük doğrulayıcılar şu anda büyük miktarlarda teminatı karşılamak için bir örnekte binlerce doğrulayıcı anahtarı çalıştırmak zorunda bırakılıyor, bunları 32 ETH bölümüne ayırıyor. Electra ile bu davranış artık zorunlu değil. Finansal açıdan, bu değişikliğin etkisi çok büyük değil, çünkü ödül ve olasılık teminat miktarıyla doğrusal olarak ölçeklenir. Bu nedenle, her biri 32 ETH olan 100 doğrulayıcı, 3200 ETH'lık bir doğrulayıcıya eşittir. Ayrıca, birden fazla etkin doğrulayıcı anahtarı aynı Eth1 çekme belgesine sahip olabilir, bu da tüm ödüllerin tek bir ETH adresine çekilmesine izin verir ve ödül birleştirmeyle ilişkili gaz maliyetinden kaçınır. Bununla birlikte, birçok anahtarın yönetimi ek yönetim maliyeti doğurur.
Aggregator validatorının bakiye yeteneği, yeni bir yürütme katmanı istek türü ekledi. Daha önce, yatırma ve çekme vardı. Şimdi ise başka bir tür olacak: toplama isteği. İki doğrulayıcı birleştirilecek. Bu işlem isteği, kaynak doğrulayıcının genel anahtarını ve hedef genel anahtarını içerecek ve yatırma ve çekme gibi işlemler gerçekleştirilecek. Toplamda, işleme alınacak istekler ve bakiye değiştirme sınırlamaları olacak, yatırma ve çekme gibi.
Aşağıda özetlenmiştir:
Küçük bağımsız doğrulayıcılar için, Electra'nın etkin denge (ve ödül) artırma yeteneği getirildi. Daha önce, 32 ETH'nin üzerindeki herhangi bir fazla, çekilebilirdi, ancak Electra'dan sonra, bu fazla sonunda etkin dengeye katkıda bulunacaktır. Ancak, etkin denge yalnızca spec.effective_balance_increment (1 ETH) katları şeklinde arttırılabilir, bu da artışın yalnızca bir sonraki '1 ETH sınırına' ulaşıldıktan sonra meydana geleceği anlamına gelir.
Büyük bağımsız doğrulayıcılar için, Electra, birden fazla etkin doğrulayıcı anahtarını birleştirerek önemli bir yönetim kolaylığı sağlar. Bu, oyun kurallarını değiştirmese de, 1x2048 teminatı yönetmek, 64x32 teminatı yönetmekten kesinlikle çok daha basit olacaktır.
Akışkan teminat sağlayıcıları için, küçük teminatları kullanıcılardan toplarlar ve doğrulayıcılar arasında dağıtırlar, Electra, teminat dağıtım planına daha fazla esneklik eklerken, aynı zamanda sabit 32 ETH etkin bakiyesine dayalı doğrulayıcı muhasebesine ciddi bir şekilde yeniden yapılandırma gerektirir.
Başka bir önemli konu, validatorlerin tarih verileri ve kar tahmini, özellikle yeni katılımcılar için ilgilidir, risk ve getiriyi değerlendirmeye çalışırlar. Electra'dan önce (bu yazı yazılırken), 32 ETH sınırı (aslında en küçük veya en büyük olması fark etmeksizin) tarih verilerinde homojenlik yarattı. Tüm validatorlerin etkin bakiyesi, ödül, bireysel ceza kesintisi, blok önerisi sıklığı ve diğer göstergeler aynıdır. Bu homojenlik, Ethereum'un konsensüs mekanizmasını istatistiksel anormallik olmaksızın test etmesine ve değerli ağ davranış verileri toplamasına olanak tanır.
Electra'dan sonra staking'in dağılımında önemli değişiklikler olacak. Büyük doğrulayıcılar, blok teklifi ve senkronizasyon komitelerine daha sık katılacak, slashing olaylarında daha büyük cezalarla karşı karşıya kalacak ve gecikmeli slashing, aktivasyon kuyrukları ve çıkış kuyrukları üzerinde daha büyük etkiye sahip olacak. Bu, veri toplamada zorluklar yaratabilse de, Ethereum'un fikir birliği, doğrusal olmayan hesaplamanın minimum düzeyde olmasını sağlar. Doğrusal olmayan tek bileşen, tüm doğrulayıcılar için geçerli olan temel ödülü hesaplamak için sqrt)total_effective_balance( kullanır. Bu, doğrulayıcı ödüllerinin ve kesintilerinin hala "1 ETH başına" (veya daha doğrusu, gelecekte değişebilecek spec.effective_balance_increment'e göre) tahmin edilebileceği anlamına gelir.
Daha fazla ayrıntı için, doğrulayıcı davranışıyla ilgili önceki makalemize bakın.
EIP-7002: Tetiklenebilir İcra Katmanı Çıkışı
Referans: EIP-7002
Ethereum'daki her doğrulayıcının iki anahtar çifti vardır: bir aktif anahtar ve bir para çekme anahtarı. Aktif genel BLS anahtarı, Beacon Chain'deki doğrulayıcının birincil kimliği olarak hizmet eder ve anahtar çifti, blokları, kanıtları, eğik çizgiyi, komite toplamasını senkronize etmek ve (bu EIP'den önce) gönüllü çıkışı (bir gecikmeden sonra doğrulayıcının konsensüs çıkışını başlatmak için) için kullanılır. İkinci anahtar çifti ("para çekme kimlik bilgisi") başka bir BLS anahtar çifti veya normal bir Eth1 hesabı (özel anahtar ve adres) olabilir. ETH adreslerine para çekme işlemleri artık aktif BLS özel anahtarı tarafından imzalanmış bir para çekme mesajı gerektiriyor. Bu EIP değişti.
Aslında, bu iki (aktif ve çekilme) anahtar çiftinin sahipleri farklı olabilir. Doğrulayıcının aktif anahtarı, doğrulama görevlerinden sorumludur: sunucuyu çalıştırmak, çalışır durumda tutmak vb., para çekme kimlik bilgileri genellikle ödülleri alan ve fonlardan sorumlu olan stake sahibi tarafından kontrol edilir. Şu anda, yalnızca para çekme kimlik bilgilerini kontrol eden stake sahibi, doğrulayıcının para çekme işlemini başlatamaz ve yalnızca ödülü çekebilir. Bu durum, doğrulayıcının aktif anahtar sahibinin, doğrulayıcının bakiyesini etkin bir şekilde "rehine" olarak tutmasına olanak tanır. Doğrulayıcılar çıkış mesajını "önceden imzalayabilir" ve stake sahibine teslim edebilir, ancak bu geçici çözüm ideal değildir. Ek olarak, hem çıkarma hem de çekme şu anda özel bir API aracılığıyla işaret katmanı doğrulayıcılarıyla etkileşim gerektirmektedir.
En iyi çözüm, pay sahiplerinin normal akıllı sözleşmeleri çağırarak çıkış ve para çekme işlemlerini aynı anda yapmalarına izin vermektir. Bu, standart Eth1 imza kontrolünü içerir ve işlemleri büyük ölçüde basitleştirir.
Bu EIP, tüm sahiplerin ETH adreslerinden özel akıllı sözleşmeye standart işlem göndererek çekme ve çıkışı tetiklemelerine izin verir (mevcut 'mevduat' sözleşmesini kullanarak mevduat sürecine benzer şekilde). Çekme (veya yeterli teminatın kaldırılmasıyla gerçekleştirilen çıkış) süreci aşağıdaki gibi gerçekleşir:
Stakeholders send withdrawal requests (in requests) to the system's 'withdrawal' contract.
Belirli bir ücret alır (ETH cinsinden) ve potansiyel kötü niyetli saldırıları hafifletmek için EIP-1559 gibi, istek kuyruğu meşgul olduğunda ücret artar.
Sözleşme, çekme/çıkış isteğini "in" depolama alanına kaydeder.
Bir blok önerildiğinde, işaret katmanındaki sıradaki "in" çekme / çıkış istekleri depodan alınır.
Beacon Chain, 'in' taleplerini işleyerek aktif doğrulayıcıların bakiyeleriyle etkileşime girer, doğrulayıcıların çıkışını düzenler ve 'out' para çekme talepleri oluşturur.
'out' çekme isteği yürütme katmanında işlenir ve teminat veren ETH'lerini alır.
Para yatırma, bir Eth1 bloğunda tetiklenen ve daha sonra "bekleyen" para yatırma kuyruğu aracılığıyla işaret katmanına "taşınan" bir eylem olsa da, para çekme işlemleri farklı bir şema izler. İşaret katmanında (CLI aracılığıyla) tetiklenirler ve ardından Eth1 bloğuna "taşınırlar". Şimdi, her iki şema da aynı ortak çerçeve üzerinden çalışacak (aşağıda açıklanmıştır): ETH1 katmanında istekler oluşturun, "bekleyen" para yatırma/çekme/birleştirme kuyruğunu işleyin ve bunları işaret katmanında işleyin. Para çekme gibi "çıktı" işlemleri için çıktı kuyruğu da işlenir ve sonuç Eth1 bloğuna "yerleşir".
Bu EIP aracılığıyla, stake edenler, doğrudan validator CLI ile etkileşime girmeye veya validator altyapısına erişmeye gerek kalmadan normal ETH işlemleri kullanarak validatorlarını çıkarabilirler. Bu, özellikle büyük stake sağlayıcıları için stake işlemlerini büyük ölçüde basitleştirir. Validator altyapısı artık neredeyse tamamen izole edilebilir, çünkü yalnızca aktif validatorların anahtarlarını korumak yeterli olup tüm stake işlemleri başka yerde gerçekleştirilebilir. Bu, bağımsız stake sağlayıcılarının aktif validator eylemlerini beklemelerini ortadan kaldırır ve Lido gibi Community Staking Module gibi hizmetlerin off-chain kısmını önemli ölçüde basitleştirir.
Bu nedenle, bu EIP, teminat işlemini "tamamladı" ve bunu tamamen Eth1 katmanına taşıdı, temel altyapı güvenlik riskini önemli ölçüde azalttı ve bağımsız teminat girişimini merkezi olmayan hale getirdi.
EIP-6110: Zincir Üstünde Doğrulayıcı Mevduatı Sağlama
Referans: EIP-6110
Şu anda, mevduat, 'Deposit)(' olayını tetikleyen 'mevduat' sözleşmesi sistemi aracılığıyla gerçekleştirilir (ayrıntılı olarak önceki makalede tartışıldığı gibi). Sözleşme, ETH ve doğrulayıcı belgelerini kabul eder ve 'Deposit)(' olayını gönderir, bu olaylar daha sonra işaret katmanında mevduat taleplerine dönüştürülür. Bu sistem birçok dezavantaja sahiptir: işaret zinciri katmanının eth1data'sına oy verilmesini gerektirir, bu da önemli bir gecikmeye neden olur. Ayrıca, işaret katmanının yürütme katmanını sorgulaması gereklidir, bu da karmaşıklığı daha da artırır. Bu sorunlar EIP'de detaylı olarak tartışılmıştır. Bu sorunların çoğuyla uğraşmayı gerektirmeyen daha basit bir yaklaşım, mevduat taleplerini doğrudan Eth1 bloklarına dahil etmektir. Bu mekanizma, önceki EIP'lerde açıklanan para çekme işlemleriyle benzerdir.
Bu EIP tarafından önerilen değişiklikler geleceği parlak. eth1data işlemi tamamen kaldırılabilir, artık Eth1 tarafında olaylar ve beacon katmanı arasında oy kullanılmasına veya uzun süreli gecikmelere (şu anda yaklaşık 12 saat) ihtiyaç duyulmaz. Ayrıca, mevduat sözleşmesinin anlık görüntüsü kaldırıldı. Bu EIP, mevduat işlemini basitleştirir ve çekme işleme yöntemiyle uyumlu hale getirir.
Stakerlar ve doğrulayıcılar için, bu değişiklikler yatırım ve doğrulayıcının etkinleştirilmesi arasındaki gecikmeyi önemli ölçüde azaltır. Doğrulayıcıların kesintiye uğratılması durumunda, gerekli tamamlama işlemleri de daha hızlı olacaktır.
Bu EIP hakkında söyleyecek daha fazla bir şey yok, eskimiş mantığı kaldırdı, süreci basitleştirdi ve ilgili herkes için daha iyi sonuçlar yarattı.
EIP-7685: Genel Yürütme Katmanı İsteği
Referans: EIP-7685
Bu EIP, depozito/çekme/birleştirme ile ilgili ilk üç EIP'den önce sunulmalıydı, çünkü bu EIP'ler için temel oluşturdu. Ancak burada tanıtılması, Eth1 (yürütme) ve beacon (consensus) zincir blokları (katmanlar) arasında özel veri hareketliliğinin giderek artan ihtiyacını vurgulamak için yapılmıştır. Bu EIP, iki katmanı etkileyerek, normal ETH işlemiyle tetiklenen istekleri daha verimli bir şekilde işlemeyi sağlar. Şu anda, gözlemlediğimiz durum: )
Eth1 blokundaki depozito olayı, işleme amacıyla beacon bloğuna 'taşındı'.
İşaret bloğundaki para çekme isteği (CLI kullanarak) Eth1 bloğuna taşındı ve orada işleme alınıyor.
Beacon request'ini gerektirir.
Bu üç eylem, yürütme katmanı ve işaret katmanı arasında geçiş yaparken çeşitli türdeki isteklerin tutarlı işlenmesinin gerekliliğini göstermektedir. Ayrıca, doğrulayıcıların altyapısını ve bağış yönetimi altyapısını izole etmek ve böylece güvenliği artırmak için yalnızca Eth1 katmanını tetiklemek için kullanmamız gereken bir yeteneğe ihtiyacımız var. Bu nedenle, bu tür istekleri yönetmek için genel bir çözüm hem pratik hem de gerekli bir durumdur.
Bu EIP, depozito, çekme ve birleştirme gibi en az üç ana durum için bir çerçeve oluşturur. Bu nedenle, erken EIP'ler WITHDRAWAL_REQUEST_TYPE ve DEPOSIT_REQUEST_TYPE gibi alanlar tanıtırken, birleştirme şimdi başka bir alan ekleyecek: CONSOLIDATION_REQUEST_TYPE. Ayrıca, bu EIP, bu tür talepleri işlemek için genel bir mekanizma (PENDING_DEPOSITS_LIMIT, PENDING_PARTIAL_WITHDRAWALS_LIMIT, PENDING_CONSOLIDATIONS_LIMIT sabitleri ile ilgili) de içerebilir.
Bu çerçevenin ayrıntılı uygulama ayrıntıları henüz mevcut olmasa da, kesinlikle ana istek türlerini, bütünlük mekanizmalarını (örneğin, karma ve Merkelize istekler) ve işlem sırasını ve hız sınırlamasını içerecektir.
Bu EIP, Eth1'in kritik işlemleri birleşik bir çerçeve aracılığıyla işaretçi katmanında tetikleyebilmesi için mimari anlamda önemlidir. Son kullanıcılar ve projeler için, bu Eth1 katmanında tetiklenen tüm taleplerin işaretçi katmanında daha verimli bir şekilde iletilip işleneceği anlamına gelir.
EIP-2537: Ön derlenmiş BLS12-381 eğrisi işlemleri
Referans: EIP-2537
Eğer daha fazla ayrıntıya girmek istemiyorsanız, önceden derlenmiş BLS12-381'i karmaşık bir şifreleme 'hash' işlemi olarak düşünebilirsiniz ve şimdi akıllı sözleşmelerde kullanabilirsiniz. İlgi duyanlar için daha fazla araştıralım.
BLS12-381（ve buna karşılık gelen BN-254） gibi eliptik eğriler üzerinde yapılan matematiksel işlemler şu anda iki amaç için kullanılmaktadır:
BLS imzası, bu imzaları doğrulamak için 'eşleştirme' adı verilen özel bir işlemi kullanan. BLS imzaları, çeşitli imzaları bir araya getirebildikleri için doğrulayıcılar tarafından geniş çapta kullanılır. Doğrulayıcılar, BLS imzalarına dayanır (bununla birlikte, BN254 gibi eşleştirmeyi destekleyen herhangi bir eğri uygulaması da kullanılabilir) BLS12-381 eğrisine dayalı.
zkSNARK kanıtının doğrulanması, eşleştirme kanıtın doğrulanması için kullanılır. Ayrıca, Dencun hard fork tarafından tanıtılan büyük bloklar için KZG taahhüdü, blok taahhüdünün doğrulanması için eşleştirme kullanır.
Eğer akıllı bir sözleşmede BLS imzasını veya zkSNARK kanıtını doğrulamak istiyorsanız, bu 'eşleştirme'leri hesaplamanız gerekir, bu hesaplama oldukça pahalıdır. Ethereum'da, BN254 eğrisi işlemleri için önceden derlenmiş bir sözleşme (EIP-196 ve EIP-197) zaten mevcuttur. Bununla birlikte, BLS12-381 eğrisi (şu anda daha güvenli ve daha yaygın olarak kullanılmaktadır) henüz önceden derlenmiş olarak uygulanmamıştır. Bu tür bir önceden derlenmiş olmadan, akıllı bir sözleşmede eşleştirme ve diğer eğri işlemlerini gerçekleştirmek büyük miktarda hesaplama gerektirir, burada gösterildiği gibi ve büyük miktarda gaz tüketir (yaklaşık ~10^5 ila 10^6 gaz).
Bu EIP, özellikle BLS12-381 eğrisine dayalı ucuz BLS imza doğrulaması alanında birçok potansiyel uygulamanın kapısını açmaktadır. Bu, çeşitli amaçlar için eşik şemasının uygulanabilir hale gelmesini sağlar. Ethereum doğrulayıcıları zaten BLS12-381 tabanlı imzaları kullanmaktadır. Bu EIP aracılığıyla standart akıllı sözleşmeler artık toplu doğrulayıcı imzalarını verimli bir şekilde doğrulayabilir. Bu, konsensüs kanıtını ve farklı ağ varlıklarının köprülenmesini basitleştirebilir çünkü BLS imzaları blok zincirinde yaygın olarak kullanılır. Eşik BLS imzası kendisi, oylama, merkezi olmayan rastgele sayı üretimi, çoklu imza vb. için birçok verimli eşik şeması oluşturmayı mümkün kılar.
Daha ucuz zkSNARK kanıt doğrulaması, birçok uygulamanın kilidini açabilir. Şu anda, yüksek kanıt doğrulama maliyeti nedeniyle birçok zkSNARK tabanlı çözümün bazı projelerin neredeyse imkansız hale gelmesine neden olduğu biliniyor. Bu EIP'nin bu durumu değiştirme potansiyeli var.
EIP-2935: Geçmiş blok karma değerlerini durumda saklama
Referans: EIP-2935
Bu EIP, rollup gibi durumsuz istemciler ve akıllı sözleşmeler için genişletilmiş bir geçmiş sağlamak için blok zinciri durumunda 8192 (yaklaşık 27.3 saat) tarihli blok karmaşasını depolamayı önerir. Mevcut BLOCKHASH işlem kodunun davranışını korumayı, 256 blok sınırlamasını sürdürmeyi ve aynı zamanda tarihli karmaşaları depolamak ve geri almak için özel olarak tasarlanmış yeni bir sistem sözleşmesi tanıtmayı önerir. Bu sözleşme, blok işlemek için set() işlemini gerçekleştirir. get() yöntemi, istenen blok karmaşasını döngüsel bir tampon bölgeden almak için herkese erişilebilir.
Şu anda, EVM'de geçmiş blok hash'lerine başvurmak mümkün olsa da, erişim en son 256 blokla sınırlıdır (yaklaşık 50 dakika). Bununla birlikte, bazı durumlarda daha eski blok verilerine erişim son derece önemlidir, özellikle cross-chain uygulamalar için (önceki blok verilerini kanıtlamak gerektiren) ve stateless istemciler için, bunlar periyodik olarak erken blok hash'lerine erişim gerektirir.
Bu EIP, rollup ve cross-chain uygulamalarının kullanabileceği zaman aralığını genişletir ve bunların dışarıdan toplama yapmadan EVM'de doğrudan geçmiş verilere erişmesine izin verir. Bu nedenle, bu çözümler daha sağlam ve sürdürülebilir hale gelir.
EIP-7623: Artırılmış calldata maliyeti
Referans: EIP-7623
calldata, bazı durumlarda (örneğin, büyük bir dizi veya ikili tampon olarak parametre olarak iletilirken) işlemin etkin yükünün kullanılabilir boyutunu ayarlar ve bu büyük olabilir. Önemli calldata kullanımı genellikle rollup'a atfedilir, bunlar mevcut rollup durumunu içeren calldata'yı göndererek etkin yüklerini ileterek gerçekleşir.
Büyük ölçekli, kanıtlanabilir ikili verilerin blok zincire dahil edilmesi, rollup için son derece önemlidir. Dencun (Deneb-Cancun), bu tür kullanımlar için önemli bir yenilik olan blob işlemlerini (EIP-4844) tanıttı. Blob işlemleri, kendi özel 'blob' gaz ücretine sahiptir; aslında geçici olarak depolanmış olsalar da, şifreli kanıt (KZG taahhütleri) ve hash'leri ile birlikte konsensüs katmanına entegre edilmişlerdir. Bu nedenle, veri depolamak için calldata kullanmaktan farklı olarak, blob, rollup için daha iyi bir çözüm sunar.
Rollup'u teşvik etmek, verilerini blob'a taşıyarak 'havuç ve sopa' yöntemiyle gerçekleştirilebilir. Düşürülen blob gaz ücreti 'havuç' olarak hizmet ederken, bu EIP, aşırı veri depolamayı engellemek için calldata maliyetini artırarak 'kaldıraç' görevi görür. Bu EIP, bir sonraki EIP-7691'e (Blob Throughput Increase) ek bir katkıdır, ki bu da her blok için izin verilen en fazla blob sayısını artırır.
EIP-7691: blob Throughput Increases
Referans: EIP-7691
Daha önceki Dencun sert çatalında, bir blob tanıtıldı ve her bloğun blob'unun maksimum ve hedef sayısı muhafazakar bir tahmin olarak belirlendi. Bu, büyük ikili nesnelerin doğrulayıcı düğümler arasında nasıl işleneceğini tahmin etmenin karmaşıklığından kaynaklanmaktadır. Önceki yapılandırmanın iyi performans gösterdiği kanıtlanmıştır, bu da yeni değerleri test etmenin uygun bir zaman olduğu anlamına gelmektedir. Daha önce, her bloğun hedef/maksimum blob sayısı 3/6 olarak ayarlanmıştı. Bu sınırlamalar şimdi sırasıyla 6/9'a yükseltilmiştir.
EIP-7623 (calldata maliyetini artıran) ile birleşerek, bu ayar, verilerini calldata'dan blob'lara taşıma konusunda rollup'ı daha da teşvik ediyor. En iyi blok parametrelerini bulma çalışması devam ediyor.
EIP-7840: EL yapılandırma dosyasına blob işlemini ekleyin
Referans: EIP-7840
Bu EIP önerisi, hedef ve maksimum 'her blok' blog sayısını (önceki tartışmalarda bahsedildiği gibi) ve baseFeeUpdateFraction değerini Ethereum yürütme katmanı (EL) yapılandırma dosyasına ekler. Ayrıca, istemciye bu değerleri düğüm API'si aracılığıyla almanıza olanak tanır. Bu özellik, blog gaz ücretlerini tahmin etmek gibi görevler için özellikle yararlıdır.
EIP-7702: EOA Hesap Kodu Ayarı
Referans: EIP-7702
Bu, Ethereum kullanıcılarına önemli değişiklikler getirecek çok önemli bir EIP'dir. Bildiğimiz gibi, EOA (Dış Akıllı Sözleşme) herhangi bir kod içermemeli, ancak işlem imzası sağlayabilir (tx.origin). Bununla karşılaştırıldığında, akıllı sözleşmelerin baytları olabilir, ancak doğrudan bir imza sunamazlar. Şu anda, ek, otomatik ve doğrulanabilir mantığa ihtiyaç duyan herhangi bir kullanıcı etkileşimi yalnızca dış sözleşmeleri çağırarak gerçekleştirilebilir. Bununla birlikte, bu durumda, dış sözleşmeler, sonraki sözleşmelerin msg.sender'ı haline gelir, bu da 'kullanıcıdan değil, sözleşmeden gelen çağrıları' yapar.
Bu EIP, yeni bir SET_CODE_TX_TYPE=0x04 işlem türü sunar (daha önce eski 0x1 işlemine, Berlin'den yeni 0x02 işlemine ve EIP-1559 yükseltmesine ve Dencun'da tanıtılan 0x03 blob işlemine sahiptik). Bu yeni ticaret türü, EOA hesapları için kodlar ayarlamanıza olanak tanır. Aslında, EOA'nın "kendi EOA hesabı bağlamında" harici kod yürütmesine izin verir. Dışarıdan bakıldığında, EOA harici bir sözleşmeden kod "ödünç alıyor" ve bir işlem sırasında yürütüyor gibi görünüyor. Teknik olarak bu, EOA adresinin "kod" deposuna bir dizi özel yetkilendirme verisi eklenerek yapılır (bu EIP'ye kadar, bu "kod" deposu EOA için her zaman boştu).
Şu anda, bu EIP önerisindeki yeni 0x04 işlem türü bir dizi içeriyor:
Her öğe, hesabın belirtilen adresten gelen kodları kullanmasına izin verir (en son geçerli yetkilendirme öğesinden). Bu tür işlemleri işlerken, belirtilen EOA kodu özel bir 0xef0100 || adres değeri (23 bayt) olarak ayarlanır ve adres, gereken kodu içeren bir sözleşmeye işaret eder, || bağlantıyı temsil eder, 0xef0100, EIP-3541'e göre normal akıllı sözleşmelerin içeremeyeceği özel sihirli bir değeri temsil eder. Bu sihirli değer, bu EOA'nın normal bir sözleşme olarak görülemeyeceğinden ve normal bir sözleşme gibi çağrılamayacağından emin olur.
Bu EOA işlemi başlattığında, belirtilen adres, ilgili kodları çağırmak için bu EOA'nın bağlamında kullanılacaktır. Bu EIP'nin tam uygulama detayları henüz net olmasa da, büyük değişiklikler getireceği kesindir.
Birincil etkilerden biri, EOA'dan doğrudan çoklu çağrı (multicall) yapabilme yeteneğidir. Multicall, DeFi'de sürekli bir trenddir ve birçok protokol, Uniswap V4, Balancer V3 veya Euler V2 gibi güçlü bir araç olarak bu özelliği sunar. Bu EIP sayesinde artık EOA'dan doğrudan çoklu çağrı başlatılabilir.
Örneğin, bu yeni özellik DeFi'deki yaygın bir sorunu çözer: approve() + anything()'nin iki ayrı işlem gerektiren verimsizliği. Bu EIP, approve(X) + deposit(X) gibi genel 'ön izin' mantığına izin verir ve tek bir işlemde tamamlanmasını sağlar.
EOA'nın vekaleten işlem yürütebildiği bir diğer avantaj da sponsorluk kavramıdır. Sponsorluk, Ethereum'a yeni kullanıcıların girmesine yardımcı olmak için sıkça tartışılan ve büyük özlem duyulan bir özelliktir.
EOA ile ilişkili programlanabilir mantık, güvenlik kısıtlamaları uygulama, harcama sınırı belirleme, KYC gereksinimleri zorlama gibi birçok olasılığı açar.
Tabii ki, bu değişim aynı zamanda bir dizi tasarım sorusunu da gündeme getiriyor. Sorunlardan biri, imzaya dahil edilip edilmediğine bağlı olarak aynı imzanın birden fazla ağda geçerli olup olmayacağını belirleyen zincir_id kullanımıdır. Diğer bir komplikasyon, nesne kodunun adresini kullanmak ile gerçek bayt kodunu gömmek arasındaki seçimdir. Her iki yöntemin de kendine özgü özellikleri ve sınırlamaları vardır. Ek olarak, nonce kullanımı, bir iznin "çok amaçlı" mı yoksa "tek amaçlı" mı olduğunu tanımlamada önemli bir rol oynar. Bu öğeler, toplu geçersiz kılma imzaları ve kullanım kolaylığı gibi hususlar da dahil olmak üzere işlevsellik ve güvenlik sorunlarını etkiler. Vitalik, bu soruları daha fazla araştırmaya değer bir tartışmada (burada) gündeme getirdi.
Bu değişikliğin Ethereum'un güvenlik mekanizmalarından biri olan tx.origin'i etkileyeceğini belirtmekte fayda var. Bu EIP uygulaması hakkında daha fazla ayrıntı gereklidir, ancak require(tx.origin == msg.sender) davranışı değişecek gibi görünüyor. Bu kontrol, msg.sender'ın bir sözleşme değil, bir EOA olduğundan emin olmanın en kesin yolu olmuştur. EXTCODESIZE'I KONTROL ETMEK (BUNUN BIR SÖZLEŞME OLUP OLMADIĞINI KONTROL ETMEK IÇIN) GIBI DIĞER YÖNTEMLER GENELLIKLE BAŞARISIZ OLUR VE ATLATILABILIR (ÖRNEĞIN, OLUŞTURUCUYU ÇAĞIRARAK VEYA BIR IŞLEMDEN SONRA KODU ÖNCEDEN TANIMLANMIŞ BIR ADRESE DAĞITARAK). Bu kontroller, yeniden giriş ve flaş kredi saldırılarını önlemek için kullanılır, ancak harici protokollerle entegrasyonu da engelledikleri için ideal olmaktan uzaktır. Güvenilir requiretx.origin == msg.sender kontrolü bile bu EIP'den sonra geçerliliğini yitirmiş gibi görünüyor. "EOA" ve "sözleşme" arasındaki ayrım artık geçerli olmayacağından, protokolün bu kontrolleri kaldırarak uyum sağlaması gerekiyordu - artık her adresin kendisiyle ilişkili bir kodu olabilirdi.
Geleneksel EOA ve akıllı sözleşmeler arasındaki ayrım giderek belirsizleşiyor. Bu EIP, Ethereum'u her hesabın temelde yürütülebilir kod olduğu TON gibi tasarımlara daha da yaklaştırıyor. Protokolle etkileşim giderek karmaşık hale geldikçe, son kullanıcı deneyimini iyileştirmek için programlanabilir mantığı kullanmak, bu evrimin doğal bir parçasıdır.
Sonuç
布拉格 /Electra（Pectra）升级定于 2025 年 3 月。其最显著的计划变更包括：
Değişken doğrulayıcılar için geçerli olan maksimum stake miktarı 2048 ETH'ye kadar çıkabilir, bu durum stake dağılımını ve doğrulayıcı zamanlamasını önemli ölçüde değiştirecek ve daha küçük stake miktarlarını yönetmeyi basitleştirerek büyük stake sağlayıcılarını entegre edecektir.
İcra katmanı ile uzlaşma katmanı arasındaki etkileşimi geliştirmek, Eth1 icra bloğu ile tanık zinciri bloğu arasındaki veri alışverişini basitleştirmek. Bu, depozito, etkinleştirme, çekme ve çıkış işlemlerini büyük ölçüde basitleştirecek, bu süreçleri hızlandıracak ve uzlaşma katmanı ile icra katmanı arasındaki daha fazla etkileşimin temelini oluşturacak.
Akıllı sözleşmelerde, yeni 'eşleme dostu' BLS12-381 derlemesi aracılığıyla daha ucuz BLS imzaları ve zkSNARK doğrulamaları doğrudan desteklenmektedir
Rollups'un blob işlemlerini artırarak blob işlemlerinin eşik değerini yükseltmesi ve calldata maliyetini artırması teşvik edilmektedir.
EOA'yı programlanabilir bir hesap olarak kullanarak, çoklu çağrı, sponsorluk ve diğer gelişmiş özellikler sağlanır
Gördüğünüz gibi, Pectra, stake ve konsensüs katmanı ile yürütme katmanı üzerindeki son kullanıcı deneyimini büyük ölçüde etkileyecektir. Kod ayrıntılı olarak incelenemese de, geliştirme devam ettiği için bu değişikliklerin hepsini bu aşamada kapsayamıyoruz, ancak gelecekteki yazılarda bu güncellemeleri ele alacağız.
The content is for reference only, not a solicitation or offer. No investment, tax, or legal advice provided. See Disclaimer for more risks disclosure.
Yaklaşan Hard Fork - Pectra Güncellemesiyle ETH ağının ayrıştırılması
Tanıtım
Önceki makalemizde Ethereum doğrulayıcısının yaşam döngüsünü detaylı bir şekilde inceledik ve yaklaşan Electra hard fork ile ilgili birçok yönü tartıştık. Şimdi, yaklaşan Electra ve Prague güncellemelerindeki değişikliklere odaklanma ve detaylı bir şekilde açıklama zamanı geldi.
Ethereum 2.0 'Proof of Stake' hard fork history is complex. It started with adding the beacon chain to the existing execution layer, while the execution layer still maintained proof of work consensus (Phase0 and Altair hard forks). Then, in the Bellatrix hard fork, PoS was fully activated (although withdrawals were not enabled). Subsequently, the Capella hard fork allowed for withdrawals, completing the validator lifecycle. The recent Deneb hard fork (part of the Deneb/Cancun upgrade) made minor revisions to the beacon chain parameters, such as the inclusion of proof-of-time windows, handling voluntary exits, and validator rotation limits. The main changes in Deneb occurred in the execution layer, introducing blob transactions, blob gas, KZG commitments for blobs, and deprecating the SELFDESTRUCT operation.
Şu anda, Prague/Electra (yani Pectra) hard fork, yürütme ve konsensüs katmanına önemli bir güncelleme getirdi. Lido projesinin denetçileri olarak, özellikle bu hard fork'ta konsensüs ve staking ile ilgili değişikliklere odaklanıyoruz. Ancak, Prague'daki yürütme katmanındaki değişiklikleri göz ardı edemeyiz, çünkü bunlar Ethereum ağını ve doğrulayıcıları etkileyen önemli özellikleri içerir. Bu değişikliklerin detaylarına derinlemesine inelim.
Pectra'nın daha yüksek düzeyde genel bir bakışı
Electra, işaret katmanına birçok özellik ekledi. Başlıca güncellemeler şunları içerir:
Bu arada, Prag'da yürütme katmanına şu değişiklikler getirildi:
Daha fazla tartışma için, ilgili Ethereum İyileştirme Önerisi (EIP)'yi referans alalım.
Bu EIP'lerin bazıları çoğunlukla konsensüs (beacon) katmanını, diğerleri ise yürütme katmanını ilgilendirmektedir. Bazıları iki katmanı da kapsar çünkü bazı işlemler (örneğin, depozito ve çekme) konsensüs ve yürütme katmanları arasında senkron değişiklik gerektirir. Bu karşılıklı bağımlılık nedeniyle, Electra ve Prague'yi ayırmak pratik değildir, bu nedenle her bir EIP'yi sırayla gözden geçireceğiz ve etkilenen Ethereum bileşenlerini belirleyeceğiz.
EIP-7251: MAX_EFFECTIVE_BALANCE EKLEME
Referans: EIP-7251
İlk Phase0 sert çatalından bu yana, Ethereum'un proof of stake'e hazırlanması için, Electra'ya kadar, validatorların maksimum etkin bakiyesi sabitlenmiş 32 ETH olarak belirlenmiştir. Validatorları etkinleştirmek için en az spec.min_activation_balance (32 ETH) gerekir. Etkinleştikten sonra, validatorlar bu maksimum etkin bakiyeden başlar ancak etkin bakiyelerini spec.ejection_balance (16 ETH) seviyesine düşürebilir ve bu eşiğe ulaşıldığında atılabilirler. Bu "minimum" mantık Electra'da aynen devam ederken, şimdi spec.max_effective_balance 2048 ETH'ye yükseltilmiştir. Bu nedenle, validatorlar 32 ile 2048 ETH arasında bir depozito yaparak etkinleştirilebilir, tüm bu miktarlar etkin bakiyelerine katkıda bulunacaktır. Bu değişiklik, "32ETH- stake"den "stake"ye geçişi işaret ediyor.
Bu değişken geçerli bakiye şu anda kullanılacaktır:
İlk iki etkinlik, doğrulayıcılar için en karlı işlemlerdir. Bu nedenle, Electra'dan sonra, yüksek miktarda staking yapan doğrulayıcılar blok önerme ve senkronizasyon komitesine daha sık katılacaklar ve frekansları geçerli bakiyeleriyle orantılı olacaktır.
Başka bir etkisi azaltmayla ilgilidir. Tüm kesinti cezaları doğrulayıcının geçerli bakiyesi ile orantılıdır:
Electra, azaltma oranına yönelik değişiklikler de sunmuş, azaltılan doğrulayıcı bakiyesinin bir kısmını tanımlamış ve bildiren kişi tarafından alınmıştır.
Sonraki şey geçersizlik etkisidir. Bir doğrulayıcı aktifken (ispatlama veya teklif) çevrimdışı olduğunda, geçersizlik puanı birikir ve her dönemde geçersizlik cezası uygulanır. Bu cezalar ayrıca doğrulayıcının geçerli bakiyesiyle orantılıdır.
Geçerli bakiyenin artması nedeniyle doğrulayıcıların "değiştirme sınırlaması" da değişti. Ethereum'un "Electra'dan önceki" versiyonunda doğrulayıcılar genellikle aynı geçerli bakiyeye sahiptir ve çıkış değiştirme sınırlaması "bir döngü içinde toplam stakingin 1/65536'sından fazlasının çıkış yapamaz" şeklinde tanımlanır. Bu, aynı stakinge sahip doğrulayıcıların "sabit" bir çıkış miktarı oluşturur. Ancak, "Electra'dan sonra" sadece birkaç "balina"nın çıkabileceği durumlar ortaya çıkabilir çünkü bunlar toplam stakingin önemli bir kısmını temsil eder.
Başka bir düşünce, bir tek doğrulayıcı örneği üzerinde birçok doğrulayıcı anahtarının dönüşümüdür. Büyük doğrulayıcılar şu anda büyük miktarlarda teminatı karşılamak için bir örnekte binlerce doğrulayıcı anahtarı çalıştırmak zorunda bırakılıyor, bunları 32 ETH bölümüne ayırıyor. Electra ile bu davranış artık zorunlu değil. Finansal açıdan, bu değişikliğin etkisi çok büyük değil, çünkü ödül ve olasılık teminat miktarıyla doğrusal olarak ölçeklenir. Bu nedenle, her biri 32 ETH olan 100 doğrulayıcı, 3200 ETH'lık bir doğrulayıcıya eşittir. Ayrıca, birden fazla etkin doğrulayıcı anahtarı aynı Eth1 çekme belgesine sahip olabilir, bu da tüm ödüllerin tek bir ETH adresine çekilmesine izin verir ve ödül birleştirmeyle ilişkili gaz maliyetinden kaçınır. Bununla birlikte, birçok anahtarın yönetimi ek yönetim maliyeti doğurur.
Aggregator validatorının bakiye yeteneği, yeni bir yürütme katmanı istek türü ekledi. Daha önce, yatırma ve çekme vardı. Şimdi ise başka bir tür olacak: toplama isteği. İki doğrulayıcı birleştirilecek. Bu işlem isteği, kaynak doğrulayıcının genel anahtarını ve hedef genel anahtarını içerecek ve yatırma ve çekme gibi işlemler gerçekleştirilecek. Toplamda, işleme alınacak istekler ve bakiye değiştirme sınırlamaları olacak, yatırma ve çekme gibi.
Aşağıda özetlenmiştir:
Başka bir önemli konu, validatorlerin tarih verileri ve kar tahmini, özellikle yeni katılımcılar için ilgilidir, risk ve getiriyi değerlendirmeye çalışırlar. Electra'dan önce (bu yazı yazılırken), 32 ETH sınırı (aslında en küçük veya en büyük olması fark etmeksizin) tarih verilerinde homojenlik yarattı. Tüm validatorlerin etkin bakiyesi, ödül, bireysel ceza kesintisi, blok önerisi sıklığı ve diğer göstergeler aynıdır. Bu homojenlik, Ethereum'un konsensüs mekanizmasını istatistiksel anormallik olmaksızın test etmesine ve değerli ağ davranış verileri toplamasına olanak tanır.
Electra'dan sonra staking'in dağılımında önemli değişiklikler olacak. Büyük doğrulayıcılar, blok teklifi ve senkronizasyon komitelerine daha sık katılacak, slashing olaylarında daha büyük cezalarla karşı karşıya kalacak ve gecikmeli slashing, aktivasyon kuyrukları ve çıkış kuyrukları üzerinde daha büyük etkiye sahip olacak. Bu, veri toplamada zorluklar yaratabilse de, Ethereum'un fikir birliği, doğrusal olmayan hesaplamanın minimum düzeyde olmasını sağlar. Doğrusal olmayan tek bileşen, tüm doğrulayıcılar için geçerli olan temel ödülü hesaplamak için sqrt)total_effective_balance( kullanır. Bu, doğrulayıcı ödüllerinin ve kesintilerinin hala "1 ETH başına" (veya daha doğrusu, gelecekte değişebilecek spec.effective_balance_increment'e göre) tahmin edilebileceği anlamına gelir.
Daha fazla ayrıntı için, doğrulayıcı davranışıyla ilgili önceki makalemize bakın.
EIP-7002: Tetiklenebilir İcra Katmanı Çıkışı
Referans: EIP-7002
Ethereum'daki her doğrulayıcının iki anahtar çifti vardır: bir aktif anahtar ve bir para çekme anahtarı. Aktif genel BLS anahtarı, Beacon Chain'deki doğrulayıcının birincil kimliği olarak hizmet eder ve anahtar çifti, blokları, kanıtları, eğik çizgiyi, komite toplamasını senkronize etmek ve (bu EIP'den önce) gönüllü çıkışı (bir gecikmeden sonra doğrulayıcının konsensüs çıkışını başlatmak için) için kullanılır. İkinci anahtar çifti ("para çekme kimlik bilgisi") başka bir BLS anahtar çifti veya normal bir Eth1 hesabı (özel anahtar ve adres) olabilir. ETH adreslerine para çekme işlemleri artık aktif BLS özel anahtarı tarafından imzalanmış bir para çekme mesajı gerektiriyor. Bu EIP değişti.
Aslında, bu iki (aktif ve çekilme) anahtar çiftinin sahipleri farklı olabilir. Doğrulayıcının aktif anahtarı, doğrulama görevlerinden sorumludur: sunucuyu çalıştırmak, çalışır durumda tutmak vb., para çekme kimlik bilgileri genellikle ödülleri alan ve fonlardan sorumlu olan stake sahibi tarafından kontrol edilir. Şu anda, yalnızca para çekme kimlik bilgilerini kontrol eden stake sahibi, doğrulayıcının para çekme işlemini başlatamaz ve yalnızca ödülü çekebilir. Bu durum, doğrulayıcının aktif anahtar sahibinin, doğrulayıcının bakiyesini etkin bir şekilde "rehine" olarak tutmasına olanak tanır. Doğrulayıcılar çıkış mesajını "önceden imzalayabilir" ve stake sahibine teslim edebilir, ancak bu geçici çözüm ideal değildir. Ek olarak, hem çıkarma hem de çekme şu anda özel bir API aracılığıyla işaret katmanı doğrulayıcılarıyla etkileşim gerektirmektedir.
En iyi çözüm, pay sahiplerinin normal akıllı sözleşmeleri çağırarak çıkış ve para çekme işlemlerini aynı anda yapmalarına izin vermektir. Bu, standart Eth1 imza kontrolünü içerir ve işlemleri büyük ölçüde basitleştirir.
Bu EIP, tüm sahiplerin ETH adreslerinden özel akıllı sözleşmeye standart işlem göndererek çekme ve çıkışı tetiklemelerine izin verir (mevcut 'mevduat' sözleşmesini kullanarak mevduat sürecine benzer şekilde). Çekme (veya yeterli teminatın kaldırılmasıyla gerçekleştirilen çıkış) süreci aşağıdaki gibi gerçekleşir:
Para yatırma, bir Eth1 bloğunda tetiklenen ve daha sonra "bekleyen" para yatırma kuyruğu aracılığıyla işaret katmanına "taşınan" bir eylem olsa da, para çekme işlemleri farklı bir şema izler. İşaret katmanında (CLI aracılığıyla) tetiklenirler ve ardından Eth1 bloğuna "taşınırlar". Şimdi, her iki şema da aynı ortak çerçeve üzerinden çalışacak (aşağıda açıklanmıştır): ETH1 katmanında istekler oluşturun, "bekleyen" para yatırma/çekme/birleştirme kuyruğunu işleyin ve bunları işaret katmanında işleyin. Para çekme gibi "çıktı" işlemleri için çıktı kuyruğu da işlenir ve sonuç Eth1 bloğuna "yerleşir".
Bu EIP aracılığıyla, stake edenler, doğrudan validator CLI ile etkileşime girmeye veya validator altyapısına erişmeye gerek kalmadan normal ETH işlemleri kullanarak validatorlarını çıkarabilirler. Bu, özellikle büyük stake sağlayıcıları için stake işlemlerini büyük ölçüde basitleştirir. Validator altyapısı artık neredeyse tamamen izole edilebilir, çünkü yalnızca aktif validatorların anahtarlarını korumak yeterli olup tüm stake işlemleri başka yerde gerçekleştirilebilir. Bu, bağımsız stake sağlayıcılarının aktif validator eylemlerini beklemelerini ortadan kaldırır ve Lido gibi Community Staking Module gibi hizmetlerin off-chain kısmını önemli ölçüde basitleştirir.
Bu nedenle, bu EIP, teminat işlemini "tamamladı" ve bunu tamamen Eth1 katmanına taşıdı, temel altyapı güvenlik riskini önemli ölçüde azalttı ve bağımsız teminat girişimini merkezi olmayan hale getirdi.
EIP-6110: Zincir Üstünde Doğrulayıcı Mevduatı Sağlama
Referans: EIP-6110
Şu anda, mevduat, 'Deposit)(' olayını tetikleyen 'mevduat' sözleşmesi sistemi aracılığıyla gerçekleştirilir (ayrıntılı olarak önceki makalede tartışıldığı gibi). Sözleşme, ETH ve doğrulayıcı belgelerini kabul eder ve 'Deposit)(' olayını gönderir, bu olaylar daha sonra işaret katmanında mevduat taleplerine dönüştürülür. Bu sistem birçok dezavantaja sahiptir: işaret zinciri katmanının eth1data'sına oy verilmesini gerektirir, bu da önemli bir gecikmeye neden olur. Ayrıca, işaret katmanının yürütme katmanını sorgulaması gereklidir, bu da karmaşıklığı daha da artırır. Bu sorunlar EIP'de detaylı olarak tartışılmıştır. Bu sorunların çoğuyla uğraşmayı gerektirmeyen daha basit bir yaklaşım, mevduat taleplerini doğrudan Eth1 bloklarına dahil etmektir. Bu mekanizma, önceki EIP'lerde açıklanan para çekme işlemleriyle benzerdir.
Bu EIP tarafından önerilen değişiklikler geleceği parlak. eth1data işlemi tamamen kaldırılabilir, artık Eth1 tarafında olaylar ve beacon katmanı arasında oy kullanılmasına veya uzun süreli gecikmelere (şu anda yaklaşık 12 saat) ihtiyaç duyulmaz. Ayrıca, mevduat sözleşmesinin anlık görüntüsü kaldırıldı. Bu EIP, mevduat işlemini basitleştirir ve çekme işleme yöntemiyle uyumlu hale getirir.
Stakerlar ve doğrulayıcılar için, bu değişiklikler yatırım ve doğrulayıcının etkinleştirilmesi arasındaki gecikmeyi önemli ölçüde azaltır. Doğrulayıcıların kesintiye uğratılması durumunda, gerekli tamamlama işlemleri de daha hızlı olacaktır.
Bu EIP hakkında söyleyecek daha fazla bir şey yok, eskimiş mantığı kaldırdı, süreci basitleştirdi ve ilgili herkes için daha iyi sonuçlar yarattı.
EIP-7685: Genel Yürütme Katmanı İsteği
Referans: EIP-7685
Bu EIP, depozito/çekme/birleştirme ile ilgili ilk üç EIP'den önce sunulmalıydı, çünkü bu EIP'ler için temel oluşturdu. Ancak burada tanıtılması, Eth1 (yürütme) ve beacon (consensus) zincir blokları (katmanlar) arasında özel veri hareketliliğinin giderek artan ihtiyacını vurgulamak için yapılmıştır. Bu EIP, iki katmanı etkileyerek, normal ETH işlemiyle tetiklenen istekleri daha verimli bir şekilde işlemeyi sağlar. Şu anda, gözlemlediğimiz durum: )
Bu üç eylem, yürütme katmanı ve işaret katmanı arasında geçiş yaparken çeşitli türdeki isteklerin tutarlı işlenmesinin gerekliliğini göstermektedir. Ayrıca, doğrulayıcıların altyapısını ve bağış yönetimi altyapısını izole etmek ve böylece güvenliği artırmak için yalnızca Eth1 katmanını tetiklemek için kullanmamız gereken bir yeteneğe ihtiyacımız var. Bu nedenle, bu tür istekleri yönetmek için genel bir çözüm hem pratik hem de gerekli bir durumdur.
Bu EIP, depozito, çekme ve birleştirme gibi en az üç ana durum için bir çerçeve oluşturur. Bu nedenle, erken EIP'ler WITHDRAWAL_REQUEST_TYPE ve DEPOSIT_REQUEST_TYPE gibi alanlar tanıtırken, birleştirme şimdi başka bir alan ekleyecek: CONSOLIDATION_REQUEST_TYPE. Ayrıca, bu EIP, bu tür talepleri işlemek için genel bir mekanizma (PENDING_DEPOSITS_LIMIT, PENDING_PARTIAL_WITHDRAWALS_LIMIT, PENDING_CONSOLIDATIONS_LIMIT sabitleri ile ilgili) de içerebilir.
Bu çerçevenin ayrıntılı uygulama ayrıntıları henüz mevcut olmasa da, kesinlikle ana istek türlerini, bütünlük mekanizmalarını (örneğin, karma ve Merkelize istekler) ve işlem sırasını ve hız sınırlamasını içerecektir.
Bu EIP, Eth1'in kritik işlemleri birleşik bir çerçeve aracılığıyla işaretçi katmanında tetikleyebilmesi için mimari anlamda önemlidir. Son kullanıcılar ve projeler için, bu Eth1 katmanında tetiklenen tüm taleplerin işaretçi katmanında daha verimli bir şekilde iletilip işleneceği anlamına gelir.
EIP-2537: Ön derlenmiş BLS12-381 eğrisi işlemleri
Referans: EIP-2537
Eğer daha fazla ayrıntıya girmek istemiyorsanız, önceden derlenmiş BLS12-381'i karmaşık bir şifreleme 'hash' işlemi olarak düşünebilirsiniz ve şimdi akıllı sözleşmelerde kullanabilirsiniz. İlgi duyanlar için daha fazla araştıralım.
BLS12-381（ve buna karşılık gelen BN-254） gibi eliptik eğriler üzerinde yapılan matematiksel işlemler şu anda iki amaç için kullanılmaktadır:
Eğer akıllı bir sözleşmede BLS imzasını veya zkSNARK kanıtını doğrulamak istiyorsanız, bu 'eşleştirme'leri hesaplamanız gerekir, bu hesaplama oldukça pahalıdır. Ethereum'da, BN254 eğrisi işlemleri için önceden derlenmiş bir sözleşme (EIP-196 ve EIP-197) zaten mevcuttur. Bununla birlikte, BLS12-381 eğrisi (şu anda daha güvenli ve daha yaygın olarak kullanılmaktadır) henüz önceden derlenmiş olarak uygulanmamıştır. Bu tür bir önceden derlenmiş olmadan, akıllı bir sözleşmede eşleştirme ve diğer eğri işlemlerini gerçekleştirmek büyük miktarda hesaplama gerektirir, burada gösterildiği gibi ve büyük miktarda gaz tüketir (yaklaşık ~10^5 ila 10^6 gaz).
Bu EIP, özellikle BLS12-381 eğrisine dayalı ucuz BLS imza doğrulaması alanında birçok potansiyel uygulamanın kapısını açmaktadır. Bu, çeşitli amaçlar için eşik şemasının uygulanabilir hale gelmesini sağlar. Ethereum doğrulayıcıları zaten BLS12-381 tabanlı imzaları kullanmaktadır. Bu EIP aracılığıyla standart akıllı sözleşmeler artık toplu doğrulayıcı imzalarını verimli bir şekilde doğrulayabilir. Bu, konsensüs kanıtını ve farklı ağ varlıklarının köprülenmesini basitleştirebilir çünkü BLS imzaları blok zincirinde yaygın olarak kullanılır. Eşik BLS imzası kendisi, oylama, merkezi olmayan rastgele sayı üretimi, çoklu imza vb. için birçok verimli eşik şeması oluşturmayı mümkün kılar.
Daha ucuz zkSNARK kanıt doğrulaması, birçok uygulamanın kilidini açabilir. Şu anda, yüksek kanıt doğrulama maliyeti nedeniyle birçok zkSNARK tabanlı çözümün bazı projelerin neredeyse imkansız hale gelmesine neden olduğu biliniyor. Bu EIP'nin bu durumu değiştirme potansiyeli var.
EIP-2935: Geçmiş blok karma değerlerini durumda saklama
Referans: EIP-2935
Bu EIP, rollup gibi durumsuz istemciler ve akıllı sözleşmeler için genişletilmiş bir geçmiş sağlamak için blok zinciri durumunda 8192 (yaklaşık 27.3 saat) tarihli blok karmaşasını depolamayı önerir. Mevcut BLOCKHASH işlem kodunun davranışını korumayı, 256 blok sınırlamasını sürdürmeyi ve aynı zamanda tarihli karmaşaları depolamak ve geri almak için özel olarak tasarlanmış yeni bir sistem sözleşmesi tanıtmayı önerir. Bu sözleşme, blok işlemek için set() işlemini gerçekleştirir. get() yöntemi, istenen blok karmaşasını döngüsel bir tampon bölgeden almak için herkese erişilebilir.
Şu anda, EVM'de geçmiş blok hash'lerine başvurmak mümkün olsa da, erişim en son 256 blokla sınırlıdır (yaklaşık 50 dakika). Bununla birlikte, bazı durumlarda daha eski blok verilerine erişim son derece önemlidir, özellikle cross-chain uygulamalar için (önceki blok verilerini kanıtlamak gerektiren) ve stateless istemciler için, bunlar periyodik olarak erken blok hash'lerine erişim gerektirir.
Bu EIP, rollup ve cross-chain uygulamalarının kullanabileceği zaman aralığını genişletir ve bunların dışarıdan toplama yapmadan EVM'de doğrudan geçmiş verilere erişmesine izin verir. Bu nedenle, bu çözümler daha sağlam ve sürdürülebilir hale gelir.
EIP-7623: Artırılmış calldata maliyeti
Referans: EIP-7623
calldata, bazı durumlarda (örneğin, büyük bir dizi veya ikili tampon olarak parametre olarak iletilirken) işlemin etkin yükünün kullanılabilir boyutunu ayarlar ve bu büyük olabilir. Önemli calldata kullanımı genellikle rollup'a atfedilir, bunlar mevcut rollup durumunu içeren calldata'yı göndererek etkin yüklerini ileterek gerçekleşir.
Büyük ölçekli, kanıtlanabilir ikili verilerin blok zincire dahil edilmesi, rollup için son derece önemlidir. Dencun (Deneb-Cancun), bu tür kullanımlar için önemli bir yenilik olan blob işlemlerini (EIP-4844) tanıttı. Blob işlemleri, kendi özel 'blob' gaz ücretine sahiptir; aslında geçici olarak depolanmış olsalar da, şifreli kanıt (KZG taahhütleri) ve hash'leri ile birlikte konsensüs katmanına entegre edilmişlerdir. Bu nedenle, veri depolamak için calldata kullanmaktan farklı olarak, blob, rollup için daha iyi bir çözüm sunar.
Rollup'u teşvik etmek, verilerini blob'a taşıyarak 'havuç ve sopa' yöntemiyle gerçekleştirilebilir. Düşürülen blob gaz ücreti 'havuç' olarak hizmet ederken, bu EIP, aşırı veri depolamayı engellemek için calldata maliyetini artırarak 'kaldıraç' görevi görür. Bu EIP, bir sonraki EIP-7691'e (Blob Throughput Increase) ek bir katkıdır, ki bu da her blok için izin verilen en fazla blob sayısını artırır.
EIP-7691: blob Throughput Increases
Referans: EIP-7691
Daha önceki Dencun sert çatalında, bir blob tanıtıldı ve her bloğun blob'unun maksimum ve hedef sayısı muhafazakar bir tahmin olarak belirlendi. Bu, büyük ikili nesnelerin doğrulayıcı düğümler arasında nasıl işleneceğini tahmin etmenin karmaşıklığından kaynaklanmaktadır. Önceki yapılandırmanın iyi performans gösterdiği kanıtlanmıştır, bu da yeni değerleri test etmenin uygun bir zaman olduğu anlamına gelmektedir. Daha önce, her bloğun hedef/maksimum blob sayısı 3/6 olarak ayarlanmıştı. Bu sınırlamalar şimdi sırasıyla 6/9'a yükseltilmiştir.
EIP-7623 (calldata maliyetini artıran) ile birleşerek, bu ayar, verilerini calldata'dan blob'lara taşıma konusunda rollup'ı daha da teşvik ediyor. En iyi blok parametrelerini bulma çalışması devam ediyor.
EIP-7840: EL yapılandırma dosyasına blob işlemini ekleyin
Referans: EIP-7840
Bu EIP önerisi, hedef ve maksimum 'her blok' blog sayısını (önceki tartışmalarda bahsedildiği gibi) ve baseFeeUpdateFraction değerini Ethereum yürütme katmanı (EL) yapılandırma dosyasına ekler. Ayrıca, istemciye bu değerleri düğüm API'si aracılığıyla almanıza olanak tanır. Bu özellik, blog gaz ücretlerini tahmin etmek gibi görevler için özellikle yararlıdır.
EIP-7702: EOA Hesap Kodu Ayarı
Referans: EIP-7702
Bu, Ethereum kullanıcılarına önemli değişiklikler getirecek çok önemli bir EIP'dir. Bildiğimiz gibi, EOA (Dış Akıllı Sözleşme) herhangi bir kod içermemeli, ancak işlem imzası sağlayabilir (tx.origin). Bununla karşılaştırıldığında, akıllı sözleşmelerin baytları olabilir, ancak doğrudan bir imza sunamazlar. Şu anda, ek, otomatik ve doğrulanabilir mantığa ihtiyaç duyan herhangi bir kullanıcı etkileşimi yalnızca dış sözleşmeleri çağırarak gerçekleştirilebilir. Bununla birlikte, bu durumda, dış sözleşmeler, sonraki sözleşmelerin msg.sender'ı haline gelir, bu da 'kullanıcıdan değil, sözleşmeden gelen çağrıları' yapar.
Bu EIP, yeni bir SET_CODE_TX_TYPE=0x04 işlem türü sunar (daha önce eski 0x1 işlemine, Berlin'den yeni 0x02 işlemine ve EIP-1559 yükseltmesine ve Dencun'da tanıtılan 0x03 blob işlemine sahiptik). Bu yeni ticaret türü, EOA hesapları için kodlar ayarlamanıza olanak tanır. Aslında, EOA'nın "kendi EOA hesabı bağlamında" harici kod yürütmesine izin verir. Dışarıdan bakıldığında, EOA harici bir sözleşmeden kod "ödünç alıyor" ve bir işlem sırasında yürütüyor gibi görünüyor. Teknik olarak bu, EOA adresinin "kod" deposuna bir dizi özel yetkilendirme verisi eklenerek yapılır (bu EIP'ye kadar, bu "kod" deposu EOA için her zaman boştu).
Şu anda, bu EIP önerisindeki yeni 0x04 işlem türü bir dizi içeriyor:
izin_listesi = [[zincir_id, adres, nonce, y_parity, r, s], ...]
Her öğe, hesabın belirtilen adresten gelen kodları kullanmasına izin verir (en son geçerli yetkilendirme öğesinden). Bu tür işlemleri işlerken, belirtilen EOA kodu özel bir 0xef0100 || adres değeri (23 bayt) olarak ayarlanır ve adres, gereken kodu içeren bir sözleşmeye işaret eder, || bağlantıyı temsil eder, 0xef0100, EIP-3541'e göre normal akıllı sözleşmelerin içeremeyeceği özel sihirli bir değeri temsil eder. Bu sihirli değer, bu EOA'nın normal bir sözleşme olarak görülemeyeceğinden ve normal bir sözleşme gibi çağrılamayacağından emin olur.
Bu EOA işlemi başlattığında, belirtilen adres, ilgili kodları çağırmak için bu EOA'nın bağlamında kullanılacaktır. Bu EIP'nin tam uygulama detayları henüz net olmasa da, büyük değişiklikler getireceği kesindir.
Birincil etkilerden biri, EOA'dan doğrudan çoklu çağrı (multicall) yapabilme yeteneğidir. Multicall, DeFi'de sürekli bir trenddir ve birçok protokol, Uniswap V4, Balancer V3 veya Euler V2 gibi güçlü bir araç olarak bu özelliği sunar. Bu EIP sayesinde artık EOA'dan doğrudan çoklu çağrı başlatılabilir.
Örneğin, bu yeni özellik DeFi'deki yaygın bir sorunu çözer: approve() + anything()'nin iki ayrı işlem gerektiren verimsizliği. Bu EIP, approve(X) + deposit(X) gibi genel 'ön izin' mantığına izin verir ve tek bir işlemde tamamlanmasını sağlar.
EOA'nın vekaleten işlem yürütebildiği bir diğer avantaj da sponsorluk kavramıdır. Sponsorluk, Ethereum'a yeni kullanıcıların girmesine yardımcı olmak için sıkça tartışılan ve büyük özlem duyulan bir özelliktir.
EOA ile ilişkili programlanabilir mantık, güvenlik kısıtlamaları uygulama, harcama sınırı belirleme, KYC gereksinimleri zorlama gibi birçok olasılığı açar.
Tabii ki, bu değişim aynı zamanda bir dizi tasarım sorusunu da gündeme getiriyor. Sorunlardan biri, imzaya dahil edilip edilmediğine bağlı olarak aynı imzanın birden fazla ağda geçerli olup olmayacağını belirleyen zincir_id kullanımıdır. Diğer bir komplikasyon, nesne kodunun adresini kullanmak ile gerçek bayt kodunu gömmek arasındaki seçimdir. Her iki yöntemin de kendine özgü özellikleri ve sınırlamaları vardır. Ek olarak, nonce kullanımı, bir iznin "çok amaçlı" mı yoksa "tek amaçlı" mı olduğunu tanımlamada önemli bir rol oynar. Bu öğeler, toplu geçersiz kılma imzaları ve kullanım kolaylığı gibi hususlar da dahil olmak üzere işlevsellik ve güvenlik sorunlarını etkiler. Vitalik, bu soruları daha fazla araştırmaya değer bir tartışmada (burada) gündeme getirdi.
Bu değişikliğin Ethereum'un güvenlik mekanizmalarından biri olan tx.origin'i etkileyeceğini belirtmekte fayda var. Bu EIP uygulaması hakkında daha fazla ayrıntı gereklidir, ancak require(tx.origin == msg.sender) davranışı değişecek gibi görünüyor. Bu kontrol, msg.sender'ın bir sözleşme değil, bir EOA olduğundan emin olmanın en kesin yolu olmuştur. EXTCODESIZE'I KONTROL ETMEK (BUNUN BIR SÖZLEŞME OLUP OLMADIĞINI KONTROL ETMEK IÇIN) GIBI DIĞER YÖNTEMLER GENELLIKLE BAŞARISIZ OLUR VE ATLATILABILIR (ÖRNEĞIN, OLUŞTURUCUYU ÇAĞIRARAK VEYA BIR IŞLEMDEN SONRA KODU ÖNCEDEN TANIMLANMIŞ BIR ADRESE DAĞITARAK). Bu kontroller, yeniden giriş ve flaş kredi saldırılarını önlemek için kullanılır, ancak harici protokollerle entegrasyonu da engelledikleri için ideal olmaktan uzaktır. Güvenilir requiretx.origin == msg.sender kontrolü bile bu EIP'den sonra geçerliliğini yitirmiş gibi görünüyor. "EOA" ve "sözleşme" arasındaki ayrım artık geçerli olmayacağından, protokolün bu kontrolleri kaldırarak uyum sağlaması gerekiyordu - artık her adresin kendisiyle ilişkili bir kodu olabilirdi.
Geleneksel EOA ve akıllı sözleşmeler arasındaki ayrım giderek belirsizleşiyor. Bu EIP, Ethereum'u her hesabın temelde yürütülebilir kod olduğu TON gibi tasarımlara daha da yaklaştırıyor. Protokolle etkileşim giderek karmaşık hale geldikçe, son kullanıcı deneyimini iyileştirmek için programlanabilir mantığı kullanmak, bu evrimin doğal bir parçasıdır.
Sonuç
布拉格 /Electra（Pectra）升级定于 2025 年 3 月。其最显著的计划变更包括：
Gördüğünüz gibi, Pectra, stake ve konsensüs katmanı ile yürütme katmanı üzerindeki son kullanıcı deneyimini büyük ölçüde etkileyecektir. Kod ayrıntılı olarak incelenemese de, geliştirme devam ettiği için bu değişikliklerin hepsini bu aşamada kapsayamıyoruz, ancak gelecekteki yazılarda bu güncellemeleri ele alacağız.