こんにちは、テクノロジー部の菊池です。
LIGのテクノロジー部ではクロスファンクションという勉強会活動をしており、そのうち僕はブロックチェーン（Web3.0）のチームリードをしています。
前回のブログでは、「Web2.0エンジニアがWeb3.0・ブロックチェーンを学ぶべき理由」についてお話ししました。
Web2.0エンジニアがWeb3.0・ブロックチェーンを学ぶべき理由とは？
Hiroyuki Kikuchi
今回は、ブロックチェーンやWeb3.0がどのようにビジネスの世界で取り扱われているかを理解したうえで、テクノロジーの観点から何をどのように学ぶべきかについてお話ししたいと思います。
目次
用語
うちのクロスファンクションメンバーが最初に相当躓いたのは、ここです。ブロックチェーンやWeb3.0の世界では、新しい用語が大変多いのです。
例えば、Gasであったり、マイニング、コンセンサス、Block、トランザクション、ノード、ABI、PoS、PoWなど……覚えるべき用語がたくさんある状況です。
ここで一つひとつの用語に関する解説は避けたいとは思いますが、一つひとつの用語がどのように関連付けされているか、マインドマップを描きながら用語を紐付けすることをおすすめします。
結果的には、ブロックチェーン全体のアーキテクチャを見れるようになってくると思います。
セキュリティ観点
ブロックチェーンのセキュリティはよく覚えておいたほうが良いと思います。理由としては、クライアント様や各ステークホルダーから、中央で管理する人がいないのにセキュリティ的に大丈夫なの？ とエンジニアの皆さんに対して懸念を覚えられる可能性があるためです。
まさしくおっしゃる通りだと思います。ブロックチェーンがどのようにして高い堅牢性を施されたアルゴリズムであり、アーキテクチャについて正しく理解する必要性はあると思います。特に情報漏洩という部分については、禁忌するべきことではあるので尚更ですね。
学ぶべきセキュリティのポイントはご覧の通りです。
- コンセンサス
- ハッシュ
- RSA
コンセンサス
1つ目のコンセンサスというのは、ブロックチェーンのコアとなる部分となります。コンセンサスとは、ブロックチェーン上で新しいBlockデータの書き込みを検証と承認するワークフローです。
要は世界中の利用者から送られてきたトランザクションデータの整合性チェックをおこない、一定数のマイナーから承認を得られれば新しいBlockの追加を実施しています。この場では細かいコンセンサスのロジックについては割愛しますが、知っておくべきことはどのようなコンセンサスにはどのような種類があり、どのような特徴と利点と欠点があるかについてです。
例えばPoW（Proof of Work）の特徴は、世界中のEthereumネットワークに参加しているマイニング参加者（マイナー）の51%の承認が必要であり、メリットは、誰でもマイナーとして参加することができること。デメリットとしては、PoS（Proof of Stake）と比べてGas代が高騰したり、各マイナーサーバーの電力消費が問題になっていること。
後述となりますが、各仮想通貨はコンセンサスアルゴリズムは異なり、どの仮想通貨を選定するかにも役立つことにもなるので、しっかりとポイントを押さえたいですね。
ハッシュ
2つ目のハッシュについては、ブロックチェーンのアルゴリズムにおいてよく出てくるキーワードです。ブロックチェーンはトランザクションデータや各々のBlockなどありとあらゆる情報について、ハッシュ形式でリレーションシップをとっています。
これを理解しておくべき一番の理由はセキュリティです。ブロックチェーンではありとあらゆる資産を台帳機能つきで管理されます。実際にエンジニアの皆さんがクライアントの方から、データの改竄対策は大丈夫なの？ と言われたときに、ブロックチェーンの強力な改竄対策について説明する必要性があります。
ちなみにハッシュ構造化することによって何ができるかというと、改竄されたかどうかを確認することができます。Blockの場合は新しいBlockに前Blockのハッシュ値を保持することになります。そうすることでBlock前後関係についてお互い改竄確認を実施します。また分散型技術により壊れたBlockを抱えているノードは、他の正常なノードによって正常化されます。
RSA
3つ目のRSAについて、全ユーザーのウォレット情報は各ユーザー固有の秘密鍵によって、復号が可能な状況となります。つまりブロックチェーン上では、秘密鍵と対となる公開鍵暗号化方式によってデータが暗号化され保存されている状況です。
公開鍵暗号化方式では、1024～2048ビットの暗号鍵が利用されており、現在のコンピューターの性能ではほぼ解読が難しい状況です。そのため、秘密鍵がない限りはユーザーのデータの読み出しは不可能な状況です。
また、秘密鍵さえあれば、別ブラウザやデバイスに対して、ウォレットの移行が可能な状況です。そのため、秘密鍵の管理は最重要課題となります。
他にもまだブロックチェーンには様々なセキュリティ方式を施されておりますので、各関係者にしっかりと説明して安心してもらえるようになるまで、学ばれたほうが良いかと思います。
各仮想通貨の特徴を理解する
筆者自身もNFT関連の要件定義を実施する際に悩んだことがあります。それはどの仮想通貨を使って、スマートコントラクトを実施するべきかについてです。
2022年9月現在では、Ethereumの時価総額は22兆円となっている状況で、メジャーな仮想通貨として利用されている状況です。しかしながら、コンセンサスと呼ばれるトランザクションの検証や承認プロセスで大変時間がかかっていること、Gas代が高いことが問題になっています（将来的なハードフォークで解消される見込みですが）。
Gas代が安いと思われるSolanaについても検討してみましたが、スマートコントラクトのロジックがC++やらRust言語と呼ばれているものとなっており、現在のWebエンジニアにとって馴染みがなく、どれを選定するべきか大変悩んでおりました。
このように各仮想通貨には、それぞれ特徴があります。これからブロックチェーンエンジニアを目指される方は少なくとも、各仮想通貨の以下ポイントは押さえておきたいところです
- コンセンサスアルゴリズム
- スマートコントラクトのプログラミング言語
- 仮想通貨の流通量
これらの選定を誤ってしまうと、例えばGas代が高いコンセンサスアルゴリズムの仮想通貨を選んでしまったがゆえになかなかサービスが普及しなかったり、Gas代が安いからといって、マイナーな仮想通貨を選んでしまったがゆえに他のサービスでも、利用ができなくってしまったり、最悪その仮想通貨がなくなってしまって、紙屑となってしまう恐れがあります。各仮想通貨の特徴を掴んだうえでメリット、デメリットをアウトプットできるようになることをおすすめします。
Solidityでコードを書いてみる
スマートコントラクトのコードについて、仮想通貨によってはRustやC++で書けたりしますが、これらの言語はメモリ管理やらポインタ管理などを実施する必要性があり、あまりオープンWeb系のエンジニアには適していないと思います（ただし処理速度という観点では、大変適していると思います）。
オープンWeb系のエンジニアの人にとっては、Solidityと呼ばれる言語が適していると思います。
その理由はご覧のとおりです。
- オブジェクト指向型プログラミング
- JavaやPHPなどのオープンWeb系で使う言語と似ている
現にSolanaと呼ばれている仮想通貨のスマートコントラクトは、C/C++/Rust言語で定義する必要がありますが、圧倒的に世界に採用されているEthereumではSolidityをスマートコントラクトとして採用している状況です。
その背景もあるので、Web2.0からブロックチェーンエンジニアへなるためには、まずはSolidityから始められてみるといいでしょう（無論、案件でSolanaを選択されたら、否応なしにC/C++/Rustを学ぶ必要があります）。
クライアントアプリケーション言語を勉強する
スマートコントラクトを呼ぶためには、クライアントアプリケーションから呼ばれる必要があります。クライアントアプリケーションはどの言語で定義されているかというと、Ethereumの記事を見る限りですとご覧のとおりとなります。
- Dart
- Go
- .Net
- Go
- Java
- JavaScript
- Python
- Ruby
- Rust
JavaScriptを例にとると、web3.jsやらEthers.jsというライブラリが存在しており、これによってEthereumノードやスマートコントラクトへのアクセス、仮想通貨の送金などを実施できます。
スマートコントラクトをどのように叩けば良いかについても、これらライブラリを通じて学ぶべきだと考えます。
各ネットワークの特徴を理解する
ブロックチェーンには以下3つのネットワークが存在しております。
- プライベート型
- コンソーシアム型
- パブリック型
簡単に特徴をお伝えすると、プライベート型はその組織内のみしか使わないネットワーク、コンソーシアム型は外部には公開はしないけれども許可性による参加型の組織間で共同利用ネットワーク、パブリックネットワークは全世界誰でも参加可能なネットワークです。
なぜ特徴を知っておくべきかというと、適切な技術選定をおこなうためです。
例えばNFTマーケットプレイスを作るために、プライベートネットワークを採用するとかは、あり得ないですよね？ 逆に顧客データなど、特定の組織間だけで共有したいのにバブリックネットワークを使うのは、ありえない選択かなと考えます。
そうならないように、どこまで何を誰に対して公開するか、誰までを参加可能にするかなどの定義は必要になってくるかと考えます。
規格を理解しよう
ブロックチェーンのなかには様々な規格がありますが、今回はEthereumであるERCについてお話をしてみたいと思います。規格ですが、こちらのEthereumのサイトに書かれています。これらの規格はSolidityのプログラムで、インターフェースとして提供されており、Solidityのプログラムの中でオーバーライドが必要です。
たくさんの規格がありますが、すべて覚える必要性はないです。大事なことは、多数の規格から適切なものを選択できるようになることです。
例えばEIP-20は独自トークンを発行するための規格ですし、EIP-721はNFTを管理するための規格です。各規格が何を目的で作られたものか、提供されているインターフェースはどのタイミングで呼び出しをされるかなど、理解することが大事です。
幸いにもこれらは共通規格のため、世界中に同様に開発経験があるエンジニアもいるので、彼らのGitHubなどを覗いてみて、開発してみるといいでしょう。
また規格については、Solidityのバージョンアップにつれて新機能も搭載されます。例えばEIP-2981は、NFTのロイヤリティ機能を搭載しています。どの規格を採用するかに応じて、プロジェクトの生き死にが決まるので、適切な選定が必要なところですね。
様々なデザイン（設計）パターンを収集ならびに学習しよう
プログラミング言語をSolidityを使う前提にはなりますが、前述のとおり、Solidityはオブジェクト指向型のプログラミング言語です。さらにクラスやインターフェースの継承をおこない、オーバーライドやオーバーロードの定義が必要です。
大変困ったことに、一度デプロイしたスマートコントラクトはアップデートすることは不可能です。何か問題が起きたときでも、修正が可能なようにクラス（コントラクト）設計が大切です。スマートコントラクトを更新できるようにするためには、ロジックとデータのコントラクトを分離することで、仮にロジックが間違えていたとしても、ロジック部分のみを修正し、新しいスマートコントラクトとしてデプロイすることで、データには影響が出ないようにすることができます。
このように適切なコントラクト設計をおこなえるようにするためには、インターネットの記事を見ると様々なデザインパターンがあるので、それを参考にしながらコントラクト設計をおこなえるようになると良いでしょう。
Web2.0の世界をとると、GoFのデザインパターンによるクラス設計みたいなものですね。
ここで一つ例を挙げてみましょう！ 例えば、英語の記事にはなりますが、「Design Patterns In Solidity」という記事では様々なデザインパターンについて書かれています。このサイトをみている限り、GoFと同様のFactory creation patternが定義されていますね！
一つのFactoryクラスから様々な具象オブジェクトを生成するデザインパターンです。これによってコントラクトごとに独立性の高いコードを構築することが可能になりますね！
またLogRocketというサイトでは比較的世界的によくOracleパターンについて記載されています。このパターンは端的に言うと、APIなどを使って外部データをスマートコントラクトでハンドリングするためのデザインパターンです。外部からデータソースの状態変化が発生したら、スマートコントラクトのロジックで一定の処理をおこなうことが可能となります。
例としては、完全に賭博かつ違法ですが、天気の結果が晴れか雨かを賭けるアプリが存在するとします。しかしながら、スマートコントラクトは完全にクローズな世界につき、APIを取得しない限りは外部の世界の状況がわかりません。そこでスマートコントラクトからAPIを呼び出しをおこない、晴れであれば晴れに対して、Betしているユーザーに対して仮想通貨を送金するなどのスマートコントラクトも実現することが可能です。
今回は一部のみの紹介とはなりますが、適切かつ更新が可能なスマートコントラクト設計ができるように様々なデザインパターンを学習されることをおすすめします。
おまけ
ここからのお話はブロックチェーンエンジニアのみではなく、システムやアプリ、サービス全体を設計する方向けのお話になります。
当然のことながら、スマートコントラクトのプログラムをキックするのは、「クライアントアプリケーション言語を勉強する」で書いたようなクライアントアプリケーション側となります。
例えばクライアントアプリのロジックをバックエンド側に持たせたいとなったら、どうしますか？ また、ウォレットレスのブロックチェーンサービスを開発したいというユーザーの希望があった場合、ウォレット情報はWeb2.0の世界で持たせる必要がありますが、どのようにして秘密鍵を管理しましょうか？
ここでお伝えしたいことは何かというと、クライアントだったり、社内のステークホルダーの要望を柔軟に取り込めるようにするために、Web2.0×Web3.0のアーキテクチャを検討できるようになることです。
前述のとおり、仮想通貨のウォレットの管理は、UX的にみたらまだユーザーに馴染みがない部分はあります。とはいえ、ウォレットレスアプリケーション開発は、Web3.0だけでは不可能な状況で、Web2.0の技術採用が必要となります。
柔軟に様々な技術を取り入れると、UXの向上などの相乗効果が生まれるうようになりますし、結果的にアーキテクチャまで検討ができるようになると思います。そのためには、AWSやAzureなど世界を代表するクラウドサービスについて学習して、どのようにWeb3.0のアーキテクチャと連結するか考えられるようになると良いかと考えます。
最後に
ここまで、色々と文章を書いてみましたが、やはりブログを書いてみてアウトプットすることが大事だということに改めて気づきました。
裏を返すと、ブロックチェーンエンジニアとなるためには、座学のみをやるのではなく、このように何かしらの形でアウトプットしてみたり、LIGみたいにクロスファンクションという形でメンバー同士と話し合ったり知見を得ながら、学習を進めていくということで、より相乗効果が得られると思います。
クロスファンクション並びにチームリード活動を引き続き頑張っていき、どんどんチームとしての技術スタックをためていきたいと思います！
最後までお読みいただきありがとうございました！
