Background
Cryptographically relevant quantum computer, if built, could enable Shor’s algorithm and Grover’s algorithm. These completely break ECDSA / ECDH, and reduce hash function (& cipher) strengt...

<div><h2><a href="https://ethresear.ch#p-51852-background-1" rel="nofollow"></a>Background</h2>Cryptographically relevant quantum computer, if built, could enable Shor’s algorithm and Grover’s algorithm. These completely break ECDSA / ECDH, and reduce hash function (&amp; cipher) strength from 2^n2n to 2^\frac{n}{2}2n2There are some non-obvious parts of ETH which would need to be upgraded.<h2><a href="https://ethresear.ch#p-51852-what-is-still-ok-2" rel="nofollow"></a>What is still OK</h2><ul><li>bip39 (pbkdf2-sha512) seems just fine</li></ul><h2><a href="https://ethresear.ch#p-51852-what-is-not-ok-3" rel="nofollow"></a>What is not OK</h2><ul><li>bip32 hdkey derivation<ul><li>Should be replaced by something post-quantum and better (no “non-hardened” keys)</li><li>New scheme could be based on HKDF (like EIP-2333), but not HKDF-SHA256</li><li>Alternative KDF is Blake3 in context mode (pq security is unclear)</li><li>The proposed scheme should support both ECC and new pq mode</li></ul></li><li>Transaction signing<ul><li>Should be replaced by lattice-based Falcon (FN-DSA / FIPS-206), or hash-based Sphincs-plus (SLH-DSA / FIPS-205)</li><li>New keys and signatures will consume more space</li><li>Falcon-1024 has 1.75KB keys and 1.25KB sigs</li><li>SLH-DSA-256 has 128B keys and 17KB-50KB sigs</li></ul></li><li>Sender address recovery<ul><li>It was feature of ECDSA (not available in Schnorr, for example)</li><li>Perhaps txs (and not sigs) should encode sender addresses</li></ul></li><li>Address format<ul><li>Currently it’s 40 hex characters, keccak256(pubkey)</li><li>keccak256 should be replaced by keccak512 / sha3-512 / sha512 / blake3-512</li><li>How does Grover algo affect brute-forcing of addresses? Should 40 characters be upped to 80-128?</li><li>Longer address formats should probably use something like bech32 for checksumming &amp; human-friendliness</li><li>How would new addresses interop with old addresses / EVM?</li></ul></li><li>Encrypted wallets<ul><li>Should upgrade from AES-128 to AES-256 or chacha20</li><li>HMAC-SHA256 should upgrade to HMAC-SHA512 or KMAC / blake3-512 (keyed mode)</li></ul></li><li>KZG EIP-4844 verification<ul><li>Should be replaced by a post-quantum scheme</li><li>Algorithms are unclear for now, any suggestions?</li></ul></li><li>EVM 0x20 opcode (KECCAK256)<ul><li>Should be replaced by keccak512 / sha3-512 / sha512 / blake3-512</li></ul></li><li>EVM precompile for ECRECOVER<ul><li>See address recovery above</li></ul></li><li>EVM precompiles for BN / BLS / KZG<ul><li>Should be replaced by newer schemes (unclear which ones?)</li></ul></li><li>Consensus layer signature aggregation<ul><li>Currently aggregates signatures of all validators once per epoch (6 mins)</li><li>More than 1M signatures right now?</li><li>Algorithms are unclear for now, any suggestions?</li></ul></li><li>Anything else?</li></ul><h2><a href="https://ethresear.ch#p-51852-final-thoughts-4" rel="nofollow"></a>Final thoughts</h2>I’m confident all of these problems can be solved even in limited time. Let’s start solving them.If such computer appears soon, it’s possible to do Vitalik’s trick (<a href="https://ethresear.ch/t/how-to-hard-fork-to-save-most-users-funds-in-a-quantum-emergency/18901" rel="nofollow">How to hard-fork to save most users’ funds in a quantum emergency</a>): freeze all accounts and leverage BIP39 with ZK-proofs to recover funds into new pq scheme.</div>

Tidbits of post-quantum ETH

背景
如果建成,具有密码学意义的量子计算机可以实现Shor算法和Grover算法。这些算法完全破坏了ECDSA/ECDH,并降低了哈希函数(和密码)的强度...

