@cgeek bon ça fait 4 soirs que je me prends un mur avec mocha, pour une raison que j’ignore le check de la sig de la preuve dans un worker bloque, l’appel a la fonction verify ne retourne jamais, la fonction est appelée puis…le programme bloque et ne rend jamais la main, on est alors obligé de le tuer.
Plus précisément :
mocha sur le seul fichier test/fast/prover/prover-pow-1-cluster.js
-> bloque.
débogueur vscode sur le seul fichier test/fast/prover/prover-pow-1-cluster.js
-> bloque.
mocha all tests -> tous les tests dans test/fast/prover/prover-pow-1-cluster.js
échouent sauf le premier.
Je ne peux pas déboguer cette partie avec vscode, quand je place un breakpoint sur la ligne app/modules/prover/lib/proof.ts:216
le debuggeur ne l’atteint jamais (à mon avis c’est le côté multi-thread qui n’est pas géré comme il faut par le déboguer de vscode).
De plus, si je commente les lignes 215 à 220 inclus, tout refonctionne normalement, tous les tests passent.
Enfin, si j’appelle la fonction verify puis que je force a true la valeur de sigOk, comme ceci :
if (found) {
let sigOk = verifyFunc(raw, sig);
sigOk = true;
if (!sigOk) {
found = false;
}
}
Alors le programme bloque et ne rend jamais la main. Ce n’est donc pas que la fonction verify renverrait false, la fonction verify ne rend pas la main.
Plus troublant encore, le problème est spécifique aux tests, quand je déploie mon noeud de dev sur la g1-test j’arrive à trouver des blocs, il ne bloque pas à l’appel de la fonction verify :
2020-01-23T23:04:32+01:00 - info: ENGINE c#0#3 HAS FOUND A PROOF #000241A6331FEB976CCB9F508F07B26AB30BD34A4F32B7E59BDFC6B0AD75DEAD
2020-01-23T23:04:32+01:00 - info: Matched 3 zeros 000241A6331FEB976CCB9F508F07B26AB30BD34A4F32B7E59BDFC6B0AD75DEAD with Nonce = 10099900001233 for block#506074 by 42jMJt
2020-01-23T23:04:32+01:00 - info: Done: #506074, 000241A6331FEB976CCB9F508F07B26AB30BD34A4F32B7E59BDFC6B0AD75DEAD in 5.57s (~9856 tests, ~1769.80 tests/s, using 8 cores, CPU 60%)
2020-01-23T23:04:32+01:00 - info: FOUND proof-of-work with 3 leading zeros followed by [0-6]!
2020-01-23T23:04:32+01:00 - info: SIDE Block #506074-000241A6 added to the blockchain in 0 ms
2020-01-23T23:04:32+01:00 - info: Block resolution: 1 potential blocks after current#506073...
2020-01-23T23:04:32+01:00 - info: Block #506074 added to the blockchain in 14 ms
2020-01-23T23:04:32+01:00 - trace: PoW loops = 4
2020-01-23T23:04:32+01:00 - info: Block resolution: 0 potential blocks after current#506074...
2020-01-23T23:04:32+01:00 - warn: Waiting 0ms before starting to compute next block...
2020-01-23T23:04:32+01:00 - trace: PoW loops = 5
2020-01-23T23:04:32+01:00 - info: Generating proof-of-work with 7 leading zeros followed by [0-9A-D]... (CPU usage set to 60%) for block#506075 42jMJt
2020-01-23T23:04:39+01:00 - info: [42jMJtb8] ⬇ PEER 42jMJtb8 506044-0
2020-01-23T23:04:39+01:00 - info: [42jMJtb8] ✔ PEER 42jMJtb8 506044-0
2020-01-23T23:04:39+01:00 - info: [42jMJtb8] ⬇ PEER 42jMJtb8 506044-0
2020-01-23T23:04:55+01:00 - info: Matched 3 zeros 00013C808392D83FF1DAE344E319691D9BD5581EAEACFFBBCE167B17982391DF with Nonce = 10099900005970 for block#506075 by 42jMJt
2020-01-23T23:04:55+01:00 - info: Matched 3 zeros 00013C808392D83FF1DAE344E319691D9BD5581EAEACFFBBCE167B17982391DF with Nonce = 10099900005970 for block#506075 by 42jMJt
2020-01-23T23:04:59+01:00 - info: Matched 3 zeros 000BF259F6D78321A6E5DDF555CC0605E691479AEA623F00E849738E942464A2 with Nonce = 10099900006616 for block#506075 by 42jMJt
2020-01-23T23:04:59+01:00 - info: Matched 3 zeros 000BF259F6D78321A6E5DDF555CC0605E691479AEA623F00E849738E942464A2 with Nonce = 10099900006616 for block#506075 by 42jMJt
2020-01-23T23:04:59+01:00 - info: Matched 3 zeros 000BF259F6D78321A6E5DDF555CC0605E6
Oui la diff est très faible sur g1-test en ce moment ça m’arrange bien pour mes tests
Ce comportement bizarre des tests auto. est au delà de mes compétences, ça fait 4 jours que j’essaye et je n’ai aucune piste ni aucune explication
Il semblerait que le NodeJs reste hélas un écosystème qui m’échappe, c’est pas faute d’essayer pourtant, mais je ne bloque jamais autant et aussi longtemps en Java ou en Rust
Je vois bien une solution de contournement, j’aimerais savoir ce que tu en penses :
On pourrait laisser proof.ts
inchangé mais seulement utilisé la fonction verify non buggée en validation locale des blocs v12. Ainsi, si le noeud génère par malchance un bloc avec sig invalide (1 chance sur 2^64), il va refuser son propre bloc, est ce que ça te semble ok comme solution ?