liberalism (张)

IoTeX、DePHY 和 Peaq 等基础设施是怎么运转的

liberalism — Sat, 20 Jul 2024 03:04:37 +0800

原文：https://mp.weixin.qq.com/s/-7JJjXlycdFfkTYoeWPMBw

作者：Pika，Sui 公链大使，DePIN 研究员

编辑：Faust，极客 web3

导语：尽管 DePIN 赛道在当下十分火热，但 DePIN 相关的物联网设备要大规模接入到区块链，仍存在技术上的障碍。一般而言，若要将物联网硬件接入到区块链中，要经历以下三个关键阶段：

硬件设备的可信任运行；
收集验证并提供数据；
将数据分发到不同应用。

这三个阶段中存在不同的攻击场景与反制手段，需要引入各种机制设计。本文从项目工作流程与协议设计的角度，回顾分析了物联网设备从可信任产生数据，验证存储数据，通过计算产生证明，和向区块链 rollup 数据的整个流程。如果你是 DePIN 赛道的创业者，希望本文可以在方法论和技术设计上对你的项目发展有所帮助。

下文中，我们以空气质量检测的场景为例，结合 IoTeX、DePHY、peaq 这三个 DePIN 基础设施进行分析，向大家阐明 DePIN 基础设施是如何工作的。此类基础设施平台可以对接物联网设备与区块链/Web3 设施，帮助项目方快速启动 DePIN 应用类项目。

硬件设备的可信任运行

硬件设备的可信任，包括设备身份的信任与程序执行可验证无篡改的信任。

DePIN 的基础工作模式

在大多数 DePIN 项目的激励方案里，硬件设备的运行者会对外提供服务，以此为筹码向激励系统索要奖励，比如在 Helium 中，网络热点设备通过提供信号覆盖，来获取 HNT 奖励。但在从系统中获取激励前，DePIN 设备需要先出示证据，证明自己的确按要求付出了一定“努力”。

这类用于证明自己在现实世界中提供了某类服务、进行了某些活动的证明，被称为物理工作证明(Proof of Physical Work, PoPW)。在 DePIN 项目的协议设计中，物理工作证明占有举足轻重的地位，相应的也存在各种攻击场景与对应的反制手段。

DePIN 项目要依托于区块链完成激励分发与代币分配。类似于传统公链中的公私钥体系，DePIN 设备的身份核验流程中，也需要使用公私钥，私钥用于生成和签署“物理工作证明”，公钥则被外界用于验证上述证明，或作为硬件设备的身份标签 (Device ID)。

除此之外，直接用设备的链上地址接收代币激励并不方便，因此 DePIN 项目方往往在链上部署一个智能合约，合约中记录着不同设备持有人的链上账户地址，类似于数据库中一对一或多对一的关系。这种方式下，链下物理设备应当收到的代币奖励，可以直接打到设备持有人的链上账户里。

女巫攻击

绝大多数提供激励机制的平台，都会遇到“女巫攻击”，就是说有人可能操控大量的账号或设备，或是生成不同的身份证明，伪装成多个人，拿多份奖励。以我们前面提到的空气质量检测为例，提供此服务的设备越多，系统分发出去的奖励也越多。有人可以通过技术手段，快速生成多份空气检测数据以及对应的设备签名，制造大量的物理工作证明来获利，这会使 DePIN 项目的代币陷入高通胀，所以要制止此类作弊行为。

所谓的反女巫，如果不采用 KYC 等破坏隐私性的方法，最常见的措施就是 POW 和 POS，在比特币协议中，矿工要付出大量的算力资源，才能获得挖矿奖励，POS 公链则直接让网络参与者质押大量的资产。

在 DePIN 领域中，反女巫可以归结为“抬高物理工作证明的生成成本”，由于物理工作证明的生成，依赖于有效的设备身份信息（私钥），所以只要抬高身份信息的获得成本，就可以防止某些低成本生成大量工作证明的作弊行为。

针对上述目标，一种相对有效的方案是，让 DePIN 设备生产商垄断身份信息的生成权限，对设备进行定制化处理，为每部设备录入唯一的身份标签。这就好比，由公安局统一记录全体公民的身份信息，只有在公安局数据库里可查的人，才有资格领取政府补贴。

（图片来源：DigKey）

在生产环节，DePIN 设备厂商会使用程序在足够长的时间里生成根密钥，然后随机选择根密钥使用 eFuse 技术写入到芯片中。这里要科普下，eFuse（可编程电子熔断器）是在集成电路中存储信息的电子技术，录入的信息通常无法被篡改或擦除，具有较强的安全保障。

在这种生产流程下，设备持有者和生产商都无法获知设备的私钥，以及根密钥。硬件设备可以在 TEE 的隔离环境中，从根密钥导出并使用工作密钥，包含签署信息用的私钥，和交由外界验证设备身份的公钥。TEE 环境外的人或程序都无法感知到密钥的细节。

上述模式下，如果你想获取代币激励，必须要从专属厂商那里购买设备。女巫攻击者若想绕开设备厂商，低成本生成大量的工作证明，就需要破解厂商的安全系统，将自己生成密钥的公钥注册到网络许可设备中去，女巫攻击者很难低成本发起攻击，除非设备生产厂商监守自盗。

而一旦人们发现设备厂商有作恶的可疑迹象，可以通过社会共识的方式对 DePIN 设备生产厂商进行曝光，这往往会使得 DePIN 项目本身连带遭殃。但多数情况下，设备厂商作为 DePIN 网络协议的核心受益方，大多没有作恶动机，因为让网络协议井然有序运转的话，卖矿机赚的钱会比 DePIN 挖矿赚的钱多，所以他们更多会倾向于不作恶。

