AI ajanları onchain ticareti nasıl gerçekleştiriyor?

AI ajanlarının onchain ticaretleri gerçekleştirmesi, 'AI sihri' değil, altyapıya dayanıyor: ajan, diğer aktörlerin Ethereum durum değişikliklerine dönüştürdüğü imzalı niyetler üretir. Ticaret, iki demiryolunun doğru bir şekilde bağlanması durumunda yalnızca sonuçlanır: yürütme demiryolu (EOA işlemi veya ERC-4337 UserOperation) ve token-izin demiryolu (izinler veya Permit2 tarzı izinler).

Anahtar Çıkarımlar

• Bir AI ajanı kendi başına 'ticaret' yapmaz Ethereum'da. Onun, sözleşme çağrılarını ve token transferlerini tetikleyebilen bir onchain hesabı kontrol etmesi veya yetkilendirilmesi gerekir.
• İki yürütme demiryolu vardır: EOA kökenli bir işlem veya bir bundler'ın doğrulama ve yürütme için EntryPoint sözleşmesine sunduğu ERC-4337 UserOperation.
• Değişimlerin token hareketinden önce açık token harcama iznine ihtiyacı vardır ve Permit2AllowanceTransfer, o izni bağlamak ve tekrar oynamaya karşı korumak için süre sonları ve her bir (sahip, token, harcayıcı) için nonce'lar ekler.
• Daha büyük boyutlar veya daha sıkı kontroller için, bir Safe, bir ajanı bir işlemi önermeye izin vererek görevleri ayırabilirken, birden fazla sahibin yürütmeden önce onaylamasını sağlar.

Bir AI ajanı nasıl zincir üzerinde ticaret yapabilir

Bir model çıktısı onchain bir eylem değildir. Zincir, yalnızca imza kontrollerini geçen ve bir hesabın sözleşmelere çağrı yaptığı mesajlara yanıt verir.varlıklarOtonom onchain ticaretin arkasındaki temel gerçek budur: “ajan”, offchain bir karar motorudur ve onchain kısmı, ağın kabul edeceği bir hesap artı imzalı bir istektir.

İki ray birblok gezginiİlk olarak, yürütme rayı, talebin nasıl bir Ethereum işlemi haline geldiğini ifade eder. Ethereum'da, yalnızca Harici Sahipli Hesap (EOA) bir işlemi başlatabilir, çünkü bir EOA birözel anahtarve işlemi doğrudan imzalar. Bir akıllı sözleşmehesabı varlıkları tutabilir ve mantık çalıştırabilir, ancak kendi başına bir işlem başlatamaz. Sadece başka bir şey tarafından çağrıldığında çalışır.

İkinci ray, token hareketidir. Bir DEXtakas, “sadece bir yönlendirici çağırmak” değildir.ERC-20 tokenlarıbir takas fonksiyonu çağrıldığı için hareket etmez. Token sahibi, bir harcayıcıya harcama yetkisi verdiği için hareket eder ve ardından o harcayıcı bu yetkiyi kullanarak tokenları transfer eder.

Eğer ajan, ERC-20'leri etkileyen onchain ajan yürütmesi inşa ediyorsa, her seferinde her iki rayı da çözmesi gerekir: (1) zincirin çağrıları yürütmesini sağlamak ve (2) doğru sözleşmenin doğru miktarda token çekmesine yetki verdiğinden emin olmak.

Burada defai ürünlerinin kümelendiği yer: cüzdan UX'inde sarılı otonom yürütme, imzalanan ve harcanan şeyler etrafında koruma rayları ile. Kullanışlı zihinsel model, defai otonom onchain yürütmesinin bir kategori olarak arkasındaki aynı modeldir: ajan niyetleri yazar ve altyapı bu niyetleri uzlaşmaya dönüştürür.

ERC-4337 yürütme hattı

