ccip Télécharger - ccip Téléchargement du code source

ccip

Autre code source

v2.14.0-ccip1.5.10

Télécharger

Chainlink étend les capacités des contrats intelligents en permettant l'accès aux données du monde réel et au calcul hors chaîne tout en conservant les garanties de sécurité et de fiabilité inhérentes à la technologie blockchain.

Ce référentiel contient le nœud principal Chainlink et les contrats. Le nœud principal est le binaire fourni qui peut être exécuté par les opérateurs de nœuds participant à un réseau Oracle décentralisé. Toutes les versions majeures disposent d'images Docker prédéfinies disponibles en téléchargement à partir du Dockerhub Chainlink. Si vous souhaitez contribuer, veuillez consulter nos directives de contribution. Si vous êtes ici pour signaler un bug ou demander une fonctionnalité, veuillez vérifier les problèmes actuellement ouverts. Pour plus d'informations sur la façon de démarrer avec Chainlink, consultez notre documentation officielle. Des ressources pour les développeurs Solidity peuvent être trouvées dans la Chainlink Hardhat Box.

Communauté

Chainlink a une communauté active et en constante croissance. Discord est le principal canal de communication utilisé pour la communication quotidienne, pour répondre aux questions de développement et pour regrouper le contenu lié à Chainlink. Jetez un œil à la documentation de la communauté pour plus d'informations sur les comptes sociaux Chainlink, les actualités et les réseaux.

Construire un maillon de chaîne

Installez Go 1.22 et ajoutez le répertoire bin de votre GOPATH à votre PATH

Exemple de chemin pour export PATH=$GOPATH/bin:$PATH & export GOPATH=/Users/$USER/go

Installez NodeJS v20 et pnpm v9 via npm.

Il pourrait être plus facile à long terme d'utiliser nvm pour basculer entre les versions de nœuds pour différents projets. Par exemple, en supposant que $NODE_VERSION soit défini sur une version valide de NodeJS, vous pouvez exécuter : nvm install $NODE_VERSION && nvm use $NODE_VERSION

Installez Postgres (>= 12.x). Il est recommandé d'exécuter la dernière version majeure de Postgres.

Notez que si vous exécutez l'image docker officielle Chainlink, la version Postgres la plus élevée prise en charge est 16.x en raison du client fourni.
Vous devez configurer Postgres pour utiliser la connexion SSL (ou pour les tests, vous pouvez définir ?sslmode=disable dans votre chaîne de requête Postgres).

Assurez-vous que Python 3 est installé (cela est requis par solc-select qui est nécessaire pour compiler les contrats de solidité)
Téléchargez Chainlink : git clone https://github.com/smartcontractkit/chainlink && cd chainlink
Construire et installer Chainlink : make install
Exécuter le nœud : chainlink help

Pour obtenir les dernières informations sur la configuration d’un environnement de développement, consultez le Guide de configuration du développement.

Apple Silicium - ARM64

Les versions natives sur Apple Silicon devraient fonctionner immédiatement, mais l'image Docker nécessite plus de considération.

 $ docker build . -t chainlink-develop:dernier -f ./core/chainlink.Dockerfile

Exigences du client d'exécution Ethereum

Pour exécuter le nœud Chainlink, vous devez avoir accès à un nœud Ethereum en cours d'exécution avec une connexion Websocket ouverte. Tout réseau basé sur Ethereum fonctionnera une fois que vous aurez configuré l'ID de chaîne. Versions du nœud Ethereum actuellement testées et prises en charge :

[Officiellement pris en charge]

