Bot NFT w Pythonie: oprzyj projekt na danych i uprawnieniach

Wyznacz botowi NFT w Pythonie jasne granice komponentów

Rozdziel pracę na adapter obserwacji, magazyn znormalizowanych zapisów, komponent oceny polityki, koordynator realizacji i ograniczony interfejs podpisywania. Mogą zaczynać jako moduły jednego projektu; nie muszą stawać się pięcioma osobnymi usługami. Wartość wynika z odpowiednio jasnych obowiązków, pozwalających niezależnie je testować i analizować.

Adapter obserwacji rozumie strukturę odpowiedzi i błędy zewnętrznego API. Nie powinien decydować o wartości zakupu tokena. Komponent oceny polityki rozumie kryteria kolekcji i limity wydatków. Nie powinien niejawnie pobierać innej ceny, gdy podana obserwacja nie spełnia reguł. Koordynator realizacji zarządza autoryzowanymi działaniami i ich nierozstrzygniętymi stanami, a komponent podpisujący sprawdza dokładnie żądane uprawnienia.

Każda granica potrzebuje określonych danych wejściowych i wyjściowych. Zapis oferty sprzedaży może zawierać tożsamość aktywa i zlecenia, jednostki ceny, tożsamość tokena płatności, czas obserwacji i stan weryfikacji. Decyzja dodaje wersję polityki, powód i maksymalny autoryzowany wydatek. Żądanie transakcji odwołuje się do decyzji, zachowując łańcuch dowodów od danych do działania.

Zapisy ujawniają niezgodność. Jeśli adapter obserwacji podaje cenę tokena w jednej walucie, a polityka oczekuje innej, dane powinny nie przejść walidacji. Automatyczne podstawienie znajomego symbolu waluty ukrywałoby właśnie fakt wymagający zbadania. Mały jawny błąd jest lepszy niż duże niejawne założenie.

Traktuj tożsamość jako dane strukturalne

Wyświetlana nazwa NFT pomaga osobie, lecz jest słabym kluczem bazy danych. Dla zwykłego aktywa EVM zapisz sieć, adres kontraktu, identyfikator tokena i standard. Uwzględnij ilość tam, gdzie właściwe. Ten sam identyfikator innego kontraktu oznacza inne aktywo, a tak samo wyglądający adres kontraktu w innej sieci należy do innego kontekstu sieciowego.

Tożsamość zlecenia jest osobna od tożsamości aktywa. Token można wystawiać wiele razy, a sprzedawca zastępować jedno zlecenie drugim. Deduplikacja tylko według identyfikatora tokena może odrzucić rzeczywistą zmianę ceny lub pomylić wygasłe zlecenie z zamiennikiem. Zachowuj protokół i identyfikator zlecenia obok zapisu przedmiotu.

Używaj ciągów znaków lub odpowiednio dużych liczb całkowitych dla identyfikatorów bez założenia, że każdy dalszy system bezpiecznie reprezentuje je jako zwykłe liczby zmiennoprzecinkowe. Duży liczbowy identyfikator tokena może zachować się w liczbach całkowitych Pythona, a potem stracić precyzję w innym komponencie traktującym go jako binarną liczbę zmiennoprzecinkową. Serializacja jest częścią architektury, a nie tylko prezentacją.

Wskazówki OpenSea dotyczące przeglądu strony przedmiotu dają przydatny kontekst tożsamości dla kontroli przez człowieka. Program powinien zachowywać bazowe identyfikatory pozwalające odróżnić autentyczne aktywo kolekcji od niepowiązanego przedmiotu z podobną grafiką lub nazwą.

Obsługuj kwoty tokenów jako liczby całkowite na granicy systemu

Kwoty tokenów wymagają liczby i jednostki. Surowa kwota miliona oznacza coś innego dla tokena z sześcioma miejscami dziesiętnymi niż z osiemnastoma. Przechowuj razem surową liczbę całkowitą, tożsamość tokena i zweryfikowaną konwencję miejsc dziesiętnych. Liczba bez jednostki nie powinna trafiać do decyzji o wydatku.

