Solana Signature SDK 是一个以开发人员为中心的工具包，旨在将 Solana 钱包（例如 Phantom、Backpack 和 Solflare）集成到通过 Neon EVM 部署在 Solana 上的与以太坊兼容的 dApp 中。

关键要点

• 统一的用户体验：使用与 Solana 兼容的钱包以及与以太坊兼容的 dApp 进行交易签名。
• 技术创新：通过链上签名验证支持以太坊交易的 Solana 原生 ed25519 签名。
• 简化开发：通过 SDK 快速集成钱包和交易管理，几分钟内即可完成设置和功能。
• 生命周期透明度：从钱包到 Neon EVM 上执行的交易流程的详细概述。
• 高级功能：支持 Solana 程序调用、ERC20-SPL 资产管理和交易调度。

随着 Solana 签名钱包 SDK 的发布，我们朝着实现 Solana 原生集成和简化 Solana 环境中与以太坊兼容 dApp 的用户交互迈出了重要的变革一步，正如我们的白皮书中所强调的那样。

Neon EVM 和钱包集成简介

Solana 签名钱包 SDK 工具包使开发人员能够构建 dApp，使 Solana 用户能够与部署在 Neon EVM 上的智能合约进行交互。与以太坊兼容的 dApp 历来依赖类似以太坊的签名 (secp256k1) 进行交易身份验证。这种依赖关系为 Solana 用户带来了障碍，要求他们使用 MetaMask 等其他工具并进行复杂的流动性转移。Solana 签名钱包 SDK 与 Neon Proxy 一起解决了这个问题。通过匹配 Solana 的 ed25519 签名方案和以太坊的交易要求，此 SDK 简化了钱包集成和跨生态系统的资产可访问性。

从本质上讲，此 SDK 简化了交易管理，如下所示：

1. 在 Solana 钱包内创建 EVM 交易。
2. 通过 Neon EVM 的链上内存池打包并提交交易
3. 通过 Neon Proxy 执行和状态管理
4. Neon 和 Solana 的状态更新。

通过抽象交易转换的复杂性并增强两个网络之间的兼容性，它允许开发人员专注于构建和与去中心化应用程序（dApps）交互，而不必担心底层基础设施障碍。

让我们深入了解细节、技术概述、代币管理流程、优势、局限性和未来前景。

Solana 签名钱包 SDK 详细概述

Neon EVM Solana 签名钱包 SDK 是一种模块化且灵活的解决方案，旨在使开发人员和用户受益。

好处：

对于用户

• 简化的体验：使用现有的 Solana 钱包与与以太坊兼容的 dApp 进行交互。
• 降低复杂性：无需额外的钱包或复杂的流动性转移。

对于开发人员

• 快速集成：通过全面的 SDK 工具简化钱包连接和交易工作流程。
• 生态系统兼容性：构建适合 Solana 和以太坊用户的 dApp，无需额外的开发开销。

Solana 签名验证：功能

Neon EVM Solana 签名钱包 SDK 的一个突出功能是它能够使用 Solana 的 ed25519 签名系统验证 Solana 交易。这一增强功能对于确保通过 Solana 钱包（例如 Phantom、Solflare 和 Backpack）发起的交易在 Neon EVM 网络上准确、安全地处理至关重要。

验证过程在 Neon Proxy 中实时进行，它会在 Neon EVM 上执行任何交易之前检查 Solana 签名的真实性。通过原生验证 Solana 的 ed25519 签名，Neon Proxy 无需手动验证签名或使用中间层。这意味着交易可以安全地处理，延迟最少，确保每笔交易都经过身份验证并正确记录。

这种实时验证机制对于 Solana 钱包用户直接与部署在 Neon EVM 上的与以太坊兼容的 dApp 交互至关重要，而无需单独的身份验证方法或 MetaMask 等附加工具。

对于 SDK，为确保流畅的用户体验，两个关键关注领域包括：

• 通过 Neon Proxy 实现的技术功能；
• 使用 ERC20ForSPL 管理进行资产管理，用于以太坊和 Solana 网络之间的代币转移。

继续阅读，了解 Neon Proxy 如何支持这一点，以及 ERC20ForSPL 合约如何管理 Solana 和以太坊兼容环境之间的代币余额和转移。

