NFT-bot i Python: bygg rundt data og fullmakt

Gi NFT-boten i Python tydelige komponentgrenser

Del arbeidet i en observasjonsadapter, et lager for normaliserte oppføringer, en regelvurderer, en utførelseskoordinator og et begrenset signeringsgrensesnitt. Disse kan begynne som moduler i ett prosjekt; de trenger ikke bli fem separate tjenester. Verdien ligger i å gjøre oppgavene tydelige nok til å teste og resonnere om uavhengig.

Observasjonsadapteren forstår et eksternt APIs svarform og feil. Den bør ikke avgjøre at et token er verdt å kjøpe. Regelvurdereren forstår samlingskriterier og forbruksgrenser. Den bør ikke hente en annen pris i det stille hvis oppgitt observasjon bryter reglene. Utførelseskoordinatoren styrer autoriserte handlinger og uavklarte tilstander, mens signereren kontrollerer nøyaktig fullmakt som forespørres.

Hver grense trenger definerte inndata og utdata. En oppføringspost kan inneholde aktivaidentitet, ordreidentitet, prisenheter, betalingstokenidentitet, observasjonstid og valideringsstatus. En beslutning legger til regelversjon, grunn og maksimalt autorisert forbruk. En transaksjonsforespørsel viser tilbake til beslutningen og bevarer dokumentasjonskjeden fra data til handling.

Oppføringene gjør uenighet synlig. Hvis observasjonsadapteren rapporterer en tokenpris i én valuta og reglene forventer en annen, bør inndataene avvises i validering. Automatisk erstatning med et kjent valutasymbol ville skjule nettopp faktumet systemet må undersøke. En liten uttrykkelig feil er å foretrekke fremfor en stor skjult antakelse.

Behandle identitet som strukturerte data

En NFTs visningsnavn er nyttig for en person, men er en dårlig databasenøkkel. For et vanlig EVM-aktivum registreres kjede, kontraktadresse, tokenidentifikator og standard. Ta med mengde der det passer. Samme identifikator under en annen kontrakt er et annet aktivum, og samme kontraktlignende adresse på en annen kjede tilhører en annen nettverkskontekst.

Ordreidentitet er separat fra aktivaidentitet. Et token kan oppføres mer enn én gang over tid, og en selger kan erstatte én ordre med en annen. Duplikatfjerning bare etter tokenidentifikator kan forkaste en reell prisendring eller forveksle en utløpt ordre med erstatningen. Bevar protokoll og ordreidentifikator sammen med gjenstandsoppføringen.

Bruk strenger eller heltall med passende størrelse til identifikatorer uten å anta at ethvert senere system trygt kan representere dem som vanlige flyttall. En stor numerisk tokenidentifikator kan overleve Pythons heltallshåndtering og deretter miste presisjon når den sendes til en annen komponent som behandler den som en binær flyttallsverdi. Serialisering er del av arkitekturen, ikke bare presentasjon.

OpenSeas veiledning om gjennomgang av en gjenstandsside gir nyttig identitetskontekst for menneskelige kontroller. Programmet bør beholde underliggende identifikatorer som lar operatøren skille et ekte samlingsaktivum fra en urelatert gjenstand med lignende kunstverk eller navn.

Bruk heltallshåndtering av tokenbeløp ved grensen

Tokenbeløp krever både tall og enhet. Et råbeløp på én million betyr noe annet for et token med seks desimaler enn for et med atten. Lagre råheltallet, tokenidentiteten og bekreftet desimalkonvensjon sammen. Et tall uten enhet bør ikke inngå i en forbruksbeslutning.

For et hypotetisk betalingstoken med seks desimaler tilsvarer 12,345678 enheter 12 345 678 grunnenheter. Tre gjenstander priset til 4,125000 enheter hver blir totalt 12,375000 enheter, eller 12 375 000 grunnenheter. En regelgrense på 12,300000 enheter mangler derfor 75 000 grunnenheter, tilsvarende 0,075000 enheter. Sammenligningen bør være eksakt selv om grensesnittet avrunder begge tall for visning.

Python-heltall passer for eksakte grunnenhetsbeløp. Desimalregning kan hjelpe med menneskeangitte priser, forholdstall og rapporter, forutsatt passende tolking av inndata og uttrykkelige presisjons- og avrundingsregler. Opprettelse av en desimalverdi fra et allerede tilnærmet binært flyttall gjenoppretter ikke opprinnelig tiltenkt desimalinndata. Foretrekk opprinnelig tallstreng når det er kilderepresentasjonen.

