　worm の実行系に先に挙げられた修正がほどこされ、規格にも反映された。その規格は管理機関に送られ、公開を待つこととなった。

　その期間を、情報処理研究所では公開γテストと位置付け、 worm の実行に関するファイル群と規格に関するファイル群を公開した。

　初期には、予想された問題が起きなかったわけではなかった。つまり、ネットワークの帯域と、サーバの処理容量だった。

　前者は、ともかく契約を改めることで可能な範囲での対応はなされた。後者については、別の研究課題として新たなチームが組まれた。対処としては共有サーバを多重化するという方法もとられたが、情報処理研究所では別の課題を見い出していた。分散処理に際してのネットワークの機能と構成についての課題だった。サーバ群を繋ぐ方法についての課題だった。

　その課題が課題であると認識されたのは、 worm のγテストに入り、より具体的な通信量と処理量の見込みが可能になったためでもあった。それは、ハブ、ブリッジやルータによるLANの構成という制約を受けてはいたが、同時にトポロジカルな問題であるとも認識された。あるノードからあるノードまでをいかに短い経路で結ぶか、また経路の制御をどのように行なうかという問題でもあった。

　ハブを使った場合、そのハブを中央に起くように図示することにより、ノードはスター型に配置される。この場合、あるノードが別のノードにデータを送る場合、必ず中央に位置するハブを経由しなければならない。ダムハブは論外としても、スイッチングハブであってもそれは変わらない。あるノードが通信中の場合、そのノードに対して通信を求めることもできない。

　4次元以上のハイパー・キューブとして構成されるだろうという案を歩（あゆむ）は聞いてはいたが、それが具体的にどのようなものになるのかはわからなかった。ハブか、あるいはそれに相当するものはノードとしてカウントされるのか、それに入口は一つなのか。

　また、分散処理用のライブラルはすでに昔からあるものの、それは処理を切り分けられる場合に対応したものだった。ループであれば、前回のループに依存しないような場合を分散させるようにするものだった。そちらのチームでは、それを超えた分散処理のライブラリの設計も行なっていた。もちろん分散処理に書き換えることができない部分は多くある。だが、 worm の探索データの閲覧のように、そもそも一台のサーバでなくともかまわない部分も多くある。そのような場合、さらに言うなら、サーバを一台割り当てる必要がない計算も多い。

　現在の超並列マシンのように、CPUの性能や機能が制限されていたもかまわないだろうし、より強く制限されていてもいいだろう。多体問題の多くは、それで計算時間を短縮できるだろう。それが重力であれ、電磁気力であれ、あるいはそれ以外のなにかであれ。

　正直に言えば、歩は超並列処理については理解が及んでいなかった。直感的にわかりやすい並列化は、例外もあるのかもしれないが、結果として効率的に超並列マシンを使えなかった。それだけは経験として知っていた。ではどうすればいいのか。歩の研究においては、先に行なった計算を次のステップで使うことが前提であることが多く、必要がなかったことも理由の一つだった。

　γテストは、結局のところ順調だった。γテストの間に2回サーバの増設が必要だったが、それで済んだ。さらに増設が必要なら、γテストへの参加者のリストを見れば、他のサイトにリダイレクトすることも可能だろうと思えた。

　worm の規格は最終的な些細な修正が求められた。それは worm に関する実装において変更が必要なものではなく、文書としての些細な修正だった。

　そうして、 worm の規格は公式に公開された。委員会から公開日を知らされていたチームは、ささやかな祝宴を開いた。ここからが本番とも言える状況であることも宣言された。 worm の別実装が必ず現われるだろう。それらの検証を誰かがやらなければならなかった。そのすべてに責任を持つことは現実的ではないとしても、その責任を放棄することはできなかった。