anchor build时报以下错误

info: uninstalling toolchain 'solana'
info: toolchain 'solana' uninstalled
error: rustc 1.79.0-dev is not supported by the following package:

                 Note that this is the rustc version that ships with Solana tools and not your system's rustc version. Use `solana-install update` or head over to https://docs.solanalabs.com/cli/install to install a newer version.
  bytemuck_derive@1.9.2 requires rustc 1.84
Either upgrade rustc or select compatible dependency versions with
`cargo update <name>@<current-ver> --precise <compatible-ver>`
where `<compatible-ver>` is the latest version supporting rustc 1.79.0-dev

执行以下命令

cargo update -p bytemuck_derive --precise 1.7.0

十分钟开始使用多签工具SQUADS

关于squads

Squads是Solana区块链上领先的多重签名(multisig)解决方案，已经为超过100亿美元的资产提供安全保障。它提供直观的用户界面和完善的安全机制，让团队能够安全地管理数字资产、程序升级权限和验证者节点。作为一个去中心化的自托管工具，Squads支持多种功能，包括资金库管理、代币发行、NFT操作以及与Solana生态系统中其他DeFi应用的集成。其核心特点是要求多方签名才能执行交易，大大提升了资产安全性，特别适合DAO组织和Web3项目团队使用。

什么是多重签名(multisig)

多重签名(Multisig)是一种数字资产安全管理机制，要求多个预设的密钥持有者共同授权才能执行某项操作。与传统的单一签名不同，多重签名通常设置为"M-of-N"模式，即在N个授权者中需要至少M个授权者同意才能完成交易。例如，在3-of-5的多重签名设置中，需要5个授权者中的至少3个同意才能执行交易。这种机制有效防止了单点故障，即使某个密钥丢失或被盗，资产仍然是安全的。

快速开始

接下来我们会有一个简单的教程展示如何使用Typescript在测试网上与SQUADS 协议交互。

首先，创建目录和文件结构：

mkdir squads_quickstart
cd squads_quickstart

1. 创建 tsconfig.json:

{
  "compilerOptions": {
    "module": "commonjs",
    "target": "es6",
    "esModuleInterop": true
  }
}

1. 创建 package.json:

{
  "scripts": {
    "test": "npx mocha -r ts-node/register 'main.ts' --timeout 10000"
  },
  "dependencies": {
    "@solana/web3.js": "^1.73.0",
    "@sqds/multisig": "^2.1.3"
  },
  "devDependencies": {
    "@types/chai": "^4.3.3",
    "@types/mocha": "^10.0.6",
    "chai": "^4.3.6",
    "mocha": "^10.3.0",
    "ts-mocha": "^10.0.0",
    "typescript": "^4.8.3"
  }
}

1. 创建main.ts 本文将会带领读者创建一个脚本逐步进行如下几步，创建多签，提出一个新的转账，进行投票并且执行。 首先， 设置多签成员并且创建地址

describe("Interacting with the Squads V4 SDK", () => {
  const creator = Keypair.generate();
  const secondMember = Keypair.generate();
  before(async () => {
    const airdropSignature = await connection.requestAirdrop(
      creator.publicKey,
      1 * LAMPORTS_PER_SOL
    );
    await connection.confirmTransaction(airdropSignature);
  });

  const createKey = Keypair.generate();

  // 从多签账户中派生PDA
  const [multisigPda] = multisig.getMultisigPda({
    createKey: createKey.publicKey,
  });

  it("Create a new multisig", async () => {
    const programConfigPda = multisig.getProgramConfigPda({})[0];

    console.log("Program Config PDA: ", programConfigPda.toBase58());

    const programConfig =
      await multisig.accounts.ProgramConfig.fromAccountAddress(
        connection,
        programConfigPda
      );

    const configTreasury = programConfig.treasury;

    // 生成多签
    const signature = await multisig.rpc.multisigCreateV2({
      connection,
      //一次性密钥
      createKey,
      // 创建者和费用支付这
      creator,
      multisigPda,
      configAuthority: null,
      timeLock: 0,
      members: [
        {
          key: creator.publicKey,
          permissions: Permissions.all(),
        },
        {
          key: secondMember.publicKey,
          // 这里的权限代表用户只可以投票
          permissions: Permissions.fromPermissions([Permission.Vote]),
        },
      ],
      // 这里代表至少需要两票才可以使提案通过
      threshold: 2,
      rentCollector: null,
      treasury: configTreasury,
      sendOptions: { skipPreflight: true },
    });
    await connection.confirmTransaction(signature);
    console.log("Multisig created: ", signature);
  });

生成转账提案

现在，我们可以进行转账提案的生成。 我们希望这个多签账户向生成者发送0.1 SOL。

  it("Create a transaction proposal", async () => {
    const [vaultPda] = multisig.getVaultPda({
      multisigPda,
      index: 0,
    });
    const instruction = SystemProgram.transfer({
      // 转账是从Squads金库签名的，这就是为什么我们使用VaultPda
      fromPubkey: vaultPda,
      toPubkey: creator.publicKey,
      lamports: 1 * LAMPORTS_PER_SOL,
    });
    // 这个消息包含了交易将要执行的指令
    const transferMessage = new TransactionMessage({
      payerKey: vaultPda,
      recentBlockhash: (await connection.getLatestBlockhash()).blockhash,
      instructions: [instruction],
    });

    // 获取当前多签交易索引
    const multisigInfo = await multisig.accounts.Multisig.fromAccountAddress(
      connection,
      multisigPda
    );

    const currentTransactionIndex = Number(multisigInfo.transactionIndex);

    const newTransactionIndex = BigInt(currentTransactionIndex + 1);

    const signature1 = await multisig.rpc.vaultTransactionCreate({
      connection,
      feePayer: creator,
      multisigPda,
      transactionIndex: newTransactionIndex,
      creator: creator.publicKey,
      vaultIndex: 0,
      ephemeralSigners: 0,
      transactionMessage: transferMessage,
      memo: "Transfer 0.1 SOL to creator",
    });

    await connection.confirmTransaction(signature1);

    console.log("Transaction created: ", signature1);

    const signature2 = await multisig.rpc.proposalCreate({
      connection,
      feePayer: creator,
      multisigPda,
      transactionIndex: newTransactionIndex,
      creator,
    });

    await connection.confirmTransaction(signature2);

    console.log("Transaction proposal created: ", signature2);
  });

向提案投票，这里我们使用教程开始部分生成的两个密钥

  it("Vote on the created proposal", async () => {
    // 获取当前多签账户的交易索引
    const transactionIndex =
      await multisig.accounts.Multisig.fromAccountAddress(
        connection,
        multisigPda
      ).then((info) => Number(info.transactionIndex));

    // 第一个成员（创建者）对提案进行投票
    const signature1 = await multisig.rpc.proposalApprove({
      connection,
      feePayer: creator,      // 交易费用支付者
      multisigPda,            // 多签账户地址
      transactionIndex: BigInt(transactionIndex),  // 交易索引
      member: creator,        // 投票成员
    });

    // 等待第一个投票交易确认
    await connection.confirmTransaction(signature1);

    // 第二个成员对提案进行投票
    const signature2 = await multisig.rpc.proposalApprove({
      connection,
      feePayer: creator,      // 交易费用仍由创建者支付
      multisigPda,            // 多签账户地址
      transactionIndex: BigInt(transactionIndex),  // 交易索引
      member: secondMember,   // 第二个投票成员
    });

    // 等待第二个投票交易确认
    await connection.confirmTransaction(signature2);
  });

执行交易

  it("Execute the proposal", async () => {
    const transactionIndex =
      await multisig.accounts.Multisig.fromAccountAddress(
        connection,
        multisigPda
      ).then((info) => Number(info.transactionIndex));

    const [proposalPda] = multisig.getProposalPda({
      multisigPda,
      transactionIndex: BigInt(transactionIndex),
    });
    const signature = await multisig.rpc.vaultTransactionExecute({
      connection,
      feePayer: creator,
      multisigPda,
      transactionIndex: BigInt(transactionIndex),
      member: creator.publicKey,
      signers: [creator],
      sendOptions: { skipPreflight: true },
    });

    await connection.confirmTransaction(signature);
    console.log("Transaction executed: ", signature);
  });

});

