週刊 Life is Beautiful ２０２２年７月１９日号：中学生にも分かるWeb3、Solidity

今週のざっくばらん 中学生にも分かるWeb3-8（メルマガ限定） Solidity プログラミンング Solidity は、Ethereum ブロックチェーン上のソフトウェア、スマートコントラクトを作るために開発された言語です。Solidity以外にも選択肢はありますが、Solidity で書いたスマートコントラクトは Ethereum 以外のブロックチェーン上でも動くし（EVM: Ethereum Virtual Machine がある環境であれば動きます）、現時点では Solidity が最も多く使われているスマートコントラクト用の言語です。 そのため、私も含めて、多くのエンジニアが、まずはSolidityの勉強からスタートしています。今後、他の言語が普及する可能性も十分にありますが、その場合は、そこで新たな勉強をすれば良いだけの話で、あれこれと悩む前に、まずは言語や開発環境に慣れ親しむことが何よりも大切です。 私がSolidityの勉強を始めたのは今年（２０２２年）４月ごろです。その頃は、Web3のムーブメントには注目していましたが、それが意味するものは、まだ理解できていませんでした。 まずは、言語仕様を読むところから始めました。多くの人が指摘するように、JavaScriptに似た言語であり、言語仕様を理解するのはそれほど難しくありません。しかし、その頃は、何か具体的に作りたいものがあったわけでもなく、全く頭に入って来ませんでした。典型的な「勉強のための勉強」になってしまっていました。 そんな状況を大きく変えてくれたのが、５月になって試したクリプトゾンビです。本当に良くできたチュートリアルで、楽しみながら勉強も出来たし、「自分でスマートコントラクトをブロックチェーン上にデプロイしたい！」という思いが凄く強くなりました。 クリプトゾンビは、（Solidityに限った話ではなく）プログラミング言語のチュートリアル環境としては、最も良くできたものの一つです。私は常々、書籍を読んだり、プログラミング教室で授業を受けるよりも、実際にプログラムを自分で書くのが一番良い勉強方法だと指摘して来ましたが、クリプトゾンビはそれを完璧な形でチュートリアルの形に仕上げてくれています（日本では、高校で「情報」の授業が始まることになり、先生不足が大きな問題になっていますが、クリプトゾンビを参考にしてオンラインのチュートリアルを作り、子供たちにはそれを使って勉強してもらうのが一番良いと思います）。 クリプトゾンビのチュートリアルを一通り終えるのに１週間もかかりませんでした。たったそれだけの努力（とても楽しいので「努力」という言葉が適切ではないかも知れません）で、Web3イノベーションの中核技術である「Solidityが書けるエンジニア」になれるのだから、これを勉強しない手はないと思います。 クリプトゾンビを終えた私が最初にしたのは、Nouns のソースコードをひたすら読むことです。他人のソースコードを読むことは、どんな言語においても、とても良い勉強になります。私は Microsoft に入った時には、ひたすらWindows のソースコードを読んで勉強しましたが、それと全く同じことを Nouns のソースコードで行ったのです。Nouns には、開発者にインセンティブとして１０個に１個のNFTを上げる仕組み、ドット絵をオンチェーンで実装する仕組み、１日一回行われるオークションの仕組みなど、複数のコントラクトで構成することによりアップデートを可能にする仕組み、など学べるものが沢山含まれています。 その後すぐに私が関わったのは、Nouns LoveというNFTの開発です。私が立ち上げた、オンライン映画祭「Nouns Art Festival」の資金集めを主たる目的にしたプロジェクトです。Nounsのソースコードをベースに、ダッチオークション（徐々に値下がりする中で、最初に買うと宣言した人が買えるオークション）でNFTを販売する仕組みです。Nouns Love のコントラクトのソースコードは、ここに置いてあります。 Nouns Loveに関しては、私は「主たる開発者」ではなく、主にコードレビューとデプロイだけを行いましたが、とても良い勉強になりました。特に、Ethereum のブロックチェーンにスマートコントラクトを生まれて始めてデプロイする瞬間は非常に緊張し（ガス代がかかるし、やり直しが効かないからです）、とても良い経験になりました。 ６月に入って取りかかったのは、Pride Squiggle NFT コレクションの開発です。NFTの勉強をするにつれ、多くのNFTプロジェクトが採用している「画像をブロックチェーンの外に置く」というアプローチに大いに疑問を感じ、スマートコントラクトで動的に画像を生成するNFTを作る方法はないか、という実験的なプロジェクトです。 とは言え、何の目的もないNFTを作っても仕方がないので、６月がLGBTコミュニティをお祝いする Pride Month だったことにちなみ、LGBTコミュニティのシンボルである虹色をあしらった「Pride Squiggle」というNFTコレクションを作ることにしました。 Squiggle （殴り書き）という部分は、Chromie Squiggle by SnowfroというNFTを参考にしました。当初は Chromie Squiggle もすべてオンチェーンで実装されていると勝手に思い込んでいましたが、実際には違いました。私がやったことはかなり画期的なことなことだったようです。この分野（オンチェーン・ジェネラティブ・アート）のイノベーションは始まったばかりで、誰でも先駆者になれる「ブルーオーシャン」なのです。 ちなみに、このNFTはフリーミント（無料）で提供した上で、二次流通のロイヤリティのみLBGTのコミュニティに渡すことに決めたのですが、ロイヤリティを渡す相手選びと、その手続きに結構な手間がかかりました。結論から言えば、OutRight Action Internationalという非営利団体に、The Giving Blocksという会社が提供する仕組みを使うことにより、OpenSea で生じるロイヤリティを直接、この非営利団体に渡すことが出来るようになりました。 Pride Squiggle の開発がとても楽しかったので、今後も、さまざまな「オンチェーン・ジェネラティブ・アート」を作ろうとは考えているのですが、その前に、作っておくべきものがあると開発をスタートしたのが、７月に入ってリリースしたばかりのOn-chain Asset Storeプロジェクトです。 これは、世の中に数多くある CC0（パブリックドメイン）や、CC-BY-SA(Attribution-ShareAlike) などの再利用に関する条件が緩やかなベクトルデータを、ブロックチェーン上に書き込み、オープンなAPIを通じて、他のスマートコントラクトから自由に使えるようにしよう、という発想から始まったプロジェクトです。 プログラミングは、６月２１日にシアトルから日本に来る飛行機の中でスタートし、７月１０日に正式リリースしました。この時期は、日本で色々とやらねばならないことがあったので、実働出来たのは１０日間ぐらいです。 ローンチに向けて、以下のような作業をしました。AssetStore の設計と実装SVGデータの圧縮アルゴリズムの設計と実装クラウドミンティングを可能にするインセンティブ設計MaterialTokenの設計と実装SVGデータの変換ツールの設計と実装Discordコミュニティの立ち上げと運営 AssetStore は、このプロジェクトの中心的な役割を果たすスマートコントラクトであり、アップデートも不可能なので、慎重に慎重を重ねて実装しました。「とりあえず動くもの」は飛行機の中で作ったので、それを複数回のリファクタリングを繰り返して、少しづつ改良しました（Github の履歴で、その過程を見ることが可能です）。 その過程で重要な役割を果たしたのが、テストです。正しく動いていることを自動的に確認してくれるテストプログラムを作り（"npm run test" で実行出来ます）、それを変更するたびに実行し、副作用がないことを確認しながら丁寧に進めました。 「テスト駆動型プログラミング」などと言う大袈裟な名前をつける人もいますが、スマートコントラクトのような、ユーザーインターフェイスが関わらないバックエンドモジュール（MVCアーキテクチャで Model に相当する部分）に関しては、このアプローチはとても有効です。 ちなみに、実装しているうちにスマートコントラクトが次第に大きくなって複雑度が増し、どこに何が書いてあるのかが分かりにくくなったため、コントラクトの階層化を行ったのですが、これはとても有効でした。クリプトゾンビの中にも、コントラクトの階層化の話が少し出て来ますが、「メンテナンスしやすいコントラクト」を作る上では、もっとも重要なコンセプトとも言えます。 AssetStore は、以下のような階層構造で作られています。abstract contract AssetStoreCore is Ownable, IAssetStoreRegistry {...}abstract contract AssetStoreAdmin is AssetStoreCore {...}contract AppStoreRegistory is AssetStoreAdmin {...}contract AssetStore is AppStoreRegistory, IAssetStore {...} AssetStoreCoreは、アセット・データベースを実装している部分です。データベースの整合性だとか、効率を考える上では、ここだけを見れば良いように設計してあります。ガス代のほとんどはこのレイヤーで消費されるので、ガス代を考慮した最適化をする際には、ここだけを見れば良いように設計されています。 AssetStoreAdmin は、管理者向けのメソッドを提供する部分で、ここがホワイトリストやブラックリストの管理を行い、すべてのメソッドは管理者権限を持つ人しか呼べないように作ってあります。管理者用のメソッドをここに集中したことにより、セキュリティ面からの解析がとてもやりやすくなりました。 AppStoreRegistoryは、アセットの登録など、IAssetStoreRegistry インターフェイスに定義されているメソッドを実装している部分です。セキュリティ面から言えば、ホワイトリストに乗っているコントラクトからのみ呼ぶことが出来るメソッドがここに集中しています。スマートコントラクトの設計・実装においては、セキュリティ面がとても重要なので、こんな風に、セキュリティ・レベルで階層化することを強くお勧めします。 AssetStore が、一番上のレイヤー（実際にデプロイしたもの）ですが、ここにはブラウジングやSVGの生成など、読み込み専用のメソッド（view もしくは pure）のみが置かれています。読み込み専用ということは、セキュリティ面での心配をほとんどする必要がないことを意味します。