Chapter 1：EVE Frontier 宏观架构与核心概念

目标： 理解 EVE Frontier 是什么，它为什么选择 Sui 区块链，以及“可编程宇宙“的核心哲学。

状态：基础章节。正文以宏观架构和术语建立为主，适合作为全书入口。

如果你对这款游戏本身还没有形成清晰直觉，建议先读 前置章节：先读懂 EVE Frontier 这款游戏。

1.1 为什么 EVE Frontier 不一样？

传统网络游戏的世界规则由开发商独断——经济系统、战斗公式、内容更新，玩家只是参与者。EVE Frontier 挑战了这一范式：游戏的核心机制是开放的，开发者（Builders）可以在游戏服务器限定的框架内，真正重写和扩展游戏规则。

这不是简单的“MOD 插件“——你写下的逻辑会作为智能合约运行在 Sui 公链上，永久可查、无需中心化服务器托管、7×24 自动执行。

它不是什么？

初学者最容易把 EVE Frontier 想成以下几种东西，但它都不完全等同：

你可以把它理解成：

EVE Frontier 不是“把整个游戏搬上链”，而是把足够重要、足够可组合、足够值得公开验证的那部分游戏规则搬上链。

三种玩家角色

本课程的目标受众是 Builder，但理解另外两个角色有助于你设计更有价值的产品。

这三种角色如何互动？

很多人第一次读会以为这三个角色是完全分开的。实际不是，它们描述的是同一套生态里的三种责任：

• Builder 负责“定义规则” 例子：写一个收费星门、租赁市场、联盟分红系统
• Operator 负责“经营规则” 例子：真的去买下设施、设置费率、颁发通行证、维护库存
• Player 负责“消费规则” 例子：购票、租装备、通过炮塔检查、领取奖励

一条最小业务链通常是这样的：

Builder 写合约
  -> Operator 部署并配置设施
  -> Player 与设施交互
  -> 链上状态变化被 dApp / 其他 Builder 继续消费

这也是为什么 Builder 不能只会写合约。你还得理解：

• Operator 在意什么：收益、权限、安全、维护成本
• Player 在意什么：价格、便利性、可预测性、是否被坑

一个最小 Builder 闭环长什么样？

如果把 EVE Builder 生态压缩成最小闭环，通常是下面这条链：

Builder 设计规则
  -> 部署设施和扩展
  -> Operator 配置参数并经营
  -> Player 付费或满足条件后使用
  -> 交易、权限和资产变化落到链上
  -> 前端和索引层把结果再展示出来

这条链里每一环都不是可有可无：

• 没有 Builder，世界里就没有新的规则设施
• 没有 Operator，设施就缺少持续经营者
• 没有 Player，规则就不会形成真实经济活动

所以后面你在设计任何组件时，都最好先问自己三件事：

1. 谁来定义规则？
2. 谁来经营和维护它？
3. 玩家为什么愿意使用它？

1.2 智能组件 (Smart Assemblies)：可编程的星空基础设施

Smart Assemblies 是 EVE Frontier 中被玩家建造在太空中的物理设施。它们既是游戏对象，也是区块链上的可编程合约对象。

更准确地说，一个智能组件通常同时有三层身份：

1. 游戏世界中的物理设施 例子：你在太空里真的能看到一个炮塔或星门
2. 链上的共享对象 例子：它有对象 ID、状态字段、权限规则
3. dApp 可访问的服务入口 例子：前端可以查询它的库存、费率、在线状态，并发起交易

所以当你说“我做了一个智能星门”，本质上不是只做了一个 UI，也不是只写了一个 Move 模块，而是做了一个：

游戏中可见、链上可验证、前端可操作的基础设施服务。

主要组件类型

🏗 网络节点 (Network Node)

• 锚定在拉格朗日点（Lagrange Point）
• 为整个基地提供能源（Energy）
• 所有设施必须连接网络节点才能运行
• 不可直接编程，但是其他组件的运行基础

📦 智能存储单元 (Smart Storage Unit, SSU)

• 链上存储物品，支持“主仓库“与“临时仓库“（Ephemeral Inventory）
• 默认只允许 Owner 取放物品
• 通过自定义合约可变身为：自动售货机、拍卖行、公会金库

⚡ 智能炮塔 (Smart Turret)

• 自动防御设施
• 默认行为是标准攻击逻辑
• 通过合约可自定义锁定目标的判断逻辑（例如：只攻击没有许可证的角色）

🌀 智能星门 (Smart Gate)

• 链接两个位置，允许角色跃迁
• 默认所有人可跳跃
• 通过合约引入“跳跃许可证 (JumpPermit)“机制，可实现白名单、收费、时效控制等

四种组件最常见的 Builder 改造方向

如果你不确定一个点子该从哪种组件切入，先问自己：

• 它本质上是“存东西”吗？优先从 Storage Unit 开始
• 它本质上是“决定谁能通过”吗？优先从 Gate 开始
• 它本质上是“决定谁会被打”吗？优先从 Turret 开始
• 它本质上依赖供能/联网约束吗？需要同时理解 Network Node