Dla hipotetycznego tokena płatności o sześciu miejscach dziesiętnych 12,345678 jednostki odpowiada 12 345 678 jednostkom bazowym. Trzy przedmioty po 4,125000 jednostki dają łącznie 12,375000 jednostki, czyli 12 375 000 jednostek bazowych. Limit polityki 12,300000 jednostki jest więc za mały o 75 000 jednostek bazowych, równoważnych 0,075000 jednostki. Porównanie powinno być dokładne, nawet jeśli interfejs zaokrągla obie liczby.

Liczby całkowite Pythona nadają się do dokładnych kwot jednostek bazowych. Arytmetyka dziesiętna może pomagać przy cenach wpisywanych przez człowieka, ilorazach i raportach, jeśli dane są właściwie parsowane, a reguły precyzji i zaokrąglania jawne. Utworzenie wartości dziesiętnej z już przybliżonej binarnej liczby zmiennoprzecinkowej nie odzyskuje pierwotnie zamierzonej danej dziesiętnej. Preferuj oryginalny ciąg liczbowy, gdy taką reprezentację ma źródło.

Nie zaokrąglaj niejawnie kwoty użytkownika ze zbyt wieloma miejscami dziesiętnymi do wykonalnej ilości. Zdecyduj przed autoryzacją o odrzuceniu lub jasno udokumentowanej regule zaokrąglenia. Zaokrąglenie maksymalnej ceny w górę może przekroczyć limit, a kwoty potrzebnej do rozliczenia w dół może spowodować błąd transakcji. Poprawne zachowanie zależy od roli kwoty.

Zachowuj cenę, opłaty i gaz w ich własnych jednostkach

Zakup może używać tokena płatności ERC-20 i natywnego ETH na gaz. To osobne salda i osobne kontrole autoryzacji. Łączna wartość raportowa pomaga dopiero po wskazaniu założeń przeliczenia. Program nie powinien bezpośrednio dodawać 0,02 ETH gazu do 100 jednostek innego tokena i nazywać wyniku 100,02 jednostki.

Rozważ transakcję Ethereum z limitem gazu 150 000 i maksymalną ceną gazu 40 gwei. Maksymalny przydział gazu wynosi 0,006 ETH. Jeśli transakcja faktycznie zużywa 110 000 gazu po efektywnej cenie 25 gwei, obciążenie wykonania wynosi 0,00275 ETH. Liczby ilustrują różnicę przydziału rezerwowanego przed wysłaniem i kosztu uzgadnianego później.

Dokumentacja gazu Ethereum wyjaśnia jednostki bazowe. Implementacja powinna też uwzględniać rzeczywisty rodzaj i ścieżkę transakcji zamiast zakładać jeden wzór dla każdej sieci lub dodatkowej opłaty. Potwierdzenie transakcji i wykonane przepływy płatności ustalają rzeczywiste wydatki; szacunek nie jest końcowym zapisem księgowym.

Używaj jawnych nazw, takich jak kwota płatności, maksymalny przydział sieciowy i rzeczywisty koszt sieci. Niejasne pola „opłata” lub „suma” zachęcają do podwójnego liczenia, gdy jedna odpowiedź API już obejmuje składnik dodawany ponownie w innym raporcie. Koordynator transakcji powinien wyjaśniać pochodzenie i jednostkę każdej rezerwowanej kwoty.

Normalizuj dane zewnętrzne bez wymyślania brakujących faktów

Adapter API powinien odróżniać nieobecne pole od pola o prawidłowej wartości zero. Brak ceny nie oznacza darmowej oferty. Niedostępne pole właściciela nie oznacza, że nikt nie posiada tokena. Pusta odpowiedź może oznaczać brak pasujących zapisów, lecz błąd uwierzytelnienia lub przekroczenie czasu żądania nie ustala braku ofert w kolekcji.

Weryfikuj oczekiwane struktury i odrzucaj nieoczekiwane z użytecznym powodem. Zachowuj dość pierwotnej publicznej odpowiedzi lub bezpieczne odniesienie do niej, aby diagnozować zmiany schematu. Unikaj rejestrowania nagłówków uwierzytelniania lub tajnej konfiguracji, zachowując zwykłe identyfikatory i czasy. Diagnoza nie powinna wymagać ujawnienia uprawnień użytych do dostępu do usługi.

