NFT bot v Pythonu: stavte na datech a oprávněních

NFT botovi v Pythonu dejte jasné hranice součástí

Práci rozdělte na pozorovací adaptér, úložiště sjednocených záznamů, vyhodnocování pravidel, koordinátor provádění a omezené podpisové rozhraní. Mohou začít jako moduly jednoho projektu; nemusejí se stát pěti samostatnými službami. Hodnota vychází z dostatečně výslovných odpovědností pro nezávislé testování a uvažování.

Pozorovací adaptér rozumí podobě odpovědi a chybám vnějšího API. Nemá rozhodovat, že token stojí za nákup. Vyhodnocování pravidel rozumí kritériím kolekce a limitům útraty. Nemá potichu získat jinou cenu, pokud dodané pozorování nesplňuje pravidla. Koordinátor provádění spravuje autorizované úkony a jejich nevyřešené stavy, zatímco podepisující kontroluje přesné požadované oprávnění.

Každá hranice potřebuje vymezený vstup a výstup. Záznam prodejní nabídky může obsahovat identitu aktiva a objednávky, cenové jednotky, identitu platebního tokenu, čas pozorování a stav ověření. Rozhodnutí přidává verzi pravidel, důvod a maximální schválenou útratu. Transakční požadavek odkazuje na rozhodnutí a zachovává důkazní řetězec od dat k úkonu.

Záznamy zviditelňují nesoulad. Hlásí-li pozorovací adaptér cenu tokenu v jedné měně a pravidla očekávají jinou, vstup má selhat při ověření. Automatické dosazení známého symbolu měny by skrylo právě skutečnost, kterou systém potřebuje prozkoumat. Malá výslovná chyba je vhodnější než velký tichý předpoklad.

Identitu chápejte jako strukturovaná data

Zobrazovaný název NFT je pro člověka užitečný, ale slabým databázovým klíčem. U běžného aktiva EVM zaznamenejte řetězec, adresu kontraktu, identifikátor tokenu a standard. Tam, kde je to vhodné, zahrňte množství. Stejný identifikátor pod jiným kontraktem je jiným aktivem a stejně vypadající adresa kontraktu na jiném řetězci patří jinému síťovému kontextu.

Identita objednávky je oddělená od identity aktiva. Token může být v čase opakovaně vystaven k prodeji a prodávající může jednu objednávku nahradit jinou. Odstranění duplicit jen podle identifikátoru tokenu může zahodit skutečnou změnu ceny nebo zaměnit vypršelou objednávku s náhradou. Vedle záznamu položky zachovejte protokol a identifikátor objednávky.

Pro identifikátory používejte řetězce nebo dostatečně velká celá čísla bez předpokladu bezpečného vyjádření běžnými čísly s pohyblivou řádovou čárkou v každém dalším systému. Velký číselný identifikátor může přežít celočíselné zpracování Pythonu a potom ztratit přesnost při odeslání jiné součásti používající binární číslo s pohyblivou řádovou čárkou. Serializace je součástí architektury, nikoli pouhou prezentací.

Pokyny OpenSea ke kontrole stránky položky poskytují užitečný kontext identity pro lidské kontroly. Program má uchovat podkladové identifikátory umožňující provozovateli odlišit skutečné aktivum kolekce od nesouvisející položky s podobným obrázkem nebo názvem.

Na hranici používejte celočíselné zpracování tokenových částek

Tokenové částky vyžadují číslo i jednotku. Surová částka jeden milion znamená něco jiného u tokenu se šesti desetinnými místy než u tokenu s osmnácti. Surové celé číslo, identitu tokenu a ověřenou desetinnou konvenci ukládejte společně. Číslo bez jednotky nemá vstupovat do rozhodnutí o útratě.

U hypotetického platebního tokenu se šesti desetinnými místy odpovídá 12,345678 jednotky počtu 12 345 678 základních jednotek. Tři položky po 4,125000 jednotky činí celkem 12,375000 jednotky, tedy 12 375 000 základních jednotek. Limit pravidel 12,300000 jednotky proto nestačí o 75 000 základních jednotek, ekvivalentně 0,075000 jednotky. Srovnání má být přesné, i když rozhraní obě čísla zaokrouhluje pro zobrazení.

Celá čísla Pythonu jsou vhodná pro přesné částky v základních jednotkách. Desetinná aritmetika může pomoci s lidsky zadanými cenami, poměry a zprávami při správném parsování vstupů a výslovných pravidlech přesnosti a zaokrouhlení. Konstrukce desetinné hodnoty z již aproximovaného binárního čísla s pohyblivou řádovou čárkou neobnoví původní zamýšlený desetinný vstup. Pokud je zdrojovou reprezentací původní číselný řetězec, upřednostněte jej.