Smart Assembly 的生命周期

一个智能组件不是“发到链上就完了”，它通常会经历一整条生命周期：

1. 创建 / 锚定 设施第一次在世界里被建立
2. 归属 它被绑定到某个角色或经营主体
3. 上线 它获得能量、网络和可交互状态
4. 扩展 Builder 把自定义规则挂进去
5. 运营 Operator 调整价格、库存、权限
6. 消费 Player 与之发生真实交互
7. 下线 / 迁移 / 停用 设施可能失去能量、升级、被替换或停止运营

你后面学到的合约、dApp、脚本、钱包、索引，其实都是围绕这条生命周期服务的。

1.3 三层架构：游戏世界是如何构建的？

EVE Frontier 的世界合约使用了严格的三层架构，这是理解后续所有内容的关键：

┌────────────────────────────────────────────────────┐
│  Layer 3: Player Extensions（玩家扩展层）              │
│  你写的 Move 合约就在这里                              │
└────────────────┬───────────────────────────────────┘
                 │  通过 Typed Witness Pattern 调用
┌────────────────▼───────────────────────────────────┐
│  Layer 2: Smart Assemblies（智能组件层）               │
│  storage_unit.move  gate.move  turret.move          │
└────────────────┬───────────────────────────────────┘
                 │  内部调用
┌────────────────▼───────────────────────────────────┐
│  Layer 1: Primitives（基础原语层）                     │
│  status  location  inventory  fuel  energy          │
└────────────────────────────────────────────────────┘

• Layer 1 - 基础原语：不可直接调用的底层模块，实现“数字物理学“（如位置、库存、燃料）
• Layer 2 - 智能组件：面向玩家开放的组件对象，每一个都是 Sui 共享对象（Shared Object）
• Layer 3 - 玩家扩展：你作为 Builder 工作的地方，通过类型见证（Typed Witness）安全插入自定义逻辑

关键理解：你无法直接修改 Layer 1/2，但你可以在 Layer 3 编写逻辑，通过官方授权的 API 与组件交互。这既保证了游戏世界的安全性，又为 Builders 提供了足够的自由度。

每一层到底负责什么？

一个很实用的判断标准：

• 如果你在定义“世界基本规律”，那通常是 Layer 1 的问题
• 如果你在定义“官方设施默认怎么工作”，那通常是 Layer 2 的问题
• 如果你在定义“我的设施想怎么工作”，那通常是 Layer 3 的问题

一次真实交互是怎么穿过三层的？

以“玩家付费通过星门”为例：

玩家在 dApp 点击“购买并跳跃”
  -> Layer 3: 你的收费扩展检查是否已支付 / 是否持票
  -> Layer 2: Gate 组件执行跃迁入口
  -> Layer 1: 底层位置、状态、权限、燃料等原语完成校验与状态更新
  -> 结果写回链上对象，前端刷新

所以你写扩展时，脑子里最好始终分清：

• 哪部分是“我的业务规则”
• 哪部分是“官方组件保证的行为”
• 哪部分是“底层世界物理规则”

为什么这套分层对 Builder 很重要？

因为它直接决定了你应该把逻辑写在哪里。

比如你想做一个“收费星门”：

• 收费规则和折扣策略：写在你的扩展里
• 星门跳跃本身如何执行：由官方组件负责
• 跳跃时涉及的位置、权限、状态切换：由底层原语负责

如果你把这三件事混在一起，就会出现两种常见问题：

• 你在扩展里重复实现了底层已经保证的规则
• 你以为自己能改官方组件内核，实际根本没有那个权限

什么是 Typed Witness？

这里先给一个直觉，不深入语法细节：

• 你不能随便对官方星门说“以后按我的函数来”
• 你必须通过一种被官方接受的类型身份标记接入
• 这个类型身份就是后面会反复出现的 Typed Witness

你可以把它粗略理解成：

“我不是直接改官方代码，而是拿着一张类型化的授权工牌，把自己的扩展逻辑挂到官方组件上。”

后面在 Chapter 30 你会看到它如何具体工作。

1.4 为什么选择 Sui 区块链？

EVE Frontier 迁移到 Sui 不是偶然，而是深思熟虑的技术选型。

Sui 的核心优势

对象模型意味着什么？

在 Sui 上，游戏内的每一件物品、每一个角色、每一个组件都是独立的链上对象，具有：

• 唯一的 ObjectID
• 明确的所有权（owned by address / shared / owned by object）
• 完整可追溯的操作历史

这对游戏世界特别重要，因为很多游戏对象本来就天然适合“独立实体”表达：

• 许可证是一张独立票据
• 仓库是一座独立设施
• 条约是一份独立协议
• 击杀记录是一条独立战报

当这些东西都是对象时，你就能很自然地做：

• 转让
• 授权
• 查询
• 组合
• 历史追踪

这也是为什么 EVE Frontier 能把“设施、权限、交易、事件”做成可编程生态，而不是一堆只能内部消费的数据库记录。

