Jag är här igen för att ELI5 @akileshpotti Här är uppdelningen: (a) Agentregister som ERC-8004 är i bästa fall en Mid Solution: Register onchain är ett effektivt sätt att hantera något så komplext som agentupptäckt och interaktion. Det fungerar helt enkelt inte bra i praktiken. (b) Faktiskt On-Chain-agenter: Om du faktiskt vill ha "trustless AI-agenter" på en blockkedja är det logiska steget att göra AI-modeller och agenter till en central del av själva kedjan – inbyggd i exekverings- och konsensuslagren. På så sätt kan vem som helst i kedjan komma åt dem på ett inbyggt och säkert sätt. @ritualnet redan byggt detta. Ett register ger dig inte detta (och se (c)) (c) Klumpiga on-chain/off-chain-broar fungerar inte: ERC-8004 är en janky patch för att ansluta on-chain och off-chain-system. Vi vet att det inte är optimalt för UX och produkt eftersom vi på @ritualnet byggde exakt den modellen för nästan två år sedan med vårt Infernet-orakel. Det är bara en halv lösning (vilket är anledningen till att vi bestämde oss för att bygga in vår egen infrastruktur) (d) Titta på vem som faktiskt tjänar pengar: De framgångsrika Web2-agentföretagen som @DecagonAI och @cursor_ai använder inte någon kaotisk, öppen marknadsplats. De tjänar pengar genom att antingen (1) köra en kraftfull agent upprepade gånger eller (2) använda en liten, fast uppsättning agenter på ett mycket strukturerat sätt. Drömmen om att "agenter slumpmässigt kommer att upptäcka varandra" är helt enkelt inte hur lönsamma produkter byggs i praktiken (om det är ditt mål) (e) De svåra problemen som ingen annan löser: Att ringa en agent från en blockkedja är enkelt. Den verkliga utmaningen är att bygga upp infrastrukturen för att göra det rätt. Det betyder: - Skalbarhet: Undvika redundant beräkning utan att kompromissa med säkerheten. - Prissättning: Bygga nya avgiftsmarknader anpassade för dessa specifika modeller/agenter - Nytta: Inklusive viktiga funktioner som återkommande transaktioner (tänk cron-jobb på kedjan) som gör agenter genuint användbara Ingen annan L1 har tänkt igenom detta eller byggt infrastrukturen för att lösa alla dessa problem. Bara @ritualnet. (tbh, mycket mer smält den här gången på hans OG inlägg så jag rekommenderar folk att läsa den)
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,45K