0x11-b Sentinel Hardening

🇺🇸 English    |    🇨🇳 中文

🇺🇸 English

1. Objectives

This phase addresses the critical gaps identified during Phase 0x11-a QA:

2. Deposit Flow Architecture

Important

🚨 Production Risk Control Requirements

Before crediting user balance on finalization, deposits SHOULD pass through:

1. Source Verification - Check if sender address is on sanctions/blacklist
2. Amount Thresholds - Large deposits may require enhanced verification
3. Pattern Analysis - Detect unusual deposit patterns (structuring, layering)
4. AML Compliance - Regulatory reporting for threshold amounts
5. Address Attribution - Verify expected vs actual funding sources

The current implementation credits balance automatically on finalization.

2.1 Overview

┌─────────────────────────────────────────────────────────────────────────────┐
│                           Sentinel Deposit Flow                             │
├─────────────────────────────────────────────────────────────────────────────┤
│                                                                             │
│  ┌──────────┐    ┌──────────────┐    ┌────────────────┐    ┌─────────────┐ │
│  │ BTC/ETH  │───▶│ ChainScanner │───▶│ Confirmation   │───▶│ Deposit     │ │
│  │  Node    │    │              │    │    Monitor     │    │  Pipeline   │ │
│  └──────────┘    └──────────────┘    └────────────────┘    └─────────────┘ │
│       ▲                 │                    │                    │        │
│       │                 ▼                    ▼                    ▼        │
│       │          ┌─────────────┐      ┌───────────┐      ┌─────────────┐   │
│       │          │ ScannedBlock│      │ deposit_  │      │ balances_tb │   │
│       │          │ + Deposits  │      │ history   │      │ (Balance)   │   │
│       │          └─────────────┘      └───────────┘      └─────────────┘   │
│       │                                    DB                   DB         │
└───────┴─────────────────────────────────────────────────────────────────────┘

2.2 State Machine

DETECTED ──▶ CONFIRMING ──▶ FINALIZED ──▶ SUCCESS
              │                              │
              └───────── ORPHANED ◀──────────┘
                      (Re-org detected)

2.3 Key Components

2.4 Database Schema

deposit_history (Deposit Records):

tx_hash       VARCHAR PRIMARY KEY  -- Transaction hash
user_id       BIGINT               -- User ID
asset         VARCHAR              -- Asset (BTC/ETH)
amount        DECIMAL              -- Amount
chain_id      VARCHAR              -- Chain ID
block_height  BIGINT               -- Block height
block_hash    VARCHAR              -- Block hash (for re-org detection)
status        VARCHAR              -- Status (see state machine)
confirmations INT                  -- Current confirmation count

3. Withdraw Flow Architecture

Caution

⛔ Production Risk Control Requirements ⛔

The current implementation is for MVP/Testing only. Before production deployment, withdrawals MUST pass through:

1. Comprehensive Risk Engine - Real-time fraud detection, velocity limits, address blacklist
2. Manual Review - Large amounts require human approval
3. Multi-signature Approval - Hot wallet threshold triggers cold wallet multi-sig
4. AML/KYC Verification - Regulatory compliance checks
5. Delay Mechanism - Suspicious transactions held for review period

Never deploy the current auto-approval flow to production!

3.1 Overview

┌─────────────────────────────────────────────────────────────────────────────┐
│                         Withdraw Flow (Push Model)                          │
├─────────────────────────────────────────────────────────────────────────────┤
│                                                                             │
│  ┌──────────┐    ┌──────────────┐    ┌────────────────┐    ┌─────────────┐ │
│  │   User   │───▶│ WithdrawServ │───▶│   Balance      │───▶│   Chain     │ │
│  │  Request │    │     ice      │    │    Deduct      │    │  Broadcast  │ │
│  └──────────┘    └──────────────┘    └────────────────┘    └─────────────┘ │
│       │                 │                    │                    │        │
│       │                 ▼                    ▼                    ▼        │
│       │          ┌─────────────┐      ┌───────────┐      ┌─────────────┐   │
│       │          │  Validate   │      │ withdraw_ │      │   TX Hash   │   │
│       │          │  Address    │      │  history  │      │   or Fail   │   │
│       │          └─────────────┘      └───────────┘      └─────────────┘   │
│       │                                    DB                   ▼          │
│       │                              ┌─────────────────────────────────┐   │
│       │                              │ On Fail: AUTO REFUND to balance │   │
│       │                              └─────────────────────────────────┘   │
└───────┴─────────────────────────────────────────────────────────────────────┘

