Sonraki 1 Milyar Kullanıcı - Hesap Soyutlamayı (Account Abstraction) Anlamak - 2

FgcF...q4AM

24 Jan 2024

138

Yazımın 2. bölümü ile devam ediyorum. Keyifli okumalar dilerim :)

Neden Akıllı Kontrat Tabanlı Cüzdanlar Yeterince Popüler Değil?

Öncelikle belirtmekte fayda var ki, akıllı kontratlar gizli anahtara sahip değillerdir ve işlemleri otomatik olarak başlatamazlar. Ayrıca, bir akıllı kontratı kullanmak veya oluşturmak için belirli bir ücret ödenmesi gerekliliği bulunmaktadır. Ancak, bu özelliklerin akıllı kontrat tabanlı cüzdanların yaygınlaşmasına engel olduğunu düşünebiliriz. Şimdi, bu durumun neden sorunlara yol açtığını anlamak için genel bir bakış atalım, özellikle de tornado.cash örneğini ele alarak.

Tornado Cash ve Gizlilik Zorluğu

Tornado Cash, gizliliği artırmak amacıyla tasarlanmış bir karıştırıcıdır (mixer). Finansal aktivitelerimizin izlenebilirliğiyle ilgili ciddi bir sorun olan gizlilik ihtiyacını karşılamak adına ortaya çıkmıştır. Temel çalışma prensibi oldukça basittir. Tornado Cash'te farklı havuzlara herkesin Ether yatırma imkanı bulunmaktadır, bu havuzlara 0.1, 1, 10 ve 100 Ether gibi miktarlarla katılım sağlanabilir. Ardından, yatırılan Ether'e dair bir "kanıt" alınır. Ancak, burada bir sorun ortaya çıkar. Tornado Cash kontratına Ether yatırdığınıza dair ispatınız olmasına rağmen, işlemi başlatabilmek için bir miktar Ether'e ihtiyaç duyarsınız. Bu Ether'i ya kendi cüzdanınızdan aktarmanız ya da bir merkezi borsa kullanmanız gerekmektedir, ki bu da gizlilik çabalarını tamamen zedeler. "İşlemi başlatmak için gerekli" Ether miktarının gerekliliği, akıllı kontratların doğrudan işlem başlatamamasından kaynaklanmaktadır. Tornado Cash'te ise Relayer olarak adlandırılan aracılar, protokol içinde EOA cüzdanı yürüterek işlemleri sponsorluk yapar ve bu sorunu çözer. Ancak, relayerlerin çalışmasını durdurması durumunda gizlilik tehlikeye girebileceğinden, mevcut sistemin iyileştirmeye ihtiyaç duyduğu açıktır.

Akıllı Kontrat Tabanlı Cüzdanlar

Telefonunuza bir akıllı kontrat tabanlı cüzdan indirdiniz, varlığınızı cüzdana aktardınız ve kontrat Ethereum'a yüklendi. Ancak, işlem yapmak istediğinizde karşılaştığınız sorun, telefonunuzun Face ID'si, parmak izi veya mail sisteminin eliptik eğrisinin imzalaması gibi yöntemlerle "geçerli" işlem başlatamamanızdır. Bu nedenle, işlemlerinizi başlatmak için hala EOA cüzdanınızı kullanmak zorundasınız ve bu durumda yine 12 kelimeli anahtarlarla uğraşmak ve EOA cüzdanınıza giriş yapmak gerekiyor.
Akıllı kontrat tabanlı cüzdanlar da kendiliğinden işlem başlatamadığından, işlemleri başlatmak için bir EOA cüzdandan çıkmış işleme ihtiyaç duyarlar. Şu anda Ethereum'da faaliyet gösteren akıllı kontrat tabanlı cüzdanlar, bir relayer aracılığıyla işleme sponsor olur ve bu işlemin gerçekleşmesini ücret karşılığında sağlarlar. Ancak, bu relayerler genellikle merkezi aracılardır, bu da kullanıcıların sansür ve varlığın donması riskiyle karşılaşabileceği anlamına gelir. Bu dezavantajın temel nedeni, önceki bölümlerde değindiğim, akıllı kontratların doğrudan işlem başlatamamasıdır.

