Przejdź do głównej zawartości

Jak rozwijać i testować dApp na lokalnej, wieloklientowej sieci testowej

klienci
węzły
smart kontrakty
kompozycyjność
warstwa konsensusu
warstwa wykonawcza
testowanie
Średnio zaawansowany
Tedi Mitiku
11 kwietnia 2023
10 minuta czytania

Wprowadzenie

Ten poradnik przeprowadzi Cię przez proces tworzenia konfigurowalnej lokalnej sieci testowej Ethereum, wdrażania na niej smart kontraktu i używania sieci testowej do przeprowadzania testów Twojej dApp. Ten poradnik jest przeznaczony dla deweloperów dApp, którzy chcą rozwijać i testować swoje dapki lokalnie w różnych konfiguracjach sieci przed wdrożeniem na działającą sieć testową lub sieć główną.

W tym poradniku:

  • Utworzyć lokalną sieć testową Ethereum za pomocą pakietu eth-network-package (opens in a new tab) przy użyciu Kurtosis (opens in a new tab),
  • Połączyć swoje środowisko programistyczne dApp Hardhat z lokalną siecią testową w celu kompilacji, wdrożenia i przetestowania dApp oraz
  • Skonfigurować lokalną sieć testową, w tym parametry takie jak liczba węzłów i określone pary klientów EL/CL, aby umożliwić procesy programistyczne i testowe w różnych konfiguracjach sieci.

Czym jest Kurtosis?

Kurtosis (opens in a new tab) to komponowalny system budowania przeznaczony do konfigurowania wielokontenerowych środowisk testowych. W szczególności umożliwia deweloperom tworzenie odtwarzalnych środowisk, które wymagają dynamicznej logiki konfiguracji, takich jak sieci testowe blockchain.

W tym poradniku pakiet eth-network-package Kurtosis uruchamia lokalną sieć testową Ethereum z obsługą klienta warstwy wykonawczej (EL) geth (opens in a new tab), a także klientów warstwy konsensusu (CL) teku (opens in a new tab), lighthouse (opens in a new tab) i lodestar (opens in a new tab). Ten pakiet służy jako konfigurowalna i komponowalna alternatywa dla sieci w frameworkach takich jak Hardhat Network, Ganache i Anvil. Kurtosis oferuje deweloperom większą kontrolę i elastyczność nad sieciami testowymi, których używają, co jest głównym powodem, dla którego Ethereum Foundation użyła Kurtosis do testowania Połączenia (opens in a new tab) i nadal używa go do testowania aktualizacji sieci.

Konfiguracja Kurtosis

Zanim przejdziesz dalej, upewnij się, że masz:

Tworzenie lokalnej sieci testowej Ethereum

Aby uruchomić lokalną sieć testową Ethereum, wykonaj:

1kurtosis --enclave local-eth-testnet run github.com/kurtosis-tech/eth-network-package

Uwaga: to polecenie nazywa Twoją sieć: "local-eth-testnet" za pomocą flagi --enclave.

Kurtosis wydrukuje kroki, które podejmuje w tle, podczas gdy interpretuje, waliduje, a następnie wykonuje instrukcje. Na końcu powinieneś zobaczyć dane wyjściowe podobne do poniższych:

