UTXOSUITE — home
← Retour à l'Académie
NIVEAU 1 · Gratuit

Fondamentaux Crypto & Blockchain

Construisez le modèle mental nécessaire pour raisonner sur chaînes, transactions, wallets et finalité.

8 leçons · 8 Exercice de terrain · 8 Scénarios pratiques · 20 question · 80% score minimal
Commencer à apprendre0% · 0/21

Ce que vous saurez faire

Ce module approfondit état, consensus & finalité avec une théorie appliquée et un laboratoire décisionnel dédié.

Ce module approfondit clés, adresses & frontières du wallet avec une théorie appliquée et un laboratoire décisionnel dédié.

Ce module approfondit cycle d'une transaction & frais avec une théorie appliquée et un laboratoire décisionnel dédié.

Ce module approfondit modèle utxo vs modèle compte avec une théorie appliquée et un laboratoire décisionnel dédié.

Programme

1.1 · L'état est ce sur quoi la chaîne s'accorde14 min
1.2 · Le consensus ne supprime pas les hypothèses de confiance16 min
Laboratoire · Tracer la transaction

Ce cours comprend

  • 8 leçons · 12 heures guidées
  • 4 Laboratoire · Scénarios pratiques
  • 8 Cas pratiques appliqués · 8 Contrôles des connaissances
  • 52 Banque de questions · 80% note de passage
  • Attestation de fin: UTXO Certified · Crypto Foundations

Ce que ce cours attend de vous

  • Tracer une transaction et expliquer où se situe réellement la confiance.
  • Score minimal: 80%
  • Aucun cours préalable requis.
Brief du cours

Contrat de formation

Tracer une transaction et expliquer où se situe réellement la confiance.

01 · Capacité viséeTracer une transaction et expliquer où se situe réellement la confiance.
02 · Prérequis recommandéAucun cours préalable requis
Livrables pratiques
01

État, consensus & finalité

Ce module approfondit état, consensus & finalité avec une théorie appliquée et un laboratoire décisionnel dédié.

Mémo de preuve · TX-FLOW
02

Clés, adresses & frontières du wallet

Ce module approfondit clés, adresses & frontières du wallet avec une théorie appliquée et un laboratoire décisionnel dédié.

Mémo de preuve · KEY-BOUNDARY
03

Cycle d'une transaction & frais

Ce module approfondit cycle d'une transaction & frais avec une théorie appliquée et un laboratoire décisionnel dédié.

Mémo de preuve · TX-FLOW
04

Modèle UTXO vs modèle compte

Ce module approfondit modèle utxo vs modèle compte avec une théorie appliquée et un laboratoire décisionnel dédié.

Mémo de preuve · TX-FLOW
Contrat d'évaluation
Contrôles de leçon8
Labs de module4
Examen final20
Seuil de maîtrise80%
Programme complet

Fondamentaux Crypto & Blockchain

Examinez l'ensemble du programme, des compétences et du parcours d'évaluation avant de commencer.

Charge d'étude guidée12h
modules4
leçons8
01

État, consensus & finalité

Ce module approfondit état, consensus & finalité avec une théorie appliquée et un laboratoire décisionnel dédié.

1.1
L'état est ce sur quoi la chaîne s'accorde45 min · Leçon technique approfondie
1.2
Le consensus ne supprime pas les hypothèses de confiance45 min · Leçon technique approfondie
Laboratoire pratique du moduleTracer la transaction
02

Clés, adresses & frontières du wallet

Ce module approfondit clés, adresses & frontières du wallet avec une théorie appliquée et un laboratoire décisionnel dédié.

2.1
Une clé autorise ; une adresse identifie45 min · Leçon technique approfondie
2.2
Un wallet est plus qu'un stockage de clés45 min · Leçon technique approfondie
Laboratoire pratique du moduleProtéger la frontière de signature
03

Cycle d'une transaction & frais

Ce module approfondit cycle d'une transaction & frais avec une théorie appliquée et un laboratoire décisionnel dédié.

3.1
De l'intention à l'inclusion45 min · Leçon technique approfondie
3.2
Les frais achètent de la priorité, pas de la correction45 min · Leçon technique approfondie
Laboratoire pratique du moduleTracer la transaction
04

Modèle UTXO vs modèle compte