最后，使用

yarn test

来执行脚本

好了,现在脚本已经执行完成，复制地址可以在solana explorer中查看。

完整代码可以参考 https://github.com/kimmy1886/squads_quickstart

本文介绍了EVM开发者如何转向Solana平台，包括Solana的架构、技术优势、开发工具及账户模型的不同，强调程序的无状态特性以及数据存储的外部化。同时，文章比较了Ethereum和Solana的交易处理模型、费用机制及开发工具，帮助开发者顺利过渡。

概述

以太坊虚拟机（EVM）多年来一直是去中心化应用（dApp）开发的基础，但 Solana 的创新架构提供了诸如高吞吐量、低延迟和成本效率等独特优势。本指南旨在为希望在 Solana 上构建应用的 EVM 开发者设计。通过利用你对以太坊和 EVM 的现有知识，本指南将帮助你理解 Solana 的关键概念、工具和工作流程。

在本指南结束时，你将对 Solana 的架构有一个清晰的理解，并了解其与以太坊的不同之处。你将学习账户、执行模型和交易处理等关键概念如何与 EVM 进行比较，帮助你将开发思维从基于 Solidity 的智能合约转变为 Solana 的无状态 Rust 程序。

你将做什么

• 理解 EVM 和 SVM 之间的关键差异，包括执行模型、账户结构和费用机制
• 学习在 Solana 上如何存储和访问数据，与以太坊的存储模型进行比较
• 探索两个网络的交易处理模型，以理解执行效率
• 将你的思维方式从基于 Solidity 的智能合约开发转向基于 Rust 的 Solana 程序及其基于账户的架构

你需要什么

• 以太坊智能合约开发（Solidity、Hardhat、Foundry）经验
• 基本 EVM 概念（交易、存储、gas 费用、合约执行）的知识

不需要有 Rust 或 Solana 的先前经验。我们将以适合以太坊开发者的方式解释关键差异。

为什么选择 Solana？

作为以太坊开发者，探索 Solana 提供了独特的机会，得益于其技术优势和相当明显的生态系统增长。

技术优势

• 高吞吐量的并行执行：Solana 利用 Sealevel，一个并行执行引擎，允许多个交易同时处理，而不是以太坊的顺序执行模型。这使得在没有网络拥堵的情况下实现更高的吞吐量。
• 无状态程序：与以太坊智能合约不同，后者存储自己的状态，Solana 程序是无状态的，并通过外部账户进行数据存储。这种代码和状态的分离提高了效率并减少了链上存储成本。
• 单体设计：与以太坊的模块化路线图不同，Solana 旨在原生扩展，无需依赖 rollup 或分片。这意味着更简单的开发、更少的跨链复杂性、没有流动性分散，更好的用户体验。
• 成本效率：Solana 的 Layer 1 架构被设计为低交易费用，为开发者和用户提供了经济可行的环境，而无需依赖附加的扩展解决方案。

生态系统增长与开发者机会

• 链 GDP 增长：在 2024 年第四季度，Solana 的总应用收入（称为链 GDP）环比增长 213%，从 2.68 亿美元增长到 8.4 亿美元。值得注意的是，仅 11 月，当月的应用收入就达到了 3.67 亿美元。
• DeFi 总锁定价值（TVL）：在 2024 年第四季度末，Solana 成为第二大 DeFi TVL 区块链，达到 86 亿美元，标志着环比增长 213%。
• 去中心化交易所（DEX）主导地位：Raydium 作为 Solana 的一家领先 DEX，在 2024 年第四季度的平均日交易量达 32 亿美元，较去年大幅增长。Raydium 在全球 DEX 交易量的份额也环比上升超过 66%，使其成为按交易量计算的第二大 DEX，仅次于 Uniswap。
• 流动性质押增长：Solana 的流动性质押率环比上升 33%，达到了 11.2%。作为一家领先的流动性质押提供商，Sanctum 现在支持超过 100 种流动性质押 Token（LST）。

网络的技术能力，加上不断扩展的生态系统，使其成为开发者的一个吸引人选择。通过学习如何在 Solana 上构建应用，你可以利用这些机会并为网络的增长做出贡献。

如需详细分析，请参考 Messari 的 State of Solana Q4 2024 报告。

以太坊与 Solana 之间的关键架构差异

在开始之前，熟悉以太坊和 Solana 的术语差异至关重要。

以太坊与 Solana：术语对比表

以太坊 (EVM)	Solana (SVM)	描述
智能合约	程序	在以太坊中，智能合约存储逻辑和状态。在 Solana 中，程序是包含可执行代码但无状态的账户，数据存储在单独的账户中。
Wei	Lamports	在以太坊中，wei是ETH的最小单位，其中1 ETH = 10¹⁸ wei。在 Solana 中，lamports是SOL的最小单位，其中1 SOL = 1,000,000,000 lamports。
Gas	计算单位	在以太坊中，Gas 测量交易所需的计算工作量，其中费用 = gas 使用量 ×（基础 + 优先级）。在 Solana 中，计算单位（CUs）充当类似角色，其中费用 = 固定基数（每签名）+（CU × CU 价格）。
ABI	IDL（接口描述语言）	在以太坊中，ABI（应用程序二进制接口）定义了合约与外部应用的交互方式。在 Solana 中，IDL（接口描述语言）具有相同的目的，定义程序如何为客户端交互暴露函数。
代理合约	程序	在以太坊中，代理合约用于启用智能合约更新。在 Solana 中，程序是默认可升级的。
Nonce	区块哈希 / 持久性 Nonce	以太坊交易使用逐增的每账户 nonce来防止重放攻击。Solana 主要使用最近的区块哈希进行交易验证，但也支持 Durable Nonces 用于离线签名和更长的交易有效期。
交易	指令	在以太坊中，交易通常调用单个合约函数，即使涉及复杂的合约逻辑。在 Solana 中，交易由一个或多个指令组成，每个指令调用一个程序以执行特定操作。
ERC20 Token	SPL Token	在以太坊中，ERC-20 Token 是为每个 Token 部署的单独智能合约。在 Solana 中，SPL Token 通过一个共享的 Token 程序进行管理，消除了为每个 Token 部署单独合约的需求。

