Saltar al contenido
ecbyts

← Todas las novedades

Arquitetura

Registro seguro y trazable: dónde entra el blockchain y dónde no hace falta

Lectura estimada: 15 min

  • Guía
  • Tour

En una planilla común se puede borrar el número de ayer, escribir otro encima y guardar. No queda registro de quién lo tocó, cuándo lo tocó ni cuál era el valor original. Esta nota muestra, en lenguaje simple, cómo ecbyts cierra ese hueco — con libro de registro a lapicera, sello digital de cada paquete y cofre separado por empresa — y dónde la cadena de sellos ya funciona hoy y dónde todavía es un plan para el futuro.

Sello ECBYTS sobre curvas de nivel, con la franja Demostración, datos ficticios y la dirección del tour guiado.

Quien alguna vez revisó un estudio ambiental conoce la escena. La planilla final trae un número, el PDF trae otro, y nadie sabe cuál de los dos es el verdadero. La lectura de campo se corrigió por teléfono y el archivo sigue con el valor antiguo. Alguien abrió el documento, cambió una coordenada, guardó encima y cerró. No hay registro de quién lo hizo, cuándo, ni por qué.

Conviene empezar por el problema, sin términos técnicos. Piense en una planilla común. Guarda un número por celda y no guarda nada más. Por eso, cualquiera que tenga el archivo puede borrar el número de ayer, escribir otro en su lugar, guardar y cerrar. El número anterior desaparece. No queda marca de quién lo tocó, ni de qué día lo tocó, ni de cuál era el valor antes. La planilla no tiene memoria del pasado: muestra solo lo que está escrito ahora.

ecbyts existe para cerrar ese hueco. Hace cuatro cosas, descritas más abajo con ejemplos del día a día: guarda cada cambio en un libro de registro a lapicera, cierra cada paquete con un sello digital, separa los datos de cada empresa en cofres propios y amarra cada número al lugar, al momento, al método y a la regla que lo produjeron.

Y hay un tema del que casi todos hablan y pocos separan con honestidad: el blockchain. En esta nota la palabra aparece en dos situaciones muy distintas. En una, la cadena de sellos ya funciona dentro de la propia clave de ecbyts. En la otra, que es enviar el sello a una red pública, es un plan para el futuro — y eso queda dicho con todas las letras más abajo.

Qué falla hoy

Tres fallas aparecen en casi toda gestión ambiental hecha con planilla y carpeta compartida:

  1. Edición sin historial. La planilla muestra el estado de ahora y solo eso. El valor anterior, quién lo cambió y el motivo se pierden en el instante en que alguien guarda encima.
  2. Versiones que no coinciden. El PDF entregado al organismo salió de una tabla que ya cambió después. Los dos documentos existen, los dos parecen oficiales, y no hay vínculo que se pueda revisar entre ellos.
  3. Lectura de campo alterada sin rastro. Una medición se ajusta después de la campaña y nada indica que el número registrado antes era otro.

En auditoría, la pregunta que traba el proceso es siempre la misma: ¿cómo prueba que este número es el mismo que se registró aquel día? La respuesta honesta, con el modelo de hoy, es: por la confianza en quien guarda el archivo. Eso no es prueba, es un acuerdo entre las partes.

Qué hace ecbyts en la base

ecbyts trata cada paquete de modelo como un documento cerrado, con identidad propia. Son cuatro mecanismos, y cada uno resuelve una parte distinta del problema.

Libro de registro a lapicera, sin goma de borrar

El rastro de auditoría del sistema solo crece. Funciona como un libro de caja en el que solo se escribe a lapicera: nada se borra y ninguna línea se reescribe. Si un número necesita corrección, la corrección entra como una línea nueva debajo, diciendo qué cambió, quién lo cambió, en qué momento y por qué motivo. La línea antigua sigue ahí, visible.

Eso cambia la naturaleza de la pregunta. En lugar de "¿jura que no lo tocó?", la conversación pasa a "muestre el libro". Si alguien alteró un dato, aparece. Si nadie lo alteró, también aparece, porque el silencio queda registrado.

Sello digital de cada paquete

Todo paquete de modelo exportado recibe un sello digital: un código generado a partir del contenido completo del paquete. Funciona como un código de barras matemático del documento. El mismo contenido genera siempre el mismo código, y el cambio de una sola letra o de un solo decimal cambia el código por completo, en el acto.

