Bot de NFT em Python: construa em torno dos dados e da autoridade

Dê a um bot de NFT em Python fronteiras claras entre componentes

Separe o trabalho num adaptador de observação, um armazenamento de registos normalizados, um avaliador de políticas, um coordenador de execução e uma interface restrita de assinatura. Podem começar como módulos de um projeto; não precisam de se tornar cinco serviços separados. O valor vem de tornar as suas responsabilidades suficientemente explícitas para as testar e analisar de forma independente.

O adaptador de observação compreende a estrutura de respostas e os erros de uma API externa. Não deve decidir que vale a pena comprar um token. O avaliador de políticas compreende critérios de coleções e limites de despesa. Não deve obter discretamente outro preço se a observação fornecida falhar as suas regras. O coordenador de execução gere ações autorizadas e os seus estados por resolver, enquanto o assinante verifica a autoridade exata pedida.

Cada fronteira precisa de dados de entrada e saída definidos. Um registo de listagem pode conter identidade do ativo, identidade da ordem, unidades de preço, identidade do token de pagamento, hora de observação e estado de validação. Uma decisão acrescenta a versão da política, o motivo e a despesa máxima autorizada. Um pedido de transação remete para essa decisão, preservando a cadeia de provas dos dados à ação.

Estes registos tornam visíveis as divergências. Se o adaptador de observação apresentar o preço de um token numa moeda e a política esperar outra, os dados de entrada devem falhar a validação. Substituir automaticamente por um símbolo familiar de moeda ocultaria precisamente o facto que o sistema precisa de examinar. Um pequeno erro explícito é preferível a um grande pressuposto silencioso.

Trate a identidade como dados estruturados

O nome apresentado de um NFT é útil para uma pessoa, mas é uma má chave de base de dados. Para um ativo EVM normal, registe a cadeia, o endereço do contrato, o identificador de token e a norma. Inclua quantidade quando adequado. O mesmo identificador sob outro contrato é outro ativo, e o mesmo endereço com aspeto de contrato noutra cadeia pertence a outro contexto de rede.

A identidade da ordem é separada da identidade do ativo. Um token pode ser listado mais de uma vez ao longo do tempo, e um vendedor pode substituir uma ordem por outra. Eliminar duplicados apenas pelo identificador do token pode descartar uma mudança genuína de preço ou confundir uma ordem expirada com a sua substituição. Preserve o protocolo e o identificador da ordem junto do registo do item.

Use cadeias de texto ou inteiros com dimensão adequada para identificadores, sem presumir que todos os sistemas seguintes os conseguem representar com segurança como números normais de vírgula flutuante. Um identificador numérico grande de token pode sobreviver ao tratamento de inteiros de Python e depois perder precisão quando enviado a outro componente que o trata como um valor binário de vírgula flutuante. A serialização faz parte da arquitetura, não é apenas apresentação.

As orientações da OpenSea sobre analisar uma página de item fornecem contexto útil de identidade para verificações humanas. O programa deve reter os identificadores subjacentes que permitem ao operador distinguir um ativo genuíno da coleção de um item sem relação com imagem ou nome semelhantes.

Use tratamento de montantes inteiros de tokens na fronteira

Os montantes de tokens exigem tanto um número como uma unidade. Um montante bruto de um milhão significa algo diferente num token com seis casas decimais e num com dezoito. Guarde juntos o inteiro bruto, a identidade do token e a convenção verificada de casas decimais. Um número sem unidade não deve entrar numa decisão de despesa.

Para um token hipotético de pagamento com seis casas decimais, 12,345678 unidades correspondem a 12 345 678 unidades base. Três itens a 4,125000 unidades cada totalizam 12,375000 unidades, ou 12 375 000 unidades base. Um limite de política de 12,300000 unidades fica, por isso, aquém em 75 000 unidades base, equivalentes a 0,075000 unidades. A comparação deve ser exata, mesmo que a interface arredonde ambos os valores para apresentação.

Os inteiros de Python são adequados para montantes exatos em unidades base. A aritmética decimal pode ajudar com preços introduzidos por pessoas, rácios e relatórios, desde que os dados sejam interpretados adequadamente e as regras de precisão e arredondamento sejam explícitas. Construir um valor decimal a partir de um número binário de vírgula flutuante já aproximado não recupera o dado decimal original pretendido. Prefira a cadeia numérica original quando essa for a representação da fonte.

