普通账户地址 对于账户地址的创建是由一个密钥对来生成的，但在Solana中账户地址与以太坊中的账户地址还是有一些区别的。 以太坊账户地址 以太坊账户地址的生成过程： 通过私钥生成公钥 对公钥进行 Keccak-256 哈希 取哈希值的最后 160 位（20 字节）作为地址 将地址以 0x 开头，并根据需要选择是否使用 EIP-55 格式 地址中通常是小写字母，但也有大写字母的变种，称为 EIP-55 格式。在 EIP-55 中，某些字符会根据哈希值的大小写进行区分，从而增加地址的错误检查能力。 Solana 账户地址 Solana账户地址的生成过程： 通过私钥生成公钥，一般通过调用 Keypair.generate() 生成 公钥直接映射为账户的地址，长度为 32 字节 为了使用方便，一般对其进行 Base58 编码，将公钥转换为地址字符串 代码： const { Keypair } = require('@solana/web3.js'); // 生成一个新的密钥对 const keypair = Keypair.generate(); // 获取公钥，实际上就是账户地址 const publicKey = keypair.publicKey; // 转换公钥为 Base58 编码的字符串（即账户地址） const address = publicKey.toBase58(); console.log("Solana Account Address (Base58):", address); 可以看到 Solana 中的账户地址就是公钥，平时使用的账户地址，一般都是指 Base58 编码后的字符串。

在 Solana 中转账有两种方式。 修改结构体字段 一种是在不调用（invoking ）系统程序（ System Program ）的情况下，将 lamports 从一个账户转移到另一个账户。它的实现是直接通过修改结构体的 lamports 字段值来实现的。 这种方法可以实现将 lamports 从任何由您的程序拥有的账户转移到任何账户。文档 /// Transfers lamports from one account (must be program owned) /// to another account. The recipient can by any account fn transfer_service_fee_lamports( from_account: &AccountInfo, to_account: &AccountInfo, amount_of_lamports: u64, ) -> ProgramResult { // Does the from account have enough lamports to transfer? if **from_account.try_borrow_lamports()? < amount_of_lamports { return Err(CustomError::InsufficientFundsForTransaction.into()); } // Debit from_account and credit to_account **from_account.

在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!