AS-01 anchor adapter: AN01-P01

AN01-P01 — propuesta de adaptador de anclaje AS-01

Fecha: 2026-10-19. Estado: detalles N1–N6 propuestos, sin adoptar. La dirección A4/D06 de un perfil AS anclado ya está adoptada; esta propuesta concreta su adaptador. No hay contrato Solidity implementado/compilado, despliegue, transacción, pins de red instalados ni verificación viva de finalidad. AS01-F01 conserva sus bytes y anchor_evidence: null.

1. Recomendación y alternativas

Recomiendo un contrato nuevo, no actualizable, para un issuer/log, un ABI específico que ancle el compromiso C4 y su predecesor, genesis aceptado por política local y un ensayo Amoy eip155:80002. Para la ruta que pretende verificación independiente, exigir un nodo receptor que valide ejecución y consenso Bor/Heimdall, con bootstrap de red aceptado. Dos RPC remotos sólo permiten observación corroborada de ensayo, bajo otra política explícita.

Amoy figura como testnet con chain ID 80002 y parent Sepolia en la referencia oficial de red. La documentación distingue milestones de Polygon de checkpoints enviados al parent y documenta el tag RPC finalized en Finality. Esto fundamenta la hipótesis técnica, no prueba que nuestros nodos, proveedores o el futuro contrato la soporten correctamente en Amoy.

2. Selección, scope y compatibilidad

Nombre candidato del adaptador: xcim-as01-evm-amoy-milestone-01. Perfil AS envolvente: as-01-anchored; versión del artefacto de diseño AN01-P01. No son registros IANA ni activan un perfil por discovery.

El receiver debe aceptar exactamente issuer URN, log ID, URI de Consent Issuer, genesis AS, intent, deployment binding, red y política de finalidad. Cada adaptador liga explícitamente esos valores. Se conserva la selección del receipt/batch WD y firmas RBA/MSA/MP de P1; no se sustituyen sus algoritmos, preimágenes o roles por ECDSA/EVM. El firmante on-chain sólo publica un hash.

No agregar un objeto anchor a C7 F01: su schema cerrado exige null. Tras aceptar N1–N6 habrá que emitir una revisión nueva del contrato C1/C7 y fixtures con rama de evidencia explícita. El checker F01 y sus 19 schemas/97 escenarios siguen offline; los checks ABI de esta propuesta no son nuevos escenarios AS de permisos ni un verificador de anclaje.

3. Compromisos y ABI candidato

Notación: H=SHA-256, K=Keccak-256 (no SHA3-256), J=JCS, U=UTF-8, b64u base64url canónico sin padding. \0 es un octeto NUL.

G = H(U("XCIM-AS-01-GENESIS\0") || J(as_genesis))
C = H(U("XCIM-AS-01-CHECKPOINT\0") || J(checkpoint_payload))
I = H(U("XCIM-AS-EVM-01-IDENTITY\0") || J({
    adapter_profile, issuer_id, log_id, as_genesis_commitment: b64u(G)
}))
T = H(U("XCIM-AS-EVM-01-INTENT\0") || J(anchor_intent))
D = K(U("XCIM_AS01_EVM_ANCHOR_V1"))
anchor_id = K(abi.encode(
    bytes32 D, uint256 chain_id, address contract_address,
    bytes32 T, bytes32 I, bytes32 G, uint64 sequence,
    bytes32 C, bytes32 previous_C
))

G/C son exactamente los hashes AS existentes, decodificados a 32 bytes. No volver a hashear sus strings base64url/hex ni el envelope JWS. previous_C es cero de 32 octetos sólo en secuencia 1, cuando C4 tiene predecesor null; para secuencias posteriores es el compromiso del C4 anterior. No es el hash del anchor record ni el genesis del perfil Amoy viejo.

ABI concreto descargable: abi.json. Notación de interfaz, sin implementación ni promesa de bytecode desplegable:

constructor(bytes32 asGenesisCommitment_, bytes32 anchorIntentCommitment_,
            bytes32 identityCommitment_, address publisher_, address guardian_);

event ASCheckpointAnchored(
    bytes32 indexed identityCommitment,
    uint64 indexed sequence,
    bytes32 indexed checkpointCommitment,
    bytes32 previousCheckpointCommitment,
    bytes32 asGenesisCommitment,
    bytes32 anchorId,
    address publisher);
event ASHalted(address indexed guardian);

function anchor(uint64 sequence, bytes32 checkpointCommitment,
                bytes32 previousCheckpointCommitment) external returns (bytes32 anchorId);
function checkpointAt(uint64 sequence) external view
    returns (bytes32 checkpointCommitment, bytes32 previousCheckpointCommitment, bytes32 anchorId);
