私は再びELI5に来ました@akileshpotti 内訳は次のとおりです。 (a) ERC-8004のようなエージェントレジストリは、せいぜい中程度のソリューションです:オンチェーンのレジストリは、エージェントの発見や対話のような複雑なものを処理するには効果のない方法です。実際にはうまくいきません。 (b) 実際にオンチェーン エージェント: ブロックチェーン上に「トラストレスな AI エージェント」を実際に必要とする場合、論理的なステップは、AI モデルとエージェントをチェーン自体の中核部分にし、実行層とコンセンサス層に組み込まれることです。これにより、チェーン上の誰もがネイティブかつ安全にアクセスできます。@ritualnetすでにこれを構築しています。レジストリでは、これは取得されません((c)を参照) (c) 不格好なオンチェーン/オフチェーンブリッジが機能しない: ERC-8004 は、オンチェーン システムとオフチェーン システムを接続するためのジャンキー パッチです。UXと製品にとって最適ではないことはわかっていますが、@ritualnetではほぼ2年前にInfernetオラクルを使用してその正確なモデルを構築しました。それは半分の解決策にすぎません(それが私たちが独自のインフラストラクチャを祀ることにした理由です) (d) 実際に誰がお金を稼いでいるのかを見てください: @DecagonAI や @cursor_ai のような成功した Web2 エージェント企業は、混沌としたオープンな発見マーケットプレイスを使用していません。彼らは、(1)1つの強力なエージェントを繰り返し実行するか、(2)高度に構造化された方法で小規模で固定されたエージェントセットを使用することで収益を上げています。「エージェントがランダムに互いを発見する」という夢は、実際に収益性の高い製品がどのように構築されるかではありません (それがあなたの目標である場合) (e) 誰も解決していない難しい問題: ブロックチェーンからエージェントを呼び出すのは簡単です。本当の課題は、それを正しく行うためのインフラストラクチャを構築することです。ということは: - スケーラビリティ: セキュリティを損なうことなく冗長な計算を回避します。 - 価格: これらの特定のモデル/エージェントに適応した新しい料金市場の構築 - ユーティリティ: エージェントを真に便利にする定期的なトランザクション (オンチェーンの Cron ジョブを考えてください) などの重要な機能が含まれます 他の L1 は、これらすべての問題を解決するためにこれを熟考したり、インフラストラクチャを構築したりしていません。@ritualnetだけです。 (tbh、今回は彼のOGの投稿ではるかに消化しやすいので、読んでみることをお勧めします)
Akilesh Potti
Akilesh Potti8月27日 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.31K