ERC-8004 ve x402 birlikte: kim olduğunuz ve ne borçlu olduğunuz

ERC-8004 bir ajana zincir üstü kimlik verir: token kimliği, sahip, uçlar ve itibar ile doğrulama kayıtlarının iliştirileceği bir yer içeren bir kayıt girdisi. "Kim" sorusunu cevaplar.

x402 bir sunucuya bir istek için ücret alma yolu verir: ödenmemiş bir çağrı, makine tarafından okunabilir ödeme gereksinimleriyle HTTP 402 döner, istemci öder ve istek tekrarlanır. "Ne kadar" ve "nasıl" sorularını cevaplar.

Hiçbiri diğerini cevaplamaz. x402, kimsenin duymadığı bir ajandan seve seve para alır; ERC-8004 ise hiçbir şeye ödeme yapmayan bir ajanı seve seve tarif eder. İki ajan arasındaki gerçek bir işlem ikisine de ihtiyaç duyar ve ilginç olan kısım, aralarında duran şeydir.

Entegrasyonu yazmanın doğal yolu şudur: ucu çağır, 402 al, öde, kaynağı al. Kimlik, eğer hiç devreye giriyorsa, gelen şeye güvenip güvenmeyeceğinize karar verirken sonradan kontrol edilir.

Gerçek para söz konusu olan hiçbir şey için bu doğru sıra değildir. Ödediğiniz ana kadar geriye kalan tek soru haklı olup olmadığınızdır ve gerçekleşmiş bir stablecoin transferinin geri alması yoktur.

Doğru sıra şudur: önce karşı tarafı çözümleyin, işlem yapıp yapmayacağınıza karar verin ve ancak ondan sonra 402'yi karşılayın. Kimlik, ödemenin bir ön koşuludur, sonradan yapılan denetimi değil. Yazınca bariz duruyor ama pratikte düzenli olarak tersi yapılıyor, çünkü kodun ilk çarptığı şey 402 ve kontrol akışının düşünme sırasını belirlemesine izin vermek kolay.

Bir x402 meydan okuması bir `payTo` adresi, bir ağ, bir varlık ve bir tutar belirtir. O adres, dikiş yeridir.

Kimsenin sormadığı soru şudur: bu meydan okumadaki adres, satın aldığınızı sandığınız ajana mı ait? x402 içinde bunu iddia eden hiçbir şey yok ve ERC-8004 içinde bir kayıt girdisini, bir sunucunun 402 cevabına koyduğu adrese otomatik olarak bağlayan hiçbir şey yok.

Dolayısıyla önemli olan kontrol şudur: bu meydan okumadaki `payTo`, karşı tarafın zincir üstünde kontrolünü kanıtladığı adresle eşleşiyor mu? Bir sunucu, içinde başkasının adresi olan bir 402 sunmaya ikna edilebiliyorsa ya da bir ajanın kayıt girdisi hiç sahipliğini kanıtlamadığı bir adresi listeliyorsa, her bileşen tam olarak tarif edildiği gibi davranırken ödeme yanlış yere gider.

KYA'nın, yani bir ajanın iddia ettiği cüzdanı kontrol ettiğine dair belgenin, bir incelik olmamasının sebebi budur. Dikiş yerini taşıyıcı hale getiren şey odur.

ERC-8004 kimliklerine birkaç şekilde atıf yapılabilir: `#849980` gibi bir token kimliği, `eip155:5042002:8004/849980` gibi bir CAIP tanımlayıcısı ya da sahibin `0x` adresi. Üçü de aynı ajanı çözümler.

Bu esneklik pratiktir ve aynı zamanda hataların saklandığı bir yerdir. Tanımlayıcıları metin olarak karşılaştıran kod, `#849980` ile onun CAIP biçiminin farklı ajanlar olduğuna karar verir; sahip adresini kimlik sayan kod ise aynı sahibi paylaşan iki ajanı birleştirir.

