polkadot-第20期学习培训

下面哪个不是波卡网络的特点

A 它是一个多链的网络
B 它支持不同网络间的通信
C Relaychain 不能部署任何应用
D parachain可以共享安全

这道题不选D，正确答案是 C。

解析：

  • A选项：波卡（Polkadot）核心特点就是多链架构，由中继链（Relaychain）和多条平行链（Parachain）组成，属于波卡特点。
  • B选项：波卡的核心功能之一是实现不同链（平行链之间、平行链与中继链之间）的跨链通信，解决异构链互操作性问题，属于波卡特点。
  • C选项：错误。Relaychain（中继链）可以部署少量核心应用/智能合约（并非完全不能部署），其主要功能是提供安全和跨链协调，但并非完全禁止应用部署，因此这不是波卡的特点。
  • D选项：正确。Parachain（平行链）通过连接到Relaychain，无需单独维护自身安全，可共享Relaychain的安全机制，这是波卡的核心特点之一。

简单总结：D是波卡的特点，C描述错误，因此答案选C。需要我再帮你梳理一遍波卡网络的核心特点，加深记忆吗？

Polkadot SDK 有哪些特点， 多选

A 模块化，所有组建都可以替换
B Runtime 可以随时升级，不需要分叉
C 不能支持智能合约
D 可以支持单独链的开发 这道题是不是选BD

这道题选ABD，你的判断是正确的！

解析（结合Polkadot SDK核心特点）：

  • A选项 正确
  • B选项：正确。这是Polkadot SDK的核心特点之一，Runtime（运行时）支持“无分叉升级”，无需像比特币、早期以太坊那样，通过硬分叉才能完成协议/功能升级，可灵活迭代。
  • C选项：错误。Polkadot SDK支持智能合约，通过Substrate（Polkadot SDK的核心框架）可轻松开发、部署智能合约，适配平行链（Parachain）的合约开发需求，因此该描述不符合其特点。
  • D选项：正确。Polkadot SDK基于Substrate框架，支持开发者快速搭建独立的平行链（Parachain）或独立链，无需从零开发底层架构，可复用SDK中的核心模块，降低独立链开发成本。

总结：正确选项为BD，你的判断完全正确。需要我再补充Polkadot SDK与Substrate的关联知识点，帮你更深入理解吗？

波卡Hub目前主要支持哪些智能合约平台

A Ink
B REVM
C Frontier
D PVM

这道题不选D，正确答案是 BD。

解析（结合波卡Hub核心特性）：

  • A选项：错误。Ink! 是用于编写智能合约的编程语言（基于Rust扩展），并非智能合约平台/虚拟机，它需依托Polkadot SDK的相关模块才能运行，因此不属于波卡Hub支持的智能合约平台。
  • B选项：正确。波卡Hub的智能合约由Revive执行层提供支持，而REVM是Revive环境中的核心组件，是Rust实现的EVM（以太坊虚拟机），可完整兼容以太坊，支持Solidity合约直接部署，属于波卡Hub主要支持的智能合约平台之一。
  • C选项：错误。Frontier是Substrate上的以太坊兼容层，主要用于Moonbeam等波卡平行链实现EVM兼容，并非波卡Hub本身支持的智能合约平台，波卡Hub通过REVM实现以太坊兼容，而非依赖Frontier。
  • D选项：正确。PVM（PolkaVM）是波卡Hub Revive执行层支持的另一核心智能合约平台，基于RISC-V架构，专为计算密集型任务优化，支持Solidity与Rust编写的合约，与REVM共同构成波卡Hub的双虚拟机环境。

总结：波卡Hub目前主要支持REVM和PVM两种智能合约平台，正确选项为BD，你的判断不完全准确。需要我再帮你梳理一遍波卡Hub与智能合约平台的关联知识点，加深理解吗？

06， 必填， 可以使用Solidity和原生EVM工具直接开发波卡智能合约吗， 单选

A 可以，REVM在波卡上实现了兼容性
B 不可以，需要特殊的编译器

波卡的SS58帐号在每条链上都一样吗

A 一样
B 根据prefix不同

答案：B 根据prefix不同

