SORA-QAI 区块链

SORA 官方X: 点击这里

SORA 官方微博: 点击这里

SORA 白皮书: 点击这里

SORA 路线图: 点击这里

SORA 使用方法: 点击这里

SORA 技术信息: 点击这里

SORA 技术博客: 点击这里

SORA 安全验证: 点击这里

SORA-QAI 技术信息

项目名称: SORA L1 区块链
版本信息: v3.67.14
日期: 2024年5月17日 完成!
作者: SORA-QAI

SORA-QAI:
https://github.com/FromHDDtoSSD/SorachanCoin-qt/commit/c74ef646ae2fccb9ef324b330fc0a18e4bc557f5

I. scriptPubKey 的结构

此交易利用了传统的 OP_CHECKMULTISIG 的特性,并通过软分叉实现。在本节中,我们将详细介绍 scriptPubKey 的结构。

CScript() << OP_1 << ECDSA 公钥 << SORA-QAI 公钥 ID << SORA-QAI 扩展信息 << OP_3 << OP_CHECKMULTISIG

OP_1 和 OP_3 的结构

OP_1 和 OP_3 的结构被视为标准交易。在此上下文中,第一个对应于 OP_1 的脚本被分配了一个 ECDSA 公钥。

剩余的两个元素

剩余的两个元素是通常会被忽略的脚本。作为约束,它们的大小为 33 字节,这通常用于存储压缩的 ECDSA 公钥。因此,根据此规则,我们存储新的 SORA-QAI 公钥的 ID 及其扩展信息。

0x02,剩余的 32 字节区域和 CKeyID 的组合

首先,我们解释 SORA-QAI 公钥的位置。首字节是 0x02。通常,此区域用于存储压缩的 ECDSA 公钥,其中二进制格式以 0x02 或 0x03 开头。为了使其可识别为标准交易,我们将 0x02 分配为首字节。此分配使 32 字节可用。在这里,请回忆 CKeyID,它是一个哈希结构,由 20 字节组成。

SORA-QAI 公钥的转换

SORA-QAI 公钥通过 CKeyID 转换为 20 字节。剩余的 12 字节用 0x00 填充。这使我们能够将其与 ECDSA 公钥区分开来,因为 ECDSA 公钥的二进制格式的最后 12 个字节全部为 0x00 的概率几乎为零。

存储 SORA-QAI 扩展信息

接下来的 33 字节用于存储 SORA-QAI 的扩展信息。第一个字节是 0x02,后面是一个用于版本信息的字节。接下来的 20 字节是空闲的,剩下的 10 字节用 0xFF 填充。

II. scriptSig 的结构

scriptSig 的结构如下组装:

CScript() << OP_0 << ECDSA 签名 << SORA-QAI 公钥 << SORA-QAI 签名

利用 OP_0 及其产生的副作用

OP_0 作为区块链中的常见错误解决方法存在。当项目数量在结束时不匹配时,它会调整堆栈。此事实表明,在 scriptPubKey 中堆栈与 33 字节区域之间不存在一对一关系。因此,SORA-QAI 的附加信息可以堆叠在其后。

严格执行的影响

如果应用严格执行,OP_1 到 OP_3 的结构总共需要一个堆栈。因此,无法堆叠其他项目。

III. 通过软分叉实现

通过软分叉实现有两种方法。第一种是 SegWit。通过巧妙地序列化 CTransaction 并将一个空的虚拟向量分配给 CTxIn 作为标志,旧节点将忽略 CTxIn 之后的元素。因此,即使 CTxIn 之后的序列化偏移一个字节(因为空的虚拟向量序列化为一个字节,0x00),也不会导致错误。因此,旧节点将无问题地通过它。

第二种方法是我们这次采用的,它有效地利用了 OP_CHECKMULTISIG 的解决方法。此方法也避免了旧节点上的错误。

IV. 每种软分叉的优缺点

SegWit

优点:
费用降低:通过将 scriptSig 移到专用区域,可以将其排除在交易大小计算之外,从而减少费用。 交易ID唯一性:ECDSA签名缺乏唯一性(因为不使用随机数可能导致私钥泄漏),在被包含到区块之前存在签名被篡改和交易ID更改的风险。将scriptSig移到专用区域,将其排除在交易ID哈希计算之外,保持交易ID的唯一性。

