多链赌场架构：在没有账户余额层的情况下构建

Source: Dev.to

基于账户架构的问题

传统的加密赌场架构大致如下：

1. 用户存入加密货币 → 智能合约接收资金
2. 后端记入内部余额
3. 游戏过程更新数据库中的余额
4. 提现触发链上交易

这形成了一个混合系统：

• 链上用于结算
• 链下用于状态管理

缺点

• 内部余额无法公开验证
• 状态转移发生在链下
• 对账要等到提现时才完成
• 多链支持变得复杂（或受限）
• 托管风险增加

即使存款和提现在链上进行，核心逻辑仍然依赖于中心化系统。

Source: …

无账户余额模型

一种不同的方法完全消除内部余额。每一次交互都成为直接的链上交易，使区块链本身成为账本——而不是数据库。

关键特性

• 后端系统中不存储用户余额
• 每一次投注、结果和支付都通过智能合约执行
• 钱包 = 身份 + 余额来源
• 状态转换按每笔交易记录在链上

这与 DeFi 协议的运作方式更为接近。

交易流程（逐步说明）

1. 钱包连接 – 用户连接 MetaMask 或其他 EVM 兼容钱包。
2. 游戏交互 – 用户发起投注 → 交易被签名。
3. 智能合约执行 – 合约处理逻辑（RNG、结果、支付规则）。
4. 状态更新 – 结果直接写入区块链。
5. 前端同步 – UI 读取合约状态并在确认后即时更新。

• 没有内部记账
• 没有链下余额变动
• 没有对账步骤
• 所有操作在交易层面上是原子的

为什么多链支持在架构上很重要

支持单条链相对简单。支持九条链——Ethereum、Arbitrum、BNB Chain、Base、Polygon、Optimism、Avalanche、zkSync Era 和 Linea——则会增加复杂性。

关键挑战

• 跨链的 RPC 抽象
• 每个网络的 Gas 优化
• 合约部署的一致性
• 跨多个账本的事件索引
• 前端状态聚合而不产生中心化

在无账户余额系统中，你并不会在链之间“合并余额”。相反：

• 每条链维护各自的状态。
• 前端独立查询每个网络。
• 用户在每笔交易时自行选择要交互的链。

这样就完全避免了桥接的需求。

基于钱包的会话处理

在没有传统账户的情况下，会话管理转向钱包。

传统方式

• 电子邮件/密码认证
• JWT/会话令牌

基于钱包的方式

• 钱包签名
• 基于随机数的认证
• 无状态前端会话

钱包成为：

• 身份层
• 授权层
• 价值存储

这降低了后端复杂性，同时增加了对客户端安全性和签名流程的依赖。

链上透明性设计

透明性不是附加功能——它是固有的。因为每个操作都是交易，你可以：

• 检查输入和输出
• 验证合约执行
• 确定性地跟踪付款
• 审计历史活动

没有隐藏状态。

对比基于账户的系统，余额变化不透明，日志是内部的，信任是隐含的。

Maticslot 作为实时实现

Maticslot 是该架构的可运行示例。它在以下多链钱包基础的加密赌场中运行：

• Ethereum、Arbitrum、BNB Chain、Base、Polygon、Optimism、Avalanche、zkSync Era 和 Linea

关键实现特性

• 所有交互均直接在链上进行交易
• 没有账户余额系统——没有内部账本
• 钱包原生访问（MetaMask 及兼容钱包）
• 非托管流程——资金从不抽象为平台余额

平台支持完整的游戏套件：

• 老虎机
• 现场赌场
• 体育博彩
• 扑克
• 彩票
• 永续式游戏

这表明复杂的应用逻辑可以完全基于链上状态运行，而无需回退到托管后端。

设计权衡

优点

• 完全透明
• 降低托管风险
• 原生多链兼容性
• 确定性状态

缺点

• 每次交互的 gas 成本
• 与区块确认绑定的延迟
• 对非加密用户的用户体验复杂性
• 需要稳健的合约设计

开发者必须决定是优先考虑：

• 用户便利性（链下速度）
• 还是链上完整性（可验证状态）

要点

从基于账户的系统转向基于钱包的链上架构是一项根本性的变革——不仅仅是实现细节。去除内部余额层：

• 简化信任假设
• 与 Web3 原则保持一致
• 实现真正的多链交互

随着越来越多的应用采用这种模型，我们可能会看到混合系统减少，更多平台把区块链视为唯一重要的账本。如果你在该领域构建，问题不再是如何管理余额，而是是否根本需要管理余额。