はじめに
『DApps開発入門』という本や色々記事を書いているかるでねです。
今回は、スマートコントラクトを使用せずにオンチェーン上にメッセージを残す仕組みを提案しているERC2848についてまとめていきます！
以下にまとめられているものを翻訳・要約・補足しながらまとめていきます。
他にも様々なEIPについてまとめています。
概要
My Own Messages（MOM）は、誰でも自分専用の公開メッセージボードを作成できる仕組みです。
メッセージボードは常に更新可能で、停止することがなく誰でも検証可能です。
この仕組みはスマートコントラクトを使わず、Ethereumの送金トランザクションに特定のペイロード（データ）を添付することで実現されます。
つまり、自分自身に対するETHの送金トランザクションの形式でメッセージを記録し、そのトランザクションの存在とデータによってメッセージの信頼性を保証します。
Ethereumはメッセージの認証レイヤーとして使われ、メッセージの内容自体はIPFSやSwarmなどの分散ストレージに保存されます。
Ethereum上にはそのマルチハッシュ（コンテンツのハッシュ値）だけが記録されるため、検閲に強く改ざんされることがありません。
動機
My Own Messages（MOM）は、Ethereumと分散型ストレージを活用することで、安全かつ信頼性の高いメッセージ配信を実現する新しい仕組みです。
スマートコントラクトのオーナーや開発者にとって、MOMは利用者に対して信頼できる方法で情報を発信する手段を提供します。
従来のSNSのような中央集権的サービスでは、乗っ取りや改ざんのリスクが常につきまといますが、MOMはEthereum上の自己署名トランザクションに基づいて情報の発信者を検証できるため、安全性が確保されます。
スマートコントラクトとの関係性（オーナーやユーザーであること）も明示的に証明できるため、真正性を持った情報提供が可能です。
一方、ユーザーにとってはMOMは手軽にメッセージを発信・共有できる仕組みです。
複雑な操作は必要なく、単にメッセージを書いて送信するだけで自分の意思や意見をEthereum上に記録できます。
さらに、スマートコントラクトの開発者や特定のトランザクションの送信者など、特定の相手に対して直接メッセージを届けることもできます。
ブロックチェーンの特性により、そのやり取りは検証可能で改ざんされることはありません。
ブロックチェーンエクスプローラーなどのサービス提供者にとっては、MOMによってスマートコントラクトの作者からの公式情報やユーザーからの意見などを、中央集権的な外部サービスに依存することなく提供できるようになります。
例えば、EtherscanのようなサービスがEthereum上のメッセージをそのまま表示できる仕組みが実現可能になります。
MOMにはさまざまな利点があります。
まず、スマートコントラクトと連動するアプリケーション（ÐApp）ユーザーに向けて、発信元が明確なメッセージを送ることができます。
次に、一度メッセージを投稿すれば、それをあらゆるプラットフォームで再投稿する必要がなくなるという合理性があります。
メッセージの内容はIPFSなどの分散型ストレージに保存され、そのマルチハッシュをEthereum上に記録することで、改ざんされていないことが証明できます。
さらに、メッセージを読んだ人がその内容に賛同すれば、トークンなどでチップを送ることもできます。
これにより、発信者はコンテンツに対して直接報酬を受け取ることが可能です。
情報の受け手は、特定の発信アカウントを自ら「フォロー」することでのみメッセージを受信するため、スパム行為が起きにくい構造になっています。
このように、MOMは「誰もが自分のメッセージボードを持ち、安心して情報を発信・共有できる」世界を目指して設計されています。
名前の「MOM」には、親しみやすさや温かみを込めた意図もあり、技術的な強さと人間的なやさしさを両立させた提案となっています。
仕様
MOM対応クライアントの基本要件
- ユーザーがMOMトランザクションを送受信できるようにする必要があります。
- 各アドレスごとに最新のメッセージリストを作成し表示する機能が必要です。
- 必要に応じて過去のメッセージ履歴も表示できるようにする必要があります。
- メッセージ本体をIPFSなどからダウンロードして表示できるようにする必要があります。
- コンテンツの取得元をユーザーが選択・設定できるようにする必要があります。
- HTTPからダウンロードする場合は、必ずマルチハッシュと一致するか検証する必要があります。
- デフォルトでは、コンテンツのメディアタイプは
text/markdown（UTF-8, BOMなし）と見なされます。 - ユーザーが他のメディアタイプを選択できるようにしてもよいが、その場合は注意喚起を行う必要があります。
- クライアントは、現在設定されているデフォルトのメディアタイプをユーザーに明示することが推奨されます。
MOMトランザクションの検証ルール
- MOMトランザクションはすべて有効と仮定する必要があります。
- MOM標準に準拠していないトランザクションは無視しなければなりません。
- MOMに準拠していないデータを誤って処理しないようにするため、解釈や追跡は避けるべきです。
有効なMOMトランザクションの条件
| 属性 | 条件 |
|---|---|
to |
署名者のアカウントと同一である必要があります。 |
value |
必ず 0 wei である必要があります。 |
data |
最低でも2バイト以上必要。最初の1バイトはオペコード（命令コード）、以降のバイトはその命令に対応するパラメータである必要があります。 |
コアオペレーション一覧
| 操作名 | コード | パラメータ | 意味 | クライアントの挙動 |
|---|---|---|---|---|
ADD |
0x00 |
メッセージのマルチハッシュ | 新規メッセージの追加 | 送信者のメッセージリストに追加 |
UPDATE |
0x01 | 旧マルチハッシュ, 新マルチハッシュ | 既存メッセージの更新 | リスト内のメッセージを更新 |
REPLY |
0x02 |
返信対象メッセージ, 新しいメッセージ | メッセージへの返信 | 新規メッセージを追加し、返信元との関係を保存 |
DELETE |
0x03 |
削除対象メッセージ | 表示からの削除リクエスト | クライアントは対象のメッセージを表示しない（ブロックチェーンからの削除ではない） |
CLOSE ACCOUNT |
0xFD |
アカウント終了理由のメッセージ | アカウントの使用停止 | メッセージを追加後、そのアドレスからのMOMメッセージを今後無視する |
RAW |
0xFF |
任意（最低1バイト） | 非公開フォーマットのメッセージ（例：バイナリ） | デコードせずに保持し、ユーザーが明示的に要求した場合のみ表示 |
DELETEについての補足
DELETEはブロックチェーン上からの削除ではなく、クライアント側での非表示処理の指示です。
発信者が「このメッセージは無効にしたい」と意思表示することで、閲覧側に非表示を求めるものです。
内容がIPFS等で既に共有されていなければ、実質的にアクセス不能となる可能性があります。
拡張オペレーション一覧
| 操作名 | コード | パラメータ | 意味 | クライアントの挙動 |
|---|---|---|---|---|
ADD & REFER |
0x04 |
メッセージ, 参照アドレス | メッセージ投稿とアカウント参照 | メッセージを追加し、指定アドレスを参照対象として記録 |
UPDATE & REFER |
0x05 |
旧メッセージ, 新メッセージ, 参照アドレス | メッセージ更新と参照 | メッセージを更新し、指定アドレスを参照対象として記録 |
ENDORSE |
0x06 |
メッセージ | メッセージへの賛同（いいね） | 賛同を記録 |
REMOVE ENDORSEMENT |
0x07 |
メッセージ | 賛同の取消 | 賛同を削除 |
DISAPPROVE |
0x08 |
メッセージ | メッセージへの否定的反応 | 否定を記録 |
REMOVE DISAPPROVAL |
0x09 |
メッセージ | 否定の取消 | 否定を削除 |
ENDORSE & REPLY |
0x0A |
返信対象メッセージ, 新メッセージ | 返信と賛同の同時実行 | メッセージ追加・返信関係の保存・賛同の記録 |
DISAPPROVE & REPLY |
0x0B |
返信対象メッセージ, 新メッセージ | 返信と否定の同時実行 | メッセージ追加・返信関係の保存・否定の記録 |
実装上の注意点
- コアオペレーションはすべてのクライアントで必ず対応する必要があります。
- 拡張オペレーションは、できるだけ多くに対応することが推奨されていますが、一部だけの実装も可能です。
- すべてのオペレーションでは、指定されたパラメータが完全にそろっていない場合は、そのトランザクションを無視する必要があります。
このように、MOMは極めて厳密な仕様に基づいており、コンテンツの信頼性やクライアント間の互換性を維持するための設計がなされています。
補足
MOM標準の設計背景と技術的根拠
MOM（My Own Messages）標準は、EthereumとIPFSなどの外部ストレージを組み合わせて、安全で効率的なメッセージ配信を実現するために設計されています。
その根底には、ブロックチェーンと分散型ストレージの役割を明確に分け、それぞれの強みを活かすという思想があります。
なぜEthereumを使うのか
Ethereumはアカウントベースであるため、あるアカウントから発信された情報であることを一意に識別できます。
また、Ethereumには署名やトランザクション構造の制約といった「公証（notarization）」の仕組みが備わっており、コマンドの発行や検証に適しています。
なぜIPFSやSwarmを使うのか
IPFSやSwarmといったコンテンツアドレス型ネットワーク（Content Addressable Network）は、大量のデータ保存に適しています。
Ethereum上ではハッシュ（multihash）だけを保存し、実際のデータは外部に置くという設計により、効率性と拡張性を確保できます。
このように、EthereumとCANを組み合わせることで、信頼性のあるコマンド送信と大量データの効率的保存という両方の目標を同時に達成できます。
なぜ他人宛てにトランザクションを送れない仕様なのか
MOMは詐欺や悪意ある行為を未然に防ぐことを目的としています。
そのため、MOMトランザクションは「自分宛て」でなければならず、他人に送信することはできません。
また、ETHの送信も禁止されており、常に value = 0 に固定されています。
これにより、意図しない資金移動や誘導の余地を排除しています。
なぜスマートコントラクトを使わないのか
スマートコントラクトを使うと以下のような問題が発生しやすくなります。
- コントラクトアドレスの入力ミスにより機能しない可能性がある
- 対象ネットワーク上にコントラクトが存在していなければ機能しない
- 実行コストが高くなる
- 静的データの保存だけを目的としたスマートコントラクトは、設計の観点からもアンチパターンとされている
MOMは、スマートコントラクトを一切必要としないため、既存のEthereumネットワークや将来の互換ネットワーク上でもすぐに利用できます。
「同じ結果をスマートコントラクトなしで達成できるのであれば、最初から使う必要はなかった」という原則に基づいています。
なぜメッセージ自体をオンチェーンに保存しないのか
メッセージがスマートコントラクトの状態や価値移転に直接関係しない場合、オンチェーンに保存する意味はありません。
オンチェーンのストレージは非常に高価であり、静的なメッセージの保存には適していません。
なぜオペコードをメッセージ本文に含めないのか
オペコード（操作命令）をメッセージの本文に含めてしまうと、クライアントはメッセージ内容をダウンロードしないと、どのような操作か判断できなくなります。
これにより、帯域幅の浪費や処理の遅延が発生し、効率が大きく低下します。
トランザクションのデータ部分にオペコードを含めておけば、クライアントは先にすべての操作履歴を把握し、その後で更新済みのメッセージだけを選んでダウンロードできるようになります。
これは大規模なクライアント処理において非常に重要な設計です。
また、メッセージ本文にコマンド構造を含めてしまうと、構文エラーやパースミスなどによる不整合が発生するリスクも高くなります。
内容は純粋な情報にとどめ、命令部分とは分離すべきというのがMOMの方針です。
なぜmultihashを使うのか
multihashは、将来のアルゴリズム変更にも柔軟に対応できる形式で、さまざまなハッシュアルゴリズムを区別可能です。
すでに多くのライブラリがサポートしており、Ethereumとも高い互換性を持ちます。
MOMがmultihashを採用しているのは、この標準が異なるプラットフォームやアーキテクチャと統合しやすいという利点を持つためです。
互換性
Ethereumネットワーク上には、MOMの仕様に似た形式で送信されたトランザクションがすでに存在します。
これは主に、メモリプール内の既存トランザクションをキャンセルする目的で使われています。
例えば、同じnonceでガス価格の高い別のトランザクションを送ることで、元のトランザクションを無効化するケースがあります。
このような既存のトランザクションは、MOM標準として正式に承認される前に送られたものであり、パース対象から除外すべきです。
具体的には、トランザクションのペイロードがMOM仕様に従った構造でない限り、それをMOMメッセージとみなして処理するべきではありません。
セキュリティ
MOMは非常にシンプルな設計であり、標準自体には重大なセキュリティリスクは存在しません。
MOMとして有効と認められるトランザクションは、送信先と送信元が同一のアドレスであり、かつ送金額が0である必要があります。
これにより、資金移動やなりすましといったリスクは基本的に排除されています。
ただし、セキュリティ上の懸念は、MOMを実装するクライアント側に発生する可能性があります。
コマンドのパース処理に関する注意
MOMでは、外部のユーザーが生成したペイロード（バイナリデータ）をクライアントが解釈して処理するため、不正なデータや悪意のある構造に注意する必要があります。
- 標準で定義されたオペコードのみを厳格に解釈し、それ以外の命令を実行してはなりません。
- ユーザーの明示的な同意なしに、標準外の処理やコマンドを実行してはいけません。
- 仕様に違反した形式のトランザクションは完全に無視することが求められます。
メッセージの扱いに関する注意
MOM標準で想定されているメッセージの形式は、UTF-8（BOMなし）のMarkdownテキストです。
この形式以外のメッセージは、ユーザーが明示的に許可しない限り、表示を許可するべきではありません。
また、メッセージの実体はIPFSやSwarmといったコンテンツアドレス型ネットワーク、あるいはHTTPサーバーから取得される可能性があります。
このとき、取得したコンテンツの整合性（内容が改ざんされていないか）を検証する必要があります。
- マルチハッシュと照合して、メッセージ内容が正当であるかを必ずチェックするべきです。
- クライアントにその検証機能が実装されていない場合や検証に失敗した場合には、ユーザーに警告を表示するべきです。
このように、MOM自体は非常に安全で簡素な仕組みですが、その安全性を実現するには、クライアント側の実装が正しく行われていることが前提となります。
標準に厳密に従うことが、MOMを安心して使えるメッセージング手段として成立させるための鍵となります。
引用
Giuseppe Bertone (@Neurone), "ERC-2848: My Own Messages (MOM) [DRAFT]," Ethereum Improvement Proposals, no. 2848, August 2020. [Online serial]. Available: https://eips.ethereum.org/EIPS/eip-2848.
最後に
今回は「スマートコントラクトを使用せずにオンチェーン上にメッセージを残す仕組みを提案しているERC2848」についてまとめてきました！
いかがだったでしょうか？
質問などがある方は以下のTwitterのDMなどからお気軽に質問してください！
他の媒体でも情報発信しているのでぜひ他も見ていってください！