如果这些概念仍有些不清晰，别担心。我们将在本指南后续部分对其进行更详细的覆盖。

账户模型：有状态与无状态

在以太坊中，智能合约存储自己的状态，这意味着存储和执行是捆绑在一起的。在 Solana 中，程序根本不存储任何状态。所有状态都存储在与合约本身分开的账户中。

以太坊的账户模型

以太坊账户有两种形式：

• EOAs（外部拥有账户）：用户控制的带有私钥的账户。
• CAs（合约账户）：智能合约账户，存储代码和状态。

当你在以太坊上部署智能合约时，它存储在合约账户中，并且所有状态修改都会发生在该账户内。

Solana 的账户模型

在 Solana 上，一切都是账户。但它们分为两类：

• 程序账户（可执行）：仅包含代码，类似于以太坊智能合约，但没有状态。
• 数据账户（不可执行）：存储所有链上数据，充当程序的持久存储。

Solana 中的账户如何运作

• 每个账户都有一个所有者。唯一可以修改账户数据的实体是所有者程序。
• 默认情况下，新账户由系统程序拥有，该程序处理某些操作，如转移 Token、在账户上分配数据和分配账户的所有权。
• 要创建一个账户，你只需向该地址发送 SOL。
• 当一个账户被分配给一个程序后，程序本身控制该账户可以发生的事情。
• 账户需要保持一定数量的 SOL（lamports）以支付租金，这是一个确保有效使用区块链资源的机制。它要求账户保持最低余额以保持活跃。如果关闭账户，可以收回这笔租金。

程序账户可以通过分配来自另一个程序的账户或使用程序衍生地址（PDAs）模型在数据账户中存储其数据。开发人员可以通过将程序设置为账户所有者并使用种子生成地址来生成这些数据账户。

从下图可以看出，一个账户有五个字段：lamports、owner、executable、rent_epoch 和 data。

图片来源

程序衍生地址（PDAs）

程序衍生地址（PDA）是一种特殊类型的账户地址，程序可以控制而无需私钥。它们允许程序签名。如果 PDAs 是基于其程序 ID 生成的，程序可以用于签署。此外，它们允许确定性数据存储，以确保相同的种子值将始终生成相同的 PDA。

PDA 可用作链上账户的地址（唯一标识符），提供方便存储、映射和提取程序状态的方法。 来源

开发人员可以使用种子和 bump 生成 PDA，确保它们不会与用户控制的地址发生冲突。bump 是一个额外值（介于 0 和 255 之间），加到种子上以生成唯一地址。

图片来源

例如，假设我们的程序有一个 increment 函数，用于递增计数器。我们可以为每个用户创建一个单独的 PDA，而不是将所有用户计数器存储在单个账户中，其中 PDA 的种子基于用户的公共密钥。

• 如果用户 A 调用 increment，程序定位并更新用户 A 的计数器 PDA。
• 如果用户 B 调用 increment，程序定位并更新用户 B 的计数器 PDA。
• 因为程序拥有 PDA，所以只有程序可以修改它——用户不直接控制数据。但是，程序还可以通过在 PDA 的数据中存储一个 authority 字段来设计权限检查，以根据程序的逻辑给予用户间接控制。

这消除了每次写入时显式授权的需要，使 Solana 程序的高效性显著提高。

Solana 的账户模型带来了一些关键优势，改善了用户体验，使在 Solana 上构建变得更加容易。让我们探讨一些这些好处。

并行执行与本地化的费率市场

Solana 的账户模型通过要求每个交易预定义将要读取和写入的账户，启用了并行执行。这使得非冲突交易可以并行处理，提高了网络效率并减少了拥堵。

其工作原理：

• 如果两个交易仅从同一账户读取，则它们可以同时执行。
• 如果一个交易写入而另一个交易读取同一账户，则执行必须是顺序的，以保持数据一致性。
• 如果多个交易尝试写入同一账户，则它们将逐一处理。处理是在本地化费率市场中决定的，其中优先级更高（费用更高）的交易首先执行。

Solana 优先费 API

QuickNode 的 Solana Priority Fee API 允许开发人员获取最新费率的优先费用。

交易 1	交易 2	Solana 上的执行模型
Alice 向 Bob 发送 SOL	Alice 向 Charlie 发送 SOL	顺序
Alice 向 Bob 发送 SOL	Charlie 向 Carol 发送 SOL	并行

为什么这很重要：

• 未涉及高需求操作的用户（例如流行的 Token 铸造）不会受到无关交易的费用峰值影响。
• 程序设计影响性能。例如，需求写入量高的自动化做市商（AMM）和 Token 铸造程序可能会发生执行瓶颈。设计程序以最小化写入争用可以改善性能。

程序可重用性

Solana 账户模型的其他关键优势是程序可重用性。Solana 允许多个应用程序与共享链上程序进行交互。这减少了代码重复、部署成本和执行效率低下，使 Solana 更加可扩展和可组合。

以太坊：智能合约是孤立的

在以太坊中，每个新用例（Token、NFT、DeFi 协议）通常需要：

• 单独的智能合约部署，导致网络中逻辑冗余。
• 由于重复合约，合约创建会产生不必要的交易费用。
• 独立的存储和执行，使得合约之间很难实现无缝交互。

例如，如果你创建一个新的 ERC-20 Token，你必须部署一个全新的智能合约，尽管大多数 ERC-20 合约在功能上是相同的。

Solana：可重用的程序

Solana 程序设计为可共享和可重用的。开发者可以在现有程序下创建新账户，而不是为每个用例部署新程序。

例如，Solana Token Program 管理所有 SPL Token（Solana 的 Token 标准），消除了为单个 Token 创建单独合约的需要：

• 你只需在 Token 程序下创建一个铸造账户，而不是部署合同。
• 这个铸造账户定义 Token 的属性，例如供应量、小数位数和权限。
• Token 程序处理所有操作（铸造、销毁、转移），而无需为每个 Token 要求单独的合约。

这些示例还可以扩展到 DAO、NFT 等其他用例。

本指南无法覆盖 Solana 账户模型的所有细节。如果你希望了解更多关于 Solana 账户模型的信息，请查看我们的 Solana 账户模型简介 指南。

Gas 费用

在以太坊和 Solana 之间转变时，理解交易费用的工作原理至关重要，因为它们的处理方式由于架构选择的不同而存在显著差异。虽然它们有一些相似之处，例如有优先费用和基础费用，但费率结构却不同。

以太坊费用

• 全球费用市场：以太坊运行着一个通用费用市场，其中某一领域（如 NFT 铸造）的高需求可能会推动所有交易的 gas 价格上涨。Gas 测量计算工作量，而你设置的 gas 价格决定交易的优先级，导致费用高峰和网络拥堵期间成本增加。
• 基础费用：以太坊的每个区块有一个基础费用，由当前区块之前的区块确定。
• 优先费用：优先费用是为了激励验证者优先处理交易。用户可以支付更高的优先费用以确保其交易优先于其他交易包含在一个区块中，这可能导致在网络拥塞期间的费用峰值。