这使得去中心化的所有权、交易和游戏历史存档变成了天然成立的能力。

三种最关键的对象状态

这一节如果不讲清，后面很多内容都会读着别扭。

这三种状态决定了你后面几乎所有设计：

• 权限怎么写
• 交易怎么组装
• 前端怎么查对象
• 能否并行执行

为什么对象模型特别适合空间游戏？

因为空间游戏天然就是“很多离散对象在互动”：

• 飞船是对象
• 角色是对象
• 门、炮塔、存储箱是对象
• 通行证、保单、租赁凭证也是对象

Sui 的对象模型让这些东西不需要硬塞进一个中心化数据库表或者一个巨大的合约映射里。你可以把每个设施、每个凭证、每笔关系都建成独立对象，再通过：

• 所有权关系
• 共享访问
• 事件
• 动态字段

把它们组织起来。

Sponsored Tx 和 zkLogin 为什么对游戏体验重要？

传统链上应用最劝退玩家的两个点是：

1. 要先学钱包、助记词、Gas
2. 每做一步都要自己付手续费

Sui 在 EVE Frontier 里的价值，不只是“性能更高”，而是它提供了把 Web2 玩家逐步引入链上交互的基础条件：

• zkLogin：降低钱包门槛
• Sponsored Tx：降低交易门槛
• 低延迟对象交易：降低交互等待感

这三点叠在一起，才让“游戏内点一下就完成链上动作”变得现实。

1.5 EVE Vault：你的身份与钱包

EVE Vault 是官方提供的浏览器扩展 + Web 钱包，是你作为 Builder 和玩家的数字身份。

核心功能

• 存储 LUX、EVE Token 及游戏内 NFT
• 通过 zkLogin 用 EVE Frontier SSO 账号创建 Sui 钱包，无需管理助记词
• 作为 dApp 连接协议，在游戏内和外部浏览器中授权第三方 dApp 访问
• FusionAuth OAuth 将游戏角色身份与钱包绑定

它和普通钱包的区别是什么？

普通加密钱包的思路通常是：“先有钱包，再去找应用”。

EVE Vault 更像是：“我先是 EVE Frontier 里的用户，然后钱包能力自然嵌进这个身份体系里”。

这意味着它同时承担三件事：

1. 资产容器 持有 LUX、Token、NFT、凭证
2. 身份桥梁 把游戏账号、SSO 登录、Sui 地址连接起来
3. 交互授权器 给 dApp 提供连接、签名、赞助交易能力

zkLogin 先记住什么就够了？

先不用一上来就钻密码学细节，理解这三点就够：

• 它让用户可以用熟悉的登录方式进入链上系统
• 背后仍然会落到一个可在 Sui 上使用的钱包身份
• 这不是“没有钱包”，而是“钱包创建和恢复的体验被重新包装了”

等你看到 Chapter 33 时，再深入它的证明结构和临时密钥机制。

两种货币

1.6 可编程经济：Builder 的商业可能性

回顾一下 Builder 可以实现哪些真实的商业逻辑：

💰 经济系统
  ├── 自定义交易市场（自动撮合、竞价拍卖）
  ├── 联盟代币（基于 Sui 的 Fungible Token）
  └── 服务收费（星门通行费、存储租金）

🛡 安全与权限
  ├── 白名单访问控制（哪些玩家可以使用你的设施）
  └── 条件锁定（只有完成任务的角色才能提取物品）

🤖 自动化
  ├── 炮塔自定义锁定逻辑
  ├── 物品自动分发（任务奖励、空投）
  └── 跨设施联动（A 设施的行为触发 B 设施的响应）

🏗 基础设施服务
  ├── 第三方 dApp 读取链上状态
  └── 外部 API 联动（链外数据触发链上动作）

一个最小 Builder 商业闭环长什么样？

如果你还是觉得“Builder 到底在做什么”有点抽象，可以先记住这个最小闭环：

我控制一个设施
  -> 我定义别人使用它时必须遵守的规则
  -> 规则写进链上
  -> 玩家按规则付费/持证/满足条件后使用设施
  -> 收入、权限、凭证、历史记录都留在链上

例如：

• 收费星门：按次收费
• 联盟仓库：按权限放物品
• 任务门：完成考核后才能进入
• 拍卖箱：按价格曲线卖资源

这和“做一个普通游戏插件”最大的差别是：

• 规则是公开的
• 状态是可验证的
• 资产流转是可追踪的
• 其他 Builder 还可以继续组合你的规则

第一章读完后，你至少应该能回答这 5 个问题

1. EVE Frontier 为什么不是普通 MOD 系统？
2. Builder、Operator、Player 各自负责什么？
3. Smart Assembly 为什么既是游戏设施又是链上对象？
4. 三层架构里，Builder 真正工作的层是哪一层？
5. Sui 的对象模型为什么比传统账户余额模型更适合这类游戏？

🔖 本章小结

📚 延伸阅读

• Why Build on EVE Frontier?
• Smart Infrastructure
• EVE Frontier World Explainer
• Sui 文档：对象模型