Ik ben hier weer om het eenvoudig uit te leggen @akileshpotti Hier is de uitleg: (a) Agent Registries zoals ERC-8004 zijn op zijn best een tussenoplossing: Registries on-chain zijn een ineffectieve manier om iets zo complex als agentontdekking en interactie te beheren. Het werkt gewoon niet goed in de praktijk. (b) Eigenlijk On-Chain Agents: Als je echt "trustless AI agents" op een blockchain wilt, is de logische stap om AI-modellen en agents een kernonderdeel van de chain zelf te maken—gebouwd in de uitvoerings- en consensuslagen. Dit is hoe iedereen op de chain ze op een native en veilige manier kan benaderen. @ritualnet heeft dit al gebouwd. Een registry levert dit niet (en zie (c)) (c) Haperige On-Chain/Off-Chain Bridges Werken Niet: ERC-8004 is een rommelige patch om on-chain en off-chain systemen te verbinden. We weten dat het suboptimaal is voor UX en product omdat wij bij @ritualnet dat exacte model bijna twee jaar geleden hebben gebouwd met onze Infernet oracle. Het is slechts een halve oplossing (wat de reden is dat we besloten hebben onze eigen infrastructuur te verankeren) (d) Kijk Naar Wie Echt Geld Verdient: De succesvolle Web2 agentbedrijven zoals @DecagonAI en @cursor_ai gebruiken geen chaotische, open-ontdekkingsmarktplaats. Ze verdienen geld door ofwel (1) één krachtige agent herhaaldelijk te laten draaien of (2) een kleine, vaste set agents op een zeer gestructureerde manier te gebruiken. De droom dat "agents elkaar willekeurig zullen ontdekken" is gewoon niet hoe winstgevende producten in de praktijk worden gebouwd (als dat je doel is) (e) De Moeilijke Problemen Die Niemand Anders Oplost: Een agent vanaf een blockchain aanroepen is eenvoudig. De echte uitdaging is het bouwen van de infrastructuur om het goed te doen. Dat betekent: - Schaalbaarheid: Vermijden van redundante berekeningen zonder de veiligheid in gevaar te brengen. - Prijsstelling: Het bouwen van nieuwe vergoedingsmarkten aangepast voor deze specifieke modellen/agents - Nut: Essentiële functies opnemen zoals terugkerende transacties (denk aan on-chain Cron jobs) die agents echt nuttig maken Geen enkele andere L1 heeft dit goed doordacht of de infrastructuur gebouwd om al deze problemen op te lossen. Alleen @ritualnet. (om eerlijk te zijn, veel beter te begrijpen deze keer op zijn OG-post, dus ik raad mensen aan het te lezen)
Akilesh Potti
Akilesh Potti27 aug, 07:19
i am once again here to say agent discovery & registry hell is one of the least impactful things to focus on that for whatever reason keeps nerd sniping cracked ppl...most "mid" solutions for it are good enough and "better" solutions barely move the needle either you: 1) actually take your 'thought experiment' to its sci-fi logical conclusion wrt "autonomous" + "trustless" agents and make them a first class citizen by enshrining the {fdn model, tool use, etc.} components of an agent directly into the chain* (we do this) rather than frankensteining together some off-chain & on-chain stuff as mentioned in 8004 (we did this: infernet) 2) stay grounded in reality & grok how the largest b2b / b2b2c web2 agent startups (sierra, decagon, ...) that are printing real $$$ work. either they're in the camp of single general purpose agent deployed many times or a statically defined computational graph of how specialized agents communicate. this intellectual masturbatory notion of dynamic graphs of agents discovering each other much less useful than you may think if you're in the camp of web2 cos getting real users. if you're not in this camp, and believe in futuristic settings, then you should do 1). anything in between is worst of both worlds imo. *feel free to @ me but your fave L1 today (eth, solana, monad, ...) doesn't allow for enshrined agents. it's also highly non-trivial for them to do this given it's not in line with their fundamental design. expanding the exec clients' vm to handle fwd passes across oss llms, network calls for tool use, etc. is the easy part. hard part is bypassing replicated exec in consensus for non-deterministic behavior w/out ~degrading safety/liveness, fee mech, and how to allow for scheduled txs to exist in a way without borking the perf / end UX for regular txs. wouldn't be possible for us without the gigabrains @noamnisan @n_durvasula @bahrani_maryam and others coming up with some new machinery. reality is most L1s are an exercise in networking-bound settings...we're in an exec-bound one.
12,9K