El Foro de Coordinación KCC de Kaspa ha finalizado tres estándares que cubren interfaces de covenant, autorización y tokens fungibles, estableciendo especificaciones compartidas para desarrolladores que construyen aplicaciones en la red.
Resumen
- KCC-1 define interfaces compartidas para billeteras, compiladores, indexadores y otras herramientas que trabajan con covenants.
- KCC-2 especifica cinco esquemas de autorización estándar, incluidos claves públicas, scripts e identificadores de covenant.
- KCC-20 establece reglas de transferencia de tokens y admite la recepción de tokens a través de una salida compatible existente.
- La finalización establece convenciones del ecosistema sin cambiar las reglas de consenso ni requerir que cada participante las adopte.
El Foro de Coordinación KCC dijo en un anuncio del 21 de octubre que KCC-1, KCC-2 y KCC-20 eran definitivos y estaban listos para su adopción en todo el ecosistema. El foro invitó a los constructores a unirse a su canal público para preguntas, discusiones de implementación y soporte.
El repositorio de estándares canónicos de Kaspa enumera los tres documentos como Definitivos. Su índice identifica KCC-1 como la especificación de covenant, KCC-2 como la especificación de autoridad y KCC-20 como el estándar de aplicación para covenants de tokens fungibles.
El repositorio describe los KCC como convenciones compartidas para implementaciones independientes. Su documentación separa esas convenciones de los cambios en el consenso o en el comportamiento del nodo central, que pertenecen a las Propuestas de Mejora de Kaspa.
Los estándares de Kaspa cubren diferentes partes del desarrollo de aplicaciones
KCC-1 define términos comunes, diseños de datos y una interfaz binaria de aplicación, o ABI, para covenants. La especificación describe cómo el software codifica información, llama a funciones de programa e identifica el estado transportado entre transacciones.
Sus autores, Romain Billot, Michael Sutton y Ori Newman, identifican compiladores, billeteras, indexadores y constructores de transacciones entre las herramientas que necesitan ponerse de acuerdo sobre esos detalles. El documento afirma que las implementaciones independientes necesitan formatos comunes más allá de simplemente producir scripts que pasen las verificaciones de consenso.
La especificación KCC-1 deja a los desarrolladores en libertad de elegir su lenguaje de programación, compilador y framework. Su interfaz compartida cubre puntos de entrada de programa, plantillas de estado y reglas para manejar transacciones que involucran múltiples entradas.
Dentro del mismo documento, los autores distinguen las reglas básicas de interfaz de las características que dependen de identificadores de covenant. Los programas sin vinculaciones de covenant pueden seguir KCC-1, pero la especificación dice que no reciben las garantías de linaje y autorización proporcionadas por KIP-20.
KCC-2 define quién puede autorizar una operación
KCC-2, escrito por Billot y Sutton, especifica cómo los programas identifican una autoridad y las verificaciones mínimas requeridas para establecer su aprobación. Una autoridad puede ser una clave pública, un compromiso a una clave, un script o un linaje de covenant continuo.
La especificación asigna identificadores estándar a cinco esquemas de autorización. Sus opciones de clave pública cubren firmas Schnorr y ECDSA, mientras que sus otras opciones permiten que un script o un linaje de covenant participe como autoridad.
Para la autorización de hash de clave pública, KCC-2 requiere que la transacción revele la clave pública correspondiente, compare su hash con el valor de autoridad almacenado y proporcione una firma válida. Las especificaciones de nivel superior definen el mensaje firmado y cualquier condición adicional.
El registro de autoridades reserva rangos separados para esquemas estándar y personalizados. KCC-2 permite a los participantes adoptar esquemas personalizados sin esperar a la estandarización, siempre que sus definiciones especifiquen el formato, el significado y las verificaciones de aprobación.
Según su esquema de identificador de covenant, la aprobación requiere una entrada del linaje de covenant identificado. KCC-2 dice que una convención de nivel superior puede imponer verificaciones adicionales sobre el programa y el estado de esa entrada.
KCC-20 establece las reglas de transferencia y recepción de tokens
KCC-20 se basa en los dos primeros estándares, definiendo las cantidades de tokens, la propiedad y las interfaces de transferencia. El documento nombra a Sivan Helfer, Sutton, Newman y Billot como sus autores.
Su especificación requiere que cada covenant de token publique información del programa que el software pueda usar para decodificar el estado y construir transferencias. Las configuraciones deben divulgar los esquemas de propiedad admitidos y los límites en las entradas y salidas de tokens.
Una característica llamada recepción prestada permite a un remitente usar una salida de token compatible existente del destinatario como destino. KCC-20 indica que la transacción recrea esa salida con más tokens, preserva su propiedad y estado extendido, y no puede reducir su valor en KAS.
La sección de seguridad advierte que reemplazar la salida cambia su referencia de transacción, invalidando las transacciones no confirmadas que gastan la referencia anterior. Según el documento, una billetera debe descubrir el reemplazo antes de gastarlo.
El estándar vincula una implementación de referencia de Argent con contratos SilverScript generados y pruebas de conformidad en Rust.
El estado final conlleva requisitos de implementación
KCC-0, el documento que rige el proceso de estándares, exige más que la simple finalización de un período de revisión final. Afirma que una convención de la vía de estándares necesita vectores de prueba legibles por humanos y legibles por máquinas, además de al menos una implementación pública que pase las comprobaciones legibles por máquinas.
Según las mismas reglas, las dependencias deben estar en estado Final para otros KCC o en estado Activo para los KIP. KCC-0 indica que los cambios de estado se producen mediante pull requests y que el índice del repositorio debe actualizarse con ellos.
KCC-0 describe los vectores de prueba legibles por máquinas como la forma autoritativa para las pruebas automatizadas cuando acompañan a ejemplos legibles por humanos. Sus reglas de presentación requieren que las consideraciones de seguridad aborden las amenazas, los supuestos de confianza y los posibles problemas de repetición antes de que un documento de la vía de estándares pueda entrar en Last Call.
El documento rector establece que la finalización no requiere que todos los participantes del ecosistema implementen una convención. Los cambios sustanciales generalmente requieren un KCC de reemplazo, mientras que las correcciones y aclaraciones siguen las reglas de enmienda del documento.
El desarrollo de aplicaciones de Kaspa ha incluido anteriormente infraestructura de Capa 2 separada. Gate anunció una integración de Kasplex Layer 2 en abril, habilitando depósitos y retiros de KAS a través de la red compatible con EVM, según informó crypto.news.
En su anuncio de integración anterior, Gate dijo que los clientes podían transferir KAS desde la red base a una billetera Kasplex. Los materiales del proyecto de Kasplex describen un puente bidireccional y afirman que los desarrolladores familiarizados con las herramientas de Ethereum pueden desplegar contratos cambiando sus puntos de conexión de llamada a procedimiento remoto.
Kasplex describe su diseño como un rollup ligero que coloca el bytecode de EVM en transacciones de Kaspa y lo ejecuta fuera de la cadena. Su documentación indica que Kaspa proporciona el ordenamiento de transacciones y la disponibilidad de datos, mientras que el KAS puenteado sirve como token de gas de la Capa 2.