Stronicowanie wymaga podobnej uwagi. Stosuj udokumentowany mechanizm kontynuacji i zachowuj postęp przy dużych kolekcjach. Nie zakładaj reprezentowania wszystkich obecnych zasobów przez pierwszą stronę. Jeśli zapisy mogą zmieniać się podczas czytania stron, traktuj wynik jako obserwacje w przedziale czasu i uzgadniaj duplikaty lub zmiany zamiast twierdzić bez dowodów, że to natychmiastowa migawka.

Warstwa opakowująca API powinna raportować to, co wie. Przekroczenie czasu transportu jest przekroczeniem czasu transportu, a nie anulowaniem sprzedawcy. Wadliwa odpowiedź jest błędem parsera, a nie ujemnym sygnałem handlu. Precyzyjne kategorie błędów zapobiegają działaniu polityki na podstawie historii, której dane faktycznie nigdy nie opowiedziały.

Obsługuj zdarzenia jako obserwacje, a nie polecenia

Zdarzenie oferty sprzedaży powinno uruchamiać ocenę, a nie natychmiastowy zakup tylko przez nadejście. Może być zduplikowane, opóźnione lub zastąpione innym zdarzeniem. Proces roboczy powinien normalizować tożsamość, zapisywać czas, porównywać z istniejącym stanem i ustalać potrzebę świeżej weryfikacji przed żądaniem uprawnień do wydatku.

Dokumentacja Stream API OpenSea opisuje dostarczanie bez gwarancji kompletności i możliwe zdarzenia poza kolejnością. Ponowne połączenie wymaga więc ścieżki uzgadniania potrafiącej odkryć zmiany pominięte podczas luki. Dokładny projekt odzyskiwania zależy od zapisów potrzebnych strategii, lecz nie powinien zakładać kompletnego, trwałego rejestru w strumieniu zdarzeń.

Oddzielaj tłumienie duplikatów od aktualności. Dwie kopie tego samego zdarzenia nie powinny powodować dwóch działań. Dwie różne obserwacje tego samego tokena mogą obie mieć znaczenie, bo jedna zmienia stan zlecenia. Zbyt szeroki klucz deduplikacji może szkodzić tak jak brak deduplikacji, jeśli tłumi prawidłowe aktualizacje.

Prosta próba może dostarczyć tę samą obserwację dwukrotnie, potem anulowanie o wcześniejszej kolejności nadejścia, lecz istotnym znaczniku czasu zdarzenia. Oczekiwany wynik to jeden zapis kandydata z prześledzalną historią stanu, a nie dwa zakupy lub ślepe zaufanie ostatnio przybyłej wiadomości. Zdefiniuj oczekiwania przed podłączeniem programu do rzeczywistych uprawnień.

Koordynuj jednoczesne decyzje wspólnymi limitami

Programy Pythona często używają zadań asynchronicznych do obsługi kilku żądań sieciowych bez sekwencyjnego czekania na każde. Może to poprawić responsywność, lecz wprowadza pytania o wspólny stan. Dwie oceny kandydatów mogą widzieć ten sam dostępny budżet przed zapisaniem którejkolwiek rezerwacji. Szybsze przetwarzanie nie zmniejsza konsekwencji wyścigu.

Załóż kampanię z 600 dostępnymi jednostkami tokena płatności i dwoma procesami roboczymi proponującymi zakup po 400. Każda propozycja mieści się osobno, lecz razem wymagają 800 jednostek. Koordynator musi autoryzować najwyżej jedną w tym budżecie. Druga powinna widzieć pozostałe 200 i zostać odrzucona lub czekać według polityki.

Asynchroniczna blokada wewnątrz procesu może koordynować współpracujące zadania jednego procesu. Nie koordynuje automatycznie osobnych procesów, innych komputerów lub ręcznego zakupu z tego samego portfela. Przy szerzej rozdzielonych uprawnieniach potrzebny jest trwały wspólny rejestr i odpowiednia aktualizacja transakcyjna. Podaj granicę rzeczywiście chronioną przez wybrany mechanizm synchronizacji.

