NFT-bot i Python: bygg kring data och befogenhet

Ge en NFT-bot i Python tydliga komponentgränser

Dela upp arbetet i en observationsadapter, ett lager för normaliserade poster, en policyutvärderare, en genomförandesamordnare och ett begränsat signeringsgränssnitt. De kan börja som moduler i ett projekt; de behöver inte bli fem separata tjänster. Värdet ligger i att göra ansvaret tillräckligt uttryckligt för att testa och resonera om varje del oberoende.

Observationsadaptern förstår ett externt API:s svarsstruktur och fel. Den bör inte avgöra att en token är värd att köpa. Policyutvärderaren förstår samlingskriterier och utgiftsgränser. Den bör inte tyst hämta ett annat pris om den tillhandahållna observationen inte klarar reglerna. Genomförandesamordnaren hanterar tillåtna åtgärder och deras olösta tillstånd, medan signeraren kontrollerar exakt vilken befogenhet som begärs.

Varje gräns behöver definierade in- och utdata. En annonspost kan innehålla tillgångsidentitet, orderidentitet, prisenheter, betalningstokens identitet, observationstid och valideringsstatus. Ett beslut lägger till policyversion, skäl och maximal tillåten utgift. En transaktionsbegäran hänvisar tillbaka till beslutet och bevarar underlagskedjan från data till handling.

Posterna gör motstridiga uppgifter synliga. Om observationsadaptern rapporterar ett tokenpris i en valuta och policyn förväntar en annan bör indata underkännas vid validering. Automatisk ersättning med en välbekant valutasymbol skulle dölja just det systemet behöver granska. Ett litet uttryckligt fel är att föredra framför ett stort tyst antagande.

Behandla identitet som strukturerade data

En NFT:s visningsnamn är användbart för en person men en dålig databasnyckel. För en vanlig EVM-tillgång ska kedja, kontraktsadress, tokenidentifierare och standard registreras. Inkludera mängd där det är relevant. Samma identifierare under ett annat kontrakt är en annan tillgång, och samma kontraktsliknande adress på en annan kedja tillhör ett annat nätverkssammanhang.

Orderidentitet är skild från tillgångsidentitet. En token kan annonseras flera gånger över tid och en säljare kan ersätta en order med en annan. Dubblettrensning enbart efter tokenidentifierare kan kasta bort en verklig prisändring eller förväxla en utgången order med dess ersättare. Bevara protokollet och orderidentifieraren bredvid objektposten.

Använd strängar eller heltal av lämplig storlek för identifierare utan att anta att varje nedströms system säkert kan representera dem som vanliga flyttal. En stor numerisk tokenidentifierare kan överleva Pythons heltalshantering och sedan förlora precision när den skickas till en annan komponent som behandlar den som ett binärt flyttal. Serialisering är del av arkitekturen, inte bara presentation.

OpenSeas vägledning om granskning av en objektsida ger användbart identitetssammanhang för mänskliga kontroller. Programmet bör behålla underliggande identifierare som låter operatören skilja en äkta samlingstillgång från ett orelaterat objekt med liknande konstverk eller namn.

Hantera tokenbelopp som heltal vid gränsen

Tokenbelopp kräver både tal och enhet. Ett råbelopp på en miljon betyder något annat för en token med sex decimaler än för en med arton. Lagra råheltalet, tokenidentiteten och den verifierade decimalkonventionen tillsammans. Ett tal utan enhet bör inte ingå i ett utgiftsbeslut.

För en hypotetisk betalningstoken med sex decimaler motsvarar 12,345678 enheter 12 345 678 basenheter. Tre objekt prissatta till 4,125000 enheter vardera blir totalt 12,375000 enheter, eller 12 375 000 basenheter. En policygräns på 12,300000 enheter saknar därför 75 000 basenheter, motsvarande 0,075000 enheter. Jämförelsen bör vara exakt även om gränssnittet avrundar båda talen vid visning.

Python-heltal lämpar sig för exakta basenhetsbelopp. Decimalaritmetik kan hjälpa med användarinmatade priser, kvoter och rapporter, förutsatt att indata tolkas korrekt och precision och avrundningsregler är uttryckliga. Att konstruera ett decimalvärde från ett redan approximerat binärt flyttal återställer inte den ursprungligen avsedda decimalinmatningen. Föredra den ursprungliga numeriska strängen när det är källrepresentationen.