缺点:
缺乏ECDSA验证:由于CTxIn变为0的虚拟值,旧节点不进行ECDSA验证,直接通过。 代码更改复杂:代码更改较多,增加了验证和新增功能的复杂性。

SORA-QAI方法:利用OP_CHECKMULTISIG解决方法

优点:
重用现有代码:通过扩展OP_CHECKMULTISIG并将新地址格式集成到base58中,可以重用大部分现有的已验证代码,使引入新功能变得容易。 量子和AI抗性:量子和AI抗性签名具有唯一性,与多重签名结合确保了交易ID的唯一性。篡改ECDSA签名会使量子和AI抗性签名失效,从而使交易无效。

缺点:
交易费用:由于scriptSig原样使用,交易费用不变。 缺乏交易ID唯一性:如果验证仅限于ECDSA,签名的性质意味着交易ID缺乏唯一性。然而,量子和AI抗性签名是唯一的,与多重签名结合确保了交易ID的唯一性。这是因为篡改ECDSA签名会使量子和AI抗性签名失效,从而使交易无效。

V. SORA-QAI交易的检测

为了检测此交易,我们检查scriptPubKey,特别是SORA-QAI公钥ID部分。该部分原本用于存储压缩ECDSA公钥的堆栈。因此,它通过CKeyID转换为20字节,0x02之后的剩余12字节始终填充为0x00。这个特征用于检测SORA-QAI交易。

SORA-QAI公钥ID的结构
0x02 | SORA-QAI公钥ID(20字节)| 0x00(12字节)

VI. SORA-QAI版本信息的检测

为了检测此交易的版本信息,我们检查scriptPubKey,特别是SORA-QAI扩展信息部分。此部分最初也是用于存储压缩ECDSA公钥的堆栈,因此以0x02开头。之后的字节是版本信息。

SORA-QAI扩展信息的结构
0x02 | 版本 | SORA-QAI自由字段(20字节)| 0xFF(11字节)

VII. SORA-QAI 哈希目标

首先,使用 SIGHASH_ALL 获取 ECDSA 哈希值。然后,将信息按以下顺序堆叠到 CScript 中,并使用 CHashWriter 进行哈希处理。

CScript() << ECDSA 签名 << ECDSA 公钥 << SORA-QAI 公钥 ID << SORA-QAI 自由字段信息 << ECDSA SIGHASH_ALL 哈希 << 版本 << nHashType

将 ECDSA 签名包含在哈希目标中

因此,ECDSA 签名的更改将改变此哈希。由于 ECDSA 签名使用随机数,有效签名的内容可能会有所不同,导致交易 ID 发生变化。然而,SORA-QAI 的量子和 AI 抗性签名是唯一的。如果哈希目标发生变化,签名将失效,确保矿工不会将修改后的交易 ID 包含在区块中。

VIII. base58 和 bech32

有两种地址格式:base58 和 bech32。通常,P2PKH 使用 base58 格式,而 SegWit 采用 bech32 格式。这些格式通过其结构加以区分,但在实现上可以自由使用。因此,SORA-QAI 最初使用 bech32 格式实现。

区分地址格式的机制

当实现多种地址格式时,它们如何区分?首先,对地址进行解码以获取二进制数据。该二进制数据的一部分包含区分地址格式的标识符。根据此标识符,确定 scriptPubKey 的结构,并应用适当的处理。

硬分叉和软分叉

这引出了一个问题:我们能否轻松地在该部分添加新的地址格式?不,这很困难。如果任意添加新格式,旧节点将无法解释新格式,并将其视为错误。这将导致无法达成共识,因此需要进行硬分叉来更新节点。

然而,正如运行区块链的经验所示,请求硬分叉极具挑战性。因此,更倾向于逐步过渡以实现一致性的软分叉。软分叉包含使旧节点能够识别新格式的机制。SegWit 就是一个这样的例子,SORA-QAI 实现了类似的复杂措施。

IX. 软分叉和 SORA-QAI 方法

像 SegWit 这样的软分叉利用了一种向 CTransaction 序列化中添加虚拟元素的结构。另一方面,SORA-QAI 专注于 P2SH 的结构。

SegWit 方法

如前所述,向 CTransaction 中添加虚拟元素导致旧节点中 CTxIn 的元素数量为零,将其视为无输入的交易。当它被包含在区块中时,旧节点将其解释为无输入并通过,不进行进一步处理,从而避免错误。

SORA-QAI 方法

