Axiom：去中心化与抗审查通信协议

🚀 线上部署详情

• 网络： Arbitrum One（主网 L2）
• 链 ID： 42161
• RPC 端点： https://arb1.arbitrum.io/rpc（或任何自定义的 Alchemy/Infura 端点）
• Axiom 代理合约地址： 0xc11CFf8111e8b1F055eba095Efb679a38Abe6b63

（注意：Axiom 采用 UUPS 可升级代理架构。所有客户端交互必须始终指向此代理地址，而绝不能指向底层实现合约。）

📖 如何读取数据（索引器/客户端）

客户端绝不应尝试从智能合约状态变量中直接读取协议帖子（因为优先考虑节省 Gas，内容不存储在状态中）。相反，客户端必须索引区块链事件。

✍️ 如何发布数据（客户端交易提交）

要向协议发布数据，客户端必须提交一笔链上交易，调用代理合约上的 publishAxiom 函数。

---

Axiom 的目标是提供一个完全匿名、去中心化且抗审查的社交媒体平台。

为了实现这一点，架构严格划分：基础层（协议）和客户端（软件）。此代码仓库定义了该基础层——一个部署在以太坊 Layer 2 网络上的智能合约和一个标准化的数据结构。

项目范围

该协议确立了平台的基础：

• 标准命名约定： 一个清晰的结构，定义了数据如何发送到智能合约以及客户端如何读取它们。
• 不可变性： 区块链作为防故障和防篡改的数据库。
• 微博客专注： 该协议并非为大量链上数据而设计，而是遵循传统的微博客概念（短帖）。媒体文件不原生存储在链上，而是在需要时通过外部链接嵌入。
• 垃圾信息防护： 交易费用以及钱包首次发帖的一次性低额入场费，可防止僵尸网络造成状态膨胀攻击。
• 安全路由： 协议根据特定安全要求强制对消息进行 OPSEC 分离。

---

协议安全级别

Axiom 旨在让通信受限国家的用户真正实现言论自由。协议区分三种安全级别。它假设用户知道哪种安全级别适合他们的具体情况。

• 级别 1：开放 通信以明文形式在区块链上公开进行。所有客户端均可读取并处理全部流量。此级别允许嵌入链接（例如，通过第三方提供商加载图片）。期望标准社交媒体通信在此发生——包括搞笑猫咪图片。这会在网络中产生重要的噪声。在纯 IP 追踪方面安全性较低，但帖子完全无法被审查。
• 级别 2：封闭 此级别旨在实现严格安全。它仅支持纯文本消息。协议在此禁止媒体链接，以在技术层面杜绝客户端加载外部内容时出现 IP 泄露。用户必须独立确保他们匿名获取用于支付 Gas 费用的加密货币。
• 级别 3：加密 专为最高隐私保护而构建。消息本身在发送前使用 AES-256-GCM 加密。只有元数据、初始化向量 (IV) 和密文存储在区块链上。只有拥有正确加密密钥的用户客户端才能解密并读取这些消息。

网络安全与 IP 追踪（硬性规定）

对于所有级别，洋葱路由（例如 Tor）是严格强制要求的。与商业 RPC 提供商（如 Infura 或 Alchemy）通信会以明文方式泄露发送者的 IP 地址。为了关闭持不同政见者可能面临的致命 OPSEC 漏洞，客户端必须通过 Tor 网络将交易路由到 RPC 节点。

---

加密标准（适用于级别 3）

对于级别 3 的消息，所有客户端必须严格遵守以下加密标准，以确保互操作性并避免损害安全性。

1. 加密算法：AES-256-GCM 所有级别 3 的负载必须使用 AES 的 GCM 模式进行对称加密，密钥长度为 256 位。初始化向量 (IV/Nonce) 必须为每条消息随机重新生成，并作为明文元数据写入区块链。这可以防止外部观察者进行模式识别。
2. 密钥派生：Argon2id 用户在其客户端中输入人类可读的密码。这些密码绝不能直接用作 AES 密钥。客户端被严格要求使用 Argon2id 哈希算法。（注意：开发者必须在客户端内定义固定的迭代次数和内存使用参数，以便所有客户端生成完全相同的密钥。）
3. 密钥交换：带外 Axiom 不处理链上密钥交换。协议不存储任何公钥。交换特定频道的密码（共享秘密）是用户的责任，且必须在网络之外进行（例如，当面进行）。
4. 数据完整性 AES-GCM 会生成一个认证标签。客户端必须验证此标签。如果验证失败，客户端必须静默丢弃该消息（drop）。

---

数据结构、负载交付与索引

Axiom 采用混合负载交付（ABI 拆分）。为了避免智能合约解包昂贵的数据格式，数据在传输前被分离：