function head() external view returns (uint64 sequence, bytes32 checkpointCommitment);
function asGenesisCommitment() external view returns (bytes32);
function anchorIntentCommitment() external view returns (bytes32);
function identityCommitment() external view returns (bytes32);
function publisher() external view returns (address);
function guardian() external view returns (address);
function halted() external view returns (bool);
function halt() external;

Evento no anónimo: cuatro topics (firma + identity + sequence + C); data son cuatro palabras de 32 bytes (previous_C, G, anchor_id, publisher), 128 octetos. Secuencias usan uint64 pero el contrato debe limitar 1..9007199254740991, intersección con enteros seguros AS/E1. Address son 20 octetos con padding izquierdo cero; uint64 debe tener sus 24 octetos altos cero. Rechazar longitudes, padding, topics extra/faltantes y campos fuera de rango, no truncar casts. Los hashes son bytes32 completos; el último argumento de anchor_id no es un nuevo hash del predecesor. Se usa abi.encode, nunca encodePacked.

La especificación ABI de Solidity define la separación indexed/data y Keccak de la firma. El fixture y checker publicados aquí comprueban sólo esta representación, no ejecución EVM.

4. Máquina de estado del contrato propuesto

Constructor: exigir G/T/I no nulos, publisher y guardian no cero y distintos; fijarlos inmutables. Sin proxy, setters, delegatecall, llamadas externas, retiro de fondos ni selector para editar historia. No hay ERC/token/billing. Inicialmente head=(0,0) y halted=false.

anchor exige sender publisher, estado no detenido, C no cero y secuencia segura positiva. Para una secuencia nueva exigir sequence=head.sequence+1 y predecesor igual a head.C (cero sólo para la primera). Calcular anchor_id con block.chainid y address(this); escribir mapping/head y emitir el evento en la misma ejecución. El contrato no comprueba firmas JWS/roles/roots: el receiver debe hacerlo sobre C4/C3/C2. Un publisher comprometido puede causar denegación de servicio con hashes basura, pero no forjar por ello un C4 válido.

Retry de una secuencia ya guardada con exactamente C/predecesor iguales: devolver el mismo anchor_id sin cambiar storage ni emitir evento nuevo. Valores diferentes revierten ConflictingCheckpoint; saltos/cero/overflow revierten InvalidSequence. Si está detenido, rechazar incluso retries de escritura; los getters continúan disponibles. Errors candidatos adicionales: UnauthorizedPublisher, UnauthorizedGuardian, Halted, InvalidCommitment. Sus selectores están en ABI; no son resultados XCIM.

halt sólo puede llamarlo guardian, de forma irreversible e idempotente: primera llamada cambia false→true y emite ASHalted; posteriores no emiten. No resetea head/mapping. Detención retira disponibilidad/autoridad de publicación según política al conocerse; no borra ni concede consentimiento. Receiver debe leer halted al bloque finalizado aceptado, no asumir que un anchor antiguo implica que el contrato sigue habilitado. Su caché tiene la cota de §7; no hay revocación de efecto instantáneo garantizado.

No existe anchorVariantCount AS: el modelo rechaza segunda variante en la misma cadena canónica. Un receiver igualmente debe detectar contradicciones entre eventos/estado, C4/C3 y sus floors; si aparecen, pone en cuarentena el issuer/log. No elegir una variante ni retroceder a otra red/contrato.

Rotación de publisher/guardian: en esta primera propuesta requiere detener y desplegar una instancia nueva, con nuevo log/genesis y bootstrap aceptado. No hay migración unilateral ni reset de floors. Esto tiene coste operativo; si se quiere rotación in-place, debe diseñarse su autorización por epoch, eventos, recovery y revisión, antes de añadir un setter o proxy al ABI.

5. Genesis y provenance sin ciclos

Tres piezas con funciones distintas. La plantilla tiene nulls intencionales: es una checklist, no un genesis válido. No se publican direcciones, keys ni hashes de despliegue fingidos.

5.1 Genesis AS existente

Payload cerrado de F01: {issuer_id, log_id, profile_id, origin_nonce, anchor_policy_id}. Su hash es G. anchor_policy_id es un identificador estable, no el hash de un documento que contiene la dirección futura. No agregar campos a ese schema ni copiar el nonce del fixture para un despliegue real.

5.2 AnchorIntent previo al despliegue

Contenido candidato: adapter_profile, anchor_policy_id, issuer_id, log_id, as_genesis_commitment, identity_commitment, chain_id, network_genesis_block_hash, contract_model, abi_sha256, creation_code_template_keccak256, build_recipe, initial_publisher, guardian, finality_policy_id. contract_model=immutable-single-log. La receta fija compilador exacto, target EVM, optimizer, metadata y fuentes.

