aaa (brooke)

Jito 推出的三明治攻击缓解机制与 Demo 示例

aaa — Mon, 02 Jun 2025 21:23:06 +0800

Jito 推出的三明治攻击缓解机制与 Demo 示例

在两个月前，Jito 推出了一个新特性，用于缓解三明治攻击，而无需使用投票账户方法。这一机制的推出标志着 Jito 在提高交易安全性方面迈出了重要一步。为此，我编写了一个 Demo 仓库，展示了如何使用这一机制，并提供了相关示例。

Jito 的三明治攻击缓解机制

机制简介

Jito 通过新增一个特殊格式的账户来实现三明治攻击的缓解。其基本规则如下：

在 Solana 交易中，添加任何有效的 Solana 公钥，并确保该公钥以 jitodontfront 开头。例如：

jitodontfront111111111111111111111111111111 或
jitodontfront111111111111111111111111111123

任何包含 jitodontfront 账户的交易都将被区块引擎拒绝，除非该交易出现在 Bundle 中的第一位（索引 0）。
该账户不需要在链上存在，但必须是一个有效的公钥。
建议将该账户标记为只读，以优化处理速度。

允许的 Bundle 模式

[tx_with_dont_front, tip]
[tx_with_dont_front, arbitrage, tip]

不允许的 Bundle 模式

[tip, tx_with_dont_front]
[txA_with_dont_front, txB_with_dont_front]
[txA_with_dont_front, txB_with_dont_front, tip]
[trade, tx_with_dont_front, arbitrage, tip]

重要提示

该账户不需要在链上存在，但必须是一个有效的公钥。
将该账户标记为只读以优化处理速度。
可选：为您的应用程序使用 jitodontfront 的唯一变体（注意：使用您自己的公钥）。例如：
- jitodontfront111111111114511111111111111123
- jitodontfront111111111111234565432123456782
该解决方案支持 Jito 的 sendBundle 和 sendTransaction 接口，而不像投票账户方法那样不兼容。
支持 Address Lookup Tables（ALT）。

示例

您可以查看以下使用该保护机制的示例 Bundle： Jito Bundle Explorer 示例

Demo 仓库

为了展示这个机制的实现，我写了一个 Demo 仓库，其中包含了一个基于 Jito Bundle 交易功能的演示，并实现了三明治攻击保护机制。您可以通过此仓库学习如何将这一新特性应用到 Solana 交易中。

免责声明

尽管该特性可以帮助减少三明治攻击的发生，但并不能保证完全解决所有类型的交易排序问题，特别是第三方排序问题。此外，此功能仅适用于区块引擎，无法应用于其他软件。

此机制的推出为 Solana 生态系统中的交易提供了更高的安全性和防护，尤其是在去中心化金融（DeFi）交易中防止恶意攻击。

一个为所有对学习和构建 Solana 感兴趣的人提供的全面、真实的资源中心

aaa — Mon, 31 Mar 2025 08:21:14 +0800

欢迎阅读原文翻译https://github.com/brooke007/solana-awesome-zh

solana-awesome

一个为所有对学习和构建 Solana 感兴趣的人提供的全面、真实的资源中心

Solana 简介
Solana 基础
开发者资源
压缩
Solana 移动端
Solana 支付
验证者
观点和文章
Solana 的未来

Solana 简介

标题	类型	作者	链接	描述
Solana 架构新手指南	文章	Anvit Mangal	链接	Solana 架构的总体概述
那么 Solana 到底是怎么回事	文章	hana	链接	对 Solana 基础知识的一种有趣的视角，适合技术读者
在 Solana 上编程 - 简介	文章	Paul X	链接	对在原生 Rust 中进行 Solana 编程的介绍
Solana：单体	文章	Ceteris	链接	Delphi Digital 对 Solana 的全面深入研究
Solana：工作原理 - Solana 协议的执行概述	报告	Lostin	链接	Solana 核心协议的整体概述。
Solana 编程模型：Solana 开发简介	文章	0xIchigo	链接	关于 Solana 架构、账户模型和交易的介绍性文章

Solana 基础

标题	类型	作者	链接	描述
使 Solana 成为第一个 Web 规模区块链的 8 项创新	文章	Anatoly Yakovenko	链接	Solana modus operandi 的八项关键技术概述
Solana 共识	文章	Ryan Chern	链接	一篇阐明历史证明在 Tower BFT（Solana 的共识机制）的插槽中的作用的文章
Solana 交易的生命周期	文章	Umbra Research	链接	Solana 运行时如何处理交易以及 Solana 和 Ethereum 上的交易执行之间的差异的概述
Solana 上的本地费用市场	推文	7Layer	链接	一个解释 Solana 区块空间结构的 Twitter 帖子，阐明了费用市场是什么、它们如何工作以及为什么它们有用
优先级费用：了解 Solana 的交易费用机制	文章	0xIchigo	链接	了解 Solana 的交易费用机制、优先级费用以及如何以编程方式实现它们
Solana 费用	文章	Umbra Research	链接	了解当今 Solana 的费用如何运作
Solana 内部原理	文章	Sec3	链接	一个深入探讨 Solana 内部原理的 4 部分系列，适合技术读者
Solana 节点 - Solana RPC、验证器和 RPC 提供商入门	文章	Mert Mumtaz	链接	了解 Solana 节点、不同类型、它们的重要性以及顶级 RPC 提供商
Solana 权益证明 + 历史证明入门	文章	Shinobi Systems	链接	深入探讨历史证明 (PoH) 是什么以及它是如何工作的，适合技术读者
Solana 的海湾流：无内存池，问题多多	文章	Lostin	链接	对海湾流（Solana 的无内存池交易转发协议）的探索
股权加权服务质量：您需要了解的一切	文章	0xIchigo	链接	了解 SWQoS、Solana 如何处理交易以及验证器和股权日益增长的重要性
Solana 白皮书	白皮书	Anatoly Yakovenko	链接	Solana 的圣经文本
关于 Solana 本地费用市场的真相	文章	Lostin	链接	本文对 Solana 当前本地费用市场的状态以及需要改进的地方进行了通俗易懂的分析。
Turbine：Solana 上的区块传播	文章	Ryan Chern	链接	了解 Solana 上的区块传播、它与 Ethereum 的比较以及区块传播和数据可用性的未来研究途径
了解 Solana 上的 Slot、Block 和 Epoch	文章	Mert Mumtaz	链接	深入探讨 Solana Slot、Block 和 Epoch 如何协同工作
Solana 代币扩展入门	文章	Yash Agarwal	链接	深入探讨 Solana 令牌扩展 (Token 2022)，探索它们的用例，以及它们为何可能成为 Solana 令牌化叙事的下一个主要催化剂。

开发者资源

通用学习资源

标题	类型	作者	链接	描述
60 天 Solana	教程	Rareskills	链接	一个为具有 Ethereum 或 EVM 开发的初级或中级背景的工程师设计的 60 天 Solana 课程
从头开始创建一个 Solana dApp	教程	Loris Leiva	链接	一个关于构建简化版 Twitter 作为 Solana dApp 的系列
Rust + Solana 高级开发课程	教程	ICB	链接	一个免费的高级 Solana 开发课程
Solana Bootcamp	视频	Solana Foundation	链接	一个视频海盗主题训练营，用于快速掌握 Solana 编程
Solana Bytes	视频	Solana Foundation	链接	一系列解释核心开发和 Solana 概念的短视频
Solana 课程	教程	freeCodeCamp	链接	旨在作为 Solana 开发介绍的引导式互动项目
Solana 教程	视频	Solana Foundation	链接	关于 Solana 和 Anchor 的综合视频
SolDev 的 Solana 开发课程	教程	Various	链接	一个学习 Solana 开发的完整课程
Solana Cookbook	文档	Various	链接	一个开发者资源，提供在 Solana 上构建的基本概念和参考资料

Anchor 开发

标题	类型	作者 (s)	链接	描述
Anchor 简介：构建 Solana 程序的初学者指南	文章	0xIchigo	链接	学习您需要知道的一切，以开始使用 Anchor 在 Solana 上进行构建。
Anchor	文档	Coral	链接	Anchor 的官方文档，适用于 Solana 的 Sealevel 运行时框架。
使用 React 和 Anchor 的全栈 Solana 开发	文章	Solana 基金会	链接	逐步演示如何构建、测试和部署一个 Anchor 程序和 React 前端。
开始使用 Anchor 框架	文章	Solana 基金会	链接	介绍 Anchor，涵盖一个简单程序、IDL 和 TypeScript 客户端。
Anchor / Solana 开发简介	视频	Harry Papacharissiou, Chainlink	链接	适合初学者的 Solana 和 Anchor 开发简介。
Poseidon	框架	Turbin3	链接	转换 Solana 程序的翻译器，将其从 TypeScript 转换为 Anchor。
Solana 智能合约教程：使用 Anchor 框架	视频	Josh's DevBox	链接	介绍 Anchor，属于 “Solana 开发教程”系列。
Anchor 书籍	文档	Coral	链接	一本入门书籍，帮助您开始学习 Anchor。

