第27章 · Crypto Product は Web2 Product と何が違うのか

現実の問題

Web2の商品を八年作った人が、オンチェーンのチームへ入った。

最初は簡単な依頼だ。ステーブルコインを別資産へ替えるワンクリック購入を作る。慣れた手順で、読み込み、進捗、成功画面、再試行、計測、A/Bテストをすべてそろえた。

二週間で、サポートとデータに六つが出た。

1. 押しても何も起きない。買う資金はあるが、手数料のネイティブトークンがない。
2. 三回押した。四十秒待って止まったと思い、さらに二回押す。三取引とも成立した。
3. 成功後に、いつ取り消せるかと聞く。
4. アドレスを間違え、返金を求める。
5. 十六進数の画面を承認し、三週後に資金を失う。署名は無制限の承認だった。
6. 表示1.02、約定0.97と苦情が来る。何が起きたか画面にない。

Web2には残高検査、連打防止、取消API、返金、平易な権限表示、価格固定という標準解がある。ここではどれもそのまま成立しない。

能力不足ではなく、慣れた手順の三前提が、チェーンではすべて成立しないからだ。

課題は、三前提は何で、失われるとどこを変えるかだ。

思考実験

一度に考えず、一前提ずつ取り除こう。

第一：取消を削除する。

ボタンを隠すのでなく、物理的に存在させない。確認すると発生し、自分、データベース、裁判所を含め誰も逆転できない。

多くの設計が崩れる。

• 確認画面が通過点から主画面になる。 取消可能なら礼儀だが、不可逆なら最後の防御だ。
• サポートは解決から説明へ変わる。 救済を教える話法の半分が無効になる。
• 本番流量で試行錯誤できない。 小規模公開して戻す道具がなく、対象者の資金は実際に失われる。
• 初心者案内を先にする。 とりあえず試して直すとは言えない。

第二：毎行動に鍵を取り出し、その場で署名させる。

鍵は自分になく、代理も保管もできない。毎回ウォレットが、理解しにくい内容を示して押すかを求める。

さらに崩れる。

• 手数が圧縮すべき費用になる。 Web2では体験だが、追加署名は離脱点とリスク点だ。
• 書いた文案を利用者が見るとは限らない。 別のウォレットが描画し、影響はできても支配できない。
• 選択を記憶する設計が危険になる。 対応するのは、一承認が永久で無制限という状態だ。

第三：知らないうちに誰でも他の製品を接続できる。

申請、契約、同意なく、インターフェースを読んでコードを呼ぶだけでつながる。

最大の利点と問題を同時に生む。

• 何もしなくても流通が起こる。 相手の利用者が自分の利用者になる。
• 利用仮定が破れる。 人でなく契約、一件ずつでなく一取引に百件来る。
• 単独でインターフェースを変えられない。 接続先が一緒に壊れ、誰なのかも知らない。

残るのはチェーンを足したWeb2ではなく、制約がまったく違う製品だ。

あなたが決める

ワンクリック再投資を作る。収益を再び入れるには、受取、承認、入金の三つが要る。

結果を観察する

一文へまとまる。

難しさは機能ではなく、状態と信頼の境界が引き直されたことだ。

三つの暗黙前提を、現実と並べる。

後の二つは追加の、忘れやすい差だ。

第四：Web2の中間は読み込みだけだが、署名済み未配信、メモリプール待機、格納済み未確定、組替えで消失など、それぞれ意味が違う。

第五：試すにも価格があり、料金が行動を変える。迷い、まとめて行い、高い時は来ない。

モデルを作る

交渉できない三制約

第三は技術だけでなく位置付けだ。入口にも、他人の部品にもなる。 入口は使いやすさ、部品は安定、明確な文書、予測可能な動作が要る。多くは選び切れず、両方不足する。

六状態

各欄に画面と文案が必要だ。 抜ければ利用者が想像し、大抵最悪を想像する。

不足時の成功表示は、保証できない約束だ。 第1章の到着表示と決済完了の時差を、製品が表す責任を持つ。

失敗経路

最も写すべき表だ。 取引機能のPRDで一つずつ使う。

七つは署名前に止められる。一回の追加検査は最も費用対効果が高く、離脱、損失、問い合わせを同時に減らす。

四つの署名

ウォレットが区別しないかもしれず、自画面で分ける。

第二は第24章の入口だ。必要量、期限、履歴閲覧と取消の三つで減らす。

第四は無料・非配信で第三に見えるが、実行可能な権限で、時点を本人が決めない。期限と無効化を必ず書く。

何と呼ぶか

実践

この製品の良い点三つ：
この製品が見落とした失敗経路三つ：
自分が改善するなら最初に直す点：

AI Lab

次の機能についてPRD草案を書いてください：
<機能の説明。例：利用者が保有するA資産をB資産へ、一度の操作で交換する>

対象チェーン：<チェーン名>。対象利用者：<この種類の製品を初めて使う人 / 経験者>。

第1部：主要フロー。各段階について次を記してください。
- 利用者には何が見えるか
- 署名が必要か。必要なら送金 / 利用許可 / メッセージ / オフライン注文のどれか
- 利用許可なら上限額と有効期限をどう設定するか。その理由

第2部：取引状態。「作成 / 署名待ち / 送信済み / 承認待ち / 承認済み / 最終確定」
の六状態ごとに、表示する文言と利用者ができる操作を記してください。
何番目の状態で「成功」と表示するか、判断基準も明示してください。

第3部：失敗経路。一つずつ、発生条件、利用者の表示、製品側の処理を書いてください。
ネイティブトークンなし / 残高不足 / 許可額不足 / スリッページ超過 / 先回り実行 /
メモリプールでの滞留 / コントラクト実行失敗 / 利用者のキャンセル / ネットワーク混雑 / チェーン再編

第4部：不確かな点を別に列挙してください。

規則：
- オンチェーンでの実現方法を説明できない取消・ロールバック・返金処理は書かないでください。
- 各失敗経路には具体的な画面文言を用意してください。「親切な案内を出す」だけでは不十分です。

実例

変数を一つ変える

持ち帰る問い

章末チェック