Avrunda inte tyst ett användarbelopp med för många decimaler till en genomförbar mängd. Bestäm om det ska avvisas eller omfattas av en tydligt dokumenterad avrundningsregel före godkännande. Uppåtavrundning av ett högsta pris kan överskrida användarens gräns, medan nedåtavrundning av ett belopp som behövs för avveckling kan få transaktionen att misslyckas. Rätt beteende beror på beloppets roll.

Behåll pris, avgifter och gas i sina egna enheter

Ett köp kan omfatta en ERC-20-betalningstoken och nätverkets egen ETH för gas. Det är separata saldon och separata behörighetskontroller. Ett kombinerat rapportvärde är användbart först när växlingsantaganden angetts. Programmet bör inte lägga till 0,02 ETH i gas direkt till 100 enheter av en annan token och kalla resultatet 100,02 enheter.

Betrakta en Ethereum-transaktion med gasgräns 150 000 och maximalt gaspris 40 gwei. Maximalt gasutrymme är 0,006 ETH. Om transaktionen faktiskt använder 110 000 gas till effektivt pris 25 gwei är genomförandeavgiften 0,00275 ETH. Siffrorna illustrerar skillnaden mellan ett utrymme reserverat före inskickande och en kostnad avstämd efteråt.

Ethereums gasdokumentation förklarar de underliggande enheterna. En implementation bör också beakta faktisk transaktionstyp och väg i stället för att anta att en formel täcker varje nätverk eller extra avgift. Kvittot och genomförda betalningsflöden bestämmer realiserade utgifter; en uppskattning är ingen slutlig redovisningspost.

Använd uttryckliga namn som betalningsbelopp, maximalt nätverksutrymme och realiserad nätverkskostnad. Tvetydiga fält kallade avgift eller total uppmuntrar dubbelräkning när ett API-svar redan inkluderar en komponent som en annan rapport lägger till igen. En transaktionssamordnare bör kunna förklara ursprung och enhet för varje reserverat belopp.

Normalisera externa data utan att hitta på saknade fakta

En API-adapter bör skilja ett frånvarande fält från ett fält vars giltiga värde är noll. Ett saknat pris betyder inte en gratis annons. Ett otillgängligt ägarfält betyder inte att ingen äger token. Ett tomt svar kan betyda att matchande poster saknas, men ett autentiseringsfel eller en begäran som fått timeout fastställer inte att samlingen saknar annonser.

Validera förväntade strukturer och avvisa oväntade med ett användbart skäl. Behåll tillräckligt av det ursprungliga offentliga svaret, eller en säker hänvisning till det, för att diagnostisera schemaändringar. Undvik att logga autentiseringshuvuden eller hemlig konfiguration men bevara vanliga identifierare och tidsstämplar. Felsökning bör inte kräva att befogenheten för tjänståtkomst exponeras.

Sidindelning kräver liknande omsorg. Följ den dokumenterade fortsättningsmekanismen och bevara förloppet vid behandling av stora samlingar. Anta inte att första sidan representerar hela det aktuella innehavet. Om poster kan ändras medan sidor läses ska resultatet behandlas som observationer över ett intervall, med avstämning av dubbletter och ändringar, i stället för att utan belägg hävda en momentan ögonblicksbild.

API-omslaget bör rapportera vad det vet. En transporttimeout är en transporttimeout, inte en säljarannullering. Ett felaktigt formaterat svar är ett tolkningsfel, inte en negativ handelssignal. Exakta felkategorier hindrar policyn från att agera på en berättelse som data aldrig faktiskt gav.

Hantera händelser som observationer, inte kommandon

En annonshändelse bör utlösa utvärdering, inte omedelbart köp bara för att den anlände. Den kan vara dubblerad, fördröjd eller ersatt av en annan händelse. Arbetsprocessen bör normalisera identiteten, registrera tiden, jämföra med befintligt tillstånd och avgöra om ny validering behövs innan någon utgiftsbefogenhet begärs.

OpenSeas Stream API-dokumentation beskriver leverans efter bästa förmåga och möjliga händelser i fel ordning. Återanslutning behöver därför en avstämningsväg som kan upptäcka förändringar missade under avbrottet. Den exakta återhämtningsutformningen beror på vilka poster strategin behöver, men bör inte anta att händelseflödet är ett fullständigt permanent register.

Håll dubblettundertryckning åtskild från aktualitet. Två kopior av samma händelse bör inte orsaka två åtgärder. Två olika observationer om samma token kan båda spela roll för att en ändrar orderstatusen. En alltför bred dubblettnyckel kan vara lika skadlig som ingen alls om den undertrycker legitima uppdateringar.

