项目概述与背景

Psy Protocol（前身为 QED Protocol）是一个无需信任、可水平扩展的 Layer-1 区块链和 ZK-Rollup 网络^{1, 2}。其核心使命是打破传统区块链的“串行处理监狱”，通过重新定义状态存储方式和计算发生地，为高频订单簿 DEX、全链游戏 and AI 代理经济等高并发 Web3 应用提供互联网级的吞吐量（TPS），同时继承比特币和狗狗币等 PoW 基础层的安全性^{2, 4, 5}。

Speculative Messaging — Minimal POC Implementation Design

Based on speculative-messaging-design.md.

This is the single source of truth for the minimal speculative-messaging POC on the current codebase, covering implementation design, end-to-end workflow, off-chain networking, and the follow-up roadmap.

Phase 1 scope — Inclusion-based messaging with Late Block Proofs. Removes message storage from relay chain state while keeping latency at ~6–12s (1–2 relay blocks for inclusion). This is the first implementation slice of the broader offchain-XCMP replacement direction — the conservative inclusion-based path of the general commitment-driven speculative messaging model.

Speculative Messaging

Design Document

Field	Value
Authors	eskimor
Status	Draft
Version	0.2
Related Designs	Low-Latency Parachains v2

---

Table of Contents

1. Introduction
2. Motivation
3. Goals
4. Non-Goals
5. Background
6. Solution Overview
7. Detailed Design
   • Message Accumulators
   • Provides Commitment
   • Requires Commitment
   • Relay Chain Matching
   • Late Block Proofs
   • Proof Size Considerations
   • Acknowledgement Extensions
   • Cycle Prevention
   • Super Chains
8. Trust Domains
9. Censorship Considerations
10. Comparison with Alternatives
11. Implementation Considerations
12. Security Analysis

---

Introduction

Speculative Messaging introduces a new cross-chain messaging mechanism for Polkadot that replaces HRMP with a more scalable, lower-latency alternative. By using cryptographic accumulators (such as Merkle Mountain Ranges) to commit to messages off-chain and having the relay chain enforce these commitments at inclusion time, we achieve:

Speculative Messaging is the companion design to Low-Latency Parachains v2. Its goal: replace HRMP (Horizontal Relay Message Passing) with a faster, more scalable cross-chain communication mechanism built on MMR accumulators, on-chain commitments, and off-chain message delivery.

Forum background: XCMP Design Discussion (Polkadot).

XCMP MMD - Design Document

Overview

XCMP MMD (Merkle Mountain Range based cross-chain messaging) is a proof-of-concept for trustless cross-chain message delivery between parachains. It uses a three-tier cryptographic proof system that leverages the relay chain’s BEEFY finality gadget and Merkle structures.

Problem Statement

HRMP (Horizontal Relay-routed Message Passing) stores message payloads on the relay chain, which is expensive in terms of storage and execution costs.

When building AI agents, the most successful implementations typically rely on simple, composable patterns rather than overly complex frameworks. Agentic systems generally fall into two categories: workflows, where LLMs and tools are orchestrated through predefined code paths, and agents, where LLMs dynamically direct their own processes and tool usage.

Project Overview & Background

Zcash is a decentralized protocol and privacy-protecting digital currency designed to function as encrypted electronic cash. It holds the distinction of being the first cryptocurrency to pioneer and implement zero-knowledge encryption specifically for private peer-to-peer payments. Its core mission is to protect users’ right to privacy through end-to-end encryption, ensuring that individuals retain full control over their funds without relying on traditional banks.

This post supplements Hyperbridge ISMP — state_root, overlay_root, and mmr_root with a consolidated “root map + workflow” view, new framing (trie vs MMR as state vs log, not a Substrate-vs-EVM split), and notes from reading pallet_state_coprocessor and Tesseract EVM messaging.

Repo context: polytope-labs/hyperbridge.

---

TL;DR (one paragraph)

Hyperbridge keeps two “views” of the same ISMP object, keyed by the same commitment hash:

• a compact ISMP child trie (Patricia / Substrate LayoutV0) for pallet state: commitment metadata, receipt bookkeeping, claim/fee data, and pointers into the offchain log
• an append-only message MMR (ordered log) for history + succinct inclusion proofs (and relayer/EVM batch verification)

The commitment hash of a request/response is not stored twice as separate unrelated facts: it is used as a key in the trie and as a member of the MMR log, but the stored payloads differ (trie = operational metadata; MMR = message log membership).

Notes mirrored from Hyperbridge - ISMP Storage Proofs & Substrate Child Trie (Obsidian). Repo context: polytope-labs/hyperbridge. Protocol docs: docs.hyperbridge.network.

When reading pallet-ismp and SubstrateStateMachine, three roots show up: the parachain state_root, the optional overlay_root on StateCommitment, and the mmr_root in the per-block ConsensusDigest. They are not interchangeable; each corresponds to a different data structure and proof type.

---

What each root is

Name	Role
state_root	Root of the chain’s main Substrate state trie (Header::state_root). It commits to all pallets. Child tries are still included under this trie.
mmr_root	Root of the ISMP MMR after the MMR pallet finalizes the block: an append-only tree over message leaves (full bodies stored off-chain). It appears in the header as part of ConsensusDigest, not as a separate top-level field on StateCommitment by itself.
overlay_root on StateCommitment	The ISMP overlay slot carried in consensus proofs. It is not a third independent trie type in the abstract—it is whatever the chain puts in that slot (see packing below).

Each block, on_finalize builds:

结论速记

• 关键不是“多 hash 一次更强”：keccak256(keccak256(...)) 的主要价值在于域分离（domain separation），让“叶子哈希”和“内部节点哈希”的构造形状不同，避免 Merkle 结构里的“角色混淆”讨论。
• 更标准：显式前缀（leaf/internal）通常比 ~hash 或双 keccak 更容易被审计/跨语言实现接受。
• 验证端必须逐字对齐：叶子公式、内部节点哈希顺序（是否排序）、稀疏缺失节点默认值（0）必须完全一致。

keccak256(keccak256(abi.encode(member, amount))) 是否足以避免 second preimage？

在 Merkle 语境里，大家常担心的不是去破 Keccak 的 preimage，而是：