creation_code_template es el output de creación del compilador sin los argumentos de constructor; no contiene T/dirección/tx futura. T se calcula después con intent completo y se pasa al constructor. Hash ABI es SHA-256 de los bytes JCS del array ABI; no su JSON pretty printed. Este paquete fija ABI candidato, pero source/compiler/template hashes siguen pendientes.

5.3 DeploymentBinding posterior al despliegue

Objeto candidato firmado por el quórum raíz aceptado: adapter_profile, anchor_policy_id, issuer_id, log_id, as_genesis_commitment, anchor_intent_commitment, chain_id, network_genesis_block_hash, contract_address, deployment_transaction_hash, deployment_block_number, deployment_block_hash, creation_input_keccak256, runtime_code_keccak256, abi_sha256, constructor_arguments, bootstrap_finalized_block_number, bootstrap_finalized_block_hash, root_policy_epoch, valid_from, valid_until. Debe coincidir con intent y observación independiente del despliegue.

Orden acíclico: fuentes/ABI/receta → template de creación → genesis AS e intent → T/args → despliegue → runtime/location/receipt → DeploymentBinding → pins locales C1. G/T/I nunca contienen el DeploymentBinding. C4 nunca contiene su propio anchor_id/receipt/bloque; sólo el genesis/perfil y compromisos anteriores.

La raíz autentica el binding, pero la firma no reemplaza verificar creation input, código runtime, constructor, getters y cadena/bloques. Discovery, explorer o HTTP200 no hacen bootstrap. Chain ID por sí solo tampoco distingue una cadena falsa con el mismo número: fijar genesis de red y estado de consenso aceptado, software y procedimiento de sincronización verificados.

6. Red y alternativas de finalidad

Piloto recomendado: Amoy 80002, opt-in por receiver, nuevo log/genesis y contrato AS. No reutilizar la dirección ni evento del batch de octubre. Parent Sepolia no equivale a heredar una prueba de finalidad Ethereum del anchor AS. Otra EVM, Polygon mainnet 137 o Sepolia como red de ejecución son otros perfiles.

No se promete una latencia de red. La documentación de Polygon orienta el mecanismo, pero se deben observar las versiones y comportamiento reales Amoy. Fallo del tag finalized, nodo sin sync, datos podados o políticas incompatibles retiran señal positiva; no degradar silenciosamente a latest/safe/N bloques.

7. Algoritmo candidato del receiver

1. Aplicar límites y seleccionar perfil/pins C1 antes de tocar URLs. Validar C2/C3/C4, hashes y estados bajo AS; la presencia del evento no autoriza esos objetos. C4 debe ser exacto, con scope y genesis aceptados.
2. Verificar identidad/salud/sync de la fuente de consenso aceptada. Obtener F finalizado y conservar su número/hash y contexto de observación local. La fuente de consenso debe justificar el header; un RPC remoto arbitrario no se convierte en nodo verificador porque use el tag correcto.
3. Obtener receipt exitoso y bloque B del evento. Exigir chain ID/genesis/red y contract address aceptados; receipt.status=1, transaction/block hashes, logIndex/transactionIndex y removed=false consistentes. Fallar ante logs ambiguos. Verificar B pertenece a la cadena finalizada de F por ancestry o la vista coherente del nodo validador, no sólo B.number <= F.number. Si B=F, hashes deben ser idénticos.
4. Decodificar exactamente el evento AS y comparar I, sequence, C, previous_C, G, publisher y anchor_id recalculado con chain/contract/T. Confrontar el checkpoint C4 y su predecesor. Una transacción exitosa con otro evento no sirve.
5. Leer código y getters al mismo hash F, con requireCanonical=true cuando corresponda. Verificar runtime hash, G/T/I, publisher/guardian y halted=false; checkpointAt(sequence) debe coincidir con evento. head no puede contradecir el historial aceptado ni justificar seguir usando un C4 anterior si ya revela uno posterior. Si el nuevo head no tiene evidencia AS usable, retirar señal.
6. Comprobar floors durables de manifest/C3/C4 y de cadena: hash por altura, no descenso de finalized height, evento/head ya aceptados y tombstones. Una reorg de datos que se habían aceptado como finalizados es fallo de seguridad: cuarentena, diagnóstico y recuperación autenticada, no rollback a active.
7. Recalcular deadline al aceptar SMTP o reutilizar/exportar. Esperar, adquirir F más nuevo o reintentar transacción no renueva el corte firmado. Registrar evidencia/diagnóstico sin PII; actualizar floors atómicamente con su uso.

EIP-1898 permite consultas por hash y condición de canonicalidad para llamadas de estado; véase su especificación. En este perfil candidato se exige soporte consistente: si un proveedor/nodo no lo ofrece, no se presupone que una consulta a latest sea equivalente.

