装置
印刷用: 図面一式「Geiger TRNG emitter: the detector and an ESP32-C6 in a box」TM-TRNG-001 版 F (PDF、英語)。
hotbits は放射性崩壊から得る真の乱数バイトだ。装置は、CAJOE RadiationD-v1.1 カウンター基板の SBM-20 ガイガー管に密封されたトリウム校正カードを当てたもので、鋼のケースの中にある。カウントのひとつひとつは光としてケースを出る。フォトカプラを通り、ケースの外にある小さな基板がそのエッジの瞬間をハードウェアで捕まえ、サーバーへ送る。残りはすべてそこで起きる。管より下流はすべて帳簿付けにすぎない。原子核が崩壊した後に、乱数性を足すものは何も無い。
端から端までの連鎖:
| 段階 | 何が起きるか | どこで |
|---|---|---|
| 崩壊 | Th-232 系列の原子核が崩壊し、管が放電する | カードと管 |
| パルス | 基板の NE555 が放電を綺麗なエッジに整形する | カウンター基板 |
| 絶縁 | エッジがフォトカプラを駆動する。ケースの壁を越えるのは光だけ | カウンター基板の隣のフォトカプラ |
| タイムスタンプ | エミッタが立ち下がりエッジをハードウェアで捕まえ、番号付きのエッジをサーバーへ流す。ひとつひとつに確認応答がある | ESP32-C6 の基板、ファームウェア emitter |
| 欠落 | ハードウェアのカウンタが同じピンを数えるので、流れから失われたエッジは「取りこぼし」として数えられ、連鎖はそこで切れる。またいでつながることはない | エミッタと、サーバー上の extract_stream.py |
| ビット | イベント間の間隔をペアで比較し、ペアごとに 1 ビット | extract_stream.py、毎分、サーバー上で |
| 健全性 | 新しいビットが連続テストを通るか、さもなくばプールが給仕を拒む | 同じ処理の中で。健全性テストを参照 |
| プール | 新鮮なバイトが、消費水位を持つ追記専用ファイルに溜まる | API のプール |
| ゲートウェイ | 鍵がバイトを消費する。シードと再生は開放のまま | ゲートウェイ |
線源が何か珍しいものではなくトリウムカードであることには、記録しておく価値のある理由がある。永続平衡にある Th-232 は崩壊系列まるごとであり、六つのアルファ崩壊核種といくつかのベータ崩壊核種が、すべて独立に崩壊しながら一本の管で合算される。独立なポアソン過程の和はやはりポアソン過程であり、それこそが ビットの抽出が必要とする唯一の性質だ。
2026 年 10 月時点のベンチ
2026-10-05 まではカウンター基板の隣に Raspberry Pi 4 があり、すべてのエッジにソフトウェアでタイムスタンプを打っていた。それは退役した。USB-C の電源プラグが溶けたからで、さらに二つの点でも最も弱い環だった。タイムスタンプが負荷と温度でマイクロ秒単位で動き、カウンター基板とグラウンドを共有していた。代わりに入ったのが、このページの題の下にリンクした図面一式にある設計で、三つの部分からなる。
- ケース。 カウンター基板は専用の 5 V アダプタで動き、鋼のケースの中のフォトカプラを駆動する。絶縁の壁を越えるのは光だけだ。
- エミッタ。 ケースの外で、ESP32-C6 の基板が立ち下がりエッジをハードウェアで捕まえる。図面に記録された捕捉クロックは 160 MHz、すなわち一刻み 6.25 ns。番号付きのエッジを Wi-Fi で確認応答つきで流し、確認されていないエッジを 8192 個、通常の計数率で十三分ほど、停電や断線のあいだ抱えておく。ハードウェアのパルスカウンタが同じピンを数えるので、失われたエッジは黙って飛ばされるのではなく、取りこぼしとして数えられる。
- サーバー。 抽出、健全性テスト、API は今は装置ではなくサーバーで動く。抽出器は取りこぼしのたびに間隔の連鎖をやり直すので、取りこぼしをまたいで間隔が作られることはない。
2026-10-06 の時点では、エミッタと受信側は組み上がり、チップ自身のテストパルスで端から端まで動いて、取りこぼしは無かった。受信側は十秒黙ったリンクを切る。フォトカプラはカウンター基板に配線している最中で、本物のカウントはまだ流れていなかった。だからその時点でプールは管から供給されておらず、プールについて信じてよい唯一の主張は、ランディングページが読み込み時にプールを読んで述べるものだ。
図面が隠さずに述べる限界が二つある。管とカウンター基板のパルス整形器がマイクロ秒程度のジッタを加えるので、6.25 ns のタイムスタンプの下位ビットは崩壊ではなく管の雑音だ。そして最初に付けたフォトカプラは遅い代役で、速いものを注文することになっている。
このサイトのどこにあるか
ページは二つあり、どちらも装置について断言する代わりに、装置に問い合わせる。
/ja/hotbits は読み込まれた時に、稼働中のサービスからバイトプールと健全性の判定を読む。/ja/hotbits/api はサービス自身の
openapi.json を描画した上で、そこに書かれたルートをすべて呼び出す。だからリファレンスは「応答すべきだ」と主張する代わりに、どのルートがいま応答しているかを言える。
このツリーが扱う範囲と、扱わない範囲
ここにあるページは、ここから検証できる部分を扱う。抽出と健全性テストは装置のソースツリーから読んで書かれ、ゲートウェイの挙動は呼び出して測られる。二つのものは意図的に書き写していない:
- ベンチ。 接地、オシロスコープでの作業、筐体の履歴、部品表は装置自身の リポジトリにある。あれは実験ノートであり、実験ノートの書き写しは、それが真実であることをやめる方法だ。図面一式だけはベンチのうちここで配布する一片で、図面はその元から組み立てられ、リンクされる前に元と照合されるからだ。
- ゲートウェイの内部。 鍵の発行とバイト予算の管理はプールを持つサーバーの上にあり、そのソースはこのサイトがビルドするツリーには無い。 ゲートウェイのページは、サービスが観測できる振る舞いを文書化し、観測がすべてである箇所ではそう述べる。