我不确定谁批准了在 Sui 中从 JSON-RPC 迁移到 gRPC 的更改，以及相关的 SDK 更改，但这绝对不是在版本发布中迁移事物的正确方式。 Mysten/Sui、Mysten/Dapp 和 Mysten/Kiosk 的新版本更改了许多接口，我老实说不太理解，而且它们迫使你更新大量代码。 有趣的是，Mysten/Kiosk 仍然告诉你使用 JSON-RPC 或 GraphQL，因为 gRPC 不支持它。 这是一项巨大的工作。 想象一下 Ika 拥有许多不同的网站和应用，我根本无法相信 Claude 会正确修复所有内容。 为什么不提供一个用于此迁移的 codemod？ 而且，为什么要第二次弃用一个已经有效的工具包？

如果您在使用 Next.js 和 Web3，这是坚持使用页面路由器（仅限客户端）而不是应用路由器（RSC + SSR）的原因之一。 更重要的是，如果您正在处理私钥，请不要使用托管设置（@ThePumpkinToken）。如果您想在用户的钱包上构建，请使用 Ika 导入的密钥 + 智能合约策略。 确保用户共享始终保留在浏览器中（例如，Vite 应用或 Next.js 页面路由器应用）。对于 Web3 应用，避免使用应用路由器和 RSC。CSR 对于良好的 Web3 应用来说已经足够了。

短暂密钥。 使用 Solana 钱包，您可以签署消息并从该签名生成加密密钥。然后，您使用这些密钥创建 dWallet。 这使得 Solana 钱包安全地保护用户在 dWallet 中的份额，并且可以随时与之交互。 这解决了用户入门的问题。您消除了他们在其他链上创建新钱包的需要。他们现有的 Solana 钱包成为 Sui（或任何链）dWallet 的控制者。用户甚至不需要知道他们正在使用 Sui（或任何链）。一切都被抽象化了。 您可以更进一步。您的应用可以使用盐、电子邮件和密码生成短暂密钥。这为您提供了完整的账户抽象。您甚至不需要钱包。应用可以安全地动态派生密钥，并通过 dWallet 管理一切。