Glossaire

Basé sur l’annexe A du livre « Due Diligence d’un Layer 2 – Le cas Bitcoin Hyper », de Michele Stefanelli. 33 entrées réparties en 12 catégories.

33 entrées

Ancrage (anchoring)

Règlement

Publication périodique d’un state commitment du rollup sur la couche de base de Bitcoin. L’ancrage enregistre un engagement d’état et permet de détecter des modifications ultérieures, mais il ne garantit pas à lui seul l’exactitude de l’état, la disponibilité des données ni la sécurité du bridge.

Chap. 11–12

OP_RETURN

Bitcoin L1

Opcode du langage de script de Bitcoin permettant d’insérer jusqu’à 80 octets de données arbitraires dans une transaction, en rendant la sortie de manière démontrable non dépensable. Il peut être utilisé pour ancrer des state commitments.

Chap. 12

Taproot

Bitcoin L1

Mise à niveau de Bitcoin (BIP 341/342, activée en novembre 2021) introduisant les signatures Schnorr et MAST. Elle améliore la confidentialité, l’efficacité et la flexibilité des scripts et présente un intérêt pour des mécanismes d’ancrage plus efficaces.

Chap. 12

UTXO

Bitcoin L1

Unspent Transaction Output (sortie de transaction non dépensée). Modèle comptable de Bitcoin : au lieu de « comptes », il existe des « sorties non dépensées » correspondant à des montants précis. Il diffère du modèle de comptes utilisé par la SVM et Ethereum.

Chap. 1

Rollup

Layer 2

Solution Layer 2 qui exécute les transactions hors chaîne et publie périodiquement un état compressé sur la couche de base (L1). Elle combine la scalabilité hors chaîne avec une sécurité qui, selon le modèle adopté, s’appuie sur la L1.

Chap. 4–6

Sidechain

Layer 2

Blockchain indépendante reliée à la L1 par un bridge. Sa sécurité dépend principalement de son propre mécanisme de consensus et de la conception du bridge, et non directement de la sécurité de la L1.

Chap. 4

Validium

Layer 2

Architecture proche d’un rollup dans laquelle les données nécessaires à la reconstruction de l’état sont conservées hors de la L1. Elle peut réduire les coûts et accroître la capacité, mais introduit des hypothèses supplémentaires de disponibilité des données : si celles-ci deviennent inaccessibles, les utilisateurs peuvent perdre la capacité de vérifier l’état ou de retirer leurs fonds.

Chap. 14

Optimistic Rollup

Layer 2

Rollup qui considère par défaut que les transitions d’état sont valides — d’où le terme « optimiste ». Il s’appuie sur des preuves de fraude permettant de contester les transitions incorrectes pendant une fenêtre temporelle, généralement de sept jours sur Ethereum.

Chap. 6

ZK Rollup

Layer 2

Rollup utilisant des preuves de validité — souvent fondées sur la cryptographie à divulgation nulle de connaissance — pour démontrer que les transitions d’état respectent les règles du protocole. Il peut réduire les délais de confirmation par rapport à un optimistic rollup, même si la finalité effective dépend également de la L1 et de la conception du système.

Chap. 6

SVM (Solana Virtual Machine)

Exécution

Runtime d’exécution développé par Solana Labs. Il permet l’exécution en parallèle en exigeant que chaque transaction déclare explicitement les comptes qu’elle utilise. Selon le projet, Bitcoin Hyper l’emploie comme environnement d’exécution.

Chap. 7–8

Sealevel

Exécution

Runtime de parallélisation de la SVM. Il analyse les comptes déclarés par chaque transaction et permet d’exécuter en parallèle celles qui n’entrent pas en conflit. Il constitue l’un des éléments contribuant aux performances de Solana et, selon le projet, de la conception prévue pour Bitcoin Hyper.

Chap. 8

Anchor

Exécution

Framework Rust destiné au développement de programmes SVM. Il ajoute des macros, des conventions et des outils de test facilitant le développement sur Solana. Selon le projet, Bitcoin Hyper entend proposer une chaîne d’outils similaire ; la compatibilité réelle devra être vérifiée.

Chap. 9

SPL (Solana Program Library)

Exécution

Bibliothèque de programmes standards sur la SVM : tokens (SPL Token), staking, gouvernance, entre autres. Selon le projet, Bitcoin Hyper vise la compatibilité avec SPL, ce qui permettrait de réutiliser des tokens et des programmes de Solana.

Chap. 9

Sequencer

Séquencement

Composant du rollup qui ordonne les transactions avant leur exécution. L’entité qui contrôle le sequencer peut déterminer cet ordre, avec des implications en matière de MEV et de censure. Au lancement de Bitcoin Hyper, il est prévu qu’il soit centralisé.

Chap. 15–17

MEV (Maximal Extractable Value)

Séquencement

Valeur pouvant être extraite en réordonnant, insérant ou omettant des transactions au sein d’un bloc ou d’un lot. Un sequencer centralisé peut disposer d’une capacité importante à capter ou influencer le MEV du rollup.

Chap. 15

Inclusion forcée (forced inclusion)

Séquencement