Gas 测量计算工作量，类似于 Solana 的计算单位，总费用计算为gas 使用量 * gas 价格，而 gas 价格由基础费用和优先费用组成。

Solana 费用

Solana 的费用结构确保只有与同一账户交互的交易相互竞争优先级，而其他交易不受高需求操作的影响。

基础费用：

• 依赖于交易所需的签名数量。
• 每个签名费用为 5000 lamports（0.000005 SOL）。
• 一半的费用被销毁，另一半归验证者。

优先费用：

• 用户可以出价额外费用以优先处理其交易，类似于以太坊的优先费用。
• 验证者根据此费用确定在高需求情况下优先包含哪些交易。
• 一半的费用被销毁，另一半归验证者。

总费用取决于用户愿意支付的优先费用以及交易所需的总计算（更复杂的交易需要更多的计算单位）。

租金（存储成本）：

• Solana 要求账户存入 SOL 以保持活跃——这防止了不活跃账户占用不必要的存储。
• 这不是费用，而是可退还的押金。当账户关闭后，租金将根据程序所有者（例如，通常是账户权限）规定收回。
• 关于租金的更多细节，请查看 Solana 上的租金 指南。

交易处理

Solana 和以太坊都支持原子交易，这意味着如果交易的任何部分失败，整个交易将被回滚。然而，Solana 和以太坊的交易处理方式略有不同。

以太坊交易

在以太坊中，交易通常是对智能合约的单一函数调用。因此，开发者可能需要创建自定义函数以处理特定用例。

以太坊使用增量 nonce（与你的账户相关联的计数器）确保交易唯一，并防止重放攻击。交易等待在内存池中，等待验证者选择，但这可能导致抢跑交易或在网络拥堵时期的高 gas 费用。

Solana 交易

Solana 采取滚动，而事务可以捆绑多个指令（可视为小函数调用），使你能够链式操作（例如，转移 tokens 和更新余额）一次完成。

然而，限制了可以包括在单个交易中的指令数量：

• 交易大小限制：每个交易 1232 字节
• 计算单位限制：交易必须保持在最大计算预算内，这意味着复杂交易可能需要拆分

Solana 的计算单位

限制	计算单位
每个区块的最大计算	4800 万
每个账户每个区块的最大计算	1200 万
每个交易的最大计算	140 万
默认交易计算	20 万

随着你对 Solana 的进一步了解，你可能会遇到这些交易限制。有一些工具，例如 Lil' JIT Jito Bundles，使多交易的原子批处理成为可能，从而允许复杂的执行超出标准的 CU 限制。

来源：优化 Solana 交易的策略

Solana 使用最近的 blockhash 而不是 nonce 来验证交易。此 blockhash 对 150 个区块有效，之后交易失效。

另外，Solana 支持 持久性 Nonces，允许事务离线签名后随时提交。持久性 Nonces 是唯一和顺序的，可以防止重放攻击，确保延迟交易的安全执行。

没有内存池，但优先费用仍然在订单排序中发挥作用。交易直接发送到验证者和领导者，减少了开销并缩短了延迟，但需要验证者向领导者转发交易，直到它们被处理。

领导者负责生成区块，每 4 个区块进行一次轮换。

Solana 交易

Solana 交易由以下组成：

• 一组指令
• 一组读取或写入的账户
• 一组签名
• 最近的 blockhash

有关 Solana 交易的更多详细信息，请查看我们的 指南。

开发工具

以下是对以太坊（EVM）和 Solana（SVM）之间的一些常用开发工具的比较表，以帮助你顺利过渡。

以太坊工具	Solana 对应工具	描述
Solidity	Rust、C、TypeScript、Assembly	Rust（有或没有 Anchor）是 Solana 的标准。C、Assembly 和 TypeScript 也用于 Solana。
Hardhat/Foundry	Solana 测试验证器、LiteSVM、Luzid	类似于 Hardhat 节点的本地区块链，用于测试程序和账户。
Hardhat/Foundry	Program-test、BankRun.js	Rust 和 JS 测试框架，用于程序测试
Ethers.js / Viem	@solana/kit（前身为 Solana Web3.js 2.x）、Solana Web3.js 1.x（不推荐使用）	用于客户端 dApp 交互的 JavaScript SDK，类似于 Ethers.js。
Remix	Solana Playground	基于 Web 的 IDE，编写、测试和部署 Rust 程序，类似于 Remix 的便利性。
ABI	Codama、Shanks、Anchor	标准化的 IDL 和客户端生成工具，替代以太坊的 ABI，进行程序交互。
Etherscan	SolanaFM、Solana Explorer、Solscan	用于检查账户和交易的区块链浏览器，类似于 Etherscan。
scaffold-eth	create-solana-dapp	用于快速 dApp 设置的模板生成器，类似于 scaffold-eth。
RainbowKit	Solana Wallet Adapter	处理钱包连接的框架，类似于以太坊中的 wagmi 或 RainbowKit。

不准备使用 Rust？

如果你还没有准备深入学习 Rust，可以使用 Neon，在 Solana 程序中部署的 EVM。它允许你编写 Solidity 合约并将其部署在 Solana 上。你可以在 这里 找到更多 Neona 信息，查看我们的 Neon 指南。

智能合约（程序）开发

在智能合约（程序）开发中，Solana 采取不同的方法，程序是无状态的，数据存储在单独的账户中。

本节将帮助你理解以太坊和 Solana 智能合约开发之间的关键差异，而不深入研究。

智能合约结构：代码与状态分离

以太坊：智能合约同时持有代码和状态

• 在以太坊中，智能合约是一个包含逻辑（代码）和持久存储（状态）的单元。
• 它作为合约账户（CA）被部署，与用户控制的外部拥有账户（EOA）分开。
• 示例：如果你提取 Token 余额，它会直接从合约的存储中获取。
• 升级需要代理模式（例如，透明代理、UUPS）。

Solana：程序是无状态的；状态是外部的。

• Solana 程序不存储任何状态。相反，所有数据存储在程序交互的账户中。
• 程序被部署到可执行账户中，状态存储在不可执行账户中（例如，PDAs - 程序衍生地址）。
• 示例： Token 余额不存储在智能合约中，而是存储在由 Token 程序拥有的账户中。
• 程序是默认可升级的（但可以锁定以实现不可变性）。

数据存储：映射与账户

以太坊：使用映射存储数据

• Solidity 允许映射（例如，mapping(address => uint256) balances;）在合约内部存储数据。

Solana：使用账户而不是映射

• Solana 中没有直接等同于映射的概念。相反，PDAs（程序衍生地址）充当存储结构化数据的确定性账户。
• 示例：而不是将 Token 余额映射到地址，你创建一个 PDA 账户来存储用户余额。

想问题时，不要以映射为思路，而是要以创建可以存储每个用户或实体所需数据的单独账户为思路。

函数执行：消息发送者 VS 显式账户

以太坊：msg.sender 和 tx.origin 处理授权

• 在 Solidity 中，合约可以自动知道通过 msg.sender 调用函数的用户是谁，以及通过 tx.origin 得到发起交易的用户。

Solana：需要显式账户传递

