Bot NFT in Python: progettare attorno ai dati e all’autorità

Assegnare al bot NFT in Python confini chiari tra i componenti

Separa il lavoro in un adattatore di osservazione, un archivio di record normalizzati, un valutatore della politica, un coordinatore dell’esecuzione e un’interfaccia di firma limitata. Possono iniziare come moduli di un progetto; non devono diventare cinque servizi separati. Il valore deriva dal rendere le loro responsabilità abbastanza esplicite da poterle verificare e analizzare indipendentemente.

L’adattatore di osservazione comprende la struttura delle risposte e gli errori di un’API esterna. Non dovrebbe decidere che valga la pena acquistare un token. Il valutatore della politica comprende i criteri delle collezioni e i limiti di spesa. Non dovrebbe recuperare silenziosamente un prezzo diverso se l’osservazione fornita non supera le sue regole. Il coordinatore dell’esecuzione gestisce le azioni autorizzate e i loro stati irrisolti, mentre il firmatario controlla l’autorità precisa richiesta.

Ogni confine richiede un ingresso e un’uscita definiti. Il record di un’inserzione potrebbe contenere identità dell’asset, identità dell’ordine, unità del prezzo, identità del token di pagamento, ora dell’osservazione e stato di convalida. Una decisione aggiunge versione della politica, motivo e spesa massima autorizzata. Una richiesta di transazione rimanda a quella decisione, conservando la catena dei riscontri dai dati all’azione.

Questi registri rendono visibili i disaccordi. Se l’adattatore di osservazione riporta il prezzo di un token in una valuta e la politica ne prevede un’altra, il dato dovrebbe fallire la convalida. Sostituire automaticamente un simbolo di valuta familiare nasconderebbe proprio il fatto che il sistema deve esaminare. Un piccolo errore esplicito è preferibile a una grande supposizione silenziosa.

Trattare l’identità come dato strutturato

Il nome visualizzato di un NFT è utile per una persona, ma è una scarsa chiave di database. Per un normale asset EVM, registra blockchain, indirizzo del contratto, identificativo del token e standard. Includi la quantità ove opportuno. Lo stesso identificativo sotto un contratto diverso è un asset diverso, e lo stesso indirizzo dall’aspetto di contratto su un’altra blockchain appartiene a un diverso contesto di rete.

L’identità dell’ordine è separata da quella dell’asset. Un token può essere messo in vendita più volte nel tempo e un venditore può sostituire un ordine con un altro. Deduplicare soltanto per identificativo del token può scartare una vera variazione di prezzo o confondere un ordine scaduto con il suo sostituto. Conserva protocollo e identificativo dell’ordine accanto al record dell’elemento.

Usa stringhe o interi di dimensione appropriata per gli identificativi senza presumere che ogni sistema successivo possa rappresentarli in sicurezza come normali numeri a virgola mobile. Un grande identificativo numerico di token può sopravvivere alla gestione degli interi di Python e poi perdere precisione quando viene inviato a un altro componente che lo tratta come valore binario a virgola mobile. La serializzazione fa parte dell’architettura, non soltanto della presentazione.

La guida di OpenSea su come esaminare la pagina di un elemento offre un contesto utile sull’identità per i controlli umani. Il programma dovrebbe conservare gli identificativi sottostanti che consentono a un operatore di distinguere un asset autentico della collezione da un elemento non correlato con un’opera o un nome simili.

Gestire gli importi interi dei token al confine del sistema

Gli importi dei token richiedono sia un numero sia un’unità. Un importo grezzo di un milione significa qualcosa di diverso per un token con sei decimali rispetto a uno con diciotto. Conserva insieme l’intero grezzo, l’identità del token e la convenzione decimale verificata. Un numero senza unità non dovrebbe entrare in una decisione di spesa.

Per un ipotetico token di pagamento con sei decimali, 12,345678 unità corrispondono a 12.345.678 unità di base. Tre elementi a 4,125000 unità ciascuno totalizzano 12,375000 unità, ossia 12.375.000 unità di base. Un limite della politica di 12,300000 unità è quindi inferiore di 75.000 unità di base, equivalenti a 0,075000 unità. Il confronto dovrebbe essere esatto, anche se l’interfaccia arrotonda entrambe le cifre per mostrarle.

Gli interi di Python sono adatti a importi esatti in unità di base. L’aritmetica decimale può aiutare con prezzi inseriti dall’utente, rapporti e rapporti informativi, purché i dati siano analizzati appropriatamente e le regole di precisione e arrotondamento siano esplicite. Costruire un valore decimale da un numero binario a virgola mobile già approssimato non recupera l’input decimale originariamente previsto. Preferisci la stringa numerica originale quando quella è la rappresentazione della fonte.