Uživatelskou částku s příliš mnoha desetinnými místy potichu nezaokrouhlujte na proveditelné množství. Před schválením rozhodněte o odmítnutí nebo jasně zdokumentovaném pravidle zaokrouhlení. Zaokrouhlení maximální ceny nahoru může překročit uživatelův limit, zatímco zaokrouhlení částky potřebné k vypořádání dolů může způsobit selhání transakce. Správné chování závisí na roli částky.

Cenu, poplatky a gas ponechte ve vlastních jednotkách

Nákup může zahrnovat platební token ERC-20 a nativní ETH na gas. Jde o samostatné zůstatky a kontroly schválení. Kombinovaná vykazovací hodnota je užitečná až po uvedení předpokladů převodu. Program nemá přičítat gas 0,02 ETH přímo ke 100 jednotkám jiného tokenu a výsledek označit jako 100,02 jednotky.

Uvažujte transakci Etherea s limitem gasu 150 000 a maximální cenou gasu 40 gwei. Maximální příděl gasu je 0,006 ETH. Pokud transakce skutečně používá 110 000 gasu při efektivní ceně 25 gwei, poplatek provedení je 0,00275 ETH. Čísla znázorňují rozdíl mezi přídělem rezervovaným před odesláním a nákladem odsouhlaseným poté.

Dokumentace gasu Etherea vysvětluje podkladové jednotky. Implementace má také zahrnout skutečný typ transakce a cestu místo předpokladu jediného vzorce pro každou síť nebo další poplatek. Potvrzení transakce a provedené platební toky určují realizované výdaje; odhad není konečným účetním záznamem.

Používejte výslovné názvy jako platební částka, maximální síťový příděl a realizovaný síťový náklad. Nejasná pole poplatek nebo součet podporují dvojí započtení při zahrnutí složky jednou odpovědí API a opětovném přidání jinou zprávou. Koordinátor transakcí má umět vysvětlit původ a jednotku každé rezervované částky.

Vnější data sjednocujte bez vymýšlení chybějících skutečností

Adaptér API má odlišovat nepřítomné pole od pole s platnou nulovou hodnotou. Chybějící cena neznamená bezplatnou prodejní nabídku. Nedostupné pole vlastníka neznamená, že token nikdo nevlastní. Prázdná odpověď může znamenat žádné odpovídající záznamy, ale selhání ověření nebo vypršení časového limitu žádosti nedokládá nepřítomnost prodejních nabídek kolekce.

Ověřujte očekávané struktury a neočekávané odmítejte s užitečným důvodem. Uchovejte dost původní veřejné odpovědi nebo bezpečný odkaz na ni k diagnóze změn schématu. Neprotokolujte ověřovací hlavičky nebo tajnou konfiguraci a přitom zachovejte běžné identifikátory a časová razítka. Ladění nemá vyžadovat odhalení pravomoci použité k přístupu ke službě.

Podobnou péči potřebuje stránkování. Sledujte zdokumentovaný mechanismus pokračování a uchovávejte postup při zpracování velkých kolekcí. Nepředpokládejte zastoupení veškeré současné držby první stránkou. Mohou-li se záznamy během čtení stránek měnit, chápejte výsledek jako pozorování během intervalu a odsouhlaste duplicity či změny místo tvrzení okamžitého snímku bez podkladů.

Obalová vrstva API má vykazovat známé skutečnosti. Přenosový timeout je přenosový timeout, nikoli zrušení prodávajícím. Nesprávně formátovaná odpověď je chybou parseru, nikoli záporným obchodním signálem. Přesné kategorie chyb brání jednání pravidel podle příběhu, který data nikdy nevyprávěla.

Události zpracovávejte jako pozorování, nikoli příkazy

Událost prodejní nabídky má spouštět hodnocení, nikoli okamžitý nákup jen kvůli příchodu. Může být duplicitní, opožděná nebo nahrazená jinou událostí. Proces má sjednotit identitu, zaznamenat čas, porovnat ji se stávajícím stavem a rozhodnout, zda je potřeba čerstvé ověření před žádostí o jakékoli oprávnění utrácet.

Dokumentace Stream API OpenSea popisuje doručování bez úplné záruky a možné události mimo pořadí. Obnovení spojení proto potřebuje cestu odsouhlasení schopnou objevit změny zmeškané během mezery. Přesný návrh obnovy závisí na záznamech potřebných strategii, ale nemá předpokládat, že tok událostí je úplnou a trvalou účetní knihou.

Potlačení duplicit ponechte oddělené od čerstvosti. Dvě kopie stejné události nemají způsobit dva úkony. Dvě různá pozorování stejného tokenu mohou být obě důležitá, protože jedno mění stav objednávky. Příliš široký deduplikační klíč může být při potlačování platných aktualizací stejně škodlivý jako žádná deduplikace.