SORA-QAI 利用了 P2SH 的结构和 OP_CHECKMULTISIG(OP_0)的解决方法。通过利用这两种方法,SORA-QAI 能够以最小的更改实现软分叉,重用现有的已验证代码。重用现有代码是最安全的方法,因为它已经经过了充分的测试。

X. SORA-QAI 验证的结构

SORA-QAI 交易的验证结构包括以下步骤:

1, 识别 SORA-QAI 交易
首先,确定交易是否对应于 SORA-QAI。

2, 基于版本信息的条件分支
然后,基于版本信息执行条件分支。

3, 检查所有堆栈
由于区块链堆栈具有可变结构,因此需要检查所有堆栈。这是必要的,因为数据可以任意放置。

检查 scriptSig 和 scriptPubKey 中公钥的关联性

比较存储在 scriptSig 中的公钥的 CKeyID 与存储在 scriptPubKey 中的 SORA-QAI CKeyID。如果它们匹配,则确认 scriptSig 与相应的 scriptPubKey 关联。

构建验证哈希并执行验证

一旦确认 scriptSig 中的公钥与 scriptPubKey 关联,构建验证哈希。该构建的哈希与公钥和量子与 AI 抗性签名一起用于验证。重要的是要排除嵌入在量子与 AI 抗性签名最后一个字节中的 nHashType。

如果此验证失败,EvalScript 会立即失败,防止达成共识,从而确保量子与 AI 抗性验证的有效性。

量子与 AI 抗性验证后传递给 OP_CHECKMULTISIG

如果量子与 AI 抗性验证成功,流程将传递给 OP_CHECKMULTISIG。由于 scriptSig 和 scriptPubKey 包含 ECDSA 验证公钥和签名,因此随后会执行 ECDSA 验证。

XI. 通过 EvalScript 验证:
对齐堆栈以处理 OP_CHECKMULTISIG 的 OP_0 解决方法

EvalScript 包含多个验证标志,其中一个是专门用于验证 OP_CHECKMULTISIG 中的 OP_0 解决方法。在验证过程中,当到达 OP_0 时,要求堆栈为空。然而,我们必须考虑为什么需要这个解决方法。

如果堆栈的位置和数量严格一一对应,就不需要这种解决方法。因此,通过利用堆栈位置和数量的宽松特性,我们只为此检查暂时模仿一个标准状态。成功通过此检查后,我们悄悄移除额外的 SORA-QAI 堆栈以保持一致性。

通过这种模仿,将完全不同的验证算法作为多重签名引入 OP_CHECKMULTISIG

堆栈位置和计数的宽松特性也适用于旧节点。因此,虽然旧节点无法验证 SORA-QAI 并会忽略它,但它们仍会可靠地执行 ECDSA 验证。

XII. P2SH 和 scriptPubKey

在 P2SH 中,scriptPubKey 的 CScriptID 被存储为 P2SH scriptPubKey。在 EvalScript 的预处理阶段,会发生脚本连接过程,调用并连接从 CScriptID 计算得出的原始 scriptPubKey。然后由 EvalScript 处理这个组合脚本。

P2SH 和 base58 之间的关系

P2PK,P2PKH 和 P2SH 都是以 base58 格式实现的。如前所述,解码 base58 会在开头显示一个标识符二进制。这种标识符用于调用 P2SH,但它保持在 base58 格式。在 SORA-QAI 中,为了利用 bech32,额外的处理被应用于在这个标识符部分嵌入 bech32。

处理带有 bech32 地址的 base58 调用

首先,base58 和 bech32 可以明确区分。当使用 bech32 地址进行 base58 调用时,内部处理切换为 bech32,同时将处理传递给 P2SH。在此过程中,请注意 base58 处理部分的 bool operator==。此操作符用于 base58 地址之间的比较。当 bech32 被并入 base58 内部处理时,二进制结构根本不同,使得此操作符不适用于比较。因此,请确保使用 ToString 进行比较。

bool operator==(const CBase58 &a, const CBase58 &b) const { return a.ToString() == b.ToString(); }

与 SegWit 的兼容性

将 bech32 引入 SegWit 允许与 SORA-QAI 并行运行。这是可行的,因为 SegWit 通过不同的机制(如 P2WPKH)操作,确保这些过程可以明显分开。

SORA-QAI 地址的注册和识别

