0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

@io0323

【書評】 SolidityとEthereumによる実践スマートコントラクト開発 ―Truffle Suiteを用いた開発の基礎からデプロイまで

0
Posted at

はじめに

「スマートコントラクト開発に興味はあるけれど、何から手を付ければよいのかわからない」。
今回は、そんなエンジニアに向けて書かれた次の一冊を、設計・アーキテクチャの視点を中心に振り返ります。

『SolidityとEthereumによる実践スマートコントラクト開発 ―Truffle Suiteを用いた開発の基礎からデプロイまで』

結論から言うと、本書は「ブロックチェーンの理論書」ではなく、テスト駆動開発（TDD）でコントラクトを一本作り切り、UIにつなぎ、セキュリティまで一周する実践書です。
ふだんWebやバックエンドの設計をしているエンジニアが、既存の設計感覚をどこまで持ち込めて、どこで捨てるべきかを掴むのに向いています。

書誌情報

項目 内容
原題 Hands-On Smart Contract Development with Solidity and Ethereum
著者 Kevin Solorio / Randall Kanna / David H. Hoover
監訳 中城 元臣
訳 株式会社クイープ
出版社 オライリー・ジャパン
初版 2021年1月15日
題材 Solidity / Truffle Suite（Truffle・Ganache）/ Web3 / React

本記事は書評であり、本書の内容そのものの転載ではありません。
章ごとの要点は筆者の言葉でまとめています。詳細やコード全文は書籍をご参照ください。

本書の全体像

本書は4部12章で構成されています。流れを図にするとこうなります。

部 章 内容
第I部 1〜3章 ブロックチェーンの概念、DAppのユースケース、開発環境の準備
第II部 4〜7章 Greeter、Fundraiser、FundraiserFactoryをTDDで実装
第III部 8〜11章 Web3の基礎、Reactとの接続、Fundraiser UIの完成
第IV部 12章 代表的な脆弱性と監査の考え方

「最小のコントラクトから始めて、題材を少しずつ育てていく」構成なので、読み進めるほど設計の判断ポイントが増えていくのが特徴です。

各章の要約

第I部 イーサリアムブロックチェーンの紹介

1章 ブロックチェーンの概念

ブロックチェーンの歴史から、ノード・コンセンサス・トランザクション処理・ファイナリティ、そしてイーサリアム固有のガスやアカウントまでを一気に押さえる章です。

  • 通常のデータベースとの最大の違いは、やり取りが即時でも確定的でもないこと
  • コンセンサス（PoW / PoS / PoA）は、コントラクト開発者にとっては基本的に「ブラックボックス」として扱えること
  • トランザクションはメモリプールで待たされ、ガス価格によって処理順が変わること
  • ブロックのタイムスタンプは粒度が粗く、等価比較ではなく大小比較で使うべきこと
  • EOA（外部所有アドレス）だけがトランザクションを起こせ、コントラクトは自発的には動けないこと

ここで語られる「確定しない」「順序を制御できない」という前提は、後の設計判断すべての土台になります。

2章 非中央集権アプリケーション

ブロックチェーンが向いているユースケースを3つ紹介します。

  1. トークン（ERC-20 / ERC-721）
  2. サプライチェーン（産地や流通経路の追跡）
  3. 永続的な記録（整備記録のような改ざんされてはいけない履歴）

後半では「自分のアプリにブロックチェーンは本当に必要か」を判断する観点として、検証可能性・透明性・回復力の3つが示されます。
アーキテクチャ選定の議論そのものなので、設計に関心がある方にはここが意外な読みどころです。

3章 スマートコントラクトを開発するための準備

イーサリアムクライアント、ウォレット（MetaMask）、Node.js、Truffle、Ganacheを順にセットアップします。
Truffleを「フレームワーク」というよりコンパイル・テスト・デプロイ・パッケージ化のための道具箱として紹介している点が、全体を理解する助けになります。

第II部 スマートコントラクトの開発

4章 初めてのスマートコントラクト

題材は定番のGreeterです。ここで本書の開発スタイルが確立します。

  1. 失敗するテストを書く
  2. エラーメッセージを読んで、必要最小限の実装を足す
  3. テストが通ったらリファクタリングする

特に「エラーを読んで次の一手を決める」進め方が丁寧で、Could not find artifacts や is not a function といったよくあるエラーの意味を、TDDのフィードバックとして体験できます。
後半では可視性修飾子（external / public / internal / private）、pure / view、状態変数、modifier、そしてOpenZeppelinのOwnableによる所有権管理まで進みます。

5章 コントラクトのデプロイと操作

