德州封存发牌：把底牌交付移出牌局进程
普通德州桌如何用独立发牌进程交付底牌，机器人拿到哪些信息，发牌故障为何作废退筹码，以及这项改造仍然需要信任运营方的边界。
把整副牌从牌局进程里拿走
一桌德州扑克需要有人管理轮次、下注、底池和结算。这些工作大部分时间并不需要知道玩家的底牌。过去，BluffKing 的普通发牌路径把整副牌交给牌局服务；最近的改造把洗牌和底牌交付移到了独立的发牌进程，普通德州桌统一走封存发牌，包括与机器人练习的牌局。
这次改造的价值在于减少正常运行时接触未公开牌面的代码。牌局进程继续判断谁该行动、加注是否合法、底池如何分配；真人底牌则由发牌进程通过独立连接交给对应客户端。底牌位置在规则引擎里先以不含牌面的占位表示。
这里的“封存”有明确边界：发牌进程仍然知道整副牌，运营方仍须被信任。这是进程分工和数据流约束，不是让所有服务端组件都无法知晓牌面的密码学协议。
一手牌里，信息何时进入牌局服务
创建一手牌时，发牌进程生成牌堆、牌堆承诺和各座位的领取凭证。牌局服务将凭证发给相应玩家，客户端再凭它向发牌进程领取自己的两张底牌。牌局服务的正常底牌交付路径不需要转发真人底牌明文。
| 阶段 | 牌局进程正常收到什么 | 仍留在发牌进程的材料 |
|---|---|---|
| 开局 | 牌堆承诺、座位领取凭证；有机器人时另取机器人自己的底牌 | 真人底牌和未来公共牌的明文 |
| 翻牌、转牌、河牌 | 当前轮次允许公开的公共牌 | 尚未公开的后续公共牌和真人底牌 |
| 需要摊牌 | 参与比牌的未弃牌座位底牌 | 未在摊牌中公开的牌 |
| 牌局结束 | 完整牌堆及核对承诺的材料，供持久化和局后复盘使用 | 此时不再承诺对牌局服务保密 |
这个时间边界很重要。我们需要的是在行动发生时缩小未公开牌面的接触范围，同时保留结束后的历史记录和训练能力。局后取得完整材料，并不意味着把其他玩家的弃牌公开给全桌；面向用户的历史查询仍需要自己的权限边界。
机器人也只需要自己的牌
服务器运行的机器人必须知道自己拿到了什么，否则无法正常决策。因此，含机器人的桌子不能简单地套用“牌局进程一张底牌也不知道”的说法。
封存发牌把这个例外缩到座位：创建牌局时明确登记机器人座位，专门的读取接口只允许领取这些座位的底牌。真人座位不能通过这个机器人接口取牌。规则引擎中的真人底牌继续保持不含牌面的占位，直到需要摊牌或牌局结束。
这让真人桌和练习桌可以共享封存发牌结构，同时保留机器人行动所需的数据。它约束的是正常接口如何提供信息；它本身不能证明运营方无法修改机器人或服务端程序。
发牌失败时，撤销这一手
把发牌拆成独立进程，会增加必须处理的故障：发牌服务不可用、某个客户端未完成底牌交付、公共牌取回失败，或者结束时的牌堆材料无法通过核对。
封存路径遇到无法继续的发牌错误时，会作废当前手牌并退回本手投入的筹码；恢复时也要保留期间已经入账的额外筹码。系统不会为把这一手勉强打完而改走明文发牌。后续手牌仍使用封存发牌，前提是所需服务和交付恢复正常；连续多次发牌失败会关闭牌桌，不会无限重试。
这里说的是封存发牌失败的处理，不是“玩家一断网就退筹码”的规则。普通重连、行动超时，以及高级加密协议中的违规处理，各有对应逻辑，不能从这一条故障路径推导出通用退款承诺。
必须保留的信任边界
进程隔离能减少误用和意外暴露的机会，却不能单独对抗一个控制全部服务的运营者。当前实现有几个决定性的事实：
- 发牌进程持有完整明文牌堆。
- 牌局服务拿得到座位领取凭证；这些凭证是持有即可领取的凭证，并非只属于玩家设备的密码学密钥。
- 发牌进程接受经过内部认证的公开牌和结束牌局指令，依赖牌局服务在正确时机调用；它不独立验证整段下注过程。
- 牌局结束后，牌局服务能够取得完整材料，用于持久化和复盘。
因此，准确的承诺是：正常牌局执行中，真人未公开底牌不经过牌局服务的明文交付路径；这一性质依赖运营方正确运行当前实现。不能把它扩大为“平台任何人都看不到牌”或者“无需信任运营方”。
牌堆承诺回答的是另一个问题：结束时交回的材料是否与开局承诺一致。实现将手牌标识、种子、随机 nonce 和牌序一起纳入哈希，并在接收完整牌堆时检查承诺。这个核对不能证明没有人提前看过牌，也不能单靠自身排除承诺之前的选择行为。封存发牌的承诺格式也不等同于旧版种子证明，不能据此声称旧验证工具适用于所有新手牌。
让代码检查这些边界
这次改造对应的回归检查不只关心一手牌能否顺利结束，还覆盖了几个更容易出错的边界：
- 底牌能通过发牌进程的连接直接交付，返回的手牌、座位和承诺对应正确。
- 公共牌分轮次公开，已经公开的摊牌座位集合不能事后更换。
- 机器人接口拒绝读取真人座位的底牌。
- 正常结束时取得的牌堆包含 52 张牌，重新计算的承诺与开局承诺一致。
- 封存故障会返回明确的手牌作废状态，并继续选择封存路径。
这些检查支持的是实现行为，不是独立安全审计，也不能远程证明线上进程一定运行了某份源码。本文依据 2026 年 9 月 28 日至 30 日的封存发牌改造，主要对应 sealed_dealer.rs、mp_engine_blind_live.rs 和牌局调度代码；不把内部实现文件误称为已公开的审计材料。
值得复用的做法
处理敏感数据时，可以先列清楚每个组件完成工作真正需要知道什么，再按时间和角色缩小信息流：轮到公开才取回，某个角色只拿自己的部分，结束后再开放复盘材料。最后，把故障路径也纳入同一约束，避免正常路径守住的边界在恢复时被绕开。
BluffKing 的这次改造把这个做法落实到一手牌：牌局服务负责推进规则，发牌进程负责保管与交付牌面，故障时明确结束这一手。玩家继续使用熟悉的下注操作，背后接触未公开底牌的正常代码路径变少了。