1INFO[2023-04-04T18:09:44-04:00] ======================================================
2INFO[2023-04-04T18:09:44-04:00] ||          Created enclave: local-eth-testnet      ||
3INFO[2023-04-04T18:09:44-04:00] ======================================================
4Name:            local-eth-testnet
5UUID:            39372d756ae8
6Status:          RUNNING
7Creation Time:   Tue, 04 Apr 2023 18:09:03 EDT
8
9========================================= Files Artifacts =========================================
10UUID           Name
11d4085a064230   cl-genesis-data
121c62cb792e4c   el-genesis-data
13bd60489b73a7   genesis-generation-config-cl
14b2e593fe5228   genesis-generation-config-el
15d552a54acf78   geth-prefunded-keys
165f7e661eb838   prysm-password
17054e7338bb59   validator-keystore-0
18
19========================================== User Services ==========================================
20UUID           Name                                           Ports                                         Status
21e20f129ee0c5   cl-client-0-beacon                             http: 4000/tcp -> <http://127.0.0.1:54261>    RUNNING
22                                                              metrics: 5054/tcp -> <http://127.0.0.1:54262>
23                                                              tcp-discovery: 9000/tcp -> 127.0.0.1:54263
24                                                              udp-discovery: 9000/udp -> 127.0.0.1:60470
25a8b6c926cdb4   cl-client-0-validator                          http: 5042/tcp -> 127.0.0.1:54267             RUNNING
26                                                              metrics: 5064/tcp -> <http://127.0.0.1:54268>
27d7b802f623e8   el-client-0                                    engine-rpc: 8551/tcp -> 127.0.0.1:54253       RUNNING
28                                                              rpc: 8545/tcp -> 127.0.0.1:54251
29                                                              tcp-discovery: 30303/tcp -> 127.0.0.1:54254
30                                                              udp-discovery: 30303/udp -> 127.0.0.1:53834
31                                                              ws: 8546/tcp -> 127.0.0.1:54252
32514a829c0a84   prelaunch-data-generator-1680646157905431468   <none>                                        STOPPED
3362bd62d0aa7a   prelaunch-data-generator-1680646157915424301   <none>                                        STOPPED
3405e9619e0e90   prelaunch-data-generator-1680646157922872635   <none>                                        STOPPED
35
Pokaż wszystko

Gratulacje! Użyłeś Kurtosis do utworzenia lokalnej sieci testowej Ethereum z klientem CL (lighthouse) i klientem EL (geth) za pośrednictwem Dockera.

Podsumowanie

W tej sekcji wykonałeś polecenie, które poleciło Kurtosis użycie pakietu eth-network-package hostowanego zdalnie na GitHub (opens in a new tab) do uruchomienia lokalnej sieci testowej Ethereum w enklawie Kurtosis Enclave (opens in a new tab). Wewnątrz enklawy znajdziesz zarówno "artefakty plików", jak i "usługi użytkownika".

Artefakty plików (opens in a new tab) w Twojej enklawie zawierają wszystkie dane wygenerowane i wykorzystane do uruchomienia klientów EL i CL. Dane zostały utworzone za pomocą usługi prelaunch-data-generator zbudowanej z tego obrazu Docker (opens in a new tab)

Usługi użytkownika wyświetlają wszystkie skonteneryzowane usługi działające w Twojej enklawie. Zauważysz, że został utworzony pojedynczy węzeł, zawierający zarówno klienta EL, jak i klienta CL.

Połącz swoje środowisko programistyczne dApp z lokalną siecią testową Ethereum

Konfiguracja środowiska programistycznego dApp

Teraz, gdy masz działającą lokalną sieć testową, możesz połączyć swoje środowisko programistyczne dApp, aby korzystać z lokalnej sieci testowej. W tym poradniku zostanie użyty framework Hardhat do wdrożenia dApp do gry w blackjacka na Twojej lokalnej sieci testowej.

Aby skonfigurować środowisko programistyczne dApp, sklonuj repozytorium zawierające naszą przykładową dApp i zainstaluj jego zależności, uruchamiając:

1git clone https://github.com/kurtosis-tech/awesome-kurtosis.git && cd awesome-kurtosis/smart-contract-example && yarn

Użyty tutaj folder smart-contract-example (opens in a new tab) zawiera typową konfigurację dla dewelopera dApp korzystającego z frameworka Hardhat (opens in a new tab):

Konfiguracja Hardhat do korzystania z lokalnej sieci testowej