Jednoduchý nácvik může doručit stejné pozorování dvakrát a potom zrušení s dřívějším pořadím příchodu, ale relevantním časem události. Očekávaným výsledkem je jeden kandidátní záznam s dohledatelnou historií stavu, nikoli dva nákupy nebo slepá důvěra poslední doručené zprávě. Očekávání vymezte před připojením programu ke skutečným oprávněním.

Souběžná rozhodnutí koordinujte sdílenými limity

Programy Pythonu často používají asynchronní úkoly ke zpracování několika síťových žádostí bez postupného čekání na každou. To může zlepšit pohotovost, ale zavádí otázky sdíleného stavu. Dvě hodnocení kandidátů mohou obě vidět stejný dostupný rozpočet před zaznamenáním rezervace kterýmkoli z nich. Rychlejší zpracování nesnižuje důsledky tohoto souběhu.

Předpokládejte kampaň s dostupnými 600 jednotkami platebního tokenu a dva procesy navrhující každý nákup 400 jednotek. Každý návrh při samostatném zkoumání vyhovuje, ale dohromady vyžadují 800 jednotek. Koordinátor musí podle rozpočtu schválit nejvýše jeden. Druhý má vidět zbývajících 200 jednotek a selhat nebo čekat podle pravidel.

Asynchronní zámek uvnitř procesu může koordinovat spolupracující úkoly jednoho procesu. Automaticky nekoordinuje samostatné procesy, jiné počítače ani ruční nákup ze stejné peněženky. Při širším rozdělení oprávnění jsou potřeba trvalá sdílená evidence a příslušná transakční aktualizace. Uveďte hranici skutečně chráněnou zvoleným synchronizačním mechanismem.

Omezte také počet nevyřízených žádostí. Neomezená souběžnost může vytvářet rostoucí frontu zastaralých kandidátů, zahltit vnější služby a ztížit sledování obnovy. Respektujte zdokumentované limity a po neúspěších, u nichž je možné žádost zopakovat, záměrně prodlužujte odstupy. Cílem jsou současná vysvětlitelná rozhodnutí, nikoli největší možný počet souběžných žádostí.

Záměr zachovejte před vyžádáním podpisu

Před vyžádáním podpisu uložte trvalý záznam záměru obsahující schválené aktivum, cestu, měnu, maximální částky, příjemce, verzi pravidel a příslušné vypršení. Záměru přidělte identifikátor používaný v celém postupu. Podepisující má obdržet dost strukturovaných informací k ověření žádosti vůči záznamu místo nevysvětleného bloku dat doprovázeného uklidňujícím označením.

Přihlašovací údaje API a podpisová pravomoc peněženky jsou různá tajemství s různými schopnostmi. Datová služba může potřebovat klíč ke čtení povolených záznamů bez důvodu přístupu k tajemství peněženky. Oddělení snižuje počet součástí schopných autorizovat transakce a usnadňuje omezení náhodného odhalení tajemství.

Podpisové rozhraní má odmítnout jiný řetězec, příjemce, kontrakt nebo částku, i když volající tvrdí příslušnost žádosti ke schválenému nákupu. Schválení se týká konkrétního úkonu v limitech, nikoli libovolných bajtů vytvořených procesem. Při podstatné změně cesty získejte nové rozhodnutí podle pravidel místo natahování starého.

Před převzetím kódu této vrstvy použijte přístup posuzování NFT bota z GitHubu. Známý název repozitáře nebo funkční ukázka neukazují, kam závislosti odesílají data ani jak široké oprávnění může konstruktor transakcí požadovat.

Obnovu transakcí NFT v Pythonu navrhněte výslovně

Nebezpečný okamžik bývá mezi odesláním a místním potvrzením. Síťová služba může transakci přijmout, zatímco volajícímu může vypršet časový limit před uložením vráceného výsledku. Obecné opakování může vytvořit další úkon, zatímco původní úkon stále čeká na výsledek. Obnova potřebuje nejprve prozkoumat původní záměr a identifikátory transakcí.

Používejte stavy zachovávající nejistotu: příklady jsou připraveno, schváleno, odesláno, čekající, potvrzeno, neúspěšné a nevyřešené. Přesné názvy jsou méně důležité než požadavky na podklady. Úspěšná odpověď HTTP není totéž co potvrzené vlastnictví a chybějící odpověď nedokazuje selhání transakce.

Při restartu odsouhlaste nedokončené záměry před zpracováním nových kandidátů. Rezervace jejich rozpočtu uchovejte do výsledku odůvodňujícího změnu. Je-li vlastnictví potvrzeno, zaznamenejte skutečné množství aktiva a náklad. Je-li doložen neúspěch, započtěte síťový výdaj před uvolněním zbytku. Nelze-li výsledek zatím doložit, zachovejte nevyřešený stav a ukažte jej provozovateli.