Bu iki sistemde de işlemlere sponsor olan relayerlerin merkezi yapılar olması, çeşitli güvenlik ve sansür riskleri doğurduğundan, bu sorunları çözecek bir güncellemeye ihtiyaç duyulmaktadır. Evet, hesap soyutlama, bu konuyu tam olarak karşılamaktadır. Önceki bölümlerde neden hesap soyutlamaya ihtiyaç duyulduğunu ele aldık; şimdi ise hesap soyutlamanın tarih içindeki evrimine ve EIP 4337'nin detaylarına odaklanacağız.

Hesap Soyutlamanın Evrimi
EIP 86, EIP 2938, EIP 3074, EIP 4337

Hesap soyutlama ve akıllı kontratları bir sonraki aşamaya taşıma konsepti, uzun bir süredir üzerinde tartışılan bir fikir olmuştur. Hesap soyutlamayı mümkün kılmak için 2017 yılında önerilen EIP 86, Ethereum topluluğuna sunulan çeşitli geliştirme tekliflerinden biridir. Bu teklifler zaman içinde evrilmiş ve gelişmiş bir hale gelmiştir. Ethereum geliştirme tekliflerine ve evrim sürecine yakından bakalım:

EIP 86: Vitalik Buterin tarafından 2017 yılında önerilen EIP 86, hesap soyutlamayı mümkün kılmayı amaçlamaktadır. Bu teklif, işlemin "başlangıcı", nonce şeması ve işleme ait "imzalama" sisteminin soyutlanmasını içermektedir. EIP 86, ECDSA dışındaki imzalama yöntemlerini kullanarak geçerli işlem başlatmayı mümkün kılar. Bu sayede, önceden programlanmış imzalama kurallarıyla kontratlardan işlem başlatmak ve kontrat tabanlı cüzdanları programlamak mümkün hale gelir. EIP 86 ile:
- MultiSig cüzdanlarında yapılan işlemler, EOA cüzdanlarından gönderilir ve EOA cüzdanlar Ethereum gas ücretini ödemek zorundadır. EIP 86 ile MultiSig içindeki Ether ile bu gas ücretini ödemek mümkün olur.
- Ethereum'da kullanılan dijital imza kuantum dirençli değildir. EIP 86, farklı dijital imza yöntemlerini kullanarak kuantum dirençli Ethereum cüzdanlarının oluşturulmasını mümkün kılar.
- Güncellemede açıkça belirtilmemiş olsa da, bu güncelleme ile programlanabilir akıllı kontrat tabanlı cüzdanların oluşturulması mümkün hale gelir.
- Ethereum'da çalışan karıştırıcılardaki relayerlere olan ihtiyacı ortadan kaldırarak karıştırıcı kontratındaki varlıkları çekerken ödenmesi gereken gas ücretini kontrattaki varlıkla ödemeyi mümkün kılar.

Ancak, EIP 86'nın protokol düzeyinde getirmeye çalıştığı önemli güncellemeler nedeniyle, o dönemdeki geliştiriciler tarafından rafa kaldırılmıştır. Bu güncellemelerin Ethereum için çok radikal olması, merge sürecini uzun bir süreye yayması ve tüm client geliştiricilerinin bu konuya odaklanmasını gerektirmesi nedeniyle teklif kabul edilmemiştir.
Ayrıca, EIP 86'da çözülemeyen bir DOS vektörü bulunmaktadır. Benzer şekilde, EIP 4337'de de bir DOS vektörü bulunmaktadır.

