在上一篇博文《深入理解 Serde、Bincode 与 Borsh 的关系与区别》介绍了常用的几种解析二进制数据的方法，主要有 bincode 与 borsh, 并提到过在区块链领域里一般推荐使用 borsh 解析数据。但随着合约的开发使用borsh的地方越来越多，会经常遇到提示超出 4K Stack 大小的错误。这是因为在solana里，虚拟机 sbf 限制了一个合约最大允许使用的statck大小上限为 4k。尽管我们使用完一个大变量通过一些方法，如变量作用域、通过Box将内存移动到heap、或手动drop立即释放内存。但仍有些场景是没有采用这种办法的，这时应该如何办呢？ 如果经常看一些优秀的开源项目的话，会发现有一个 bytemuck 的crate，它是一个 zerocopy 库，可以避免内存复制带来的开销，加速解析数据速度，这里给出一个测试代码 use borsh::{BorshDeserialize, BorshSerialize}; use bytemuck::{Pod, Zeroable}; use solana_program::pubkey::Pubkey; use std::time::Instant; /// -------- 零拷贝结构 (定长布局) -------- #[repr(C, packed)] #[derive(Clone, Copy, Pod, Zeroable, Debug)] pub struct AccountZC { pub lamports: u64, // 8字节 pub data: [u8; 32], // 32字节 pub owner: Pubkey, // 32字节 } /// -------- Borsh 结构 -------- #[derive(BorshSerialize, BorshDeserialize, Clone, Debug)] pub struct AccountBorsh { pub lamports: u64, pub data: [u8; 32], pub owner: Pubkey, } fn main() { // 模拟数据 let lamports: u64 = 123456789; let data: [u8; 32] = [7u8; 32]; // 32字节全是 7 let owner = Pubkey::new_unique(); // ---------- 用 Borsh 序列化测试数据 ---------- let account_borsh = AccountBorsh { lamports, data, owner, }; let serialized_raw = borsh::to_vec(&account_borsh).

在Rust开发中，无论是构建网络服务、存储数据还是开发区块链程序，**序列化（Serialization）和反序列化（Deserialization）**都是不可或缺的操作。序列化是将内存中的数据结构(struct)转换成字节序列或者其他格式(JSON, vec)，以便存储或传输；反序列化则是将字节序列还原成原来的数据结构。 Rust 生态中常用的序列化工具包括 Serde、Bincode 和 Borsh。初学者在阅读文档或实际开发中可能会发现它们名字都很熟悉，但它们的定位、使用方式和特点却不完全相同。 本文将系统梳理三者的关系、差异和使用场景。 Serde Serde（Serialization / Deserialization） 是 Rust官方生态最流行的序列化框架。它提供了一种 抽象接口，让你可以将 Rust 类型序列化为多种格式，而不关心底层具体实现。 特点 通用性强：支持 JSON、YAML、TOML、Bincode 等多种格式。 灵活：可以自定义序列化逻辑。 宏支持：通过 #[derive(Serialize, Deserialize)] 自动生成序列化代码。 安全性：类型系统保证序列化和反序列化操作类型安全。 示例 use serde::{Serialize, Deserialize}; #[derive(Serialize, Deserialize, Debug)] struct User { name: String, age: u32, } fn main() { let user = User { name: "Alice".to_string(), age: 30 }; let json = serde_json::to_string(&user).unwrap(); println!("JSON: {}", json); } // Output: // JSON: {"name":"Alice","age":30} 注意：Serde 本身不提供具体的存储格式，它是框架，依赖具体格式库（如 serde_json、bincode）来实现序列化。