Neon Proxy 变更：增强基础设施功能

Neon Proxy 对于促进交互至关重要。它将类似以太坊的交易打包到 Solana 交易中，消除了实现转换逻辑的负担。代理架构的最新更新引入了新功能，优化了交易处理，并确保与现有系统的兼容性，同时整合了 Solana 签名基础设施。

Solana 签名 SDK 的关键代理增强功能

• Solana 签名验证： Neon Proxy 现在可以验证 Solana 的 ed25519 签名，使 Solana 钱包（Phantom、Backpack、Solflare 等）能够直接向 Neon EVM 签名并提交交易。这消除了中间层，简化了流程并确保了安全性。
• 链上内存池集成：借助链上内存池支持，Solana 钱包交易可以在 Neon EVM 生态系统中透明高效地存储、验证和执行。这一改进增强了可扩展性，并消除了对交易调度链下操作的依赖。

为了实现链上内存池，Neon 引入了NeonTxs 树的概念。这将单个大交易拆分为更小、可管理的单元（NeonTxs），同时保持整体逻辑。

工作原理

1. 交易树：
   Neon 合约创建了一个交易“树”，其中较小的单元（分支）可以独立执行。
   每个交易都是原子的，这意味着只有交易成功完成，其变化才会生效。

2. 并行执行：
   独立交易可以并行运行，从而加快进程。

3. 错误处理：
   如果树中的一个交易失败，它不会破坏整个过程。Neon 合约的逻辑可以决定如何处理失败。

4. 最终聚合：
   树中的所有交易完成后，它们的结果将被组合（聚合）成最终交易。

使用 Solana 签名 SDK 的代理工作流

• 交易创建：
  Solana 用户通过使用 Solana Signature SDK 通过他们的原生钱包（Phantom、Backpack、Solflare）对交易进行签名来发起交易。
  交易通过SDK打包成Neon兼容的格式并发送给Neon Proxy。

• 链上调度和映射：
  Neon Proxy 将用户的 Solana 钱包地址映射到与以太坊兼容的地址，确保与 Neon EVM 上基于以太坊的智能合约正确集成。
  该交易在 Neon EVM 内存池中链上调度，等待执行。

• 交易执行：
  Neon Proxy 扫描内存池以查找预定的交易，并使用 Solana 的 ed25519 签名来验证它们。
  该交易在 Neon EVM 上执行，触发智能合约交互并更新 Solana 和 Neon 网络上的状态。

• 执行后清理：
  Neon Proxy 通过清理临时资源来确保高效的系统维护，从而优化未来的交易。

虽然 Neon Proxy 可以作为 Solana 钱包和 Neon EVM 生态系统之间交互的推动者，但要充分发挥市场潜力，需要消除资产管理碎片化。跨网络的统一资产管理是推动采用和更集成的用户体验的关键。

ERC20ForSPL 更新：统一代币管理

SDK 的主要功能是其完善的 ERC20ForSPL 合约逻辑，解决了以太坊和 Solana 之间的互操作性挑战。合约通过使 ERC-20 代币能够在 Solana 环境中运行来连接两个网络。重点是完善 ERC20ForSPL 合约逻辑，以统一余额、保持向后兼容性并为开发人员引入强大的工具。具体方法如下：

统一余额管理

• PDA 和 ATA 集成：Neon EVM 目前使用程序派生地址 (PDA) 来管理余额。随着关联代币账户 (ATA) 使用的实施，合约将整合这两个关键 Solana 组件，以统一的方式管理余额。
• 转账优先级：在转账时，合约优先使用PDA余额，如果PDA余额不够，则使用ATA余额。
• 消除碎片化：这种统一使得代币管理变得更简单、更少碎片化，为用户提供统一的代币管理体验。

这里的传输逻辑很简单：

• 收件人地址验证：在发送代币之前，合约会检查收件人的地址是否与以太坊（EVM）兼容，并确保他们的 ATA（Solana 版本的钱包）已初始化。
• 有条件传输：如果 ATA 已准备就绪，令牌将发送到那里。如果没有，则默认将令牌发送到 PDA。
• 综合余额视图：balanceOf方法现在提供PDA和ATA余额的统一视图，确保准确反映用户的总持有量。

向后兼容性和安全性