En enkel repetition kan leverera samma observation två gånger och sedan leverera en annullering med tidigare ankomstordning men relevant händelsetidsstämpel. Det förväntade resultatet är en kandidatpost med spårbar tillståndshistorik, inte två köp eller ett blint betrott sist anlänt meddelande. Definiera förväntningarna innan programmet kopplas till faktisk befogenhet.

Samordna samtidiga beslut genom gemensamma gränser

Python-program använder ofta asynkrona uppgifter för flera nätverksbegäranden utan att vänta på var och en sekventiellt. Det kan förbättra responsen men skapar frågor om delat tillstånd. Två kandidatutvärderingar kan båda se samma tillgängliga budget innan någon registrerat sin reservation. Snabbare behandling gör inte kapplöpningen mindre betydelsefull.

Anta att en kampanj har 600 betalningstokenenheter tillgängliga och två arbetsprocesser föreslår varsitt köp på 400 enheter. Varje förslag ryms sett för sig, men tillsammans kräver de 800 enheter. Samordnaren måste tillåta högst ett inom budgeten. Det andra bör se återstående 200 enheter och avvisas eller vänta enligt policy.

Ett asynkront lås inom processen kan samordna samarbetande uppgifter i en process. Det samordnar inte automatiskt separata processer, andra datorer eller ett manuellt köp från samma plånbok. Ett beständigt gemensamt register och en lämplig transaktionell uppdatering behövs när befogenheten är bredare distribuerad. Ange gränsen som vald synkroniseringsmekanism faktiskt skyddar.

Begränsa också antalet utestående begäranden. Obegränsad samtidighet kan skapa en växande kö av inaktuella kandidater, överbelasta externa tjänster och göra återhämtning svårare att följa. Respektera dokumenterade gränser och tillämpa avsiktligt ökande väntan efter fel som kan prövas igen. Målet är aktuella, förklarliga beslut, inte största möjliga antal samtidiga begäranden.

Bevara avsikten innan en signatur begärs

Spara före signaturbegäran en beständig avsiktspost med godkänd tillgång, väg, valuta, maximala belopp, mottagare, policyversion och relevant giltighetstid. Ge avsikten en identifierare som används genom hela flödet. Signeraren bör få tillräcklig strukturerad information för att verifiera begäran mot posten, snarare än ett oförklarat datapaket tillsammans med en lugnande etikett.

API-autentiseringsuppgifter och plånbokens signeringsbefogenhet är olika hemligheter med olika makt. En datatjänst kan behöva en nyckel för att läsa tillåtna poster utan skäl att få åtkomst till en plånbokshemlighet. Att hålla befogenheterna åtskilda minskar antalet komponenter som kan auktorisera transaktioner och gör oavsiktlig hemlighetsexponering lättare att begränsa.

Signeringsgränssnittet bör avvisa annan kedja, mottagare, annat kontrakt eller belopp även när anroparen säger att begäran tillhör ett godkänt köp. Godkännandet gäller en viss åtgärd inom gränser, inte godtyckliga byte skapade av en arbetsprocess. Om vägen ändras väsentligt ska ett nytt policybeslut erhållas i stället för att tänja på det gamla.

Innan kod lånas för detta lager, använd granskningsmetoden i att bedöma en NFT-bot på GitHub. Ett välbekant arkivnamn eller en fungerande demonstration visar inte vart beroendena skickar data eller hur mycket befogenhet transaktionsbyggaren kan begära.

Utforma transaktionsåterhämtning för NFT:er i Python uttryckligen

Det farliga ögonblicket är ofta mellan inskickande och lokal kvittens. En nätverkstjänst kan acceptera en transaktion medan anroparen får timeout innan det returnerade resultatet sparas. Ett generellt återförsök kan skapa ytterligare en åtgärd när den ursprungliga fortfarande väntar. Återhämtning behöver först undersöka den ursprungliga avsikten och transaktionsidentifierarna.

Använd tillstånd som bevarar osäkerhet: förberedd, godkänd, inskickad, väntande, bekräftad, misslyckad och olöst är möjliga exempel. De exakta namnen betyder mindre än deras underlagskrav. Ett lyckat HTTP-svar är inte samma sak som bekräftat ägande, och ett saknat svar bevisar inte att transaktionen misslyckades.

Stäm vid omstart av oavslutade avsikter innan nya kandidater behandlas. Behåll deras budgetreservationer tills utfallet motiverar en ändring. Om ägandet bekräftas ska faktisk tillgångsmängd och kostnad registreras. Om misslyckande fastställs ska eventuell nätverksutgift redovisas innan resten frigörs. Om utfallet ännu inte kan fastställas ska olöst tillstånd behållas och visas för operatören.

