积分：加密生态参与的催化剂

作者：Kautuk Kundan, Manan @Stackr Labs；编译：Leia @TEDAO

译者导读：

积分系统作为一种激励机制，能够促进用户与协议的互动，从而推动协议的发展与增长。它是一种工具，而不是目标。积分不应该成为用户使用产品唯一的原因，产品本身应该具有吸引力。同时，用户需要清晰、可预测的规则来理解如何获得积分，而链上积分可以避免传统积分系统的“黑箱”问题。

Micro-rollup，作为一种在链上实现积分系统的方法，提供了一种既节省成本又高效的方式。它通过在链下执行逻辑操作然后将验证结果推送到链上的方式，既保证了操作的速度和灵活性，又确保了数据的可验证性和安全性。

这不仅为开发者提供了一种新的工具，也为整个加密生态系统提供了一种新的思考方式，即如何将技术创新应用于提高用户参与度和激励机制。

近来，积分迅速成为加密生态中推动用户参与的催化剂，引领了众多顶尖团队和协议的成功实践。其概念并不复杂：用户通过促进协议发展的方式与之互动，从而获得协议以积分形式发放的奖励。这一机制与许多视频游戏中常见的经验值（XP）系统类似，玩家通过不断积累经验值，提升自己的排名；而排名的提升，又会激励玩家继续努力，争取获得更高的排名。

许多协议将积分作为引入协议治理代币（token）的前奏，表明代币的分发将基于用户所积累的积分数量。这种策略为协议和团队在公布代币细节之前争取到宝贵的时间，同时也推迟了他们出现失误时所面临的审查。积分积累的运作方式和收益耕作（yield farming）类似，但是没有直接的经济激励，而是提供一种更为广泛的用户参与和奖励方式。

现在，使用积分激励用户并促进协议的发展已经成为一种新趋势。有趣的是，从理论上讲，积分的供应量可以是无限的，这为传统空投机制带来了新的变化，使其与实际代币区别开来。

积分的问题

PMF 不应被理解为 “Points Market Fit”（积分市场匹配度）。如果一个产品在没有积分系统的情况下无法获得用户青睐，那么在其之上再添加积分系统并称其为 PMF 也是无济于事的。积分不应成为决定用户选择产品 X 还是产品 Y 的关键因素，而应是产品 X 和 Y 都能为用户提供内在价值。

另一个重大问题是，大多数积分系统都是“黑箱”，随着时间的推移，它们的计算属性不可预测。这种不透明性有利有弊——有利是指，它赋予了团队更大的灵活性来调整系统的规则；而弊端则是，它同时也剥夺用户可感知的控制权或影响力。

游戏获取经验值（即积分）的规则应当是清晰且可预测的！

如果积分系统是可审计、透明且可预测的，同时又能保持足够的灵活性，让团队围绕它设计各种活动，那将会怎样呢？

链上积分

在链上实现积分系统是一个吸引人的想法，但这不应该只是为了创造另一个 ERC-20 代币的幌子。曾经有协议推出过一种预发行代币，承诺最终会将其转换成另一种代币（本质上就是变相的积分），结果只是让生态系统中充斥着不必要的代币。

将链上积分设想为与 ERC-20 代币不同的存在，通过积分系统的组合性可以为用户创造出独特的体验。然而，无论是在 Layer-1 还是 Layer-2 层面实现一个链上积分追踪系统都需要高昂的成本，这就引出了一个非常关键问题：为什么不直接用 ERC-20 代币来代表积分呢？

这种情况凸显了为什么链上积分系统是作为 Stackr 上的 micro-rollup 来开发的理想选择。深入研究现有积分系统基础设施所面临的问题，团队通宵达旦地进行了内部研究冲刺，最终开发出了一种专用的虚拟机（VM）来跟踪和管理协议的积分。

Micro-Rollups 快速入门

Micro-Rollup 端到端工作流程

Micro-rollups 本质上是一种状态机（state machines），它可以在链下执行特定的逻辑运算，然后将执行验证外包给一个叫做 "Vulcan" 的验证层。Vulcan 负责验证状态更新，并将计算数据提交到链上。

-状态机具有定义好的状态形态，并且会根据一组初始条件（genesis condition）进行初始化，以确定状态机的起始状态。

-状态机包含一组动作（可以理解为交易类型），当被调用时，这些动作会触发状态机上的状态转换函数。