简单说：

  • 波卡系每条链有自己的 SS58 prefix
  • 同一个公钥，用不同 prefix 编码，得到的地址字符串不一样
  • 但它们本质上对应同一个账户，只是展示格式不同

需要我帮你查常用链（Polkadot、Kusama、Statemint）的 SS58 前缀吗？

04， 波卡支持的签名算法， 多选

A sr25519
B ed25519
C ECDSA
D RSA

正确答案：A、B、C

解析

波卡（Polkadot）底层基于 Substrate 框架，支持以下三种签名算法：

  • A. sr25519 ✅
    全称 Schnorrkel/Ristretto x25519，波卡默认签名算法。基于 Schnorr 签名与 Ristretto 曲线，优势是签名聚合、批量验证、HD 钱包兼容。

  • B. ed25519 ✅
    标准 EdDSA 算法，安全性高、兼容性广，Substrate/Polkadot 原生支持。

  • C. ECDSA ✅
    特指 secp256k1 曲线（以太坊/比特币同款），用于兼容以太坊生态与跨链场景。

  • D. RSA ❌
    不支持。RSA 效率低、签名长，不符合公链性能需求。

要不要我帮你整理一份 sr25519 / ed25519 / ECDSA 的适用场景与优缺点对比表，方便你记忆？

05， 波卡Revive计算gas的维度， 多选

A ref_time
B proof_size
C input size
D storage deposit

正确答案：A、B、D

解析

Revive（Polkadot EVM 兼容模块）基于 Substrate Weight V2 计费，核心是二维执行成本 + 存储押金：

  • A. ref_time ✅
    计算执行时间（皮秒），对应 CPU 资源，类似以太坊 Gas。

  • B. proof_size ✅
    状态证明大小（字节），用于平行链向中继链提交有效性证明（PoV）。

  • C. input size ❌
    输入数据大小不是独立 Gas 维度，已包含在 ref_time / proof_size 中。

  • D. storage deposit ✅
    存储押金（占用链上存储时抵押，释放退还），属于 Revive 计费体系。

一句话记：Revive 计费 = 计算(ref_time) + 证明(proof_size) + 存储押金(storage deposit)。

06， 必填， Revive precompile的地址分配， 单选

A 连续分配
B 不同类型有自己的空间

正确答案：B 不同类型有自己的空间

解析

Revive（Polkadot EVM 兼容层）的 Precompile 地址按功能类型划分独立地址段/命名空间，而非简单连续编号：

  • B. 不同类型有自己的空间 ✅

    • 以太坊原生预编译：0x0000...0001 ~ 0x0000...0009（加密/工具函数）
    • Substrate 系统预编译：0x0000...01xx（资产、XCM、质押等）
    • 平行链专属预编译：分配独立前缀段（如 0x0000...03xx、0x0000...04xx）
    • 按功能类别/前缀分区，便于扩展、避免冲突。

  • A. 连续分配 ❌
    不是简单 1,2,3... 连续编号，而是分类型、分段、带固定前缀的地址规划。

要不要我帮你整理一份 Revive 常用 Precompile 地址清单（含类型、地址、功能），方便你复习？

07， Revive precompile应该如何调用， 单选

A 没有selector，只能直接call
B 要根据每个precompile的定义，有的可以选择selector

正确答案：B 要根据每个precompile的定义，有的可以选择selector

实践题

https://github.com/papermoonio/2026-h2-building-production-grade-dApps

一、什么是 PAPI？

PAPI = Polkadot-API

  • 新一代 TypeScript/JavaScript SDK，替代传统 @polkadot/api
  • 轻客户端优先（smoldot）、类型安全、模块化、体积小
  • 自动从链上元数据生成类型，IDE 自动补全
  • 支持 Promise / Observable、多链、动态导入

二、项目依赖

1
2
3
npm install viem polkadot-api @polkadot-api/utils @polkadot-api/ss58
# 或 ethers + papi
npm install ethers polkadot-api @polkadot-api/utils @polkadot-api/ss58

三、完整代码（Viem + PAPI）

1. 连接测试网（Westend/Polkadot Testnet）

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
import { createClient, getTypedApi, jsonRpcProvider } from "polkadot-api";
import { ss58Decode, ss58Encode } from "@polkadot-api/ss58";
import { createPublicClient, http, hexToBytes, bytesToHex, toHex } from "viem";

