在Solana中 Account 的角色很重要，它就像Linux中一切皆文件的概念一样，无处不在。了解它也是开发Solana的基础，本节主要介绍我们最经常使用的 Account 、AccountInfo 和 SystemAccount 这三种账户类型的区别与使用场景。 当然除此之外还有一些账户类型也很重要，如 UncheckedAccount、Signer、TokenAccount、Mint、CpiAccount、Loader、Program、AssociatedToken 等，我们这里就不再一一讲解，有兴趣的话可以参考官方相关文档。 由于多数情况下都是使用anchor框架开发Solana合约，因此本文主要是根据 anchor-lang 文档里介绍账户来讲解 账户类型 以下我们分别对这三种账户类型做一些简单的介绍。 AccountInfo 在 Solana 中 AccountInfo 是最基础的账户类型。 其它几种账户类型都是对它的封装，它的定义 #[repr(C)] pub struct AccountInfo<'a> { pub key: &'a Pubkey, pub lamports: Rc<RefCell<&'a mut u64>>, pub data: Rc<RefCell<&'a mut [u8]>>, pub owner: &'a Pubkey, pub rent_epoch: u64, pub is_signer: bool, pub is_writable: bool, pub executable: bool, } 字段解释 key 公钥地址，当前账户的address lamports 账户中的 lamports。可由程序修改。 data 此账户中保存的数据。 owner 当前账户的所有者（下面会有一个图解释owner关系），它也是一个公钥地址 rent_epoch 租约纪元，此账户下次需支付租金的时间点（每个账户要想在在网络中存在，必须支付一定的存储空间费用，如果达到租金两倍则可以免除）

我们平时提到的比特币、以太坊、Solana，它们都属于Layer 1网络，而Layer 2(L2) 网络是指基于Layer1网络之上构建的一层网络，它很类似于Layer 1 网络，也是一个独立的区块链。但它的主要目的并不是为了代替 Layer 2 ，而是为了通过扩展 Layer1 层网络从而解决一些在 Layer 1 网络中存在的一些问题，它同时继承了 Layer 1 网络的安全性和去中心化性。 以太坊存在的问题 这里以以太坊为例，在 L1 网络上随着交易量越来越大，交易频率也越来越频繁，导致Gas（网络交易费）越来越高，一笔交易可能在网络繁忙的时候高达十几美元，导致一些交易可能需要花费好久才可以真正成交到区块网络。 这两个问题大大提高了用户使用门槛，那有没有好的解决办法呢？ 解决方案 区块链的三个核心特性是 去中心化、安全性和可扩展性，一般简单的区块链架构只能实现其中两个特性（这一点很类似于分布式中的CAP理论）。想要一个安全且去中心化的区块链的话，只能牺牲可扩展性，而这也正是第二层网络发挥作用的地方。 以太坊生态系统坚定认为，第 2 层扩展是解决可扩展性三难问题的唯一途径，同时保持去中心化和安全性。 Layer 2网络工作原理 Layer 2 也是一个独立的区块链，它扩展了以太坊。这在很大程度上减轻了第一层的交易负担，使其变得不那么拥堵，从而使整体更具扩展性。 目前存在多种第二层解决方案，每种都有其自身的权衡和安全模型。如 Rollups、State Channels、Sidechains、Validium、混合解决方案 等。 其中Rollups 是一种目前比较流行的 Layer 2（L2）扩展技术方案，它在以太坊生态系统中得到了广泛应用，并被许多主流项目采用。它不仅提高了区块链(以太坊生态)的性能和可扩展性，同时保持 Layer 1（以太坊）的安全性和去中心化特性。 Rollups 的核心思想是将大量交易打包成一个批次（Rollup）在链下处理，仅在 Layer 1 上存储交易数据和验证证明，从而降低交易手续费。 在区块链的中，链下 是指不在 Layer 1（主链）上直接处理交易或计算，而是将这些任务转移到 Layer 2 网络或其他链下环境中执行 针对 Rollups 分两种类型，乐观汇总 和 零知识证明， ——它们的主要区别在于如何将此交易数据提交到 Layer 1网络。 Optimistic rollups 它假设所有交易都是有效的，但如果怀疑存在无效交易，则提出挑战(质疑)，此时将运行错误证明以查看是否发生这种情况。 原理： 用户将交易发送到 Optimistic rollups 网络，并将这些交易合并成一个批次，并计算新的状态。 将所有交易数据进行压缩，并和新的状态根提交给 layer1 ，并在layer1进行存储 假设此时所有交易都是有效的，而如果有人质疑批次中的交易，则可以提出挑战(在挑战期内)。 如果发现无效交易，挑战者可以提交欺诈证明（Fraud Proof），触发状态回滚，并对提交无效交易人进行惩罚。 优点：

