SPINA enregistre chaque événement dans un journal scellé tamper-evident : une chaîne de Merkle en SHA-256, horodatée eIDAS et ancrée sur Hedera. Toute modification ou insertion après coup brise la chaîne et devient mathématiquement détectable — l'intégrité de l'historique se vérifie par un tiers, sans compte.
Comment SPINA démontre-t-il qu'un événement n'a pas été modifié ou réinséré après coup ?
Chaque événement est chaîné au précédent par un hash SHA-256 (arbre de Merkle). Toute modification ou insertion brise la chaîne : l'altération devient mathématiquement détectable par un tiers qui rejoue l'historique.
Quel débit et quel volume d'événements SPINA peut-il sceller sans dégrader mon système ?
SPINA scelle de façon asynchrone et passive : il n'interfère pas avec votre système. La chaîne Merkle supporte un volume élevé, chaque scellement n'étant qu'un simple hash.
Puis-je rejouer et vérifier moi-même l'intégrité de tout l'historique du journal ?
Oui. L'historique se vérifie de bout en bout par recalcul des hashs successifs. Aucun compte ni accès à l'infrastructure 0DATA n'est nécessaire : la vérification est publique.
SPINA remplace-t-il une base immuable (immudb) ou un transparency log (Rekor/Trillian) ?
SPINA est un journal scellé tamper-evident (Merkle SHA-256 + ancrage). Il remplit la même fonction d'intégrité, avec en plus l'ancrage sur registre public Hedera et l'horodatage eIDAS — sans auto-héberger un serveur.
Où les empreintes du journal sont-elles ancrées, et à quelle périodicité ?
Les empreintes sont ancrées sur Hedera (Hedera Consensus Service), à périodicité configurable (quotidienne par défaut). L'ancrage rend l'intégrité vérifiable indépendamment de l'éditeur.
Comment intégrer SPINA à mon SI (API, SDK, collecte syslog) ?
Via API ou SDK, et par collecte des flux existants (syslog, événements applicatifs). La capture est passive : SPINA scelle ce que votre SI émet déjà, sans refonte.