Ce module approfondit modèle utxo vs modèle compte avec une théorie appliquée et un laboratoire décisionnel dédié.

4.1
Les chaînes UTXO dépensent des sorties discrètes45 min · Leçon technique approfondie
4.2
Les chaînes à comptes modifient un état partagé45 min · Leçon technique approfondie
Laboratoire pratique du moduleTracer la transaction
Compétences
  • Une transaction valide par consensus peut rester économiquement dangereuse.
  • Adaptez le niveau de finalité à la chaîne, à la valeur et au risque.
  • Sécurité économique et sécurité applicative sont des couches différentes.
  • Documentez les garanties de confirmation requises par chaque workflow.
  • Seed et clés privées sont du matériel d'autorité, jamais des données de support.
  • Considérez toute signature comme potentiellement porteuse de droits, même sans transfert immédiat.
  • Validité cryptographique ne signifie pas intention correcte.
  • Inspectez payload et contexte avant la frontière finale de signature.
  • Signer et diffuser sont deux actions distinctes.
  • Intervenez avant l'autorisation irréversible dès que possible.
  • L'estimation des frais n'est pas une validation de sécurité.
  • Ajustez confirmations et finalité à la valeur et au comportement de la chaîne.
Parcours d'évaluation
  1. Exercice de terrain écrit × 8
  2. Contrôles des connaissances × 8
  3. Laboratoire pratique du module × 4
  4. Examen final chronométré · 20 · ≥ 80%
Charge d'étude guidée
  1. Leçon technique approfondie · 360 min
  2. Exercice de terrain écrit · 160 min
  3. Laboratoire pratique du module · 140 min
  4. Specialist units · 105 min
  5. Examen final chronométré · 30 min
MANUEL DU COURS

Portée, résultats et standard d'étude

12h
Public visé

Construisez le modèle mental nécessaire pour raisonner sur chaînes, transactions, wallets et finalité.

Prérequis

Aucun cours technique préalable n'est requis.

Résultats d'apprentissage
  • Une transaction valide par consensus peut rester économiquement dangereuse.
  • Adaptez le niveau de finalité à la chaîne, à la valeur et au risque.
  • Sécurité économique et sécurité applicative sont des couches différentes.
  • Documentez les garanties de confirmation requises par chaque workflow.
  • Seed et clés privées sont du matériel d'autorité, jamais des données de support.
  • Considérez toute signature comme potentiellement porteuse de droits, même sans transfert immédiat.
  • Validité cryptographique ne signifie pas intention correcte.
  • Inspectez payload et contexte avant la frontière finale de signature.
  • Signer et diffuser sont deux actions distinctes.
  • Intervenez avant l'autorisation irréversible dès que possible.
Méthode d'étude
  1. 01

    Lire le chapitre technique en six parties

  2. 02

    Inspecter le visuel unique et le modèle de protocole

  3. 03

    Travailler le cas et la carte de preuves

  4. 04

    Soumettre l'exercice écrit

  5. 05

    Réussir le knowledge check et le lab du module

  6. 06

    Passer l'évaluation finale chronométrée

Standard de preuve

Chaque affirmation doit être reliée à des champs observables, au comportement du protocole, à des sources primaires ou à des hypothèses explicitement déclarées. Les inconnues doivent rester visibles.

Critère de réussite

La réussite exige le travail écrit, les knowledge checks, tous les labs et au moins 80% à l'examen final. Le niveau professionnel exige également le capstone.

