一粒の種は一度しか花を咲かせられない。だから種をまく前に、収穫用の種を集めることは自分でやり切るしかない、と考えておく必要がある。

これは私が庭で考え抜いてたどり着いたことだ。@BabylonLabs_io のWOTS秘密鍵というのは、この種に相当する。使い切りであり、使った鍵素材は無効になる。新しい手順を踏むなら、新しいプロセス（新しい鍵材料）に切り替えなければならない。プロトコルは「使い切り」を最初から固定しているので、バックアップ（予備）の責任はユーザー側に委ねられている。

では、思考実験をしてみよう。もし鍵を繰り返し再利用できるとしたら、何が起きるだろう？署名に使う材料の再利用は、攻撃者に「繰り返し悪用できる窓」を与えることと同じだ。どこかで一度漏れれば、次もまた同じ被害に遭う。

私は「使い切り」設計は面倒だと思っていた。でも読み終えて分かった。これにはリスクを最前線で遮断する狙いがあるのだ。鍵は使い切ったら捨てる。漏洩の窓はその時点で閉じる。庭でも、一粒の種は一度だけ花を咲かせる。それはむしろ害虫対策として最善の方法だ。虫が一度食べたら、次には食べ物（花）がない。

ではユーザーは何をすべきか？バックアップだ。種が使い切られたらもうない。だから播種（種まき）の前に、次の種の準備を整えておかなければならない。バックアップ一覧は、金庫との対応関係を控え、使い切りの状態を記録し、材料の保存場所を書き留める。1項目でも漏れれば、収穫の一季分を落とすのと同じだ。

バックアップ一覧には具体的に何を書けばいい？金庫との対応関係、使い切りの秘密鍵の使用状態、材料の保管場所。この3つが欠けてはならない。場所だけ覚えて状態を書かないと、種がそこにあるのか、ないのか分からない。状態だけ覚えて対応関係を書かないと、収穫が誰のものか説明できない。庭の掟は、必要な印をすべて付けてこそ来年の収穫につながる。

$BABY の生態系では、「一度しか使えない」と書かれているものは、必ずバックアップを2つ取る価値がある。

締めくくりに一言：使い切りは難癖ではない。安全コストを、作成したその日へ前倒ししているだけだ。前倒しされたコストはユーザーに見えるが、後回しされたリスクはユーザーからは見えない。見えるコストは管理しやすい。見えないリスクが怖いのだ。花を育てる人なら知っている。良い収穫は「選種」から始まる。バックアップという宿題は、播種の前にこなすこと。材料は3か所に置く：ローカル、オフラインディスク、紙。チェーン上にはインデックス（索引）を残しておけば、1つ失ってもあと2つがある。

この設計をじっくり見ていくと、見るほど自然であることが分かる。一度限り（使い切り）はプロトコルの安全な下限。バックアップはユーザーの責任の境界。両者はそれぞれが担当する範囲をきちんと守る。Babylonは、下限と責任をはっきり分けてくれている。あとはユーザーが手順どおりにやればいい。#baby