Ethereum'nin Sonraki Aşaması: L1 ve L2'yi Birleştirme, Gizliliği Güçlendirme ve Kullanıcı Deneyimini İyileştirme

Geçen yıllar boyunca Ethereum'un yükseltmelerini bir çizgi üzerinde birleştirdiğinizde, anahtar kelime kesinlikle «genişletme» olacak.

Dencun ile Blob'ların Rollup'lara büyük vergi indirimi sağlaması, Pectra ile doğrulayıcı verimliliği ve stake mekanizmasının ayarlanması, Fusaka ile PeerDAS'in veri dağıtım yükünü azaltması kadar, protokol katmanı neredeyse tüm çabalarını bir tek şeye odaklamıştır: Ethereum'un daha fazla veriyi yemesini sağlamak ve aynı zamanda düğüm eşiğini çok yükseltmemek.

Bu kombinasyon gerçekten etkili, Rollup veri maliyetleri düşürüldü, ana ağ Gas Limiti istikrarlı bir şekilde artıyor ve Ethereum artık önceki牛市 gibi onlarca dolarlık işlem ücretleriyle kullanıcıları korkutmayacak.

Ancak yol genişletildi, araba nasıl sürülür hâlâ çok rahatsız edici:

• Hâlâ 3. ve 4. L2 arasında varlık taşıyoruz; biraz dikkatsizlikle yanlış zincire çekim yapıyoruz;
• Bir transfer açıkçası birkaç saniye içinde paketlendi, ancak köprü ve borsa onaylamak için onlarca dakika beklemenizi istiyor;
• Profesyonel Builder'lar blok paketleme konusunda neredeyse monopole sahip; hassas bir işlem göndermek istediğinizde, protokol dışındaki gizli kurallar tarafından anında engellenebilirsiniz;
• Daha da önemlisi, bugün bile yeni giren bir kullanıcı, sadece birkaç yüz USDC aktarmak istiyorsa, cüzdanında neden ETH olması gerektiğini, Nonce’un ne olduğunu ve Gas’ın ne anlama geldiğini anlamak zorunda kalır;

Bu sorunlar görünürde kullanıcı deneyimi sorunları olarak ortaya çıksa da, arkalarında onay kuralları, blok oluşturma, inceleme direnci ve hesap modeli gibi daha temel protokol mekanizmaları yer alıyor.

Aynı zamanda, Glamsterdam'dan Hegotá'ya, 2026 Q4'ten 2027 yılına kadar Ethereum'un yeni bir merkezi işleme sorunu başlamasıdır.

Elbette, ölçeklendirme fren yapmaz.

Glamsterdam, özellikle ePBS (EIP-7732) ve BAL (Block-level Access Lists, EIP-7928) olarak bilinen iki özelliğe odaklanan yüksek performanslı bir yapıya sahiptir; basitçe ifade edersek:

• ePBS, bugün protokol dışında zaten yaygın olan Proposer ile Builder görevlerini daha resmi bir şekilde protokole entegre ederek, blok oluşturma ve doğrulama zaman pencerelerini daha bilimsel bir şekilde böler ve gelecekte daha büyük bloklar için yeterli bir tampon sağlar;
• BAL, bloğun başlangıcında bir «erişim listesi» oluşturarak, düğümlerin verileri önceden almasını hatta paralel işlemesini sağlar ve depolama I/O darboğazlarını giderir;

Yalnızca ölçeklendirme dışında, bugün çoğu kişinin gerçek acısı, Ethereum'un TPS'sinin yeterli olup olmadığı değil, "çok fazla zincir var" olması.

Örneğin ETH ana ağda, oynanan meme Robinhood Chain'de, ödeme ve settlements için kullanılan USDC muhtemelen Arbitrum'da, alttan almak istediğiniz USDC ise Base'de...

Ethereum Vakfı için Rollup'lar Ethereum'un bir parçasıdır, ancak kullanıcılar için bu, uluslararası para değiştirme ve vize başvurusu ile aynı şeydir.