-状态转换函数（State Transition Function，STF）负责执行计算并更新状态机的状态。STF 执行完毕后，这些动作会被打包成一个区块，并发送给 Vulcan。

最后，Vulcan 会：

悲观地假设 STF 的计算结果可能存在错误或者恶意篡改，重新执行区块中的动作，以确保结果的正确性。

为已验证的区块生成元数据。

在 Layer-1 和 DA 上完成结算。

Micro-rollup 更新后的状态被发送到 DA。

经过验证的区块的元数据和更新后的状态根（state root）被安置到 micro-rollup 在 Layer-1 上的 inbox contract 中。

上述流程共同构成了 Stackr 的 Micro-Rollup 框架的工作原理。

积分系统 Micro-Rollup

那么，为什么 micro-rollups 特别适合构建积分系统呢？

Micro-rollups 提供了快速、灵活、自托管的执行环境。

这确保了积分的发放不会产生“链上”开销，并且所有状态更新都能尽可能快地发生。

Micro-rollups 支持可验证的链下计算。

尽管是自托管的，该框架仍然可以保证在数据结算到 Layer-1 之前，任何进入系统并改变状态的数据都能得到充分验证。这确保了系统以可预测的方式运行，并且不会被篡改。

Micro-rollups 使状态可审计。

一旦状态机被部署，STF 的逻辑就不能被更改。这为用户提供了一种保障，确信系统的规则不会被提供者随意修改。

Micro-rollups 可以直接在 Layer-1 上进行结算。

由于 micro-rollups 可以直接在 Layer-1 上进行结算，状态证明可以在合约内部直接使用，进而实现链上操作。验证层通过提供预结算保证，能大大缩短结算周期。

构建积分系统的探索之旅

免责声明：本演示仅展示了该框架的功能，是一个未经任何优化的版本，不适用于生产环境。请将此内容理解为说明性的示例，而非最终产品。

在开发 micro-rollup 时，以状态机的形式去构思逻辑至关重要。这需要仔细考虑 micro-rollup 的状态（即它将保存的数据），以及决定 STF 行为的动作（该函数会对状态进行操作）。

从状态机的视角思考应用构建

秉持上述理念，我们使用 Stackr 的 SDK（开发工具包）开始设计 micro-rollup 的状态。

设计

当用户在平台上执行链下或链上动作时，会触发事件（events）。管理员也可以为用户分配事件。

积分存储在链下的状态机中。

系统包含一个 STF，用于决定授予用户积分的时间和数量。

事件会触发 STF，状态会基于用户的最新积分进行更新。

每过一个设定的时间段（epoch），就会生成一个区块，其中包含用户事件的详细信息和更新后的积分表状态。

区块被发送到 Vulcan 网络进行验证。

如果区块符合状态机的规则，则被批准。

区块数据拆分为两部分，分别在 Layer-1 和 DA 上进行结算。

Micro-rollup 架构中的积分系统

定义基础状态

首先，我们添加 admins （管理员）和 eventRegistry（事件注册表）：

admins： 可以注册事件实体并为用户分配积分的地址。

event： 用户可获得积分的任何类型的实体。它可以是链上事件，也可以是手动添加的自定义事件。例如：“sign-up”注册事件（自定义）可以获得 200 积分，“swap”兑换事件（链上）可以获得 500 积分等。

接下来，我们需要一种方法来跟踪用户有资格获得积分的事件。

一个用户可能进行过 1 次 sign-up 事件和 5 次 swap 事件。每个事件都是 eventLog（事件日志）中的一个条目。

我们在状态中添加了 eventLog，以跟踪每个用户对应的所有链上事件以及每个事件的最大积分。目前，我们不需要积分子字段，因为它可以从 eventRegistry 中获取。但为了使系统更灵活，以便未来扩展，我们仍然添加了该字段。

添加状态更新处理

在设置好最小可行状态（minimum viable state）后，我们需要定义更新状态的 reducers。

添加 logEventReducer，负责为用户的事件创建日志条目。

详细拆解如下：

管理员使用事件名称和用户标识符调用 logEvent 动作（本文不包含此操作的详细讨论）。

此动作会触发状态机并调用 logEventReducer。

这个 Reducer 随后会：

查找与事件对应的积分。

基于事件和相应的积分来更新用户的事件日志。

例如：

管理员调用 logEvent({user: mg-labs.eth, event: "deposit"})

Reducer 将在 eventRegistry 中找到 deposit 这个动作，并为用户 mg-labs.eth 记录 deposit 事件及其对应的积分。