（图片来源：Pintu Academy）

如果硬件设备不是由中心化生产商统一供应的，那么当任意一台设备接入 DePIN 网络时，系统要先确认该设备具有协议要求的特性。比如，系统会检查这些新加入的设备，有没有专属的硬件模块，没有此类模块的设备往往无法通过认证。而要让设备拥有上述硬件模块，要花费一定的资金，这就抬高了女巫攻击的成本，进而达到反女巫的目的。在这种情况下，还是正常运行设备而非制造女巫攻击更为明智和稳妥。

数据篡改攻击

让我们脑洞一下，如果某台设备收集到的空气质量检测数据，其波动性越强，系统就认为数据更有价值，并为此提供更多奖励，那么任何设备都有充足的动机伪造数据，让其故意表现出高波动性。即便是由中心化厂商做身份认证的设备，也可以在数据计算过程中“夹带私货”，对收集到的原始数据进行改写。

该如何保证 DePIN 设备是诚实可信的，没有对收集到的数据进行肆意修改呢？这需要用到可信固件 (Trusted Firmware) 技术，其中较为出名的是 TEE(Trusted Execution Environment), 还有 SPE(Secure Processing Environment).。这些硬件层面的技术，可以保障数据在设备上按照事先验证过的程序来执行，计算过程中没有“夹带私货”。

（图片来源：Trustonic）

这里简单介绍下，TEE(可信执行环境) 通常是在处理器或处理器核心中实现的，用于保护敏感数据，执行敏感操作。TEE 提供了一个受信任的执行环境，其中的代码和数据能够受到硬件级别的安全保障，以防止恶意软件、恶意攻击或未经授权的访问。比如，Leger, Keystone 这些硬件钱包都有使用到 TEE 技术。

大多数现代芯片都支持 TEE，尤其是针对移动设备、物联网设备和云服务的芯片。通常情况下，高性能处理器、安全芯片、智能手机 SoC（系统级芯片）和云服务器芯片都会集成 TEE 技术，因为这些硬件涉及的应用场景，往往对安全性有较高的追求。

但是，不是所有的硬件都支持可信任固件，一些较低端的微控制器、传感器芯片和定制的嵌入式芯片可能缺乏对 TEE 的支持。对于这些低成本芯片，可以通过探针攻击等手段去获取芯片内留存的身份信息，进而伪造设备身份和行为。比如，攻击获取到芯片上保存的私钥数据，然后使用私钥对篡改或伪造的数据进行签名，伪装成设备自身运行生成的数据。

但探针攻击依赖于专门设备和精确的操作、数据分析流程，攻击成本过高，远高于从市场上直接获取这类低成本芯片的成本。相比于通过探针攻击等手段破解伪造低端设备的身份信息来获利，攻击者会更愿意直接购买更多台低成本的设备。

数据源攻击场景

前面提到的 TEE 可以保证硬件设备如实的生成数据结果，只能证明数据在输入到设备内部后，没有被恶意的处理，但无法确保数据在进行计算处理前，其输入源头可信，这其实类似于预言机协议面对的难题。

比如，某台空气质量检测仪，被放置在了排废气的工厂附近，但有人在夜里用密闭的玻璃罐把空气质量检测仪罩起来，那么这台空气检测仪获取的数据必定不真实。但上述攻击场景往往无利可图，攻击者大多数时候没必要这么做，因为是费力不讨好。对于 DePIN 网络协议而言，只要设备满足诚实可信的计算过程，付出了满足激励协议所要求的工作量，理论上就该获得奖励。

方案介绍

IoTeX

IoTeX 提供了 W3bStream 开发工具，将物联网设备接入到区块链和 Web3 当中。在 W3bStream 物联网端的 SDK 中，包含了通信和消息传递、身份和凭证服务以及密码学服务等基本组件。

W3bStream 的 IoT SDK 对加密功能的开发非常完善，包含多种加密算法的实现，比如 PSA Crypto API, Cryptographic primitives, Cryptographic services, HAL, Tooling, Root of Trust 等模块。

有了这些模块，可以在各种硬件设备上，用安全或欠安全的方式去对设备产生的数据进行签名，并通过网络传递到后续数据层供验证。

DePHY

DePHY 在物联网端提供了 DID(Device ID) 认证服务。DID 由生产商铸造，每一个设备都有且仅有一个对应的 DID。DID 的元数据可以自定义，可以包含设备序列号、型号、保修信息等等。

对于支持 TEE 的硬件设备，最开始由生产商生成密钥对，使用 eFuse 将密钥写入芯片中，而 DePHY 的 DID 服务，可以帮助生产商根据设备公钥来生成 DID. 而生产商生成的私钥除了被写入到物联网设备，就只有生产商持有。

由于可信任固件可以实现安全可靠的消息签名与硬件端私钥保密，如果人们发现网络中存在作弊生成设备私钥的行为，基本就可以认为是设备生产商在作恶，就可以溯源到对应的生产商身上，实现信任溯源。

DePHY 的用户在买入设备后，可以获取设备的激活信息，再调用链上的激活合约，将硬件设备的 DID 与自己的链上地址关联绑定，进而接入到 DePHY 网络协议中。物联网设备经过 DID 设置流程后，就可以实现用户与设备之间的数据双向流动。

当用户通过链上账户向设备发送控制指令时，流程如下：