Bu nedenle, dağılmış pusula parçalarını tekrar bir ağa dönüştürmek için çapraz zincir protokollerinin yanı sıra, protokol katmanının son dönemde öne çıkardığı temel bir mekanizma özellikle dikkat çekiyor—FCR (Fast Confirmation Rule, Hızlı Onay Kuralı).

Birçok kişi, işlemin bir bloğa dahil edildiğini düşünür, ancak kriptografik ve uzlaşım düzeyinde, yeni oluşturulan bir blok küçük yeniden yapılandırmalara maruz kalabilir. Gerçekten kalıcı olan “sona erme (Finality)” durumu için Ethereum, iki Epoch tamamlamalıdır, bu yaklaşık 13 dakika sürer.

Bu günlük transferler için sorun olmasa da, çapraz zincir köprüleri, büyük tutarlı清算 ve merkeziyatlaştırılmış borsalar için gerçek bir acı; yeniden yapılandırma riskini almamak için sadece beklemenizi zorunlu kılarlar.

FCR'nin akıllı fikri, tam Finality için onlarca dakika beklemek yerine, doğrulayıcıların zaten sürekli ürettiği Attestation'ları kullanarak, bir bloğun yeterince güçlü bir uzlaşmayı kazandığını daha erken belirlemektir.

Ethereum Vakfı'nın belirlediği hedeflere göre, ağ normal şekilde senkronize kalıyorsa, FCR bu "güçlü onay"ı yaklaşık 15-30 saniye öne çekebilir; tam Finality ile eşdeğer olmasa da, bugün sona erme beklemek zorunda kalan birçok köprü, çapraz zincir iletişim ve altyapı için daha erken ve açık bir güvenlik modeli sunan bir onay sinyali yeterlidir.

Daha da özel olarak, FCR'nin bir hard fork'un beklenmesine gerek yoktur; bu, konsensüs istemcileri ve altyapı tarafından adım adım benimsenebilen bir onay kuralı kümesine daha yakındır.

L2'lerin, çapraz zincir köprülerinin ve cüzdanların bu sinyali kullanmaya başlamasıyla, bugün "L1 sona ermesini beklemek" nedeniyle oluşan çok sayıda katman arası gecikme, onlarca dakikadan onlarca saniyeye indirilebilir.

Bu, gelecekte bir varlığı taşıdığınızda arka planda birden fazla zincir veya daha fazla zincir arasında geçiş yapılabileceği anlamına gelir; ancak ön uçta yalnızca bir kez onaylamanız yeterli olacak ve kısa sürede bakiyenize eklenecektir.

Ancak bloklar giderek daha büyük hale gelir ve Builder'lar giderek daha profesyonel hale gelirken, Ethereum başka tipik bir ikilemle karşı karşıya kalır.

Profesyonel Builder'lar, en üst düzey hesaplama gücü ve sipariş akışlarıyla blok oluşturma verimliliğini maksimum seviyeye çıkardığından, çoğu bloğun kaderi doğal olarak birkaç büyük kuruma ait olmaktadır.

Bu, aşırı derecede tehlikeli bir sorun olan denetim getiriyor.

Eğer bazı Builder'lar, uyum baskısı, ticari rekabet veya basitçe bazı gizlilik anlaşmalarından hoşlanmamak nedeniyle, hafıza havuzunda kulağını tıkayıp, anahtarınızı elde tuttuğunuz ve yeterli Gas verdiğiniz halde legítim işlemlerinizi paketlemeyi reddederse, işleminiz zincir dışında sıkışmış kalabilir (daha fazla bilgi için İnceleme Direncini Protokole Yazmak: Bir Ethereum İşleminin Zincire Eklenip Eklenemeyeceğini Kim Karar Verir?).

Merkeziyetsizlik, en temel olan "inceleme direnici işlem erişimi" bile korunamazsa, işlem kapasitesi ne kadar yüksek olursa olsun hava kalesidir.