• Solana 程序没有内置的 msg.sender 等效项。相反，你必须显式传递程序将要交互的账户。
• 示例：要将 Token 从一个用户转移到另一个用户，交易必须包括：
  • Token 程序账户：执行 Token 转移逻辑的程序。
  • 发送者的 Token 账户：这个账户持有发送者的 Tokens，将被扣除。
  • 接收者的 Token 账户：这个账户将接收转移的 Tokens。
  • 发送者的主钱包账户：这个账户支付交易费用，通常是交易的签署者。
• 这种显式性确保了 Solana 运行时确切知道涉及哪些账户及其角色（例如，可读写或签名）。

在设计 Solana 程序时，总是要以账户为思考对象。你必须传入程序交互的每个账户。

代币标准：ERC-20、ERC-721等 VS SPL Tokens

以太坊：每个 Token 都有自己的合约

• 以太坊针对每种代币有不同的代币标准（例如 ERC-20、ERC-721 等）。每个代币遵循其对应的标准，但每个代币都是单独的智能合约，这需要单独为每个新代币进行合约部署。

Solana：一个 Token 程序，多个 Tokens

• Solana 只有一个中心化的 Token 程序，管理所有 SPL（Solana 程序库）代币。
• 相较于以太坊（例如 ERC-20），不需要为每种代币部署新合约，你只需在 Token 程序下创建一个铸造账户。
• Token 程序处理所有核心代币功能，包括：
  • 创建新代币（铸造账户）
  • 将新代币铸造到账户
  • 销毁代币
  • 在账户之间转移代币
• 每个用户的代币余额存储在专用代币账户中——一个与用户的钱包地址和 Token 的铸造地址Hook的 关联代币账户（ATA）。
• Solana 还引入了 SPL Token 2022，增强了原 Token 程序的高级功能，例如元数据、转移保护、转移费用等。

尽管 本指南没有涵盖所有差异，但这些是转变时应牢记的一些关键区别。

接下来，我们将探索使用 Solana 开发的基础知识，包括钱包和命令行工具。

开始使用 Solana：钱包和 CLI 基础

尽管可以通过库以编程方式创建钱包，但以太坊开发者通常会使用浏览器钱包（如 MetaMask 或 Rabby）来创建其钱包。这些钱包生成外部拥有账户（EOA），允许用户签署交易和管理资金。

在 Solana 上，你可以通过浏览器扩展（例如 Phantom、Solflare）或通过命令行（Solana CLI）创建钱包。

在 Solana 上创建钱包

选项 1：使用浏览器钱包（Phantom、Solflare、Backpack）

• 安装钱包。详细信息请查看 本指南。
• 创建一个新钱包并备份你的恢复密语短语。
• 使用此钱包签署交易并与 Solana dApp 交互。

选项 2：使用 Solana CLI 创建钱包

如果你希望用于开发目的的钱包，可以使用 CLI 生成密钥对：

solana-keygen new --outfile ~/.config/solana/id.json

这将创建一个密钥对 JSON 文件（id.json），其中包含你的私钥（数组形式）。此外，你将有一个助记词，可用于恢复你的密钥对。

保护你的密钥对

保持 id.json 文件的安全和私密。绝不要分享其内容或你的助记词，因为它们给予完全访问钱包和资金的权限。

导入和导出钱包

如果你在浏览器扩展中有一个钱包（即 Phantom），但希望在 CLI 中使用它，则需要从扩展中导出其私钥。

我们将涵盖如何将 Phantom 钱包导出到 Solana CLI 以及反向操作。

将 Phantom 钱包导入 Solana CLI

1. 打开 Phantom 并找到导出你的恢复密语短语的选项。
2. 复制短语（一个单词序列）。
3. 运行以下命令：

solana-keygen recover 'prompt://?key=0/0' -o my-wallet.json

1. 在提示时输入你的恢复密语短语。
2. 密钥对将导入到 Solana CLI。

将 Solana CLI 钱包导入 Phantom

1. 在文本编辑器中打开 id.json 文件。
2. 复制文件的内容（格式像是 [12, 34, 56, ...]）。
3. 在 Phantom 中找到导入私钥并粘贴复制的值。

这将把你在 CLI 生成的钱包恢复到 Phantom 中。

设置 Solana CLI 和 RPC 配置

开发者通过 RPC 端点与 Solana 网络交互。你可以配置与哪个网络交互（主网络、测试网或开发网）。

QuickNode RPC

为更快的发展，QuickNode 提供 Solana 的 RPC 端点。你可以使用这些 RPC 与 Solana 网络交互，而无需设置自己的节点或使用公共 RPC。
要获取 RPC 端点，请在 这里 注册一个免费帐户。

检查你的当前配置：

solana config get

设置你的 RPC 端点（例如，devnet）：

solana config set --url devnet

验证你的钱包地址：

solana address

空投测试 SOL 以供开发：

solana airdrop 2
solana balance

这将为你提供 2 SOL 以便在开发网进行测试。此外，你还可以使用 QuickNode Faucet 获取测试 SOL。

有关更多信息，请查看 在 Solana 上空投测试 SOL 的完整指南。

使用 QuickNode 进行多链开发

尽管以太坊和 Solana 在其技术设计上存在显著差异，但 QuickNode 提供了一个强大、统一的基础设施，方便开发者在这些生态系统之间桥接。以下是 QuickNode 如何支持以太坊（及其他 EVM 兼容链）和 Solana 之间无缝切换的技术概述，以及提升开发体验的关键特色。

多链开发的关键特征

• 统一基础设施：QuickNode 作为以太坊和 Solana 生态系统信任的提供者，消除了在这两个区块链之间切换提供商的需要。
• 链特定优化：
  • 对于以太坊和 EVM 兼容链：高性能 RPC 端点、先进的分析和智能合约开发工具。
  • 对于 Solana：超低延迟访问，优化高吞吐量和快速区块时间。
• 自定义产品和工具：

QuickNode 提供针对每个区块链独特要求的专门产品和工具，包括 核心 RPC API、实时数据流、无服务器功能和附加服务。

• 以太坊：我们的 以太坊链页面 提供关于 QuickNode 所能做的一切的概述，从核心基础设施到像 Streams、Functions 和 Marketplace 附加工具等高级工具。在我们的 以太坊文档 中了解更多信息。
• Solana：我们的 Solana 链页面 概述了 QuickNode 在 Solana 的能力，包括四种不同的数据流解决方案、核心 RPC 服务和通过 Marketplace 提供的额外开发者工具。有关更多信息，请参见我们的 Solana 文档。
• 全球低延迟架构：确保无论地理位置如何，性能都最优，关键于需要最小延迟的去中心化应用。

可靠性和合规性

QuickNode 的基础设施旨在满足任务关键应用的需求，确保安全性、正常运行时间和对开发者的支持。- SOC合规性：遵循SOC 1和SOC 2 Type 2标准，确保安全可靠的操作。

• 保证正常运行时间：保持99.99%的正常运行时间，以确保应用程序持续性能。
• 端到端支持：提供直接技术支持，以快速解决问题并保持开发进度。

凭借其强大的基础设施和以开发者为中心的工具，QuickNode简化了在Ethereum和Solana上构建的复杂性。