策略分类 在 Solana 上 MEV（最大可提取价值） 的几种策略主要有： 套利（Arbitrage） 清算（Liquidation） 抢跑（Front-Running） 三明治攻击（Sandwich Attack） 后置插队（Back-Running） Jito MEV 竞标 套利（Arbitrage） 价格差异猎手 想象你是一个精明的商人，在不同的市场上发现同一件商品价格不同。比如，在A市场一个苹果卖1元，在B市场卖1.2元。你会怎么做？立即在A市场买入，然后在B市场卖出，赚取0.2元的差价。 在加密世界中，这就是套利。交易员快速在不同交易所或流动性池之间捕捉加密货币价格差异，瞬间完成买卖，赚取微小但稳定的利润。 清算（Liquidation） 充当风险管理者角色。想象银行放贷时，借款人需要提供抵押物品，如果抵押物品价值下跌到无法覆盖贷款，银行会立即收回资产。 在加密借贷平台，当用户的抵押品价值跌破安全线，MEV机器人（清算人Liquidator） 通常可以以折扣价买入资产。这是因为在借贷平台（如 Solend、Mango Markets）中，如果用户的抵押资产价值不足以覆盖其贷款，借贷平台会进行 清算，并出售抵押资产来弥补贷款人的损失。MEV机器人（清算人）通过买入这些资产并偿还借款人欠的平台，可以获得折扣或者奖励。 抢跑（Front-Running） 想象在股市，有人获得内部消息，得知一家上市公司发生重大利好消息，他要在股市正式开市前抢先买入大量股票（盘前交易），这被称为"抢跑"。 MEV机器人监听交易池，当发现即将发生大额交易时，快速插入自己的交易，在原交易之前完成，从中获利。这就像是站在股市交易大厅的最前排，抢先一步。 三明治攻击（Sandwich Attack） 假如你要在一个拥挤的市场买入大量的苹果。一些精明的商贩知道这个消息后，他会在你购买之前大量的收购市场里的苹果，然后再出售给你，从而获利。 由于在一笔大额交易的前后各插入一笔交易，通过制造价格滑点来获利，就像把目标交易"夹"在中间，形成一个"三明治"。 攻击者的前置交易 ↓ 目标用户的大额交易 ↓ 攻击者的后置交易 在加密交易中，MEV机器人 会在大额交易前后插入自己的交易，通过制造价格波动来获利，就像把目标交易"夹"在中间。 后置插队（Back-Running） 可以想象在一个拍卖会上，一位艺术家的艺术品被以高价成交后，紧接着他的其它类似艺术品的价值大概率也会上涨。 MEV机器人 会紧随大额交易之后立即交易，利用这个交易带来的市场变动获利，就像是紧跟在大浪后的冲浪者。 Jito MEV 竞标 区块空间拍卖 你可以将其想象成一个竞标会，不同的商人为获得 最佳展位 而竞争。谁出价最高，谁就能获得最好的位置。 在Solana区块链上，MEV机器人通过Jito平台向验证者竞标区块空间。出价最高的机器人可以将自己的交易打包到区块中，从MEV中获得收益。 总结 总的来说，MEV策略就像是金融世界的高频交易算法，需要极快的计算能力、复杂的算法和对市场的敏锐洞察。它们在捕捉微小利润的同时，也为市场提供了一定的流动性和价格发现机制。 不过，这些策略也存在争议。它们可能被视为不道德，因为它们在某种程度上"操纵"了市场。 对于以上这些MEV策略，在开发时，一般通过以下几种监听交易的方式实现 监听实时交易日志（onLogs） 适用场景：抢跑（Front-Running）、三明治攻击（Sandwich Attack） 📌 思路： 监听目标 DEX（如 Raydium、Orca、Jupiter）的交易日志 解析 交易内容（Swap / 清算 / 预言机更新） 立即提交 更高 Gas 费的交易 抢跑 示例代码 import { Connection, PublicKey } from "@solana/web3.

本篇文章将对官方教程的基本上进行整理和完善，同时对一些官方未提到的一些知识点和实践进行一些介绍，方便一些刚入门solana开发的同学能够对solana开发有更完整的了解。 本篇文章使用 spl-token 命令行进行演示操作，分别介绍 Mint Account 和 token Account 的创建、转账、关闭账户并回收租金SOL等操作。 这里假如用户本机已经安装好solana命令行，这里使用本地集群环境，通过 solana-test-validator 命令在本地启动开发集群。 环境准备 开启一个新终端，在本地创建一个集群 (base) ➜ ~ solana-test-validator --ledger test-ledger -r Ledger location: test-ledger Log: test-ledger/validator.log ⠠ Initializing... Waiting for fees to stabilize 1... Identity: 7U4BYYhgGtjXyujPxX7BrqwYJmLA5BGijUhEv6BACphi Genesis Hash: ATwFvEZBVuQjAYbp2Y8FyrbLL8AQxN3sPxci2uKkNxFe Version: 2.2.3 Shred Version: 45925 Gossip Address: 127.0.0.1:1024 TPU Address: 127.0.0.1:1027 JSON RPC URL: http://127.0.0.1:8899 WebSocket PubSub URL: ws://127.0.0.1:8900 ⠚ 00:00:10 | Processed Slot: 22 | Confirmed Slot: 22 | Finalized Slot: 0 | Full Snapshot Slot: - | Incremental Snapshot Slot: - | Transactions: 21 | ◎499.

在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