Quelle est la différence entre politique et consensus en ce qui concerne les scripts de validation d'un nœud Bitcoin Core ?

alors le bloc est valide.

Les vérifications de politique sont un sur-ensemble de vérifications de consensus (ce qui signifie que les vérifications de politique s’ajoutent aux vérifications de consensus, de sorte que la réussite des vérifications de politique implique la réussite des vérifications de consensus), et les vérifications de politique ne s’appliquent qu’aux transactions envisagées pour être ajoutées au mempool. Le but des contrôles de politique est généralement (a) de fermer les vecteurs DoS et (b) de rendre le déploiement des futurs changements de consensus plus sûr, en empêchant le relais de transactions qui violeraient ces futurs changements de consensus bien à l’avance.

Vous posez spécifiquement des questions sur les vérifications de script de transaction, mais notez qu’il existe de nombreuses vérifications de politique (et de consensus) sur les transactions qui se produisent en dehors de la simple validation de script. De plus, les liens de votre question renvoient aux sous-répertoires « policy/ » et « consensus/ » dans l’arborescence des sources de Bitcoin Core, mais de nombreuses vérifications de politique et de consensus se produisent en dehors de ces répertoires.

Voici quelques exemples de contrôles de politique dans la validation de script, qui ne sont pas (encore) des contrôles de consensus. Ces premières sont issues de BIP62, qui proposait un ensemble de règles pour limiter la malléabilité des transactions.

Voici quelques vérifications de politique relatives à la sécurisation du déploiement de softfork à l’avenir  :

Et puis, bien sûr, tous les futurs changements de consensus (tels que les changements de racine pivotante) qui n’ont pas encore été activés sur le réseau sont également des contrôles de politique. Une liste (presque) complète des contrôles de validation de script de transaction effectués dans le cadre des contrôles de politique lorsqu’une transaction est en cours de validation pour le mempool est disponible ici. (Notez que cette liste comprend également des vérifications de consensus.)

dont certains dépendent des scripts d’une transaction. Voici quelques exemples  :

• Les dépenses non p2sh et non segwit doivent être P2PKH, P2PK ou bare multisig
• scriptSig ou témoin ne doit pas dépasser une taille donnée

doit être P2SH/v0 segwit/P2PKH/P2PK/MULTISIG, la valeur doit être supérieure au seuil de poussière)

• Limites sur le nombre de contrôles de signature effectués par la transaction

Il y en a beaucoup à énumérer, mais le traçage du code dans l’acceptation mempool (en particulier ici) et l’inspection de fonctions telles que CheckTransaction, IsStandardTx et CheckTxInputs devraient générer les vérifications de script de politique restantes, en plus de celles appliquées dans l’interpréteur de script.

Les contrôles de consensus de script de transaction sont un ensemble beaucoup plus petit. Certains des indicateurs de script qui sont désormais des vérifications de consensus incluent  :

• P2SH
• DERSIG
• NULLDUMMY
• CHECKLOCKTIMEVERIFY
• CHECKSEQUENCEVERIFY
• TÉMOIN

La liste complète (avec les conditions d’activation) peut être consultée ici. Notez que comme les règles de consensus ont changé dans l’histoire de Bitcoin, tous les indicateurs de script mentionnés dans cette fonction ne sont pas activés sur tous les blocs.

La plupart (tous ?) des contrôles de consensus restants effectués sur les transactions se trouvent dans ConnectBlock(), CheckBlock() et ContextualCheckBlock().