确认用户拥有访问控制权限。由于设备的访问控制权限以 metadata 的形式写在 DID 上，可以通过检查 DID 来确认权限；
允许用户和设备开通私密通道建立联接来支持用户控制设备。DePHY relayer 除了 NoStr relay 外，还包含 peer-to-peer 的网络节点，可以支持点对点通道，由网络里的其他节点帮忙中继流量。可以支持用户在链下实时控制设备。

在物联网设备向区块链发送数据时，后续数据层会从 DID 上读取设备的许可状态，只有通过注册被许可的设备才能上传数据。比如被生产商注册过的设备。

这个 DID 服务另一项有意思的功能在于提供了物联网设备的功能特性 (trait) 认证。这项认证可以识别出物联网硬件设备是否具有某些特定功能，达到足以参与特定区块链网络的激励活动的资格。比如一台 WiFi 发射器，通过识别到具有 LoRaWAN 的功能 (trait)，可以认为具有提供无线网络连接的作用，也就可以参与到 Helium 网络中。类似的，还有 GPS trait, TEE trait 等。

在拓展服务方面，DePHY 的 DID 还支持参与质押，链接可编程钱包等，方便参与链上活动。

peaq

peaq 的方案比较奇特，它的方案分为三个等级，分别是源自设备的认证、模式识别校验、基于预言机的认证。

1.源自设备的认证。peaq 同样提供了生成密钥对，在设备上使用私钥签署信息，将设备地址 peaq ID 绑定用户地址等功能函数。但是，在他们的开源代码中却找不到可信固件的功能实现。peaq 简单的使用私钥对设备信息进行签名的认证方式，并不能保证设备的诚信运行和数据未经篡改。peaq 更像是一个乐观 Rollup，默认设备不会作恶，然后在后续阶段去验证数据的可信状况。

2.模式识别校验。第二个方案是结合机器学习、模式识别。通过学习之前的数据得到模型，当新的数据输入时，与先前的模型做比较，判别是否可信。但统计模型其实只能识别出异常数据，并不能判断物联网设备是否诚实运行。

比如，城市 A 中的某台空气质量检测仪放置在了地下室，收集产生的数据与其他空气质量检测仪都不一样，但并不代表数据伪造，设备仍在诚实运行。另一方面，只要收益足够大，黑客们也愿意使用 GAN 等方法，生成机器学习难以鉴别的数据，尤其是判别模型公开共享的情况下。

3.基于预言机的认证。第三个方案是他们会挑选一些更受信任的数据源作为预言机，与其它 DePIN 设备收集上来的数据进行比较验证。比如，项目方在城市 A 部署了一台精确的空气质量检测仪，其他空气质量检测仪收集的数据如果偏差太大，就被认为不可信。

这种方式一方面给区块链引入并依赖权威，另一方面，也可能因为预言机数据源的采样偏差，而使得整个网络数据采样都出现偏差。

就目前的资料来看，peaq 的基础设施，在物联网端无法保证设备和数据的可信任。（注：笔者查阅了 peaq 的官网、开发文档、Github 仓库，以及一份仅有的 2018 年白皮书草稿。即使向开发团队发送邮件，也未能在发稿前得到更多补充说明资料）

数据的产生与发布（DA）

DePIN 工作流程中第二个阶段主要是收集、验证物联网设备传递过来的数据，保存起来向后续阶段提供数据，要确保数据能完整无误、可被还原的发送给特定接收方，这被称为数据可用性层 (DA 层)。

物联网设备往往通过 HTTP, MQTT 等协议，将数据和签名认证等信息广播出去。而 DePIN 基础设施的数据层在接收到设备端的信息时，需要验证数据的可信度，把通过验证的数据汇集存储起来。

这里介绍下，MQTT(MQ Telemetry Transport) 是一种轻量级的、开放的、基于发布/订阅模式的消息传输协议，旨在用于连接受限的设备，如传感器和嵌入式系统，在低带宽和不稳定网络环境下进行通信，非常适合物联网 (IoT) 应用程序。

在验证物联网设备消息的环节，会包含设备可信执行的认证和消息的认证。

设备可信执行的认证可以结合 TEE.。TEE 通过将数据收集代码隔离在设备的受保护区域中，确保了数据的安全收集。

另一种方式是零知识证明，这种方法使得设备能够证明其数据收集的准确性，同时又不泄露底层数据的细节。这种方案因设备而异，对于性能强大的设备，可以在本地生成 ZKP，对于受限制的设备，则可以进行远程生成。

在认证了设备的信任之后，使用 DID 去验证消息签名，就可以确定消息是由该设备产生。

方案介绍

IoTeX

在 W3bStream 中，分为可信任数据收集、验证，数据清洗，数据存储这三个部分。

可信数据的收集、验证使用了 TEE 和零知识证明的方法。
数据清洗是指将来自不同类型设备上传的数据格式统一化、标准化，便于存储和处理。
数据存储环节，允许不同应用项目通过配置存储适配器来选择不同的存储系统。

在当前的 W3bStream 实现中，不同的物联网设备可以直接把数据发送给 W3bStream 的服务终端，也可以先把数据通过服务器收集后，再发送给 W3bStream 的服务器终端。

在接收到传入的数据时，W3bStream 会像一个中心分发调度器那样，将传入的数据分发给不同的程序去处理，而W3bStream 生态内的 DePIN 项目，会在 W3bStream 上申请注册，并定义事件触发逻辑 (Event Strategy) 和处理程序 (Applet).

每部物联网设备都会有设备账号 (device account), 归属于一个而且也只能有一个 W3bStream 上的项目。因此，当物联网设备的消息传递到 W3bStream 服务端口时，可以先根据注册绑定信息，重定向到某个项目，并验证数据的可信。

