期号
当前玩法下的唯一业务编号，用于关联开奖、链上输入和生成记录。
例如：日期序列与当日期次组合
算法总览
双链开奖算法的重点不是让计算过程变得复杂，而是让期次、链上数据与最终号码之间形成稳定对应关系。每个环节都保留可识别的输入和输出：期次先确定目标时间窗口，再从两条链分别选取符合条件的区块；区块字段经过统一格式处理后按固定顺序组合，组合结果进入摘要与数字映射环节，最终形成对外展示的号码。
读取期号、玩法频率与该期截止时间，确定本次计算边界。
按时间规则寻找两条链各自满足条件的候选区块。
读取区块高度、时间戳、完整哈希及规则指定字段。
统一大小写与长度，并按固定链顺序拼接输入。
对组合串执行确定性摘要、截取和数字映射。
同时保存输入、规则版本、中间值和最终号码。
算法页面说明的是数据如何流动。核对某个真实期次时，应使用该期生成记录中标注的规则版本、目标时间、区块高度和完整哈希；不同规则版本不得混合计算。
期次与区块映射
期号是业务层索引，区块高度是链上索引。两者不能直接用数字相等的方式对应，因此中间需要一个明确的目标时间。对于波场以太1分、3分和5分玩法，系统按照各自的开奖频率计算期次截止点，并把该时刻作为两条链共同使用的时间参照。
映射时关注的是“哪个区块符合该期规则”，而不是随意选择离截止时间最近的区块。通常需要检查区块时间戳是否跨过目标边界、区块是否已达到规则要求的确认状态，以及同一链上是否存在替代候选。这样可以避免因为两条链出块节奏不同而误用数据。
两条链使用同一期次边界，但会产生不同的区块高度和时间偏差。
目标边界后首个满足规则并达到确认条件的区块成为候选。
期次目标时间 T
开奖频率 + 期号 → 统一时间边界
Ethereum 候选区块独立判断，不要求与 TRON 拥有相同高度或相同秒级时间戳。
| 映射检查项 | TRON | Ethereum | 为什么需要记录 |
|---|---|---|---|
| 目标时间 | 与同一期次边界比较 | 与同一期次边界比较 | 证明两条链服务于同一期次 |
| 区块高度 | 保存 TRON 高度 | 保存 Ethereum 高度 | 便于在区块浏览记录中直接定位 |
| 链上时间戳 | 检查是否符合边界条件 | 独立检查边界条件 | 解释候选区块为何被选中 |
| 确认状态 | 按规则等待确认 | 按规则等待确认 | 降低短暂链状态变化带来的影响 |
链 A
TRON 侧记录独立的区块高度、区块时间与完整哈希。选取过程先根据期次目标时间定位候选范围，再应用确认条件。最终进入算法的必须是被记录锁定的区块，而不是查询时临时取得的最新区块。
链 B
Ethereum 侧采用相同的期次时间参照，但按照自身链上出块状态确定候选。由于两条链的出块间隔、区块高度和确认节奏不同，Ethereum 区块不需要在数字上与 TRON 区块对应，只需要分别满足同一规则。
某条链暂未满足确认条件时，不以另一条链的数据替代，也不跳过该项输入。
同样的两个哈希如果交换前后顺序，会产生不同的组合文本，因此链顺序必须写入规则。
页面上的省略号仅便于阅读，实际计算和验证应使用记录中保存的完整值。
输入字段释义
完整记录不仅显示开奖号码，还应说明号码由哪些字段产生。下面这些字段共同回答三个问题：这是哪一期、选中了哪两个区块、使用哪套规则完成转换。
当前玩法下的唯一业务编号，用于关联开奖、链上输入和生成记录。
例如：日期序列与当日期次组合
区分1分、3分或5分开奖，并据此计算相邻期次与目标时间。
频率不同，期次时间边界不同
由期号和玩法规则得到的统一时间参照，两条链均围绕它选择区块。
使用明确时区和秒级时间
区块在对应链上的序号。TRON 与 Ethereum 各保存一个高度。
用于快速定位，不直接互相比较
区块被链上记录的时间，用于判断其是否满足该期映射条件。
必须与目标时间一同阅读
区块内容对应的固定长度摘要，也是双链组合中的关键原始输入。
计算时使用完整哈希
标识字段顺序、规范化方式、摘要方式和号码映射方式。
复算时必须使用同一版本
双链组合文本经过确定性转换后形成的中间结果。
用于连接原始输入与开奖号码
双链数据组合
为了让相同输入在不同设备和不同时间得到相同结果，组合前必须先消除格式差异。常见处理包括移除展示空格、统一十六进制字母大小写、保留或移除前缀、确认字段长度，并以明确分隔符连接期号、TRON 哈希和 Ethereum 哈希。
分隔符的作用是避免字段边界含糊。例如，三个字段直接相连可能无法判断某个字符属于前一字段还是后一字段；加入固定标记后，输入结构可以被准确重建。具体期次应以生成记录展示的规则版本和组合文本为准。
// 从期次记录和两条链读取
period = "20250308-1201"
tron_hash = "0xA91F...72BC"
eth_hash = "0x08dE...F19a"
rule = "DC-1"
// 按规则统一格式
period → 20250308-1201
TRON → a91f········72bc
ETH → 08de········f19a
版本 → DC-1
// 固定顺序与分隔符
// 组合后进入摘要转换
digest = HASH( combined_input )
结果转换
区块哈希本身通常是较长的十六进制字符串，不能直接作为常规开奖号码展示，因此需要经过确定性转换。所谓确定性，是指同一规则版本接收完全相同的输入时，必须得到完全相同的中间摘要和最终号码；任何人按记录复算，都应能够重现该结果。
把完整组合串送入规则指定的摘要函数，得到固定长度的十六进制结果。
按照固定位置或分组长度读取摘要片段，位置必须由规则定义，不能在开奖后选择。
将十六进制片段转为整数，再按玩法规定的号码范围执行取模或对应映射。
依据位数、前导零和号码顺序要求形成最终展示结果，并写入生成记录。
输入
期号 + TRON 哈希 + ETH 哈希
中间结果
组合串 + 生成摘要
输出
规则对应的开奖数字
单期演算示意
以下数据仅用于解释阅读顺序，不代表实际开奖。示例故意缩短哈希和摘要；真实复算需要从对应期次记录中读取完整字段。
示例期次
20250308-1201
玩法：波场以太1分 · 规则版本：DC-1
根据玩法频率和期号得到目标时间 T。该时间仅作为选取边界，不直接转换为开奖号码。
TRON
高度 69,840,321
哈希 a91f…72bc
Ethereum
高度 22,009,418
哈希 08de…f19a
先规范两个完整哈希，再按“版本、期号、TRON、Ethereum”的顺序加入字段标记和分隔符。链顺序在计算前已经确定，不能根据结果调整。
组合文本得到示意摘要 7c2a…91e4。规则随后从指定位置取段，而不是寻找看起来合适的数字。
摘要片段被转换为整数，再映射到玩法定义的号码范围。最终记录同时保存开奖号码、输入区块、组合摘要和规则版本，使结果能够从输出反查到输入。
记录交叉核对
算法原理回答“如何计算”，而链上数据、生成记录和历史结果分别回答“用了什么输入”“保留了哪些中间值”“最终公布了什么”。核对时以同一期号为主线在这些页面之间切换，可以避免把不同期次或不同规则版本的数据混在一起。
按期号查看 TRON 与 Ethereum 的区块高度、时间戳和哈希。
查看区块输入检查记录中的区块哈希与待核对字段是否保持一致。
核验哈希查看期次输入、规则版本、中间摘要和号码生成过程。
追踪生成过程确认同一期号最终公布的号码及其历史排列位置。
对照开奖结果波场以太双链哈希彩票数据中心
联系时请提供玩法名称、完整期号、发现差异的字段及页面显示值。涉及区块哈希时，建议同时注明 TRON 或 Ethereum，便于准确定位记录。
周一至周五 09:00–18:00（北京时间，法定节假日除外）
波场以太双链数据中心以期次记录为索引整理双链开奖数据。算法说明用于帮助理解字段之间的关系；复核具体结果时，请以该期完整生成记录中列出的输入、规则版本和链上数据为计算依据。