Mécanisme permettant aux utilisateurs de « forcer » l’inclusion d’une transaction via la L1 de Bitcoin, en contournant un sequencer qui exercerait une censure. Dans Bitcoin Hyper, cette fonction était encore en développement au 28/04/2026.

Chap. 21

Canonical Bridge

Bridge

Bridge officiel de Bitcoin Hyper permettant de transférer des BTC de la L1 vers le rollup et inversement. Au lancement : conservation fédérée ou centralisée, avec les hypothèses de confiance que cela implique. La feuille de route prévoit une décentralisation progressive, qui reste à vérifier.

Chap. 31, 34

Sortie forcée (forced exit)

Bridge

Mécanisme permettant aux utilisateurs de retirer leurs fonds du rollup même lorsque le sequencer ou le bridge ne coopèrent pas, en utilisant la L1 de Bitcoin. Il s’agit d’une fonction de sécurité critique, encore en développement.

Chap. 21

Disponibilité des données (data availability, DA)

Disponibilité des données

Garantie que les données de toutes les transactions sont accessibles publiquement. Si les données manquent, personne ne peut reconstruire l’état du rollup. Dans Bitcoin Hyper, la solution définitive reste à l’étude.

Chap. 14

State Commitment

Règlement

Représentation compressée — généralement une racine de Merkle — de l’état complet du rollup à un instant donné. Elle est publiée périodiquement sur Bitcoin comme ancrage ; sa publication n’équivaut pas à une vérification complète de l’état.

Chap. 11

Arbre de Merkle (Merkle tree)

Cryptographie

Structure de données arborescente dans laquelle chaque nœud parent correspond au hash de ses nœuds enfants. Elle permet des preuves efficaces — preuves de Merkle — d’inclusion de données sans révéler l’ensemble complet.

Ann. A

$HYPER

Tokenomics

Token que la documentation du projet présente comme natif de Bitcoin Hyper. L’offre totale annoncée est de 21 milliards. Selon la documentation publiée, son utilisation est prévue pour payer les frais, participer au staking et, à un stade ultérieur, aux mécanismes de gouvernance. L’allocation annoncée est la suivante : 25 % Trésorerie, 30 % Développement, 20 % Marketing, 15 % Récompenses et 10 % Cotations.

Chap. 30–33

Vesting

Tokenomics

Mécanisme de libération progressive des tokens au fil du temps. Selon les conditions publiées pour la prévente, $HYPER aurait une période de vesting de sept jours.

Chap. 33

TGE (Token Generation Event)

Tokenomics

Événement au cours duquel un token est créé et distribué initialement. Selon le livre blanc, les audits de sécurité doivent être achevés avant le TGE de Bitcoin Hyper.

Chap. 33

TVL (Total Value Locked)

DeFi

Valeur totale des actifs déposés dans les protocoles DeFi d’un réseau. Il s’agit d’un indicateur utilisé pour mesurer l’adoption et la confiance au sein d’un écosystème.

Ann. A

AMM (Automated Market Maker)

DeFi

Protocole DeFi utilisant des formules mathématiques — généralement x*y=k — pour déterminer les prix d’échange, sans recourir à un carnet d’ordres traditionnel.

Ann. A

Oracle

DeFi

Service qui introduit dans la blockchain des données provenant du monde réel — prix, événements, etc. Il est essentiel pour la DeFi : les prêts, les produits dérivés et de nombreux contrats dépendent de données de prix externes fiables.

Ann. A

Preuve de fraude (fraud proof)

Sécurité

Preuve cryptographique démontrant qu’une transition d’état n’est pas valide. Elle est utilisée dans les optimistic rollups pour contester des états frauduleux pendant la période de contestation.

Chap. 19

Audit de sécurité (security audit)

Sécurité

Examen du code source par des spécialistes indépendants afin d’identifier d’éventuelles vulnérabilités. Dans le cas de Bitcoin Hyper, le projet a annoncé la publication d’audits avant le TGE ; au 28 avril 2026, aucun rapport public d’audit du protocole ou du bridge n’avait été identifié.

Chap. 34

Finalité (finality)

Règlement

Moment à partir duquel une transaction est considérée comme irréversible selon les règles et les hypothèses du système. Dans la conception décrite pour Bitcoin Hyper, les engagements d’état accumuleraient des confirmations sur Bitcoin après leur publication ; cela ne garantit pas à lui seul la validité de l’état ni la possibilité de retirer les fonds.

Chap. 13

Lightning Network

Projets comparables

Réseau de paiement sur Bitcoin fondé sur des canaux. Il est principalement conçu pour des paiements rapides et peu coûteux et n’offre pas un environnement généraliste de smart contracts comparable à une machine virtuelle. Il est utilisé en production depuis 2018.

Chap. 25–26

Stacks

Projets comparables

Réseau de smart contracts lié à Bitcoin utilisant le mécanisme PoX (Proof of Transfer). Il dispose de son propre langage, Clarity, et enregistre des informations relatives à ses blocs sur Bitcoin.

Chap. 27

Rootstock (RSK)

Projets comparables

Sidechain de Bitcoin compatible avec l’EVM et utilisant le merge-mining. Elle utilise RBTC, un actif lié au BTC, comme token pour le paiement du gas. Elle est opérationnelle depuis 2018.

Chap. 28