从 Ethereum 迁移到 Solana：范围、成本驱动因素与证据

从 Ethereum 迁移到 Solana 不是机械移植，也不存在通用重写比例。受影响范围取决于合约行为、状态、资产、钱包、签名、数据管道、集成、治理和运营。应从实际产品出发估算这些工作流。

Wavect 曾支持 Quivr 和其他区块链产品。这些经验为下列问题提供参考，但私人项目不是市场基准，也不能证明另一产品会有相同动机、范围、进度或结果。

应迁移、双链部署还是保留现状？

从产品约束而不是链的热度开始。定义代表性交易、风险价值、延迟与最终性需求、费用敏感度、吞吐量、资产和协议依赖、钱包用户、合规义务、可用性及恢复目标。在相同负载下测量现有系统和候选实现。

至少比较三种方案：改进现有 Ethereum 或 L2 设计、并行部署 Solana 版本，或者迁移并关闭旧路径。双链部署可降低切换风险，但会增加流动性碎片、数据核对、支持、监控、治理和安全工作。应明确列出这些成本。

程序模型为何不同？

Solana 程序通过指令接收显式账户，可变状态则保存在账户中。账户所有权、签名与写权限、程序派生地址、跨程序调用、交易限制和计算预算都会影响设计。官方概览说明了这些当前基础机制 （Solana 核心概念）。

不要把每个 Solidity 入口翻成一条 Rust 或 Anchor 指令就认定完成。应映射不变量、权限、顺序、原子性、并发、账户大小、初始化、关闭、错误行为和拒绝服务边界。部分业务规则可沿用，但实现与威胁模型仍需审查。

迁移清单应包含什么？

资产应如何重构？

应映射每项 ERC 资产的实际行为，而不是假设 ERC-20 等于一种 SPL 设置。Solana 代币设计可涉及铸币账户、代币账户、关联账户、权限和可选 Token Extensions。扩展会增加状态与兼容约束，许多必须在账户或铸币初始化时选择。当前参考资料记录了这些取舍 （Solana Token Extensions）。

决定供应连续性、持有人主张、小数位、元数据、权限转移、冻结、费用、钩子、机密功能、托管、赎回以及旧资产的处置。桥、快照、申领合约、兑换或人工流程各有不同信任与失败假设。针对实际资产和司法辖区寻求法律与税务意见。

钱包和交易体验有何变化？

应按钱包、平台、交易版本、签名能力和用户旅程定义支持范围。测试连接、账户选择、模拟、区块哈希过期、部分签名、费用赞助、优先费、拒绝签名、失败交易、重试与恢复。不要把任务简化为用一个 Solana 钱包替换 MetaMask。

分离用户可见状态与链上提交状态。交易可能已签名、已提交、已上链、失败、过期或需要核对。根据产品风险充分展示费用支付方、资产移动、权限和最终性。

费用如何影响决策？

使用捕获的生产级代表性交易比较费用，不要使用全链平均值。Solana 目前说明每个签名有基础费，并可选择优先费。请求的计算限制、签名、交易失败、账户创建、租金相关余额、RPC 和第三方服务都可能影响总成本。官方费用参考解释了公式和当前机制 （Solana 费用结构）。

记录原生单位及明确时间点的法币换算。纳入失败和重试交易、拥堵、赞助、RPC 与索引费用、资金库操作、桥和运营人员。重新运行负载，不要承诺某条链永远更便宜。

升级权限应如何处理？

盘点谁能部署、升级、暂停、关闭、铸币、冻结、配置或移动资金库资产。根据部署方式，程序权限可以是个人密钥、组织控制账户或其他治理安排。不要把它描述成天然单密钥或自动多签。

定义批准阈值、硬件签名、职责分离、紧急动作、延迟、监控、恢复及适当时走向不可变的路径。测试运营程序，而不只测试程序逻辑。

RPC 与索引应如何划定范围？

列出每条读取路径、订阅、历史查询、事件或日志依赖、分析事件、确认规则和核对任务。按方法支持、新鲜度、保留、完整性、配额、延迟、地区、服务级别、事故记录和退出能力评估供应商或自托管。

按数据语义设计回退。切换 RPC 端点不能保证索引状态或历史完全相同。保留检查点、幂等回填、来源信息、滞后指标和重建派生数据的方法。

估算应如何构成？

未经范围检查，不要引用固定重写比例或工程周数。按假设、依赖、验收证据、置信度和负责人估算工作包：

1. 发现、行为映射、威胁模型和方案决策。
2. 程序与账户设计、实现、测试及部署控制。
3. 资产和用户状态迁移，包括供应量与资金库核对。
4. 钱包、签名、交易、费用和恢复体验。
5. RPC、索引、分析、监控和运营。
6. 交易所、托管方、合作伙伴或协议的集成迁移。
7. 独立安全审查、修复和复测。
8. 演练、发布、共存、回滚、支持和退役。

纳入产品、法律、合规、运营、资金库、沟通和外部供应商。范围应由已发现的未知项驱动，并在证据消除未知后更新。

"链迁移估算盘点的是信任、状态和运营变化，不是给合约代码套用一个百分比。"

哪些证据应作为上线门槛？

• 每条受支持用户旅程的行为与不变量等价性已获接受。
• 状态、资产供应、余额、权限和资金库在演练中核对一致。
• 性能和费用测试覆盖代表性、压力、拥堵和失败情况。
• 钱包、RPC、索引器、集成、监控、恢复和支持路径均已测试。
• 独立审查发现已修复，或由授权负责人明确接受。
• 切换、共存、回滚、用户沟通和旧系统控制均有负责人。

何时不应迁移？

若所述约束可在当前生态中更安全地解决，所需集成不可用，用户和流动性碎片化超过收益，缺少运营责任，或证据未达到验收阈值，就不应迁移。趋势、补助或单独费用比较都不是产品依据。

如果迁移仍合理，可通过我们的区块链工程工作流把清单转成实现与验证计划。独立安全审查方应与实现团队分离。