至于前面提到的事件触发逻辑，可以定义从 HTTP API 终端、MQTT 话题接收到的数据信息，以及检测到区块链上的事件记录，检测到区块链高度等可以被触发的事件 (Event triggers) 类型，并且绑定对应的处理程序去处理。

处理程序 (Applet) 中定义了一个或多个执行函数，被编译成了 WASM 格式。数据的清洗和格式整理就可以通过 Applet 去执行。处理之后的数据被存放到由项目定义的 key-value 数据库中。

DePHY

DePHY 项目采用了更为去中心化的方式来处理和提供数据，他们称之为 DePHY 消息网络 (DePHY Message network). 图片

DePHY 消息网络由无许可的 DePHY 中继节点 (relayer) 组成。物联网设备可以通过任意一个 DePHY 中继节点的 RPC 端口将数据传入，传入的数据会先调用中间件，结合 DID 去验证数据可信任。

通过信任验证的数据需要在不同的中继节点之间同步，形成共识。DePHY 消息网络采用了 NoStr 协议来实现。NoStr 原本的用途是用于构建去中心化的社交媒体，还记得之前有人用 NoStr 代替 Twitter 而大火么，用在 DePIN 数据的同步中居然也巧妙的合适。

在 DePHY 网络中，每台物联网设备存储的数据片段，都可以被组织成一棵 Merkle 树，节点间会彼此同步这棵 Merkle 树的 root，以及整棵树的 tree 哈希。当某个 Relayer 得到上述 Merkle Root 和 Tree 哈希后，可以快速定位还缺少哪些数据，方便从其他 Relayer 中获取补齐。这种方法能异常高效地达成共识确认 (Finalize)。

DePHY 消息网络的节点运行是 Permissionless 的，任何人都可以质押资产并运行 DePHY 网络节点。节点越多，网络的安全性越高，可访问性就越强。DePHY 节点可以通过 zk 条件付款 (Zero-Knowledge Contingent Payments) 的方式，获得奖励。也就是说，有数据索引需求的应用，在向 DePHY 中继节点请求数据时，根据可否检索到数据的 ZK 证明，来决定向中继节点支付多少费用。

同时，任何人都可以接入 DePHY 网络来监听、读取数据。项目方运营的节点可以设置过滤规则，只储存与自己项目相关的 DePIN 设备数据。由于沉淀了原始数据，DePHY 消息网络可以作为后续其他任务的数据可用层。

DePHY 协议会要求中继节点在运行时至少把接收到的数据在本地存储一段时间，再把冷数据要转存到 Arweave 这种永久性的存储平台上。如果全部数据都当作热数据去处理，最终会抬高节点的存储成本，进而提高全节点运行门槛，使得普通人难以运行全节点。

通过冷热数据分类处理的设计，DePHY 能大大降低消息网络中全节点的运行成本，更能应对海量的物联网数据。

peaq

前面的两种方案都是把数据的收集存储放在链下去执行，然后 Rollup 到区块链上去。这是因为物联网应用产生的数据量本身极大，同时又有通信延时的要求。如果在区块链上去直接去执行 DePIN 交易，数据处理能力有限而且存储成本很高。

单是等待节点共识就带来不可忍耐的延时问题。peaq 却另辟蹊径，自己搭建了一条公链，直接承载和执行这些计算和交易。它是基于 Substrate 开发的，当主网实际上线后，承载的 DePIN 设备增多，将会因为 peaq 的性能瓶颈，最终无法承载那么大量的计算和交易请求。

由于 peaq 没有可信任固件的功能，基本无法有效验证数据的可信。在数据存储方面，peaq 直接在开发文档中介绍了如何给基于 substrate 的区块链接入 IPFS 分布式存储。

将数据分发到不同应用

DePIN 工作流程中的第三阶段，是根据区块链应用的需求，将数据可用层的数据抽取出来，通过执行运算或零知识证明，把执行结果高效地同步到区块链上。

方案介绍

IoTeX

W3bStream 把这一阶段称为数据证明聚合 (Data Proof Aggregation)。这部分网络由许多聚合器节点 (Aggregator Nodes) 组成一个计算资源池 (computing resource pool), 给所有的 DePIN 项目共享调用。

每个聚合器节点会在区块链上记录自己的工作状态，是忙碌还是空闲。当有 DePIN 项目的计算需求过来时，根据链上的状态监控 (monitor) 选择空闲的聚合器节点去处理。

被选中的聚合器节点，会先从存储层检索需要的数据；然后根据 DePIN 项目的需求对这些数据做运算，并且生成运算结果的证明；最后把证明结果发送到区块链上给智能合约去验证。完成工作流程之后，聚合器节点重新回到空闲状态。

而聚合器节点在生成证明时，会用到分层聚合电路 (layered aggregation circuit)。分层聚合电路包含四个部分：

数据压缩电路：类似于 Merkle 树，验证所有收集的数据都来自特定的 Merkle 树根。
签名批验证电路：批量验证来自设备的数据的有效性，每个数据都与一个签名相关联。
DePIN 计算电路：证明 DePIN 设备按照特定计算逻辑正确执行了一些指令，例如在医疗健康项目中验证步数，或者在太阳能发电厂中验证产生的能量。
证明聚合电路：将所有证明聚合成一个单一的证明，以供 Layer1 智能合约最终验证。

数据证明聚合对于确保 DePIN 项目中计算的完整性和可验证性至关重要，为验证链下计算和数据处理提供了可靠和高效的方法。

IoTeX 的收益环节也主要在这一阶段，用户可以通过质押 IOTX 代币，运行聚合器节点。越多聚合器的参与，也就能带来更多的运算处理能力，形成算力充足的计算层。

