Parfois c’est un peu plus que ça : A Polkadot Postmortem - 24.05.2021
Un exemple ou la différence entre runtime wasm et runtime natif a posé problème 
1 Like
Certes mais ce n’est pas un cas nominal
Utiliser le Runtime natif en temps normal permet juste de gagner en performances et donc d’effectuer plus de traitements (en Idle, en Offchain worker, …).
Très intéressant en tout cas ce post-mortem, un bel enseignement à tirer, je bookmarke.
gagner en performances et donc d’effectuer plus de traitements
Est-ce que tu en es sûr ? Ce n’est pas parce qu’une machine utilise le runtime natif que c’est le cas de toutes. Si un bloc a un poids cumulé trop élevé, il se peut que d’autres nœuds n’arrivent pas à le rejouer à temps. Je n’ai pas du tout creusé cet aspect.
Ce paramètre devrait faire partie de la définition de la machine minimale.
Polkadot prévoit de peut-être ne plus utiliser de runtime natif. Il permet de doubler les perfs, mais augmente le risque de non-déterminisme (et j’imagine aussi de failles de sécurité). L’OOM ne devrait pas nous concerner (il faudrait tout de même vérifier que toutes les listes non bornées (genre certifs reçues) ne risquent pas d’exploser).
On pourra considérer cela quand le WASM/RPi ne suffira plus, mais on devrait avoir largement assez de puissance pour un certain temps. En plus avec la règle de distance hors-chaîne.
1 Like
Le contraire serait illogique : les poids sont calibrés sur une machine de référence afin d’assurer qu’un bloc soit produit en un temps maximal, c’est bien pour effectuer un raisonnement au pire. De sorte que toute amélioration de ces performances pour une raison externe (meilleure machine, utilisation du Runtime natif) soit seulement un bonus.
Sinon le temps de génération de bloc risquerait de déborder fréquemment, avec toutes les conséquences sur le consensus et donc sur la viabilité de la blockchain.
Je comprends, ça m’embête pour le déboggage car ça signifie que l’exécution Wasm deviendrait plus difficilement vérifiable par un développeur.
Selon ce que j’avais compris, les poids étaient calibrés sur une machine de référence afin d’assurer que toute machine au moins aussi puissante puisse exécuter un bloc dans le temps imparti. Si un validateur remplit un bloc au delà de la limite de poids, il y a un risque qu’un autre ne puisse pas exécuter le bloc dans le temps imparti.
Je croyais que l’idée du raisonnement “au pire” était purement algorithmique, c’est-à-dire pour donner avant l’exécution une borne haute sur le poids d’exécution, compté en nombre d’opérations élémentaires (nombre de lectures / écritures, instructions cpu).
Si une machine se met à remplir un bloc plus que prévu parce qu’elle a des performances plus élevées, comment s’assurer que le réseau va suivre ?
Le remplissage du bloc n’est pas calculé sur le temps d’exécution local, mais sur la somme des poids de son contenu.
Je ne sais pas comment sont gérées les piscines, mais j’imagine qu’une machine plus puissante que la référence, traitant un bloc plein, utilisera seulement une partie de ses 2s, mais attendra quand même les 2s avant de publier (ou 4s ou autre seuil pour la synchro inter-nœuds et pouvoir attendre de nouveaux extrinsics).
Le validateur ne peut pas faire ça, non. J’ai utilisé le mauvais exemple tout à l’heure en mentionnant “en Idle” pour les traitements supplémentaires, car justement on_idle vient consommer le poids restant du bloc.
Par contre mon 2ème exemple, les offchain workers, là c’est du temps libre CPU qui peut être exploité par la machine sans jamais impacter les autres clients. Ce temps ne serait pas forcément disponible avec le Runtime Wasm, alors qu’il peut l’être avec le natif.
1 Like
Oui, tout à fait d’accord que les ressources non utilisées par la blockchain peuvent l’être par d’autres processus qui tournent sur la même machine. Mais il faut quand même que le thread cpu qui exécute le runtime ait la priorité sur les autres, de manière à ce que la puissance disponible ne tombe pas en dessous de la puissance de référence. Ce sont des questions que peut se poser le validateur, mais ça ne concerne pas directement le développeur. Publier un exécutable avec un runtime natif à jour n’est pas une obligation, mais une option donnée aux personnes qui veulent limiter la puissance cpu réellement consommée par Duniter-v2s sur leur machine.
Oui, à voir si l’on souhaite faciliter sa mise à disposition ou pas.
Pour l’instant, compte tenu de la faible charge de la Ğ1 et du bug d’indéterminisme (post-mortem Polkadot), il semble plus sage de ne pas promouvoir ce Runtime natif.
1 Like