Glossaire essentiel
L'état est ce sur quoi la chaîne s'accorde
Une blockchain applique des règles aux transitions d'état et converge vers une histoire via un mécanisme de consensus. L'analyse de sécurité doit identifier l'état faisant autorité, les hypothèses qui le soutiennent et le risque de réorganisation restant.
Le consensus ne supprime pas les hypothèses de confiance
PoW, PoS et les autres mécanismes répartissent autorité et modes de panne différemment. Ils modifient le coût d'une réécriture de l'histoire, de la censure ou d'une perte de disponibilité, mais ne remplacent pas la sécurité applicative.
Une clé autorise ; une adresse identifie
Une clé privée permet de produire des signatures valides. Une adresse est un identifiant public régi par des règles de signature ; la partager est normal, alors que révéler seed ou clé privée transfère le contrôle.
Un wallet est plus qu'un stockage de clés
Le logiciel wallet construit des requêtes, affiche du contexte, se connecte aux sites et demande une autorisation. L'UI, l'origine navigateur, le signer et l'appareil sont des frontières distinctes pouvant être compromises séparément.
De l'intention à l'inclusion
Une opération devient payload sérialisé, signature, propagation, entrée mempool, inclusion puis finalité. Chaque étape expose des risques et des possibilités de remédiation différentes.
Les frais achètent de la priorité, pas de la correction
Les frais influencent l'inclusion et sa vitesse mais ne valident pas l'intention. Une transaction malveillante chère reste malveillante et une transaction correcte peut rester pending assez longtemps pour que le contexte change.
Les chaînes UTXO dépensent des sorties discrètes
Dans le modèle UTXO, une transaction consomme des outputs précédents et en crée de nouveaux. Coin selection, change et conditions de script influencent validité, confidentialité et coût.
Les chaînes à comptes modifient un état partagé
Les chaînes account-based stockent balances, nonces et storage dans un état commun. Un call peut déclencher une logique arbitraire ; l'adresse visible seule ne suffit donc pas à comprendre l'effet réel.
EXTENSIONS SPÉCIALISÉES

Protocoles modernes et sujets opérationnels

Ces extensions élargissent le cursus central avec des normes actuelles et des frontières de sécurité qu'un praticien doit savoir reconnaître.

Wallets HD, BIP-32 et limites de dérivation
Unité d'étude spécialisée01
EXT / 01

Wallets HD, BIP-32 et limites de dérivation

Comprenez comment une seed produit une hiérarchie de clés étendues, pourquoi la dérivation hardened existe et pourquoi un xpub est plus sensible qu'une adresse ordinaire. La sécurité dépend aussi des sous-arbres exposés.

Point de sécuritéChemin de dérivation · hardened/non-hardened · exposition xpub · séparation des comptes
Tâche d'étudeLisez les sources primaires, identifiez la frontière de confiance et expliquez comment le mécanisme modifie le modèle d'autorisation ou d'exécution.
Livrable requisProduisez une note d'analyste concise contenant hypothèses, preuves matérielles, conditions de défaillance et décision de sécurité justifiée.
Références primairesBIP-32 ↗
PSBT, signature hors ligne et transfert de transaction
Unité d'étude spécialisée02
EXT / 02

PSBT, signature hors ligne et transfert de transaction

Étudiez PSBT comme interface structurée entre construction et signature. Le signer doit vérifier inputs, outputs, change, fee et champs inconnus au lieu de faire confiance au fichier parce qu'il est offline.

Point de sécuritéTransaction non signée · metadata inputs · change · vérification signer · PSBT v0/v2
Tâche d'étudeLisez les sources primaires, identifiez la frontière de confiance et expliquez comment le mécanisme modifie le modèle d'autorisation ou d'exécution.
Livrable requisProduisez une note d'analyste concise contenant hypothèses, preuves matérielles, conditions de défaillance et décision de sécurité justifiée.
Références primairesBIP-174 ↗BIP-370 ↗
Taproot, Schnorr et autorisation MuSig2
Unité d'étude spécialisée03
EXT / 03

Taproot, Schnorr et autorisation MuSig2

Reliez les key/script paths de Taproot aux multisignatures compatibles BIP-340. L'agrégation simplifie l'empreinte on-chain, mais les nonces, la coordination et le fallback restent critiques.

Point de sécuritéTaproot · Schnorr · MuSig2 · discipline de nonce · fallback
Tâche d'étudeLisez les sources primaires, identifiez la frontière de confiance et expliquez comment le mécanisme modifie le modèle d'autorisation ou d'exécution.
Livrable requisProduisez une note d'analyste concise contenant hypothèses, preuves matérielles, conditions de défaillance et décision de sécurité justifiée.
Références primairesBIP-341 ↗BIP-327 ↗
Module 01

État, consensus & finalité

Ce module approfondit état, consensus & finalité avec une théorie appliquée et un laboratoire décisionnel dédié.

Environnement technique lié à ce module de cours
Leçon 1.1

L'état est ce sur quoi la chaîne s'accorde

