← Todas las entradas

10 min de lectura

¿Es Label 309 de código abierto?

Sí. Label 309 es un estándar abierto de prueba de existencia: el código está bajo Apache-2.0, la especificación bajo CC-BY-4.0, y cualquiera puede implementarlo, bifurcarlo, ejecutar un gateway y crear productos sin pedir permiso a CardanoWall.

Sí. Label 309 es un estándar abierto, no la trinchera privada de un producto. El código se publica bajo la licencia Apache-2.0, la prosa de la especificación bajo Creative Commons Attribution 4.0 (CC-BY-4.0), y todo ello vive en repositorios públicos en github.com/cardanowall. Desarrolladores, empresas, investigadores y la comunidad de Cardano en general pueden implementarlo, auditarlo, bifurcarlo, crear productos sobre él y operar su propia infraestructura sin pedirle nada a CardanoWall.

De eso se trata, precisamente. CardanoWall es el primer producto pulido construido en torno al estándar. Y, deliberadamente, no es el único producto que puede usarlo.

¿Es de verdad un estándar si lo creó un solo producto?

Puede serlo, pero solo si el trabajo se puede usar fuera de ese producto.

Un estándar de prueba de existencia debería sobrevivir a la empresa que primero le pone una interfaz bonita. Si un registro solo puede producirlo un sitio web, verificarlo un servidor o entenderlo un backend privado, no es un estándar público. Es una funcionalidad.

Label 309 toma el camino opuesto:

  • el formato del registro está documentado por completo;
  • la prueba vive en los metadatos de la transacción de Cardano bajo la etiqueta de metadatos 309;
  • la verificación funciona a partir de datos públicos de la cadena y claves locales, sin ningún servidor del emisor de por medio;
  • las herramientas —los SDK, la herramienta de línea de comandos, la aplicación de escritorio y el gateway— se publican como software de código abierto;
  • los gateways puede operarlos cualquiera, no solo CardanoWall;
  • los clientes pueden ser aplicaciones web, aplicaciones de escritorio, herramientas de línea de comandos, integraciones con el SDK o sistemas internos de una empresa.

CardanoWall puede seguir ofreciendo la experiencia alojada más sencilla. Pero la prueba en sí no depende de que CardanoWall sea de confianza, esté en línea o participe comercialmente. Para ver esa independencia paso a paso, consulta cómo verificar un registro Label 309.

¿Esto es CIP-309?

Aquí las palabras exactas importan, así que conviene ir con cuidado.

La propuesta de prueba de existencia se ha presentado al proceso CIP de Cardano y está bajo revisión por parte de los editores de CIP como propuesta de la categoría Metadata. Como el registro usa la etiqueta de metadatos 309 de Cardano, a veces se le llama informalmente «CIP-309», pero la etiqueta de metadatos no es el número del CIP. Son dos identificadores distintos. En la pull request abierta, la propuesta aparece por ahora con un número tentativo, listada como «CIP-0190? | Proof of Existence Transaction Metadata». Puedes seguir la discusión en la pull request del CIP.

Hasta que concluya la revisión, los nombres correctos son Label 309, etiqueta de metadatos 309 o la propuesta de CIP de prueba de existencia. Todavía no es un estándar de Cardano aceptado ni oficial, y no existe ningún «CIP-309» asignado.

El compromiso con el código abierto no depende del número final del CIP. El principio que lo sustenta es más simple: la comunidad debe poder leer, implementar, probar y reutilizar el estándar sin la aprobación privada del autor original.

¿Qué les da el código abierto a los desarrolladores?

Convierte el estándar de una promesa en algo que puedes inspeccionar y ejecutar tú mismo.

Para los desarrolladores, el código público significa que puedes:

  • leer la implementación en lugar de deducir el comportamiento a partir del material de marketing;
  • ver exactamente cómo se codifican, firman, sellan y comprueban los registros;
  • reutilizar los SDK (TypeScript, Python y Rust) en tus propias aplicaciones;
  • crear sobre ellos herramientas de línea de comandos a medida, paneles, verificadores y utilidades de subida;
  • conectar la publicación de pruebas con CI/CD, sistemas de cumplimiento, flujos de trabajo legales o canalizaciones de contenido con IA;
  • ejecutar pruebas de conformidad sobre tu propia implementación, validadas contra vectores de prueba canónicos compartidos;
  • reportar problemas o proponer cambios de forma abierta;
  • bifurcar el código si necesitas una forma de producto distinta.