DePHY

在数据分发层面，DePHY 提供了协处理器来监听 DePHY 消息网络的 finalized 消息，进行状态迁移 (State change) 后，将数据打包压缩并提交到区块链。

状态迁移是用于处理消息的类智能合约的函数，由不同 DePIN 项目方定制，还包括 zkVM 或 TEE 的计算打包数据处理方案。这部分由 DePHY 团队向 DePIN 项目方提供项目脚手架 (Scaffold) 来开发和部署，具有很高的自由度。

除了 DePHY 提供的 co-processor, DePIN 项目方也可以根据项目脚手架将 DA 层的数据接入到其他基础设施的计算层，实现上链。

综合分析

尽管 DePIN 赛道火热，但物联网设备要大规模接入到区块链，仍存在技术上的障碍。本文从技术实现的角度，回顾分析了物联网设备从可信任产生数据，验证存储数据，通过计算产生证明和向区块链 rollup 数据的整个流程，从而支持将物联网设备集成到 Web3 应用中。如果你是 DePIN 赛道的创业者，也希望本文可以在方法论和技术设计上能对项目发展有所帮助。

在选择分析的三个 DePIN 基础设施中，peaq 依然像六年前网上的评论一样，is just hype. DePHY 和 IoTeX 都选择了链下收集物联网设备数据，然后 rollup 到链上的工作模式，能够在低时延、保证设备数据可信的条件下，将物联网设备数据接入到区块链。

DePHY 和 IoTeX 又各有侧重，DePHY 的 DID 包含了硬件功能 trait 的验证，双向数据传输等特点，DePHY 消息网络更注重于去中心化的数据可用层，更多是作为低耦合的功能模块与 DePIN 项目结合；IoTeX 的开发完整度很高，有完整的开发工作流程，更侧重于给不同事件绑定处理程序，偏向计算层。DePIN 项目方可以根据实际需求，选择不同的技术方案去组合。

如果读者在 DePIN 方向有创业项目，也可以通过 telegram 与笔者讨论交流。

Tele: @pika042

【视频】Solana 交易分析与钓鱼欺诈

liberalism — Thu, 18 Jul 2024 18:45:09 +0800

视频内容：关于 Solana 交易分析和钓鱼欺诈的全面介绍

包括 Solana RPC 交易数据接口

交易指令解析

SPL Token

模拟交易及其安全性探讨

钓鱼欺诈的多种手法及其应对策略。

7/20 solana 索夏将至 @深圳

liberalism — Thu, 18 Jul 2024 13:19:17 +0800

周六邀请大家在上海成都深圳一起和 Solana kick off Solar New Year

活动链接：https://lu.ma/x6uflta9

报名后以获得详细地址。

使用 Phalcon Explorer 教你看懂 Solana 交易

liberalism — Sun, 07 Jul 2024 15:18:10 +0800

原文：https://mp.weixin.qq.com/s/3X_S7bmoNVjIyWK7VU2MBQ

关于 Tokens

Solana 上的 Token 可以分为两类：Native Token 和其它 Token。

Native Token 其实就是 Solana Token (SOL)。我们在之前的文章里曾提到，Solana 中的每一个账户都拥有一个 Lamports 字段，Lamports 实际上是 SOL Token 的最小单位（1 SOL = 10 亿 Lamports），它记录了当前账户 Solana Token 的余额。

而对于其它 Token，Solana 使用了一个程序账户（Token Program）以及两种数据账户（Mint Account 和 Token Account），来实现 Token 需要的所有功能。

Token Program

Token Program 结构示意图 Token Program 是由 Solana Program Library（SPL）提供的一个程序账户，因此 AccountInfo 的 Executable 字段显示为 True。

正如我们在第一篇文章中介绍的那样，所有程序账户的拥有者都是 BPF Loader，Token Program 也不例外。此外，和 System Program 一样，Token Program 也被部署在 Solana 链上的一个固定地址。

作为一个程序账户，它实现了数个指令来提供不同的功能。比如，一些指令被用于创建 Mint Account 以初始化一种新的 Token，或是创建 Token Account 用于记录某一个地址持有的 Token 数量；而另一些指令则提供了使用 Token 需要的所有功能，比如增加 Token 数量的 MintTo 指令，或是用于在一对地址之间转移 Token 的 Transfer 指令。

需要注意，由于 Token Program 负责创建 Mint Account 和 Token Account，它还是这两种账户的拥有者。

Mint Account

Mint Account 的结构和关系如下所示：

Mint Account 是一种数据账户，这意味着其 AccountInfo 的 Executable 字段为 False。

在 Solana 上，每一种 Token 都和一个 Mint Account 对应。Mint Account 记录了该种 Token 的总供应量，拥有 Mint 该 Token 权限的账户地址等信息。

Token Account

Token Account 用于记录个体持有某种特定 Token 的数量。针对某一种 Token，每一个持有该 Token 的账户都拥有一个 Token Account。如果某用户拥有 5 种 Token，那么 TA 将拥有 5 个 Token Account。

Token Account 作为一种数据账户，其 AccountInfo 的 Data 部分由三个字段组成：

Mint: 该 Token Account 对应的 Mint Account 的地址；
Owner: 有权将 Token Account 中 Token 转出的账户，即该 Token 真正的“owner”；
Amount：当前 Token Account 持有的 Token 数量。

Token Account 结构图

需要强调的是，AccountInfo 中的 owner 字段和 Data 字段中的 owner 是完全不同的。前者是 Solana 中每一个账户都拥有的一个字段，它指明了哪一个地址拥有直接修改当前账户数据的权限；后者则指明了该 Token Account 所记录的 Token 实际上是属于谁的，该字段本身是 AccountInfo Data 字段的一部分。

