以下是 Anchor 工作区中默认文件结构的概述：

.
├── .anchor
│   └── program-logs
├── app
├── migrations
├── programs
│   └── [project-name]
│       └── src
│           ├── lib.rs
│           ├── Cargo.toml
│           └── Xargo.toml
├── target
│   ├── deploy
│   │   └── [project-name]-keypair.json
│   ├── idl
│   │   └── [project-name].json
│   └── types
│       └── [project-name].ts
├── tests
│   └── [project-name].ts
├── Anchor.toml
├── Cargo.toml
└── package.json

程序文件夹

该/programs文件夹包含项目的 Anchor 程序。单个工作区可以包含多个程序。

测试文件夹

该/tests文件夹包含项目的测试文件。创建项目时会为您创建一个默认测试文件。

目标文件夹

该/target文件夹包含构建输出。主要子文件夹包括：

• /deploy：包含您的程序的密钥对和程序二进制文件。
• /idl：包含程序的 JSON IDL。
• /types：包含 IDL 的 TypeScript 类型。

Anchor.toml文件

该Anchor.toml文件为您的项目配置工作区设置。

.anchor 文件夹

包含一个program-logs文件，其中包含上次运行测试文件的事务日志。

应用程序文件夹

该/app文件夹是一个空文件夹，您可以选择将其用于前端代码。

了解以太坊和 Solana 智能合约之间的区别。

您可以在 Solana 区块链上编写和部署程序。 程序（在其他协议中也称为智能合约）是从 DeFi 和 NFT 到社交媒体和游戏等链上活动的基础。

• 程序处理从用户或其他程序收到的指令。
• 所有程序都不维护状态。换句话说，程序使用的数据通过指令发送到单独的账户。
• 该程序本身存储在一个executable已检查的帐户中。
• 所有程序均归 BPF Loader 所有，并由 Solana Runtime 执行。
• 开发人员通常使用 Rust 或 C++ 编写程序。不过，任何针对 LLVM 和 BPF 后端的语言都可以选择。
• 所有程序都有一个单独的入口点，在此进行指令处理（即process_instruction）。始终包含以下参数：
  • program_id: pubkey,
  • accounts: array,
  • instruction_data: byte array

与大多数其他区块链不同，Solana 将数据和代码完全分离。程序与之交互的所有数据都存储在单独的账户中，并通过指令进行调用。
这种模式允许综合单一程序通过各种帐户运行，而无需额外部署。这种模式的一个常见示例可以在 Native 和 SPL 程序之间看到。

本机程序和 Solana 程序库 (SPL)

Solana 有许多程序可作为链上交互的核心构建块。
这些程序分为本机程序和 Solana 程序库 (SPL) 程序。
原生程序提供运行验证器所需的基础功能。其中最著名的程序之一是System Program，负责管理新账户并在两个组之间转移 SOL。
SPL 程序支持各种链上活动，包括代币创建、兑换、借贷、权益池生成和链上名称服务。SPL 代币程序可以直接通过 CLI 调用。其他程序（如关联代币帐户程序）通常配置为自定义程序

编写程序

程序通常用 Rust 和 C++ 开发。但是，您可以使用任何针对 LLVM 和 BPF 后端的语言进行开发。Neon Labs 和 Solang 最近的努力使 EVM 兼容性成为可能，允许开发人员用 Solidity 编写程序。

大多数基于 Rust 的程序遵循以下架构：

最近，Anchor 已成为一种程序开发框架。Anchor 减少了样板代码并简化了（反）序列化处理，类似于 Ruby on Rails，但适用于基于 Rust 的程序。程序通常在 Localhost 和 Devnet 环境中开发和测试，然后部署到 Testnet 和 Mainnet。

Solana 支持以下环境：

一旦部署到环境，客户端就可以通过与每个集群的 RPC 连接与链上程序进行交互。

部署程序

开发人员可以通过 CLI 部署程序，如下所示：

solana program deploy <PROGRAM_FILEPATH>

程序部署后，会被编译为 ELP 共享对象（包括 BPF 字节码）并上传到 Solana 集群。除非程序被标记为可执行并分配给 BPF 加载器，否则它们都存在于帐户内。帐户的地址用作 program_id在所有交易中引用程序的地址。

Solana 支持多个 BPF 加载器，包括最近的可升级 BPF 加载器。BPF 加载器负责管理程序帐户，并通过客户端的 program_id 实现这一点。
所有程序都有一个单独的入口点，在此进行指令处理（即 process_instruction）。参数始终包括：

• program_id: pubkey
• accounts: array
• instruction_data: byte array

一旦调用，程序就会由 Solana Runtime 执行。

概括

• Solana 中的程序对应于 Solana 区块链上的“可执行账户”。
• 以太坊中的智能合约概念与 Solana 中的程序概念一致。
• Solana 允许任何人发行代币，而无需部署额外的合约。

