midnight-transactions
Compare original and translation side by side
🇺🇸
Original
English🇨🇳
Translation
ChineseTransactions
交易
The Midnight node supports the standard Polkadot SDK transaction format, but default Substrate-style signed extrinsics are uncommon in practice. Midnight relies on a proof-based verification model tightly coupled with the Midnight Ledger.
Midnight节点支持标准的Polkadot SDK交易格式，但默认Substrate风格的签名外部交易在实际中并不常见。Midnight依赖与Midnight Ledger紧密结合的基于证明的验证模型。
Lifecycle overview
生命周期概述
mermaid
flowchart TB
Build["Build transaction + ZK proof<br/>(wallet / SDK)"]
Submit["Submit to node RPC / P2P"]
Pool["Transaction pool<br/>well-formedness check"]
Block["Included in block"]
Verify["Runtime verifies embedded proof"]
Execute["Execute state transition"]
Commit["Commit to trie + ledger commitment"]
Build --> Submit --> Pool
Pool -->|Valid structure| Block
Pool -->|Reject| Reject["Dropped from pool"]
Block --> Verify
Verify -->|Invalid proof| Fail["Transaction fails"]
Verify -->|Valid| Execute --> Commitmermaid
flowchart TB
Build["Build transaction + ZK proof<br/>(wallet / SDK)"]
Submit["Submit to node RPC / P2P"]
Pool["Transaction pool<br/>well-formedness check"]
Block["Included in block"]
Verify["Runtime verifies embedded proof"]
Execute["Execute state transition"]
Commit["Commit to trie + ledger commitment"]
Build --> Submit --> Pool
Pool -->|Valid structure| Block
Pool -->|Reject| Reject["Dropped from pool"]
Block --> Verify
Verify -->|Invalid proof| Fail["Transaction fails"]
Verify -->|Valid| Execute --> CommitProof-based model
基于证明的模型
Most Midnight transactions are unsigned and follow the Midnight Ledger format.
| Traditional chain | Midnight |
|---|---|
| Signature authorizes action | Cryptographic proof attests validity |
| Public signer identity | Sensitive data stays off-chain / in proof |
| Standard extrinsic format | Ledger-specific transaction envelope |
The proof lets the network validate state transitions without exposing sensitive data or raw signatures directly.
大多数Midnight交易是无签名的，且遵循Midnight Ledger格式。
| 传统区块链 | Midnight |
|---|---|
| 签名授权操作 | 密码学证明证明有效性 |
| 公开签名者身份 | 敏感数据保留在链下/证明中 |
| 标准外部交易格式 | 账本专属交易信封 |
该证明允许网络在不直接暴露敏感数据或原始签名的情况下验证状态转换。
Transaction types
交易类型
- Contract deployment
- Contract invocation (circuit calls)
- ZSwap asset transfers
- 合约部署
- 合约调用（电路调用）
- ZSwap资产转移
Processing stages
处理阶段
1. Submission
1. 提交
Client (wallet, SDK, dApp) submits a transaction to a node's RPC or propagates via P2P gossip.
客户端（钱包、SDK、去中心化应用）将交易提交至节点的RPC，或通过P2P gossip传播。
2. Transaction pool validation
2. 交易池验证
The pool checks well-formedness:
- Structural requirements per runtime and ledger specification
- Logical preconditions (format, size, basic validity)
- Not full proof verification yet (that happens at block execution)
mermaid
sequenceDiagram
participant Client
participant Pool as Tx pool
participant Block as Block author
participant RT as Runtime (pallet-midnight)
Client->>Pool: Submit unsigned proof tx
Pool->>Pool: Well-formedness validation
alt Invalid
Pool-->>Client: Reject
else Valid
Pool->>Block: Candidate for inclusion
Block->>RT: Execute in block
RT->>RT: Full proof verification
RT->>RT: State transition + commit
end交易池检查格式合规性：
- 符合运行时和账本规范的结构要求
- 逻辑前置条件（格式、大小、基本有效性）
- 尚未进行完整的证明验证（该步骤在区块执行时进行）
mermaid
sequenceDiagram
participant Client
participant Pool as Tx pool
participant Block as Block author
participant RT as Runtime (pallet-midnight)
Client->>Pool: Submit unsigned proof tx
Pool->>Pool: Well-formedness validation
alt Invalid
Pool-->>Client: Reject
else Valid
Pool->>Block: Candidate for inclusion
Block->>RT: Execute in block
RT->>RT: Full proof verification
RT->>RT: State transition + commit
end3. Block inclusion
3. 区块纳入
A block producer (AURA validator) includes the transaction in a new block.
区块生产者（AURA验证者）将交易纳入新区块。
4. Runtime verification and execution
4. 运行时验证与执行
pallet-midnight- Fully verifies the embedded cryptographic proof (native libraries).
- If valid, executes the corresponding state transition.
- Commits the updated state to on-chain storage.
pallet-midnight- 完整验证嵌入的密码学证明（原生库）。
- 若证明有效，则执行对应的状态转换。
- 将更新后的状态提交至链上存储。
5. Finality
5. 最终性
Block may be finalized asynchronously via GRANDPA after inclusion.
区块纳入后，可通过GRANDPA异步完成最终确认。
Comparison: pool vs runtime checks
对比：交易池与运行时检查
| Check | Where | What |
|---|---|---|
| Well-formedness | Transaction pool | Structure, basic validity |
| Proof verification | Runtime ( | Full cryptographic validation |
| State transition | Runtime | ZSwap / contract state update |
| Persistence | Storage layer | Trie + ledger commitment |
| 检查项 | 执行位置 | 检查内容 |
|---|---|---|
| 格式合规性 | 交易池 | 结构、基本有效性 |
| 证明验证 | 运行时（ | 完整密码学验证 |
| 状态转换 | 运行时 | ZSwap / 合约状态更新 |
| 持久化 | 存储层 | 前缀树 + 账本提交 |
Building and submitting txs (dApp context)
构建与提交交易（去中心化应用场景）
For application developers:
| Layer | Skill |
|---|---|
| Prove + submit txs | |
| Contract logic | |
| Read results | |
Node operators care about pool sizing, block limits, and RPC submission endpoints.
面向应用开发者：
| 层级 | 技能组件 |
|---|---|
| 生成证明 + 提交交易 | |
| 合约逻辑 | |
| 读取结果 | |
节点运营商关注交易池规模、区块限制以及RPC提交端点。
Related skills
相关技能组件
- —
midnight-onchain-logic/executionpallet-midnight - — how commits are persisted
midnight-storage/ - — who includes txs in blocks
midnight-consensus/ - — submission and state query endpoints
midnight-rpc/ - — what proofs attest to at the contract level
compact/
- —
midnight-onchain-logic/执行逻辑pallet-midnight - — 提交内容的持久化方式
midnight-storage/ - — 负责将交易纳入区块的角色
midnight-consensus/ - — 提交与状态查询端点
midnight-rpc/ - — 证明在合约层面所验证的内容
compact/