14 min
STATE / CONSENSUS
UTXO ACADEMY / CONCEPT MODELSTATE / CONSENSUSFINALITYVISUAL AID · NOT A SECURITY VERDICT
Chapitre technique

L'état est ce sur quoi la chaîne s'accorde

Leçon technique approfondie
01
Modèle mental

Une blockchain applique des règles aux transitions d'état et converge vers une histoire via un mécanisme de consensus. L'analyse de sécurité doit identifier l'état faisant autorité, les hypothèses qui le soutiennent et le risque de réorganisation restant.

Ce concept est important parce que Une transaction valide par consensus peut rester économiquement dangereuse.

Inspectez les champs exacts du protocole qui créent une autorité ou modifient l'exécution. Comparez ces champs avec l'intention déclarée de l'utilisateur et la frontière de sécurité attendue.

02
Ce qui se passe réellement

Inspectez les champs exacts du protocole qui créent une autorité ou modifient l'exécution.

Au niveau du protocole et de l'exécution, il faut inspecter state et transition et consensus et reorg et finality. Les identifiants de protocole restent non traduits car ils font partie du payload technique.

state

Points d'inspection technique

transition

Points d'inspection technique

consensus

Points d'inspection technique

reorg

Points d'inspection technique

finality

Points d'inspection technique

03
Surface de défaillance

Considérez les contradictions, l'autorité excessive et les dépendances inexpliquées comme des signaux matériels de défaillance.

La conséquence pratique est que Adaptez le niveau de finalité à la chaîne, à la valeur et au risque. Inconnu ne signifie pas sûr.

  • Une transaction valide par consensus peut rester économiquement dangereuse.
  • Adaptez le niveau de finalité à la chaîne, à la valeur et au risque.
04
Critère de décision

Reliez chaque signal matériel à sa conséquence concrète sur les actifs, l'autorité ou la confiance.

La conséquence pratique est que Adaptez le niveau de finalité à la chaîne, à la valeur et au risque.

Escaladez lorsque les preuves sont contradictoires, incomplètes ou que la conséquence dépasse la politique courante.

05
Procédure de vérification

Vérifiez la requête au moyen de preuves indépendantes avant toute autorisation irréversible.

  1. 01

    Inspectez les champs exacts du protocole qui créent une autorité ou modifient l'exécution.

  2. 02

    Comparez ces champs avec l'intention déclarée de l'utilisateur et la frontière de sécurité attendue.

  3. 03

    Vérifiez la requête au moyen de preuves indépendantes avant toute autorisation irréversible.

  4. 04

    Consignez faits, hypothèses, inconnues et décision afin qu'un autre analyste puisse reproduire la revue.

  5. 05

    Escaladez lorsque les preuves sont contradictoires, incomplètes ou que la conséquence dépasse la politique courante.

06
Livrable analyste

Consignez faits, hypothèses, inconnues et décision afin qu'un autre analyste puisse reproduire la revue.

Une transaction valide par consensus peut rester économiquement dangereuse. et Adaptez le niveau de finalité à la chaîne, à la valeur et au risque.

Livrable analysteL'état est ce sur quoi la chaîne s'accorde · Critère de décision
L'état est ce sur quoi la chaîne s'accorde
LESSON VISUALL'état est ce sur quoi la chaîne s'accordestate consensus finality
L'état est ce sur quoi la chaîne s'accorde
CONTEXTE RÉEL · ENVIRONNEMENT NŒUDS ET INFRASTRUCTUREL'état est ce sur quoi la chaîne s'accordeCONCEPT → ENVIRONNEMENT RÉEL → DÉCISION OPÉRATIONNELLE
VISUAL MODEL / AUTHORITY MAPstate-consensus-finality
N01N02N03N04N05N06AUTHORITY MAPL'état est ce sur quoi la chaîne s'accorde
CONCEPT → EVIDENCE → FAILURE MODE → VERIFICATION
Workbook technique

Objectif analyste

Une transaction valide par consensus peut rester économiquement dangereuse.

Mécanique
stateaccepted chain/application state
transitionvalid state change
consensushistory selection / finalization
reorgaccepted history can change
finalityconfidence / economic or protocol guarantee
Signaux de défaillance
  1. 01

    treating inclusion as absolute finality

  2. 02

    ignoring reorg assumptions

  3. 03

    confusing consensus security with app safety

  4. 04

    wrong confirmation threshold

  5. 05

    no chain-specific finality model

