Quantova/QCore.rs

# QCore.rs Quantova 的抗量子客户端核心，使用 Rust 编写。这是 Quantova 客户端必须精确处理四件事的唯一场所。它派生抗量子密钥；构建交易；使用抗量子方案对交易进行签名；并与 Quantova gateway 通信。QCore.js 和 QCore.py 都是基于这个相同的核心生成的，因此签名只需在 Rust 中编写一次，且永远不会用其他语言重写。对签名的第二次实现将意味着有第二次机会在用户的资金上犯错，因此永远只会有这一个实现。 一个核心，每种语言一个 binding。QCore.rs 就是这个 Rust 核心。QCore.js 是基于它的 JavaScript 和 WebAssembly binding。QCore.py 是基于它的 Python binding。这三个库从相同的 seed 派生出相同的地址，并将相同的 body 签名为相同的字节，因为它们是同一个核心，而不是它的三个副本。 ## 这个库的用途 任何持有 Quantova 账户、读取链上数据并发送签名交易的程序。无论是钱包、区块浏览器、水龙头、交易机器人、后端服务还是命令行工具。程序可以进行它偏好的任何网络调用，而 QCore 负责处理密码学和通信协议，因此程序永远不需要手动构建签名或请求 body，也无需理解交易的 byte 布局。 ## 它处理的抗量子密码学 Quantova 从根本上就是抗量子的。它中没有任何椭圆曲线，没有 secp256k1，没有 ECDSA，没有 Ethereum 地址，也没有 Substrate envelope。以下每一个基础组件都是 Quantova 在 Q Crypto 库中从零开始的自主实现，不携带任何第三方密码学依赖，并且 QCore 直接构建于该链自身的账户和交易代码之上，从而确保客户端与节点在字节级别上保持一致。 1. 密钥派生。一个钱包持有一个 32 字节的主 seed。QCore 利用 SHAKE256 对主 seed、方案字节和账户索引进行处理，从中衍生出每个账户的 seed，然后从该 seed 派生出模块格点密钥对。节点运行相同的派生过程，因此密钥所签名的账户就是实际持有资金的账户。 2. 签名方案。默认方案是 FIPS 204 标准化的模块格点签名 ML-DSA-65，在网络上作为方案一进行传输。基于哈希的签名 SLH-DSA（由 FIPS 205 标准化）是方案二。签名是确定性的，因此一个交易 body 总是会签出一段确定的字节流，这使得签名后的交易具有可重现性和可测试性。 3. 地址。Quantova 地址是一个 Bech32m Q1 字符串，它渲染了方案字节连同整个 1952 字节模块格点公钥的 SHA3 256 哈希。整个公钥都绑定在地址中。没有任何内容会被截断为 20 字节的哈希，也无法从签名中恢复密钥，因此一个地址仅精确命名一个抗量子密钥。 4. 交易。一个交易 body 包含 sender、nonce、meter limit、fee 和 call。签名所覆盖的字节是规范 body 的 SHA3 256 哈希加上一个固定的 Quantova 交易 domain tag，因此交易签名永远不能被重放为其他类型的签名消息。QCore 负责 assemble body，使用账户的抗量子密钥对 digest 进行签名，并返回规范 wrapper 字节以及准备好用于 gateway 的 transaction id。 ## 它如何针对 Quantova 进行定制且不继承任何行业遗产 Quantova 不与任何其他链共享通信协议、地址或单位，并且 QCore 只使用 Quantova 协议。该地址是基于完整抗量子密钥的 Q1 Bech32m 字符串，绝不是十六进制的 20 字节地址，也绝不是 SS58 字符串。资金以 Quon（最小单位）计量，一百万 Quon 等于一个 QTOV，并且它始终以十进制字符串的形式在网络中传输，因此 JavaScript 的 number 永远不会导致余额舍入误差。其通信协议是 Quantova gateway，即在版本前缀下向命名方法发送的 HTTP POST 请求，带有扁平的 JSON body，既不是 Ethereum JSON RPC，也不是 Substrate WebSocket。交易编码是 Quantova 自有的规范 codec，不是 RLP 也不是 SCALE。签名来自于 Q Crypto，这是 Quantova 从零开始编写的、针对格点和哈希标准的自主实现，而不是借用任何 crate。QCore 不会向或从任何旧格式进行转换，因为根本不存在需要转换的旧格式。 ## 创建钱包 在 client feature 下，核心会从操作系统的随机 源生成一个全新的主 seed，因此钱包只需一次调用即可创建新密钥。恢复短语是唯一的备份，并且始终保留 在设备上。 ``` let seed = qcore::generate_seed()?; let phrase = qcore::mnemonic_from_seed(&seed); ``` ## 从 Rust 中使用它 client feature 在标准库之上添加了一个轻量级的 HTTP transport，供原生调用者使用，并用于针对正在运行的 gateway 验证核心。下面的示例读取 fee 和 nonce，在核心内部对一笔转账进行签名并提交。调用者传入其愿意接受的最高 fee，如果 gateway 报告的 fee 高于此值，核心将拒绝签名，从而防止 gateway 恶意提高 fee 并耗尽账户。在此 transport 上，客户端仅以明文形式与 loopback 节点通信，因为如果没有 transport 安全性，不可信网络上的 gateway 可能会篡改 fee 和 nonce，因此请通过一个终止于 loopback 的 tunnel 来连接远程 gateway。 ``` use qcore::{Client, account_address, TxStatus}; let client = Client::new("http://127.0.0.1:8645"); let seed = [11u8; 32]; let to = account_address(&seed, 1); let info = client.node_info()?; let (signed, outcome) = client.transfer(&seed, 0, &to, 1000, info.transfer_fee)?; let status = client.transaction(&signed.tx_id)?; ``` ## 构建 ``` cargo build --features client cargo test --features client ``` ## 终端客户端 client feature 还在相同的核心之上构建了一个名为 qcore 的小型终端客户端，以便人们可以 从 shell 创建钱包、读取链上数据并发送转账。它的签名方式与钱包完全一致， 绝不会手动干预签名过程。 ``` qcore new create a wallet, seed, phrase, and address qcore address [index] the address for a seed and index qcore info the chain id, height, and fee qcore register register a funded account's key so it can send qcore balance

an account balance and nonce qcore send sign and submit a transfer qcore status where a transaction is ``` ## 所有权与许可 QCore.rs 由 Quantova Inc 构建并拥有，它是生成 QCore.js 和 QCore.py 所使用的参考核心。它不携带任何行业技术栈，也不继承其中的任何内容。从密钥派生到通信协议的所有内容都是 Quantova 自主拥有的。它采用 Apache 2.0 和 MIT 许可证发布，因此任何钱包、浏览器或服务都可以基于它进行构建，其版权归 Quantova Inc 所有。

标签：AI工具, CVE, Rust, 加密货币钱包, 区块链, 可视化界面, 后量子密码学, 数字签名, 网络流量审计, 跨语言绑定, 通知系统