Po skonfigurowaniu środowiska programistycznego dApp, połączysz teraz Hardhat z lokalną siecią testową Ethereum wygenerowaną za pomocą Kurtosis. Aby to osiągnąć, zastąp <$YOUR_PORT> w strukturze localnet w pliku konfiguracyjnym hardhat.config.ts portem z danych wyjściowych rpc uri dowolnej usługi el-client-<num>. W tym przykładowym przypadku portem byłoby 64248. Twój port będzie inny.

Przykład w hardhat.config.ts:

1localnet: {
2url: 'http://127.0.0.1:<$YOUR_PORT>',// TODO: ZASTĄP $YOUR_PORT PORTEM URI WĘZŁA WYGENEROWANYM PRZEZ PAKIET SIECI ETH KURTOSIS
3
4// To są klucze prywatne powiązane z prefinansowanymi kontami testowymi utworzonymi przez eth-network-package
5// <https://github.com/kurtosis-tech/eth-network-package/blob/main/src/prelaunch_data_generator/genesis_constants/genesis_constants.star>
6accounts: [
7    "ef5177cd0b6b21c87db5a0bf35d4084a8a57a9d6a064f86d51ac85f2b873a4e2",
8    "48fcc39ae27a0e8bf0274021ae6ebd8fe4a0e12623d61464c498900b28feb567",
9    "7988b3a148716ff800414935b305436493e1f25237a2a03e5eebc343735e2f31",
10    "b3c409b6b0b3aa5e65ab2dc1930534608239a478106acf6f3d9178e9f9b00b35",
11    "df9bb6de5d3dc59595bcaa676397d837ff49441d211878c024eabda2cd067c9f",
12    "7da08f856b5956d40a72968f93396f6acff17193f013e8053f6fbb6c08c194d6",
13  ],
14},
Pokaż wszystko

Po zapisaniu pliku Twoje środowisko programistyczne dApp Hardhat jest połączone z lokalną siecią testową Ethereum! Możesz sprawdzić, czy Twoja sieć testowa działa, uruchamiając:

1npx hardhat balances --network localnet

Dane wyjściowe powinny wyglądać mniej więcej tak:

10x878705ba3f8Bc32FCf7F4CAa1A35E72AF65CF766 has balance 10000000000000000000000000
20x4E9A3d9D1cd2A2b2371b8b3F489aE72259886f1A has balance 10000000000000000000000000
30xdF8466f277964Bb7a0FFD819403302C34DCD530A has balance 10000000000000000000000000
40x5c613e39Fc0Ad91AfDA24587e6f52192d75FBA50 has balance 10000000000000000000000000
50x375ae6107f8cC4cF34842B71C6F746a362Ad8EAc has balance 10000000000000000000000000
60x1F6298457C5d76270325B724Da5d1953923a6B88 has balance 10000000000000000000000000

To potwierdza, że Hardhat korzysta z Twojej lokalnej sieci testowej i wykrywa wstępnie zasilone konta utworzone przez eth-network-package.

Wdróż i przetestuj swoją dApp lokalnie

Gdy środowisko programistyczne dApp jest w pełni połączone z lokalną siecią testową Ethereum, możesz teraz uruchamiać procesy programistyczne i testowe dla swojej dApp, korzystając z lokalnej sieci testowej.

Aby skompilować i wdrożyć smart kontrakt ChipToken.sol do lokalnego prototypowania i rozwoju, uruchom:

1npx hardhat compile
2npx hardhat run scripts/deploy.ts --network localnet

Dane wyjściowe powinny wyglądać mniej więcej tak:

1ChipToken wdrożono do: 0xAb2A01BC351770D09611Ac80f1DE076D56E0487d

Teraz spróbuj uruchomić test simple.js na swojej lokalnej dApp, aby potwierdzić, że każdemu graczowi w naszej dApp Blackjack zostało wybite 1000 żetonów:

Dane wyjściowe powinny wyglądać mniej więcej tak:

1npx hardhat test --network localnet

Dane wyjściowe powinny wyglądać mniej więcej tak:

1ChipToken
2    wybij
3      ✔ powinien wybić 1000 żetonów dla GRACZA PIERWSZEGO
4
5  1 przeszedł (654ms)