Parity/Openethereum (REMARQUE : La parité est obsolète et la prise en charge de ce client pourrait être supprimée à l'avenir)
Geth
Bésu

[Supporté mais cassé] Ces clients sont pris en charge par Chainlink, mais présentent des bogues qui empêchent Chainlink de fonctionner de manière fiable sur ces clients d'exécution.

Problèmes de blocage de Nothermind :

NethermindEth/nethermind#4384

Problèmes de blocage d'Erigon :

erigontech/erigon#4946
erigontech/erigon#4030 (commentaire)

Nous ne pouvons pas recommander de numéros de version spécifiques pour les nœuds Ethereum puisque le logiciel est continuellement mis à jour, mais vous devez généralement essayer d'exécuter la dernière version disponible.

Exécuter un nœud Chainlink local

REMARQUE : Par défaut, chainlink s'exécutera en mode TLS. Pour le développement local, vous pouvez désactiver cela en utilisant une dev build en utilisant make chainlink-dev et en définissant les champs TOML :

 [WebServer]SecureCookies = falseTLS.HTTPSPort = 0[Non sécurisé]DevWebServer = true

Vous pouvez également générer des certificats auto-signés à l'aide tools/bin/self-signed-certs ou manuellement.

Pour démarrer votre nœud Chainlink, exécutez simplement :

 début du nœud de maillon de chaîne

Par défaut, cela démarrera sur le port 6688. Vous devriez pouvoir accéder à l'interface utilisateur à l'adresse http://localhost:6688/.

Chainlink fournit un client CLI distant ainsi qu'une interface utilisateur. Une fois votre nœud démarré, vous pouvez ouvrir une nouvelle fenêtre de terminal pour utiliser la CLI. Vous devrez d'abord vous connecter pour autoriser le client :

 connexion administrateur Chainlink

(Vous pouvez également définir ADMIN_CREDENTIALS_FILE=/path/to/credentials/file à l'avenir si vous le souhaitez, pour éviter d'avoir à vous reconnecter).

Vous pouvez désormais consulter vos emplois actuels avec :

 liste d'emplois de maillons de chaîne

Pour en savoir plus sur la CLI Chainlink, vous pouvez toujours exécuter chainlink help .

Consultez les pages de documentation sur les Jobs pour en savoir plus sur la façon de créer des Jobs.

Configuration

La configuration des nœuds est gérée par une combinaison de variables d'environnement et de paramètres directs via API/UI/CLI.

Consultez la documentation officielle pour plus d'informations sur la façon de configurer votre nœud.

Adaptateurs externes

Les adaptateurs externes rendent Chainlink facilement extensible, offrant une intégration simple de calculs personnalisés et d'API spécialisées. Un nœud Chainlink communique avec des adaptateurs externes via une simple API REST.

Pour plus d'informations sur la création et l'utilisation d'adaptateurs externes, veuillez consulter notre page sur les adaptateurs externes.

Vérifier les versions officielles de Chainlink

Nous utilisons cosign avec la signature sans clé OIDC pendant le flux de travail de création, de signature et de publication de Chainlink.

Il est encouragé pour tout opérateur de nœud créant à partir de l'image Docker officielle de Chainlink de vérifier que la version balisée a bien été créée à partir de ce flux de travail.

Vous aurez besoin cosign pour effectuer cette vérification. Suivez les instructions ici pour installer cosign.

 La balise # est la version balisée - c'est-à-dire. v2.16.0cosign verify public.ecr.aws/chainlink/chainlink:${tag} 
      --certificate-oidc-issuer https://token.actions.githubusercontent.com 
      --certificate-identity "https://github.com/smartcontractkit/chainlink/.github/workflows/build-publish.yml@refs/tags/${tag}"

Développement

Exécution de tests

Installez pnpm 9 via npm
Installez gencodec et jq pour pouvoir exécuter go generate ./... et make abigen
Installer la moquerie

make mockery

L’utilisation de la commande make installera la version correcte.

Construire des contrats :

 contrats pushd
pnpm je
Compilation pnpm : nativepopd

Générez et compilez des ressources statiques :

 faire générer

Préparez votre environnement de développement :

Les tests nécessitent une base de données postgres. À son tour, la variable d'environnement CL_DATABASE_URL doit être définie sur une valeur permettant de se connecter à la base de données _test , et l'utilisateur doit pouvoir créer et supprimer la base de données _test donnée.

Remarque : d'autres variables d'environnement ne doivent pas être définies pour que tous les tests réussissent

Il existe un script d'assistance pour la configuration initiale afin de créer un utilisateur de test approprié. Il nécessite que Postgres soit exécuté sur localhost sur le port 5432. Vous serez invité à saisir le mot de passe de l'utilisateur postgres

 faire setup-testdb

Ce script enregistrera le CL_DATABASE_URL dans .dbenv

Les modifications apportées à la base de données nécessitent l'exécution de migrations. De même, pull du référentiel peut nécessiter l'exécution de migrations. Après la configuration unique ci-dessus :

source .dbenv
make testdb

Si vous rencontrez l'erreur database accessed by other users (SQLSTATE 55006) exit status 1 et souhaitez forcer la création de la base de données, puis utilisez

source .dbenv
make testdb-force

Exécutez des tests :

 allez tester ./...

Remarques

L'indicateur parallel peut être utilisé pour limiter l'utilisation du processeur, pour exécuter des tests en arrière-plan ( -parallel=4 ) - la valeur par défaut est GOMAXPROCS
L'indicateur p peut être utilisé pour limiter le nombre de packages testés simultanément, s'ils interfèrent les uns avec les autres ( -p=1 )
L'indicateur -short ignore les tests qui dépendent de la base de données, pour une vérification ponctuelle rapide des tests plus simples en une minute environ

Détecteur de course

Depuis Go 1.1, le runtime comprend un détecteur de courses de données, activé avec l'indicateur -race . Ceci est utilisé dans CI via le script tools/bin/go_core_race_tests . Si l'action détecte une course, l'artefact sur la page de résumé inclura des fichiers race.* avec des traces de pile détaillées.

Il n’émettra pas de faux positifs, alors prenez ses avertissements au sérieux.

Pour une détection locale et ciblée des races, vous pouvez exécuter :

 GORACE="log_path=$PWD/race" go test -race ./core/path/to/pkg -count 10
GORACE="log_path=$PWD/race" go test -race ./core/path/to/pkg -count 100 -run TestFooBar/sub_test

https://go.dev/doc/articles/race_detector

Tests de flou

Depuis Go 1.18, les tests fuzz func FuzzXXX(*testing.F) sont inclus dans la suite de tests normale, donc les cas existants sont exécutés avec go test .

De plus, vous pouvez exécuter un fuzzing actif pour rechercher de nouveaux cas :

 allez tester ./pkg/path -run=XXX -fuzz=FuzzTestName

https://go.dev/doc/fuzz/

Aller aux modules

Ce référentiel contient trois modules Go :

 organigramme RL
    github.com/smartcontractkit/chainlink/v2
    github.com/smartcontractkit/chainlink/integration-tests --> github.com/smartcontractkit/chainlink/v2
    github.com/smartcontractkit/chainlink/core/scripts --> github.com/smartcontractkit/chainlink/v2

Les modules integration-tests et core/scripts importent le module racine en utilisant un remplacement relatif dans leurs fichiers go.mod , de sorte que les changements de dépendance dans le go.mod racine nécessitent souvent également des modifications dans ces modules. Après avoir effectué une modification, go mod tidy peut être exécuté sur les trois modules en utilisant :

make gomodtidy

Solidité

Dans le répertoire contracts/ :

Installer les dépendances :

 pnpm je

Exécutez des tests :

 test pnpm

REMARQUE : Chainlink est actuellement en train de migrer vers Foundry et contient à la fois des tests Foundry et Hardhat dans certaines versions. Plus d’informations peuvent être trouvées ici : Documentation Chainlink Foundry. Tous les fichiers 't.sol' associés aux tests Foundry, contenus dans les répertoires src seront ignorés par Hardhat.

Génération de code

Go generate est utilisé pour générer des simulations dans ce projet. Les simulations sont générées avec moquerie et vivent dans core/internal/mocks.

Rien

Un shell.nix est fourni pour être utilisé avec le gestionnaire de packages Nix. Par défaut, nous utilisons le shell via Nix Flakes.

Nix définit un environnement de développement déclaratif et reproductible. La version Flakes utilise des dépendances déterministes et gelées ( flake.lock ) pour gagner plus de cohérence/reproductibilité sur les artefacts construits.

Pour l'utiliser :

Installez le gestionnaire de packages nix sur votre système.

Activer la prise en charge des flocons

Exécutez nix develop . Vous serez mis dans un shell contenant toutes les dépendances.

En option, nix develop --command $SHELL utilisera votre shell actuel au lieu de celui par défaut (bash).
Vous pouvez utiliser direnv pour l'activer automatiquement lorsque cd est inséré dans le dossier ; pour cela, activez nix-direnv et use flake dessus.

Créez une base de données Postgres locale :

 mkdir -p $PGDATA && cd $PGDATA/
base de données d'initialisation
pg_ctl -l postgres.log -o "--unix_socket_directories='$PWD'" start
crééb chainlink_test -h localhost
createuser --superuser --password chainlink -h localhost# puis tapez un mot de passe de test, par exemple : chainlink, et définissez-le dans shell.nix CL_DATABASE_URL

En rentrant dans le projet, vous pouvez redémarrer postgres : cd $PGDATA; pg_ctl -l postgres.log -o "--unix_socket_directories='$PWD'" start Vous pouvez maintenant exécuter des tests ou compiler du code comme d'habitude.
Lorsque vous avez terminé, arrêtez-le : cd $PGDATA; pg_ctl -o "--unix_socket_directories='$PWD'" stop

Ensembles de modifications

Nous utilisons des ensembles de modifications pour gérer la gestion des versions des bibliothèques et des services.

Chaque PR qui modifie une configuration ou un code doit très probablement être accompagné d'un fichier d'ensemble de modifications.

Pour installer changesets :

Installez pnpm s'il n'est pas déjà installé - docs.
Exécutez pnpm install .

Soit après, soit avant de créer une validation, exécutez la commande pnpm changeset pour créer une entrée de modifications d'accompagnement qui se reflétera dans le CHANGELOG de la prochaine version.

Le format est basé sur Keep a Changelog,

et ce projet adhère au versioning sémantique.