Esto importa porque la prueba de existencia es infraestructura, y la infraestructura se gana la credibilidad cuando otras personas pueden construir sobre ella sin un apretón de manos privado. Integrar al nivel más bajo —operar tu propio gateway— es un camino con soporte, no un apaño.

¿Qué permite la licencia Apache-2.0?

Apache-2.0 es una licencia de código abierto permisiva, y cubre el código: los SDK, la herramienta de línea de comandos, el gateway, el verificador y los esquemas.

En términos prácticos, te permite usar, modificar, distribuir y construir sobre el código licenciado —incluso en productos comerciales— siempre que respetes los términos de la licencia. También concede una licencia de patente explícita por parte de quienes contribuyen, lo cual es una de las razones por las que es una elección habitual para infraestructura y herramientas de desarrollo. Puedes leer el texto completo en apache.org/licenses/LICENSE-2.0.

Eso le encaja bien al software de Label 309:

  • los SDK deben ser fáciles de incrustar;
  • las herramientas de línea de comandos deben ser fáciles de empaquetar;
  • el código del gateway debe ser fácil de autoalojar;
  • los verificadores deben ser fáciles de ejecutar de forma independiente;
  • las empresas deben poder lanzar productos sin negociar un permiso a medida.

El código abierto no significa «sin condiciones». Los avisos de licencia, los archivos de atribución y los términos de patente siguen aplicándose. Significa que el permiso viene de la propia licencia, no de una conversación privada con CardanoWall.

¿Por qué la especificación está bajo una licencia Creative Commons?

La licencia del código y la licencia de la especificación son decisiones separadas, y Label 309 hace ambas explícitas.

El código, los esquemas, la gramática CDDL y los vectores de prueba de conformidad están bajo Apache-2.0. La prosa de la especificación, legible por humanos, está licenciada bajo Creative Commons Attribution 4.0 (CC-BY-4.0). Una licencia de documentación le encaja mejor al texto de la especificación porque el objetivo es la reutilización amplia: por parte de quienes implementan, educadores, autores de carteras, operadores de gateways, auditores, empresas y otras personas que escriben estándares. CC-BY-4.0 mantiene la atribución a la vez que permite esa reutilización amplia.

Esta división es intencionada y ya está zanjada en el repositorio; no es una cuestión abierta a la espera de resolverse antes del lanzamiento. Los derechos se ceden a la comunidad para que construir sobre Label 309 nunca requiera un permiso privado. Si se espera que la comunidad implemente el estándar, necesita una licencia que claramente le deje hacerlo.

¿Puede alguien crear un producto competidor?

Sí, y eso no es un fracaso del estándar. Es la prueba de que el estándar es lo bastante abierto como para importar.

Alguien podría crear:

  • otro gateway alojado;
  • un gateway local para uso interno de una empresa;
  • un gestor de pruebas centrado en el escritorio;
  • un verificador de Label 309 nativo de una cartera;
  • un panel de pruebas para uso legal;
  • una canalización de procedencia con IA;
  • un puente de atestación para CI/CD;
  • un archivo de cumplimiento;
  • un explorador público de registros Label 309;
  • un cliente móvil para recibir registros sellados.

Algunos de ellos competirían con CardanoWall. Otros lo complementarían. Otros servirían a sectores en los que CardanoWall nunca se centra. Todo eso es sano: un estándar de pruebas se vuelve más fuerte cuando muchas herramientas independientes pueden producir y verificar el mismo tipo de registro.

¿Qué sigue siendo propio de CardanoWall?

El código abierto no borra la línea que separa un estándar de un producto.

El formato del registro Label 309, los SDK, la herramienta de línea de comandos, el código del gateway y la lógica de verificación están abiertos para que cualquiera los use. CardanoWall sigue teniendo su propio servicio alojado, interfaz de usuario, precios, soporte, políticas operativas, marca, dominio y hoja de ruta de producto, y eso sigue siendo suyo.

Esa distinción protege a ambas partes:

  • los usuarios obtienen un producto alojado cómodo;
  • los desarrolladores obtienen infraestructura reutilizable;
  • las empresas pueden autoalojar cuando necesitan control;
  • la comunidad puede verificar y ampliar el estándar;
  • CardanoWall sigue construyendo un producto sin que el protocolo dependa de una sola empresa.

