Solana Stores Bytes, Not JSON. Here’s What That Actually Means

Solana 存储的是字节而非 JSON，这到底意味着什么？

I spent weeks reading Solana accounts through explorers and RPC calls, seeing nicely formatted data token balances, authorities, supply numbers and thinking that’s what Solana stored. It isn’t. Solana stores raw bytes. Day 24 of #100DaysOfSolana made this uncomfortably real.

我花了数周时间通过浏览器和 RPC 调用来读取 Solana 账户，看着格式整齐的代币余额、权限、供应量等数据，我一直以为这就是 Solana 存储的内容。其实不然，Solana 存储的是原始字节。#100DaysOfSolana 的第 24 天让我深刻地意识到了这一点。

The Moment It Clicked

顿悟时刻

The challenge was to fetch the Wrapped SOL mint account from mainnet and decode it three different ways: using an SPL Token decoder, manually byte by byte, and via the RPC’s jsonParsed output. When I fetched the raw account data it looked like this: 82 bytes of nothing, apparently. No field names. No labels. Just numbers.

挑战是从主网获取 Wrapped SOL 的铸造账户（mint account），并用三种不同的方式进行解码：使用 SPL Token 解码器、手动逐字节解码，以及通过 RPC 的 jsonParsed 输出。当我获取到原始账户数据时，它看起来就像这样：82 个字节，看起来什么都没有。没有字段名，没有标签，只有数字。

But here’s the thing: those 82 bytes contain everything: the total supply of Wrapped SOL, the number of decimals, the mint authority, the freeze authority, and whether the mint has been initialized. All of it, packed tightly into a flat array.

但关键在于：这 82 个字节包含了所有信息：Wrapped SOL 的总供应量、小数位数、铸造权限、冻结权限，以及该铸造账户是否已初始化。所有这些信息都被紧凑地打包在一个扁平的数组中。

How Programs Know What the Bytes Mean

程序如何理解字节的含义

This is the key insight: the program that owns an account defines what its bytes mean. The Token Program knows that bytes 0–3 are a discriminator, bytes 4–35 are the mint authority option, bytes 36–43 are the supply, byte 44 is the decimal count, and so on. It’s essentially a binary schema baked into the program’s code.

这是核心洞察：拥有账户的程序定义了其字节的含义。Token 程序知道第 0-3 字节是识别码（discriminator），第 4-35 字节是铸造权限选项，第 36-43 字节是供应量，第 44 字节是小数位数，以此类推。这本质上是一种嵌入在程序代码中的二进制模式（schema）。

When you decode the account three ways—with the SPL codec, manually, and via jsonParsed—all three produce the same output:

{
  "mintAuthority": null,
  "supply": "0",
  "decimals": 9,
  "isInitialized": true,
  "freezeAuthority": null
}

Three approaches. One truth. The bytes were the truth all along.

当你用三种方式解码该账户——使用 SPL 编解码器、手动解码以及通过 jsonParsed——这三种方式产生的结果完全一致： （见上方 JSON 代码块） 三种方法，一个真相。字节始终是真相所在。

Why This Changes How You Think About On-Chain Data

为什么这改变了你对链上数据的看法

Solana explorers are doing you a favour you don’t see. Every time you open explorer.solana.com and see a nicely formatted token account, the explorer is decoding those raw bytes using the program’s known schema and presenting the result as readable JSON. If you’re building your own indexer, your own program, or your own tooling, you don’t get that favour for free. You need to know the schema. You need to decode the bytes yourself. This is why Solana programs publish IDLs (Interface Definition Languages) so that clients know how to decode the data their program writes. Without an IDL, you’re reading tea leaves.

Solana 浏览器为你提供了一种你未曾察觉的便利。每当你打开 explorer.solana.com 并看到格式整齐的代币账户时，浏览器其实正在使用该程序已知的模式（schema）解码那些原始字节，并将结果呈现为可读的 JSON。如果你正在构建自己的索引器、程序或工具，你无法免费获得这种便利。你需要了解模式，你需要自己解码字节。这就是为什么 Solana 程序会发布 IDL（接口定义语言），以便客户端知道如何解码其程序写入的数据。没有 IDL，你就像是在看茶叶渣占卜一样（毫无头绪）。

The Bigger Picture

更宏大的视角

In Web2, your database stores typed fields. VARCHAR, BIGINT, BOOLEAN—the database engine enforces types, and your ORM maps them to objects automatically. On Solana, the “database” is just bytes. The “ORM” is the program’s codec. The “schema” is whatever the program’s developers decided and (hopefully) documented. That’s a lot more power and a lot more responsibility. Raw bytes go in. Structured data comes out. Understanding what’s in between is what separates someone who uses Solana from someone who understands it.

在 Web2 中，数据库存储的是类型化字段。VARCHAR、BIGINT、BOOLEAN——数据库引擎强制执行类型，而你的 ORM 会自动将它们映射为对象。在 Solana 上，“数据库”仅仅是字节。“ORM”就是程序的编解码器。“模式”则是程序开发者所决定并（希望）记录下来的内容。这带来了更大的权力，也带来了更大的责任。原始字节输入，结构化数据输出。理解这两者之间的过程，正是区分“使用 Solana 的人”与“理解 Solana 的人”的关键所在。