原文：https://solana.com/developers/evm-to-svm/smart-contracts

了解在以太坊和 Solana 上构建账户时的不同之处。
作为区块链网络，以太坊和 Solana 拥有独特的数据结构，充当全球公共计算机，在其网络上存储和共享数据。在本章中，我们旨在探索这些链如何构建其数据集。

以太坊中的“账户”

在以太坊中，“账户”是指拥有以太币并可以发送交易的实体。它包括存款和取款所需的地址，并分为以下几类：

• EOA（外部拥有账户）：外部拥有的账户，拥有私钥。可以将其视为个人钱包的账户。
• CA（合约账户）：合约账户，持有智能合约代码。

以太坊中 EOA 与 CA 的一个关键区别是，EOA 不是智能合约，通常没有自己的存储。因此，EOA 的代码哈希被设置为“空”哈希，表示该帐户没有存储空间。

外部拥有账户 (EOA) 是具有私钥的账户，拥有私钥意味着控制对资金或合约的访问。私钥意味着控制对资金或合约的访问。EOA 中包含以下数据：

合约账户包含智能合约代码，而 EOA 根本无法拥有这些代码。此外，合约账户没有私钥。相反，它由智能合约代码的逻辑控制。此智能合约代码是在创建合约账户时记录在以太坊区块链上的，是由 EVM 执行的软件程序。

与 EOA 一样，合约账户有一个地址，可以发送和接收 Ether。但是，当交易的目的地是合约账户地址时，交易和交易数据将用作在 EVM 中执行合约的输入。除了 Ether，交易还可以包含指示要执行的合约特定功能的数据以及要传递给该功能的参数。因此，交易可以调用合约内的函数。如果 EOA 请求，合约还可以调用其他合约。但是，由于合约账户没有私钥，因此它无法签署交易，也无法自行发起交易。关系总结如下：

• EOA → EOA（确定）
• EOA → CA（确定）
• EOA → CA → CA（确定）
• CA → CA（不可能）

Solana 中的“账户”

Solana 中的帐户概念比以太坊中的要广泛一些。在 Solana 中，所有数据都是基于帐户存储和执行的。这意味着，在交易之间需要存储状态的每种情况下，都会使用帐户来保存状态。与 Linux 等操作系统中的文件类似，帐户可以存储在程序生命周期之外仍然存在的任意数据。此外，与文件一样，帐户包含元数据，可告知运行时谁可以访问数据以及如何访问。

在 Solana 的 Sealevel VM 中，所有账户都能够存储数据。那么，智能合约开发人员可以将数据存储在哪里呢？他们可以将数据存储在可执行账户拥有的非可执行账户 (PDA) 中。开发人员可以通过分配与其可执行账户地址相同的所有者来创建新账户来存储数据。

然而，Solana 网络上存储数据的“账户”需要支付费用。这些账户包含有关其所含数据寿命的元数据，以名为“Lamports”的原生代币表示。账户存储在验证者的内存中，并支付“租金”以保留在那里。验证者定期扫描所有账户并收取租金。Lamports 降至零的账户将被自动删除，因为它们无法支付租金。如果一个账户包含足够数量的 Lamport，它将免收租金，并且不会单独扣除租金。

Solana 的账户分为以下两种类型，与以太坊类似：

• 可执行账户（程序账户）：这些是存储代码的智能合约，通常更简单地称为“程序”。
• 不可执行账户（数据账户）：这些账户可以接收代币或数据，但不能执行代码，因为可执行变量设置为“false”。

（*与以太坊不同，Solana 使用术语“程序”而不是“合约”。）

比较每个链中的帐户结构，可以发现以下差异。

那么，EOA 和 CA 与 Solana 的 Account 结构如何对应呢？ 它们可以进行如下映射。

账户抽象

以太坊一直在探索账户抽象的概念。以太坊中有两种类型的账户：EOA 和 CA，每种账户的功能截然不同。值得注意的是，合约账户 (CA) 无法生成或签署交易，这带来了很大的限制。交易必须通过 EOA 发起和签署，这意味着使用 21,000 gas 的基本费用，并增加了账户管理的复杂性。账户抽象旨在消除这些限制，允许单个账户同时执行 EOA 和合约账户的功能。

因此，可以对图表进行以下调整：

• EOA → EOA（确定）
• EOA → CA（确定）
• EOA → CA → CA（确定）
• EOA + CA (AA) → CA（现在，好的！）

例如，多重签名钱包或智能合约钱包需要在单独的 EOA 中存储少量以太坊以支付交易费用，这带来了需要随时间补充的不便。账户抽象允许单个账户执行合约并发出交易，从而改善了这种不便。Vitalik 通过 ERC-4337 向社区提出了这一概念，并于 2021 年被采纳，现已在以太坊网络中实现。