Ikke avrund et brukerbeløp med for mange desimaler til en gjennomførbar mengde i det stille. Avgjør om det skal avvises eller om en tydelig dokumentert avrundingsregel skal brukes før autorisering. Avrunding av en maksimalpris oppover kan overskride brukerens grense, mens avrunding av et beløp nødvendig for oppgjør nedover kan få transaksjonen til å mislykkes. Korrekt atferd avhenger av beløpets rolle.

Hold pris, gebyrer og gas i egne enheter

Et kjøp kan bruke et ERC-20-betalingstoken og kjedens eget ETH til gas. Dette er separate saldoer og separate autoriseringskontroller. En samlet rapporteringsverdi er nyttig først etter at omregningsforutsetningene er angitt. Programmet bør ikke legge 0,02 ETH i gas direkte til 100 enheter av et annet token og kalle resultatet 100,02 enheter.

Vurder en Ethereum-transaksjon med gasgrense på 150 000 og maksimal gaspris på 40 gwei. Maksimal gasramme er 0,006 ETH. Hvis transaksjonen faktisk bruker 110 000 gas til en effektiv pris på 25 gwei, er utførelseskostnaden 0,00275 ETH. Tallene illustrerer skillet mellom en ramme reservert før innsending og en kostnad avstemt etterpå.

Ethereums gasdokumentasjon forklarer underliggende enheter. En implementasjon bør også ta hensyn til faktisk transaksjonstype og forløp fremfor å anta at én formel dekker ethvert nettverk eller ethvert tilleggsgebyr. Kvitteringen og gjennomførte betalingsstrømmer bestemmer realiserte utgifter; et anslag er ikke en endelig regnskapsoppføring.

Bruk uttrykkelige navn som betalingsbeløp, maksimal nettverksramme og realisert nettverkskostnad. Tvetydige felt kalt gebyr eller total oppmuntrer dobbelttelling når ett API-svar allerede inkluderer en komponent en annen rapport legger til igjen. En transaksjonskoordinator bør kunne forklare opphav og enhet for hvert beløp den reserverer.

Normaliser eksterne data uten å finne på manglende fakta

En API-adapter bør skille et fraværende felt fra et felt der null er gyldig verdi. En manglende pris betyr ikke en gratis oppføring. Et utilgjengelig eierfelt betyr ikke at ingen eier tokenet. Et tomt svar kan bety ingen samsvarende oppføringer, men en autentiseringsfeil eller en forespørsel med tidsavbrudd fastslår ikke at samlingen mangler oppføringer.

Valider forventede strukturer og avvis uventede med en nyttig grunn. Behold nok av opprinnelig offentlig svar, eller en trygg referanse til det, til å diagnostisere skjemaendringer. Unngå å logge autentiseringshoder eller hemmelig konfigurasjon samtidig som vanlige identifikatorer og tidsstempler bevares. Feilsøking bør ikke kreve eksponering av fullmakten brukt for tilgang til tjenesten.

Sideinndeling krever tilsvarende omtanke. Følg dokumentert fortsettelsesmekanisme og behold fremdrift ved behandling av store samlinger. Ikke anta at første side representerer hele gjeldende beholdning. Hvis oppføringer kan endres mens sider leses, behandles resultatet som observasjoner over et intervall, og duplikater eller endringer avstemmes fremfor å hevde et øyeblikkelig bilde uten dokumentasjon.

API-innpakningen bør rapportere det den vet. Et transporttidsavbrudd er et transporttidsavbrudd, ikke en selgerkansellering. Et feilformet svar er en tolkerfeil, ikke et negativt handelssignal. Presise feilkategorier hindrer at regler handler på en historie dataene aldri fortalte.

Håndter hendelser som observasjoner, ikke kommandoer

En oppføringshendelse bør utløse vurdering, ikke umiddelbart kjøp bare fordi den kom. Den kan være duplisert, forsinket eller erstattet av en annen hendelse. Arbeidsprosessen bør normalisere identitet, registrere tid, sammenligne med eksisterende tilstand og avgjøre om fersk validering trengs før forbruksfullmakt forespørres.

OpenSeas Stream API-dokumentasjon beskriver levering etter beste evne og mulige hendelser ute av rekkefølge. Ny tilkobling trenger derfor en avstemmingsvei som kan oppdage endringer oversett under avbruddet. Nøyaktig gjenopprettingsutforming avhenger av oppføringene strategien trenger, men bør ikke anta at hendelsesstrømmen er et fullstendig, permanent regnskap.

Hold duplikatundertrykking separat fra ferskhet. To kopier av samme hendelse bør ikke gi to handlinger. To forskjellige observasjoner om samme token kan begge bety noe fordi én endrer ordretilstanden. En for bred nøkkel for duplikatfjerning kan være like skadelig som ingen fjerning hvis den undertrykker legitime oppdateringer.