将上述的内容串联起来，我们便能得到下面这张账户关系的示意图。不管是 System Program 还是 Token Program，它们在区块链上都部署在唯一的地址，以库的形式存在；一个钱包账户可能同时持有多个 Token Account，它是这些 Token Account 真正的“owner”；同一类 Token Account 的 Mint 字段指向了该种 Token 唯一的 Mint Account，而该账户则记录了 Token 的总供应量等信息。

在 Solscan 查看 Token 账户变化情况

我们可以使用 Solscan 来查看一笔交易中 Token 账户的变化情况：

https://solscan.io/tx/byRn8qtNAYSdvgaGCK4kmZV1m89b7uuFuy1cn96W6femp7WgwymLqJ2MP9hPbegqN9EPe7NvghWpqDFqoCDjKph#tokenBalanceChange

Address 一栏列出了该交易涉及到的所有 Token Account；

Owner 一栏则标注了该 Token 真正的“拥有者”，也就是 Token Account Data 字段中的 owner；

Token 一栏则对应了当前 Token 的 Mint Account，我们可以点进第一行的$SON 进一步查看：

可以看到，Profile Summary 中的 Owner Program 指明了当前 Mint Account 的拥有者是 Token Program，至此三类账户我们都在 Solscan 中进行了对应。

不过，Solscan 这种展示方法可能会给人带来一些误解。比如，在上一张图中第一行增加的 Balance 到底属于地址 CHS9WajyFfuaAZRk2JC7hRJvPHXmG5fC94gtAPbnLjuY，还是 Raydium Authority V4？这种展示方式无疑增加了理解的成本。

除此之外，读者也许还会发现，Solscan 中的 Solana Token 和其它 Token 在两个板块分开展示。尽管这种分割方式在技术上是合理的，但如果能在展示时将它们统一视作 Token 放置在相同板块下则更加容易理解。

Phalcon Explorer 不仅解决了上述问题，还针对 Solscan 做了很多其它创新，接下来让我们再使用 Phalcon Explorer 来看看同一笔交易。

👀 建议打开链接，跟随我们的步骤一起分析，这样可以更好地了解交易细节，感受 Phalcon Explorer 的强大功能 💪

https://app.blocksec.com/explorer/tx/solana/byRn8qtNAYSdvgaGCK4kmZV1m89b7uuFuy1cn96W6femp7WgwymLqJ2MP9hPbegqN9EPe7NvghWpqDFqoCDjKph

使用 Phalcon Explorer 查看和分析交易

在 Phalcon Explorer 的正上方可以看到，当前交易被识别成了 JITO 的 MEV 交易，并且可以通过点击交易签名旁的 Solana 标识来一键跳转到 Solscan。

关于这笔交易的信息被分成了四个板块，分别是：Basic Info，Fund Flow，Balance Changes 和 Invocation Flow，你可以通过点击右上角的图标来切换到相应的部分。

Basic Info

Basic Info 一栏的信息相对简单，它提供了一些关于当前交易的关键信息。和交易签名类似，你也可以点击区块号和签名者地址来跳转到 Solscan 上。

Fund Flow

Fund Flow 一栏为分析者提供了交易执行时产生的资金流转移和时序信息。我们可以看到：

交易的发起者兼签名者 59vLEsmV5VCCGTxjHCoRiXkNgHDVcq7dGx98v9HCn2F 首先向被标记为 Raydium Authority V4 的地址转移了一定数量的某种 Token；
接着 Raydium Authority V4 向签名者 59vLEsmV5VCCGTxjHCoRiXkNgHDVcq7dGx98v9HCn2F 转账了约 6.747 的 Wrapped SOL Token；
最后，签名者还向 Jito 提供了 0.000003 的 SOL Token 作为 Jito 验证者执行交易的小费。

下图为 Solscan 中的资金流向图。相较于 Solscan，每一个地址在 Phalcon Explorer 中的资金流向图唯一对应到一个节点，故而能更容易发现地址之间的资金流向关系，提高分析时的效率。

如果你想要对交易的资金流向进行更深入的分析还可以点击右上角的棕色标识进入 MetaSleush。

Balance Changes

Balance Changes 一栏为我们清晰展示了不同账户在当前交易结束后所有 Token 的变化情况。

比如，交易的签名者 59vLEsmV5VCCGTxjHCoRiXkNgHDVcq7dGx98v9HCn2F 就有三种 Token 发生了变化，分别是原生的 SOL Token、名为 61Hh8Udg7zruvG3BhyNiHF4UmULnC8reB9RBFtwi8uKp 的 Token，以及 Wrapped SOL Token。

在 Balance Changes 中出现的每一个 Account Address 都拥有一个或多个 Token Account，通过点击相应的地址能够对其进行拷贝或跳转到 solscan 上。

我们可以看到，Phalcon Explorer 并没有对 SOL Token 和其它 Token 作区分，故而能直接反映出某一账户所有 Token 的变化情况，并且能更加直观地展示 Token Account 和其 Owner 之间的关系。

Invocation Flow

Invocation Flow 记录了交易的指令执行流程，其中的每一行都对应了 Solana 交易执行时的一条指令。

在这里，我们重点关注 2 和 4 这两条涉及到 Token 转移的指令。

第二条指令调用了 Raydium 的 AMM 的 swapBaseIn 来卖掉 Token。展开该指令可以看到它由两条 CPI（Cross Program Invocation）指令组成，这两条指令的作用是在 Raydium Authority V4 和交易签名者之间进行 Token 转移；第四条指令则是签名者向 Jito 支付小费的过程。

