Testnet

Anna chce nauczyć się odbierać i wysyłać bitcoiny, zanim użyje własnych pieniędzy. W aplikacji obsługującej Testnet zakłada osobny portfel testowy. Otrzymuje środki z faucetu, usługi rozdającej niewielkie ilości monet testowych, i wysyła część Pavlowi w tej samej sieci. Poznaje adres, transakcję i oczekiwanie na potwierdzenie bez wydawania prawdziwych BTC. To przykład, a nie instrukcja konkretnej aplikacji: nie każdy portfel oferuje taki tryb. Monety testowe nie są darmowymi bitcoinami. Ich salda nie można przełączyć ani przenieść do mainnetu, a niedostępny faucet nie jest powodem, by kupować je jako inwestycję. [11]

Testnet nie jest kontem ćwiczeniowym wewnątrz głównego Bitcoina. To inny łańcuch, rozpoczynający się własnym Genesis Block. Blok grupuje transakcje we wspólnej historii, a Genesis Block jest jej blokiem początkowym. Sieć ma też własne UTXO, czyli niewydane jeszcze wyjścia transakcji. Wyjście określa kwotę i warunki jej wydania, na przykład wymagany podpis. Otrzymanie środków przez Annę w jednej sieci nie tworzy salda w drugiej. Programy rozróżniają sieci na podstawie parametrów, takich jak identyfikatory początku komunikatów i porty. Inna sieć nie musi jednak mieć adresów wyglądających inaczej. Klucz prywatny to tajne dane, z których portfel tworzy podpis upoważniający do wydania odpowiednich środków. Nawet identyczne klucze prywatne nie połączą obu historii w jeden portfel ze wspólnym saldem. [12] [15]

Adresy zaczynające się od tb1 mogą należeć do Testnet3, Testnet4 lub Signetu. Anna i Pavel uzgadniają więc konkretną sieć i sprawdzają ją w obu aplikacjach; samo „testowa” nie wystarcza. Anna używa nowych kluczy i osobnej kopii zapasowej. Nie wpisuje Seed Phrase (słów odzyskiwania) portfela z prawdziwymi środkami do aplikacji eksperymentalnej. Zmiana trybu nie czyni niezaufanego programu bezpiecznym. Faucet potrzebuje najwyżej publicznego adresu odbiorczego, nigdy słów odzyskiwania ani klucza prywatnego. Oddzielne pliki portfela, klucze i kopie ograniczają pomyłki oraz niechciane powiązania testów z osobistymi płatnościami. [12] [14]

Publiczny Testnet służy eksperymentom z nieznanymi uczestnikami i otwartym wydobyciem. Signet również jest środowiskiem testowym, ale poza Proof of Work (pracą obliczeniową potrzebną do znalezienia poprawnego bloku) wymaga spełnienia warunku bloku, zwykle podpisu utworzonego za pomocą uprawnionych kluczy. Pozwala to lepiej koordynować tworzenie bloków, choć nie gwarantuje ciągłego działania. Regtest przydaje się programiście, który potrzebuje kontroli: uruchamia własne środowisko i tworzy bloki na żądanie, na przykład w teście automatycznym. Jeśli Anna poznaje tylko obsługę portfela, znaczenie ma również to, jakie sieci wspiera aplikacja. Żadna z tych sieci nie zamienia swoich monet na bitcoiny sieci głównej. [10] [11] [16]

Próbna płatność Pavla może przejść szybko i za niewielką opłatą. Nie wynika z tego koszt tej samej operacji w mainnecie. Różnią się ruch, moc wydobywcza i motywacje uczestników. Publiczny Testnet może długo czekać na blok, doświadczyć awarii usługi albo reorganizacji: węzły, czyli komputery sprawdzające reguły sieci, zastępują wtedy niedawną gałąź historii inną poprawną gałęzią. Takie sytuacje pomagają wykrywać błędy aplikacji, ale nie każda awaria jest zamierzona. Udany test sprawdził określone zachowanie w określonych warunkach; sam nie dowodzi bezpiecznego przechowywania kluczy ani odporności usługi operującej prawdziwymi pieniędzmi. [10] [2]

