【流れでわかる】Web3の基礎をマスターする：ノードからネットワークまで
【初めに】
この記事は2022年9月22日に公開された@0xPhillan氏による「Master Web3 Fundamentals: From Node To Network」を許可を得た上で翻訳した記事になります。
*原文執筆時(2022年9月22日)から時間が経過しているため、内容と実際の情報が異なる場合があります。予めご了承ください。
web3は、様々な構成要素、技術、コンセプトを組み合わせた、広大で複雑なものです。Web3、ブロックチェーン、暗号の初心者でも、ベテランでも、この記事で、Web3を稼働するさまざまな構成要素のハイレベルな概要を知り、各構成要素の目的と利点を理解できるようになります。
具体的には、本シリーズの目的は以下の通りです。
1,Web3の基本的な構成要素の概要を説明する
2,各構成要素の目的を理解する
私たちはWeb3をインターネットの次の形態と定義しています。
現在のインターネットの機能に加え、検証可能なデジタル所有権、オープンシステム、透明性、普遍性を追加した形になります。
Web3、BlockChain、Cryptoは、密接に関連する3つのトピックですが、ここでは3つの別々の用語として扱っていきます。
それぞれの用語の定義
・BlockChain：検証可能なデジタル所有権、透明性、不変性を可能にする技術的革新
・Crypto：暗号通貨の略で、ブロックチェーンネットワーク上で暗号的に保護されたトークンを示す
・Web3：ブロックチェーン、暗号、およびその上に構築されたすべてのエコシステムとイノベーションを包括する
Web3を理解するために、基礎となるブロックチェーンと暗号技術を理解する必要があります。Bitcoinは、2009年にローンチされたばかりで、Web3自体が、まだ比較的新しい概念です。
本記事がWeb3の理解の一助となり、また、本記事をきっかけにみなさんが興味のある分野を見つけ、研究するきっかけになればと考えています。
また、各トピックをより深く掘り下げるための追加資料へのリンクを散りばめたので、道しるべとなることを願っています。
本記事は3部構成となっており、本編ではWeb3ノードのインフラからレイヤー1のブロックチェーンネットワークの仕組みまで、必要なことを網羅しています。
次に、レイヤー2、相互運用性、そして本作品で概説したプリミティブの上に構築された膨大なdAppエコシステムについて説明します。
最後に、オフチェーン環境とオン／オフチェーン間の通信について取り上げます。
【Web3基盤の概要】
Web3基盤は、オンチェーン・エコシステム、オンチェーン・エコシステムを支えるオフチェーン環境、分散型ネットワーク同士を接続し、オフチェーン環境と接続するためのミドルウェアに分類されます。
●オンチェーンエコシステム
○ノードレイヤー
マイニング/バリデーションノード、ノードクライアントソフトウェア、 マイニング/ステーキングプール
○ネットワークレイヤー
■レイヤー1ネットワーク
モノリシックネットワーク、モジュラーネットワーク、コンセンサス（PoW、PoS）、Shared Ledger(共有台帳)技術、仮想マシン＆EVM互換性、スマートコントラクト、ERCトークン標準規格
■レイヤー2ネットワーク
ライトニングネットワーク、楽観的ロールアップ、ゼロナレッジロールアップ
○分散型アプリケーション（dApp）層
●オフチェーン環境
アナリティクス、監査＆セキュリティ、ウォレット、集中型取引所（CEX）、開発者ツール（フレームワーク、IDE）、分散型クラウド（ストレージ、コンピューティング、インデキシング）
●相互運用性レイヤー（「ミドルウェア」）
○ネットワークの相互運用性
ブリッジ、アトミック・スワップ
○オン／オフチェーンコミュニケーションツール：
ブロックチェーンAPI、オラクル
【オンチェーンエコシステム】
オンチェーンエコシステムは、主に3つの層に分かれています。
・分散型アプリケーション（dApp）レイヤー
・ネットワーク層
・ノード層
この3つのレイヤーを組み合わせることで、Web3が得意とするスマートコントラクト主導のエコシステムとアプリケーションを実現することができます。
ここでは、オンチェーン・エコシステムをノード層から、dApp層まで解説していきます。
●ノードレイヤー
この層では、ハードウェアと、特定のブロックチェーンネットワークに参加するためのハードウェア操作に関連するすべてがセットアップできます。このレイヤーは、ハードウェアレイヤーとも呼ばれます。
○ノードクライアント
ノードとは、クライアントと呼ばれるネットワーク専用のソフトウェアを実行するサーバーのことで、ノードがネットワークのブロック生成プロセスに参加したり、ブロックチェーン全体の履歴データにアクセスしたり、RPCコマンドを実行できるようにします。（詳しくはLayer1のセクションで説明します。）
RPCはRemote Procedure Call(リモートプロシージャコール)の略で、特定のコマンドをノードから呼び出して実行できるようにするものです。
この記事を書いている時点では、時価総額で2大ブロックチェーンネットワークは、BitcoinとEthereumです。
それぞれのネットワークに参加するための必要条件は異なりますが、どちらもクライアントのハードウェアの仕様を満たすサーバー（任意のコンピュータ）、インターネット接続、クライアントソフトウェアが必要です。
Bitcoinの場合、最も人気のあるクライアントソフトウェアはBitcoin Coreであり、Ethereumの場合、最も人気のあるクライアントはGETH（Go Ethereum）となっています。
クライアントはブロックチェーンのルールを成文化し、検証された新しいブロックが同じルールに従うように運用します。
ルールを運用しなかった場合、あるノードが他のノードが受け入れないブロックを検証すると、ネットワークがフォークしてしまう等の問題が発生してしまいます。
あるノードはあるルールに従い、他のノードは別のルールに従う。同じ履歴を共有していても、異なる検証ルールが導入された瞬間に新しいチェーンが作られ、新しいルールを受け入れるノードのみが受け入れられてしまうことを回避します。
前述したクライアントは最も人気のあるクライアントですが、ブロックチェーンネットワークに参加するために使用できるクライアントはこれだけではありません。
また、ブロックチェーンの仕組みの詳細については、レイヤー 1 ネットワークのセクションに記載します。
○ノードインフラストラクチャープロバイダー
一般ユーザーは、パブリックネットワークの分散化をサポートするために、自分のノードを実行するよう奨励されます。理由としては、より多くのユーザーが独自のノードを運営すれば、誰かが実行中のノードの大部分を占有してネットワークを攻撃する等の可能性を減らすことができるからです。
このような背景から、ネットワークは、ノード運営者に分配するブロック報酬や取引手数料を通じて、ユーザーが自前のノードを運営するよう奨励しています。
ただ、上記のようなインセンティブがあるにもかかわらず、多くのユーザーは自前でノードを設置していません。理由としては、複雑な技術的セットアップ、必要なハードウェアを購入するための先行投資、ノードを一時的にしか必要としない等があるからです。
そこで登場するのが、ノード・インフラ・プロバイダーです。これらのプロバイダーは、ノードのセットアップと運用を請け負い、クライアントにエンドツーエンドのサービスを提供します。ノード・インフラを専門とする大規模なプロバイダーには、BlockdaemonやAllnodesなどがあります。
これらのノードインフラストラクチャープロバイダーの便益は、まだ強力な分散型ノードネットワークを構築していない新しいブロックチェーンプロジェクトのためにノードを提供することです。
これらの新しいネットワークは、ノードインフラストラクチャープロバイダを利用することで、各国で独自のインフラストラクチャーを設定する手間をかけずに、グローバルな分散型ネットワークを稼働させることができます。
○マイニングプールとステーキングプロバイダー
ノード・インフラ・プロバイダーがクライアントのためにノードを設置するのに対し、マイニングプールやステーキング・プロバイダーは独自のノードを運用し、ユーザーが自分のノードの下にリソースをプールできるようにしています。
これにより、ノードがネットワークからブロック報酬や取引手数料の収益を受け取ることができるようになります。使っていないハードウェアを活用したいユーザーにとっては、複雑な技術的セットアップなしにマイニングプールに参加し、既存のリソースで収益を上げることができます。
また、コンセンサス・メカニズムが異なるネットワークでは、ノードの操作に若干のニュアンスの違いがあるので注意してください。
基本的に、Proof-of-Workを使用するネットワークは計算資源をプールし、Proof-of-Stakeネットワークはネットワークトークンをプールします。Proof-of-Workネットワークではマイニングプールが参入への技術的障壁を大きく軽減し、Proof-of-Stakeネットワークではステーキングプロバイダが参入への金銭的障壁（最低必要ステーク）を大きく軽減しています。
詳細はコンセンサスのセクションで説明します。
最大のマイニングプールにはFoundry USAとF2POOL等が含まれ、最大のステーキングプロバイダーにはLidoとRocketpoolなどが含まれます。
○まとめ - ノード層
Web3のノード層は、グローバルに分散した数千のノードで構成されており、特定のネットワークの一部である各ノードでは、そのネットワークに必要なクライアントソフトウェアが実行されています。
クライアントソフトウェアの検証ルールがネットワーク上の他のノードと同じである限り、そのノードはブロックチェーンのフォークを引き起こすことなく正常に動作することができます。
パブリックな分散型ブロックチェーン・ネットワークでは、誰でも自分のノードを動かすことができますが、ノードインフラストラクチャープロバイダーは、ノードの運用とネットワークの立ち上げに必要なハードウェアのセットアップと運用に特化しています。
最後に、マイニングプールとステーキングプロバイダーは、マイニングとステーキングへの参入障壁を減らします。
これにより、ユーザーはネットワークに参加するための要件条件を満たしていなくても、マイニングやステーキング活動に参加し、ネットワークインセンティブを獲得することができます。
●ネットワークレイヤー
ブロックチェーンネットワークは、上記のノード基盤の上で稼働しています。ネットワーク層は様々な部分から構成されており、Layer1ネットワーク、Layer2ネットワーク、そしてこれらのネットワーク間で通信するためのインターオペラビリティ層が必須となり、幅広い技術で構成されています。
○Layer1ネットワーク
Bitcoin、Ethereum、Solanaは、本稿執筆時点で最もよく知られているLayer1ネットワークだと思います。
Layer1ネットワークとは、Web3エコシステムのメインネットワークで、トランザクションの決済を行うものを指します。
Layer2ネットワークはLayer1ネットワークの上位レイヤーとして存在し、トランザクションをオフチェーンでトランザクションを実行することができます（詳細は次回の見出しに記載します）
アーキテクチャ的には全く異なるものですが、これらはすべて同様のアーキテクチャ・プリミティブのセットに依存しています。
・ネットワーク上の取引を追跡する共有台帳を有している
・どの取引とブロックを有効とみなすかについて、コンセンサスを得るためのメカニズムを採用している
・ネットワークに送信されるコマンドを計算する構造を持つ（Ethereum
仮想マシン、ソラナや他のEVM互換チェーン、BitcoinはBitcoinスクリプト）
以下のセクションでは、上記の3つの要素それぞれについて見ていき、取引からブロックチェーンに記録されるまでの要素を分解していきます。
○Shared Ledger(共有台帳)
すべての分散型ブロックチェーン・ネットワークは、"Shared Ledger(共有台帳)"を備えています。台帳とは、ビジネスの経済活動を記録したもので、お金の移動や資産の所有権の移動を追跡するために使われます。
"Shared Ledger(共有台帳)"という言葉は、台帳が単一の主体によって保持・管理されているのではなく、多くの主体によって保持・管理されていることを意味します。
分散型ブロックチェーンネットワークでは、ブロックチェーン（ネットワーク上のすべての活動の台帳）はネットワーク上のすべてのノードに保存されています。もし、活動の台帳を中央集権的な1つの機関だけが管理・保存していた場合、以下のような課題にぶつかることになります。
・検閲と排除（PayPalによって削除されたユーザー）
・記録管理者による不正行為（ルーキンコーヒーによる財務内容の虚偽記載）
・記録の紛失（アレキサンドリア図書館の破壊）
台帳が何百、何千ものノードにまたがってグローバルに保存されていれば、意図的であろうとなかろうと、改ざんや破損が非常に困難なシステムを手に入れることができるようになります。
あるノードが破壊されても、ユーザーが接続できる他の多くのノードがあり、台帳とのやり取りを継続することができます。
ただし、このシステムには別の課題があります。ネットワーク上のノードは、何が正しいまたは有効な元帳エントリであるかについてどのように合意するのでしょうか？
ここで、コンセンサスアルゴリズムの出番です。
○コンセンス
ブロックチェーンネットワークにおいて、コンセンサスとは、ネットワーク上のノード間で、どのledger entries(台帳項目（取引やブロック）)が有効で、ノードに受け入れられるべきか？という一般的な合意形成を意味します。
この合意形成における問題は"ビザンチン将軍問題"として知られています。ビザンチン将軍問題は、システムが壊滅的な失敗を避けるために参加者全員で、戦略に対する合意を取る必要があるが、システムの参加者の中には信頼できない参加者もいて、こういった場合にどのような方法で、全体の合意形成をとるか？という問題のことを指しています。
具体的に、このシナリオでは、3人の行為者がいて、ビザンツ戦争で敵に蹂躙されないように、次のステップを調整しなければならないという状況にあります。
シチュエーションは、3人のうち1人は悪意があり、残りの関係者に一貫性のないメッセージを中継しているという状態です。
このシチュエーションにおける正直な（悪意のない）参加者は、どのようにして誰を信頼すべきか？
あるいは、別の言い方をすれば、システム内のすべての参加者は、どのメッセージを受け入れるべきかについて、どのように合意形成を作ることができるでしょうか？
システムに参加者が増えれば増えるほど、（誤った）コミュニケーションの複雑さは指数関数的に増大していくため、この問題は非常に重要なテーマとなっています。
この課題を世界規模で解決することに成功した最初のシステムが、Proof-of-Workアルゴリズムを採用したBitcoinです。
■Proof-of-Work(PoW)
BitcoinのProof-of-Workアルゴリズム（PoWとも呼ばれる）は、ノードに受け入れられるために、あらゆるメッセージがある種の検証を受けたことを証明するという方法を使うことによって、ビザンチン将軍の問題を解決しています。この検証を受けていないメッセージは有効なものとして受け入れられず、ノードから拒否されます。
また、検証プロセスには計算機資源が必要であり、検証の偽造は非常に困難です。Proof-of-Workの語源もここにあります。「私があなたのメッセージを受け入れるために、必要な作業を行ったことを証明しなさい」という意味になっています。
理論から実践に移り、トランザクション、ブロック、PoWプロセスの仕組みについて少し掘り下げてみましょう。
□ブロック構造
Bitcoinのブロックは、取引履歴が保存される場所であり、厳重に管理されている情報の1つの集合体です。暗号化されたパズルが解かれると、ネットワークを通じて配信されます。
Bitcoinのブロックは、主に2つの部分から構成されています。
1, ブロックヘッダ
2, トランザクションのリスト
トランザクションリストはその名の通り、ノードが受け取りブロックに含めたトランザクションのリストのことを指しています。
Bitcoinにおけるトランザクションは、Bitcoinネットワーク上のBitcoinの転送のことを指します。（注：小文字のbが付いたBitcoinはBitcoinアセットを指し、大文字のBが付いたBitcoinはBitcoinネットワークのことを指します）
Bitcoinネットワークは、Bitcoin資産の動きを追跡する誰でも見ることができる公開台帳です。したがって、Bitcoin上の取引は、アドレス間のBitcoinの移動を示しています。
Bitcoinは、取引の際にUTXOとして知られている未使用のトランザクション出力を使用します。
取引とUTXOについては、UTXOモデルとアカウントモデルのセクションで詳しく説明します。
トランザクションの数と各トランザクションで転送される金額はブロックによって異なりますが、ブロックヘッダーの要素はすべてのトランザクションで同じになります。
ブロックヘッダには多くの要素があります。それぞれの要素が極めて重要なのですが、ここでは入門編なので、以下の要素をのみを詳しく説明します。
・Hash of previous block’s header：前のブロックのすべての要素がハッシュ化されます
・Difficulty target：‘leading 0s’の量、つまり採掘の難易度を決定します
・Nonce：任意の数値（nonceは "nonsense "の略称）
・Merkle root：このブロック内の全トランザクションをハッシュ化したもの
□ブロックからブロックチェーンへ
先に進む前に、ハッシュについて簡単に説明する必要があります。ハッシュ化とは、ある文字列を別の値に変換する処理です。
ハッシュアルゴリズムが決定論的であるということは、同じ入力があれば、出力は毎回同じになるということです。しかし、元の文字列の1文字が変わると、ハッシュ出力は全く変わってしまい、元の文字列との関係を推測することができなくなってしまいます。
以下のBitcoinとBitcoinのSHA256ハッシュアルゴリズム出力の比較をご覧ください。
Bitcoinでは、あるブロックが採掘されると、そのブロックのヘッダーがハッシュ化され、次のブロックの入力として含まれます。各ブロックの前のヘッダーのハッシュが次のブロックに含まれるため、ブロックの連鎖ができます。これがブロックチェーンと呼ばれるものとなります。
次のブロックに既に含まれていたハッシュ化された出力は、新しいハッシュ化された出力とは異なるため、任意のブロックに変更を加えるとチェーンが壊れます。このような変更は、ネットワーク上のノードによって拒否されます。
□Merkle Root
Merkle Treeは、データ構造の要素が 1 つの要素だけになるまに連続的にハッシュされるデータ構造です。残りの要素はMerkle Rootです。
Merkle Treeには、ある要素がMerkle Treeの一部であることを、Merkle rootとその要素だけで証明できるという、数学的に面白い特徴があります。
Bitcoinでは、ブロックヘッダに格納されるMerkle rootは、そのブロックに含まれるすべての取引の再帰的ハッシュ出力になっています。
つまり、どこかの取引が調整されれば、Merkle rootも変化し、ヘッダー全体のハッシュ出力も変化することになる。そうなると、ブロックが無効化してしまいます。
□ルーフ・オブ・ワークにおける"作業"
ハッシュとは何か、ブロックはどのように構成され、ブロックチェーンはどのように連鎖して形成されるかが分かったところで、いよいよProof-of-Workの実際の仕組みについて掘り下げていきます。
ビザンチン将軍の問題に戻りますが、検証されたメッセージは、実はブロックチェーンのブロックなのです。ブロックが検証されるには、特定の条件を満たすハッシュを見つける必要があります。たった1ビットの変化で、ハッシュの出力が大きく変わるのを覚えていますでしょうか？BitcoinのPoWアルゴリズムは、まさにこの方法でターゲットハッシュを探します。
任意の数であるnonceを調整して、ブロックヘッダのハッシュ出力を変化させます。ハッシュ出力がターゲットハッシュを満たさない場合、nonceは再び調整されます。この処理を、ブロックヘッダのハッシュが目標条件を満たすまで繰り返す。目標条件を満たすと、ブロックヘッダは有効とみなされ、ブロックはネットワーク上の他のノードにブロードキャストされ、ブロックチェーンのコピーに新しいブロックが追加されます。
目標条件、つまり期待されるハッシュは、先頭のゼロの数によって定義されます。十分な数のゼロを含むハッシュが生成された場合、つまり、目標条件を満たすハッシュを見つけるための作業が行われた場合、ネットワーク上のノードはそのブロックを有効なものとして受け入れることになります。
このプロセスを理解するために、Githubにあるハッシュアルゴリズムシミュレーターに移動してください。“Bitcoin”という文字を入力し、末尾に数字を付けます。
0から始まり、先頭の0になるまで1ずつ数字を増やしていきます（例：bitcoin0、bitcoin1、など）。1つの先頭のゼロ、つまりハッシュの最初の文字がゼロであることを見つけるには、3まで数字を増やすだけでよいことにお気づきでしょう（「bitcoin3」）。次に、先頭のゼロを2つ見つけることに挑戦してみましょう。
ネタバレ：先頭のゼロが2つある最初のハッシュは「bitcoin230」からの結果です。
ノードが遵守すべきルールはこれだけではありません。
例えば、最も長いチェーンは常に有効なチェーンである（ブロックチェーン全体が上書きされるのを防ぐ）、採掘されたブロックはネットワーク時間のある閾値内のタイムスタンプでなければならない（最新のブロックが上書きされないように）、またネットワークの難しさ（ターゲットハッシュのリーディングゼロの量）がどのように決定されるかに関わる複雑なメカニズムが存在等様々なルールがあります。
詳細はBitcoin.orgまたはBitcoin Wikiを参照してください。
□パラダイムシフト
上記の仕組みにより、歴史上初めて、第三者の証人なしでトランザクションを独立して確認および検証し、トランザクションを承認することができるようになりました。
中央集権化の課題を抱える銀行に取引証明を提出する代わりに、介入なしに自律的に取引を処理できる独立したノードのネットワークに送られるのです。このような技術的なパラダイムシフトと台帳の再構築は、今日のWeb3のエコシステムを構築するためのスタンダートとなっています。
さらに、ネットワークに参加するための唯一の要件は、ノードソフトウェアを実行できる計算装置とインターネット接続であるため、誰でも独立したノードとしてネットワークに参加でき、ネットワークの分散化を強化することができます。
□批判
ただ、一方で、BitcoinのようなPoWネットワークには、多くのノードが存在しており（bitnodes.ioによると2022年9月15日現在で約15000）、競争が激しいく、個々のノードの新規参入障壁が高すぎるという批判があります。
具体的には、ハッシュパワー（計算資源）が大きいノードほど、ネットワーク上の他のノードよりも速いペースで多くの計算ができるため、そのノードが最初にハッシュパズルを解ける可能性が高くなります。ハッシュパワーの低い単一ノードとしてBitcoinネットワークに参入すると、エネルギーコストがかかり、新しいブロックの採掘に最初に成功する可能性はほぼゼロになってしまいます。
また、ネットワークは膨大なエネルギーを必要とし、Bitcoinの年間エネルギー消費量はノルウェーを上回るとする試算もあり、批判の対象となっています。
このエネルギーは、ハッシュを探すために毎秒数百万回のハッシュ計算を行うノードに浪費されてしまっています。これはBitcoinネットワークの安全性を高める一方で、ブロックの検証にもっと無駄のないアプローチはないのか、という疑問を抱かせます。そこで登場するのが、Proof-of-Stake(POS)です。
■Proof-of-Stake(PoS)
Proof-of-Stakeでは、ノードはネットワークへの出資額に応じてブロックを検証する権限を与えられます。これはPoWとは根本的に異なるアプローチで、検証に必要な計算能力を大幅に削減することができます。
ノードは計算能力を提供する代わりに、ブロックを検証するチャンスと引き換えに、自分のネイティブネットワークトークンを担保として提供します。これにより、競争ベースの計算が本質的になくなり、ブロックの検証に成功するノードの普及が進みむと考えられています。
■その他のコンセンサスメカニズム
Proof-of-Work(PoW)とProof-of-Stake(PoS)以外にも、特定のネットワークと特定の目的のために設計されたコンセンサスメカニズムが多く存在します。以下は、一般的なコンセンサスメカニズムの非網羅的リストです。
Delegated Proof-of-Stage (DPoS)
Proof-of-Authority (PoA)
Proof-of-Activity (PoA)
Proof-of-Brun (PoB)
Proof-of-Spacetime (PoSt)
Proof-of-History (PoH)
Practical Byzantine Fault Tolerance (pBFT) Consensus
●Shared Ledgers – Accounting Systems (UTXO vsAccount Model)
ブロックチェーンとは、ハッシュ化により暗号化されたデータのブロックであり、これによってledger(台帳)が作成されると先に説明しました。
このledger(台帳)は、ネットワーク上の数千のノードにまたがり保存され、これらのネットワーク間でledger(台帳)が「共有」されることになります。共有されたブロックチェーン台帳であろうと、従来の会計台帳であろうと、どんな台帳でも記帳は必要です。
帳簿管理とは、取引をどのように受け入れ、実行し、新しい残高をブロックチェーンに保存するかということです。Web3では、主に2つの簿記モデルがあります。
・The Unspent Transaction Output (UTXO) モデル (e.g., Bitcoin)
・The Account モデル(e.g., Ethereum)
これらの異なる帳簿モデルの理解をするために、ブロックチェーンをステートマシンと考えることが役立ちます。ステートマシンは、状態を保存するシステムであり、その状態はデバイスへの入力に基づいて変化することができます。
つまり、ある時点では、システムはある状態にあり、取引などを通じてシステムに何らかの入力があると、システムの状態が変化するのです。システムに入力が提供され、状態が変化すると、システムは状態遷移を起こします。
ブロックチェーンをステートマシンのレンズを通して見ると、任意の時点でブロックチェーンシステムは状態nにあり、ブロックチェーンに追加されたブロックは状態遷移を起こし、新しい状態n+1になることを意味します。
この新しい状態n+1では、追加された新しいブロックに含まれていたすべての取引が考慮され、新しいシステム状態になります。
■未使用トランザクション出力(UTXO)モデル
UTXOモデルとAccountモデルの違いは、簿記、つまり取引の記録をどのように処理するかにあります。
詳細は省きますが、UTXOモデルでは、口座残高というものは存在しません。その代わり、すべての取引は、誰から誰へいくら送金されたかを記した領収書となります。
これがUnspent Transaction Outputという名前の由来であり、ユーザーが送金できる残高は、過去の取引でまだ使っていない金額であるという解釈のものもと運用されています。
ユーザーがBitcoinを送りたい場合、選択したUTXO内のすべてのBitcoinがトランザクションの入力になります（上記のUTXO0を参照）。新しいUTXOが作成され、送信される金額が格納されます（上記のUTXO2を参照）。UTXOが保有するBitcoinが送信するBitcoinより多い場合、残りのBitcoinは新しいUTXOとしてユーザーに送り返されます（上記の0.5が送信されますが、UTXO0には2.0が保有されているので、UTXO2には送信される0.5、UTX03には送信者に戻される1.5が含まれています）。
UTXOモデルの結果、すべてのトランザクションの出力には対応する入力が必要なため、すべてのネイティブトークンの起源をその作成までさかのぼることができます。
UTXOモデルを採用しているBitcoinでは、すべてのBitcoinが採掘されたブロックまで遡ることができることを意味します。その結果、UTXOモデルには残高という概念が存在しない。その代わり、残高とはネットワーク上のすべての取引受領の集合体となります。
ネットワーク上のすべての取引は、どの取引入力から誰がどれだけのBitcoinを得ているかかを正確に記録しています。そしてシステムは、取引入力が未使用であること、送信者がBitcoinを送信する権限を持ち、受信者がBitcoinを受け取るための正しいパラメータを満たしていることを確認することができます。
このように、UTXOモデルは検証システムとして考えることができます。
先ほどの例には含まれていませんが、採掘業者に支払われる取引手数料も取引の一部として差し引かれます。1.5コインではなく、UTXO3は1.499コインとなり、その差額が取引手数料となります。
■The Account Model
口座モデルは、従来の銀行口座のデジタル表現に近いです。状態遷移ごとに、UTXOモデルのように口座残高を計算しなければならない領収書のセットではなく、すべての口座と残高のセットが保存されます。
状態遷移を開始するには、残高を変更するようシステムに指示するトランザクションを開始する必要があります。次に、システムは各勘定科目の残高の変化を計算し、次の状態では新しい残高のセットが保存されます。
UTXOシステムでは、すべての取引入力（以前の取引から受け取ったUTXO）は個別に検証され、出力よりも大きくなければならないが、勘定モデルでは、勘定残高は取引出力よりも大きくなければならない。
つまり、UTXOシステムでは、複数のUTXOを組み合わせて個別に検証し、1つまたは複数の取引出力を作成することができるが、勘定モデルでは残高のみを検証する必要がある。
UTXOモデルとアカウントモデルの比較について詳しくは、この件に関する Horizen.ioの記事を読むことをお勧めします。
●Virtual Machines (仮想マシン,VM)、スマート コントラクト、チューリング完全性
仮想マシンは、コンピュータをエミュレートするソフトウェアの一部です。物理デバイスの代わりに、仮想コンピュータのすべての物理コンポーネントが別のシステム内でソフトウェアとして実行されます。
例えば、Windows VMはMacOS上で実行することができ、Windowsシステム全体をMacOSの内部で実行することができます。Windowsマシンの物理コンポーネントはソフトウェアでエミュレートされているため、Windowsシステムには一切影響がありません。
これと同じコンセプトがブロックチェーンネットワークにも適用されています。Shared Ledger(共有台帳)の傍らに別の仮想マシンコンポーネントが存在し、計算タスクの実行を可能にしているのです。
つまり、残高（Accountモデル）や残高の変更（UTXOモデル）が保存されるShared Ledger(共有台帳)とは別に、残高を計算するための計算コンポーネントが存在することになります。この計算コンポーネントは、単純な残高計算だけでなく、より複雑なロジックにも利用することができる。
これがスマートコントラクトへの道を開きました。詳しくは後述します。このようなシステムでの運用に最初に成功したのは、Ethereum仮想マシン（EVM）です。
また、Bitcoinスクリプトも仮想マシンとみなすことができます。Bitcoinネットワークの計算コンポーネントで、ノードがUTXOを検証し、取引を実行するために使用するからです。しかし、Bitcoinスクリプトは非常に限定的で、EVMのような複雑なロジックを実行することはできません。
■The Ethereum Virtual Machine (EVM)
EVMは、Ethereumノードで実行される特定のコンピューターシステムをエミュレートするソフトウェアです。EVMの主な目的は、Ethereumネットワークの世界の状態を計算し、スマートコントラクトを実行することです。EVMの目新しさは2つあります。
・EVMは、スマートコントラクトのやや複雑な計算ロジックの実行を含む、世界状態の分散型計算を可能にする
・EVMは、分散型ブロックチェーンネットワーク（スマートコントラクト）上で自律的かつ信頼性の高いコード実行を可能にします
ネットワークが「EVM互換性」を主張する場合、そのネットワークがEthereum仮想マシン向けに書かれたスマートコントラクトをデプロイし実行できることを意味します。
EVMは最も人気のある仮想マシンであり、Web3におけるスマートコントラクト計算のデファクトスタンダードとなっています。EVMとの互換性があることで、新しいネットワークはプロジェクトのネットワークへの移植が容易になり、エコシステムを起動させることができます。
また、この標準化により、両方のネットワークが同じコードを実行できるため、ネットワーク間でのトークンのブリッジが容易になります。
EVMのアーキテクチャに関する深堀りについては、TakenobuT.によるこのウォークスルーを参照してください。（2022年9月15日にEthereumのエコシステムがPoWからPoSに移行する「the Merge」以降、このプレゼンテーションのPoWに関する部分は古くなってしまいました。）
●スマートコントラクト
スマートコントラクトは、分散型ネットワーク上に格納されたプログラムで、特定の条件が満たされたときにVMが自律的に実行することができます。
これらの条件は、ネットワーク上で特定のイベントが発生したとき、またはユーザーがスマートコントラクトと対話したときに起動するあらゆる条件を指すことができます。
スマートコントラクトの複雑な計算能力により、ERC-20トークンやNFT（non-fungible token）も作成することができます。スマートコントラクトとEVMは、ブロックチェーンや暗号を越えて、Web3のコンセプトを実現するために業界を後押ししました。
これらの技術革新の組み合わせが、Web3の広大なdAppエコシステムを生み出しました。
dAppは分散型アプリケーションで、スマートコントラクトと、ブロックチェーンネットワークとの対話を可能にする簡単にアクセスできるウェブベースのフロントエンドを組み合わせて使用することもよくあります。
dAppのスマートコントラクトはノードを介して直接アクセスすることもできますが、ウェブベースのフロントエンドはアクセスの障壁を大きく軽減します。今日、最も有名なdAppはおそらくUniswapでしょう。
■Solidity、Rust、Bitcoin Script
Solidity は、Ethereumブロックチェーン上のスマートコントラクトで最も使用されているプログラミング言語です。開発者はSolidityでスマートコントラクトをコーディングし、それをバイトコードにコンパイルし、バイトコードをネットワークにデプロイします。
Solidityは、C++、Python、JavaScriptをベースとしたオブジェクト指向・静的型付けプログラミング言語です。
Rustは、Solana、Polkadot、NEARブロックチェーン上のスマートコントラクトのための最も一般的なプログラミング言語の1つです。Rustは低レベルの静的型付けプログラミング言語で、そのスピード、効率性、設計のベストプラクティスで知られています。若い言語ではありますが、2020年と2021年に連続してStackOverflowで最も愛されているプログラミング言語に選ばれています。Solidityと同様に、コードをコンパイルし、バイトコードを各種ネットワークにデプロイします。
ブロックチェーンは、ネットワークが読んで解釈できるバイトコードにコンパイルできるコードであれば、さまざまなプログラミング言語を受け入れています。
これはBitcoinにも言えることで、Bitcoinスクリプトが主要なスクリプト言語となっています。Bitcoin ScriptとSolidity/Rustの違いは、Bitcoin Scriptが実際にはプログラミング言語ではなく、トランザクションに使用されるスクリプトシステムであることです。
Bitcoinでは、スクリプトは各トランザクションで記録される命令のリストであり、転送されたBitcoinを使いたい次の人がどのようにアクセスできるかを記述しています。UTXOは未使用の取引出力であるため、すべての出力には、その出力が別の取引の入力になることを許可されるために満たされる必要がある要件が付加される可能性があることを忘れないでください。
■チューリング完全性
Solidity/Rust と Bitcoin Script の違いは、チューリング完全性という角度から見ると、より明確になります。チューリング完全性とは、無限の時間と計算資源が与えられたとき、問題がコード化または論理的に構成できる限り、あらゆる問題を計算できる抽象的な機械（チューリングマシン）の考え方を指します。
より複雑な論理問題では、条件文やループを使用する必要があり、完全なプログラミング言語であるSolidityやRustはこれをサポートしています。しかし、Bitcoin Scriptはこれらに対応していません。これは、Bitcoinが複雑な計算を許さず、取引のアイデアの周りだけで動作する、かなり単純な命令セットに依存しているためです。（スマートコントラクトはありません）
このため、Bitcoinはエラーが起こりにくく、間違いなく安全ですが、その分、プログラマビリティが制限されます。
Ethereum, Solana、Polkadotは、準チューリング完全と考えることができます。SolidityとRustのおかげで複雑な計算が可能で、理論的には十分な時間があればどんな論理的問題も解くことができます。しかし、ガス代によって稼働を制限されています。
ガス代とは、ネットワークがあらゆる計算タスクの実行に対して請求する料金のことです。時間と計算資源は理論上無限ですが、ネイティブネットワークトークンの量は無限ではありません。
したがって、理論的にはチューリング完全なネットワークであっても、実際にはせいぜい準チューリング完全と見なすしかありません。
チューリング完全とチューリング非完全の区別は、ネットワークの能力とネットワーク上に構築できるものをより良く理解するために重要です。チューリング機械とチューリング完全性にはニュアンスの違いがあり、興味のある方はこちらで詳細を読むことができます。
■EIPからERCへ
ERC（Ethereum Request for Comment）とは、Ethereumのブロックチェーンで使用される技術的なコーディング規格を指します。
ERCは、Ethereumのスマートコントラクトが従わなければならない多くのルールやアクション、そしてそれらをどのように実装するかを指示することができます。
また、ERCはすでにEthereumのドキュメントに含まれる、開発者が使用することに同意したスタンダードです。ERCがERCとしてスタンダードになる前に、それはEIP（Ethereum Improvement Proposal）として提案がなされます。
EIPは基本的に非常に詳細なフォーラムの投稿で、ユーザーはEthereumのブロックチェーンとエコシステムの変更について議論、討論、投票することができます。
このシステムは、ネットワーク (例:Bitcoinは BIP を使用 -Bitcoin改善提案)からdApps(例: AAVE は AIPS を使用する - AAVE 改善提案)まで、Web3エコシステム全体で非常に広く使用されています。
■ERC Token Standards
ERCベースのトークンはEthereumネットワーク上に存在しますが、EthereumネットワークのネイティブトークンであるEthereumトークンとは技術的に区別されます。
Ethereumトークンがネットワークの一部として定義され、ガス料金の形で取引やスマートコントラクトの実行に支払うためのネットワークの基礎となる「貨幣」であるのに対し、ERCベースのトークンはスマートコントラクトで定義されています。
ERC規格のスマートコントラクトは、トークンのすべてのパラメータとすべての動作を定義し、etherscan.ioまたはEVM互換ネットワーク用のその他のブロックエクスプローラを使用してオンラインで確認することが可能です。
ブロックエクスプローラーとは、ブロックチェーンに保存されているリアルタイムおよび履歴情報を閲覧できるツールです。この標準化の結果、ERCベースのトークンの動作は予測可能になり、dAppsやその他のスマートコントラクトは、これらの標準を使用するあらゆるスマートコントラクトと相互作用することができるようになりました。
ここからは、ERC-20、ERC-721、ERC-1155、ERC-4626の各規格について説明します。最初の 3 つは、ブロックチェーン上に存在する代替可能なデジタル資産と代替不可能なデジタル資産の作成に関連しており、ERC-4626 は、ERC-20 に適用される利回りを伴う機能を標準化しています。
ERC-20トークン（Fungible Token）
ERC-20は、Fungible Tokenの規格です。Fungibilityとは、ある資産が他の同じ資産と交換可能であり、両資産が互いに区別されない性質を指します。例えば、1米ドル紙幣は、他の1米ドル紙幣と交換できるため、Fungibleである。
ERC-20規格は、EVM互換ネットワーク上で代替可能なトークンを作成することを可能にします。The Curve token（CRV）、the Uniswap token（UNI）、AAVEトークン（AAVE）などは、Fungibleトークンの例ですが、米ドルに固定されたUSDTやUSDCなど、不換紙幣のデジタル表現もERC-20に含まれています。
□ERC-721 Tokens (Non-Fungible Tokens)
ERC-721 標準は Non-fungible トークン (NFT) を定義しています。NFTのユニークな点はその名前にあります。トークンはnon-fungibleであり、すべてのトークンがユニークであることを意味します。
NFTのコンテンツは、プロフィール写真から不動産の権利書、その他の証明書まで、作成者が望むものであれば何でも可能であるため、NFTは非常に可能性を秘めています。
NFTは、あらゆる物理的資産やユニークなデジタル資産のデジタル所有権を公に検証することを可能にします。
人気のあるNFTには、Cryptopunks、Bored Ape Yacht Club、Ethereum Name Service (ENS)があります。
□ERC-1155 (Multi-Tokens)
ERC-1155はいわゆる「マルチトークン」で、ERC-20（Fungibleトークン）とERC-721（Non-Fungibleトークン）の両方の機能を兼ね備えています。つまり、複数の「ユニークな」Fungibleアセット（例えば、ゲーム内の剣（ユニーク）、100個供給（Fungible））を通じて新しいユースケースを可能にするほか、1つのスマートコントラクト内で複数のトークンタイプを管理することも可能だということです。
これらの機能を1つのスマートコントラクトに集約することで、スマートコントラクトがEVM内で使用する容量が効率化されます。また、複数のトークンを1つのスマートコントラクトで管理できるため、大規模で複雑なプロジェクトでも簡素化できます。
人気のあるERC-1155には、ENJIN NFTがあり、ERC-1155を使用して、少数のブロックチェーンベースのゲームにわたってゲーム内資産を追跡するほか、1つの契約の一部として大量のユニークな資産のセットを定期的に作成する必要のあるチケット販売アプリケーションも含まれています。
ERC-1155を使用するプロジェクトの例としては、The Sandbox Metaverse、Fanz、Azure Heroesなどがあります。
□ERC-4626 (The Vault Standard)
ERC-4626は、トークンVaultを標準化するものです。Vaultとは、ERC-20トークンの預託を受け、預託者に別のトークンの報酬（イールド）を提供するイールドベアリング・スマートコントラクトのことです。基本的にはマルチシグの資産管理スマートコントラクトで、預け入れに対する報酬の一形態としてトークンを生成し、後で最初にVaultに預け入れたトークンと交換することができます。
例えば、xSushiはSUSHIトークン（SushiSwap dAppのガバナンストークン）と交換できるイールドベアリングトークンで、本質的にはSushi DeFiプロトコルにおけるイールド生成アクティビティのユーザーのシェアを表しています。
このトークン標準により、開発者はすべてのトークンを手動で統合し、特定の設計上の決定を考慮することなく、あらゆるERC-20トークンを受け入れることができます。これにより、資産の損失につながるコーディングエラーのリスクを軽減することができます。
Yearn V3はERC-4626標準を使用する最初の主要なプロトコルであり、BalancerやRari Capitalなどのプロトコルも同様にこの標準を実装し始めています。
●Blockchains vs. Directed Acyclic Graphs (DAGs)
Directed Acyclic Graphs (DAG)は、データを構造化する異なるアプローチであり、ブロックチェーンのShared Ledger(共有台帳)構造の代替アプローチとして使用するプロジェクトもあります。ブロックチェーンにはブロックに含まれるトランザクションがあり、ブロックは時系列で検証され連鎖します。ブロックチェーンはネットワーク上の全ノードに複製されます。
DAGでは、トランザクションは1つずつ検証され、すべてのトランザクションは次のトランザクションにリンクしています。ある取引を検証するためには、ネットワークによって指示されたさらに2つの取引も検証されなければいけません。
これは、簡単に拡張でき、トランザクションの並列計算を可能にし、スループット速度を大幅に向上させることができるウェブのような構造をもたらす。トランザクションの検証は非常に簡単であるため、このシステムにおいて採掘業者の役割は非常に小さいです。
ネットワークと対話するどのユーザーも他のユーザーのトランザクションを検証することができ、これにより取引コストが大幅に削減されます。
Directed Acyclic Graphという名称が、その構造をよく表していると考えています。具体的には
・Directed：データ構造は1つの方向にしか移動できない（新しいデータを追加する）
・Acyclic：データポイント間の有向パスを移動するとき、前のデータポイントにぶつかることはありえない（非循環的）
・Graph：ノード/頂点とエッジ（ノード間の接続）で構成される非線形データ構造
この構造はトランザクションのスループット、検証速度、トランザクションコストに関して利点をもたらしますが、DAGは全く異なる課題に直面しています。理論的にはこのシステムは強力な分散化を可能にしますが、トランザクションの減少は理論的にはネットワークセキュリティの減少につながってしまします。
トランザクションの減少はランダムなバリデータの減少を意味し、単一のバリデータまたはバリデータのセットがトランザクションの大部分を制御する可能性を増大させてしまいます。トランザクションの数が少なければランダムバリデーターも少なくなり、単一のバリデーターまたはバリデーターのセットがトランザクションの大部分を支配する可能性が高くなリます。
上記の課題に対処するため、DAGベースのネットワークでは、検証対象のトランザクションをルーティングする中央コーディネーターの実装、高い権限を持つ‘witness(証人)’バリデータの制御、または検証ネットワークのプライベート化といった集中型のソリューションに移行しています。
これらの課題にもかかわらず、DAGネットワークはWeb3のエコシステムにおいて重要な局所的なニーズを満たしています。重いトランザクション負荷を管理できる、やや集中型の高スループットネットワークで、Web3の主流採用が進むにつれてより多くのユースケースを見つけることができると考えています。
●Monolithic vs. Modular Blockchains
分散型ネットワークは、様々なコンポーネントが相互運用することで、信頼性の高い不変のネットワークを構築する複雑なシステムです。Bitcoin、Ethereum、Solana、Polkadot、NEARなどのネットワークはすべてモノリシックブロックチェーンと考えられており、これらはすべて「一片から形成された」ネットワークで、あるコンポーネントに変更があるとネットワーク全体の更新が必要になります。
モジュラー型ブロックチェーンは、これらの様々な構成要素を取り込み、他の構成要素と交換できるようにしたものです。モジュール型ブロックチェーンシステムの様々な構成要素は以下の通りです。
・Execution layer：取引実行とスマートコントラクト
・Settlement layer：トランザクションの検証、トランザクションの決済
・Consensus layer：コンセンサスメカニズム
・Data availability：Shared Ledger(共有台帳)
出典：Celestia Web サイト
システムを複数の構成要素に分割することで、各構成要素ごとに最適化を行うことができ、各構成要素の効率や安全性を高めることができます。本連載の次回で取り上げるLayer2は、モジュール化の第一歩と考えることができます。Layer2は実行レイヤーをオフロードし、トランザクションやスマートコントラクトを別のネットワークで実行し、その結果をLayer1のモノリシックネットワークにフィードバックして、決済、合意、Shared Ledger(共有台帳)を管理することができます。
モジュール化には多くの利点がありますが、モジュール化されたシステムは、その最も弱いリンクによってのみ強くなるのです。モジュール化されたコンポーネントを持つことで、個々のコンポーネントがより容易に狙われる可能性があります。
さらに、ネットワークにモジュール性を持たせることで、技術的な観点からネットワークを正しく機能させるという点でも、ネットワークのネイティブ・トークンの価値の観点から見ても、新たなレベルの複雑さが生じます。決済レイヤーを別のトークンに置き換えることができれば、そもそもネットワークがトークンの存在を正当化することは困難になります。
こうした課題はあるものの、モジュール型ブロックチェーンのコンセプトは、新しいプロジェクトや新技術の開発にエキサイティングな方向性を提供し、Web3エコシステムの拡張と成長に貢献する可能性があります。人気のあるモジュール型ブロックチェーン・プロジェクトには、CelestiaやCosmosがあります。
●まとめ – レイヤ 1 ネットワーク
Web3は、ブロックチェーン、暗号通貨とその上に構築されたエコシステム、および関連技術を組み合わせた広大な概念です。
Bitcoinは分散型ブロックチェーン技術を普及させたレイヤー1ネットワークであり、Ethereumはスマートコントラクトを可能にする準チューリング完全な計算機能を提供したネットワークです。また、Ethereumは、スマートコントラクトを可能にする準チューリング完全計算機能を提供するネットワークです。
不滅性とデータの永続性を可能にしたのは、以前のブロックからのデータをハッシュ化することでデータブロックを連結するというアイデアと、すべての保存データのコピーを多くのノードに分散させることでした。ネットワーク上にノードが1つしかない場合、ネットワークは本質的に中央集権的であり、データの改ざんや削除、ノードによるアクセス制限といった中央集権的な問題に直面することになります。
また、基盤となるデータ構造とは別に、ネットワーク上のノードが、提供されるデータが正しいかどうかをどのように知るかという問題もあります。これは「ビザンチン将軍問題」としてまとめられています。Bitcoinは、ブロックの検証に必要な検証作業を行ったことを証明するために、ネットワーク上のノードが計算量の多い暗号パズルを解くことを要求するProof-of-Workコンセンサスアルゴリズムによってこの問題を解決しています。Proof-of-Stakeのような代替コンセンサスアルゴリズムも存在し、こちらは必要なエネルギーがはるかに少なく、環境にも良いとされています。
本稿執筆時点で最も人気のあるブロックチェーン・ネットワークであるBitcoinとEthereumは、大きく異なる簿記モデルを使用しています。BitcoinはUTXOモデル、Ethereumはアカウントモデルを使用しています。UTXOモデルは、すべてのUTXOが取引の受領となる「"verification system”(検証システム)」と考えることができます。アカウントモデルは、ブロックチェーンに新しいブロックが追加されるたびに更新される口座と残高のデータベースに近いものです。
Ethereumのコンピューティングコンポーネントは「“Ethereum Virtual Machine(Ethereum仮想マシン)」と呼ばれ、スマートコントラクトの実行を可能にします。スマートコントラクトは、分散型ブロックチェーンネットワークに保存され、プログラム可能なトリガー基準に基づいて自律的に実行できるアプリケーションです。どのブロックチェーンを使用しているかによって、スマートコントラクトはSolidityやRustなどのプログラミング言語で書かれている場合があります。
スマートコントラクト間の相互運用性を高めるために、スマートコントラクトの標準化が必要でした。ERCは、Ethereumのドキュメントで固められたコーディングの標準であり、「それを実現した」EIPです。
EIPはEthereumエコシステムの誰でも作ることができる提案であり、誰でも閲覧、議論、投票が可能です。EIPが投票されると、提案された変更がネットワークに適用されます。ERCトークンには、ERC-20（fungible token）、ERC-721（non-fungible token、「NFT」）、ERC-1155（multi-tokens）、ERC-4626（vault standard）の4つの規格があります。
ブロックチェーンはWeb3の分散型ネットワークで最も人気のあるledger format(台帳形式)ですが、既存の構造を特定のユースケースに合わせて調整することで、代替形式が登場しています。
directed acyclic graphs（DAG）はそのような代替構造の一例で、フルブロックの代わりにトランザクションの検証に依存しています。モジュラー・ネットワークは、既存の構造を見直す必要があるという考え方の延長線上にある。モジュラー・ネットワークは、分散型ネットワークを、それぞれが個別に最適化できる異なる機能層に分割することを目的としています。
【最後に】
Web3の基礎知識をマスターするシリーズの第一弾はこれで終わりです。この記事を楽しんでいただけたなら、ぜひシェアをお願いします。この記事についてのフィードバックや内容について議論したい場合は、Twitterの@0xPhillanまでご連絡ください。
また、Web3edgeのニュースレターを購読し、Twitterで@Web3edge_ioをフォローしていただくと、後編をいち早くお届けします。
【この記事に関して】
翻訳の間違いや、感想などあれば、下記のTwitterアカウントまで、気軽にご連絡いただければと思います。