ord
0.21.3
ord ord est un index, un explorateur de blocs et un portefeuille en ligne de commande. Il s'agit d'un logiciel expérimental sans garantie. Voir LICENCE pour plus de détails.
La théorie ordinale confère aux satoshis une valeur numismatique, leur permettant d'être collectés et échangés comme bibelots.
Les numéros ordinaux sont des numéros de série pour les satoshis, attribués dans l'ordre dans lequel ils sont extraits et conservés lors des transactions.
Consultez la documentation pour la documentation et les guides.
Voir le BIP pour une description technique de l'algorithme d'affectation et de transfert.
Consultez le tableau de bord du projet pour connaître les problèmes actuellement prioritaires.
Rejoignez le serveur Discord pour discuter avec d'autres dégénérés ordinaux.
Ordinals est open source et financé par la communauté. Le principal responsable actuel d’ ord est Raphjaph. Le travail de Raph sur ord est entièrement financé par des dons. Si vous le pouvez, pensez à faire un don !
L'adresse du don est bc1qguzk63exy7h5uygg8m2tcenca094a8t464jfyvrmr0s6wkt74wls3zr5m3.
Cette adresse est 2 des 4 portefeuilles multisig avec des clés détenues par Raphjaph, Erin, Rodarmor et Ordinally.
Les Bitcoins reçus serviront à financer la maintenance et le développement d' ord , ainsi qu'à couvrir les frais d'hébergement d'ordinals.com.
Merci pour votre don !
ord s'appuie sur Bitcoin Core pour la gestion des clés privées et la signature des transactions. Cela a un certain nombre d'implications que vous devez comprendre afin d'utiliser les commandes ord wallet en toute sécurité :
Bitcoin Core n'a pas connaissance des inscriptions et n'effectue pas de contrôle sat. L'utilisation de commandes bitcoin-cli et d'appels RPC avec des portefeuilles ord peut entraîner une perte d'inscriptions.
Les commandes ord wallet chargent automatiquement le portefeuille ord donné par l'option --name , qui est par défaut « ord ». Gardez à l’esprit qu’après avoir exécuté une commande ord wallet , un ord wallet peut être chargé.
Étant donné que ord a accès à vos portefeuilles Bitcoin Core, ord ne doit pas être utilisé avec des portefeuilles contenant une quantité importante de fonds. Gardez les portefeuilles ordinaux et cardinaux séparés.
Les portefeuilles Alpha ord ne sont pas compatibles avec les portefeuilles créés par les versions précédentes d' ord . Pour migrer, utilisez ord wallet send depuis l'ancien portefeuille pour envoyer des sats et des inscriptions aux adresses générées par le nouveau portefeuille avec ord wallet receive .
ord est écrit en Rust et peut être construit à partir des sources. Les binaires prédéfinis sont disponibles sur la page des versions.
Vous pouvez installer le dernier binaire prédéfini à partir de la ligne de commande avec :
curl --proto ' =https ' --tlsv1.2 -fsLS https://ordinals.com/install.sh | bash -s Une fois ord installé, vous devriez pouvoir exécuter ord --version sur la ligne de commande.
Sous Linux, ord nécessite libssl-dev lors de la construction à partir des sources.
Sur les distributions Linux dérivées de Debian, y compris Ubuntu :
sudo apt-get install pkg-config libssl-dev build-essential
Sur les distributions Linux dérivées de Red Hat :
yum install -y pkgconfig openssl-devel
yum groupinstall "Development Tools"
Vous aurez également besoin de Rust :
curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh
Clonez le dépôt ord :
git clone https://github.com/ordinals/ord.git
cd ord
Pour créer une version spécifique de ord , commencez par extraire cette version :
git checkout <VERSION>
Et enfin pour construire réellement ord :
cargo build --release
Une fois construit, le binaire ord peut être trouvé sur ./target/release/ord .
ord nécessite la version rustc 1.79.0 ou ultérieure. Exécutez rustc --version pour vous assurer que vous disposez de cette version. Exécutez rustup update pour obtenir la dernière version stable.
Une image Docker peut être construite avec :
docker build -t ordinals/ord .
ord est disponible en Homebrew :
brew install ord
Pour créer un package .deb :
cargo install cargo-deb
cargo deb
Si vous souhaitez contribuer, il est utile de savoir quelques éléments. Nous accordons beaucoup d'importance aux tests appropriés dans la base de code, avec trois grandes catégories de tests : unitaires, d'intégration et fuzz. Les tests unitaires se trouvent généralement au bas d'un fichier dans un bloc mod appelé tests . Si vous ajoutez ou modifiez une fonction, veuillez également ajouter un test correspondant. Les tests d'intégration tentent de tester les fonctionnalités de bout en bout en exécutant une sous-commande du binaire. Ceux-ci peuvent être trouvés dans le répertoire tests. Nous n'avons pas beaucoup de fuzzing mais la structure de base de la façon dont nous le faisons se trouve dans le répertoire fuzz.
Nous vous recommandons fortement de l'installer uniquement pour faciliter l'exécution des tests. Pour exécuter notre suite de tests CI, vous feriez :
just ci
Cela correspond aux commandes :
cargo fmt -- --check
cargo test --all
cargo test --all -- --ignored
Jetez un œil au justfile pour voir des recettes (commandes) plus utiles. En voici quelques autres bons :
just fmt
just fuzz
just doc
just watch ltest --all
Si les tests échouent ou se bloquent, vous devrez peut-être augmenter le nombre maximum de fichiers ouverts en exécutant ulimit -n 1024 dans votre shell avant d'exécuter les tests, ou dans la configuration de votre shell.
Nous essayons également de suivre une approche TDD (Test-Driven-Development), ce qui signifie que nous utilisons les tests comme moyen d'obtenir une visibilité sur le code. C'est pour cette raison que les tests doivent s'exécuter rapidement afin que la boucle de rétroaction entre la réalisation d'une modification, l'exécution du test et l'affichage du résultat soit réduite. Pour faciliter cela, nous avons créé une instance Bitcoin Core simulée dans mockcore
ord nécessite un nœud bitcoind synchronisé avec -txindex pour créer l'index des emplacements satoshi. ord communique avec bitcoind via RPC.
Si bitcoind est exécuté localement par le même utilisateur, sans configuration supplémentaire, ord devrait le trouver automatiquement en lisant le fichier .cookie à partir du répertoire de données de bitcoind et en se connectant à l'aide du port RPC par défaut.
Si bitcoind n'est pas sur le réseau principal, n'est pas exécuté par le même utilisateur, a un répertoire de données autre que celui par défaut ou un port autre que celui par défaut, vous devrez transmettre des indicateurs supplémentaires à ord . Voir ord --help pour plus de détails.
bitcoind ord effectue des appels RPC vers bitcoind , ce qui nécessite généralement un nom d'utilisateur et un mot de passe.
Par défaut, ord recherche un nom d'utilisateur et un mot de passe dans le fichier cookie créé par bitcoind .
Le chemin du fichier cookie peut être configuré à l'aide de --cookie-file :
ord --cookie-file /path/to/cookie/file server
Alternativement, ord peut être fourni avec un nom d'utilisateur et un mot de passe sur la ligne de commande :
ord --bitcoin-rpc-username foo --bitcoin-rpc-password bar server
Utilisation de variables d'environnement :
export ORD_BITCOIN_RPC_USERNAME=foo
export ORD_BITCOIN_RPC_PASSWORD=bar
ord server
Ou dans le fichier de configuration :
bitcoin_rpc_username : foo
bitcoin_rpc_password : bar ord utilise env_logger. Définissez la variable d'environnement RUST_LOG afin d'activer la journalisation. Par exemple, exécutez le serveur et affichez les messages du journal au niveau info et au-dessus :
$ RUST_LOG=info cargo run server
Définissez la variable d'environnement RUST_BACKTRACE afin d'activer la trace complète de la rouille. Par exemple, exécutez le serveur et activez le débogage et le backtrace complet :
$ RUST_BACKTRACE=1 RUST_LOG=debug ord server
Les messages de validation de version utilisent le modèle suivant :
Release x.y.z
- Bump version: x.y.z → x.y.z
- Update changelog
- Update changelog contributor credits
- Update dependencies
Pour traduire les documents, nous utilisons l'assistant mdBook i18n.
Consultez le guide d'utilisation de mdbook-i18n-helpers pour obtenir de l'aide.
L'ajout d'une nouvelle traduction est quelque peu complexe, alors n'hésitez pas à lancer la traduction et à ouvrir une pull request, même si votre traduction est incomplète.
Jetez un œil à ce commit pour un exemple d’ajout d’une nouvelle traduction. Un responsable vous aidera à l'intégrer dans notre système de build.
Pour démarrer une nouvelle traduction :
Installez mdbook , mdbook-i18n-helpers et mdbook-linkcheck :
cargo install mdbook mdbook-i18n-helpers mdbook-linkcheck
Générez un nouveau fichier pot nommé messages.pot :
MDBOOK_OUTPUT='{"xgettext": {"pot-file": "messages.pot"}}'
mdbook build -d po
Exécutez msgmerge sur XX.po où XX est le code ISO-639 à deux lettres de la langue dans laquelle vous traduisez. Cela mettra à jour le fichier po avec le texte de la version anglaise la plus récente :
msgmerge --update po/XX.po po/messages.pot
Les sections non traduites sont marquées d' #, fuzzy dans XX.po . Modifiez la chaîne msgstr avec le texte traduit.
Exécutez la commande mdbook pour reconstruire les documents. Pour le chinois, dont le code ISO-639 à deux lettres est zh :
mdbook build docs -d build
MDBOOK_BOOK__LANGUAGE=zh mdbook build docs -d build/zh
mv docs/build/zh/html docs/build/html/zh
python3 -m http.server --directory docs/build/html --bind 127.0.0.1 8080
Si tout semble bon, validez XX.po et ouvrez une pull request sur GitHub. Les autres fichiers modifiés doivent être omis de la demande d'extraction.
