Gatekeepers

The only gatekeepers here are NAND gates. 5,555 on-chain fighters on @XLayerOfficial — the circuit is the NFT. Fair by drand. Mint soon.

[Gatekeepers @TapeoutGK]

我们给 @BruceBlue 的 TAP-721 参考实现提了一个 PR，想解决一个很具体的问题：盲铸的揭示，怎样做到连项目方自己都动不了手脚。

【现在的问题】
参考合约 TapNetlistNFT 的揭示函数 reveal(seed) 只有 owner 能调用，而且接受任意种子。标准 §6.1 第 8 条把“种子怎么写上链”留给了各自的实现，于是：
· 清单里写了 drand 轮次，owner 照样可以写入别的种子，轮次只是一个承诺；
· drand 轮次公布以后，owner 还能继续铸造，或者让别人继续铸造。这时谁都能算出哪个还没铸出的编号会分到哪个条目，内部人和科学家可以只挑稀有的铸；
· owner 也可以改用区块哈希揭示，而在只有一个排序器的链上，区块哈希不适合当随机数。
事后检查能发现种子对不上，或者有人在轮次公布后才铸造，但那时分配已经定了，损失已经发生。

【这个 PR 怎么做】
把这些承诺变成合约里的规则：
· 控制器在部署时自己创建合集，并成为它唯一的 owner。设置铸造者、转移所有权、提交不带揭示规则的清单、区块哈希揭示、直接写入种子，这些入口全部调用不了；
· 所有铸造都必须经过控制器，在第 R 轮可能被知道之前就关闭；
· 种子只能是 drand quicknet 第 R 轮的随机数，签名在链上用 BLS 验证（EIP-2537 预编译）。R 出来以后，任何人都可以提交揭示：提交的人只能决定时间，决定不了数值；
· 每一轮只接受一种标准编码的签名，所以一轮只对应一个随机数。
另外还有一个没有 owner 的 drand 信标合约，以及一个任何人都能用的工厂合约。

【对谁有用】
· 发行方：不用再说“相信我们”，规则写在合约里，谁都能查；
· 买家和持有人：不需要信任团队，也不需要信任排序器；
· 检查工具：拿到合约和一个 drand 轮次，就能复算整套分配。
Gatekeepers 的揭示遵守的正是这条规则：没有人能挑种子，包括我们。现在它是公开代码，任何基于 TAP-721 的合集都能用。

【怎么验证的】
新增 85 个 Foundry 测试；测试数据里有 49 个从两个独立 relay 录下的真实 quicknet 轮次；两条独立的构建流程编出的字节码逐字节一致。PR 不部署任何合约，也不改动现有合约。

【已知限制】
drand 网络本身；链上时钟可能落后于真实时间（合约用信标里最新验证过的轮次来校正，剩余误差写在文档里）；一条只有管理员能走的紧急路径，只在 R 之后 72 小时、并且链失去 BLS 预编译时才会打开；还没有外部审计。固定轮次模式符合 TAP-721 §6.1；我们用的延后模式（售罄后才确定 R）需要修改草案，PR 里提了一个最小的改法。

PR 已开启，等待审阅。如果一次看太多，可以拆成三个小 PR。链接在评论区。

#TAP721 #XLayer

[Gatekeepers @TapeoutGK]

PR：https://t.co/X9XBwFjZqB
已开启，等待审阅。

[Gatekeepers @TapeoutGK]

我们给 @BruceBlue 的 TAP-721 参考实现提了一个 PR，想解决一个很具体的问题：盲铸的揭示，怎样做到连项目方自己都动不了手脚。