Não arredonde silenciosamente um montante do utilizador com demasiadas casas decimais para uma quantidade executável. Decida se o rejeita ou aplica uma regra de arredondamento claramente documentada antes de autorizar. Arredondar um preço máximo para cima pode exceder o limite do utilizador, enquanto arredondar para baixo um montante necessário para liquidação pode fazer a transação falhar. O comportamento correto depende do papel do montante.

Mantenha preço, comissões e gas nas suas próprias unidades

Uma compra pode envolver um token de pagamento ERC-20 e ETH nativo para gas. São saldos separados e verificações separadas de autorização. Um valor combinado de relato só é útil depois de indicar os pressupostos de conversão. O programa não deve somar diretamente 0,02 ETH de gas a 100 unidades de outro token e chamar ao resultado 100,02 unidades.

Considere uma transação Ethereum com limite de gas de 150 000 e preço máximo de gas de 40 gwei. O montante máximo permitido para gas é 0,006 ETH. Se a transação usar efetivamente 110 000 unidades de gas a um preço efetivo de 25 gwei, o encargo de execução é 0,00275 ETH. Estes valores ilustram a distinção entre um montante permitido reservado antes da submissão e um custo conciliado depois.

A documentação de gas da Ethereum explica as unidades subjacentes. Uma implementação também deve ter em conta o tipo e a rota efetivos da transação, em vez de presumir que uma fórmula cobre todas as redes ou todas as comissões adicionais. O comprovativo e os fluxos executados de pagamento determinam despesas realizadas; uma estimativa não é um registo contabilístico final.

Use nomes explícitos como montante de pagamento, montante máximo permitido para rede e custo realizado de rede. Campos ambíguos chamados comissão ou total incentivam dupla contagem quando uma resposta de API já inclui um componente que outro relatório volta a somar. Um coordenador de transações deve conseguir explicar a origem e a unidade de todos os montantes que reserva.

Normalize dados externos sem inventar factos em falta

Um adaptador de API deve distinguir um campo ausente de um campo cujo valor válido é zero. Um preço em falta não significa uma listagem gratuita. Um campo de proprietário indisponível não significa que ninguém detenha o token. Uma resposta vazia pode significar ausência de registos correspondentes, mas uma falha de autenticação ou um pedido que excedeu o tempo de espera não estabelecem que a coleção não tem listagens.

Valide as estruturas esperadas e rejeite as inesperadas com um motivo útil. Guarde o suficiente da resposta pública original, ou uma referência segura à mesma, para diagnosticar mudanças do esquema. Evite registar cabeçalhos de autenticação ou configuração secreta enquanto preserva identificadores e marcas temporais normais. A depuração não deve exigir expor a autoridade usada para aceder ao serviço.

A paginação exige cuidado semelhante. Siga o mecanismo documentado de continuação e retenha o progresso ao processar coleções grandes. Não presuma que a primeira página representa todo o inventário atual. Se os registos puderem mudar enquanto se leem páginas, trate o resultado como observações ao longo de um intervalo e concilie duplicados ou mudanças, em vez de alegar um retrato instantâneo sem provas.

A camada de acesso à API deve comunicar o que sabe. Um tempo de espera de transporte esgotado é um tempo de espera de transporte esgotado, não um cancelamento do vendedor. Uma resposta malformada é uma falha do analisador, não um sinal negativo de negociação. Manter precisas as categorias de erro impede uma política de agir sobre uma história que os dados nunca contaram.

Trate eventos como observações, não como comandos

Um evento de listagem deve desencadear avaliação, não uma compra imediata apenas por ter chegado. Pode ser duplicado, atrasado ou substituído por outro evento. O processo deve normalizar a sua identidade, registar o seu momento, compará-lo com o estado existente e decidir se é necessária nova validação antes de pedir qualquer autoridade de despesa.

A documentação da Stream API da OpenSea descreve entrega na medida do possível e possíveis eventos fora de ordem. Uma nova ligação precisa, por isso, de uma via de conciliação que consiga descobrir mudanças perdidas durante a lacuna. A conceção exata de recuperação depende dos registos de que a estratégia precisa, mas não deve presumir que o fluxo de eventos é um registo contabilístico completo e permanente.

Mantenha a supressão de duplicados separada da atualidade. Duas cópias do mesmo evento não devem causar duas ações. Duas observações diferentes sobre o mesmo token podem ambas importar porque uma muda o estado da ordem. Uma chave demasiado abrangente de eliminação de duplicados pode ser tão prejudicial como não eliminar duplicados se suprimir atualizações legítimas.

