ProtocolContratos e InteroperabilidadeSmart Contracts

Visão Geral da Arquitetura de Contratos

Como os contratos da Rede Carrot são organizados, os princípios de design por trás da arquitetura e por que o registry público de créditos opera em um ledger imutável.

Last updated on

Por que o registry público de créditos opera em uma blockchain pública

A Rede Carrot registra cada crédito ambiental em uma blockchain pública para garantir três propriedades que bancos de dados tradicionais não conseguem oferecer:

  • Imutabilidade — Cada emissão de crédito, compra e aposentadoria é permanentemente registrada on-chain, e os metadados de proveniência são endereçados por conteúdo no IPFS, onde a disponibilidade contínua depende de pinning ativo. O ponteiro de metadados de um token pode ser corrigido pela governança, e MassIDs e certificados podem ser revogados — em ambos os casos, a alteração é ela própria registrada on-chain. A lógica contratual no nível do protocolo (verificações de uso único e destruição permanente na aposentadoria) previne a dupla contagem.
  • Transparência — Todas as transações são publicamente verificáveis na blockchain. Qualquer pessoa pode inspecionar o histórico on-chain de um crédito em qualquer explorador de blockchain (ex.: PolygonScan), sem nenhum serviço da Carrot envolvido, e abrir o documento de proveniência por trás de cada registro no Metadata Viewer. O Carrot Registry acrescenta o contexto ambiental — metodologias, resultados de verificação e homologações.
  • Auditabilidade — Cada evento do ciclo de vida do crédito (emissão, compra, aposentadoria) existe on-chain, junto com os MassIDs e certificados registrados por trás dele; os créditos de um certificado só são emitidos quando o certificado é registrado. O Carrot Registry também publica certificados ainda não registrados on-chain, que não têm créditos emitidos, e acrescenta a verificação por trás de cada registro, de modo que toda a cadeia — do resíduo físico ao crédito aposentado — é rastreável. Auditores, reguladores e stakeholders podem verificar independentemente o ciclo de vida sem depender dos registros de uma única entidade.

Implantação

Os smart contracts da Rede Carrot são implementados em Solidity e compatíveis com qualquer blockchain compatível com EVM. Atualmente estão implantados na Polygon PoS, selecionada por seus baixos custos de transação e total compatibilidade com EVM, permitindo que a rede processe altos volumes de operações de emissão, compra e aposentadoria sem taxas de gas proibitivas, mantendo compatibilidade com o ecossistema Ethereum mais amplo. A plataforma é agnóstica em relação à rede blockchain e poderia ser implantada em outras redes compatíveis com EVM no futuro.

Visão geral da arquitetura

O ecossistema de smart contracts segue uma arquitetura modular organizada em cinco categorias de contratos. Cada categoria tem uma responsabilidade bem definida, e os contratos interagem através de interfaces bem definidas em vez de lógica monolítica.

CategoriaContratosFunção
ControllersInventoryManager, CreditPurchaseManager, CreditRetirementManagerOrquestram operações multi-contrato
CustodiansVault, RewardsVaultMantêm e gerenciam ativos (créditos, NFTs, USDC)
NFTsMassID, Certificate, CreditPurchaseReceipt, CreditRetirementReceiptTokens soulbound ERC-721 representando ativos e provas
TokensCreditTokens fungíveis ERC-20 de crédito ambiental
RegistriesContractRegistry, CertificateRegistryDescoberta de serviços e rastreamento de relacionamentos

Essa separação mantém cada contrato focado e auditável. Controllers contêm a lógica de negócio, custodians gerenciam a custódia de ativos, e NFTs e tokens representam os próprios ativos. Registries fornecem a infraestrutura que conecta tudo.

Princípios de design

Atualizabilidade (UUPS)

Todos os contratos utilizam o Universal Upgradeable Proxy Standard (UUPS), permitindo que o protocolo evolua sem perder estado ou exigir reimplantação. Quando um contrato é atualizado, seu endereço permanece o mesmo e os dados armazenados são preservados — a lógica muda, e a chamada de atualização também pode executar uma migração sobre esse armazenamento existente. Isso permite que a equipe corrija bugs, adicione funcionalidades e melhore a eficiência, preservando a integridade do registro on-chain.

Descoberta baseada em registry

Os contratos localizam uns aos outros através do ContractRegistry usando chaves lógicas em vez de endereços hardcoded. Isso desacopla os contratos entre si e permite atualizações independentes. Uma atualização de lógica mantém o endereço do proxy, então nenhuma alteração no Registry é necessária e todos os pares continuam resolvendo a mesma entrada. O Registry importa quando um contrato é substituído por um novo proxy: atualizar essa única entrada reaponta todos os pares sem reimplantar nenhum deles. De qualquer forma, contratos individuais podem ser melhorados, corrigidos ou estendidos sem uma reimplantação de todo o sistema.

NFTs soulbound

Todos os NFTs na Rede Carrot são soulbound — não transferíveis e permanentemente mantidos pelo contrato Vault. Isso preserva a integridade da trilha de auditoria ambiental — tokens não podem ser movidos, vendidos ou ocultados. Um MassID ou certificado pode ser queimado por revogação; cada emissão, tentativa de transferência e revogação permanece no log de eventos on-chain, de modo que a cadeia de evidências sobrevive ao token.

Meta-transações

Compradores nunca precisam possuir o token de gas nativo da rede ou pagar taxas de transação da blockchain — a Carrot envia as transações de compra e aposentadoria em nome deles, removendo uma barreira significativa para adoção por compradores novos em blockchain. Os contratos de compra e aposentadoria de créditos implementam o padrão de meta-transações ERC-2771, de modo que isso também pode ser delegado a um relayer confiável.

Controle de acesso baseado em funções

Cada contrato implementa RBAC com funções definidas para operações cotidianas, atualizações e ações emergenciais. Os cinco papéis são atribuídos a cinco endereços distintos, de modo que a operação rotineira exige mais de uma chave. Consulte Segurança para o que essa separação garante e o que não garante.

Pausabilidade

Operações críticas podem ser pausadas em emergências, interrompendo toda movimentação de saldo do contrato enquanto uma vulnerabilidade ou incidente é investigado. Pausas emergenciais têm expiração de 48 horas, após a qual qualquer conta pode encerrá-las. Pausas padrão, mantidas por uma função de pauser separada, persistem até serem explicitamente encerradas. Consulte Segurança para o modelo completo de controle de acesso e pausabilidade, incluindo como um incidente em curso é mantido aberto além dessa janela.

Próximos passos

  • Categorias de Contratos — Detalhamento de cada contrato e seu papel no sistema.
  • Fluxos On-Chain — Passo a passo de emissão, compra, recompensas e aposentadoria.
  • Segurança — Controle de acesso, segurança de governança e mecanismos anti-manipulação.

On this page