Procédure de vérification
  1. 01

    identify consensus mechanism

  2. 02

    define confirmation/finality criterion

  3. 03

    measure reorg exposure

  4. 04

    separate protocol validity from economic intent

  5. 05

    document settlement assumption

Chaîne de raisonnement
  1. 01

    faits → éléments matériels

  2. 02

    preuves → conséquence / autorité

  3. 03

    conséquence → décision explicite + prochaine action

Livrable requischain finality assumption record
Parcours du protocole

Suivez le chemin de décision de sécurité

state / consensus / finality
01Observer
  • state: accepted chain/application state
  • transition: valid state change
02Tracer
  • consensus: history selection / finalization
  • reorg: accepted history can change
  • finality: confidence / economic or protocol guarantee
03Contester
  • treating inclusion as absolute finality
  • ignoring reorg assumptions
  • confusing consensus security with app safety
04Vérifier
  • identify consensus mechanism
  • define confirmation/finality criterion
  • measure reorg exposure
05Résultat
  • chain finality assumption record
Surface d'autoritéstate · transition · consensus
Condition de défaillancetreating inclusion as absolute finality
Cas pratique
btc-finality
CAS / state-consensus-finality
chainBitcoin
value1.8 BTC
confirmations1
reorg Policytreasury requires 6
mempool Replacementdisabled
questionsettled or still operationally reversible?
Tâche de l'analyste

Avant de répondre, identifiez l'autorité accordée, la frontière de confiance susceptible d'échouer et la conséquence irréversible.

Carte de preuves

Organisez avant de décider

Séparez identité, autorité, exécution et contexte avant toute décision de sécurité.

01
Identité

Qui ou quoi demande, reçoit ou représente une autorité ?

—
02
Autorité

Quelle capacité peut être accordée, conservée ou exercée ?

reorg Policytreasury requires 6
03
Exécution

Que fera réellement le payload, la route ou le système ?

value1.8 BTC
mempool Replacementdisabled
04
Contexte

Quels faits environnants peuvent changer la décision ?

chainBitcoin
confirmations1
questionsettled or still operationally reversible?
Exercice de terrain

Produisez une conclusion exploitable par un analyste

Dossier analyste local uniquement

Ne répondez pas de mémoire. Utilisez le cas, les champs du protocole et la procédure de vérification ci-dessus pour rédiger une conclusion reproductible.

Point d'attentionstate · transition · consensus
Signal de défaillancetreating inclusion as absolute finality
Vérifier d'abordidentify consensus mechanism
Livrablechain finality assumption record
Critères de validation
  • Cite des preuves matérielles, pas l'apparence de l'interface.
  • Nomme l'autorité, la transition d'état ou la conséquence.
  • Fournit une prochaine action ou décision reproductible.
Notes de sécurité
  1. 01

    Une transaction valide par consensus peut rester économiquement dangereuse.

  2. 02

    Adaptez le niveau de finalité à la chaîne, à la valeur et au risque.

Carnet d'analyste

Construisez votre mémo de preuve

Dossier d'apprentissage local uniquement

Consignez votre raisonnement avant le contrôle et terminez par une décision ou une prochaine action explicite. Les notes restent sur cet appareil.

LOCAL STORAGE
Exercice de terrain

Développez les trois sections avant validation.

Leçon 1.2

Le consensus ne supprime pas les hypothèses de confiance

16 min
CONSENSUS MODEL
UTXO ACADEMY / CONCEPT MODELCONSENSUS MODELASSUMPTIONSVISUAL AID · NOT A SECURITY VERDICT
Chapitre technique

Le consensus ne supprime pas les hypothèses de confiance

Leçon technique approfondie
01
Modèle mental

PoW, PoS et les autres mécanismes répartissent autorité et modes de panne différemment. Ils modifient le coût d'une réécriture de l'histoire, de la censure ou d'une perte de disponibilité, mais ne remplacent pas la sécurité applicative.

Ce concept est important parce que Sécurité économique et sécurité applicative sont des couches différentes.

Inspectez les champs exacts du protocole qui créent une autorité ou modifient l'exécution. Comparez ces champs avec l'intention déclarée de l'utilisateur et la frontière de sécurité attendue.