Non arrotondare silenziosamente un importo dell’utente con troppi decimali in una quantità eseguibile. Decidi se respingerlo o applicare una regola di arrotondamento chiaramente documentata prima dell’autorizzazione. Arrotondare verso l’alto un prezzo massimo può superare il limite dell’utente, mentre arrotondare verso il basso un importo necessario al regolamento può far fallire la transazione. Il comportamento corretto dipende dal ruolo dell’importo.

Mantenere prezzo, commissioni e gas nelle rispettive unità

Un acquisto può coinvolgere un token di pagamento ERC-20 ed ETH nativo per il gas. Sono saldi separati e controlli di autorizzazione separati. Un valore combinato nei rapporti è utile soltanto dopo aver dichiarato le ipotesi di conversione. Il programma non dovrebbe sommare direttamente 0.02 ETH di gas a 100 unità di un altro token ed etichettare il risultato come 100.02 unità.

Considera una transazione Ethereum con limite di gas di 150.000 e prezzo massimo del gas di 40 gwei. Il margine massimo per il gas è 0.006 ETH. Se la transazione usa effettivamente 110.000 unità di gas a un prezzo effettivo di 25 gwei, l’addebito di esecuzione è 0.00275 ETH. Queste cifre illustrano la distinzione tra un margine riservato prima dell’invio e un costo riconciliato in seguito.

La documentazione sul gas di Ethereum spiega le unità sottostanti. Un’implementazione dovrebbe anche considerare tipo e percorso effettivi della transazione anziché presumere che una formula copra ogni rete o ogni commissione aggiuntiva. La ricevuta e i flussi di pagamento eseguiti determinano le spese realizzate; una stima non è un registro contabile finale.

Usa nomi espliciti come importo del pagamento, margine massimo di rete e costo di rete realizzato. Campi ambigui chiamati commissione o totale favoriscono il doppio conteggio quando una risposta API include già una componente che un altro rapporto aggiunge di nuovo. Un coordinatore delle transazioni dovrebbe poter spiegare origine e unità di ogni importo che riserva.

Normalizzare i dati esterni senza inventare fatti mancanti

Un adattatore API dovrebbe distinguere un campo assente da un campo il cui valore valido è zero. Un prezzo mancante non significa un’inserzione gratuita. Un campo del proprietario indisponibile non significa che nessuno possieda il token. Una risposta vuota può significare che non vi siano record corrispondenti, ma un errore di autenticazione o una richiesta scaduta non dimostrano che la collezione non abbia inserzioni.

Convalida le strutture attese e respingi quelle inattese con un motivo utile. Conserva abbastanza della risposta pubblica originale, o un riferimento sicuro a essa, per diagnosticare cambiamenti dello schema. Evita di registrare intestazioni di autenticazione o configurazioni segrete, conservando invece identificativi ordinari e indicazioni temporali. Il debug non dovrebbe richiedere di esporre l’autorità usata per accedere al servizio.

La paginazione richiede un’attenzione simile. Segui il meccanismo di continuazione documentato e conserva l’avanzamento durante l’elaborazione di grandi collezioni. Non presumere che la prima pagina rappresenti tutto l’inventario attuale. Se i record possono cambiare mentre vengono lette le pagine, tratta il risultato come osservazioni lungo un intervallo e riconcilia duplicati o cambiamenti anziché dichiarare un’istantanea senza riscontri.

Il wrapper dell’API dovrebbe riportare ciò che sa. Un timeout di trasporto è un timeout di trasporto, non un annullamento del venditore. Una risposta malformata è un errore del parser, non un segnale di trading negativo. Mantenere precise le categorie di errore impedisce a una politica di agire su una storia che i dati non hanno mai realmente raccontato.

Gestire gli eventi come osservazioni, non comandi

Un evento di inserzione dovrebbe innescare una valutazione, non un acquisto immediato soltanto perché è arrivato. Può essere duplicato, ritardato o superato da un altro evento. Il processo di lavoro dovrebbe normalizzarne l’identità, registrarne l’ora, confrontarlo con lo stato esistente e decidere se sia necessaria una nuova convalida prima di richiedere qualsiasi autorità di spesa.

La documentazione della Stream API di OpenSea descrive la consegna secondo il massimo sforzo e possibili eventi fuori ordine. La riconnessione richiede quindi un percorso di riconciliazione che possa scoprire i cambiamenti persi durante la lacuna. Il progetto preciso di ripristino dipende dai registri necessari alla strategia, ma non dovrebbe presumere che il flusso di eventi sia un registro completo e permanente.

Tieni separata la soppressione dei duplicati dalla freschezza. Due copie dello stesso evento non dovrebbero causare due azioni. Due osservazioni diverse sullo stesso token possono contare entrambe perché una modifica lo stato dell’ordine. Una chiave di deduplicazione eccessivamente ampia può essere dannosa quanto l’assenza di deduplicazione se sopprime aggiornamenti legittimi.

