Solana 中的函数修饰符与 Fallback 函数：为何不存在

Solana 无 Fallback 或 Receive 函数

在 Solidity 中，fallback 和 receive 函数处理未定义操作或直接 ETH 转账。Solana 则不同，其交易需预先声明所有涉及的账户。若引入类似 Fallback 函数，访问未指定的账户会导致交易失败，用户需提前预测账户调用，增加复杂性。因此，Solana 直接禁止此类函数，简化设计。

Solana 无 view 或 pure 函数

Solidity 中的机制

Solidity 的 view 和 pure 函数通过编译器约束状态访问：

• view：禁止状态修改，所有外部调用使用 staticcall（若修改状态则回滚），编译器检测 SSTORE 等操作码时抛错。
• pure：更严格，禁止读取状态（如 SLOAD），仅限纯计算。

Solana 的差异

Anchor 未实现类似编译器检查。Solana 程序的状态访问由 Context 结构定义，未列明的账户无法直接读写，间接提供一定约束。但这并非强制：

• 外部程序可通过独立逻辑读取账户数据并传递结果。
• Solana 运行时无 staticcall 等原生支持。

其他框架如 Seahorse 也未强制此类限制，未来或有框架引入类似声明，但目前依赖开发者自律。

为何 Solana 不需 view 函数

Solana 账户数据对所有程序公开可读，无需程序实现 view 函数授权访问。这与 Solidity 依赖 public 或 view 函数形成对比。

只读重入风险

• Solidity：通过 nonReentrant 修饰符防御只读重入，阻止视图函数被恶意调用。
• Solana：无法阻止数据读取，程序需显式设置标志（如锁定状态），供调用者验证数据可靠性。

示例：银行程序可添加 isLocked 字段，消费程序检查此标志，避免信任被重入篡改的数据。

Rust 无自定义修饰符

Solidity 的 onlyOwner 或 nonReentrant 是宏或修饰符，Rust 未提供类似原生机制。Anchor 依赖 Rust 的函数逻辑实现权限控制，例如通过条件检查替代修饰符。

Rust 与 Anchor 无内置单位

Solidity 集成 Ethereum 单位（如 ether、wei），而 Rust 未定义 LAMPORTS_PER_SOL（1 SOL = 10⁹ Lamports）。意外的是，Anchor 也未封装此常量，仅在 Solana Web3.js 中可用（LAMPORTS_PER_SOL）。

时间单位亦然，Solidity 的 days（86,400 秒）在 Rust/Anchor 中无对应，需手动计算。

Solana 无 payable 函数

Solidity 的 payable 函数接收 ETH，Solana 不支持用户直接向程序转账 SOL。相反，程序通过指令从用户账户转移 SOL，后续文章将详述此机制。

总结

Solana 的设计哲学与 Ethereum 迥异：

• 无 Fallback 函数，因账户需预声明。
• 无 view/pure，因数据公开且无编译器约束。
• 无 payable，转账由程序主动处理。
• Rust 未提供 Solidity 式的修饰符或单位。

【笔记配套代码】 https://github.com/0xE1337/rareskills_evm_to_solana 【参考资料】 https://learnblockchain.cn/column/119 https://www.rareskills.io/solana-tutorial