总而言之，账户抽象具有以下好处：

• 其他人支付我的交易费用，或者我为其他人支付。
• 使用 ERC-20 代币支付费用
• 设置自定义安全规则。
• 密钥丢失时的帐户恢复。
• 在受信任的设备或个人之间共享帐户安全。
• 批量交易（例如，一次性授权和执行掉期）。
• 为 dapp 和钱包开发人员提供更多机会来创新用户体验。

Solana 中实现了账户抽象吗？

Solana 自推出以来就实现了账户抽象（AA）。如前所述，Solana 将所有数据存储在称为“账户”的单元中，分为可执行（程序账户）和不可执行（数据账户）。从一开始，Solana 就支持程序创建和管理特定账户（即直接发起交易）的能力。此功能扩展了 Solana 中的账户抽象功能，称为程序派生地址（PDA）。与数据账户不同，Solana 程序是包含可执行代码的可执行账户。通过 PDA，开发人员可以设置交易签名的规则和机制，允许代表 Solana 网络认可和批准的受控账户（PDA）自主授权各种链上操作。因此，与以太坊不同，Solana 允许直接控制基于 Solana 程序的另一个程序，而无需繁琐的分层。

概括

• Solana 的账户概念构建了链上的所有数据，所有数据都基于账户。
• Solana 原生支持 AA，实现程序间自调用。

原文：https://solana.com/developers/evm-to-svm/accounts

了解以太坊和 Solana 在达成共识方面的差异。
众所周知，以太坊和 Solana 的共识机制均采用 PoS（权益证明）。它们都通过基于权益的验证器生成区块。尽管它们从根本上采用相同的共识，但以太坊目前记录的 TPS（每秒交易数）约为 30，而 Solana 则拥有 4000 TPS。这种差异间接表明了共识如何显著影响区块生成速度。本章将深入探讨这两条链之间的差异。

以太坊最初的共识

以太坊最初采用的是工作量证明（PoW）方式，比特币至今仍在使用这种方式。在 2022 年 8 月合并升级后，以太坊从工作量证明过渡到权益证明，现在采用上述的 PoS。

以太坊目前的共识

以太坊的核心是 PoS，但它特别采用了一种称为 Gasper 的共识算法。Gasper 是 Casper 友好最终性小工具 (Casper-FFG) 和 LMD-GHOST 分叉选择算法的组合。在深入研究 Gasper 之前，需要注意的是，以太坊最初是根据基于 PoW 的 Nakamoto 共识生成区块的。Nakamoto 共识遵循最长链规则，在分叉期间选择区块链中最长的链。因此，以太坊并没有完全放弃 PoW；它保留了 PoW 下的基本区块生成，同时在其上集成了 PoS 元素。

Casper (Casper-FFG) 是 Gasper 的一部分，它将某些区块升级为“最终确定”状态，确保网络参与者与常规链同步。它最初是在 Merge 升级期间为从基于 PoW 的链到 PoS 的过渡阶段提出的，现在部分贡献于更大的 Gasper 算法。LMD-GHOST（最新消息驱动最贪婪最重观察子树）是一种分叉选择算法，用于在各种分叉中选择最有效和最值得信赖的链。如果分叉生成多个新区块，验证者将通过证明消息进行投票，以确定将哪个区块附加到现有链。这些证明遵循从创世区块到最新区块（叶区块）的路径，选择由最新证明支持的区块。

Solana 的共识

Solana 中与以太坊各个共识算法对应的技术组件是什么？答案就在支持 PoS 的 Tower BFT 中。

首先，让我们了解一下 BFT 和 PBFT。BFT 是一种在分布式系统中实现节点间可靠共识的方法，源自“拜占庭将军问题”。即使某些节点是恶意的或不可靠的，它也能确保系统正常运行。PBFT 是 BFT 的一种实际实现，它通过确保所有节点之间对所有交易达成一致来保证系统的最终性和一致性。

Tower BFT 采用了 PBFT 的变体，但有一个根本区别：历史证明 (PoH) 在达成共识之前充当全局时钟。在 Solana 的实现中，PoH 用作网络时钟，用于安排区块、交易和数据的顺序。

以太坊经常会低效地更新其整个网络状态以用于特定交易，并且交易可能无法按顺序处理。相比之下，Solana 利用 PoH（历史证明）来支持 PoS。要确定两个事件之间的加密时间，需要一系列计算步骤。例如，考虑两张照片：一张是苹果，另一张是正在拍摄的照片。我们可以推断苹果的照片是先拍摄的。Solana 通过在数据中添加时间戳来跟踪它们的顺序，确保其结构不会混淆。