【现在的问题】
参考合约 TapNetlistNFT 的揭示函数 reveal(seed) 只有 owner 能调用，而且接受任意种子。标准 §6.1 第 8 条把“种子怎么写上链”留给了各自的实现，于是：
· 清单里写了 drand 轮次，owner 照样可以写入别的种子，轮次只是一个承诺；
· drand 轮次公布以后，owner 还能继续铸造，或者让别人继续铸造。这时谁都能算出哪个还没铸出的编号会分到哪个条目，内部人和科学家可以只挑稀有的铸；
· owner 也可以改用区块哈希揭示，而在只有一个排序器的链上，区块哈希不适合当随机数。
事后检查能发现种子对不上，或者有人在轮次公布后才铸造，但那时分配已经定了，损失已经发生。

【这个 PR 怎么做】
把这些承诺变成合约里的规则：
· 控制器在部署时自己创建合集，并成为它唯一的 owner。设置铸造者、转移所有权、提交不带揭示规则的清单、区块哈希揭示、直接写入种子，这些入口全部调用不了；
· 所有铸造都必须经过控制器，在第 R 轮可能被知道之前就关闭；
· 种子只能是 drand quicknet 第 R 轮的随机数，签名在链上用 BLS 验证（EIP-2537 预编译）。R 出来以后，任何人都可以提交揭示：提交的人只能决定时间，决定不了数值；
· 每一轮只接受一种标准编码的签名，所以一轮只对应一个随机数。
另外还有一个没有 owner 的 drand 信标合约，以及一个任何人都能用的工厂合约。

【对谁有用】
· 发行方：不用再说“相信我们”，规则写在合约里，谁都能查；
· 买家和持有人：不需要信任团队，也不需要信任排序器；
· 检查工具：拿到合约和一个 drand 轮次，就能复算整套分配。
Gatekeepers 的揭示遵守的正是这条规则：没有人能挑种子，包括我们。现在它是公开代码，任何基于 TAP-721 的合集都能用。

【怎么验证的】
新增 85 个 Foundry 测试；测试数据里有 49 个从两个独立 relay 录下的真实 quicknet 轮次；两条独立的构建流程编出的字节码逐字节一致。PR 不部署任何合约，也不改动现有合约。

【已知限制】
drand 网络本身；链上时钟可能落后于真实时间（合约用信标里最新验证过的轮次来校正，剩余误差写在文档里）；一条只有管理员能走的紧急路径，只在 R 之后 72 小时、并且链失去 BLS 预编译时才会打开；还没有外部审计。固定轮次模式符合 TAP-721 §6.1；我们用的延后模式（售罄后才确定 R）需要修改草案，PR 里提了一个最小的改法。

PR 已开启，等待审阅。如果一次看太多，可以拆成三个小 PR。链接在评论区。

#TAP721 #XLayer

[Gatekeepers @TapeoutGK]

为什么是 X Layer？为什么是 @Fabx_global ?

Gatekeepers 是 5,555 个链上战士。每个战士都是一块真实的 NAND + LATCH 电路，自己读战局、自己出招，整场对战由合约逐门计算，没有人手动操作。这样的玩法对链有三个硬要求，@XLayerOfficial 都满足：
1. 随机数可验证。X Layer 支持 BLS12-381 预编译（EIP-2537），@drand_loe 的签名可以直接在合约里验证。我们不用区块哈希做随机数，揭示结果谁都挑不了，包括我们自己。
2. 计算够便宜。两个 256 门的电路打满一整场，Gas 大约 1 美分。
3. 出块够快。1 秒一个区块，对战很快就能结算。
为什么是 FabX：
FabX 是 X Layer 原生的 TapeOut 协议生态，FAB 就在 X Layer 上挖出。它还很年轻：社区成立不到一个月，规模不大，靠社区自己推动，DeWEB 应用、矿机碎片化、链上游戏正在一个个长出来。正因为早，现在加入的每个项目都能真正影响它的方向。我们想和它一起长大。
所以竞技场的赛季奖池计划用 OKB + FAB 发放
#FabX #XLayer #TAP721

[Gatekeepers @TapeoutGK]

https://t.co/xWJ71DsK87