Part B の案内
Technical Crypto OS:チェーンを読み、コントラクトを書き、システムを作り、最後にメインネットで動く製品を届ける。
すでにコードを書ける人を対象にしています。目標は Solidity を書けることだけではなく、完全な Onchain System を自分で理解し、構築できることです。
前提
Part A の第 1–12 章。 これは形式的な条件ではありません。
- 資産はチェーンの状態にあり、ウォレットが管理するのは鍵だと理解しなければ、署名と承認を正しく書けません。
- Blockspace が市場だと理解しなければ、Gas の最適化が何を最適化しているか分かりません。
- ファイナリティが確率に基づくと理解しなければ、フロントエンドでブロードキャスト済みを成功と扱ってしまいます。
エンジニアなら、通常は一週間ほどでこの 12 章を読めます。
六つのステージ
開発者の視点を身につける。チェーン上に何が保存され、取引はコードから承認まで何を通るのか?
段階成果物: ブロックとアカウントを読み、取引を解析して状態の変化を表示するコマンドラインツール。
EVM と Solana の両モデルで使えるコントラクトとプログラムを書き、テストしてデプロイする。
段階成果物: 十分にテストしたトークンコントラクトをテストネットに公開し、ブロックエクスプローラーでソースコードを検証する。
コントラクトをプロダクトにする:ウォレット、フロントエンドの取引状態、バックエンド、データベース、インデックス化、リアルタイム通知。
段階成果物: フルスタック dApp:ウォレット接続、取引送信、イベントのインデックス化、リアルタイム更新。
AMM、ルーティング、オラクル、レンディング、無期限先物を数学からコードまで実装し、MEV を理解する。
段階成果物: 動作する AMM とルーター。スリッページ、手数料、清算のテスト付き。
オンチェーンデータを検索できる仕組みに変え、脅威モデルと不変条件で資金の安全を守る。
段階成果物: 脅威モデルと不変条件の一覧に、ファジングテストと監視アラートを添える。
モデルを意思決定に参加させても資金は握らせない。提案、検証、シミュレーション、実行、監査を分離する。
段階成果物: ウォレット、予算、戦略エンジン、監査ログを備えたオンチェーンエージェント。
T1–T36
| 章 | タイトル | 中心となる問い |
|---|---|---|
| T1 | ブロックチェーンのデータとは何か | チェーン上には実際に何が保存されるか? |
| T2 | 暗号技術の基礎 | 署名はどうやって「自分だ」と証明するのか? |
| T3 | 取引がコードからチェーンに至るまで | 取引の構築から承認まで、コードは何をする必要があるか? |
| T4 | RPC とは何か | あなたの dApp は本当は誰と通信しているのか? |
| T5 | EVM Account Model | EOA とコントラクトアカウントは何が違うのか? |
| T6 | Solana Account Model | Solana のプログラムが自分でデータを保存しない理由 |
| T7 | Solidity の基礎 | コントラクトをチェーンにデプロイすると、どのような形になるか? |
| T8 | EVM を深く理解する | 同じ代入文なのに、ガス代が 100 倍も違うのはなぜか? |
| T9 | ERC Standards | 標準は実際にどんな問題を解決するのか? |
| T10 | Solana Program | コントラクトの保存領域がなければ、プログラムは状態をどう覚えるか? |
| T11 | Token Program | Solana 上のトークンが独立したコントラクトではない理由 |
| T12 | Testing & Deployment | 実際のお金を使う前に問題をどう見つけるか? |
| T13 | Wallet Connection | dApp にログインするとき、実際には何が起きるか? |
| T14 | Web3 Frontend | 取引が承認を待つ十数秒間、画面には何を表示すべきか? |
| T15 | Backend for Crypto | データが既にオンチェーンにあるのに、なぜバックエンドが必要なのか? |
| T16 | データベースとオンチェーンデータ | オンチェーンデータをどうデータベースに保存するべきか? |
| T17 | Indexer | ブロックチェーンの再編成後、データはどうなるか? |
| T18 | Realtime System | チェーン上の変化をリアルタイムでユーザーにどう届けるか? |
| T19 | AMM:数式からコードへ | x·y=k をコードで書くとどうなるか? |
| T20 | DEX Architecture | 1 回のスワップはいくつの層を通るか? |
| T21 | Oracle | チェーンは外部の価格をどう知るのか? |
| T22 | Lending Protocol | 清算エンジンはいつ市場より速く動く必要があるか? |
| T23 | Perp DEX | 証拠金、資金調達率、リスクエンジンはどう組み合わさって 1 つの仕組みになるか? |
| T24 | MEV | 取引がブロックに入る前に、誰が見ていたか? |
| T25 | Blockchain Data Infrastructure | チェーン全体のデータをどう検索可能なデータウェアハウスにするか? |
| T26 | Cross-chain | チェーンをまたいだ資産は、なお同じ資産か? |
| T27 | Account Abstraction | ユーザーが秘密鍵を直接持たなくても、安全に使えるか? |
| T28 | Smart Contract Security | コードは間違っていないのに、なぜ盗まれたのか? |
| T29 | Protocol Security | 脆弱性を使わず、お金だけで攻撃者には何ができるか? |
| T30 | Audit | 監査では実際に何を調べるのか? |
| T31 | AI-assisted Crypto Development | AI が書いたコントラクトをメインネットに公開できるか? |
| T32 | Reliable AI Architecture | モデルを意思決定に参加させつつ、資金の管理権限を持たせないには? |
| T33 | Tool-using Crypto Agent | エージェントにオンチェーンのツールを本当に使わせるには? |
| T34 | Agent Wallet & Payment | エージェント用ウォレットには、どんな安全装置が必要か? |
| T35 | DeFi Agent | 資産配分を変更するエージェントは、どのチェックを通るべきか? |
| T36 | Autonomous Onchain Economy | 自分で稼ぎ、使えるシステムの境界はどこにあるか? |
二つの系統を並行して学ぶ
各ステージでは、EVM と Solana の二つのモデルを同時に示します。両方を完全に習得するためだけではなく、比較がモデルを理解する最も速い方法だからです。Solana が取引で触れるアカウントの事前宣言を求める仕組みを見て初めて、EVM のグローバルな状態機械が何を意味するかが分かります。
一つを主な開発先に選び、もう一つは読んで理解できる程度を保ってください。
学び終えたあと
最終プロジェクトの Build an Onchain Economyに取り組み、そのあと T シリーズの職業別 Trackに進みます。