ブロックチェーンってなに？ の次は、「ふつうのWebアプリ」と「DApp」のちがいを見ます。 すでにWebやTypeScriptを知っている人は、ここで一気に地図がつながります。
たとえ話：お店のレジ
- ふつうのWebアプリ … お店のレジは1台。店長（サーバー）が記録を全部にぎっている。
- DApp … レジの記録を、町じゅうの人が同じ帳簿で持っている。店長がいなくても、みんなで正しさを確かめられる。
対比でわかる
DApp で増える「3つの登場人物」
ふつうのWeb開発に、だいたい次の3つが加わります。
- 契約（Compact）：サーバーのロジックにあたる部分。ただし証明できる形で書く。
- ウォレット：ログインの代わり。ユーザーはカギで本人確認・サインする。
- proof server：秘密を見せずに「正しさ」を証明する係（Midnight 特有）。
でも「ぜんぶ別物」ではない
- 画面（フロントエンド）は、いつもの React / Svelte / TypeScript で作れます。
- 違うのは「サーバーAPIを叩く」代わりに、「契約を呼ぶ（providers 経由）」ところ。
- だから Web 開発者の知識は、かなりそのまま使えます。
開発者として理解すべきこと
- DApp ＝ サーバー→契約、DB→台帳、ログイン→ウォレット の置きかえ＋ 証明（ZK） が加わる
- フロントエンドの作りかたは今まで通り。違いは「契約を呼ぶ」こと
- 「サーバーを信じる」から「みんなで検証できる＋証明」へ、信頼のモデルが変わる
公式Docsではどこ？
今日のまとめ
- ちがいは サーバー→契約 / DB→台帳 / ログイン→ウォレット / 信頼→証明
- でも画面づくりは今まで通りの Web 技術でOK
- 「店長を信じる」から「みんなで確かめる」へ
今はここだけでOK
「サーバーの代わりに契約、ログインの代わりにウォレット」——この2つの置きかえが言えればOK。
✍️ 白紙練習
答えを見る前に、いったん自分の頭と手から出してみよう。手で書くと「わかったつもり」がはがれます。
ふつうのWebアプリと DApp のちがいを、サーバー・DB・ログインの3つの置きかえで自分の言葉で説明してみよう。
DApp では サーバー→契約（Compact）、DB→台帳（公開ステート）＋手元の秘密ステート、ログイン→ウォレット（カギでサイン） に置きかわります。さらに「サーバーを信じる」から「みんなで検証できる＋証明（ZK）」へ、信頼のモデルが変わるのがポイントです。
DApp なのに「ぜんぶ別物ではない」と言えるのはなぜ？Web開発者の知識がどこまで使えるかを書いてみよう。
画面（フロントエンド）は、いつもの React / Svelte / TypeScript でそのまま作れます。違うのは「サーバーAPIを叩く」代わりに「契約を呼ぶ（providers 経由）」ところだけ。だから Web 開発者の知識はかなりそのまま使えます。
DApp（Midnight）で、ふつうのWeb開発に加わる「3つの登場人物」は？
- 契約（Compact）：サーバーのロジックにあたる部分（証明できる形で書く）。
- ウォレット：ログインの代わり。ユーザーはカギで本人確認・サインする。
- proof server：秘密を見せずに「正しさ」を証明する係（Midnight 特有）。
ふつうのWebアプリでの「ログイン」は、DApp では何に置きかわる？
ウォレットに置きかわります。ID/パスワードの代わりに、カギでサインして本人確認をします。
DApp でデータはどこに置かれる？ふつうのWebアプリと対比して答えよう。
ふつうのWebアプリは自分のデータベースに置きますが、DApp では 台帳（公開ステート） と、手元の 秘密ステート に置かれます。
DApp を動かすときの「お金」は何で、ふつうのWebアプリと何がちがう？
ふつうのWebアプリはサーバー代がかかりますが、DApp では取引ごとに 手数料（DUST） がかかります。
DApp で「正しさ」はどうやって担保される？ふつうのWebアプリと対比しよう。
ふつうのWebアプリは「サーバーを信じる」ことで担保しますが、DApp では 証明（ZK）＋みんなの検証 によって担保されます。
つぎに読むページ
➡️ その新しい登場人物を見る。ウォレット・取引・状態