Podsumowanie

W tym momencie skonfigurowałeś środowisko programistyczne dApp, połączyłeś je z lokalną siecią Ethereum utworzoną przez Kurtosis oraz skompilowałeś, wdrożyłeś i uruchomiłeś prosty test dla swojej dApp.

Teraz zbadajmy, jak można skonfigurować podstawową sieć do testowania naszych dapek w różnych konfiguracjach sieci.

Konfiguracja lokalnej sieci testowej Ethereum

Zmiana konfiguracji klienta i liczby węzłów

Twoją lokalną sieć testową Ethereum można skonfigurować do używania różnych par klientów EL i CL, a także różnej liczby węzłów, w zależności od scenariusza i konkretnej konfiguracji sieci, którą chcesz rozwijać lub testować. Oznacza to, że po skonfigurowaniu możesz uruchomić dostosowaną lokalną sieć testową i używać jej do uruchamiania tych samych procesów (wdrażanie, testy itp.) w różnych konfiguracjach sieci, aby upewnić się, że wszystko działa zgodnie z oczekiwaniami. Aby dowiedzieć się więcej o innych parametrach, które możesz modyfikować, odwiedź ten link.

Spróbuj! Możesz przekazać różne opcje konfiguracyjne do eth-network-package za pośrednictwem pliku JSON. Ten plik JSON z parametrami sieci dostarcza określonych konfiguracji, których Kurtosis użyje do skonfigurowania lokalnej sieci Ethereum.

Weź domyślny plik konfiguracyjny i edytuj go, aby uruchomić dwa węzły z różnymi parami EL/CL:

  • Węzeł 1 z geth/lighthouse
  • Węzeł 2 z geth/lodestar
  • Węzeł 3 z geth/teku

Ta konfiguracja tworzy heterogeniczną sieć implementacji węzłów Ethereum do testowania Twojej dApp. Twój plik konfiguracyjny powinien teraz wyglądać następująco:

1{
2  "participants":
3    [
4      {
5        "el_client_type": "geth",
6        "el_client_image": "",
7        "el_client_log_level": "",
8        "cl_client_type": "lighthouse",
9        "cl_client_image": "",
10        "cl_client_log_level": "",
11        "beacon_extra_params": [],
12        "el_extra_params": [],
13        "validator_extra_params": [],
14        "builder_network_params": null,
15      },
16      {
17        "el_client_type": "geth",
18        "el_client_image": "",
19        "el_client_log_level": "",
20        "cl_client_type": "lodestar",
21        "cl_client_image": "",
22        "cl_client_log_level": "",
23        "beacon_extra_params": [],
24        "el_extra_params": [],
25        "validator_extra_params": [],
26        "builder_network_params": null,
27      },
28      {
29        "el_client_type": "geth",
30        "el_client_image": "",
31        "el_client_log_level": "",
32        "cl_client_type": "teku",
33        "cl_client_image": "",
34        "cl_client_log_level": "",
35        "beacon_extra_params": [],
36        "el_extra_params": [],
37        "validator_extra_params": [],
38        "builder_network_params": null,
39      },
40    ],
41  "network_params":
42    {
43      "preregistered_validator_keys_mnemonic": "giant issue aisle success illegal bike spike question tent bar rely arctic volcano long crawl hungry vocal artwork sniff fantasy very lucky have athlete",
44      "num_validator_keys_per_node": 64,
45      "network_id": "3151908",
46      "deposit_contract_address": "0x4242424242424242424242424242424242424242",
47      "seconds_per_slot": 12,
48      "genesis_delay": 120,
49      "capella_fork_epoch": 5,
50    },
51}
Pokaż wszystko

Każda struktura participants odpowiada węzłowi w sieci, więc 3 struktury participants poinformują Kurtosis, aby uruchomić 3 węzły w Twojej sieci. Każda struktura participants pozwoli Ci określić parę EL i CL używaną dla tego konkretnego węzła.

