BLS12-381私钥可签署以太坊交易？原因及密钥复用疑问

1. 为什么BLS私钥能用于生成以太坊账户并完成交易？ #

你忽略的核心细节是：私钥本质上是一个符合特定范围的随机数，不同签名算法（BLS12-381、secp256k1）只是对这个随机数的使用规则不同，只要私钥的数值落在目标算法的有效范围内，就能被正常使用。

具体来说：

• BLS12-381的私钥是从有限域Fr中生成的随机数，Fr的阶是一个接近2^256的质数
• 以太坊使用的secp256k1曲线，私钥要求是1 <= 私钥 <= n-1（n是secp256k1的曲线阶，同样是256位级别的质数）
• 你生成的BLS私钥数值几乎必然落在secp256k1的有效范围内，因此ethereumjs-wallet可以用它推导secp256k1公钥和以太坊地址，MetaMask也能基于secp256k1算法完成交易签名——整个过程和BLS签名算法本身无关，只是把BLS生成的随机数当作secp256k1的私钥来用。

你的代码里，Buffer.from(keyPair.secretKey)只是把BLS私钥的字节序列转成了secp256k1私钥需要的格式，以太坊工具链只关心这个字节序列对应的数值是否符合secp256k1的私钥要求，不关心它原本是为哪个算法生成的。

2. 「不建议同一密钥用于两种不同类型的签名」是否正确？ #

这个观点完全正确，原因包括：

• 攻击面扩大：如果其中一个签名体系（比如算法实现漏洞、密钥存储不安全）被攻破，攻击者就能拿到密钥，进而攻击所有使用该密钥的场景
• 安全假设冲突：不同签名算法的安全模型和假设不同，复用密钥可能打破这些假设。比如侧信道攻击，不同算法的硬件实现可能有不同的泄露风险，复用密钥可能让攻击者通过一个场景的泄露获取密钥，入侵另一个场景
• 生命周期管理混乱：不同场景的密钥通常有不同的有效期、权限要求、审计规则，复用密钥会混淆边界，增加管理复杂度和风险
• 合规风险：很多行业的合规要求（如金融、医疗）明确要求不同业务场景使用独立密钥，复用可能违反规定

你的测试代码（格式化后） #

const {
  generateBls12381G2KeyPair,
} = require("@mattrglobal/node-bbs-signatures");

const {
  default: { fromPrivateKey },
} = require("ethereumjs-wallet");

const keyPairTest = (async function () {

  const keyPair = await generateBls12381G2KeyPair();

  const wallet = fromPrivateKey(Buffer.from(keyPair.secretKey));

  console.log(`secretKey: ${Buffer.from(keyPair.secretKey).toString("hex")}`);
  console.log(`ethereum address: ${wallet.getAddressString()}`);

})();

内容的提问来源于stack exchange，提问作者pgermani