链上随机数怎么变成中奖号 · 用户钱怎么从一堆地址归集到热钱包 · 冷热钱包怎么分层防风险 · 用户的提现怎么走 sign-service 出去。
面向老板 / 投资人 / 新员工，技术细节放在折叠区，主线看动画。
Four key mechanics explained with animations: how the draw works, how funds get swept, hot/cold tiering, and how withdrawals flow through the isolated sign-service.
sign-service 签名服务
wallet-service 钱包账户
chain-service 链上交互
game-service 抽奖（开奖）
admin-service 运营后台
message-service 站内信 / TG 推送
平台不能决定谁中奖。中奖号由链上随机数算出来 —— 区块产生时谁也无法预测，
产生后所有人都能看到，任何人都能用同样的算法独立复算结果。
本节演示 VRF_ONLY 模式：Chainlink VRF 在 BSC 上提供随机数，game-service 链下取模算中奖号。
本节定位 30 秒搞懂"为什么链上开奖是公平的"。三种引擎的取舍 / RNG 风险 / 合约可升级与否等深度技术决策，见 三种开奖引擎怎么选 →
game-service 在售罄（或截止时间）那刻，发一条内部 Kafka 消息 game.draw.requested，draw-engine consumer 拿到后委托 chain-service 调合约。
chain-service 构造一笔 tx 调 TreasureParadise.requestRandomWords()，tx 经 sign-service 签名后发到 BSC。合约内部转调 IVRFCoordinatorV2Plus.requestRandomWords()，返回一个 uint256 requestId。这个 tx 写到链上立刻可见。
Chainlink 节点网络（多节点联合，单点不能作恶）在链下用 VRF 算法生成 256-bit 随机数与证明，再发一笔 fulfillment tx 调合约的 fulfillRandomWords(requestId, randomWords) 回调。这一步通常 1–3 分钟。
合约在回调里 winningIndex = randomWords[0] % ticketAll 算出获奖下标，emit WinnerDecided(round, winningIndex, requestId, randomness) 事件并把结果固化到合约存储。randomness 与下标都明文写在事件里。
chain-service 监听到 WinnerDecided → 反查中奖票的拥有者 → game-service 派奖 → 用户在 Mini App 收到通知。任何用户也可以在 BscScan 找这条 fulfillment tx，看 fulfillRandomWords() 调用，自己 mod 一遍验证。
Chainlink VRF 由全球多个独立节点合作生成，单一节点串通其他节点的成本极高。
tx hash 公开，进 BscScan 看 fulfillRandomWords() 事件，randomness 一目了然。
不能。开奖凭证（tx hash）一旦上链就不可篡改；平台只能消费这个数字。
one.draw.mode，详见 draw-modes-explainer →FULL_CHAIN 或 BACKEND，BSC 侧主推 VRF_ONLY。environment × executionChain 正交配置实现。每个用户在每条链上有独立的充值地址，方便系统识别"这笔钱是谁的"。 但散落在一堆地址里的 USDT 没法直接出款。需要把它们定期归集到统一的热钱包。 归集会烧一点 gas，但换来资金集中管理 + 出款效率。
$50 USDT 立即归集（不等定时）。$5（gas 不划算）的地址等积累。chain-service：扫地址余额、构造 batch tx。sign-service：签名（用户地址的私钥也归 sign-service）。wallet-service：归集记账（账本不变 —— 用户余额不动，是平台内部的物理调度）。admin-service：运维监控归集成功率、gas 成本、异常地址。资金不能都放在同一个钱包里 —— 如果热钱包被攻破，损失就是全部资金。 分层做法：热钱包只放维持日常出款的最小余额；超出部分推到冷钱包长期储备。 热钱包余额低于阈值时，从冷钱包回填。冷钱包是离线签名，攻击面极小。
$10k，覆盖 ~24 小时高峰出款。$10–15k。
用户点提现到链上完成，6 步 —— 但只有 第 4 步真正接触私钥。
私钥永远只在 sign-service 子网里，业务服务永远不持有 —— 这是整个系统最重要的安全边界。
本节定位 视觉直觉版 —— 解释为什么需要 sign-service。每一步的参数 / nonce / idempotency / 失败回滚等工程细节，见 提现 + 签名隔离时序 →
PENDING_OUT。
v1.0 默认全部走运营审核（不分金额；小额自动放行为后续可配置开关）。
mTLS + IP 白名单 调 sign-service。
withdraw.confirmed →
wallet-service 标 DONE → message-service 推 TG Bot 通知 "已到账 + tx hash"。
如果业务服务（wallet-service / game-service）直接持有私钥，任何 RCE 漏洞 / SQL 注入 / 容器逃逸都可能直接提走资金。
把私钥隔离到 sign-service，业务面的攻击只能调用有限的内部签名 API，签名前还有白名单 / nonce / 限额多重校验。
即使业务面被打穿，资金仍然安全。
这是整个系统的最关键安全边界，所有动手前都要 review 是否动了这条线。
$1,000 USDT，超出走运营审核。$10,000 USDT / 用户，避免账户被盗 + 一次性掏空。