El detalle que importa es este: el sello se calcula sobre el contenido del paquete, no sobre la imagen del PDF. Por eso dos versiones se pueden comparar sin lectura visual, tramo por tramo. Basta generar el sello de los dos archivos y comparar: sello igual significa contenido exactamente igual; sello distinto significa que algo cambió. Para quien quiera la referencia técnica, ese sello es la huella conocida como SHA-256.

Existen cuatro tipos de paquete. La letra dice solamente cómo se arma y se cierra el paquete, no qué tipo de dato guarda. Para entenderlo ayuda pensar en cuatro maneras de cerrar y enviar un documento:

  • Paquete A — el paquete simple. Es la forma básica: el contenido del modelo se organiza, se comprime y se cierra, con una revisión de integridad que solo verifica si los datos llegaron enteros. Sirve para guardar y abrir el modelo en el día a día.
  • Paquete B — el paquete encadenado. Es la forma reforzada. Lleva cuatro elementos propios: un código corto que identifica esa clave (el identificador de la clave); el sello de la versión anterior, que arma una cadena de versiones donde cada paquete apunta al que vino antes; un índice de cada ítem del modelo, que muestra exactamente qué ítem cambió sin necesidad de releer el modelo entero (la referencia técnica es árbol de verificación, o Merkle); y la firma digital de quien emitió el paquete, que funciona como una firma personal que nadie puede copiar a otro documento.
  • Paquete C — el paquete comprimido. Es la versión optimizada para ocupar menos espacio, usada cuando hay un límite de tamaño para enviar o guardar.
  • Paquete D — el paquete cerrado con llave. Es la versión cerrada con clave, para cuando el contenido solo puede abrirlo gente autorizada. Ahí entra el cifrado. El envío de este tipo de paquete es opcional y solo se enciende cuando la institución decide usar ese recurso.

Volviendo a la imagen principal: dentro del paquete encadenado, la cadena de sellos se arma y se revisa en el propio navegador de quien exporta, sin depender de internet. Cada versión lleva el sello de la anterior; la primera lleva la marca de inicio. Cambiar una versión antigua rompe la cadena, y la revisión muestra en qué eslabón se rompió. Cada número también queda amarrado a la firma personal de quien emitió: tocar el contenido invalida la firma. Es como un sello de notaría que se rompe si alguien cambia una coma del documento.

Qué ya está en funcionamiento y qué todavía es un plan

Conviene separar las capas, porque la diferencia es grande:

  • Ya funciona hoy, dentro de la propia clave de ecbyts y en el servidor de la plataforma: la cadena de sellos entre versiones, el índice de ítems del modelo y la firma digital de quien emitió, además del registro del sello en el servidor.
  • Todavía no está encendido: el envío de cualquier información a una red pública externa, de esas de criptomoneda, como Ethereum o Polygon. En la base de datos, el campo que señala ese uso está apagado. Los créditos ambientales también siguen en fase de diseño, sin existir dentro de la aplicación.

Un cofre separado por empresa

Cada empresa ve solamente sus propios datos. El punto importante es dónde se aplica esa separación: en la puerta de la propia base de datos, y no solo en la pantalla del sistema. La pregunta "¿esta persona puede ver esta línea?" la responde la base de datos en cada consulta, y no la buena voluntad del programa que pidió la consulta.

La diferencia práctica es grande. Un reporte nuevo, una consulta mal escrita o un pedido olvidado en medio del sistema no filtran datos de otra empresa, porque la traba no depende de quién escribió la consulta. Es la misma lógica de los niveles de visibilidad que se usan al leer el Sello ECBYTS: quien no tiene autorización recibe solo lo que la regla permite, y cada acceso queda registrado.

Cada número amarrado al lugar, al momento, al método y a la regla

Un número ambiental solo no dice nada. Significa algo únicamente junto con cuatro informaciones: dónde y cuándo se midió, dentro de qué campaña de muestreo, por qué método de análisis, y bajo qué regla se interpretó.

En ecbyts, ese vínculo se graba como parte del dato, y no como nota al pie. Cambiar el método de análisis de una medición, o reinterpretar un resultado bajo otra versión de regla, no reescribe el registro antiguo: crea un vínculo nuevo, y el vínculo anterior sigue disponible para consulta. La figura siguiente muestra cómo el resultado, la regla y los responsables aparecen juntos en un modelo de demostración.

