Padrão
A-REX Core — o padrão
O que o padrão define, o que faz um token conforme, como ele muda e como se torna um ERC. O texto normativo é compartilhado por acesso antecipado.
Status
Rascunho 2.1.0-alpha.2, antes da submissão, com o esquema de metadados de lote 1.2.0. O texto está escrito no formato de um Ethereum Request for Comments para que possa ir para ethereum/ERCs quando implementadores independentes tiverem usado as interfaces em produção. Será publicado sob CC0; a implementação de referência é MIT. Enquanto não houver dois implementadores independentes, as mudanças aceitas ficam marcadas como provisórias.
O que define
A-REX Core é uma extensão pequena do ERC-1155 e do ERC-7943. Um lote (uma partida de uma commodity física, ou o direito a uma partida futura) é um id de token ERC-1155. O padrão acrescenta quatro camadas:
| Camada | Interface | O que cobre | Obrigatória |
|---|---|---|---|
| 0 | ERC-1155, ERC-165, IERC7943MultiToken | saldos e transferências em lote; congelamento, transferência forçada, elegibilidade de contas | sim |
| 1 | IARexBatch | o registro do lote: códigos abertos de produto e unidade, datas de produção e validade, uma referência de origem, um compromisso com um documento fora da cadeia, um status de ciclo de vida, e a linhagem quando um lote é dividido, fundido ou processado | sim |
| 2 | IARexHook, IARexHookManager | um único pipeline ordenado de contratos de regras externos; uma regra responde com um motivo legível por máquina | sim |
| 3 | IARexAttest | certificações, inspeções e declarações por lote e por tema, de emissores confiáveis para esse tema | recomendada, no token ou em um contrato complementar |
O que faz um token conforme
- Comporta-se como um token ERC-1155 comum, de modo que carteiras, marketplaces e indexadores funcionam sem mudanças.
- Expõe a superfície de execução do ERC-7943: um lote pode ser congelado ou movido por ordem judicial, penhor ou recall, e cada uma dessas ações fica visível na cadeia.
- Mantém um registro de cada lote e anota cada divisão, fusão ou etapa de processamento, de modo que os lotes de origem sempre podem ser rastreados.
- Passa cada transferência pelo seu pipeline de regras e consegue dizer por que uma transferência foi recusada.
- Declara as interfaces que implementa, para que as ferramentas possam detectá-lo.
Um contrato de regras (um hook) é conforme quando implementa IARexHook. Um mesmo contrato de regras pode servir a muitos tokens.
Como a conformidade é verificada
A implementação de referência inclui uma suíte de conformidade que não depende dela: uma implementação sob teste é acessada apenas pelas interfaces do padrão e por um pequeno adaptador escrito pelos seus autores. Cada teste indica a cláusula que verifica; há 85 cláusulas, 74 de nível DEVE e 11 de nível DEVERIA. Uma execução termina com um veredito, e uma declaração de conformidade precisa justificar cada cláusula que pulou. As cláusulas que não podem ser observadas na cadeia, como a regra de que a referência de origem não contém dados pessoais, ficam para revisão.
Propostas ainda não lançadas
Estas mudanças estão redigidas e abertas para revisão. Nenhuma delas foi aceita: cada uma aguarda a confirmação de dois implementadores independentes, e as de nível DEVE seguem a regra das mudanças maiores.
| Proposta | O que mudaria |
|---|---|
| ADR-019 (Proposto): capacidades no padrão, política em perfis | O padrão fixa papéis, eventos, formatos de dados, a semântica de pausa e de revogação e as regras de privacidade; quem pode usar uma capacidade, se ela está ativada e quais listas ou autoridades se aplicam passam para perfis de política versionados por jurisdição e por organização. Traz dois esclarecimentos: a referência de origem NÃO DEVE ser derivada da localização (nenhum hash nem codificação de coordenadas ou da geometria do talhão); e o emissor de uma atestação, ou um revogador que ele tenha delegado, a revoga, enquanto um papel administrativo NÃO DEVERIA revogar na 2.x uma atestação que não emitiu e NÃO DEVE a partir da 3.0, para que os tokens já implantados continuem conformes. |
ADR-017 (Proposto): extensions nos metadados | O esquema de metadados 1.3.0 acrescentaria um objeto opcional extensions, com uma entrada por regra, validada pelo fragmento de esquema do descritor da regra. |
| ADR-018 (Proposto): pegada de carbono declarada | Um lote pode trazer uma pegada de carbono de produto declarada por um terceiro identificado, copiada do PACT 3.0.3 para extensions.pact_pcf com um status de verificação; nunca calculada, somada nem transmitida a outros lotes. |
| ADR-020, ADR-021, ADR-022 (Proposto): adaptadores de referência | As ferramentas do ERC-3643 leem cada lote por meio de uma visão que não pode permitir nem recusar nada; declarações do ONCHAINID válidas enquanto o A-REX confia no seu signatário; um espelho no EAS dos certificados e registros de lote vigentes. Informativos: não acrescentam nenhum requisito. |
Descritor de regras arex.module/1 (informativo, Proposto) | Um documento JSON que uma regra ou um módulo adicional publica para que os consumidores o integrem sem código personalizado. |
Os mapeamentos informativos para GS1 EPCIS 2.0, UN Transparency Protocol 0.7.0, PACT 3.0.3, ERC-3643 e Ethereum Attestation Service não acrescentam nenhum requisito; Interoperabilidade os resume.
O que fica de fora
Não há lista de culturas, classificações ou certificações: os códigos são abertos. Não há dados pessoais na cadeia: nem coordenadas de talhões, nem nomes, nem identificadores de pessoas físicas, nem valores calculados a partir da localização de um talhão. Nenhum provedor de identidade, oráculo ou registro é exigido, nem nenhuma política: quem pode executar ordens, pausar ou fazer triagem, e com base em quais listas, é decisão do emissor segundo a sua jurisdição. Curvas de deterioração, fluxos de entrega, contabilidade de carbono e seguros são construídos como regras ou contratos complementares; a implementação de referência demonstra alguns, e a conformidade não depende deles.
Versionamento
As interfaces são versionadas junto com o padrão. Uma mudança em uma função, um evento ou um requisito é uma versão maior e vem com uma nota de migração. Acréscimos opcionais, como novos códigos recomendados ou campos de metadados, são uma versão menor: o esquema de metadados 1.1.0 abriu o esquema de commodity, e o esquema 1.2.0 acrescentou referências a lotes de outros tokens (upstream). Todo documento válido em um esquema anterior continua válido. Até a submissão as interfaces ainda podem mudar, sempre como versão maior.
Caminho até um ERC
O texto vai para ethereum/ERCs quando quatro condições forem cumpridas: uma implantação em produção com lotes reais funcionou por seis meses; existem pelo menos três contratos de regras independentes; a implementação de referência tem uma auditoria externa publicada; e as interfaces não mudaram durante um ciclo de versões. O roteiro está em Desenvolvimentos Futuros.
O que este site reserva
As cláusulas normativas, os fontes das interfaces e seus identificadores, os códigos de rejeição e o esquema de metadados do lote ficam no repositório do padrão enquanto ele for privado. Empresas que queiram implementar A-REX, emitir lotes com ele ou auditá-lo solicitam acesso de leitura em Solicitar acesso antecipado. Cada solicitação é revisada manualmente; quem é aprovado recebe acesso somente leitura ao padrão e à implementação de referência. O material permanece confidencial até ser publicado sob CC0, e o acesso antecipado não concede exclusividade.