EIP 2938: EIP 86'ya kıyasla daha basit düzeyde güncellemeler içeren EIP 2938, 2020 yılında Vitalik Buterin ve üç geliştirici tarafından oluşturuldu. EIP 2938, hesap soyutlamayı mümkün kılmak için 2 yeni opcode eklemeyi içerir. Bu güncelleme, Ethereum'a yeni bir "işlem türü" ekleyerek hesap soyutlamanın çeşitli uygulamalarını mümkün kılar. Belirli şartları sağlayan kontratları "kontrat cüzdanı" olarak işaretleyerek eklenen yeni işlem türünü kullanmalarına izin verir. EIP 2938, sınırlı bir hesap soyutlaması sağlar. Geçerlilik kurallarından gas'ı soyutlamamıza olanak tanırken, nonce ve ECDSA (imzalama sistemleri) soyutlanamadığı için EIP ile geliştiremeyeceğimiz uygulamalar bulunmaktadır. Bu EIP, protokol seviyesinde güncellemeler gerektirdiği, hesap soyutlamasını tam anlamıyla desteklemediği ve EIP 86 ve EIP 4337'de bulunan DOS vektörüne kesin çözümler getiremediği için kabul edilmedi.

EIP 3074: EIP 3074, aslında hesap soyutlamayı hedeflemeyen, ancak EOA cüzdanlara programlanabilirlik getirmeyi amaçlayan bir güncellemedir. EIP 3074'te işlemlerin orijini yine EOA cüzdanlarından gelir, ancak bu güncelleme sayesinde bir EOA cüzdanındaki işlem, farklı bir EOA cüzdanı tarafından başlatılabilir hale gelir. Bu, örneğin gas ödemek için Ether tutma zorunluluğunun ortadan kalkmasını sağlar. Bunu, protokole AUTH ve AUTHCALL adında iki yeni opcode getirerek gerçekleştirmeyi amaçlar. Bu opcode'ların amacı, EOA'nın işlem başlatma yetkisini (invoker olarak adlandırılan) bir akıllı kontrata vererek meta işlemler, işlem birleştirme gibi bazı "hesap soyutlama ürünlerini" mümkün kılmaktır. EOA cüzdanlarındaki işlem başlatma yetkisini bir akıllı kontrata vermenin birçok avantajı ve dezavantajı bulunmaktadır.

EIP 3074'teki Sponsorlu İşlemlerin Çalışma Mekanizması

Ethereum cüzdanlarından ERC20 token transferi veya kontrattan işlem başlatma gibi işlemleri gerçekleştirmek istediğimizde, bu işlemler için Ether olarak fee ödeme zorunluluğumuz bulunmaktadır. Yani, örneğin USDC ERC20 tokenini transfer etmek için cüzdanımızda hem USDC hem de Ether bulundurmak gereklidir. Ancak, bu zorunluluğu ortadan kaldırmak adına "sponsorlu" işlemler adı verilen ve belirli bir ücret karşılığında işleme sponsor olan aracılarla gerçekleştirilen bir dizi güncelleme önerilmiştir. Bu sayede kullanıcılar, Ether tutmadan işlem yapabilir hale gelir. EOA cüzdanlarında bu işlem şu an mümkün değildir çünkü geçerli bir işlem başlatabilmek için önceki bölümlerde değindiğim geçerlilik kuralının tamamının sağlanması gerekmektedir. Bu kurallardan biri de gas olduğu için işlem başlatmak için Ether tutma zorunluluğu doğar. Gas'ı soyutladığımızda ise işlemi başlatmak için Ether tutma zorunluluğu ortadan kalkar ve "sponsorlu işlemleri" gerçekleştirebilir hale geliriz. EIP 3074 ile birlikte gelen iki opcode, Auth ile AuthCall, kullanıcılara Auth opcode'uyla Invoker kontratına sahiplik verme imkanı sunar. Daha sonra kullanıcı, ERC20 token transferi gibi işlemleri başlatabilmek için işlemi imzalar. İmzalanan işlemin gas'ı, AuthCall fonksiyonu aracılığıyla bir sponsor tarafından karşılanır ve işlem EVM'de yürütülür. Auth ve AuthCall opcode'ları arasındaki tek fark, "Caller"ın değiştirilebilmesidir. Bu sayede ERC20 token transferi gibi işlemler, Ether ile fee ödemek zorunda kalmadan gerçekleştirilebilir.