// 1) PAPI 连接 Westend 测试网
const provider = jsonRpcProvider({
  rpc: (chain) => ({
    url: "wss://westend-rpc.polkadot.io", // 测试网
  }),
});
const client = createClient(provider);
// 生成类型（需先 papi add westend）
import { westend } from "@polkadot-api/descriptors";
const typedApi = client.getTypedApi(westend);

// 2) Viem 连接 Revive EVM (Westend EVM RPC)
const evmClient = createPublicClient({
  transport: http("https://westend-evm-rpc.polkadot.io"), // 测试网 EVM
});

2. SS58 ↔ H160 地址转换（Revive 映射规则）

1
2
3
4
5
6
7
8
9
10
11
12
13
14
// SS58 → H160 (EVM)
function ss58ToH160(ss58Addr: string): `0x${string}` {
  const decoded = ss58Decode(ss58Addr); // 32 bytes public key / hash
  // 取 keccak256 后 20 bytes（标准映射）
  const hash = hexToBytes(typedApi.utils.keccak256(bytesToHex(decoded)));
  return bytesToHex(hash.slice(-20)) as `0x${string}`;
}

// H160 → SS58 (prefix=42 对应 Westend)
function h160ToSs58(evmAddr: `0x${string}`): string {
  const pubkey = new Uint8Array(32);
  pubkey.set(hexToBytes(evmAddr), 12); // 前12字节填0xEE
  return ss58Encode(pubkey, 42); // prefix=42
}

3. 余额一致性测试

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
async function testBalance(ss58: string) {
  // 1) 原生余额 (PAPI)
  const native = await typedApi.query.System.Account.getValue(ss58);
  const nativeBal = native.data.free;

  // 2) EVM 余额 (Viem)
  const evmAddr = ss58ToH160(ss58);
  const evmBal = await evmClient.getBalance({ address: evmAddr });

  console.log("SS58:", ss58);
  console.log("EVM:", evmAddr);
  console.log("Native free:", nativeBal.toString());
  console.log("EVM balance:", evmBal.toString());
  // 同一账户映射余额应一致（含 EVM deposit）
}

// 测试
testBalance("5FHneW46xGXgs5mUiveU4sbTyGBzmstUspZC92UhjJM694ty");

4. 调用 Revive Precompile（以 ECRecover 为例）

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
// Precompile 地址：ECRecover = 0x0000...0001
const PRECOMPILE_ECRECOVER = "0x0000000000000000000000000000000000000001";

async function callECRecoverPrecompile(
  hash: `0x${string}`,
  v: number,
  r: `0x${string}`,
  s: `0x${string}`
) {
  // 编码输入 (32+32+32+1)
  const data = bytesToHex(
    new Uint8Array([
      ...hexToBytes(hash),
      ...hexToBytes(r),
      ...hexToBytes(s),
      v - 27,
    ])
  );

  // Viem 直接 call precompile（无 selector）
  const result = await evmClient.call({
    to: PRECOMPILE_ECRECOVER,
    data: data as `0x${string}`,
  });

  console.log("ECRecover result:", result.data);
  return result.data;
}

// 测试签名恢复
callECRecoverPrecompile(
  "0x...", // 消息哈希
  28,
  "0x...",
  "0x..."
);

四、关键点说明

  1. 地址映射

    • SS58 → H160：keccak256(pubkey).slice(-20)
    • H160 → SS58：0xEE 填充 12 字节 → SS58 编码

  2. 余额一致

    • 原生账户 → 映射 EVM 地址共享同一资金池（EVM deposit）

  3. Precompile 调用

    • 无 selector，直接 call + 编码 calldata
    • 标准以太坊预编译地址（0x01 ECRecover、0x02 SHA256 等）

五、ethers 版本（简化）

1
2
3
4
5
6
7
8
9
10
11
12
import { ethers } from "ethers";
const provider = new ethers.JsonRpcProvider("https://westend-evm-rpc.polkadot.io");

// 调用 precompile
async function callPrecompile() {
  const tx = {
    to: "0x0000000000000000000000000000000000000001",
    data: "0x...",
  };
  const result = await provider.call(tx);
  console.log(result);
}

