Zycord Code source

Code source

Un seul dépôt, sous licence MIT : le nœud, le portefeuille, la ligne de commande, les jeux de paramètres et les vecteurs de référence qui définissent le protocole. Tout ce sur quoi tourne le réseau s'y trouve.

Rien sur ce site ne vaut plus que ce que vous pouvez vérifier sans rien demander à personne, et la vérification commence ici. Un auteur anonyme ne peut pas vous offrir une réputation ; ce qui est offert à la place, c'est un arbre que vous pouvez lire, compiler et comparer aux binaires qu'on vous a remis.

Clonez-le#

git clone https://gitlab.com/zycord-group/zycord-node.git
cd zycord-node

Ou lisez-le d'abord dans le navigateur : gitlab.com/zycord-group/zycord-node.

C'est le seul dépôt

Les emplacements canoniques de ce projet — celui-ci compris — sont épinglés dans l'attestation signée du fil d'annonce, sous la clé du projet E724 39CE DD85 11F9 D607 550B 87FD 60D5 EB4A 0B29. Un arbre hébergé ailleurs est une copie : elle peut être honnête, périmée ou hostile, et rien sur cette page ne peut vous dire laquelle. Vérifiez la liste signée avant de faire confiance à un miroir, et compilez depuis un tag dont vous avez vérifié l'empreinte vous-même.

Ce qu'il contient#

Répertoire	Ce qu'il contient
`spec/`	Le protocole. Les jeux de paramètres, les vecteurs de référence et les images de bibliothèque prédéployées. Une implémentation qui passe les vecteurs est un pair, pas un fork.
`core/`	Code critique pour le consensus, bibliothèque standard uniquement : le modèle de cellules, la validité sans état, le fold, l'EVM adaptée aux certificats et RandomX derrière une étiquette de compilation.
`node/`	Le nœud autour de ce noyau — stockage, mempool, mineur, couche pair-à-pair, synchronisation, RPC en lecture seule, Stratum.
`wallet/`	Gestion des clés et constructeurs de certificats. Une référence, pas du consensus.
`cmd/`	`zycordd`, le nœud ; `zcd`, la ligne de commande et le portefeuille.
`sim/`	Le simulateur et les harnais de fuzzing, un second fold délibérément naïf soumis au fuzzing face au vrai, et le test d'endurance chaotique qui fait tourner de vrais nœuds sur de vraies sockets.
`contracts/`	Les contrats de référence, en Solidity.
`packaging/`	Le script d'installation et les paquets par plateforme, lisibles avant de les exécuter.
`docs/`	L'architecture, la référence du protocole, le guide d'exploitation et le livre blanc.

Le protocole, ce sont les vecteurs#

Le code Go de cet arbre est une implémentation de référence, et délibérément pas la définition. Ce qui définit le réseau, ce sont les jeux de paramètres et les vecteurs de référence : chaque règle de fold, de bloc et de validité sous forme de cas (état avant, bloc) → (état après, frais), positif et négatif. Écrivez votre propre nœud dans le langage que vous voulez — s'il passe le corpus, c'est un pair, et cette implémentation n'a aucune préséance sur lui.

Les hauteurs d'activation vivent au même endroit. h1_bond et h1_vm sont des paramètres figés à la genèse plutôt qu'une livraison : la machine est compilée dans chaque binaire et refusée en dessous de sa hauteur, si bien qu'une ère arrive parce que la chaîne a atteint un nombre et jamais parce qu'on a demandé aux opérateurs de mettre à jour.

Compilez-le#

make build           # no cgo, reproducible, development engine only
make build-randomx   # the network binary: mainnet and the public testnet

Seule la compilation RandomX peut rejoindre un réseau. La compilation par défaut est reproductible octet pour octet et fait tourner un devnet local ; les deux écrivent des fichiers différents à dessein, si bien qu'un binaire qui ne peut pas parler au mainnet n'est jamais pris pour un qui le peut. La chaîne d'outils Go est figée à go1.26.2 et la compilation refuse de tourner sous autre chose, parce que les mêmes sources compilées par deux versions de Go sont deux binaires différents.

Reconstruire un tag publié et comparer les empreintes, c'est la vérification qui remplace la confiance dans l'éditeur — Vérifier un téléchargement en donne la procédure complète, et Installation couvre la compilation pour un usage ordinaire.

Tickets et sécurité#

Les bogues, les questions et les correctifs vont dans le gestionnaire de tickets, et CONTRIBUTING.md indique ce qu'il faut à un changement avant qu'il puisse être fusionné.

Une vulnérabilité passe par le processus de divulgation de SECURITY.md plutôt que par le gestionnaire de tickets. Le projet préfère le rapport au bénéfice du doute, et un défaut trouvé avant le mainnet ne coûte rien à personne.

Licence#

MIT, pour tout l'arbre. Forkez-le, distribuez-le, vendez-le, renommez-le — la licence demande une mention de copyright et rien d'autre. La seule chose qu'elle ne peut pas vous remettre, c'est le réseau : cela se décide par les nœuds qui acceptent vos blocs, et ils les acceptent selon les règles de spec/.