Ik heb gekeken naar meer post-quantum upgrade mechanismen, vooral die welke geen adreswijziging vereisen. EdDSA-ketens die RFC-8032 (Ed25519-stijl) volgen, hebben een ingebouwd voordeel. Je ondertekeningssleutel is geen rauwe willekeurige scalar, maar wordt deterministisch afgeleid van een korte seed door hashing. Dat betekent dat je kunt bewijzen dat je de seed kent (in een post-quantum-geluid ZK-bewijs) en een nieuwe post-quantum sleutel aan hetzelfde adres kunt binden. Geen fondsen verplaatsen en geen nieuwe curvegegevens on-chain. Zelfs inactieve accounts kunnen worden geüpgraded als de seed bestaat. Dit dekt ketens zoals Sui, Solana, NEAR, Stellar, Aptos. Bitcoin/Ethereum hebben die invariant niet standaard omdat veel ECDSA-sleutels afkomstig zijn van "gewoon een willekeurige scalar kiezen". Maar er is een mogelijke weg voor grote cohorten die BIP-39 → BIP-32 gebruiken met goed gedefinieerde paden. Je kunt die exacte afleiding bewijzen en een post-quantum sleutel binden zonder fondsen te verplaatsen. Maar, het is portemonnee-specifiek en kan complex zijn: - BIP-39’s PBKDF2-HMAC-SHA512 (2048 rondes) is kostbaar in ZK - BIP-32 voegt HMAC-SHA512 en secp256k1 wiskunde binnen de circuit toe Toch kan het voor veelvoorkomende paden (bijv. Ethereum m/44’/60’/0’/0/x) haalbaar zijn. Over het algemeen zijn er twee implementatiepatronen: 1. Eenmalig bewijs + mapping: publiceer een bewijs eenmaal en registreer adres → post-quantum sleutel. Vanaf dat moment onderteken je post-quantum voor dat adres. 2. Per-transactie bewijs: elke transactie draagt een enkel bewijs dat de seed aan het adres koppelt en het bericht autoriseert. Stateless, maar elke verifier moet het bewijs controleren. Dit kan veel ketens uitsluiten gezien de prestatie-overhead van het verifiëren van het bewijs per tx. Waarom dit werkt: Shor’s algoritme breekt discrete logs (dus publieke-sleutel systemen zoals ECDSA/EdDSA falen zodra de publieke sleutel wordt blootgesteld). Grover’s algoritme biedt alleen een kwadratische versnelling voor hash pre-images. Dus als je privésleutel is afgeleid van een seed via een sterke hash (bijv. SHA-512), blijft de seed verborgen, zelfs als een toekomstige machine de sleutel van vandaag herstelt. Daarom helpt het "seed-first" ontwerp in EdDSA. Bovendien heb je geen hard fork nodig om te beginnen. Voor Q-Day kun je ook identiteiten binden zonder ZK door de legacy-adres en de post-quantum sleutel in beide richtingen kruisgewijs te ondertekenen en het aan de tijd te verankeren. Dat is wat we hebben gebouwd met yellowpages. In de post breek ik de mechanica af, wat je vandaag kunt besparen op EdDSA-ketens, wat je realistisch kunt besparen op ECDSA, de afwegingen van eenmalige versus per-tx bewijzen, en de limieten waar je om moet geven (seed handling, replay bescherming, bewijs kosten). Volledige beschrijving hieronder.