非 Anchor 程序开发

标题	类型	作者	链接	描述
Pinocchio	框架	Anza	链接	创建没有依赖项的 Solana 程序。
Steel	框架	Regolith Labs	链接	Solana 智能合约框架。

测试程序

标题	类型	作者 (s)	链接	描述
Solana 程序测试指南	文章	0xIchigo	链接	了解如何测试 Solana 程序，从理论到实际示例。
Bankrun	框架	Kevin Heavey	链接	为 Solana 程序编写的轻量级、灵活的测试框架，使用 Node.js。
LiteSVM	框架	LiteSVM 团队	链接	快速、轻量级的测试库，创建针对程序开发者优化的进程内 Solana 虚拟机。
Mollusk	框架	Joe Caulfield	链接	小巧快速的 SVM 程序测试工具。
solana-program-test	框架	Anza	链接	一个基于 Rust 的测试框架，围绕 BanksClient 进行开发。
solana-test-framework	框架	Halborn	链接	Halborn 开发的 solana-program-test 的扩展。
使用 Anchor 进行测试	视频	Harry Papacharissiou, Chainlink	链接	在 Chainlink 2022 春季黑客马拉松中进行的关于测试 Anchor 程序的直播。

程序安全

标题	类型	作者 (s)	链接	描述
Solana 程序安全的穿越指南	文章	0xIchigo, bl0ckpain	链接	了解 Solana 程序安全以及如何缓解常见漏洞。
Sealevel 攻击	GitHub 仓库	Coral	链接	常见的针对 Solana 编程模型的攻击示例以及使用 Anchor 避免它们的推荐示例。
Solana 审计和安全资源	GitHub 仓库	0xsanny	链接	用于研究 Solana 智能合约安全、审计和漏洞的资源合集。
Solana：审计师的入门介绍	文章	OtterSec	链接	关于 Solana 的安全性，探讨基础运行时环境、安全边界和影响的安全导论。
Solana 智能合约：常见陷阱及如何避免	文章	Neodyme	链接	关于常见 Solana 安全陷阱及其缓解措施的简要介绍。

Crates 和 SDKs

标题	类型	作者 (s)	链接	描述
helius	Crate	Helius	链接	一个异步 Helius Rust SDK，用于构建 Solana 的未来。
helius-sdk	SDK	Helius	链接	一个 Helius Node.js SDK，用于构建 Solana 的未来。
solana-program	Crate	Anza	链接	所有 Solana 链上 Rust 程序的基础库。
solana-sdk	Crate	Anza	链接	官方 Solana SDK，用于用 Rust 编写客户端应用程序。
@solana/web3.js	SDK	Anza	链接	一个为 Solana 构建的 JavaScript 客户端，基于 Solana JSON RPC API。

开发工具

标题	类型	作者 (s)	链接	描述
Bubblegum	程序	Metaplex	链接	创建和管理 Metaplex 压缩 NFT。
Builderz dApp Scaffold	工具	Builderz Labs	链接	一个开源的 Next.js Solana dApp 脚手架。
Builderz xNFT Scaffold	工具	Builderz Labs	链接	一个开源的 Next.js Solana xNFT 背包脚手架。
cNFT 垃圾邮件过滤器	工具	Solarnius	链接	一个开源、轻量和可移植的 cNFT 垃圾邮件分类器。
create-solana-dapp	工具	Solana 基金会	链接	创建 Solana dApps 的 CLI。
Dreamcast	框架	Joey Meere	链接	在几分钟内获取和交互 Anchor 程序。
Gill	框架	Solana 基金会	链接	用于与 Solana 区块链交互的 JavaScript/TypeScript 客户端库。
Kite	框架	Helius	链接	现代 TypeScript 框架，适用于 @solana/web3.js 2.0。
Kinobi	框架	Metaplex	链接	为您的 Solana 程序生成强大的客户端。
Lighthouse	框架	Jac0xb	链接	Solana 断言协议。
Metaboss	工具	Metafrost	链接	Metaplex NFT 标准的瑞士军刀工具。
PubKey Link	工具	Beeman	链接	基于 Solana 的免费开源 Discord 验证。
PubKey Stack	工具	Beeman	链接	一个用于使用 PubKey 堆栈生成应用程序的起始工具。
Shank	框架	Metaplex	链接	从 Solana Rust 合同中提取 IDL。
Skeet	框架	Skeet Dev	链接	一个开源的 TypeScript 无服务器框架。
Solita	框架	Metaplex	链接	Solana IDL 到 API 生成器。
sol4k	框架	Sasha Shpota	链接	用于 Solana 的 Kotlin 客户端，可与 Java 或任何其他 JVM 语言以及 Android 一起使用。
Squads CLI	工具	Squads	链接	通过简单的 CLI 与 Squads 多签程序进行交互。
Turnkey Rust Client	框架	Eliascm17	链接	与 Turnkey API 进行交互的 Rust 接口，允许通过安全 enclave 安全存储和签名交易。
Umi	框架	Metaplex	链接	用于 JavaScript 客户端的 Solana 框架。
Wallet Adapter	框架	Anza	链接	適用于 Solana 应用程序的模块化 TypeScript 钱包适配器及组件。

浏览器

标题	类型	作者 (s)	链接	描述
SOL CLI Explorer	探索器	cavemanloverboy	链接	一个用于 Solana 区块链的命令行探索器。
Solana Explorer	探索器	Solana Labs	链接	Solana 集群的官方探索器。
SolanaFM	探索器	SolanaFM 团队	链接	一个友好的 Solana 浏览器。
Solscan	探索器	Solscan 团队	链接	用户友好且实时扫描 Solana 生态系统的工具。
XRAY (旧版)	探索器	Helius	链接	由 Helius 提供的可读性强的 Solana 交易探索器。

性能仪表板

标题	类型	作者 (s)	链接	描述
Chainstack Compare	节点性能监控仪表板	Chainstack	链接	在时间上比较 Solana 节点的 RPC 性能仪表板，包括交易落地率。

游戏

标题	类型	作者 (s)	链接	描述
Foundation Kit	框架	Star Atlas	链接	为虚幻引擎 4 和 5 创建的插件，允许虚幻游戏客户端连接和与 Solana 交互。
GameShift	框架	Solana 实验室	链接	一个平台，方便游戏开发者通过单一 API 轻松集成 Web3 元素。
Godot SDK	框架	ZenRepublic, Virus-Axel	链接	使 Godot 能够制作链上和 Solana 集成游戏的 GDExtension。
Honeycomb Protocol	框架	Honeycomb Protocol 团队	链接	为游戏开发者设计的一整套 Web3 工具。
MagicBlock	游戏引擎	MagicBlock 团队	链接	一款用于链上 SVM 游戏的多功能引擎。
Solana Unreal SDK	框架	Bifrost Technologies	链接	用于在 Solana 上使用虚幻引擎 5 构建区块链游戏的完整虚幻插件和工具包。
Solana Unity SDK	框架	MagicBlock 团队	链接	一套全面的开源工具，方便在基于 Unity 的游戏中轻松访问 Solana。
Thugz BC Plugin Packaged	框架	ThugzLabs	链接	Thugz Labs BC 插件的打包版本，适用于虚幻引擎。
Turbo	游戏引擎	Jozanza	链接	特别为快速制作低分辨率、基于精灵的 2D 游戏而构建。

压缩

标题	类型	作者 (s)	链接	描述
关于 Solana 状态压缩的所有知识	文章	0xIchigo	链接	了解状态压缩、压缩 NFT（cNFT）以及如何获取、铸造或转移它们。
使用并发梅克尔树压缩数字资产	白皮书	Jarry Xiao, Noah Gundotra, Austin Adams, Anatoly Yakovenko	链接	状态压缩背后的理论。
使用 JavaScript 创建压缩 NFT	文章	Solana 基金会	链接	创建树、铸造、读取和转移 cNFT 的逐步指南。
探索 Solana 上的 NFT 压缩	文章	Mert Mumtaz	链接	了解如何在 Solana 上处理 NFT 压缩。
如何使用 TypeScript 铸造 Solana 压缩 NFT（cNFT）	文章	kishi.sol	链接	使用 TypeScript 铸造 cNFT 的逐步指南。
状态压缩	文档	Solana 基金会	链接	状态压缩的官方文档。
状态压缩与压缩 NFT	GitHub 仓库	solana-developers	链接	使用压缩 NFT 的示例代码。
同时在 Solana 上铸造多个压缩 NFT (cNFT) 的小贴士	文章	kishi.sol	链接	同时铸造多个 cNFT 的小贴士。
ZK 压缩	文档	Helius x Light Protocol	链接	一种旨在减少状态成本几个数量级的新原语。

