EIP-6493: SSZ 交易签名方案
用于原生 SSZ 交易的签名方案
Authors | Etan Kissling (@etan-status), Gajinder Singh (@g11tech), Matt Garnett (@lightclient), Vitalik Buterin (@vbuterin) |
---|---|
Created | 2023-02-24 |
Discussion Link | https://ethereum-magicians.org/t/eip-6493-ssz-transaction-signature-scheme/13050 |
Requires | EIP-6404, EIP-6466 |
摘要
本 EIP 定义了原生 Simple Serialize (SSZ) 编码交易的签名方案。
动机
EIP-6404 通过从 RLP 交易转换来引入 SSZ 交易。为原生 SSZ 交易定义签名方案进一步减少了所需的转换,并解锁了 SSZ StableContainer
的前向兼容性优势。
规范
本文档中的关键词“必须”,“禁止”,“需要”,“应该”,“不应该”,“推荐”,“不推荐”,“可以”和“可选”应按照 RFC 2119 和 RFC 8174 中的描述进行解释。
交易签名方案
原生 SSZ 交易基于 EIP-6404 中定义的 TransactionPayload
和 Transaction
类型,并发出 EIP-6466 Receipt
。为了区分原生 SSZ 交易与从 RLP 转换而来的交易,原生 SSZ 交易不会在其 TransactionPayload
中设置 RLP TransactionType
。
所有原生 SSZ 交易都遵循基于 hash_tree_root
的相同方案来计算它们的签名哈希 (sig_hash
) 和唯一标识符 (tx_hash
)。
附加信息被混合到 sig_hash
中,以唯一地标识底层规范并避免不同签名种类之间的哈希冲突。供应商定义的网络必须使用不同的 DomainType
来签署自定义交易类型。
名字 | 值 | 描述 |
---|---|---|
DOMAIN_TX_SSZ |
DomainType('0x00000080) |
用于签署与本 EIP 兼容的原生 SSZ 交易的 DomainType |
class ExecutionSigningData(Container):
object_root: Root
domain_type: DomainType
def compute_ssz_sig_hash(payload: TransactionPayload) -> Hash32:
return Hash32(ExecutionSigningData(
object_root=payload.hash_tree_root(),
domain=DOMAIN_TX_SSZ,
).hash_tree_root())
def compute_ssz_tx_hash(tx: Transaction) -> Hash32:
assert tx.payload.type_ is None
return Hash32(tx.hash_tree_root())
JSON-RPC
某些 JSON-RPC 端点(例如 eth_getTransactionByHash
)在 type
字段中指示相应的 EIP-2718 包络类型前缀。
当在这些端点上表示原生 SSZ 交易时,应该指示 SSZ_TX_TYPE
作为它们的 type
,如 EIP-6404 中所定义。 不建议省略 type
,因为某些客户端应用程序可能会将省略与无类型的 LegacyTransaction
混淆。
Transaction
配置文件
引入了新的 EIP-7495 Profile
定义来表示原生 SSZ 交易:
class BasicTransactionPayload(Profile[TransactionPayload]):
chain_id: ChainId
nonce: uint64
max_fees_per_gas: BasicFeesPerGas
gas: GasAmount
to: Optional[ExecutionAddress]
value: uint256
input_: ByteList[MAX_CALLDATA_SIZE]
access_list: List[AccessTuple, MAX_ACCESS_LIST_SIZE]
max_priority_fees_per_gas: BasicFeesPerGas
class BasicTransaction(Container):
payload: BasicTransactionPayload
signature: Secp256k1ExecutionSignature
class BlobTransactionPayload(Profile[TransactionPayload]):
chain_id: ChainId
nonce: uint64
max_fees_per_gas: BlobFeesPerGas
gas: GasAmount
to: ExecutionAddress
value: uint256
input_: ByteList[MAX_CALLDATA_SIZE]
access_list: List[AccessTuple, MAX_ACCESS_LIST_SIZE]
max_priority_fees_per_gas: BlobFeesPerGas
blob_versioned_hashes: List[VersionedHash, MAX_BLOB_COMMITMENTS_PER_BLOCK]
class BlobTransaction(Container):
payload: BlobTransactionPayload
signature: Secp256k1ExecutionSignature
更新 EIP-6404 中的 identify_transaction_profile
帮助程序以支持原生 SSZ 交易。
def identify_transaction_profile(tx: Transaction) -> Type[Profile]:
if tx.payload.type_ is None:
if tx.payload.blob_versioned_hashes is not None:
return BlobTransaction
return BasicTransaction
else:
if tx.payload.type_ == BLOB_TX_TYPE:
return RlpBlobTransaction
if tx.payload.type_ == FEE_MARKET_TX_TYPE:
return RlpFeeMarketTransaction
if tx.payload.type_ == ACCESS_LIST_TX_TYPE:
return RlpAccessListTransaction
if tx.payload.type_ == LEGACY_TX_TYPE:
return RlpLegacyTransaction
raise Exception(f'Unsupported transaction: {tx}')
理由
SSZ 签名方案减少了哈希开销,并确保 tx_hash
承诺在链上可用。 它还为未来的交易功能提供了灵活的基础。
向后兼容性
新的交易签名方案仅用于 SSZ 交易,并使用与现有 RLP 交易不同的 EIP-2718 包络类型前缀表示。
安全考虑
SSZ 签名不得与 RLP 交易和消息哈希冲突。
由于 RLP 消息使用 keccak256 进行哈希处理,而所有 SSZ 对象都使用 SHA256 进行哈希处理。 这两种哈希算法都被认为是密码学安全的,并且基于根本不同的方法,从而最大限度地降低了这两种哈希算法之间发生哈希冲突的风险。
此外,RLP 消息在其序列化过程中以线性方式进行哈希处理,而 SSZ 对象则使用递归 Merkle 树进行哈希处理。 具有不同的机制进一步降低了哈希冲突的风险。
版权
通过 CC0 放弃版权和相关权利。
Citation
Please cite this document as:
Etan Kissling (@etan-status), Gajinder Singh (@g11tech), Matt Garnett (@lightclient), Vitalik Buterin (@vbuterin), "EIP-6493: SSZ 交易签名方案 [DRAFT]," Ethereum Improvement Proposals, no. 6493, February 2023. [Online serial]. Available: https://eips.ethereum.org/EIPS/eip-6493.