Bu, Hegotá planında FOCIL'in (Fork-choice Enforced Inclusion Lists, EIP-7805) bu kadar kritik bir konuma getirilmesinin nedenidir.

Mantığı son derece basit ve kaba: Builder'a bir sıkı bağlama takmak.

Her bir Slot'ta, protokol, kendi bellek havuzlarında gördükleri geçerli işlem listelerini bir "Dahil Etme Listesi"ne eklemek için rastgele bir dizi normal bağımsız doğrulayıcı seçer. Builder, MEV kazanmak için işlem sıralamasını serbestçe düzenlemeye devam edebilir, ancak sunduğunuz blok, listedeki işlemleri mutlaka içermelidir.

Eğer Builder, bu listeyi kötü niyetle görmezden gelirse, tüm ağ doğrulayıcıları bu bloğu fork seçim kuralı içinde doğrudan dışaruda bırakacaktır. Başka bir deyişle, kazanmak için yetenekli olabilirsiniz, ancak ağ genelinde kimin Ethereum'a erişim hakkı olduğunu siz karar veremezsiniz.

Bu mekanizma kurulunca, uzun süredir duyulup hiçbir şekilde ilerletilemeyen Ethereum'un diğer bir eksikliği olan, herkesin beklediği gizlilik de nihayet bir temel buldu.

Genel olarak, geçmişte gizlilikten bahsederken herkes sıfır bilgi kanıtları, gizli adresler ve karıştırma havuzlarından bahsederdi, ancak Builder bir işlemin gizlilik sözleşmesine yapılan bir çağrı olduğunu tanır tanımaz hemen reddederse, matematiksel sihriniz anında çöker.

Şu anda Ethereum gizlilik yolunda FOCIL, en kolay boğulma noktasını kapatıyor, çünkü protokol katmanı her yasal işlemin erişim hakkını güvenle koruyabiliyorsa, üst katman gizlilik araştırmaları hayatta kalabilir.

EIP-8182 (protokol seviyesinde yerel Shielded Pool'u tanıtmayı deneyen) gibi daha radikal gizlilik önerileri hâlâ aday tartışmalar aşamasında (Proposed), ancak trend açıkça ortada: gizlilik, bir üçüncü taraf dapp'in kenar fonksiyonu olarak değil, yavaş yavaş Ethereum'un temel altyapısının bir parçası haline gelmelidir.

Önceden konuşulan yapısal değişiklikler daha çok su altındayken, üçüncü konu, normal kullanıcıların gerçek kullanım deneyimiyle doğrudan ilgilidir.

Yani Ethereum, on yıldan beri süren EOA hesap modeline nihayet büyük bir değişiklik yapmaya karar verdi.

Dürüst olmak gerekirse, Ethereum'un uzun süredir kullandığı anahtar imza modeli, biraz daha sıradan bir internet kullanıcısı için son derece insan dışıdır:

Anahtar kaybolduğunda kurtuluş yoktur; cüzdanınızda binlerce stabil kripto varken, sadece 0,001 ETH fazladan işlem ücreti eksik olduğu için varlıklarınız geçici olarak transfer edilemez; DeFi oynamak için önce Onaylayın, sonra Değiştirin, bir işi tamamlamak için üç kez imza atmanız gerekir; İşlem Noncesi kesinlikle sıraya girer, bir işlem takılırsa, tüm sistem durur.

İki önceki yükseltme turunda topluluk çeşitli uzlaşmalar yaptı. Örneğin, ERC-4337'yi protokol dışında sözleşme cüzdanları kullanarak kurtarmak; ya da Pectra'da EIP-7702'yi tanıtarak, normal adreslerin geçici olarak bir sözleşme mantığı eklemesine izin vererek esneklik kazandırmak.

Ancak 7702 temelde bir geçit köprüsüdür; Hegotá'nın kilit noktası, gerçek yerel hesap soyutlaması EIP-8141 (Frame Transactions, çerçeve işlemleri)dir.

Basitçe anlaşılabileceği kadarıyla, daha önce Ethereum'da bir işlem, kimin sizin olduğunuzu doğruladığı (doğrulama) + kimin bu ücreti ödediği (Gas ödemesi) + tam olarak ne yapmak istediğinin üçünü sıkıca bir araya getiriyordu, ancak EIP-8141, bu üç işlemi protokolün temelinde farklı «çerçevelere» ayırmaktadır (daha fazla bilgi için Yerel Hesap Soyutlaması + Kuantum Tehditlerine Karşı Direnç: EIP-8141 Neden Ethereum Hegotá'nın Öncüleri Arasında Değil? başlıklı makaleye bakın):