Una semplice prova può consegnare due volte la stessa osservazione, poi consegnare un annullamento con un ordine di arrivo precedente ma un orario dell’evento pertinente. Il risultato atteso è un record del candidato con una cronologia dello stato tracciabile, non due acquisti o un messaggio arrivato per ultimo considerato affidabile alla cieca. Definisci queste aspettative prima di collegare il programma ad autorità reale.

Coordinare decisioni concorrenti attraverso limiti condivisi

I programmi Python usano spesso compiti asincroni per gestire diverse richieste di rete senza attendere ciascuna in sequenza. Questo può migliorare la reattività, ma introduce questioni di stato condiviso. Due valutazioni di candidati possono entrambe vedere lo stesso budget disponibile prima che una delle due registri la propria riserva. Un’elaborazione più rapida non rende meno rilevanti le conseguenze di questa competizione.

Supponiamo che una campagna abbia 600 unità del token di pagamento disponibili e che due processi di lavoro propongano ciascuno un acquisto da 400 unità. Ogni proposta rientra nel limite se esaminata da sola, ma insieme richiedono 800 unità. Il coordinatore deve autorizzarne al massimo una entro quel budget. L’altra dovrebbe vedere le 200 unità residue ed essere respinta o attendere secondo la politica.

Un blocco asincrono interno a un processo può coordinare compiti cooperanti in quel processo. Non coordina automaticamente processi separati, altri computer o un acquisto manuale dallo stesso wallet. Servono un registro condiviso persistente e un aggiornamento transazionale appropriato quando l’autorità è distribuita più ampiamente. Dichiara il confine che il meccanismo di sincronizzazione scelto protegge effettivamente.

Limita anche il numero di richieste ancora aperte. Una concorrenza illimitata può creare una coda crescente di candidati obsoleti, sovraccaricare servizi esterni e rendere più difficile seguire il ripristino. Rispetta i limiti documentati e applica una pausa progressiva deliberata dopo errori per cui è consentito riprovare. L’obiettivo sono decisioni attuali e spiegabili, non il massimo numero possibile di richieste simultanee.

Conservare l’intenzione prima di richiedere una firma

Prima di richiedere una firma, salva un record persistente dell’intenzione contenente asset approvato, percorso, valuta, importi massimi, destinatario, versione della politica e scadenza pertinente. Assegna a tale intenzione un identificativo usato in tutto il flusso. Il firmatario dovrebbe ricevere informazioni strutturate sufficienti per verificare la richiesta rispetto a questo record, anziché un blocco incomprensibile accompagnato da un’etichetta rassicurante.

Le credenziali API e l’autorità di firma del wallet sono segreti diversi con poteri diversi. Un servizio dati può avere bisogno di una chiave per leggere record consentiti senza avere alcun motivo di accedere a un segreto del wallet. Tenere separati questi poteri riduce il numero di componenti che possono autorizzare transazioni e rende più semplice contenere l’esposizione accidentale di segreti.

L’interfaccia di firma dovrebbe respingere una blockchain, un destinatario, un contratto o un importo diversi anche quando il chiamante afferma che la richiesta appartenga a un acquisto approvato. L’approvazione riguarda una particolare azione entro limiti, non byte arbitrari prodotti da un processo di lavoro. Se il percorso cambia sostanzialmente, ottieni una nuova decisione della politica anziché estendere quella vecchia.

Prima di prendere in prestito codice per questo livello, usa l’approccio di verifica descritto in valutare un bot NFT su GitHub. Un nome di repository familiare o una dimostrazione funzionante non mostrano dove le dipendenze inviino dati o quanta autorità possa richiedere il suo costruttore di transazioni.

Progettare esplicitamente il ripristino delle transazioni NFT in Python

Il momento pericoloso è spesso tra l’invio e la conferma locale di ricezione. Un servizio di rete può accettare una transazione mentre la chiamata scade prima di salvare il risultato restituito. Un tentativo generico può creare un’azione aggiuntiva mentre quella originale è ancora in sospeso. Il ripristino deve prima indagare l’intenzione originale e gli identificativi della transazione.

Usa stati che conservino l’incertezza: preparato, approvato, inviato, in sospeso, confermato, fallito e irrisolto sono possibili esempi. I nomi esatti contano meno dei requisiti di riscontro. Una risposta HTTP riuscita non equivale alla proprietà confermata e una risposta mancante non dimostra che la transazione sia fallita.

Al riavvio, riconcilia le intenzioni incompiute prima di elaborare nuovi candidati. Mantieni le loro riserve di budget finché l’esito non giustifichi una modifica. Se la proprietà viene confermata, registra quantità effettiva dell’asset e costo. Se il fallimento viene stabilito, contabilizza ogni spesa di rete prima di liberare il residuo. Se l’esito non può ancora essere stabilito, conserva lo stato irrisolto e rendilo visibile all’operatore.

