在Solana中有一些少量的内置原生程序，它们的程序ID格式一般为 xxx11111111111111111111111111111111。它们与第三方自定义程序不同，原生程序是 validator node 运行所必须的一部分。同时它们也是集群升级的一部分，这些升级可能包括新功能的添加、BUG修复，又或者是性能的优化提升。这些内置原生程序极少的发生变化，目前提供的所有内置原生程序可以在 https://docs.anza.xyz/runtime/programs 找到。 其中有两个非常重要的程序很值得我们关注，因为我们在开发中，需要经常用到他们。 System Program 作用： 创建新帐户 分配帐户数据 将帐户分配给所属的程序，即指定账户与程序的对应关系 转账最小 lamports 给账户(租金)，防止账户被系统回收 Program id: 11111111111111111111111111111111 Instructions: SystemInstruction BPF Loader 作用： 部署所有自定义程序，并将其作为的所有自定义程序的 owner 升级和执行链条上的程序 Program id: BPFLoaderUpgradeab1e11111111111111111111111 Instructions: LoaderInstruction BPF可升级加载器将自己标记为它为存储程序而创建的可执行文件和程序数据帐户的“Owner”。当用户通过程序id调用指令时，Solana运行时会加载您的程序及其所有者BPF Upgradeable Loader。然后，运行时将程序传递给BPF可升级加载器，以便其处理指令。 对于 BPFLoaderUpgradeab1e11111111111111111111111程序它是作为 Token2022 专用的，它是对 Token 的扩展版，对于 Token 对应的内置程序是 BPFLoader2111111111111111111111111111111111，两者的区别是后者是无法升级的。 关系图 对于这些内置原生程序与三方程序的关系图大概是这个样子的。 参考资料 https://docs.anza.xyz/runtime/programs https://solana.com/zh/docs/core/accounts#native-programs

普通账户地址 对于账户地址的创建是由一个密钥对来生成的，但在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 1 ，而是为了通过扩展 Layer 1 层网络从而解决一些在 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 分两种类型，Optimistic rollups(乐观汇总) 和 Zero knowledge rollups(零知识证明)， 它们两者的主要区别在于如何将此交易数据提交到 Layer 1网络。 Optimistic rollups 它假设所有交易都是有效的，但如果怀疑存在无效交易，则提出挑战(质疑)，此时将运行错误证明以查看是否发生这种情况。