ERC-4337, “bir işlem gönder” eylemini ek aktörlerle bir tedarik zincirine dönüştürüyor ve bu, güvenilirlik varsayımlarını değiştiriyor. Bir EOA'nın işlemi kamuya yayması yerine,mempool, bir ERC-4337 cüzdanı bir UserOperation nesnesi oluşturur ve bunu daha sonra bir singleton EntryPoint sözleşmesine onchain işlem gönderen bir bundler'a teslim eder.

Uçtan uca akış, bir dizi olarak takip edilmesi en kolay olandır:

1. Ajan, bir yük hazırlar. ERC-4337 akıllı hesabı olan bir ajan cüzdanı için yük, gönderici, nonce, callData, gaz limitleri, ücret parametreleri ve bir imza gibi alanlara sahip bir UserOperation'dır. 2. Ajan, UserOperation'ı alternatif bir mempool'a gönderir. Cüzdanlar genellikle bunu standart Ethereum işlem havuzu yerine bir bundler RPC uç noktasına gönderir. 3. Bir bundler toplar ve simüle eder.

Bundler'lar alternatif mempool'u izler, aday UserOperation'ları simüle eder ve hangilerini bir pakete dahil edeceğine karar verir. 4. Bundler, onchain işlemi başlatır. Bundler, bir dizi UserOperation ile EntryPoint.handleOps çağrısını yapar ve bu çağrı, bir blokta yer alan gerçek Ethereum işlemidir. 5. EntryPoint doğrular, ardından yürütür.

