用語集:Web3技術定義の基準点
地理的境界のないWeb3の世界において、情報は常に断片化され、時に作為的な解釈を伴って流通します。Crypto Verseの「用語集」は、こうしたノイズを排し、公式ドキュメント、スマートコントラクトの仕様、およびホワイトペーパーといった一次情報を基盤とし、客観的な「技術的事実(Fact)」を抽出・整理したものです。
私たちは、主観的な推奨や市場の憶測を排除し、検証可能な「事実」という土台を提示することに重きを置いています。本セクションが、読者の皆様が自律的に判断し、確かな根拠を持ってデジタル空間を航海するための「羅針盤」となることを目指しています。
目次
- 1 MetaMask
- 2 アップグレード権限(Admin Key)
- 3 プロキシパターン(Proxy Pattern)
- 4 秘密鍵(Private Key)
- 5 シードフレーズ(Seed Phrase)
- 6 DeFi(Decentralized Finance)
- 7 スマートコントラクト(Smart Contract)
- 8 DAO(Decentralized Autonomous Organization:分散型自律組織)
- 9 直接投票(Direct Voting)
- 10 委任型ガバナンス(Delegated Governance)
- 11 ハイブリッドガバナンス(Hybrid Governance)
- 12 MakerDAO
- 13 ガス代(Gas Fee)
- 14 Layer 1(レイヤー1)
- 15 Layer 2(レイヤー2)
- 16 ビットコイン(Bitcoin)
- 17 BTC
- 18 イーサリアム(Ethereum)
- 19 ETH
- 20 Solana(ソラナ)
- 21 プロトコル(Protocol)
- 22 Arbitrum
- 23 Optimism
- 24 ブロックチェーン(Blockchain)
- 25 Solidity
- 26 Optimistic Rollup
- 27 ZK Rollup(Zero-Knowledge Rollup)
- 28 フラッシュローン(Flash Loan)
- 29 アカウント抽象化(ERC-4337)
- 30 UXの抽象化(ERC-4337)
- 31 インパーマネント・ロス(Impermanent Loss)
- 32 ミームコイン(Meme Coin)
- 33 Virtuals Protocol
- 34 ラグプル(Rug Pull)
MetaMask
定義:
MetaMaskは、暗号資産の管理およびブロックチェーンアプリケーション(dApps)への接続を可能にするセルフカストディ型ウォレットソフトウェアである。主にブラウザ拡張機能およびモバイルアプリとして提供されている。
事実:
MetaMaskは2016年に公開され、Ethereum系ブロックチェーンとの接続を主目的として開発された。秘密鍵およびシードフレーズはユーザー端末内で管理され、運営企業が直接保管する設計ではない。EthereumおよびEVM互換チェーンに対応し、トークン送受信、ガス代設定、dAppsとの署名連携機能を提供する。利用時には秘密鍵やシードフレーズの自己管理が前提となる。フィッシング詐欺や不正サイト接続による資産流出事例が報告されているため、利用者側のセキュリティ対策が重要である。
参照ソース:
MetaMask公式サイト
https://metamask.io/
MetaMask公式ドキュメント
https://docs.metamask.io/
※ 利用者が秘密鍵やシードフレーズを紛失した場合、資産の回復はできない。
アップグレード権限(Admin Key)
定義:
アップグレード権限(Admin Key)とは、プロキシパターンを用いてデプロイされたスマートコントラクトにおいて、実装(ロジック)コントラクトの参照先アドレスを変更できる管理者権限を指す。これにより、既存コントラクトの動作仕様を後から変更することが可能となる。
事実:
アップグレード権限は、主にEthereum 上で採用されるUpgradeable Contract設計に存在する。一般的な実装はProxyコントラクトとImplementationコントラクトを分離し、delegatecall を通じて処理を委譲する構造を取る。管理者は upgradeTo などの関数を通じて実装アドレスを書き換えることができる。
関連する技術標準には以下がある。
- EIP-1967(Proxyのストレージスロット標準)
- EIP-1822(UUPS: Universal Upgradeable Proxy Standard)
Upgradeable設計は、バグ修正や機能追加を可能にする一方で、管理者秘密鍵の漏洩、権限集中、監査後のロジック変更といった構造的リスクを内包する。アップグレード可否や管理者アドレスの存在は、Etherscan 等のブロックチェーンエクスプローラー上で確認可能である。
参照ソース:
Ethereum Improvement Proposal 1967
https://eips.ethereum.org/EIPS/eip-1967
Ethereum Improvement Proposal 1822
https://eips.ethereum.org/EIPS/eip-1822
OpenZeppelin Contracts Documentation
https://docs.openzeppelin.com/contracts/
※ アップグレード設計の有無はコントラクトごとに異なる。実装仕様はプロジェクト単位で確認する必要がある。
プロキシパターン(Proxy Pattern)
定義:
プロキシパターン(Proxy Pattern)とは、スマートコントラクトをプロキシ構造で実装し、実行ロジックを別コントラクトへ委譲することで、後から実装部分を差し替え可能にする設計手法を指す。プロキシ自体は固定アドレスを維持し、内部参照先のみを変更する。
事実:
Proxy Patternは主にEthereum 上で広く採用されるUpgradeable Contractの設計方式である。プロキシコントラクトは delegatecall を用いて実装(Implementation)コントラクトへ処理を委譲する。利用者は常に同一アドレス(Proxy)と対話するため、ロジック変更後もアドレスは維持される。
代表的な標準・設計は以下。
- EIP-1967(Proxy Storage Slot Standard)
- EIP-1822(UUPS)
- Transparent Proxy Pattern
Proxy Patternでは、実装アドレスを変更する管理者権限が存在する場合がある。この権限は、バグ修正や機能追加を可能にする一方、管理者鍵の漏洩や不正なロジック差し替えといった構造的リスクを内包する。
Upgradeable構造の有無、管理者アドレスの存在、upgradeTo 関数の実装状況などは、Etherscan 等のブロックチェーンエクスプローラー上で確認可能である。
参照ソース:
Ethereum Improvement Proposal 1967
https://eips.ethereum.org/EIPS/eip-1967
Ethereum Improvement Proposal 1822
https://eips.ethereum.org/EIPS/eip-1822
OpenZeppelin Contracts Documentation
https://docs.openzeppelin.com/contracts/
※ Proxy Patternの採用有無および管理者権限の範囲は、各プロジェクトの実装仕様によって異なる。
秘密鍵(Private Key)
定義:
秘密鍵とは、暗号資産ウォレットやブロックチェーンアカウントの所有権を証明し、トランザクション署名や資産移転を行うために用いられる非公開の暗号鍵である。対応する公開鍵(Public Key)とペアで機能し、秘密鍵を保持する者だけが資産を操作できる。
事実:
秘密鍵はランダムに生成され、他者に知られると資産が不正に移転されるリスクがあるため、安全に保管する必要がある。ウォレットによっては秘密鍵をユーザーが管理する「セルフカストディ型」と、サービス側が管理する「カストディ型」が存在する。暗号化技術に基づき、秘密鍵から対応する公開鍵やアドレスは生成可能であるが、逆に公開情報から秘密鍵を導くことはほぼ不可能とされる。
参照ソース:
Bitcoin Whitepaper(2008年)
著者:Satoshi Nakamoto
Ethereum公式ドキュメント(アカウントと鍵管理)
https://ethereum.org/en/developers/docs/accounts/
※ 秘密鍵を紛失した場合、対応する暗号資産は回復できない。
シードフレーズ(Seed Phrase)
定義:
シードフレーズとは、暗号資産ウォレットの秘密鍵を生成・復元するための一連の単語列である。通常12語または24語で構成され、ウォレット作成時にランダム生成される。シードフレーズを保持することで、紛失したウォレットや秘密鍵を復元可能である。
事実:
シードフレーズはウォレットのバックアップとして機能し、第三者に知られると資産が不正にアクセスされるリスクがあるため、安全な保管が必須である。ウォレットはシードフレーズから秘密鍵を導出し、対応する公開鍵およびアドレスを生成する。シードフレーズはヒューマンリーダブル形式で提供されるが、暗号化技術により秘密鍵と同等の権限を持つ。
参照ソース:
BIP-39: Mnemonic code for generating deterministic keys(2013年)
https://github.com/bitcoin/bips/blob/master/bip-0039.mediawiki
Ethereum公式ドキュメント(ウォレット管理)
https://ethereum.org/en/developers/docs/accounts/
※ シードフレーズを紛失または漏洩した場合、資産は回復不能または不正に移転される。
DeFi(Decentralized Finance)
定義:
DeFiとは、ブロックチェーン上で提供される分散型金融サービスの総称である。銀行や証券会社などの中央管理主体を介さず、スマートコントラクトを用いて貸借、取引、決済、資産運用などを実行する仕組みを指す。
事実:
DeFiは主にEthereum 上で発展し、貸付プロトコル、分散型取引所、ステーブルコインなど多様な金融機能が構築されている。利用者はウォレットを通じて直接プロトコルと接続し、スマートコントラクトにより取引が自動実行される。資産は原則としてユーザー自身が管理するセルフカストディ型である。価格変動リスク、スマートコントラクトの脆弱性、流動性不足などのリスクが存在する。規制上の位置付けは国・地域ごとに異なる。
参照ソース:
Ethereum公式ドキュメント(DeFi解説)
https://ethereum.org/en/defi/
Bank for International Settlements, “Decentralised finance: on blockchain- and smart contract-based financial markets”(2021年)
※ 市場規模およびプロトコル仕様は時間とともに変動する。
スマートコントラクト(Smart Contract)
定義:
スマートコントラクトとは、ブロックチェーン上で自動的に実行されるプログラムであり、契約条件やルールをコード化して管理する仕組みである。事前に定義された条件が満たされると、第三者を介さずに資産の移転や処理が自動で実行される。
事実:
スマートコントラクトはEthereumなどのスマートコントラクト対応ブロックチェーン上で稼働する。コードはブロックチェーン上に保存され改ざんが困難であり、透明性が確保される。実行にはガス代が必要であり、条件に従ったトランザクション処理が自動化される。設計や実装によってはバグや脆弱性により資産の不正流出リスクがあるため、監査やテストが重要とされる。
参照ソース:
Ethereum Whitepaper(2013年)
著者:Vitalik Buterin
Ethereum公式ドキュメント(Smart Contract入門)
https://ethereum.org/en/developers/docs/smart-contracts/
※ スマートコントラクトの挙動はコード通りに自動化されるため、設計ミスは実行後に修正困難である。
DAO(Decentralized Autonomous Organization:分散型自律組織)
定義:
DAOは、ブロックチェーン上でスマートコントラクトにより運営される分散型組織である。中央管理者を置かず、トークン保有者による提案や投票を通じて、資金管理やプロトコルの主要パラメータを決定する自律的な仕組みを持つ。
事実:
DAOでは、ネイティブトークン保有者が提案の提出や投票を行い、資金運用やプロジェクト実行に関する意思決定を行う。ガバナンスはオンチェーンまたはオフチェーンで実施され、直接投票、委任型、ハイブリッド型などの意思決定モデルが存在する。2026年時点、多くのDAOは理念上の「完全分散型」よりも、効率性や専門性確保のためハイブリッド型や委任型ガバナンスを採用している。プロトコルごとに担保管理、資金配分、自動清算ルールなどの設計が異なる。
参照ソース:
Ethereum Whitepaper(2013年)
著者:Vitalik Buterin
「DAOs, DACs, DAs and More: An Incomplete Terminology Guide」(2014年)
著者:Vitalik Buterin
2016年 The DAO 事件関連資料
※ 法的定義は国・地域ごとに異なり、統一された国際基準は存在しない。
直接投票(Direct Voting)
定義:
直接投票とは、DAOや分散型プロトコルにおいて、トークン保有者が自ら提案に対して直接投票し意思決定に参加するガバナンスモデルを指す。中間の代表者や委任者を介さず、各参加者の意思がそのまま反映される仕組みである。
事実:
直接投票では、全ての投票権を持つ参加者が提案に直接投票を行うため、意思決定の透明性が高い。プロトコルにより、オンチェーンまたはオフチェーンで投票が実施される。2026年時点の多くのDAOでは、完全分散型の理念に基づく直接投票だけでは効率性や意思決定速度の面で課題があることから、委任型やハイブリッド型ガバナンスと組み合わせる場合もある。
参照ソース:
「DAOs, DACs, DAs and More: An Incomplete Terminology Guide」(2014年)
著者:Vitalik Buterin
MAO DAO公式ドキュメント
https://mao-dao.org/docs
※ 投票の手続きや実行方法はプロトコルごとに異なる。
委任型ガバナンス(Delegated Governance)
定義:
委任型ガバナンスとは、DAOや分散型プロトコルにおいて、トークン保有者が自ら直接投票する代わりに、信任した代表者や専門チームに投票権を委任して意思決定を行うガバナンスモデルを指す。参加者の負担軽減と効率的な意思決定を目的とする。
事実:
委任型ガバナンスでは、トークン保有者は代表者に自分の投票権を預け、代表者が提案への投票を実施する。これにより、全参加者が個別に投票する場合に比べ、意思決定の迅速化や投票参加率の向上が期待される。多くの2026年時点のDAOは完全分散型ガバナンスよりも、委任型やハイブリッド型を採用しており、権限や責任の分配はプロトコルごとに異なる。
参照ソース:
「DAOs, DACs, DAs and More: An Incomplete Terminology Guide」(2014年)
著者:Vitalik Buterin
MAO DAO公式ドキュメント
https://mao-dao.org/docs
※ 委任の範囲や撤回可能性など、具体的な設計は各プロトコルで異なる。
ハイブリッドガバナンス(Hybrid Governance)
定義:
ハイブリッドガバナンスとは、DAOや分散型プロトコルにおいて、完全分散型意思決定と専門チームによる集中管理の仕組みを組み合わせたガバナンスモデルを指す。中央管理者の権限を最小化しつつ、効率的な運営や専門性を確保する設計である。
事実:
ハイブリッドガバナンスでは、一般参加者によるオンチェーン投票や提案と、コア開発チームや委任された意思決定主体による運営が並行して行われる。これにより、重要なプロトコル更新や緊急対応が迅速に行える一方、完全分散型ガバナンスよりも参加者間の意思決定権が偏在する場合がある。多くの2026年時点のDAOは理念上の完全分散型よりも、効率性や専門性確保のためハイブリッド型を採用している。
参照ソース:
「DAOs, DACs, DAs and More: An Incomplete Terminology Guide」(2014年)
著者:Vitalik Buterin
MAO DAO公式ドキュメント
https://mao-dao.org/docs
※ プロトコルごとに設計や権限分配の具体的方式は異なる。
MakerDAO
定義:
MakerDAOは、分散型ステーブルコインDAIを発行・管理する分散型自律組織である。スマートコントラクトにより担保管理と発行を行い、ガバナンストークン保有者の投票によってプロトコルの主要パラメータが決定される。
事実:
MakerDAOは2017年にEthereum上で稼働を開始した。DAIは暗号資産担保型モデルを採用し、利用者は担保をロックすることでDAIを発行できる。担保価値が清算閾値を下回ると自動清算が行われる。ガバナンスはMKRトークン保有者によるオンチェーン投票で実施される。2019年にはSingle-Collateral DAIからMulti-Collateral DAIへ移行している。
参照ソース:
MakerDAO Whitepaper
https://makerdao.com/whitepaper/
MakerDAO公式ドキュメント
https://docs.makerdao.com/
Ethereum公式ドキュメント
https://ethereum.org/
※ 担保構成およびガバナンス設計はアップデートにより変更される場合がある。
ガス代(Gas Fee)
定義:
ガス代とは、ブロックチェーン上でトランザクションやスマートコントラクトを実行する際に支払う手数料である。計算資源の消費量に基づいて算定され、ネットワークの検証者に対する報酬として支払われる。
事実:
ガス代は通常、そのチェーンのネイティブトークンで支払われる。EthereumではETHで支払われる。手数料はGas LimitとGas Priceで決まり、2021年のLondon Hard Fork以降はEIP-1559によりBase FeeとPriority Feeの構造に再設計された。Base Feeはネットワーク需要に応じ自動調整され支払われたETHはバーンされ、Priority Feeはバリデーターへの追加報酬として支払われる。ネットワーク混雑時にはBase Feeが上昇し、トランザクションコストも高騰する。
参照ソース:
Ethereum Improvement Proposal 1559
https://eips.ethereum.org/EIPS/eip-1559
Ethereum公式ドキュメント(Gas解説)
https://ethereum.org/en/developers/docs/gas/
※ 手数料水準はネットワーク状況により変動する。
Layer 1(レイヤー1)
定義:
Layer 1とは、独自のコンセンサスアルゴリズムとバリデーション機構を備えた基盤ブロックチェーンを指す。トランザクションの記録、検証、確定を自律的に行うプロトコル層である。
事実:
Layer 1はネットワークのセキュリティ、分散性、整合性を直接担う。代表的なLayer 1としてBTC、Ethereum、Solanaがある。ブロック生成、手数料設計、ネイティブトークン発行などの基本仕様をプロトコルレベルで規定する。処理能力や手数料の制約が課題となる場合があり、拡張策としてLayer 2が構築されることがある。
参照ソース:
Bitcoin Whitepaper(2008年)
Ethereum公式ドキュメント
Solana Whitepaper(2017年)
※ 性能や設計思想は各チェーンにより異なる。
Layer 2(レイヤー2)
定義:
Layer 2とは、既存のレイヤー1ブロックチェーン上に構築され、トランザクション処理を補完・拡張するためのスケーリング技術群を指す。基盤チェーンのセキュリティを活用しつつ、処理能力向上や手数料削減を目的とする。
事実:
Layer 2はトランザクションをオフチェーンまたは別レイヤーで集約処理し、結果のみをレイヤー1に記録する。代表的な方式にはロールアップ(Optimistic Rollup、ZK Rollup)やステートチャネルがある。Ethereum上ではスケーリング戦略の中核として活用されており、代表例としてArbitrumやOptimismが挙げられる。Layer 2はレイヤー1に最終的なデータ確定やセキュリティを依存する設計である。
参照ソース:
Ethereum公式ドキュメント(Layer 2解説)
https://ethereum.org/en/layer-2/
各Layer 2プロジェクト公式ドキュメント
※ セキュリティモデルやデータ可用性設計は方式ごとに異なる。
ビットコイン(Bitcoin)
定義:
ビットコインは、分散型ネットワーク上で発行・管理される暗号資産(デジタル通貨)。中央発行主体を持たず、ピアツーピア方式で価値移転を行うことを目的として設計された。ネイティブトークンはBTC。
事実:
ビットコインは2009年に稼働を開始した。コンセンサスアルゴリズムにはProof of Work(PoW)が採用されている。発行上限は2,100万BTCとプロトコル上で定められている。新規発行量は約4年ごとの半減期(Halving)により段階的に減少する設計である。トランザクション手数料はBTCで支払われ、マイナーへの報酬として分配される。標準機能としてのスマートコントラクト実行環境は限定的である。
参照ソース:
Bitcoin: A Peer-to-Peer Electronic Cash System(2008年)
著者:Satoshi Nakamoto
Bitcoin公式サイト
https://bitcoin.org/
※ 発行スケジュールおよび手数料水準はネットワーク状況により変動する。
BTC
定義: BTCは、Bitcoinネットワークのネイティブトークンである。分散型デジタル通貨として設計され、中央管理者を持たず、ピアツーピアでの価値移転を可能にする。
事実: 発行上限は2,100万BTCとプロトコル上で規定されており、最小単位は1 Satoshi(0.00000001 BTC)である。新規発行は約4年ごとの半減期(Halving)により段階的に半減する設計となっている。Bitcoinネットワークにおける価値移転の媒体、およびネットワークのセキュリティを維持するマイナーへの報酬(ブロック報酬とトランザクション手数料)として機能する。
参照ソース:
Bitcoin: A Peer-to-Peer Electronic Cash System(2008年)
著者:Satoshi Nakamoto
Bitcoin公式サイト
https://bitcoin.org/
※ 実効発行ペースおよび手数料水準はネットワーク状況により変動する。
イーサリアム(Ethereum)
定義:
イーサリアムは、スマートコントラクト機能を実装したレイヤー1ブロックチェーン。分散型アプリケーション(dApps)の実行基盤として設計され、ネイティブトークンETHを用いてトランザクション手数料およびステーキングを行う。
事実:
イーサリアムは2015年にローンチされた。スマートコントラクトはEVM(Ethereum Virtual Machine)上で実行される。2022年のThe Mergeにより、コンセンサスはProof of Work(PoW)からProof of Stake(PoS)へ移行した。トランザクション手数料はETHで支払われ、2021年のEIP-1559導入以降、Base Feeのバーン機構が実装されている。発行上限は固定されておらず、供給量は発行量とバーン量の差分によって変動する。
参照ソース:
Ethereum Whitepaper(2013年)
著者:Vitalik Buterin
Ethereum公式ドキュメント
https://ethereum.org/
Ethereum Improvement Proposal 1559(2019年)
https://eips.ethereum.org/EIPS/eip-1559
※ プロトコル仕様はアップグレードにより変更される可能性がある。
ETH
定義:
ETHは、Ethereum ネットワークのネイティブトークン。トランザクション手数料(ガス代)の支払い、バリデーターのステーキング、およびスマートコントラクト実行の基軸資産として機能する。
事実:
ETHはネットワーク利用時のガス代支払いに使用される。2022年のThe Merge以降、EthereumはProof of Stake(PoS)へ移行し、ETHはバリデーター参加のためのステーキング資産となっている。EIP-1559導入以降、トランザクション手数料の一部(Base Fee)はバーン(焼却)される仕組みが実装されている。発行量は固定上限を持たず、発行とバーンの差分により実質供給量が変動する設計である。
参照ソース:
Ethereum Whitepaper(2013年)
著者:Vitalik Buterin
Ethereum公式ドキュメント
https://ethereum.org/en/
Ethereum Improvement Proposal 1559(2019年)
https://eips.ethereum.org/EIPS/eip-1559
※ 発行量および供給動向はネットワーク活動状況により変動する。
Solana(ソラナ)
定義:
Solanaは、高速処理と低手数料を特徴とするレイヤー1ブロックチェーン。Proof of Stake(PoS)に加え、独自の時間証明メカニズム「Proof of History(PoH)」を組み合わせたコンセンサス設計を採用している。
事実:
SolanaはネイティブトークンSOLを用い、トランザクション手数料の支払いおよびステーキングに利用される。理論設計上は高スループットを目指すが、実効処理性能はネットワーク負荷およびバリデーター環境に依存する。手数料モデルはEthereum型の動的オークション構造とは異なり、計算資源単位に基づく設計である。過去にネットワーク停止事例が確認されており、可用性に関する技術的議論が存在する。
参照ソース:
Solana Whitepaper(2017年)
著者:Anatoly Yakovenko
Solana公式ドキュメント
https://docs.solana.com/
※ 実効TPSおよび安定性はソフトウェア更新やネットワーク状況により変動する。
プロトコル(Protocol)
定義:
プロトコルとは、ネットワーク上でデータ通信や処理を行うために定められた技術的規則および手順の集合を指す。ブロックチェーン分野では、トランザクション検証、ブロック生成、コンセンサス形成、トークン発行などの基本動作を規定するルール体系を意味する。
事実:
ブロックチェーンはプロトコルに基づいて動作し、参加ノードは同一の仕様に従うことで整合性を維持する。代表例として、Bitcoin プロトコルはProof of Workに基づくコンセンサスと発行上限2,100万BTCを規定している。Ethereum プロトコルはスマートコントラクト実行環境とProof of Stake型コンセンサスを備える。DeFi領域では、貸借や取引機能を提供するアプリケーションレベルのプロトコルが存在し、スマートコントラクトにより自動実行される。プロトコルの仕様変更はアップグレードやハードフォークを通じて実施される。
参照ソース:
Bitcoin: A Peer-to-Peer Electronic Cash System(2008年)
著者:Satoshi Nakamoto
Ethereum Whitepaper(2013年)
著者:Vitalik Buterin
※ プロトコル仕様は開発者コミュニティの合意形成により変更される場合がある。
Arbitrum
定義:
Arbitrumは、Ethereum上に構築されたLayer 2スケーリングソリューションである。Optimistic Rollup方式を採用し、トランザクションを集約処理したうえで最終的なデータをEthereumに記録する設計を持つ。
事実:
ArbitrumはOffchain Labsによって開発され、2021年にメインネットが公開された。Optimistic Rollupは、不正がある場合のみ検証を行う前提設計を採用しており、一定期間のチャレンジ期間を設ける。トランザクション手数料はEthereumと比較して低水準となることを目的としているが、最終確定はEthereumのセキュリティに依存する。ネイティブガバナンストークンARBが存在し、ネットワークのガバナンスに利用される。
参照ソース:
Arbitrum公式サイト
https://arbitrum.io/
Arbitrum公式ドキュメント
https://docs.arbitrum.io/
Ethereum公式ドキュメント(Layer 2解説)
https://ethereum.org/en/layer-2/
※ 手数料水準および処理性能はネットワーク状況により変動する。
Optimism
定義:
Optimismは、Ethereum上に構築されたLayer 2スケーリングソリューションである。Optimistic Rollup方式を採用し、トランザクションを集約処理したうえで最終結果をEthereumに記録する設計を持つ。
事実:
Optimismは2021年にメインネットを公開した。Optimistic Rollupは、原則としてトランザクションを正当とみなし、不正が指摘された場合にのみ検証を行う仕組みである。このため、一定のチャレンジ期間が設けられている。トランザクション手数料はEthereumメインネットより低減されることを目的としているが、最終的なデータ確定とセキュリティはEthereumに依存する。ネイティブトークンOPはガバナンスに利用される。
参照ソース:
Optimism公式サイト
https://www.optimism.io/
Optimism公式ドキュメント
https://community.optimism.io/docs/
Ethereum公式ドキュメント(Layer 2解説)
https://ethereum.org/en/layer-2/
※ 手数料水準および処理性能はネットワーク状況により変動する。
ブロックチェーン(Blockchain)
定義:
ブロックチェーンとは、取引データを一定期間ごとにまとめた「ブロック」を時系列に連結し、分散型ネットワーク上で共有・検証する分散型台帳技術である。各ブロックは暗号技術により前のブロックと連結され、改ざんが困難な構造を持つ。
事実:
ブロックチェーンは中央管理者を持たず、複数のノードが同一の台帳を保持することで整合性を維持する。トランザクションはコンセンサスアルゴリズムに基づいて検証され、承認された取引のみがブロックに記録される。代表例として、Bitcoin はProof of Workを採用し、Ethereum は現在Proof of Stakeを採用している。用途は暗号資産の移転に加え、スマートコントラクト実行、分散型金融、NFT発行など多岐にわたる。
参照ソース:
Bitcoin: A Peer-to-Peer Electronic Cash System(2008年)
著者:Satoshi Nakamoto
Ethereum公式ドキュメント
https://ethereum.org/en/
※ コンセンサス方式や処理性能は各プロトコルにより異なる。
Solidity
定義:
Solidityは、Ethereum上でスマートコントラクトを開発するために設計された高水準プログラミング言語である。静的型付けを採用し、コントラクト指向の構文を持つ。
事実:
Solidityは2014年に提案され、Ethereum Virtual Machine(EVM)上で実行可能なバイトコードにコンパイルされる。主に分散型アプリケーション(dApps)、DeFiプロトコル、NFTコントラクトなどの開発に用いられる。オブジェクト指向に類似した構造を持ち、継承、ライブラリ、インターフェースなどの機能を備える。セキュリティ上の注意点として、再入攻撃、整数オーバーフロー、アクセス制御不備などの脆弱性が過去に確認されている。コード監査やテストが重要とされる。
参照ソース:
Solidity公式ドキュメント
https://docs.soliditylang.org/
Ethereum公式ドキュメント(Smart Contract開発)
https://ethereum.org/en/developers/docs/smart-contracts/
※ 言語仕様はバージョン更新により変更される場合がある。
Optimistic Rollup
定義:
Optimistic Rollupは、Layer 2スケーリング技術の一種であり、トランザクションをオフチェーンで集約処理し、その結果のみをレイヤー1ブロックチェーンに記録する方式である。原則としてトランザクションを正当と仮定し、不正が指摘された場合のみ検証を行う設計を採用する。
事実:
Optimistic Rollupは主にEthereum 上で採用されている。トランザクションはLayer 2上で実行され、圧縮されたデータがLayer 1に投稿される。不正がある場合にはチャレンジ期間内に異議申し立てが可能であり、正当性が検証される。代表的な実装例として、Arbitrum および Optimism がある。最終確定にはチャレンジ期間を経る必要があるため、即時確定ではない点が特徴である。
参照ソース:
Ethereum公式ドキュメント(Rollups解説)
https://ethereum.org/en/developers/docs/scaling/rollups/
Arbitrum公式ドキュメント
https://docs.arbitrum.io/
Optimism公式ドキュメント
https://community.optimism.io/docs/
※ チャレンジ期間や実装仕様はプロトコルごとに異なる。
ZK Rollup(Zero-Knowledge Rollup)
定義:
ZK Rollupは、Layer 2スケーリング技術の一種であり、複数のトランザクションをオフチェーンで集約処理し、その正当性を暗号学的証明(ゼロ知識証明)によって検証したうえで、レイヤー1ブロックチェーンに記録する方式である。
事実:
ZK Rollupは主にEthereum 上で採用されている。トランザクションはLayer 2で実行され、計算結果とともに有効性証明(Validity Proof)がLayer 1に提出される。Layer 1は提出された証明を検証することで、個々のトランザクションを再実行せずに整合性を確認できる。Optimistic Rollupと異なり、チャレンジ期間を前提とせず、証明が受理されれば原則として即時確定に近い性質を持つ。代表的な実装例として、zkSync や StarkNet がある。
参照ソース:
Ethereum公式ドキュメント(Rollups解説)
https://ethereum.org/en/developers/docs/scaling/rollups/
zkSync公式ドキュメント
https://docs.zksync.io/
StarkNet公式ドキュメント
https://docs.starknet.io/
※ 証明方式やデータ可用性設計は実装ごとに異なる。
フラッシュローン(Flash Loan)
定義:
フラッシュローンとは、ブロックチェーン上の単一トランザクション内で借入と返済を完結させる無担保ローンの仕組みである。返済が同一トランザクション内で実行されなかった場合、処理全体はrevert(巻き戻し)される。
事実:
フラッシュローンは主にEthereum 上のDeFiプロトコルで実装されている。代表例として、Aave が提供するFlash Loan機能がある。
仕組みの基本構造は以下。
- 借入要求
- 資金受領
- 任意のロジック実行(裁定取引など)
- 元本+手数料の返済
- 未返済の場合はトランザクション全体が失敗
この仕組みは、Ethereum Virtual Machine(EVM)の「アトミック性(トランザクションが全て成功するか、全て失敗するか)」に依存している。
用途として確認されているもの。
- DEX間の価格差を利用した裁定取引
- 担保ポジションの即時清算
- 流動性再配置
一方で、過去には価格オラクル操作や流動性の一時的操作を通じた攻撃事例が複数発生している。これらはフラッシュローン自体の脆弱性ではなく、外部プロトコルの設計不備を突いたものである。
参照ソース:
Aave公式ドキュメント(Flash Loan)
https://docs.aave.com/developers/guides/flash-loans
Ethereum公式ドキュメント
https://ethereum.org/en/developers/docs/
※ フラッシュローンの利用可否、手数料水準、実装仕様はプロトコルごとに異なる。
アカウント抽象化(ERC-4337)
定義:
アカウント抽象化(ERC-4337)とは、ブロックチェーン上においてユーザーアカウントをスマートコントラクトとして実装可能にし、署名検証・ガス支払い・実行ロジックを柔軟に設計できる仕組みである。
従来の外部所有アカウント(EOA)依存構造を拡張し、トランザクション処理をアプリケーション層で抽象化する。
事実:
ERC-4337は Ethereum 上で提案されたEthereum Improvement Proposalである。プロトコル本体のハードフォークを必要とせず、スマートコントラクトとオフチェーンインフラによって実装される。
ERC-4337の基本構造は以下。
UserOperation生成
↓
Bundlerが複数のUserOperationを集約
↓
EntryPointコントラクトで検証・実行
↓
ガス精算(Paymaster経由も可能)
特徴的な点は、従来のトランザクションではなく「UserOperation」という独自構造体を用いる点である。未検証または実行失敗時は処理はrevertされる。
この仕組みは、Ethereum Virtual Machine(EVM)のアトミック性(処理が全て成功するか全て失敗するか)に依存している。
確認されている機能:
- ガス代の第三者負担(Gas Sponsorship)
- 任意署名ロジック(例:多要素署名)
- バッチ処理
- セッションキー発行
- ソーシャルリカバリー
リスク構造:
- Bundler依存構造
- EntryPointコントラクトの集中化リスク
- Paymaster悪用リスク
- スマートコントラクトウォレット実装ミスによる資産損失
ERC-4337は柔軟性を拡張する仕様であり、安全性を自動的に保証するものではない。
参照ソース:
ERC-4337 Proposal
https://eips.ethereum.org/EIPS/eip-4337
Ethereum公式ドキュメント
https://ethereum.org/en/developers/docs/accounts/
OpenZeppelin Account Abstraction Documentation
https://docs.openzeppelin.com/contracts
※ ERC-4337の実装状況、対応ウォレット、手数料構造はプロトコル・サービスごとに異なる。
UXの抽象化(ERC-4337)
定義:
UXの抽象化(ERC-4337)とは、ユーザーが秘密鍵管理・ガス支払い・署名方式といった内部構造を意識せずにブロックチェーンを利用できる体験設計を、ERC-4337仕様に基づいて実現する仕組みである。
ERC-4337は、スマートコントラクトベースのアカウントを用いてトランザクション検証および実行ロジックを柔軟化するAccount Abstractionの実装仕様である。
事実:
ERC-4337は Ethereum 上で提案されたEthereum Improvement Proposalであり、プロトコルのハードフォークを伴わず、スマートコントラクトとオフチェーンコンポーネントによって実装される。
基本構造は以下。
UserOperation生成
↓
Bundlerが複数のUserOperationを集約
↓
EntryPointコントラクトで検証・実行
↓
ガス精算(Paymaster利用可)
従来の外部所有アカウント(EOA)では、
- 署名方式は固定(ECDSA)
- ガス代は本人負担
- 単一トランザクション単位で実行
であった。
ERC-4337では以下が実装可能。
- ガス代の第三者負担(Gas Sponsorship)
- 任意署名ロジック
- バッチ処理
- セッションキー
- ソーシャルリカバリー
処理はEthereum Virtual Machine(EVM)のアトミック性に依存し、検証失敗時は全体がrevertされる。
リスク構造:
- Bundler依存構造
- EntryPointコントラクト集中化リスク
- Paymaster悪用リスク
- スマートコントラクトウォレット実装不備による資産毀損リスク
ERC-4337はUX改善を目的とする仕様であり、安全性を保証する設計ではない。
参照ソース:
ERC-4337 Proposal
https://eips.ethereum.org/EIPS/eip-4337
Ethereum公式ドキュメント
https://ethereum.org/en/developers/docs/accounts/
OpenZeppelin Account Abstraction Documentation
https://docs.openzeppelin.com/contracts
インパーマネント・ロス(Impermanent Loss)
定義:
インパーマネント・ロス(Impermanent Loss)とは、分散型取引所(AMM)に流動性提供(LP)を行った際、預け入れ資産の価格比率が変動することにより、単純保有(HODL)していた場合と比較して発生する相対的な損失を指す。
価格が元の比率に戻れば損失は理論上解消されるため「インパーマネント(非永続的)」と呼ばれる。
事実:
インパーマネント・ロスは、Automated Market Maker(AMM)型DEXで発生する構造的現象である。代表例として、Uniswap が挙げられる。
一般的なAMMは「x × y = k」の定数積モデルを採用する。
価格変動が起こると、アービトラージ参加者によってプール内資産比率が調整される。この結果、流動性提供者の保有構成が変化し、価格変動分が実質的損失として現れる。
確認されている特徴。
- 価格変動幅が大きいほど損失は拡大
- ボラティリティが高い資産ペアで顕著
- 手数料収益で相殺される場合もある
- 価格が初期比率へ回帰すれば損失は解消
数理的には、価格比率変化率 r に対し、
損失率 ≒ 2√r / (1+r) − 1
で表現される(定数積モデルの場合)。
リスク構造:
- 高ボラティリティ資産で損失拡大
- 手数料収益が損失を下回る可能性
- 流動性集中型AMMではレンジ外リスクが発生
- 短期的な価格急変動時に急激な含み損
インパーマネント・ロスはバグではなく、AMM設計に内在する経済的メカニズムである。
参照ソース:
Uniswap公式ドキュメント
https://docs.uniswap.org/
Ethereum公式ドキュメント
https://ethereum.org/en/developers/docs/defi/
※ 実際の損益は価格変動、手数料水準、流動性レンジ設計により異なる。
ミームコイン(Meme Coin)
定義:
ミームコインとは、インターネット上のミーム(風刺画像・ジョーク・コミュニティ文化)を起点として発行された暗号資産を指す。
多くの場合、明確なユーティリティや技術的革新よりも、コミュニティ拡散力や話題性に価値形成が依存する。
事実:
代表例として以下が確認されている。
- Dogecoin(2013年発行)
- Shiba Inu(2020年発行)
Dogecoinは当初ジョークとして作成されたが、後に市場取引が拡大した。
Shiba InuはEthereum上のERC-20トークンとして発行された。
一般的特徴。
- 発行枚数が非常に多い設計が多い
- SNS拡散による価格変動が顕著
- 著名人発言やコミュニティ動向の影響を受けやすい
- 実需よりも投機需要主導で価格形成される傾向
一部はDEX・ステーキング・NFT連携など機能拡張を行っているが、設計思想はプロジェクトごとに異なる。
リスク構造:
- 極端な価格ボラティリティ
- ファンダメンタルズ不明確
- 流動性の急減リスク
- プロジェクト放棄(Rug Pull)リスク
- 規制対応の不確実性
ミームコインは構造的に価格形成が感情・拡散依存型となる傾向が強い。
参照ソース:
Dogecoin公式サイト
https://dogecoin.com
Shiba Inu公式サイト
https://shibatoken.com
CoinMarketCapデータベース
https://coinmarketcap.com
※ 各ミームコインの設計・供給量・機能は個別に異なる。投資判断はリスク構造を十分理解した上で行う必要がある。
Virtuals Protocol
定義:
Virtuals Protocolとは、AIエージェントをオンチェーン上で発行・管理・共同所有・収益化可能にすることを目的とするWeb3プロトコルである。AIエージェントをトークン化し、市場参加者が出資・取引・収益分配に関与できる構造を採用している。
事実:
Virtuals Protocolは、AIエージェントをブロックチェーン上のデジタル資産として発行可能な設計を採用している。エージェントごとにトークン設計がなされ、保有比率に応じて収益分配が行われるモデルが提示されている。
主な構造的要素。
- AIエージェントのオンチェーン登録
- エージェント単位のトークン発行
- コミュニティ共同所有モデル
- 収益分配メカニズム
- プロトコルトークン「VIRTUAL」の存在
プロジェクトはEthereumエコシステム上で展開されていると公表されている。トークン「VIRTUAL」はユーティリティおよびガバナンス用途を持つと説明されている。
設計思想としては、「AIエージェント=資産化可能なデジタル主体」という概念を前提としている。
リスク構造:
- トークン価格の高ボラティリティ
- AIエージェント収益性の不確実性
- スマートコントラクトリスク
- 規制上の分類不確実性(証券性判断等)
- 流動性縮小リスク
- プロジェクト運営依存リスク
AIエージェントの価値評価は従来資産と異なり、収益予測・持続性・利用実態に大きく依存する。
参照ソース:
Virtuals Protocol 公式サイト
https://www.virtuals.io
公式ドキュメント
https://docs.virtuals.ioCoinMarketCap
https://coinmarketcap.com
※ トークン設計、ネットワーク展開状況、経済モデルは更新される可能性がある。掲載時点の公式情報との照合が必要である。
ハニーポット(Honey Pot)
定義:
ハニーポットとは、スマートコントラクトに意図的に制限や罠を設け、特定の条件を満たさないウォレットが資産を引き出せないようにした仕組みを指す。外部から見ると通常のトークンや資産に見えるが、購入・送金・売却が特定条件下でブロックされる場合がある。
事実:
- ハニーポットはEthereumなどのスマートコントラクト対応ブロックチェーンで確認されている。
- 多くはプロキシパターンや権限管理機能を利用しており、特定のアドレス(例:開発者)以外は「transfer」関数や「sell」関数を実行できない構造になっている。
- 監査済みでないコントラクトや、アップグレーダブル契約に潜在的に存在することがある。
- 過去にはUniswapやその他DEX上のトークンにおいて、外部ユーザーが売却できない事例が報告されている。
リスク構造:
B: ハニーポットは、スマートコントラクト上の関数制限や条件分岐によって資産流出を防止する一方で、外部ユーザーが資産を失う可能性を内包する。主なリスクは以下。
- 資金回収不能リスク:購入したトークンが売却できず、流動性が事実上ゼロになる場合がある。
- 権限依存リスク:開発者や特定アドレスに依存しており、権限濫用が発生する可能性がある。
- アップグレードリスク:プロキシ構造の場合、後から悪意あるコードに更新されることがあり、購入者に予期せぬ制限が加わる。
参照ソース:
- Ethereum公式ドキュメント(Smart Contract Security)
https://ethereum.org/en/developers/docs/smart-contracts/security/ - ConsenSys Smart Contract Best Practices – Access Control & Honey Pot
https://consensys.github.io/smart-contract-best-practices/attacks/#honey-pot
ラグプル(Rug Pull)
定義:
ラグプルとは、暗号資産プロジェクトの開発者やトークン発行者が、流動性プールや投資資金を意図的に引き上げ(引き抜き)、投資家が資産を失う形で市場から撤退する行為を指す。特にDEX(分散型取引所)上のトークンや流動性プールにおいて観測される。
事実:
- ラグプルはEthereumやSolanaなどのブロックチェーン上で発生事例が報告されている。
- 発生の仕組みとしては、開発者がスマートコントラクト上の管理者権限を用い、流動性プールに預けられたETHやUSDC、その他の基軸通貨を全額または大部分引き抜くケースが確認されている。
- DEXにおけるAMM(自動マーケットメイカー)では、流動性が急減することでユーザーがトークンを売却できなくなり、価格が急落する。
- 過去にはプロジェクト開始直後のトークン販売後に即座にラグプルが行われた事例もある。
リスク構造:
B: ラグプルはスマートコントラクトの管理者権限や流動性設計の脆弱性を利用して実行される。主なリスクは以下。
- 資産喪失リスク:ユーザーが保有するトークンやステーブルコインを失う可能性が高い。
- 流動性消失リスク:流動性プールが枯渇することで、資産の売却や交換が不可能になる。
- プロジェクト依存リスク:スマートコントラクトの権限設計に依存しており、開発者の意図次第でトークンが凍結される。
参照ソース
- Ethereum公式ドキュメント(Smart Contract Security)
https://ethereum.org/en/developers/docs/smart-contracts/security/ - ConsenSys Smart Contract Best Practices – Rug Pull
https://consensys.github.io/smart-contract-best-practices/attacks/#rug-pull