İşlem Birleştirme (Transaction Aggregation) EIP3074’te Nasıl Çalışır?

Ethereum’da bir ERC20 transferi gerçekleştirmeyi düşünelim; ilk olarak, “approve” fonksiyonu için bir işlem yapmamız, ardından da “transferfrom” fonksiyonu ile bir başka işlem gerçekleştirmemiz gerekiyor. Ancak, ERC20 kontratı üzerinden doğrudan approve fonksiyonunu çağıramadığımızdan, bu iki fonksiyonu çağırmak için iki ayrı işlem yapmak zorundayız. Auth opcode’u ile birlikte gelen mesajlaşma formatındaki “commit” özelliği, birden fazla işlemi birleştirerek bunları tek bir işlem olarak EVM’de yürütebilmemize olanak tanır. Bu sayede birçok uygulamadaki kullanıcı deneyimini geliştirme ve işlemleri daha etkili bir şekilde gerçekleştirme imkanına sahip olabiliriz.

EIP-3074 Neden Hala İnceleme Sürecinde?

EIP-3074, protocol düzeyinde değişiklik yaparak iki yeni opcode eklemeyi içerdiği için ciddi bir güvenlik araştırması sürecinden geçmek zorundaydı. Bu güvenlik araştırmalarında, EIP-3074'ün hala inceleme sürecinde olmasına sebep olan başlıca üç konu bulunmaktadır.

Mevcut sandviç saldırılarını daha da kolaylaştırma potansiyeli taşımaktadır.
"Invoker" olarak adlandırılan kontratların cüzdandaki varlıklara tam erişim sağlayabilmesi ve varlıklar üzerinde sınırsız yetkiye sahip olmasından kaynaklanan risklerdir.
EIP-3074'ün imzaları ve nonce'u soyutlayamaması nedeniyle çeşitli Hesap Soyutlama uygulamalarının bu güncelleme ile mümkün olamamasıdır.

Şu anda Ethereum topluluğu tarafından tartışılan EIP-5003 teklifi, EIP-3074'teki AUTH fonksiyonunu 4337 DelegateCall fonksiyonu ile birleştirme olasılığını ele almaktadır.

Account Abstraction uzun ve iyi anlaşılması gerektiği bir konu olduğundan ikinci bölümü bu şekilde bitirebiliriz. İlerleyen günlerde yazının devamı gelecektir takipte kalın :)

CC: Doğan, Clave

Buraya kadar okuyup içeriğimi beğendiyseniz çok teşekkür ederim. Bu içeriği değerli bulduysanız bu yazıya tepki vererek ve yorum yaparak sevginizi gösterebilirsiniz. Görüşlerinizi duymak için sabırsızlanıyorum. Teşekkür ederim✨

📌Read My Latest Posts :

Sonraki 1 Milyar Kullanıcı - Hesap Soyutlamayı (Account Abstraction) Anlamak - 1 - 22 January, 2024 | Link
Mina Bir Devrim mi? Yoksa... - 18 January, 2024 | Link
Celestia Modularism vs Ethereum Eip4844 - 15 January, 2024 | Link
Paralel EVM: Ethereum'un Geleceğinde Bir Ölçeklenme Çözümü - 12 January, 2024 | Link
Nedir Bu EigenLayer? - 09 January, 2024 | Link
My Daily Airdrop Grind Routine - 06 January, 2024 | Link
Chromatic Testnet - Definitely Worth to Check it Out - 04 January, 2024 | Link
AI ve Airdrop İşte Tüm Mesele Bu - 01 January, 2024 | Link