• Doğrulama çerçevesi: Sabit ECDSA eliptik eğri imzalarına kilitli kalmıyor, Passkey gibi daha esnek doğrulama yöntemlerini destekliyor ve telefon parmak izi, Face ID gibi yetenekleri daha iyi bir şekilde entegre ederek anahtar döndürme ve hesap kurtarma işlemlerini daha doğal hale getiriyor;
• Ödeme Çerçevesi: Gas ücretlerinin yerel olarak desteklenmesi. Uygulama sağlayıcıları, yeni kullanıcılar için Gas ücretlerini doğrudan ödemeye başlayabilir veya ödeme çerçevesinde doğrudan transferdeki USDC’yi düşürmeyi belirleyebilir; artık zincir dışı gas ücreti aracılarına gerek kalmaz;
• İşlem çerçevesi: Doğal olarak atomik toplu işleme desteği sağlar, yetki verme ve takas bir adımda tamamlanır; başarı durumunda tüm işlemler birlikte etkinleşir, başarısızlık durumunda ise tamamen geri alınır;

EIP-8250 (Keyed Nonces) de tartışmada olan ek bir özellik olarak eklenirse, gelecekteki hesaplar birden fazla paralel Nonce yolu sahip olabilecek.

Bu yetenekler protokole doğrudan entegre edildiğinde, imToken gibi cüzdanlar için ürün formatı kalitatif bir özgürlük kazanacaktır.

Geçmişte cüzdanın büyük bir kısmı, kullanıcıları Gas hazırlamaya hatırlamak, neden bu işlemin takıldığını açıklamak, kullanıcıların seed phrase’leri nasıl kopyalayacaklarını öğretmek ve kullanıcıların farklı zincirler arasında RPC geçişini sağlamaya harcanmıştı.

Gelecekte, imza algoritması, Gas ödemesi, izin kontrolü ve işlem rota yönetimi programlanabilir hale geldiğinde, cüzdan nihayet kendisine layık olan yere geri dönecek ve kullanıcı ile merkeziyetsiz dünya arasında sessiz bir işletim sistemi olacak.

Daha önceki gibi tamamen kullanıcı elinde, ancak kullanımı Alipay QR kodlu ödeme veya parmak izi kilidi gibi doğal olacaktır.

Ethereum'in son birkaç yıl içindeki yükseltme izlerine geri bakıldığında, yol aslında son derece net.

Dencun, Blob'ları çözer; Pectra, ölçeklendirmeye devam ederken doğrulayıcı ve hesap yeteneklerini geliştirir; Fusaka, PeerDAS ile daha büyük veri throughput için yol hazırlar; Sonraki Glamsterdam, ePBS, BAL gibi yapısal değişikliklerle daha yüksek Gas Limit ve paralel yürütme için temel oluşturacaktır.

Genişleme hâlâ bitmedi, ancak genişleme artık tek sorun değil.

Ethereum nihayet en temel ve en sorunlu sorunlarla yüzleşmek için zaman ayırdı, bu da EF'nin 2026 yılında protokol geliştirme yönünü üç çok basit hedefe özetlemesinin nedenidir:

Scale, UX'yi geliştirin ve L1'i güçlendirin.

Ethereum, zaten dünyaya, bir durmaksızın çalışan dünya bilgisayarı olabileceğini kanıtlamıştır; şimdi sıradaki adım, sıradan insanların bunu gerçekten sorunsuz bir şekilde kullanabilmesidir.