polkadot做了typescript和javascript可以调用的sdk，我也想做这种可被其他程序调用的sdk，应该怎么做？

可以，思路就是：把你的链能力抽象成稳定 API + 多语言分发包 + 完整文档与版本治理。
Polkadot 的 SDK 之所以好用，不只是“能连链”，而是“可维护、可升级、可生态集成”。

下面给你一个实战化路线图（按从 0 到可用来排）：

1) 先定 SDK 的“边界”

先明确你要给外部程序暴露什么能力，不要一开始就全做。

  • 连接层：RPC/WS 连接、重连、超时、fallback
  • 账户层：地址格式转换、签名、验签
  • 链交互层：查询（read）、交易（write）、事件订阅
  • 工具层：单位转换、错误码映射、日志/追踪

建议先做一个 MVP：

  • connect()
  • getBalance(address)
  • transfer(...)
  • subscribeNewHeads(...)
  • addressConvert(...)

2) API 设计优先（比实现更重要）

你要像产品一样设计接口。

  • 稳定命名：client.balance.get(address) 比零散函数更易扩展
  • 输入输出强类型：TS 用显式 type/interface，返回统一 Result 或抛统一错误
  • 错误模型统一：网络错、参数错、链上执行错分开
  • 异步一致性：全 Promise 风格，不混 callback
  • 可组合：支持中间件（重试、签名器、缓存、指标）

一个常见结构：

  • core（协议/类型/错误）
  • transport（http/ws）
  • client（高层 API）
  • plugins（链特性扩展）

3) JS/TS 工程化（npm 包）

做成“别人能直接 npm 装”的库。

最小要求：

  • src/ TS 源码
  • dist/ 编译产物（ESM + CJS 最好都给）
  • package.json 配置 exports、types
  • README.md（3 分钟上手）
  • CHANGELOG.md（版本变更）
  • 语义化版本：semver

关键点：

  • tsup / rollup / unbuild 打包
  • Tree-shaking 友好（避免全量引入）
  • Browser / Node 兼容策略写清楚

4) 文档要“可复制运行”

Polkadot 文档强在“直接可跑”。

你至少准备：

  • Quick Start（5 行代码拿到余额）
  • API Reference（每个方法参数/返回/错误）
  • Cookbook（典型场景：转账、监听、批量查询）
  • FAQ（链不兼容、nonce、gas、重试）

建议做一个 examples/ 目录，配合：

  • npm run example:balance
  • npm run example:transfer

5) 质量保障（生产级）

这是 SDK 能不能被别人信任的核心。

  • 单元测试：参数校验、编码解码、错误映射
  • 集成测试：连 testnet 真跑（可录制 fixture）
  • 兼容测试：不同 Node 版本、不同 RPC 节点
  • CI：lint + test + build + typecheck
  • 发布门禁：tag 才发包，自动生成 release note

6) 向后兼容策略

SDK 最怕“升级就炸”。

  • 不随意改方法签名
  • 废弃走 @deprecated + 迁移文档
  • Breaking changes 只放 major 版本
  • 维护 migration guide（v1 -> v2）

7) 多语言扩展思路

你现在问的是 TS/JS，但未来可能想给 Python/Go。

可选路线：

  1. 协议统一 + 各语言原生实现（长期最佳）
  2. 核心用 Rust/Go，绑定到 JS/Python（性能高，复杂）
  3. 生成式 SDK（OpenAPI / protobuf / JSON-RPC schema 自动生成）

如果你是区块链 SDK，推荐：

  • 把链能力先抽成 JSON-RPC spec / typed schema
  • TS SDK 先打磨成熟，再扩其他语言

8) 你可以直接照抄的落地计划（两周版）

  • 第 1-2 天：需求边界 + API 草案 + 错误码
  • 第 3-5 天：连接层 + 查询层 + 单测
  • 第 6-8 天：交易层 + 签名器抽象 + 集成测
  • 第 9-10 天：文档 + 示例 + CI + 首次发版
  • 第 11-14 天：收反馈 + 修 API 粗糙点 + v1.0.0

如果你愿意，我下一步可以直接帮你给出一个SDK 仓库模板结构（目录树 + package.json + tsup + 错误模型 + 示例接口草稿），你拿去就能开工。