Concevoir le registre partagé d'un terminal à conteneurs
Aperçu
En quoi consiste ce défi.
Votre livrable est une proposition d'architecture, pas un prototype. En vous appuyant uniquement sur le dossier de cas fourni, le jeu de données d'événements documentaires fourni et les deux documentations techniques publiques référencées, vous devez : (1) décider si le registre doit être ouvert à tous ou permissionné, c'est-à-dire réservé à des participants identifiés, et défendre ce choix ; (2) choisir et justifier un mécanisme de consensus — la règle par laquelle les participants se mettent d'accord sur l'ordre des écritures — parmi au moins trois options que vous aurez comparées ; (3) spécifier le modèle de données et de confidentialité, sachant qu'un transitaire ne doit pas voir les prix négociés par un concurrent ; (4) définir la gouvernance : qui admet un nouveau participant, qui exploite les nœuds, que se passe-t-il si un acteur cesse de coopérer. Contraintes fermes : au maximum douze organisations participantes, un délai de finalisation d'écriture inférieur à cinq secondes, et une réversibilité obligatoire (l'opérateur doit pouvoir revenir à son système actuel sans perte de données). La réussite se mesure à une chose : un comité technique qui ne connaît pas la blockchain doit pouvoir lire votre proposition et trancher, parce que chaque choix est chiffré à partir des données fournies et que chaque compromis est nommé explicitement.
Le brief
Ce que vous ferez, et ce que vous démontrerez.
Comment concevoir un registre distribué partagé entre douze organisations portuaires aux intérêts divergents, qui accélère la libération des conteneurs sans exposer les données commerciales de chaque acteur ni imposer une confiance que personne n'accordera ?
Earning criteria — what you'll demonstrate
- Choisir entre registre ouvert et registre permissionné à partir de contraintes métier réelles, et non par préférence technologique
- Comparer des mécanismes de consensus (tolérance aux fautes byzantines, preuve d'autorité, protocoles à quorum) sur des critères mesurables de débit, de latence et d'hypothèse de confiance
- Concevoir la confidentialité dans un système décentralisé où les participants sont aussi des concurrents commerciaux
- Formuler la gouvernance d'un système décentralisé : admission, exploitation, sortie et résolution de conflits
- Défendre une architecture décentralisée devant une audience non technique en nommant honnêtement les compromis
Adéquation au programme
Où cela s'inscrit dans votre cursus.
Renforce les mêmes compétences que celles attendues par votre diplôme.
Cursus associés bientôt disponibles.
Compétences
Les compétences que vous démontrerez.
Chacune apparaît sur votre certificat vérifié.
Débouchés
Les métiers auxquels ce défi vous prépare.
De vrais intitulés. De vraies passerelles de compétences. Choisissez celui qui se rapproche le plus de votre trajectoire.
Les parcours de carrière que ce défi construit
Métiers de référenceIngénieur Systèmes Distribués
Ce défi fait manipuler les compromis fondamentaux des systèmes distribués — ordre des écritures, latence de finalisation, tolérance aux pannes et aux participants malveillants — sur un cas industriel réel plutôt que sur un exercice théorique, exactement le raisonnement attendu au quotidien dans ce rôle.
Ce défi renforce
- consensus-protocol-design
- distributed-ledger-design
- analytical-reasoning
Consultant Blockchain
Vous produisez le livrable central du métier : une recommandation d'architecture argumentée pour un client qui ne connaît pas la technologie, incluant la capacité rare et valorisée de conclure qu'une blockchain n'est pas nécessaire sur un sous-périmètre donné.
Ce défi renforce
- architecture-decision-records-adrs
- 6-pager-writing
- analytical-reasoning
Ingénieur Plateforme
La conception d'une plateforme partagée entre douze organisations, avec gouvernance d'admission, exploitation des nœuds et plan de réversibilité, correspond directement aux responsabilités d'ingénierie de plateforme multi-locataires.
Ce défi renforce
- distributed-ledger-design
- threat-modeling
- architecture-decision-records-adrs