Solana基础指南

为了帮助你实际操作Solana，以下是一些涵盖基础知识的基础指南：

• 发送你的首个交易
• 创建代币
• 转移SPL代币
• 编写你的第一个Anchor程序
• 如何使用Solana Memo程序
• 如何使用程序派生地址

结论

从Ethereum（EVM）过渡到Solana（SVM）需要思维方式的转变，尤其是在程序架构、执行模型和账户管理方面。Solana将执行（程序）与存储（账户）分开，而不是智能合约存储自己的状态，这导致了更高的效率和更好的可扩展性。

虽然Solana开发与Ethereum不同，但许多概念可以映射，以便更轻松地进行过渡。通过理解关键差异并利用现有知识，你可以探索Solana的生态系统，构建高效的去中心化应用程序，并为网络的增长做出贡献。

想要看到更多类似内容吗？在下方留下你的反馈！

我们❤️反馈！

[告知我们](https://airtable.com/shrKKKP7O1Uw3ZcUB?prefill_Guide+Name=Solana Development for EVM Developers) 你的反馈或新主题请求。我们非常乐意听取你的意见。

订阅我们的时事通讯，获取更多关于Web3和区块链的文章和指南。如果你有任何问题或需要进一步的帮助，请随时加入我们的Discord服务器或使用下面的表格提供反馈。关注我们在Twitter（@QuickNode）和我们的Telegram公告频道以了解最新动态。

其他资源

对于那些希望深入了解Solana开发的人，以下是一些有用的资源：

QuickNode Solana内容

• Solana文档 - Solana的技术文档。
• Solana指南 - 为Solana开发者提供的所有指南。
• Solana开发入门 - Solana开发基础的免费课程。
• Solana基础概念参考指南 – Solana开发者的关键概念和术语。
• Solana钱包入门 – 找一个Solana钱包开始使用。

官方文档 & 指南

• Solana官方文档 – 官方技术文档。
• Solana Cookbook – 适合开发者的Solana指南。
• Anchor框架 – 使用简化的Solana智能合约框架。

探索者 & 工具

• Solana探索者 – 查看交易和账户。
• SolanaFM – 高级区块浏览器。
• Solana Playground – 用于编写和测试Solana程序的网页IDE。

社区 & 学习

• Solana Stack Exchange – 提问技术问题。
• Solana GitHub – 探索核心Solana代码库。
• Anza GitHub - Agave客户端和其他Solana工具（以前是Solana Labs）。

转载：https://learnblockchain.cn/article/13189

跨程序调用 (CPI) 是 Solana 的术语，用于描述一个程序调用另一个程序的公共函数。

我们之前已经进行过 CPI，当我们向系统程序发送一个 转账 SOL 交易。以下是相关代码片段，以作提醒：

    pub fn send_sol(ctx: Context<SendSol>, amount: u64) -> Result<()> {  
        let cpi_context = CpiContext::new(
            ctx.accounts.system_program.to_account_info(),
            system_program::Transfer {
                from: ctx.accounts.signer.to_account_info(),
                to: ctx.accounts.recipient.to_account_info(),
            }
        );

        let res = system_program::transfer(cpi_context, amount);

        if res.is_ok() {
            return Ok(());
        } else {
            return err!(Errors::TransferFailed);
        }
    }

Cpi 在 CpiContext 中字面上的意思是“跨程序调用”。

调用除系统程序外的其他程序的公共函数的工作流程并没有太大的不同——我们将在本教程中教授这一点。

本教程只关注如何调用另一个使用 Anchor 构建的 Solana 程序。如果其他程序是用纯 Rust 开发的，则以下指南将无法使用。

在我们的示例中，Alice 程序将调用 Bob 程序上的一个函数。

Bob 程序

我们从使用 Anchor 的 CLI 创建一个新项目开始：

    anchor init bob

然后在 bob/lib.rs 中复制并粘贴下面的代码。该账户有两个函数，一个用于初始化存储一个 u64 的账户，另一个函数 add_and_store 接受两个 u64 变量，将它们相加并存储在由结构体 BobData 定义的账户中。

    use anchor_lang::prelude::*;
    use std::mem::size_of;

    // 替换为你的 <PROGRAM_ID>
    declare_id!("8GYu5JYsvAYoinbFTvW4AACYB5GxGstz21FmZe3MNFn4");

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

        pub fn initialize(ctx: Context<Initialize>) -> Result<()> {
            msg!("数据账户已初始化: {}", ctx.accounts.bob_data_account.key());

            Ok(())
        }

        pub fn add_and_store(ctx: Context<BobAddOp>, a: u64, b: u64) -> Result<()> {
            let result = a + b;

            // 修改/更新数据账户
            ctx.accounts.bob_data_account.result = result;
            Ok(())
        }
    }

    #[account]
    pub struct BobData {
        pub result: u64,
    }

    #[derive(Accounts)]
    pub struct BobAddOp<'info> {   
        #[account(mut)]
        pub bob_data_account: Account<'info, BobData>,
    }

    #[derive(Accounts)]
    pub struct Initialize<'info> {
        #[account(init, payer = signer, space = size_of::<BobData>() + 8)]
        pub bob_data_account: Account<'info, BobData>,

        #[account(mut)]
        pub signer: Signer<'info>,

        pub system_program: Program<'info, System>,
    }

本教程的目标是创建另一个程序 alice，调用 bob.add_and_store。

在项目（bob）内，使用 anchor new 命令创建一个新程序：

    anchor new alice

命令行将打印出 创建了新程序。

在开始编写 Alice 的程序之前，必须将下面的代码片段添加到 Alice 的 Cargo.toml 文件的 [dependencies] 部分，位置为 programs/alice/Cargo.toml。

    [dependencies]
    bob = {path = "../bob", features = ["cpi"]}

Anchor 在这里做了大量的后台工作。Alice 现在可以访问 Bob 的公共函数和 Bob 的结构体的定义。你可以将这视为在 Solidity 中导入接口，以便知道如何与另一个合约进行交互。

下面是 Alice 程序。 在代码顶部，Alice 程序正在导入承载 BobAddOp（用于 add_and_store）的结构体。请注意代码中的注释：

    use anchor_lang::prelude::*;
    // account struct for add_and_store
    use bob::cpi::accounts::BobAddOp;

    // Bob 的程序定义
    use bob::program::Bob;

    // Bob 存储和的账户
    use bob::BobData;

    declare_id!("6wZDNWprmb9TAZYMAPpT23kHDPABvBLT8jbWQKLHEmBy");

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

        pub fn ask_bob_to_add(ctx: Context<AliceOp>, a: u64, b: u64) -> Result<()> {
            let cpi_ctx = CpiContext::new(
                ctx.accounts.bob_program.to_account_info(),
                BobAddOp {
                    bob_data_account: ctx.accounts.bob_data_account.to_account_info(),
                }
            );

            let res = bob::cpi::add_and_store(cpi_ctx, a, b);

            // 如果 CPI 失败则返回错误
            if res.is_ok() {
                return Ok(());
            } else {
                return err!(Errors::CPIToBobFailed);
            }
        }
    }

    #[error_code]
    pub enum Errors {
        #[msg("cpi to bob 失败")]
        CPIToBobFailed,
    }

    #[derive(Accounts)]
    pub struct AliceOp<'info> {
        #[account(mut)]
        pub bob_data_account: Account<'info, BobData>,

        pub bob_program: Program<'info, Bob>,
    }

