Le staking du Bitcoin : aperçu technique et analyse de sécurité
TechFlow SélectionTechFlow Sélection
Le staking du Bitcoin : aperçu technique et analyse de sécurité
À l'avenir, Chakra collaborera avec Babylone pour organiser une série d'activités de mise en gage afin d'offrir aux utilisateurs des rendements multiples.
Dédié à des analyses Web3 approfondies
Récemment, Babylon a lancé une campagne de mise en gage (staking) de Bitcoin sur son Testnet-4, suscitant des discussions au sein de la communauté autour du staking du Bitcoin. Aujourd'hui, l'équipe de recherche Chakra vous propose d'explorer les dernières solutions de staking du Bitcoin.
Dans le récent Testnet-4 de Babylon, le processus de staking est divisé en trois types de transactions : transaction de staking (Staking Tx), transaction de déliaison (Unbonding Tx) et transaction de sanction (Slashing Tx). Ces transactions génèrent respectivement trois types de sorties Bitcoin : sortie de staking (Staking Output), sortie de déliaison (Unbonding Output) et sortie de sanction (Slashing Output). Le processus de conversion est illustré ci-dessous.
Transaction de staking
Une transaction de staking doit inclure deux sorties spéciales. L'une est une sortie Taproot qui détient les actifs mis en jeu, et qui doit contenir le script de staking BTC défini par Babylon. L'autre est une sortie à montant nul, qui utilise OP_RETURN pour stocker des informations identifiables relatives au staking Babylon.
L'image ci-dessous montre un exemple de transaction de staking, où la première sortie est la sortie de staking, la deuxième est la sortie OP_RETURN, et la troisième est la sortie de monnaie rendue.
Sortie de staking
La sortie de staking est une sortie Taproot. Comme mentionné dans un article précédent de Chakra :
Une sortie Taproot offre deux méthodes de paiement : le chemin de paiement par clé et le chemin de paiement par script. Babylon désactive le chemin de paiement par clé en définissant la clé interne comme étant un point “Nothing Up My Sleeve” (NUMS), obligeant ainsi toute dépense de la sortie de staking à passer par le chemin de script.
La sortie de staking peut être dépensée via trois chemins de script, correspondant au diagramme du processus :
1. Chemin de verrouillage temporel
Le chemin de verrouillage temporel implémente la fonctionnalité de staking et sert également de garantie d'activité.
<Staker_PK> OP_CHECKSIGVERIFY <Timelock_Blocks> OP_CHECKSEQUENCEVERIFY
Ce script verrouille les BTC du validateur pendant un certain nombre de blocs. Ce chemin ne nécessite aucune entité tierce, offrant ainsi une garantie d'activité au staker. Même si les fournisseurs de finalité et le comité de pacte deviennent inactifs, le staker peut toujours récupérer ses BTC après la période de verrouillage.
2. Chemin de déliaison
Si les BTC sont verrouillés par un timelock, comment l'utilisateur peut-il mettre fin prématurément au staking ? Babylon résout ce problème en introduisant le chemin de déliaison.
<StakerPk> OP_CHECKSIGVERIFY
<CovenantPk1> OP_CHECKSIG <CovenantPk1> OP_CHECKSIGADD ... <CovenantPkN> OP_CHECKSIGADD
<CovenantThreshold> OP_GREATERTHANOREQUAL
Ce chemin nécessite non seulement la signature du staker, mais aussi celles d’un nombre de membres du comité de pacte supérieur ou égal au seuil CovenantThreshold. L'introduction du comité de pacte vise principalement à créer artificiellement une période de déliaison, empêchant ainsi le staker d’éviter les sanctions via ce chemin.
3. Chemin de sanction
Pour assurer la sécurité du PoS, les sanctions sont nécessaires. Si un fournisseur de finalité agit malicieusement, il faut confisquer ses fonds propres et délégués afin d’assurer la sécurité économique. Babylon introduit le chemin de sanction pour permettre cette fonctionnalité.
<StakerPk> OP_CHECKSIGVERIFY
<FinalityProviderPk> OP_CHECKSIGVERIFY
<CovenantPk1> OP_CHECKSIG <CovenantPk1> OP_CHECKSIGADD ... <CovenantPkN> OP_CHECKSIGADD
<CovenantThreshold> OP_GREATERTHANOREQUAL
Avant que l’état de staking ne passe à Actif, le staker doit pré-signer la transaction du chemin de sanction, afin d’éviter qu’il retienne sa signature en cas de comportement malveillant du fournisseur de finalité, ce qui pourrait entraîner une perte de BTC. Après avoir reçu la signature du staker, le comité de pacte vérifie d'abord celle-ci ; une fois validée, il libère alors sa propre signature.
Dans le staking BTC, l'acte sanctionnable est lorsqu'un fournisseur de finalité signe deux blocs conflictuels à la même hauteur. Dans ce cas, n'importe quel utilisateur peut obtenir la clé privée du fournisseur de finalité malveillant via EOTS. Puisque le staker et le comité ont déjà pré-signé la transaction de sanction, un utilisateur disposant de la clé privée peut signer la transaction et utiliser le chemin de sanction pour envoyer une partie des fonds mis en jeu vers une adresse de brûlage comme punition.
Sortie OP_RETURN
Bien que la sortie Taproot permette d'exprimer des conditions d'utilisation complexes avec des ScriptPubKeys compacts, cela rend difficile la distinction entre transactions de staking et autres transactions sur le réseau Bitcoin. Il est donc nécessaire de divulguer autrement les informations liées au staking, afin que les utilisateurs puissent identifier les transactions de sanction.
Babylon sérialise les informations à divulguer, les intègre dans un script OP_RETURN, puis les attache comme une autre sortie de la transaction de staking. Le format est illustré ci-dessous, et les données doivent correspondre à celles présentes dans le script Taproot.
type V0OpReturnData struct {
MagicBytes []byte
Version byte
StakerPublicKey []byte
FinalityProviderPublicKey []byte
StakingTime []byte
}
D'après les instantanés de transactions précédents, les données utiles portées par la sortie OP_RETURN totalisent effectivement 4+1+32+32+2 = 71 octets. Sur l'image, la clé publique FinalityProviderPublicKey de la transaction de staking est f4940b238dcd00535fde9730345bab6ff4ea6d413cc3602c4033c10f251c7e81, appartenant à Chakra.
Les MagicBytes servent à localiser rapidement les transactions de staking, tandis que le champ Version est réservé pour de futures mises à jour, permettant de distinguer les versions.
Transaction de déliaison
Lorsqu’un staker souhaite débloquer prématurément ses BTC mis en jeu, il peut soumettre une transaction de déliaison en dépensant le chemin de déliaison depuis la sortie de staking. La transaction de déliaison doit accepter une seule transaction de staking comme entrée, et produire une unique sortie vers un script de déliaison en Taproot.
Voici une capture d’écran de la transaction de déliaison, correspondant à la sortie de staking précédente.
Parmi les champs, celui se terminant par '20' est le tapscript du chemin de déliaison, tandis que celui commençant par 'c1' correspond à la preuve de Merkle combinant la clé interne Taproot et le chemin de déliaison, où l'on peut clairement observer le point NUMS 0x50929b74c1a04954b78b4b6035e97a5e078a5a0f28ec96d547bfee9ace803ac0. Dans le champ Witness de la transaction de déliaison, on observe les signatures du staker et du comité de pacte.
La sortie de déliaison peut être dépensée selon deux conditions : le chemin de verrouillage temporel et le chemin de sanction, identiques à ceux de la sortie de staking. À un niveau supérieur, la sortie de déliaison constitue un état intermédiaire conçu pour empêcher le staker de retirer immédiatement ses fonds et d’éviter les sanctions, conduisant finalement à un état stable via une transaction de retrait.
Transaction de sanction
La transaction de sanction prend en entrée une transaction de staking ou de déliaison, la dépense via le chemin de sanction du script Taproot, et produit deux sorties. L'une envoie une partie des BTC mis en jeu vers une adresse de brûlage, l'autre renvoie le solde restant au staker.
Plus précisément, Babylon applique une confiscation partielle en cas de comportement fautif, plutôt que de brûler immédiatement tous les BTC mis en jeu par le staker. Cette approche offre une meilleure tolérance aux erreurs et protège les intérêts du staker.
La transaction de sanction ne peut être exécutée qu’avec les signatures conjointes du staker, du comité de pacte et du fournisseur de finalité. Ainsi, même si une partie est compromise, cela n'entraînera pas l'effondrement du système de staking. La transaction de sanction joue un rôle dissuasif, décourageant économiquement tout comportement malveillant. Tant que la sanction excède tout gain potentiel, les participants ont intérêt à respecter les règles.
Analyse de sécurité
La sécurité associée à Babylon comporte deux aspects :
Le premier concerne la sécurité du staker : tant que ni lui ni le fournisseur de finalité qu'il délègue ne commettent aucun acte malveillant, ses actifs mis en jeu ne seront jamais sanctionnés.
Le second concerne la sécurité du système PoS lui-même : il doit être capable d'identifier et de sanctionner tout comportement malveillant des participants.
Point de vue du staker
Pour le staker, une fois que ses BTC sont mis en jeu via une transaction Babylon, ses fonds ne peuvent être transférés que de trois manières.
Premièrement, via le chemin de verrouillage temporel, qui ne nécessite que sa propre signature. Cela garantit que, même si le FP et Babylon cessent leurs activités, le staker pourra récupérer ses BTC après la période de verrouillage.
Deuxièmement, via le chemin de déliaison, qui crée un état intermédiaire (sortie de déliaison) et autorise un temps de déverrouillage plus court, permettant ainsi au staker de récupérer ses fonds plus tôt.
Troisièmement, via le chemin de sanction, le seul pouvant nuire aux intérêts du staker. Pour qu’un tiers puisse attaquer ce chemin, il devrait fournir simultanément la signature du staker, celle du fournisseur de finalité et celles d’un nombre de membres du comité de pacte dépassant le seuil requis — ce qui est extrêmement difficile. Même en cas de comportement malveillant du comité de pacte, tant que le fournisseur de finalité reste honnête, les BTC du staker restent sécurisés.
Point de vue du système PoS
Du point de vue du système PoS, la sécurité repose sur la capacité à sanctionner les fournisseurs de finalité en cas de comportement malveillant.
Babylon utilise le mécanisme EOTS : si un fournisseur de finalité signe doublement un bloc, tout utilisateur peut extraire sa clé privée à partir des deux signatures différentes. Il peut alors signer et soumettre une transaction de sanction, punissant partiellement les BTC correspondant à l'ensemble des droits de vote détenus par ce fournisseur.
Cette mesure dissuasive aligne les incitations des fournisseurs de finalité avec leur rôle de sécurisation de la finalité pour le consensus PoS connecté à Babylon, assurant ainsi la sécurité des systèmes PoS disposant d’un grand volume total mis en jeu (TVL).
À l’avenir, Chakra continuera de collaborer avec Babylon pour organiser une série d’activités de staking, offrant aux utilisateurs des rendements multiples, tout en résolvant les défis liés à la liquidité et à l’interopérabilité, afin de libérer tout le potentiel du Bitcoin dans l’ensemble des écosystèmes cryptographiques.
Bienvenue dans la communauté officielle TechFlow
Groupe Telegram :https://t.me/TechFlowDaily
Compte Twitter officiel :https://x.com/TechFlowPost
Compte Twitter anglais :https://x.com/BlockFlow_News
@ChakraChain