1. 逻辑变量： 级别 (uint8 _level) 和初始化向量 (bytes _iv) 作为直接参数传递给智能合约，因为合约需要它们来执行其安全规则。
2. 不透明数据： 实际消息内容由客户端内部构建为 JSON，并压缩为 CBOR（简明二进制对象表示）。合约“盲目”地处理此 CBOR 包，并直接将其转发到事件日志中。

负载键（CBOR 结构）

Axiom 使用单字母作为键以节省字节。作者 (msg.sender) 和时间戳 (block.timestamp) 被省略，因为智能合约会以防篡改的方式提取这些值。

• t（类型）：整数。操作的类型。
• c（内容）：字符串/字节。文本、名称或密文。
• h（标签/话题标签）：数组。可选。用于分类（子频道）。
• m（消息提示）：字节（长度为 2）。仅限级别 3。 用于模糊分桶的 2 字节 HMAC 哈希值。
• r（回复至）：字节。可选。被引用帖子的交易哈希。

操作类型（t 字段）

• 0 = 资料更新（将钱包地址链接到字段 c 中的可读名称）
• 1 = 帖子（标准消息）
• 2 = 回复（r 需要原始帖子的哈希）
• 3 = 喜欢（r 需要帖子的哈希）
• 4 = 取消喜欢（撤销类型 3）
• 5 = 转发/转帖（r 需要帖子的哈希）
• 6 = 取消转发（撤销类型 5）

子频道与暗路由（h 字段）

• 级别 1 和 2： 标签以明文方式传递。
• 级别 3（加密）： 协议级别严格禁止以明文方式传递标签，因为这会泄露元数据。标签必须像内容 (c) 一样被加密。因此，对于外部观察者来说，标签是完全不可见的（暗路由）。

级别 3：模糊分桶（m 字段）

由于级别 3 的标签是加密的，理论上客户端必须尝试解密每一条消息（试解密）。为了防止 CPU 过载，Axiom 使用消息提示：

• 发送方计算 HMAC-SHA256(AES_Key, IV)，并将前 2 个字节 作为字段 m 放入 CBOR 负载中。
• 接收方对其本地存储的密码计算出此提示。仅当匹配时，才会执行昂贵的解密过程。这能在不泄露元数据的情况下过滤掉 99.99% 的无关流量。

---

身份：全局资料与私人别名

Axiom 以完全透明的方式处理身份：L2 钱包地址 (msg.sender) 是唯一的社会和金融身份。 协议将金融 OPSEC 的责任完全转移给用户（例如，使用混币器和跨链桥来匿名获取 Gas 代币）。

资料更新操作 (t: 0) 根据所选安全级别表现不同：

1. 全局身份（级别 1 和 2） 如果钱包发送未加密的资料更新，它便作为全局声明。该钱包在整个网络中以该名称被知晓。所有人都能看到此名称（例如，建立公开声誉如 @Dissident99）。
2. 私人别名与昵称（级别 3） 如果钱包在加密的级别 3 负载内发送资料更新，它会创建一个隔离的、私有的别名。此别名仅在已解密的子频道内对知道密码的用户可见。这允许在封闭群组中进行假名角色分配，而无需改变全局身份。渲染优先级： 对于级别 3，前端必须始终先检查是否存在本地别名，如果存在则使用，否则回退到全局名称。

---

智能合约架构与 OPSEC 强制执行

Axiom 依赖于 O(1) 复杂度的链上验证。为了将 Gas 成本保持在绝对最低水平，智能合约仅执行基本的加密检查。所有资源密集型的内容验证都被卸载到客户端（Layer 2）。

1. 链上验证（智能合约）

合约充当不可腐败的门卫。如果负载不遵守严格规则，交易将被回滚。

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.24;

import "@openzeppelin/contracts-upgradeable/proxy/utils/Initializable.sol";
import "@openzeppelin/contracts-upgradeable/proxy/utils/UUPSUpgradeable.sol";
import "@openzeppelin/contracts-upgradeable/access/OwnableUpgradeable.sol";

contract Axiom is Initializable, UUPSUpgradeable, OwnableUpgradeable {
    uint256 public entryFee;
    mapping(address => uint8) public walletPath; // 0=New, 1=PathA(Level1), 2=PathB(Level2/3)

    event AxiomPost(address indexed sender, uint8 level, bytes iv, bytes cbor, uint256 timestamp);

    /// @custom:oz-upgrades-unsafe-allow constructor
    constructor() {
        _disableInitializers();
    }

    function initialize() initializer public {
        __Ownable_init(msg.sender);
        entryFee = 0.0001 ether;
    }

    function _authorizeUpgrade(address newImplementation) internal override onlyOwner {}

    function publishAxiom(
        uint8 _level,
        bytes calldata _iv,
        bytes calldata _cbor
    ) external payable {
        require(_level >= 1 && _level <= 3, "Invalid level");

        uint8 requiredPath = (_level == 1) ? 1 : 2;
        uint8 currentPath = walletPath[msg.sender];

        if (currentPath == 0) {
            require(msg.value >= entryFee, "Anti-Sybil: Insufficient entry fee");
            walletPath[msg.sender] = requiredPath;
        } else {
            require(msg.value == 0, "Fee already paid");
            require(currentPath == requiredPath, "OPSEC Violation: Wallet is tainted");
        }

        if (_level == 3) {
            require(_iv.length == 12, "Level 3 strictly requires a 12-byte IV");
        } else {
            require(_iv.length == 0, "Level 1 and 2 require strictly empty IV");
        }

        emit AxiomPost(msg.sender, _level, _iv, _cbor, block.timestamp);
    }

    function withdraw() external onlyOwner {
        payable(owner()).transfer(address(this).balance);
    }
}