Sello ECBYTS anotado con las seis capas de lectura, numeradas de 1 a 6, en modelo de demostración con datos y responsables ficticios.

Dónde entra el blockchain

Si usted nunca escuchó hablar de blockchain, la imagen más fiel es esta: una notaría colectiva, con muchas copias repartidas, donde cada página nueva lleva el sello de la página anterior. Para cambiar una página antigua habría que rehacer todas las páginas siguientes en todas esas copias. Por eso, en la práctica, el pasado se vuelve demasiado caro de falsificar.

ecbyts ya aplica esa misma cadena de sellos en dos lugares: dentro de cada clave del tipo encadenado (el paquete B) y en el servidor de la plataforma. Y lo hace sin enviar nada a redes públicas de criptomoneda. Es esa cadena la que sostiene la revisión entre versiones, y es la que corre en producción hoy.

  • La cadena de sellos — ya funciona hoy. Cada versión del paquete lleva el sello de la versión anterior, el índice que muestra qué ítem cambió y la firma digital de quien emitió. El sello del estado cerrado también queda registrado en el servidor y en los rastros de auditoría que solo crecen.
  • El envío del sello a una red pública — todavía no. Hoy la aplicación no envía nada a una red pública como Ethereum o Polygon, y el campo de la base de datos que señala ese uso está apagado. Ese envío es el escalón siguiente, todavía no encendido. Sirve para un caso específico: probar que una información existía en cierta fecha, de un modo que convenza a alguien que no confía en ecbyts ni en el dueño del dato.
  • Los créditos ambientales en red pública — fase de diseño. El diseño de los créditos ambientales prevé ese tipo de transferencia en el futuro. Está en especificación, no en el aire, y nada de lo que existe hoy depende de eso para funcionar.

En resumen, con honestidad: la prueba que ecbyts entrega hoy es la cadena de sellos, el índice de ítems y la firma digital, sumados al sello registrado de forma inmutable en el servidor. Eso ya alcanza para revisar, dentro de la plataforma, que un número no cambió. El envío a la red pública es el escalón siguiente, previsto y todavía apagado.

Cuando ese envío se encienda, lo que sale de la plataforma es solo el código del sello — y nunca los datos. Ese código es un número que no significa nada para quien no tiene el archivo original: sin el modelo en mano, no abre nada y no revela nada de lo que hay dentro. Es el mismo principio de un sello de control de equipaje: el sello prueba que la valija es la misma, pero no muestra qué lleva adentro.

Y resuelve una sola pregunta, que es una pregunta real: probar que una información existía en cierta fecha y no cambió desde entonces, de un modo que cualquiera pueda revisar, incluso sin confiar en la plataforma. En ese escenario, tres códigos van a la red pública: el del estado del modelo en el momento en que se cerró, el del Sello ECBYTS emitido sobre ese estado, y el de los créditos ambientales cuando empiecen a existir en la aplicación.

Lo que esa revisión pública pasa a garantizar es un equilibrio de fuerzas: ni el dueño del dato ni la propia plataforma pueden reescribir el pasado en silencio. Si el contenido del paquete cambia después, el sello recalculado deja de coincidir con el sello publicado, y esa diferencia es pública y revisable por cualquier parte — incluso por quien no confía en ecbyts.

Lo que ese envío no hace, y es importante no vender lo contrario:

  • no valida si el dato es correcto, si el método es adecuado o si el número tiene sentido;
  • no reemplaza la responsabilidad técnica de quien firma;
  • no acredita cumplimiento legal ni reemplaza el pronunciamiento de un organismo ambiental;
  • no impide que alguien publique un dato equivocado. Solo prueba que ese dato equivocado es el mismo de siempre, y desde cuándo.

Una honestidad más sobre el diseño, y vale para los dos momentos. Hoy, revisar que el contenido no cambió se hace en el propio navegador, recalculando el sello y verificando la cadena y la firma: eso no depende de ninguna red. Cuando el envío a la red pública se encienda, la prueba de la fecha va a depender de esa red externa. Si el servicio está fuera de línea en ese momento, el paquete sigue válido y revisable por el sello local, pero queda sin prueba pública de fecha hasta que el envío se complete. El sistema dice "todavía no registrado en red pública" en ese caso, nunca "registrado".

Dónde el blockchain NO hace falta