Il mint richiede ulteriori distinzioni perché l’asset potrebbe non esistere prima della transazione. Un flusso di mint NFT automatizzato dovrebbe collegare la quantità di mint autorizzata agli identificativi effettivamente creati e ricevuti. Non dovrebbe inventare identificativi di token attesi soltanto perché il contratto sembra spesso emetterli in sequenza.

Verificare le decisioni con casi salvati

Costruisci una piccola raccolta di esempi pubblici ripuliti da dati sensibili e decisioni attese. Includi un’inserzione valida, un elemento sulla blockchain sbagliata, un prezzo mancante, una richiesta oltre budget, un evento duplicato e un risultato di transazione sconosciuto. Questi casi verificano comportamenti significativi ai confini in cui gli errori possono cambiare spesa o inventario.

Verifica le conversioni di interi con valori appena sotto, esattamente al limite e appena sopra. Includi token con convenzioni decimali diverse. Un test che ripete il calcolo dell’implementazione senza un risultato atteso indipendente può passare mentre sia l’implementazione sia il test fraintendono l’unità. Controlla manualmente alcuni casi e conservane il ragionamento.

Per i flussi di mint, includi wallet non idonei e allocazioni esaurite come normali esiti negativi. L’automazione dovrebbe rispettare le condizioni pubblicate anziché trattare il rifiuto come una sfida da aggirare. La discussione sulla politica in liste di autorizzazione NFT per il profitto aiuta a separare l’idoneità dalla questione non correlata della convenienza economica di un mint consentito.

Infine, prova l’interruzione del processo e il ripristino. Ferma dopo la registrazione dell’intenzione, dopo la preparazione della firma e dopo l’invio. Il sistema riavviato dovrebbe spiegare che cosa sia noto a ogni confine ed evitare di inventare un nuovo acquisto per eliminare l’incertezza. Una dimostrazione con avvio pulito, da sola, non verifica gli stati che causano molti errori operativi.

Convalidare la configurazione con la stessa cura dei dati di mercato

La configurazione è un altro confine di ingresso. Un identificativo della blockchain digitato male, un numero di decimali errato o un budget massimo mancante possono cambiare ogni decisione successiva mentre il codice continua a funzionare normalmente. Controlla le impostazioni necessarie prima di avviare i processi di lavoro e respingi una configurazione che non possa spiegare unità o percorsi consentiti. Le impostazioni predefinite dovrebbero essere scelte deliberatamente, soprattutto dove un’omissione potrebbe altrimenti significare spesa illimitata.

Conserva una descrizione con versione della configurazione usata per ogni decisione senza copiarvi segreti. Un operatore che indaga un acquisto deve sapere se il massimale applicabile fosse 100 o 120 unità, non soltanto che cosa dica oggi l’impostazione. Una modifica successiva non dovrebbe riscrivere la spiegazione di un’azione precedente.

Cambiare un limite richiede anche una regola per gli impegni esistenti. Ridurre un massimale di campagna sotto l’esposizione attuale dovrebbe impedire impegni aggiuntivi e richiedere un esame; non può annullare retroattivamente gli acquisti. Aumentare un massimale dovrebbe richiedere la stessa autorità esplicita del compito originale. Ricaricare la configurazione è un comodo meccanismo di consegna di una decisione, non un permesso indipendente di cambiare la strategia. Verifica queste transizioni insieme alla normale convalida all’avvio.

Mantenere gestibile la manutenzione di un bot NFT in Python

API esterne, dipendenze e percorsi dei marketplace cambiano. Registra rispetto a quali versioni e ipotesi sulle risposte sia stata verificata una versione del software. Esamina gli aggiornamenti in un ambiente controllato prima di attribuire loro la stessa autorità della versione precedentemente esaminata. Un’installazione riuscita dice poco sulla conservazione del comportamento previsto da parte di una dipendenza modificata.

Mantieni i rapporti comprensibili a chi non ha scritto il codice. Ogni azione dovrebbe mostrare motivo, importo autorizzato, esito osservato e domande irrisolte. L’analisi delle prestazioni dovrebbe includere tentativi falliti e inventario invenduto, mentre i rapporti tecnici dovrebbero esporre errori di schema, lacune del ripristino e richieste respinte. Sono viste del sistema correlate ma distinte.

L’architettura più utile è quella che rende un errore piccolo e diagnosticabile. Unità esatte impediscono spese ambigue, confini espliciti limitano l’autorità e registri persistenti supportano il ripristino. Python fornisce strumenti utili per implementare queste idee, ma la qualità del bot deriva dalla chiarezza delle decisioni che tali strumenti devono applicare.