rpcpool.solana_rpc

Rola RPC Solana

Rola Ansible do wdrożenia węzła RPC Solana. Konfiguruje oprogramowanie walidatora w trybie RPC, działającym pod użytkownikiem solana. Usługa RPC jest instalowana jako usługa użytkownika, działająca pod tym samym użytkownikiem.

Aktualizacje

16/02 - Od wersji Solana 1.8.15 (mainnet) i 1.9.6 (testnet) należy określić solana_full_rpc_api: true, aby ta rola mogła stworzyć w pełni eksponowany węzeł API RPC.

Wymagania sprzętowe

Serwer RPC wymaga co najmniej takich samych specyfikacji jak walidator Solana, ale zazwyczaj ma wyższe wymagania. Zwłaszcza zalecamy użycie 256 GB pamięci RAM, aby móc przechowywać indeksy. Więcej informacji na temat wymagań sprzętowych można znaleźć pod adresem https://docs.solana.com/running-validator/validator-reqs. Zdecydowanie polecamy korzystanie z dostawcy baremetal (nie Hetzner) zamiast dostawcy chmurowego, chyba że dokładnie wiesz, co robisz (a jeśli tak, to czemu czytasz tę stronę?).

Przed wdrożeniem należy przygotować host, aby katalog używany do bazy danych kont i lokalizacji księgi był odpowiednio skonfigurowany. Może to obejmować ustawienie folderu tmpfs dla kont oraz oddzielnego systemu plików (najlepiej na dysku NVME) dla księgi. Typowy sposób konfiguracji może wyglądać tak:

/solana/tmpfs - partycja tmpfs o pojemności 100 GB do przechowywania stanu kont
/solana/ledger - dysk NVME o pojemności 2 TB do przechowywania księgi

Dlaczego bare metal, a nie chmura?

Serwery w chmurze (AWS, GCP itp.) są zazwyczaj nieodpowiednie dla Solana z wielu powodów:

Wydatki na egress są naprawdę wysokie, a Solana wykorzystuje dużo egress.
Wydajność pojedynczego rdzenia jest zazwyczaj zbyt niska i nie może się zwiększyć w sposób, w jaki mogą to robić systemy baremetal.
Wiele dostawców chmurowych nie chce obsługiwać obciążenia, które generuje Solana na swoich tańszych instancjach, co prowadzi do korzystania z bardzo drogich instancji baremetal.

Dlaczego nie Hetzner?

Hetzner zdecydował, że nie chce, aby usługi RPC Solana działały w ich sieci. Aktywnie blokują połączenia do punktów wejściowych Solany i ograniczają wszelkie połączenia Solana. Nie tylko twój węzeł Solana będzie miał trudności z nadążeniem za siecią (na mainnet prawdopodobnie nigdy nie nadgoni), ale Hetzner bardzo prawdopodobnie zamknie twoje konto.

Wymagania programowe

Ansible >= 2.7 (głównie testowane na Ansible 2.8)
Ubuntu 18.04+ na docelowej maszynie wdrożeniowej

Ta rola zakłada pewną znajomość procesu wdrażania oprogramowania walidatora Solana.

Zmienne roli

