# bitsumi.

> Web開発、ブロックチェーン、システム設計の技術記事と、開発中の発見を残すスクラップ。仕組みから理解するための個人テックメディア。

## Blockchain / AI

- [\[ERC8444\] AIエージェントの提供機能と報酬付きの依頼をオンチェーンで見つける仕組み](https://cardene.dev/articles/03cafeb763efd8d1e6c5.md): 旅行を計画するAIエージェントが、航空券を検索できる機能と、旅程作成を報酬付きで依頼している相手を探す場面を考えます。
- [\[ERC8436\] 複数のAIエージェントが投票で作業の承認結果を決める仕組み](https://cardene.dev/articles/7d23cebc8935c3282be1.md): ソフトウェア開発を依頼し、AIエージェントから成果物が提出された場面を考えます。発注者は、1人の評価者ではなく、技術面を確認する5人のAIエージェントに受入れ判断を頼みたいとします。
- [\[ERC8350\] AIエージェントの保存データを公開せずに更新履歴を確認する仕組み](https://cardene.dev/articles/16b515d56203218a73c4.md): 旅行を手配するAIエージェントが、利用者から「窓側の席を優先する」と教えられた場面を考えます。事業者は、その好みを非公開データベースへ保存できます。
- [\[ERC8196\] AIエージェントの資産操作を条件付きで実行する仕組み](https://cardene.dev/articles/120d8e71a33c15255295.md): 例えば、所有者が「このエージェントは指定したDEXへ0.01ETHまで、今日の18時まで送れる」と登録したとします。エージェントが出す操作要求は、その条件を指すハッシュ、送付先、金額、有効期限、使い切り番号を署名とともに渡します。
- [\[ERC8183\] 依頼の報酬をエスクローで支払う仕組み](https://cardene.dev/articles/44e076586c6faeabfb3b.md): 依頼者がデータ分析を依頼し、結果を確認してから報酬を支払う場面を考えます。提出後に支払うまたは返金するを決める役割が判定主体です。
- [\[ERC8122\] AIエージェントを登録して探せる仕組み](https://cardene.dev/articles/3ec73d2a8a63bb7e4911.md): 例えば利用者がDeFi向けのAIエージェントを探し、候補一覧でAlphaという名前を見つけたとします。同じ名前の候補が別のregistryにもあるため、名前だけで接続先を開くと、意図しないagentへつながるおそれがあります。
- [\[ERC8107\] AIエージェントの参加をENSで判定する仕組み](https://cardene.dev/articles/3b0716e0af0587f56c5f.md): ERC8107は、AIエージェントが別のエージェントへ仕事を任せる前に、任せてよい相手かを確かめるための規格です。ここでいう評価は、ENS名の所有者が「このENS名を、この用途の仕事の相手として受け入れる」と署名するものです。
- [\[ERC8217\] AIエージェントを外部トークンの制御者へ結び付ける仕組みを理解しよう！](https://cardene.dev/articles/e5892053dfc3cd83307c.md): ERC8004では、AIエージェントの識別情報を管理するレジストリが、各エージェントをNFTとして登録します。
- [\[ERC8273\] Agentの操作を1回のトランザクションだけ認可する仕組みを理解しよう！](https://cardene.dev/articles/b913add46e84735fefba.md): ERC8273では、AttestorがAgentの操作を事前に評価します。評価に通ったら、AttestorはRegistryコントラクトのattestAndCallを呼びます。
- [\[ERC8257\] AIエージェントが使うツールをオンチェーンで発見・検証するAgent Tool Registryの仕組みを理解しよう！](https://cardene.dev/articles/f398eb8af12a4b28607e.md): ERC8257は、AIエージェントが利用できるツールを登録するオンチェーンレジストリです。登録情報は ToolConfig として保存され、ツールの説明本体はHTTPSで取得できるmanifestに置かれます。
- [\[ERC8126\] AIエージェントの信頼を検証とリスクスコアで示す提案を理解しよう！](https://cardene.dev/articles/ae24ee67cb56178ab587.md): ERC8126はERC8004のIdentity Registryにmintされたエージェント（ERC721の tokenId が agentId ）を起点に、メタデータを読んでコントラクト（ETV）、メディア（MCV）、Solidity（
- [Solidityの仕様書をOpenAPI+Swagger形式で定義してみる](https://cardene.dev/articles/solidity-openapi-spec.md): この仕様書はHTTP API設計ではなく、Solidityコントラクトのインターフェイス定義をOpenAPI/Swagger形式で記述するためのものです。
- [\[ERC7662\] AIエージェントとして扱う仕組みを理解しよう！](https://cardene.dev/articles/59f4752835f9ff726372.md): AIエージェントをNFTとして扱うためには、従来のNFT設計では不十分な点があります。ERC7662は、その課題を解決するためにAIエージェント専用のNFT標準を定義しています。
- [Smart Contractの仕様書をClaude Codeで生成してみる](https://cardene.dev/articles/solidity-openapi-spec-generator.md): スマートコントラクトの仕様書を手作業で作成するのは、膨大な時間と労力がかかります。ABIを解析して関数やイベントを列挙し、各要素に適切な説明を付け、型情報をOpenAPI形式に変換し、さらにNatSpecコメントを抽出して反映する。
- [\[ERC7517\] デジタル資産のAI利用ルールを定義する仕組みを理解しよう！](https://cardene.dev/articles/5ced1ee754d53e29f826.md): ERC7517は、EVM互換ブロックチェーンで扱われるデジタルメディアに対して、データマイニング（大量のデータを解析する処理）やAI学習用途への利用可否を明確に示す仕組みを整えるものです。
- [\[ERC8004\] トラストレスに動くエージェントの仕組みを理解しよう！](https://cardene.dev/articles/4958873135ba9892c298.md): このプロトコルは、ブロックチェーンを活用して、組織をまたいでエージェント（自律的なプログラムやAI）を「発見」、「選択」、「やり取り」できる仕組みを提案しています。ここで重要なのは、事前に信頼関係がなくても安全に協働できるという点です。
- [\[ERC8001\] 複数エージェントが安全に連携する仕組みを理解しよう！](https://cardene.dev/articles/d579c93bceca73cd08b7.md): ERC8001は、複数の主体（エージェント）が単一のブロックチェーン上で足並みをそろえて行動するための、最小限のオンチェーン仕組みを定義する規格です。
- [\[ERC7777\] ロボットと人間が共に暮らす分散社会の仕組みを理解しよう！](https://cardene.dev/articles/641f9deac0553dc8395b.md): ERC7777では、「IUniversalIdentity」と「IUniversalCharter」という2つの主要なインターフェースを定義しています。
- [\[ERC7857\] AIのデータを安全に扱うNFTの仕組みを理解しよう！](https://cardene.dev/articles/aba603c8d36674f1cdc3.md): ERC7857では、**AIエージェント（人工知能の自律的な行動主体）**を対象とした、NFT（Non-Fungible Token／代替不可能トークン）の新しい標準インターフェースを定義しています。
- [\[ERC7007\] AI生成コンテンツをNFTにして検証できる仕組みを理解しよう！](https://cardene.dev/articles/315fed3015f833f4c75f.md): ERC7007は、AIが生成したコンテンツ（AIGC：AI Generated Content）をブロックチェーン上で安全かつ検証可能に扱うための新しいNFT標準である「Verifiable AIGC-NFT Standard」について提案

## Blockchain / Avalanche

- [Avalanche Consensus](https://cardene.dev/articles/855c8a9c6e2488.md): Avalancheコンセンサスは、ブロックチェーンの合意形成における課題を解決するために設計された、スケーラブルで堅牢な分散型プロトコルです。
- [ブロックチェーンでのISO20022の取り組み](https://cardene.dev/articles/65833002cff470.md): ISO 20022は、国際標準化機構（ISO）が金融分野向けに定めた電子メッセージ交換の標準規格です。金融機関や決済ネットワーク間で取引データを効率的かつ統一的にやり取りするための「共通言語」を提供します。
- [\[ACP181\] ICM検証を安定化するP-Chainエポック化の仕組みを理解しよう！](https://cardene.dev/articles/6ed05be0a9f0f7f70613.md): ACP181は、P-Chain（プライマリチェーン）におけるエポック（一定期間の単位）化のための標準スキームを定義する提案です。
- [Avalanche ICTT](https://cardene.dev/articles/f1a879d1792ba0.md): Avalanche Interchain Token Transfer (ICTT)は、異なるL1ブロックチェーン間でトークンを送付するためのアプリケーションです。
- [\[ACP224\] Subnet-EVMの動的手数料アップグレードの仕組みを理解しよう！](https://cardene.dev/articles/fe92a936643bab47dcec.md): ACP224は、Subnet-EVMに対してACP176を実装し、さらに新たなプリコンパイルコントラクトであるACP224FeeManagerPrecompileを導入することを目的としています。
- [\[ACP209\] EIP-7702をAvalancheで安全に導入する仕組みを理解しよう！](https://cardene.dev/articles/43dc6d655b5db6c0b11b.md): ACP209は、EIP7702で導入された新しい「set code transaction（コード設定トランザクション）」の仕組みを、AvalancheのEVM（Ethereum Virtual Machine）実装にも取り入れる提案です。
- [Avalanche ICM](https://cardene.dev/articles/c6edd8d46ec9bc.md): Avalanche ICM（Interchain Messaging）とは、AvalancheのL1ブロックチェーン間でメッセージを送受信する仕組みです。ここでのメッセージとは、単純な文字列や関数の実行情報などです。
- [\[ACP204\] C-ChainにP-256検証を行うプリコンパイルを追加する仕組みを理解しよう！](https://cardene.dev/articles/e874823f8a61aba5dc43.md): ACP204は、AvalancheのC-Chainにsecp256r1（P-256）楕円曲線の署名検証を行うプリコンパイルコントラクト（precompiled contract）を導入するものです。
- [\[ACP194\] トランザクション順序と処理を分けるSAEの仕組みを理解しよう！](https://cardene.dev/articles/a5f0eaf1703a393a92f0.md): StreamingAsynchronousExecution（SAE）は、consensus（トランザクションの順序決定）とexecution（決定順に従ってstateを更新）の結びつきをqueueで分離します。
- [\[ACP151\] ICM検証を高速化するBlockHeight参照変更の仕組みを理解しよう！](https://cardene.dev/articles/951a21f78d03b1a780fc.md): ACP151は、ProposerVM（ブロックを組み立てるときに内側のVMへ補助情報を渡すコンポーネント）が、内側のVM（EVMなど）へ渡すP-Chainの**BlockHeight（ブロック番号）を、「親ブロックのBlockHeight」
- [\[ACP99\] コントラクトでL1バリデータを管理する仕組みを理解しよう！](https://cardene.dev/articles/61546e03f0abe6df657b.md): ACP99Managerは、Avalanche上の任意のEVMチェーンにデプロイできるValidatorManager（バリデータを管理するコントラクト）の標準仕様を定める提案です。
- [\[ACP83\] P/X-Chainの動的手数料方式の仕組みを理解しよう！](https://cardene.dev/articles/7c49de6233fb191d4f3f.md): ACP83は、AvalancheのP-ChainとX-Chainに「動的かつ多面的な手数料方式」を導入するものです。
- [\[ACP125\] C-Chain最低ベース手数料1nAVAX化の仕組みを理解しよう！](https://cardene.dev/articles/b460e0b6277fe5999c15.md): ACP125は、AvalancheのC-Chainにおける最低ベース手数料（minimum base fee）を、現在の25nAVAXから1nAVAXへと引き下げることを目的としています。
- [\[ACP176\] AvalancheEVMの動的ガス調整の仕組みを理解しよう！](https://cardene.dev/articles/8e9ccb3b0316ca1ad7c8.md): ACP176では、AvalancheのC-ChainおよびSubnet-EVMチェーンにおいて、P-Chainのアップグレード提案であるACP103で導入された「動的手数料（dynamic fee）メカニズム」と類似した仕組みを採用すること
- [\[ACP226\] 優先手数料ではなく時間でブロック生成を制御する仕組みを理解しよう！](https://cardene.dev/articles/8fcb0a165db08299c8a0.md): ACP226は、AvalancheのEVMチェーンにおけるブロック生成速度を制御する仕組みを、従来の「ブロックガスコスト方式(」から新しい方式に置き換える提案です。
- [\[ACP31\] Subnet所有権移転の仕組みを理解しよう！](https://cardene.dev/articles/8c3bf2fcf450c2e1feb6.md): ACP31は、現在のSubnet（サブネット）の所有者が、新しい所有者へと所有権を移転できるようにする仕組みを導入する提案です。
- [\[ACP41\] ステーク期間管理の新ルールの仕組みを理解しよう！](https://cardene.dev/articles/96dbb5d86eb3571b54c7.md): ACP41は、ステーカー（stakingを行う人やノード）が自分で指定するStartTime（ステーキング開始時刻）を廃止し、ステーキング取引がP-chainで「受理（accept）」された瞬間にステーキングを開始するという変更案です。
- [\[ACP62\] バリデータ登録時にBLS鍵の登録を必須化する仕組みを理解しよう！](https://cardene.dev/articles/ce2bb7eda730d80023f8.md): ACP62は、これまでP-Chain（Avalancheのステーキングやサブネット管理を担うチェーン）で使われてきたAddValidatorTxとAddDelegatorTxという古い登録用トランザクションを「無効化」し、今後はAddPer
- [\[ACP30\] C-Chain/Subnet-EVMへのAWM統合の仕組みを理解しよう！](https://cardene.dev/articles/d07a1ac7376ff1b20ea7.md): ACP30では、Avalanche Warp Messaging（以下AWM）をC-ChainおよびSubnet-EVMに統合し、Avalanche上のEVM環境においてクロスサブネット通信（Cross-Subnet Communicati
- [\[ACP25\] リクエスト失敗を即時通知するAppErrorの仕組みを理解しよう！](https://cardene.dev/articles/86dbeeea0e0ac179db98.md): ACP25は、VirtualMachine（VM）がアプリケーション固有のエラー状態を別のVMへ通知できる仕組みを追加するものです。
- [\[ACP23\] Avalanche P-Chainにおける資産Transferの仕組みを理解しよう！](https://cardene.dev/articles/6eb1d3978230b39da748.md): ACP23は、AvalancheのP-Chainに「ネイティブなTransfer機能」を追加する提案です。現在、P-Chain上にはユーザーが資産を直接送付するためのシンプルなトランザクション形式が存在しません。
- [\[ACP20\] AvalancheノードIDをEd25519で扱う仕組みを理解しよう！](https://cardene.dev/articles/1ff102690b7c58bc1e5b.md): ACP20は、Avalancheネットワークのp2p通信におけるTLS証明書でEd25519をサポートし、Avalanche Network Clients (ANCs) のNode IDにEd25519公開鍵をそのまま利用できるようにし、
- [\[ACP108\] Avalancheチェーン間イベント共有の仕組みを理解しよう！](https://cardene.dev/articles/9c3eed204c11622a1ab2.md): ACP108では、Avalanche内の任意のL1ブロックチェーンからEVMイベントをインポートするための、スマートコントラクトの標準インターフェースと抽象的な実装を定義しています。
- [\[ACP75\] P-Chain承認を証明するAcceptanceProofの仕組みを理解しよう！](https://cardene.dev/articles/b566c26ea51229d9d1a8.md): ACP75は、あるブロックがコンセンサス（合意）によって承認されたことを第三者が確かめられる「AcceptanceProof（承認証明）」をプロトコルとして扱えるようにする提案です。
- [\[ACP118\] Warp署名リクエスト標準化の仕組みを理解しよう！](https://cardene.dev/articles/733325719fce1d8486c6.md): ACP118は、AvalancheネットワークにおいてWarpメッセージの署名を取得する時に利用するAppRequestペイロード形式を標準化しようというものです。
- [\[ACP77\] バリデータ管理をL1に移す仕組みを理解しよう！](https://cardene.dev/articles/3c28cdfe275253b75da5.md): ACP77は、Subnetsの作成と運用のしやすさ・柔軟性を高めるため、以下の3つを提案しています。
- [\[ACP13\] Subnet専用Validatorの仕組みを理解しよう！](https://cardene.dev/articles/fb5625058f8ff4bc9bc0.md): ACP13では「Subnet-Only Validators（SOVs）」という新しいタイプのバリデータを導入することが目的です。
- [\[ACP103\] Avalanche P-Chainの動的手数料の仕組みを理解しよう！](https://cardene.dev/articles/347024f238de4641e7b3.md): ACP103は、Avalanche の P-Chain（プラットフォーム管理を担うチェーン。
- [ERC20トークンを秘匿化して送付できるEncrypted ERC](https://cardene.dev/articles/0e7aa66aa2165c.md): Encrypted ERCは、プライバシー重視で設計されたERC20トークンと互換性がある新しいトークンの仕組みです。

## Blockchain / Account Abstraction

- [\[EIP8130\] Account ConfigurationでネイティブAAを実現する仕組みを理解しよう！](https://cardene.dev/articles/6c030864f527b9dfc24b.md): EIP8130は、アカウント抽象化をネイティブトランザクションとして扱うための提案です。
- [\[ERC7895\] ユニバーサルウォレットがアプリ専用アカウントを配下に持つ仕組みを理解しよう！](https://cardene.dev/articles/fe31f16bde567a894509.md): ERC7895は、アプリがウォレットに対して「このアカウントをあなたの配下アカウントとして扱ってほしい」と要求するためのRPCである wallet_addSubAccount を定義する提案です。
- [\[ERC7902\] Wallet Call APIでアカウント抽象化向けの追加設定を受け渡す仕組みを理解しよう！](https://cardene.dev/articles/1b92b39d97ea7bf39730.md): ERC7902は、EIP5792のCapability機構を使って、アカウント抽象化で必要になる追加パラメータをdAppからウォレットへ渡すための提案です。
- [\[ERC8000\] EIP7702を使わずEOAでバッチ実行を可能にするOperatorコントラクト](https://cardene.dev/articles/4820b6c4b4377b185f71.md): ERC8000は「Operator」と「Operated」という2つのコンポーネントで構成されています。
- [\[ERC7947\] スマートアカウントの鍵を失っても復旧できるリカバリインターフェースの仕組みを理解しよう！](https://cardene.dev/articles/1c6a92923bdb541d6c36.md): ERC7947は、Account Abstraction Recovery Interface（AARI）と呼ばれるスマートアカウント向けのリカバリインターフェースです。
- [\[ERC7988\] EIP7702のコード委任を活用した最小構成スマートウォレットMASWの仕組みを理解しよう！](https://cardene.dev/articles/310fd0501317fa06d44d.md): ERC7988とは、Minimal Avatar Smart Wallet（MASW）と呼ばれる、EIP7702のコード委任メカニズムを利用した最小構成のスマートウォレット規格です。
- [\[ERC7780\] スマートアカウントの署名検証とポリシー判定を分離するモジュール拡張の仕組みを理解しよう！](https://cardene.dev/articles/43b8f85e31dc6794888d.md): ERC7780は、ERC7579のモジュールシステム上に6つの新しいモジュールタイプを導入する提案です。
- [\[ERC7582\] コントラクトアカウントの検証処理を外部コントラクトに委譲する仕組みを理解しよう！](https://cardene.dev/articles/c96b38d4ddcea3783106.md): ERC4337は、アカウント（ウォレット）をスマートコントラクトとして実装するための仕組みを提案している規格です。
- [\[ERC7522\] OIDCとZKを組み合わせてスマートアカウントを保護する仕組みを理解しよう！](https://cardene.dev/articles/d89b7032b47d72b280cd.md): ERC4337は、スマートアカウントの柔軟な拡張を可能にするAccount Abstraction（アカウント抽象化）の仕組みを利用することで、従来の秘密鍵だけに依存しない認証やリカバリー方法を実現します。
- [\[ERC7484\] スマートアカウントがモジュールを安全に扱う仕組みを理解しよう！](https://cardene.dev/articles/aad1c1a343ed78caf740.md): ERC4337は、コントラクトアカウントの実行フローを標準化し、ERC7579はそれらを構成するモジュールを組み合わせて使える仕組みを標準化しています。
- [\[ERC7405\] スマートコントラクトアカウントを自由に移行できる仕組みを理解しよう！](https://cardene.dev/articles/9fe3c86ba95bdd4ea15d.md): Portable Smart Contract Accounts（PSCA）は、スマートコントラクトアカウント（SCA）が抱える「他のウォレットへ移行できない」という問題を解消する仕組みです。
- [\[ERC7093\] 柔軟にリカバリーポリシーを設定できる仕組みを理解しよう！](https://cardene.dev/articles/6a6726e5f64ab10fa794.md): ERC7093は、スマートコントラクトアカウントの「ソーシャルリカバリー」（本人が鍵を失った時、信頼できる人たちの協力でアカウントを復旧する仕組み）を標準化するためのインターフェイスを定義します。
- [\[ERC6981\] 予約型スマートアカウントの仕組みを理解しよう！](https://cardene.dev/articles/b109e6026ac718651652.md): ERC6981は、外部サービスのユーザーに対して「後から取り出せる形でのEthereumアドレス」を紐づけられる仕組みを提案しています。
- [\[ERC7739\] EOAが複数スマートアカウントを管理する時の署名保護の仕組みを理解しよう！](https://cardene.dev/articles/6bef153574454340c17c.md): ERC7739は、1つの外部所有アカウント（Externally Owned Account, EOA）が複数のスマートアカウントを管理している場合に発生する「署名のリプレイ攻撃」を防ぐための標準を定義しています。
- [\[ERC7766\] ERC4337の署名集約の仕組みを理解しよう！](https://cardene.dev/articles/edda29b011254d3722d6.md): ERC4337は、Ethereum上でAccount Abstractionを実現する仕組みを提案していて、標準のトランザクション処理とは別の「UserOperation mempool」を用いることで、柔軟なトランザクション実行を可能にし
- [\[ERC4950\] コントラクトアカウントの機能つきNFTの仕組みを理解しよう！](https://cardene.dev/articles/5adc379d4a42e57da569.md): ERC4950は、スマートコントラクトウォレットの操作権限を、ペアになった2つのERC721トークンを使って委任（デリゲート）するインターフェースを提案しています。
- [\[ERC5005\] コントラクトアカウントをモジュール構成にできる仕組みを理解しよう！](https://cardene.dev/articles/ba594a44aa1250f21d33.md): ERC5005は、Ethereum上でのプログラマブルアカウントに関するツールをより柔軟かつ相互運用可能にするためのインターフェース標準を提案しています。
- [\[ERC7769\] ERC4337に準拠したコントラクトアカウントのためのJSON-RPC APIを理解しよう！](https://cardene.dev/articles/0b6d631ed4363ba67d2a.md): ERC7769では、新しいJSON-RPC APIメソッドを定義してERC4337に準拠したコントラクトアカウントがUserOperationのmempoolノードやバンドラー（bundler）と通信できるようにする仕組みを提案しています。
- [\[ERC7562\] Account Abstractionのトランザクション検証ルールについて理解しよう！](https://cardene.dev/articles/213a17c8dd12a29f8f2c.md): ERC7562では、Account Abstractionのトランザクションの検証フェーズで守るべきルールについて提案しています。
- [\[ERC7821\] EIP7702を利用したバッチトランザクションの仕組みを理解しよう！](https://cardene.dev/articles/7ee723c7d9ae6b270879.md): ERC7821は、デリゲーションのための最小限のバッチ実行インターフェースを提案しています。デリゲーションとは、あるコントラクトが他のコントラクトに対して実行ロジックを提供する仕組みです。
- [\[ERC7803\] Account Abstraction向けにEIP712を拡張する仕組みを理解しよう！](https://cardene.dev/articles/4a49ea89e08c709d679e.md): ERC7803は、EIP712の署名方式を改良してコントラクトアカウントに適した形にすること仕組みを提案しています。
- [\[ERC7579\] 最小限のモジュラースマートアカウントの仕組みを理解しよう！](https://cardene.dev/articles/369c641b2ed168637075.md): ERC7579は、モジュール型のコントラクトアカウントおよびそのモジュール間の相互運用性を確保するために必要な最小限のインターフェースと動作仕様を定義しています。
- [\[ERC7679\] ERC4337のUserOperationを標準化する仕組みを理解しよう！](https://cardene.dev/articles/4a66dbe19e76ab5b5b7e.md): ERC4337コントラクトアカウントの実装では、署名、nonce、calldata（呼び出しデータ）のエンコード方法が異なります。
- [\[ERC7677\] アプリが特定のPaymasterサービスと通信する仕組みを理解しよう！](https://cardene.dev/articles/0e7a75a5d98654b0f3d2.md): EIP5792は、アプリがウォレットと通信して高度な機能を利用できるようにする提案です。この提案では、アプリがERC4337ウォレットに特定のPaymasterサービスと通信するようにリクエストできる機能を定義しています。
- [\[ERC7597\] コントラクトウォレットからの署名をもとにPermitを実行する仕組みを理解しよう！](https://cardene.dev/articles/0cb50137f1f0adc219c6.md): この規格はERC2612という既存の企画を拡張して、ERC20トークンをガスレスで送付することをコントラクトウォレットから実行する仕組みを提案しています。
- [\[ERC7638\] コントラクトアカウントからのトランザクションバッチ処理を効率よく実行する仕組みを理解しよう！](https://cardene.dev/articles/1e2240e32bb4bbcd000a.md): バッチコールエンコーディング（Batch Calls Encoding = BCE）は、スマートコントラクトアカウント（Smart Contract Account = SCA） ウォレットからのトランザクションを1つのトランザクションにま
- [\[EIP7702\] EOAをコントラクトアカウントに変換する仕組みを理解しよう！](https://cardene.dev/articles/13a828c97786aab953e4.md): この規格では、contract_codeフィールドと署名を追加し、署名アカウント（tx.originと同じとは限らない）をトランザクション期間中スマートコントラクトウォレットに変換する新しいトランザクションタイプを追加します。
- [\[EIP2938\] ERC4337につながるアカウント抽象化の提案を理解しよう！](https://cardene.dev/articles/baf4c07631756b35dcf0.md): アカウント抽象化（Account Abstraction, AA）は、イーサリアムネットワークの取引とアカウントの管理方法を革新的に改善する提案です。
- [\[EIP7377\] EOAアカウントからコントラクトアカウントへの移行を効率的に行う仕組みを理解しよう！](https://cardene.dev/articles/618d07652c73fcfe9bd5.md): EIP2718（Ethereum Improvement Proposal 2718）は、Ethereumのトランザクション構造を拡張するための提案で、新しいトランザクションタイプを導入することで、さまざまな機能や拡張性の向上を図るものです
- [\[EIP3074\] 2つの新しい命令を追加しコントラクトにEOAの制御を委任する仕組みを理解しよう！](https://cardene.dev/articles/f55a6d2df6d13030e20e.md): EIP（Ethereum Improvement Proposal、イーサリアム改善提案）におけるこの提案は、EVM（Ethereum Virtual Machine、イーサリアム仮想マシン）に新たな命令セット「AUTH」と「AUTHCAL
- [\[ERC7564\] コントラクトウォレットでNFTを管理し特有の関数を追加する仕組みを理解しよう！](https://cardene.dev/articles/a3979363a66d3f2d0a5e.md): この提案は、NFT（Non-Fungible Tokens、非代替トークン）の管理にスマートコントラクトウォレットを使用する新しいアプローチを紹介しています。
- [\[ERC7561\] コントラクトウォレット用に設計された新たなERC721規格の仕組みを理解しよう！](https://cardene.dev/articles/0c375ccd106ec9df4b9f.md): 新しいタイプのNFT(非代替トークン)アセットに関する提案です。
- [\[ERC7204\] コントラクトウォレットでの使用を想定したより安全で柔軟なトークン管理の仕組みを理解しよう！](https://cardene.dev/articles/5d8732733b473166194c.md): この提案は、トークン管理におけるコントラクトウォレットの活用を中心においています。コントラクトウォレットはプログラム可能で、その特性を利用して資産管理をより適応性が高く、安全で、効率的なものにすることを目指しています。
- [\[ERC7196\] コントラクトウォレットに最適化させたERC20の仕組みを理解しよう！](https://cardene.dev/articles/6c7909fe161a7d97aab6.md): このERC（イーサリアムリクエストコメント）は、コントラクトウォレット（アカウント抽象化を含む）に基づいて設計された新しい資産であり、ERC20との互換性を保持しつつ、ERC20のtransferFrom、approve、allowance
- [\[ERC6662\] ERC4337を拡張した認証データ管理の仕組みを理解しよう！](https://cardene.dev/articles/2a28b56522466bf993f5.md): ERC4337は、Ethereumのアカウント抽象化に関する提案であり、ユーザーがウォレットアカウントのセキュリティや使用性をカスタマイズできるようにするスマートコントラクトウォレットの標準を提供します。
- [\[ERC4972\] ENSにコントラクトアカウントを紐づける仕組みを理解しよう！](https://cardene.dev/articles/64bdb724a083550e0903.md): Ethereum Name Service（ENS）は、Ethereumブロックチェーン上で動作する分散型の名前解決サービスです。
- [\[ERC6492\] デプロイされていないコントラクトアカウントで署名検証する仕組みを理解しよう！](https://cardene.dev/articles/019072f96b73939a047d.md): ERC1271は、ブロックチェーン上のコントラクトで署名を確認するためのルールです。
- [\[ERC5189\] プロトコルの変更をせずにより少ない制約でAccount Abstractionを実装する仕組みを理解しよう！](https://cardene.dev/articles/f7dcf09d693a84f5dacb.md): このEIPは、イーサリアムネットワークのスマートコントラクトウォレットの仕組みを新しいレベルに引き上げようとしています。具体的には、アカウント抽象化（AA）という技術を用いて、ウォレットの機能性と柔軟性を高めることを目指しています。
- [\[ERC7521\] コントラクトウォレットで新しいインテント規格に簡単に対応できる仕組みを理解しよう！](https://cardene.dev/articles/f9468a5fe68c1a123574.md): この内容は、新しいインテント規格に対応するための汎用的なエントリーポイントコントラクトに関するものです。
- [\[ERC6900\] MSCA（モジュラースマートコントラクトアカウント）の仕組みについて理解しよう！](https://cardene.dev/articles/cae5f7ae2dd86d373b27.md): この提案は、スマートコントラクトアカウントと、そのアカウント内で使える「プラグイン」と呼ばれるコードのインターフェースを標準化しようとするものです。
- [\[ERC6551\] NFTにスマートコントラクトアカウントを与えるトークンバウンドアカウントの仕組みについて理解しよう！](https://cardene.dev/articles/8a0e50b939e0c95f3592.md): 非代替トークン（NFT）という特別な種類のデジタルアセットを考えてみましょう。NFTは、個々のアイテムやアートなどをオンラインで一意に識別するために使用されます。
- [\[ERC4337\] プロトコルの変更をせずにAAを実装する仕組みを理解しよう！](https://cardene.dev/articles/8c97ca7c93c4557ebfc2.md): ERC4337は、Ethereumのコンセンサス層（プロトコルの最下層）を一切変更せずにアカウント抽象化（Account Abstraction）を実現するための仕組みを提案しています。

## Blockchain / Wallet

- [\[ERC7811\] ウォレットが保有資産をDAppへ返す仕組み](https://cardene.dev/articles/2d38e0bb596ab06f8500.md): DAppがERC20トークンの残高を読む場合、通常はトークンコントラクトのアドレスを知ったうえで balanceOf 関数を呼び出します。しかし、この方法では、DAppがまだ知らないトークンコントラクトを見つけられません。
- [\[ERC7721\] ERC-1155をウォレットに残したままロックする仕組み](https://cardene.dev/articles/608f3c6858439c290d42.md): ERC-7721は、ERC-1155へロックと解除の操作を追加する拡張です。ロックされた数量は保有者のERC-1155残高に残りますが、通常の送付で動かせる数量から除かれます。
- [\[ERC7946\] ウォレット接続なしでQR/NFCからバッチトランザクションを実行するUWULinkの仕組みを理解しよう！](https://cardene.dev/articles/74cb1edb51abdcb19b29.md): ERC7946は、Universal Wallet Uplink（UWULink）と呼ばれるプロトコルです。
- [\[ERC7795\] dAppsがウォレットにトークン前提条件を指定できるWallet Call Token Capabilitiesの仕組みを理解しよう！](https://cardene.dev/articles/eab82f94332e974f2c5d.md): ERC7795とは、EIP5792のwallet_sendCallsメソッドを拡張し、dAppsがウォレットに対してトークンに関する前提条件を指定できるようにする仕組みのことです。
- [\[ERC8128\] ウォレットの署名だけでAPI認証を完結させる仕組みを理解しよう！](https://cardene.dev/articles/2ea3b9cb21612b1b8b3e.md): ERC8128は、Ethereumアカウントを使ってHTTPリクエストに暗号署名を付与し、リクエストの認証と整合性を保証する仕組みです。
- [\[ERC7795\] dAppsがウォレットにトークン前提条件を指定できるWallet Call Token Capabilitiesの仕組みを理解しよう！](https://cardene.dev/articles/09d6129ec75b598cb0c0.md): ERC7795とは、EIP5792のwallet_sendCallsメソッドを拡張し、dAppsがウォレットに対してトークンに関する前提条件を指定できるようにする仕組みのことです。
- [\[EIP5792\] 複数のオンチェーン呼び出しをバッチ送信するWallet Call APIの仕組みを理解しよう！](https://cardene.dev/articles/59d6b2ae4c64c1a6614d.md): EIP5792は、アプリケーションがウォレットに対して複数のオンチェーン呼び出し（call）をバッチとして送信し、そのステータスを確認するための新しいJSON-RPCメソッドを定義する提案です。
- [\[ERC7754\] Dappとウォレット間通信を改ざんから守る仕組みを理解しよう！](https://cardene.dev/articles/efc02d5c74fc27fd557c.md): ERC7754は、ウォレットとDapp（分散型アプリケーション）の間の通信を改ざんできない形で行うための仕組みを定義しています。
- [\[ERC7730\] ウォレットで署名内容を正しく確認する仕組みを理解しよう！](https://cardene.dev/articles/a136e1d935a5b1ee56b5.md): ERC7730は、ウォレット画面で人間が内容を正しく確認できる形で表示したり、トランザクションシミュレーターなどの機械が意味を理解できる形で処理したりするために必要な「追加の意味情報」をJSON形式で定義する仕様です。
- [\[ERC7715\] ウォレットがDAppに実行権限を委ねる仕組みを理解しよう！](https://cardene.dev/articles/7b4792f84798c9cee323.md): ERC7715は、DApp（分散型アプリケーション）がウォレットに対して「特定の権限を付与してほしい」と要求するための、新しいJSON-RPCメソッドである wallet_grantPermissions を定義します。
- [\[EIP5792\] ウォレットで複数オンチェーン処理をまとめて扱う仕組みを理解しよう！](https://cardene.dev/articles/e958a08b4cbdfc1e98df.md): EIPC5792は、ウォレットとアプリケーション（DApp）がやり取りするための新しいJSON-RPCメソッド群を定義しています。
- [\[EIP6963\] ブラウザに注入されたウォレットを正しく選ぶ仕組みを理解しよう！](https://cardene.dev/articles/f8949690d54b9d02362e.md): EIP6963は、Webページ上で複数のウォレットプロバイダーを安全かつ公平に発見するための仕組みです。
- [\[ERC5630\] Ethereumウォレットで暗号化と復号化を行う仕様を理解しよう！](https://cardene.dev/articles/af371c36c15728a3a3f9.md): ERC5630は、Ethereumの鍵（アカウントが持つ秘密鍵/公開鍵の組）を使って暗号化と復号を行う新しい方法を提案しています。
- [\[ERC7908\] 子会社や部門を安全に管理するHDウォレットの仕組みを理解しよう！](https://cardene.dev/articles/ccb8ca8b5a41e63b8176.md): ERC7908は、ブロックチェーン上での企業・組織向け資産管理（オンチェーン・トレジャリー管理）を標準化することを目的としています。
- [\[ERC6809\] 3つのウォレットでNFTを安全に管理するNFKBTの仕組みを理解しよう！](https://cardene.dev/articles/e556d2660fd04338ef21.md): Non-FungibleKeyBoundToken（NFKBT）は、KeyBoundToken（KBT＝鍵に紐付くトークンという総称）の一種で、ERC721との互換性を保ちつつ「資産そのものに任意で付与できるセキュリティ」を備えるためのイン
- [\[EIP2256\] ウォレット内の資産を取得できるJSON-RPCの仕組みを理解しよう！](https://cardene.dev/articles/f8d57814faa887cb6f7e.md): EIP2256は、Ethereumのウォレットからユーザーが保有している資産（トークンやNFTなど）の一覧を取得するための新しいJSON-RPCメソッド wallet_getOwnedAssets を定義するものです。
- [\[BIP44\] 階層型ウォレット構造の仕組みを理解しよう！](https://cardene.dev/articles/031a610d87ac89b71617.md): BIP44は、BIP0032（以降BIP32）で定義されたアルゴリズムと、BIP0043（以降BIP43）で定義された目的（purpose）スキームに基づき、決定性ウォレット（Deterministic Wallet）のための論理的な階層構
- [\[BIP39\] 単語でウォレットを復元する仕組みを理解しよう！](https://cardene.dev/articles/58f7c40a8441cadc608f.md): BIP39は、「ニーモニックコード」あるいは「ニーモニックセンテンス」と呼ばれる仕組みを導入しています。これは、ある種の意味を持った単語の列（英単語など）を使って、人間にとって記憶しやすくしたウォレット復元用の情報を表現する手法です。
- [\[SLIP0010\] 複数曲線に対応するHDウォレットの仕組みを理解しよう！](https://cardene.dev/articles/8915db5813cf3e2ec3c4.md): SLIP0010（Slip Improvement Proposal 0010）は、階層的決定性ウォレット（HDウォレット）において、さまざまな種類の楕円曲線（secp256k1、NIST P-256、ed25519、curve25519）
- [\[BIP32\] 階層的に鍵を導出するHDウォレットの仕組みを理解しよう！](https://cardene.dev/articles/9d4376d124d2f50778c2.md): HDウォレット（Hierarchical Deterministic Wallet）は、ひとつのシード（種）から複数の鍵ペア（公開鍵と秘密鍵）を階層的に生成できる仕組みを持つウォレットです。
- [\[ERC1193\] Ethereum Provider APIの仕組みを理解しよう！](https://cardene.dev/articles/9e796da49299f57bd5c7.md): Ethereumの分散型アプリケーション（dapp）では、ユーザーの秘密鍵やアカウントを管理するための「ウォレット」と呼ばれるソフトウェアがよく使われています。
- [\[EIP85\] トークンアドレスからHDウォレットパスを導く仕組みを理解しよう！](https://cardene.dev/articles/af5d53ac31897721b225.md): Ethereumやそのトークンを扱うウォレットにおいて、アドレスの階層的な生成方法（HDウォレット）を標準化することは、ユーザーにとっての一貫性や相互運用性を確保する上で重要です。
- [\[SLIP0044\] HDウォレットで通貨を分けて管理する仕組みを理解しよう！](https://cardene.dev/articles/cfbb0cbee7062553e599.md): BIP0044は、階層的決定性ウォレット（HDウォレット）のための論理的な構造を定義した仕様です。BIP0044では、ウォレット内でどのように鍵を整理し、異なる目的ごとに安全に使い分けるかを規定しています。
- [\[SLIP0013\] サービスごとの安全な鍵導出の仕組みを理解しよう！](https://cardene.dev/articles/fe0c6b721bd447216223.md): SLIP0013では、Webサイトやリモートシェル（SSHなど）への認証を行うための方法として、「決定性階層（Deterministic Hierarchy）」を利用する仕組みについて説明されています。
- [\[ERC1775\] アプリ専用鍵「App Key」の仕組みを理解しよう！](https://cardene.dev/articles/14e6316fc4dec45b9d55.md): Ethereumブロックチェーンにおいて、スケーラビリティやプライバシーを向上させるためのアプリケーションでは、ユーザーが大量の署名操作を行う必要があります。
- [\[ERC1102\] Ethereumアカウントを安全にサイトに接続する仕組みを理解しよう！](https://cardene.dev/articles/3d1c6d38f21c0289b07e.md): ERC1102は、dApp（分散型アプリケーション）とEthereumに対応したDOM環境（例えば、ブラウザの拡張機能）との間で、安全に情報をやり取りするための通信プロトコルを定義するものです。
- [\[EIP2333\] ポスト量子時代に備えるBLS鍵導出の仕組みを理解しよう！](https://cardene.dev/articles/99a51a2a78f3b774b400.md): EIP2333は、1つのエントロピーソース（乱数を生成するための元データ）からツリー構造を用いてBLS秘密鍵を導出するための方式を提案しています。
- [\[ERC2386\] Ethereum 2のHDウォレット保存形式の仕組みを理解しよう！](https://cardene.dev/articles/a7a9d28e8b70076c1882.md): ERC2386は、Ethereum 2.0における階層的決定性（HD: Hierarchical Deterministic）ウォレットの定義情報を保存・取得するためのJSON形式を標準化する提案をしています。
- [\[ERC2680\] Ethereumウォレットとキーストアの保存形式の仕組みを理解しよう！](https://cardene.dev/articles/820ef2f7042ecd4ecd9d.md): Ethereumウォレットに関して、現在はウォレットやキーストアの保存場所やファイル名の標準が存在しません。そのため、異なるソフトウェア同士で同じウォレットや鍵を共有・再利用することが困難です。
- [\[ERC4527\] QRコードを使用してネットワークから隔離された署名デバイスと閲覧のみ可能なウォレットを接続する仕組みを理解しよう！](https://cardene.dev/articles/df0ab875352662485f4c.md): ERC4527は、オフライン署名デバイス（ハードウェアウォレットや通信を切ったスマートフォンなど）と閲覧のみ可能なウォレットとの間で、QRコードを使って安全にデータをやり取りするための手順とプロトコルを定める提案をしています。
- [\[ERC7682\] ウォレット外の追加資金をアプリケーションに教える仕組みを理解しよう！](https://cardene.dev/articles/6dddb2a77dee47f6160c.md): EIP5792に準拠した機能により、ウォレットアドレスの残高を参照できます。この時、ウォレット内にある資金しか使用できません。
- [\[EIP5792\] バッチトランザクションを実行するJSON-RPCメソッドの仕組みを理解しよう！](https://cardene.dev/articles/45da7ebe31ff0ee860a2.md): この規格では新しいJSON-RPCメソッドを定義しています。これにより、アプリケーションはMetamaskなどのウォレットにデータ更新のバッチ処理をリクエストし、それらのステータスを確認できます。
- [RemixでWallet Connectを使用してコントラクト開発しよう！](https://cardene.dev/articles/3903c469ffff87.md): まずはRemixのページを開きましょう。
- [\[ERC7521\] コントラクウォレットに対応した新しいIntent標準の仕組みを理解しよう！](https://cardene.dev/articles/313a5f76214e2f356cfa.md): ブロックチェーン技術、特にスマートコントラクトを使用してユーザーの意図（UserIntent）を効率的に処理する新しい方法について述べています。
- [\[EIP3085\] ウォレットに新しいチェーンを追加する標準インターフェースの仕組みを理解しよう！](https://cardene.dev/articles/81eb33376fcee9dfebd9.md): イーサリアムのウォレットに新しいチェーン（ブロックチェーンネットワーク）を追加するための標準的な方法を提供する提案です。
- [\[EIP2700\] JavaScriptJavaScriptクライアントへEthereumの状態変化を通知する標準の提案を理解しよう！](https://cardene.dev/articles/bff71aec3f8c45c10a85.md): JavaScriptで作成されたアプリケーションがEthereumのプロバイダー（Ethereumと通信を行うためのサービスやソフトウェア）からチェーンの状態変化についての通知を受け取るための仕組みの標準化について説明しています。
- [\[EIP2696\] Ethereum通信のためのJavaScript標準インターフェースの提案を理解しよう！](https://cardene.dev/articles/fe9aeb070699649072a5.md): この標準は、Ethereumプロバイダー（Ethereumブロックチェーンとの通信を提供するもの）とEthereumクライアント（Ethereumブロックチェーンに接続するもの）の間でのリモート手続き呼び出し（RPC）を定義しています。
- [\[EIP747\] ウォレット内で資金を簡単に追跡できる機能の追加提案を理解しよう！](https://cardene.dev/articles/a91b5578311872b30172.md): 新しいウォレット向けのRPC(Remote Procedure Call)メソッド、wallet_watchAssetの標準化に関するEIPです。
- [\[ERC1328\] アプリとウォレットを接続するURIフォーマットの仕組みを理解しよう！](https://cardene.dev/articles/7e0d5d7a019866bef8d7.md): この規格は、アプリ（ソフトウェア）とウォレット（お金や仮想通貨を管理する財布）を繋ぐための情報を、URIという特別なアドレス形式でどう書くかを決めています。
- [\[ERC601\] Bitcoinを参考にした新しいEthereumのウォレット生成の仕組みを理解しよう！](https://cardene.dev/articles/a29e84d0c12815d2ef9d.md): このEIP（イーサリアム改善提案）は、イーサリアムのウォレットをもっと効率的に作るための新しいルールを提案しています。このルールは、ビットコインのBIP32という提案と、BIP43という別の提案をベースにしています。
- [\[ERC600\] BIP32の仕組みをEthereumに適用する仕組みを理解しよう！](https://cardene.dev/articles/1a0a0e50c77c7c3be091.md): このEIP（イーサリアム改善提案）は、ビットコインのBIP32（ビットコイン改善提案32）に基づく決定論的ウォレット（Deterministic Wallet）の階層構造をイーサリアムに適用するものです。
- [\[ERC5568\] ウォレットに何らかのアクションが必要であることを通知する仕組みを理解しよう！](https://cardene.dev/articles/0645beb4327317d388b7.md): このERC（Ethereum Request for Comment）は、ブロックチェーン上での取引や操作に関する情報をウォレットに伝えるためのルールの一部です。

## Blockchain / Gas

- [\[EIP8032\] コントラクトのストレージ量に応じてSSTOREガスを変える仕組みを理解しよう！](https://cardene.dev/articles/028725c801d0e8e20824.md): EIP8032は、SSTORE（コントラクトのストレージへ値を書き込むEVM命令）のガスコストをコントラクト単位のストレージ量に連動させるコア提案です。
- [\[EIP8141\] トランザクションの認証・実行・ガス支払いを自由に組み立てる Frame Transactionの仕組み](https://cardene.dev/articles/cb88aaf5731a50c96d9d.md): Frame Transactionのコアとなるアイデアは、1つのトランザクションを複数の「フレーム」に分割するということです。各フレームは独立した実行単位であり、それぞれが「このフレームは何のためにあるか」を示すモードを持っています。
- [\[EIP7971\] Transient Storageのガスコストを下げてハードリミットで安全性を確保する仕組みを理解しよう！](https://cardene.dev/articles/a64552dad4f19467c56e.md): EIP7971とは、EIP1153で導入されたTransient Storage（トランザクション実行中だけ存在する一時的なストレージ）のガスコストを引き下げ、同時にトランザクション全体で使用できるスロット数に上限（ハードリミット）を設ける
- [\[EIP8062\] 0x01バリデータのsweep引き出しに手数料を課してステーク統合を促す仕組みを理解しよう！](https://cardene.dev/articles/61f15547b3c97f9642d7.md): EIP8062は、0x01クレデンシャルを持つバリデータの部分的な「sweep」引き出し（残高が32 ETHを超えた分の自動引き出し）に対して、引き出し額の0.05%の手数料を課す提案です。
- [\[ERC7968\] 第三者がガス代を負担する安全なトークン送付の仕組みを理解しよう！](https://cardene.dev/articles/92eb3b2599cfd4f38792.md): ERC7968は、第三者がEthereum上で発行されるトークン（例：ERC20）を安全かつスムーズに利用できるようにする、新しいトークン送付処理モデルを提案しています。
- [\[EIP2200\] SSTOREのガス削減提案の仕組みを理解しよう！](https://cardene.dev/articles/2131ee7da551ec6a5ce9.md): EIP2200は、Ethereumにおけるスマートコントラクトのストレージ操作（SSTORE オペコード）に対するガスコストの計算方法を見直す提案です。
- [\[EIP1884\] 処理負荷の高いオペコードのガス価格を見直す仕組みを理解しよう！](https://cardene.dev/articles/2bbb79e2b67325b0ee7e.md): EIP1884は、Ethereum上で動作するいくつかのオペコード（EVMが実行する命令）のガス価格を見直すことを提案しています。
- [\[EIP1706\] SSTOREの2300ガス制限の仕組みを理解しよう！](https://cardene.dev/articles/cd5c5b7b7a668624e1c8.md): EIP1706は、すでに稼働している多くのスマートコントラクトに影響を与えるEthereumネットワークの仕様変更に対して、安全性を維持するための対策を目的としています。
- [\[EIP1283\] SSTOREのガス最適化の仕組みを理解しよう！](https://cardene.dev/articles/eb4eee35e5a2716f632a.md): EIP1283では、SSTORE（ストレージ書き込み）命令に関するガスメータリングの仕組みを見直す提案が行われています。
- [\[EIP1087\] ストレージ書き込みのガス節約の仕組みを理解しよう！](https://cardene.dev/articles/6f2886262667837f7011.md): EIP1087は、EVMにおけるSSTORE操作、つまりストレージへの書き込み処理にかかるガスコストの仕組みを見直す提案です。
- [\[EIP4762\] Verkleツリー対応に向けた新ガスモデルの仕組みを理解しよう！](https://cardene.dev/articles/e057fa94905ac9ff0a4f.md): EIP4762は、Ethereumにおけるガススケジュールの変更を提案するものです。主な目的は、「witness（証明データ）」の生成にかかる計算コストをガスコストに正確に反映させることです。
- [\[EIP7623\] calldataのガスコスト増加の仕組みを理解しよう！](https://cardene.dev/articles/7c755812eccfe88e7d51.md): 現在のEthereumでは、トランザクションに含まれるcalldata（コールデータ）のコストが比較的低く設定されており、その結果として最大7.15MBものEL（Execution Layer）ペイロードがブロックに含まれる可能性があります
- [\[EIP1559\] Ethereumの新たなガス価格設定メカニズムを理解しよう！](https://cardene.dev/articles/ce77124940010280717b.md): そもそもガス代についてあまり理解していない方向けに簡単に特徴だけ説明します。
- [\[EIP3860\] initcodeに対してサイズの制限とガスコストを課す提案を理解しよう！](https://cardene.dev/articles/df8d2a331482e6b7c66b.md): EIP170は、Ethereumのスマートコントラクトのコードサイズに上限を設ける提案です。
- [\[EIP3529\] ガス代の返金を削減する提案を理解しよう！](https://cardene.dev/articles/3acae2ad02efc0fac5ec.md): Ethereumのブロックチェーンでは、トランザクションを処理するために「ガス」と呼ばれる単位が使われます。トランザクションにはさまざまな種類があり、それぞれ異なる量のガスを消費します。
- [\[EIP3198\] 現在のブロックの基本手数料を直接取得できる提案を理解しよう！](https://cardene.dev/articles/ac0b538fc97840eb990d.md): Ethereum Virtual Machine (EVM) に関連する命令コード（opcode）の追加について説明しています。具体的には、BASEFEE（0x48として表される）という新しいopcodeを追加する提案です。
- [\[EIP2929\] 特定のオペコードを使用する時のガスコストを増加させる提案を理解しよう！](https://cardene.dev/articles/ca94d8fd0159bb3cc9fb.md): Ethereumブロックチェーンでは、トランザクションを実行する時にさまざまなオペコードが使用されます。オペコードとは、ブロックチェーンのスマートコントラクト内で行われる特定の操作を指示するためのコードです。
- [\[EIP2565\] ModExpプリコンパイルのガスコストに関する提案について理解しよう！](https://cardene.dev/articles/339d85d2e550fdd67243.md): イーサリアムのブロックチェーン上で実行される特定の計算操作、ModExp プリコンパイルのガスコストをどのように定めるかについて説明しています。
- [\[EIP2028\] Calldataのガスコストを削減する提案について理解しよう！](https://cardene.dev/articles/8fb1dea76c23122fb7c7.md): ブロックチェーンにおける特定のデータ送信コスト、具体的には「Calldata（GTXDATANONZERO）」と呼ばれる部分のガスコスト（ブロックチェーンの取引を行う時にかかる手数料の単位）を現在の1バイトあたり68ガスから16ガスに大幅に
- [\[EIP160\] EXPオペコードのガスコストを増加させる提案を理解しよう！](https://cardene.dev/articles/865cb73db25da3fc23f3.md): 「block.number >= FORK_BLKNUM」という条件の下で、EXP命令（指数計算を行う命令）のガスコスト（実行コスト）を変更することを提案しています。
- [\[EIP150\] オペコードのガスコストを増加させる提案を理解しよう！](https://cardene.dev/articles/38750e8f3708f86bbb7a.md): イーサリアムのようなブロックチェーンネットワークでのトランザクション処理に関わる変更点について説明しています。これらの変更は、特定のブロック番号（FORK_BLKNUM）を超えた後に適用されることが想定されています。
- [\[EIP5\] 使用したメモリに対してのみガス代を支払う仕組みを理解しよう！](https://cardene.dev/articles/6c666cba3523af2d7ce5.md): このEIP（Ethereum Improvement Proposal）は、Ethereum Virtual Machine（EVM）内で、文字列やその他の動的サイズ配列を返す関数を呼び出せるようにするための提案です。
- [\[ERC1167\] コントラクトを簡単にガス効率良く複製する仕組みを理解しよう！](https://cardene.dev/articles/85f77603ed33e3eaab07.md): この規格は、コントラクト機能を効率的かつコスト効率よく「複製」するための仕組みについて提案しています。この方法では、あるコントラクトが他の特定のコントラクトの機能を使えるようにし、それを標準化することを目的にしています。
- [\[ERC6982\] ガス効率よくNFTをロックする仕組みを理解しよう！](https://cardene.dev/articles/db2d57fee096f3282e5e.md): この提案は、ERC721トークンのロック可能なインターフェースを導入し、不要なイベントを省いてガスの使用効率を向上させるものです。このインターフェースは、ロック可能なERC721トークンの作成と管理の基盤を提供します。
- [\[ERC2771\] ガス代を他のアドレスに負担させるメタトランザクションの仕組みを理解しよう！](https://cardene.dev/articles/e84f53471b7a79240f33.md): このEIPは、新しい方法でEthereumのコントラクト間で通信する仕組みを提案しています。具体的には、メタトランザクションと呼ばれるもので、コントラクトが別のコントラクトに対して操作を実行できるようになります。

## Blockchain / Signature

- [\[EIP8030\] P256署名をEIP7932の署名アルゴリズムとして扱う仕組みを理解しよう](https://cardene.dev/articles/512c25f692edcfa298d0.md): EIP8030は、新しいトランザクション型や新しいP256検証プリコンパイルを定義する提案ではありません。役割は、EIP7932の署名アルゴリズムレジストリに「P256をどう扱うか」を追加することです。
- [\[EIP7951\] secp256r1プリコンパイルでApple Secure EnclaveやPasskeyをEthereumに繋ぐ仕組みを理解しよう！](https://cardene.dev/articles/a55db75ffbc68801d968.md): EIP7951は、0x100番地にP256VERIFYというプリコンパイルを追加します。このプリコンパイルは、secp256r1（別名P-256またはprime256v1）楕円曲線上でのECDSA署名検証を6900ガスで実行します。
- [\[ERC7964\] 1つの署名で複数チェーンの操作をまとめて実行するクロスチェーンEIP712署名の仕組みを理解しよう！](https://cardene.dev/articles/9bb09dd0a5048f50e220.md): ERC7964とは、EIP712の署名を使って複数のブロックチェーンにまたがる操作を1つの署名でまとめて承認できるようにする提案です。
- [\[ERC8111\] ECDSA署名を64バイトに圧縮するBound Signaturesの仕組みを理解しよう！](https://cardene.dev/articles/0f0930075300bc05d254.md): ERC8111とは、ECDSA署名のvパラメータを27に固定することで、署名を96バイトから64バイトに圧縮する仕組みのことです。
- [\[ERC8019\] 毎回の署名なしでSIWEログインを自動化する仕組みを理解しよう！](https://cardene.dev/articles/59d12fd4152f8bf14742.md): 今回は「ERC8019によるSIWE自動ログインのウォレット管理」についてまとめてきました！いかがだったでしょうか？
- [\[ERC7524\] 匿名性と一意性を両立する署名の仕組みを理解しよう！](https://cardene.dev/articles/a20a3c4d29c8847a43dc.md): ZK-SNARK（ゼロ知識での正しさ証明を行う技術）は、匿名のまま「自分が特定の秘密情報を持っている」ことを示す新しいアイデンティティアプリケーションを生み出すきっかけとなりました。
- [\[ERC6865\] オンチェーンでEIP712のメッセージを可視化する仕組みを理解しよう！](https://cardene.dev/articles/f36939a6cc9102eb1563.md): 現在、多くのプロトコルや分散型アプリケーション（dApp）は、EIP712（構造化データを署名するための標準仕様）をそれぞれ独自の「スキーマ（データの項目名や型の定義）」で使っています。
- [\[ERC6327\] パスワードで安全にデータ署名する仕組みを理解しよう！](https://cardene.dev/articles/b2b6b86dbd2c4e550046.md): Elastic Signature（以下、ES）は、人が覚えやすい秘密情報を使ってデータへ署名できる仕組みです。
- [\[ERC7913\] 鍵の種類を問わない署名の新しい仕組みを理解しよう！](https://cardene.dev/articles/4ae111f8680e1847d6e1.md): Ethereumでは、**Externally Owned Account（EOA）**は対応する秘密鍵でメッセージに署名できます。
- [\[ERC7951\] プリコンパイルにP-256検証を実装してデバイス署名を使える仕組みを理解しよう！](https://cardene.dev/articles/c4bc4dc53ce8f3acc912.md): ERC7951は、楕円曲線暗号方式であるsecp256r1（別名：P-256またはprime256v1）に基づくECDSA署名検証を、Ethereum上で効率的に行えるようにするための「プリコンパイル（precompile）」を追加する提案
- [\[ERC7739\] ネスト型EIP-712と防御的リハッシュで署名リプレイ攻撃を防ぐ仕組みを理解しよう！](https://cardene.dev/articles/23ec7be557f2144d9d87.md): ERC7739は、1つの外部所有アカウント（EOA）が複数のスマートアカウントを所有している場合に発生する、署名のリプレイ攻撃（過去に使用した署名を再利用して不正に取引を成立させる攻撃）を防ぐための標準仕様を定義しています。
- [\[ERC1812\] EIP712を活用したオフチェーン証明の仕組みを理解しよう！](https://cardene.dev/articles/aadfcb2f4d81fd8ade5b.md): ERC1812は、「EIP712」に基づいた署名済みTyped Data（型付きデータ）を使って、オフチェーンで再利用可能な「Verifiable Claims（検証可能な証明）」を発行・提示できる仕組みです。
- [\[ERC6384\] EIP712の署名確認をしやすくする仕組みを理解しよう！](https://cardene.dev/articles/6274e5b49f1f552a59ef.md): ERC6384は、evalEIP712Buffer という関数を提案しています。この関数は、EIP712形式の署名データ（バッファ）を受け取り、それに対応する人間が読める形式の説明文を返すものです。
- [\[ERC2335\] BLSキーストアの仕組みを理解しよう！](https://cardene.dev/articles/73aa4ef1aa04809c4aa6.md): ERC2335は、BLS12-381曲線を使った暗号署名における秘密鍵を安全に保存・共有するための標準的なJSON形式の定義です。この形式は「キーストア（keystore）」と呼ばれるファイルで、秘密鍵を暗号化して保存します。
- [\[EIP2334\] BLS鍵における用途別パス構造の仕組みを理解しよう！](https://cardene.dev/articles/4e9dc2f5af58ed01aebd.md): EIP2334は、EIP2333で生成される鍵に「目的」を割り当てるための標準を定義しています。
- [\[ERC2770\] メタトランザクションでの署名検証とトランザクションの中継を行う仕組みを理解しよう！](https://cardene.dev/articles/cfbe79eab7f32912dbee.md): ERC2770は、メタトランザクション（meta-transaction）の処理を実行するための「拡張可能なフォワーダー（Forwarder）」を提案しています。
- [\[ERC3224\] トランザクション署名時にトランザクションの内容を確認する仕組みを理解しよう！](https://cardene.dev/articles/dafe2bb7e7155755f115.md): ERC3224は、ユーザーがEthereumウォレット（例：MetaMask、Clef、ハードウェアウォレットなど）を通じて実行する操作について、よりわかりやすい説明を提供する仕組みを提案しています。
- [\[ERC7741\] EIP712を使用してメタトランザクションを実行する仕組みを理解しよう！](https://cardene.dev/articles/28bd916560a99cf91f8c.md): ERC7741は、EIP712に基づく署名を活用し、オペレーター（代理人）を管理するためのメタトランザクションやアトミックなコントラクト実行を可能にする一連の関数を提案しています。
- [\[ERC7598\] コントラクトによる署名に対応したメタトランザクションの仕組みを理解しよう！](https://cardene.dev/articles/1ffd298d78b3931ccc59.md): この規格では、ERC3009の機能を拡張して、コントラクトウォレットでのapprove + transferFromのサポートを提案しています。
- [\[ERC7015\] NFTクリエイターと作品の帰属を明確にする署名メカニズムを理解しよう！](https://cardene.dev/articles/5bb3ac05999231ce11c5.md): このEthereum Improvement Proposal（EIP）は、Non-Fungible Token（NFT）標準（ERC721、ERC1155）におけるクリエーター帰属問題を解決することを目的としています。
- [\[ERC191\] 署名済みデータを安全に使用する仕組みを理解しよう！](https://cardene.dev/articles/ee4edd15ad6fe7f58f7e.md): このERCは、Ethereumコントラクトにおける署名済みデータの扱い方に関する仕様を提案しています。
- [\[ERC2098\] Ethereumの署名をよりコンパクトにする仕組みを理解しよう！](https://cardene.dev/articles/2fb8f63af3b22eb72e33.md): Ethereumのブロックチェーンでは、トランザクション（取引）を確認するために、特定の数学的な方法（secp256k1曲線）を使ってデジタル署名が作られます。この署名によって、トランザクションの送信者が本当に自分であることを証明できます。
- [\[ERC5267\] EIP712ドメインの生成に必要な情報を渡す仕組みを理解しよう！](https://cardene.dev/articles/3f0d49e6796d6f35d321.md): このEIPは、EIP712を補完する役割を果たし、コントラクトがそのドメインを記述するフィールドと値をどのように公開すべきかを標準化しています。
- [\[ERC6066\] 署名主体がNFTである時の署名検証方法の仕組みを理解しよう！](https://cardene.dev/articles/54febb93a37b77447e35.md): 通常、外部所有アカウント（Externally Owned Accounts）は、ecrecover()関数を使って、署名が本物かどうかを確認できます。スマートコントラクトも、ERC1271のルールに従って署名を検証することができます。
- [\[ERC6066\] NFTによる署名検証の仕組みを理解しよう！](https://cardene.dev/articles/b170c0d6c33d9761f9df.md): 現在のブロックチェーンでは、個人が所有するアカウント（外部所有アカウント、EOA）はecrecover()という関数を使って、署名されたメッセージを検証することができます。
- [\[ERC1271\] コントラクトで署名を検証する仕組みを理解しよう！](https://cardene.dev/articles/da237b1b8cc185491512.md): 提案されているのは、ブロックチェーン上のコントラクトが自分自身の署名を検証するための新しい方法です。これまで、外部所有アカウント（EOA）は秘密鍵を使用してメッセージに署名することができましたが、コントラクトにはその機能がありませんでした。
- [\[EIP712\] 型付き構造化データのハッシュ化と署名の仕組みを理解しよう！](https://cardene.dev/articles/f54bc85cb66de5a54257.md): この標準は、データを構造化された型に基づいて処理し、それをハッシュ化および署名するためのものです。通常のバイト列だけでなく、データの型や構造を考慮して安全に操作できるようにすることを目指しています。以下のような特徴を持ちます。
- [\[ERC5453\] 1トランザクション内で複数関数呼び出しや署名関連拡張機能の仕組みを理解しよう！](https://cardene.dev/articles/6d4ffb1e979a6793f6d8.md): この提案は、Ethereumの改善提案（EIP）で、ERC5750を基盤としています。その主な目的は、同じトランザクション内で複数の関数呼び出しを承認できる一般的なプロトコルを設けることです。これは、従来のアプローチとは異なります。

## Blockchain / Privacy

- [\[ERC8290\] プライバシープール間で資産を移す仕組みを理解しよう！](https://cardene.dev/articles/c6172fb33abb45b11fa6.md): ERC8290は、利用者の資産や取引の対応関係を公開しないまま、あるサービスから別のサービスへ資産を移すためのEthereumの提案です。
- [\[ERC7945\] トークンの残高やTransfer額を暗号化する機密トランザクション対応トークンの仕組みを理解しよう！](https://cardene.dev/articles/e95e50cf48e17cabe932.md): ERC7945は、機密トランザクション（Confidential Transactions）に対応したファンジブルトークンの標準インターフェースです。
- [\[ERC7984\] 送金額と残高を秘匿化できるConfidential Fungible Tokenの仕組みを理解しよう！](https://cardene.dev/articles/a8bed849bcd885eafa48.md): ERC7984は、トークンの残高や送金額を秘匿化しながらトークンのTransferを行うための標準インターフェースです。通常のERC20トークンでは、誰が誰にいくら送ったかがブロックチェーン上に公開されます。
- [\[ERC7992\] ゼロ知識証明でMLモデルの推論結果をオンチェーンで検証するZKMLの仕組みを理解しよう！](https://cardene.dev/articles/c8711d2ef575f9037d8d.md): ERC7992は、機械学習（ML）モデルの推論結果をオンチェーンで暗号的に検証するための標準インターフェースです。
- [\[EIP7503\] 送付元を隠してETHを送付できる仕組みを理解しよう！](https://cardene.dev/articles/8c47d87326201faa3432.md): 今回は「EIP7503によるゼロ知識ワームホールを使用したプライバシーソリューション」についてまとめてきました！いかがだったでしょうか？
- [\[ERC2494\] zk-SNARK回路で高速動作するBaby Jubjub曲線の仕組みを理解しよう！](https://cardene.dev/articles/210d250c9e871d33f2b6.md): ERC2494では、Ethereumのzk-SNARK回路内で利用できる新しい楕円曲線「Baby Jubjub」を定義しています。
- [\[ERC7627\] ユーザー間のメッセージ送信を安全に暗号化する仕組みを理解しよう！](https://cardene.dev/articles/00371797fd85ae1cd9b9.md): この提案は、ブロックチェーン上で暗号化されたメッセージを安全に交換する機能を実装することを目指しています。
- [\[ERC5564\] 送受信者のみがアクセスできるステルスアドレスの仕組みを理解しよう！](https://cardene.dev/articles/115df838afdb3f582731.md): この規格では、ステルスアドレスと呼ばれるアドレスに関する提案をしています。
- [\[ERC6538\] 匿名取引を可能にするステルスアドレスを管理するレジストリの仕組みを理解しよう！](https://cardene.dev/articles/137f61a0bc05707b1ec0.md): この規格は、エンティティが自分の身元や取引を秘密に保ちながら活動するための特別なアドレス、つまりステルスメタアドレスを管理する方法を標準化しています。これはERC5564というイーサリアムの拡張を通じて行われます。

## Blockchain / NFT

- [\[ERC8034\] 参照可能NFTのロイヤリティをDAGで自動分配する仕組みを理解しよう！](https://cardene.dev/articles/8fa9fe9f033bd7ef4df3.md): ERC8034とは、ERC5521で導入された参照可能NFT（rNFT）のために設計された、独立型のロイヤリティ分配標準です。
- [\[ERC7588\] Blobトランザクションにメタデータを付与するJSON Schema標準化の仕組みを理解しよう！](https://cardene.dev/articles/b465e0b4671fd620de44.md): ERC7588 とは、EIP4844のBlobトランザクションにメタデータを付与するためのJSON Schema標準を定義した提案です。
- [\[ERC7765\] RWAとNFTをつなぐ権利行使の仕組みを理解しよう！](https://cardene.dev/articles/40e8fe8f4e91fd5233c0.md): ERC7765は、現実世界の資産（Real World Asset, RWA）に紐づいたNFTが「権利」や「特典（Privileges）」を持つことを前提に、それらをオンチェーンで扱うための標準インターフェースを定義する規格です。
- [\[ERC7729\] ERC20にメタデータを標準で持たせる仕組みを理解しよう！](https://cardene.dev/articles/61e2cc6cb9cf3940590e.md): ERC7729は、既存のERC20規格を拡張し、トークンに「メタデータ」を標準化された方法で付与できるようにする規格です。
- [\[ERC7721\] ERC1155形式のNFTを預けずに使い続けるロックの仕組みを理解しよう！](https://cardene.dev/articles/c6114950191b9e769388.md): ERC7721は、ERC1155に「ロック（lock）/アンロック（unlock）」の仕組みを追加する拡張です。対象はERC1155の中でも、とくにNFTとして扱う「特定のtokenId」です。
- [\[ERC7695\] ERC721に所有権委任と利用権を分離する仕組みを理解しよう！](https://cardene.dev/articles/a9cdd06d85de3ad4904c.md): ERC7695は、ERC721を拡張して「誰がそのNFTを使えるのか」を状況に応じて明確にし、さらにロック（lock）機能を持たせるための標準です。
- [\[ERC7652\] NFTに価格保証を持たせる仕組みを理解しよう！](https://cardene.dev/articles/552a9d293e9da4b1a605.md): ERC7652は、ERC721（NFT）に「保証人（Guarantor）」という役割を追加する提案です。保証人とは、特定のNFT（token ID）に対して価格保証を提供する主体を指します。
- [\[ERC7651\] NFTをロックせずに分割して流通させる仕組みを理解しよう！](https://cardene.dev/articles/f2162ed68b7a1bd154fe.md): ERC7651は、非代替性トークン（NFT）を分割可能な形で表現・管理できる標準規格です。ここでいうNFTとは、ERC721に代表される「1つ1つが固有で代替できないトークン」を指します。
- [\[ERC7649\] NFTに流動性を組み込む仕組みを理解しよう！](https://cardene.dev/articles/207e550f9e482dd971c0.md): ERC7649は、ERC721（NFT）の仕様を変更せずに、ボンディングカーブ型の流動性をNFTに組み込むための標準を提案しています。
- [\[ERC7632\] NFTのtokenIdと文字列名を結び付ける仕組みを理解しよう！](https://cardene.dev/articles/92729e359491d1a0b203.md): ERC7632は、NFTなどのトークンで一般的に使われている uint256 型の tokenId を拡張し、文字列型（string）の tokenName を扱えるようにする仕組みです。
- [\[ERC7603\] 利用シーンごとに最適なデータを返すERC1155を拡張した仕組みを理解しよう！](https://cardene.dev/articles/a4edce91b0969c3196df.md): Multi-Asset Token standardは、ERC1155と互換性のあるトークン標準で、1つのトークンコレクションに対して「複数のアセット（出力）」を持てるようにする仕組みです。
- [\[ERC7595\] NFTに担保資産を組み込む仕組みを理解しよう！](https://cardene.dev/articles/ed354442a3eed819a7bd.md): ERC7595は、既存のERC721（NFT）規格を拡張し、NFTを担保（コラテラル）として扱えるようにするための提案です。ここでいう担保とは、NFTに価値の裏付けとなる資産を紐づけ、その価値を利用できる状態にすることを指します。
- [\[ERC7510\] 派生NFTの関係性を階層的に管理する仕組みを理解しよう！](https://cardene.dev/articles/800f042129b63977e8f3.md): ERC721を拡張したERC7510では、異なるコントラクト間に存在するNFT同士の階層関係を管理する仕組みを提供しています。
- [\[ERC7390\] ERC1155を使った分割可能なオプション発行の仕組みを理解しよう！](https://cardene.dev/articles/d7ac135e836c8b16df44.md): ERC7390は、バニラオプションを扱うための機能やイベントをまとめたものです。バニラオプションとは、特定の価格で資産を買うか売るかを選べる権利のことで、権利を使うかどうかは購入者が自由に決められます。
- [\[ERC7280\] JSON-LD形式でNFT情報を拡張する仕組みを理解しよう！](https://cardene.dev/articles/22f7374d7fae95de871a.md): ERC721、ERC1155、ERC3525といった非代替性トークンのメタデータに、リンクされたデータを扱える仕組みを追加します。新しい情報は、従来のメタデータ JSON にある linked_data という項目の中に保存します。
- [\[ERC1155\] ERC1155を1からわかりやすく解説](https://cardene.dev/articles/c3ef92722b057161bebd.md): ERC1155は、ERC20が持つ特徴とERC721が持つ「非代替性」の2つを兼ね備えたトークン規格になります。
- [\[ERC721\] ERC721を1からわかりやすく解説](https://cardene.dev/articles/0570a8d05bc7c9b9593f.md): この章ではERC721の特徴について紹介していきます。ERC721は「非代替性トークン」です。「非代替性トークン」について調べると以下のような定義がされていました。
- [\[ERC5604\] NFTにリース権を付与する仕組みを理解しよう！](https://cardene.dev/articles/cf459c271022a0d91ebe.md): ERC5604は「NFTリース権（NFT Lien）」という新しい概念を提案しています。NFTリース権とは、特定の資産に対して設定される**担保権（security interest）**の一種です。
- [\[ERC7829\] クリエイターのデータを守りながら共有できるNFTの仕組みを理解しよう！](https://cardene.dev/articles/11ac63fce535f2e8d2cc.md): ERC7829は、既存のトークン規格であるERC721を拡張し、「データ資産」を扱えるようにします。ここでいうデータ資産とは、クリエイターが作ったブログ記事、動画、ミニゲーム、音楽などのデジタル作品のことです。提案の中核は二つあります。
- [\[ERC6596\] 文化財をNFTで記録するCHAT標準の仕組みを理解しよう！](https://cardene.dev/articles/e6e761b8bbb7ad7bbaec.md): ERC6596は、Cultural and Historical Asset Tokens（CHATs）、つまり「文化的・歴史的資産トークン」のための包括的なメタデータ標準を**Ethereumプラットフォーム上に確立することを目的としてい
- [\[ERC7590\] NFTがERC20トークンを管理する仕組みを理解しよう！](https://cardene.dev/articles/0425cb3493bfa1ee3276.md): ERC7590は、ERC721（非代替性トークンの標準。各トークンが一意で、同じものに置き換えられない資産を表す規格）を拡張し、ERC20（代替性トークンの標準。
- [\[ERC7743\] NFTを共同所有するMO-NFTの仕組みを理解しよう！](https://cardene.dev/articles/cbde819e9390cf2cbd57.md): ERC7743は、複数の所有者を持つことができる新しいNFT標準「MO-NFT（Multi-Owner NFT）」を定義する提案です。
- [\[ERC7858\] NFTとSBTに有効期限を付与する仕組みを理解しよう！](https://cardene.dev/articles/262fa2e9622e72e5f3a9.md): ERC7858は、ERC721トークン（NFT）および**SBT（Soulbound Token）**に「有効期限（Expiration）」というを追加する拡張提案です。
- [\[ERC5625\] NFTメタデータにNFTの実態データの保存情報を追加するdStorageの仕組みを理解しよう！](https://cardene.dev/articles/acf6f6ff52f26b5edd36.md): ERC5625は、EIP721およびEIP1155で定義されているNFTメタデータのJSONスキーマを拡張し、NFTデータの保存方法を示すdStorageという新しいキーを追加する提案です。
- [\[ERC1948\] NFTに付随するデータを変更できる仕組みを理解しよう！](https://cardene.dev/articles/a1fa2f17fc3092506e2e.md): NFT（非代替性トークン）では、通常、生成時（ミント時）に一度だけ設定される静的なメタデータしか扱えません。
- [\[ERC5851\] Verifiable CredentialをSBTで管理する仕組みを理解しよう！](https://cardene.dev/articles/adba5a2e8d1e92b3699c.md): ERC5851は、特定のアドレスがある条件（クレーム）を満たしていることを証明し、それをオンチェーンのメタデータを用いて検証できる仕組みを導入する提案です。
- [\[ERC1523\] 保険証券をNFTにする仕組みを理解しよう！](https://cardene.dev/articles/83fa7c68be5ea877017f.md): ERC1523は、スマートコントラクト上で保険証券（保険契約）を扱うための標準的なAPIを提案しています。保険証券は、加入者、対象となるリスク、保険料、契約期間、保険会社、引受人などの要素により一意性を持つ金融資産です。
- [\[ERC2477\] トークンのメタデータが改ざんされていないことを検証する仕組みを理解しよう！](https://cardene.dev/articles/4ea0b8b64e972961fa8a.md): ERC2477は、トークンのメタデータが取得された時に、その内容が改ざんされていないことを検証できる仕組みを提案しています。
- [\[ERC2615\] NFTに使用権と担保権を付与する仕組みを理解しよう！](https://cardene.dev/articles/d34cc1c5060955f750da.md): ERC2615は、ERC721を拡張し、賃貸（レンタル）および担保（モーゲージ）の機能を追加する提案です。これにより、NFTが現実世界の不動産のような性質を持つことが可能になります。
- [\[ERC3386\] NFTを預けてERC20トークンを発行する仕組みを理解しよう！](https://cardene.dev/articles/7f1627768719c936f962.md): ERC3386は、ユニークなERC721またはERC1155トークンをプールにロックすることで、それに関連するERC20トークンを生成するためのスマートコントラクトのインターフェースを提案しています。
- [\[ERC3440\] NFTのオリジナルと限定盤を区別する仕組みを理解しよう！](https://cardene.dev/articles/ae86f8b0ca071c9bde0f.md): ERC3440は、ERC721を拡張し、アート作品を表すNFTに対して「署名」の機能を追加する提案です。これにより、アーティストが作品のオリジナルと限定版プリントを明確に区別し、それぞれに署名データを紐づけることが可能になります。
- [\[ERC3569\] NFTのメタデータが変更されないことを保証する仕組みを理解しよう！](https://cardene.dev/articles/ca19d3888c03804aac40.md): Sealed NFT Metadata Extension（シールドNFTメタデータ拡張）は、NFTのメタデータを変更不可能な状態で固定する提案です。
- [\[ERC3589\] NFTで複数の資産を管理・一括送付する仕組みを理解しよう！](https://cardene.dev/articles/593822c6b813afce04d6.md): ERC3589は、「アセンブリトークン（Assembly Token）」と呼ばれるERC721トークンの拡張仕様を提案しています。
- [\[ERC3754\] NFTに実行権やアクセス権を付与する仕組みを理解しよう！](https://cardene.dev/articles/c3e655357b313c01895f.md): ERC3754では、NFTをアトミックな存在として扱い、その上に抽象的なレイヤーを重ねていく設計を提案しています。
- [\[ERC4341\] 複数のNFTを送付する時の順番を保証する仕組みを理解しよう！](https://cardene.dev/articles/7f9898e3459e9e1c1095.md): ERC4341は、複数のNFTを順序付きで扱えるコントラクトインターフェースを提案しています。
- [\[ERC4353\] ステーキングされているNFTのトークン量を取得する仕組みを理解しよう！](https://cardene.dev/articles/ce72554fb377dd789e78.md): ERC4353は、NFT（ERC721）にステーキングされたトークンの数量を取得するインターフェースを提案しています。
- [\[ERC4393\] NFTにERC20形式の少額の報酬を送る仕組みを理解しよう！](https://cardene.dev/articles/9db7cf661cd5087e8ca4.md): ERC4393は、ERC721（NFT）およびERC1155（マルチトークン）に対してチップ（少額の報酬）を送るコントラクトインターフェースを定義しています。
- [\[ERC4521\] ERC20コントラクトが安全にERC721形式のNFTを送付する仕組みを理解しよう！](https://cardene.dev/articles/64f88dab5c6f513e35ca.md): ERC721はEthereumブロックチェーン上でユニークなデジタル資産（NFT）を扱う標準規格です。
- [\[ERC4671\] NTTと呼ばれる譲渡できないNFTの仕組みを理解しよう！](https://cardene.dev/articles/7acca8927401cbe8491c.md): 非譲渡トークン（NTT：Non-Tradable Token）は、大学の卒業証書、オンライン研修の修了証明書、政府発行の各種書類（国民ID、運転免許証、ビザ、婚姻証明書など）、ラベルなど、個人的な所有物（有形・無形）を表すトークンです。
- [\[ERC4675\] NFTをトークンIDごとに分割所有することができる仕組みを理解しよう！](https://cardene.dev/articles/c220eecaa04b69344dcb.md): ERC4675は、1つのスマートコントラクトで複数のNFTを分割管理できるようにするインターフェースを提案しています。
- [\[ERC1633\] ERC721形式のNFTを共有所有する仕組みを理解しよう！](https://cardene.dev/articles/b6a8b4a1fd348e47673c.md): ERC1633は、ERC20トークン標準を拡張し、ERC721の共有所有権を表現する新しいトークンであるRe-Fungible Token（RFT）を提案しています。
- [\[ERC4799\] NFTの所有権を別のNFTで管理する仕組みを理解しよう！](https://cardene.dev/articles/8c3602cf7e17debbc0ad.md): ERC4799が提案しているインターフェースは、NFTがスマートコントラクトによってエスクロー（保管）されている状態でも、別のアドレスに所有権を指定できる仕組みを提案しています。
- [\[ERC4885\] NFTをサブスクで提供する仕組みを理解しよう！](https://cardene.dev/articles/12c2ef6d8c2de1586a1c.md): ERC4885は、NFT（ERC721）やマルチトークン（ERC1155）の利用権をサブスクリプション形式で提供する標準APIを提案しています。
- [\[ERC5058\] NFTにロック機能を適用する仕組みを理解しよう！](https://cardene.dev/articles/9c06eea1e08d19441600.md): ERC5058は、NFTの標準規格であるERC721に「ロック機能」を拡張機能として追加する提案です。NFTの所有者は、指定したオペレーターに対してロックを許可し、そのオペレーターがNFTをロックします。
- [\[ERC5050\] NFTなどのトークン同士で特定のアクションを送受信できる仕組みを理解しよう！](https://cardene.dev/articles/c6d955c839a0221fb5ea.md): ERC5050は、ユーザーが起こす「アクション」を異なるトークン間でやり取りできる、汎用的なアクションメッセージングプロトコルを提案しています。
- [\[ERC5185\] NFTのメタデータを事前に定義されたルールに沿って更新する仕組みを理解しよう！](https://cardene.dev/articles/323d43a71d6b60d78719.md): ERC5185は、NFTのメタデータをあらかじめ定義されたルールに従って更新できるようにする標準的な方法を提案しています。更新は自由に行えるわけではなく、決められた「レシピ（変換ルール）」に従ってのみ許可されます。
- [\[ERC5187\] ERC1155の所有権と使用権を分離させる仕組みを理解しよう！](https://cardene.dev/articles/0c7bc4359bd66c2bb961.md): ERC5187は、ERC1155を拡張し、NFTの「使用権」を分離して扱えるようにする提案です。
- [\[ERC5334\] ERC721形式のNFTにアドレス・有効期限・レベルという情報を付与できる仕組みを理解しよう！](https://cardene.dev/articles/1bb4a14fdf405ae7c83c.md): ERC5334は、ERC721に、新しく「user」というロールを追加する提案です。
- [\[ERC5409\] ERC1155形式のNFTの保有者を確認する仕組みを理解しよう！](https://cardene.dev/articles/c05da5321c8a37d79fdd.md): ERC5409は、ERC1155に「ownerOf」という新しい関数を追加して、ERC1155トークンにも「非代替性」を持たせることを目的としています。
- [\[ERC5501\] 期限までNFTのレンタル権を取り消されない仕組みを理解しよう！](https://cardene.dev/articles/0b0755a515039f592819.md): ERC5501では、ERC721に「user」という新しいロールを追加する標準を提案しています。この利用者はNFTを実際に使うことはできますが、transferしたり他のuserに渡すことはできません。
- [\[ERC5505\] 現物資産NFTを分割所有→単一所有に切り替えられる仕組みを理解しよう！](https://cardene.dev/articles/4645ea1748cc27ff85b9.md): ERC5505では、ERC1155規格をベースにした資産担保型の分割所有プロジェクトに対して、「全体取得（トータルアクイジション）」を可能にするトコントラクトインターフェースの拡張を提案しています。
- [\[ERC5516\] SBTを再利用できる仕組みを理解しよう！](https://cardene.dev/articles/328f94d84f5e54b682ff.md): ERC5516では、アカウントに紐づくトークン（ソウルバウンドトークン、SBT）の新しい仕組みを提案しています。従来のSBTでは、ユーザーが秘密鍵を失ったり鍵を作り替えると、トークンが失われてしまう問題がありました。
- [\[ERC5553\] IPの管理やロイヤリティの設定を行う仕組みを理解しよう！](https://cardene.dev/articles/5d8628dd0753f6b1b847.md): ERC5553は、「知的財産（IP）」をブロックチェーン上で汎用的に表現する提案しています。対象とするIPの種類は特定されておらず、音楽、動画、本、画像など、さまざまなタイプのIPに対応できます。
- [\[ERC5218\] NFTのライセンスをオンチェーンで管理する仕組みを理解しよう！](https://cardene.dev/articles/ac9ea1bc38a51bd25092.md): ERC5218は、NFTに関するライセンスを管理するためのAPI仕様を提案しています。NFTに付随する著作権ライセンスを、オンチェーンで発行・譲渡・取消できるようにする仕組みを提供します。
- [\[ERC5554\] NFTに関する著作権をオンチェーンで管理する仕組みを理解しよう！](https://cardene.dev/articles/84c5009837a08a967701.md): ERC5554では、NFTなどのトークンに「著作権や利用権に関する明確なルール」を追加できる仕組みを提案しています。
- [\[ERC5560\] NFTを物理的アイテムと引き換え可能かを管理する仕組みを理解しよう！](https://cardene.dev/articles/57256ead1ed829795473.md): ERC5560は、ERC721形式のNFTに「引き換え機能（redeem function）」を追加する仕組みを提案しています。NFTを使って、物理的なモノと交換できるようにしたい発行者向けの機能です。
- [\[ERC5635\] NFTのライセンスを管理する仕組みを理解しよう！](https://cardene.dev/articles/19de1b66ee61db45fced.md): ERC5635は、NFTの派生作品に関するライセンス契約を登録・参照できる「ライセンス・オラクル（NFT Licensing Oracle）」を標準化する提案です。
- [\[ERC5633\] ERC1155をSBTにする仕組みを理解しよう！](https://cardene.dev/articles/835bceecec8e8fe6549b.md): ERC5633は、ERC1155を拡張する提案です。特徴は、「ソウルバウンド（Soulbound）」かどうかの性質をトークンごとに設定できるようにする点です。
- [\[ERC5753\] NFTをロックしてtransferを制限する仕組みを理解しよう！](https://cardene.dev/articles/dc1537339513c4cd76e4.md): ERC5753は、ERC721を拡張してNFTにロック機能を追加する提案です。ロックされたNFTは、売却や譲渡はできませんが、それ以外の用途には自由に使えます。
- [\[ERC5643\] NFTの所有権をサブスクのように管理できる仕組みを理解しよう！](https://cardene.dev/articles/16fb915db14e134cd46e.md): ERC5643は、ERC721を拡張してNFTに有効期限を設け、定期的に更新（支払い）しないと権利が失われる仕組みを提案しています。
- [\[ERC5744\] 一定期間後にNFTがFTに変わる仕組みを理解しよう！](https://cardene.dev/articles/277ecbab99edde351a4b.md): ERC5744はERC20の拡張版で、代替性（ファンジブル）トークンが一定期間非代替性（ノンファンジブル）トークンになる仕組みを提案しています。
- [\[ERC6268\] ERC1155形式のNFTをSBTにする仕組みを理解しよう！](https://cardene.dev/articles/5ac107681eac3328258d.md): ERC6268は、EIP1155に対応するトークンの「譲渡不可（送付できない）」を示すためのインターフェースを標準化する提案です。EIP165の機能検出を活用して、トークンを譲渡できるかどうかを判別できるようにします。
- [\[ERC6047\] コントラクトデプロイ時のNFT発行でイベントを発行する提案を理解しよう！](https://cardene.dev/articles/ed29f903ca52017d4f1d.md): ERC6047は、ERC721の仕様を拡張してNFTの追跡やインデックス作成をしやすくするために、コントラクト作成時にもTransferイベントを発行することを義務付ける提案です。
- [\[ERC6464\] NFTを複数アドレスにapproveする仕組みを理解しよう！](https://cardene.dev/articles/66d1c7dfcefcd79fb6fa.md): ERC721では、1つのNFTに対して複数のオペレーター（代理人）を承認する仕組みが想定されていませんでした。そのため、ほとんどのケースでsetApprovalForAll()が使われてきました。
- [\[ERC7565\] ロックした資産を表すNFTを担保にDeFiで資金を借りることができる仕組みを理解しよう！](https://cardene.dev/articles/d3e1dc461b1bb32e5f02.md): この規格では、ロックされた資産を表すNFTを担保として資金を借りることができる仕組みを提案しています。このNFTは、設定された満期後に預けた資産と得られた利益を受け取ることができます。
- [\[ERC7589\] Semi-Fungible Tokensのロール管理の仕組みを理解しよう！](https://cardene.dev/articles/69db9a18b2c939a54a52.md): この規格では、SFT（セミファンジブルトークン） のロール管理について提案されています。
- [\[ERC7604\] ERC2612をERC1155形式のNFTに適用してUX良くNFTを送付する仕組みを理解しよう！](https://cardene.dev/articles/a2ab1f9a9adb4c668a89.md): ERC2612やERC4494を使用したPermitのフローは、ERC20やERC721トークンのUXを大幅に改善しました。この規格では、ERC1155にPerimtの仕組みを定期ようすることを提案しています。
- [\[ERC4494\] ERC2612をNFTに適用してUX良くNFTを送付する仕組みを理解しよう！](https://cardene.dev/articles/f80c6b2f938fa1f54868.md): この規格は、ERC2612で提案されているPermit承認フローをERC721に適用する仕組みを提案しています。
- [\[ERC7628\] ERC721のNFTの所有権を分割する仕組みを理解しよう！](https://cardene.dev/articles/59f76feb5d1b2e5b4c95.md): この規格では、NFTの各トークンに「シェア」と呼ばれる所有権示す値を付与して、NFTの部分所有の仕組みを提案しています。
- [\[ERC7629\] ERC20トークンとERC721トークンを変換できる仕組みを理解しよう！](https://cardene.dev/articles/92206f1254b114058600.md): この規格では、Ethereumブロックチェーン上でERC20（代替性トークン）とERC721（非代替性トークン）の両方を管理できるインターフェースを提案しています。
- [\[ERC7634\] NFTのTransfer回数を制限する仕組みを理解しよう！](https://cardene.dev/articles/14a75ed0f80e114e3c5e.md): この規格では、ERC721を拡張してNFTのtransferの回数を制限するTransferCountの導入を提案しています。
- [\[ERC7644\] 有効期限付きの名前をNFTに紐づける仕組みを理解しよう！](https://cardene.dev/articles/865a1d0092b05224fe34.md): この規格では、ERC721トークンに命名メカニズムを追加するインターフェースを提案しています。これにより、各トークンに有効期限が設定された一意の名前をつけることができ、NFTコントラクトないので一意性が確保されます。
- [\[ERC7656\] ERC6551を拡張してより汎用的なコントラクトをNFTに紐づけられる仕組みを理解しよう！](https://cardene.dev/articles/fedb579c576c3013fc58.md): この規格では、ERC6551にバリエーションをもたらすことを提案しています。ERC6551に沿って作成されるコントラクトをアカウントのみに限らず、様々な種類のコントラクトにできるような仕組みが説明されています。
- [\[EIP7681\] ERC20とERC1155を組み合わせたERC404のような仕組みを理解しよう！](https://cardene.dev/articles/8bf0bb1d4d307136a5a1.md): この規格では、ERC20（代替可能トークン）とERC1155（マルチトークン）を統合して、単一のコントラクト内で2つのトークンを管理できる仕組みを提案しています。
- [\[ERC7565\] 資産をNFTとしてロックしてDeFiなどで担保にできる仕組みを理解しよう！](https://cardene.dev/articles/610d3c7fec5daac7daa7.md): このERC(イーサリアムリクエストコメント)の提案は、特定の資産を担保にして資金を借りるためのメカニズムに関するものです。
- [\[ERC7527\] ERC20/ETHをERC721（NFT）にラップ/アンラップする仕組みを理解しよう！](https://cardene.dev/articles/d7340f715ba9f576dad0.md): この規格では、ERC20トークンやETHをERC721トークンに変換するためのインターフェース、そしてその逆変換のためのシステムを提案しています。
- [\[ERC7631\] ERC20とERC721トークンが相互に影響し合う仕組みを理解しよう！](https://cardene.dev/articles/feef82cecbacf9a043bb.md): この提案は、分割可能なERC20トークンと非分割可能なERC721トークンのコントラクトが相互に連携できるようにする方法について説明しています。具体的には、一方のコントラクトで行われたアクションがもう一方に反映されるようにするものです。
- [\[ERC7572\] コントラクトに関するメタデータを一元管理する仕組みを理解しよう！](https://cardene.dev/articles/cecd23351f13f16a30b8.md): この仕様は、contractURI()を標準化し、コントラクトレベルのメタデータを返すようにします。
- [\[ERC7548\] IP登録の仕組みとNFTの派生作品と元のNFTの関係を追跡可能にする仕組みを理解しよう！](https://cardene.dev/articles/b95a8dc929fcfb5635ca.md): この提案は、既存の複数の知的財産（IP）を組み合わせて新しいIPを分散的に創出する標準化された方法を確立することを目指しています。このプロトコルはNFT（非代替トークン）を基礎として構築され、各知的財産はNFTとして表されます。
- [\[ERC7538\] ERC20とERC1155のトークンをより細かい単位で管理する仕組みを理解しよう！](https://cardene.dev/articles/cc3162c299ac176ab5bc.md): ERC20とERC1155はイーサリアムのブロックチェーン上で使われるトークン標準です。これらはデジタル資産やトークンを作成し、交換するためのルールを定義しています。
- [\[ERC7513\] コントラクトの実行ロジックとNFTを組み合わせたスマートNFTの仕組みを理解しよう！](https://cardene.dev/articles/816307d468f85f68d5dd.md): スマートNFTというのは、NFT（Non-Fungible Token、非代替トークン）とスマートコントラクトを組み合わせたものです。
- [\[ERC7510\] 異なるコントラクト間でNFTの階層構造を管理する仕組みを理解しよう！](https://cardene.dev/articles/a1c18c38229303ae2d2e.md): ERC721は、イーサリアムブロックチェーン上でユニークなアセット（NFT、非代替トークン）を表現するための標準規格です。
- [\[ERC7303\] NFTを使用したアクセスコントロールの仕組みを理解しよう！](https://cardene.dev/articles/1135a58ef498232b05ab.md): このERC（イーサリアムの提案）は、「Token-Controlled Token Circulation（TCTC）」というアクセスコントロールスキームを導入しています。
- [\[ERC7085\] NFT同士の関係性やNFTの属性を管理する仕組みを理解しよう！](https://cardene.dev/articles/c519c6d3b3f65b5e7948.md): 提案されている新しい標準は、ERC1155をさらに発展させたもので、NFT間に関係性を設定し、それぞれのNFTに対して定量的な属性を設定できるようにします。
- [\[ERC6806\] NFTの保有期間を追跡する仕組みを理解しよう！](https://cardene.dev/articles/10282d2510158e01fff3.md): この規格は、ERC721規格のNFT（非代替トークン）を拡張して、保持時間を追跡および記述するインターフェースを追加する提案をしています。
- [\[ERC6785\] NFTのユーティリティ情報をメタデータに記載する拡張機能の提案を理解しよう！](https://cardene.dev/articles/ee40455e3ab86b036eb6.md): この規格はERC721トークンを拡張しています。ERC721は、イーサリアムブロックチェーン上で非代替トークン（NFT）を発行するための標準規格です。
- [\[ERC7531\] NFTのステーキング時に所有権を安全に保持するインターフェースの仕組みを理解しよう！](https://cardene.dev/articles/4aea6f01e0fc71b53e0e.md): ERC721トークン、特にロック機能を持たない古いNFT（例えばCrypto PunksやBored Ape Yacht Club（BAYC）トークン）をプールにステーキングするとき、所有権の認識に関して特有の課題が生じます。
- [\[ERC5604\] NFTに担保権を設定するインターフェースの仕組みを理解しよう！](https://cardene.dev/articles/f34498526f42463c5243.md): リーン（Lien） とは、負債の回収や他の義務の履行を保証するために、財産項目に対して設定される担保権の一形態です。不動産や車両など、具体的な資産に対してよく用いられます。
- [\[ERC6682\] ERC3156を拡張したERC721 NFTフラッシュローンの仕組みを理解しよう！](https://cardene.dev/articles/8e6d727d5ff3ee4e2e88.md): ERC3156は、イーサリアムのスマートコントラクトの標準の一つで、フラッシュローン（短期間の貸し付けと返済を行う仕組み）に関するものです。
- [\[ERC6120\] ERC20やERC721などのトークンをapproveなしにtransferする仕組みを理解しよう！](https://cardene.dev/articles/99e789166d601166bed2.md): イーサリアムのトランザクションでは、本来「transferしてコールする」（transfer-and-call）というのが基本的な動作です。
- [\[ERC6956\] 物理的なデジタルアセットとNFTを紐付けて管理する仕組みを理解しよう！](https://cardene.dev/articles/632677fa50f918f74ad5.md): この標準は、ERC721の拡張を通じて、物理的かつデジタルなアセットをdAppsなどに統合することを可能にするものです。
- [\[ERC6997\] 認証ステップを追加することで不正なNFT流出を防ぐ仕組みを理解しよう！](https://cardene.dev/articles/70dc4a4a1e533c6ee52b.md): この規格はERC721を拡張したもので、ウォレットのドレイン（資金の不正な流出）を防ぐために、新しい検証（バリデーション）機能を導入しています。
- [\[ERC3448\] 変更できないメタデータを追加してコントラクトを複製する仕組みを理解しよう！](https://cardene.dev/articles/2ab7174316a7e93ad650.md): この標準は、ブロックチェーン上でのコントラクトがどのように動くかを明確にし、信頼性を高めるためのものです。
- [\[ERC6239\] RDF形式でSBTにより多くの情報を持たせる仕組みを理解しよう！](https://cardene.dev/articles/5c53900f22af16c1a365.md): この提案は、ブロックチェーンの世界でより豊かな情報を持つトークンを作るための新しい方法です。
- [\[ERC5169\] クライアントスクリプトとNFTの安全な連携を可能にする仕組みを理解しよう！](https://cardene.dev/articles/18c591e6f71fbae28cce.md): このEIPは、イーサリアムのブロックチェーン上で動くコントラクトが、自分に関連付けられた特定のスクリプトを簡単に見つけられるようにする新しい機能を提案しています。
- [\[ERC7231\] NFTを通じた新しい自己管理型アイデンティティの仕組みを理解しよう！](https://cardene.dev/articles/0075f7fee082c1601089.md): この新しいシステムは、ERC721という基準をさらに進化させています。
- [\[ERC7439\] チケットの正式な再販と不正なチケット転売を防止するインターフェースの仕組みを理解しよう！](https://cardene.dev/articles/662b5445f9200766bdc7.md): この標準はERC721の改良版で、チケットの転売市場での問題に対処するための新しい方法を提供します。主な目的は、チケットの不正な転売を防ぎ、顧客がチケットを公認リセール業者を通じて合法的に再販できるようにすることです。
- [\[ERC7066\] NFTをロックする仕組みを理解しよう！](https://cardene.dev/articles/c7815399d88d6e26ffd6.md): 提案されているこの拡張されたERC721規格は、NFTに新しい機能を追加するものです。主なポイントは以下になります。
- [\[ERC7160\] NFTに複数のメタデータを紐づける仕組みを理解しよう！](https://cardene.dev/articles/4b4af26075932bf3ccb8.md): このEIP（イーサリアム改善提案）は、ERC721標準に新しい機能を加えることを提案しています。この提案の主な内容は、1つのトークンに複数のメタデータURIを紐付ける機能です。
- [\[ERC7409\] より多くの絵文字をコントラクトで管理する仕組みを理解しよう！](https://cardene.dev/articles/1bacc51c74c793b24f2d.md): ERC7409は、ERC6381の後継として提案された新しい規格です。
- [\[ERC5507\] ERC20、ERC721、ERC1155の払い戻し機能の仕組みを理解しよう！](https://cardene.dev/articles/cb67afec0453715158b9.md): このERCの提案は、ERC20、ERC721、ERC1155トークンの新規販売において、返金が可能な機能を追加するものです。
- [\[ERC4910\] NFTのロイヤリティの管理やロイヤリティを含んだ取引の仕組みを理解しよう！](https://cardene.dev/articles/41e1c8907b326a35ac5b.md): この提案は、NFT（非代替トークン）とロイヤルティを結びつけ、ERC721標準を拡張したスマートコントラクトの設計です。主な目的は、中央機関が法的に権利を持つ人々への支払いを不正に操作したり回避したりすることを防ぐことです。
- [\[ERC998\] NFTが他のNFTやERC20トークンを所有する仕組みを理解しよう！](https://cardene.dev/articles/9198e509a1ea99985dd0.md): この規格は、ERC721トークンが他のERC721トークンとERC20トークンを所有できるようにするものです。また、ERC20やERC223トークンがERC721トークンによって所有できるようにもします。
- [\[ERC721C\] オンチェーンロイヤリティを強制化する仕組みを理解しよう！](https://cardene.dev/articles/771c0250f86b09d54f30.md): ERC721Cとは、NFTを作成したクリエイターが確実に二次売買時のロイヤリティを受け取れるようにする拡張機能です。
- [\[ERC5173\] 過去のNFT保有者もロイヤリティを取得できる仕組みを理解しよう！](https://cardene.dev/articles/2133591db882b3e096e5.md): 提案されているERC7507は、ERC721トークン（NFT）の所有者に、トークンを売却した後でも将来の価格上昇から利益を得る機会を提供するものです。
- [\[ERC4883\] SVGを連結して作成される「SVG NFT」の仕組みを理解しよう！](https://cardene.dev/articles/9786416dd7ede745c2f0.md): SVG（Scalable Vector Graphics）NFTは、特定のトークンID用に2つの異なるNFTのSVGデータを連結して1つの新しいSVGデータを生成するプロセスです。
- [\[ERC6786\] ロイヤリティを集計して受け取ることができる仕組みを理解しよう！](https://cardene.dev/articles/ddfaf1c87eacb95596af.md): この規格により、誰でも特定のNFTに対してロイヤルティを支払うことができ、また支払ったロイヤルティの金額を記録することができます。この規格を通じて支払いが実行されるたびにその値が累積され、情報が公開されるようになります。
- [\[ERC5252\] アカウントバウンドトークンの資金喪失を防止する仕組みを理解しよう！](https://cardene.dev/articles/4bc7450d05678a4729ea.md): このEIPは、イーサリアム（Ethereum）のアップグレード提案で、資産の管理と投資の透明性を確保し、金融運用業者からの独立性を守るための新しいスマートコントラクトのデザインパターンを提案しています。
- [\[ERC7507\] NFTに複数のユーザーが制限付きのアクセスができる仕組みを理解しよう！](https://cardene.dev/articles/04f49ad8e2efef3f783c.md): 通常のERC721トークンは、単一の所有者（オーナー）によって保持され、その所有者がそのトークンに対する完全なコントロール権を持っています。
- [\[ERC7303\] NFTの所有権に基づいたアクセス制御の仕組みを理解しよう！](https://cardene.dev/articles/b39d0f7d473a3f08f3ee.md): ERCはイーサリアム（Ethereum）で使用されるトークンの規格を指します。
- [\[ERC5727\] 様々な機能を備えたSBTの仕組みを理解しよう！](https://cardene.dev/articles/9b798dc496eb2561ffaa.md): このインターフェースは、ソウルバウンドトークン（SBT）のために設計されました。
- [\[ERC5700\] NFTにNFTを紐付けたり解除する仕組みを理解しよう！](https://cardene.dev/articles/58250d6ecbab677eb005.md): この規格は、仮想世界やデジタルアセットの新しい仕組みを提供するものです。ERC721やERC1155という種類のトークンを「バインダブル」と呼び、これらのトークンをERC721 NFT（非代替性トークン）に関連付ける方法を提供します。
- [\[ERC7508\] NFTにさまざまな属性情報を持たせて管理する仕組みを理解しよう！](https://cardene.dev/articles/83b2bfcc0499556cb8a0.md): この提案は、ERC721とERC1155という2つの異なるトークン規格を使っているトークン（通常、デジタルアセットやゲームアイテムなど）に関連しています。
- [\[ERC5521\] ERC721規格のNFTの参照関係を表現する仕組みを理解しよう！](https://cardene.dev/articles/a50c10a528683e75b2d3.md): この規格では、ERC721を拡張して2つの参照可能なインジケーター (referingとreferred) と時間ベースのインジケーターであるcreatedTimestamp提案しています。
- [\[ERC6093\] ERC20・ERC721・ERC1155のカスタムエラーの提案を理解しよう！](https://cardene.dev/articles/ec266ece8e18c9c0d6f6.md): このEIP（Ethereum Improvement Proposal）は、Ethereum上で動作するトークンのスマートコントラクトに関する規格です。特に、ERC20、ERC721、ERC1155規格のトークンに関連しています。
- [\[ERC6808\] FKBTと呼ばれるERC20トークンをより安全に送付・管理する仕組みを理解しよう！](https://cardene.dev/articles/77f7104857ce86ee70c7.md): FKBT（Fungible Key Bound Tokens）は、スマートコントラクト内で使用されるトークンの一種で、Key Bound Tokens（KBT）というカテゴリーに属します。
- [\[ERC5114\] NFTとアドレスに紐づいたSBTライクな仕組みを理解しよう！](https://cardene.dev/articles/f447336e0c4eb3f886ad.md): ソウルバウンド・バッジは、NFT（非代替性トークン）トの一種です。このバッジは、作成（または発行）された瞬間から、別のNFTと"結びつき"、その後は二つを切り離すことができません。
- [\[ERC4944\] 1つのコントラクトで1つのNFTのみを管理する仕組みを理解しよう！](https://cardene.dev/articles/e201be85e598cf2693a7.md): ERC721は、イーサリアムブロックチェーン上でユニークなデジタルアセットであるノンファンジブルトークン（NFT）を作成するための規格です。
- [\[ERC4974\] コントラクト内でレートを管理する仕組みを理解しよう！](https://cardene.dev/articles/a3f3101dc80d52557e26.md): この規格は、Ethereumブロックチェーン上でレートを管理するための基準を設定したものです。レートとは、何かのアイテムやプロジェクトに対する数値的な評価やランキングのことを指します。
- [\[ERC7432\] NFTのさまざまなロールを管理する仕組みを理解しよう！](https://cardene.dev/articles/a095cc031af9824c3c62.md): この規格は、NFTに特定のロールを与える仕組みを提案しています。NFTごとにロールが紐づけられており、あらかじめ設定された時間が経過すると紐づけられたロールは自動的に無効になります。
- [\[ERC7401\] NFTでネスト構造を作るERC6059をアップデートした仕組みを理解しよう！](https://cardene.dev/articles/d9bbc27f188e1ce1d6cd.md): ERC7401は、ERC6059を置き換える新しい規格です。これは、NFT（非代替可能トークン）の親子関係を管理するためのもので、ERC721規格を拡張しています。
- [\[ERC6065\] 不動産NFTのインターフェースの仕組みを理解しよう！](https://cardene.dev/articles/9fd3bab02d48cdb40563.md): この提案は、ブロックチェーン上で不動産や物件を表現するための構造を提供しています。これにより、不動産をデジタルトークンとして扱うことが可能になります。
- [\[ERC5585\] NFTに紐づくさまざまな権利を管理する仕組みを理解しよう！](https://cardene.dev/articles/79feb0603be4184a3501.md): この提案は、ERC721規格のNFT（非代替性トークン）に関連しています。通常、NFTは特定のデジタルアセットやコンテンツを所有する権利を表します。
- [\[ERC4973\] Account Bound Tokenの仕組みを理解しよう！](https://cardene.dev/articles/dd116b4813ca699ed58e.md): Account-Bound Tokens（ABT）の標準API提案
- [\[ERC7498\] Openseaが提案する追加のデジタルアセットを紐づける仕組みを理解しよう！](https://cardene.dev/articles/26747762eaf00340cc25.md): この新しい仕様は、既存のNFT（非代替性トークン）規格であるERC721とERC1155を拡張するためのものです。
- [\[ERC7496\] Openseaが提案するメタデータをオンチェーンで管理する仕組みを理解しよう！](https://cardene.dev/articles/73b778dfaee423c213fa.md): この仕様は、NFTを管理するための新しいルールを導入しています。具体的には、ERC721とERC1155と呼ばれる既存のトークン規格を拡張しています。これらの規格は、NFTを表現するために使用されています。
- [\[ERC5791\] NFTの所有権を物理チップに紐付ける仕組みを理解しよう！](https://cardene.dev/articles/f38307c94463715ff5a9.md): この規格は、ERC721の規格を基にしています。ERC721は、非代替トークン（NFT）として知られるもので、独自の特性や所有権を持つデジタルアセットを表現するための枠組みです。
- [\[ERC5008\] NFTの送付などの状態を管理する仕組みを理解しよう！](https://cardene.dev/articles/1498eb062060ffbb88df.md): 提案されている規格では、ERC721トークンを拡張して「nonce」と呼ばれる概念を導入しようとしています。
- [\[ERC5725\] NFTを使用したべスティングの仕組みを理解しよう！](https://cardene.dev/articles/4b8820cb2ba7c08f9222.md): この規格は、NFT（非代替性トークン）を使用して、特定のトークン（たとえばERC20トークン）を段階的に解放する方法を提供するものです。
- [\[ERC6909\] ERC1155を使いやすくアップデートした仕組みを理解しよう！](https://cardene.dev/articles/edbc280b177255d1d981.md): この提案は、ERC-1155 Multi-Token Standardのシンプルな代替案として、マルチトークンコントラクトを定義しています。
- [\[ERC5496\] NFTに紐づく特典の柔軟なやり取りの仕組みを理解しよう！](https://cardene.dev/articles/004f0bd9c14cc5c46497.md): このEIP（Ethereum Improvement Proposal）は、EIP721を拡張するインターフェースを定義しています。この提案の目的は、NFTに新しい機能を追加することです。
- [\[Bunzz Decipher\] Nounsの『NounsDAOLogicV1』コントラクトを理解しよう！](https://cardene.dev/articles/68fcb8c7554d49.md): NounsDAOLogicV1というコントラクトは、Nouns DAO（分散型自治組織）システムの重要な要素です。
- [\[ERC5216\] 所有しているERC1155トークンの一部を他アドレスへ承認できる仕組みを理解しよう！](https://cardene.dev/articles/cde40951719798ead6f5.md): EIP1155は、同じトークンIDを持つ複数のトークンを効率的に管理する標準インターフェースを提供する企画です。
- [\[Bunzz Decipher\] Nounsの『NounsDAOExecutor』コントラクトを理解しよう！](https://cardene.dev/articles/b563db73d1a547.md): NounsDAOExecutorコントラクトは、Nouns DAO（分散型自治組織）システムにおいて重要な要素です。
- [\[Bunzz Decipher\] Nounsの『NounsAuctionHouse』コントラクトを理解しよう！](https://cardene.dev/articles/c7998dc19e5ae9.md): NounsAuctionHouse（名詞オークションハウス） コントラクトは、Nounsエコシステムの中で大切な部分で、デジタルアセットの所有権を表す特別なERC721トークンである「Nouns」をオークション形式で取引するための仕組みを提
- [\[Bunzz Decipher\] Nounsの『NounsSeeder』コントラクトを理解しよう！](https://cardene.dev/articles/234a91e746de6a.md): NounsSeederコントラクトは、Ethereumブロックチェーン上に構築されたNounsプロジェクトの中で重要な役割を果たすコントラクトです。
- [\[Bunzz Decipher\] Nounsの『NounsDescriptor』コントラクトを理解しよう！](https://cardene.dev/articles/87a238ea31f0ba.md): NounsDescriptorコントラクトは、Ethereumブロックチェーン上の大規模なシステムの重要なコントラクトです。
- [\[ERC5646\] トークンの状態を追跡できるインターフェースの仕組みを理解しよう！](https://cardene.dev/articles/20e5db0d7404d3684eaf.md): この規格では、ミュータブル（可変）トークンと呼ばれる状態が変更できるトークンに関連しています。例えば、ゲーム内のアイテムやデジタルアセットがこれに当たります。
- [\[Bunzz Decipher\] Nounsの『NounsToken』コントラクトを理解しよう！](https://cardene.dev/articles/6d806a814f0720.md): NounsTokenコントラクトは、Nouns DAOプロジェクトの中心的なコントラクトです。Nouns DAOは、非代替可能トークン（NFT）と呼ばれるユニークなデジタルアセットを作成し管理する分散型自治組織（DAO）です。
- [\[ERC4906\] NFTのメタデータの変更をログに残すインターフェースの仕組みを理解しよう！](https://cardene.dev/articles/a1f334a059f08971cfaa.md): この標準は、EIP721の拡張版です。EIP721トークンにMetadataUpdateイベントを追加します。
- [\[ERC3475\] 債券をトークン化して発行や償還ができる仕組みを理解しよう！](https://cardene.dev/articles/6b45573b83b926381ac3.md): このEIPは、ブロックチェーン上で債券をトークン化するための提案です。従来のトークン規格では、複数の償還データを持つ債券を作成することが難しかったのですが、このEIPによってその問題が解決されます。
- [\[ERC5773\] NFTの提供形式を画像・PDF・3Dモデルに切り替えたり、内容をアップデートする仕組みを理解しよう！](https://cardene.dev/articles/ec6641365505a2c06964.md): マルチアセットNFT規格は、デジタルアセットをより柔軟に、かつ多様な形式で表現できる方法を提供するもので、個々のNFTに合わせて異なる情報を表示する方法を提供します。
- [\[ERC5375\] NFTの作者の情報や作者の証明を格納する仕組みを理解しよう！](https://cardene.dev/articles/ff4ed253fc6a793f6643.md): この提案（EIP）は、NFTに関連する改善案です。NFTは一意で交換できないトークンであり、デジタルアートやコレクションアイテムなどに使用されます。
- [\[ERC6105\] NFTマケプレに頼らずにNFTの取引を実現する仕組みを理解しよう！](https://cardene.dev/articles/a9f1d3f91867955490a1.md): このERC（Ethereum Request for Comments）は、ERC721にマーケットプレイスの機能を追加して、中間取引プラットフォームに頼らずに非代替可能トークン（NFT）の取引を可能にするものです。
- [\[ERC6059\] 複数NFTコレクションでネスト構造を作る仕組みを理解しよう！](https://cardene.dev/articles/544b01bc14850ecd657c.md): 「Parent-Governed Nestable NFT」標準は、ERC721を進化させ、異なるNFT同士の関係や相互作用を可能にする提案です。
- [\[ERC6150\] NFTにLinuxのファイルシステムのような階層構造を持たせる仕組みを理解しよう！](https://cardene.dev/articles/38c75ae824373684aecd.md): この標準は、EIP721を拡張したものです。多層のファイルシステムのような階層型NFTを提案しています。
- [\[ERC6220\] NFTをNFTに装備できるコンポーザブルな仕組みを理解しよう！](https://cardene.dev/articles/0c522d50a33424cba122.md): 「Composable NFTs utilizing equippable parts」は、ERC721を拡張し、NFT（非代替トークン）が自身にパーツを選択して装備することを可能にする標準です。
- [\[ERC5570\] レシートをNFTとして発行する仕組みを理解しよう！](https://cardene.dev/articles/88952bcd669fbaa431a3.md): このERC提案は、取引のデジタルレシートに関する標準スキーマを提案しています。
- [\[ERC6381\] NFTに絵文字を付与することができる仕組みについて理解しよう！](https://cardene.dev/articles/d22d76d1cf66c34f1e57.md): この公共非代替トークンEmotリポジトリ標準は、ERC721およびERC1155に対して、NFTに感情を込めることを可能にする強化された対話型ユーティリティを提供します。
- [\[ERC2135\] NFTの使用を管理するインターフェースの仕組みを理解しよう！](https://cardene.dev/articles/7174e91de844899eca72.md): このEIPは、Ethereum上でデジタルアセットに「消費可能」というマークをつけ、「消費」に対応するためのインターフェースを提供することを目的としています。
- [\[ERC4955\] 複数メタバースにNFTを適用させる仕組みを理解しよう！](https://cardene.dev/articles/149f522758cff5a8820a.md): このEIP（Ethereum Improvement Proposal）では、ERC721およびERC1155と呼ばれるEthereumのNFT（非代替トークン）の標準に、新しいフィールド名前空間を追加することを目的としています。
- [\[ERC1046\] ERC20のメタデータをERC721のようにする仕組みを理解しよう！](https://cardene.dev/articles/90e8e7f6f1646f8c8cfe.md): ERC721は、イーサリアムブロックチェーン上で非代替可能トークン（NFT）を作成するための標準規格です。これにより、異なるデジタルアセットやコレクティブルなアイテムを一意に識別し、所有権をトークンとして表現できます。
- [\[ERC5023\] NFTをコピーして送付できる仕組みを理解しよう！](https://cardene.dev/articles/d4604dcc8f4bbfc90208.md): この提案では、他と交換できない価値を持つトークンを共有可能にするインターフェースを標準化します。共有可能なトークンは、既存のトークンを別のアドレス用ににコピーして作成されます。
- [\[ERC4519\] 物理的な資産とNFTを紐づける仕組みを理解しよう！](https://cardene.dev/articles/b26de6b3826dc72d39d9.md): このEIPは、物理的な資産（例：IoTデバイス）を表す非代替トークン（Non-Fungible Token、NFT）のインターフェースを標準化します。
- [\[ERC4907\] NFTを使用できる期限付きのロールを付与する仕組みを理解しよう！](https://cardene.dev/articles/253672c18241edcc57eb.md): この標準は、EIP721の拡張機能です。新たに「user」ロールが提案され、このロールがアドレスに付与される期間が自動的に取り消される（expires）仕組みが提案されています。
- [\[ERC3525\] ERC721とERC20の特徴を併せ持つ半代替性トークンの仕組みを理解しよう！](https://cardene.dev/articles/9dc7bad8211af65fa285.md): この提案は、セミファンジブルトークン（semi-fungible tokens）の標準についてまとめたものです。この文書で説明されているスマートコントラクトインターフェースのセットは、ERC721互換のトークン標準を定義しています。
- [\[ERC5006\] ERC1155のNFTの所有権と使用権を分離した仕組みを理解しよう！](https://cardene.dev/articles/7c3520f068d7888aa692.md): ERC721と同様に、ERC1155トークンには様々なユースケースが想定されます。例えば、トークンを使用できるアドレスとトークンの所有者のアドレスが異なる場合があります（例：レンタル）。
- [\[ERC5007\] NFTの有効期間を管理する仕組みを理解しよう！](https://cardene.dev/articles/b1f4e51c4d34938960f2.md): 一部のNFTは使用期間が決められており、その期間外では使用できません。時間情報が定義されていない従来のERC721規格のNFTでは、NFTを時間情報によって無効/有効するには、処理が煩雑でガス代が余分にかかってしまいます。
- [\[ERC5484\] SBTのMint時にBurnできる権限を付与する仕組みを理解しよう！](https://cardene.dev/articles/12fbba291e17f96b4610.md): このEIPは、EIP721を拡張してSBTを作成するインターフェースを定義します。
- [ERC721の拡張機能をざっくり仕組みから理解しよう！](https://cardene.dev/articles/15f9f5b16da8447d5226.md): まずはOpenZeppelinとは何かから確認していきましょう。OpenZeppelinとは、「安全にスマートコントラクトを開発するためのライブラリ」のことです。
- [\[ERC5606\] 1つのNFTを使用して複数プラットフォームで利用できるアセットを作成しよう！](https://cardene.dev/articles/19029053e56f7a5846da.md): この仕様では、ウェアラブルやゲーム内アイテムなどのデジタルアセットのためのマルチバースNFTを作成するための最小限の標準インターフェースを提案しています。
- [\[EIP5679\] ERC20, ERC721, ERC1155のMintとBurnの実装を統一しよう！](https://cardene.dev/articles/3be55bed3c7793830513.md): EIP20やEIP721、EIP1155などのトークンのMint（生成）とBurn（破棄）はよく実行されます。トークンのMint（生成）とBurn（破棄）の実行を統一した方法で行いベースとなるライフサイクルを提案します。
- [\[ERC4400\] NFTに『consumer』という新たなロールを付与してみよう！](https://cardene.dev/articles/9807131ded7d1da7f9d9.md): ERC721規格のNFTの所有者が、特定の役割（以下ロール）を他のアドレスへ与えるための標準化された関数を定義しています。特定のロールを与えられたアドレスをこの提案の中ではconsumerと名付けています。
- [\[ERC5489\] NFTにハイパーリンクをつける機能を理解しよう！](https://cardene.dev/articles/b8ec87ca082fffeb3639.md): ERC721規格のNFTの新たな拡張を提案します。nft-hyperlink-extention（hNFT）　とは、NFTにハイパーリンクを組み込むもので、hNFTsと呼ばれます。
- [\[ERC2309\] 複数のNFTの作成や送付時に発行されるログの標準規格を理解しよう！](https://cardene.dev/articles/f79a04d6b879178053d5.md): 1つ以上の連続したトークンIDのERC721規格のNFTを発行、もしくは送付する標準化されたイベントを発行する。
- [\[ERC6454\] NFTがTransfer可能か検証するインターフェースの提案を理解しよう！](https://cardene.dev/articles/80abea7cc74f2bb5bd9f.md): 「Minimalistic Transferable interface for Non-Fungible Tokens（NFT）」規格は、ERC721規格を拡張し、NFTがTransfer（送付）可能か識別機能です。
- [\[Bunzz Decipher\] BAYC (BoredApeYachtClub)のコントラクトを見てみよう！](https://cardene.dev/articles/dab1107e0f9e0f.md): BAYCは、 NFTであるERC721トークンの標準規格であり、Ethereumブロックチェーン上に構築されたコントラクトです。
- [\[ERC5192\] NFTを送付できなくする『SBT』について理解しよう！](https://cardene.dev/articles/01b2463cb87f391498a8.md): この規格はEEC721規格のNFTの拡張で、EIP165のチェック機能を用いてNFTをソウルバウンドにする提案しています。SBT（ソウルバウンドトークン）は、1つのアドレスに紐づけられたNFTで、他のアドレスに送ることができなくなります。
- [\[ERC5380\] NFTの使用権限を他のアドレスに付与しよう！](https://cardene.dev/articles/96c2923bc1f967ea7a28.md): ERC721規格のNFT所有者が、あるアドレスに対してNFTの限定的な使用を許可する新たなインターフェースの提案です。
- [ERC721の拡張機能である『ERC721A』について理解しよう！](https://cardene.dev/articles/4aaed6f3022b84963c0e.md): ERC721Aは名前の通りERC721の拡張機能です。
- [\[ERC5615\] ERC1155で作られた全てのNFTを取得してみよう！](https://cardene.dev/articles/58d0e490df74dff38e76.md): ERC1155の拡張機能です。ERC1155トークンに、与えられたトークンIDを持つトークンの数を取得するtotalSupply関数と、与えられたトークンIDの存在を確認するexists関数を追加します。
- [\[ERC6672\] いろんなイベントでNFTと物理/デジタルアイテムを交換しよう！](https://cardene.dev/articles/783911914c3aa61d9f5e.md): ERC721規格の拡張機能の提案です。
- [\[ERC6147\] NFTに『guard』ロールを付与して機能拡張しよう！](https://cardene.dev/articles/8dee2730cd71d43774d9.md): ERC721の拡張であり、NFTやSBTの保有権と譲渡権を分離し、有効期限（expires）を持たせる新しいロールである「guard」を付与するします。
- [\[ERC2981\]NFTのロイヤリティ強制化!? ERC2981の仕組みについて理解しよう！](https://cardene.dev/articles/456ccacca080fd72e3ec.md): NFTを販売する時マーケットプレイスという、NFTの売買ができるプラットフォームに出品することがほとんどです。このマーケットプレイスで二次販売を行うとき、ロイヤリティを受け取れるかがマーケットプレイス次第であることが問題となっています。
- [Web3を学ぶ動画/音声チャンネル・サイト一覧](https://cardene.dev/articles/7d45f37d78eff9e914b7.md): この章ではエンジニアを対象としたYoutubeチャンネルを紹介していきます。
- [ERC20とERC721を1からわかりやすく解説](https://cardene.dev/articles/60ee4178bf7879.md): ERC20とは、「Ethereumブロックチェーンで動作する統一されたトークン規格の1つ」です。
- [\[図解\]マークルツリーについて理解しよう！〜ブロックチェーンに絡めながらわかりやすく解説〜](https://cardene.dev/articles/ce0efdc11cf905.md): まずは「マークルツリー」がどんなものなのかや関連用語について解説していきます。

## Blockchain / DeFi

- [\[ERC8017\] 固定額を支払ってバケット内の資産を全量受け取る仕組みを理解しよう！](https://cardene.dev/articles/6b385dbb7f7d11c50e34.md): ERC8017は、1種類の払い出し資産を入れておくバケットコントラクトと、固定額の支払いでそのバケット全量を受け取る purchase() 関数を定義する提案です。
- [\[ERC8161\] まだ完了していない入金と償還を譲渡できる仕組みを理解しよう！](https://cardene.dev/articles/7935e7c3fb192c791a81.md): ERC8161は、ERC7540の非同期入金リクエストと非同期償還リクエストに対して、Pending状態の残高だけを別のcontrollerへ譲渡できるようにする拡張仕様です。
- [\[ERC7893\] DeFiプロトコルの支払い能力をオンチェーンで証明・監視する仕組みを理解しよう！](https://cardene.dev/articles/72f566a5114c6096919e.md): ERC7893とは、DeFiプロトコルがスマートコントラクト上で検証可能なソルベンシー証明（支払い能力の証明）を実装するための標準インターフェースです。
- [\[ERC7770\] 担保と借入で発行される合成資産の仕組みを理解しよう！](https://cardene.dev/articles/2d3d344360c30d4bb861.md): ERC7770は、「部分的にしか裏付け資産と交換できないが、他の担保資産によって全体としては完全に裏付けられている合成資産（シンセティックアセット）」のための新しいトークン規格です。
- [\[ERC7726\] 価格ではなく数量で評価するオラクルの仕組みを理解しよう！](https://cardene.dev/articles/87f86d6cbcb0c4f31d75.md): ERC7726は、資産の相対的な価値を提供するデータフィード（いわゆる価格情報）に対して、共通のAPI仕様を定義するERCです。
- [オンチェーンFXを実現するCircleのStableFX](https://cardene.dev/articles/stablefx-onchain-fx-engine.md): 外国為替（FX）市場は1日あたり9兆ドルを超える取引量を持つ世界最大の金融市場です。しかし、その規模にもかかわらず、インフラの多くは数十年前の仕組みに依存しています。
- [\[ERC6787\] 二段階出金に対応したOrder Book DEXの仕組みを理解しよう！](https://cardene.dev/articles/d9638e22435bfe2cfc1d.md): Order Book DEX Standardは、注文板を使って資産を売買する分散型取引所（DEX）を実装するための共通インターフェース仕様です。
- [\[ERC6229\] ロック期間付きERC4626ボールトの仕組みを理解しよう！](https://cardene.dev/articles/cce575948e97e4d23516.md): ERC6229は、既存のERC4626（トークン化された資産管理ボールトの規格）に、一定期間トークンを引き出せない「ロック期間」を組み込むための仕組みを追加する提案です。
- [\[ERC6123\] デリバティブの担保・決済を自動化する仕組みを理解しよう！](https://cardene.dev/articles/d0ede8f0e0cc3363abc1.md): Smart Derivative Contract（以下、SDC）は、金融派生商品や債券といった金融商品の取引開始から決済完了までの一連のプロセスを完全に自動化し、安全に実行するための仕組みです。
- [\[ERC7586\] オンチェーン金利スワップの標準化提案の仕組みを理解しよう！](https://cardene.dev/articles/fc7205de3717a2f5ecf6.md): ERC7586は、ブロックチェーン上で利率スワップ（Interest Rate Swap：IRS）を標準化するためのフレームワークを導入する提案です。
- [\[ERC7399\] フラッシュローンを標準化する仕組みを理解しよう！](https://cardene.dev/articles/3629aa932a431c0c0530.md): フラッシュローンとは、ブロックチェーン上で動作するスマートコントラクト（自動で契約内容を実行するプログラム）同士の間で行われる特殊なローン取引のことです。
- [Chainlink Functions](https://cardene.dev/articles/790042a9bd6ceb.md): Chainlink Functionsは、ブロックチェーン上のスマートコントラクトが、ブロックチェーンの外（オフチェーン）にある信頼性の高い計算インフラへ安全にアクセスできるようにするサービスです。
- [\[ERC7540\] ERC4626の入金と償還のリクエストと処理実行を分離する仕組みを理解しよう！](https://cardene.dev/articles/4aa8cf3f1806f966ce4a.md): ERC7540は、ERC4626を拡張し、非同期的な入金（Deposit）と償還（Redemption） をサポートする規格です。非同期的な処理は「リクエスト（Request）」と呼ばれ、新しいメソッドを追加することで実行できます。
- [\[ERC7575\] ERC4626を拡張してマルチアセット保管を可能にする仕組みを理解しよう！](https://cardene.dev/articles/13daf479168d2cb653ba.md): まず、ERC4626、ERC20、ERC165などの用語が出てくるのでこの説明からしていきます。
- [\[ERC7535\] ERC4626にネイティブトークンを活用する仕組みを理解しよう！](https://cardene.dev/articles/30d8292805d1c54cfee1.md): この規格は、ERC4626という既存の Ethereum コントラクト規格に追加機能をもたらすもので、特に Ether や他のネイティブアセットを基盤資産として取り扱う時のインターフェースと動作をカスタマイズする点に特徴があります。
- [\[ERC2266\] 第三者なしで直接トークンを交換するアトミックスワップの仕組みを理解しよう！](https://cardene.dev/articles/4e263429568fac8c8d5c.md): この標準は、トークンコントラクトがアメリカンコールオプションという特定の種類のオプション取引を行えるようにするためのものです。アメリカンコールオプションとは、購入者が特定の期間内にある価格で資産を購入する権利を持つことを意味します。
- [\[ERC3156\] Ethereumチェーン上でフラッシュローンを実装する仕組みを理解しよう！](https://cardene.dev/articles/0158dd70155b165abf8d.md): このERCは、イーサリアムのブロックチェーン上で、特定の種類の取引、つまりフラッシュローンを行う時に必要なルールや手順を定めたものです。
- [\[Technical Reference編\] UniswapV3のドキュメントを読んでみよう！](https://cardene.dev/articles/b5a4293f85fd1a.md): Uniswap V3は、多くのライブラリで構成されたバイナリスマートコントラクトシステムで、これらのライブラリはCore（コア）とPeriphery（周辺）を形成しています。
- [UniswapV3のドキュメントを読んでみよう！](https://cardene.dev/articles/5aad9233c7fabb.md): Uniswap V3は、スマートコントラクトを使用したプロトコルであり、分散型取引所（DEX）の一つです。このプロトコルは、ユーザーが異なるトークンを交換したり流動性を提供したりすることを可能にします。
- [\[Bunzz Decipher\] UniswapV3の『NFTDescriptor』コントラクトを理解しよう！](https://cardene.dev/articles/879b65cd81343a.md): NFTDescriptorは、NFT（非代替トークン）の説明を作成するコントラクトです。これによって、NFTの特徴や情報をユーザーに分かりやすく伝えることができます。
- [\[Bunzz Decipher\] UniswapV3の『Quoter』コントラクトを理解しよう！](https://cardene.dev/articles/a08b8dcd55f569.md): Quoter（クォーター） コントラクトは、Uniswap v3プロトコル内で非常に重要な役割を果たしています。このコントラクトは、Uniswap分散型取引所でのトークンスワップに関する見積もり機能を提供します。
- [\[Bunzz Decipher\] UniswapV3の『TickLens』コントラクトを理解しよう！](https://cardene.dev/articles/d546eea4729041.md): TickLens（ティックレンズ）コントラクトは、Uniswap V3プロトコルの一部であり、リクイディティプールに関する詳細な情報を提供します。
- [\[Bunzz Decipher\] UniswapV3の『QuoterV2』コントラクトを理解しよう！](https://cardene.dev/articles/48804dad7bb857.md): QuoterV2コントラクトは、Uniswap V3プロトコルの中でトークンのスワップに関する正確な見積もりを提供します。このコントラクトは、Uniswapプラットフォーム上で効率的かつ信頼性の高いトークンスワップの実行をサポートします。
- [\[Decipher\] UniswapV3の『NonfungibleTokenPositionDescriptor』コントラクトを理解しよう！](https://cardene.dev/articles/e59072e94c78e7.md): Uniswap V3プロトコルの「NonfungibleTokenPositionDescriptor（NFTポジションの詳細）」コントラクトは、非代替トークン（NFT）のポジションについて詳細な情報を提供します。
- [\[Bunzz Decipher\] UniswapV3の『NonfungiblePositionManager』コントラクトを理解しよう！](https://cardene.dev/articles/96c6fa9d04460c.md): Uniswap v3プロトコルの中心的な要素であるNonfungiblePositionManager（非代替ポジションマネージャー）コントラクトは、Uniswap v3の流動性プール内に存在する特別なポジションを管理するのが役割です。
- [\[Bunzz Decipher\] UniswapV3の『V3Migrator』コントラクトを理解しよう！](https://cardene.dev/articles/197e0f1ed053ac.md): Uniswap V3プロトコルの一部であるV3Migratorコントラクトは、、ユーザーが以前のUniswap V2の流動性を新しいUniswap V3に移すのを支援する役割を果たしています。
- [\[Bunzz Decipher\] UniswapV3のUniversalRouterコントラクトを理解しよう！](https://cardene.dev/articles/b00b2a32c615e3.md): UniversalRouterコントラクトは、私たちのdAppエコシステムにおける重要な要素です。このコントラクトは、プラットフォーム内で発生するさまざまなトランザクションの中枢として機能します。
- [\[Bunzz Decipher\] UniswapV3のSwapRouter02コントラクトを理解しよう！](https://cardene.dev/articles/989121595dda7c.md): SwapRouter02コントラクトは、Uniswap分散型取引プロトコルの重要なコンポーネントです。このコントラクトは、Uniswapプラットフォーム上でトークンを交換するためのルーターとして機能します。
- [\[Bunzz Decipher\] UniswapV3のSwapRouterコントラクトを理解しよう！](https://cardene.dev/articles/614571336c74e2.md): SwapRouterコントラクトは、Uniswap V3プロトコルの重要な部分で、Ethereumブロックチェーン上で効率的で安全なトークンスワップを実行します。
- [\[Bunzz Decipher\] UniswapV3Factoryコントラクトを理解しよう！](https://cardene.dev/articles/61ee19994743fd.md): UniswapV3Factoryコントラクトは、Uniswap V3プロトコルの中で重要な機能です。このコントラクトは、ユーザーが流動性プールを作成し、それに参加するためのプラットフォームを提供しています。
- [Uniswapのドキュメントを読んでみよう！](https://cardene.dev/articles/b18277a7b568a5.md): Uniswapには、以下のようないくつかの領域が存在します。
- [\[Bunzz Decipher\] UniswapV2Migratorのコントラクトを理解しよう！](https://cardene.dev/articles/644169eae6e90c.md): UniswapV2Migratorコントラクトは、Ethereumブロックチェーン上に構築された分散型取引所（DEX）であるUniswapプロトコルの重要なコンポーネントです。
- [UniswapV2のドキュメントを読んでみよう！](https://cardene.dev/articles/6e4f33d07bc93a.md): UniswapV2は、分散型取引所プロトコルのバージョン2であり、その詳細なコンセプトと技術的な情報が含まれています。
- [\[Bunzz Decipher\] UniswapV2Router01のコントラクトを理解しよう！](https://cardene.dev/articles/75433e91eea8cc.md): UniswapV2Router01コントラクトは、Ethereumブロックチェーン上に構築された分散型取引所（DEX）であるUniswapプロトコルの重要な部分です。
- [\[Bunzz Decipher\] UniswapV2Router02のコントラクトを理解しよう！](https://cardene.dev/articles/a958a6870d9016.md): UniswapV2Router02コントラクトは、Ethereumブロックチェーン上に構築された分散型取引所（DEX）であるUniswapプロトコルの重要なコンポーネントです。
- [\[Bunzz Decipher\] UniswapのUNIトークンのコントラクトを理解しよう！](https://cardene.dev/articles/ea1fd18d81dc94.md): UniコントラクトはEthereumブロックチェーン上に展開されたスマートコントラクトです。このコントラクトはUniswapトークン（UNI）を管理するために設計されています。
- [\[Bunzz Decipher\] UniswapV2Factoryのコントラクトを理解しよう！](https://cardene.dev/articles/89744d2e9629f4.md): UniswapV2Factoryコントラクトは、Uniswapプロトコルの重要な構成要素であり、すべての展開済みPairコントラクトのレジストリとして機能しています。
- [\[Bunzz Decipher\] UniswapV2Pairのコントラクトを理解しよう！](https://cardene.dev/articles/dde2314cb2417b.md): UniswapV2Pairコントラクトは、Ethereumブロックチェーン上に構築された分散型取引所 Uniswapプロトコルの重要な一部です。このコントラクトは、一対のERC20トークンの取引を管理および実行する役割を担っています。
- [\[ERC4626\] あるトークンを保有していると報酬を受け取れる標準規格の仕組みを理解しよう！](https://cardene.dev/articles/99db4ee3074ab6c8c4e2.md): この規格により、ERC20トークンを元にVault（保管庫）とをトークン化する標準APIの実装が可能となります。

## Blockchain / Payments

- [\[ERC8056\] ERC20トークンの実残高を変えずに表示数量だけを調整する仕組みを理解しよう！](https://cardene.dev/articles/a7eb4e6d40793a5ce75e.md): ERC8056は、ERC20トークンに表示用の倍率を追加する拡張です。提案名では、この仕組みを Scaled UI Amount Extension と呼んでいます。
- [\[EIP7973\] 同じアドレスへの2回目以降のETH送金を安くする仕組みを理解しよう！](https://cardene.dev/articles/13928a9c2bbae0a3e7a5.md): EIP7973とは、アカウントへの書き込み操作に「2回目以降は安くする」仕組み（warm metering）を導入する提案です。
- [\[ERC7994\] ERC20トークンに複数のアンロック条件を設定して条件付き送金を実現する仕組みを理解しよう！](https://cardene.dev/articles/747ed8133384bf442569.md): ERC7994は、ERC7291で導入されたPurpose Bound Money（目的拘束型通貨）の概念をERC20トークンに拡張し、複数のアンロック条件を組み合わせてプログラマブルな送金制約を実現する規格です。
- [\[ERC7699\] ERC20送金に支払い参照を持たせる仕組みを理解しよう！](https://cardene.dev/articles/8aeed08a9ffa827109b8.md): ERC7699は、ERC20トークンの送金に「支払い参照情報」を付与できるようにする拡張仕様です。ここでいう支払い参照情報とは、「この送金が何の支払いなのか」を示す短いメッセージや識別情報のことです。
- [HTTP 402ベースの支払いプロトコルx402を理解しよう](https://cardene.dev/articles/x402-introduction.md): 「x402」は、HTTPの 402 Payment Required ステータスコードを活用したオープンな支払いプロトコルです。
- [\[ERC7518\] 規制対応と資産管理を両立するセキュリティトークンの仕組みを理解しよう！](https://cardene.dev/articles/355d512b5b3cb15efbbb.md): ERC1155を拡張したセキュリティトークン標準は、実物資産（不動産やファンドなどの現実世界の資産）を、証券として適切に取り扱うためのトークン規格です。
- [Commerce Payments Protocolで実現するオンチェーンAuth & Capture](https://cardene.dev/articles/commerce-payments-protocol-auth-capture.md): BaseチェーンでクレジットカードのAuth & Captureを実現するCommerce Payments Protocolを、エスクローの仕組み、6つの決済オペレーション、Operatorの制約、手数料の設定から解説します。
- [\[ERC6932\] 定期支払いを自動化する仕組みを理解しよう！](https://cardene.dev/articles/b13d8405b157c0a717ce.md): ERCサブスクリプショントークンは、既存のERC20トークン（残高管理や送金のインターフェースが標準化されたトークン仕様）に、「定期支払い（サブスクリプション）」の仕組みを追加したトークンです。
- [\[ERC7943\] 現実世界の資産を安全に扱うUniversal RWAの仕組みを理解しよう！](https://cardene.dev/articles/c48a8b2390ec7601fd6c.md): ERC7943は、ブロックチェーン上で「現実資産（Real World Assets / RWA）」をトークン化するときに必要になる共通のインターフェースを定める「uRWA（Universal RWA）標準」を提案しています。
- [\[ERC7828\] ENSを活用したチェーン識別と安全な送金の仕組みを理解しよう！](https://cardene.dev/articles/470e4fe9b68af4ca2595.md): ERC7828は、ERC7930（Interoperable Addresses & Names）の拡張仕様です。主な目的は、アドレスとチェーンを結びつけた人間に読みやすい形式を標準化することです。
- [\[HIP15\] Hederaアドレスのチェックサムによる誤送金防止の仕組みを理解しよう！](https://cardene.dev/articles/2016225aa200712f7d43.md): Hederaでは、アドレスを「チェックサム付き」と「チェックサムなし」の2種類で表記できます。チェックサムとは、アドレスの後に5文字の英小文字を追加したもので、入力ミスや桁間違いを検出するために用いられます。
- [\[ERC1973\] 分散型報酬分配の仕組みを理解しよう！](https://cardene.dev/articles/692eea05c6c601edae1e.md): ERC1973では、分散型アプリケーション（DApp）においてアクティブな参加者に対し、ブロックごとに発行されるトークンを均等に分配する仕組みが紹介されています。
- [\[ERC2021\] トークン支払いリクエスト管理の仕組みを理解しよう！](https://cardene.dev/articles/cc0b146baa0d68d20fda.md): ERC2021は、ERC20トークンに対してトークン保有者が自身のウォレットからの支払い（払い出し）をリクエストできる機能を追加する提案です。
- [\[ERC1996\] 将来の送金を実行できるHold機能の仕組みを理解しよう！](https://cardene.dev/articles/828581bf1626b4d8d48c.md): ERC1996は、ERC20トークンに「Hold（保留）」機能を追加する拡張提案です。この機能により、将来的に確実なトークン送付を約束することが可能になります。
- [JPMD](https://cardene.dev/articles/d86fad8ed30994.md): ERC20トークンをベースに構築されています。複数のロールごとに実行できる権限が管理されています。中央集権的な機能があり、特定のロールを持つアドレスからであればユーザーが保有しているトークンを勝手に送付したりできるようになっています。
- [\[ERC6506\] DAO投票に報酬を安全に渡す仕組みを理解しよう！](https://cardene.dev/articles/9b9464d75c950d7ab113.md): ERC6506では、DAO（分散型自律組織）における投票のインセンティブを透明かつ安全に行うための標準的なスマートコントラクトのインターフェースを定義します。
- [\[ERC2876\] 入金時に識別子を付与して入金情報を管理しやすくする仕組みを理解しよう！](https://cardene.dev/articles/63d3261a793884161332.md): ERC2876は、ETHのデポジット（入金）を効率的かつ安全に処理するためのコントラクトインターフェースを定義する提案です。
- [\[ERC2917\] ステーキング報酬をオンチェーンで計算する仕組みを理解しよう！](https://cardene.dev/articles/1bc83271cfe0ef2e52d9.md): ERC2917は、ステーキング報酬をチェーン上で計算する提案です。ERC2917では、ユーザーの報酬を「有効な担保量（＝生産性）×時間」の積をもとにリアルタイムで算出する仕組みを導入しています。報酬の計算式は次の通りです。
- [\[ERC3135\] オンチェーン処理を最小限にしたマイクロペイメントの仕組みを理解しよう！](https://cardene.dev/articles/c4a7f4c14219d615f8f9.md): ERC3135は、ERC20のような既存のトークン標準に追加機能を加え、オンラインおよびオフラインのサービス提供者が多数のユーザーと簡単にマイクロペイメントチャネル（少額決済のためのチャネル）を構築できる仕組みを提供しています。
- [\[ERC5827\] ERC20トークンをサブスクリプションや給与支払いに使用できる仕組みを理解しよう！](https://cardene.dev/articles/4c22af4fbae97da72f6e.md): ERC5827は、ERC20の承認メカニズムに「renewable allowance」を追加する提案です。具体的には、recoveryRate というパラメータを導入し、トークンの許可額が時間の経過とともに回復する仕組みになっています。
- [\[ERC6353\] ERC20の送金時に一定の割合を別のアドレスに送付する仕組みを理解しよう！](https://cardene.dev/articles/f69e43cecfb68994be7d.md): ERC6353は、ERC20トークンの機能を拡張してトークンの送金時に一定の割合を自動的に第三者へ送れるようにする提案です。例えば、トークンの送金と同時に指定された慈善団体へ寄付を行うことができます。
- [\[ERC7578\] RWAに使用できる物理資産情報をトークンに紐づける仕組みを理解しよう！](https://cardene.dev/articles/fefe476f23b3760a8c3e.md): この規格はERC721を拡張して、物理的な資産を裏付けとするNFTの保有者が、その資産の真正性を確認して物理的資産と交換できる情報を取得できる仕組みを提案しています。これにより、以下の情報をNFTに紐づけて透明性を保ちます。
- [\[ERC7580\] オンチェーンでのユーザーアクションと広告報酬を追跡する仕組みを理解しよう！](https://cardene.dev/articles/f80e34df74ba109dcc3c.md): この規格では、広告クライアントがコントラクト内のユーザーアクションを追跡し、広告プロトコルからの報酬を確認するための標準インターフェースを提案しています。
- [\[EIP7092\] 債券のトークン化を簡素化する新たな標準の仕組みを理解しよう！](https://cardene.dev/articles/34f462a4d08e373d992c.md): この提案は、固定利付き金融債券に関するものです。この債券には、以下のような主要な特徴があります。
- [\[EIP7291\] 取引の条件が満たされた時に自動的に支払いを行うPBM（Purpose Bound Money）の仕組みを理解しよう！](https://cardene.dev/articles/887a4ba382543d1666a1.md): この提案は、PBM（Purpose Bound Money）というコンセプトを実装するために、ERC1155標準を拡張したスマートコントラクトインターフェースを構築するものです。
- [\[EIP649\] difficulty bombを遅延させてブロック報酬を調整する提案を理解しよう！](https://cardene.dev/articles/c553ec071cb5015c1254.md): イーサリアムのネットワークでは、「難易度爆弾（difficulty bomb）」というメカニズムが導入されており、これは意図的にブロック生成時間を時間が経つにつれて遅くするものです。
- [\[ERC3643\] 「T-REX」という機関投資家向けのセキュリティトークンの仕組みを理解しよう！](https://cardene.dev/articles/1978a45e1b98133491c5.md): T-REXトークンは、デジタル資産のセキュリティと取引を保証するための新しい標準です。
- [\[ERC681\] ETHやERC20を送金できるURLの仕組みついて理解しよう！](https://cardene.dev/articles/87cb8429d7a2f0db7c28.md): この方法は、主にイーサリアムネットワーク上での支払いリクエストに使われます。このURL方式では、あなたがイーサリアムやERC20トークンを送る時、その取引の詳細（送り先のアドレス、金額、トークンの種類など）を含むURLが作られます。
- [\[ERC5528\] エスクロー・スマートコントラクトの払い戻しを可能にする規格を理解しよう！](https://cardene.dev/articles/64092b7680b953154a21.md): この規格はEIP20の拡張で以下のエスクローサービスのフローを定義します。

## Blockchain / Token

- [\[ERC8255\] トークンの利用許可を期限付きにする仕組み](https://cardene.dev/articles/3bd1980e74261e001e11.md): 利用者がアプリへトークンを動かす許可を出す時、使える量だけでなく終了時刻も一緒に記録します。終了時刻までは許可された量を使え、時刻を過ぎると保存中の量が残っていても使えません。
- [\[ERC7962\] アドレスの代わりに鍵ハッシュでトークンを管理するKey Hash Based Tokensの仕組みを理解しよう！](https://cardene.dev/articles/6a95e6b6280c56a0ce86.md): ERC7962とは、従来のERC721（NFT）やERC20（FT）のようにEthereumアドレスで所有権を管理するのではなく、公開鍵のハッシュ値（keyHash = keccak256(key)）で所有権を管理するトークンインターフェー
- [\[ERC8063\] ERC20トークンの残高でグループメンバーシップを表現する仕組みを理解しよう！](https://cardene.dev/articles/f84ac39bd08ad5e02689.md): ERC8063とは、ERC20トークンの残高をそのまま「グループメンバーシップのレベル」として解釈する仕組みを定義した提案です。
- [\[ERC7802\] クロスチェーンブリッジでトークンをmint・burnするための標準インターフェースを理解しよう！](https://cardene.dev/articles/f3781e115e73c6289633.md): 今回は「ERC7802によるクロスチェーントークンインターフェースの標準化」についてまとめてきました！いかがだったでしょうか？
- [\[ERC7722\] 残高を公開しないトークン設計の仕組みを理解しよう！](https://cardene.dev/articles/7339460d4c50fadead62.md): ERC7722は、トークンの残高情報をオンチェーン上にそのまま記録しないことで、プライバシーを強化するためのトークン仕様です。
- [\[ERC7674\] ERC20の一時承認の仕組みを理解しよう！](https://cardene.dev/articles/cd9ac988145b8dc29758.md): ERC7674は、ERC20トークンを「同一トランザクション内だけ」一時的に承認（approve）するための最小限のインターフェースを定義しています。
- [\[ERC6960\] Dual Layer Tokenの階層的な資産管理仕組みを理解しよう！](https://cardene.dev/articles/dcfcf5b0630fcc3cdcb1.md): Dual Layer Token（DLT）は、既存のトークン規格であるERC20（同じ単位がすべて同じ価値を持つトークンの規格）、ERC721（1つ1つが固有なトークン＝NFTの規格）、ERC1155（複数種類のトークンを1つのコントラクト
- [\[ERC6864\] ERC20を別実装へ安全にアップグレードする仕組みを理解しよう！](https://cardene.dev/articles/2455fadcf46f6e8ce2d7.md): ERC20は、Ethereum上で最も広く使われているトークン規格ですが、一度デプロイしたスマートコントラクトは基本的に変更できません。
- [\[ERC6823\] トークン所有情報のストレージ位置を特定する仕組みを理解しよう！](https://cardene.dev/articles/fe75b8f442db1abf8a42.md): ERC20、ERC721、ERC1155に準拠したトークンを扱う取引を、オフチェーンでより正確にシミュレーションするための方法について提案しています。
- [\[ERC20\] ERC20を1からわかりやすく解説](https://cardene.dev/articles/aeefe2d89dd5332c9f43.md): ERC20とは、「Ethereumブロックチェーンで動作する統一されたトークン規格の1つ」です。
- [\[ERC7417\] ERCトークンを相互変換する「Token Converter」の仕組みを理解しよう！](https://cardene.dev/articles/3f20df95c12b6f7bd271.md): ERC7417は、Ethereum上で広く使われるトークン標準どうしを相互運用できるようにするための仕組みを提案しています。
- [\[ERC5115\] 利回り資産の共通規格を定めるSYトークンの仕組みを理解しよう！](https://cardene.dev/articles/777a83016a6f439e7941.md): ERC5115では、スマートコントラクト内で利用できる「利回り付きトークン（yield-bearing token）」をラップ（包み込む）ためのAPIを提案しています。
- [\[ERC6734\] 複数チェーンでトークンを共通管理する仕組みを理解しよう！](https://cardene.dev/articles/9bf8d238647a4fac3d58.md): ERC6734では、複数のブロックチェーン（Layer 1、Layer 2、またはサイドチェーン）が、他のチェーン上のトークンを識別できるようにするためのJSON形式のトークンリストについて提案しています。
- [\[ERC6358\] 複数チェーンでトークンを同期する仕組みを理解しよう！](https://cardene.dev/articles/7c0db6a2ddf81027af7a.md): ERC6358は、ブロックチェーン間での資産のやり取りを安全かつ検証可能に行うための共通インターフェースを定義する提案です。
- [\[ERC7878\] トークンを遺言で相続する標準仕様の仕組みを理解しよう！](https://cardene.dev/articles/ba9c7c6e09533ed2d02d.md): ERC7878は、所有者が亡くなった後でもトークンを相続できるようにするための、スマートコントラクト向け標準インターフェースを提案しています。
- [\[ERC2019\] トークンの発行申請をオンチェーンで行う仕組みを理解しよう！](https://cardene.dev/articles/be45d41a61027c6db342.md): ERC2019は、ERC20トークンに「ファンドリクエスト（資金要求）」の機能を追加することで、トークンウォレットの所有者がスマートコントラクトを通じてトークンの発行依頼を行えるようにする拡張仕様です。
- [\[ERC918\] PoWの仕組みを利用してトークンの初期配布を行う仕組みを理解しよう！](https://cardene.dev/articles/4812d9d2fdbf574e9c46.md): ERC918は、「マイナブルトークン（Mineable Token）」の標準化に関する提案です。マイナブルトークンとは、Proof of Workアルゴリズムを使ってトークンを分配する仕組みを持つトークンのことです。
- [\[ERC2767\] ERC20トークンを使用した分散型のガバナンスの仕組みを理解しよう！](https://cardene.dev/articles/5e604fd3628f5a880b8a.md): ERC2767は、ERC20トークンを使って投票権を分配するガバナンス用スマートコントラクトのAPIを提案しています。
- [\[ERC2980\] スイスの法律に準拠したERC20トークンの仕組みを理解しよう！](https://cardene.dev/articles/8db7ad8e4e39e1a69887.md): ERC2980は、ERC20互換のトークンでありながら、スイスの主要な金融関連法に準拠するように設計されています。具体的には、以下の法律への対応が含まれます。
- [\[ERC3234\] 複数のトークンを一括で借りる仕組みを理解しよう！](https://cardene.dev/articles/3362af127e9731e86e10.md): ERC3234は、複数のトークンを一括で扱うフラッシュローン（バッチ・フラッシュローン）の実装を提案しています。
- [\[ERC4524\] ERC20を安全に送付する仕組みを理解しよう！](https://cardene.dev/articles/1cb8c029df32b9715e97.md): ERC4524は、従来のERC20トークンにEIP165を組み込む提案をしています。
- [\[ERC4546\] approveと同じ仕組みをトークンをdepositして実現する仕組みを理解しよう！](https://cardene.dev/articles/2d550e398f9399c8b9a0.md): Wrapped Deposit Contractは、ユーザーに代わって資産（Ether、ERC20トークン、ERC721トークン）を預け入れるコントラクトです。
- [\[ERC4886\] 資産保有アドレスとは別に特典などを受け取るアドレスを管理する仕組みを理解しよう！](https://cardene.dev/articles/4236923066f5b14f082b.md): ERC4886は、ユーザーが別のウォレットアドレスを代理人（Proxy）として指定できるプロトコルを提案しています。また、新しい資産の受け取り先として別のアドレス（デリバリーアドレス）も設定できます。
- [\[ERC4931\] ERC20トークンを新たな別のトークンに変換する仕組みを理解しよう！](https://cardene.dev/articles/96698ba63fb0f3e5b197.md): ERC4931は、ERC20トークンのアップグレードを行う標準的なAPIの実装を提案しています。
- [\[ERC4987\] トークンをコントラクトに預けた時にアドレスと残高を紐付ける仕組みを理解しよう！](https://cardene.dev/articles/0838f2865a097fa61d5d.md): ERC4987は、コントラクトが保有するトークン（ERC20、ERC721、ERC1155）に関する所有者情報および残高情報をインターフェースで外部に公開する提案をしています。
- [\[ERC5095\] ERC20トークンの所有権を示すPrincipalトークンの仕組みについて理解しよう！](https://cardene.dev/articles/a2d9717ebd4dbb8e6f65.md): Principalトークンは、ある将来の時点で特定のERC20トークンの所有権を表すトークンです。ERC5095は、ERC20の基本的な送受信機能に加えて、トークンの入金・出金や残高確認の機能を持ちます。
- [\[ERC5883\] アクセスできなくなったアドレスが保有するトークンを移動させる仕組みを理解しよう！](https://cardene.dev/articles/a97188b496ac6f349a2d.md): ERC5883は、ソーシャルリカバリーの仕組みを標準化する提案をしています。アクセスできなくなったアカウントから新しいアカウントへトークンを移す方法を決める提案です。この仕組みを実行するには1つ以上のアドレスによる承認が必要になります。
- [\[ERC7837\] DIFFトークンの仕組みを理解しよう！ ](https://cardene.dev/articles/74d156eddf17a8f14a13.md): ERC7837では、新しいタイプのFTであるDiffusive Tokens（DIFF）を提案しています。従来のERC20トークンと異なり、DIFFトークンを送信しても送付元アドレスの残高は減りません。
- [\[ERC7787\] 貢献度に応じたガバナンストークンの仕組み理解しよう！](https://cardene.dev/articles/de6e0bd1510a1e05f22b.md): ERC7787は、ガバナンス権を譲渡不可能なトークン（ソウルバウンドトークン）として付与し、時間の経過とともにその権限が弱まっていく仕組みを提案しています。
- [\[ERC7818\] ERC20トークンに有効期限を持たせる仕組みを理解しよう！](https://cardene.dev/articles/f05cb5a25b9c1da5c719.md): ERC7818では、ERC20標準と互換性を保ちつつ、トークンの有効期限をコントラクトレベルで管理・強制できる機能を追加する提案をしています。
- [\[ERC7758\] 安全にERC20トークンをメタトランザクションで送付する仕組みを理解しよう！](https://cardene.dev/articles/9ead3db11831a24e37e8.md): ERC7758では、EIP712を活用してERC20トークンのメタトランザクションを可能にする仕組みを提案しています。この仕組みを活用することで以下を実現できます。
- [\[ERC7573\] 2つのブロックチェーン間で安全にトークンを送付する仕組みを理解しよう！](https://cardene.dev/articles/463649b8dc528a56db92.md): この規格では、2つのブロックチェーン間で安全なdelivery-versus-payment（DVP）を実行するためトランザクションスキームのインターフェースを提案をしています。
- [\[ERC677\] ERC223をベースにトークンを受け取ったことを通知する幻の規格を理解しよう！](https://cardene.dev/articles/a33541bc7ae02bdc4b2a.md): この規格では、ERC20トークンにtransferAndCallという関数を追加する提案をしています。この関数は、ERC20トークンをコントラクトにtransferし、追加のデータを渡すことができます。
- [\[ERC7621\] 資産に裏付けされたオンチェーンのトークン化ファンドを作成する仕組みを理解しよう！](https://cardene.dev/articles/b92d98a59d19ee906210.md): この規格では、Basket Token Standard（BTS）というNFTを使用して、複数のERC20トークンを含んだファンドの実装を提案しています。
- [\[ERC7641\] ERC20トークンに収益分配メカニズムを追加する仕組みを理解しよう！](https://cardene.dev/articles/0c8031753bc122a15bd4.md): この規格では、ERC20トークンを拡張して、収益分配（Intrinsic RevShare）メカニズムを導入する提案をしています。
- [\[ERC7720\] ERC20トークンを設定したタイムスタンプ以降に引き出せる仕組みを理解しよう！](https://cardene.dev/articles/a888f4edb650c6083ed2.md): この規格では、特定のアドレスが引き出せるようにERC20トークンを預けて、指定した将来のタイムスタンプ以降にのみトークンを引き出すことができます。預け入れる時に以下の情報が保存されます。
- [\[ERC7410\] spenderが自らのトークンallowance量を変更する仕組みを理解しよう！](https://cardene.dev/articles/977286526e3b22f15f7a.md): ERC20というのは、イーサリアム上で標準的なトークンを作成するための規格です。この規格は、トークンの送信や残高の確認などの基本的な機能を定義しています。また、「allowance」という機能があります。
- [\[ERC7272\] 新しいアクセス制御の方法であるEthereum Access Token（EAT）の仕組みを理解しよう！](https://cardene.dev/articles/1b35d85341d50ea4204e.md): Ethereum Access Token（EAT）についての提案です。
- [\[ERC7254\] ERC20トークン保有者への新しい収益分配方法の仕組みを理解しよう！](https://cardene.dev/articles/af7cd7c9d53bb0584eb8.md): このプロジェクトは、ERC20トークンの所有者にユニークな機能を提供し、トークンの価値を高めることを目指しています。
- [\[ERC6604\] Abstract Tokenの仕組みを理解しよう！](https://cardene.dev/articles/22026f67da326e76d5d0.md): この提案では、ブロックチェーン技術の中で抽象トークン（Abstract Token）に関する概念を理解するためのものです。
- [\[ERC7528\] ETHをERC20トークンとして扱う標準の仕組みを理解しよう！](https://cardene.dev/articles/1e836143549e5e4aa5cb.md): 提案されている規格は、EthereumなどのEVM (Ethereum Virtual Machine) チェーン上で、ETH（Ethereumのネイティブ通貨）をERC20トークンと同じように扱う時の標準的な方法に関するものです。
- [\[ERC7144\] ERC20トークンのapproveとtransferの安全性チェックの仕組みを理解しよう！](https://cardene.dev/articles/989edfb117a3b68f3850.md): この新しい標準は、ERC20をもっと安全にするためのアップグレードした規格です。ERC20は、ブロックチェーン上でトークンのやり取りをする基本的な方法です。
- [\[ERC7425\] ブロックチェーン上で管理されるトークン化されたリザーブの仕組みを理解しよう！](https://cardene.dev/articles/ccc4c87f036616e43500.md): この提案は、トークン化されたリザーブ（資金のプール）メカニズムに関するものです。このリザーブは、所有者のコントラクト上のアクションを監視できるように設計されています。
- [\[ERC2612\] ERC20のapproveとtransferFromを1つのトランザクションで実行できる仕組みを理解しよう！](https://cardene.dev/articles/6809173b2ac428b1ccd0.md): このERCは、ERC20トークンを拡張して、承認（approve）とtransferFromという2つの関数に関連する提案をしています。
- [\[ERC223\] ETHと同様の振る舞いをするERC20トークンの仕組みを理解しよう！](https://cardene.dev/articles/0e0ef7a1c17989689796.md): この規格では、ERC20トークンにtokenReceivedという関数を追加して、トークンを受け取ったときにトークンを受け取ったというこを通知するcallback機能をサポートするインターフェースとロジックについて提案しています。
- [\[ERC7528\] ETHの送付をERC20トークンの送付と同等に扱う仕組みを理解しよう！](https://cardene.dev/articles/cb02ff8a445fea0b8331.md): この規格では、アドレスがERC20トークンと同じようにETHを使用する時のルールを提案しています。アドレスフィールドがETHまたはERC20トークンを示す場合や、ERC4626ボールトのアセットフィールドなど、特定の場面で適用されます。
- [\[ERC777\] トークンコントラクトの標準インターフェースの仕組みを理解しよう！](https://cardene.dev/articles/c0fcb8f3122f66985226.md): このEIPは、トークンのコントラクトに関する標準的なインターフェースを提案しています。これにより、既存のERC20規格との互換性を保ちながら、トークンを取り扱う時により多くの機能と柔軟性を提供することができます。
- [\[ERC1363\] ERC20のtransferやapprove後に追加で関数を実行する仕組みを理解しよう！](https://cardene.dev/articles/18e3a3e8104951b2d057.md): 現在、ERC20トークンのtransfer（送付）やapprove（承認）後にコードを実行する方法がないため、もし他の関数を実行したい場合は別のトランザクションを送信して2回のGASを支払う必要があります。
- [\[Bunzz Decipher\] BNBトークンのコントラクトを見てみよう！](https://cardene.dev/articles/e4e90738a97d9f.md): BNBコントラクトは、特定の仮想通貨トークンであるBNBを取り扱うためにEthereumブロックチェーンプラットフォーム上に構築された堅牢で効率的なコントラクトです。

## Blockchain / Identity

- [\[ERC8092\] 複数のアカウントの関係を確認できるようにする仕組み](https://cardene.dev/articles/7976def5a388ac0f1574.md): 主アカウントと、ゲーム専用のアカウントを使い分ける場面を考えます。ゲーム側が2つのアドレスを見ても、同じ利用者が管理しているとは判断できません。
- [\[ERC8326\] 契約書や証明書のファイルを決まった手順でハッシュ化してオンチェーンに記録する仕組みを理解しよう！](https://cardene.dev/articles/7d910bc2a6c6441290e0.md): 契約に関するPDF、JSON形式の証明書、補足資料を複数人が持つ場合を考えます。ファイルが同じに見えても、名前の大文字小文字、JSONのキー順、登録した順番が異なると、単純なハッシュでは別の値になります。
- [\[EIP8016\] SSZ CompatibleUnionで共通フィールドのMerkle証明を安定させる仕組みを理解しよう！](https://cardene.dev/articles/698ccc9793ae9f7d4437.md): EIP8016は、SSZにCompatibleUnion({selector: type})という型を追加します。この型は、selectorで選ばれた1つの型オプションを中に持ちます。
- [\[ERC8152\] CALMでプロキシ向けロジックを同一アドレスで再利用する仕組みを理解しよう！](https://cardene.dev/articles/72ec7d77018c7d3eeea3.md): ERC8152は、CALM(Content-Addressable Logic Modules) という形式で、プロキシから delegatecall されるロジックを標準化する提案です。
- [\[ERC7969\] メールの送信元をオンチェーンで検証するDKIMレジストリの仕組みを理解しよう！](https://cardene.dev/articles/16198d8fe6204b8f1adc.md): ERC7969は、DomainKeys Identified Mail（DKIM）の公開鍵ハッシュをEthereumブロックチェーン上に登録・検証するための標準インターフェースです。
- [\[ERC7965\] 暗号学的証明でクロスチェーンメッセージを検証するProof-based Broadcastの仕組みを理解しよう！](https://cardene.dev/articles/949edd85073fba5715c4.md): ERC7965とは、ERC7786のクロスチェーンメッセージングゲートウェイに暗号学的証明（Cryptographic Proofs）の属性を追加する提案です。
- [\[ERC7585\] Merkle Treeを活用して公開データを安全に証明するMixHashの仕組みを理解しよう！](https://cardene.dev/articles/9fc4f9ef4642772a1c1f.md): ここでは、Merkle Tree（多数のデータを階層的にまとめて改ざん検知を可能にする仕組み）を使い、特定のデータを本当に保持しているかどうかを確認する「ストレージ証明」を成立させるための仕組みを説明します。ポイントは二つあります。
- [\[ERC7529\] DNSとブロックチェーンを結びつけるスマートコントラクト認証の仕組みを理解しよう！](https://cardene.dev/articles/86154aeebd970153a692.md): ERC7529は、DNS over HTTPS（DoH）を使って、DNSに登録されたTXTレコードをウェブアプリケーションから直接、安全に取得し、スマートコントラクトと一般的なDNSドメインを結びつけて確認できる仕組みをまとめたものです。
- [\[ERC7555\] 複数アプリ間で同じアカウントを扱える仕組みを理解しよう！](https://cardene.dev/articles/63890392322eb9ae8cd0.md): ERC7555は、アプリケーションがユーザーのアカウントを見つけるための共通インターフェースと、その振る舞いを標準化する提案をしています。
- [\[ERC7506\] オンチェーンで信頼情報を扱う仕組みを理解しよう！](https://cardene.dev/articles/d491a2f54302c32eddc6.md): ERC Trusted Hint Registry は、「ヒント」と呼ばれるオンチェーンメタデータを標準的な形で管理するための仕組みを提案しています。
- [\[ERC6735\] 複数のEVMチェーンで同じアドレスを扱う仕組みを理解しよう！](https://cardene.dev/articles/aa8615a63e62fcc2663c.md): ERC6735では、Ethereum Virtual Machine（EVM）を基盤とするアドレスのエイリアス化（Aliasing）を実現するために必要な最小限のビジネス的および技術的前提条件、ならびに機能要件と非機能要件を定義しています。
- [\[ERC7930\] 複数チェーンのアドレスを1つの形式で扱う仕組みを理解しよう！](https://cardene.dev/articles/e280966bf2619d25d4c8.md): Interoperable Addresses（インターオペラブル・アドレス）は、「ある特定のチェーン固有のアドレス」をバイナリ形式で表現するための提案です。
- [\[ERC7734\] シンプルなDID標準によるID検証の仕組みを理解しよう！](https://cardene.dev/articles/314aed73487fa5fcf8c5.md): ERC7734は、ブロックチェーン上での分散型アイデンティティ（Decentralized Identity, DID）検証のための新しい標準を導入する提案です。
- [\[ENSIP12\] ENSでアバターを一元管理する仕組みを理解しよう！](https://cardene.dev/articles/154b0e46b5f4f64094bb.md): ENSIP12は、Ethereum Name Service（ENS）におけるアバター画像の扱い方を標準化する提案です。
- [\[ERC7785\] ENSを活用したチェーンID管理の仕組みを理解しよう！](https://cardene.dev/articles/686b9bf3163168481772.md): ERC7785は、ブロックチェーンのチェーン識別子（chain identifier）を「チェーン名などの情報を元に計算したハッシュ値（digest）」として導き出す仕組みを提案しています。
- [\[ENSIP19\] ENSのマルチチェーン対応の仕組みを理解しよう！](https://cardene.dev/articles/feda013862efe0833903.md): ENSIP19は、すべてのコインタイプに対して「リバース解決」と「プライマリ名解決」を標準化し、さらにその解決プロセスをマルチチェーン化したEthereumエコシステム全体で統一的に動作させる仕組みを定めたものです。
- [\[ENSIP22\] ENSで複数レコードをまとめて解決する仕組みを理解しよう！](https://cardene.dev/articles/16813afa4b69fb6979c8.md): ENSIP22は、ENS（Ethereum Name Service）に関連するコントラクト機能をERC7996として標準化する提案です。
- [\[ENSIP5\] ENSにプロフィール情報を登録できる仕組みを理解しよう！](https://cardene.dev/articles/5f38e117246ef4bb3711.md): ENSIP5は、Ethereum Name Service（ENS）において「任意のキーと値の組み合わせ（key-value）」を保存・参照できるリゾルバの仕組みを定義しています。
- [\[ENSIP10\] ENSにおける自動サブドメイン解決の仕組みを理解しよう！](https://cardene.dev/articles/793fafc39987090fe7b4.md): Ethereum Name Service（ENS）は、人が覚えやすい名前をブロックチェーン上のアドレスなどに対応づける仕組みです。通常は以下の手順で解決（リゾルブ）が行われます。
- [\[ENSIP3\] Ethereumアドレスに名前を紐付ける仕組みを理解しよう！](https://cardene.dev/articles/845794b9ea21c5eaa4c9.md): ENSIP3は、Ethereum Name Service（ENS）において「リバース解決（Reverse Resolution）」を行うための仕様を定めています。
- [\[ENSIP11\] ENSが導入するEVMチェーン識別番号の仕組みを理解しよう！](https://cardene.dev/articles/6eb35a26617eb07d31a1.md): ENSIP11は、Ethereum Name Service（ENS）の仕様 ENSIP9（マルチチェーンアドレス解決） を拡張し、EVM互換チェーン専用のコインタイプ範囲を確保し、さらにEVMのChain IDをコインタイプに変換する方法
- [\[ENSIP1\] ENSの登録と更新の仕組みを理解しよう！](https://cardene.dev/articles/9bfb5c7b037fc33dc2ff.md): Ethereum Name Service（ENS）は、人間が理解しやすい短い名前を、コントラクトやデータといったリソースに結びつけるための仕組みを定義した提案です。
- [\[ENSIP9\] ENSにおける複数チェーン対応の仕組みを理解しよう！](https://cardene.dev/articles/fd2ab09579d9db7bdb81.md): ENSIP9は、ENS（Ethereum Name Service）のリゾルバにおける addr フィールドを拡張し、新しいオーバーロード（同じ名前の関数に異なる使い方を追加する仕組み）を導入するものです。
- [\[ERC7930\] クロスチェーン取引を安全にするためにチェーンIDをアドレスを含む仕組みを理解しよう！](https://cardene.dev/articles/a0475affba1edb342a9f.md): Interoperable Addressesは、特定のブロックチェーンに固有のアドレスを表現するためのバイナリ形式です。これにより、人間が読みやすい表示用の仕様「Interoperable Names」と組み合わせて利用できます。
- [\[CAIP350\] マルチチェーン対応アドレス変換規格の仕組みを理解しよう！](https://cardene.dev/articles/514b7340056bbb9ac7b6.md): CAIP350は、各チェーンの名前空間（namespace）ごとに異なるアドレス形式やネットワーク識別方法を統一し、ERC7930で定義された「Interoperable Address（相互運用可能アドレス）」形式に変換する方法を定めてい
- [\[ERC1056\] 分散型IDレジストリの仕組みを理解しよう！](https://cardene.dev/articles/8c69b3f439b70cb3cb4d.md): ERC1056は、Ethereumブロックチェーン上で軽量なID（アイデンティティ）を管理するためのレジストリの標準仕様を定義したものです。
- [\[ERC780\] オンチェーンでの証明情報管理の仕組みを理解しよう！](https://cardene.dev/articles/8297dcb1c730bf77bc44.md): Ethereum Claims Registry（ECR）は、Ethereum上で「誰が、誰に対して、どのような主張（クレーム）をしているか」を一元的に記録・参照できる仕組みを提供する提案です。
- [\[ERC735\] 証明情報をコントラクトで管理する仕組みを理解しよう！](https://cardene.dev/articles/a478ddb96b07af139ca7.md): ERC735は、「クレーム（Claim）」と呼ばれる情報をスマートコントラクト上で取り扱うための、共通インターフェースの標準仕様を定めたものです。
- [\[ERC1844\] ENSにコントラクトのインターフェースを紐づける仕組みを理解しよう！](https://cardene.dev/articles/d76cc5139c46e9eb8e71.md): ERC1844は、Ethereum Name Service（ENS）の名前やアドレスに対して、関連するコントラクトのインターフェース情報を公開し、それをアプリケーションが発見・利用できるようにする仕組みを定義しています。
- [\[EIP6800\] Verkleツリーで証明サイズを削減する仕組みを理解しよう！](https://cardene.dev/articles/1d12fe71f82f7d8dbd67.md): EIP6800は、Ethereumのステートを管理する既存の「hexary Patricia tree」に加えて、新たに「Verkle tree」を導入する提案です。
- [\[ERC2304\] ENSで複数チェーンに対応した仕組みを理解しよう！](https://cardene.dev/articles/007b901a2dc7f7a04112.md): ERC2304は、ENS（Ethereum Name Service）のリゾルバにおける addr フィールドに対して、異なるブロックチェーンのアドレスも扱えるようにするための新しい引数形式を追加する提案です。
- [\[ERC2390\] ENSに地理情報を紐付けられる仕組みを理解しよう！](https://cardene.dev/articles/ac9a65d2cfe2486f5ca2.md): GeoENSは、ENS（Ethereum Name Service）に地理的な「スプリットホライズン（Split Horizon）」の概念を導入することで、地理情報に基づいた名前解決を可能にする提案です。
- [\[ERC1062\] IPFSのハッシュをENSに登録する仕組みを理解しよう！](https://cardene.dev/articles/84dca7cc6174508056fe.md): ERC1062は、IPFS（InterPlanetary File System）に保存されたリソースと、Ethereum上のネーミングサービスであるENS（Ethereum Naming Service）との間のマッピング手法を提案してい
- [\[ERC2470\] 複数ブロックチェーン上に同じアドレスのコントラクトをデプロイできるFactoryコントラクトの仕組みを理解しよう！](https://cardene.dev/articles/39daf0e0565b945157ed.md): DApps（分散型アプリケーション）の中には、どのブロックチェーン上でも同一のアドレスで動作するコントラクト（シングルトン）を必要とするケースがあります。
- [\[ERC1014\] コントラクトのデプロイ先アドレスを事前に予測する仕組みを理解しよう！](https://cardene.dev/articles/e5b4ebf180ee62af8865.md): CREATE2 は、EVM（Ethereum Virtual Machine）における新しいオペコードで、0xf5 番に割り当てられています。スタック引数として以下の4つを取ります。
- [\[ERC2520\] ENSを異なる分散型ホスティングシステムに同時対応させる仕組みを理解しよう！](https://cardene.dev/articles/ab20e61a5404e95cd18b.md): ERC2520は、1つのENS（Ethereum Name Service）ドメインに対して、複数のcontenthashレコードを登録できるようにする提案です。
- [\[ERC1577\] ENSドメインでIPFSやSwarmのコンテンツにアクセスする仕組みを理解しよう！](https://cardene.dev/articles/4b0a25d33edd2f894259.md): ERC1577では、ENS（Ethereum Name Service）のリゾルバに新しいフィールド contenthash を導入することを提案しています。
- [\[ERC2525\] ENSを使用してDappにログインする仕組みを理解しよう！](https://cardene.dev/articles/e4c56e52c583115f383a.md): ERC2525は、Ethereumブロックチェーンへのユニバーサルなログイン方法を改善する仕組みを提案しています。
- [\[ERC2544\] ENSでワイルドカードサブドメインの解決を可能にする仕組みを理解しよう！](https://cardene.dev/articles/5ab88c59ee4c5624f26c.md): 現在のEthereum Name Service（ENS）は、名前を解決する際に2段階の処理を行います。まず、ENSクライアントがドメイン名に対してnamehashアルゴリズムを適用し、対応するノード（node）を求めます。
- [\[ERC4974\] 評価システムをコントラクトで管理する仕組みを理解しよう！](https://cardene.dev/articles/976cdea1d53fef8930c6.md): ERC4974は、Ethereumブロックチェーン上で数値による評価（Rating）を割り当て・管理する標準インターフェースを提案しています。
- [\[ERC5539\] データや証明が有効か無効かを管理する仕組みを理解しよう！](https://cardene.dev/articles/b2342a60c4c2d820eef5.md): ERC5539は、「このデータや証明はもう無効です」という情報を、ブロックチェーン上で安全かつ信頼できる形で記録・確認できるようにするインターフェースの提案をしています。
- [\[ERC7812\] オンチェーンで証明可能なデータを管理・証明する仕組みを理解しよう！](https://cardene.dev/articles/f04a1e007ca3e4e14433.md): ERC7812は、証明可能な情報をオンチェーンで保存し、後からその正当性を検証できるレジストリシステムを提案しています。
- [\[ERC6821\] Web3URLからENSの紐付けをサポートする仕組みを理解しよう！](https://cardene.dev/articles/9ed0e6aac8a076567b6f.md): この規格では、Ethereum Name Service（ENS）から、ERC4804で定義されているアドレスへのマッピングを定義しています。
- [\[ERC3770\] どのチェーンか判別しやすいようにチェーンの短縮名をアドレスにつける仕組みを理解しよう！](https://cardene.dev/articles/de8ce92b89ee722b37aa.md): この規格では、ウォレットやDappsがチェーン固有のアドレスを表示するためのアドレス標準を提案しています。各チェーン固有のプレフィックスをアドレスの前につけることで、異なるブロックチェーン上のアドレスを簡単に識別できるようにしています。
- [\[ERC7673\] アドレスを絵文字に置き換えて識別子やすくする仕組みを理解しよう！](https://cardene.dev/articles/ef3add52e6a533b9fe3f.md): ユーザーのアカウントアドレスを扱う時に16進数やBase64の代わりに、256種類の絵文字を用いるbase256emojiの導入を提案しています。
- [\[EIP6913\] データとアドレスを保持しつつコントラクトをアップグレードするSETCODE命令の仕組みを理解しよう！](https://cardene.dev/articles/2e9b4354919f0c226399.md): この規格では、SETCODE (0xfc) という実行中のアカウントのコードをメモリから置き換える命令の導入を提案しています。
- [\[EIP5003\] AUTHUSURPオペコードを追加しEOAアドレスの秘密鍵を作り替える仕組みを理解しよう！](https://cardene.dev/articles/e65613d99a2a243c878b.md): EIP (Ethereum Improvement Proposal)とは、イーサリアムネットワークのプロトコルに変更や追加を提案する公式文書のことです。
- [\[EIP3651\] COINBASEアドレスアクセスの最適化の提案を理解しよう！](https://cardene.dev/articles/189a74bb08bf9bed7466.md): ブロックチェーンやスマートコントラクトに関連するトランザクションの実行コンテキストを指しています。
- [\[EIP3607\] Etherumアドレスの衝突を防ぐ提案を理解しよう！](https://cardene.dev/articles/b7a12a2848d2b2022761.md): Ethereumのアドレスは160ビットの長さしかなく、これはコントラクトのアカウント（スマートコントラクトのアドレス）とEOA（外部所有）アカウント（ユーザーが直接コントロールするアカウント、略してEOA）の間で衝突（同じアドレスを持つ可
- [\[EIP684\] 同じアドレスでのコントラクトの作成を無効にする提案を理解しよう！](https://cardene.dev/articles/8678b581b7d4444eda7a.md): このEIPはイーサリアムのブロックチェーン上で、特定のアドレスに既にスマートコントラクトのコードが存在する場合に、そのアドレスで新たなコントラクトを「作成」しようとする行為を禁止するものです。
- [\[ERC4361\] Ethereumアドレスを使用してオフチェーンサービスにログインする仕組みを理解しよう！](https://cardene.dev/articles/b4d04cc84b4f1f8a3be1.md): 「Sign-In with Ethereum」とは、Ethereumアカウントを使ってオフチェーンサービス（インターネット上のサービスなど）にログインするための方法です。
- [\[ERC1185\] DNS情報をENSに保存する仕組みを理解しよう！](https://cardene.dev/articles/4a625ced12f68f8606ef.md): このEIPはイーサリアムの改善提案の1つで、ENSというシステムを使って、インターネット上のドメイン名に関連する情報（DNSレコード）をイーサリアムブロックチェーン上に保存し、検索できるようにするためのルールを定めています。
- [\[ERC1191\] チェーンIDをEthereumのチェックサムに活用する仕組みを理解しよう！](https://cardene.dev/articles/7db8090642e0fc3c5649.md): この提案（EIP）は、イーサリアムで資金を安全に送るためのルールを改善するためのものです。
- [\[ERC7201\] 名前空間を用いた効率的なストレージ管理の仕組みを理解しよう！](https://cardene.dev/articles/64ef137f8bd096681713.md): 「@custom:storage-location」というアノテーションは、SolidityやVyperで書かれたスマートコントラクトの中でデータがどこに保存されるかを明確に記録するためのものです。
- [\[ERC181\] ENSのリバース解決の仕組みを理解しよう！](https://cardene.dev/articles/24ed2fd419da26f67613.md): このEIPは、イーサリアムブロックチェーンのアドレスに対して、ENSを用いてより親しみやすい名前を割り当てるシステムについて説明しています。
- [\[ERC4834\] Ethereumアドレスを簡単な名前に変換するENSに似た仕組みを理解しよう！](https://cardene.dev/articles/0702d22282a55350124f.md): コントラクトを人間にとって親しみやすい名前で特定できるようにするための規格です。これはERC137、つまり「ENS（Ethereum Name Service）」と似た目的を持っています。
- [\[ERC162\] ENSのコントラクトの仕組みを理解しよう！](https://cardene.dev/articles/dea5106984cbde3f8ab6.md): この文章は、イーサリアム・ネーム・サービス（ENS）のためのコントラクトに関するものです。ENSは、イーサリアムブロックチェーン上でドメイン名を管理するシステムで、2017年5月4日にメインネットワークに導入されました。
- [\[EIP55\] Ethereumアドレスのチェックサムの仕組みを理解しよう！](https://cardene.dev/articles/985f03760df12929b5f9.md): この要求に基づいて、アドレスを16進数文字列に変換し、特定の条件に従って大文字または小文字で出力するプロセスを説明します。また、指定された条件に従った例も示します。
- [\[ERC6357\] EOAアドレスが複数コントラクトを1つのトランザクションで実行できる仕組みを理解しよう！](https://cardene.dev/articles/37118c0c4d36c2eaf2ca.md): このEIPは、1つの機能、つまり「multicall」を含む標準化されたインターフェースです。これにより、外部所有者アカウント（EOA）は1つのトランザクションでスマートコントラクトの複数の関数を呼び出すことができます。
- [\[ERC6315\] 信頼不要のメタトランザクションの仕組みを理解しよう！](https://cardene.dev/articles/210da4f4404cca214caa.md): 「ERC2771」は、メタトランザクションにおける共通の標準で、1つ以上の信頼できるフォワーダー（転送者）を使用します。
- [\[ERC137\] アドレスに任意の名前を紐付けるENSの仕組みを理解しよう！](https://cardene.dev/articles/17e6e1a452006f08a197.md): このERC137では、Ethereum Name Service（ENS）の詳細を説明していきます。

## Blockchain / Transaction

- [\[EIP7966\] トランザクション送信とレシート取得を1回で完結させるeth_sendRawTransactionSyncの仕組みを理解しよう！](https://cardene.dev/articles/4e712c5f95092fbecb6d.md): EIP7966とは、eth_sendRawTransactionSyncという新しいJSON-RPCメソッドを定義する提案です。
- [\[ERC7950\] 複数チェーン上のトランザクションを一意に特定する文字列形式の仕組みを理解しよう！](https://cardene.dev/articles/44c124dd548c2eef4ab7.md): ERC7950では、「チェーンID」と「トランザクションハッシュ（取引ハッシュ）」を1つの文字列としてまとめて表現する方法を提案しています。
- [\[ERC2400\] 標準化されたトランザクションハッシュのURI形式の仕組みを理解しよう！](https://cardene.dev/articles/722069dab8b71348130c.md): 通常、トランザクションハッシュ（transaction hash）は、それ自体だけでは意味を持ちません。なぜなら、単なるハッシュ値であり、どのチェーン上のどの処理を指しているのかといった情報が欠落しているためです。
- [\[ERC3005\] 複数のメタトランザクション処理を一括で送付する仕組みを理解しよう！](https://cardene.dev/articles/79b6849a060aa6ad6d7f.md): ERC3005では、ERC20などのFungible Token（代替可能トークン）規格を拡張するための新しい関数 processMetaBatch を定義しています。
- [\[EIP7886\] ブロック内のトランザクションを実行せずに検証する仕組みを理解しよう！](https://cardene.dev/articles/bcb7f97953554f1c3ceb.md): EIP7886は、ブロックの検証をより効率的にする仕組みを提案しています。具体的には、ブロック内のトランザクションを実行しなくても、そのブロックが正しいかどうかを簡単なチェックだけで確認できるようにします。
- [\[ERC7796\] トランザクション実行の事前条件を設定できる仕組みを理解しよう！](https://cardene.dev/articles/3b06e3c3acf84cf9c9b2.md): ERC7796は、新しいJSON-RPC APIメソッドである eth_sendRawTransactionConditional を提案しています。
- [\[ERC3009\] より安全にメタトランザクションを実行する仕組みを理解しよう！](https://cardene.dev/articles/5aaed2168d4e16e4880d.md): この規格では、署名されたapproveを使用してトークンをtransfer可能にするインターフェースを提案しています。
- [\[EIP2718\] Ethereumのトランザクションを拡張するための仕組みを理解しよう！](https://cardene.dev/articles/1d273e5564158eebe463.md): EIP2718は、イーサリアムのトランザクションとレシートのフォーマットを拡張するための提案です。この提案の目的は、将来の機能拡張に備えて、トランザクションとレシートのフォーマットを柔軟にすることです。
- [\[EIP2930\] アクセスリストを含む新しいトランザクションタイプの導入提案を理解しよう！](https://cardene.dev/articles/632180dfb44d66344e70.md): EIP2718はイーサリアムのトランザクションに関する改善提案の一つで、新しいトランザクションタイプを導入しています。この新しいタイプの主な特徴は「アクセスリスト」の追加です。
- [\[EIP658\] トランザクションの成功・失敗をより簡単に確認できる提案を理解しよう！](https://cardene.dev/articles/e6833f2dc27400b165c5.md): このEIP（Ethereum Improvement Proposal、イーサリアム改善提案）では、トランザクションの結果を記録するレシートの一部を変更する提案がされています。
- [\[EIP4444\] 1年以上前のトランザクションデータを削除する仕組みを理解しよう！](https://cardene.dev/articles/4eced22bd5fc3b6c37d8.md): クライアントは、P2P（ピアツーピア）レイヤーにおいて、1年以上前の履歴であるヘッダー、ボディ、レシートの提供を停止できます。クライアントは、この履歴データをローカルで削除することができるようになります。

## Blockchain / Cross-chain

- [\[ERC8121\] 保存した情報から別チェーンの関数を呼び出す仕組み](https://cardene.dev/articles/281a6a09302527b540df.md): アプリがあるチェーンのmetadataを読んだ時、必要な資格情報が別のチェーンに保存されていることがあります。関数名だけを保存しても、引数の型、渡す値、戻り値の読み方、呼び出すチェーン、コントラクトは分かりません。
- [\[EIP8163\] Ethereum L1では使わない拡張用オペコードを予約する仕組みを理解しよう！](https://cardene.dev/articles/55dee734e8417e03fa3d.md): EIP8163は、0xaeという1バイトのオペコードをEXTENSIONとして予約する提案です。Ethereum L1では、このEXTENSIONを有効な命令にしません。
- [\[ERC8002\] Bitcoinの取引をEthereumで検証するSPVゲートウェイ提案を理解しよう](https://cardene.dev/articles/fda1814f9999129ed25e.md): ERC8002は、Bitcoin上の取引をEthereumで検証するためのISPVGatewayインターフェースを定めた提案です。ドラフトのためデプロイ先アドレスはプレースホルダのままです。
- [\[EIP8135\] Blob容量をさらに拡張するBPO2アップグレードの仕組みを理解しよう！](https://cardene.dev/articles/38906dd2d2ace9135be6.md): EIP8135は、Ethereumネットワークで2回目に実施されるBlob Parameter Only（BPO）アップグレードであるBPO2の公式記録です。
- [\[EIP8134\] Blobパラメータだけを変える軽量アップグレードBPO1の仕組みを理解しよう！](https://cardene.dev/articles/e234a68c68fee22c1e52.md): EIP-8134は、Ethereumネットワークで初めて実施されたBlob Parameter Only（BPO）アップグレードであるBPO1の公式記録です。
- [\[ERC7985\] クロスチェーンメッセージのキャンセル・タイムアウト・リトライを制御するGateway Attributesの仕組みを理解しよう！](https://cardene.dev/articles/c792bfc1bd250a220906.md): 今回は「ERC7985によるクロスチェーンメッセージングのメッセージ制御属性」についてまとめてきました！いかがだったでしょうか？
- [\[ERC7700\] データをL2やデータベーに安全に保存する仕組みを理解しよう！](https://cardene.dev/articles/bf920d3a26dffbaf1f5d.md): ERC7700は、スマートコントラクトが「データの保存先」を外部システムに振り分けられるようにするための標準です。
- [ブロックチェーンBridgeについて考え直してみる](https://cardene.dev/articles/blockchain-bridge.md): ブロックチェーンのBridgeとは、異なるブロックチェーン同士の間で資産（トークン）やデータを移動・共有できるようにする仕組みのことです。
- [\[ERC7786\] クロスチェーン通信を標準化する仕組みを理解しよう！](https://cardene.dev/articles/485e08da098ad3a6dfba.md): ERC7786では、スマートコントラクトがクロスチェーン・メッセージング・プロトコルを通じて任意のデータを送信するための共通インターフェースと、そのためのワークフローを定義しています。
- [\[ERC7683\] クロスチェーンインテントの標準化仕組みを理解しよう！](https://cardene.dev/articles/744da8d0f26265045953.md): ERC7683は、クロスチェーン（複数のブロックチェーン間）でのトークン送付を行うシステム向けに、標準化されたAPIを提供する仕組みです。
- [\[CAIP10\] 異なるブロックチェーンのアカウントを統一管理する仕組みを理解しよう！](https://cardene.dev/articles/c483d9a87a43c94a3db5.md): CAIP10は、CAIP2で定義されたブロックチェーンIDを基に、あらゆるブロックチェーン上のアカウントを一意に識別する方法を定める提案です。
- [\[CAIP2\] 複数のブロックチェーンを識別する仕組みを理解しよう！](https://cardene.dev/articles/ee2925039fa62b982101.md): CAIP2は、特定のブロックチェーンを人間にも開発者にもわかりやすく、さらにトランザクションで扱いやすい形式で識別するためのルールを提案しています。
- [\[ERC7794\] 複数チェーン上の助成金の管理・追跡を行う仕組みを理解しよう！](https://cardene.dev/articles/ef85b694e667b914e629.md): ERC7794は、複数のブロックチェーンにまたがる助成金（グラント）を一元的に管理するGrant Registryコントラクトの仕組みを提案しています。
- [\[ERC7683\] クロスチェーンインテントのインターフェースを理解しよう！](https://cardene.dev/articles/1a364823ddea1d9fd890.md): この規格では、クロスチェーン取引実行のための標準APIの実装を提案しています。この標準は、汎用的なCrossChainOrder構造体とISettlementContractインターフェイスが提案されています。
- [\[ERC6170\] 異なるブロックチェーン間でのメッセージ送受信インターフェースの仕組みを理解しよう！](https://cardene.dev/articles/30dcff76ed2b121d60b8.md): このEIPは、異なるブロックチェーン間でのメッセージ送受信のための「クロスチェーン任意メッセージブリッジ（AMB）」という共通インターフェースを導入することを目的としています。

## Blockchain / Governance

- [\[ERC2018\] オフチェーン審査を実現するClearableTokenの仕組みを理解しよう！](https://cardene.dev/articles/ecf7085f387da99d125d.md): 「クリアリング（Clearing）」とは、金融・銀行業務において、取引の約束がなされてから実際に資金が決済されるまでの一連の手続きを指します。
- [\[ERC5805\] 投票の委任と履歴管理の仕組みを理解しよう！](https://cardene.dev/articles/8f502d429fe943602dbd.md): ERC5805は、DAO（分散型自律組織）の投票トークンに必須となる「委任（delegation：自分の投票権を別のアドレスに預けること）」と「チェックポイント（checkpoint：過去の投票権の状態を記録し後から参照できる仕組み）」のイ
- [\[ERC3000\] オフチェーンで承認された提案をオンチェーンで実行・異議申し立てできる仕組みを理解しよう！](https://cardene.dev/articles/d954dc9a9bf0627bad26.md): ERC3000は、オフチェーンで承認された実行内容をオンチェーンでスケジューリング・実行・チャレンジできる仕組みを提供しています。
- [\[ERC7750\] コントラクト上で企業の設立や様々な契約の管理を行う仕組みを理解しよう！](https://cardene.dev/articles/68063da45d01a9c2c544.md): ERC7750は、Ethereumブロックチェーン上で分散型雇用システム（DES: Decentralized Employment System）を構築する提案をしています。
- [\[ERC5289\] スマートコントラクトに法的拘束力をもたす仕組みを理解しよう！](https://cardene.dev/articles/2fbc89e0aae6c5e39371.md): このEIP（イーサリアム改善提案）は、スマートコントラクトが現状では法的に拘束力を持たないという大きな問題を解決しようとしています。
- [\[ERC4824\] DAOのためのAPIの仕組みを理解しよう！](https://cardene.dev/articles/cd3582262e403d1346a3.md): この提案では分散型自律組織（DAO）のためのAPI規格について説明しています。
- [\[ERC1202\] オンチェーン投票の標準インターフェースの仕組みを理解しよう！](https://cardene.dev/articles/d4671dd9a46591f749c3.md): このEIPは、スマートコントラクトによる投票を実装するためのAPIです。この標準は、投票機能、投票結果の表示機能、投票ステータスの設定機能を提供します。
- [\[ERC5247\] 提案の作成と実行をするインターフェースの仕組みを理解しよう！](https://cardene.dev/articles/f1c81b127e33c25a29f3.md): このEIP（Ethereum Improvement Proposal）は、ブロックチェーン上のスマートコントラクトに関する提案を作成し、実行するための方法を提供しています。
- [\[ERC5485\] コントラクトの正当性・管轄権・主権を管理する仕組みを理解しよう！](https://cardene.dev/articles/8491c7a0da78b8dcc02d.md): スマートコントラクトが合法であることを示すために、その起源や背後にある法的な基盤を明示します。

## Blockchain / Security

- [\[ERC7512\] スマートコントラクトが監査情報を読み取る仕組みを理解しよう！](https://cardene.dev/articles/0ba765a717c51b57c3b9.md): ERC7512で提案されている仕組みは、監査レポートをオンチェーン上で表現し、スマートコントラクト側がその内容を解析できるようにする標準を整えることを目的としています。
- [\[ERC5437\] コントラクトの脆弱性報告手段を定義する仕組みを理解しよう！](https://cardene.dev/articles/09530e8cad448065d507.md): ERC5437では、非対称暗号を用いた「セキュリティ通知用インターフェース」を導入する提案をしています。
- [\[ERC7746\] コントラクトレベルのセキュリティレイヤーについて理解しよう！](https://cardene.dev/articles/3515f45a89b8be39ffd6.md): ERC7746では、コントラクトにおいてセキュリティレイヤー（ILayer）という標準インターフェースの導入を提案しています。
- [\[ERC7512\] オンチェーンでコントラクト監査の検証を行える仕組みを理解しよう！](https://cardene.dev/articles/4c174d7051247c490660.md): この提案は、オンチェーン（ブロックチェーン上）で監査報告書を表現するための標準を作成することを目指しています。
- [\[EIP155\] Ethereumネットワークでリプレイ攻撃を防ぐ仕組みを理解しよう！](https://cardene.dev/articles/2526432899353e4a0225.md): EIP155は、イーサリアムのトランザクション署名の方法に関する改善提案です。これは、イーサリアムネットワークでの「リプレイ攻撃」を防ぐために設計されました。
- [スマートコントラクトの脆弱性を理解してBugハンターになろう](https://cardene.dev/articles/ff3a98d909b659.md): Bug Bounty（バグバウンティ）とは「脆弱性報奨金制度」という意味で、コントラクトに脆弱性がないか発見することで、報酬をもらうことができます。

## Blockchain / Data

- [\[EIP2327\] バイトコードの後続データを実行対象から分けるBEGINDATA命令](https://cardene.dev/articles/b1fd952ab9b6a98c8166.md): コントラクトのバイトコードには、実行する命令だけでなく、定数、コンパイラのメタデータ、初期化処理で扱うランタイムコードを直接入れられます。従来のEVMは後続バイトをデータとして区別しないため、解析器は末尾まで命令列として扱います。
- [\[ERC6860\] HTTPスタイルのURLでオンチェーンコンテンツにアクセスするWeb3 URLの仕組みを理解しよう！](https://cardene.dev/articles/d9c493fe942473cdeaad.md): ERC6860とは、HTTPスタイルのWeb3 URL（例: web3://uniswap.eth/）をEVMのCall Messageに変換するプロトコルのことです。
- [\[ERC7774\] ブロックチェーンイベントでWeb3ページのキャッシュを更新する仕組みを理解しよう！](https://cardene.dev/articles/a5d9e592865a5fd3218b.md): ERC7774は、ERC6860で定義されている web3:// プロトコルにおける名前解決方式であるERC6944 resolve modeを拡張し、HTTPの標準キャッシュ仕様であるRFC9111を実用的に利用できるようにするための仕組
- [\[ERC7087\] Web3 URLのMIMEタイプ指定仕組みを理解しよう！](https://cardene.dev/articles/8625895604e9ffe95f88.md): ERC7087は、ERC6860で定義されている web3:// プロトコルを拡張する提案です。
- [\[ERC7813\] テーブルベースで構造化されたオンチェーンデータの仕組みを理解しよう！](https://cardene.dev/articles/6119b5c4579e0d76b09a.md): ERC7813は、ブロックチェーン上のデータを柔軟に保存・管理するための「オンチェーンストレージパターン」を提案しています。
- [\[ERC7208\] オンチェーンデータ管理の新しい仕組みを理解しよう！](https://cardene.dev/articles/611a57a3765506ad3d73.md): ERC7208は、オンチェーン上に保存されるデータを「抽象化（Abstraction）」するための一連のインターフェースを定義しています。これにより、データの保存とそれを制御するロジックを分離し、柔軟で拡張性のある設計を可能にします。
- [\[ERC3668\] オフチェーンデータ参照の仕組みを理解しよう！](https://cardene.dev/articles/6bd9a27a7353bd8147b2.md): ERC3668は、スマートコントラクトが外部（オフチェーン）に保存されたデータを取得するための共通仕様です。コントラクトはデータを直接返すのではなく、OffchainLookup というエラーを発生させます。
- [\[RFC3548\] データを文字で扱うBaseエンコーディングの仕組みを理解しよう！](https://cardene.dev/articles/8d5765196bd49e10e9dc.md): Baseエンコーディング（Base64など）は、データを文字列として扱うための仕組みです。特に、古いシステムや特定の環境では US-ASCII（英数字や記号のみを扱う文字コード）しか使えない場合があります。
- [\[ERC725\] 実行とデータ管理を分離したコントラクトの仕組みを理解しよう！](https://cardene.dev/articles/28d8d603ccf5e9384174.md): ERC725は、スマートコントラクトにおける柔軟で長期的に活用できるデータ管理と実行の仕組みを提供するための標準提案です。この標準は2つのサブ仕様から構成されており、それぞれ独立して使うことも、組み合わせて使うこともできます。
- [\[EIP7736\] Verkleツリーでステートデータを期限切れ管理する仕組みを理解しよう！](https://cardene.dev/articles/f8edd33c1a35f593be5f.md): EIP7736では、Verkleツリーの各拡張ノード（共通の鍵接頭部をまとめる中間ノード）に「更新エポック」を導入する提案をしています。
- [\[ERC2193\] オンチェーンデータにエイリアスをつける仕組みを理解しよう！](https://cardene.dev/articles/09bd0bf5cf177bbcef37.md): Aliasは、オンチェーンのリソースに対して人間が読める識別子（エイリアス）を与えるための規格です。
- [\[ERC2569\] オンチェーン上にSVG画像を保存する仕組みを理解しよう！](https://cardene.dev/articles/8de48881dc9665fc3e5d.md): ERC2569で提案されているインターフェースセットは、スマートコントラクトがEthereum上にSVG画像を保存し、後からその画像を取得できるようにする仕組みを提案しています。対応するトークンは以下のように幅広く想定されています。
- [\[ERC3722\] イベントで投稿内容を管理する仕組みを理解しよう！](https://cardene.dev/articles/f919b1ab6e990df8ae98.md): Posterは、非常にシンプルな分散型ソーシャルメディア向けスマートコントラクトです。2つの文字列（content: 投稿内容、tag: タグ）を受け取り、投稿者のアドレス（msg.sender）とともにイベントとして発行します。
- [\[ERC5018\] ファイルをコントラクトに保存する仕組みを理解しよう！](https://cardene.dev/articles/04c33da2f5be1d3982ec.md): ERC5018は、コントラクト内でファイルやディレクトリを扱うためのAPIを標準化する提案です。従来のファイルシステムと同様のインターフェースをEVM上で実現することを目的としています。
- [\[ERC7744\] コントラクトのバイトコードをインデックス化する仕組みを理解しよう！](https://cardene.dev/articles/e1ef294ca3ce70a0e179.md): ERC7744では、Ethereumのコントラクトをバイトコードのハッシュによってインデックス化する標準インターフェースを提案しています。
- [\[ERC7615\] コントラクト間でアトミックにデータをプッシュする仕組みを理解しよう！](https://cardene.dev/articles/845645cfd10e412d27c2.md): この規格では、Ethereumのスマートコントラクトでデータをプッシュ（送信）する仕組みを提案し、パブリッシャーコントラクト（データの送信元）が特定のデータをサブスクライバーコントラクト（データの送信先）に自動でプッシュできる仕組みを提案し
- [\[ERC7618\] データが返される前に指定されたアルゴリズムでデコードする仕組みを理解しよう！](https://cardene.dev/articles/845a5c7673c29fbec458.md): この規格は、ERC6860のweb3URL標準の文脈において、ERC6944のresolveモードを拡張する仕組みを提案しています。
- [\[ERC7617\] 大容量データを小分けにして取得ができる仕組みを理解しよう！](https://cardene.dev/articles/e834423ba74beecb433b.md): この規格は、ERC6860のweb3URL標準の文脈において、ERC6944のresolveモードを拡張する仕組みを提案しています。
- [\[ERC6860\] HTTPスタイルのWeb3URLを使用してオンチェーンコンテンツにアクセスする仕組みを理解しよう！](https://cardene.dev/articles/30bdd75be892cf776b88.md): この規格では、RFC3986をweb3://uniswap.eth/のようなEVMメッセージに変換する仕組みを提案しています。
- [\[ERC7412\] オフチェーンデータを安全かつ効率的に活用する仕組みを理解しよう！](https://cardene.dev/articles/c0ee8e94802318b2d949.md): スマートコントラクトがオフチェーン（ブロックチェーン外）のデータを必要とする場合の対応策を提案しています。
- [\[ERC7406\] ブロックチェーン上での多様なデータ管理を実現するマルチネームスペースレジストリについて理解しよう！](https://cardene.dev/articles/30158f5cab6483bbc9e0.md): このEIP（Ethereum Improvement Proposal、イーザリアム改善提案）は、マルチネームスペースをサポートするマッピングタイプ（キーと値のペア）の構造を取り入れることを提案しています。
- [\[EIP4895\] ビーコンチェーンからEVMへのバリデーター出金サポートの提案を理解しよう！](https://cardene.dev/articles/f154a261447388d500f1.md): ブロックチェーン技術には「ビーコンチェーン」と「EVM（イーサリアム仮想マシン）」という二つの重要な要素があります。
- [\[EIP211\] 動的サイズの返却データを管理するRETURNDATASIZEとRETURNDATACOPYについて理解しよう！](https://cardene.dev/articles/28a034e9998d30fff7a3.md): EVMでより柔軟にデータを扱うためのメカニズムについて提案しています。現状、Ethereumのスマートコントラクト間で情報をやり取りする時には、データの長さに限りがあるため大量のデータをやり取りすることが難しいという問題があります。
- [\[ERC4804\] HTTP形式のWeb3 URLからコントラクトを呼び出すことができる仕組みを理解しよう！](https://cardene.dev/articles/837931ce60ca844aee13.md): この標準は、インターネット上のアドレスを示すURI（例: web3://uniswap.eth/）をイーサリアムブロックチェーンで使える形に変換するものです。具体的には、「EVMMessage」というメッセージ形式に変換します。
- [\[ERC5750\] 各メソッドの引数にデータを追加して動作を拡張する仕組みを理解しよう！](https://cardene.dev/articles/216265154b75c1612904.md): このEIPは、将来の拡張性を考慮して、関数への非構造化データの渡し方を統一する規格です。
- [\[ERC7053\] デジタルメディアの履歴の記録や検索のためのインデックス作成の仕組みを理解しよう！](https://cardene.dev/articles/c27595d80442837083c8.md): このEIPは、Ethereum（イーサリアム）というブロックチェーンプラットフォームおよびその他の互換ブロックチェーン上で、デジタルメディア情報を整理し、取得するための新しい方法を提案しています。
- [\[ERC5219\] GETリクエストのみの効率的なDapp通信の仕組みを理解しよう！](https://cardene.dev/articles/a96196b201a34e6eb640.md): このEIP（Ethereum Improvement Proposal）は、スマートコントラクトへのリソースリクエストとHTTPに似たレスポンスの受け取りを標準化するインターフェースを提供します。

## Blockchain / Contract Design

- [\[EIP8133\] Ethereumアップグレード名の付け方を理解しよう！](https://cardene.dev/articles/2773130eae2ca012e596.md): EIP8133は、Ethereumネットワークアップグレードの命名規則を整理する情報提供型のEIPです。
- [\[ERC8023\] コントラクトの所有権移転を3段階で安全に進める仕組みを理解しよう！](https://cardene.dev/articles/c8fd6c36069536ed7591.md): ERC-8023は、スマートコントラクトの owner を新しいアドレスへ移す操作を、すぐに完了させないためのインターフェースです。
- [\[ERC8167\] selectorごとにdelegatecall先を切り替えるModular Dispatch Proxyの仕組みを理解しよう](https://cardene.dev/articles/dddba8abb85200b4b49e.md): ERC8167は、selector -> delegate の対応表を持つプロキシを標準化します。
- [\[ERC7955\] 許可不要で全EVMチェーンにCREATE2ファクトリーをデプロイする仕組みを理解しよう！](https://cardene.dev/articles/adf69fa6bb1b277d8101.md): ERC7955とは、EIP7702のコード委任メカニズムを利用して、すべてのEVM互換チェーンの同一アドレス（0xC0DEb853af168215879d284cc8B4d0A645fA9b0E）にCREATE2ファクトリーコントラクトをデ
- [\[ERC8042\] 人間が読める文字列でストレージ位置を定義するDiamond Storageの仕組みを理解しよう！](https://cardene.dev/articles/7a8398919701a545b77b.md): ERC8042とは、ERC2535 Diamondsで初めて導入され広く採用されてきたDiamond Storageパターンを正式に標準化する規格です。
- [\[ERC7760\] 最小構成のアップグレード可能プロキシの仕組みを理解しよう！](https://cardene.dev/articles/1d2edb4b1692fb065065.md): ERC7760は、アップグレード可能なコントラクトで広く使われているERC1967方式のプロキシについて、最小構成の標準バイトコードを定義する規格です。
- [\[ERC7738\] スマートコントラクトに実行スクリプトを紐づける仕組みを理解しよう！](https://cardene.dev/articles/c4758b77a4071bb033f0.md): ERC7738は、任意のスマートコントラクトアドレスに対して、対応する実行可能スクリプトのURI（インターネット上の取得先アドレス）を登録・取得できるレジストリコントラクトを定義しています。
- [\[ERC7710\] スマートコントラクトで権限を安全に委譲する仕組みを理解しよう！](https://cardene.dev/articles/0dad0829753e578c2086.md): ERC7710は、スマートコントラクトが持つ権限や実行能力を、他のスマートコントラクトやEOA（Externally Owned Account）に委譲するための標準仕様です。
- [\[ERC7613\] calldataで実行先を指定するPuppet Proxyの仕組みを理解しよう！](https://cardene.dev/articles/346f572ddea9c4573763.md): **Puppet（パペット）**は、「呼び出されると空のアカウント（Externally Owned Account: EOA のように見える存在）」のように振る舞うコントラクトです。
- [\[ERC7511\] Minimal Proxy Contractのデプロイコストを下げる仕組みを理解しよう！](https://cardene.dev/articles/332c08d45da0aecc1b94.md): PUSH0 という新しい命令がShanghaiアップグレードで追加されたことで、**ERC1167（Minimal Proxy Contract）**をより効率的に実装できるようになりました。
- [\[ERC7444\] ロック解除日時を統一的に取得できる仕組みを理解しよう！](https://cardene.dev/articles/5a3104e83f0a7c560e80.md): ERC7444で扱われるさまざまな仕組みの中には、特定の日付まで引き出しや移動ができない**タイムロック（一定期間ロックされる仕組み）**が多く存在します。しかし、「いつロックが解除されるのか」を標準的な形式で示す方法がありませんでした。
- [\[ERC7246\] 所有権を手放さずに権利だけ渡す仕組みを理解しよう！](https://cardene.dev/articles/18c8cdf1e33fa69ca0bf.md): ERC20に「エンカンバー」という機能を追加し、アカウントが自分の保有残高の一部について、特定のアカウントに対して「排他的に移動させる権利」を与えられるようにする内容ですここでいう排他的な権利とは、他の誰でもなく指定した相手だけが、その範囲
- [\[ERC5573\] Ethereumsaサインインで権限を細かく指定できる仕組みを理解しよう！](https://cardene.dev/articles/8009b2d413563ed00601.md): ERC4361（Sign-In with Ethereum: SIWE）は、Ethereumアカウントを使ってブロックチェーンの外部にあるサービス（オフチェーンサービス）へ安全にログインする仕組みを定義した規格です。
- [\[ERC7936\] 複数バージョンを選べるプロキシの仕組みを理解しよう！](https://cardene.dev/articles/81a8458d820f52efc388.md): ERC7936は、スマートコントラクトのプロキシ（実体のロジックを別コントラクトに委ねる仕組み）に「バージョンを選んで呼び出せる」という考え方を取り入れた標準を提案しています。
- [\[ERC838\] SmartContractのエラー表示をわかりやすくする仕組みを理解しよう！](https://cardene.dev/articles/9656f8a54e3a38901527.md): ERC838は、スマートコントラクトの**JSON ABI（Application Binary Interface）**において、発生し得るエラー条件をどのようにエンコード（符号化）するかを定義するものです。
- [\[ERC6224\] スマートコントラクトを一元管理する仕組みを理解しよう！](https://cardene.dev/articles/7d2bde242d2ca81136a1.md): ERC6224では、分散型プロトコルが自らのスマートコントラクトを効率的に管理するためのオンチェーンレジストリシステムを提案しています。
- [\[ERC7820\] 複数コントラクトの権限を一括管理するACRの仕組みを理解しよう！](https://cardene.dev/articles/b3214581da37cdfcdbd7.md): Access Control Registry（ACR）標準は、複数のスマートコントラクトにおける**ロールベースのアクセス制御（Role-Based Access Control, RBAC）**を一元的に管理するための共通インターフェー
- [\[ERC7751\] コントラクトのエラー理由を解析しやすくする仕組みを理解しよう！](https://cardene.dev/articles/4d2d5ab40c2759a5b55a.md): ERC7751では、イーサリアムのスマートコントラクトにおいて「バブルアップされたリバート（bubbled up reverts）」を扱うための標準を提案しています。
- [\[ERC1761\] スコープ単位で安全に権限を与えるApproveの仕組みを理解しよう！](https://cardene.dev/articles/df81010b7d13e50edb67.md): ERC1761は、トークンコントラクトに「スコープ（scope）」という概念を導入し、特定の範囲に限定して承認（approval）を与えるための標準インターフェースを定義する提案です。
- [\[ERC7996\] コントラクトの追加機能を見分けるFeatureの仕組みを理解しよう！](https://cardene.dev/articles/c1cb447f14ce0fb34077.md): ERC7996は、スマートコントラクトが実装している機能を標準的な方法で公開し、それを検出できるようにするための仕組みを定めています。
- [\[ERC2255\] Web3アプリの権限リクエストの仕組みを理解しよう！](https://cardene.dev/articles/e5c2ac6c5d3e2e4520f6.md): ERC2255は、wallet_getPermissions および wallet_requestPermissions という2つの新しいRPCエンドポイントを導入するものです。
- [\[ERC1921\] コントラクト内の関数の共有・再利用する仕組みを理解しよう！](https://cardene.dev/articles/ddedb20a6f1dfd9615c7.md): ERC1921は、ERC1900で定義された分散型型システム（dType）の拡張として、コントラクトの関数を dType レジストリに登録できるようにすることを目的としています。
- [\[ERC1444\] コントラクトのエラーメッセージを多言語化する仕組みを理解しよう！](https://cardene.dev/articles/c178ba42bd417867c976.md): ERC1444は、スマートコントラクトが出力する機械向けのコードを、任意の言語や表現で人間が理解できる文章に変換する方法を提供するものです。変換されたテキストは、ブロックチェーン上に保存され、誰でも作成・登録・共有・利用することができます。
- [\[ERC1066\] コントラクトの実行結果を詳細に取得する仕組みを理解しよう！](https://cardene.dev/articles/f46ae4018f20a2f76c4b.md): ERC1066は、スマートコントラクトの実行結果に対して共通の「ステータスコード（状態コード）」を導入するための標準仕様です。
- [\[ERC2157\] 共通の型定義を共有する仕組みを理解しよう！](https://cardene.dev/articles/1e12c60a54061c578d3d.md): **ERC2157*は、分散型型システムである「dType」のためのストレージ拡張を提案しています。
- [\[ERC1900\] コントラクトの型標準化の仕組みを理解しよう！](https://cardene.dev/articles/822e60e3fb3e4699fb1a.md): Ethereum Virtual Machine（EVM）とSolidityなどの関連言語を「単一のOS（世界のコンピュータ）」へと進化させるには、拡張可能な型システムに対するコンセンサスが必要です。
- [\[ERC2942\] EthPMのカスタムURLの仕組みを理解しよう！](https://cardene.dev/articles/2d4056b2225f673d790a.md): ERC2942は、EthPM（Ethereum Package Manager）におけるレジストリ・パッケージ・リリース・特定のコントラクト資産を識別するためのカスタムURIスキームの導入を提案しています。
- [\[ERC3561\] コントラクトのUpgrade時に遅延時間を設ける仕組みをりかいしよう！](https://cardene.dev/articles/24ebc89e0390ca7dd1eb.md): ERC3561では、アップグレード可能なプロキシにおいて、信頼を前提としない設計を実現する提案しています。特に、匿名の開発者がプロキシのアップグレード機能を利用する時に、外部からの信頼を得にくいという課題を解消するために設計されています。
- [\[ERC4430\] コントラクトの機能実行前に実行内容を視覚化する仕組みを理解しよう！](https://cardene.dev/articles/d1fb7e1c79fa82e4358a.md): ERC4430では、コントラクト内に仮想関数を定義することで、実行可能なバイトコードと同時に人間が読める説明文も生成できる仕組みを提案しています。
- [\[ERC7546\] プロキシとDictionaryコントラクトを使用したコントラクトのモジュール化とアップグレードの仕組みを理解しよう！](https://cardene.dev/articles/b9dd555b54d1bc047fd0.md): Ethereumの仮想マシン（EVM）上でクローン可能かつアップグレード可能なコントラクトを作成することは難く課題でした。
- [\[ERC1822\] UUPSパターンのコントラクトアップグレードの仕組みを理解しよう！](https://cardene.dev/articles/1bbeb4482b69653e3c2e.md): この標準プロキシコントラクトは、すべてのロジックコントラクトと完全に互換性があるように設計されています。
- [\[ERC7654\] リクエストメソッドをもとにコントラクトの構造を管理する仕組みを理解しよう！](https://cardene.dev/articles/951924a8b0143236ea3e.md): この規格では、クライアントとコントラクト間の通信の標準を統一することを提案しています。POST、GET、PUTリクエストが特定の操作にマッピングされ、それに応じてコントラクトのデータの追加、読み取り、変更を行います。
- [\[ERC7509\] コントラクトにECS設計パターンを導入する仕組みを理解しよう！](https://cardene.dev/articles/306fbc1e6814cc37465c.md): この提案は、エンティティ・コンポーネント・システム（ECS）という仕組みを最小限に定義しています。
- [\[ERC6944\] コントラクトが特定のリソース要求をどのようの処理するか指定するための仕組みを理解しよう！](https://cardene.dev/articles/c8f906536dcb7fe7492d.md): EIP (Ethereum Improvement Proposals)はEthereumの機能拡張や標準を提案するドキュメントで、その中で新たに提案されているのは、ERC5219コントラクトのリソース要求を解決するためにERC4804のr
- [\[EIP3541\] 0xEFで始まるコントラクトのデプロイを禁止する提案を理解しよう！](https://cardene.dev/articles/c49b1f83f370c74d3bdb.md): 特定のバイト（0xEF）で始まる新しいコードのデプロイを禁止するという提案に関するものですが、既にアカウントのトライ（ブロックチェーンのデータ構造の一種）に存在する0xEFバイトで始まるコードは、この変更の影響を受けません。
- [\[ERC6617\] ビットベースの権限管理の仕組みを理解しよう！](https://cardene.dev/articles/79da627c6d8ad83cd6d3.md): このEIPはイーサリアムのスマートコントラクトにおいて、非常に高度で柔軟な権限とロール管理システムを実現するためのフレームワークを提案しています。
- [\[ERC6366\] 256ビット数値による効率的かつ柔軟な権限管理の仕組みを理解しよう！](https://cardene.dev/articles/6b797eb78c28cf9d1252.md): このEIP（イーサリアム改善提案）は、アクセスコントロールリスト（ACL）を代替する新しい認証付与とセキュリティ強化の方法を提案しています。
- [\[ERC2678\] Ethereumスマートコントラクトのパッケージ標準の改訂版の仕組みを理解しよう！](https://cardene.dev/articles/fd3e543d98ed13d059e4.md): このEIPは、スマートコントラクトのための新しいファイル形式を提案しています。
- [\[ERC5202\] コントラクトを複製するブループリントコントラクトについて理解しよう！](https://cardene.dev/articles/6db304301f6319fbe7bc.md): "ブループリント"コントラクトとは、初期化コード（initcode）がオンチェーンに保存されるコントラクトを表す標準のことです。
- [\[ERC1820\] SolidityのアップデートによるERC820のバグ修正の仕組みを理解しよう！](https://cardene.dev/articles/81744cc4b3f81da70949.md): この規格は、コントラクトやアカウントがどのインターフェースをサポートしているか、そしてその実装を担当するコントラクトがどれかを登録するためのレジストリコントラクトを提供します。これにより、ERC165との互換性も維持されています。
- [\[ERC820\] 特定のコントラクトが特定の機能を実装しているかなどを知る仕組みを理解しよう！](https://cardene.dev/articles/dc468017e1297a527afd.md): この規格は、スマートコントラクトやアカウントがどのような機能を提供しているかを一元的に登録し確認できるシステムを定義しています。
- [\[ERC5732\] commit-revealスキームをサポートするcommitインターフェースの仕組みを理解しよう！](https://cardene.dev/articles/5e36f1c0f20625932f52.md): このコントラクトのインターフェースは、ブロックチェーン上で特定の情報を隠しながら、後でそれを明らかにするための方法を提供します。これは「コミット-リベール方式」と呼ばれ、特に投票や資産の移転などのシーンで使われます。
- [\[ERC684\] 既存コントラクトの上書きを防ぐ仕組みを理解しよう！](https://cardene.dev/articles/7d0f6db6a4953a583fee.md): このEIP（イーサリアム改善提案）は、イーサリアムのブロックチェーンにおいて、すでに何かしらのコードが存在するアドレスで新たなコントラクトを作成しようとすると、エラーを発生させるものです。
- [\[ERC190\] コントラクトパッケージの標準使用の仕組みを理解しよう！](https://cardene.dev/articles/51bcfc5f5d32fa1362f4.md): この仕様は、コントラクトの作成、管理、配布をより良くするためのルールや方法を定めるものです。
- [\[ERC5269\] 各ERCをサポートしているか識別してくれる仕組みを理解しよう！](https://cardene.dev/articles/fe62ab0ad613c945693f.md): このインターフェースは、Ethereumリソースコントラクト（通常はERCと略されます）を識別および検出するための新しいアプローチを提供します。
- [\[ERC5639\] より安全で便利な権限委譲の仕組みを理解しよう！](https://cardene.dev/articles/015608d3ec01f6882c69.md): このEIPは、提案されたプロトコルとABI（アプリケーションバイナリインターフェース）の詳細を説明しています。
- [\[ERC5982\] ロールベースのアクセス制御の仕組みを理解しよう！](https://cardene.dev/articles/6457bb501aa5ac1677af.md): このEIPは、Ethereumスマートコントラクトにおけるアクセス制御を簡単にする規格です。アクセス制御は、誰がコントラクトの特定の機能や操作を実行できるかを管理する方法です。
- [\[ERC6372\] コントラクトが使用している時間表現を取得する仕組みを理解しよう！](https://cardene.dev/articles/eacc6a32cbac790df52d.md): スマートコントラクトは、特定のタスクを実行する時に時間情報を使用することがよくあります。例えば、特定の条件が満たされるまで待機する必要がある場合や、トランザクションのタイムスタンプを記録して取引の履歴を管理する場合などです。
- [\[ERC2535\] 💎 ダイヤモンドパターンの仕組みを理解しよう！](https://cardene.dev/articles/51fc6fc998421c4d931a.md): この規格では、アップグレーダブルなスマートコントラクトをより柔軟に管理する仕組みを提案しています。
- [\[ERC1967\] コントラクトのアップグレードの仕組みについて理解しよう！](https://cardene.dev/articles/8a46bae9f23f2315ba4e.md): デリゲートプロキシコントラクトは、スマートコントラクトのアップグレードとガスの節約に広く使用されている仕組みです。
- [\[ERC165\] コントラクトが特定のインターフェースをサポートしているか確認する仕組みを理解しよう！](https://cardene.dev/articles/541184977a5cba51b759.md): 以下のことを標準化します。
- [\[ERC5313\] ERC173をシンプルにした提案を理解しよう！](https://cardene.dev/articles/6978005a6899259e2d36.md): この提案では、コントラクトを制御するアカウントを特定するために必要な最小限のインターフェースを定義しています。
- [\[ERC173\] コントラクトの所有権を制御できる仕組みを理解しよう！](https://cardene.dev/articles/0b8cdc156404920a8cbd.md): この仕様では、コントラクトを所有または制御する標準となる関数を定義します。
- [スマートコントラクトのアップグレードを理解しよう！](https://cardene.dev/articles/339d9fd83955cda55d14.md): 「コントラクトはアップデートできない。」このように聞いたことはあると思います。ではコントラクトをアップグレードするとはどういうことでしょうか？

## Blockchain / EVM

- [\[EIP8246\] SELFDESTRUCTでETHが消えないようにする仕組みを理解しよう！](https://cardene.dev/articles/63aabc5cfbd7a6aaa5bf.md): EIP8246は、SELFDESTRUCT によってETHが総供給から消える処理を取り除く提案です。SELFDESTRUCT の対象としてマークされたアカウントは、トランザクション終了時にコード・ストレージ・nonce を消されます。
- [\[EIP8013\] EVMのジャンプ先を静的に読み取れるようにする仕組みを理解しよう！](https://cardene.dev/articles/7f7bc69dac48b12dd3b4.md): EIP8013は、EVMに以下の5つの命令を追加します。
- [\[EIP7976\] calldataのフロアコストを引き上げてブロックサイズを抑制する仕組みを理解しよう！](https://cardene.dev/articles/c08fc5c10faae8c3a7f0.md): EIP7976とは、calldataのフロアコスト（最低ガスコスト）を従来の10/40ガス/バイトから64/64ガス/バイトに引き上げる提案です。
- [\[EIP8024\] EVMスタック操作の16段制限を突破するSWAPN/DUPN/EXCHANGEの仕組みを理解しよう！](https://cardene.dev/articles/f02e024a2a0e7ea905f4.md): EIP8024とは、EVMにDUPN、SWAPN、EXCHANGEという3つの新しいスタック操作命令を追加する提案です。
- [\[EIP7923\] EVMのメモリコストを大幅に安くする仕組みを理解しよう！](https://cardene.dev/articles/fd6eff6af4240149e238.md): EIP7923とは、EVMの二次関数的なメモリモデルを線形のページベースコストモデルに置き換える提案のことです。メモリは仮想的にアドレス指定可能になり、ページ割り当てがコストモデルに含まれます。
- [\[ERC7779\] EIP-7702時代のEOA再委任とストレージ衝突防止の仕組みを理解しよう！](https://cardene.dev/articles/54fbb63f9c4eaee1007a.md): ERC7779は、EIP7702によって導入される「委任可能なEOA（Delegated EOA）」同士が、異なるウォレットやスマートアカウント実装間でも安全かつ一貫して動作するための共通インターフェースを定義する提案です。
- [\[ERC7694\] EthereumからSolanaにストレージを書き込む仕組みを理解しよう！](https://cardene.dev/articles/ba115d9d8543f3f4da1f.md): ERC7694は、Ethereumにおけるクロスチェーン・ストレージルーティングの仕組みを拡張し、Solanaブロックチェーンをストレージ先として直接利用できるようにする標準です。
- [\[ERC7533\] EVMチェーンを安全につなぐPublic Cross Port仕組みを理解しよう！](https://cardene.dev/articles/6b1e25f87f70eec57daf.md): ERC7533が提案するPCP（Public Cross Port）は、複数のEVM互換チェーンを「安全かつ効率的に」つなぐことを目的にした仕組みです。
- [\[EIP1898\] JSON-RPCを拡張してブロックハッシュからステートを取得する仕組みを理解しよう！](https://cardene.dev/articles/0139451be89696bf6212.md): EIP1898は、EthereumのJSON-RPCインターフェースにおけるdefault block parameter（デフォルトブロックパラメータ）」に関する仕様拡張です。
- [\[EIP1153\] EVMの一時ストレージの仕組みを理解しよう！](https://cardene.dev/articles/58a056298e327f7a3604.md): EIP1153では、「トランジエントストレージ（Transient Storage）」と呼ばれる、一時的なストレージ領域を扱う新しいオペコード TLOAD（0x5c）と TSTORE（0x5d）の導入が提案されています。
- [\[EIP7907\] コントラクトサイズ上限256KBの仕組みを理解しよう！](https://cardene.dev/articles/6a741e5355357fc330ee.md): EIP7907では、これまでEthereumで導入されていた「コントラクトコードサイズの上限（24KB）」を256KBまで引き上げる提案がされています。
- [\[ERC2537\] BLS12-381プリコンパイルの仕組みを理解しよう！](https://cardene.dev/articles/ad4371bf51041f39a7d7.md): ERC2537は、BLS12-381というペアリングフレンドリーな楕円曲線に対して、効率的な演算機能を提供するプリコンパイル（precompile）を導入している提案です。
- [\[ERC3772\] uint型のストレージコストを最適化する仕組みを理解しよう！](https://cardene.dev/articles/b856b13c618cc7732546.md): ERC3772は、uint256 型のデータを uint64 や uint96、uint128 などの小さなデータ構造へ圧縮する手法を提案しています。目的は、ストレージコストの最適化です。
- [\[EIP7862\] 1つ前のブロックの最終ステートを参照する仕組みを理解しよう！](https://cardene.dev/articles/5ea2b7975fc88353aa18.md): EIP7862は、各ブロックnのstate_rootを、ブロックnのExecutionPayload内ではなく、前のブロック（n-1）の後のステートを参照するようにする提案です。
- [コントラクトのストレージを解剖してみよう！](https://cardene.dev/articles/fc7d8e876d3d0e.md): まずはコントラクトのストレージについての理解を深めていきましょう。コントラクトにはデータの保管場所が3つあります。
- [\[EIP6\] SUICIDEからSELFDESTRUCTへ用語を置き換える提案を理解しよう！](https://cardene.dev/articles/077e34aa46bf93cee4e8.md): Ethereumでのプログラミングにおいて、EIP（Ethereum Improvement Proposal、イーサリアム改善提案）によって提案された変更の1つに、「SUICIDE」というオペコード（操作コード）の名前を「SELFDEST
- [\[EIP4399\] DIFFICULTYオペコードをPREVRANDAOオペコードに置き換える提案を理解しよう！](https://cardene.dev/articles/121949e0763872786a01.md): このEIP（Ethereum Improvement Proposal：イーサリアム改善提案）は、既存のDIFFICULTY（0x44）オペコードの戻り値の意味を変更し、オペコードの名前をPREVRANDAO（0x44）に変更するものです。
- [\[EIP3855\] 新オペコードであるPUSH0を追加する提案を理解しよう！](https://cardene.dev/articles/b8c702924f5c636877b2.md): PUSH0（0x5f）命令について説明します。この命令はプログラミングやコンピューターサイエンスの分野で使われる概念の1つです。具体的には、スタック型のデータ構造に対して操作を行う命令の1つです。
- [\[EIP2681\] Etherumアカウントのnonceの範囲を制限する提案を理解しよう！](https://cardene.dev/articles/5c48b751358eb85d6821.md): アカウントの「nonce」を0から2^64-1の範囲に限定するという提案です。ここでの「nonce」とは、特定の操作やトランザクションが一度だけ行われることを保証するための一意の番号のことです。
- [\[EIP1052\] 新オペコードであるEXTCODEHASHの導入の提案について理解しよう！](https://cardene.dev/articles/8ecd0c5eeedc88942659.md): このEIP（Ethereum Improvement Proposal、イーサリアム改善提案）は、新しいオペコードに関するもので、コントラクトのコードのkeccak256ハッシュを返す機能を定めています。
- [\[EIP1344\] チェーンIDを返す新オペコードを追加する提案を理解しよう！](https://cardene.dev/articles/c54870930dd0039f9558.md): このEIP（Ethereum Improvement Proposal、イーサリアム改善提案）は、EIP155によるユニークなチェーン識別子を返すオペコードを追加する内容を指しています。
- [\[EIP214\] コントラクト呼び出し時に状態の変更を禁止するSTATICCALLの仕組みを理解しよう！](https://cardene.dev/articles/294b6ce47a343cef3570.md): この提案では、スマートコントラクトの安全性を高めるために新しいオペコードを導入することが提案されています。
- [\[EIP170\] コントラクト作成時にサイズ制限を設ける提案を理解しよう！](https://cardene.dev/articles/eef7d90d07aae21dfe6f.md): ブロックチェーンでは、各トランザクションが含まれるブロックには一意の番号（ブロック番号）が割り当てられています。FORK_BLKNUMは、特定のブロックチェーンアップグレードやフォーク（分岐）が適用されるブロック番号を指します。
- [\[EIP158\] 空のアカウントの自動削除によるステートサイズ減少の仕組みを理解しよう！](https://cardene.dev/articles/7b2cf7ce660ff5426ab8.md): イーサリアムネットワークのアップデート後に適用される新しいルールについて説明しています。主なポイントは以下の通りです。
- [\[EIP145\] SHL・SHR・SARオペコードについて理解しよう！](https://cardene.dev/articles/695a60205ef6ba9e916c.md): ネイティブのビットワイズシフト命令が導入されました。これはホストでの処理効率が高く、コントラクトによって使用する時のコストも安くなります。
- [\[EIP141\] INVALIDオペコードの仕組みについて理解しよう！](https://cardene.dev/articles/69c29ecc0e93cc741f05.md): 特定の「命令」を意図的に「無効」にするように指定します。
- [\[EIP7\] DELEGATECALLについて理解しよう！](https://cardene.dev/articles/c216ea1d7c0a5ede1d44.md): 各チェーンで、このアップデートが有効になるタイミングがまとめられています。メインネットでは1,150,000ブロック目以降、Mordenでは494,000ブロック目以降にこのアップデートが適用されます。
- [\[EIP140\] REVERT命令の仕組みいついて理解しよう！](https://cardene.dev/articles/31e73aaddaa6503332ce.md): REVERT命令は、すべてのガスを消費することなく実行を停止し、状態変更を戻してエラーの原因を返すことができます。
- [\[ERC5164\] 異なるEVMネットワーク間でのコントラクトの実行をサポートする仕組みを理解しよう！](https://cardene.dev/articles/40fd6767fa583a702145.md): この仕様は、EVM（Ethereum Virtual Machine）を使用するブロックチェーンにおいて、異なるチェーン間でスマートコントラクトが連携できる方法を定義しています。

## Blockchain / Protocol

- [\[ERC8179\] Blobを複数プロトコルで分けて使うBlob Space Segmentsの仕組みを理解しよう！](https://cardene.dev/articles/0f439e5747638415df85.md): ERC8179は、EIP4844のBlobを「FEの連続範囲」として区切り、その区間をオンチェーンイベントで宣言するためのインターフェースです。Blobは4096個のFEで構成され、1つのFEは32バイトです。
- [\[EIP7002\] ステーキングしたETHの出金要求を送る新しい仕組みを理解しよう！](https://cardene.dev/articles/fc917bdda0c98a05c7c8.md): EIP7002 は、バリデータの退出や出金要求を、実行レイヤー側からリクエストできるようにする提案です。リクエスト自体は実行レイヤーのコントラクトに送られますが、最終的な処理はコンセンサスレイヤーで行われます。
- [\[EIP7949\] genesis.jsonを標準化してEthereumネットワーク起動の互換性を高める仕組みを理解しよう！](https://cardene.dev/articles/659064822ec4f4ba81ff.md): Ethereumノードを立ち上げる時、そのネットワークがどんな設定から始まるかを定義するファイルがgenesis.jsonです。
- [\[EIP7685\] 実行レイヤーからコンセンサスレイヤーへリクエストを共有する汎用フレームワークの仕組みを理解しよう！](https://cardene.dev/articles/f19820fbecd8049e3885.md): EIP7685とは、コントラクトからトリガーされたリクエストを保存するための汎用フレームワークを定義した規格のことです。実行ヘッダーにリクエスト情報を保存するための単一のフィールドを追加します。
- [AlchemyがどのようにしてBlockchainの最新情報を配信しているのか](https://cardene.dev/articles/alchemy-supernode-vox-nodi.md): AlchemyのSupernodeと、複数のノードの結果を突き合わせて正しいデータを返すVox Nodi、その後継のCortexの仕組みを、従来のノード構成の課題から解説します。
- [\[ERC7776\] ブロックチェーンで財務情報を開示する仕組みを理解しよう！](https://cardene.dev/articles/7b48d4fc669874cd0ecc.md): ERC7776は、EVM（Ethereum Virtual Machine。
- [コンセンサスアルゴリズム](https://cardene.dev/articles/1f308510b8cbde.md): Proof-of-Work（PoW）は、新しいブロックを作るときに「特定の条件を満たすまでハッシュ計算を繰り返す」仕組みです。
- [\[RFC2119\] 技術仕様におけるMUSTやSHOULDなどについての定義を理解しよう！](https://cardene.dev/articles/418e88d341ef1adf5801.md): RFC2119は、IETF（Internet Engineering Task Force）において標準文書を記述する時に使用される「要求レベルを表すキーワード」の意味とその使用方法を定義したドキュメントです。
- [\[ERC1767\] JSON-RPC互換のGraphQL APIの仕組みを理解しよう！](https://cardene.dev/articles/ef9c4021603c368f1743.md): ERC1767は、Ethereumノードに保存されているデータへアクセスするための新しい方法として、GraphQLスキーマを標準化することを目的としています。
- [\[ERC1474\] Ethereum RPC仕様標準化の仕組みを理解しよう！](https://cardene.dev/articles/ad6976e01c325fd88c64.md): ERC1474は、Ethereumノードが実装すべきリモートプロシージャコール（RPC）メソッドの標準的なセットを定義することを目的としています。
- [\[ERC7547\] ブロック検閲を防ぐInclusion Listの仕組みを理解しよう！](https://cardene.dev/articles/995603a46f8e780b2727.md): ブロックチェーンの重要な価値の一つに「検閲耐性」があります。Ethereumにおける「Inclusion List（インクルージョンリスト）」は、この検閲耐性を高めるための仕組みです。
- [\[ERC1581\] ブロックチェーン外でも使える鍵管理の仕組みを理解しよう！](https://cardene.dev/articles/607c58ca12187848b410.md): ERC1581では、BIP32によって定義された「階層的な鍵生成方式（HD鍵：Hierarchical Deterministic key）」を活用し、ブロックチェーンの外側でも使用できる鍵の体系的な運用方法を提案しています。
- [\[EIP7251\] ステーク上限を2048 ETHの仕組みを理解しよう！](https://cardene.dev/articles/f501837f250747fad8b6.md): EIP7251では、Ethereumのバリデータが保有できる最大ステーク額「MAX_EFFECTIVE_BALANCE」の上限を引き上げることが提案されています。
- [\[EIP7917\] proposerの事前スケジュール仕組みを理解しよう！](https://cardene.dev/articles/d513400abeb56d38fea3.md): Ethereumのビーコンチェーンでは、各エポック（約 6.4 分）ごとに「ブロック proposer（提案者）」の順番が決定されます。これまでは次のエポックのproposerスケジュールが完全には予測できませんでした。
- [\[ERC2848\] コントラクトを使用せずにブロックチェーン上にメッセージを残す仕組みを理解しよう！](https://cardene.dev/articles/6a1150ca6186d0568b88.md): My Own Messages（MOM）は、誰でも自分専用の公開メッセージボードを作成できる仕組みです。メッセージボードは常に更新可能で、停止することがなく誰でも検証可能です。
- [\[EIP2077\] Ethereumのマーケティングを改革する提案を理解しよう！](https://cardene.dev/articles/19b53128e43cc702ab23.md): 上記の公式サイトに書いてあるように、「2077年の集団」とのことです。未来を見据えて、そこに向けて活動していくよということですかね。Ethereumのマーケティングを問題視していて、より良いマーケティングを行うことを目標にしているようです。
- [\[EIP1\] EIPの目的とガイドラインについて理解しよう！](https://cardene.dev/articles/24768d24a8d222a07107.md): EIPは、Ethereum Improvement Proposal（Ethereum改善提案）の略です。Ethereumコミュニティに対しての情報提供や、Ethereumの新機能ついての設計文書です。
- [\[EIP2159\] Ethereumクライアントのメトリクスを標準化する提案を理解しよう！](https://cardene.dev/articles/2fa4edccf82eedaef691.md): Ethereumクライアントでは、自身の動作やパフォーマンスを監視し、ブロックチェーンに問題があるなどのエラーが発生した時にアラートを出せるように、Prometheusという監視・警告システムが広く使用されています。
- [\[EIP695\] EthereumのJSON-RPCにチェーンIDを取得できる機能を追加する提案を理解しよう！](https://cardene.dev/articles/02ec9ef125808a70a4d5.md): eth_chainIdは、EthereumのJSON-RPC仕様の一部で、現在接続されているブロックチェーンの識別子、つまりCHAIN_IDを取得するために使われるメソッドです。
- [\[EIP234\] Ethereumログ取得のフィルターオプションにブロックハッシュを追加する提案を理解しよう！](https://cardene.dev/articles/9de1c05e30d5007967d9.md): EthereumのJSON-RPC APIにおけるフィルターオプションの改善提案についてです。
- [\[EIP3554\] マイニングの難易度上昇を意図的に遅らせる提案を理解しよう！](https://cardene.dev/articles/40aeb99b561fabab8d2a.md): ブロックチェーンの「難易度爆弾（Difficulty Bomb）」の遅延に関する提案です。
- [\[EIP2384\] 平均ブロック生成時間の増加を約611日間遅らせる提案を理解しよう！](https://cardene.dev/articles/9df79d55d2bbbccf93d4.md): イーサリアムブロックチェーンでは、ブロック生成時間を意図的に遅くする「難易度爆弾」というメカニズムがあります。
- [\[EIP1234\] PoS実装の遅延によりマイニングの難易度増加を緩和する提案を理解しよう！](https://cardene.dev/articles/f4d3f155968be681a00d.md): イーサリアムネットワークで進行中の変更についてのものです（当時）。イーサリアムは、トランザクションを処理し新しいブロックを生成するためのルールを定めるブロックチェーン技術を使用しています。
- [\[EIP4844\] Shard Blob Transactionsの仕組みについて理解しよう！](https://cardene.dev/articles/4966cf7f6691d7220367.md): 「blob-carrying transactions」とは、イーサリアムネットワークにおいて、非常に大量のデータを含む新しいタイプのトランザクションを指します。
- [\[EIP100\] アンクルブロックをブロック生成の難易度調整に組み込む仕組みを理解しよう！](https://cardene.dev/articles/d1fbd5b7561c81c0b13e.md): ブロックチェーンでは、ブロックの生成速度を一定に保つために、ブロックの難易度を調整する必要があります。
- [\[EIP2\] ホームステッド・ハードフォークについて理解しよう！](https://cardene.dev/articles/2c81484c7469233fa4ee.md): Ethereumのホームステッドアップデートには、以下のような変更点が含まれています。
- [\[EIP4\] EIPの分類を理解しよう！](https://cardene.dev/articles/c8768dcd56884b2ff374.md): この文書は、EIP（Ethereum Improvement Proposals）の分類方法を説明しており、BIP123から適応されました。
- [\[EIP5069\] EIPエディターについてのハンドブックの内容を理解しよう！](https://cardene.dev/articles/f4bc860063f2d613448a.md): Ethereum Improvement Proposal（EIP）エディターは、Ethereumプロトコルとそのエコシステムに関連する文書のリポジトリを管理しています。

## Blockchain / Dev Tools

- [Solidity 0.8.31での変更点まとめ](https://cardene.dev/articles/solidity-0831-changes.md): Solidity 0.8.31では、Ethereumの次期ネットワークアップグレード「Fusaka」への対応や、ストレージレイアウト機能の拡張、さらにリリースプロセスの改善が行われています。
- [OpenAPI+Swagger形式のSolidity仕様書を自動生成](https://cardene.dev/articles/5fee6d0417692955fe93.md): この仕様書はHTTP API設計ではなく、Solidityコントラクトのインターフェイス定義をOpenAPI/Swagger形式で記述するためのものです。
- [パーツを組み立ててスマートコントラクトを作成できる『Modulity』](https://cardene.dev/articles/6413490c3e8619.md): 通常スマートコントラクトを開発する場合は、開発環境が必要となります。この開発環境のセットアップに苦労することが多いです。
- [Solidity 0.8.30での変更点まとめ](https://cardene.dev/articles/7618ac033a6417.md): Ethereumの次期ハードフォーク「Pectra」では、Solidityの挙動やコントラクト設計に直接的な影響を与える複数のEIPが導入されます。
- [Solidity 0.8.29での変更点まとめ](https://cardene.dev/articles/87357e423f4d9f.md): Solidity 0.8.29で、新しいEVM Object Format（EOF）の実験的なサポートがされています。
- [『DApps開発入門』という本](https://cardene.dev/articles/55560122f1298b67b824.md): 『DApps開発入門』という本
- [Solidity 0.8.28での変更点まとめ](https://cardene.dev/articles/59c8cb88018e2b.md): Solidityのバージョン0.8.28では以下の項目が変更されました。
- [OpenZeppelin v5.1での変更点まとめ](https://cardene.dev/articles/3fcd22f83b8a3e.md): これらのイベントは、contracts/interfaces/ ディレクトリの下にある IERC1967 インターフェースから利用可能。
- [Solidity 0.8.27での変更点まとめ](https://cardene.dev/articles/1d9850df4148ab.md): Solidityのバージョン0.8.27では以下の項目が変更されました。
- [Solidity 0.8.25での変更点まとめ](https://cardene.dev/articles/b2d105a995c297.md): Solidityのバージョン0.8.25では以下の項目が変更されました。
- [Solidity 0.8.24での変更点まとめ](https://cardene.dev/articles/a547db420f75a8.md): Solidityのバージョン0.8.24では以下の項目が変更されました。
- [Solidity 0.8.22での変更点まとめ](https://cardene.dev/articles/1d8f5c8c2a6cb7.md): Solidityのバージョン0.8.22では以下の項目が変更されました。
- [Solidity 0.8.23での変更点まとめ](https://cardene.dev/articles/f64f07a9d706fe.md): Solidityのバージョン0.8.23では以下の項目が変更されました。
- [Solidity 0.8.26での変更点まとめ](https://cardene.dev/articles/fc4392ce6c27ef.md): Solidityのバージョン0.8.26では以下の項目が変更されました。
- [\[EIP\] 100個のEIPを記事にまとめてみて思うこと](https://cardene.dev/articles/323bf67fa8cc89a36855.md): EthereumのEIP（Ethereum Improvement Proposal）は、イーサリアムプラットフォームに対する改善提案のことです。
- [\[Bunzz Decipher\] 『Multicall2』コントラクトを理解しよう！](https://cardene.dev/articles/0b08b59bd5ca99.md): Multicall2コントラクトは、MakerDAOが開発した便利なツールで、Ethereumブロックチェーン上で複数の関数呼び出しを効率的に実行します。
- [\[Bunzz Decipher\] 『Permit2』コントラクトを理解しよう！](https://cardene.dev/articles/4251878665f6e4.md): Permit2コントラクトは、Ethereumブロックチェーン上で安全で効率的なトークンの送受信を実現します。
- [Bunzz 『DeCipher』の使い方紹介](https://cardene.dev/articles/33266f0c19d523.md): まずは基本的な使い方から紹介していきます。

## Blockchain / その他

- [\[ERC7566\] オンチェーンゲームでプレイヤー間の交流を促進する仕組みを理解しよう！](https://cardene.dev/articles/e8f257e49bfb5c04dc8f.md): この提案は、マルチプレイヤーゲーム通信（MGC）インターフェースについて述べています。

## AI / Spec-Driven

- [OpenSpecで現行仕様と変更内容を分ける仕組み](https://cardene.dev/articles/openspec-explained.md): OpenSpecは、現在有効な仕様と作業中の変更案をMarkdownファイルで分けて管理するツールです。AIコーディングエージェントは同じ記録を読み、計画と実装を進めます。利用者は、変更理由と外部から確認できる動作を確認します。
- [GitHub Spec Kitで要求から実装までをつなぐ仕組み](https://cardene.dev/articles/github-spec-kit-explained.md): GitHub Spec Kitは、要求、技術設計、作業一覧を別々の記録へ保存し、実装後にコードとの不足を確認する工程をAIコーディングエージェントへ提供するツールです。

## AI / Coding Agents

- [いつでもどこでもiPhoneからPC上のClaude Codeを直接操作できるようにしてみた](https://cardene.dev/articles/claude-code-ui-iphone-tailscale.md): この記事を読み終えると、以下の環境が手に入ります。
- [Claude Codeで過去記事を分析して記事生成を自動化](https://cardene.dev/articles/5b488d7671476b6acf77.md): 技術記事を書くのは楽しいですが、時間がかかる作業でもあります。記事の構成を毎回ゼロから考えたり、過去記事との一貫性を保つのが難しかったりします。
- [自分のCloneに記事を執筆させてみた](https://cardene.dev/articles/claude-code-skill-article-creator.md): 記事を書くのは楽しいですが、時間がかかる作業でもあります。記事の構成を毎回ゼロから考えたり、過去記事との一貫性を保つのが難しかったりします。
- [Code Interpreterを使用してコードの生成とNFTの取引データの分析をしてみよう！](https://cardene.dev/articles/3f7c448595df4bcea598.md): 『Code Interpreter』でデータ分析を行うには、CSVなどのデータを入力する必要があります。そのため、今回は『Dune Analytics』を使用してデータを取得します。