SolidityとEthereumによる実践スマートコントラクト開発 書評 ~ 再構築
2023.02.10
この記事は最終更新日から1年以上が経過しています。
どもです。
去年だか、一昨年だが、購入していた書籍「SolidityとEthereumによる実践スマートコントラクト開発」を、そういえば最後までやってなかったな。と、ふと思い出して進めてみたは良いが、各所で様々なレビューコメントでも挙がっているように、今のタイミングで購入して読む書籍ではないな。と正直な感想。
というのも、移り変わりの早いウェブ技術において、更にブロックチェーン、Web3の領域となるとその移り変わりのスピードは加速し、書籍に記載している内容との乖離が大きくあったりする。
そのまま、書籍に沿って実装して動作させようとすると、動かないところが多々である。
また、前半は基礎知識などで良いにしろ、後半になると実装へと入っているのですが、だんだんと説明もざっぱな感じとなり、最終章あたりの大規模なDApps開発あたりになると、ほとんどフロント実装の話が中心でしかもReactでの実装なので、フロント技術に明るくない方にはとっては不親切を感じた。フロント技術に慣れている自分でもちょっと辛さを感じたほどだ。
更に仕様と実装する内容が異なっている気もするし（気のせいか？？）、色んな要因があり、今のタイミングでの購入は、あまりオススメしない。
正直、こんなに難しいと感じなかったスマートコントラクトの実装が、より難しくややこしくなっている感じがした。
今回は、後半の実装において、書籍と実装が異なる箇所や躓いたところの回避など大まかなところを記載し、課題内容は良いかと思っておりますので、もっと簡単に実装できる気がするので、Nuxt.jsを用いて再構築を試みて見たいと思います。
躓いた点など
P.34
3.1.1 parityのインストール
書籍では、インストールスクリプトを用いてインストールしていましたが、brewでparityをインストールを行いました。
tap
brew tap ethcore/ethcore
brew インストール
brew install parity
4章 初めてのスマートコントラクト
solidityのバージョンは、書籍の方では、
pragma solidity >= 0.4.0 < 0.7.0;
となっているが、0.8.17を使用した。
pragma solidity = 0.8.17;
それが故にWarnig等が発生したのかも知れない。 警告（Warning）
Warning: SPDX license identifier not provided in source file. Before publishing, consider adding a comment containing "SPDX-License-Identifier: <SPDX-License >" to each source file. Use "SPDX-License-Identifier: UNLICENSED" for non-open-source code. Please see https://spdx.org for more information. -- > project:/contracts/Greeter.sol
ライセンス表記を追加で対応
// SPDX-License-Identifier: MIT
修飾子publicで警告。 警告（Warning）
,Warning: Visibility for constructor is ignored. If you want the contract to be non-deployable, making it "abstract" is sufficient.
-- > project:/contracts/Greeter.sol:7:5:
|
7 | constructor() public {
| ^ (Relevant source part starts here and spans across multiple lines).
削除し対応。
constructor() {
5章 コントラクトのデプロイと操作
P.77
Ganacheのport番号が書籍では8545となっているが異なる。
port7545で接続が行えた。
development: {
host: "127.0.0.1", // Localhost (default: none)
port: 7545, // Standard Ethereum port (default: none)
network_id: "*", // Any network (default: none)
},
5.4 Parityを使ったGoerliへのデプロイ
P.82
Goerli Faucetを用いてテスト用のGoerliイーサを取得するところで、goreli-faucet.slock.itは既にクローズされている様子で、https://goerli-faucet.mudit.blog/はまだ生きている感じですが、最終的にはこちらで取得した。
1日0.2Goerli ETHまでと制限のあるものとなる。
Goerli faucet
こちらは、alchemyが運用しているFaucetぽく、以前はログイン無しで利用できていたっぽいのですが、現在使用するためには、alchemyのアカウントが必要ぽいです。
alchemyは、ブロックチェーン周りのソリューションを提供している企業みたいです。
P.83
HDWalletProviderインストール
$ npm install truffle-hdwallet-provider --save-dev
↓
どうやら、truffle Organizations以下のものが最新ぽい。
$ npm install @truffle/hdwallet-provider
9章 UIをコントラクトに接続する
正直、ここまではそんなに大きく躓くポイントはなかったのですが、ここからReactを用いてフロントの実装で大きく時間が奪われた気がします。
まず、truffle unboxコマンドでReact Truffle Boxを展開するのですが、書籍に記載されているディレクトリ構造と現在のディレクトリ構造が異なります。
$ truffle unbox react
clientディレクトリとtruffleディレクトリが作成され、contracts、migrations、testなどはtruffleディレクトリ以下に、src、publicなどはclient以下に生成される。truffleディレクトリが新しく生成される形になったのかと思います。
truffleのバージョンなどは以下のとおり。
$ truffle --version Truffle v5.6.1 (core: 5.6.1) Ganache v7.4.4 Solidity v0.5.16 (solc-js) Node v14.18.3 Web3.js v1.7.4
多分、フロント起動後のホーム画面もtruffleのバージョンが異なることによって、書籍と異なっているかと思う。
truffle migrate --reset
P.190
client/src App.jsのファイル参照になっていて「ボイラープレートコードの一部を削除し」となっているが、そもそも生成されている client/src App.jsの内容が異なる。
近いところでいうと、 src/contexts/EthContext/EthProvider.jsxのファイルが書籍の内容と近い。
P.192
Reactバージョンの18となっており、React Routerもv6となり、この辺りで色々異なる。
import { BrowserRouter as Router, Route, NavLink } from "react-router-dom";
↓
import { Routes, Route, NavLink } from "react-router-dom";
index.jsで
import { BrowserRouter } from "react-router-dom";
使用。
<Router>
↓
<Routes>
React Router v6より以下の記述となりこういった形に。
<Routes>
<Route path="/" exact element={<Home />} />
<Route path="/new/" element={<NewFundraiser />} />
</Routes>
StrictModeをDisableにしないとエラー出ていたので削除。
<React.StrictMode>
<BrowserRouter>
<App />
</BrowserRouter>
</React.StrictMode>
↓
<BrowserRouter>
<App />
</BrowserRouter>
10.2 ReactとMaterial-UI
P.195
material-uiがReactバージョンの18に対応していないので、forceオプションで半ば無理やりインストール。
npm install @material-ui/core --force --save
こちらもエラーとなり、forceオプションで半ば無理やりインストール。
npm install @metamask/detect-provider
↓
npm install --force @metamask/detect-provider
withdrawの仕様
自分がきちんと読めていないのかもですが、withdrawの仕様のはっきりしない。 Fundraiser作成がwithdrawを行えるのかと思いきや、コントラクトのオーナーのみなのか？ 書籍の参照用のソースをみるとオーナーがFundraiserコントラクト作成のみwithdraw対象になっている気がする。うーん。 https://github.com/oeawFebe/fundraiser/blob/main/client/src/FundraiserCard.js#L131
と、こんな感じで思い出せる限りは書いたのですが、まだ躓いたポイントもあった感じで、なかなか後半は、何をやっているのだろう感が漂ってしまいました。
読むタイミングの悪さもあったのかも知れませんが、あまりに無駄に考えるポイントが多かった印象です。オライリー書籍でも当たり外れはやはりあるもので、少し時間を無駄にもしてしまった気がする。 しかしながら、チャレンジ内容は良いと思っていますので、次回、こちらをベースとし、更にもっと簡単に実装しやすい形で再構築を書いて行ければと思っております。
ではでは。
またまたぁ。