如下图所示，通过点击指令后的 Accounts 标签，我们可以查看指令涉及到的所有账户。相较于 Solscan，这种展示方式会更加简洁，让分析者将注意力放在交易中更关键的信息上。

结论

在本文中我们首先介绍了 Solana 中 Token 的实现原理，随后使用 Solscan 查看了一笔交易中 Token Account 的变化情况。最后，我们使用 Phalcon Explorer 对该交易作了进一步分析，并介绍了 Phalcon Explorer 功能上的创新和优化细节。

一文掌握 Solana 核心概念

liberalism — Sat, 06 Jul 2024 17:22:38 +0800

原文：https://mp.weixin.qq.com/s/IPE2WK4CdZc2fZi3uppZJQ

2024 年，Solana 异军突起，TVL 从年初的十亿美元飙升至如今的近五十亿美元，一跃成为第 4 大公链。

与 Ethereum 相比，Solana 以更快的速度和更低廉的费用为用户带来了更为优越的体验。其基于 POH 的共识机制和异步的交易执行模式为开发者提供了高吞吐量和低延迟的区块链性能，成为各种去中心化应用的首选平台。

本文将深入介绍 Solana 网络中的关键概念，包括其运行机制，账户模型和交易，为大家编写出正确且高效的 Solana 合约打下基础。

eBPF: Solana 交易的执行基石

为了编写和执行智能合约，区块链往往需要一套编程语言和图灵完备的计算环境。

熟悉 Ethereum 的朋友们应该知道，以太坊上的智能合约通常使用高级语言 Solidity 来编写，而 Solidity 编译产生的字节码则运行在一个叫做以太坊虚拟机的环境中。

Solana 并没有选择开发全新的虚拟环境和语言，而是充分利用了现有的优秀技术。原本用于拓展 Linux 内核功能的 eBPF（extended Berkeley Packet Filter）虚拟机被 Solana 选中并作为底层的执行环境。

那么，eBPF 相对于 EVM 有哪些优势？

相较于只支持解释执行的 EVM，eBPF 能够以即时编译（JIT）模式直接将字节码转换成处理器可以直接执行的机器指令，从而更高效地运行程序。

eBPF 拥有一套高效的指令集和成熟的基础设施。开发者只需要使用 Rust 语言即可编写智能合约。LLVM 编译框架提供了一个 eBPF 的后端，利用它可以直接将这些 Rust 语言编写的程序编译成可运行在 eBPF 虚拟机上的字节码。

Solana 的账户模型

1. Solana 账户结构

Solana 上的数据以账户的形式存储。如下图所示，我们可将 Solana 中的所有数据视作一个庞大的键值对数据库。数据库的键是账户的地址，对于“钱包”账户（即由

Solana 用户通过公私钥对直接控制的账户）而言，这个地址是使用 Ed25519 签名系统生成的公钥；而数据库的值是该账户的具体信息，包含余额和其它相关信息。

Solana 使用名为 AccountInfo 的结构来描述一个账户，其组成如下图所示。

Solana 中的每个账户均包含四个字段。这里我们对其进行逐一解释。

Data 字段存储了该账户有关的数据。如果该账户为一个程序（即智能合约），则它存储的其实就是 eBPF 字节码。否则，Data 中信息格式一般由账户创建者自行定义。
Executable 字段用于标识该账户是否为程序。需要注意的是，与以太坊不同，Solana 中的程序是可以更新的。
Lamports 字段记录了该账户 Solana 代币的余额。Lamports 实际上是 SOL Token 的最小单位（1 SOL = 10 亿 Lamports）。
Owner 字段指示了当前账户的拥有者。在 Solana 中，任何一个账户都有一个“Owner”。例如，所有“钱包”账户的拥有者都是 System Program，这是 Solana 网络上的一个特殊账户，负责账户创建等功能。账户拥有者是唯一能够修改账户数据和扣除 Lamports 余额的人（但任何人都可以增加 Lamports，即向账户执行转账功能）。

2. 预定义的 Solana 账户

Solana 拥有一套称作Native Programs的预定义运行程序，它们被部署在固定的地址上。随着 Solana 网络的升级，这些预定义的程序也可能会被更新。我们可以将这些程序理解成 Solana 网络下提供特定功能的 API 和库函数。

在Native Programs中，开发者经常需要与之交互的一个程序是System Program。System Program 为开发者提供了一些指令（Instructions），我们可以把每条指令理解成是一个独立的方法。例如，开发者可使用 CreateAccount 指令来创建新的账户，或者使用 Transfer 指令将 Lamports 转账给其它账户。

另外一个常见的 Native Programs 是 BPF Loader 程序。它是所有其它程序账户的拥有者，其负责部署、更新和执行特定的程序。当一个“钱包”账户需要更新它部署过的程序时，实际上就是通过委托 BPF Loader 程序来完成的，毕竟只有程序的拥有者才有直接权限修改数据。

除了 Native Programs，Solana 还提供了一组被称作Sysvar的账户。它们为 Solana 上的程序提供了与当前 Solana 网络状态相关的信息和全局变量，例如当前的时钟，最近的区块哈希等。

3. 账户租金

在 Solana 链上，每个账户需要保持一定数量的 Lamports 作为最低额度，这被称为租金。与现实生活中的租金概念不同，Solana 上的租金是可以收回的。为了确保账户在链上的数据是可用的，账户需要持有相应数量的 Lamports。租金的数额与账户在链上存储空间的大小相关。