Tower BFT 使用 PoH，通过时间戳验证有效地确定区块、交易和数据的顺序。因此，验证者可以最终决定分叉，选择最受投票信任的链。以太坊缺乏像 PoH 那样的时间戳概念来进行整体状态同步，迫使验证者根据之前的哈希值进行计算以选择分叉。相反，基于 PoH 的 Solana Tower BFT 可以轻松达成共识，而无需进行完整的区块验证。

因此，比较可以总结如下：

概括

以太坊共识：基于 PoS 的 Gasper = Casper 友好最终性小工具（Casper-FFG）+ LMD-GHOST 分叉选择规则
Solana 的共识：基于 PoS 的 Tower BFT + PoH

原文：https://solana.com/developers/evm-to-svm/consensus

了解 Solana 和以太坊上的客户端之间的区别。
以太坊和 Solana 是独特的区块链，具有多个不同的验证器客户端来验证交易。拥有各种验证器客户端有助于防止特定客户端遇到问题时网络中断。在本章中，我们将介绍以太坊和 Solana 生态系统中的验证器客户端，并讨论存在的节点类型。

验证器客户端的类型

随着以太坊从 PoW（工作量证明）过渡到 PoS（权益证明），它采用了两种类型的验证器客户端：执行层 (EL) 和共识层 (CL) 客户端。执行客户端负责接收网络上广播的新交易、在 EVM 上执行它们以及维护所有以太坊数据的当前状态和数据库。另一方面，共识客户端实现 PoS 的共识算法，并根据来自执行客户端的已验证数据在网络上达成共识。这两种类型的客户端扮演着不同的角色，这就是为什么以太坊验证器节点通常同时运行执行客户端和共识客户端的原因。相比之下，Solana 将这两种功能结合在一个客户端中。

以下是以太坊的执行客户端列表：

以下是以太坊共识客户端列表：

现在，让我们看一下 Solana 的验证者客户端列表：

以太坊和 Solana 的节点数量

对于以太坊，您可以通过访问clientdiversity检查每个验证器客户端运行的节点数量。 对于 Solana，您可以从验证器健康报告中找到此信息。

节点类型

根据使用情况和所需条件，节点有多种形式。它们可以是存储所有数据的重量级节点，也可以是专注于处理交易的轻量级节点。
以太坊根据数据存储范围和参与共识的方式将节点分为三类：

• 全节点：全节点逐个区块验证区块链，下载并验证每个区块的数据。全节点有多种类型，有些从创世区块开始，验证整个区块链历史中的所有区块。其他全节点从最近的可信区块开始验证，通常维护最近 128 个区块的本地副本，并定期删除旧数据以节省磁盘空间。旧数据可以在需要时重新生成。
• 存档节点：存档节点验证并保存从创世块开始的所有块，从不删除任何数据。它们对于区块浏览器、钱包提供商和链分析等服务以及查询测试集（无需可靠地挖掘它们）至关重要。
• 轻节点：轻节点仅下载区块头，而不是整个区块链。轻节点所需的其他信息则向全节点请求。轻节点可以独立地根据区块头的状态根验证收到的数据。它们不需要高带宽或强大的硬件，因此可以通过手机或嵌入式设备参与以太坊网络。轻节点不参与共识，这意味着它们不能成为矿工或验证者，但它们提供与全节点相同的功能和安全保障，从而允许访问以太坊区块链。

对于 Solana 来说，节点根据其参与共识的方式分为两种类型：

• 共识节点：共识节点在网络中发挥着至关重要的作用，它们负责创建和向网络提交新区块，并对其他节点提交的新区块的有效性进行投票。它们是网络运行的核心。
• RPC 节点（远程过程调用节点）：RPC 节点对于在 Solana 区块链上构建的 dApp 至关重要，可充当区块链数据的网关。与共识节点一样，它们独立验证所有新区块和网络更改，但不参与投票。

Solana 从一开始就将 RPC 节点与共识节点区分开来。不过，RPC 节点不参与投票。以太坊的 RPC 节点通常基于完整节点或存档节点。

Solana 为什么这样对节点进行分类？与以太坊不同，Solana 每秒生成大量交易，由于交易量巨大，将整个区块链存储在每个节点上是不切实际的。目前，Solana 使用 Google Bigtable 存储数据，RPC 节点从那里访问数据。因此，Solana 不太注重在本地存储大量数据，这与以太坊的节点分类标准不同。

总而言之，比较如下：

RPC 服务列表

有同时支持以太坊和 Solana 的 RPC 服务，也有支持单链的 RPC 服务。Alchemy 和 Quicknode 等服务同时支持以太坊和 Solana。您可以在此处查看 Solana 的各种 RPC 服务。

概括

与以太坊一样，Solana 也拥有各种类型的验证器客户端。
虽然每个链的节点类型可能看起来不同，但它们从根本上为用户提供相同的功能。