Solana 移动端

标题	类型	作者 (s)	链接	描述
5 分钟内构建 cNFT 铸币移动应用	文章	Anam Ansari	链接	涵盖如何构建 cNFT 铸造 Android 应用程序的教程。
iOS 上的密钥托管	文章	Mike Sulistio	链接	深入探讨 iOS 上密钥托管的模式和挑战。
移动 dApp 架构	文档	Mike Sulistio	链接	移动 dApp 架构概述，包括移动钱包适配器协议。
发布 Solana 移动应用的指南	文章	0xSolanaGirl	链接	在 Solana 移动 dApp 商店发布的必要步骤和资源。
Solana 移动堆栈	文档	Solana Mobile Team	链接	有关在 Solana 上进行移动开发的全面资源。
Solana 移动教程应用	GitHub 仓库	solana-mobile	链接	展示 Solana 移动堆栈（SMS）的教程应用程序集合。
Solana 的令牌门控 - Solana 移动教程	文章	0xSolanaGirl	链接	学习如何使用 Saga Genesis Token 创建令牌门控体验。

Solana 支付

标题	类型	作者 (s)	链接	描述
Shopify 和 Solana Pay：逐步指南（2023）	文章	Owen Venter	链接	集成 Solana Pay 到 Shopify 商店的详细指南，涵盖商户设置和客户流程。
Solana Pay	GitHub 仓库	Anza	链接	一种新的去中心化支付标准。
Solana Pay Android 示例	GitHub 仓库	Solana Mobile Team	链接	针对 Android 钱包处理外部生成的 Solana Pay URI 的集成指南
Solana Pay: 所有你需要知道的事情	文章	Owen Venter	链接	Solana Pay 是一种标准协议和参考实现的集合，可以实现去中心化支付。
用 100 秒解释 Solana Pay	视频	Abdullah Raza	链接	一个有趣且简明扼要的解释，讲述了 Solana Pay 的工作原理、用途和优点。
Solana Pay 规范	文档	Anza	链接	Solana Pay 的规范文档。

验证者

Agave 客户端

标题	类型	作者 (s)	链接	描述
Agave	GitHub 仓库	Anza	链接	Anza 的 Solana Labs 验证者客户端的分支。
Agave 过渡	文档	Anza	链接	Solana Labs 客户端迁移到新的 Agave 客户端的过程。
Anza 的新 SVM API	文章	Joe Caulfield	链接	定义 SVM 以及项目能够构建的内容。
Solana Labs 验证者客户端	GitHub 仓库	Solana Labs	链接	OG 验证者客户端。
Agave 运行时	文章	Joe Caulfield	链接	深入探讨 Agave 运行时。

Firedancer

标题	类型	作者 (s)	链接	描述
Breakpoint 2023: Firedancer 更新	视频	Dan Albert	链接	Dan Albert 在 Breakpoint 2023 上介绍的 Firedancer 更新。
Breakpoint 2023: FPGA 以 8M TPS 工作	视频	Kaveh Aasaraai, Kevin Bowers	链接	在 Breakpoint 2023 上的演讲，演示 Firedancer 如何在一台 8 年旧的机器上，以 7 年旧的 FPGA 实现 800 万 TPS。
Breakpoint 2023: 网络通信的快速 Reed-Solomon 编码	视频	Philip Taffet	链接	在 Breakpoint 2023 的演讲，讲述 Firedancer 如何优化 Reed-Solomon 编码以用于其网络通信。
Breakpoint 2023: Securing Firedancer	视频	Felix Willhelm	链接	在 Breakpoint 2023 的演讲，讨论 Firedancer 的安全考虑和实现。
Firedancer	GitHub 仓库	Firedancer 团队	链接	Firedancer 是 Jump Crypto 的 Solana 共识节点
Firedancer 可靠性努力	文章	Richard Patel	链接	本文介绍了 Firedancer 如何提高 Solana 的吞吐量和可靠性
Firedancer 的 fd_quic 技术里程碑	主题	Firedancer 团队	链接	一个关于 Firedancer 高性能实现 QUIC 和 Solana 吸收网络协议的 Twitter 线程
Jump Crypto 着手构建新的验证者客户端，以提高 Solana 区块链的吞吐量和可靠性	文章	Kevin J Bowers	链接	Jump Crypto 的 Firedancer 宣告
跳跃与光速的比较	文章	Kevin J Bowers	链接	“光速太慢了”
Firedancer 是什么？深入了解 Solana 2.0	文章	0xIchigo	链接	了解关于 Firedancer 的所有信息，这是 Jump 开发的 Solana 新独立验证者客户端

更新

标题	类型	作者	链接	描述
关于 Solana 的 v1.16 更新你需要知道的一切	文章	0xIchigo	链接	了解 Solana 的 v1.16 更新，这是 Solana Labs 验证者客户端的最新升级
关于 Solana 的 v1.17 更新你需要知道的一切	文章	0xIchigo	链接	了解 Solana 的 v1.17 更新，这是 Solana Labs 验证者客户端的最新升级，以及最近的二月份网络故障
关于 Solana 的 v1.18 更新你需要知道的一切	文章	0xIchigo	链接	了解关于 Solana Labs（现为 Agave）客户端的最新更新，以及新的中央调度程序
Agave v2.0 更新你需要知道的一切	文章	Lostin	链接	总结了 Solana Agave 2.0 的关键特性和优化，包括系统调用、经济变化和 ZK ElGamal 证明
Agave v2.1 更新：你需要知道的一切	文章	Lostin	链接	总结了 Solana Agave 2.1 客户端更新中需要关注的所有主要发布周期特性和优化

结构

标题	类型	作者	链接	描述
介绍中央调度器：Agave v1.18 的可选功能	文章	Rex St. John	链接	介绍 Agave v1.18 更新中的新中央调度器
关于 Solana 9 月 14 日故障的反思	文章	Jump Crypto	链接	对早期 Solana 故障事件的深入分析
Solana 银行阶段和调度器	文章	Andrew Fitzgerald	链接	深入解释 Solana Labs 验证器客户端在块生产中使用的历史、当前和即将到来的调度算法和设计
从基本原理看 Solana 的发行	文章	Matt Resnick	链接	从根本上了解 Solana 的发行及当前的发行是否最优
聚焦：Solana 的调度器	视频	Solana Foundation	链接	对 1.17 版调度器的关键分析，交易如何通过银行阶段，以及未来 1.18 版调度器的工作原理
Solana eBPF 虚拟机	文章	Joe Caulfield	链接	了解 rBPF 虚拟机的工作原理，以及验证者如何使用它执行程序
Solana 验证者 101：交易处理	文章	Jito Labs	链接	对交易生命周期的技术深入探讨

运营、维护与经济学

标题	类型	作者 (s)	链接	描述
如何设置 Solana 验证者	文章	John Sloboda	链接	学习如何启动和运行 Solana 主网验证者
运行 Solana 验证者：全面解析	文章	Fikunmi Ajayi-Peters	链接	关于验证者、运行一个的经济学与盈利能力的全面指南
设置 Solana 验证者	文档	Solana Foundation	链接	Solana 官方文档，关于运行验证者的信息
从第一原则看 Solana 的发行	文章	Max Resnick	链接	学习 Solana 的发行方式及当前发行是否最优
Solana 验证者经济学：入门	文章	Ryan Chern	链接	Solana 验证者经济学的入门指南
Solana 验证者运营最佳实践	文档	Solana Foundation	链接	Solana 官方文档推荐的最佳实践
验证者利润计算器	工具	Cogent Crypto	链接	用于估计验证者在假设场景下的收益的工具

观点和文章

