Wersja 2.2.1 jest teraz dostępna do pobrania!
W skrócie:
Ta aktualizacja naprawia problemy zgłoszone w wersji 2.2.0 oraz wprowadza usprawnienia i ulepszenia dotyczące Farmingu, Portfela, Poprawek Sieciowych oraz Narzędzi dla Deweloperów.
Naprawiono
- Naprawiono problem z odnajdywaniem ploterów bladebit i madmax w interfejsie wiersza poleceń i interfejsie graficznym (dzięki @nanofarmer).
- Naprawiono problem z banowaniem peerów z powodu błędnych logów związanych z błędnymi haszami INVALID_TRANSACTIONS_FILTER_HASH oraz INVALID_BLOCK_COST (#17620).
Zmiany w wersji Chia 2.2.1 / 2.2.0
Ulepszenia Farmingu i Portfela
Rozszerzony protokół harwestera
Proces plotowania na platformie Chia stał się znacznie bardziej efektywny od wczesnych dni sieci, kiedy ChiaPoS był jedyną dostępną opcją. Obecnie istnieje wiele konkurencyjnych ploterów, tworząc zdrowy ekosystem. Farming na Chia również znacznie się poprawił dzięki wdrożeniu zdecentralizowanego grupowania.
Niemniej jednak niektóre plotery zrezygnowały z oficjalnego protokołu grupowania na rzecz zamkniętego modelu, który wykorzystuje plotery, farmerów i harwestery o kodzie źródłowym dostępnym tylko dla wybranych. To doprowadziło do zwiększonej centralizacji przestrzeni sieciowej.
Po spotkaniu z wieloma twórcami oprogramowania do plotowania i farmingu o zamkniętym kodzie źródłowym dowiedzieliśmy się, że ich główną motywacją do przyjęcia tej architektury było ułatwienie korzystania - chcieli prostego sposobu na pobieranie opłat od deweloperów bez konieczności dokonywania dużych zmian w kodzie źródłowym Chia.
Z tej wiedzy korzystając, rozpoczęliśmy prace nad ulepszeniem protokołu harwestera Chia, zgodnie z CHIP-22. Ta aktualizacja pozwala zamkniętym harvesterom na współpracę z referencyjnym farmerem. Zamknięte puly mogą teraz pobierać opłaty od deweloperów za swoją pracę, nie naruszając przy tym zdecentralizowania Chia. To powinno być dużym sukcesem dla farmerów, pul i ogólnego ekosystemu Chia.
Zwiększone wykorzystanie bloku
Od momentu uruchomienia głównego łańcucha Chia trzy lata temu, wykorzystanie bloków było ograniczone do 50%. Głównym powodem tego było zapewnienie, że niskonapięciowe węzły, takie jak Raspberry Pi, mogą nadążyć za siecią.
Wprowadziliśmy szereg optymalizacji, które miały ułatwić tym systemom utrzymanie synchronizacji. Dzisiaj jesteśmy pewni, że możemy zacząć zwiększać wykorzystanie bloku bez utraty wielu (lub nawet żadnego) węzła. Pierwszy krok w tym kierunku następuje w tej wersji, gdzie zwiększymy wykorzystanie bloku do 60%.
Planujemy stopniowo zwiększać to wykorzystanie, aż osiągniemy narzucony konsensusem limit 100%. Wraz ze wzrostem wskaźnika wypełnienia bloku wzrośnie ilość transakcji na sekundę w sieci (TPS), a także średnie opłaty, gdy mempool zawiera wystarczającą liczbę transakcji do wypełnienia bloku. Gdy wskaźnik wypełnienia osiągnie 100%, maksymalny TPS sieci osiągnie około 40.
Udoskonalona logika mempoolu
Zgodnie z naszym niedawnym wpisem na oficjalnym blogu Chia, każdy węzeł ma możliwość wyboru dowolnych transakcji przy tworzeniu bloku. Niemniej jednak większość węzłów korzysta z domyślnej logiki mempoolu, która ma na celu maksymalizację opłat blockchainowych przekazywanych farmerowi.
Teraz, gdy blockchain doświadcza trwałej presji opłatowej, zidentyfikowaliśmy kilka przypadków brzegowych, w których można by poprawić logikę wyboru transakcji. Na przykład w rzadkim
przypadku re-orga, jeśli ostatni blok nie był blokiem transakcyjnym, mempool nie był aktualizowany do czasu następnego bloku transakcyjnego. Począwszy od wersji 2.2.1, pełen węzeł będzie natychmiast aktualizować mempool po wystąpieniu re-orga.
Poprawiliśmy również domyślny algorytm wypełniania bloku. Wcześniej węzeł wypełniał nowy blok wielokrotnie wybierając transakcję o najwyższym priorytecie z mempoolu. Kiedy kolejna transakcja miała zapełnić blok, węzeł uznawał blok za zakończony i przesyłał go do sieci.
Było to nieefektywne w niektórych przypadkach. Na przykład, jeśli blok był wypełniony na mniej niż połowę, a następna transakcja w kolejce była wystarczająco duża, aby przekroczyć pojemność bloku, węzeł przestawał szukać kolejnych transakcji. Powstały blok byłby wypełniony znacznie poniżej pojemności, chociaż mógł pomieścić wiele mniejszych transakcji.
To trudny problem do rozwiązania - jeśli algorytm wypełniania bloku jest zbyt prosty, wiele bloków będzie niewystarczająco wypełnionych. Jednak jeśli algorytm jest zbyt skomplikowany, węzeł może zbyt długo zastanawiać się, które transakcje uwzględnić. Skutkowałoby to pustym blokiem lub, co gorsza, nawet nie dodaniem go do łańcucha.
Nowy algorytm wypełniania bloku stara się znaleźć równowagę, efektywnie wypełniając bloki, jednocześnie starając się nie zatrzymywać zbyt długo przy wyborze transakcji.
Udoskonalona synchronizacja portfela
Portfele korzystające z protokołu portfela mogą teraz efektywnie synchronizować stan swoich monet partiami, zamiast pobierać cały stan w jednej odpowiedzi.
Ulepszenia Sieci
Ochrona przed ponownym układaniem z nadmiernymi wydaniami
Usprawniliśmy komunikację pełnego węzła, która jest rozprzestrzeniana w sieci, co powinno skutkować mniejszą liczbą reorganizacji.
Farmerzy nigdy nie powinni przechowywać wielu kopii tego samego wydania, nawet korzystając z wielu pełnych węzłów (co również nie jest zalecane). Gdy w takim przypadku zostanie znalezione wygrywające dowody, każdy węzeł przedstawiający dowód przekazuje blok do sieci, ale timelordowie infuzują tylko jeden z nich. W rzeczywistości nadmiarowe miejsce tworzy koszt szansy, który skutkuje niższymi nagrodami: miejsce zajęte przez nadmiarowy wydanie mogło zostać wypełnione unikalnym wydaniem, co skutkowałoby wyższymi nagrodami.
Mimo tego wytycznego czasami farmerzy kopiują swoje wydania do nadmiarowych pełnych węzłów. W tym scenariuszu każdy węzeł przechowuje unikalną kopię mempoolu. Z powodu tego, gdy nadmiarowi farmerzy tworzą blok transakcyjny z tego samego dowodu, wynikające bloki mogą być różne. Ze względu na to, jak zachodzi propagacja bloku, każdy timelord może zobaczyć tylko jeden z bloków. Jeśli różni timelordowie infuzują różne bloki tymi samymi dowodami, tymczasowo utworzą konkurujące ze sobą blockchainy.
Ta sytuacja nie stwarza zagrożenia dla bezpieczeństwa sieci. W rzeczywistości jest to zwykle rozwiązane jeden blok później w reorganizacji. Jednak reorganizacje są niewygodne dla farmerów, którzy muszą ponownie walidować ostatnie kilka bloków. Lepszym rozwiązaniem byłoby unikanie reorganizacji.
Począwszy od wersji 2.2.1 węzły będą rozprzestrzeniać każde wystąpienie niezakończonych bloków w całej sieci. Timelordowie zobaczą obie kopie bloków, pozwalając im deterministycznie wybrać, który z nich infuzować. Ponieważ tylko jedna kopia zostanie początkowo dodana do blockchaina, reorganizacja nie wystąpi.
*Zauważ, że ta aktualizacja dotyczy tylko jednego rodzaju reorganizacji; inne rodzaje są wciąż możliwe, a nawet normalne.
Szybki przewijanie pojedynczego wydatku
To rodzaj agregacji wydatków pojedynczych, który będzie używany tylko wtedy, gdy wydatek będzie zawierał pewne właściwości, na przykład gdy hasz łamigłówki singletona nie będzie zmieniany przez wydatek. Szybkie przewijanie będzie więc najbardziej przydatne przy wydatkach orakularnych. Zostało to dodane w dwóch częściach:
chia_rs PR #267
chia-blockchain PR #16919
Narzędzia dla Deweloperów
Testnet11
Jesteśmy zobowiązani do utrzymania publicznej sieci, w której deweloperzy mogą testować nowe funkcje. Przez ostatnie dwa lata był to testnet10. Chcemy, aby proces synchronizacji węzła testnet pozostał szybki i łatwy. Jednak baza danych testnet10 z czasem znacznie urosła. Z tego powodu kilka miesięcy temu uruchomiliśmy testnet11 jako ewentualną sieć zastępczą.
Nadszedł czas na zakończenie testnet10. Począwszy od wersji 2.2.1, testnet11 będzie domyślną siecią stosowaną podczas uruchamiania "chia configure --testnet true". Zachęcamy wszystkich deweloperów do korzystania z testnet11, jeśli jeszcze tego nie robią.
Będziemy nadal uruchamiać timelordów dla testnet10 przez miesiąc po wydaniu 2.2.1. Następnie nie będziemy już obsługiwać starej sieci. Oczywiście, ponieważ testnet10 to publiczny blockchain, każdy może uruchomić timelorda i farmera, aby utrzymać sieć przy życiu, jeśli zachodzi taka potrzeba.
Aby uzyskać więcej informacji na temat uruchamiania węzła testnet, zapoznaj się z naszą dokumentacją.
Stałe połączenia z peerami
Możesz teraz łączyć się z zawsze tym samym zestawem peerów za każdym razem, gdy uruchamiasz swój węzeł. Może to być przydatne w różnych sytuacjach, na przykład podczas łączenia z prywatnym testnetem, gdzie znane są wszystkie peery. Zobacz naszą dokumentację, aby uzyskać więcej informacji. Specjalne podziękowania dla Felixa Bruckera za stworzenie tej funkcji!
Udoskonalone logowanie
Poprawiliśmy nasze logowanie w kilku obszarach, w tym podczas organizowania mempoolu i podczas ostrzeżeń dotyczących walidacji. Nowe logowanie powinno pomóc deweloperom w wysiłkach związanych z debugowaniem.
Profilowanie walidacji bloku
Dodaliśmy nowy profiler specjalnie do walidacji bloku. Wcześniej dostępny był tylko profiler dla całego zadania pełnego węzła. Nowy profiler będzie pomocny przy debugowaniu w przypadkach, gdy walidacja bloku trwa dłużej niż dwie sekundy.
Pełne dodatkowe dane dotyczące aggsig
Pełny węzeł RPC umożliwia teraz żądanie dodatkowych danych wymaganych do warunku aggsig_me. Ułatwia to deweloperom tworzenie podpisów, które działają na testnetach, symulatorach, głównym łańcuchu i nawet innych odgałęzień Chia.
Udoskonalenia w odpowiedzi get_offer_summary
Podczas korzystania z portfela RPC get_offer_summary, "additions" i "removals" zostaną teraz uwzględnione w odpowiedzi. Pomoże to portfelom określić, czy oferta jest anulowana czy zaakceptowana, umożliwiając porównanie wyników RPC do identyfikatorów monet dla dodatków i usunięć. Specjalne podziękowania dla Mike'a White'a za stworzenie tej funkcji!
Weryfikacja podpisów wygenerowanych za pomocą kart Tangem
Portfel RPC verify_signature teraz ma zdolność do weryfikacji podpisu wygenerowanego za pomocą karty Tangem. Wcześniej nie było to możliwe, ponieważ Tangem używał innej łamigłówki do podpisywania niż ta używana przez referencyjny portfel. Specjalne podziękowania dla Marina Quevedo za stworzenie tej funkcji!
Źródło: Oficjalna strona CHIA, opracowanie własne i pomoc AI.
