Midnight こども学園

フェーズ1：ブロックチェーンの土台

ふつうのWebアプリと何がちがう？

いつものWebアプリ（サーバーとデータベース）と、ブロックチェーンの DApp は何がちがうのか。サーバーの代わりに契約、DBの代わりに台帳、ログインの代わりにウォレット——を対比で理解します。

ブロックチェーンってなに？の次は、「ふつうのWebアプリ」と「DApp」のちがいを見ます。すでにWebやTypeScriptを知っている人は、ここで一気に地図がつながります。

たとえ話：お店のレジ

ふつうのWebアプリ … お店のレジは1台。店長（サーバー）が記録を全部にぎっている。
DApp … レジの記録を、町じゅうの人が同じ帳簿で持っている。店長がいなくても、みんなで正しさを確かめられる。

対比でわかる

	ふつうのWebアプリ	DApp（Midnight）
ロジックの置き場所	サーバー（自分の管理）	契約（Compact）＝みんなが検証できる
データの置き場所	データベース（自分のDB）	台帳（公開ステート）＋手元の秘密ステート
ログイン	ID/パスワード	ウォレット（カギでサイン）
「正しさ」の担保	サーバーを信じる	証明（ZK）＋みんなの検証
動かすお金	サーバー代	取引ごとの手数料（DUST）
変更	いつでも自由に書きかえ	取引として記録、書きかえにくい

DApp で増える「3つの登場人物」

ふつうのWeb開発に、だいたい次の3つが加わります。

契約（Compact）：サーバーのロジックにあたる部分。ただし証明できる形で書く。
ウォレット：ログインの代わり。ユーザーはカギで本人確認・サインする。
proof server：秘密を見せずに「正しさ」を証明する係（Midnight 特有）。

でも「ぜんぶ別物」ではない

画面（フロントエンド）は、いつもの React / Svelte / TypeScript で作れます。
違うのは「サーバーAPIを叩く」代わりに、「契約を呼ぶ（providers 経由）」ところ。
だから Web 開発者の知識は、かなりそのまま使えます。

開発者として理解すべきこと

DApp ＝ サーバー→契約、DB→台帳、ログイン→ウォレット の置きかえ＋ 証明（ZK） が加わる
フロントエンドの作りかたは今まで通り。違いは「契約を呼ぶ」こと
「サーバーを信じる」から「みんなで検証できる＋証明」へ、信頼のモデルが変わる

公式Docsではどこ？

今日のまとめ

ちがいは サーバー→契約 / DB→台帳 / ログイン→ウォレット / 信頼→証明
でも画面づくりは今まで通りの Web 技術でOK
「店長を信じる」から「みんなで確かめる」へ

今はここだけでOK

「サーバーの代わりに契約、ログインの代わりにウォレット」——この2つの置きかえが言えればOK。

つぎに読むページ

➡️ その新しい登場人物を見る。ウォレット・取引・状態