核心原则
算法不是“猜数”，而是确定的数据管线
双链算法的目标，是让同一期结果能够由相同输入得到相同输出。计算从预先确定的期次截止时间开始，不以用户提交时间、页面刷新时间或某台服务器的本地时钟为准。系统按照该期所采用的规则版本，在TRON与Ethereum上寻找符合条件的区块，将区块高度、区块哈希和期次标识整理成固定格式，再执行摘要与号码映射。
两条链承担的是共同提供公开输入的作用。单独修改展示页面中的一个号码，不会改变链上已经存在的区块哈希；反过来，只知道其中一条链的数据，也不足以完整复现双链种子。核验时应同时检查期次、时间锚点、两条链的区块高度、完整哈希、字段顺序以及规则版本。
“可复算”并不等于只看哈希末几位。完整过程还包含区块选择条件、字符规范化、字段分隔、摘要算法和号码区间映射。省略任一环节，都可能产生看似合理但与公布记录不一致的结果。
期次固定
先确定玩法、期号、截止时间和采用的规则版本。
区块可定位
两条链分别记录候选高度、时间戳、哈希与确认状态。
输入有顺序
字段按版本定义串联，不能交换链顺序或省略分隔符。
输出可复现
相同字节输入必须生成相同摘要与号码序列。
一次开奖的数据流
从期次映射到号码生成
选择任一环节查看它接收什么数据、解决什么问题，以及核验时最容易忽略的细节。
先把“这一期”定义清楚
每个玩法按照公布的开奖频率划分期次。期次记录至少包含玩法代码、期号、计划截止时间、时区和算法版本。截止时间是区块选择的时间锚点，不随网页打开时间变化。
例如某期锚点为北京时间12:30:00，转换为统一时间后再与链上时间戳比较。采用统一时间可以避免浏览器时区、夏令时或人工录入格式造成偏移。
如果期次暂停、延迟或规则版本切换，状态必须先进入期次记录。不能通过私自移动时间锚点来“寻找”另一个更合意的哈希。
两条链各自确定唯一候选区块
系统分别扫描TRON与Ethereum，在期次锚点之后按照该版本的选择条件定位候选区块。记录中保存高度和哈希，而不是只保存截图或被截短的哈希尾部。
候选区块还要达到规则要求的确认状态。确认等待不会改变原始时间锚点，它只是降低短暂分叉导致区块替换的影响。若区块后来不再处于主链，异常处理会保留原选择、替代依据和修正时间。
两条链出块节奏不同，因此对应区块的时间戳不必完全相同。关键是它们各自满足同一版本定义的选择边界。
把可读字段变成唯一字节序列
哈希统一为小写十六进制并保留完整长度；高度使用十进制无前导空格表示；时间使用统一时间格式；期号和玩法代码保持记录中的规范形式。每个字段之间加入明确分隔符。
典型顺序为：规则版本、玩法、期号、TRON高度、TRON哈希、Ethereum高度、Ethereum哈希。顺序本身也是算法的一部分，交换两条链的位置会生成完全不同的摘要。
规范化的价值在于消除“0x前缀是否保留”“字母大小写是否区分”“高度是否补零”等歧义。核验页面应展示最终种子文本或其可核对表示。
摘要提供均匀素材，玩法规则决定号码格式
组合种子进入规则版本指定的密码摘要函数，得到固定长度的十六进制摘要。随后按字节读取，并映射到该玩法所需的号码范围、位置数量及重复规则。
为减少简单取模可能产生的偏差，可先限定可接受字节区间，再对合格字节执行取模；不合格字节跳过。若当前摘要提供的合格字节不足，则按版本定义加入计数器继续派生。
最终记录应同时保存摘要、读取位置、被跳过的值和输出号码。这样用户不仅能看到结果，也能解释每一位号码来自哪里。
期次与区块的对应关系
时间边界负责定位，确认状态负责稳定
期号本身不是区块高度。1分、3分或5分玩法使用各自的时间表生成期次，而TRON与Ethereum按照各自网络节奏产生区块。映射工作要做的，是把同一个期次锚点分别投射到两条链上。
区块时间戳只用于执行已公布的边界条件，不应在看过哈希后再调整条件。常见边界表达包括“锚点之后首个符合确认要求的主链区块”或“包含指定参考时刻的区块”。具体期次究竟采用哪一种，以该期生成记录标注的规则版本为准。
当网络拥堵、节点短暂不同步或区块重组发生时，页面可能先显示“等待确认”。这表示输入尚未封存，而不是已经生成了一个可随意替换的结果。封存后如需变更，应形成独立修正记录，保留旧值、新值和变更原因。
Anchor
期次截止时间封存
记录期号、玩法、统一时间与算法版本，之后不因链上结果而移动。
TRON
定位波场候选高度
保存完整区块哈希、链上时间戳、确认信息与查询时点。
Ethereum
定位以太坊候选高度
独立执行相同版本规定的时间边界，不强求与TRON时间戳相等。
Locked
双链输入进入封存状态
确认完成后形成稳定输入，并进入组合、摘要和号码映射环节。
输入字段释义
复算一期开奖结果需要哪些数据
仅有开奖号码无法反推完整过程。下面这些字段共同描述一次计算上下文，也是比对链上数据与生成记录时的检查清单。
| 公开名称 | 作用 | 核对重点 |
|---|---|---|
| 玩法与期号 | 确定结果所属系列、频率和输出规则。 | 避免把1分、3分、5分的同日相近期次混用。 |
| 时间锚点 | 为两条链提供共同的区块搜索边界。 | 确认时区及边界是“大于”还是“大于等于”。 |
| TRON区块高度与哈希 | 构成波场侧公开输入，并用于链上定位。 | 核对完整哈希、主链状态与高度是否匹配。 |
| Ethereum区块高度与哈希 | 构成以太坊侧公开输入，并用于交叉验证。 | 不要把交易哈希、区块根或截断值当成区块哈希。 |
| 规则版本 | 定义字段顺序、编码、摘要函数和号码映射。 | 历史期次必须使用当期版本，不能自动套用新版本。 |
| 组合种子与摘要 | 连接原始链上输入和最终号码的中间证据。 | 检查大小写、前缀、分隔符、编码及摘要长度。 |
| 映射轨迹 | 说明摘要中的哪些字节产生了哪些号码。 | 核对跳过值、读取顺序、重复处理和号码区间。 |
数据组合方法
固定顺序比“拼在一起”更重要
双链数据不是把两个哈希随意相加，也不是只取各自最后一位。规范组合先把每个字段转换成明确的字符串或字节表示，再按规则版本规定的顺序连接。分隔符用于避免字段边界歧义，例如“12”和“345”不能与“123”和“45”形成相同文本。
一个便于理解的规范结构可以写成：版本、玩法、期号、TRON高度、TRON区块哈希、Ethereum高度、Ethereum区块哈希。实际复算时应使用生成记录给出的完整值，不能使用页面为了排版而显示的省略号。
Canonical sequence
规范种子结构示意
图中结构用于说明字段边界。具体期次的前缀处理、编码方式、分隔符和字段名称，以对应生成记录中的规则版本为准。
结果转换
从摘要字节到玩法号码
摘要函数把长度不一的组合种子转换为固定长度输出。输入只要改变一个字符，摘要通常就会发生大范围变化，因此摘要适合充当号码映射的稳定素材。它不是对未来区块的预测，也不能脱离原始种子单独证明区块选择正确。
映射阶段读取摘要字节，并根据玩法参数产生需要的号码位置。若目标范围为0至9，直接对全部0至255字节取模会使部分数字出现次数略有差异。更严谨的方式是仅接受0至249，再对10取模；250至255跳过。其他号码范围也可按照同一原则确定最大可整除区间。
当玩法不允许重复时，已出现号码应按照版本规则跳过；允许重复时则按位置顺序写入。摘要耗尽仍未得到足够号码，可将原摘要与递增计数器再次派生。所有跳过和续算动作都应出现在生成轨迹中。
摘要不是原始数据
先核对种子，再核对摘要；只比对摘要无法发现区块选错。
拒绝区间
跳过不能均匀映射的字节，避免简单取模带来的范围偏差。
顺序读取
从规定位置依次读取，不能自行挑选看起来合适的摘要片段。
可控续算
号码不足时按固定计数器派生，续算输入同样可以复现。
完整期次演练
用一组教学数据走完计算链路
下列数值用于解释阅读方法，不对应实际开奖。哈希在展示中被缩短，正式复算必须使用生成记录里的完整值。
示例期次：三分钟玩法 · 20260318-041
2026-03-18 12:03:00 +08:00
2026-03-18T04:03:00Z
高度 81234567 · 0000a7…3e91
高度 22456789 · 0x8bd2…f04c
组合后的可读表示
v2.1|3M|20260318-041|81234567|0000a7…3e91|22456789|8bd2…f04c
-
1
确认输入
两个候选区块达到要求后，完整哈希和高度进入封存记录。
-
2
生成种子
字段转为规定格式，并严格按照v2.1定义的顺序连接。
-
3
计算摘要
规范种子作为字节输入，得到固定长度摘要并存入记录。
-
4
映射结果
按玩法范围读取合格字节，形成号码并保存逐位轨迹。
交叉核对
把原理落到具体期次
算法说明回答“怎样计算”，期次页面回答“这一期用了什么”。建议沿着链上原始值、哈希复算、生成轨迹和历史结果四个层面依次比对。
查开奖，核双链，看清每一期。
核验结果不一致时
先检查期号、玩法、时区、区块高度和哈希是否完整，再确认规则版本、字段顺序、字符大小写及前缀处理。若链上数据相同而输出不同，应继续比较组合种子与摘要；若摘要相同而号码不同，则重点检查号码范围、拒绝区间、重复规则和读取位置。页面展示值与链上原始值发生差异时，应以可追溯记录和修正历史共同判断，不要仅凭截图认定结果。