虽然 ERC20ForSPL 合约已经更新，但保持向后兼容性（确保现有实现继续不中断地运行）同时添加新功能以增强功能仍然至关重要。
为此，合约通过保留状态变量、方法签名和事件参数来保持与现有实现的兼容性。它在 0xFf000000000000000000000000000000000000000000007 下引入了新的预编译方法，增强了开发人员的能力。isSolanaUser 确定 EVM 地址是否对应于 Solana 帐户，而 solanaAddress 检索与 EVM 地址关联的 Solana 公钥。

构建器预览：使用 SDK 创建的 Neon 交易的生命周期

步骤 1：在前端创建交易

1. 使用 ethers.js、web3.js 或任何其他工具创建 Neon EVM 交易。
2. 使用 Native Wallet SDK 将交易打包成 Solana 交易，通过 Neon Proxy 获取必要的元数据。
3. （可选）：添加 Solana 资产审批说明，以便 Neon EVM 智能合约直接访问。

步骤 2：Solana 钱包签署并提交交易

1. dApp 前端将打包的交易发送到用户的 Solana 钱包。
2. 用户通过其钱包 UI 审查并签署交易。
3. 钱包将签名的交易提交给 Solana 网络，并将其安排在 Neon 的链上内存池中。

步骤 3：Neon Proxy 执行预定交易

1. Neon Proxy 扫描链上内存池并识别准备执行的交易。
2. 在 Neon EVM 上执行交易，从而导致 Neon 和 Solana 上的状态更新。
3. 执行后从内存池中删除交易。

开始使用 SDK

访问存储库：深入研究GitHub上的 Neon Solana Signature SDK 。
开发人员文档：探索全面的文档。
社区开发者支持：加入我们的Discord。查看 Discord 开发频道以获取实时帮助，并寻求我们仅限邀请的 Telegram Builder 聊天访问权限。

原文：https://neonevm.org/blog/unveiling-solana-signature-sdk-enabling-solana-users-to-access-evm-dapps

这是 Solana 的 Hello World 教程。我们将引导您完成安装 Solana 的步骤并解决可能出现的问题。
如果您遇到问题，请查看本文末尾的故障排除部分。

安装步骤

安装 Rust

如果您已经安装了 Rust，请跳过此步骤。

# install rust
curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh

安装 Yarn

您需要它来运行单元测试。如果您已经安装了 yarn，请跳过此步骤。

# install yarn -- assumes node js is installed
corepack enable # corepack comes with node js

安装 Solana cli

我们强烈建议使用stable版本，而不是latest。 Solana 安装不再支持符号通道名称（edge、beta、stable），因此我们必须指定版本。

# install solana
sh -c "$(curl -sSfL https://release.solana.com/v1.16.25/install)"

安装锚点

Anchor 是 Solana 开发的框架。它在很多方面与 hardhat 非常相似。

# install anchor
cargo install --git https://github.com/coral-xyz/anchor avm --locked --force

avm install latest
avm use latest

测试安装

初始化并构建一个锚点程序（用于 hello world）

Mac 用户：我们建议调用您的程序day_1而不是day1因为 Anchor 有时似乎会在 Mac 机器上默默插入下划线。

anchor init day1 # use day_1 if you have a mac
cd day1
anchor build

根据您的机器和互联网连接，此步骤可能需要一段时间。这也是您可能遇到安装问题的地方，因此如有必要，请参阅故障排除部分。

配置 Solana 在本地主机上运行

# shell 1
solana config set --url localhost

运行测试验证器节点

在新的 shell 中（而不是在 Anchor 项目中）运行以下命令。但不要关闭运行的 shell anchor build。这会在您的机器上运行本地（测试）Solana 节点实例：

# shell 2

solana-test-validator

确保 program_id 与 Anchor 键同步

返回 Anchor 项目的 shell 并运行以下命令：

# shell 1

anchor keys sync

运行测试

在 Anchor 项目中运行此命令

# shell 1

anchor test --skip-local-validator

上面的命令运行我们程序的测试。如果您尚未创建测试钱包，Anchor 将为您提供如何创建钱包的说明。我们在此不提供这些说明，因为它取决于您的操作系统和文件结构。您可能还需要通过在终端中运行来为自己空投一些本地 Sol 。您可以通过在命令行中solana airdrop 100 {YOUR_WALLET_ADDRESS}运行来获取您的钱包地址。solana address
预期输出如下：

