Daha iyi ve daha güvenli kullanım deneyimi
EIP-3074, EOA'nın (Harici Olarak Sahip Olunan Hesaplar) kontrolü belirli bir sözleşmeye devretmesine ve böylece sözleşmeyle aynı zengin yürütme yeteneklerini elde etmesine olanak tanır. EIP-3074'ten önce, bir EOA, ERC20'yi onaylamak veya Uniswap'ta takas yapmak gibi işlem başına yalnızca bir işlem gerçekleştirebiliyordu. EIP-3074'ten sonra, bir EOA aynı anda birden fazla işlem gerçekleştirebilir, hatta daha önce hayal bile edilemeyen görevleri gerçekleştirebilir. Basitçe söylemek gerekirse, EIP-3074 kullanıcı deneyimini büyük ölçüde geliştirir ve tanıdık belirteç yetkilendirme yöntemi yeniden şekillendirilerek kullanıcı deneyimini değiştirmeden güvenliği artırır.
Ayrıca, EIP-3074 aracılığıyla, EOA'nın hiçbir long'cu zincire kendi başına işlem göndermesine gerek kalmaz ve işlem ücretlerini ödemek için ETH toplama zahmetini ortadan kaldırır.
EOA'nın kontrolünü ele geçirebilen sözleşmeye Invoker sözleşmesi denir. Tabii ki, herhangi bir sözleşme EOA'nın kontrolünü ele geçiremez: EOA özel bir anahtarla imzalamalıdır ve imzanın içeriği, hangi Invoker sözleşmesi olduğunu ve Invoker'ın hangi işlemleri gerçekleştirmesine izin verildiğini açıkça belirtecektir.
EOA imza içeriği, hangi Invoker sözleşmesini (invoker adresi) açıkça belirtecek ve bu Invoker sözleşmesinin işlemlerini yetkilendirecektir (taahhüt)
Gerçek yürütme süreci muhtemelen şöyle görünecektir:
Not 1: Relayer gerekli değildir. Alice ayrıca kendi imza içeriğini ve mührünü zincire getirebilir.
Invoker imzayı doğruladıktan ve işlemi yürütmeye başladıktan sonra, EOA'nın (sınırlı) kontrolünü elde etmek gibi Alice EOA olarak yürütülecektir.
Bununla birlikte, EOA'nın nonce değerinin yürütmeden sonra artırılmayacağına dikkat edilmelidir, bu nedenle aynı imza yeniden kullanılabilir (EOA nonce değişmeden kaldığı long), bu nedenle Invoker'ın tekrar oynatmayı önlemek için kendi nonce mekanizmasını uygulaması gerekir.
Invoker sözleşmesi Tekrar Oynatmaya karşı korumalı değilse, aynı yetkilendirme her zaman yürütülebilir.
EIP-3074'ün gerçek çalışma mekanizmasına giriş için lütfen aşağıdakilere bakın: EIP3074'e Giriş
Kullanıcıların birkaç işlemin yürütülmesini tek bir işlemde birleştirmesine izin vererek, birden çok yetkili imza sürecinden ve bazı Gas maliyetlerinden tasarruf edin.
Not: Bu, dApp'in şu anda topluluk tarafından zorlanan EIP-5792 gibi Batchcall işlevini de destek gerektirecektir. Aksi takdirde, dApp, kullanıcıyı normal bir EOA olarak ele alırsa, kullanıcıdan her işlem için yalnızca bir kez imzalamasını isteyecektir.
Kullanıcılar, belirli koşullar altında üçüncü bir tarafın kendi adlarına hareket etmesine de izin verebilir. Aşağıdaki şemada yer alan temsilci anahtarı, yetkili üçüncü taraftır; erişim politikası, yalnızca Uniswap'ı çalıştırmakla sınırlamak, günde en fazla 1 ETH transfer etmek, yetkilendirme geçerlilik süresi vb. gibi yürütme kısıtlamasıdır. Bu koşullar, Invoker sözleşmesi içinde tasarlanır ve kontrol edilir. Kontrol geçtiği long, üçüncü taraf işlemleri kullanıcının EOA'sı olarak yürütebilir.
Telegram Bot'a, kullanıcının EOA'sı adına işlem gerçekleştirmesi için belirli izinler verilebilir
yerine getirildiği long (yani, İzin imzası yasalsa), ETH aktarımı, yerel ETH İzninin etkisini elde ederek yetkilendirici EOA olarak gerçekleştirilebilir.
Kullanıcı limit emir koşullarını doldurur ve koşullar karşılandığında, tokenlerin DEX onaylanması, itfa için DEX gitmesi vb. dahil olmak üzere kullanıcı EOA'sı olarak yürütülebilir. DEX'in kendisi tarafından sağlanan Limit Emri ile karşılaştırıldığında, kullanıcıların önceden onay için DEX işlem göndermesine gerek yoktur.
Alice bir emir tamamladığında, aynı anda bir onay yürütecek ve önceden onay ihtiyacını ortadan kaldıracaktır.
Koşul daha genel olacak şekilde tasarlanırsa, bir Niyet sözleşmesi gibi olacaktır: kullanıcı tarafından belirtilen koşullar karşılandığı long, herkes amacı kendi EOA'sı adına gerçekleştirebilir.
Niyet koşulu karşılandığı long, herkes kullanıcının EOA'sı adına yürütmeyi başlatabilir
Kullanıcı EOA özel anahtarını kaybettiğinde, (Alice) EOA'nın tüm varlıklarını transfer etmek için yetkili kişisinin (Koca ve Güven Temsilcisi) imzalarıyla birlikte imzaladığı EIP-3074 yetkilendirmesini kullanabilir. Gerçekte, kurtarılan hesap kontrolü değil, (devredilebilir) varlıklardır. EOA özel anahtarı kaybolduktan sonra, EOA long'cu kullanılamaz.
Kullanıcı EOA özel anahtarını kaybettiğinde, diğer yetkili kişiler EOA varlıklarının transferini imzalayabilir ve yetkilendirebilir.
Belirteç yetkilendirme yöntemlerinin iyileştirilmesi ve potansiyel olarak onayın/izinin değiştirilmesi?
Şu anda, dApp'ler, kullanıcının bir EOA olduğu varsayımı altında tasarlanmaktadır: kullanıcı, dApp sözleşmesi için "ön onay vermeli" ve "yeterli miktarda parayı onaylamalıdır". Bu, kullanıcıların her zaman çevrimiçi kalmasına, dApp'in yürütülmesini beklemesine veya sürekli olarak yeniden onaylamasına gerek olmadığı anlamına gelir ve kullanıcı deneyimini büyük ölçüde iyileştirir. Limit emirleri veya DCA gibi koşulla tetiklenen uygulamalar için, koşullar karşılandığında kullanıcılar çevrimiçi olmayabilir, bu nedenle dApp sözleşmesinin yürütülmesi için yeterince büyük miktarda parayı önceden onaylamaları gerekir ve bu tekrarlayan bir süreç olabilir.
Kullanıcı, dApp'in parasıyla çalışabilmesi için dApp için yeterince büyük bir miktarı önceden onaylamalıdır.
Ancak dApp'e güvenmek veya sahte dApp'i onaylamaktan kaçınmak ve onayı hemen kaldırabilmek de gereklidir
Belirteç yerel EIP-2612 veya yerel olmayan Permit2 gibi daha sonra ortaya çıkan izin modlarının tümü, onaylama modunun kullanım deneyimini ve güvenliğini iyileştirmek içindir: kullanıcıların long'cu her bir dApp sözleşmesi için büyük miktarda parayı onaylaması gerekmez (ve her belirtecin bir kez onaylanması gerekir). Bunun yerine, kullanıcının dApp sözleşmesine "belirtilen süre" içinde "belirtilen tutarı çekme" yetkisi vermek için yalnızca "bir isim imzalaması" gerekir. Bu, yalnızca saldırı yüzeyini büyük ölçüde azaltmakla kalmaz, aynı zamanda kullanıcı deneyimini de büyük ölçüde geliştirir.
Kullanıcıların yalnızca off-chain imzalaması gerekir ve miktarı ve geçerlilik süresini belirterek, onaylamaktan daha iyi bir kullanıcı deneyimi ve güvenlik sağlar.
Ama aslında, sadece onaylamakla kalmayıp, izin modu sıklıkla bir dolandırıcılık saldırı yöntemi olarak kullanılmıştır (1,2,3): kurbanlar, bir dApp için izin olduğunu düşündükleri ancak aslında saldırgana verilen şeyi yanlışlıkla imzaladılar.
Kullanıcılar bir izni imzaladıklarında yalnızca kimin yetkilendirileceğini görebilirler, ancak yürütmek için hangi işlemlerin bu izinle eşleştirileceğini bilmezler.
Not: Mevcut izin tasarımı, DCA veya diğer düzenli ödeme uygulamaları gibi tekrarlayan işlem dApp'leri ile uyumlu değildir. Bunun nedeni, iznin bir tekrar koruma mekanizmasına sahip olmasıdır, bu nedenle bir aktarım tamamlandıktan sonra aynı izin tekrar kullanılamaz, bu da kullanıcıların gelecekteki her tekrarlayan işlem için önceden bir izin imzalamaları gerektiği anlamına gelir.
Bununla birlikte, EIP-3074 değişim için bir fırsat getiriyor: dApp geliştiricileri, EOA'nın Invoker aracılığıyla çeşitli karmaşık işlemleri gerçekleştirebileceğini bildiklerinde, dApp etkileşiminin tasarımının, "kullanıcılar büyük miktarda parayı önceden onaylar" ve "kullanıcılar para çekme işlemine izin vermek için bir izin mesajı imzalar" gibi kullanıcı deneyimini iyileştirmek emir hiçbir long'cu güvenlikten ödün vermesine gerek kalmaz. Bunun yerine, kullanıcılar Invoker aracılığıyla atomik yürütmeyi onaylamak ve gerçekleştirmek için dApp işlemlerini bağlar: onaylama ve dApp işlemleri birlikte başarıyla yürütülür veya birlikte başarısız olur. Tek başına onay için başarı olasılığı yoktur, bu nedenle kullanıcılar bu onayın bu işlem için olduğundan emin olabilirler. Ve kullanıcılar off-chain imza yetkilendirmesi kullanıyor, bu nedenle kullanıcı deneyimi izinle aynı! Bu, dApp'in long'cu izin moduna ihtiyaç duymayacağı anlamına gelir! Gelecekte, cüzdanlar, kullanıcıların bazı dApp'leri kullanmamasına (ancak dolandırıcılık için kullanılmasına) neden olup olmayacağı konusunda endişelenmenize gerek kalmadan, izin imza taleplerini doğrudan yasaklayabilir veya daha katı incelemeler yapabilir.
Kullanıcılar long'cu sadece belirli bir adresi yetkilendirmez, ancak belirli bir adresi ve ne yapılacağını yetkilendirir ve hatta simüle edilmiş yürütme sonucunu görür.
Not: Bu, dolandırıcılıkların tamamen engellenebileceği anlamına gelmez! Kullanıcılar hala dolandırıcı web sitelerine kandırılabilir ve dolandırıcı web siteleri, kullanıcıların imzalaması için onaylama veya aktarma işlemlerini düzenlemeye devam edebilir, ancak şu anda kullanıcılar en azından bu imzanın ne yapacağını görebilir ve cüzdanlar ekran yürütme sonuçlarını simüle edebilir ve bunları kullanıcılara sunabilir, böylece kullanıcılar kimin ne kadar para kaybedeceğini ve kimin ne kadar para kazanacağını açıkça bilebilir. Hangi işlemin ve hatta yürütmenin sonucunu bilmeyen izinlerle karşılaştırıldığında, kullanıcılar yetkilendirme yapıp yapmamaya karar vermek için daha fazla bilgiye sahiptir. Mükemmel bir tedavi olmasa da, mevcut durum için yine de önemli bir gelişme olacaktır.
Mevcut EIP-3074 tasarımı, imza içeriğinde EOA nonce değerini içerecektir, böylece EOA yürütme için zincire bir işlem gönderdiğinde ve nonce değerini değiştirdiğinde long, tüm orijinal EIP-3074 yetkilendirmeleri geçersiz olacaktır.
Kullanıcı, yukarıda bahsedilen Oturum Anahtarı veya Sosyal Kurtarma yöntemi gibi EOA'yı çalıştırması için başka birini yetkilendiriyorsa, EOA'nın nonce değişmesi engellenmelidir. Aksi takdirde, tüm yetkilerin yeniden imzalanması ve mütevelliye verilmesi gerekir, bu da kullanıcı deneyimi ve mekanizmanın sağlamlığı üzerinde önemli bir etkiye sahiptir.
Kullanıcı kendi başına işlem yapma yetkisine sahipse, EOA nonce değiştirilmesini özel olarak engellemeye gerek yoktur, çünkü EIP-3074 imzasının işlem gibi belirli bir son tarihten önce yürütülmesi beklenir. Sadece cüzdanın EOA'nın daha fazla EIP-3074 işlemini yönetmesi gerekiyor: zincire yüklenmeyi bekleyen EIP-3074 imza varsa, EOA'nın işlemlerinin kendisinin beklemesi gerekecektir.
Not: Invoker sözleşmesinin kendisi bir dizi nonce mekanizmasını koruyacaktır (ve korumalıdır), bu nedenle imza kullanıldıktan sonra, EOA nonce değişip değişmediğine bakılmaksızın yine de yeniden imzalanması gerekir.
Oturum Anahtarı ve Sosyal Kurtarma, büyük ölçekte benimsenmeden önce büyük olasılıkla EIP-3074'ün EOA nonce imza içeriğinden kaldırmak için kuralları değiştirmesini beklemek zorunda kalacaktır. Bu nedenle, cüzdanın yalnızca "kullanıcı tarafından yetkilendirilmiş işlemlerin" kullanım durumuna odaklanması ve EIP-3074 imzasını bir işlem olarak ele alması gerekir. EOA gönderme işlemlerinden kaçınma veya EOA nonce değiştirme konusunda endişelenmenize gerek yoktur.
Bununla birlikte, kullanıcının kendi EIP-3074 imza içeriğini zincire getirmek istemesi durumunda iki dezavantajın olacağı unutulmamalıdır:
Zincir önce EOA nonce 1 ekleyeceğinden, EIP-3074 imzasının doğrulanması, uyumsuz EOA nonce nedeniyle başarısız olacaktır.
Kullanıcılar, zincire kendileri getirmeden önce EIP-3074 imzasındaki EOA nonce 1 eklerse, doğrulama sorunsuz bir şekilde ilerleyebilir.
Daha iyi ve daha güvenli kullanım deneyimi
EIP-3074, EOA'nın (Harici Olarak Sahip Olunan Hesaplar) kontrolü belirli bir sözleşmeye devretmesine ve böylece sözleşmeyle aynı zengin yürütme yeteneklerini elde etmesine olanak tanır. EIP-3074'ten önce, bir EOA, ERC20'yi onaylamak veya Uniswap'ta takas yapmak gibi işlem başına yalnızca bir işlem gerçekleştirebiliyordu. EIP-3074'ten sonra, bir EOA aynı anda birden fazla işlem gerçekleştirebilir, hatta daha önce hayal bile edilemeyen görevleri gerçekleştirebilir. Basitçe söylemek gerekirse, EIP-3074 kullanıcı deneyimini büyük ölçüde geliştirir ve tanıdık belirteç yetkilendirme yöntemi yeniden şekillendirilerek kullanıcı deneyimini değiştirmeden güvenliği artırır.
Ayrıca, EIP-3074 aracılığıyla, EOA'nın hiçbir long'cu zincire kendi başına işlem göndermesine gerek kalmaz ve işlem ücretlerini ödemek için ETH toplama zahmetini ortadan kaldırır.
EOA'nın kontrolünü ele geçirebilen sözleşmeye Invoker sözleşmesi denir. Tabii ki, herhangi bir sözleşme EOA'nın kontrolünü ele geçiremez: EOA özel bir anahtarla imzalamalıdır ve imzanın içeriği, hangi Invoker sözleşmesi olduğunu ve Invoker'ın hangi işlemleri gerçekleştirmesine izin verildiğini açıkça belirtecektir.
EOA imza içeriği, hangi Invoker sözleşmesini (invoker adresi) açıkça belirtecek ve bu Invoker sözleşmesinin işlemlerini yetkilendirecektir (taahhüt)
Gerçek yürütme süreci muhtemelen şöyle görünecektir:
Not 1: Relayer gerekli değildir. Alice ayrıca kendi imza içeriğini ve mührünü zincire getirebilir.
Invoker imzayı doğruladıktan ve işlemi yürütmeye başladıktan sonra, EOA'nın (sınırlı) kontrolünü elde etmek gibi Alice EOA olarak yürütülecektir.
Bununla birlikte, EOA'nın nonce değerinin yürütmeden sonra artırılmayacağına dikkat edilmelidir, bu nedenle aynı imza yeniden kullanılabilir (EOA nonce değişmeden kaldığı long), bu nedenle Invoker'ın tekrar oynatmayı önlemek için kendi nonce mekanizmasını uygulaması gerekir.
Invoker sözleşmesi Tekrar Oynatmaya karşı korumalı değilse, aynı yetkilendirme her zaman yürütülebilir.
EIP-3074'ün gerçek çalışma mekanizmasına giriş için lütfen aşağıdakilere bakın: EIP3074'e Giriş
Kullanıcıların birkaç işlemin yürütülmesini tek bir işlemde birleştirmesine izin vererek, birden çok yetkili imza sürecinden ve bazı Gas maliyetlerinden tasarruf edin.
Not: Bu, dApp'in şu anda topluluk tarafından zorlanan EIP-5792 gibi Batchcall işlevini de destek gerektirecektir. Aksi takdirde, dApp, kullanıcıyı normal bir EOA olarak ele alırsa, kullanıcıdan her işlem için yalnızca bir kez imzalamasını isteyecektir.
Kullanıcılar, belirli koşullar altında üçüncü bir tarafın kendi adlarına hareket etmesine de izin verebilir. Aşağıdaki şemada yer alan temsilci anahtarı, yetkili üçüncü taraftır; erişim politikası, yalnızca Uniswap'ı çalıştırmakla sınırlamak, günde en fazla 1 ETH transfer etmek, yetkilendirme geçerlilik süresi vb. gibi yürütme kısıtlamasıdır. Bu koşullar, Invoker sözleşmesi içinde tasarlanır ve kontrol edilir. Kontrol geçtiği long, üçüncü taraf işlemleri kullanıcının EOA'sı olarak yürütebilir.
Telegram Bot'a, kullanıcının EOA'sı adına işlem gerçekleştirmesi için belirli izinler verilebilir
yerine getirildiği long (yani, İzin imzası yasalsa), ETH aktarımı, yerel ETH İzninin etkisini elde ederek yetkilendirici EOA olarak gerçekleştirilebilir.
Kullanıcı limit emir koşullarını doldurur ve koşullar karşılandığında, tokenlerin DEX onaylanması, itfa için DEX gitmesi vb. dahil olmak üzere kullanıcı EOA'sı olarak yürütülebilir. DEX'in kendisi tarafından sağlanan Limit Emri ile karşılaştırıldığında, kullanıcıların önceden onay için DEX işlem göndermesine gerek yoktur.
Alice bir emir tamamladığında, aynı anda bir onay yürütecek ve önceden onay ihtiyacını ortadan kaldıracaktır.
Koşul daha genel olacak şekilde tasarlanırsa, bir Niyet sözleşmesi gibi olacaktır: kullanıcı tarafından belirtilen koşullar karşılandığı long, herkes amacı kendi EOA'sı adına gerçekleştirebilir.
Niyet koşulu karşılandığı long, herkes kullanıcının EOA'sı adına yürütmeyi başlatabilir
Kullanıcı EOA özel anahtarını kaybettiğinde, (Alice) EOA'nın tüm varlıklarını transfer etmek için yetkili kişisinin (Koca ve Güven Temsilcisi) imzalarıyla birlikte imzaladığı EIP-3074 yetkilendirmesini kullanabilir. Gerçekte, kurtarılan hesap kontrolü değil, (devredilebilir) varlıklardır. EOA özel anahtarı kaybolduktan sonra, EOA long'cu kullanılamaz.
Kullanıcı EOA özel anahtarını kaybettiğinde, diğer yetkili kişiler EOA varlıklarının transferini imzalayabilir ve yetkilendirebilir.
Belirteç yetkilendirme yöntemlerinin iyileştirilmesi ve potansiyel olarak onayın/izinin değiştirilmesi?
Şu anda, dApp'ler, kullanıcının bir EOA olduğu varsayımı altında tasarlanmaktadır: kullanıcı, dApp sözleşmesi için "ön onay vermeli" ve "yeterli miktarda parayı onaylamalıdır". Bu, kullanıcıların her zaman çevrimiçi kalmasına, dApp'in yürütülmesini beklemesine veya sürekli olarak yeniden onaylamasına gerek olmadığı anlamına gelir ve kullanıcı deneyimini büyük ölçüde iyileştirir. Limit emirleri veya DCA gibi koşulla tetiklenen uygulamalar için, koşullar karşılandığında kullanıcılar çevrimiçi olmayabilir, bu nedenle dApp sözleşmesinin yürütülmesi için yeterince büyük miktarda parayı önceden onaylamaları gerekir ve bu tekrarlayan bir süreç olabilir.
Kullanıcı, dApp'in parasıyla çalışabilmesi için dApp için yeterince büyük bir miktarı önceden onaylamalıdır.
Ancak dApp'e güvenmek veya sahte dApp'i onaylamaktan kaçınmak ve onayı hemen kaldırabilmek de gereklidir
Belirteç yerel EIP-2612 veya yerel olmayan Permit2 gibi daha sonra ortaya çıkan izin modlarının tümü, onaylama modunun kullanım deneyimini ve güvenliğini iyileştirmek içindir: kullanıcıların long'cu her bir dApp sözleşmesi için büyük miktarda parayı onaylaması gerekmez (ve her belirtecin bir kez onaylanması gerekir). Bunun yerine, kullanıcının dApp sözleşmesine "belirtilen süre" içinde "belirtilen tutarı çekme" yetkisi vermek için yalnızca "bir isim imzalaması" gerekir. Bu, yalnızca saldırı yüzeyini büyük ölçüde azaltmakla kalmaz, aynı zamanda kullanıcı deneyimini de büyük ölçüde geliştirir.
Kullanıcıların yalnızca off-chain imzalaması gerekir ve miktarı ve geçerlilik süresini belirterek, onaylamaktan daha iyi bir kullanıcı deneyimi ve güvenlik sağlar.
Ama aslında, sadece onaylamakla kalmayıp, izin modu sıklıkla bir dolandırıcılık saldırı yöntemi olarak kullanılmıştır (1,2,3): kurbanlar, bir dApp için izin olduğunu düşündükleri ancak aslında saldırgana verilen şeyi yanlışlıkla imzaladılar.
Kullanıcılar bir izni imzaladıklarında yalnızca kimin yetkilendirileceğini görebilirler, ancak yürütmek için hangi işlemlerin bu izinle eşleştirileceğini bilmezler.
Not: Mevcut izin tasarımı, DCA veya diğer düzenli ödeme uygulamaları gibi tekrarlayan işlem dApp'leri ile uyumlu değildir. Bunun nedeni, iznin bir tekrar koruma mekanizmasına sahip olmasıdır, bu nedenle bir aktarım tamamlandıktan sonra aynı izin tekrar kullanılamaz, bu da kullanıcıların gelecekteki her tekrarlayan işlem için önceden bir izin imzalamaları gerektiği anlamına gelir.
Bununla birlikte, EIP-3074 değişim için bir fırsat getiriyor: dApp geliştiricileri, EOA'nın Invoker aracılığıyla çeşitli karmaşık işlemleri gerçekleştirebileceğini bildiklerinde, dApp etkileşiminin tasarımının, "kullanıcılar büyük miktarda parayı önceden onaylar" ve "kullanıcılar para çekme işlemine izin vermek için bir izin mesajı imzalar" gibi kullanıcı deneyimini iyileştirmek emir hiçbir long'cu güvenlikten ödün vermesine gerek kalmaz. Bunun yerine, kullanıcılar Invoker aracılığıyla atomik yürütmeyi onaylamak ve gerçekleştirmek için dApp işlemlerini bağlar: onaylama ve dApp işlemleri birlikte başarıyla yürütülür veya birlikte başarısız olur. Tek başına onay için başarı olasılığı yoktur, bu nedenle kullanıcılar bu onayın bu işlem için olduğundan emin olabilirler. Ve kullanıcılar off-chain imza yetkilendirmesi kullanıyor, bu nedenle kullanıcı deneyimi izinle aynı! Bu, dApp'in long'cu izin moduna ihtiyaç duymayacağı anlamına gelir! Gelecekte, cüzdanlar, kullanıcıların bazı dApp'leri kullanmamasına (ancak dolandırıcılık için kullanılmasına) neden olup olmayacağı konusunda endişelenmenize gerek kalmadan, izin imza taleplerini doğrudan yasaklayabilir veya daha katı incelemeler yapabilir.
Kullanıcılar long'cu sadece belirli bir adresi yetkilendirmez, ancak belirli bir adresi ve ne yapılacağını yetkilendirir ve hatta simüle edilmiş yürütme sonucunu görür.
Not: Bu, dolandırıcılıkların tamamen engellenebileceği anlamına gelmez! Kullanıcılar hala dolandırıcı web sitelerine kandırılabilir ve dolandırıcı web siteleri, kullanıcıların imzalaması için onaylama veya aktarma işlemlerini düzenlemeye devam edebilir, ancak şu anda kullanıcılar en azından bu imzanın ne yapacağını görebilir ve cüzdanlar ekran yürütme sonuçlarını simüle edebilir ve bunları kullanıcılara sunabilir, böylece kullanıcılar kimin ne kadar para kaybedeceğini ve kimin ne kadar para kazanacağını açıkça bilebilir. Hangi işlemin ve hatta yürütmenin sonucunu bilmeyen izinlerle karşılaştırıldığında, kullanıcılar yetkilendirme yapıp yapmamaya karar vermek için daha fazla bilgiye sahiptir. Mükemmel bir tedavi olmasa da, mevcut durum için yine de önemli bir gelişme olacaktır.
Mevcut EIP-3074 tasarımı, imza içeriğinde EOA nonce değerini içerecektir, böylece EOA yürütme için zincire bir işlem gönderdiğinde ve nonce değerini değiştirdiğinde long, tüm orijinal EIP-3074 yetkilendirmeleri geçersiz olacaktır.
Kullanıcı, yukarıda bahsedilen Oturum Anahtarı veya Sosyal Kurtarma yöntemi gibi EOA'yı çalıştırması için başka birini yetkilendiriyorsa, EOA'nın nonce değişmesi engellenmelidir. Aksi takdirde, tüm yetkilerin yeniden imzalanması ve mütevelliye verilmesi gerekir, bu da kullanıcı deneyimi ve mekanizmanın sağlamlığı üzerinde önemli bir etkiye sahiptir.
Kullanıcı kendi başına işlem yapma yetkisine sahipse, EOA nonce değiştirilmesini özel olarak engellemeye gerek yoktur, çünkü EIP-3074 imzasının işlem gibi belirli bir son tarihten önce yürütülmesi beklenir. Sadece cüzdanın EOA'nın daha fazla EIP-3074 işlemini yönetmesi gerekiyor: zincire yüklenmeyi bekleyen EIP-3074 imza varsa, EOA'nın işlemlerinin kendisinin beklemesi gerekecektir.
Not: Invoker sözleşmesinin kendisi bir dizi nonce mekanizmasını koruyacaktır (ve korumalıdır), bu nedenle imza kullanıldıktan sonra, EOA nonce değişip değişmediğine bakılmaksızın yine de yeniden imzalanması gerekir.
Oturum Anahtarı ve Sosyal Kurtarma, büyük ölçekte benimsenmeden önce büyük olasılıkla EIP-3074'ün EOA nonce imza içeriğinden kaldırmak için kuralları değiştirmesini beklemek zorunda kalacaktır. Bu nedenle, cüzdanın yalnızca "kullanıcı tarafından yetkilendirilmiş işlemlerin" kullanım durumuna odaklanması ve EIP-3074 imzasını bir işlem olarak ele alması gerekir. EOA gönderme işlemlerinden kaçınma veya EOA nonce değiştirme konusunda endişelenmenize gerek yoktur.
Bununla birlikte, kullanıcının kendi EIP-3074 imza içeriğini zincire getirmek istemesi durumunda iki dezavantajın olacağı unutulmamalıdır:
Zincir önce EOA nonce 1 ekleyeceğinden, EIP-3074 imzasının doğrulanması, uyumsuz EOA nonce nedeniyle başarısız olacaktır.
Kullanıcılar, zincire kendileri getirmeden önce EIP-3074 imzasındaki EOA nonce 1 eklerse, doğrulama sorunsuz bir şekilde ilerleyebilir.