如果我们将 ask_bob_to_add 与本文顶部展示的转账 SOL 的代码片段进行比较，会发现很多相似之处。

要实现 CPI，以下内容是必需的：

• 目标程序的引用（作为 AccountInfo）（红框）
• 目标程序运行所需的账户列表（包含所有账户的 ctx 结构体）（绿框）
• 传递给函数的参数（橙框）

测试 CPI

以下 TypeScript 代码可用于测试 CPI：

    import * as anchor from "@coral-xyz/anchor";
    import { Program } from "@coral-xyz/anchor";
    import { Bob } from "../target/types/bob";
    import { Alice } from "../target/types/alice";
    import { expect } from "chai";

    describe("从 Alice 到 Bob 的 CPI", () => {
      const provider = anchor.AnchorProvider.env();

      // 配置客户端以使用本地集群。
      anchor.setProvider(provider);

      const bobProgram = anchor.workspace.Bob as Program<Bob>;
      const aliceProgram = anchor.workspace.Alice as Program<Alice>;
      const dataAccountKeypair = anchor.web3.Keypair.generate();

      it("已初始化！", async () => {
        // 在这里添加测试。
        const tx = await bobProgram.methods
          .initialize()
          .accounts({
            bobDataAccount: dataAccountKeypair.publicKey,
            signer: provider.wallet.publicKey,
            systemProgram: anchor.web3.SystemProgram.programId,
          })
          .signers([dataAccountKeypair])
          .rpc();
      });

      it("可以相加然后加倍！", async () => {
        // 在这里添加测试。
        const tx = await aliceProgram.methods
          .askBobToAddThenDouble(new anchor.BN(4), new anchor.BN(2))
          .accounts({
            bobDataAccount: dataAccountKeypair.publicKey,
            bobProgram: bobProgram.programId,
          })
          .rpc();
      });

it("可以断言 Bob 的数据账户中的值等于 4 + 2", async () => {

  const BobAccountValue = (
    await bobProgram.account.bobData.fetch(dataAccountKeypair.publicKey)    ).result.toNumber();
  expect(BobAccountValue).to.equal(6);
});
});

一行完成 CPI

因为传递给 Alice 的 ctx 账户包含进行交易所需的所有账户的引用，我们可以在该结构体的impl内创建一个函数来完成 CPI。请记住，所有impl将“附加”函数到可以使用结构体中的数据的结构体。由于ctx结构体AliceOp已经持有Bob进行交易所需的所有账户，我们可以将所有 CPI 代码移动：

let cpi_ctx = CpiContext::new(
    ctx.accounts.bob_program.to_account_info(),

    BobAddOp {
        bob_data_account: ctx.accounts.bob_data_account.to_account_info(),
    }
);

到一个impl中，如下所示：

let cpi_ctx = CpiContext::new(
    ctx.accounts.bob_program.to_account_info(),
    BobAddOp {
        bob_data_account: ctx.accounts.bob_data_account.to_account_info(),
    }
);

use anchor_lang::prelude::*;
use bob::cpi::accounts::BobAddOp;
use bob::program::Bob;
use bob::BobData;

// 用你的<PROGRAM_ID>替换 declare_id!("B2BNs2GecG8Ux5EchDDFZakRWX2NDfy1RDhPCTJuJtr5");

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

    pub fn ask_bob_to_add(ctx: Context<AliceOp>, a: u64, b: u64) -> Result<()> {
        // 调用 bob 程序中的`bob_add_operation`函数
        let res = bob::cpi::bob_add_operation(ctx.accounts.add_function_ctx(), a, b);

        if res.is_ok() {
            return Ok(());
        } else {
            return err!(Errors::CPIToBobFailed);
        }
    }
}

impl<'info> AliceOp<'info> {
    pub fn add_function_ctx(&self) -> CpiContext<'_, '_, '_, 'info, BobAddOp<'info>> {
        // 我们正在与之交互的 bob 程序
        let cpi_program = self.bob_program.to_account_info();

        // 将所需账户传递给 Bob 程序中的`BobAddOp`账户结构体
        let cpi_account = BobAddOp {
            bob_data_account: self.bob_data_account.to_account_info(),
        };

        // 使用新方法创建`CpiContext`对象
        CpiContext::new(cpi_program, cpi_account)
    }
}

#[error_code]
pub enum Errors {
    #[msg("cpi to bob 失败")]
    CPIToBobFailed,
}

#[derive(Accounts)]
pub struct AliceOp<'info> {
    #[account(mut)]

    pub bob_data_account: Account<'info, BobData>,
    pub bob_program: Program<'info, Bob>,
}

我们能够以“一行”的方式调用Bob的 CPI。这在 Alice 程序的其他部分调用 Bob 的 CPI 时可能很方便——将代码移动到impl中可以防止我们复制和粘贴代码来创建CpiContext。

转载：https://learnblockchain.cn/article/10309

本文详细介绍了在Solana链上程序中如何读取不属于自己的账户数据，通过创建data_holder和data_reader两个程序，展示了如何初始化并读取PDA中的数据，并探讨了Anchor框架下的数据反序列化机制及其限制。

在 Solidity 中，读取另一个合约的存储需要调用 view 函数或者存储变量是公共的。在 Solana 中，离线客户端可以直接读取存储账户。这个教程展示了一个链上 Solana 程序如何读取它不拥有的账户中的数据。

我们将设置两个程序： data_holder 和 data_reader。 data_holder 将初始化并拥有一个 PDA，其数据将被 data_reader 读取。

设置存储数据的 data_holder 程序: Shell 1

以下代码是一个基本的 Solana 程序，它初始化账户 Storage，其中包含 u64 字段 x，并在初始化时将值 9 存储在其中：

Typescript 代码：

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

describe("data-holder", () => {
  anchor.setProvider(anchor.AnchorProvider.env());

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

  it("Is initialized!", async () => {
    const seeds = [];
    const [storage, _bump] = anchor.web3.PublicKey.findProgramAddressSync(
      seeds,
      program.programId
    );

    await program.methods
      .initialize()
      .accounts({ storage: storage })
      .rpc();

    let storageStruct = await program.account.storage.fetch(
      storage
    );

    console.log("The value of x is: ",storageStruct.x.toString());

    console.log("Storage account address: ", storage.toBase58());
  });
});

测试将打印出 PDA 的地址，我们稍后会提到这个地址：

读取器

为了让 data_reader 读取另一个账户，必须通过 Context 结构将该账户的公共密钥作为交易的一部分传递。这与传递任何其他类型的账户没有区别。

账户中的数据以序列化字节的形式存储。 为了反序列化账户，data_reader 程序需要读取它的 Rust 结构定义。我们需要以下账户定义，并且它与 data_holder 中的 Storage 结构完全相同：

#[account]
pub struct Storage {
    x: u64,
}