你好世界

现在让我们让程序输出“Hello, world!”。将以下标有 的行添加NEW LINE HERE到programs/day_1/src/lib.rs。

use anchor_lang::prelude::*;

declare_id!("...");

#[program]
pub mod day_1 {
    use super::*;

    pub fn initialize(ctx: Context<Initialize>) -> Result<()> {
        msg!("Hello, world!"); // **** NEW LINE HERE ****
        Ok(())
    }
}

#[derive(Accounts)]
pub struct Initialize {}

再次运行测试之前，请终止本地验证器进程并使用以下命令重新启动它：

solana-test-validator --reset

再次运行测试

anchor test --skip-local-validator

通过运行查找日志文件

ls .anchor/program-logs/

打开该文件即可看到记录的“Hello world”

实时 Solana 日志

或者，您可以通过打开第三个 shell 并运行以下命令来查看日志：

# shell 3

solana logs

现在再次运行测试，您应该在运行的终端中看到相同的消息solana logs。

问答

为什么 declared_id! 和 msg! 后面有感叹号？

在 Rust 中，感叹号表示这些是宏。我们将在后面的教程中重新讨论宏。

我需要一个初始化函数吗？

不，这是由 Anchor 框架自动生成的。您可以随意命名。

在此上下文中，initialize 这个名称没有什么特殊之处，因此我们可以将其更改为任何我们喜欢的名称。这与其他一些关键字和语言不同，例如 main 在某些语言中是一个特殊名称，或者在 Solidity 中，constructor 是一个特殊名称。
练习：尝试将initialize中的programs/day_1/src/lib.rs和initialize中的重命名为 ，tests/day_1.ts然后initialize2再次运行测试。请参见下面橙色圆圈中标记的更改。

为什么我们要使用 –skip-local-validator 来运行测试？

当测试针对某个节点运行时，我们将能够查询该节点的状态变化。如果您无法让节点运行，则可以anchor test在不使用--skip-local-validator标志的情况下运行。但是，这将使您的开发和测试变得更加困难，因此我们建议让本地验证器正常工作。

故障排除

Solana 是一款快速发展的软件，您可能会遇到安装问题。我们在以下部分记录了您最有可能遇到的问题。
我们的教程系列使用以下版本编写： Anchor = 版本 0.29.0 Solana = 版本 1.16.25 * Rustc = 1.77.0-nightly
您可以通过运行以下命令来更改 Anchor 版本：

avm install 0.29.0
avm use 0.29.0

错误：solana-program v1.18.0无法构建包

error: package `solana-program v1.18.0` cannot be built because it requires rustc 1.72.0 or newer, while the currently active rustc version is 1.68.0-dev
Either upgrade to rustc 1.72.0 or newer, or use
cargo update -p solana-program@1.18.0 --precise ver

检查您正在使用的 Solana 版本solana --version。然后将该版本插入到ver上面的内容中。示例解决方案如下所示：

错误[E0658]：使用不稳定库功能“build_hasher_simple_hash_one”

如果出现以下错误：

error[E0658]: use of unstable library feature 'build_hasher_simple_hash_one'
--> src/random_state.rs:463:5
|
463 | / fn hash_one<T: Hash>(&self, x: T) -> u64 {
464 | | RandomState::hash_one(self, x)
465 | | }
| |_____^
|
= note: see issue #86161 https://github.com/rust-lang/rust/issues/86161 for more information
= help: add #![feature(build_hasher_simple_hash_one)] to the crate attributes to enable

运行以下命令：cargo update -p ahash@0.8.7 --precise 0.8.6。

来源：https ://solana.stackexchange.com/questions/8800/cant-build-hello-world

错误：部署程序失败：错误处理指令 1：自定义程序错误：0x1

Error: Deploying program failed: Error processing Instruction 1: custom program error: 0x1
There was a problem deploying: Output { status: ExitStatus(unix_wait_status(256)), stdout: "", stderr: "" }.

如果出现此错误，则表示您的密钥未同步。运行anchor keys sync。

错误：无法发送交易：交易模拟失败：尝试加载不存在的程序