• 双向钱包污染（强制隔离）： 如果钱包首次在级别 1 发帖，则被永久禁止使用级别 2/3。如果先在级别 2 或 3 发帖，则级别 1 被禁止。
• 必需参数： 对于级别 3，合约严格强制要求 12 字节的 IV。

2. 链下验证（由客户端执行）

如果某条帖子违反协议规则，客户端必须静默丢弃它（本地丢弃）。

• 级别 2 链接拦截器： 客户端扫描级别 2 消息的明文 (c)。如果检测到 URL、IP 地址或典型的媒体标签，该帖子将被完全屏蔽。
• 自我清理： 如果攻击者在级别 2 用链接进行垃圾消息攻击，他们将支付 Gas 费用，但任何有效的 Axiom 客户端都不会渲染这些消息。

---

基础设施与推荐客户端架构

Axiom 部署在以太坊 Layer 2（L2）网络上（例如 Arbitrum Nova）。

为了避免使移动设备过载（电池寿命、存储限制、Argon2id 的 WebAssembly 限制），Axiom 强制采用高性能的客户端架构：

• Axiom Core（自托管节点）： 一个服务器/Docker 容器（例如在 NAS 上运行），通过 RPC 读取区块链、索引事件，并原生执行资源密集型加密操作。
• Axiom UI（瘦客户端）： 一款移动应用或 Web UI，仅通过 API 与用户自己的 Axiom Core 通信。

数据检索与 EIP-4444

客户端不会下载整个区块链状态。它们会过滤智能合约的 AxiomPost 事件，该事件包含所有必要数据（发送者、级别、IV、CBOR、时间戳）。

由于根据 EIP-4444，以太坊节点最终会丢弃历史数据（超过 365 天的事件），协议建议本地 Axiom Core 作为去中心化归档，永久存储数据库。

---

示例工作流：级别 3 的帖子

为了说明该架构在实际中的运作方式，这里提供一个完整的生命周期演练。

场景： Alice 想在子频道 "AxiomDev" 中发布消息 "Meeting at 8 PM"。该群组此前在离线状态下商定了密码 "Secret123"。

步骤 1：本地准备与加密（Axiom Core）

Alice 的 Axiom Core 负责处理计算密集型任务：

1. 密钥派生： 它使用 Argon2id 将密码转换为 256 位的 AES 密钥。
2. IV 生成： 生成一个随机的 12 字节初始化向量（例如 0x12ab34cd56ef789012ab34cd）。
3. 加密： 使用 AES-GCM 加密内容和标签 ("AxiomDev")。
4. 提示生成： 计算用于模糊分桶的 2 字节 HMAC 哈希值（m: "0xa1b2"）。

步骤 2：负载构建（CBOR 序列化）

由于级别和 IV 直接传递给合约，因此它们被排除在 CBOR 对象之外。

内部 JSON 表示：

{
  "t": 1,
  "c": "0x8a4f...",
  "h": ["0x9b5e..."],
  "m": "0xa1b2"
}

此 JSON 被压缩为原始 CBOR 字节数组（0xa3617401...）以节省 Gas。

步骤 3：智能合约调用（区块链交互）

Alice 触发合约函数。重要提示：该调用严格通过 Tor 路由！

（级别 3 和级别 1 的示例：）

// 示例 1：客户端调用智能合约发布加密的级别 3 帖子
await axiomContract.publishAxiom(
    3,                                      // _level: 3
    "0x12ab34cd56ef789012ab34cd",           // _iv: 需要的 12 字节十六进制字符串
    "0xa3617401616358208a4f..."             // _cbor: 压缩后的 CBOR 十六进制字符串
);

// 示例 2：客户端调用智能合约发布公开的级别 1 帖子
await axiomContract.publishAxiom(
    1,                                      // _level: 1
    "0x",                                   // _iv: 严格空字节数组
    "0xa361740161634c48656c6c6f204178..."   // _cbor: 压缩后的 CBOR 十六进制字符串
);

智能合约随后发出事件：

事件：AxiomPost(发送者: 0xAlice..., 级别: 3, IV: 0x12ab..., CBOR: 0xa361..., 时间戳: 1710425890)

步骤 4：索引与试解密（接收方）

Bob 的 Axiom Core 正在监听区块链并收到该事件。