La marca no es el estándar. El servicio alojado no es el estándar. El estándar es el formato del registro y las herramientas interoperables que lo rodean.

¿Por qué importa el código abierto para la confianza?

Los sistemas de prueba se debilitan con facilidad mediante dependencias ocultas.

Si tienes que confiar en la base de datos de un proveedor para saber si existe una prueba, el sistema es más débil. Si un registro no se puede verificar sin una cuenta alojada, la prueba es menos portátil. Si otro desarrollador no puede implementar el mismo formato, el ecosistema no puede comprobar de forma independiente si el formato es sólido. El código abierto elimina esas trampas.

Con Label 309, cualquiera puede partir de datos públicos de Cardano, recuperar el registro, validar su estructura, recalcular los hashes, comprobar las firmas, abrir cargas selladas localmente cuando es un destinatario previsto y confirmar pruebas de inclusión de Merkle cuando un solo registro representa a muchos archivos. CardanoWall puede hacer que ese flujo de trabajo resulte agradable; el estándar abierto lo hace independiente.

¿Qué significa esto para las empresas?

Para las empresas, el licenciamiento abierto reduce el riesgo de adopción.

Una empresa podría empezar con el gateway alojado de CardanoWall porque es rápido. Más adelante, esa misma empresa podría necesitar operar un gateway en su propia nube, conectar sistemas de identidad internos, archivar pruebas bajo una política de retención legal o publicar miles de compromisos de Merkle desde una canalización privada. Un estándar abierto hace que ese camino sea realista.

La elección no es «usar la interfaz alojada para siempre» frente a «reescribirlo todo desde cero». Una empresa puede empezar con CardanoWall, añadir automatización con el SDK o la API, mover algunos flujos de trabajo a la herramienta de línea de comandos y, con el tiempo, operar su propio gateway si la política o la escala lo exigen. Ese camino gradual es lo que necesita una infraestructura seria.

¿Qué significa esto para los usuarios de a pie?

Para la mayoría de la gente, el código abierto no consiste en leer código todos los días.

Significa que las herramientas que rodean tus pruebas son menos frágiles. Si publicas una prueba hoy, no deberías necesitar que un sitio web concreto siga en línea para darle sentido mañana. Otras herramientas pueden verificar el registro. Otros clientes pueden abrir registros sellados cuando tienes la identidad correcta. Otros gateways pueden publicar pruebas compatibles. En la práctica, ya puedes usar CardanoWall sin el sitio web a través de la herramienta de línea de comandos y los SDK abiertos.

La experiencia puede ser sencilla porque el producto está pulido. La confianza a largo plazo viene de que el formato no quede atrapado dentro de ese producto.

¿Qué no deberías confundir con el código abierto?

El código abierto es útil, pero no es magia, y no resuelve por sí solo todas las cuestiones.

No significa que todo servicio alojado sea gratis: un gateway sigue pagando comisiones de red de Cardano, almacenamiento en Arweave, infraestructura y costes operativos. No significa que la marca o las marcas registradas de CardanoWall puedan usarse de forma engañosa. No significa que toda pull request se acepte. Y no significa que una implementación sea segura solo porque sigue el mismo estándar.

Tampoco sustituye a la diligencia debida. Antes de confiar en una implementación en producción —la tuya o la de otra persona— conviene comprobar:

  • los archivos de licencia reales del repositorio;
  • la licencia de la especificación;
  • el estado de la propuesta de CIP;
  • el estado de las versiones del SDK y del gateway;
  • el modelo de seguridad para identidades, sellado y claves de destinatario;
  • las pruebas de conformidad contra las que se valida la implementación.

La promesa del código abierto no es que nadie tenga que comprobar nada. La promesa es que comprobar es posible.

La versión corta

Label 309 es abierto en cada capa que importa para la interoperabilidad. El código está bajo Apache-2.0. La especificación está bajo CC-BY-4.0. El gateway es autoalojable. La verificación funciona sin confiar en CardanoWall. Quienes desarrollan tienen libertad para crear sus propias herramientas y productos.

CardanoWall es el primer producto completo. El estándar pertenece al ecosistema.

Para seguir leyendo

label-309open-sourcestandards