3.2 Flow Steps

1. Validate Request
   └─▶ Address format ✓, Amount > 0 ✓

2. Lock & Check Balance (FOR UPDATE)
   └─▶ available >= amount ? Continue : Error

3. Deduct Balance (Immediate)
   └─▶ available -= amount

4. Create Record (PROCESSING)
   └─▶ INSERT INTO withdraw_history

5. COMMIT Transaction
   └─▶ Balance deducted, record created

6. Broadcast to Chain
   ├─▶ Success: UPDATE status = 'SUCCESS', tx_hash = ?
   └─▶ Failure: AUTO REFUND + status = 'FAILED'

3.3 State Machine

           ┌──────────────┐
           │  PROCESSING  │
           └──────┬───────┘
                  │
      ┌───────────┼───────────┐
      ▼                       ▼
┌──────────┐           ┌──────────┐
│  SUCCESS │           │  FAILED  │
│  (✅ TX) │           │(Refunded)│
└──────────┘           └──────────┘

3.4 Key Components

3.5 Database Schema

withdraw_history (Withdraw Records):

request_id    VARCHAR PRIMARY KEY  -- Request UUID
user_id       BIGINT               -- User ID
asset         VARCHAR              -- Asset (BTC/ETH)
amount        BIGINT               -- Amount (scaled integer)
fee           BIGINT               -- Network fee (scaled integer)
to_address    VARCHAR              -- Destination address
status        VARCHAR              -- PROCESSING/SUCCESS/FAILED
tx_hash       VARCHAR              -- Blockchain TX hash (on success)
created_at    TIMESTAMP            -- Created time
updated_at    TIMESTAMP            -- Updated time

3.6 Amount Calculation

User Balance Delta = -Request Amount
Network Receive    = Request Amount - Fee

Example:

• User requests withdraw 1.0 BTC with 0.0001 BTC fee
• Balance deducted: 1.0 BTC
• Network receives: 0.9999 BTC

4. 🛡️ Tiered Risk Control Framework (Defense in Depth)

4.1 Defense Layers

┌─────────────────────────────────────────────────────────────────────────────┐
│                       Defense in Depth Architecture                         │
├─────────────────────────────────────────────────────────────────────────────┤
│                                                                             │
│  Layer 1: 🟢 AUTOMATED                                                      │
│  ├─▶ Address blacklist/sanctions check                                      │
│  ├─▶ Velocity limits (per hour/day/week)                                    │
│  └─▶ Basic fraud pattern detection                                          │
│                                                                             │
│  Layer 2: 🟡 THRESHOLD-BASED                                                │
│  ├─▶ Amount > $1K: Enhanced verification                                    │
│  ├─▶ Amount > $10K: 24-hour delay + notification                            │
│  └─▶ Amount > $50K: Requires Layer 3                                        │
│                                                                             │
│  Layer 3: 🔴 MANUAL REVIEW                                                  │
│  ├─▶ Human analyst verification                                             │
│  ├─▶ Source of funds documentation                                          │
│  └─▶ Multi-party approval (2-of-3)                                          │
│                                                                             │
│  Layer 4: ⚫ COLD WALLET MULTI-SIG                                          │
│  ├─▶ Amount > $100K: Cold wallet release                                    │
│  ├─▶ Hardware key requirement                                               │
│  └─▶ Geographic distribution of signers                                     │
│                                                                             │
└─────────────────────────────────────────────────────────────────────────────┘

4.2 Risk Tiers by Amount

4.3 Automated Checks (All Tiers)

4.4 Deposit-Specific Checks

┌────────────────────────────────────────────────────────────────┐
│                    Deposit Risk Assessment                      │
├────────────────────────────────────────────────────────────────┤
│ ✓ Source address attribution (known exchange? mixer? unknown?) │
│ ✓ Transaction graph analysis (1-hop, 2-hop connections)        │
│ ✓ Timing pattern (structuring detection)                       │
│ ✓ Historical behavior baseline                                  │
│ ✓ Cross-chain correlation (same entity on ETH/BTC?)            │
└────────────────────────────────────────────────────────────────┘

4.5 Withdraw-Specific Checks

┌────────────────────────────────────────────────────────────────┐
│                   Withdraw Risk Assessment                      │
├────────────────────────────────────────────────────────────────┤
│ ✓ Destination address reputation                                │
│ ✓ First-time address penalty                                    │
│ ✓ Account age vs amount ratio                                   │
│ ✓ Recent password/2FA changes (48h cooldown)                   │
│ ✓ Device fingerprint verification                               │
│ ✓ API key usage pattern                                         │
└────────────────────────────────────────────────────────────────┘