02
Ce qui se passe réellement

Inspectez les champs exacts du protocole qui créent une autorité ou modifient l'exécution.

Au niveau du protocole et de l'exécution, il faut inspecter safety et liveness et censorship et economic security et centralization. Les identifiants de protocole restent non traduits car ils font partie du payload technique.

safety

Points d'inspection technique

liveness

Points d'inspection technique

censorship

Points d'inspection technique

economic security

Points d'inspection technique

centralization

Points d'inspection technique

03
Surface de défaillance

Considérez les contradictions, l'autorité excessive et les dépendances inexpliquées comme des signaux matériels de défaillance.

La conséquence pratique est que Documentez les garanties de confirmation requises par chaque workflow. Inconnu ne signifie pas sûr.

  • Sécurité économique et sécurité applicative sont des couches différentes.
  • Documentez les garanties de confirmation requises par chaque workflow.
04
Critère de décision

Reliez chaque signal matériel à sa conséquence concrète sur les actifs, l'autorité ou la confiance.

La conséquence pratique est que Documentez les garanties de confirmation requises par chaque workflow.

Escaladez lorsque les preuves sont contradictoires, incomplètes ou que la conséquence dépasse la politique courante.

05
Procédure de vérification

Vérifiez la requête au moyen de preuves indépendantes avant toute autorisation irréversible.

  1. 01

    Inspectez les champs exacts du protocole qui créent une autorité ou modifient l'exécution.

  2. 02

    Comparez ces champs avec l'intention déclarée de l'utilisateur et la frontière de sécurité attendue.

  3. 03

    Vérifiez la requête au moyen de preuves indépendantes avant toute autorisation irréversible.

  4. 04

    Consignez faits, hypothèses, inconnues et décision afin qu'un autre analyste puisse reproduire la revue.

  5. 05

    Escaladez lorsque les preuves sont contradictoires, incomplètes ou que la conséquence dépasse la politique courante.

06
Livrable analyste

Consignez faits, hypothèses, inconnues et décision afin qu'un autre analyste puisse reproduire la revue.

Sécurité économique et sécurité applicative sont des couches différentes. et Documentez les garanties de confirmation requises par chaque workflow.

Livrable analysteLe consensus ne supprime pas les hypothèses de confiance · Critère de décision
Le consensus ne supprime pas les hypothèses de confiance
LESSON VISUALLe consensus ne supprime pas les hypothèses de confianceconsensus tradeoffs
Le consensus ne supprime pas les hypothèses de confiance
CONTEXTE RÉEL · ENVIRONNEMENT NŒUDS ET INFRASTRUCTURELe consensus ne supprime pas les hypothèses de confianceCONCEPT → ENVIRONNEMENT RÉEL → DÉCISION OPÉRATIONNELLE
VISUAL MODEL / TRUST TOPOLOGYconsensus-tradeoffs
N01N02N03N04N05N06TRUST TOPOLOGYLe consensus ne supprime pas les hypothèses de confiance
CONCEPT → EVIDENCE → FAILURE MODE → VERIFICATION
Workbook technique

Objectif analyste

Sécurité économique et sécurité applicative sont des couches différentes.

Mécanique
safetyconflicting histories prevented
livenessnetwork continues progressing
censorshiptransactions can be excluded/delayed
economic securitycost of attacking consensus
centralizationconcentration of block/finality power
Signaux de défaillance
  1. 01

    generic 'decentralized' claim

  2. 02

    no adversary model

  3. 03

    ignoring validator/miner concentration

  4. 04

    assuming liveness under every partition

  5. 05

    same finality policy across all chains

Procédure de vérification
  1. 01

    name consensus actors

  2. 02

    identify safety/liveness assumptions

  3. 03

    identify attack/economic threshold

  4. 04

    inspect concentration dependencies

  5. 05

    set workflow-specific finality requirement

Chaîne de raisonnement
  1. 01

    faits → éléments matériels

  2. 02

    preuves → conséquence / autorité

  3. 03

    conséquence → décision explicite + prochaine action

Livrable requisconsensus threat-assumption matrix
Parcours du protocole

Suivez le chemin de décision de sécurité

consensus / tradeoffs
01Observer
  • safety: conflicting histories prevented
  • liveness: network continues progressing