Struktura network_params konfiguruje ustawienia sieci, które są używane do tworzenia plików genezy dla każdego węzła, a także inne ustawienia, takie jak sekundy na slot sieci.

Zapisz edytowany plik parametrów w dowolnym katalogu (w poniższym przykładzie jest on zapisany na pulpicie), a następnie użyj go do uruchomienia pakietu Kurtosis, uruchamiając:

1kurtosis clean -a && kurtosis run --enclave local-eth-testnet github.com/kurtosis-tech/eth-network-package \"$(cat ~/eth-network-params.json)\"

Uwaga: polecenie kurtosis clean -a jest tutaj używane, aby poinstruować Kurtosis, aby zniszczył starą sieć testową i jej zawartość przed uruchomieniem nowej.

Ponownie, Kurtosis będzie działać przez chwilę i wydrukuje poszczególne kroki, które mają miejsce. Ostatecznie, dane wyjściowe powinny wyglądać mniej więcej tak:

1Starlark code successfully run. No output was returned.
2INFO[2023-04-07T11:43:16-04:00] ==========================================================
3INFO[2023-04-07T11:43:16-04:00] ||          Created enclave: local-eth-testnet          ||
4INFO[2023-04-07T11:43:16-04:00] ==========================================================
5Name:            local-eth-testnet
6UUID:            bef8c192008e
7Status:          RUNNING
8Creation Time:   Fri, 07 Apr 2023 11:41:58 EDT
9
10========================================= Files Artifacts =========================================
11UUID           Name
12cc495a8e364a   cl-genesis-data
137033fcdb5471   el-genesis-data
14a3aef43fc738   genesis-generation-config-cl
158e968005fc9d   genesis-generation-config-el
163182cca9d3cd   geth-prefunded-keys
178421166e234f   prysm-password
18d9e6e8d44d99   validator-keystore-0
1923f5ba517394   validator-keystore-1
204d28dea40b5c   validator-keystore-2
21
22========================================== User Services ==========================================
23UUID           Name                                           Ports                                            Status
24485e6fde55ae   cl-client-0-beacon                             http: 4000/tcp -> http://127.0.0.1:65010         RUNNING
25                                                              metrics: 5054/tcp -> http://127.0.0.1:65011
26                                                              tcp-discovery: 9000/tcp -> 127.0.0.1:65012
27                                                              udp-discovery: 9000/udp -> 127.0.0.1:54455
2873739bd158b2   cl-client-0-validator                          http: 5042/tcp -> 127.0.0.1:65016                RUNNING
29                                                              metrics: 5064/tcp -> http://127.0.0.1:65017
301b0a233cd011   cl-client-1-beacon                             http: 4000/tcp -> 127.0.0.1:65021                RUNNING
31                                                              metrics: 8008/tcp -> 127.0.0.1:65023
32                                                              tcp-discovery: 9000/tcp -> 127.0.0.1:65024
33                                                              udp-discovery: 9000/udp -> 127.0.0.1:56031
34                                                              validator-metrics: 5064/tcp -> 127.0.0.1:65022
35949b8220cd53   cl-client-1-validator                          http: 4000/tcp -> 127.0.0.1:65028                RUNNING
36                                                              metrics: 8008/tcp -> 127.0.0.1:65030
37                                                              tcp-discovery: 9000/tcp -> 127.0.0.1:65031
38                                                              udp-discovery: 9000/udp -> 127.0.0.1:60784
39                                                              validator-metrics: 5064/tcp -> 127.0.0.1:65029
40c34417bea5fa   cl-client-2                                    http: 4000/tcp -> 127.0.0.1:65037                RUNNING
41                                                              metrics: 8008/tcp -> 127.0.0.1:65035
42                                                              tcp-discovery: 9000/tcp -> 127.0.0.1:65036
43                                                              udp-discovery: 9000/udp -> 127.0.0.1:63581
44e19738e6329d   el-client-0                                    engine-rpc: 8551/tcp -> 127.0.0.1:64986          RUNNING
45                                                              rpc: 8545/tcp -> 127.0.0.1:64988
46                                                              tcp-discovery: 30303/tcp -> 127.0.0.1:64987
47                                                              udp-discovery: 30303/udp -> 127.0.0.1:55706
48                                                              ws: 8546/tcp -> 127.0.0.1:64989
49e904687449d9   el-client-1                                    engine-rpc: 8551/tcp -> 127.0.0.1:64993          RUNNING
50                                                              rpc: 8545/tcp -> 127.0.0.1:64995
51                                                              tcp-discovery: 30303/tcp -> 127.0.0.1:64994
52                                                              udp-discovery: 30303/udp -> 127.0.0.1:58096
53                                                              ws: 8546/tcp -> 127.0.0.1:64996
54ad6f401126fa   el-client-2                                    engine-rpc: 8551/tcp -> 127.0.0.1:65003          RUNNING
55                                                              rpc: 8545/tcp -> 127.0.0.1:65001
56                                                              tcp-discovery: 30303/tcp -> 127.0.0.1:65000
57                                                              udp-discovery: 30303/udp -> 127.0.0.1:57269
58                                                              ws: 8546/tcp -> 127.0.0.1:65002
5912d04a9dbb69   prelaunch-data-generator-1680882122181135513   <none>                                           STOPPED
605b45f9c0504b   prelaunch-data-generator-1680882122192182847   <none>                                           STOPPED
613d4aaa75e218   prelaunch-data-generator-1680882122201668972   <none>                                           STOPPED
Pokaż wszystko