Mintning behöver ytterligare skillnader eftersom tillgången kanske inte finns före transaktionen. Ett flöde för automatiserad NFT-mintning bör koppla tillåten mintmängd till de identifierare som faktiskt skapats och mottagits. Det bör inte hitta på förväntade tokenidentifierare bara för att kontraktet ofta verkar utfärda dem i följd.

Testa beslut med sparade fall

Bygg en liten samling offentliga, rensade exempel och förväntade beslut. Inkludera en giltig annons, ett objekt på fel kedja, ett saknat pris, en begäran över budget, en dubblerad händelse och ett okänt transaktionsresultat. Fallen testar meningsfullt beteende vid gränser där misstag kan ändra utgifter eller innehav.

Testa heltalsomvandlingar med värden strax under, exakt vid och strax över en gräns. Inkludera token med olika decimalkonventioner. Ett test som upprepar implementationens egen beräkning utan ett oberoende förväntat resultat kan godkännas medan både implementation och test missförstår enheten. Kontrollera några fall för hand och behåll resonemanget.

För mintflöden ska obehöriga plånböcker och förbrukade tilldelningar ingå som normala negativa utfall. Automation bör respektera publicerade villkor snarare än behandla avvisning som en utmaning att kringgå. Policydiskussionen i NFT-vitlistning för vinst hjälper till att skilja behörighet från den orelaterade frågan om en tillåten mintning har attraktiv ekonomi.

Repetera slutligen processavbrott och återhämtning. Stoppa efter avsiktsregistrering, efter signaturförberedelse och efter inskickande. Det omstartade systemet bör förklara vad som är känt vid varje gräns och undvika att hitta på ett nytt köp för att undanröja osäkerhet. En demonstration enbart från ren start testar inte tillstånden som orsakar många driftfel.

Validera konfiguration lika omsorgsfullt som marknadsdata

Konfiguration är ytterligare en indatagräns. En felskriven kedjeidentifierare, felaktigt decimalantal eller saknad maximal budget kan ändra varje efterföljande beslut medan koden fortsätter köra normalt. Kontrollera nödvändiga inställningar innan arbetsprocesser startas och avvisa en konfiguration som inte kan förklara sina enheter eller tillåtna vägar. Standardvärden bör väljas avsiktligt, särskilt där utelämnande annars kan betyda obegränsade utgifter.

Behåll en versionshanterad beskrivning av konfigurationen som användes för varje beslut utan att kopiera hemligheter till posten. En operatör som utreder ett köp behöver veta om gällande tak var 100 eller 120 enheter, inte bara vad inställningen säger i dag. En senare ändring bör inte skriva om förklaringen till en tidigare åtgärd.

Att ändra en gräns kräver också en regel för befintliga åtaganden. Sänkning av ett kampanjtak under aktuell exponering bör förhindra ytterligare åtaganden och utlösa granskning; den kan inte retroaktivt återföra köp. Höjning av ett tak bör kräva samma uttryckliga befogenhet som ursprungsuppdraget. En konfigurationsomläsning är en bekväm leveransmekanism för ett beslut, inte självständig behörighet att ändra strategin. Testa övergångarna tillsammans med vanlig startvalidering.

Håll en NFT-bot i Python underhållbar

Externa API:er, beroenden och marknadsplatsvägar förändras. Registrera vilka versioner och svarsantaganden en utgåva testades mot. Granska uppdateringar i en kontrollerad miljö innan de får samma befogenhet som den tidigare granskade versionen. En lyckad installation säger lite om huruvida ett ändrat beroende bevarar avsett beteende.

Håll rapporter begripliga för någon som inte skrev koden. Varje åtgärd bör visa sitt skäl, tillåtet belopp, observerat utfall och olösta frågor. Resultatanalys bör inkludera misslyckade försök och osålt innehav, medan teknikrapporter bör visa schemafel, återhämtningsluckor och avvisade begäranden. Det är relaterade men skilda vyer av systemet.

Den mest användbara arkitekturen gör ett misstag litet och möjligt att diagnostisera. Exakta enheter förhindrar tvetydiga utgifter, uttryckliga gränser begränsar befogenhet och beständiga poster stödjer återhämtning. Python ger användbara verktyg för att genomföra idéerna, men botens kvalitet kommer från tydligheten i de beslut som verktygen ombeds upprätthålla.