W starszych instrukcjach pojawia się Testnet3, uruchomiony w 2011 roku. Z czasem ujawniły się problemy z dystrybucją monet i regułami trudności wydobycia. Tak zwane block storms były seriami bardzo szybko wydobywanych bloków: wysokość łańcucha rosła niezwykle szybko, a subsydium nowych bloków malało szybciej, niż sugerował kalendarz. Zaczęto też handlować monetami testowymi, choć miały być łatwo dostępnym narzędziem. Nowa generacja rozpoczyna zatem nową historię, a nie zmienia wyceny dawnych sald. Czytając instrukcję, sprawdź numer sieci, nie tylko nazwę Testnet. [1]

Testnet4 opisuje propozycja techniczna BIP 94, a jego obsługę wprowadził Bitcoin Core 28.0. Oprócz nowego Genesis Block zmieniono obliczanie trudności i reguły znaczników czasu, aby ograniczyć znane sposoby wywoływania block storms. Pozostawiono jednak wyjątek: poza pierwszym blokiem okresu trudności znacznik czasu późniejszy o ponad 20 minut od poprzedniego bloku wymaga minimalnej trudności. To nie obietnica potwierdzenia płatności w ciągu 20 minut. Testnet4 stosuje też od początku zmiany reguł aktywne w mainnecie w chwili przedstawienia propozycji w maju 2024 roku. Te ulepszenia nie czynią go bezawaryjnym modelem głównej sieci. [1] [9]

Na 17 października 2026 roku BIP 95 dotyczący Testnet5 ma status Draft, czyli projekt w opracowaniu. Proponuje usunięcie wyjątku minimalnej trudności, podniesienie jej minimum oraz stosowanie od pierwszego bloku BIP 54, zestawu proponowanych zmian reguł konsensusu. Dokument nadal nie zawiera ostatecznych danych Genesis Block ani odnośnika do implementacji referencyjnej. Nie pozwala więc przedstawiać Testnet5 jako standardowo wdrożonej sieci Bitcoin Core. Testowanie nowych zasad nie aktywuje ich też w mainnecie. Przy późniejszej lekturze liczą się status propozycji i dokumentacja używanej wersji, a nie wyższy numer w nazwie. [2]

W Bitcoin Core opcja testnet4 wybiera Testnet4; dokładną składnię polecenia podaje dokumentacja danej wersji. W konfiguracji sekcja [test] oznacza Testnet3, a [testnet4] — Testnet4. Dane trafiają do osobnych podkatalogów testnet3, testnet4, signet lub regtest. Ważne jest też sprawdzenie działającego programu: getblockchaininfo zwraca identyfikator sieci w polu chain. Zweryfikuj również hash Genesis Block, synchronizację i połączone węzły. Własny Signet wymaga także sprawdzenia jego warunku bloku, bo wspólny genesis nie wystarcza. Tytuł okna ani podobny adres nie zastępują tych kontroli. [8] [12] [13] [14] [10]

Anna najpierw sprawdza, czy oba portfele używają tej samej sieci. Potem próbuje odbioru i wysyłki oraz rozróżnia płatność wysłaną od potwierdzonej. Odtwarzanie ćwiczy wyłącznie z osobnej kopii testowej. Programista może dodać restart aplikacji, niedostępny węzeł, reorganizację albo odrzucenie niewłaściwej sieci. Przy opłatach przydają się RBF, zastąpienie niepotwierdzonej transakcji nową, oraz CPFP: lepiej opłacona transakcja potomna zachęca górników do uwzględnienia także niepotwierdzonej poprzedniczki. Wynik powinien zawierać sieć, wersję programu i faktycznie sprawdzone zachowanie. Testnet pozwala popełniać błędy, których chcemy uniknąć z prawdziwymi pieniędzmi; nie dowodzi, że dalsze kontrole są zbędne. [11] [9]