La pregunta correcta no es "¿se puede poner esto en blockchain?", sino "¿qué gana algo al registrarse allá afuera?". Mandar el dato en sí a una red pública sería peor en tres frentes: cada operación cuesta dinero, cada dato tiene que circular por la red, y se pierde el control sobre información sensible. El dato ambiental crudo trae coordenada exacta, especie amenazada, documento del propietario e información de terceros. Nada de eso tiene motivo para circular fuera del ambiente controlado.

Lo que va a la red es el sello, y solo el sello. Y hay dos casos en los que ni eso ayuda:

  • Quién puede ver. El blockchain no es control de acceso. Quién ve qué se sigue decidiendo en la base de datos, con el cofre separado por empresa y la traba por línea.
  • Calidad del análisis. Asegurar que el muestreo siguió el procedimiento y que el laboratorio trabajó dentro del control de calidad es trabajo de método y de laboratorio. Ninguna red distribuida reemplaza eso.

El criterio práctico es este: si la duda es "quién puede ver", se resuelve en la base. Si la duda es "esto existía en aquella fecha", se resuelve con el sello publicado. Si la duda es "este número está bien", ninguna de las dos lo resuelve — lo resuelve la cadena técnica y analítica que produjo el número.

Privacidad y protección de datos

El diseño se hizo para que la capa pública no reciba dato personal ni dato sensible en ningún momento.

  • Lo que ya va al servidor, hoy: solo el código del sello y la fecha y la hora, en el registro del sello y en los rastros de auditoría que solo crecen. Un código de sello no permite reconstruir el contenido original.
  • Lo que va a la red pública, cuando el envío se encienda: solo el código del sello y la fecha y la hora. Nada más que eso.
  • Lo que nunca va, en ninguno de los dos casos: datos crudos, coordenadas exactas, anexos, documentos, nombres de personas y cualquier identificador del titular.
  • Lo que queda bajo control del titular: el nivel de detalle del acceso. El dueño de los datos decide qué ve cada destinatario, y ubicación exacta, aproximada u oculta es elección suya, no un estándar escondido de la plataforma.

Vale explicar por qué el código del sello no es dato personal en la práctica. Es una vía de una sola dirección: del contenido se llega al código, pero del código no se vuelve al contenido. Funciona como un sello de verificación. Quien tiene el archivo original recalcula el código y compara. Quien no tiene el archivo no obtiene nada con el código. Por eso este diseño es compatible con la regla de recoger la menor cantidad posible de información: lo que se expone es la prueba de que nada cambió, no el dato.

El titular mantiene, en cualquier momento y sin costo, el derecho a ocultar el nombre y los documentos asociados a una declaración, y la revocación del consentimiento vale para los accesos siguientes, sin borrar el historial de quienes ya accedieron dentro de la autorización. Revocar no reescribe el pasado; solo cierra la puerta de aquí en adelante.

Qué no resuelve este diseño

  • No corrige dato equivocado. Que nada haya cambiado no quiere decir que el número esté bien. Registrar un número inadecuado solo vuelve el error permanente y rastreable.
  • No reemplaza el informe ni la responsabilidad técnica. El registro revisable ordena la prueba; quien firma sigue siendo quien responde.
  • No es prueba de cumplimiento legal. El sistema ordena y comprueba que el registro no cambió y desde cuándo. Nada más que eso.
  • No garantiza disponibilidad para siempre. La revisión depende de los servicios involucrados y de que la red de registro esté accesible.
  • No es una revisión independiente de la cuenta. El servidor revisa la estructura, los responsables y los documentos, pero todavía no rehace el cálculo: los números se calculan en el navegador de quien publica y se registran como llegaron.

Lo que entrega es más modesto y más útil de lo que parece: vuelve imposible reescribir el pasado sin que la diferencia aparezca.

Para conocerlo

El tour guiado dura unos 3 minutos y corre sobre un modelo de demostración, con responsables ficticios. Ningún paso emite, cobra ni graba nada, y puedes exportar un paquete y revisar la clave de verificación en el propio navegador.

Practicar la exportación y la revisión de la clave ECBT en el tour guiado · Ver los otros tours en la Ruta de Tours

Para quienes trabajan con datos ambientales todos los días: ¿cuándo fue la última vez que necesitaste probar que un número no cambió desde la colecta — y pudiste probarlo?

← Todas las novedades