Ražba potřebuje další rozdíly, protože aktivum před transakcí nemusí existovat. Postup automatické ražby NFT má propojit schválené množství ražby se skutečně vytvořenými a přijatými identifikátory. Nemá vymýšlet očekávané identifikátory tokenů jen proto, že je kontrakt zdánlivě často vydává postupně.

Rozhodnutí testujte uloženými případy

Sestavte malou kolekci veřejných příkladů zbavených citlivých údajů a očekávaných rozhodnutí. Zahrňte platnou prodejní nabídku, položku na nesprávném řetězci, chybějící cenu, nadrozpočtový požadavek, duplicitní událost a neznámý výsledek transakce. Případy testují smysluplné chování na hranicích, kde chyby mohou měnit útratu či držbu.

Celočíselné převody testujte hodnotami těsně pod limitem, přesně na něm a těsně nad ním. Zahrňte tokeny s různými desetinnými konvencemi. Test opakující vlastní výpočet implementace bez nezávislého očekávaného výsledku může projít při současném nepochopení jednotky implementací i testem. Několik případů ověřte ručně a uchovejte odůvodnění.

U postupů ražby zahrňte nezpůsobilé peněženky a vyčerpané příděly jako běžné záporné výsledky. Automatizace má respektovat zveřejněné podmínky místo chápání odmítnutí jako výzvy k obejití. Rozbor pravidel seznamů povolených účastníků NFT pro zisk pomáhá oddělit způsobilost od nesouvisející otázky ekonomické přitažlivosti povolené ražby.

Nakonec nacvičte přerušení procesu a obnovu. Zastavte po zaznamenání záměru, po přípravě podpisu a po odeslání. Restartovaný systém má vysvětlit znalosti na každé hranici a nevymýšlet nový nákup k odstranění nejistoty. Samotná ukázka čistého startu netestuje stavy způsobující mnoho provozních chyb.

Konfiguraci ověřujte stejně pečlivě jako tržní data

Konfigurace je další vstupní hranicí. Chybně napsaný identifikátor řetězce, nesprávný počet desetinných míst nebo chybějící maximální rozpočet mohou měnit každé následné rozhodnutí při normálním pokračování kódu. Požadovaná nastavení zkontrolujte před spuštěním procesů a odmítněte konfiguraci nevysvětlující jednotky nebo povolené cesty. Výchozí hodnoty mají být zvoleny záměrně, zejména pokud by vynechání jinak mohlo znamenat neomezenou útratu.

Uchovejte verzovaný popis konfigurace použité každým rozhodnutím bez kopírování tajemství do záznamu. Provozovatel zkoumající nákup potřebuje vědět, zda příslušný strop činil 100 nebo 120 jednotek, nikoli jen dnešní nastavení. Pozdější úprava nemá přepsat vysvětlení dřívějšího úkonu.

Změna limitu také vyžaduje pravidlo pro stávající závazky. Snížení stropu kampaně pod současnou expozici má zabránit dalším závazkům a vyvolat kontrolu; nedokáže zpětně obrátit nákupy. Zvýšení stropu má vyžadovat stejné výslovné oprávnění jako původní zadání. Opětovné načtení konfigurace je pohodlným doručovacím mechanismem rozhodnutí, nikoli samostatným povolením změnit strategii. Tyto přechody testujte vedle běžného ověření při spuštění.

NFT bota v Pythonu udržujte spravovatelného

Vnější API, závislosti a cesty tržišť se mění. Zaznamenejte verze a předpoklady o odpovědích, vůči nimž bylo vydání testováno. Aktualizace kontrolujte v řízeném prostředí před udělením stejného oprávnění jako dříve zkontrolované verzi. Úspěšná instalace vypovídá málo o zachování zamýšleného chování změněnou závislostí.

Zprávy ponechte srozumitelné člověku, který kód nenapsal. Každý úkon má ukazovat důvod, schválenou částku, pozorovaný výsledek a nevyřešené otázky. Analýza výkonnosti má zahrnovat neúspěšné pokusy a neprodanou držbu, zatímco technické zprávy mají odhalovat selhání schématu, mezery obnovy a odmítnuté žádosti. Jde o související, ale odlišné pohledy na systém.

Nejužitečnější architektura činí chybu malou a diagnostikovatelnou. Přesné jednotky brání nejasné útratě, výslovné hranice omezují oprávnění a trvalé záznamy podporují obnovu. Python dodává užitečné nástroje k implementaci těchto myšlenek, ale kvalita bota vychází z jasnosti rozhodnutí, jejichž vynucování je nástrojům zadáno.