Autor original: Nick Pai, Archetype
Compilație originală: Deep Chao TechFlow
Acest articol este împărțit în două părți. În primul rând, mi-am expus convingerea că infrastructura de abstractizare în lanț este esențială pentru adoptarea de către consumatori a criptomonedelor și că o arhitectură bazată pe intenții este cea mai bună modalitate de a o proiecta. În al doilea rând, descriu principala barieră în calea adoptării pe scară largă: activitatea rețelei de soluții.
Închei articolul propunând o soluție și introducând standardul dezvoltat în colaborare între Across și Uniswap, pe baza feedback-ului din partea grupului de lucru CAKE. Acest standard este conceput pentru a optimiza experiența utilizatorului soluției, pentru a reduce bariera de intrare într-o rețea de soluții comună, astfel încât majoritatea intențiilor să poată fi direcționate către această rețea și, în cele din urmă, să permită rețelelor de soluții mai mari și mai competitive să înflorească.
agenda
întrebare:
Definirea stării finale: ce face ca o aplicație criptografică să fie „utilizabilă”?
De ce este „abstracția în lanț” soluția pentru problemele experienței utilizatorului cauzate de topologia de bază a blockchain-urilor modulare?
De ce trebuie să fie construite aplicațiile criptografice utilizabile pe infrastructura de abstractizare în lanț?
Spațiu soluție:
Cum arhitectura bazată pe intenții creează abstracții în lanț
Înțelegeți că piețele de intenție funcționează cel mai bine atunci când rețeaua de soluții este mare și competitivă
Lansarea unei rețele de soluții de intenție necesită introducerea mai multor aplicații care vor genera intenții
propunere:
De ce avem nevoie de un standard de intenție încrucișată care să prioritizeze „experiența utilizatorului soluției” pentru a extinde piața de soluții și intenții la o scară suficient de mare pentru a obține efecte de rețea
Fără abstractizare în lanț, este imposibil să construiești aplicații criptografice utilizabile
Sunt infrastructura redundantă a clădirilor noastre cea mai bună și mai strălucitoare?
Mulți oameni se plâng că cei mai buni ingineri cripto sunt prea concentrați pe furnizarea de mai mult spațiu de bloc pentru utilizatorii finali. Această critică este valabilă, există prea multe soluții L2 pentru utilizatorii finali în raport cu cererea.
Cu toate acestea, refuz să accept că nu există aplicații criptografice utile.
Finanțarea descentralizată oferă persoanelor fizice capacitatea de a-și auto-custodia activele digitale, permițându-le să ocolească furnizorii de servicii pretențioși și să-și folosească activele digitale pentru a achiziționa lucruri de valoare reală. Promisiunea datelor de auto-custodie oferă, de asemenea, o alternativă utopică persoanelor din ce în ce mai precaute în a avea încredere în monopolul FAANG pentru a-și păstra datele în siguranță.
Cred că adevărata problemă nu este lipsa de aplicații cripto utile, ci fricțiunea atunci când utilizatorii finali încearcă să le acceseze. Utilizatorii finali ar trebui să experimenteze următoarele atunci când interacționează cu aplicații criptate:
Viteză: aplicația ar trebui să pară la fel de rapidă ca o aplicație web2
Cost: spre deosebire de web2, toate interacțiunile web3 trebuie să implice un anumit cost, dar costul pe clic ar trebui să fie neglijabil
Rezistența la cenzură („fără permis”): oricine are un portofel ar trebui să poată interacționa cu aplicația, atâta timp cât își poate permite taxa
Securitate: clicurile ar trebui să finalizeze acțiunea așteptată de utilizator și nu ar trebui să fie anulate, iar toate actualizările web3 ar trebui să fie permanente
Acestea sunt atributele unei aplicații criptografice „utilizabile”.
Am încercat să construim o criptare utilizabilă de mult timp
Soluțiile blockchain modulare de astăzi oferă consumatorilor toate aceste atribute, dar nu sunt toate disponibile în aceeași locație.
În 2020, blockchain-ul este monolitic, oferind utilizatorilor finali două din trei atribute: viteza, costul sau securitatea. Ne-am imaginat apoi un viitor centrat pe rollup sau modular care a deblocat toate cele trei atribute simultan.
Astăzi, am pus bazele acestei infrastructuri de upgrade axate pe upgrade. L2 oferă spațiu de bloc ieftin și rapid, în timp ce majoritatea L2 oferă spațiu de bloc fără permisiune. În schimb, L1 oferă un spațiu bloc securizat care este rezistent la WW3 (puteți citi mai multe despre compromisurile dintre securitate și experiența utilizatorului oferite de L1 și L2 în articolul meu). Aceste L2 se conectează în siguranță la L1 prin căi de mesaje reglementate, oferind baza unei rețele modulare și interoperabile. În ultimii patru ani, am construit fibra între blockchain-uri care acceptă aplicații criptografice utile. Dar de ce blockchain-urile modulare sunt atât de inutilizabile?
Inevitabilitatea rețelelor blockchain modulare este că activele de capital vor fi grupate pe cele mai sigure straturi, în timp ce clicurile utilizatorilor vor fi grupate pe straturi mai rapide și mai ieftine.
Topologia blockchain modulară încurajează ca spațiul bloc securizat să fie furnizat pe un alt strat decât spațiul bloc ieftin și rapid. În mod natural, utilizatorii vor avea tendința de a-și stoca valoarea pe cele mai sigure rețele, dar vor solicita interacțiuni frecvente cu rețele ieftine și rapide. Prin proiectare, calea canonică între L2 și L1 este lentă și/sau costisitoare. Aceste fenomene explică de ce utilizatorii trebuie să parcurgă aceste căi canonice pentru a plăti pentru interacțiunile L2 folosind activele L1. Acest lucru are ca rezultat o experiență de utilizator de criptare „inutilizabilă”.
Scopul abstracției în lanț este de a reduce frecarea utilizatorilor care trimit valoare pe căile acestor protocoale. Abstractorii lanțului presupun că utilizatorii preferă să atribuie dapp-urilor stările finale dorite ca „intenții” și că dapp-urile sunt responsabile pentru implementarea intențiilor lor. Utilizatorii nu ar trebui să compromită custodia activelor securizate pentru acces la taxe mici și latență redusă.
Prin urmare, abstracția lanțului constă în capacitatea utilizatorilor de a transfera valoare în rețea în siguranță, ieftin și rapid. Un flux de utilizatori obișnuit astăzi este că un utilizator cu un sold USDC pe un lanț „securizat” (cum ar fi Ethereum) dorește să bată un NFT sau să schimbe noi jetoane pe un lanț nou (cum ar fi Blast sau Base). Modul de a face acest lucru în cât mai puțini pași este de a efectua o secvență de tranzacții bridge → swap → mint (sau swap → bridge → mint).
În acest exemplu, intenția utilizatorului este să-și folosească USDC-ul pe lanțul securizat pentru a crea un NFT pe alt lanț. Utilizatorii vor fi mulțumiți atâta timp cât primesc NFT și soldul USDC este debitat la locația de custodie aleasă de ei.
Arhitectura bazată pe intenții este singura modalitate de a construi abstracții în lanț
Abstracțiile în lanț se bazează pe transferul de valoare încrucișat, dar trimiterea valorii prin căile de mesaje canonice este fie costisitoare, fie lentă. „Puțile rapide” oferă utilizatorilor o alternativă ieftină și rapidă la trimiterea de valoare prin rețele, dar introduc noi ipoteze de încredere. Mesageria este cea mai intuitivă modalitate de a construi o punte rapidă, deoarece este modelată pe arhitectura TCP/IP, se bazează pe un protocol de legătură care acționează ca un router TCP pentru a conecta cele două lanțuri.
Diagrama TCP/IP ResearchGate
Transferul de valoare prin transmiterea mesajelor implică un protocol bridge care trimite mesaje între contractele de pe lanțurile inițiale și țintă. Acest mesaj este declanșat pe partea de origine de o tranzacție de utilizator și este transmis către partea de destinație odată ce „validitatea” mesajului este verificată.
Un mesaj poate fi verificat numai după ce tranzacția inițială în lanț care a inițiat mesajul a fost finalizată, adică tranzacția a fost inclusă permanent în blockchain-ul canonic al lanțului inițial. Această verificare se poate face printr-o dovadă a validității că tranzacția a fost inclusă în consensul lanțului inițial, o propunere optimistă sau după ce s-au acumulat un anumit număr de semnături ale martorilor pe partea inițială. Odată ce mesajul este transmis către contractul de punte pe lanțul țintă, jetoanele sunt eliberate utilizatorului.
Există mai multe probleme fundamentale cu această arhitectură:
Mecanismul de verificare trebuie să aștepte finalitatea completă înainte de a trimite mesajul către contractul de protocol al lanțului țintă. Pentru L2 cu perioadă de determinare optimistă, aceasta poate dura până la șapte zile.
Trimiteți un singur mesaj în lanț încrucișat per tranzacție bridge sau grupați mesajele împreună, dar trimiteți lotul numai după ce ultimul mesaj din lot s-a terminat.
Puntea este limitată în capacitatea sa de a accesa lichidități externe pentru a oferi îmbunătățiri de preț utilizatorilor, deoarece trebuie să declare calea de îndeplinire a intenției utilizatorului.
Conectarea rapidă bazată pe mesagerie poate fi nesigură, lentă sau costisitoare, în funcție de mecanismul de autentificare. Intent Marketplace este o arhitectură alternativă pentru o legătură rapidă care provine dintr-o perspectivă cheie:
Valoarea este fungibilă și nu contează pentru destinatar cum este transferată valoarea, atâta timp cât fondurile sunt primite
Se poate transfera valoarea subcontractării către un agent sofisticat pentru a crește viteza și a reduce costurile? Lichiditatea este dinamică pe și în afara lanțului, iar îmbunătățirile de preț pot fi obținute dacă mecanismul de trecere poate alege în mod flexibil cea mai bună cale de execuție atunci când se realizează transferuri.
Mecanismul de intenție permite utilizatorilor să specifice condițiile sau contractele precise în care pot fi executate tranzacțiile lor de transfer de valoare.
Cea mai simplă intenție este să plătiți X jetoane din lanțul A pentru a primi o comandă pentru Y jetoane pe lanțul B.
Protocoalele de legătură nu necesită trimiterea de mesaje între domenii pentru a satisface intenția utilizatorului pe mai multe domenii. În schimb, protocolul externalizează transferul de valoare către agenți selectați dintr-o rețea de rezolutori fără permisiune, iar solutorii individuali vor solicita ulterior rambursarea din protocolul de legătură. În schimb, mecanismele bazate pe mesagerie specifică exact cum ar trebui efectuate tranzacțiile lor și nu trebuie să se bazeze pe disponibilitatea brokerilor.
acord de soluționare a intenției
Protocoalele de legătură bazate pe intenție pot fi mai precis etichetate ca protocoale de soluționare a intenției, ele fiind responsabile pentru a se asigura că solutorul nu încalcă condițiile specificate de utilizator. Protocolul de soluționare a intențiilor oferă garanții solutorilor că vor fi rambursați și recompensați atunci când îndeplinesc intențiile utilizatorului. Pentru a face acest lucru, acordul de soluționare a intenției trebuie să facă apel la Oracle pentru a verifica autenticitatea intenției de a efectua. Securitatea oracolului se poate baza pe perioada de provocare optimistă, pragul martor sau dovada validității ZK etc.
Protocoalele de soluționare a intenției oferă un transfer de valoare rapid și cu costuri reduse, deoarece un singur solutor își asumă riscul final și determină cea mai bună cale de execuție
Punturile de mesagerie pot comunica numai atunci când lanțul inițial a ajuns la final. Astăzi, durata finalității este de șapte zile pentru Optimistic Rollup și o oră pentru ZK Rollup. Deși acești timpi de finalitate ar trebui să scadă odată cu adoptarea pe scară largă a tehnologiei ZK light client și cu progresele în tehnologia de pre-confirmare a comenzilor partajate, ca în cazul tuturor blockchain-urilor, este puțin probabil ca timpii de finalitate să fie vreodată semnificativi pentru utilizatori, ceea ce demonstrează continuarea nevoie de soluții rapide de legătură. Fără a-și asuma riscul finalității, chiar dacă bridge-ul ar dori să adauge un proxy de încredere suplimentar în calea de retransmisie pentru a acoperi pierderile din cauza reorganizării lanțului, nu ar putea crește vitezele de livrare a mesajelor dincolo de perioada de finalitate.
Accelerarea oferită de arhitecturile bazate pe intenție se datorează faptului că un singur rezolvator dintr-o rețea de soluție eterogenă își poate asuma un risc de finalitate mai mare decât un protocol de transmitere a mesajelor și poate satisface intenția utilizatorului înainte ca riscul reorganizării lanțului să dispară complet. Rezolvatorul percepe apoi utilizatorii riscul final pe care și-l asumă atunci când schimbul este mai rapid.
Externalizarea îndeplinirii intențiilor încrucișate către un agent va îmbunătăți, de asemenea, prețurile pentru utilizatori în medie. În bridging-ul bazat pe intenție, pentru a îndeplini comanda utilizatorului pe lanțul țintă, solutorul front-end va fi returnat de sistem după validarea îndeplinirii acestora. Aceste decontări de intenție pot fi grupate împreună pentru a împărți costul. Spre deosebire de utilizatori, materialele de umplere nu necesită rambursare imediată și vor percepe utilizatorilor o taxă de finanțare în mod corespunzător. Decontarea loturilor nu este singura caracteristică a arhitecturii bazate pe intenție, dar această arhitectură este mai sinergică cu decontarea loturilor, deoarece separă etapa de rambursare de etapa de îndeplinire a intenției.
O sursă mai mare de îmbunătățire a prețurilor provine din intuiția că valoarea este fungibilă și că găsirea celei mai bune căi în timp va depăși, în general, transferul de valoare, cu toate acestea, există unele căi care nu pot fi depășite în timp în ceea ce privește costul, cum ar fi atunci când se transferă USDC pe CCTP .
Podurile de mesagerie trebuie să codifice modul în care vor oferi valoare utilizatorilor. Unii aleg să trimită jetoane din pool-uri de lichiditate la un curs de schimb predeterminat, în timp ce alții bat jetoane reprezentative către destinatarii care trebuie să schimbe ulterior activele jetoane canonice necesare.
Atunci când îndeplinesc intenția utilizatorului, agenții pot extrage lichiditate dintr-o combinație de locuri de lichiditate în lanț și în afara lanțului. Rețeaua de soluții competitive oferă, teoretic, utilizatorilor surse nelimitate de lichiditate (dar chiar și aceste surse de lichiditate pot fi epuizate rapid într-o singură direcție în timpul evenimentelor cu volatilitate ridicată în lanț, cum ar fi popularul eveniment NFT de batere, airdrops și covoare).
Prin trimiterea unei comenzi în lanț încrucișat ca intenție, soluția poate internaliza MEV generată de comandă ca o îmbunătățire a prețului.
Arhitectura bazată pe intenții este proiectată de la zero pentru a fi sigură
Punțile bazate pe intenții pot fi construite în siguranță, deoarece separă nevoile urgente ale utilizatorilor de nevoile complexe ale rețelei de decontare. Rezolvatorii pot aștepta rambursarea, spre deosebire de utilizatorii care vor fi taxați conform acordului de decontare pentru timpul în care așteaptă rambursarea. Prin urmare, soluționarea intenției poate fi verificată folosind un mecanism foarte robust, fără constrângeri stricte de timp. Acest lucru este de preferat din punct de vedere al securității, deoarece verificarea implementării intenției este intuitiv complexă.
Ca exemplu de validare a intenției în producție, Across validează și rambursează materialele de umplere în loturi după o perioadă optimistă de provocare de 90 de minute. Desigur, rețelele de decontare ar trebui să se străduiască să ramburseze materialele de umplere cât mai repede posibil pentru a reduce taxele pentru utilizatorii finali. O îmbunătățire a mecanismului de provocare optimist ar fi un mecanism de verificare a validității ZK, care ar necesita ca logica de verificare a intenției să fie codificată într-un circuit ZK. În opinia mea, este inevitabil ca mecanismul de dovadă a verificării să înlocuiască mecanismul de provocare optimist și să permită rețelelor de soluționare a intențiilor să ramburseze mai rapid utilizatorii.
Deci, cum apare abstracția lanțului din arhitectura bazată pe intenții?
Amintiți-vă că abstracția în lanț necesită un transfer de valoare încrucișat rapid și ieftin. Nici nu ar trebui să solicite utilizatorilor să trimită tranzacții în lanț în rețeaua în care sunt stocate activele lor.
Dacă este inclusă o semnătură Permis 2 sau EIP 3074, intenția utilizatorului nu trebuie să fie transmisă în lanț de către utilizator. Acest lucru este valabil atât pentru mesagerie, cât și pentru legătura bazată pe intenție. Ambele arhitecturi pot profita de modul Permis 2, permițând utilizatorilor să se semneze offline pe portofelul de lanț original pentru numărul de jetoane pe care sunt dispuși să le plătească.
Piețele bazate pe intenții suportă cel mai bine abstracțiile în lanț, deoarece oferă transfer de valoare încrucișat ieftin și rapid. Imaginați-vă că utilizatorii ar putea solicita unui solutor să le ofere o cotație pentru a introduce o poziție garantată WETH pe Arbitrum folosind USDC-ul lor pe Optimism ca plată. Utilizatorii pot trimite această intenție la o licitație RFQ, iar rezolvatorii pot licita pentru aceasta. Câștigătorul licitației poate primi apoi intenția semnată a utilizatorului, care conține o copie a USDC-ului său care poate fi cheltuit pe Optimism, suma de WETH câștigată pe Arbitrum și datele de apel pentru depunerea acestui WETH într-o poziție de miză Arbitrum. Rezolvatorul poate trimite apoi această tranzacție pe Optimism (în numele utilizatorului) pentru a iniția o intenție cross-chain și pentru a retrage USDC din portofelul Optimism al utilizatorului. În cele din urmă, rezolutorul poate popula intenția utilizatorului prin trimiterea WETH utilizatorului și redirecționarea datelor de apel către poziția de miză în lanț a utilizatorului.
Construirea unei infrastructuri de abstractizare în lanț înseamnă a face ca fluxul de utilizatori să se simtă instantaneu și ieftin, fără a le solicita să trimită tranzacții în lanț. Să încheiem acest articol discutând barierele în calea intențiilor mai largi de adopție.
Pentru a obține cea mai bună experiență de utilizator din abstracții în lanț bazate pe intenții, avem nevoie de o rețea de soluții competitivă
Cheia pentru a obține cea mai bună experiență de utilizator cu abstracții în lanț bazate pe intenții este construirea unei rețele competitive de rezolvatori. Intenția de conectare se bazează pe efectele de rețea ale solutorului pentru a funcționa mai bine decât varianta de mesagerie. Acesta este compromisul de bază între intenție și arhitectura de mesagerie. Realitatea este că nu toate aplicațiile care generează intenții necesită acces la un set de solutoare perfect competitive, iar unii ar putea prefera să își direcționeze intențiile către o rețea de soluții de oligopol. Cu toate acestea, starea actuală a rețelei de soluții este imatură și departe de a atinge nivelul ipotezelor activității rețelei de soluții pe care se bazează piețele de intenție.
Nu dorim ca fiecare DApp să direcționeze intențiile către o rețea izolată de soluții. Cea mai bună situație de experiență a utilizatorului este atunci când multe DApp-uri comunică cu același pool de soluții și toate DApp-urile au libertatea de a schimba grupul de soluții la care își trimit intenția.
Cum să pornești o rețea de rezolvare?
Trebuie să facem din experiența utilizatorului soluției o prioritate de vârf.
Rularea soluției de intenții este complexă și necesită experiență în construirea de software de înaltă performanță și gestionarea riscului de inventar încrucișat. Desigur, vor exista câteva părți interesate să acopere costurile de pornire ale rulării acestui cod. În cel mai bun caz, un solutor scris pentru un DApp, cum ar fi solutorul UniswapX, poate fi reutilizat pentru a rezolva alte DApp-uri care generează intenții, cum ar fi Across și CowSwap.
Trebuie neapărat să îmbunătățim eficiența generală a capitalului rețelelor de soluții în toate aplicațiile DApp bazate pe intenție. Acest lucru va necesita rezolvarea barierelor din calea rulării solutorului.
Pentru a face acest lucru, avem nevoie de DApps care generează intenții să fie vizibile pentru orice rezolvator și să ne asigurăm că toți rezolutorii au acces la mai multe rețele de soluționare a intențiilor diferențiate și competitive. Acest lucru le va oferi solutorilor încredere că pot alege să-și direcționeze îndeplinirea intențiilor către rețelele de decontare în care au încredere. Concurența dintre rețelele de decontare va reduce, de asemenea, costurile de rezolvare.
Propunerea de valoare a Rețelei de soluționare a intențiilor este de a oferi solutorilor securitate și alte caracteristici care pot afecta intențiile de completare a rezolvatorilor.
Alegerea unei rețele de soluționare a intențiilor de către un rezolvator va afecta capacitatea acestora de a oferi utilizatorilor garanții privind taxele și timpul de execuție. Unele rețele de decontare pot oferi perioade de exclusivitate pentru soluționatori, care vor sprijini dezvoltarea licitațiilor în afara lanțului, în care solutorii și utilizatorii pot negocia și se pot angaja să plătească taxe. (În plus, aceste licitații de intenție pot oferi, de asemenea, pre-confirmări garantate financiar, îmbunătățind și mai mult experiența utilizatorului. Pentru a înțelege fluxul utilizatorului de descoperire a intenției prin licitații și pre-confirmări, vă recomand să consultați această discuție a lui Karthik de la Sorella)
Unele rețele de decontare pot oferi expirarea intenției (adică, valoarea este trimisă înapoi utilizatorului după ce este atinsă o anumită perioadă de îndeplinire), suport pentru intenții (adică, rețeaua de decontare își folosește propriul bilanț pentru a îndeplini intenția utilizatorului dacă niciun solutor nu o îndeplinește), sau Lanțuri flexibile de rambursare (adică, permițând rezolvatorilor să aleagă un lanț la alegere pentru rambursare).
În cele din urmă, rețelele de decontare vor concura înverșunat pentru a rambursa solutorii rapid și ieftin, fără a compromite securitatea. La rândul lor, solutorii își vor trimite fluxul de comenzi către rețeaua de decontare care le permite să ofere cele mai ieftine taxe utilizatorilor pentru a câștiga fluxul de comenzi al DApp. Concurența în rețelele de soluționare și soluționare depinde de intenția ca toate părțile din lanțul de aprovizionare să se coordoneze pentru a vorbi aceeași limbă, iar concurența va duce la cea mai bună experiență de utilizare pentru transferul de valoare pe lanțuri.
În mod clar, avem nevoie de un standard de intenție încrucișată
Dacă rezolvatorii pot presupune că intențiile vor împărtăși elemente comune, atunci își pot reutiliza codul pentru a rezolva intențiile inițiate de diferite DApp-uri, reducând astfel costurile de configurare. Dacă DApp-uri diferite creează intenții care îndeplinesc aceleași criterii, toate își pot direcționa intențiile către același pool de soluții. Acest lucru va ajuta să ofere acces la următoarea generație de DApp-uri, permițându-le să-și conecteze direct intențiile încrucișate în pool-ul de soluții maturi existente, fără a fi nevoie să conecteze soluții individual și va avea acces la transferuri ieftine, rapide, sigure și fără permisiuni. valoare.
Software-ul de urmărire terță parte va facilita, de asemenea, urmărirea stării de intenție a oricărui nou DApp dacă standardele sunt îndeplinite.
Acest criteriu de intenție ar trebui să permită subiecților de intenție sau rezolvatorilor să specifice în ce rețea de decontare doresc să își stabilească intențiile.
Îmi imaginez protocoale de soluționare concurente (cum ar fi SUAVE, Across, Anoma și Khalani) care oferă diferite caracteristici pentru rezolvatori. În funcție de rețeaua de decontare care rambursează solutorul, acesta poate oferi diferite garanții de preț și timp proprietarului intenției. DApps și rezolvatorii pot conveni să direcționeze intenția utilizatorului către o rețea de soluționare în care au încredere pentru a evita cenzura, pentru a menține confidențialitatea datelor și, totuși, să fie suficient de siguri pentru ca solutorii să aibă încredere pentru rambursare.
Scriind alegerea rețelei de decontare în ordinea de intenție în sine, rezolvatorii pot construi această certitudine în ofertele pe care le prezintă utilizatorilor. Rezolvatorii și utilizatorii pot reduce costurile eliminând incertitudinea inițială a prețurilor bridge înainte de a transmite intențiile de a intra în lanț.
În colaborare cu Uniswap și pe baza feedback-ului din partea grupului de lucru CAKE, Across și cu mine am propus următoarele standarde de intenții încrucișate care prioritizează experiența utilizatorului soluției.
Acest standard are scopul de a simplifica munca rezolvatorilor. Una dintre alegerile conștiente pe care le-a făcut a fost să accepte Permisul 2/EIP 3074 în mod nativ cu un nonce și să inițieze Termenul limită și să ofere utilizatorilor de formulare câteva garanții cu privire la suma de rambursare pe care o vor primi de la rețeaua de facturare și ce ar putea urmări intenția utilizatorului format. În plus, standardul definește și o funcție de pornire care permite fillerului (persoana care aduce comanda în lanț) să specifice „fillerData” suplimentare pe lanț, pe care utilizatorul nu le cunoaște atunci când semnează datele CrossChainOrder. În acest fel, agenții de completare se pot asigura că sunt recompensați cu contracte de decontare pentru trimiterea meta-tranzacțiilor utilizatorului, precum și să configureze informații specifice rambursării, cum ar fi lanțurile de rambursare.
Acest standard urmărește, de asemenea, să faciliteze pentru DApps urmărirea stării de finalizare a intenției. Orice contract de decontare care implementează acest standard ar trebui să creeze un subtip personalizat de ResolvedCrossChainOrder care poate fi rezolvat din orice câmp orderData. Acestea pot include jetoanele implicate în schimb, lanțul țintă și alte constrângeri de îndeplinire. O funcție de rezolvare este inclusă în standard pentru a permite DApps să înțeleagă cum să afișeze starea intenției pentru utilizator, precum și le permite rezolutorilor să cunoască structura exactă a ordinii de intenții cu care au de-a face.
Scopul de proiectare al acestui standard este să îmbunătățească experiența utilizatorului soluției, facilitându-le să accepte mai multe rețele de decontare și să-și calculeze recompensele în mod determinist. Cred că acest lucru le va permite să ofere citate mai precise și mai compacte utilizatorilor lor. Puteți citi mai multe detalii în această postare și în discuția de pe forumul Ethereum Magicians despre standard, denumit ERC 7683.
Concluzie
Intențiile sunt confuze, deoarece nu sunt definite, iar această lipsă de definiție creează defecte reale în experiența utilizatorului.
Toată lumea vrea ca toți ceilalți să folosească definiția lor standard a intenției, așa că recunosc pe deplin că standardele sunt practic imposibil de stabilit. Cred că mai întâi definirea unui sistem de decontare a intențiilor și apoi încercarea de a atrage fluxul de comenzi este modalitatea corectă de a stabili un standard industrial.
O abordare mai fezabilă, în opinia mea, este că DApp-urile care au deja mult trafic de utilizatori și generează multă intenție de utilizator vor fi de acord să îndeplinească niște standarde minime care vor fi adoptate de solutorii lor existenți. Aceasta va forma un nou grup de soluții mai mare. Prin captarea fluxului de comenzi consolidat din locații deja proeminente, acest nou grup de soluționatori va câștiga mai multe profituri și va putea oferi prețuri mai bune utilizatorilor finali. În cele din urmă, noile DApp-uri vor fi, de asemenea, necesare să își direcționeze intențiile către acest grup de soluții și să-și susțină standardele de intenție.
Pentru a demara acest proces, Across și Uniswap au propus împreună un standard pe care participanții din lanțul de aprovizionare îl folosesc cu toate intențiile atunci când procesează comenzile utilizatorilor pentru a trimite jetoane X din lanțul A și primi jetoane Y pe lanțul B. Fluxurile de comenzi care rulează prin UniswapX (care are un avantaj comparativ în proiectarea licitațiilor și generarea intenției) și Across (care are un avantaj comparativ în îndeplinirea intenției de decontare) pot fi combinate, demarând procesul de cultivare a unei rețele de soluții mai mari și mai competitive.