Référence
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èglementPublication 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.
OP_RETURN
Bitcoin L1Opcode 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.
Taproot
Bitcoin L1Mise à 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.
UTXO
Bitcoin L1Unspent 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.
Rollup
Layer 2Solution 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.
Sidechain
Layer 2Blockchain 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.
Validium
Layer 2Architecture 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.
Optimistic Rollup
Layer 2Rollup 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.
ZK Rollup
Layer 2Rollup 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.
SVM (Solana Virtual Machine)
ExécutionRuntime 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.
Sealevel
ExécutionRuntime 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.
Anchor
ExécutionFramework 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.
SPL (Solana Program Library)
ExécutionBibliothè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.
Sequencer
SéquencementComposant 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é.
MEV (Maximal Extractable Value)
SéquencementValeur 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.
Inclusion forcée (forced inclusion)
SéquencementMé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.
Canonical Bridge
BridgeBridge 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.
Sortie forcée (forced exit)
BridgeMé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.
Disponibilité des données (data availability, DA)
Disponibilité des donnéesGarantie 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.
State Commitment
RèglementRepré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.
Arbre de Merkle (Merkle tree)
CryptographieStructure 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.
$HYPER
TokenomicsToken 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.
Vesting
TokenomicsMé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.
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.
TVL (Total Value Locked)
DeFiValeur 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.
AMM (Automated Market Maker)
DeFiProtocole 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.
Oracle
DeFiService 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.
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.
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é.
Finalité (finality)
RèglementMoment à 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.
Lightning Network
Projets comparablesRé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.
Stacks
Projets comparablesRé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.
Rootstock (RSK)
Projets comparablesSidechain 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.
Aucun terme correspondant n’a été trouvé.