以太坊 - SUAVE 链 - Flashbots

<!-- omit from toc -->

Suave 链

<div className="hide-in-docs">

目录

<!-- TOC -->

• 概览
• 配置
  • 网络参数
  • 创世设置
• 共识机制：权威证明（Clique）
  • Geth 版本
• Suave 交易
  • Suave 交易类型
• TransactionRequest 序列化 & 签名
• 节点要求和设置
• Gas 费用和交易费用
• 安全考虑

<!-- /TOC -->

概览

</div>

本文档概述了 SUAVE Rigil 链的规范。

在 SUAVE 协议的上下文中，SUAVE 链的主要目的是就智能合约代码达成（并保持）共识，用于诸如订单流拍卖、求解器、区块构建器等用例。此外，SUAVE 链还可以用于存储和广播数据，以获得更好的抗审查保证。

在开发的初始阶段，SUAVE 链通过一个许可节点网络运行一种名为 Clique 的权威证明共识协议。我们这样做是为了在协议开发期间快速试验和迭代。这将在后续的测试网中发生变化。

配置

网络参数

• 网络 ID: 16813125
• 链 ID: 16813125

创世设置

共识机制：权威证明（Clique）

Clique 是一种基于以太坊的权威证明共识协议，定义在此，它将区块的铸造限制在预定义的受信任签名者列表中。因此，客户端看到的每个区块头都可以根据受信任签名者的列表进行检查。

Geth 版本

Suave-geth 基于 geth v1.12.0 (e501b3)。

Suave 交易

SUAVE 协议向基础以太坊协议添加了一种新的交易类型，称为 SuaveTransaction。这种新的交易类型的目的是处理链下计算的费用，并支持与机密计算相关的新数据原语。

SUAVE 链上的区块由 SUAVE 交易列表组成。 这种新的交易类型促进并捕获了机密计算请求及其后续结果中涉及的关键信息。任何由用户签名的 ConfidentialComputeRequest，都指定了一个 KettleAddress。当且仅当 SUAVE 交易是由用户在原始 ConfidentialComputeRequest 中指定的 KettleAddress 签名时，该交易才有效，该请求包含在 ConfidentialComputeRecord 中。

type SuaveTransaction struct {
    ConfidentialComputeRequest ConfidentialComputeRecord
    ConfidentialComputeResult  []byte

    // Kettle 的签名
    ChainID *big.Int
    V       *big.Int
    R       *big.Int
    S       *big.Int
}

Suave 交易类型

SuaveTransaction 是主要的交易类型，当从 eth_getTransactionByHash 或 eth_getBlockByNumber 等端点请求交易时返回，但 SUAVE 引入了另外两个重要的消息类型：ConfidentialComputeRequest 和 ConfidentialComputeRecord。所有新的类型都在下表中详细说明：

TransactionRequest 序列化 & 签名

SUAVE 用户发送的消息可以采用两种形式：

1. 标准（旧版）以太坊交易
2. ConfidentialComputeRequest

标准交易用于转移 SUAVE-ETH 并将智能合约部署到 SUAVE 链。 ConfidentialComputeRequest 是一种新的 EIP-2718 消息类型，用于与 SUAVE 智能合约交互。请注意，“ConfidentialComputeRequests”不被归类为“交易”，因为“交易”意味着对数据库/区块链状态的更改。 Kettles 不提供持久存储保证，而是旨在将输入转换为输出（如针对区块链的交易）。

所有交易均使用 EIP-2718 RLP 编码方案进行编码（允许使用 EIP-2930），但 ConfidentialComputeRequest 采用一种特殊的签名方案，该方案略微偏离了传统方法。

ConfidentialComputeRequests 采用这种独特的签名方案，以使 confidentialInputs 保持在链下。ConfidentialComputeRecord（由发送者签名）仅包含 confidentialInputs 的 哈希。此记录存储在 SUAVE 链上，从而可以在不暴露链上实际数据的情况下验证 confidentialInputs。

在 javascript 中，ConfidentialComputeRequest 具有以下结构：