Para recepción de evidencia adjunta sin nodo local, exigir las pruebas de inclusión/estado y autenticación del header que defina un perfil portable futuro. El transporte de receipt/log/bloque por un mirror no autentica su contenido. La ruta de observación de dos RPC no rellena esta dependencia.

7.1 Parámetros iniciales para medir

Deadline efectivo: mínimo del deadline AS completo, deadlines de trust/keys, F.timestamp+120 y expiración local de la vista validada. La caché de vista usa tiempo monotónico; no sumar la hora de descarga de un wrapper a la frescura de permiso. Nodos recién consultados pero estancados en un F viejo no renuevan la política. Bloque B/F no acredita la veracidad del consentimiento ni la atomicidad del snapshot firmado.

Los valores 120s/30s/10s son nuevos parámetros no medidos. Si finality y transporte no caben dentro de 300s, el perfil no es viable con esa ventana; debe revisarse de forma explícita. No prometer que esperar más genera permiso.

8. Evidencia de anchor y separación de resultados

Rama C7 futura candidata: adapter_profile, anchor_intent_commitment, deployment_binding_commitment, checkpoint_commitment, sequence, transaction_hash, transaction_index, block_number, block_hash, log_index, event, finalized_view_reference. Event/receipt/proofs deben tener schemas cerrados propios del perfil seleccionado. Es diseño, no rama habilitada.

Una referencia a vista finalizada sólo es usable si el receiver ya autenticó esa vista o verifica pruebas definidas por su perfil. Campos confirmed, finalized, confirmations o una firma del issuer nunca sustituyen esa arista. El anchor_id es identificador contextual; no es por sí solo proof criptográfica de inclusión. Incluso anchor válido no establece PASS sin todas las comprobaciones de permiso, destinatario, app/roles, contenido, DKIM, frescura y replay SMTP.

Devolver por ahora sólo diagnósticos de propuesta/layout. No registrar nuevos resultados XCIM ni convertir ANCHOR_OBSERVED_TEST_ONLY, receipt.status=1, ABI válido o schema válido en permiso. Los errores de disponibilidad y de consistencia deben conservarse distintos de revocación y fraude demostrado.

9. Decisiones N1–N6 y criterios de cierre

Gates de preparación, implementación y operación

• S/editorial: propuesta/alternativas/limitaciones públicas, ABI y plantilla con status inequívoco, decisiones pendientes trazables. Un primer draft puede declarar las brechas; esta entrega no envía nada a IETF.
• G06-M: N1–N6 ratificadas, schemas C1/C7 revisados, contrato compilado y verificador completo por perfil; otro implementador reproduce preimágenes, bootstrap y anchor/finality sin APIs privadas. Las pruebas de layout de hoy no satisfacen ese gate.
• G05/G06/G16-O: ventana propuesta de siete días con carga y versiones declaradas: snapshots cada 60s objetivo, revocaciones y cero-eventos, p99 y máximo corte→inclusión→finalidad→disponibilidad, fallos/reorg/caché/restart, uso de CPU/red/storage/gas y expiración. Sin positivos tras deadline/deny conocido. Reportar también muestras fallidas; no sólo promedio de éxitos.
• G14/G15: revisión externa del contrato/ABI/trust/finality/privacy y ensayo entre operadores/equipos independientes. Dos clientes del mismo proveedor o dos lenguajes del mismo trabajo no cumplen esa independencia.

Coste base de la cadencia de 60s: hasta 1440 anclajes por día por log que opere continuamente, incluso vacíos. Gas/almacenamiento/coste monetario y capacidad no están medidos. No se cotizan fees ni se compra token/servicio en esta entrega.

10. Casos de ensayo pendientes, no ejecutados on-chain

Plan AN-T01–AN-T20 para la siguiente iteración, aparte de los checks de layout:

Los checks tools/check_proposal.py sólo cubren forma ABI, selectores/topics, preimágenes/encoding de un fixture y negativos locales de layout. No ejecutan AN-T01–AN-T20, no consultan chain/RPC y no prueban el contrato o finalidad.

11. Próximo trabajo recomendado

Aceptar/ajustar N1–N6 → source de contrato + schemas del intent/binding/evidencia → tests EVM y verifier offline con fallos → bootstrap y ensayo Amoy autorizados → operación/review/interop. Publicar este diseño y sus archivos en los sitios no autoriza ni implica deploy on-chain, envío IETF o cambio de trust local.

Fuentes primarias consultadas el 2026-10-19: AS-01, AS01-F01, Amoy 0.1 histórico, Polygon Finality, Polygon RPC/redes, ABI Solidity, EIP-1898, Ethereum PoS. Los mecanismos AN01 adicionales son diseño XCIM, no aprobación de esas fuentes.