主要技術

主要言語: Solidity

最もメジャーな言語がSolidityです。
(一応、PythonやバニラJavaScript等で開発できるスマートコントラクトもありますが、基本的にはSolidityだけを考慮すると良いでしょう)
さて、Solidityはどんな言語に似ていると言えるでしょうか。
SolidtiyはJavaScriptをベースに開発されたので、一部共通している記法はあります。
しかし、厳格な静的言語であるSolidityと、動的言語であるJavaScriptでは埋められらない隔たりがあるというのが個人的な所感です。バニラJavaScriptよりむしろTypeScriptに近いと言うべきでしょう。
もっと言うなら、TypeScriptのようなモダンな言語ではなく、CやJavaのようなレガシー言語の性質を受け継いでいるのがSolidityです。

主要フレームワーク: Hardhat, Foundry

今まで最も主要的なフレームワークであったTruffleですが、2023年9月に開発停止が発表されました。
今、最もメジャーな選択肢は下記二つとなるでしょう。

1. Hardhat

2. Foundary

▼主な機能

• スマートコントラクト開発のテンプレート生成

• ローカルでの対話環境の構築

• スマートコントラクトのテスト

• スマートコントラクトのコンパイル

• スマートコントラクトのデプロイ

💡 余談: 「Truffleの発音」
Truffleの読み方として、「トラッフル」派と「トリフ」派を観測しています。 おそらく英語的には「トラッフル」が正しい気がしますが、日本人の開発者は「トリフ」と読む方が多いです。

スマートコントラクト開発の特徴

コードの対改竄性(一度ブロックチェーン上にデプロイしたコードの書き換えは不可能)

通常の開発に比べて、スマートコントラクト開発の最も特殊な点の一つです。
一度ブロックチェーン上にスマートコントラクトをデプロイしたら、コードの書き換え自体は二度と行うことができません。
Typo(誤字)の一つですら直せません。
デプロイ後にバグやセキュリティ上の欠陥を見つけても手遅れです。
どうしてもコードを書き換える必要がある場合は、新しくスマートコントラクトをデプロイし直すことになりますが、新しいスマコンは旧スマコンのデータやトランザクションの履歴を引き継ぐことはできません。
新しくアカウントを作り直すようなものです。
よって、スマートコントラクトを本番環境(Mainnet)にデプロイする前に、 徹底してテストを繰り返すのがスマートコントラクト開発のセオリーです。Truffle等だと最初からテスト用のコードもセットになっています。
しかし、「コードの書き換えができない」= 「スマートコントラクトを後から全く改変できない」と言うわけではありません。
いくつか特殊なデザインパターンが用意されています。

• スマートコントラクトを機能毎に分割しておき、後から組み合わせる(モジュール化)

• スマートコントラクト内の値を変数とそのセッター関数で保持する

コードの透明性(一度ブロックチェーン上にデプロイしたコードは公開される)

一度ブロックチェーン上にデプロイされたスマートコントラクトのコードは公開情報です。etherscanやpolygonscan上で誰でも確認できます。
デフォルトでは機械語のままですが、コントラクトのオーナーがVerifyをすると元のコードが表示されるようになります。
スマートコントラクト開発における最も有名なアンチパターンが擬似乱数生成ですが、それもコードが筒抜けだからです。 例えばコードを読むことでガチャのレアリティのアルゴリズムが解析できるので、任意の結果を出力させることが可能になってしまいます(一種の「レア抜き」)。
また、Verifyさえしなければコードが隠蔽されるというわけでもありません。Verify前の状態からコードを復元することは可能だからです。
開発者や事業者からすると不便さもありますが、このコードの透明性という性質がスマートコントラクトの信頼性の担保として機能しています。

常にガス代を考慮する

スマートコントラクト開発とは常にガス代との戦いです。
そもそも「ガス代」とは何かというと、ブロックチェーンネットワーク上でコードを実行する際に支払う必要がある手数料のことです。
まず、スマートコントラクトをデプロイする際にガス代がかかります。
例えばイーサリアム上でNFTの独自コントラクトを、ある程度機能をカスタマイズした場合は10万円くらいかかります※。
「リリース時にだけかかるサーバー代」のようなものとでも捉えると分かりやすいでしょう。
また、スマートコントラクトのコードが冗長だと、そのスマートコントラクトを使用しているDAppsでユーザーに無駄なお金(ガス代)を支払わせることになってしまいます。
よって、スマートコントラクト開発においてはコードの可読性より計算量の削減が重視されることになります。ある意味、競技プログラミングの世界に近いかもしれませんね。

※2021年のピーク時。現在はガス代が落ち着いた

世界で一つの「DB」「サーバー」「Web API」を共有する

ざっくり言うと、ブロックチェーンという世界で一つの

1. 「巨大な情報の海」(DB)

2. 「絶対に落ちないサーバー」

3. 「誰でも参照・実行可能なWeb API」

を共有するようなイメージです。
これだけ聞くとセキュリティが心配になると思いますが、セキュリティを担保する仕組みやベストプラクティスも担保されているのでご安心ください。

コード量自体は驚くほど少ない

スマートコントラクトのコード量自体は驚くほど少ないです。
例えば世界最大のNFTマーケットプレイスであるOpenSeaでも、スマートコントラクトは約2,000行程度しかありません。
しかし当然ですが、コードの行数=開発工数では断じてありません。
前述のように、スマートコントラクトは一度デプロイしたら二度とコードを書き換えることができません。 よって、徹底的にテストを重ねてセキュリティを検証する必要があります。
また、ある種の「要件の先読み」とそれを踏まえたスマコン内の先行実装も求められます。 後から機能の追加が出来ないからです

スマートコントラクトはDApps開発のごく一部

スマートコントラクトはDApps全体の開発におけるごく一部でしかありません。
むしろ実際には、Web2部分の実装の方が割合として大きいです。
また、Solidityを書ける(スマートコントラクト開発ができる)エンジニアも希少ですが、それ以上にWeb2-Web3のブリッジができるエンジニアの方が希少です。
例えば開発リソース配分のイメージとしては下記のようになります。

• スマートコントラクト開発: 10%

• Web2-Web3のブリッジとそれを考慮したDBやバックエンドの設計・開発: 50%

• フロントエンド開発(※ウォレット接続やWeb3.js等でのスマコン制御も含む): 40%

参考

「そもそもNFTとは?」エンジニア向け解説

Bunzz(旧LasTrust社)CTOによる解説です。

※本記事は、2022年3月に作成したNotion資料をNoteに再投稿したものです。内容が一部古い可能性があります。

※本記事は、エンジニアリングが本職ではない方を想定して作成しているため、分かりやすさと引き換えに厳密な正確性を犠牲にしている箇所があります。