这个结构与 data_reader 中的结构完全相同——连名称也必须相同（稍后我们会介绍为什么）。读取账户的代码在以下两行中：

let mut data_slice: &[u8] = &data_account.data.borrow();

let data_struct: Storage = 
    AccountDeserialize::try_deserialize(
        &mut data_slice,
    )?;

data_slice 是账户中数据的原始字节。如果你运行 solana account <pda address>（使用我们在部署 data_holder 时生成的 PDA 地址），你可以在那里看到数据，包括我们储存在红框中的数字 9：

黄框中前 8 个字节是账户鉴别符，稍后我们将对此进行描述。

反序列化发生在此步骤：

let data_struct: Storage =
    AccountDeserialize::try_deserialize(
        &mut data_slice,
    )?;

在这里传递类型 Storage（我们上面定义的结构），告诉 Solana 如何（尝试）反序列化数据。

现在让我们在新文件夹中创建一个单独的 anchor 项目 anchor new data_reader。

完整的 Rust 代码如下：

use anchor_lang::prelude::*;

declare_id!("HjJ1Rqsth5uxA6HKNGy8VVRvwK4W7aFgmQsss7UxePBw");

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

    pub fn read_other_data(
        ctx: Context<ReadOtherData>,
    ) -> Result<()> {

        let data_account = &ctx.accounts.other_data;

        if data_account.data_is_empty() {
            return err!(MyError::NoData);
        }

        let mut data_slice: &[u8] = &data_account.data.borrow();

        let data_struct: Storage =
            AccountDeserialize::try_deserialize(
                &mut data_slice,
            )?;

        msg!("The value of x is: {}", data_struct.x);

        Ok(())
    }
}

#[error_code]
pub enum MyError {
    #[msg("No data")]
    NoData,
}

#[derive(Accounts)]
pub struct ReadOtherData<'info> {
    /// CHECK: We do not own this account so
    // we must be very cautious with how we
    // use the data
    other_data: UncheckedAccount<'info>,
}

#[account]
pub struct Storage {
    x: u64,
}

以下是要运行的测试代码。确保在下面的代码中更改 PDA 的地址：

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

describe("data-reader", () => {
  anchor.setProvider(anchor.AnchorProvider.env());

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

  it("Is initialized!", async () => {
    // CHANGE THIS TO THE ADDRESS OF THE PDA OF
    // DATA ACCOUNT HOLDER
    const otherStorageAddress ="HRGqGCLXxLryZav2SeKJKqBWYs8Ne7ppJxf3MLM3Y71E";

    const pub_key_other_storage = new anchor.web3.PublicKey(
      otherStorageAddress
    );

    const tx = await program.methods
      .readOtherData()
      .accounts({ otherData: pub_key_other_storage })
      .rpc();
  });
});

要测试读取另一个账户的数据：

1. 在后台运行 solana-test-validator 启动 data_holder 测试。
2. 复制并粘贴 Storage 账户打印的公共密钥。
3. 将该公共密钥放入 data_reader 测试的 otherStorageAddress 中。
4. 在另一个 shell 中运行 Solana 日志。
5. 运行 data_reader 的测试以读取数据。

以下内容应在 Solana 日志中可见：

如果我们不给结构体相同的名称，会发生什么？

如果你将 data_reader 中的 Storage 结构改为其他名称，如 Storage2 并尝试读取该账户，则会发生以下错误：

Anchor 计算的账户鉴别符是结构名称的 sha256 的前八个字节。账户鉴别符不依赖于结构中的变量。

当 Anchor 读取账户时，它检查前八个字节（账户鉴别符）以查看它是否与它在本地用于反序列化数据的结构定义的账户鉴别符匹配。如果它们不匹配，Anchor 将不会反序列化数据。

检查账户鉴别符是防止客户端错误地传入错误账户或数据格式与 Anchor 预期不符的账户数据的一种保障。

反序列化不会因解析更大结构而回退

Anchor 仅 检查账户鉴别符是否匹配——它不会验证被读取的账户内部的字段。

案例 1: Anchor 不检查结构字段名称是否匹配

让我们将 data_reader 中的 Storage 结构中的 x 字段改为 y，保持 data_holder 中的 Storage 结构不变：

// data_reader

#[account]
pub struct Storage {
    y: u64,
}

我们还需要将日志行更改如下：

msg!("The value of y is: {}", data_struct.y);

当我们重新运行测试时，它成功读取了数据：

Program log: Instruction: ReadOtherData
Program log: The value of y is: 9

案例 2: Anchor 不检查数据类型

现在让我们将 y 在 data_reader 中的 Storage 结构的数据类型更改为 u32，尽管原始结构是 u64。

// data_reader

#[account]
pub struct Storage {
    y: u32,
}

当我们运行测试时，Anchor 仍然成功解析账户数据。

Program log: Instruction: ReadOtherData
Program log: The value of y using u32 is: 9

之所以“成功”，是因为数据的布局如下：

7 里的 9 位于前几个字节中——u32 将在前 4 个字节中查找数据，因此它能够“看到”9。

当然，如果我们要存储 u32 无法容纳的值，例如 $2^{32}$，那么我们的读取程序将打印错误的数字。

练习 : 重置验证器并重新部署 data_holder，值设置为 $2^{32}$。在 Rust 中幂运算的方式是 let result = u64::pow(base, exponent)。例如，let result = u64::pow(2, 32); 查看 data_reader 记录了什么值。

案例 3: 解析的字段数据超出存储

存储账户的大小为 16 字节。它存储 8 字节给账户鉴别符，以及 8 字节给 u64 变量。如果我们尝试读取比实际大更多的数据，例如通过定义一个需要超过 16 字节来存储的结构，反序列化将失败：

#[account]
pub struct Storage {
    y: u64,
    z: u64,
}

上述结构需要 16 字节来存储 y 和 z，但还需要额外的 8 字节来保存账户鉴别符，使得账户大小达到 24 字节。

解析 Anchor 账户数据总结

在从外部账户读取数据时，Anchor 将检查账户鉴别符是否匹配，以及账户中是否有足够的数据可反序列化为用作 try_deserialize 类型的结构：

let data_struct: Storage =
    AccountDeserialize::try_deserialize(
        &mut data_slice,
    )?;

Anchor 不检查变量的名称或长度。

在底层，Anchor 不存储任何如何解释账户中数据的元数据。它只是存储变量的字节，按顺序存储。

并非所有数据账户都遵循 Anchor 的约定

Solana 不要求使用账户鉴别符。用原始 Rust 编写的 Solana 程序——没有 Anchor 框架——可能以与 Anchor 的序列化方法（即 AccountDeserialize::try_deserialize）不直接兼容的方式存储数据。要反序列化非 Anchor 数据，开发者必须提前知道使用的序列化方法——在 Solana 生态系统中并没有强制的通用约定。

读取任意账户数据时要小心

Solana 程序默认是可升级的。它们如何在帐户中存储数据的方式可能随时改变，这可能会破坏正在读取它们的程序。

接受来自任意账户的数据是危险的——在读取其数据之前，通常应检查该账户是否由受信任的程序拥有。

转载：https://learnblockchain.cn/article/11409