标题	类型	作者 (s)	链接	描述
超越技术男：重新思考加密领域中的偶像崇拜	文章	0xIchigo	链接	个人崇拜、大人物的历史理论、思想的力量、去中心化领导、草根组织、加密乐观主义。
狗币、猫视频和颠覆	文章	Mikel Ayala	链接	对 meme 币、注意力经济、在线社区和数字原生资本的批判性分析
铸造去中心化的知识——每个革命都需要一个火花	文章	M3taversal	链接	对一项变革性 Web3 项目的本质进行批判性分析，旨在创建一个经得起时间考验的知识库。
Solana：如何颠覆区块链	文章	Lee Nguyen	链接	从创始到未来的 Solana 故事。
Solana 夏季	文章	Packy McCormick	链接	关于 Solana 故事的全面而引人入胜的阅读。
SOL 生存者	文章	0xsmac	链接	关于 Solana 成为一个引人注目的资产和网络的独特视角。
几亿用户之路	文章	James Carlin	链接	对区块链的未来以及用户破十亿用户的乐观分析
Helius 宣言	宣言	Mert Mumtaz	链接	Helius 的使命是提高全球开发者的经济潜力。我们相信，这只有通过加密基础设施才能实现。
Solana 繁荣的那一年	文章	Ryan Shea	链接	对于任何对 Solana 感兴趣的人来说，这是一篇必读的文章。
为什么选择 Solana	文章	Mert Mumtaz	链接	关于在 Solana 上构建的个人观点。
Solana 论点 - 最快的马是如何从灰烬中崛起的	文章	Ryan Watkins, Wilson Withiam, Daniel Cheung	链接	一篇全面的论文，解释 Solana 的“为什么”。

Solana 的未来

标题	类型	作者 (s)	链接	描述
Solana 中的异步程序执行 (APE)	文章	Anatoly Yakovenko	链接	一篇推特文章，讨论异步执行以及独立于其他程序运行投票程序的目标。
Solana 上的状态增长问题	文章	Anatoly Yakovenko	链接	一篇推特文章，讨论 Solana 状态的快速增长及其潜在解决方案。

参考

原文：solana-awesome
作者：helius-labs
译者：[brooke007]
日期：2025-03-31

教你代币安全监测

aaa — Tue, 15 Oct 2024 14:03:08 +0800

原文：https://github.com/Solana-ShenZhen/blog/blob/main/tokencheck.md
作者：brooke007

炒币的时候经常会遇到一些盘，如果你盲目的冲进去，可能就完蛋了。比如说 https://dexscreener.com/solana/36kqsauU1HLRxecizvXWMosV1t1mQEeaeXDEfZLvkRY4 这个盘，最高的时候涨到 773.2M，然后迅速砸盘，一切都发生在三个小时以内。这就是因为他的 mint authority 还存在，每当有人买入，他就迅速冻结那个人币，导致别人只能买不能卖。你现在看这个盘可能发现 mint authority 已经是 none 了，但是之前是还有的，他修改 authority 是https://solscan.io/tx/3v3EuUm19Vii9vNNfexvgg7rFgy1wcmtGQemRZ94yUsk1awY9eLRGPpVUPMPxmL5WsDUi5Du8a5Ray4V1eCb55ot这个交易。

本文将简单判断代币是否是貔貅盘以及计算计算 LP 燃烧的比例。判断代币是否还有 mint 权限是看mint authority ,判断代币是否是貔貅盘，本质上是看代币的 freeze authority是否还在。计算 LP 燃烧的比例则是直接通过 pool 的 address，来看这个池子里的 lp 供应量（supply）和储备量，来计算整个的比例判断 burn 了的比例先引入一些包

import { nu64, struct, u32, u8, Layout } from "@solana/buffer-layout";
import { Connection, PublicKey } from "@solana/web3.js";
import type { ParsedAccountData } from "@solana/web3.js";
import { LIQUIDITY_STATE_LAYOUT_V4 } from "@raydium-io/raydium-sdk";
import dotenv from "dotenv";
import { logger } from "./logger";

然后自定义 boollayout 以及 publickeylayout 类，这两个的作用主要是定义在 buffer 中如何读取和存储这两个类型的数据

class PublicKeyLayout extends Layout<PublicKey> {
  constructor(property: string) {
    super(32, property);
  }

  decode(buffer: Buffer, offset = 0): PublicKey {
    return new PublicKey(buffer.slice(offset, offset + this.span));
  }

  encode(src: PublicKey, buffer: Buffer, offset = 0): number {
    buffer.set(src.toBytes(), offset);
    return this.span;
  }
}

const publicKey = (property: string) => new PublicKeyLayout(property);

class BoolLayout extends Layout<boolean> {
  constructor(property: string) {
    super(1, property);
  }

  decode(buffer: Buffer, offset = 0): boolean {
    return buffer[offset] === 1;
  }

  encode(src: boolean, buffer: Buffer, offset = 0): number {
    buffer[offset] = src ? 1 : 0;
    return this.span;
  }
}

const bool = (property: string) => new BoolLayout(property);

接下来就是定义 token 的结构

export interface Token {
  mintAuthorityOption: 1 | 0;
  mintAuthority: PublicKey;
  supply: bigint;
  decimals: number;
  isInitialized: boolean;
  freezeAuthorityOption: 1 | 0;
  freezeAuthority: PublicKey;
}

export const MintLayout = struct<Token>([
  u32("mintAuthorityOption"),
  publicKey("mintAuthority"),
  nu64("supply"),
  u8("decimals"),
  bool("isInitialized"),
  u32("freezeAuthorityOption"),
  publicKey("freezeAuthority"),
]);

解析直接调用 decode 方法即可

export const fetchAndParseMint = async (
  mint: PublicKey,
  solanaConnection: Connection
): Promise<Token | null> => {
  try {
    let { data } = (await solanaConnection.getAccountInfo(mint)) || {};
    if (!data) return null;

    return MintLayout.decode(data);
  } catch {
    return null;
  }
};

获取池子的信息然后计算比例

export const fetchLiqudityPoolState = async (
  pool: PublicKey,
  solanaConnection: Connection
) => {
  try {
    const acc = await solanaConnection.getMultipleAccountsInfo([
      new PublicKey(pool),
    ]);
    const parsed = acc.map((v: any) =>
      LIQUIDITY_STATE_LAYOUT_V4.decode(v.data)
    );

    const lpMint = parsed[0].lpMint;
    const lpReserve = parsed[0].lpReserve;

    const accInfo = await solanaConnection.getParsedAccountInfo(
      new PublicKey(lpMint)
    );
    const mintInfo = (accInfo.value?.data as ParsedAccountData)?.parsed?.info;

    const lpReserve2 = lpReserve / Math.pow(10, mintInfo?.decimals);
    const actualSupply = mintInfo?.supply / Math.pow(10, mintInfo?.decimals);

    //Calculate burn percentage
    const maxLpSupply = Math.max(actualSupply, lpReserve - 1);
    const burnAmt = lpReserve - actualSupply;
    const burnPct = (burnAmt / lpReserve) * 100;

    return burnPct;
  } catch {
    return null;
  }
};

完整的代码可以参考我的 github

W 币用户持有者向 Binance 的转账分析

aaa — Mon, 24 Jun 2024 13:10:18 +0800

Wormhole 最近推出了质押。许多用户开始往 Binance 转入 W，这篇文章分析了最近一周的往币安转入的记录。发现最少的也往里面转了 500560000 个 W 在币安，下面将给出图表。这张图可以看出，币的数量集中在 0.050 到 1.024 的范围，后面的人数将持续减少。这张表是通过vybenetwork的 api 以及一些 python 分析得到的。使用vybenetwork

import requests
import pandas as pd
from collections import defaultdict
import matplotlib.pyplot as plt

url = "https://api.vybenetwork.xyz/token/transfers?mintAddress=85VBFQZC9TZkfaptBWjvUw7YbZjy52A6mjtPGjstQAmQ&receiverAddress=5tzFkiKscXHK5ZXCGbXZxdw7gTjjD1mBwuoFbhUvuAi9&timeStart=1717998402&timeEnd=1718603202"

headers = {
"accept": "application/json",
"X-API-KEY": "YOUR-API-KEY"
}

response = requests.get(url, headers=headers)
data = response.json()

transactions = data["transactions"]
sorted_transactions = sorted(transactions, key=lambda x: x["amount"], reverse=True)
merged_transactions = defaultdict(lambda: {'amount': 0, 'receiverAddress': None})
for transaction in sorted_transactions:
sender = transaction["senderAddress"]
amount = transaction["amount"]
receiver = transaction["receiverAddress"]
merged_transactions[sender]["amount"] += amount
merged_transactions[sender]["receiverAddress"] = receiver
result = pd.DataFrame([
{"senderAddress": sender, "amount": data["amount"], "receiverAddress": data["receiverAddress"]}
for sender, data in merged_transactions.items()
])
result = result.sort_values(by="amount", ascending=False)
result.to_csv("sorted_transactions.csv", index=False)

print(result)

另外通过得到sorted_transactions.csv得到柱状图代码如下

import pandas as pd
import matplotlib.pyplot as plt
import numpy as np

file_path = 'sorted_transactions.csv' 

data = pd.read_csv(file_path)
prices = data['amount']
min_price = prices.min()
max_price = prices.max()
num_bins = 20
bins = np.linspace(min_price, max_price, num_bins + 1)
hist, bin_edges = np.histogram(prices, bins)
plt.figure(figsize=(10, 6))
bars = plt.bar(bin_edges[:-1], hist, width=np.diff(bin_edges), edgecolor="black", align="edge")

