原文作者：Sentinel
原文链接：
本文讲述了 GoZ (Game of Zones) 挑战赛的意义与目的，以及 Sentinel 团队在第 1A 阶段的经历与采用的独家战略，是 Sentinel 关于 GoZ 赛事系列博客的第一篇。
Sentinel 与 Responsible、IRISnet 、Aurel (Dokia Capital) 等战队在第 1 阶段被授予了获胜者的荣誉，我们在这次比赛中的表现都可圈可点。
GoZ 第 1 阶段获奖者详情：
GoZ 挑战赛进度：
什么是 GoZ 挑战赛
GoZ (Game of Zones) 挑战赛是围绕 Cosmos 区块链互操作性协议（跨链协议 IBC）展开的对抗性比赛。IBC 是一个革命性的范例，它改变了区块链互联的通讯机制——能在高价值的加密货币网络中建立桥梁，使交易与数据能在链间传输。
可以把它看做是一个测试网——GoZ 可以对 IBC 协议进行压力测试和尽可能地加以利用，从而收集到宝贵的数据和见解来让这个协议更为稳定和可靠——为在几个季度内即将到来的 IBC 发布做好准备。
主办方的海报展示了比赛各个阶段
为什么 Cosmos 的IBC协议如此重要 ？
加密货币激励了分布式网络的运行，互操作性解决方案能促进资产和数据在这些网络里进行交换，并有能力去削弱区块链行业里的部落主义：当这些网络想在彼此身上建立优越性时，常常会导致冲突。
事实是，有一些（区块链）网络拥有靠自身的定制架构和独特的开发重点来实现的独一无二的服务主题。互操作性能让这项能力实现：生态里的参与者都能去利用彼此的优点——而不仅仅只去进行比较，从而达成发挥自身特性的同时又能实现功能的水平扩展。
通过去有效地连接每条区块链，Cosmos 旨在去减少生态系统里的部落主义和分歧。此外，Cosmos 的 IBC 协议能让这些区块链上的应用去拓展自身的目标市场人群，吸引更大规模的用户：通过使这些应用有能力去实现动态的跨链支付，降低了它们的获客难度。
当前，Cosmos 与其他非常有价值且受人尊敬的区块链网络之间意义最重大的互操作性计划包括Cosmos 和 ZCash、Polkadot 之间建立可互操作的「桥梁」。
世界上最大的两个区块链正在融合：
Chorus One 要连接 Polkadot 和 Cosmos 生态：
接下来两年， IBC 模块将毋庸置疑地连接起大多数杰出的区块链网络。GoZ 让这个愿景更近了：通过 Cosmos 的 IBC 模块，一个共生的，团结的密码货币生态将形成。
第1A阶段发生了什么？
第1A阶段，每个参赛队伍要建立自己的 Zone（分区，跨链生态中的独立区块链），并连接到 GoZ Hub（枢纽）——Cosmos 主链（通证为 ATOM）的测试版。
比赛评分的关键点在于活跃度，或者每个战队的 Zone 与 GoZ Hub 连接的持续时长，此时的 Hub 面临着潜在的攻击和其他无法预料的事件——这些都会导致 Hub 宕机。
Sentinel 和 Responsible 团队在连接 GoZ Hub 时达到了最高的在线时长或活跃度——两个团队连接 Hub 的持续时间都为 102 小时 30 分 40 秒，在这期间还躲过了引起其他团队一直掉线的攻击。
第1A阶段正式计分板https://github.com/iqlusioninc/relayer/blob/jack/phase1/docs/goz-phase-1-scoring.csv
Sentinel第1阶段独家策略&对社区的贡献
Sentinel 为比赛第 1A 阶段做了两个定制战术：
-
一个定制的脚本——既能给 Hub 发送客户端更新，也能用于更新特定区块头
-
当其他 99% 的参与者都无法保持与 Hub 连接的时候，Sentinel 通过实时修改区块头以保持与 Hub 的连接
1.Sentinel 的定制脚本
Sentinel 团队开发了一个定制的脚本，用于从 Zone 往 Hub 发送客户端更新。这个脚本让团队于在线时长上与 Responsible 团队并列第一。
GoZ 主办方实际上为比赛开发了官方的中继器软件，并将它开源给参与者，使参与者可以在中继器上做修改和建造，来建立自己的优势。Iqlusioninc 团队开发的中继器详情：
Sentinel 团队决定去建立自己的定制化程序，而不是去修改官方的中继器，是出于有这么一个需求的存在：考虑到在此阶段的比赛中可能会进行几种不同类型的攻击，需要去建立一个本地 GO 语言代码的解决方案，以便去实时改进性能。
为了更新中继器上的客户端，大多数团队使用了 Shell 脚本和命令行界面，这些脚本通常没有重试机制，也没有使软件进入睡眠状态的能力（在上一次更新和下一次更新之间）。此外，原始的中继器软件不支持更新客户端的多次重试，而定制的脚本大约每 10 秒会重新发送 100 次相同的交易给 Hub，以确保消耗尽可能少的手续费（gas）。以下是 Sentinel 团队在第1阶段中使用的客户端更新脚本：
2.对区块头的实时修改
大约在 UTC 时间 5 月 6 日 下午四点半， GoZ Hub 由于延迟停止了反应，可能是剪枝故障或 RAM 存储不够造成，也甚至可能是因为 P2P 层的拥挤。
除了 Responsible 团队和 Sentinel 团队，其他参与者与 Hub 的连接都掉线了：当时 Sentinel 团队设法去更新有旧的区块头的客户端，此区块头满足 RPC （远程协议调用）端点的时间，且始终与 Hub 保持同步。
为了更新这个旧的区块头，团队修改了自身定制化脚本的第 114 行：
header, err := dst.QueryHeaderAtHeight(HEIGHT)
where HEIGHT is the block number which meets the Hub timestamp
当 Hub 处于延迟状态时，所有参与者都有大约 1 小时去更新 Hub 上边的客户端信息。然而，几乎所有更新的交易信息都被 Hub 的公共 RPC 端点和全节点驳回——因为当时它们也跟着一起延迟了。
这次意外后，为了帮助官方的中继器软件能在信息的变化中做到同步（属于原链特定高度的客户端更新），P2P.org 团队提交了一个拉取请求（pull request）：