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.
Versões
O padrão e a sua implementação de referência têm números de versão separados. Um nome como "alpha.10", sozinho, é uma versão da implementação de referência, não do padrão.
| O quê | Versão | O que é |
|---|---|---|
| Padrão (A-REX Core) | 2.1.0-alpha.2 | A especificação e as suas interfaces. O texto proposto depois desta versão é marcado como Proposto e não faz parte dela. |
| Esquema de metadados do lote | 1.2.0 publicado, 1.4.0 Proposto | O documento do lote fora da cadeia que o token compromete. |
| Implementação de referência | 2.0.0-alpha.10 | Os contratos MIT que implementam o padrão 2.1.0-alpha.2. |
| Suíte de conformidade | 1.1.0 | Os testes, cláusula por cláusula, que qualquer implementação executa; é distribuída com a implementação de referência. |
Os números contam coisas diferentes: o padrão conta as mudanças da especificação e a implementação conta as suas próprias versões. Ambos começaram em 2.0.0; a versão 2.1 do padrão não mudou nenhuma interface, evento ou requisito, por isso uma implementação 2.0 o implementa.
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á 89 cláusulas, 75 de nível DEVE e 14 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; pela mesma regra, atestar de novo nunca substitui o registro de outro emissor nem reativa um registro revogado. |
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-024 (Proposto): lugares como códigos ISO | A partir do esquema de metadados 1.3.0, origin.region é um código de subdivisão ISO 3166-2 como BR-MG (o código ISO 3166-1 do país quando nenhuma se aplica), verificado por padrão; um nome para as pessoas vai no campo opcional origin.regionName. Documentos de versões anteriores continuam válidos. |
| ADR-025 (Proposto): hooks vinculados a um único token | Um hook pode ser vinculado a um único token ao ser implantado, se tornar esse token público e recusar com um erro nomeado toda chamada de outro endereço; os hooks não vinculados continuam servindo ao token que os chamar. O hook de rastreabilidade de referência é vinculado. |
| 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. |
| ADR-023 (Proposto): vários valores nos dados de uma transferência | Os data de uma transferência podem ser um envelope etiquetado de até 8 entradas, cada uma com uma chave e um valor, para que cada regra leia apenas a sua própria chave; dados de 32 bytes mantêm o significado anterior. Não acrescenta nenhum requisito. |
| ADR-026 (Proposto): redes | A-REX Core continua sendo um padrão EVM: qualquer rede EVM de nível paris ou posterior pode hospedar um token conforme, as redes são identificadas por ids CAIP-2 e o padrão não mantém nenhuma lista delas; as evidências em torno de um token podem ser ancoradas em qualquer rede. |
| Esquema de metadados 1.4.0 (Proposto) | Uma entrada de upstream pode indicar a network CAIP-2 do lote que ela nomeia; um lote em uma rede que não é EVM é identificado pelo seu ativo CAIP-19. |
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. |
Formatos arex.vocab/1, arex.anchor-proof/1 e arex.report-sources/1 (informativos, Propostos) | O vocabulário próprio de uma organização para trabalho de campo, processos e etapas; provas de que um registro existia sem alterações, ancoradas em qualquer rede; as fontes dos números de um relatório, uma linha por registro. |
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). Os esquemas de metadados 1.3.0 e 1.4.0 estão Propostos e não foram lançados. 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.