ERC-3722: Poster

一个非常简单的通用社交媒体智能合约。

Poster

摘要

一个非常简单的通用社交媒体智能合约。 它接受两个字符串（content 和 tag）作为参数，并将这些字符串以及 msg.sender 作为事件发出。 就这样。 此 EIP 还包括一个针对类似 Twitter 应用程序的拟议标准 json 格式，其中每个 post() 调用都可以包含多个帖子和/或操作。 假设应用程序状态将通过一些索引器在链下构建。

动机

Poster 旨在用作去中心化社交媒体的基础层。 它可以部署到几乎任何与 EVM 兼容的网络上的相同地址（通过单例工厂）。 任何以太坊帐户都可以在其本地网络上的 Poster 部署中发布帖子。

规范

合约

contract Poster {

    event NewPost(address indexed user, string content, string indexed tag);

    function post(string calldata content, string calldata tag) public {
        emit NewPost(msg.sender, content, tag);
    }
}

ABI

[
    {
      "anonymous": false,
      "inputs": [
        {
          "indexed": true,
          "internalType": "address",
          "name": "user",
          "type": "address"
        },
        {
          "indexed": false,
          "internalType": "string",
          "name": "content",
          "type": "string"
        },
        {
          "indexed": true,
          "internalType": "string",
          "name": "tag",
          "type": "string"
        }
      ],
      "name": "NewPost",
      "type": "event"
    },
    {
      "inputs": [
        {
          "internalType": "string",
          "name": "content",
          "type": "string"
        },
        {
          "internalType": "string",
          "name": "tag",
          "type": "string"
        }
      ],
      "name": "post",
      "outputs": [],
      "stateMutability": "nonpayable",
      "type": "function"
    }
]

类似 Twitter 的帖子的标准 json 格式

{
  "content": [
    {
      "type": "microblog",
      "text": "this is the first post in a thread"
    },
    {
      "type": "microblog",
      "text": "this is the second post in a thread",
      "replyTo": "this[0]"
    },
    {
      "type": "microblog",
      "text": "this is a reply to some other post",
      "replyTo": "some_post_id"
    },
    {
      "type": "microblog",
      "text": "this is a post with an image",
      "image": "ipfs://ipfs_hash"
    },
    {
      "type": "microblog",
      "text": "this post replaces a previously posted post",
      "edit": "some_post_id"
    },
    {
      "type": "delete",
      "target": "some_post_id"
    },
    {
      "type": "like",
      "target": "some_post_id"
    },
    {
      "type": "repost",
      "target": "some_post_id"
    },
    {
      "type": "follow",
      "target": "some_account"
    },
    {
      "type": "unfollow",
      "target": "some_account"
    },
    {
      "type": "block",
      "target": "some_account"
    },
    {
      "type": "report",
      "target": "some_account or some_post_id"
    },
    {
      "type": "permissions",
      "account": "<account_to_set_permissions>",
      "permissions": {
        "post": true,
        "delete": true,
        "like": true,
        "follow": true,
        "block": true,
        "report": true,
        "permissions": true
      }
    },
    {
      "type": "microblog",
      "text": "This is a post from an account with permissions to post on behalf of another account.",
      "from": "<from_address>"
    }
  ]
}

原理

关于是否还应该发出帖子 ID，内容应该是字符串还是字节，以及实际上是否应该发出任何内容，存在一些讨论。

我们决定不发出 ID，因为它意味着向合约添加状态或复杂性，并且存在一种相当常见的模式，即根据 transactionHash + logIndex 在索引器层上分配 ID。

我们决定发出一个字符串，而不是字节，仅仅是因为这将使内容在许多现有界面（例如 Etherscan）上具有人类可读性。 不幸的是，这确实消除了一些我们可能从更紧凑的编码方案（如 CBOR）中获得的好处，而不是 JSON。 但这也不能满足人类可读的标准。

如果我们决定不发出任何内容，虽然可以节省一些 gas，但会大大增加索引帖子的节点要求。 因此，我们认为值得付出额外的 gas 才能实际发出内容。

参考实现

Poster 已使用 Singleton Factory 部署在多个网络上的 0x000000000000cd17345801aa8147b8D3950260FF。 如果它尚未部署在您选择的网络上，您可以使用 Singleton Factory 在几乎任何与 EVM 兼容的网络上的同一地址部署 Poster 实例，使用以下参数：

initCode: 0x608060405234801561001057600080fd5b506101f6806100206000396000f3fe608060405234801561001057600080fd5b506004361061002b5760003560e01c80630ae1b13d14610030575b600080fd5b61004361003e3660046100fa565b610045565b005b8181604051610055929190610163565b60405180910390203373ffffffffffffffffffffffffffffffffffffffff167f6c7f3182d7e4cb876251f9ae1489975fdbbf15d9f35d393f2ac9b1ff57cec69f86866040516100a5929190610173565b60405180910390a350505050565b60008083601f8401126100c4578182fd5b50813567ffffffffffffffff8111156100db578182fd5b6020830191508360208285010111156100f357600080fd5b9250929050565b6000806000806040858703121561010f578384fd5b843567ffffffffffffffff80821115610126578586fd5b610132888389016100b3565b9096509450602087013591508082111561014a578384fd5b50610157878288016100b3565b95989497509550505050565b6000828483379101908152919050565b60006020825282602083015282846040840137818301604090810191909152601f9092017fffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffe016010191905056fea2646970667358221220ee0377bd266748c5dbaf0a3f15ebd97be153932f2d14d460d9dd4271fee541b564736f6c63430008000033

salt: 0x9245db59943806d06245bc7847b3efb2c899d11b621a0f01bb02fd730e33aed2

在区块浏览器上验证源代码时，请务必将优化器设置为 yes，并将运行次数设置为 10000000。

源代码可在 Poster 合约存储库 中找到。

安全考虑

鉴于 Poster 的极其简单的实现，在合约级别上似乎没有任何真正的安全问题。

在应用程序级别，客户端应确认包括与 msg.sender 不同的 "from" 字段的帖子已通过 "permissions" 帖子获得了 "from" 地址的授权，否则应将其视为无效或来自 msg.sender 的帖子。

客户端还应确保对帖子数据进行清理。

版权

版权和相关权利通过 CC0 放弃。

Citation

Please cite this document as:

Auryn Macmillan (@auryn-macmillan), "ERC-3722: Poster [DRAFT]," Ethereum Improvement Proposals, no. 3722, July 2021. [Online serial]. Available: https://eips.ethereum.org/EIPS/eip-3722.