Imprimer la blockchain ou comment survivre à un Événement Électromagnétique majeur


#22

Au contraire. Dans une boite où je suis passé, le resp du BE m’a même dit qu’ils étaient passés à la CAO avant tout parce qu’ils ne pouvaient plus archiver tous les plans (surtout que les évolutions ont multiplié les pages par 8 ou 10). Si des plans sont imprimés à l’atelier, c’est pour certains montages et ils sont ensuite détruits.
Le client reçoit des plans, sous version papier ou CD, mais nous on ne les garde que sur le serveur (avec sauvegarde certes, mais rien en papier).
Les anciens plans sont encore au sous-sol, mais en cas de besoin on les numérise, on les modifie sur PC, et on détruit les originaux.

C’est le problème des UNL : qui va les fournir ? Je n’ai pas prévu d’en donner, et si la Ğ1 demande un droit d’entrée obligatoire en UNL, elle devient dépendante et “adossée” à une autre monnaie (au lieu de n’être adossée qu’à l’humain).


#23

Bonsoir,
Désolé de relancer un sujet de 6 mois mais la question de la sauvegarde matérielle des données m’intéresse.

À l’heure où j’ai fait le calcul, la blockchain pesait 333553664 octets (300 Mo). Une fois gzippé, on a 106711870 octets (100 Mo). Si on copie la blockchain sur papier, par exemple des feuilles A4 21×29,7 avec 0,5 cm de marge à chaque bord et que chaque bit est représenté par un carré de 0,5 mm de côté (pour former un QR code géant), on a :
106711870×8 / (200×287×4) = 3718 pages au moins, sans compter les checksums. Et il serait prudent d’avoir plusieurs copies afin de gérer en cas de bavure.
Il faut aussi imprimer le code source de tous les logiciels nécessaires au fonctionnement de la monnaie (donc on rajoute quelques Go pour un système GNU, les firmwares des routeurs, BIOS, et tout ça).

Pour penser à la postérité, on peut estimer le nombre de pages à ajouter chaque jour (je ne prendrai pas en compte la croissance du nombre de membres) :
162000 blocs / 3718 pages = 43 blocs par page
24h × 60mn / 5mn = 288 blocs par jour
288 / 43 = 6,7 pages par jour

On peut aussi décider d’utiliser du CMYK, donc un point de couleur correspond à 2 bits (ou plus si on mélange les couleurs).
Après il peut être possible de graver les données dans une plaque de céramique ultra-résistante pour une meilleure densité, mais le bête DVD de 8 Go est probablement une bonne solution aussi, et plus simple…

Tout ça me fait penser à ce XKCD : https://what-if.xkcd.com/59/ (print Wikipedia)


#24

Pour info sur Durs la blockchain Ğ1 pèse actuellement 121,2 Mo. Je viens de la gzippé a l’instant pour voir : je suis à 54,9 Mo.
Donc déjà en optimisant le format de stockage des données on gagne environ 50% :grinning:


#25

Ça fait donc environ 1900 pages. Trop pour un particulier, mais si on commence par distribuer des livres faits à l’imprimerie :
Avec 0,004 cm d’épaisseur par page on peut faire deux volumes de 3,8 cm d’épaisseur pour la synchronisation du nœud, ensuite 3,35 pages par jour c’est faisable (mais bon comme un livre format poche de 1000 pages (4 cm) coûte dans les 30 €, celui-là en A4 devrait faire dans les 100 € et à ma connaissance aucun imprimeur près de chez moi n’accepte la Ğ1).
Sinon on peut distribuer le stockage, pour faire en sorte que chaque nœud détienne une partie de la blockchain (mais qu’elle puisse être entière dans chaque ville, avec un service de livraison par brouette pour vérifier des transactions rapidement).


#26

Le jour ou on bascule sur un protocole avec des nœuds léger, capable de fonctionner avec les 100 derniers blocks + 1 snapshot, on pourrais prévoir une export imprimable par semaine ou par mois, qui permettrais de faire un reboot en perdant l’historique lointain, mais avec un instantané récent identique entre chaque noeud puisque avec suffisamment de block de retard pour être le même quel que soit le fork courant du noeud, et du coup, avec un test d’intégrité du snapshot on peut vérifier que tout le monde à le même, et repartir de là.

On en est loin aujourd’hui, mais si on veut des exports papier pour le genre de scénario que tu indique, ça me semble une approche qui à bien plus de chance de rester acceptable dans le temps, si la Ǧ1 prend beaucoup d’ampleur.


#27

En fait c’est moins que ça, j’ai compté tout les fichiers persistants de Durs alors qu’il y a beaucoup d’index qui servent juste a pouvoir traiter les donnée beaucoup plus rapidement. La blockchain seule pèse 105,5 Mo (et une fois zippé plus que 42,3 Mo).

Sachant qu’on pourrait encore gagner de la place en supprimant des données qui peuvent être retrouvés par le calcul (les hashs). Ça me donne une idée de feature tiens, la possibilité de pouvoir exporter un backup condensé de la blockchain pourrait être intéressante :blush:


#28

Les seuls éléments peu compressibles sont les signatures et hashs. Ils ne se répètent pas vraiment. Par contre les clé publiques se réduisent très bien, et elles pèsent assez lourd dans le stockage actuellement.

Donc on doit pouvoir tomber assez bas en optimisant un peu.


#29

Avec 42,3 Mo et en recto-verso (technologie fort avancée que j’avais bêtement oubliée précédemment), j’arrive à 773 pages, et 1.37 pages par jour. Ça fait donc un gros livre A4, mais d’une épaisseur tout à fait raisonnable.