5. Problem Analysis: DEF-002 (BTC SegWit Blindness)

5.1 Root Cause

The extract_address function in src/sentinel/btc.rs uses Address::from_script(script, network).

While the rust-bitcoin crate should support P2WPKH scripts (OP_0 <20-byte-hash>), the current implementation may fail due to:

1. Network mismatch between the script encoding and the Network enum passed.
2. Missing feature flags in the bitcoincore-rpc dependency.

5.2 Solution

1. Verify: Add unit test with raw P2WPKH script construction.
2. Fix: If Address::from_script fails, manually detect witness v0 scripts:

   #![allow(unused)]
   fn main() {
   if script.is_p2wpkh() {
       // Extract 20-byte hash from script[2..22]
       // Construct Address::p2wpkh(...)
   }
   }

6. Feature Specification: ETH/ERC20 Sentinel

6.1 Architecture

┌─────────────────────────────────────────────────────────────────┐
│                       EthScanner                                │
├─────────────────────────────────────────────────────────────────┤
│ 1. Poll eth_blockNumber (Tip Tracking)                          │
│ 2. eth_getLogs(fromBlock, toBlock, topics=[Transfer])           │
│ 3. Filter: Match log.address (Contract) + topic[2] (To)         │
│ 4. Parse: Decode log.data as uint256 amount                     │
│ 5. Emit: DetectedDeposit { tx_hash, to_address, amount, ... }   │
└─────────────────────────────────────────────────────────────────┘

6.2 Key Implementation Details

• Topic0 (Transfer): keccak256("Transfer(address,address,uint256)") = 0xddf252ad...
• Topic1: Sender (indexed)
• Topic2: Recipient (indexed) - Match against user_addresses
• Data: Amount (uint256, left-padded)

6.3 Precision Handling

Important

Token decimals MUST be loaded from assets_tb, not hardcoded.

7. Database Schema Extensions

-- EthScanner requires contract address tracking
ALTER TABLE assets_tb
ADD COLUMN contract_address VARCHAR(42); -- e.g., '0xdAC17F958D2ee523a2206206994597C13D831ec7'

-- Index for fast lookup by contract
CREATE INDEX idx_assets_contract ON assets_tb(contract_address);

8. Configuration: config/sentinel.yaml

eth:
  chain_id: "ETH"
  network: "anvil"  # or "mainnet", "goerli"
  rpc:
    url: "http://127.0.0.1:8545"
  scanning:
    required_confirmations: 12
    max_reorg_depth: 20
    start_height: 0
  contracts:
    - name: "USDT"
      address: "0x..."
      decimals: 6
    - name: "USDC"
      address: "0x..."
      decimals: 6

9. Acceptance Criteria

• BTC: Unit test test_p2wpkh_extraction passes. ✅ (test_segwit_p2wpkh_extraction_def_002)
• BTC: E2E deposit to bcrt1... address is detected and credited. ✅ (Verified via greybox test)
• ETH: Unit test test_erc20_transfer_parsing passes. ✅ (7 ETH tests pass)
• ETH: E2E deposit via MockUSDT contract is detected. ⏳ (Pending: ERC20 eth_getLogs not yet implemented)
• Regression: All existing Phase 0x11-a tests still pass. ✅ (322 tests)

10. Implementation Status

11. Testing Instructions

Quick Test (Rust Unit Tests)

# Run all Sentinel tests
cargo test --package zero_x_infinity --lib sentinel -- --nocapture

# Run DEF-002 verification test only
cargo test test_segwit_p2wpkh_extraction_def_002 -- --nocapture

# Run ETH Scanner tests only
cargo test sentinel::eth -- --nocapture

Full Test Suite

# Run test script (no nodes required)
./scripts/tests/0x11b_sentinel/run_tests.sh

# Run with node startup (requires docker-compose)
./scripts/tests/0x11b_sentinel/run_tests.sh --with-nodes

🇨🇳 中文

1. 目标

本阶段解决 Phase 0x11-a QA 中识别的关键缺陷:

2. 充值流程架构

Important

🚨 生产环境风控要求

在确认完成后为用户入账之前，充值 应该 经过:

1. 来源验证 - 检查发送地址是否在制裁/黑名单上
2. 金额阈值 - 大额充值可能需要加强验证
3. 模式分析 - 检测异常充值模式 (拆分、分层)
4. AML 合规 - 超过阈值金额的监管报告
5. 地址归属 - 验证预期 vs 实际资金来源