En enkel øvelse kan levere samme observasjon to ganger og deretter levere en kansellering med en tidligere plass i ankomstrekkefølgen, men et relevant hendelsestidsstempel. Forventet resultat er én kandidatoppføring med sporbar tilstandshistorikk, ikke to kjøp eller en blindt betrodd sist ankommet melding. Definer forventningene før programmet kobles til reell fullmakt.

Samordne samtidige beslutninger gjennom delte grenser

Python-programmer bruker ofte asynkrone oppgaver til å håndtere flere nettverksforespørsler uten å vente på hver etter tur. Det kan forbedre responstid, men innfører spørsmål om delt tilstand. To kandidatvurderinger kan begge se samme tilgjengelige budsjett før noen registrerer reservasjonen. Raskere behandling gjør ikke kappløpet mindre betydningsfullt.

Anta at en kampanje har 600 betalingstokenenheter tilgjengelig og to arbeidsprosesser hver foreslår et kjøp på 400 enheter. Hvert forslag passer alene, men sammen krever de 800 enheter. Koordinatoren må autorisere høyst ett under budsjettet. Det andre bør se de gjenværende 200 enhetene og feile eller vente etter reglene.

En asynkron lås i prosessen kan samordne samarbeidende oppgaver i én prosess. Den samordner ikke automatisk separate prosesser, andre datamaskiner eller et manuelt kjøp fra samme lommebok. Et varig delt regnskap og en passende transaksjonell oppdatering trengs når fullmakten er bredere fordelt. Angi grensen valgt synkroniseringsmekanisme faktisk beskytter.

Begrens også antall utestående forespørsler. Ubegrenset samtidighet kan skape en voksende kø av utdaterte kandidater, overbelaste eksterne tjenester og gjøre gjenoppretting vanskeligere å følge. Respekter dokumenterte grenser og bruk bevisst økende ventetid etter feil som kan forsøkes på nytt. Målet er gjeldende, forklarlige beslutninger, ikke flest mulig samtidige forespørsler.

Bevar hensikt før en signatur forespørres

Før en signatur forespørres, lagres en varig hensiktsoppføring med godkjent aktivum, forløp, valuta, maksimale beløp, mottaker, regelversjon og relevant utløp. Gi hensikten en identifikator brukt gjennom arbeidsflyten. Signereren bør få nok strukturert informasjon til å bekrefte forespørselen mot oppføringen, fremfor en uforklart datablokk fulgt av en beroligende etikett.

API-tilgangsopplysninger og lommebokens signeringsfullmakt er forskjellige hemmeligheter med forskjellige krefter. En datatjeneste kan trenge en nøkkel til å lese tillatte oppføringer uten grunn til tilgang til en lommebokhemmelighet. Å holde kreftene adskilt reduserer antall komponenter som kan autorisere transaksjoner og gjør utilsiktet hemmelighetseksponering lettere å begrense.

Signeringsgrensesnittet bør avvise en annen kjede, mottaker, kontrakt eller et annet beløp selv når kalleren sier forespørselen tilhører et godkjent kjøp. Godkjenningen gjelder en bestemt handling innen grenser, ikke vilkårlige byte produsert av en arbeidsprosess. Hvis forløpet endres vesentlig, hentes en ny regelbeslutning fremfor å strekke den gamle.

Før kode til dette laget lånes, brukes gjennomgangstilnærmingen i vurdering av en NFT-bot fra GitHub. Et kjent kodelagernavn eller en fungerende demonstrasjon viser ikke hvor avhengighetene sender data eller hvor stor fullmakt transaksjonsbyggeren kan be om.

Utform transaksjonsgjenoppretting i Python uttrykkelig

Det farlige øyeblikket er ofte mellom innsending og lokal bekreftelse. En nettverkstjeneste kan godta en transaksjon mens kalleren får tidsavbrudd før returnert resultat lagres. Et generelt nytt forsøk kan skape en ekstra handling mens opprinnelig handling fortsatt venter. Gjenoppretting må undersøke opprinnelig hensikt og transaksjonsidentifikatorer først.

Bruk tilstander som bevarer usikkerhet: klargjort, godkjent, innsendt, ventende, bekreftet, mislykket og uavklart er mulige eksempler. De nøyaktige navnene betyr mindre enn dokumentasjonskravene. Et vellykket HTTP-svar er ikke det samme som bekreftet eierskap, og et manglende svar er ikke bevis på at transaksjonen mislyktes.

Ved omstart avstemmes ufullførte hensikter før nye kandidater behandles. Behold budsjettreservasjonene til utfallet begrunner endring. Hvis eierskap bekreftes, registreres faktisk aktivamengde og kostnad. Hvis feil fastslås, regnskapsføres nettverksutgifter før resten frigis. Hvis utfallet ennå ikke kan fastslås, beholdes uavklart tilstand og vises til operatøren.