Tiens faudrait que je fasse un logiciel pour transformer un fichier en binaire imprimable, juste pour le fun.


#30

Et si on utilisait un système quinaire ?
On as la chance de pouvoir facilement utiliser ces valeurs :

Blanc
Bleu
Vert
Rouge
Noir

Vous en pensez quoi?

Il faudrait un outil mais ça me semble tout à fait faisable.


#31

Je lis qu’un code QR peut stocker 2.9 ko de données binaires sur wikipédia. Une chaîne de 55mo rentrerait donc sur environ 200 qrcodes non ?


#32

Je doute fortement que l’ont puisse facilement stocker 2.9 Ko et il faut prendre en compte l’espace sur le papier ainsi que l’effet de l’encre.

Par contre, un QR code est normalement binaire… Imagine un QR Code quinaire !?

Apparemment, ça s’appel un HCC2D …

Ou encore le CQR Code-5 :wink:


#33

C’est pas plutôt 18 950 qrcodes ?


#34

Hehe tu as raison :slight_smile:

Le CQR Code-5 ou 9 est une excellente piste en tout cas.

C’est assez incroyable la densité de données (2 à 3 ko pour 2.6 cm² :astonished: )


#35

Je comprend que le CQR Code-5 comprend 4.4 kb tendit que CQR Code-9 en comprend 6.6 kb. Après, en jouant sur la grosseur d’impression, on peut jouer sur la quantité d’ECC qu’on as besoin ! Pour les exemples donnés dans ce document, je trouve énorme la quantité de bit dédié à la parité…

Il faut aussi dire que c’est un papier qui prend en compte un scan par téléphone/caméra donc très à risque aux interférences… Je suppose que dans notre projet, il est considéré l’utilisation d’un numériseur ?

Si on prend un Canon CanoScan Lide 220 par exemple qui est un numériseur peu coûteux, on parle de 4800 dpi. On imagine imprimer en 1200 dpi. Ça veut dire que déjà par l’écart de dpi, le scan as 4 chances par dpi d’information de détecter correctement la bonne information. Ça réduit fortement la quantité d’ECC nécessaire !


#36

L’événement électromagnétique majeur aura potentiellement grillé le numériseur, il faut donc un support qui résiste le temps d’en remonter un, et des pixels assez gros pour que le nouveau numériseur, potentiellement grossier, puisse le lire quand même. 1200dpi me semble trop petit.


#37

Il ne faut pas oublier qu’il doit exister des blueprint dans certains bureau d’ingénieurs… Sans compté un certain nombre d’ingénieurs qui maîtrise ce domaine…

J’ai pris 1200 car ça me semble la limite technique mais dans la réalité, si on as plus de 225 (1 mm2 par carré.) carrés par pouces, ça vas me sembler pas mal fort… C’est un exemple que j’ai pris pour exprimer la non-utilité du ECC dans notre cas…


#38

Je préfère ne pas utiliser la couleur parce que c’est plus cher, plus lent, moins précis (si les plaques ne sont pas bien alignées comme ça arrive souvent dans les presses industrielles qui impriment chaque couleur séparément, tout est décalé), et si on utilise des couleurs non-primaires ça sera plein de petits points donc moins précis.
La technique que j’avais proposée est comme le QR code 4 ko, juste en plus grand…
De toute façon il faudra plus de feuilles que calculé précédemment, pour rajouter des entêtes :
un encadré pour l’humain, avec numéro de page, nom du fichier, commentaires ; un encadré de métadonnées (donc codé en binaire) avec numéro de page, checksum, encodage et tout ça, le nombre de bits par ligne et le nombre de lignes ; un encadré de données.
Ensuite il faut fabriquer un ordinateur et une caméra capables de fonctionner malgré un champ électronique puissant… Est-ce qu’il suffit de faire des câbles plus gros ? Genre ça ou ça ?


#39

Faire des câbles + gros fonctionne en théorie, mais ça a plusieurs limites :

  • les milliards de transistors d’un microprocesseur standard ne peuvent pas être câblés à la main, et à moins d’être milliardaire aucune usine ne sortira un processeur “grossi”. Il faut regardé du coté militaire mais les surcoûts me paraissent tellement énorme que personne n’a du essayer (je me trompe peut-être).
  • si on ne miniaturise pas, on perd en vitesse, donc encore un coup de pied dans les perfs,
  • un capteur pour numériser, s’il est assemblé à la main, sera incapable de lire du 1200dpi. Comme ça, là, je dirai que 0.5mm est une résolution “atteignable sans industrie”, soit 50dpi.

Donc n’espérons pas avoir des GHz à perdre ou une résolution de fou, c’est retour en 1950.
Ou alors il faut protéger du matos aujourd’hui, et le ressortir quand l’orage sera passé, mais gare à la panne car pas de pièce de rechange (et je t’avoue que le moment venu, un processeur moderne fonctionnel vaudra bien plus que tout l’avantage monnaie > troc dans un monde post-apo).


#40

On peut refaire l’histoire de l’industrie de l’électronique, mais avec déjà tous les savoirs : on commence par faire une machine pour fabriquer des CI, avec ces CI on fabrique une machine électronique plus précise, puis encore et encore… Ça ne demande que de revenir 50 ans en arrière, et la recherche est déjà faite.


#41

Oui, mais cela dépend si tu as besoin de la Ğ1 avant ou après avoir reconstruit ton industrie.
J’ai considéré qu’on serait un poil pressé de réutiliser, car si on met 40 ans autant recommencer une blockchain à partir de 0 ^^.