<div><h2><a href="https://ethresear.ch#p-51852-background-1" rel="nofollow"></a>背景</h2>如果建成量子计算机,它可以实现Shor算法和Grover算法。这些算法可以完全破解ECDSA/ECDH,并将哈希函数(和密码)的强度从2^n2n降低到2^\frac{n}{2}2n2ETH中还有一些不太明显的部分需要升级。<h2><a href="https://ethresear.ch#p-51852-what-is-still-ok-2" rel="nofollow"></a>仍然可以的部分</h2><ul><li>bip39 (pbkdf2-sha512)似乎没有问题</li></ul><h2><a href="https://ethresear.ch#p-51852-what-is-not-ok-3" rel="nofollow"></a>不可以的部分</h2><ul><li>bip32 hdkey派生<ul><li>应该被一种后量子和更好的方案取代(没有"非硬化"密钥)</li><li>新方案可以基于HKDF(如EIP-2333),但不是HKDF-SHA256</li><li>另一种KDF是上下文模式的Blake3(后量子安全性不明确)</li><li>拟议的方案应该同时支持ECC和新的后量子模式</li></ul></li><li>交易签名<ul><li>应该被基于格的Falcon(FN-DSA/FIPS-206)或基于哈希的Sphincs-plus(SLH-DSA/FIPS-205)取代</li><li>新的密钥和签名将占用更多空间</li><li>Falcon-1024有1.75KB的密钥和1.25KB的签名</li><li>SLH-DSA-256有128B的密钥和17KB-50KB的签名</li></ul></li><li>发送者地址恢复<ul><li>这是ECDSA的一个特性(Schnorr等算法中没有)</li><li>也许交易(而不是签名)应该编码发送者地址</li></ul></li><li>地址格式<ul><li>目前是40个十六进制字符,keccak256(公钥)</li><li>keccak256应该被keccak512/sha3-512/sha512/blake3-512取代</li><li>Grover算法如何影响地址的暴力破解?是否应该将40个字符增加到80-128个?</li><li>更长的地址格式可能应该使用类似bech32的东西进行校验和和人性化</li><li>新地址如何与旧地址/EVM互操作?</li></ul></li><li>加密钱包<ul><li>应该从AES-128升级到AES-256或chacha20</li><li>HMAC-SHA256应该升级到HMAC-SHA512或KMAC/blake3-512(密钥模式)</li></ul></li><li>KZG EIP-4844验证<ul><li>应该被一种后量子方案取代</li><li>目前算法还不清楚,有什么建议吗?</li></ul></li><li>EVM 0x20操作码(KECCAK256)<ul><li>应该被keccak512/sha3-512/sha512/blake3-512取代</li></ul></li><li>EVM预编译的ECRECOVER<ul><li>见上面的地址恢复</li></ul></li><li>EVM预编译的BN/BLS/KZG<ul><li>应该被新的方案取代(不清楚用哪些?)</li></ul></li><li>共识层签名聚合<ul><li>目前每个时期(6分钟)聚合所有验证者的签名</li><li>现在已经超过100万个签名了?</li><li>目前算法还不清楚,有什么建议吗?</li></ul></li><li>还有其他什么吗?</li></ul><h2><a href="https://ethresear.ch#p-51852-final-thoughts-4" rel="nofollow"></a>最后的想法</h2>我相信这些问题都可以在有限的时间内解决。让我们开始解决它们吧。如果这种计算机很快就出现,可以尝试Vitalik的方法(《如何硬分叉以拯救大多数用户的资金》):冻结所有账户,利用BIP39和ZK-证明将资金恢复到新的后量子方案。</div>

后量子ETH花絮

世界自由金融公司（World Liberty Financial）的目标是在全球数兆美元的外汇市场——全球最大、流动性最强的金融领域——分一杯羹。

这家与川普政府有关的加密货币公司…

川普支持的「世界自由」计划推出「世界互换」外汇平台

2026 年投资者面临的问题已不是 「要不要配置」，而是「配多少，以及通过什么工具配置 」。

ARK Invest：比特币的机构化之路

作者： The Economist
编译： 深潮 TechFlow
---------------------------------------------------------------
深潮导读： 尽管比特币价格仍处于 7 万美元上方，但加密市场正经历着一场前所未有的“孤独寒冬”。本文深入剖析了本轮跌势与以往的不同之处：杠杆清算的连锁反应、曾被寄予厚望的 ETF 如今沦为砸盘推手，以及最...