任何试图将账户余额扣减至低于租金数额的交易都会失败，除非这笔交易直接将账户的余额扣减至零。这种操作表明该账户的租金已被收回，在交易执行结束时，Solana 会通过垃圾回收清空相应账户的存储空间。

- 在浏览器中查看 Solana 账户

为了带领大家更好地理解相关概念，我们使用 Solana 提供的“Hello World”项目在 testnet 上创建了一个程序账户，可以通过 Solana 的区块链浏览器 Solscan（选择 testnet）来查看以下账户👇的相关信息。

CJWhxB4qEWBv9eGYUkTN881bNDMDkLbzH1FmdwqLLhoe

如上图所示，我们首先可以看到，该账户已被 Solana 浏览器标明为“Program”。在创建该账户时从发送者的余额里扣除了一部分 Lamports 作为该账户的租金，故而我们可以看到其 SOL Balance 字段不为空。

其次，由于我们创建的是一个程序，其 Executable 字段为 Yes。这里可能有一个难以理解的地方，那就是读者也许会发现 Data 字段存储的是一个地址而非 eBPF 程序。我们在前面提到过，Solana 允许更新程序，而它实际上是通过一种“代理”模式来实现的。由于 Solana 并不允许直接修改程序账户，所以它创建了一个数据账户用来存储 eBPF 程序，而在程序账户的 Data 字段只存储数据账户的地址。每当需要更新程序时，就只需修改数据账户中的 Data 字段。我们用 Solscan 查看 Executable Data 字段的账户可以发现它被标记为“Program Executable Data Account”，其 Data 字段存储了实际的程序：

回到上一张图片，我们可以发现在 More info 中 Owner 字段为 BPF Loader，这与我们在上一节中的描述是一致的。

在 Overview 中还有一个名为“Upgrade Authority”的字段，它的含义是什么呢？

正如我们前面提到的，“钱包”账户是通过委托 BPF Loader 来更新程序的，而在更新之前，BPF Loader 需要验证委托者是否拥有更新的权限。由于程序账户的 Owner 字段已经是 BPF Loader，其自身已经没有空间来存储该信息了，因此 Solana 选择把这个信息存储在数据账户的 Data 字段中，这个信息实际上就是部署程序的钱包地址，也就是这里的“Upgrade Authority”。下图展示了程序账户与数据账户之间的关系，可以看到数据账户的 Data 字段由钱包地址和 eBPF 代码两部分信息组成。

Solana 的交易和指令

在 Solana 中，用户同样通过签发交易（Transactions）来执行程序。其特别之处在于，Solana 能够并行执行这些交易，这也是其能够提供闪电般交易速度的重要原因。接下来我们来看看 Solana 的交易是如何设计的。

一笔 Solana 交易由签名和消息主体组成。一笔交易可包含多个签名。交易的消息主体由四个部分组成，如下图所示。

消息的头部信息（Header）和账户地址数组（Compact array of account addresses）两个字段指定了交易涉及的所有账户以及账户在交易中的特征：包括该账户是否提供了签名以及执行过程中是否会被写入。利用这些信息，Solana 能够验证相应账户提供的签名，并且能够并行地执行那些不触碰相同账户集合的交易。

最近的区块哈希（Recent Blockhash）是交易的时间戳。Solana 网络会确保交易来自于最近的 150 个区块，否则交易会被认为过期从而不被执行。

指令数组（Compact array of Instructions）是交易中最重要的部分，包含了一条或多条指令。一条指令实际上是对某个程序提供的一段例程的调用。指令由三个字段组成，如下图所示：

第一个字段 Program ID Index 指定了指令的接收者，即需要处理该指令的链上程序。它不直接存放一个 32 字节的地址，而是将该地址放在消息主体中的账户地址数组中。该字段使用一个字节的下标指明其在数组中的位置，实现了一种空间复用。

和第一个字段类似，第二个字段是由账户地址下标组成的数组（Compact array of account address indexes），它指明了处理该指令涉及到的所有账户。

最后一个字段是一段字节数组，它是程序处理该指令需要的额外信息，可以把它理解成函数的参数。

需要注意的是，Solana 会按照顺序处理交易中的所有指令，并确保交易的执行是原子的。这意味着一笔交易中的指令要么全部失败，要么全部成功执行，不会出现部分指令成功执行而部分失败的情况。

在浏览器中查看 Solana 交易

我们使用另外一个 Solana 浏览器来查看前面创建程序账户的交易👇。在 Overview 中能够看到 Solana 交易的签名、最近区块哈希等信息： 3uKQ85Lpsnwb5D6CgUntoMyJX3tSaeGb4pjUoMaMyNVqQNPp5PRG1kJEEEk3YNdWLYEMZGmoJ5Rowgon8hZzwL9D

而在 Account Input 中则列出了当前交易涉及到的所有账户以及相关账户在交易中的特征。我们可以看到除了发送者、程序账户等地址外，两个 Native Programs 和 Sysvar 账户也被包含进去了。

由于该交易是一个简单的程序创建交易，所以它只包含了两条指令，第一条指令的接收者是System Program，负责创建程序账户；第二条指令的接受者则是BPF Loader，负责将实际部署的 eBPF 代码写入到数据账户中，并将其地址写入到程序账户的 Data 字段。

总结

Solana 上的智能合约采用 Rust 语言开发，并在 eBPF 虚拟机上运行。它遵循账户模型，链上的账户需要维持租金才能保证数据的可用性。交易由一条或多条指令组成，明确定义了依赖的所有账户，从而使得交易能够被并行处理，提高了吞吐量并降低了响应延迟。这些特点共同促进了 Solana 的快速发展，使其成为备受青睐的区块链平台之一。