当前实现在确认完成后自动入账。

2.1 概览

┌─────────────────────────────────────────────────────────────────────────────┐
│                           Sentinel 充值流程                                  │
├─────────────────────────────────────────────────────────────────────────────┤
│                                                                             │
│  ┌──────────┐    ┌──────────────┐    ┌────────────────┐    ┌─────────────┐ │
│  │ BTC/ETH  │───▶│ ChainScanner │───▶│ Confirmation   │───▶│ Deposit     │ │
│  │   节点   │    │  区块扫描器  │    │    Monitor     │    │  Pipeline   │ │
│  └──────────┘    └──────────────┘    └────────────────┘    └─────────────┘ │
│       ▲                 │                    │                    │        │
│       │                 ▼                    ▼                    ▼        │
│       │          ┌─────────────┐      ┌───────────┐      ┌─────────────┐   │
│       │          │ ScannedBlock│      │ deposit_  │      │ balances_tb │   │
│       │          │  扫描区块   │      │  history  │      │   余额表    │   │
│       │          └─────────────┘      └───────────┘      └─────────────┘   │
│       │                                   数据库                数据库      │
└───────┴─────────────────────────────────────────────────────────────────────┘

2.2 状态机

DETECTED ──▶ CONFIRMING ──▶ FINALIZED ──▶ SUCCESS
    已检测       确认中          已完成       成功
              │                              │
              └───────── ORPHANED ◀──────────┘
                        已孤立 (区块重组)

2.3 关键组件

2.4 数据库结构

deposit_history (充值记录表):

tx_hash       VARCHAR PRIMARY KEY  -- 交易哈希
user_id       BIGINT               -- 用户 ID
asset         VARCHAR              -- 资产 (BTC/ETH)
amount        DECIMAL              -- 金额
chain_id      VARCHAR              -- 链 ID
block_height  BIGINT               -- 区块高度
block_hash    VARCHAR              -- 区块哈希 (用于重组检测)
status        VARCHAR              -- 状态 (见状态机)
confirmations INT                  -- 当前确认数

3. 提现流程架构

Caution

⛔ 生产环境风控要求 ⛔

当前实现仅用于 MVP/测试。生产部署前，提现请求 必须 经过:

1. 完整风控引擎 - 实时欺诈检测、频率限制、地址黑名单
2. 人工审核 - 大额提现需人工批准
3. 多签审批 - 热钱包阈值触发冷钱包多签
4. AML/KYC 验证 - 合规性检查
5. 延迟机制 - 可疑交易进入审核等待期

绝对不要将当前自动审批流程部署到生产环境！

3.1 概览

┌─────────────────────────────────────────────────────────────────────────────┐
│                         提现流程 (推送模式)                                  │
├─────────────────────────────────────────────────────────────────────────────┤
│                                                                             │
│  ┌──────────┐    ┌──────────────┐    ┌────────────────┐    ┌─────────────┐ │
│  │   用户   │───▶│ WithdrawServ │───▶│   余额扣减     │───▶│   链上广播  │ │
│  │   请求   │    │   提现服务   │    │   (立即)       │    │             │ │
│  └──────────┘    └──────────────┘    └────────────────┘    └─────────────┘ │
│       │                 │                    │                    │        │
│       │                 ▼                    ▼                    ▼        │
│       │          ┌─────────────┐      ┌───────────┐      ┌─────────────┐   │
│       │          │   地址验证  │      │ withdraw_ │      │ TX Hash 或  │   │
│       │          │             │      │  history  │      │   失败      │   │
│       │          └─────────────┘      └───────────┘      └─────────────┘   │
│       │                                   数据库                 ▼         │
│       │                              ┌─────────────────────────────────┐   │
│       │                              │ 失败时: 自动退款到余额          │   │
│       │                              └─────────────────────────────────┘   │
└───────┴─────────────────────────────────────────────────────────────────────┘

3.2 流程步骤

1. 验证请求
   └─▶ 地址格式 ✓, 金额 > 0 ✓

2. 锁定并检查余额 (FOR UPDATE)
   └─▶ 可用余额 >= 金额 ? 继续 : 错误

3. 扣减余额 (立即)
   └─▶ 可用余额 -= 金额

4. 创建记录 (PROCESSING)
   └─▶ INSERT INTO withdraw_history

5. 提交事务
   └─▶ 余额已扣减，记录已创建