02Tracer
  • censorship: transactions can be excluded/delayed
  • economic security: cost of attacking consensus
  • centralization: concentration of block/finality power
03Contester
  • generic 'decentralized' claim
  • no adversary model
  • ignoring validator/miner concentration
04Vérifier
  • name consensus actors
  • identify safety/liveness assumptions
  • identify attack/economic threshold
05Résultat
  • consensus threat-assumption matrix
Surface d'autoritésafety · liveness · censorship
Condition de défaillancegeneric 'decentralized' claim
Cas pratique
consensus-risk
CAS / consensus-tradeoffs
systemPoS chain
validator Concentrationtop 4 = 48%
finalityeconomic
bridge Dependencyyes
withdrawal Delay7 days
reviewliveness vs finality assumptions
Tâche de l'analyste

Avant de répondre, identifiez l'autorité accordée, la frontière de confiance susceptible d'échouer et la conséquence irréversible.

Carte de preuves

Organisez avant de décider

Séparez identité, autorité, exécution et contexte avant toute décision de sécurité.

01
Identité

Qui ou quoi demande, reçoit ou représente une autorité ?

—
02
Autorité

Quelle capacité peut être accordée, conservée ou exercée ?

—
03
Exécution

Que fera réellement le payload, la route ou le système ?

—
04
Contexte

Quels faits environnants peuvent changer la décision ?

systemPoS chain
validator Concentrationtop 4 = 48%
finalityeconomic
bridge Dependencyyes
withdrawal Delay7 days
reviewliveness vs finality assumptions
Exercice de terrain

Produisez une conclusion exploitable par un analyste

Dossier analyste local uniquement

Ne répondez pas de mémoire. Utilisez le cas, les champs du protocole et la procédure de vérification ci-dessus pour rédiger une conclusion reproductible.

Point d'attentionsafety · liveness · censorship
Signal de défaillancegeneric 'decentralized' claim
Vérifier d'abordname consensus actors
Livrableconsensus threat-assumption matrix
Critères de validation
  • Cite des preuves matérielles, pas l'apparence de l'interface.
  • Nomme l'autorité, la transition d'état ou la conséquence.
  • Fournit une prochaine action ou décision reproductible.
Notes de sécurité
  1. 01

    Sécurité économique et sécurité applicative sont des couches différentes.

  2. 02

    Documentez les garanties de confirmation requises par chaque workflow.

Carnet d'analyste

Construisez votre mémo de preuve

Dossier d'apprentissage local uniquement

Consignez votre raisonnement avant le contrôle et terminez par une décision ou une prochaine action explicite. Les notes restent sur cet appareil.

LOCAL STORAGE
Exercice de terrain

Développez les trois sections avant validation.

Laboratoire verrouillé

Réussissez les contrôles de connaissances des deux leçons avant le laboratoire.

Module 02

Clés, adresses & frontières du wallet

Ce module approfondit clés, adresses & frontières du wallet avec une théorie appliquée et un laboratoire décisionnel dédié.

Module verrouillé

Terminez le module précédent, laboratoire pratique inclus, avant de continuer.

Module 03

Cycle d'une transaction & frais

Ce module approfondit cycle d'une transaction & frais avec une théorie appliquée et un laboratoire décisionnel dédié.

Environnement opérationnel de sécurité lié à ce module de cours
Module verrouillé

Terminez le module précédent, laboratoire pratique inclus, avant de continuer.

Module 04

Modèle UTXO vs modèle compte

Ce module approfondit modèle utxo vs modèle compte avec une théorie appliquée et un laboratoire décisionnel dédié.

Module verrouillé

Terminez le module précédent, laboratoire pratique inclus, avant de continuer.

Examen final

Examen final

Évaluation cumulative reconstruite à chaque tentative à partir des concepts et cas pratiques du cours.

Un score minimal de 80 % est requis. Terminer la théorie seule ne délivre pas d'attestation.

Score minimal80%
Meilleur score0%
Banque52
Tentative20
Tentatives0
Temps limite30 min
Examen final
UTXO ACADEMY / EXAMEN FINAL · foundationsExamen final
VERROUILLÉTerminez tous les contrôles de leçon et tous les laboratoires avant de débloquer l'examen final.
Progression · 0%
Continuer