至此，我们已经构建了一个最小可行的积分系统。

智能合约 vs Micro-rollup

如果要计算用户的总积分，我们需要遍历该用户的事件日志，并且每次计算总积分都要重复这个过程。

如果将积分系统构建为一个智能合约，这可能是一种可行的方法，但是与 micro-rollup 相比，EVM 中的存储成本极为高昂，这种设计可能并不理想。

而我们正在构建的 micro-rollup，成本相对更低，可以更自由灵活地管理状态和计算，从而可以优先考虑用户体验，而不是权衡成本。

存储计算后的积分

向状态中添加 userPoints（用户积分）

它将负责保存分配给用户的积分总和。

当记录事件时，我们也更新 logEventReducer 以更新用户的积分。

完成！

构建一个具有链上可追溯性的事件驱动积分系统，就是这么简单！是不是很容易就能为后端服务器赋予链上超能力？

链下积分上链——空投等更多可能 ✨

这个系统的美妙之处在于，它允许积分在无需高昂开销的情况下无缝地在链上使用。

正如文章开头所述，micro-rollup 的状态根会在 Layer-1 上结算。值得注意的是，开发者可以选择哪些状态数据在 Layer-1 上结算，哪些作为元数据放到 DA 上，从而实现混合安全假设。

在本例中，如果我们提取 userPoints，并将其 Merkle 化的根（root）在 Layer-1 上结算，就能直接实现用户在 Merkle 树中的包含证明（inclusion proofs）。

这一特性让我们能够无缝构建各种链上体验，包括无信任代币兑换、积分奖励、积分的链上二级市场等等。通过包含证明的方式将用户积分数据引入链上，链上体验的可能性将会大幅扩展！

这种方法实现了积分上链，而又无需将积分完全放置在链上（显著降低成本，并优化用户体验）。

畅想

目前在这篇文章中构建的积分系统仅是冰山一角，可以对其进行大幅扩展，实现诸多功能。以下是一些可能的拓展方向：

Multipliers（倍数）

团队常常喜欢在某些事件或活动的基础积分上设置有时间限制的 multipliers，因为这是一种非常有效的机制，可以与其他项目展开合作、提高社区和协议活跃度等。在这版积分系统中，我们已经在特定时间为事件存储了应当分配的积分，因此，迭代和实现 multipliers 都非常简单。

首先，更新 EventRegistry 为每个事件保存 multipliers 的列表。

如上所示，每个事件都有一组可以由团队激活和停用的 multipliers，从而实现灵活的活动设计。

为了支持上述的状态更新，我们更新了 logEventReducer 使其应用有效的 multipliers。

上述逻辑不仅可以应用一个 multiplier，还可以在计算事件分配积分数量时叠加多个 multipliers。

推荐

与 multipliers 类似，推荐系统也是许多积分系统的关键。推荐系统由于其结构可能相当复杂，因此难以完全构建在链上。

例如，MarginFi 有一个多级推荐系统 ——

将积分系统构建为 micro-rollup，使你能够在自己的独立执行环境中自由地实现上述机制，无论它们有多复杂。

积分自动化

上述系统提供了很大的灵活性，但也需要额外的基础设施，为管理员（或机器人）更新用户积分增加工作量。

我们可以通过 L1Syncer（SDK 中的内置模块）将所有用户事件从选定的合约导入到 micro-rollup；同时，Rollup 的 STF 专注于计算用户积分的算法，并透明地展示积分计算方式，这样我们就可以提升系统的自主性。

积分即声誉

积分可以很容易地被视为社交经济中的经验值或声誉积分。它们是对为协议或产品做出价值贡献的一种认可形式。在社交经济中，将积分系统作为声誉追踪器，为创造链上体验提供了广阔的空间，充满了吸引人参与和创新的激动人心的机会。

例如，Reddit 的 Karma 积分如果建立在 micro-rollup 上，也许就可以立即让那些被戏称为“毫无用处的互联网积分”的东西在链上可用。

使用此框架，可能只需要几天的工作就可以将现有的 Karma 积分系统移植到链上。

结语

积分系统在Web2与Web3的交汇处展现出了巨大的潜力，需要一种新颖的混合架构来实现。这正是 micro-rollups 提供的机遇所在。

Micro-rollups 提供了灵活选择去中心化程度的自由。它们让开发者能够按照自己的偏好构建应用程序，无论是追求完全去中心化，还是充分去中心化，亦或是一种尚未揭示的全新模式。