Um guia abrangente para a segurança da Marlowe: resultados de auditoria, restrições funcionais integradas e recursos de segurança do livro razão
Saiba mais sobre o que torna a Marlowe uma plataforma segura de desenvolvimento de contratos inteligentes
26 de junho de 2023 Fernando Sanchez 19 minutos de leitura
Isenção de responsabilidade: o conteúdo deste artigo da Marlowe Security é fornecido “COMO ESTÁ” sem garantias de qualquer tipo. Nada neste documento pretende ser um aconselhamento profissional, incluindo, sem limitação, aconselhamento financeiro, de investimento, jurídico ou fiscal. A Input Output Global não é responsável por o seu uso ou confiança em qualquer informação contida neste documento.
Introdução
Na maioria das blockchains, o contrato inteligente é um programa de computador que se autoexecuta quando certas condições predefinidas são atendidas. Na Cardano é um pouco diferente, pois a execução do smart contract acontece em uma transação enviada externamente ao nó Cardano. Mas, independentemente de como funcionam sob o capô, os contratos inteligentes são úteis para muitos setores: financeiro, imobiliário, comercial e muitos outros.
As transações usando contratos inteligentes podem envolver a movimentação e transferência de valores substanciais, que podem ser alvos valiosos para os malfeitores. Da mesma forma, esse valor pode ficar bloqueado ou ser totalmente perdido devido a falhas ou vulnerabilidades na codificação.
Evitar qualquer resultado indesejado requer a implementação de uma estrutura de segurança robusta, que envolve uma combinação de princípios de design, auditorias e práticas recomendadas por desenvolvedores, trocas e quaisquer outras partes que lidam com contratos inteligentes.
Adicionando à uma gama cada vez maior de recursos da comunidade técnica da Cardano, Marlowe é um ecossistema de ferramentas e linguagens criado pela Input Output Global (IOG) para permitir o desenvolvimento de contratos inteligentes financeiros e transacionais na blockchain Cardano.
A suíte Marlowe foi projetada e desenvolvida com foco centrado na segurança. Os criadores de Marlowe criaram limitações funcionais que garantem que os contratos sejam finitos e sempre rescindam, por exemplo. Marlowe também evita certas construções de programação para evitar resultados indesejados, por exemplo, recursão e looping. A Tweag, por sua vez conduziu uma auditoria estática e dinâmica antes da implantação de Marlowe na rede principal. O resultado de todos esses recursos de segurança, e muitos outros, é uma plataforma segura e protegida para criação e desenvolvimento de contratos inteligentes.
Este artigo investiga a segurança da Marlowe, explicando as descobertas da auditoria de segurança e como a equipe respondeu a elas , limitações funcionais integradas, ferramentas de análise de segurança incluídas na implantação e algumas precauções e considerações que devem ser tomadas ao usar a Marlowe.
Estrutura deste documento
Este documento está dividido em seis seções claramente definidas:
- Auditoria de contrato inteligente
- Ataques baseados em contratos inteligentes
- Auditoria Tweag
- Limitações funcionais de aprimoramento de segurança integradas em Marlowe
- validação da transação
- políticas monetárias
Como um todo, este documento pretende fornecer uma compreensão abrangente da importância da auditoria de contratos inteligentes e dos diferentes tipos de ataques baseados em contratos inteligentes que existem hoje, antes de aprofundar-se especificamente em como o conjunto de ferramentas Marlowe utiliza auditoria e fortes princípios de segurança para manter um ambiente de desenvolvimento de contrato inteligente seguro e protegido.
Auditoria de contrato inteligente
Visão geral
A autonomia inerente dos contratos inteligentes e as apostas relativamente altas envolvidas em certas transações significam que garantir consistência e segurança é fundamental. Isso requer saber exatamente como um contrato inteligente se comportará quando for executado, para que quaisquer falhas potenciais ou códigos maliciosos intencionais possam ser detectados e resolvidos. A auditoria de contratos inteligentes do ponto de vista da segurança é a melhor maneira de evitar falhas ou danos subsequentes. Uma auditoria examina minuciosamente o código e as condições do contrato inteligente antes da implantação, para garantir que o contrato se comporte conforme o esperado.
Métodos de auditoria
Embora as abordagens para auditoria de contratos inteligentes possam diferir e variar de projeto para projeto, os contratos inteligentes podem ser analisados usando métodos manuais ou automatizados. Normalmente, a maioria dos projetos emprega uma combinação de ambos.
Levantamento de documentação
Antes do início do processo de auditoria, os auditores podem passar algum tempo reunindo qualquer documentação relacionada ao projeto. Isso pode incluir documentos técnicos, white papers, base de código e qualquer outro material que possa ser relevante e útil no processo de auditoria.
Auditoria manual
Essa forma de auditoria de contrato inteligente envolve um grupo de pessoas analisando cada linha de código, lógica de contrato, arquitetura de contrato e quaisquer medidas de segurança integradas para garantir um design e correção eficientes. Além de revelar erros de codificação, uma auditoria manual também pode descobrir falhas de design. A auditoria manual tende a ser considerada um método muito completo e preciso.
Auditoria automatizada
Ao contrário da auditoria manual, a auditoria automatizada normalmente adota uma abordagem de teste centrada no software. Ferramentas de auditoria de software proprietárias ou disponíveis no mercado podem ajudar a detectar bugs, mas certas vulnerabilidades podem não se tornar aparentes.
Devido à natureza complementar desses métodos, as melhores práticas de auditoria envolvem uma combinação de auditoria manual e automatizada para garantir que todas as possíveis falhas, bugs e vulnerabilidades sejam detectadas e corrigidas.
Ações pós-auditoria
Uma vez concluído o processo de auditoria, o(s) auditor(es) produzirá(ão) um relatório detalhando suas constatações. Isso pode incluir a classificação de erros por gravidade e uma série de recomendações.
Os erros contratuais podem ser classificados como:
- Crítico: esse tipo de falha provavelmente impedirá o funcionamento seguro de um contrato e/ou protocolo.
- Grave: certos erros na codificação ou na lógica podem levar à perda de fundos ou a um estado descontrolado do protocolo.
- Médio: embora os fundos possam não estar em risco, esses tipos de erros podem afetar o desempenho ou a confiabilidade do contrato.
- Menor: essa classificação geralmente inclui código ineficiente com pouco ou nenhum impacto na segurança. Informativo: geralmente se refere ao estilo de codificação ou questões de práticas recomendadas.
Vantagens da auditoria de contrato inteligente
Embora a auditoria seja importante para qualquer aplicativo, ela é especialmente crucial para contratos inteligentes e aplicativos descentralizados (DApps) executados em blockchain devido à natureza imutável desses registros contábeis descentralizados.
As vantagens da auditoria de contratos inteligentes incluem identificação proativa de riscos, prevenção de erros potencialmente dispendiosos, melhoria do ambiente de desenvolvimento em geral e a obtenção de informações sobre vulnerabilidades e como eliminá-las.
Identificação proativa de riscos
A implantação de contratos inteligentes não auditados é uma aposta que nenhum desenvolvedor ou empresa deve fazer. Alguns contratos inteligentes podem envolver fundos substanciais que, se perdidos ou comprometidos, podem levar a responsabilidades ainda maiores. Ao trabalhar proativamente para remediar esses riscos, a possibilidade de algo dar muito errado é bastante diminuída.
Prevenção de erros potencialmente dispendiosos
Os fundos que ficam bloqueados para sempre devido a erros de codificação/lógica ou como resultado de interferência maliciosa em um contrato são algo que nenhum cliente ou desenvolvedor deseja experimentar. A perda financeira é apenas um lado disso. Também pode haver sérias ramificações legais.
Ter um ambiente de desenvolvimento melhor em geral
O Software de auditoria não é apenas recomendado, é um requisito. Garantir a segurança de um aplicativo ou conjunto de aplicativos e seguir as melhores práticas fortalece a oferta e cria um ambiente de desenvolvimento mais saudável.
Obtenção de insights sobre vulnerabilidades e como eliminá-las
No desenvolvimento de software, é melhor prevenir do que corrigir. E quando se trata de contratos inteligentes, não há chance de correção por causa da natureza imutável do blockchain. Uma auditoria completa fornecerá muitas informações sobre o código, a lógica do contrato, a arquitetura e muitos outros parâmetros, permitindo que os desenvolvedores refinem e produzam o melhor contrato possível.
Ataques baseados em contratos inteligentes
Ataques de reentrada
Nesse ataque, uma função de contrato inteligente cede temporariamente do controle de uma transação fazendo uma chamada para um segundo contrato, que começa a fazer chamadas de retirada recursivas para o primeiro contrato, drenando seus fundos antes que o primeiro contrato atualize seu estado. Esses tipos de ataques se tornam possíveis devido a bugs na codificação de contratos inteligentes. O evento DAO de 2016 envolveu um ataque de reentrada.
O design do blockchain Cardano torna os ataques de reentrada impossíveis. Como Cardano usa o modelo EUTXO , os contratos inteligentes são atômicos e não fazem chamadas entre si, o que torna a reentrada uma impossibilidade.
Invasões de vanguarda
Alguns designs de blockchain permitem que contratos e transações inteligentes sejam visíveis publicamente por um tempo, antes de serem confirmados na cadeia. Essas transações pendentes são compartilhadas em mempools na rede, o que permite que um adversário veja o resultado pretendido de um contrato. Tal adversário com visibilidade de transações pendentes pode introduzir uma nova negociação ou transação com o conhecimento de que, ao fazê-lo, obterá lucro com base na negociação pendente, às custas dos lucros de outros usuários. Essencialmente, um adversário manipula a ordem de execução das transações em seu próprio benefício.
Embora esse tipo de evento seja um grande problema em outras blockchains, não há evidências de que Cardano (e, por extensão, Marlowe) seja vulnerável a invasões de vanguarda.
Manipulação do oráculo
Os oráculos conectam blockchains a sistemas externos e os contratos inteligentes podem ser executados com base nos dados recebidos dos oráculos. Essa confiabilidade em sistemas externos significa que, se a entrada recebida pelo oráculo for manipulada antes de ser alimentada ao oráculo, a segurança e a integridade da execução do contrato inteligente podem ser comprometidas.
Outras vulnerabilidades comuns de segurança baseadas em contratos inteligentes incluem erros aritméticos, estouro e subfluxo de números inteiros, configurações de visibilidade de contratos inteligentes e manipulação de carimbo de data/hora.
A auditoria Tweag
Esta seção enfoca os resultados da auditoria de segurança do Tweag, a resposta da equipe da Marlowe e os princípios de segurança incorporados ao projeto da Marlowe.
Principais descobertas da auditoria de segurança Tweag e respostas internas
Tweag realizou uma auditoria manual e automatizada da linguagem Marlowe, que revelou vários problemas.
As descobertas de alta gravidade incluíram o tratamento de depósitos negativos, a prevenção de ‘dupla satisfação’, a aplicação de invariantes de estado, uma diferença de implementação entre a especificação formal versus a implementação de Plutus e a prova do teorema de preservação de dinheiro.
Tratamento de depósitos negativos
A receita de depósitos é calculada somando as entradas de depósitos, independentemente de serem negativas, enquanto a semântica os considera como depósitos zero. Combinado com a ausência de uma verificação de saldo no estado final de Marlowe, isso permite que o saldo final seja diferente do valor pago ao validador de Marlowe. Isso pode ser explorado por um contrato Marlowe que permite depósitos negativos.
Resposta interna
Esse problema foi resolvido adicionando uma proteção contra depósitos negativos no validador de semântica Marlowe. Essa proteção garante que a semântica do validador para depósitos negativos corresponda à semântica de Isabelle de Marlowe. Especificamente, um depósito de uma quantidade negativa é tratado como um depósito de zero. Assim, um depósito negativo não diminuirá nenhum dos saldos da conta no datum Plutus, e o total dos saldos internos corresponderá ao valor mantido no UTXO com o endereço do script semântico Marlowe.
Prevenção da dupla satisfação
Embora o validador Marlowe tenha impedido a dupla satisfação entre várias cópias do script do validador Marlowe em execução na mesma transação, ele não a impediu nos casos em que o validador Marlowe foi executado ao lado de outro validador Plutus na mesma transação.
Resposta interna
A dupla satisfação agora é evitada pela imposição de que o validador Marlowe é o único script Plutus que é executado durante as transações que fazem pagamentos às partes. Isso permite que os contratos Marlowe sejam coordenados com outros scripts Plutus, mas apenas sob condições em que a dupla satisfação é impossível. Alguns testes baseados em propriedades foram adicionados para verificar a correção dessa mitigação.
Aplicação de invariantes de estado
Originalmente, o validador Marlowe havia feito suposições otimistas sobre sua própria operação correta e não checou certos invariantes para reduzir os custos de execução do Plutus.
Resposta interna
O validador de semântica Marlowe agora impõe rigorosamente invariantes para estados iniciais e finais, garantindo que os três invariantes de estado de contas positivas, não duplicação de entradas de estado (contas, escolhas e valores vinculados) e um valor interno total correspondam aos UTXO do script valor.
Diferença de implementação entre a especificação formal e a implementação do Plutus
A auditoria revelou algumas diferenças entre a especificação formal e a implementação real do Plutus. Especificamente, diferenças de idioma e considerações de eficiência em relação a Isabelle, Haskell e Plutus Tx.
A especificação formal é escrita em Isabelle, uma linguagem para métodos formais, enquanto a implementação real de Marlowe é escrita em Haskell e Plutus Tx. A equipe da Marlowe trabalhou para seguir a especificação de Isabelle o mais próximo possível, mas alguns desvios eram inevitáveis devido aos diferentes linguagens. Por exemplo, alguns aspectos da implementação de Marlowe seriam ineficientes em Isabelle, então mudanças foram necessárias para uma implementação de Haskell mais eficiente.
Resposta interna
Esse problema foi mitigado por meio de análise de código e testes baseados em propriedades
Prova do teorema da preservação do dinheiro
O teorema da preservação do dinheiro levou em conta apenas a quantidade de ativos, mas não seu tipo. Isso significava que a prova não consideraria um caso em que um contrato pudesse, por exemplo, receber 20 ada e 15 djed e devolver 20 djed e 15 ada.
Resposta interna
Uma revisão do código Isabelle corrigiu esse problema. Especificamente, a adição de um novo tipo MultiAssets e a refatoração do código Isabelle (sem modificar o interpretador) para provar que os ativos são preservados.
Limitações funcionais de aprimoramento de segurança integradas em Marlowe
O Marlowe apresenta várias limitações para garantir que certos riscos de segurança não ocorram.
- Os contratos são finitos
- Os contratos serão rescindidos
- Os contratos têm uma vida útil definida
- Nenhum ativo é retido quando o contrato é fechado
- O valor é conservado
Além dessas limitações, algumas construções de linguagem de programação estão ausentes da Marlowe para garantir a segurança:
- Recursão não é permitida
- Looping não é suportado
- Funções ou macros não podem ser definidas
- Os tempos limite devem ser constantes numéricas
- Somente continuações de Caso podem ser merkleizadas. A linguagem de programação Faustus relaxa algumas das limitações acima, mas compila para proteger Marlowe.
Ferramentas de análise de segurança
A ferramenta de análise projetada pela equipe da Marlowe marlowe-cli run analyzeverifica a compatibilidade de um contrato da Marlowe com as regras do livro razão da Cardano.
O livro-razão Cardano possui restrições internas que podem impedir que um contrato Marlowe seja executado na cadeia, mesmo que o próprio contrato seja válido em relação ao idioma Marlowe. Por exemplo, o livro-razão impõe restrições ao comprimento dos nomes de papéis e tokens e também limita os custos de execução do Plutus. Qualquer contrato que viole qualquer uma dessas regras não será executado na cadeia, mesmo que o contrato possa ser construído corretamente. Da mesma forma, embora os contratos possam ser executados no Playground, eles não serão executados na cadeia se o contrato violar as restrições do livro-razão. Saiba mais sobre as restrições de design do livro-razão integrado .
Conclusão principal: enquanto o Playground é sobre o idioma, o Runtime é sobre a implementação do contrato Marlowe no blockchain Cardano especificamente. Se alguém implementar Marlowe em outro blockchain, você ainda poderá usar o Playground, mas não poderá usar o Runtime em outro blockchain.
Observação: um contrato pode ser bloqueado se o dado não se encaixar na cadeia, mas a suíte Marlowe inclui ferramentas para avaliar esse risco. Essas ferramentas devem ser utilizadas antes da implantação de um contrato.
validação da transação
Dois tipos de scripts do validador Plutus estão envolvidos na validação de gastos UTXO:
- validador de semântica
- validador de pagamento
As práticas de segurança determinam que as transações não devem ser assinadas, a menos que o conteúdo e as implicações da transação tenham sido revisados e bem compreendidos. No ambiente Marlowe, isso significa verificar o contrato Marlowe, sua entrada e seu estado. Isso também significa garantir que a política de criação de papéis (se houver) e o validador Marlowe usados sejam os corretos.
As considerações de segurança abaixo se aplicam a ambos os tipos de script do validador.
validador de semântica
Os seguintes conceitos devem ser bem compreendidos antes de assinar uma transação Marlowe:
- A transação opera um contrato da Marlowe?
- Qual é a política de cunhagem de papéis (se houver)?
- Como os tokens de função foram distribuídos (se houver)?
- Qual é o contrato atual e seu estado?
- Qual insumo está sendo aplicado ao contrato?
- O que mais está ocorrendo na transação?
A transação opera um contrato da Marlowe?
Os scripts do validador Plutus são intérpretes universais para todos os contratos Marlowe de uma versão especificada, o que significa que o UTXO para um contrato Marlowe reside em um hash de script. Verificar se uma transação gasta de um endereço que possui o hash do script Marlowe como parte de pagamento confirma que o verdadeiro validador Marlowe será executado para validar o gasto desse UTXO específico. É possível calcular o hash do script do validador Marlowe a partir dos primeiros princípios, compilando o validador e calculando seu hash, assumindo que o código-fonte do script Marlowe neste repositório pode ser confiável.
Qual é a política de cunhagem de papéis (se houver)?
Uma política de cunhagem é o conjunto de regras para a criação de tokens de um determinado tipo de token, que é identificado pelo hash de sua política de cunhagem. Isso é conhecido como ID da política de cunhagem. Uma política de cunhagem determina se novos tokens podem ser criados ou se os tokens que foram criados são tudo o que haverá.
Por exemplo, as partes de um contrato da Marlowe, como credor e devedor, podem ser representadas de duas maneiras:
- Por um endereço: cada parte do tipo endereço corresponde a uma instância de um par de uma chave pública e uma chave privada que é supostamente mantida por uma carteira de uma das partes. Usar endereços para representar partes é mais simples e barato do que usar papéis. Para se autenticar, as partes representadas por um endereço precisam apenas assinar as transações que exigem sua autenticação (ou seja, aquelas que executam depósitos ou escolhas para a parte).
- Por um token de função: cada parte do tipo função corresponde a um token armazenado na cadeia. Para que um contrato use tokens de função como autenticação, o contrato precisa declarar que seu ID de política de cunhagem de token de função é o ID de política de cunhagem do token que deseja usar como token de função. Nesse caso, cada um dos nomes de ativo do token identificado pelo ID da política de cunhagem representa uma parte diferente. Para autenticar uma transação, um proprietário de token de função precisa apenas incluí-la como parte da transação que requer autenticação do proprietário do token de função. Pode haver potencialmente mais de um token com o mesmo nome de ativo, portanto, tecnicamente, você não possui uma parte de função, a menos que possua todas as instâncias do token de função que possui o nome de ativo da parte.
Como os tokens de função foram distribuídos?
Se um contrato usa apenas endereços para representar as partes, as políticas de criação de funções não são uma preocupação. A desvantagem dos endereços é que eles não podem ser transferidos de forma comprovada; portanto, uma vez conhecida a chave privada de um endereço, você não pode mostrar que o esqueceu e o excluiu. Do ponto de vista do destinatário de um endereço, o endereço é sempre inseguro. A única maneira de ter um endereço seguro é gerá-lo você mesmo.
A vantagem ou funções é que, como os tokens são tratados como ativos nativos na cadeia, eles podem ser transferidos como ada ou qualquer outro ativo. Mas qualquer pessoa que possua um token com o ID da política de cunhagem e o nome do ativo corretos pode agir como a parte que ele representa, portanto, você precisa garantir que é o único que possui tal token, ou então você não está realmente no controle do festa.
É claro que você pode garantir que é o único que possui esse token, criando os tokens de função você mesmo (o Marlowe Runtime faz isso com segurança como parte do processo de criação do contrato). Se outra pessoa cunhou os tokens de função ou criou o contrato, você precisa se certificar de que:
- Você tem todos os tokens existentes que controlam a festa
- Nenhum desses tokens pode ser criado (porque a política de cunhagem não permite isso)
Se a política de cunhagem for bastante simples, a maneira mais fácil de verificar isso é usar um scanner Marlowe para descobrir o ID da política de cunhagem da função do contrato. Em seguida, use um explorador do Cardano para verificar qual é a política por trás da política de cunhagem (para garantir que nenhuma outra função possa ser produzida) e para verificar a distribuição atual das funções existentes já cunhadas (quem tem quais tokens, em outras palavras).
Qual é o contrato atual e seu estado?
O estado pré-transação do contrato é definido no dado Plutus associado ao UTXO sendo gasto do endereço do script Marlowe. Este dado deve ser fornecido na transação e deve conter o seguinte:
- os saldos das contas internas ao contrato
- o histórico de escolhas feitas até este ponto na execução do contrato
- os valores atuais das variáveis vinculadas do contrato
- a parte do contrato que falta cumprir
O dado pode ser extraído do corpo da transação não assinado e desserializado para Language.Marlowe.Core.V1.Semantics.MarloweDatausar a função Plutus.V2.Ledger.Api.fromData.
Alternativamente:
- o contrato da ferramenta de linha de comando marlowe log --showexibirá o histórico on-chain do contrato.
- Esta ferramenta online também permite a visualização de contratos e estado on-chain
- Uma API REST fornece as mesmas informações obtidas viamarlowe log --show
Qual insumo está sendo aplicado ao contrato?
O redentor Plutus associado ao gasto do UTXO do endereço do script Marlowe define a entrada que está sendo aplicada ao contrato, juntamente com o intervalo de validade do slot para a transação especificada no corpo da transação. A entrada é uma sequência de zero ou mais depósitos, escolhas e notificações. Usando ferramentas como o Marlowe Playground ou o marlowe-cli run prepare, é possível analisar as consequências da aplicação desse insumo ao contrato.
O redentor pode ser extraído do corpo da transação não assinado e desserializado para Language.Marlowe.Scripts.MarloweInputusar a função Plutus.V2.Ledger.Api.fromData. A ferramenta de linha de comando marlowe-cli util slottingcalculará a relação entre os slots mencionados no intervalo de validade para os horários POSIX no contrato.
O que mais está ocorrendo na transação?
A transação não assinada pode conter outros gastos e pagamentos além dos especificados para o contrato da Marlowe. Isso pode ser examinado com a ferramenta cardano-cli transaction view.
políticas monetárias
Normalmente, devem ser usadas políticas monetárias (como as suportadas no Marlowe Runtime) que impõem um único evento de cunhagem e tokens únicos para cada função. Essas políticas garantem que os tokens de função sejam verdadeiros tokens não fungíveis (NFTs), portanto, os detentores de tokens de função são os únicos que podem atuar como partes no contrato.
Políticas monetárias que criam várias cópias de um token de função específico ou políticas com uma política de criação aberta oferecem suporte a casos de uso não padrão. Por exemplo, criar duas cópias de cada token de função e distribuí-las para a mesma parte permite que essa parte coloque um token no armazenamento frio como backup se a carteira que contém o token de função ‘quente’ ficar inacessível. Alguns novos contratos de crowdsourcing podem envolver a atribuição da função (através de tokens de função idênticos que podem ser cunhados mesmo após o início do contrato) para muitos participantes. Por fim, a política de cunhagem de um contrato Plutus para tokens de função pode ser coordenada com a operação de um ou mais contratos Marlowe.
tokens de função
Os tokens de função podem autorizar depósitos e escolhas nas transações da Marlowe. Autorizar o uso de um token de função é mais flexível do que autorizar com uma chave pública, porque um token de função (e, portanto, a participação em um contrato da Marlowe) pode ser transferido entre carteiras ou para outra pessoa.
Os scripts do validador Marlowe não aplicam nenhuma política monetária específica para tokens de função, para permitir novos casos de uso. No entanto, a segurança das autorizações em um contrato Marlowe baseado em função depende criticamente da política monetária do token de função. Isso significa que tanto a política monetária quanto o desembolso na cadeia dos tokens devem ser cuidadosamente examinados antes de participar de um contrato da Marlowe. Verificar a política monetária de um script simples envolve recuperar o script do blockchain e estudá-lo. A verificação da política monetária de um script Plutus envolve a obtenção e o estudo do código-fonte Plutus para o script e o hash do código-fonte para verificar o ID da política monetária.