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.
| Categoria | Contratos | Função |
|---|---|---|
| Controllers | InventoryManager, CreditPurchaseManager, CreditRetirementManager | Orquestram operações multi-contrato |
| Custodians | Vault, RewardsVault | Mantêm e gerenciam ativos (créditos, NFTs, USDC) |
| NFTs | MassID, Certificate, CreditPurchaseReceipt, CreditRetirementReceipt | Tokens soulbound ERC-721 representando ativos e provas |
| Tokens | Credit | Tokens fungíveis ERC-20 de crédito ambiental |
| Registries | ContractRegistry, CertificateRegistry | Descoberta 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.