const cRequest = {
  confidentialInputs: '0x000000000000000000000000000000000000000000000000000000000000002000000000000000000000000000000000000000000000000000000000000000fd7b22626c6f636b4e756d626572223a22307830222c22747873223a5b2230786638363538303064383235323038393461646263653931303332643333396338336463653834316336346566643261393232383165653664383230336538383038343032303131386164613038376337386234353663653762343234386237313565353164326465656236343031363032343832333735663130663037396663666637373934383830653731613035373366336364343133396437323037643165316235623263323365353438623061316361336533373034343739656334653939316362356130623661323930225d2c2270657263656e74223a31307d000000',
  kettleAddress: '0xb5feafbdd752ad52afb7e1bd2e40432a485bbb7f',
  to: '0x8f21Fdd6B4f4CacD33151777A46c122797c8BF17',
  gasPrice: 10000000000n,
  gas: 420000n,
  type: '0x43',
  chainId: 16813125,
  data: '0x236eb5a70000000000000000000000000000000000000000000000000000000000000002000000000000000000000000000000000000000000000000000000000000006000000000000000000000000000000000000000000000000000000000000000a000000000000000000000000000000000000000000000000000000000000000010000000000000000000000008f21fdd6b4f4cacd33151777a46c122797c8bf170000000000000000000000000000000000000000000000000000000000000000',
  }

注意：新字段：confidentialInputs 和 kettleAddress。

为了序列化、签名和发送此请求，客户端必须首先将请求 RLP 编码为 ConfidentialComputeRecord 并签署其哈希。

注意：以下是伪代码。rlp、keccak256 和 wallet.sign 的实现可能有所不同。

const {
  nonce,
  gasPrice,
  gas,
  to,
  value,
  data,
  kettleAddress,
  confidentialInputs,
  chainId,
} = cRequest
const rlpRecord = rlp('0x42', [
    kettleAddress,
    keccak256(confidentialInputs),
    nonce,
    gasPrice,
    gas,
    to,
    value,
    data,
  ])
const {v, r, s} = wallet.sign(keccak256(rlpRecord))
cRecord = {...cRecord, v, r, s}

然后，使用 RLP 重新编码最终请求，如下所示：

// 假设 (v, r, s) 已添加到 cRecord
const tx = rlp('0x43', [
    cRecord.nonce,
    cRecord.gasPrice,
    cRecord.gas,
    cRecord.to,
    cRecord.value,
    cRecord.data,
    cRecord.kettleAddress,
    keccak256(cRequest.confidentialInputs),
    cRecord.chainId,
    cRecord.v === 27n ? '0x' : '0x1', // yParity
    cRecord.r,
    cRecord.s,
  ],
  confidentialInputs
)

然后通过 eth_sendRawTransaction 将其发送到 SUAVE：

wallet.request('eth_sendRawTransaction', [tx])

节点要求和设置

• 硬件：
  • 最小 8GB 内存，四个核心，50GB 固态硬盘（我们预计链会增长多大？）
  • 这些要求最终将包含可信执行环境（TEE）。
• 软件：suave-geth
• 设置步骤：
  1. 克隆 suave-geth
  2. 启动 devnet：make devnet-up
  3. 创建交易：go run suave/devenv/cmd/main.go

Gas 费用和交易费用

SUAVE 链采用与以太坊 Cancun 硬分叉之前相同的 gas 定价机制（没有 blob 交易），其中 gas 价格根据网络需求进行调整。 节点当前跟踪机密计算请求 gas 的使用情况，但仅收取少量的固定费用，并且链下计算没有上限。

目前，SUAVE 交易只能表示为 Legacy 交易类型，但它们将在底层转换为 EIP-1559 基本费用模型。

安全考虑

• 安全风险：该协议未经审计。 该协议目前不保证网络中数据的机密性，除了尽最大努力。
• DoS 风险：节点尚未经过审查，并且在此早期阶段可能存在 DoS 向量。
• 安全密钥管理：在 Suave 上存储私钥是实验性的，应被认为是不安全的。

如果你在 SUAVE 中发现安全漏洞，请发送电子邮件至 security@flashbots.net。

• 原文链接： github.com/flashbots/sua...
• 登链社区 AI 助手，为大家转译优秀英文文章，如有翻译不通的地方，还请包涵～