Wdrożenie zapewnia, że suma kontrolna dla wersji solana-installer, którą pobierasz, pasuje do podanej w vars/main.yml. W przypadku chęci zainstalowania wersji solana, której tam nie wymieniono, dobrze jest najpierw pobrać i sprawdzić sumę kontrolną sha256 skryptu solana-installer (https://raw.githubusercontent.com/solana-labs/solana/master/install/solana-install-init.sh).

Istnieje wiele parametrów konfigurowalnych dla Solana. Wiele z nich ma działające domyślne wartości, a tę rolę można użyć do wdrożenia węzła RPC Solana bez zmiany jakichkolwiek wartości domyślnych, co powinno zapewnić przyzwoite doświadczenie. Jeśli uruchomisz tę rolę bez określania jakichkolwiek parametrów, skonfiguruje standardowy węzeł RPC mainnet.

Podstawowe zmienne

Są to podstawowe zmienne, które konfigurują ustawienie walidatorów. Mają domyślne wartości, ale prawdopodobnie chcesz je dostosować w zależności od swojej konfiguracji.

Nazwa	Wartość domyślna	Opis
`solana_version`	stable	Wersja Solana do zainstalowania.
`solana_full_rpc_api`	`true`	Czy włączyć pełne API RPC, czy nie. Tak zazwyczaj chcemy.
`solana_root`	/solana	Główny katalog dla księgi i kont Solana.
`solana_ledger_location`	/solana/ledger	Miejsce przechowywania księgi Solana (powinno być na NVME).
`solana_accounts_location`	/solana/ledger/accounts	Miejsce przechowywania informacji o kontach Solana. Jeśli używasz tmpfs dla kont, powinno to być podkatalogiem punktu montowania tmpfs (np. `/solana/tmpfs/accounts`, jeśli tmpfs jest zamontowany na `/solana/tmpfs`).
`solana_snapshots_location`		Miejsce do przechowywania zrzutów Solana. Może być przydatne, aby przechowywać je na oddzielnym NVME od księgi.
`solana_keypairs`	`[]`	Lista par kluczy do skopiowania do węzła walidatora. Każdy wpis w liście powinien mieć wpis `key` i `name`. Utworzy to `/home/solana/<name>.json` zawierający wartość `key`.
`solana_generate_keypair`	true	Czy generować parę kluczy, czy nie. Jeśli nie podałeś `solana_keypairs` i ustawisz to na true, nowy klucz zostanie wygenerowany i umieszczony w /home/solana/identity.json.
`solana_public_key`	`/home/solana/identity.json`	Lokalizacja tożsamości węzła walidatora.
`solana_network`	mainnet	Sieć Solana, której częścią ma być ten węzeł.
`solana_environment`	zobacz defaults/main.yml	Zmienne środowiskowe do określenia dla węzła walidatora, najważniejsze to `RUST_LOG`.
`solana_enabled_services`	`[ solana-rpc ]`	Lista usług do automatycznego uruchomienia przy starcie.
`solana_disabled_services`	`[ ]`	Lista usług do wyłączenia.

Porty

Następujące porty muszą być skonfigurowane dla twojego serwera RPC.

Nazwa	Wartość domyślna	Opis
`solana_gossip_port`	8001	Port dla ruchu gossip (musi być otwarty publicznie w zaporze zarówno dla TCP, jak i UDP).
`solana_rpc_port`	8899 (+8900)	Porty dla przychodzącego RPC (i websocket). To zazwyczaj otwarte tylko na localhost. Umieść coś jak `haproxy` z przodu tych portów i nie wystawiaj ich publicznie.
`solana_rpc_bind_address`	127.0.0.1	Adres do powiązania RPC. Zazwyczaj powinien to być localhost. Umieść coś jak `haproxy` z przodu tego, aby przyjmować ruch publiczny.
`solana_dynamic_port_range`	8002-8020	Port dla przychodzącego ruchu Solana. Może być wymagane otwarcie publicznie w zaporze dla UDP.

Z tej listy widzisz, że potrzebujesz co najmniej portów 8001-8020 otwartych w zaporze dla przychodzącego ruchu w przypadku domyślnym.

Dla czystych węzłów RPC może być możliwe zamknięcie portów TPU i TPU forward. Porty te są dynamicznie alokowane, a możesz je zobaczyć, przeglądając swój węzeł w solana gossip. Jeśli chcesz je zablokować, możesz użyć tego narzędzia: https://github.com/rpcpool/tpu-traffic-classifier. Korzystając z tego narzędzia, możesz zablokować przychodzące TPU i TPU forward na lokalnym węźle uruchamiając:

./tpu-traffic-classifier -config-file config.yml -our-localhost -tpu-policy DROP -fwd-policy DROP -update=false

Umieść to w usłudze SystemD i możesz to uruchomić przy uruchamianiu węzła oraz trzymać je w ciągłym działaniu.

Specyficzne zmienne sieciowe

Domyślne wartości dla tych zmiennych są określone w vars/{{ solana_network }}-default.yml (np. vars/mainnet-default.yml). Możesz również określić własne, dostarczając plik {{ solana_network }}.yml. Musisz określić wszystkie te zmienne, chyba że polegasz na domyślnych.

Nazwa	Wartość domyślna	Opis
`solana_network`	mainnet	Sieć Solana, do której ten węzeł powinien dołączyć.
`solana_metrics_config`	zobacz vars/mainnet-default.yml	Endpoint metryk.
`solana_genesis_hash`	zobacz vars/mainnet-default.yml	Hash genesis dla tej sieci.
`solana_entrypoints`	zobacz vars/mainnet-default.yml	Hosty punktów wejściowych.
`solana_known_validators`	zobacz vars/mainnet-default.yml	Znane walidatory, z których można pobierać zrzuty i genesis bin podczas uruchamiania.
`solana_expected_bank_hash`	zobacz vars/mainnet-default.yml	Oczekiwany hash banku.
`solana_expected_shred_version`	zobacz vars/mainnet-default.yml	Oczekiwana wersja shreda.
`solana_index_exclude_keys`	zobacz vars/mainnet-default.yml	Klucze do wykluczenia z indeksów ze względów wydajnościowych.

Specyficzne zmienne RPC

Nazwa	Wartość domyślna	Opis
`solana_rpc_faucet_address`		Określ adres fauceta RPC.
`solana_rpc_history`	true	Czy udostępnić historyczne wartości przez RPC.
`solana_account_index`	program-id spl-token-owner spl-token-mint	Które indeksy włączyć. Te znacząco poprawiają wydajność, ale spowalniają czas uruchamiania i mogą zwiększyć wymagania pamięciowe.

Zmienne wydajności

Są to zmienne, które możesz dostosować, aby poprawić wydajność.

Nazwa	Wartość domyślna	Opis
`solana_snapshot_compression`		Czy kompresować zrzuty, czy nie. Podaj none, aby poprawić wydajność.
`solana_snapshot_interval_slots`		Jak często robić zrzuty. Zwiększ, aby poprawić wydajność. Sugerowana wartość to 500.
`solana_pubsub_max_connections`	1000	Maksymalna liczba połączeń pubsub, które można zezwolić.
`solana_bpf_jit`		Czy włączyć BPF JIT. Domyślnie włączone dla devnet.
`solana_banking_threads`	16	Liczba wątków bankowych.
`solana_rpc_threads`		Liczba wątków RPC (domyślna maksymalna liczba wątków/rdzeni w systemie).
`solana_limit_ledger_size`	`solana default, 250 mio`	Rozmiar lokalnej księgi do przechowywania. Dla pełnej epoki ustaw wartość między 350-500 milionów. Dla najlepszej wydajności ustaw na 50 (minimalna wartość).
`solana_accounts_db_caching`		Czy włączyć pamięć podręczną bazy danych kont.
`solana_accounts_shrink_path`		Możesz określić inne miejsce dla procesu kurczenia kont.

Bigtable

Możesz określić dane uwierzytelniające konta Google Bigtable do zapytania o bloki, których brakuje w lokalnej księdze.

Nazwa	Wartość domyślna	Opis
`solana_bigtable_enabled`	false	Włącz dostęp do bigtable.
`solana_bigtable_upload_enabled`	false	Włącz przesyłanie do bigtable (podane dane uwierzytelniające muszą mieć dostęp do zapisu).
`solana_bigtable_project_id`		Identyfikator projektu bigtable.
`solana_bigtable_private_key_id`		Identyfikator klucza prywatnego bigtable.
`solana_bigtable_private_key`		Klucz prywatny bigtable.
`solana_bigtable_client_email`		E-mail klienta bigtable.
`solana_bigtable_client_id`		Identyfikator klienta bigtable.
`solana_bigtable_client_x509_cert_url`		Adres URL certyfikatu bigtable.

Więcej informacji na temat BigTable znajdziesz na stronie https://github.com/solana-labs/solana-bigtable.

Obsługa forków

Czasami devnet/testnet doświadczy forków. W tych przypadkach użyj następujących parametrów zgodnie z instrukcjami na Discordzie:

Nazwa	Wartość domyślna	Opis
`solana_hard_fork`		Twardy fork
`solana_wait_for_supermajority`		Czy węzeł powinien czekać na superwiększość, czy nie.

Ustawienia CPU i Sysctl

Są pewne konfiguracje, które należy wykonać, aby właściwie uruchomić węzeł RPC. Ta rola może pomóc ci w kilku standardowych zmianach konfiguracyjnych. Jednak pełna optymalizacja w dużej mierze zależy od twojego sprzętu, więc musisz poświęcić czas na zapoznanie się z prawidłową konfiguracją swojego sprzętu.

Jednak najważniejszym elementem optymalizacji jest wydajność CPU. Kontroluje to zachowanie boost i zużycie energii. W wielu hostach w centrach danych są skonfigurowane na równowagę między wydajnością a zużyciem energii. W przypadku Solany naprawdę potrzebujemy, aby działały z maksymalną wydajnością. Aby ustawić procesor serwera, dostępne są trzy opcje:

Masz dostęp do BIOS-u i ustawiasz ustawienie procesora BIOS na max performance. To wydaje się dobrze działać w systemach HPE. W tym przypadku określ zmienną cpu_governor: bios. Czasami jest to wymagane również dla systemów AMD EPYC.
Masz dostęp do BIOS-u i ustawiasz ustawienie procesora BIOS na os control. To powinno być typowym domyślnym ustawieniem. W takim przypadku możesz pozostawić zmienną cpu_governor jako domyślną lub ustawić ją jawnie na cpu_governor: performance.
Nie masz dostępu do BIOS-u ani ustawień procesora. Jeśli to możliwe, spróbuj ustawić cpu_governor: performance. W przeciwnym razie miejmy nadzieję, że twój dostawca skonfigurował to dla dobrej wydajności!

Drugą konfiguracją, którą musisz wykonać, jest edycja różnych parametrów jądra, aby dostosować je do przypadku użycia RPC Solana.

Jedna z opcji to wdrożenie solana-sys-tuner wraz z tą konfiguracją, aby automatycznie dostroić niektóre zmienne dla ciebie.

Drugą opcją, zwłaszcza jeśli jesteś nowy w optymalizacji wydajności, jest tuned i tune-adm z RedHat, gdzie profil throughput-performance jest odpowiedni.

Na koniec, jeśli wdrażasz przez tę rolę, możesz również określić listę wartości sysctl, które ta książka robocza automatycznie ustawi na twoim hoście. Pozwoli to na pełną kontrolę i trwałe ich skonfigurowanie. Oto lista wartości sysctl, które użyliśmy na rpcpool:

sysctl_optimisations:
  vm.max_map_count: 700000
  kernel.nmi_watchdog: 0
# Minimalne ograniczenie preempcji dla zadań obciążonych CPU:
# (domyślnie: 1 msec#  (1 + ilog(ncpus)), jednostki: nanosekundy)
  kernel.sched_min_granularity_ns: '10000000'
# Granularność budzenia SCHED_OTHER.
# (domyślnie: 1 msec#  (1 + ilog(ncpus)), jednostki: nanosekundy)
  kernel.sched_wakeup_granularity_ns:  '15000000' 
  vm.swappiness: '30'
  kernel.hung_task_timeout_secs: 600
# Oznacza to, że statystyki pamięci wirtualnej są zbierane rzadziej, ale jest to rozsądna wymiana za mniejsze opóźnienie.
  vm.stat_interval: 10
  vm.dirty_ratio: 40
  vm.dirty_background_ratio: 10
  vm.dirty_expire_centisecs: 36000
  vm.dirty_writeback_centisecs: 3000
  vm.dirtytime_expire_seconds: 43200
  kernel.timer_migration: 0
# Sugerowana wartość dla pid_max to 1024 * <# rdzeni/thr w systemie>
  kernel.pid_max: 65536
  net.ipv4.tcp_fastopen: 3
# Z solana systuner
# Odniesienie: https://medium.com/@CameronSparr/increase-os-udp-buffers-to-improve-performance-51d167bb1360
  net.core.rmem_max: 134217728
  net.core.rmem_default: 134217728
  net.core.wmem_max: 134217728
  net.core.wmem_default: 134217728

Przykłady playbooków

Węzeł mainnet:

    - hosts: rpc_nodes
      become: true
      become_method: sudo
      roles:
         - { role: rpcpool.solana-rpc, solana_network: mainnet }

Węzeł testnet:

    - hosts: rpc_nodes
      become: true
      become_method: sudo
      roles:
         - { role: rpcpool.solana-rpc, solana_network: testnet }

Węzeł devnet:

    - hosts: rpc_nodes
      become: true
      become_method: sudo
      roles:
         - { role: rpcpool.solana-rpc, solana_network: devnet }

Uruchamianie węzła RPC

Po wdrożeniu możesz zalogować się do maszyny i uruchomić su -l solana, aby stać się użytkownikiem solana.

Aby zobaczyć wygenerowaną dla Ciebie podczas wdrożenia linię poleceń walidatora Solana, możesz zajrzeć do /home/solana/bin/solana-rpc.sh. Pamiętaj, że wszelkie zmiany w tym pliku zostaną nadpisane przy następnym uruchomieniu Ansible.

Podczas pierwszego uruchomienia powinieneś zakomentować --no-genesis-fetch i --no-snapshot-fetch w pliku /home/solana/bin/solana-rpc.sh. Pozwoli to Solanie na pobranie podstawowych plików potrzebnych do pierwszego uruchomienia. Pamiętaj, aby ponownie aktywować te linie po uruchomieniu walidatora po raz pierwszy.

Następnie uruchom proces RPC Solana, wykonując systemctl --user start solana-rpc. Status procesu możesz sprawdzić, uruchamiając systemctl --user status solana-rpc. Pierwsze uruchomienie zajmie trochę czasu. Możesz monitorować uruchamianie, wykonując solana catchup --our-localhost.

Na koniec, aby zobaczyć logi dla swojego węzła RPC Solana, uruchom journalctl --user -u solana-rpc -f.

Jeśli to Twoje pierwsze uruchomienie węzła Solana, możesz znaleźć więcej szczegółów na temat tego, jak obsługiwać węzeł na https://docs.solana.com/running-validator/validator-start i https://github.com/agjell/sol-tutorials/.

Sprawdzanie węzła RPC

Podstawowa kontrola po sprawdzeniu, że węzeł wystartował, polega na śledzeniu catchup:

solana catchup --our-localhost

Po tym możesz kontynuować sprawdzanie, czy poprawnie obsługuje zapytania RPC.

Testowanie dostępu RPC

Możesz także spróbować kilku prostych poleceń walidacyjnych (dzięki buffalu: https://gist.github.com/buffalu/db6458d4f6a0b70ac303027b61a636af):

curl http://localhost:8899 -X POST -H "Content-Type: application/json" -d '
  {"jsonrpc":"2.0","id":1, "method":"getSlot", "params": [
      {
        "commitment": "processed"
      }
    ]}
'

curl http://localhost:8899  -X POST -H "Content-Type: application/json" -d '
  {"jsonrpc":"2.0","id":1, "method":"getSlot"}
'

Testowanie dostępu websocket

Najłatwiejszym sposobem na przetestowanie websocketów jest zainstalowanie narzędzia wscat. Aby to zrobić, musisz zainstalować NodeJS i NPM, a następnie uruchomić npm install wscat.

Następnie możesz połączyć się z własnym websocketem w następujący sposób:

wscat -c localhost:8900

Stamtąd otrzymasz wiersz poleceń, w którym możesz ręcznie wprowadzić swoje żądania subskrypcji websocket:

> {"jsonrpc":"2.0", "id":1, "method":"slotSubscribe"}

Teraz powinieneś zacząć otrzymywać regularne aktualizacje o slotach, gdy są potwierdzane przez twój węzeł RPC.

Węzeł RPC spóźnia się/nie dogania

Najczęstszym problemem wydajnościowym, z jakim może się zmagać węzeł RPC, jest to, że cały czas się spóźnia w stosunku do sieci i nie może nadążyć.

Jeśli nie potrafi nadążyć za pierwszym uruchomieniem, zazwyczaj jest to spowodowane błędną konfiguracją. Najczęstszy problem to częstotliwości boost CPU (więcej szczegółów na temat konfiguracji CPU patrz powyżej):

Sprawdź, czy twój CPU jest wystarczająco nowy (wszystko poniżej drugiej generacji EPYC na AMD lub Cascade Lake na Intel będzie miało trudności).
Sprawdź, czy twój governor CPU nie jest ustawiony na tryb oszczędzania energii w BIOS-ie i w ustawieniach jądra.
Obserwuj częstotliwości CPU podczas uruchamiania Solany za pomocą watch -n 1 grep MHz /proc/cpuinfo. Zazwyczaj potrzebujesz, aby było to > 3GHz na wszystkich rdzeniach (taka zasada). Nie chcesz widzieć, że jakiś rdzeń spada do 1.4-1.8 kiedykolwiek.

Jeśli wcześniej mógł nadążyć, ale teraz już nie (lub jeśli naprawa CPU nie pomogła):

Sprawdź pamięć/CPU/sieć - czy masz dobre częstotliwości CPU, czy nie korzystasz z swapu (brak wystarczającej pamięci), czy dostawca nie ścina UDP?
- CPU: Napraw ustawienie governor/boost, zdobądź nowszą generację CPU lub CPU z lepszym turbo dla wszystkich rdzeni (sprawdź wikichip w celu uzyskania szczegółów). Pamiętaj, że MHz nie są takie same w różnych generacjach. Broadwell 3.0 GHz nie jest tym samym co Cascade Lake 3.0 GHz lub EPYC 3. generacji 3.0 GHz.
- Sieć: Sprawdź ograniczenia pakietów UDP i łączność. Potrzebujesz co najmniej 500 Mbps bez jakichkolwiek ograniczeń na UDP. Niektórzy dostawcy chętnie blokują UDP lub ograniczają go dla ochrony przed atakami DDoS. To dotyczy zarówno przychodzących, jak i wychodzących. Jeśli masz ograniczenia na przychodzące, twój węzeł nie otrzyma sztyftów z sieci na czas. Sprawdź zapory, aby upewnić się, że nie jesteś ...
- Pamięć: Dodaj więcej RAM. Solana nie lubi działać na swapie, więc jeśli regularnie korzystasz ze swapu, musisz to naprawić. Tymczasowe rozwiązanie może polegać na wyłączeniu indeksów spl-token-owner / spl-token-mint. Stały się one naprawdę duże.
- Dysk: Sprawdź, czy twój dysk NVME do przechowywania księgi i/lub kont nie umarł lub nie umiera. Proste dmesg lub zapytanie statutu SMART powinno to potwierdzić.
Istnieje błąd, że po intensywnej próbie wywołania getBlocks przez RPC, węzeł pozostaje na zawsze spóźniony. Spróbuj ponownie uruchomić węzeł, a jeśli to pomoże, może to być twój problem.
Czy próbowałeś go odłączyć i znowu podłączyć? Czasami może pomóc wyczyścić księgę i zrestartować.
Sprawdź wzory swojego ruchu. Niektóre wzory ruchu RPC łatwo mogą wpędzić twój węzeł w opóźnienia. Może powinieneś dodać inny węzeł i podzielić się swoim ruchem RPC lub musisz ograniczyć swoje zapytania do problematycznych zapytań, jak getProgramAccounts.

Dostęp do danych historycznych

Domyślnie, gdy uruchamiasz węzeł RPC, zaczyna on budować swoją lokalną księgę z bloków, które odbiera przez sieć Solana. Ta lokalna księga zaczyna się od momentu zrzutu kont, który pobrałeś, gdy twój węzeł się uruchamiał. Jeśli nie dodasz --no-snapshot-fetch do swojej linii poleceń solana-validator, walidator często pobierze zrzut z sieci podczas uruchamiania. To stworzy luki lub dziury w twojej księdze między momentem, gdy zatrzymałeś swój węzeł RPC, a momentem, w którym pobrał zrzut kont. Aby tego uniknąć, zawsze określaj --no-snapshot-fetch po pierwszym uruchomieniu węzła. Pamiętaj, że za każdym razem, gdy pobierzesz zrzut, stworzysz lukę w lokalnej księdze.

Rozmiar lokalnej księgi określa parametr --limit-ledger-size, który mierzony jest w shredach. Shred to jednostka danych o stałej wielkości. Przekład pomiędzy shardami a blokami nie jest stały, ponieważ bloki mogą mieć różną wielkość. Dlatego bardzo trudno jest powiedzieć, jak dużo historii mierzonych w czasie lub liczbie bloków twój węzeł będzie przechowywał. Będziesz musiał dostosować to do swoich potrzeb. Dobrym punktem wyjścia może być 250-350 milionów shardów, co powinno pokrywać mniej więcej jedną epokę, co powinno oznaczać około 3 dni.

Dokładna ilość danych, którą węzeł RPC przechowa, zależy również od parametrów --enable-cpi-and-log-storage oraz --enable-rpc-transaction-history. Te są niezbędne, aby węzeł zachował i obsługiwał pełne dane bloków i transakcji.

Twój węzeł może dostarczać tylko te dane, które przechował w swojej lokalnej księdze. Oznacza to, że twoja historia zawsze zacznie się od momentu, w którym uruchomiłeś węzeł (w rzeczywistości: od slotu zrzutu, z którego uruchomiłeś węzeł). Jeśli sieć jest obecnie w slocie N, a ty pobrałeś zrzut w slocie M, to twój węzeł zacznie odbudowywać swoją historię między slotem M a slotem N. To, co dzieje się podczas catchup, węzeł przetwarza (odtwarza) wszystko, co wydarzyło się między M a N, aż nadgoni sieć i będzie mógł obsłużyć wszystkie bieżące przychodzące dane.

W teorii węzeł może przechowywać jak najwięcej historii, jaką można pomieścić na szybkim dysku (np. jeśli /nie/ określisz --limit-ledger-size lub podasz ogromną wartość). Jednak to nie rozszerza się wstecz do genesis. Aby uzyskać całą historię, można skorzystać z wbudowanego wsparcia dla Google BigTable. Możesz ustawić swój węzeł do przesyłania danych do instancji Google BigTable, gdzie będą one trwale dostępne do historycznego zapytania. Możesz również skonfigurować swój węzeł do obsługi zapytań do instancji BigTable. W takim przypadku, dla wszelkich zapytań, których węzeł nie ma w swojej lokalnej księdze, złoży żądanie do Google BigTable, a jeśli znajdzie to w Google BigTable, może pobrać te dane stamtąd.

Niektórzy dostawcy RPC i Fundacja Solana posiadają kopie BigTable, które sięgają do genesis. Więcej informacji na ten temat znajdziesz pod adresem https://github.com/solana-labs/solana-bigtable.

Indeksy i wydajność: lub, dlaczego mój RPC jest taki wolny?

Istnieją trzy indeksy, które generuje walidator Solana: program-id, spl-token-mint, spl-token-owner. Ostatnie dwa są używane do obsługi zapytań za pomocą getTokensByOwner, getTokenLargestAccounts lub za pomocą getTokensByDelegate. Są one również wykorzystywane do obsługi zapytań z getProgramAccounts, które stosują szczególne filtry.

Te indeksy zaczęły rosnąć do ogromnych rozmiarów. Jeśli nie potrzebujesz, aby te zapytania były szybkie dla swojego węzła RPC, powinieneś je usunąć, ponieważ znacznie zmniejszy to zużycie pamięci twojego węzła oraz poprawi czasy uruchamiania.

Jeśli naprawdę potrzebujesz tych wywołań RPC, musisz je aktywować za pomocą flagi indeksu konta, w przeciwnym razie te wywołania będą działać w nieakceptowalnie wolny sposób. Będzie to wymagać dużej ilości pamięci RAM - zazwyczaj nie zalecamy wdrażania tych funkcjonalności z mniej niż 512 GB dostępnej pamięci.

Alternatywą mogą być wtyczki Geyser, takie jak wtyczka Postgres, które mogą pomóc przyspieszyć zapytania, nie polegając na indeksach w pamięci: https://github.com/rpcpool/solana-geyser-park.

Obawy dotyczące bezpieczeństwa

Bezpieczeństwo to duża dziedzina i nie można polegać na małym przewodniku w repozytorium GitHub. Zazwyczaj przynajmniej powinieneś upewnić się, że twój serwer RPC nie wystawia portów 8899 i 8900 bez żadnego typu proxy i kontroli dostępu. Łatwym sposobem, aby to zrobić, jest użycie nginx lub HAproxy jako proxy zwrotnego. Możesz dodać wsparcie SSL i uwierzytelnianie w ten sposób za pomocą wbudowanych narzędzi z każdej z tych aplikacji.

Aby być bezpiecznym, możesz upewnić się, że twój rpc-bind-address jest ustawiony na 127.0.0.1 (domyślnie dla tej roli), tak aby odpowiadał tylko na lokalne żądania.

Inne playbooki

Zazwyczaj chcesz wdrożyć proxy zwrotne przed Solana RPC. HAproxy to świetna opcja, a my mamy playbook do konfigurowania HAproxy dla serwera solana rpc tutaj.

Inne przewodniki i dokumenty

Oto kilka innych przewodników, zasobów i dokumentów napisanych na temat Solana RPC:

Nie składamy żadnych zapewnień co do dokładności lub jakości któregokolwiek z tych dokumentów. Proszę przemyśleć i podjąć własną decyzję, które dokumenty należy śledzić!