Um ensaio simples pode entregar a mesma observação duas vezes e depois entregar um cancelamento com uma ordem de chegada anterior, mas uma marca temporal de evento relevante. O resultado esperado é um registo de candidato com um histórico rastreável de estado, não duas compras ou uma mensagem que chegou por último e é cegamente aceite. Defina essas expectativas antes de ligar o programa a autoridade real.

Coordene decisões concorrentes através de limites partilhados

Os programas Python usam frequentemente tarefas assíncronas para tratar vários pedidos de rede sem esperar por cada um sequencialmente. Isso pode melhorar a capacidade de resposta, mas introduz questões de estado partilhado. Duas avaliações de candidatos podem ver o mesmo orçamento disponível antes de qualquer uma registar a sua reserva. Processar mais depressa não torna essa corrida menos importante.

Suponha que uma campanha tem 600 unidades de tokens de pagamento disponíveis e dois processos propõem cada um uma compra de 400 unidades. Cada proposta cabe quando examinada isoladamente, mas juntas exigem 800 unidades. O coordenador tem de autorizar no máximo uma segundo esse orçamento. A outra deve ver as 200 unidades restantes e falhar ou esperar segundo a política.

Um bloqueio assíncrono dentro do processo pode coordenar tarefas cooperantes num processo. Não coordena automaticamente processos separados, outros computadores ou uma compra manual da mesma carteira. É necessário um registo partilhado persistente e uma atualização transacional adequada quando a autoridade é distribuída mais amplamente. Indique a fronteira que o mecanismo escolhido de sincronização efetivamente protege.

Limite também o número de pedidos pendentes. Concorrência ilimitada pode criar uma fila crescente de candidatos desatualizados, sobrecarregar serviços externos e tornar a recuperação mais difícil de acompanhar. Respeite os limites documentados e aplique espera progressiva deliberada após falhas que permitem nova tentativa. O objetivo são decisões atuais e explicáveis, não o maior número possível de pedidos simultâneos.

Preserve a intenção antes de pedir uma assinatura

Antes de pedir uma assinatura, guarde um registo persistente de intenção que contenha o ativo, a rota, a moeda, os montantes máximos, o destinatário, a versão da política e a expiração relevante aprovados. Dê a essa intenção um identificador usado ao longo do processo. O assinante deve receber informação estruturada suficiente para verificar o pedido face a esse registo, em vez de um bloco de dados inexplicado acompanhado de um rótulo tranquilizador.

Credenciais de API e autoridade de assinatura da carteira são segredos diferentes com poderes diferentes. Um serviço de dados pode precisar de uma chave para ler registos permitidos sem ter razão para aceder a um segredo da carteira. Manter estes poderes separados reduz o número de componentes que podem autorizar transações e facilita conter uma exposição acidental de segredos.

A interface de assinatura deve rejeitar uma cadeia, destinatário, contrato ou montante diferentes, mesmo quando quem faz o pedido diz que pertence a uma compra aprovada. A aprovação diz respeito a uma ação específica dentro de limites, não a bytes arbitrários produzidos por um processo. Se a rota mudar significativamente, obtenha uma nova decisão da política em vez de esticar a antiga.

Antes de aproveitar código para esta camada, use a abordagem de análise em avaliar um bot de NFT do GitHub. Um nome familiar de repositório ou uma demonstração funcional não mostram para onde as suas dependências enviam dados ou quanta autoridade o construtor de transações pode pedir.

Conceba explicitamente a recuperação de transações de NFT em Python

O momento perigoso é frequentemente entre a submissão e a confirmação local de receção. Um serviço de rede pode aceitar uma transação enquanto quem faz o pedido excede o tempo de espera antes de guardar o resultado devolvido. Uma repetição genérica pode criar uma ação adicional quando a original ainda está pendente. A recuperação precisa de investigar primeiro a intenção original e os identificadores de transação.

Use estados que preservem a incerteza: preparado, aprovado, submetido, pendente, confirmado, falhado e por resolver são exemplos possíveis. Os nomes exatos importam menos do que os seus requisitos de provas. Uma resposta HTTP bem-sucedida não é o mesmo que propriedade confirmada, e uma resposta em falta não prova que a transação falhou.

Ao reiniciar, concilie intenções inacabadas antes de processar novos candidatos. Mantenha as suas reservas orçamentais até o resultado justificar uma mudança. Se a propriedade for confirmada, registe a quantidade e o custo efetivos do ativo. Se a falha for estabelecida, contabilize qualquer despesa de rede antes de libertar o remanescente. Se ainda não for possível estabelecer o resultado, retenha o estado por resolver e apresente-o ao operador.