EntryPoint, iki aşamalı bir modeli takip eder: önce hesap üzerinde validateUserOp çağrısını yapar (ve bir paymaster eklenmişse validatePaymasterUserOp'u da) ve ancak o zaman yürütme aşamasını çalıştırır. 6. Gaz, ön fonlar veya bir paymaster aracılığıyla ödenir. ERC-4337, bir Paymaster sözleşmesinin belirli kurallar altında bundler'ı geri ödeyerek gazı sponsorluk yapmasına izin verir.

AI ticaret ajanı mekanikleri için ana nokta imza formatı değildir. Önemli olan, kimin dahil olmaktan sorumlu olduğudur. ERC-4337 ile "ajanın yürüttüğü" durum, ajanın imza attığı an değildir. Bu, EntryPoint'in yürütüldüğü andır ve bu, paketleyici davranışına ve gazın sponsorlu olup olmadığına bağlı olarak paymaster kurallarına dayanır.

Ajanlar token harcama izni nasıl alır

Token hareketi, çoğu ajan tasarımının risk sızdırdığı yerdir, çünkü izinler genellikle ticaretten daha uzun sürer. Temiz model, önce izin, sonra yürütme şeklindedir. ERC-4337, birden fazla eylemi tek bir UserOperation içinde birleştirerek bunları tek bir yerleşime sıkıştırabilir, ancak izinlerin hâlâ açık ve sınırlı olması gerekir.

Uniswap’ın Permit2 AllowanceTransfer'ı bu katman için somut bir ilke setidir. Üç temel giriş noktasını destekler: onchain izinleri ayarlamak için approve, bir imza aracılığıyla izinleri ayarlamak için permit ve geçerli izinler zaten mevcut olduğunda harcama yapmak için transferFrom. Eski “maksimum onayla sonsuza dek” alışkanlığına göre önemli fark, Permit2 izinlerinin bir sona erme zaman damgası kullanılarak zaman sınırlı hale getirilebilmesidir.

Permit2 ayrıca, ajanların gerçekten kullanabileceği pratik bir tekrar koruma mekanizması sunar. Nonce şeması, sahip başına, token başına ve harcayan başına nonce'ları artırır ve bunları bir izin haritasına paketler. Bu, bir iznin sadece "sahip bir kez imzaladı mı" değil, "sahip bu harcayan için bu belirli harcama penceresini imzaladı mı ve bu nonce zaten kullanıldı mı" olduğu anlamına gelir.

Permit2'nin izni, EOA imzalarını, EIP-2098 kompakt imzalarını ve EIP-1271 sözleşme imzalarını destekler; bu, sahibin bir EOA yerine akıllı bir hesap olduğu durumlarda önemlidir.

DeFi'de ajanların nasıl ticaret yaptığına gelince, bu, şeyler dikkatlice inşa edildiğinde ortaya çıkan operasyonel modeldir:

1. Ajan dar bir harcama penceresi talep eder. Miktar sınırlıdır, son tarih kısadır, harcayan belirgindir. 2. Ajan izin verme işlemini yürütme ile birleştirir. Bir izin veya onay, izinlerin kullanılmadan beklemesini önlemek için takas çağrısı ile birleştirilebilir. 3. Ajan yalnızca o pencerede transferFrom ile harcar. Pencere süresi dolarsa, izin zincir üzerinde geçersiz hale gelir.

Bu aynı zamanda niyet bazlı yürütme ve bir çözücü ağının kavramsal olarak nasıl uyduğudur. Ajan, istenen sonucu ifade eden bir niyet imzalayabilirken, çözücüler bunu yönlendirmek ve sonuçlandırmak için rekabet eder. Kim yönlendirirse yönlendirsin, token-izin demiryolu hala sahibin hesabından neyin çekilebileceğini belirler.

Multisig ve politika kontrolleri ile Safe

Gerçek para için en sağlam kontrol modeli politika ayrımıdır: ajanın öneride bulunmasına izin verin, ancak yürütmek için bir Safe eşiği gerektirin. Bu, otomasyonu korurken tek bir model çalıştırma anahtarından tek taraflı yetkiyi kaldırır.

Safe'in belgelenmiş akışı, devralmalar hakkında açıktır. Bir işlem oluşturulur, Safe İşlem Servisine önerilir, diğer sahipler tarafından onaylanır ve ancak o zaman yürütülür. Safe Protokol Kiti kılavuzunda, sıra şöyledir: bir işlem nesnesi oluşturun, Safe işlem hash'ini hesaplayın, diğer sahiplerin görebilmesi için önerin, sahiplerden onaylar (imzalar) toplayın, ardından executeTransaction ile yürütün.

Bu, otonom yürütme için önemlidir çünkü 'ajan eylemi' ne anlama geldiğini değiştirir. Ajan, bir DEX yönlendirici çağrısı için veya bir ERC-4337 hesabının executeBatch'ı için tam calldata üretebilir, ancak Safe, o yükün zincire ulaşmasına izin verilip verilmeyeceğine karar veren risk masasıdır.

Bu, kaynakların ajanslar için standartlaştırmadığı politikaları uygulamak için temiz bir yerdir, örneğin yeni harcayanları sınırlamak, yeni tokenlar için ekstra onaylar gerektirmek veya boyut kısıtlamak.

Safe ayrıca hesap katmanında oturum anahtarı modelleriyle iyi çalışır. ERC-4337 hesapları, validateUserOp içinde farklı imza şemalarını doğrulayabilir ve bir oturum anahtarı bu şemalardan biri olabilir. Önemli olan, moda kelime değildir. Önemli olan, kısa ömürlü bir anahtarın dar eylemler için yetkilendirilmesi, uzun vadeli sahiplerin nihai kontrolü elinde tutmasıdır.

Defai sistemleri inşa eden ekipler için bu, 'ajan ticaret yapabilir' ile 'ajan ticaret taslağı oluşturabilir' arasındaki farktır. Taslak oluşturmak ucuzdur. Yürütme, geri alınamaz durum değişikliklerinin gerçekleştiği yerdir.

Tasarım takasları ve başarısızlık modları

İlk hata modu, mesaj türlerini karıştırmaktır. Bir UserOperation, bir Ethereum işlemi değildir. Bir bundler bunu bir EntryPoint.handleOps çağrısına sarana kadar alternatif bir mempool'da veridir. Bu nedenle, akıllı sözleşme hesapları "EOA'lar gibi sadece işlem gönderemezler." Sadece EOA'lar işlem başlatır ve akıllı hesaplar çağrıldığında hareket eder.

İkinci hata modu, bundler'ı görünmez bir altyapı olarak muamele etmektir. ERC-4337, varsayımları "cüzdanım yayın yapıyor"dan "bir bundler beni dahil edecek mi"ye kaydırır. Eco'nun tanımı, bundler'ların alternatif mempool'u izlediğini, simüle ettiğini ve paketler sunduğunu, L1 gazı ödediğini ve ön fonlar veya ödeme yöneticilerinden geri ödendiğini açıkça belirtmektedir.

Eğer bir bundler uç noktası kapalıysa, hız sınırlıysa veya belirli işlemleri reddediyorsa, ajan imzalamaya devam edebilir ve hiçbir şey sonuçlanmaz.

Üçüncü hata modu, izin yayılmasıdır. Sınırsız onaylar bir ticaret özelliği değildir. Onlar sürekli bir kayıp yüzeyidir. Permit2'nin sona erme zaman damgaları ve her bir (sahip, token, harcayıcı) nonce'ları, o yüzeyi sınırlayabilecek zincir üzerindeki kontrol mekanizmalarıdır, ancak yalnızca entegrasyon bunları kullanıyorsa.

Yaygın bir entegrasyon hatası, yanlış harcayıcıyı yetkilendirmek veya bir transfer çağrısına yanlış bir adres göndermektir; bu, Uniswap tarafından entegrasyon sözleşmeleri için bir güvenlik dikkati olarak işaretlenir.

Dördüncü hata modu, AI'yi aşırı kredi vermektir. Zincir üzerindeki ajan yürütmesindeki çoğu patlama, modelin yanlış tarafı seçmesinden değil, bağlantılardan kaynaklanır. Eğer ajan cüzdanı geniş bir izin imzalayabiliyorsa veya ödeme yöneticisi kuralları çok gevşekse, sistem tam olarak yetkilendirildiği şeyi yapabilir ve yine de kabul edilemez olabilir.

Ticaret özeti basittir. EOA'lar basit ve doğrudandır ancak tüm sistemi bir anahtarın arkasına koyar. ERC-4337, toplama, özel doğrulama ve sponsorlu gaz ekler, ancak bundler'lar, EntryPoint ve isteğe bağlı ödeme yöneticileri ile bir işlem tedarik zinciri tanıtır. Safe, tasarım gereği sürtünme ekler ve bu sürtünme, boyutun önemli olduğu noktadır.

Herhangi bir ciddi mimari belgesinin en alt kısmında, daha geniş konu hala otonom zincir üzerindeki yürütmedir ve soru, sistemin stres altında gerçekten hangi rayı ve hangi politika katmanını destekleyebileceğidir.

Alıntı

Takımın "AI" kısmına takıntılı bir şekilde odaklandığını ve ardından pahalı bir hatayı gönderdiğini izledim: kırılgan altyapıyla eşleştirilmiş geniş, uzun ömürlü bir token onayı. Bir şey ters gittiğinde, bu nadiren modelin bir ticareti hayal etmesinden kaynaklanır.

Bunun nedeni, izin katmanının bir harcayıcının beklenenden daha fazlasını çekmesine izin vermesi veya ERC-4337 tedarik zincirinin bundler'da durması ve kimsenin dahil olmayı izlememesidir.

Temiz duruş, bunu her seferinde iki anahtar diyagramı gibi ele almaktır: yürütme yetkisi ve harcama yetkisi. Tasarım, işlemi kimin başlattığını (EOA mı yoksa EntryPoint aracılığıyla bundler mı) ve harcayıcının tam olarak ne kadar çekebileceğini (miktar, sona erme, nonce kapsamı) bir cümlede yanıtlayamıyorsa, sistem "otonom" değildir. Sadece gözetime ihtiyaç duyan bir sistemdir.

Kaynaklar

• QuickNode
• Ekolojik
• Uniswap
• Güvenli