同じコントラクトを3通りの環境にデプロイします。

環境 特徴
Ganache ローカルで素早く試せる
Goerli + 自前ノード 自分で管理するノード経由でテストネットへ
Rinkeby + Infura マネージドノードを使いノード同期の手間を省く

デプロイが「コンパイル結果（ABIとバイトコード）をトランザクションとして送る行為」であることを説明している点、そしてニーモニックを環境変数で渡して誤コミットを避ける点が実務的です。

6章 資金調達アプリケーション

本書の中心となる題材 Fundraiser を作る章で、分量も最大です。実装される機能は次のとおりです。

  • コンストラクタによる初期化（受取人、管理人など）
  • 受取人の変更（所有者のみ）
  • 寄付（payable、構造体とmappingによる記録）
  • 寄付の集計（SafeMathでオーバーフロー対策）
  • イベントの発行（DonationReceived、Withdraw）
  • 出金（所有者のみ、残高を受取人へ送金）
  • フォールバック関数（匿名の寄付）

Solidity特有の概念（storage / memory / calldata、address payable、mappingは列挙できない、など）が必要になった瞬間に登場するため、言語仕様の暗記ではなく「困ったから学ぶ」流れで身に付きます。

7章 FundraiserFactory

Factoryパターンで、Fundraiserのインスタンスを生成・管理するコントラクトを作ります。
目玉はページングです。limitとoffsetに加えて取得件数の上限を設け、空コレクションや範囲外アクセスなどの境界条件をテストで固めていきます。

第III部 Web3を使ったスマートコントラクトの操作

8章 Web3とは何か

Web3.jsを「JSON-RPCのラッパー」として位置付け、従来のフロント／バックエンド構成と対比させます。

  • call（読み取り）はガス不要で即時
  • send（書き込み）はMetaMaskでの署名とガス支払いが必要

この2つの区別は、そのままUXの設計方針に直結します。

9章 UIをコントラクトに接続する

React Truffle Boxを使い、4章のGreeterをReactから呼び出します。
greet()の結果を表示し、入力フォームからsetGreeting()を送るところまでを、最小構成で見せてくれます。

10章・11章 Fundraiser UI

ルーティング、一覧、新規作成フォーム、詳細ダイアログ、寄付、領収書、出金、受取人の変更までを実装します。
イーサの価格変動に対応するため、外部の為替レートを参照してドル換算で表示する工夫など、「コントラクトの外側で何を担うか」が見えてきます。

第IV部 スマートコントラクトの保護

12章 スマートコントラクトのセキュリティ

デプロイ後に修正できないという性質を踏まえ、代表的な攻撃パターンを整理します。

  • 保護されていない関数
  • トランザクション順序への依存（フロントランニング）
  • 整数のオーバーフロー／アンダーフロー
  • リエントランシー（関数間の競合状態を含む）
  • ブロックのガスリミット
  • タイムスタンプ依存

さらに、外部監査に出す前の自己点検リストや、監査会社・無償ツールの紹介で締めくくられます。

設計・アーキテクチャの観点で刺さったポイント

ここからは、同業のエンジニアに向けて、特に設計面で印象に残った点を挙げます。

1. 「確定しない・巻き戻る」前提で設計する

通常のデータベースでは、コミットされたトランザクションは覆らないと考えます。
一方ブロックチェーンでは、承認されたと思ったブロックが孤立し、結果が消えることがあります。
本書は**「何ブロック待てば確定とみなすか」をアプリケーションごとに決めるべきだと述べています。これは技術要素というより業務要件に近い設計判断**です。

2. 状態遷移とアクセス制御は最小限に、しかし厳密に

onlyOwnerのような修飾子でガード句を書き、権限あり・権限なしの両方をテストするスタイルが一貫しています。
状態を変える関数ほど、誰がいつ呼べるのかを先に決める。これは一般的な認可設計と同じ発想です。

概念コード（筆者作成）
// 所有者のみが受取人を変更できる、というルールを修飾子で表現する例
function setBeneficiary(address payable newBeneficiary) external onlyOwner {
    beneficiary = newBeneficiary;
}

3. 検証済みの部品に乗る（OpenZeppelin）

所有権管理を自前で作らず、監査済みのコントラクトを継承する方針が繰り返し示されます。
「車輪の再発明は悪」という一般論が、資産を扱うコードではより強く効くことを教えてくれます。

4. 無制限に成長するデータは最初から分割する

マッピングは反復できず、配列の全件走査はガスリミットに引っかかります。
そこでFactoryにはmaxLimitとページングを持たせています。
データ量が増える前提で、読み出しの粒度を設計に組み込むのは、一般的なAPI設計にも通じます。