Minting trenger ytterligere skiller fordi aktivumet kanskje ikke finnes før transaksjonen. En arbeidsflyt for automatisert NFT-minting bør knytte autorisert mintmengde til identifikatorene som faktisk opprettes og mottas. Den bør ikke finne på forventede tokenidentifikatorer bare fordi kontrakten ofte ser ut til å utstede dem sekvensielt.

Test beslutninger med lagrede tilfeller

Bygg en liten samling offentlige, rensede eksempler og forventede beslutninger. Ta med en gyldig oppføring, en gjenstand på feil kjede, en manglende pris, en forespørsel over budsjett, en duplisert hendelse og et ukjent transaksjonsresultat. Tilfellene tester meningsfull atferd ved grenser der feil kan endre forbruk eller beholdning.

Test heltallsomregninger med verdier like under, nøyaktig på og like over en grense. Ta med tokener med forskjellige desimalkonvensjoner. En test som gjentar implementasjonens egen beregning uten et uavhengig forventet resultat, kan bestå mens både implementasjon og test misforstår enheten. Kontroller noen tilfeller for hånd og behold resonnementet.

For mintarbeidsflyter tas ukvalifiserte lommebøker og oppbrukte tildelinger med som normale negative utfall. Automatisering bør respektere publiserte vilkår fremfor å behandle avvisning som en utfordring som skal omgås. Regeldrøftingen i NFT-tillatelseslister for fortjeneste bidrar til å skille kvalifikasjon fra det urelaterte spørsmålet om tillatt minting har attraktiv økonomi.

Øv til slutt på prosessavbrudd og gjenoppretting. Stopp etter hensiktsregistrering, etter signaturforberedelse og etter innsending. Det omstartede systemet bør forklare hva som er kjent ved hver grense og unngå å finne på et nytt kjøp for å fjerne usikkerhet. En demonstrasjon bare fra ren oppstart tester ikke tilstandene som skaper mange driftsfeil.

Valider konfigurasjon like grundig som markedsdata

Konfigurasjon er en annen inndatagrense. En feilskrevet kjedeidentifikator, feil desimalantall eller et manglende maksimumsbudsjett kan endre hver senere beslutning mens koden fortsetter å kjøre normalt. Kontroller påkrevde innstillinger før arbeidsprosesser startes og avvis konfigurasjon som ikke kan forklare enheter eller tillatte forløp. Standardverdier bør velges bevisst, særlig der utelatelse ellers kunne bety ubegrenset forbruk.

Behold en versjonert beskrivelse av konfigurasjonen brukt for hver beslutning uten å kopiere hemmeligheter inn i oppføringen. En operatør som undersøker et kjøp må vite om aktuelt tak var 100 eller 120 enheter, ikke bare hva innstillingen sier i dag. En senere redigering bør ikke skrive om forklaringen til en tidligere handling.

Endring av en grense krever også en regel for eksisterende forpliktelser. Reduksjon av kampanjetaket under gjeldende eksponering bør hindre ytterligere forpliktelser og utløse gjennomgang; den kan ikke reversere kjøp i ettertid. Økning av et tak bør kreve samme uttrykkelige fullmakt som opprinnelig oppdrag. En konfigurasjonsoppdatering er en praktisk leveringsmekanisme for en beslutning, ikke uavhengig tillatelse til å endre strategien. Test overgangene sammen med vanlig oppstartsvalidering.

Hold NFT-boten i Python vedlikeholdbar

Eksterne API-er, avhengigheter og markedsplassforløp endres. Registrer hvilke versjoner og svarantakelser en utgave ble testet mot. Gjennomgå oppdateringer i et kontrollert miljø før de får samme fullmakt som tidligere gjennomgått versjon. En vellykket installasjon sier lite om en endret avhengighet bevarer tiltenkt atferd.

Hold rapporter forståelige for noen som ikke skrev koden. Hver handling bør vise grunn, autorisert beløp, observert utfall og uavklarte spørsmål. Resultatanalyse bør inkludere mislykkede forsøk og usolgt beholdning, mens tekniske rapporter bør vise skjemafeil, gjenopprettingshull og avviste forespørsler. Dette er beslektede, men separate systemvisninger.

Den nyttigste arkitekturen er en som gjør en feil liten og mulig å diagnostisere. Eksakte enheter hindrer tvetydig forbruk, uttrykkelige grenser begrenser fullmakt og varige oppføringer støtter gjenoppretting. Python gir nyttige verktøy til å gjennomføre ideene, men botens kvalitet kommer fra tydeligheten i beslutningene verktøyene bes håndheve.