for bar, count in zip(bars, hist):
height = bar.get_height()
plt.text(bar.get_x() + bar.get_width() / 2, height, str(count), ha='center', va='bottom')

plt.xlabel('price')
plt.ylabel('people')
plt.title('people distribution of every price bin')
plt.xticks(bin_edges, rotation=45)
plt.grid(axis='y')
plt.savefig('chart_of_sorted_distribution2.png')

plt.show()

服务于 DePIN 的区块链基础设施的设计思路

aaa — Sun, 09 Jun 2024 01:09:27 +0800

原文：https://learnblockchain.cn/article/8227

本文描述了设计一个面向 DePIN 提供区块链底层服务的基础设施应考虑哪些问题，以及如何完成设计。该方案基于 BoAT3 Oracle。

概述

随着模块化区块链技术的落地，区块链解决了困扰已久的性能问题，这为需要高吞吐量，服务于海量用户的 DApp 的落地创造了条件。DePIN 是典型的这类场景。DePIN 属于 RWA，其价值相对稳定，可预期，且能将区块链服务带向更广泛的用户，成为区块链大规模使用的推手，让区块链服务于现实世界，因此成为热门技术。然而 DePIN 项目本身横跨 IoT 设备，区块链，传统互联网服务，经济学等多个领域，涉及硬件，软件，密码学等多种技术，从头到尾地构建 DePIN 项目是件复杂，困难的工作。本文尝试分析 DePIN 项目的运行原理，并介绍如何使用 DePIN App Chain 快速构建 DePIN 项目。

DePIN 项目运行原理

DePIN 项目的运行原理一般为：

PoPW 生成和上传：矿工们购买矿机并搭建 DePIN 项目网络。矿机一般是具有联网能力的，能提供特定服务能力的 IoT 设备（如太阳能电池板，信号基站等）。IoT 设备在工作中会收集其工作的证明，称为 PoPW(Proof of Physical Work)。IoT 设备将该 PoPW 发送至 DePIN 网络。
PoPW 的验证和保存：DePIN 网络中使用技术方法验证该 PoPW 的正确性，有效性。这一般是通过链下的 Oracle 服务完成的。验证完成后，正确且有效的 PW（Physical Work）数据可能会被保存下来供后期追溯和验证。因为 IoT 设备一般数量巨大，PW 总数据量一般会很大，因此 PW 数据一般被保存在链下（如 FIL，Arweave 等去中心化可信存储网络），并将其抽象汇总后，将批量数据的承诺保存在链上。
奖励发放：可信 Oracle 或链上合约通过 PW 数据计算出矿工奖励，并完成发放。奖励可能需要矿工主动在链上领取，也可能在链上直接转账，这取决于信任和成本的设计。
奖励兑换：矿工将获取的链上 Token 奖励通过 CEX,DEX 等渠道兑换成法币，覆盖其购买和运行矿机的成本，并获取利润，形成价值飞轮。

让我们拿起放大镜，来把上述流程看的更仔细一些！

2.1 PoPW 的生成

IoT 设备在工作中会不断产生 PW 数据，如太阳能电池板的发电数据，基站的服务数据等。但如何能让 DePIN 网络相信这台 IoT 设备矿机没有凭空捏造自己的数据，甚至有人在没有矿机的情况下，凭空创造出这些数据呢？一般有两种方法：

IoT 设备都包含通讯模组，通讯模组中一般会包含 TEE 模组，TEE 模组中可以安全地保存私钥并进行密码学运算。项目方可以在生产矿机时在 TEE 内生成非对称密钥对（公私钥），并取出公钥，将公钥在区块链上注册为 DID（此工作也可由 IoT 相关芯片生产商等完成）。由于 TEE 的安全设计，项目方和矿工均无法获得其私钥。IoT 设备生成的 PW 数据可以被发送至 TEE，由其内保存的私钥签名后，签名数据即为 PoPW，将此 PoPW 发送至 Oracle 后，Oracle 可通过链上注册的设备 DID 查询到该设备的公钥，从而验证签名的正确性。该方案原理简单，安全性可信度都非常高，但对 IoT 设备采用的通信模组有一定要求。幸运的是 BoAT3 Infra 已经适配了多种通信模组芯片，可以满足各种 DePIN 项目对 IoT 设备的需求。项目方仅需在其矿机中使用适配的通信模组即可。
市场上有很多 IoT 平台，以及云服务厂商提供数据存储加工功能。IoT 设备生成的数据会被送至这些平台存储和处理。可以由这些平台做信用背书，送至平台的原始数据由平台的私钥签名后，作为 PoPW 使用。该方案要求送至平台的，未经加工的原始数据被平台签名作为信任来源。因此需额外信任平台不会作恶。安全性略低于方案 1，但适用范围更广。

2.2 PoPW 的验证：BoAT3 Oracle

DePIN 网络中的 IoT 设备矿机数量一般很多，如上万台，甚至上百万台。因此生成的 PoPW 数量也非常巨大。这些 PoPW 在链上验证会产生巨大的成本，且没有必要。因此这些数据一般是通过 Oracle 完成验证的。BoAT3 Oracle 可以处理上述 1，2，方式产生的 PoPW。其原理如下：

PoPW 被传至 BoAT3 Oracle 后，Oracle 通过链上 DID 合约获取其公钥，使用公钥验证 PoPW 合法性。如果合法性验证通过，就会将 PW 数据传输至 Connector，表示该 PW 已被认可，Connector 中的运行逻辑由 DePIN 项目方决定，可以将该 PW 数据发送至链上合约进行奖励，也可以按照奖励规则收集到合适数量/时间的 PW 后进行奖励。

PW 数据量一般很大，不会直接将 PW 数据全部上链，而是将其保存在去中心化存储网络中（例如 FIL, Arweave)，计算出其数据承诺（如将数据构建 Merkle 树，Merkle 树根即为数据承诺），将数据承诺以及获取数据的方法放至链上。每次奖励周期均可在链下获取生成奖励的原始数据。

2.3 BoAT3 Oracle 和 DePIN 项目脚手架

因为 DePIN 项目涉及到的模块相对比较多，为了便于项目开发和实施，BoAT3 Oracle 提供的了几个工具供 DePIN 项目方使用，主要包括：

BoAT3 cli：用来创建基于 BoAT3 Oracle 的 DePIN 项目的命令行工具
BoAT3 scaffold：提供 DePIN 项目合约/物模型/Connector 参考实现的脚手架应用
BoAT3 console：用于 DePIN 项目信息查看/购买的网站

2.4 奖励发放和兑换

奖励发放一般由 Oracle 完成，可以在链上直接发放；也可以将发放承诺/证明上链，由矿工在链上领取，这样可以减少链上交易，降低发放成本。

无论使用哪种方式发放，都需要向社区证明奖励的发放符合规则。每次奖励发放时，Oracle 通过 PW 数据计算哪些矿工可以获取奖励，以及获取多少奖励。可以将所有奖励细节生成一棵 merkle 树，每个叶子都是一个奖励的 Hash，这个 Hash 由奖励的期数，获得奖励的账户，奖励数量等数据组成。奖励树的树根可以和 PW 数据树的树根，以及其他奖励相关数据一起输入智能合约。智能合约中可以允许社区成员对奖励的分发发起并完成挑战，如果社区成员挑战成功，则 Oracle 抵押的 Token 将被罚没，并将其中可观的部分奖励给挑战者。挑战过程可以约束 Oracle 必须按规则完成奖励的分发。

矿工获取奖励后，可以通过 DEX 或 CEX 将奖励兑换成稳定币或提现成法币，可以补贴其运行矿机，维护 DePIN 网络的成本，也可以激励其进一步购买矿机，扩大 DePIN 网络规模，形成 DePIN 网络的增长飞轮。

2.5 其他 PoPW 模型

除了上述模型外，也有其他可用于 DePIN 项目的模型。例如通过区块链生成有时限的可信挑战，如每小时都在变化的随机数。该挑战会被下发至每台矿机，矿机需要在其有效时间内，结合自身的 IoT 工作数据完成挑战，并将其生成 PoPW，发回 DePIN 网络。DePIN 网络根据挑战来验证 IoT 设备的工作是否真实有效。该方案无需对 IoT 设备芯片生产商或 IoT 平台等产生信任和依赖。但如何设计完善可信的挑战机制是件很有挑战的工作，而完成挑战也许需要额外消耗 IoT 设备的计算能力和资源等，对设备硬件有较高要求。

3. 构建满足 DePIN 要求的区块链和基础设施

3.1 需求和整体架构

