Naar de hoofdinhoud

Traceerbaarheid & terugroepen · Vraag

Controleren dat de informatie van een partij niet is gewijzigd

Elke versie van de informatie van een partij heeft een vingerafdruk die in de ledger is vastgelegd. Iedereen kan die uit de gepubliceerde informatie opnieuw berekenen en vergelijken, zonder account en zonder op A-REX te vertrouwen.

Wanneer een partij wordt geregistreerd, publiceert A-REX de informatie ervan (product, hoeveelheid, partijcode, herkomst, datums) en legt er een vingerafdruk van vast in de ledger. De vingerafdruk is een korte code die uit de exacte inhoud wordt berekend: verander één letter of cijfer en hij klopt niet meer. Een koper, een auditor of een autoriteit kan zo, zonder account en zonder op A-REX te vertrouwen, controleren dat de informatie die hij leest de informatie is die uw bedrijf heeft vastgelegd, en sinds wanneer.

De vingerafdruk laat zien dat de informatie na het vastleggen niet is gewijzigd. Hij laat niet zien dat wat is verklaard waar is: de ledger legt vast wie wat heeft verklaard, en wanneer.

Wat de vingerafdruk dekt

  • Elk veld van de gepubliceerde informatie van de partij, precies zoals het is vastgelegd.
  • Eén versie. Een correctie publiceert een nieuwe versie met een eigen vingerafdruk, vastgelegd met de correctie; de vorige versie en haar vingerafdruk blijven vastgelegd en zijn nog steeds te controleren. Zie De informatie van een partij corrigeren.
  • Niet de bestanden van certificaten: elk heeft een eigen vingerafdruk. Zie Certificaten.

Waar de console hem toont

  1. Open de partij via Partijen.
  2. Open Technische details onderaan de pagina van de partij. De lange waarde die met 0x begint, direct boven Het openbare record openen, is de vingerafdruk die voor de partij is vastgelegd.
  3. Het openbare record openen opent de gepubliceerde informatie, die iedereen kan lezen. Het webadres eindigt op dezelfde vingerafdruk.

Eigenaren en beheerders vinden hem ook in Partijen (technisch), op de pagina van elke partij.

Hoe iedereen hem controleert

  1. Download de gepubliceerde informatie van het openbare adres, het adres dat Het openbare record openen opent. De informatie bevat geen persoonsgegevens.
  2. Zet haar in de standaardvorm, de canonieke vorm van RFC 8785: de velden in een vaste volgorde en zonder extra spaties, zodat dezelfde informatie altijd dezelfde tekst geeft.
  3. Bereken de vingerafdruk van die tekst met de methode keccak-256.
  4. Vergelijk hem met de vingerafdruk die voor de partij is vastgelegd. Dezelfde waarde betekent dat de informatie de vastgelegde is. Elke andere waarde betekent dat de kopie afwijkt van wat is vastgelegd.

Uw ontwikkelaars of auditors kunnen dit met een paar regels code doen; de volgende sectie laat zien hoe.

Voor ontwikkelaars en auditors

Deze sectie gebruikt technische termen. De vingerafdruk is de metadataHash van de batch, getoond als Metadatahash onder Technische details: de keccak256 van de canonieke serialisatie volgens RFC 8785 (JCS) van het metadatadocument, berekend over de UTF-8-bytes (AREX-CORE §3.5). Het document wordt geserveerd op GET /m/{bedrijf}/{metadataHash}.json van de A-REX-API, de uri van de batch on-chain, zodra de batch in de ledger staat (concepten antwoorden 404). Het antwoord is de canonieke tekst zelf, leesbaar vanaf elke origin.

In JavaScript (Node 18 of nieuwer), met het pakket canonicalize (RFC 8785) en viem:

import canonicalize from 'canonicalize';
import { keccak256, toBytes } from 'viem';

const url = 'https://API_HOST/m/fazenda-boa-vista/0x5c1e…9a2b.json'; // Het openbare record openen
const recorded = '0x5c1e…9a2b';                                 // Metadatahash van de partij

const doc = await (await fetch(url)).json();
const computed = keccak256(toBytes(canonicalize(doc)));
console.log(computed === recorded.toLowerCase() ? 'ongewijzigd' : 'afwijkend');

Met ethers v6 wordt de laatste stap keccak256(toUtf8Bytes(canonicalize(doc))). Canonicaliseren is nodig wanneer u een opnieuw opgemaakte kopie controleert (ingesprongen, sleutels anders geordend): het gepubliceerde bestand is al canoniek, dus de bytes zoals ze zijn geven dezelfde waarde.

Op de opdrachtregel, met cast van Foundry:

curl -s "https://API_HOST/m/fazenda-boa-vista/0x5c1e…9a2b.json" -o lot.json
cast keccak "$(cat lot.json)"

Om met de ledger zelf te vergelijken in plaats van met wat de console toont, leest u de batch uit het tokencontract (Tokencontract, Token-ID en Netwerk onder Technische details):

cast call "$TOKEN" "batchOf(uint256)((address,uint64,uint8,bytes32,bytes32,uint64,uint64,bytes32,bytes32,string))" "$TOKEN_ID" --rpc-url "$RPC_URL"

De negende waarde van de tuple is metadataHash en de tiende is uri. Na een correctie geeft batchOf de gecorrigeerde versie terug, en elk event BatchMetadataUpdated(id, metadataHash, uri) legt een versie vast. Documenten verklaren schemaVersion 1.0.0, 1.1.0 of 1.2.0 (A-REX schrijft 1.2.0); de controle is voor allemaal dezelfde. Het document valideren tegen zijn schema is een aparte stap: elke validator voor JSON Schema 2020-12 met schema/batch-metadata.schema.json van de standaard, of POST /v1/metadata/validate met een API-sleutel.