开发过Solodity的同学都知道在合约开发中，不同指令对应的不同前端Endpoint(API接口)，这种开发模式特别的清晰且易维护。那在开发Solana合约时没有有对应的方法呢？ Solana开发方式 开发 Solana 合约，一般分 Native 和 Anchor 框架开发。 Native 主要是开发者通过SDK 手动实现所有业务逻辑。 这种模式一般对开发者要求比较高，除了需要了解相关概念外，最重要的还需要知道对应的SDK实现，如PDA账户的创建。 Anchor框架 推荐使用，只需要一些宏即可以实现一些逻辑，不需要用户关心底层实现。这种开发方式对于指令的处理基本与Solidity中一致，开发者只要搞明白了基本用法就可以了。 下面主要讲一下在 Native 这种方式下，如何实现指令或附加数据的解析。 如果你对 指令这个概念不太理解的话，可以将其视为路由。其类于似在mvc开发中控制器路由，如 /user/info、 /user/base、/user/changepwd 之类。 示例介绍 我们先看一个在 https://beta.solpg.io 网站上创建的一个 Native 示例 /// Define the type of state stored in accounts #[derive(BorshSerialize, BorshDeserialize, Debug)] pub struct GreetingAccount { /// number of greetings pub counter: u32, } // Declare and export the program's entrypoint entrypoint!(process_instruction); // Program entrypoint's implementation pub fn process_instruction( program_id: &Pubkey, // Public key of the account the hello world program was loaded into accounts: &[AccountInfo], // The account to say hello to _instruction_data: &[u8], // Ignored, all helloworld instructions are hellos ) -> ProgramResult { msg!

本方主要介绍在编译solana程序时，提示 rustc 版本号过低无法编译通过的问题。 问题描述 在参考官方教程 https://github.com/solana-developers/program-examples/tree/main/basics/favorites/native 在本地执行命令 ➜ native git:(main) ✗ cargo build-sbf --manifest-path=./program/Cargo.toml --sbf-out-dir=./program/target/so 报错 ➜ native git:(main) ✗ cargo build-sbf --manifest-path=./program/Cargo.toml --sbf-out-dir=./program/target/so error: package `solana-program v2.1.7` cannot be built because it requires rustc 1.79.0 or newer, while the currently active rustc version is 1.75.0-dev 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.

在上一篇《了解 Solana 中ATA账户与普通账户的关系》中，我们介绍了在Solana中，ATA账户与Token Account 的区别，其中在浏览器记录查看 user2 用户详细的时候，发现它与前两个账户有所区别，它没有 Owner 属性，这在正常情况下是不应该出现的，所以，我们来分析一下，为什么Token Account没有 Owner 属性？ 在 Soalna中，默认情况下所有的新账户都属于 System Program，也只有系统程序拥有的账户才可以作为交易费用支付者（也就是账户里必须的原生币sol）。 因此示例中正常的 Token Account 异常账号 出现我这种情况主要有两种情况： 交易还在处理中，尚未完成，这种情况下一般只需要等待一会就会正常。 账户未被初始化，需要初始化后才恢复正常。 常见的初始化方法： 空投原生币 转账原生币 通过 SystemProgram.createAccount 创建账号· 在上篇文章里，我们为了演示转账记录，对 payer 和 user1 用户都进行了空投，在空投时将自动对账户进行初始化操作，因此在浏览器里显示的 Owner 是正常状态，但对于 user2 用户，由于没有进行初始化，所以没有 Owner 属性。 那么这里可能引出一些新的疑问。 为什么没有初始化可以根据这个账户创建ATA账号呢？ 要Solana中对于账户来说，只需要一个合法的 address 地址即可，它和账户是否初始化无关。 第二个张疑问是，既然没有初始化，那它怎么会在浏览器里显示呢？ 其实原理和上面的一个差不多，它只是一个地址，理解上所有有效的地址都可以在浏览上访问，唯一的区别是这个地址是否有包含一些数据信息。当你通过浏览器查看时，如果账户有相关数据信息的话，它会将这些数据信息显示出来，如果没有数据信息，则不会显示。 而我们的 user2 用户是没有数据信息，所以它根本不会显示 Owner 属性。 验证代码 这里为了提供演示，给出一下代码： import { Connection, PublicKey, Keypair, LAMPORTS_PER_SOL, SystemProgram, } from "@solana/web3.js"; async function main() { const connection = new Connection("http://localhost:8899", "confirmed"); const account = Keypair.