0xfd8d9047…dc48sent to0xfd8d9047…dc48·#25,767,379·view on Etherscan
I have an idea.
The Ethereum Message Protocol uses Ethereum transactions as a decentralized, permanent, and publicly verifiable message layer. The protocol defines the meaning of a message based primarily on the transaction’s sender and recipient addresses, while the input data field carries the actual message payload.
The protocol has three basic message types:
A → BLACK_HOLE
This represents a public broadcast message. The sender places the message directly into input data, and anyone can discover and read it by monitoring transactions sent to the predefined BLACK_HOLE address.
A → A
This represents an encrypted personal note. Before sending the transaction, A encrypts the message using a securely derived encryption key. The encrypted data is stored in input data, allowing A to retrieve and decrypt the message later. The Ethereum private key should not be used directly as a symmetric encryption key; a proper key-derivation mechanism should be used instead.
A → B
This represents an end-to-end encrypted message. A encrypts the message for B using an appropriate public-key or hybrid encryption scheme, and the resulting ciphertext is stored in input data. B can retrieve transactions where to = B and decrypt the message using the corresponding private key or messaging key.
This design makes message discovery relatively simple. A client does not need to scan the entire blockchain and inspect every transaction. To find messages addressed to B, it can query transactions where to = B and then filter for transactions containing the protocol’s message format and non-empty input data. Transactions where from = to can be interpreted as personal encrypted notes, while transactions where from ≠ to can be interpreted as messages addressed to the recipient. Transactions sent to BLACK_HOLE can be indexed separately as public broadcasts.
The protocol should define a small message envelope, such as MAGIC | VERSION | TYPE | CRYPTO | NONCE | PAYLOAD, so that clients can distinguish protocol messages from ordinary Ethereum transaction data and support future protocol versions.
The system provides confidentiality of message content, but not anonymity. Even when A → B contains encrypted data, the blockchain still publicly reveals that A sent a transaction to B, as well as its timing and approximate data size. Therefore, the protocol should be described as a public blockchain messaging system with encrypted content, rather than an anonymous communication system.
The main limitation is cost: Ethereum calldata is relatively expensive and permanently stored as blockchain history. This architecture is therefore most suitable for small messages, permanent records, notifications, and cryptographic metadata rather than high-volume communication or large files. For larger data, an off-chain storage layer could be combined with Ethereum as the immutable message and integrity anchor.