Ograniczaj też liczbę nierozstrzygniętych żądań. Nieograniczona współbieżność może tworzyć rosnącą kolejkę nieaktualnych kandydatów, przeciążać zewnętrzne usługi i utrudniać śledzenie odzyskiwania. Przestrzegaj udokumentowanych limitów i stosuj świadome wydłużanie odstępów po błędach nadających się do ponowienia. Celem są aktualne, wyjaśnialne decyzje, a nie największa liczba jednoczesnych żądań.

Zachowaj zamiar przed żądaniem podpisu

Przed żądaniem podpisu zapisz trwały zamiar z zatwierdzonym aktywem, ścieżką, walutą, maksymalnymi kwotami, odbiorcą, wersją polityki i właściwym wygaśnięciem. Nadaj mu identyfikator używany w całym procesie. Komponent podpisujący powinien otrzymać dość danych strukturalnych do weryfikacji żądania względem zapisu zamiast niewyjaśnionego bloku danych z uspokajającą etykietą.

Dane uwierzytelniające API i uprawnienia podpisywania portfela są różnymi sekretami o różnych możliwościach. Usługa danych może potrzebować klucza do odczytu dozwolonych zapisów bez powodu dostępu do sekretu portfela. Rozdzielenie ogranicza liczbę komponentów mogących autoryzować transakcje i ułatwia ograniczenie skutków przypadkowego ujawnienia sekretu.

Interfejs podpisywania powinien odrzucać inną sieć, odbiorcę, kontrakt lub kwotę nawet przy twierdzeniu wywołującego, że żądanie należy do zatwierdzonego zakupu. Zgoda dotyczy konkretnego działania w limitach, a nie dowolnych bajtów procesu roboczego. Przy istotnej zmianie ścieżki uzyskaj nową decyzję polityki zamiast naciągać starą.

Przed zapożyczeniem kodu tej warstwy zastosuj podejście z oceny bota NFT z GitHuba. Znajoma nazwa repozytorium lub działający pokaz nie ujawniają miejsc wysyłania danych przez zależności ani zakresu uprawnień żądanych przez konstruktor transakcji.

Zaprojektuj jawnie odzyskiwanie transakcji NFT w Pythonie

Niebezpieczny moment często występuje między wysłaniem i lokalnym potwierdzeniem. Usługa sieciowa może przyjąć transakcję, gdy wywołujący przekroczy czas przed zapisaniem zwróconego wyniku. Ogólne ponowienie może utworzyć dodatkowe działanie przy nadal oczekującym pierwotnym. Odzyskiwanie musi najpierw zbadać pierwotny zamiar i identyfikatory transakcji.

Używaj stanów zachowujących niepewność: przykładowo przygotowane, zatwierdzone, wysłane, oczekujące, potwierdzone, nieudane i nierozstrzygnięte. Dokładne nazwy są mniej ważne niż wymagane dowody. Udana odpowiedź HTTP nie jest potwierdzoną własnością, a brak odpowiedzi nie jest dowodem niepowodzenia transakcji.

Po restarcie uzgadniaj niedokończone zamiary przed nowymi kandydatami. Zachowuj rezerwacje budżetu do wyniku uzasadniającego zmianę. Po potwierdzeniu własności zapisz rzeczywistą ilość aktywa i koszt. Po ustaleniu niepowodzenia uwzględnij wydatki sieci przed zwolnieniem reszty. Jeśli wyniku nie da się jeszcze ustalić, zachowaj nierozstrzygnięty stan i pokaż go operatorowi.

Mintowanie wymaga dodatkowych rozróżnień, bo aktywo może nie istnieć przed transakcją. Proces automatycznego mintowania NFT powinien łączyć autoryzowaną ilość mintu z identyfikatorami rzeczywiście utworzonymi i otrzymanymi. Nie powinien wymyślać oczekiwanych identyfikatorów tokenów tylko dlatego, że kontrakt często wydaje się nadawać je kolejno.

Testuj decyzje na zapisanych przypadkach

Zbuduj mały zbiór publicznych przykładów pozbawionych wrażliwych danych i oczekiwanych decyzji. Uwzględnij prawidłową ofertę, przedmiot z niewłaściwej sieci, brak ceny, żądanie ponad budżetem, zduplikowane zdarzenie i nieznany wynik transakcji. Przypadki testują znaczące zachowania na granicach, gdzie błędy mogą zmieniać wydatki lub zasoby.

