ERC-2848: 我自己的消息 (MOM)
| Authors | Giuseppe Bertone (@Neurone) |
|---|---|
| Created | 2020-08-02 |
| Discussion Link | https://github.com/InternetOfPeers/EIPs/issues/1 |
Table of Contents
简述
我的消息 (MOM) 是一个标准，用于创建你自己的公共、始终更新、不可阻挡、可验证的消息板。
摘要
我的消息 (MOM) 使用以太坊作为命令和消息多重哈希的认证层。它不使用智能合约，而是使用带有特定有效负载的简单自发送交易。
要获得更多见解，你可以测试一个 在线客户端，观看一个 完整视频概述和演示，并阅读一份 简短演示文稿。
动机
作为一名 开发者 或 矿池所有者，我想以一种去中心化的方式向我的用户发送消息。他们必须能够轻松验证我在智能合约上下文中的角色（所有者、用户等），并且他们必须能够在不依赖外部、不安全且容易被黑客攻击的社交媒体网站（Facebook、Twitter 等等）的情况下做到这一点。此外，我想以同样安全和可验证的方式阅读来自我用户群的消息。
作为一名 用户，我想要一种简单的方法来分享我的想法和观点，发布内容，发送消息，接收反馈，接收小费等等，而无需处理任何复杂性：只需编写一条消息，发送它，就完成了。此外，我想写信给一些智能合约的所有者或某些交易的发送者。
作为 浏览器服务，我想为我的用户提供一种有效的方式来阅读智能合约所有者的信息，并提供一个无需使用第三方服务即可分享想法和信息的地方（即 Etherscan 使用 Disqus 等）
并且在 任何角色 中，我想要一种不允许诈骗的方法 - 没有价值的交易，没有要记住或伪造的智能合约地址 - 并且它不允许垃圾邮件 - 它很便宜但不是免费的，即使你可以链接/引用其他帐户，你也不能直接向他们发送消息，如果其他人想阅读你的消息，他们必须明确地关注和监听你的交易。
主要优点：
- 你可以向你的 ÐApp 或智能合约的用户发送消息，他们总是知道这是一个像智能合约一样可靠的声音。
- 创建你专门用于个人消息的以太坊帐户，只需说一次，就可以在每个社交平台上看到（不再需要在 Reddit、Twitter、Facebook、Medium、Disqus 等数十个网站上回复相同的帖子/观点…）
- 一点费用即可获得自由：只需支付几美分的费用即可公证你的消息，并通过 IPFS、Swarm 或你喜欢的任何其他存储方式分发它们。由于内容的 multihash 经过公证，因此你始终可以检查从集中式存储服务下载的消息的完整性。
- 最后，你可以直接在你的钱包中询问并获得你的文字的小费。
我知道，“我的消息 (MOM)”听起来像 妈妈 (mom)。是的，这是双关语 :)
规范
本文档中的关键词“必须 (MUST)”，“不得 (MUST NOT)”，“必需 (REQUIRED)”，“应该 (SHALL)”，“不应该 (SHALL NOT)”，“推荐 (SHOULD)”，“不推荐 (SHOULD NOT)”，“建议 (RECOMMENDED)”，“可以 (MAY)”和“可选 (OPTIONAL)”应按照 RFC 2119 中的描述进行解释，当且仅当它们以全部大写形式出现时。
遵循 MOM 标准的客户端 必须 允许用户发送和读取 MOM 交易，为用户感兴趣的每个地址创建 更新的消息列表 。
读取 MOM 交易时，MOM 客户端 必须 能够显示当前和更新的消息列表，并且如果用户要求，它们 应该 能够显示所有消息历史记录。
除了消息列表之外，MOM 客户端 应该 能够下载消息的内容并将其显示给用户。
客户端 应该 允许用户选择和设置下载内容的来源，并且它们 应该 能够使用常见的内容寻址网络 - 即 IPFS 或 Swarm - 或 HTTP 服务器。如果内容是从 HTTP 服务器下载的，则客户端 必须 根据声明的 multihash 检查内容。
作为默认设置，客户端 必须 将 text/markdown (RFC 7763) 视为由 multihash 表示的内容的媒体类型，特别是 Markdown 文本，采用 UTF-8 编码，不带 BOM。
客户端 可以 让用户选择解析消息时考虑其他内容类型。在这种情况下，它们 应该 向用户发出警告，说明在处理消息时使用了 text/markdown 以外的内容类型。
建议 客户端告知用户默认内容类型的实际设置。
MOM 交易
客户端 必须 假设 无效的 MOM 交易不存在。如果交易没有严格遵循 MOM 标准，则客户端 必须 忽略它，并且它们 绝对不能 将其视为 MOM 交易。
由于解析用户发送的数据可能存在安全隐患，因此客户端 不应该 尝试跟踪或将交易解释为 无效的 MOM 交易。
有效的 MOM 交易数据结构
| 属性 | 值 |
|---|---|
to |
必须 与签署交易的帐户相同。 |
value |
必须 为 0 wei。 |
data |
必须 至少 2 字节。第一个字节 必须 是操作码，后面的字节 必须 基于下面列出的操作码。 |
支持的操作和消息列表
每个操作码都有一个或多个参数，并且所有参数 必须 被认为是强制性的。
不存在可选参数：如果特定操作码的参数不完整或不符合规则，则客户端 必须 完全忽略该交易。
消息 必须 始终使用其内容的多重哈希来引用。
操作分为两组：核心 和 扩展 操作。
- 客户端 必须 支持所有核心操作，并且它们 应该 尽可能多地支持扩展操作。
- 客户端 应该 支持和实现尽可能多的扩展操作，但它们 可以 选择仅实现一些它们感兴趣的特定扩展操作。
核心操作
| 操作 | 代码 | 参数 | 含义 | 效果 |
|---|---|---|---|---|
| 添加 | 0x00 |
multihash | 添加消息。参数 必须 是消息的 multihash。 | 客户端 必须 将消息添加到发送者的消息列表中。 |
| 更新 | 0x01 |
multihash, multihash | 更新消息。第一个参数 必须 是要更新的消息的 multihash。第二个参数 必须 是更新后的消息的 multihash。 | 客户端 必须 更新消息列表以显示更新后的消息。 |
| 回复 | 0x02 |
multihash, multihash | 回复消息。第一个参数 必须 是要回复的消息的 multihash。第二个参数 必须 是消息的 multihash。 | 客户端 必须 在消息列表中插入一条新消息，并且它们 必须 保留与引用消息的关系。 |
| 删除 | 0x03 |
multihash | 删除消息。参数 必须 是要删除的消息的 multihash。 | 客户端 必须 从消息列表中删除消息。 |
| 关闭帐户 | 0xFD |
multihash | 关闭帐户。参数 必须 是包含关闭帐户原因的消息的 multihash。 | 客户端 必须 将包含原因的消息添加到消息列表中，并且它们 绝对不能 再将该地址发送的 MOM 消息视为有效。换句话说，MOM 客户端 必须 在创建消息列表时忽略该地址发送的任何其他交易。当用户想要更改帐户时，这很有用，例如，因为私钥似乎已泄露。 |
| RAW | 0xFF |
任意 | 参数 必须 至少 1 字节。内容类型未公开，并且 绝对不能 将其视为 text/markdown。 |
客户端 必须 将消息添加到消息列表中，但它们 绝对不能 尝试解码内容。客户端 应该 仅在明确要求的情况下才允许用户查看此消息。此操作可用于一般客户端可以忽略的 盲 公证。 |
关于 DELETE 操作码的说明
请注意，发送 DELETE 命令的用户并不是要求实际从区块链中删除任何内容，他们只是要求客户端隐藏该特定消息，因为它由于某些原因不再有效。你可以将其视为用户说：我改变了主意，所以请 ÐApps 不再显示此内容。正如上面规范中已经说明的那样，除非用户明确要求，否则客户端 必须 遵循作者的此请求。
另请注意，因为通常由消息的作者来确保每个人都可以访问该内容，所以如果发送了 DELETE 消息，则很可能 multihash 引用的内容不再可用，仅仅因为它可能没有被任何人共享。
扩展操作
| 操作 | 代码 | 参数 | 含义 | 效果 |
|---|---|---|---|---|
| 添加 & 引用 | 0x04 |
multihash, address | 添加消息并引用一个帐户。第一个参数 必须 是消息的 multihash。第二个参数 必须 是消息引用的地址。 | 客户端 必须 将消息添加到消息列表中，并且它们 必须 跟踪对指定帐户的引用。这对于 邀请 引用帐户的所有者阅读此特定消息很有用。 |
| 更新 & 引用 | 0x05 |
multihash, multihash, address | 更新消息。第一个参数 必须 是要更新的消息的 multihash。第二个参数 必须 是更新后的消息的 multihash。第三个参数 必须 是消息引用的地址。 | 客户端 必须 更新消息列表以显示更新后的消息，并且它们 必须 跟踪对指定帐户的引用。这对于 邀请 引用帐户的所有者阅读此特定消息很有用。 |
| 赞同 | 0x06 |
multihash | 赞同由指定 multihash 标识的消息。参数 必须 是要赞同的消息的 multihash。 | 客户端 必须 记录和跟踪对该特定消息的赞同。可以将其视为 喜欢 、 转发 等。 |
| 移除赞同 | 0x07 |
multihash | 移除对由指定 multihash 标识的消息的赞同。参数 必须 是消息的 multihash。 | 客户端 必须 移除对该特定消息的赞同。 |
| 反对 | 0x08 |
multihash | 反对由指定 multihash 标识的消息。参数 必须 是要反对的消息的 multihash。 | 客户端 必须 记录和跟踪对该特定消息的反对。可以将其视为 我不喜欢 。 |
| 移除反对 | 0x09 |
multihash | 移除对由指定 multihash 标识的消息的反对。参数 必须 是消息的 multihash。 | 客户端 必须 移除对该特定消息的反对。 |
| 赞同 & 回复 | 0x0A |
multihash, multihash | 赞同消息并回复它。第一个参数 必须 是要回复的消息的 multihash。第二个参数 必须 是消息的 multihash。 | 客户端 必须 在消息列表中插入一条新消息，并且它们 必须 保留与引用消息的关系。客户端 必须 还记录和跟踪对该特定消息的赞同。 |
| 反对 & 回复 | 0x0B |
multihash, multihash | 反对消息并回复它。第一个参数 必须 是要回复的消息的 multihash。第二个参数 必须 是消息的 multihash。 | 客户端 必须 在消息列表中插入一条新消息，并且它们 必须 保留与引用消息的关系。客户端 必须 还记录和跟踪对该特定消息的反对。 |
理由
以太坊是 基于帐户的 ，因此最好被标识为单一信息来源。
它还能够很好地进行公证，并对交易结构施加一些限制，因此它很适合用于命令。
IPFS、Swarm 或其他 CAN（内容寻址网络）或存储方法非常适合存储大量信息。因此，这两个世界的结合是实现此消息标准目标的一个很好的解决方案。
目标还在于首先避免任何形式的诈骗和恶意行为，因此 MOM 不允许向其他帐户发送交易，并且 MOM 交易的值始终为 0。
为什么不使用智能合约？
MOM 希望有用、易于实现和读取、防错、快速且廉价，但是：
- 使用智能合约发送消息更容易导致错误和误解：
- 合约地址可能错误
- 要发送消息，必须将智能合约部署在特定的网络上
- 执行智能合约比发送交易的成本要高得多
- 仅执行智能合约来存储静态数据是反模式的最佳示例（昂贵且几乎无用）
如果没有要依赖的特定智能合约，则可以立即在任何现有网络甚至将来的网络中实现和使用 MOM 标准。
最后，如果你可以在没有智能合约的情况下获得完全相同的结果，那么你一开始就不需要智能合约。
为什么不直接将消息存储在链上？
如果 静态 消息与某些智能合约的状态无关，或者它们不代表价值交换，则没有将它们存储在链上的好处。在链上存储数据的成本也很高。
为什么不将操作码存储在消息中？
虽然成本效益是与区块链相关的标准中非常重要的特性，但在可用性和实用性方面也需要达成妥协。
将命令存储在消息中会强制客户端实际下载消息以了解如何处理它们。这是非常低效的，并且会消耗大量带宽和时间。
能够在下载内容之前看到命令，这允许客户端重新创建所有消息的历史记录，然后在最后仅下载更新的消息。
如果消息内容正确、拼写错误等等，则创建消息内容的结构会导致在解析内容时出现许多问题和考虑因素。
最后，内容必须保持干净。你真正想要公证的是内容，而不是引用数据结构，因为这可能会在检查内容是否与另一个内容相同时导致可能的假阴性。
为什么使用 multihash？
Multihash 灵活、面向未来，并且已经有大量的库支持它。以太坊必须能够轻松地与许多不同的平台和架构集成，因此 MOM 标准遵循了这一思路。
向后兼容性
你已经可以在以太坊网络上找到一些使用与此 EIP 相似的模式的交易。有时这样做是为了使内存池中先前的交易无效，使用相同的 nonce 但具有更高的 gas 价格，以便挖掘该交易以取消仍在内存池中的先前交易。如果在批准此 EIP 之前创建了此类交易，或者仅检查有效负载是否遵循正确的语法，则可以轻松地忽略此类交易。
测试用例
可以在 GitHub 上找到并测试符合 MOM 标准的客户端。
你可以直接通过 GitHub Pages 或通过 IPFS 使用最新版本的 MOM 客户端（请参阅 客户端仓库 以获取最新更新的地址）。
实施
你可以在 GitHub Packages 或 npmjs 上使用已经可以正常运行的 MOM JavaScript 包。该软件包已被上面的 MOM 客户端使用，你也可以在你的 ÐApps 中使用它：
npm install @internetofpeers/mom-js
交易 0x8e49485c56897757a6f2707b92cd5dad06126afed92261b9fe1a19b110bc34e6 是主网上已挖掘的有效 MOM 交易的示例；它是一条 ADD 消息。
安全考虑
MOM 非常简单，它本身没有真正的安全问题。该标准已经只考虑了 0 值的有效交易，并且 from 和 to 地址相等。
唯一的问题可能来自有效负载，但这更多与客户端有关，而不是与标准本身有关，因此在这里你可以找到一些与实施该标准的客户端相关的安全建议。
解析命令
MOM 标准涉及解析由潜在的恶意客户端生成的有效负载，因此必须注意避免不必要的代码执行。
- 严格遵守标准代码
- 除非用户明确确认，否则不要执行标准代码之外的任何命令
- 忽略格式错误的交易（不严格遵守规则的交易）
消息
遵循 MOM 标准的消息的默认内容类型是 UTF8 中不带 BOM 的 Markdown 文本。强烈建议禁止读取任何非文本内容类型，除非用户明确确认。
由于内容 multihash 始终存储在链中，因此客户端可以从内容寻址网络（如 IPFS 或 Swarm）或从中央服务器下载该内容。在后一种情况下，客户端应始终检查接收消息的完整性，否则如果它无法这样做，则必须警告用户（未实现或出错的功能）。
版权
版权及相关权利已通过 CC0 放弃。
Citation
Please cite this document as:
Giuseppe Bertone (@Neurone), "ERC-2848: 我自己的消息 (MOM) [DRAFT]," Ethereum Improvement Proposals, no. 2848, August 2020. [Online serial]. Available: https://eips.ethereum.org/EIPS/eip-2848.