Web2 到 Web3：前端数据流的变化

30 秒回答

典型非托管 DApp 的读路径会组合 RPC、索引服务与自家后端，写路径由用户钱包授权或签名后提交。连接得到地址并不等于登录；需要服务端验证签名挑战才能建立会话。资产记录在链上，由账户密钥或合约规则控制，钱包负责管理密钥与发起操作，并不把资产保存在钱包里。实现差异与工程取舍见深入回答。

深入回答

• 【协议保证】页面通过 provider 的 request 方法与钱包交互，密钥管理与签名在钱包侧完成；provider 运行在不受信任的页面环境中，不应被当作安全边界（依据：EIP-1193 §Security Considerations）。
• 【协议保证】EIP-1193 定义了 4100 Unauthorized 错误码，但是否实施授权逻辑取决于钱包；规范建议默认不暴露账户，并通过请求方法获取访问权限，不能把所有钱包的逐次授权行为当作协议保证（依据：EIP-1193 §request、§User Account Exposure and Account Changes）。
• 【工程经验】读路径从单一后端接口扩展为链上状态、RPC 与索引服务的组合，前端需要为每种数据源定义失败与降级策略（依据：ethereum.org dApps 页面；工程经验）。
• 【工程经验】链上读到的数据受节点可用性与索引延迟影响，关键数值适合标注来源与更新时间（依据：ethereum.org dApps 页面；工程经验）。
• 【工程经验】写路径由用户钱包签名并广播交易，应用侧负责组织参数、等待结果与对账（依据：ethereum.org dApps 页面；ethereum.org Web2 vs Web3 页面）。
• 【工程经验】若产品选择钱包登录，连接只提供地址；服务端仍需验证带域名与 nonce 的签名挑战，并建立自己的会话。其他登录方式也可以与钱包并存（依据：EIP-4361 §Specification；工程经验）。
• 【工程经验】资产状态在链上，非托管钱包管理密钥与签名；应用通过用户授予的权限发起操作，因此授权范围与撤销路径需要清楚呈现（依据：ethereum.org Web2 vs Web3 页面；工程经验）。
• 【工程经验】后端仍然可以承担缓存、聚合、通知与法币计价等职责，但需要把链上结论与后端加工结果分开标注（依据：ethereum.org dApps 页面；工程经验）。
• 【工程经验】写路径的状态需要区分「已提交」「已包含」「已确认」三个阶段再展示（依据：工程经验，无规范依据）。
• 【工程经验】不要把连接状态当作登录态，服务端会话需要独立建立与失效（依据：ethereum.org Web2 vs Web3 页面；工程经验）。

常见错误

• 把链上读取当成普通 GET 请求处理，忽略节点可用性与最终性。
• 把连接钱包当作登录，把地址当作已认证身份。
• 写路径没有区分提交、打包与确认三个阶段。
• 对授权只做一次展示，没有提供查看与撤销入口。
• 后端把链上结论与自行加工的数据混在一起返回。

面试官追问

1. 用户切换账户后，服务端会话应该如何处理？
2. 链上读取失败与后端接口失败，用户看到的提示应该如何区分？
3. 后端缓存与链上状态出现差异时，你会如何定位与收敛？
4. 引入签名挑战登录后，如何避免重复签名与重放？

评分标准

初级回答

• 能说出读路径从自家后端扩展到链上状态与 RPC。
• 知道写路径需要用户钱包签名。

中级回答

• 能说明身份与资产归属的变化，并解释连接与登录的差异。
• 能给出读路径的失败与降级处理。

高级回答

• 能设计读写路径、身份与会话的整体架构，覆盖最终性、授权撤销与后端边界。
• 能说明链上数据与后端加工数据的分层标注与对账方式。

参考资料

• EIP-1193：Ethereum Provider JavaScript API（§Security Considerations、§Provider Errors）
• ethereum.org：Introduction to dapps（页面级）
• ethereum.org：Web2 vs Web3（页面级）
• EIP-4361：Sign-In with Ethereum（§Specification）