6. 广播到链
   ├─▶ 成功: UPDATE status = 'SUCCESS', tx_hash = ?
   └─▶ 失败: 自动退款 + status = 'FAILED'

3.3 状态机

           ┌──────────────┐
           │  PROCESSING  │
           │    处理中    │
           └──────┬───────┘
                  │
      ┌───────────┼───────────┐
      ▼                       ▼
┌──────────┐           ┌──────────┐
│  SUCCESS │           │  FAILED  │
│   成功   │           │  失败    │
│  (✅ TX) │           │(已退款)  │
└──────────┘           └──────────┘

3.4 关键组件

3.5 数据库结构

withdraw_history (提现记录表):

request_id    VARCHAR PRIMARY KEY  -- 请求 UUID
user_id       BIGINT               -- 用户 ID
asset         VARCHAR              -- 资产 (BTC/ETH)
amount        BIGINT               -- 金额 (整数缩放)
fee           BIGINT               -- 网络手续费 (整数缩放)
to_address    VARCHAR              -- 目标地址
status        VARCHAR              -- PROCESSING/SUCCESS/FAILED
tx_hash       VARCHAR              -- 区块链交易哈希 (成功时)
created_at    TIMESTAMP            -- 创建时间
updated_at    TIMESTAMP            -- 更新时间

3.6 金额计算

用户余额变化 = -请求金额
链上到账金额 = 请求金额 - 手续费

示例:

• 用户请求提现 1.0 BTC，手续费 0.0001 BTC
• 余额扣减: 1.0 BTC
• 链上到账: 0.9999 BTC

4. 🛡️ 分级纵深防御风控框架

4.1 防御层级

┌─────────────────────────────────────────────────────────────────────────────┐
│                          纵深防御架构                                        │
├─────────────────────────────────────────────────────────────────────────────┤
│                                                                             │
│  第一层: 🟢 自动化检查                                                       │
│  ├─▶ 地址黑名单/制裁名单检查                                                 │
│  ├─▶ 频率限制 (每小时/每天/每周)                                              │
│  └─▶ 基础欺诈模式检测                                                        │
│                                                                             │
│  第二层: 🟡 阈值触发                                                         │
│  ├─▶ 金额 > ¥7K: 加强验证                                                    │
│  ├─▶ 金额 > ¥70K: 24小时延迟 + 通知                                          │
│  └─▶ 金额 > ¥350K: 进入第三层                                                │
│                                                                             │
│  第三层: 🔴 人工审核                                                         │
│  ├─▶ 人工分析师验证                                                          │
│  ├─▶ 资金来源证明文件                                                        │
│  └─▶ 多方审批 (2-of-3)                                                       │
│                                                                             │
│  第四层: ⚫ 冷钱包多签                                                        │
│  ├─▶ 金额 > ¥700K: 冷钱包释放                                                │
│  ├─▶ 硬件密钥要求                                                            │
│  └─▶ 签名者地理分布                                                          │
│                                                                             │
└─────────────────────────────────────────────────────────────────────────────┘

4.2 风险分级 (按金额)

4.3 自动化检查 (所有层级)

4.4 充值专项检查

┌────────────────────────────────────────────────────────────────┐
│                       充值风险评估                              │
├────────────────────────────────────────────────────────────────┤
│ ✓ 来源地址归属 (已知交易所? 混币器? 未知?)                      │
│ ✓ 交易图谱分析 (1跳、2跳关联)                                   │
│ ✓ 时序模式 (拆分检测)                                          │
│ ✓ 历史行为基线                                                  │
│ ✓ 跨链关联 (同一实体在 ETH/BTC?)                                │
└────────────────────────────────────────────────────────────────┘

4.5 提现专项检查

┌────────────────────────────────────────────────────────────────┐
│                       提现风险评估                              │
├────────────────────────────────────────────────────────────────┤
│ ✓ 目标地址信誉                                                  │
│ ✓ 首次使用地址惩罚                                              │
│ ✓ 账户年龄 vs 金额比率                                          │
│ ✓ 近期密码/2FA变更 (48h冷却)                                    │
│ ✓ 设备指纹验证                                                  │
│ ✓ API密钥使用模式                                               │
└────────────────────────────────────────────────────────────────┘

5. 问题分析: DEF-002 (BTC SegWit 盲区)

5.1 根因

src/sentinel/btc.rs 中的 extract_address 函数使用 Address::from_script(script, network)。

虽然 rust-bitcoin 库 理论上 支持 P2WPKH 脚本 (OP_0 <20-byte-hash>)，但当前实现可能因以下原因失败:

1. 脚本编码与传入的 Network 枚举不匹配。
2. bitcoincore-rpc 依赖缺少必要的 feature flags。

5.2 解决方案

1. 验证: 添加单元测试，手动构造原始 P2WPKH 脚本。
2. 修复: 如果 Address::from_script 失败，手动检测 witness v0 脚本:

   #![allow(unused)]
   fn main() {
   if script.is_p2wpkh() {
       // 从 script[2..22] 提取 20 字节哈希
       // 构造 Address::p2wpkh(...)
   }
   }

6. 功能规格: ETH/ERC20 哨兵

6.1 架构

┌─────────────────────────────────────────────────────────────────┐
│                       EthScanner                                │
├─────────────────────────────────────────────────────────────────┤
│ 1. 轮询 eth_blockNumber (区块高度追踪)                           │
│ 2. eth_getLogs(fromBlock, toBlock, topics=[Transfer])           │
│ 3. 过滤: 匹配 log.address (合约) + topic[2] (收款人)             │
│ 4. 解析: 将 log.data 解码为 uint256 金额                         │
│ 5. 产出: DetectedDeposit { tx_hash, to_address, amount, ... }   │
└─────────────────────────────────────────────────────────────────┘

6.2 关键实现细节

• Topic0 (Transfer): keccak256("Transfer(address,address,uint256)") = 0xddf252ad...
• Topic1: 发送方 (indexed)
• Topic2: 接收方 (indexed) - 与 user_addresses 匹配
• Data: 金额 (uint256, 左填充)

6.3 精度处理

Important

代币精度 必须 从 assets_tb 加载，禁止硬编码。

7. 数据库模式扩展

-- EthScanner 需要追踪合约地址
ALTER TABLE assets_tb
ADD COLUMN contract_address VARCHAR(42); -- 例: '0xdAC17F958D2ee523a2206206994597C13D831ec7'

-- 按合约快速查询的索引
CREATE INDEX idx_assets_contract ON assets_tb(contract_address);

8. 配置: config/sentinel.yaml

eth:
  chain_id: "ETH"
  network: "anvil"  # 或 "mainnet", "goerli"
  rpc:
    url: "http://127.0.0.1:8545"
  scanning:
    required_confirmations: 12
    max_reorg_depth: 20
    start_height: 0
  contracts:
    - name: "USDT"
      address: "0x..."
      decimals: 6
    - name: "USDC"
      address: "0x..."
      decimals: 6

9. 验收标准

• BTC: 单元测试 test_p2wpkh_extraction 通过。 ✅ (test_segwit_p2wpkh_extraction_def_002)
• BTC: E2E 测试中充值到 bcrt1... 地址被检测并入账。 ✅ (通过 greybox 测试验证)
• ETH: 单元测试 test_erc20_transfer_parsing 通过。 ✅ (7 个 ETH 测试通过)
• ETH: E2E 测试中通过 MockUSDT 合约充值被检测。 ⏳ (待完成: ERC20 eth_getLogs 尚未实现)
• 回归: 所有 Phase 0x11-a 现有测试仍然通过。 ✅ (322 个测试)

10. 实施状态

11. 测试方法

快速测试 (Rust 单元测试)

# 运行所有 Sentinel 测试
cargo test --package zero_x_infinity --lib sentinel -- --nocapture

# 仅运行 DEF-002 验证测试
cargo test test_segwit_p2wpkh_extraction_def_002 -- --nocapture

# 仅运行 ETH Scanner 测试
cargo test sentinel::eth -- --nocapture

完整测试套件

# 运行测试脚本 (无需节点)
./scripts/tests/0x11b_sentinel/run_tests.sh

# 运行测试脚本 (自动启动节点, 需要 docker-compose)
./scripts/tests/0x11b_sentinel/run_tests.sh --with-nodes

Appendix A: Industry Standards Reference

Full Design: See Chains Schema Design for complete schema and industry standards.

Naming Conventions

References

• EIP-155 - Ethereum Chain ID
• ethereum-lists/chains - Chain Registry
• SLIP-0044 - BIP-44 Coin Types

Phase 0x11-b Schema

-- Minimum viable: uses chain_slug only
CREATE TABLE user_addresses (
    user_id BIGINT,
    asset VARCHAR(32),
    chain_slug VARCHAR(32),  -- "eth", "btc"
    address VARCHAR(255),
    PRIMARY KEY (user_id, asset, chain_slug)
);