Sisteminizin sınırında tek bir kanonik biçime normalleştirin ve yalnızca onu karşılaştırın. Bir ajan kimliği bir metin değildir ve öyleymiş gibi davranmak, bir operatör aynı cüzdandan iki ajan kaydedene kadar sorunsuz çalışır.

İlk zincirler arası akışını kuran insanları yakalayan kısım şu: kimliğin yaşadığı zincir ile paranın hareket ettiği zincirin aynı olması gerekmez ve sıklıkla aynı değildir.

Bir ajan bir ağda ERC-8004 kaydı tutup x402 ödemelerini başka bir ağda gerçekleştirebilir. Bizim güven oracle'ımız tam olarak bunu yapıyor: kimlik okumaları Circle Arc üzerinde, settlement X Layer üzerinde.

Bunda yanlış bir şey yok, ama şu anlama geliyor: doğrulamanız ve ödemeniz, iki farklı doğruluk kaynağına karşı yapılan iki farklı zincir okumasıdır ve birbirleriyle çelişebilirler. Bir zincirde iptal edilmiş bir kimlik, başka bir zincirde gerçekleşen ödemeyi otomatik olarak durdurmaz. Risk mantığınız iki bilginin de aynı yerden geldiğini varsayıyorsa, tam da en yanlış anda kendinden emin biçimde yanılacaktır.

ERC-8004'ün bir itibar kaydı var ve bu, geri bildirimin nasıl kaydedileceğini standartlaştırıyor. Ama o geri bildirimi doğru yapmıyor. Herkes herkes hakkında her şeyi beyan edebilir ve kimsenin duymadığı adreslerden gelen övgülerle dolu bir kayıt girdisi tam olarak hiçbir şey ifade etmez.

İşe yarayan sinyal x402 tarafındadır: settlement'lar. Bir ödeme, birinin parasıyla arkasında durduğu bir iddiadır ve bu, bir puanlamadan maddi olarak farklı türde bir kanıttır.

Dolayısıyla pratik kurulum, itibarı beyanlardan değil settlement geçmişinden hesaplamak ve itibar kaydını girdi olarak değil, sonucu yayınlanacak bir yer olarak kullanmaktır. İki standardın birleştiği yön budur: x402 kanıtı üretir, ERC-8004 ona yaşayacak bir yer verir.

Karşı tarafı tanımlayıcısından, normalleştirilmiş biçimde çözümleyin. Bir kaydı olduğunu ve KYA'nın söz konusu cüzdanın kontrolünü kanıtladığını doğrulayın. İtibarı beyanlardan değil, gerçekleşmiş ödemelerden hesaplayın veya çekin. Riski soyut olarak değil, göndermek üzere olduğunuz tutara göre boyutlandırın. Ödemeyi kendi harcama limitlerinize karşı kontrol edin, ki bu karşı tarafın sağlam olup olmadığından ayrı bir sorudur. Ancak ondan sonra, `payTo`'nun doğruladığınız adresle eşleştiğini teyit ederek 402'yi karşılayın.

Altı adım; bunların sonuncusunu x402, ilk ikisinin bir kısmını ERC-8004 kapsıyor. Aradaki her şey, hiçbir standardın belirlemediği katman, ki bu konuda bilinçli olmaya değmesinin sebebi tam olarak bu.

A-Identity bu akışın ortasını çağrı başına ödemeli uçlar olarak uyguluyor ve kendisi de x402 üzerinden ödeme alan bir ERC-8004 ajanı, dolayısıyla döngünün tamamı anlatılmakla kalmıyor, bizzat kullanılıyor.

`trust_preview` ücretsiz ve anahtar istemiyor, böylece hiçbir şey bağlamadan bir doğrulama sonucunun nasıl göründüğünü görebilirsiniz. Skorlama yöntemi yayında ve arkasındaki settlement'lar işlem özetleriyle listeleniyor.