DePIN 项目对区块链等基础设施有如下要求：

性能和成本要求。DePIN 项目中经常包含数以万计甚至百万计的 IoT 设备，这些 IoT 设备在每个奖励周期内都会生成很多交易。因此 DePIN 项目要求区块链具有高性能，高安全性的同时，还需有非常低的成本。Rollup 作为模块化区块链方案可以同时满足这些要求，成为支持 DePIN 项目的合理选择。
存储要求。PW 或 PoPW 数据因为数量巨大，一般存储在链下，且能够被无审查地访问，有些数据还会要求长期保存。可以考虑使用可信，低成本的去中心化存储方案，如 FIL, Arweave 等，也可考虑使用云存储。需注意任何人均可读取数据。
DID 服务。链上应提供 DID 服务，可信地保存并读取 IoT 设备或服务平台的信息及公钥，用来验证 PoPW。
AA 钱包服务。两个场景可能需要 AA 钱包服务：
IoT 设备直接签发交易上链。很多 TEE 内拥有数字签名能力，可直接签发交易上链。但 IoT 设备的账号中一般不会有余额支付 gas fee，因此需要项目方使用 AA 钱包代付 gas fee.
DePIN 终端用户使用。DePIN 项目服务的终端用户很多不是 web3 用户，不熟悉钱包操作，也没有可用于支付 gas fee 的 Token，因此需要项目方使用 AA 钱包代付 gas fee，并提供类似于 web2 的用户体验。
全链服务。不太可能在一条区块链上承载很多 DePIN 项目，而 DID 和 AA 钱包等服务都需要考虑其一致性。例如同一个 IoT 设备如果需要参与多个 DePIN 项目的服务（如项目间协作），而不同 DePIN 项目可能使用了不同的区块链，因此需要该设备在不同链上注册相同的 DID；对一个终端用户来说，也可能希望在使用不同区块链上的 DePIN 服务时不需要重复注册 AA 钱包。因此各种链上服务需要具有全链服务能力。
跨链服务。不同 DePIN 项目可能需要协作，提供给用户更方便的服务。这些 DePIN 项目可能位于不同区块链上，因此需要可信的跨链服务完成 DePIN 项目间协作。
经济学支持。DePIN 项目可能数量众多，场景各式各样，大部分项目的影响力可能并不大。如果各个项目都使用自己的 Token，很可能会造成资金碎片化，用户体验也不好。因此如果能有统一的经济学机制，既可以在项目初期减少用户摩擦和扩大潜在用户群，将产品快速推向用户，又可以形成合力，提高 DePIN 项目整体影响力。
密钥可信初始化。集成于 IoT 设备里的密钥需要进行可信初始化，作为 PoPW 信任的来源。它需要做到让矿工，项目方，云服务等各个参与方都无法获取设备私钥，但可将设备公钥提取出，提交至设备 DID，后续可供 BoAT3 Oracle 验证 PoPW。

基于以上需求，考虑支持 DePIN 项目的区块链和基础设施的架构如下：

整个系统是基于 Rollup 的三层结构，包括如下核心部分：

以太坊主网。以太坊主网作为 Layer 1，成为整个系统的安全，信任的来源。为 L2 提供 DA，结算和共识。
Rollup L2。可以使用基于 OP 或 ZK 的著名 Rollup 项目，例如 Optimism, Arbitrum，ZKSync 等。这一层拥有高安全性和可信度，同时成本比较低。但由于其 DA 使用以太坊主网，所以其性能和成本尚不足以支撑大规模 DePIN 项目落地。很多支撑 DePIN 项目的，跨越多条区块链的公共服务合约会部署在这一层。例如统一的经济学，无信任跨链，全链 DID 服务等。这一层上拥有丰富的链上生态，DePIN 项目可以在这一层与丰富的链上生态互动，获得如 DEX，借贷等链上生态的支持。矿工们在 L3 的 DePIN App Chain 上获得的奖励可以轻松地跨链到 L2 层，兑换成稳定币等。
DePIN App Chain L3。这一层是 Layer3，采用 OP 或 ZK Rollup，其结算层为 L2，使用第三方 DA。其安全性和信任继承于 L2。由于采用了第三方 DA，其性能不再受制于以太坊 L1 的区块 gas limit，而且成本进一步降低。性能和成本足以支撑 DePIN 项目大规模落地。由于 DePIN 项目可能数量众多，因此一条 DePIN App Chain 可能无法支持全部项目，可能会有多条 DePIN App Chain 并行工作。它们可以通过位于 L2 的无信任跨链合约完成项目间，链间跨链协作。DePIN 项目的智能合约，以及 DID 合约等直接服务于 DePIN 项目的合约均运行于该层。
DA（Data Availability) 服务。采用第三方 DA 服务，如 Celestia, EigenDA 等。它们均采用 DAS 技术，可以保障承载的数据被完全公开给社区，避免数据扣留攻击，这对 Rollup 的安全来说是至关重要的。而且采取三方 DA 可以避免消耗以太坊 L1 的 gas 份额用于 DA，是大规模链上吞吐量扩展的基础。
数据存储服务。PW 或 PoPW 数据是构建 DePIN 项目的基础，奖励的发放一般基于该数据计算完成；另外 Rollup 如果需要进行安全挑战，则安全挑战数据可能也部分来源于 PW 数据。因此这些数据需要被安全可信地保存，可以被追溯，被授权用户可以自由读取（一般来说是完全开放的）。数据存储服务可以使用 FIL, Arweave 等去中心化存储，也可以使用云存储。为了保证数据一定能被访问到，防止数据扣留，针对数据访问的挑战流程是必要的。

下面我们来一起深入了解这些模块，以及为什么这样设计。

3.2 为什么使用 Rollup 构造区块链

Rollup 采用了模块化区块链设计，能在最大程度上继承结算链（如以太坊）的安全性。以扩展以太坊性能为例，从以太坊 L1 角度思考，L2 的安全性和信任均来自于 L1，应做到用户们只信任 L1 的情况下，仍能认为 L2 上执行的交易，以及交易结果是可信的，安全的；甚至 L1 与 L2 的智能合约之间可以互相调用。落实到实现层面，L2 需要满足如下三个要求：

L1 需要知道 L2 上发生了哪些交易
L1 需要知道 L2 上最新的世界状态，并且 L2 有能力证明世界状态是正确的
L1 和 L2 之间能完成可信的消息跨链

Sequencer（定序器）是 L2 上的共识模块，L2 上的交易都会被发送到 Sequencer 处理，Sequencer 可能是中心化的，也可能是去中心化的。Sequencer 会对收到的交易排序，并打包出块。每隔一段时间，Sequencer 会将 L2 上这段时间的所有交易压缩后，使用 calldata 提交到 L1，该过程称为 DA（Data Availability)。Sequencer 还会定期将 L2 最新的状态根提交到 L1 里的智能合约中。L2 通过 OP 或 ZK 方式保证提交的状态根是正确的。

OP：即 Optimism，乐观地认为 L2 上的 Sequencer 不会作恶，提交的状态根是正确的。但是会等待一个挑战期（一般 7 天），在挑战期内任何节点如认为状态根是错误的，均可对其发起挑战。如果挑战成功，则挑战者可以获得 Sequencer 抵押在 L1 上的抵押金。挑战是通过在 L1 上重放对 L2 上有争议的具体某笔交易，或某个 opcode 来达成的。OP 技术方案可以保证该挑战能够公平可信地完成。L2 上一般会运行着很多节点，只要有一个节点是诚实的，当它发现作恶行为时就一定会发起挑战。因此对 Sequencer 来说，作恶行为不仅意味着会失去 L1 上抵押的抵押金，其作恶提交的错误状态根也会被重置，因此方案是安全的。
ZK：即 Zero Knowledge , 使用零知识证明技术，生成一个 ZK Proof, 能够证明 L2 上的世界状态在应用当前的交易后，会转换为新的世界状态。该 ZK Proof 会被提交到 L1，在 L1 的智能合约中被验证。如果该 ZK Proof 能够验证通过，则证明当前提交的状态根是正确的。

证明 L2 的状态根正确后，即可认为所有通过 DA 提交到 L1 的交易均被正确执行了，且执行后的状态根也是正确的。因此如果这些交易中有跨链调用交易，也是可以安全执行的。

从 L2 上 Sequencer 之外的节点来看，它们并不直接信任由 Sequencer 通过 p2p 网络发出的区块，而是信任已经通过 DA 提交到 L1 的区块，并监督这些区块后续的状态根；从 L2 的用户来看，他/她们也不信任 L2 Sequencer 直接给出的交易回执和状态，而是只相信已经被提交到 L1 的区块，以及在 L1 上被验证的状态根。因此在 Rollup 架构里，信任和安全是来源于 L1 的，而不是来源于 L2。所以 Rollup 的安全性和可信度接近 L1 本身，这是一种安全可信的，效率极高的区块链扩容方案。因此选择使用 Rollup 作为服务于 DePIN 的区块链基础设施是非常合适的。

