C’est une sauvegarde incrémentale. Donc à priori, à un petit delta prêt (les méta données de chaque sauvegarde), la totalité des backups fait le même poids que les dernières données sauvegardées.
La plupart des choix sont des best-practices. Même des choses qui peuvent sembler très nouvelles font finalement intervenir des recettes classiques. Je pense notamment au fait d’utiliser une file de messages entre l’API Web - qui doit répondre en quelques millisecondes - et la blockchain - qui répond au mieux en quelques secondes.
Là ou il doit y’avoir une discussion je pense c’est sur le point « 4. Meilleure sécurisation du smart contract de vote ». Les implications sont bien plus larges que leur seul aspect technico-technique. Pour faire simple :
- A - une blockchain « publique » permet nécessairement de pouvoir librement consulter toutes les transactions de bulletin de vote faites vers un contrat de vote en particulier ; et donc de reconstituer les résultats du vote avant qu’il ne soit terminé. Mais…
- B - une blockchain « privée » ne permet pas du tout de consulter les transactions de bulletin de votes ou l’urne numérique, et nous prive donc de l’intérêt essentiel de la blockchain.
A lire sur le sujet (notamment le point 3) :
Why Many Smart Contract Use Cases Are Simply Impossible
Hiding data in a smart contract is about as secure as hiding it in
the HTML code of a web page. Sure, regular web users won’t see it,
because it’s not displayed in their browser window. But all it takes is
for a web browser to add a ‘View Source’ function (as they all have),
and the information becomes universally visible.
Similarly, for data hidden in smart contracts, all it takes is for
someone to modify their blockchain software to display the contract’s
full state, and all semblance of secrecy is lost.
A half-decent programmer could do that in an hour or so.
Et quand il dit « an hour or so » il est gentil, par ce que ça prend quasiment qu’une seule ligne de code… Donc c’est 59 minutes à boire un café et 1 minute à coder.
En conclusion on a choisi la blockchain pour être dans le cas A, pour des raisons de confiance, de transparence et de fiabilité. Mais le cas A implique que n’importe qui peut connaitre les résultats du vote en temps réel, ce qu’on ne veut à priori pas pour éviter un biais. Même si on décide nous de ne pas les afficher, ils sont techniquement consultables et d’autres pourraient décider de les afficher.
Je ne vais pas rentrer dans le détail, mais j’en suis venu à la conclusion que c’est mathématiquement impossible : toute solution qui permet de ne pas avoir les résultats accessibles en temps réel va nécessairement rendre opaque la procédure de vote/le contenu de l’urne numérique, et donc sacrifier la transparence/confiance/fiabilité/neutralité du système.
Il faut donc entamer un travail pour soit :
- démontrer que c’est faux ;
- se mettre d’accord sur cet état de fait et arriver à trouver des paliatifs.
Concernant le 1, je place peu d’espoirs. Quand je dis « mathématiquement impossible » ci-dessus, je le pense littéralement : je pense qu’on peut littéralement écrire la preuve mathématique.
Il faudrait surement créer un sujet séparé là dessus et faire un atelier.