5. オンチェーンとオフチェーンの責務分担

  • 寄付の記録はウェイ単位の金額と日時だけを保存する
  • ドル換算や領収書の見た目はフロントエンド側で組み立てる

保存コストが高い環境では、「何をチェーンに載せ、何を外に出すか」の線引きが設計の核心になります。

6. イベントは「読むための出口」

イベントはコントラクト内部からは参照できませんが、ログとして安価に残せ、外部が購読できます。
書き込み側の状態と、読み出し側の通知を分けるという考え方は、CQRSやイベント駆動の設計にも近い印象を受けました。

セキュリティ章の読みどころ

12章で特に実務に直結するのが、リエントランシー対策の基本形です。
外部へ送金する前に、自分の状態を更新しておく。この順序の入れ替えだけで防げるケースが多い、という説明は非常に明快でした。

概念コード（筆者作成）
// 状態の更新を先に済ませ、最後に外部へ送金する流れのイメージ
function withdraw() external {
    uint256 amount = balances[msg.sender];
    balances[msg.sender] = 0;                 // ① 先に状態を更新
    (bool ok, ) = msg.sender.call{value: amount}("");  // ② 最後に外部呼び出し
    require(ok, "transfer failed");
}

上記は考え方を示すための簡略例です。実運用では、監査済みのライブラリやツールの利用、外部監査を前提にしてください。

読む前に知っておきたい注意点

本書の刊行は2021年1月で、題材の環境はそれ以前のものです。そのため、現在の開発環境とは差分があります。

本書の記述 留意点
Solidity 0.5〜0.6系 現在の主流は0.8系。算術のオーバーフロー検査が言語標準になっており、SafeMathの必要性が変わっています
Truffle / Ganache 開発終了が発表されており、現在はHardhatやFoundryなどが主流です
Ropsten / Rinkeby / Goerli 既にテストネットの廃止が進んでいます
Parity（OpenEthereum） 開発が止まっており、別のクライアントを使う前提になります
PoWを前提とした説明 イーサリアムはPoSへ移行済みです

具体的なバージョンや提供状況は変化が速い分野です。実際に手を動かす前に、各ツールの公式ドキュメントで最新状況を確認してください。

ただし、本書の価値は特定ツールの操作手順ではなく、考え方の部分にあります。

  • テストから書く開発リズム
  • アクセス制御の発想
  • データ構造とガスコストの関係
  • 外部との責務分担
  • 攻撃パターンの整理

これらはツールが変わっても通用します。環境だけ最新のものに読み替えながら進めるのがおすすめです。

良かった点・気になった点

良かった点

  • TDDの徹底: エラーを読みながら進めるので、つまずきポイントを先回りして体験できる
  • 題材の一貫性: Greeter から Fundraiser、Factory、UI へと、同じ題材が段階的に育つ
  • 設計判断の説明: publicにするかどうか、memoryかstorageか、など理由が添えられている
  • セキュリティまで一周: 作って終わりにせず、守る視点で締めくくっている

気になった点

  • 環境が古く、そのままでは再現しにくい箇所がある（訳注で補われているものの限界はある）
  • UI章はReactの実装解説の比重が大きく、コントラクト設計に興味がある読者には少し長く感じる
  • 理論面（暗号やコンセンサスの内部）は意図的に浅く、深掘りには別の書籍が必要

こんな方におすすめです

  • Webやバックエンドの経験があり、スマートコントラクトの設計感覚を掴みたい方
  • 概念書を読んだものの、手を動かす最初の一冊を探している方
  • TDDで小さく作って育てる開発スタイルを別領域でも試したい方
  • ブロックチェーンの採用可否をアーキテクチャの観点で判断したい方

逆に、最新のツールチェーンで即戦力になるハンズオンを求める方には、本書で考え方を学んだうえで、最新の公式チュートリアルを併用する形が合うと思います。

まとめ

本書は、スマートコントラクト開発を**「作る → 試す → 届ける → 守る」の一周**で体験できる入門書です。

  • ブロックチェーンは確定しない・巻き戻る・順序を制御できない環境である
  • だからこそテストとアクセス制御、検証済み部品の活用が設計の軸になる
  • 保存コストが高いため、オンチェーンとオフチェーンの責務分担が重要になる
  • デプロイ後に直せないので、セキュリティは最初から設計に組み込む

ツールのバージョンこそ古くなっていますが、設計の考え方は今でも十分に役立ちます。
スマートコントラクトの世界に踏み出す入口として、手に取ってみてはいかがでしょうか。

参考

0
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
Sign upLogin
0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?