A criação de NFT precisa de distinções adicionais porque o ativo pode não existir antes da transação. Um processo de criação automatizada de NFT deve ligar a quantidade autorizada de criação aos identificadores efetivamente criados e recebidos. Não deve inventar identificadores esperados de tokens apenas porque o contrato parece frequentemente emiti-los sequencialmente.

Teste decisões com casos guardados

Construa uma pequena coleção de exemplos públicos sem dados sensíveis e decisões esperadas. Inclua uma listagem válida, um item da cadeia errada, um preço em falta, um pedido acima do orçamento, um evento duplicado e um resultado desconhecido de transação. Estes casos testam comportamento significativo em fronteiras onde erros podem alterar despesas ou inventário.

Teste conversões de inteiros com valores imediatamente abaixo, exatamente no limite e imediatamente acima dele. Inclua tokens com convenções diferentes de casas decimais. Um teste que repete o próprio cálculo da implementação sem um resultado esperado independente pode passar enquanto tanto a implementação como o teste interpretam mal a unidade. Verifique manualmente alguns casos e retenha o seu raciocínio.

Para processos de criação de NFT, inclua carteiras não elegíveis e atribuições esgotadas como resultados negativos normais. A automatização deve respeitar as condições publicadas, em vez de tratar uma rejeição como desafio a contornar. A discussão de política em listas de permissões de NFT para lucro ajuda a separar elegibilidade da pergunta distinta de saber se uma criação permitida tem uma economia atrativa.

Por fim, ensaie a interrupção e a recuperação do processo. Pare após registar a intenção, após preparar a assinatura e após a submissão. O sistema reiniciado deve explicar o que é conhecido em cada fronteira e evitar inventar uma nova compra para eliminar a incerteza. Uma demonstração que começa sem estado anterior, por si só, não testa os estados que causam muitos erros operacionais.

Valide a configuração com tanto cuidado como os dados de mercado

A configuração é outra fronteira de entrada. Um identificador de cadeia mal escrito, uma contagem incorreta de casas decimais ou um orçamento máximo em falta podem mudar todas as decisões subsequentes enquanto o código continua a funcionar normalmente. Verifique as definições necessárias antes de iniciar processos e rejeite uma configuração que não consiga explicar as suas unidades ou rotas permitidas. Os valores predefinidos devem ser escolhidos deliberadamente, especialmente quando uma omissão poderia significar despesa ilimitada.

Mantenha uma descrição com versões da configuração usada para cada decisão sem copiar segredos para esse registo. Um operador que investiga uma compra precisa de saber se o limite aplicável era 100 ou 120 unidades, não apenas o que a definição diz hoje. Uma edição posterior não deve reescrever a explicação de uma ação anterior.

Mudar um limite também exige uma regra para compromissos existentes. Reduzir um limite de campanha abaixo da exposição atual deve impedir compromissos adicionais e desencadear análise; não pode reverter retroativamente compras. Aumentar um limite deve exigir a mesma autoridade explícita da tarefa original. Recarregar a configuração é um mecanismo conveniente de entrega de uma decisão, não uma permissão independente para mudar a estratégia. Teste estas transições juntamente com a validação normal de arranque.

Mantenha um bot de NFT em Python fácil de manter

As API externas, as dependências e as rotas de mercados mudam. Registe que versões e pressupostos de resposta foram usados para testar uma versão publicada. Analise atualizações num ambiente controlado antes de lhes dar a mesma autoridade da versão anteriormente analisada. Uma instalação bem-sucedida diz pouco sobre se uma dependência alterada preserva o comportamento pretendido.

Mantenha os relatórios compreensíveis para alguém que não escreveu o código. Cada ação deve mostrar o seu motivo, montante autorizado, resultado observado e perguntas por resolver. A análise de desempenho deve incluir tentativas falhadas e inventário não vendido, enquanto os relatórios de engenharia devem expor falhas do esquema, lacunas de recuperação e pedidos rejeitados. São vistas relacionadas mas distintas do sistema.

A arquitetura mais útil é aquela que torna um erro pequeno e diagnosticável. Unidades exatas evitam despesa ambígua, fronteiras explícitas limitam a autoridade e registos persistentes suportam a recuperação. Python fornece ferramentas úteis para implementar essas ideias, mas a qualidade do bot vem da clareza das decisões que essas ferramentas são chamadas a fazer cumprir.