Summary

  • Un borrador individual propone que una persona firme con su llave de acceso el permiso de gasto de un agente. En su ejemplo, el límite de 200 libras se verifica frente a recibos y el sistema detecta una suma de 230.
  • La cuenta se cierra dentro de cada registro. Si dos registros emplean el mismo permiso, sus importes no se suman: ambos pueden resultar conformes por separado mientras la factura conjunta supera lo autorizado.

Dos libros que no conocen la misma cartera

El agente de oficina del borrador publicado el 24 de octubre puede encargar material por un total de 200 libras. Cada pedido tiene un máximo de 100. El proveedor debe contrafirmarlo y un pedido superior a 60 necesita además la aprobación de la persona representada. En el ejemplo escrito por el autor, la secuencia llega a 230 libras; el verificador señala el exceso y una aprobación ausente. Es una demostración nítida porque permiso y pedidos viven en el mismo libro.

Ahora entran dos registradores, sin tocar una sola cifra del permiso. Cada libro conserva pedidos por 125 libras, con las aprobaciones y contrafirmas exigidas. Ambos verificadores ven una cifra menor que 200 y emiten un resultado local favorable. Juntos, los pedidos suman 250. Esa segunda escena es una prueba aritmética construida con la regla del documento, no un suceso atribuido a una empresa. La sección de seguridad advierte expresamente que los totales, recuentos y límites temporales se evalúan dentro de un registro y que los recibos de un mismo permiso distribuidos entre dos registros no se agregan.

Se puede tener una firma auténtica sobre un límite que nadie aplica al gasto combinado. La llave de acceso vincula a la persona con la autorización. La firma del agente vincula un recibo con una acción declarada. La del proveedor añade una voz al pedido concreto. El conflicto aparece al decidir quién ve todos los pedidos que compiten por la misma bolsa. Ninguno de esos tres firmantes crea por sí solo una caja central.

La auditoría llega después de la compra

El Datatracker de la IETF clasifica el texto de Pavel Izmaylov como Internet-Draft individual, sin director de área responsable ni trayectoria formal de adopción. El diseño es, aun así, bastante preciso. La persona firma un permiso con límites por importe total, importe individual, número de acciones y periodos móviles. El agente firma cada recibo. Un registrador los encadena, publica cabezas firmadas del árbol y añade sellos de tiempo. Un tercero puede examinar después, incluso sin conexión, el conjunto que recibe.

La versión 01 endurece la lectura de claves, longitudes de firma y ciertos campos. Su anexo C afirma que los bytes de los registros no cambiaron respecto de la versión 00; cambia qué entradas rechaza el verificador. Eso mejora el rigor de una revisión posterior. No fusiona el presupuesto que quedó repartido entre dos historias.

El propio documento ubica su función después de los hechos. No especifica un ejecutor que bloquee una orden antes de que produzca efecto. En la tabla de ejemplo, cuando el total de 230 libras se marca como excesivo, la acción que lo elevó ya está registrada. El dictamen permite reconstruir una violación y pedir explicaciones. Para impedir la compra, alguien debe reservar saldo antes de autorizarla y denegar el segundo uso del dinero, incluso si otra máquina recibe la solicitud al mismo tiempo.

Tampoco conviene confundir las piezas de la carpeta. Una contrafirma indica que se usó la clave que el permiso atribuye a un servicio; la sección de seguridad explica que no identifica por sí sola a quien posee esa clave. Una aprobación se refiere a una acción exacta. La cabeza firmada da integridad a una secuencia cubierta. La factura final necesita otra operación: reunir todos los usos del mismo permiso y resolver sus carreras. Un informe que omite esa operación puede ser matemáticamente exacto y financieramente inútil.

El árbol conserva lo que le entregaron

La propuesta usa el árbol de Merkle de la RFC 9162. Una prueba de consistencia puede demostrar que un árbol creció sin reescribir su pasado; una cabeza conservada fuera del registrador ayuda a detectar alteraciones y recortes de la historia cubierta. Son propiedades valiosas. Si hay dos árboles separados, la integridad de cada uno no dice cuánto presupuesto gastó el otro. La pregunta que debe recibir una respuesta es cuál de los árboles comparte el límite, y quién impide que ambos acepten la última libra disponible.

El autor identifica otros riesgos en la misma sección: una cabeza final puede desaparecer sin dejar señal si nadie más la conserva; el registrador puede mostrar vistas divergentes; el texto no define una prueba de consistencia entre esas vistas. La falta de suma entre libros es incluso más sencilla: dos historias honestas de 125 libras ya bastan para romper el límite de 200. La avería reside en la unidad de cuenta, no en un ataque criptográfico.

Hay software, pero el alcance declarado importa. La sección de implementación presenta bibliotecas JavaScript y Python escritas por el mismo autor, una verificación SLH-DSA aún ausente en Python y un problema con atributos de sellos de tiempo. No enumera una implementación independiente conocida. La prueba que falta para el control de gasto es concreta: dos registradores con peticiones simultáneas, una sola reserva compartida y un informe que reproduzca tanto el rechazo del exceso como el conjunto íntegro de recibos.

Sources