3.3 为什么使用 L2+L3 架构

虽然可以使用 Rollup 安全地扩展以太坊的性能，但是受限于 EVM 的性能和其顺序执行特性，即使加快出块速度，调高 gas limit，单条 Rollup 的性能上限也并不高，一般认为在千级别。而 DePIN 应用所需的性能是比较高的，因此一条 Rollup 无法承载太多 DePIN 应用。

DePIN 应用的场景很丰富，因此很多 DePIN 应用都会有定制需求，如隐私保护等。这些定制需求可能会需要在 Rollup 层修改来满足，而不是在合约层就能满足。因此这些 DePIN 应用需要定制的 Rollup。

综上，我们不可能用一条 Rollup 就支持所有 DePIN 项目的需求，DePIN 应用的大规模落地必定是要求多链协作的。这些协作的链之间需要一个可以信任的公共基石来进行信息的同步和交换，以及完成一些公共服务，如统一的经济学中代币的发行，我们称之为管理链，相应的，承载各个 DePIN 项目的链称为应用链，应用链包含多条 DePIN App Chain L3 链。

虽然以太坊主网是管理链的理想选择，但以它的成本比较高，性能偏低，因此以太坊上的主流 Rollup L2 是管理链的理想选择，如 Optimism, Arbitrum 等。而以管理链作为结算层的 L3 是承载应用链的合理选择，它们可以提供足够的安全性，性能扩展和足够低的链上成本。

3.4 DA 服务

DA 在 Rollup 里是非常重要的模块，它不仅让 L1 了解到 L2 上发生的交易，还是安全性的重要来源。以 OP Rollup 为例，当社区节点对 Sequencer 提交的 L2 状态根有异议，对其发起挑战时，需要在 L1 上重放有歧义的交易或 opcode，从而确认哪一方是对的。挑战中需要在合约里提交这个有歧义的交易或 opcode，此时需要使用之前提交的 DA 数据来验证挑战中提交的内容与 DA 数据是一致的。因此 DA 数据必须是可以被所有社区成员获取的，并且是可以被验证的。

最简单和安全的 DA 方案是使用以太坊 L1 作为 DA，所有 L2 交易数据被压缩后，通过 calldata 方式提交到 L1，并保存于 L1 的区块数据里。因此当挑战发生时，仅需从 L1 区块数据里便能读出所有所需的 DA 数据，不存在数据扣留风险。但 calldata 是要消耗以太坊 L1 的区块 gas 的，以太坊 L1 区块有 gas limit，因此以太坊 L1 的 gas limit 将直接决定 Rollup 扩展性能的上限。按测算，以当前的 gas limit 计算，即使所有区块 gas fee 都用作 DA，也仅能将以太坊 TPS 提升至几千级别。即使采用 L2+L3 的架构，仅使用以太坊作为 DA，也无法进一步提升性能。因为交易数据的压缩是有限的，一笔 L3 上发生的交易，压缩后提交到 L2，再由 L2 提交到 L1，其压缩率并不会比 L2 上直接提交的交易更高。

因此服务于 DePIN 的 Rollup，需考虑使用第三方 DA。该 DA 需解决数据扣留攻击的风险，即发布给 DA 的数据必须能够全部无条件被任何人公开获取，任何 DA 节点都没有能力扣留住数据不对外公布。因此 L3 Sequencer 仅需将交易数据发送到第三方 DA，并将如何获取该 DA 数据的方式（如 Celestia 上的名字空间和数据 commitment）和数据承诺等提交至 L2（即结算层）即可。L3 上的其他节点可以在 L2 上获取相关数据后，各自从第三方 DA 获取交易数据，完成链上状态的计算和挑战等工作。通过使用第三方 DA，交易数据不再大量消耗以太坊 L1 的区块 gas，这给以太坊 L1 带来了近乎无限的扩展能力，这也是 DePIN 项目所需的能力。

DA 服务一般采用 DAS(Data Availability Sample) 防止数据扣留，DAS 一般基于 Reed-Solomon 编码。假设交易数据有 N bytes，将 N bytes 交易数据转换为一个 (N-1) 阶多项式，交易数据就是该多项式的系数，即它们是该多项式上的 N 个点。在该多项式的曲线上随机抽取另外 N 个点，则使用这 2N 个点中的任意 N 个即可恢复原始数据。DA 网络中有大量轻客户端，轻客户端会分别随机对数据进行抽样。如果第一次抽样中数据可正常返回，则证明至少 50% 的数据是可获取的，进行第二次抽样时数据仍可返回，则证明至少 75% 的数据是可获取的，抽样成功的次数越多，则数据扣留的几率越小。当不重复的抽样达到 N 次及以上时，则通过已抽样数据就可以恢复所有数据，不存在数据扣留的可能性。抽样失败的节点会被惩罚。

使用第三方 DA 服务将交易数据存储在以太坊之外，虽然流程变复杂了，安全性上需要额外信任第三方 DA 服务，但它可以极大降低对以太坊上 gas fee 的消耗，进而将以太坊的性能扩展极限提升至几乎无限，并可以极大地降低 Rollup 使用成本，因此是值得的。Celestia, EigenDA 等均提供成熟的，高性能的 DA 服务。

3.5 存储服务

存储服务与 DA 服务不同。DA 服务的目标是数据公开和分发，专门保存 Rollup 里的 DA 交易数据，服务于 Rollup 安全，相当于区块链的区块数据；而存储服务用于保存 PW 或 PoPW 数据，即 IoT 设备上生成的工作数据，主要为链下数据。

不同的 DePIN 项目对 PW 数据有不同的保存需求，有的需要有一定的隐私保护能力，需要对数据做脱敏或权限管理；有的需要长期保存数据，甚至永久保存。因此不同 DePIN 项目可以按自己实际需求选择合适的存储服务。

3.6 全链 DID 服务

不同 DePIN 项目间可以互相协作，构建更丰富的 DePIN 生态。这需要能跨项目地为每个 IoT 设备提供唯一标识，且能依据此标识获取关于该设备的各种数据（如密码学能力，公钥等），DID 可以提供该服务。因为不同 DePIN 项目可能位于不同链上，因此该 DID 服务需要提供全链服务能力，即在系统内支持的所有链上，每个 IoT 设备均具有不重复的 DID，且通过该 DID 可获取该设备的数据。

让不同链上的任意设备具有不重复的 DID，有两种常见方案：

具有统一的 DID 注册和更新入口，注册时检查其是否重复，再同步到所需的链。
确定各条链的命名规则，通过命名空间保证 DID 不重复。

在当前场景下，方案 b 是不合适的。因为当需要多个 DePIN 项目间协作，获取其他链上设备的 DID 时，不可能通过跨链查询完成，最好的方式是把需要的设备 DID 可信地同步到每条需要的链上（由于采用 L3，实际成本并不高），并在这些链之间保证数据一致性。对方案 b 来说，会导致名字空间的混乱，且无法保证数据一致性。因此此处考虑方案 a。方案 a 中包含 3 部分：

位于 Arweave 上的 DID 合约。该合约保存所有 DID 的数据。所有 DID 均需在此合约中完成注册；DID 数据的更新也需调用此合约完成。
PermWeb 里的服务程序。可对 Arweave 上 DID 合约的数据进行查询，加工和处理。其中 Merkle 根部分是一个特殊的服务，它会把 DID 合约里的所有 DID 数据计算生成一棵 Merkle 树，并把树根依照多种策略提交至各个 DePIN App Chain 的 DID 服务合约中。
位于各条 DePIN App Chain 上的 DID 服务合约。这些合约服务于各自所在的链，即每条链上用到的 DID 均保存在该合约中。该合约只有导入接口，没有注册和修改接口。当导入一条新的 DID 时，需通过之前输入的 Merkle 根对该 DID 进行正确性校验，校验通过才允许导入。

工作流程分为三步：

所有设备在 Arweave 的智能合约里注册其 DID，注册时会检查名字是否冲突，冲突的名字不允许注册，需修改为不重复方可注册。注册时除了 DID，还可以提供设备的其他属性，如公钥，设备 id，设备能力，访问方式等。
所有注册设备的 DID 数据会 PermWeb 上的 Merkle 树服务计算生成一棵 Merkle 树，树根会被依照策略提交至各条 DePIN App Chain 的 DID 服务合约中。
将 DID 按需导入至目标 DePIN App Chain 的 DID 服务合约中。导入时的 Merkle 验证会保证导入的 DID 数据与注册时的一致。

