Duizenden digitale handtekeningen kunnen op
Cardano worden samengevoegd tot één bewijs van 96 bytes. Plutus en Aiken maken die controle rechtstreeks op de blockchain mogelijk.
De
Cardano Foundation toont daarnaast hoe dezelfde cryptografische functies kunnen worden gebruikt voor digitale identiteit, zero-knowledge proofs en controleerbare willekeur.
Dit is geen nieuwe hardfork. De bouwstenen zitten al in Plutus Core. De
technische publicatie van de Cardano Foundation laat vooral zien hoe ontwikkelaars ze veilig kunnen toepassen.
BLS12-381 draait rechtstreeks in smart contracts
De techniek heet BLS12-381. Het is een speciale elliptische curve die zogeheten pairingcontroles ondersteunt.
Zo’n controle kan aantonen dat sleutels, handtekeningen of bewijzen wiskundig bij elkaar horen. De geheime informatie achter die gegevens hoeft daarbij niet openbaar te worden.
Cardano voegde de benodigde functies met Plutus V3 toe tijdens de Chang-upgrade. Smart contracts kunnen punten optellen, berichten naar de curve vertalen en pairingrelaties controleren.
Daarvoor is geen centrale dienst of extern oracle nodig. De berekening wordt uitgevoerd als onderdeel van de Cardano-transactie.
Aiken geeft ontwikkelaars een toegankelijkere en typeveilige interface voor deze functies. Daardoor hoeven zij minder vaak rechtstreeks met ruwe bytes en lage cryptografische bewerkingen te werken.
Honderd signatures worden één bewijs
De duidelijkste toepassing is het samenvoegen van digitale handtekeningen.
Bij traditionele systemen moet een smart contract iedere signature apart opslaan en controleren. Het vereiste rekenwerk groeit daardoor mee met het aantal ondertekenaars.
BLS werkt anders. De handtekeningen zijn punten op een curve en kunnen bij elkaar worden opgeteld.
Honderd afzonderlijke handtekeningen worden zo één signature van 96 bytes. Dat bedrag blijft gelijk wanneer meer deelnemers worden toegevoegd.
Ondertekenen alle deelnemers exact hetzelfde bericht, dan kunnen ook hun publieke sleutels worden samengevoegd. De on-chaincontrole blijft in dat specifieke geval vrijwel gelijk, of het nu om tien of duizend ondertekenaars gaat.
BLS maakt grote groepen niet kleiner. Het maakt het bewijs van hun gezamenlijke toestemming compacter.
Dat kan nuttig zijn voor multisig-wallets, bestuursstemmingen en comités die gezamenlijk transacties goedkeuren.
Verschillende berichten kosten meer werk
De vaste verificatielast geldt niet in ieder scenario.
Wanneer alle deelnemers verschillende berichten ondertekenen, kan het contract de signatures nog steeds bundelen. De verificatie moet dan wel ieder afzonderlijk bericht verwerken.
Het rekenwerk groeit in dat geval mee met het aantal berichten. De opslagwinst blijft bestaan, maar de controle wordt niet volledig constant.
Dat onderscheid is belangrijk voor ontwikkelaars. Een bestuursstemming waarbij iedereen exact dezelfde beslissing ondertekent, gedraagt zich anders dan een systeem waarin iedere gebruiker een eigen transactie goedkeurt.
De gekozen opzet bepaalt uiteindelijk hoeveel ruimte en transactiekosten worden bespaard.
Rogue keys vormen een aanvalspunt
Handtekeningen samenvoegen brengt een eigen beveiligingsrisico mee. Een aanvaller kan proberen een gemanipuleerde publieke sleutel aan de groep toe te voegen.
Zo’n rogue key is ontworpen om andere sleutels binnen het aggregaat wiskundig weg te strepen. Een vervalst resultaat kan daardoor geldig lijken zonder toestemming van alle vereiste deelnemers.
De beschreven Aiken-bibliotheek ondersteunt drie methoden om dat risico te beperken: Basic, Augmented en Proof of Possession.
De Basic-methode past vooral bij sleutels die vooraf zijn gecontroleerd. Augmented verwerkt de publieke sleutel in het ondertekende bericht.
Bij Proof of Possession moet iedere deelnemer eerst aantonen dat hij werkelijk over de geheime sleutel beschikt. Die methode past goed bij vaste validatorgroepen en bestuurscomités.
Een verkeerde keuze kan het voordeel van aggregatie tenietdoen. De Foundation levert daarom niet alleen code, maar ook patronen voor veilig sleutelbeheer en verificatie.
Privacybewijs zonder volledig identiteitsdossier
De BLS12-381-functies ondersteunen ook BBS+-signatures. Daarmee kunnen ontwikkelaars digitale identiteitsbewijzen bouwen die slechts een deel van de onderliggende gegevens tonen.
Een bevoegde organisatie kan bijvoorbeeld leeftijd, nationaliteit en lidmaatschap in één credential ondertekenen.
De gebruiker kan later aantonen ouder dan achttien jaar te zijn zonder zijn naam of exacte geboortedatum openbaar te maken. Het smart contract controleert alleen het vereiste bewijs.
Dit heet selective disclosure. Alleen de informatie die nodig is voor een bepaalde handeling wordt gedeeld.
De verborgen gegevens blijven buiten het openbare grootboek. Dat kan relevant zijn voor toegangssystemen, gereguleerde financiële diensten en apps die persoonsgegevens niet volledig op een
blockchain willen zetten.
De cryptografie bewijst overigens niet dat de oorspronkelijke gegevens correct waren. Gebruikers moeten nog steeds vertrouwen op de partij die de credential heeft uitgegeven.
Willekeur wordt achteraf controleerbaar
Een andere toepassing is de Verifiable Random Function, meestal afgekort tot VRF.
De houder van een geheime sleutel genereert daarmee een willekeurig lijkende uitkomst. Andere deelnemers kunnen achteraf controleren dat die uitkomst bij de juiste sleutel en invoer hoort.
De geheime sleutel wordt daarbij niet bekendgemaakt.
Bij dezelfde sleutel en invoer ontstaat steeds dezelfde uitkomst. Een gebruiker kan het resultaat daardoor niet achteraf aanpassen zonder dat de controle mislukt.
Dat kan worden gebruikt voor loterijen, speltoepassingen en de selectie van deelnemers binnen een protocol. De willekeur hoeft dan niet door één centrale beheerder te worden aangeleverd.
De invoer moet wel zorgvuldig worden vastgelegd. Wanneer een deelnemer vrij tussen meerdere invoerwaarden kan kiezen, kan hij mogelijk verschillende uitkomsten proberen.
Zero-knowledgecontrole komt dichterbij
Pairing-friendly curves spelen ook een rol bij zero-knowledge proofs. Daarmee kan iemand bewijzen dat een berekening klopt zonder alle invoergegevens te tonen.
Het zware bewijs wordt doorgaans buiten de keten gemaakt. Een Plutus-script controleert daarna of het bewijs geldig is.
Volgens de officiële
Cardano-documentatie over Chang zijn de BLS12-381-functies juist toegevoegd om zulke controles efficiënter te maken.
Dat betekent niet dat iedere zware privacyberekening goedkoop in één transactie past. Cardano werkt met vaste limieten voor rekenwerk en geheugen.
Ontwikkelaars moeten daarom blijven meten hoeveel transactiebudget hun bewijzen verbruiken. Theoretisch mogelijke cryptografie is niet automatisch economisch bruikbaar.
Cardano levert gereedschap, geen eindproduct
De publicatie verandert het netwerk niet direct. Er ontstaat geen nieuwe wallet, identiteitsdienst of governance-app doordat voorbeeldcode online verschijnt.
De winst zit bij ontwikkelaars. Zij krijgen werkende patronen voor signature aggregation, sleutelafleiding, VRF’s en BBS+-bewijzen.
Dat verkleint de kans dat ieder team gevoelige cryptografie zelf vanaf nul moet schrijven.
Ook de vergelijking met
Ethereum is relevant. Dat netwerk gebruikt BLS12-381 voor handtekeningen in zijn consensuslaag. Cardano maakt de functies via Plutus beschikbaar aan applicatieontwikkelaars.
De uiteindelijke waarde hangt nu af van audits, gebruikskosten en producten die gewone gebruikers werkelijk nodig hebben.
Cardano heeft de cryptografische bouwstenen klaargelegd. De volgende stap moet niet uit een technische handleiding komen, maar uit een applicatie die privacy en schaalbare controle bruikbaar maakt.