ccip
v2.14.0-ccip1.5.10
Chainlink erweitert die Möglichkeiten intelligenter Verträge, indem es den Zugriff auf reale Daten und Off-Chain-Berechnungen ermöglicht und gleichzeitig die Sicherheits- und Zuverlässigkeitsgarantien der Blockchain-Technologie beibehält.
Dieses Repo enthält den Chainlink-Kernknoten und die Verträge. Der Kernknoten ist die gebündelte Binärdatei, die von Knotenbetreibern ausgeführt werden kann, die an einem dezentralen Oracle-Netzwerk teilnehmen. Alle Hauptversionen verfügen über vorgefertigte Docker-Images, die vom Chainlink Dockerhub heruntergeladen werden können. Wenn Sie daran interessiert sind, einen Beitrag zu leisten, lesen Sie bitte unsere Beitragsrichtlinien. Wenn Sie hier sind, um einen Fehler zu melden oder eine Funktion anzufordern, überprüfen Sie bitte die aktuell offenen Probleme. Weitere Informationen zum Einstieg in Chainlink finden Sie in unserer offiziellen Dokumentation. Ressourcen für Solidity-Entwickler finden Sie in der Chainlink Hardhat Box.
Chainlink hat eine aktive und ständig wachsende Community. Discord ist der primäre Kommunikationskanal, der für die tägliche Kommunikation, die Beantwortung von Entwicklungsfragen und die Aggregation von Chainlink-bezogenen Inhalten verwendet wird. Weitere Informationen zu sozialen Konten, Neuigkeiten und Netzwerken von Chainlink finden Sie in den Community-Dokumenten.
Installieren Sie Go 1.22 und fügen Sie das bin-Verzeichnis Ihres GOPATH zu Ihrem PATH hinzu
Beispielpfad für macOS export PATH=$GOPATH/bin:$PATH & export GOPATH=/Users/$USER/go
Installieren Sie NodeJS v20 und pnpm v9 über npm.
Auf lange Sicht könnte es einfacher sein, nvm zum Wechseln zwischen Knotenversionen für verschiedene Projekte zu verwenden. Angenommen, $NODE_VERSION wurde auf eine gültige Version von NodeJS festgelegt, könnten Sie Folgendes ausführen: nvm install $NODE_VERSION && nvm use $NODE_VERSION
Installieren Sie Postgres (>= 12.x). Es wird empfohlen, die neueste Hauptversion von Postgres auszuführen.
Beachten Sie, dass, wenn Sie das offizielle Docker-Image von Chainlink ausführen, aufgrund des gebündelten Clients die höchste unterstützte Postgres-Version 16.x ist.
Sie sollten Postgres für die Verwendung einer SSL-Verbindung konfigurieren (oder zum Testen können Sie ?sslmode=disable in Ihrer Postgres-Abfragezeichenfolge festlegen).
Stellen Sie sicher, dass Sie Python 3 installiert haben (dies ist für Solc-Select erforderlich, das zum Kompilieren von Soliditätsverträgen benötigt wird).
Laden Sie Chainlink herunter: git clone https://github.com/smartcontractkit/chainlink && cd chainlink
Erstellen und installieren Sie Chainlink: make install
Führen Sie den Knoten aus: chainlink help
Aktuelle Informationen zum Einrichten einer Entwicklungsumgebung finden Sie im Development Setup Guide.
Native Builds auf dem Apple Silicon sollten sofort funktionieren, das Docker-Image erfordert jedoch mehr Überlegung.
$ docker build . -t chainlink-develop:latest -f ./core/chainlink.Dockerfile
Um den Chainlink-Knoten ausführen zu können, müssen Sie Zugriff auf einen laufenden Ethereum-Knoten mit einer offenen Websocket-Verbindung haben. Jedes auf Ethereum basierende Netzwerk funktioniert, sobald Sie die Ketten-ID konfiguriert haben. Derzeit getestete und unterstützte Ethereum-Knotenversionen:
[Offiziell unterstützt]
Parity/Openethereum (HINWEIS: Parity ist veraltet und die Unterstützung für diesen Client wird möglicherweise in Zukunft entfernt)
Geth
Besu
[Unterstützt, aber defekt] Diese Clients werden von Chainlink unterstützt, weisen jedoch Fehler auf, die verhindern, dass Chainlink auf diesen Ausführungsclients zuverlässig funktioniert.
Probleme mit der Nethermind-Blockierung:
NethermindEth/nethermind#4384
Probleme mit der Erigon-Blockierung:
erigontech/erigon#4946
erigontech/erigon#4030 (Kommentar)
Wir können keine spezifischen Versionsnummern für Ethereum-Knoten empfehlen, da die Software ständig aktualisiert wird. Sie sollten jedoch normalerweise versuchen, die neueste verfügbare Version auszuführen.
HINWEIS : Standardmäßig wird Chainlink im TLS-Modus ausgeführt. Für die lokale Entwicklung können Sie dies deaktivieren, indem Sie einen dev build mit make chainlink-dev verwenden und die TOML-Felder festlegen:
[WebServer]SecureCookies = falseTLS.HTTPSPort = 0[Insecure]DevWebServer = true
Alternativ können Sie selbstsignierte Zertifikate mit tools/bin/self-signed-certs oder manuell generieren.
Um Ihren Chainlink-Knoten zu starten, führen Sie einfach Folgendes aus:
Start des Chainlink-Knotens
Standardmäßig startet dies auf Port 6688. Sie sollten unter http://localhost:6688/ auf die Benutzeroberfläche zugreifen können.
Chainlink bietet einen Remote-CLI-Client sowie eine Benutzeroberfläche. Sobald Ihr Knoten gestartet ist, können Sie ein neues Terminalfenster öffnen, um die CLI zu verwenden. Um den Kunden zu autorisieren, müssen Sie sich zunächst anmelden:
Chainlink-Administrator-Login
(Sie können in Zukunft auch ADMIN_CREDENTIALS_FILE=/path/to/credentials/file festlegen, wenn Sie möchten, um eine erneute Anmeldung zu vermeiden.)
Jetzt können Sie Ihre aktuellen Jobs anzeigen mit:
Liste der Chainlink-Jobs
Um mehr über die Chainlink-CLI zu erfahren, können Sie jederzeit chainlink help ausführen.
Schauen Sie sich die Dokumentationsseiten zu Jobs an, um mehr darüber zu erfahren, wie Sie Jobs erstellen.
Die Knotenkonfiguration wird durch eine Kombination aus Umgebungsvariablen und direkter Einstellung über API/UI/CLI verwaltet.
Weitere Informationen zur Konfiguration Ihres Knotens finden Sie in der offiziellen Dokumentation.
Externe Adapter machen Chainlink einfach erweiterbar und ermöglichen eine einfache Integration benutzerdefinierter Berechnungen und spezialisierter APIs. Ein Chainlink-Knoten kommuniziert mit externen Adaptern über eine einfache REST-API.
Weitere Informationen zum Erstellen und Verwenden externer Adapter finden Sie auf unserer Seite zu externen Adaptern.
Wir verwenden cosign mit schlüssellosem OIDC-Signieren während des Chainlink-Workflows zum Erstellen, Signieren und Veröffentlichen.
Wir empfehlen jedem Knotenbetreiber, der aus dem offiziellen Chainlink-Docker-Image erstellt, zu überprüfen, ob die getaggte Release-Version tatsächlich mit diesem Workflow erstellt wurde.
Für diese Überprüfung benötigen Sie cosign . Befolgen Sie die Anweisungen hier, um cosign zu installieren.
# Tag ist die getaggte Release-Version – d. h. v2.16.0cosign verifizieren 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}“Installieren Sie pnpm 9 über npm
Installieren Sie gencodec und jq, um go generate ./... und make abigen ausführen zu können
Installieren Sie Spott
make mockery
Mit dem Befehl make wird die richtige Version installiert.
Bauverträge:
Pushd-Verträge pnpm i pnpm kompilieren:nativepopd
Statische Assets generieren und kompilieren:
erzeugen lassen
Bereiten Sie Ihre Entwicklungsumgebung vor:
Für die Tests ist eine Postgres-Datenbank erforderlich. Die Umgebungsvariable CL_DATABASE_URL wiederum muss auf einen Wert gesetzt werden, der eine Verbindung zur _test -Datenbank herstellen kann, und der Benutzer muss in der Lage sein, die angegebene _test -Datenbank zu erstellen und zu löschen.
Hinweis: Damit alle Tests erfolgreich sind, sollten keine anderen Umgebungsvariablen festgelegt werden
Es gibt ein Hilfsskript für die Ersteinrichtung, um einen geeigneten Testbenutzer zu erstellen. Dafür muss Postgres auf localhost an Port 5432 ausgeführt werden. Sie werden zur Eingabe des postgres Benutzerkennworts aufgefordert
make setup-testdb
Dieses Skript speichert die CL_DATABASE_URL in .dbenv
Änderungen an der Datenbank erfordern die Durchführung von Migrationen. Ebenso kann das pull des Repos die Ausführung von Migrationen erfordern. Nach der einmaligen Einrichtung oben:
source .dbenv make testdb
Wenn Sie auf den Fehler database accessed by other users (SQLSTATE 55006) exit status 1 und Sie möchten die Datenbankerstellung erzwingen, dann verwenden Sie
source .dbenv make testdb-force
Führen Sie Tests durch:
geh testen ./...
Das parallel kann verwendet werden, um die CPU-Auslastung zu begrenzen, um Tests im Hintergrund auszuführen ( -parallel=4 ) – der Standardwert ist GOMAXPROCS
Das p -Flag kann verwendet werden, um die Anzahl gleichzeitig getesteter Pakete zu begrenzen, wenn sie sich gegenseitig stören ( -p=1 ).
Das Flag -short überspringt Tests, die von der Datenbank abhängen, um einfachere Tests schnell und in etwa einer Minute stichprobenartig zu überprüfen
Ab Go 1.1 enthält die Laufzeit einen Datenrennen-Detektor, der mit dem Flag -race aktiviert wird. Dies wird in CI über das Skript tools/bin/go_core_race_tests verwendet. Wenn die Aktion ein Rennen erkennt, enthält das Artefakt auf der Zusammenfassungsseite race.* -Dateien mit detaillierten Stack-Traces.
Es werden keine Fehlalarme ausgegeben, also nehmen Sie die Warnungen ernst.
Für eine lokale, gezielte Rassenerkennung können Sie Folgendes ausführen:
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
Ab Go 1.18 sind die Fuzz-Tests func FuzzXXX(*testing.F) als Teil der normalen Testsuite enthalten, sodass vorhandene Fälle mit go test ausgeführt werden.
Darüber hinaus können Sie aktives Fuzzing ausführen, um nach neuen Fällen zu suchen:
go test ./pkg/path -run=XXX -fuzz=FuzzTestName
https://go.dev/doc/fuzz/
Dieses Repository enthält drei Go-Module:
Flussdiagramm 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 Laden Die Module integration-tests und core/scripts importieren das Root-Modul mithilfe eines relativen Ersetzens in ihren go.mod Dateien, sodass Abhängigkeitsänderungen in der root go.mod häufig auch Änderungen in diesen Modulen erfordern. Nach einer Änderung kann go mod tidy auf allen drei Modulen ausgeführt werden mit:
make gomodtidy
Im Verzeichnis contracts/ :
Abhängigkeiten installieren:
pnpm i
Führen Sie Tests durch:
pnpm-Test
HINWEIS: Chainlink migriert derzeit zu Foundry und enthält in einigen Versionen sowohl Foundry- als auch Hardhat-Tests. Weitere Informationen finden Sie hier: Chainlink Foundry-Dokumentation. Alle „t.sol“-Dateien, die mit Foundry-Tests verknüpft sind und in den src-Verzeichnissen enthalten sind, werden von Hardhat ignoriert.
Go Generate wird in diesem Projekt zum Generieren von Mocks verwendet. Mocks werden mit Spott generiert und leben in core/internal/mocks.
Zur Verwendung mit dem Nix-Paketmanager wird eine Shell.nix bereitgestellt. Standardmäßig nutzen wir die Shell über Nix Flakes.
Nix definiert eine deklarative, reproduzierbare Entwicklungsumgebung. Die Flakes-Version verwendet deterministische, eingefrorene ( flake.lock ) Abhängigkeiten, um mehr Konsistenz/Reproduzierbarkeit der erstellten Artefakte zu erreichen.
Um es zu verwenden:
Installieren Sie den Nix-Paketmanager in Ihrem System.
Aktivieren Sie die Flakes-Unterstützung
Führen Sie nix develop aus. Sie werden in eine Shell verschoben, die alle Abhängigkeiten enthält.
Optional verwendet nix develop --command $SHELL Ihre aktuelle Shell anstelle der Standard-Shell (Bash).
Sie können direnv verwenden, um es automatisch zu aktivieren, wenn cd in den Ordner wechseln. Aktivieren Sie dazu nix-direnv und use flake darauf.
Erstellen Sie eine lokale Postgres-Datenbank:
mkdir -p $PGDATA && cd $PGDATA/ initdb pg_ctl -l postgres.log -o "--unix_socket_directories='$PWD'" starten erstelltb chainlink_test -h localhost createuser --superuser --password chainlink -h localhost# Geben Sie dann ein Testkennwort ein, z. B. Chainlink, und legen Sie es in Shell.nix CL_DATABASE_URL fest
Wenn Sie das Projekt erneut aufrufen, können Sie postgres neu starten: cd $PGDATA; pg_ctl -l postgres.log -o "--unix_socket_directories='$PWD'" start Jetzt können Sie wie gewohnt Tests ausführen oder Code kompilieren.
Wenn Sie fertig sind, stoppen Sie es: cd $PGDATA; pg_ctl -o "--unix_socket_directories='$PWD'" stop
Wir verwenden Änderungssätze, um die Versionierung für Bibliotheken und Dienste zu verwalten.
Jeder PR, der eine Konfiguration oder einen Code ändert, sollte höchstwahrscheinlich von einer Changeset-Datei begleitet werden.
So installieren Sie changesets :
Installieren Sie pnpm falls es noch nicht installiert ist – Dokumente.
Führen Sie pnpm install .
Führen Sie entweder nach oder vor dem Erstellen eines Commits den Befehl pnpm changeset aus, um einen begleitenden Changeset-Eintrag zu erstellen, der sich im CHANGELOG für die nächste Version widerspiegelt.
Das Format basiert auf Keep a Changelog,
und dieses Projekt hält sich an die semantische Versionierung.
Weitere Tipps zum Erstellen und Testen von Chainlink finden Sie auf unserer Seite mit Entwicklungstipps.
Beiträge zum Quellcode von Chainlink sind willkommen.
Weitere Einzelheiten finden Sie in unseren Beitragsrichtlinien.
Danke schön!