Gratulacje! Pomyślnie skonfigurowałeś swoją lokalną sieć testową, aby miała 3 węzły zamiast 1. Aby uruchomić te same procesy, co wcześniej, w swojej dApp (wdrażanie i testowanie), wykonaj te same operacje, co poprzednio, zastępując <$YOUR_PORT> w strukturze localnet w pliku konfiguracyjnym hardhat.config.ts portem z danych wyjściowych rpc uri dowolnej usługi el-client-<num> w nowej, 3-węzłowej lokalnej sieci testowej.

Wnioski

I to wszystko! Podsumowując ten krótki poradnik, Ty:

  • Utworzyłeś lokalną sieć testową Ethereum za pośrednictwem Dockera przy użyciu Kurtosis
  • Połączyłeś swoje lokalne środowisko programistyczne dApp z lokalną siecią Ethereum
  • Wdrożyłeś dApp i uruchomiłeś prosty test na lokalnej sieci Ethereum
  • Skonfigurowałeś podstawową sieć Ethereum, aby miała 3 węzły

Chcielibyśmy usłyszeć od Ciebie, co poszło Ci dobrze, co można by poprawić, lub odpowiedzieć na wszelkie Twoje pytania. Nie wahaj się skontaktować z nami za pośrednictwem GitHub (opens in a new tab) lub napisz do nas e-mail (opens email client)!

Inne przykłady i poradniki

Zachęcamy do zapoznania się z naszym szybkim startem (opens in a new tab) (gdzie zbudujesz bazę danych Postgres i API) oraz innymi przykładami w naszym repozytorium awesome-kurtosis (opens in a new tab), gdzie znajdziesz świetne przykłady, w tym pakiety do:

  • Uruchamiania tej samej lokalnej sieci testowej Ethereum, ale z podłączonymi dodatkowymi usługami, takimi jak spamer transakcji (do symulowania transakcji), monitor forka oraz podłączona instancja Grafana i Prometheus
  • Przeprowadzania testu podsieci (opens in a new tab) na tej samej lokalnej sieci Ethereum

Strona ostatnio zaktualizowana: 23 września 2025

mdqstm (opens in a new tab)
brossetti1b (opens in a new tab)
corwintinesc (opens in a new tab)
+2

Czy ten samouczek był pomocny?