Aller au contenu
Condorcet.vote Alpha
← Documentation technique

Horodatage OpenTimestamps

Chaque bloc est ancré dans la blockchain Bitcoin via OpenTimestamps : une preuve, indépendante de la plateforme, que ses octets exacts existaient au plus tard à une date donnée.

La blockchain est le sur-protocole qui rend l'intégrité et l'immuabilité du registre public contrôlables par tous ; l'ancrage OpenTimestamps en est la partie qui prouve quand chaque bloc existait. Il ne demande aucune confiance dans la plateforme ni dans ses clés : le fichier .ots se vérifie contre le bloc avec l'outillage OpenTimestamps standard.

Protocole v1

Pourquoi un ancrage externe

Une date que la plateforme ne peut pas antidater.

La signature de la plateforme prouve qu'un bloc vient d'elle ; elle ne prouve pas que l'histoire n'a pas été réécrite. Un ancrage externe, hors de portée de ses clés, comble une partie de cet écart.

  • Une signature n'est pas l'immuabilité. La plateforme détient sa clé de signature : elle pourrait re-signer une chaîne réécrite, dont chaque bloc se vérifierait encore.
  • La date d'une signature est une affirmation. Le signed_at est la date de création que le signataire inscrit lui-même dans la signature : une clé fuitée peut antidater une signature à l'intérieur de sa fenêtre de validité.
  • Un bloc Bitcoin ne s'antidate pas. Une attestation Bitcoin n'est pas une affirmation de la plateforme : elle prouve que les octets exacts du bloc existaient au plus tard au bloc Bitcoin attesté, indépendamment des clés de la plateforme. Elle borne ainsi la fenêtre d'antidatage d'une clé fuitée.
  • Un renfort des copies indépendantes. L'immuabilité repose en pratique sur les copies que chacun peut conserver des blocs publiés. L'ancrage y ajoute une preuve d'existence tierce : une histoire réécrite ne peut pas obtenir d'attestations antidatées.
Ce qui est horodaté

Le SHA-256 du fichier, tel qu'il est publié.

Chaque bloc, quel que soit son type (configuration, rings, votes, closure), reçoit sa propre preuve. Il est soumis aux calendriers OpenTimestamps au moment de son scellement, juste après l'enregistrement de sa ligne d'ancrage en base. L'engagement porte sur le fichier publié lui-même : la preuve se vérifie contre le bloc téléchargé, sans rien d'autre.

sha256({n}.json) SHA-256 · engagement
Le SHA-256 simple des octets du fichier de bloc : les octets exacts qui sont stockés, servis, hachés et signés.
nonce absent
Soumis délibérément sans le nonce de confidentialité habituel d'OpenTimestamps, puisque les octets sont publics par conception : l'engagement auprès des calendriers est égal à sha256({n}.json), et tout outillage OpenTimestamps standard vérifie la preuve sans confiance dans la plateforme.
SHA3-512 empreinte de chaînage
À ne pas confondre : l'empreinte d'un bloc dans la chaîne (content_hash, previous_hash du bloc suivant) reste le SHA3-512 du fichier. Le SHA-256 n'est que l'engagement OpenTimestamps.
Cycle de vie

De pending à completed.

Une preuve OpenTimestamps se complète en deux temps : les calendriers s'engagent aussitôt, Bitcoin confirme ensuite, typiquement en quelques heures. Le statut de la preuve est la seule donnée modifiable d'un bloc, et il ne change qu'une fois, dans un seul sens.

  1. 1

    Soumission au scellement.

    La plateforme soumet l'engagement aux serveurs de calendrier OpenTimestamps publics et range la preuve reçue à côté du bloc. La soumission est au mieux : une panne des calendriers ne retarde ni ne fait échouer la publication du bloc, dont le fichier .ots manque alors jusqu'à la réconciliation suivante.

  2. 2

    pending : les calendriers se sont engagés.

    La preuve porte les engagements des calendriers, pas encore d'attestation Bitcoin. Elle est déjà téléchargeable, mais ne prouve encore aucune date dans Bitcoin.

  3. 3

    Une réconciliation toutes les heures.

    Chaque heure, chaque bloc encore pending est repris. Une preuve manquante est re-soumise à partir des octets stockés : l'ancrage part alors de cette nouvelle soumission. Pour un bloc publié depuis plus de 4 heures, le délai typique d'une confirmation Bitcoin, les calendriers sont interrogés. Ce rythme horaire tient lieu de politique de relance.

  4. 4

    completed : Bitcoin a confirmé.

    Dès que les calendriers fournissent l'attestation Bitcoin, la preuve enrichie remplace le fichier .ots stocké et le statut du bloc passe à completed. Il ne revient jamais à pending.

Le fichier .ots

Un troisième fichier, à côté du bloc et de sa signature.

La preuve est servie avec le bloc {n}.json et sa signature {n}.json.sig, quel que soit son état, et son statut figure dans le manifeste de l'élection. Ces fichiers existent tant que l'élection a un registre public, de l'ouverture à l'archivage ; une élection annulée les retire.