Testuj przeliczenia całkowitoliczbowe na wartościach tuż poniżej limitu, dokładnie na nim i tuż ponad nim. Uwzględnij tokeny o różnych konwencjach miejsc dziesiętnych. Test powtarzający obliczenie implementacji bez niezależnego oczekiwanego wyniku może przejść mimo niezrozumienia jednostki przez oba. Sprawdź ręcznie kilka przypadków i zachowaj uzasadnienie.

Dla mintu uwzględnij niekwalifikujące się portfele i wyczerpane przydziały jako normalne wyniki negatywne. Automatyzacja powinna przestrzegać opublikowanych warunków zamiast traktować odrzucenie jako wyzwanie do obejścia. Omówienie polityki kwalifikacji na listę NFT dla zysku pomaga oddzielać kwalifikację od niezwiązanego pytania o atrakcyjną ekonomikę dozwolonego mintu.

Na końcu przećwicz przerwanie procesu i odzyskiwanie. Zatrzymaj po zapisaniu zamiaru, po przygotowaniu podpisu i po wysłaniu. Zrestartowany system powinien wyjaśniać wiedzę na każdej granicy i unikać wymyślania nowego zakupu dla usunięcia niepewności. Sam pokaz czystego startu nie testuje stanów powodujących wiele błędów operacyjnych.

Weryfikuj konfigurację tak uważnie jak dane rynkowe

Konfiguracja jest kolejną granicą danych wejściowych. Błędny identyfikator sieci, zła liczba miejsc dziesiętnych lub brak maksymalnego budżetu mogą zmienić każdą dalszą decyzję przy normalnie działającym kodzie. Sprawdzaj wymagane ustawienia przed uruchamianiem procesów roboczych i odrzucaj konfigurację niewyjaśniającą jednostek lub dozwolonych ścieżek. Wartości domyślne należy wybierać świadomie, zwłaszcza gdy pominięcie mogłoby oznaczać nieograniczone wydatki.

Zachowuj wersjonowany opis konfiguracji użytej przy każdej decyzji bez kopiowania sekretów do zapisu. Operator badający zakup musi wiedzieć, czy właściwy limit wynosił 100 czy 120 jednostek, a nie tylko co ustawienie mówi dzisiaj. Późniejsza edycja nie powinna przepisywać wyjaśnienia wcześniejszego działania.

Zmiana limitu wymaga też reguły dla istniejących zobowiązań. Obniżenie limitu kampanii poniżej obecnej ekspozycji powinno zapobiegać dodatkowym zobowiązaniom i wywoływać przegląd; nie może wstecz odwracać zakupów. Podwyższenie limitu powinno wymagać tej samej jawnej autoryzacji co pierwotne zadanie. Ponowne wczytanie konfiguracji jest wygodnym mechanizmem dostarczenia decyzji, a nie niezależnym pozwoleniem zmiany strategii. Testuj przejścia obok zwykłej walidacji startu.

Zadbaj o łatwe utrzymanie bota NFT w Pythonie

Zewnętrzne API, zależności i ścieżki platform zmieniają się. Zapisuj wersje i założenia odpowiedzi, względem których testowano wydanie. Oceniaj aktualizacje w kontrolowanym środowisku przed nadaniem tych samych uprawnień co poprzednio ocenionej wersji. Udana instalacja niewiele mówi o zachowaniu zamierzonego działania przez zmienioną zależność.

Zachowuj raporty zrozumiałe dla kogoś, kto nie pisał kodu. Każde działanie powinno pokazywać powód, autoryzowaną kwotę, obserwowany wynik i otwarte pytania. Analiza wyników powinna obejmować nieudane próby i niesprzedane zasoby, a raporty inżynieryjne ujawniać błędy schematu, luki odzyskiwania i odrzucone żądania. To powiązane, lecz odmienne widoki systemu.

Najbardziej użyteczna architektura czyni błąd małym i możliwym do zdiagnozowania. Dokładne jednostki zapobiegają niejasnym wydatkom, jawne granice ograniczają uprawnienia, a trwałe zapisy wspierają odzyskiwanie. Python dostarcza przydatnych narzędzi wdrażania tych idei, lecz jakość bota wynika z jasności decyzji, których egzekwowania wymagamy od narzędzi.