您的密钥未同步。运行anchor keys sync。

错误：您配置的 rpc 端口：8899 已被使用

当验证器在后台运行时，您anchor test没有运行--skip-local-validator。请关闭验证器并运行，anchor test或在验证器运行时运行anchor test --skip-local-validator。跳过本地验证器意味着跳过它为项目创建的临时验证器，而不是在后台运行的验证器。

错误：帐户 J7t…zjK 资金不足，无法消费

运行以下命令将 100 SOL 空投到您的开发地址：

solana airdrop 100 J7t...zjK

错误：RPC 请求错误：集群版本查询失败

Error: RPC request error: cluster version query failed: error sending request for url (http://localhost:8899/): error trying to connect: tcp connect error: Connection refused (os error 61)
There was a problem deploying: Output { status: ExitStatus(unix_wait_status(256)), stdout: "", stderr: "" }.

这意味着solana-test-validator不在后台运行。solana-test-validator在另一个 shell 中运行。

线程“main”因“调用Option::unwrap()某个None值”而惊慌失措

thread 'main' panicked at 'called `Option::unwrap()` on a `None` value', /Users/username/.cargo/git/checkouts/anchor-50c4b9c8b5e0501f/347c225/lang/syn/src/idl/file.rs:214:73
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

你可能还没跑anchor build。

我在使用 Mac，出现错误：无法启动验证器：无法在测试分类账中创建分类账：块存储错误

按照此Stack Exchange 线程中的说明进行操作。

我的 Mac 上有 node.js，但是没有 corepack

运行以下命令：

brew install corepack
brew link --overwrite corepack

来源：https ://stackoverflow.com/questions/70082424/command-not-found-corepack-when-installing-yarn-on-node-v17-0-1

错误：不是目录：

BPF SDK: /Users/rareskills/.local/share/solana/install/releases/stable-43daa37937907c10099e30af10a5a0b43e2dd2fe/solana-release/bin/sdk/bpf
cargo-build-bpf child: rustup toolchain list -v
cargo-build-bpf child: rustup toolchain link bpf /Users/rareskills/.local/share/solana/install/releases/stable-43daa37937907c10099e30af10a5a0b43e2dd2fe/solana-release/bin/sdk/bpf/dependencies/bpf-tools/rust
error: not a directory:

清除缓存：运行rm -rf ~/.cache/solana/*。

错误：target/idl/day_1.json 不存在。您运行了吗anchor build？

创建一个新项目并将其命名为 day_1 而不是 day1。Anchor 似乎会在某些机器上默默插入下划线。

原文：https://www.rareskills.io/post/hello-world-solana

在 Solidity 中，msg.sender是一个全局变量，表示调用或发起智能合约函数调用的地址。全局变量tx.origin是签署交易的钱包。
在 Solana 中，没有与 等效的东西msg.sender。
有一个等效的tx.origin，但是你应该知道 Solana 交易可以有多个签名者，所以我们可以将其视为具有“多个 tx.origins”。
要在 Solana 中获取“ tx.origin”地址，需要通过将 Signer 帐户添加到函数上下文来设置它，并在调用函数时将调用者的帐户传递给它。
让我们看一个如何在 Solana 中访问交易签名者地址的示例：

use anchor_lang::prelude::*;

declare_id!("Hf96fZsgq9R6Y1AHfyGbhi9EAmaQw2oks8NqakS6XVt1");

#[program]
pub mod day14 {
    use super::*;

    pub fn initialize(ctx: Context<Initialize>) -> Result<()> {
        let the_signer1: &mut Signer = &mut ctx.accounts.signer1;

        // Function logic....

        msg!("The signer1: {:?}", *the_signer1.key);

        Ok(())
    }
}

#[derive(Accounts)]
pub struct Initialize<'info> {
    #[account(mut)]
    pub signer1: Signer<'info>,
}

从上面的代码片段来看，Signer<'info>用于验证账户结构signer1中的账户Initialize<'info>是否签署了交易。
在initialize函数中，signer1帐户从上下文中可变地引用并分配给the_signer1变量。
最后，我们使用宏并传入来记录signer1的公钥（地址），它取消引用并访问指向的实际值上的字段或方法。msg!*the_signer1.keykeythe_signer1

接下来就是针对上面的程序编写测试：

describe("Day14", () => {
  // Configure the client to use the local cluster.
  anchor.setProvider(anchor.AnchorProvider.env());

  const program = anchor.workspace.Day14 as Program<Day14>;

  it("Is signed by a single signer", async () => {
    // Add your test here.
    const tx = await program.methods.initialize().accounts({
      signer1: program.provider.publicKey
    }).rpc();

    console.log("The signer1: ", program.provider.publicKey.toBase58());
  });
});

测试中，我们将钱包账户作为 signer 传入账户signer1，然后调用初始化函数，最后在控制台上打印钱包账户，验证和程序中的一致。
练习：运行测试后，你从shell_1（命令终端）和shell_3 （日志终端）的输出中注意到了什么？

多名签名者

在 Solana 中，我们还可以让多个签名者签署一笔交易，你可以将其视为批量处理一堆签名并将其发送至一笔交易中。一个用例是在一笔交易中执行多重签名交易。
为此，我们只需在程序中的帐户结构中添加更多签名者结构，然后确保在调用函数时传递必要的帐户：

use anchor_lang::prelude::*;

declare_id!("Hf96fZsgq9R6Y1AHfyGbhi9EAmaQw2oks8NqakS6XVt1");

#[program]
pub mod day14 {
    use super::*;

    pub fn initialize(ctx: Context<Initialize>) -> Result<()> {
        let the_signer1: &mut Signer = &mut ctx.accounts.signer1;
        let the_signer2: &mut Signer = &mut ctx.accounts.signer2;

        msg!("The signer1: {:?}", *the_signer1.key);
        msg!("The signer2: {:?}", *the_signer2.key);

        Ok(())
    }
}

#[derive(Accounts)]
pub struct Initialize<'info> {
    pub signer1: Signer<'info>,
    pub signer2: Signer<'info>,
}

上述示例与单个签名者示例有些相似，但有一个明显的区别。在本例中，我们signer2在结构中添加了另一个签名者帐户（）Initialize，并在初始化函数中记录了两个签名者的公钥。

与单个签名者相比，使用多个签名者调用初始化函数有所不同。以下测试显示了如何使用多个签名者调用函数：

describe("Day14", () => {
  // Configure the client to use the local cluster.
  anchor.setProvider(anchor.AnchorProvider.env());

  const program = anchor.workspace.Day14 as Program<Day14>;

  // generate a signer to call our function
  let myKeypair = anchor.web3.Keypair.generate();

  it("Is signed by multiple signers", async () => {
    // Add your test here.
    const tx = await program.methods
      .initialize()
      .accounts({
        signer1: program.provider.publicKey,
        signer2: myKeypair.publicKey,
      })
      .signers([myKeypair])
      .rpc();

    console.log("The signer1: ", program.provider.publicKey.toBase58());
    console.log("The signer2: ", myKeypair.publicKey.toBase58());
  });
});

那么上述测试有什么不同？首先是signers()方法，它接受一个签名者数组，这些签名者将对交易进行签名作为参数。但是数组中只有一个签名者，而不是两个。Anchor 会自动将提供商中的钱包账户作为签名者传递，因此我们不需要再次将其添加到签名者数组中。

生成随机地址进行测试

第二个变化是变量，它存储模块随机生成的myKeypair密钥对（用于访问帐户的公钥和相应的私钥anchor.web3） 。在测试中，我们将密钥对（存储在myKeypair变量中）的公钥分配给signer2帐户，这就是为什么它作为参数传递到.signers([myKeypair])方法中的原因。

多次运行测试，你会注意到signer1pubkey 没有改变，但signer2pubkey 发生了变化。这是因为分配给该signer1账户的钱包账户（在测试中）来自提供商，这也是你本地机器中的 Solana 钱包账户，并且分配给的账户signer2是每次运行时随机生成的anchor test —skip-local-validator。

练习：创建另一个需要三个签名者（提供者钱包账户和两个随机生成的账户）的函数（您可以随意称呼它），并为其编写测试。

唯一所有者

这是 Solidity 中常用的模式，用于将函数的访问权限限制为合约所有者。使用#[access_control]Anchor 中的属性，我们还可以实现唯一所有者模式，即将 Solana 程序中函数的访问权限限制为 PubKey（所有者的地址）。

以下是如何在 Solana 中实现“onlyOwner”功能的示例：

use anchor_lang::prelude::*;

declare_id!("Hf96fZsgq9R6Y1AHfyGbhi9EAmaQw2oks8NqakS6XVt1");

// NOTE: Replace with your wallet's public key
const OWNER: &str = "8os8PKYmeVjU1mmwHZZNTEv5hpBXi5VvEKGzykduZAik";

#[program]
pub mod day14 {
    use super::*;

    #[access_control(check(&ctx))]
    pub fn initialize(ctx: Context<OnlyOwner>) -> Result<()> {
        // Function logic...

        msg!("Holla, I'm the owner.");
        Ok(())
    }
}

fn check(ctx: &Context<OnlyOwner>) -> Result<()> {
    // Check if signer === owner
    require_keys_eq!(
        ctx.accounts.signer_account.key(),
        OWNER.parse::<Pubkey>().unwrap(),
        OnlyOwnerError::NotOwner
    );

    Ok(())
}

#[derive(Accounts)]
pub struct OnlyOwner<'info> {
    signer_account: Signer<'info>,
}

// An enum for custom error codes
#[error_code]
pub enum OnlyOwnerError {
    #[msg("Only owner can call this function!")]
    NotOwner,
}

在上述代码的上下文中，OWNER变量存储与我的本地 Solana 钱包关联的公钥（地址）。在测试之前，请务必将 OWNER 变量替换为您的钱包的公钥。您可以通过运行solana address命令轻松检索您的公钥。

该#[access_control]属性在运行主指令之前执行给定的访问控制方法。调用初始化函数时，访问控制方法 ( check) 先于初始化函数执行。该check方法接受引用的上下文作为参数，然后检查交易的签名者是否等于OWNER变量的值。require_keys_eq!宏确保两个公钥值相等，如果相等，则执行初始化函数，否则，将使用自定义错误进行恢复NotOwner。

测试 onlyOwner 功能 — 令人满意的情况

在下面的测试中，我们调用初始化函数并使用所有者的密钥对签署交易：

import * as anchor from "@coral-xyz/anchor";
import { Program } from "@coral-xyz/anchor";
import { Day14 } from "../target/types/day14";

describe("day14", () => {
  // Configure the client to use the local cluster.
  anchor.setProvider(anchor.AnchorProvider.env());

  const program = anchor.workspace.Day14 as Program<Day14>;

  it("Is called by the owner", async () => {
    // Add your test here.
    const tx = await program.methods
      .initialize()
      .accounts({
        signerAccount: program.provider.publicKey,
      })
      .rpc();

    console.log("Transaction hash:", tx);
  });
});

我们调用了初始化函数，并将提供程序中的钱包账户（本地 Solana 钱包账户signerAccount）传递给具有结构体的Signer<'info>，以验证钱包账户是否确实签署了交易。 另请记住，Anchor 使用提供程序中的钱包账户秘密签署任何交易。

运行测试anchor test --skip-local-validator，如果一切正确完成，测试应该通过：

测试签名者是否不是所有者——攻击案例

使用非所有者的其他密钥对来调用初始化函数并签署交易将引发错误，因为函数调用仅限于所有者：

describe("day14", () => {
  // Configure the client to use the local cluster.
  anchor.setProvider(anchor.AnchorProvider.env());

  const program = anchor.workspace.Day14 as Program<Day14>;

  let Keypair = anchor.web3.Keypair.generate();

  it("Is NOT called by the owner", async () => {
    // Add your test here.
    const tx = await program.methods
      .initialize()
      .accounts({
        signerAccount: Keypair.publicKey,
      })
      .signers([Keypair])
      .rpc();

    console.log("Transaction hash:", tx);
  });
});

这里我们生成了一个随机密钥对并用它来签署交易。让我们再次运行测试：

正如预期的那样，我们得到了一个错误，因为签名者的公钥不等于所有者的公钥。

修改所有者

要在程序中更改所有者，需要将分配给所有者的公钥存储在链上。不过，有关 Solana 中“存储”的讨论将在未来的教程中介绍。

所有者可以重新部署字节码。

练习：升级类似上述程序，以获得新的所有者。

英文原文：https://www.rareskills.io/post/msg-sender-solana