/elections/{election}/chain/{n}.json.ots Route publique
Redirige vers le fichier stocké. Servie en attente comme complétée : une preuve pending porte déjà les engagements des calendriers.
{election}/{election}_{n}.json.ots Fichier stocké
Rangé à côté du bloc et nommé avec l'identifiant de l'élection : une copie détachée de son URL reste identifiable.
ots_url · ots_status Manifeste
Pour chaque bloc, le manifeste (/elections/{election}/chain) donne l'URL directe de la preuve et son statut, pending ou completed. La page du registre affiche le même état sur chaque téléchargement .ots : « en attente d'ancrage Bitcoin » ou « ancré dans Bitcoin ».
pending → completed Remplacé une fois
Le fichier .ots n'est pas figé : la preuve enrichie remplace la preuve en attente, pour que téléchargements et miroirs obtiennent toujours la plus complète. Le bloc, lui, ne change jamais ; en base, le statut est la seule colonne que la table des blocs, en ajout seul, laisse modifier, et dans ce seul sens.
{n}.json.ots Accès
Les preuves .ots, comme le manifeste et les blocs JSON, restent téléchargeables pour toutes les élections, quelle que soit l'offre. Seul le téléchargement des signatures .sig est réservé aux élections Officielles, et seulement dans l'interface.
Vérification

ots verify, contre le fichier téléchargé.

La plateforme rapporte l'état de la preuve, mais n'effectue elle-même aucune vérification sur la chaîne Bitcoin : c'est au vérificateur de le faire, avec l'outillage OpenTimestamps standard. Dans la procédure de vérification complète, ce contrôle est optionnel.

  1. 1

    Récupérer le bloc et sa preuve.

    Le fichier {n}.json et sa preuve {n}.json.ots, depuis le registre public de l'élection ou les URL du manifeste. Le statut indiqué par le manifeste est une déclaration de la plateforme ; seule la vérification fait foi.

  2. 2

    Vérifier la preuve contre le fichier.

    ots verify -f {n}.json {n}.json.ots. L'engagement étant le SHA-256 simple du fichier, aucune donnée de la plateforme n'intervient : un fichier modifié d'un seul octet ne correspond plus à la preuve.

  3. 3

    Reprendre une preuve en attente.

    Une preuve pending ne désigne pas encore de bloc Bitcoin. Le fichier stocké étant remplacé par la preuve complétée, il suffit de le télécharger à nouveau une fois le statut passé à completed, en général quelques heures après la publication du bloc.

Ce que cela prouve : Une preuve complétée qui se vérifie établit que le bloc existait, octet pour octet, au plus tard au bloc Bitcoin attesté, indépendamment des clés de la plateforme.

La procédure de vérification complète
Horodatage · shell 
# le statut de chaque preuve (ots_status), dans le manifeste
curl -s https://admin.stg.condorcet.vote/elections/{election}/chain

# le bloc n et sa preuve (les routes redirigent vers les fichiers stockés)
curl -sL -o {n}.json https://admin.stg.condorcet.vote/elections/{election}/chain/{n}.json
curl -sL -o {n}.json.ots https://admin.stg.condorcet.vote/elections/{election}/chain/{n}.json.ots

# l'engagement : le SHA-256 simple du fichier
openssl dgst -sha256 {n}.json

# la preuve contre le fichier
ots verify -f {n}.json {n}.json.ots
ElephStamp, notre bibliothèque OpenTimestamps Condorcet.Vote a développé sa propre bibliothèque OpenTimestamps, ElephStamp : la plus complète et la plus moderne qui soit, open source (licence MIT), utilisable comme bibliothèque PHP ou en ligne de commande. Ses preuves .ots sont 100 % interopérables, octet pour octet, avec le client officiel en Python : nos preuves se vérifient avec l'un comme avec l'autre. ElephStamp sur GitHub
Limites

Ce que l'ancrage ne prouve pas.

L'ancrage prouve quand des octets existaient. Il s'ajoute aux autres contrôles, il ne les remplace pas.

  • Une borne, pas une date exacte. Une preuve complétée établit que le bloc existait au plus tard au bloc Bitcoin attesté. Une preuve encore pending ne prouve, elle, aucune date dans Bitcoin.
  • Pas l'exactitude du contenu. L'ancrage porte sur des octets, quels qu'ils soient : la validité des bulletins, des bornes de participation et du résultat se contrôle par la procédure de vérification.
  • Pas l'authenticité. La preuve est indépendante des clés de la plateforme, donc muette sur l'auteur du bloc. Ce rôle revient à la signature OpenPGP, à vérifier avec les clés de vérification publiées.
  • Pas l'unicité de l'histoire. Une histoire réécrite ne peut pas obtenir d'attestations antidatées, mais l'ancrage ne prouve pas à lui seul qu'une histoire donnée est la seule publiée : les copies indépendantes restent la défense contre la réécriture.
  • Pas un horodatage qualifié. Un horodatage RFC 3161 par une autorité d'horodatage, de valeur probante eIDAS, reste un complément possible ; il n'est pas proposé aujourd'hui.

Voir aussi

Toute la documentation technique