SORA-QAI 地址可以通过将其 scriptPubKey 构建为 P2SH 进行注册。一旦注册,它们将与 bech32 一起处理。这里的关键考虑是如何处理钱包余额计算。

钱包的余额显示为其拥有的未花费 scriptPubKey 的累计总和。因此,必须使钱包能够识别 SORA-QAI scriptPubKey。

实施步骤:

地址注册:将 SORA-QAI scriptPubKey 注册为 P2SH 并与 bech32 格式关联。
识别添加:更新钱包的余额计算逻辑以识别 SORA-QAI scriptPubKey。
余额计算:确保钱包计算并显示包括未花费 SORA-QAI scriptPubKey 的余额。

XIII. 组装 SORA-QAI scriptSig

要利用未花费的 SORA-QAI scriptPubKey,需要组装 SORA-QAI scriptSig。组装过程如下:

使用 Solver 检查:
确认 scriptPubKey 中存在 SORA-QAI 堆栈。

组装 scriptSig:
使用已经存在的 ECDSA SIGHASH_ALL 哈希。 根据哈希顺序签名并组装 scriptSig。

通过 EvalScript:
确保组装的 scriptSig 通过 EvalScript 并获得批准。

释放到内存池:
将批准的脚本释放到内存池中。

量子与 AI 抗性机制

传统的加密算法如 ECDSA,Ed25519 和 RSA 基于离散对数问题。本质上,它们依赖于在不知道特定周期性的情况下解决某些数学问题的难度,使得暴力攻击不可行。

量子计算方法

量子计算机使用并行计算同时探索多个候选,并能检测周期模式。最初,候选解的概率幅度相等。如果量子态崩溃,只能随机获得一个解。

量子傅里叶变换的作用

量子傅里叶变换将这些候选解转换为周期信息,其中对应周期的信息具有最高的概率幅度。因此,量子计算机可以有效地获取这种高概率的周期信息。

量子与 AI 抗性的意义

量子计算机可以高效地执行经典计算机难以进行的逆向计算,可能从公钥或签名中推导出私钥。因此,开发对量子和基于 AI 攻击具有抗性的新的加密算法至关重要。这些新算法必须具有量子计算机难以解决的数学结构,并且设计上对 AI 攻击具有鲁棒性。

XIV. 量子与AI抗性多重签名的实现

ECDSA,Ed25519 和 RSA 使用周期性密钥,其安全性通过未知的周期性来保证。然而,在多重签名中使用同类型的周期性密钥是无效的。因此,我们利用非周期性密钥。

非周期性密钥和哈希函数

非周期性密钥利用了加密哈希函数的特性。加密哈希函数的主要特性包括:

抗碰撞性:不同输入产生相同输出(哈希值)的概率极低。
不可预测性:即使输入发生微小变化,产生的哈希值也会显著不同(雪崩效应)。
单向函数:从哈希值重构原始输入极其困难。

量子与AI抗性多重签名

我们使用基于这些特性的密钥实现了量子与AI抗性多重签名。与 ECDSA 需要签名中的随机性不同,使用量子与AI抗性私钥生成的签名是唯一的。虽然由于哈希碰撞(不同输入产生相同哈希值)有可能生成相同的有效签名,但在 SORA-QAI 中,这种概率低至 1/2^128,可忽略不计。

通过结合周期性和非周期性密钥,SORA-QAI 利用这两种加密元素的固有优势,确保了对量子和基于AI攻击的强大安全性。

XV. 传统 ECDSA(P2PK,P2PKH,P2SH)与 SORA-QAI 的兼容性

传统的 ECDSA(P2PK,P2PKH,P2SH)使用以“S”开头的地址。相反,SORA-QAI 地址以“sora1”开头。这些地址格式相互兼容。

兼容性详情

地址兼容性:
资金可以从传统的“S”地址发送到“sora1”地址。
反之,也可以从“sora1”地址发送到传统的“S”地址。

使用 scriptPubKey:
用户可以使用“sora1” scriptPubKey,无需特别考虑。
基于 scriptPubKey 格式的处理是无缝的。

实施考虑

交易创建:
在创建交易时,钱包软件应能够识别这两种地址格式,并处理必要的编码和解码。

验证:
在验证过程中,软件应确保 scriptSig 和 scriptPubKey 根据各自的地址格式正确解释。

通过确保这些兼容性特征,SORA-QAI 可以无缝集成到现有的区块链基础设施中,同时通过量子与AI抗性加密机制提供增强的安全性。