Arweave 不仅提供永久数据保存，而且其支持 EVM 合约和通过 PermWeb 对保存的数据进行查询和处理，因此非常适合用来保存全链 DID 数据。DID 数据的条目虽然多，但所需的总存储量并不大，因此其成本也是合适的。

3.7 密钥可信初始化

IoT 设备安全容器中保存的密钥是验证 PoPW 的信任来源，必须做到密钥被安全可信地初始化，私钥不可被任何一方读出，公钥可被提交至 DID 合约中，供任何人通过 DID 读取。可信初始化有多种可能方式：

在芯片生产和初始化阶段，由生产商直接操作安全容器，完成密钥对的生成，并读出公钥，将公钥数据提供给购买方，即 DePIN 项目方。
通过去中心化 TSM（Trusted Service Manager）系统进行空中初始化。DePIN App Chain 会构建去中心化 TSM 服务网络，通过去中心化方式和密码学算法，配合通用的芯片内安全容器接口，完成密钥对的初始化过程，并读出公钥，直接写入 DID 合约。

方案一是业界成熟方案，成本低，适合一次性大批量初始化芯片。安全容器可以位于通信模组中，而通信模组可以适配到各种不同用途的 IoT 设备中，因此可将其作为通用产品使用。可以一次性批量生产大量芯片后，向多个不同 DePIN 项目方供应该芯片。并由芯片生产方或可信第三方批量在链上初始化 DID 数据。

方案二更加灵活，可在任意阶段通过无线网络和去中心化 TSM 网络完成对芯片内密钥对的初始化。由于密钥种子来自多个去中心化参与方，因此只要去中心化 TSM 网络中有一个诚实参与方，整个流程就是安全可信的，没有任何参与方可以解码出芯片内的私钥。

3.8 经济学支持

经济学是 DePIN 项目的引擎和重要组成部分。DePIN 项目可以使用自己的 Token，也可以使用生态 Token 作为项目 Token。甚至可以两者兼而有之，在项目启动阶段使用有价值的，已经被认可的生态 Token 作为激励和应用 Token，迅速推进网络建设并获得用户和价值支撑，降低使用摩擦；在发展壮大后将网络规模和服务能力作为价值支撑，转换为使用自己的 Token 获得更高的价值捕获。

多个 DePIN 项目使用统一的生态 Token 可以形成合力，对项目方和 DePIN App Chain 生态的发展都有好处。从 DePIN App Chain 生态的角度而言，更多项目使用生态 Token，可以捕获更多价值，也给生态的发展带来更多可能性；从项目方角度而言，在项目启动阶段其网络价值较低，不易吸引用户，此时如果使用已经具有价值的生态 Token，可以提高项目价值，降低用户使用的摩擦；从终端用户和投资者角度看，拥有生态 Token 便可以使用多种 DePIN 应用服务，获取多个项目成长的预期，是件方便划算的事情。

除了 Token 经济学外，DePIN 项目的发展还需要很多其他生态经济支持，如 DEX, 借贷等传统 DeFi 支持；除此之外，鉴于 DePIN 的 RWA 属性，也会产生现实世界里的法币需求。DePIN App Chain 生态会对接多种工具，帮助项目方构建链上链下的经济学，帮助项目成长。

3.9 全链服务

由于各种原因，DePIN 项目方可能会将其项目部署在各种各样的区块链网络上，如 polygon, Solana 等 L1 网络，或 Arbitrum, Optimism, zkSync 等 L2 网络。

通过上述分析，读者们会发现各项核心服务并不依赖于特定区块链。只要在某条区块链上部署了区块链服务合约，并通过跨链将管理链上可信的服务实体（BoAT3 Oracle），数据 (DID) 或资产（DePIN 生态 Token 等）在该区块链上实例化，该区块链就可以成为应用链中的一员，与其他基于 DePIN App Chain L3 构建的应用链所获得的能力几乎是一样的。唯一的区别在于，由于链的运行原理不同，这条区块链可能并没有结算层，或其结算层不是现有的管理链，因此该链无法在系统内与其他链进行无信任的跨链协作，但这可以通过其他跨链方式完成。

4. 示例

下面以一个简单的示例来说明怎样基于 DePIN App Chain 生态构建一个 DePIN 项目。例子中的各项基础设施，从 IoT 设备到数据平台的服务，都是成熟可购买的，但项目的设计，资源的整合，社区的运营和服务，需要项目方精心设计和落地。

该例子使用太阳能电池，构建一个去中心化绿色能源网络，该网络旨在促进清洁能源的生产和使用。项目方收集太阳能电池发电的数据，以此数据证明清洁能源的生产过程是可信的，并依据此数据发出绿证。绿证可用于碳排放抵消，比特币绿化等多种场景。除绿证收入外，项目方通过发行的 Token 鼓励矿工们构建该绿色网络。

太阳能电池的发电数据可通过连接逆变器的数采器获得。矿工们可以直接购买集成好项目方的数采器的光伏系统，也可以购买项目方提供的数采器后自行安装。项目方生产数采器时会使用已经内置了密钥的安全芯片，项目方委托供应商在链上生成 DID，并写入公钥（项目方也可获得公钥后自行生成 DID，并写入公钥）。

电池板发电过程中会不断产生发电数据，如实时发电功率，发电量等。数采器会对这些数据进行采样，并发送给通信模块；数采器中的安全芯片会使用私钥对这些数据签名，即生成 PoPW，然后将 PoPW 发送给 BoAT3 Oracle。BoAT3 Oracle 根据收到的数据从 DID 合约中读取该电池板的公钥，通过公钥验证收到的 PoPW 的合法性。如果数据是合法的，则会提取出其中的有效数据部分，并使用自身私钥对其签名，表示对数据的认可，由 BoAT3 Oracle 签名的数据称为 PW（Physical Work）。BoAT3 Oracle 会将 PW 提供给项目方，项目方会将收集到的 PW 数据和原始 PoPW 签名批量保存至存储网络，如 FIL，Arweave 或云存储。

项目方会针对提供了有效发电数据的矿工进行奖励。奖励使用 DePIN 生态 Token。为了降低链上成本，可能会随机抽取部分矿工发放奖励，因为抽取是随机的，所以从更长时间来看，所有诚实的矿工都会公平地收到奖励。奖励数量由矿工的发电量决定，会将发电量抽象为奖励权重，计算所有获奖矿工的总权重后，每个矿工按自己的发电量权重获取奖励。项目方在链下计算每位矿工获得的奖励，并通过 Oracle 发放奖励。但同时会将奖励计算相关的所有数据公开至存储或 DA 网络，供社区验证和挑战。发放奖励时在合约中提供的数据至少包括：

本次奖励发放的期数相关数据。通过此数据可确定哪些矿工，哪些数据参与了此次奖励发放。
用于计算哪些矿工获得奖励的随机数。
如何获得 PW 原始数据。如使用的 IPFS 网络及文件 CID。
奖励细节的 Merkle 树树根和总权重。该 Merkle 树包含了每个获奖矿工的获奖相关数据，如 PW 数据 ID，矿工 DID，奖励数量等。确保挑战时可通过这些数据在链上验证奖励发放规则是否被严格遵守。

针对本次奖励发放，开启挑战期。在挑战期内，任何人均可针对奖励的公平性，正确性发起挑战，包括矿工获得的奖励数量是否正确，未获得奖励的矿工是否确实不该获得奖励，等等。这些挑战均在链上，使用 Oracle 提交的数据完成，而这些数据进一步都来自于矿工提交的 PoPW，任何人都可以独立下载并验证所有数据和奖励的公平性。挑战期结束后，矿工可以提取奖励。

提取奖励后，矿工可以将获得的 DePIN 生态 Token 在 CEX，DEX 等兑换成稳定币或法币，补贴其购买和运行矿机的成本，形成正向经济循环。DePIN 网络向终端用户提供服务，如碳排放抵消，绿化比特币等；这些服务的价格是稳定的，终端用户可以购买生态 Token 后，将其燃烧铸造成价值稳定的应用 Token，使用应用 Token 购买各种服务。

在购买矿机的过程中，矿工也许需要资金进行初始投资的资助。可以使用 DePIN App Chain 生态的链上借贷服务获取资金，资金的回报可通过挖矿所得的生态 Token 或服务于终端用户所得的应用 Token 支付。由于挖矿等活动均在链上完成，因此资金回报可通过智能合约自动完成利润计算，将利润分账至资金方。

5. 总结

Rollup 技术解决了区块链扩容难题，使得区块链可以在保持高度安全，可信的前提下，获得极大的性能扩展和极低的使用成本，这给 DePIN 应用的大规模落地创造了条件。