Kadena es una plataforma de contrato inteligente en vivo de servicio completo y la primera cadena de bloques pública escalable, fragmentada y de nivel 1 de Prueba de trabajo.
Aquí en Kadena, hemos terminado el corte inicial de nuestra integración con Rosetta, un nuevo marco técnico de código abierto que acaba de ser lanzado por Coinbase. Como uno de los primeros proyectos en trabajar en Rosetta, estamos aprovechando esta oportunidad para compartir lo que aprendimos de la experiencia. El proyecto Rosetta es bastante nuevo, y nuestro equipo quería dejar algunas migas de pan para aquellos que nos sigan en busca de lograr una integración similar con uno de los intercambios más populares y respetados del mundo. Puede encontrar la implementación de Rosetta basada en Haskell de Kadena aquí.
Rosetta es una API estandarizada para interactuar con datos financieros en blockchains. El objetivo de Rosetta es permitir que los proyectos de blockchain completen la mayor parte del trabajo de integración necesario para conectarse a un intercambio, lo que permite un proceso de listado de intercambio más fluido tanto para emisores como para intercambios.
De manera similar a la forma en que el Protocolo de Minería Stratum permitió la estandarización de la minería agrupada, Rosetta tiene como objetivo crear un conjunto común de llamadas y respuestas bien entendidas de los nodos de blockchain que pueden ser utilizadas por cualquier persona que se adhiera al estándar API.
Una de las facetas más atractivas de cómo Coinbase ha desarrollado Rosetta es que podríamos elegir nuestro propio camino para descubrir cómo satisfacer la especificación. El software de Kadena para el protocolo Chainweb está escrito en Haskell, y decidimos que, en lugar de crear un paquete nuevo y separado para Rosetta, expandiríamos nuestro paquete de nodos existente (Chainweb Node) para admitir completamente Rosetta. De esta manera, un intercambio que espera información de nuestra cadena de bloques en forma de llamadas de Rosetta puede ejecutar un nodo completo de Chainweb normal y saber que recibirán datos según las especificaciones. En el futuro, Rosetta puede graduarse para ser un proceso separado del nodo, pero por ahora, este enfoque simplifica enormemente la implementación.
La especificación de Rosetta tiene una estructura JSON rígida y estandarizada como parte de sus definiciones de API, por lo que el uso de un lenguaje fuertemente tipado como Haskell nos facilitó la representación nativa de los datos y nos garantizó que siempre devolviéramos el formato correcto de la carga útil.
Una de las oportunidades más desafiantes que enfrentamos con Rosetta fue la interpretación de la documentación, en lugar de la implementación. Debido a que Rosetta apunta a ser independiente de blockchain, a menudo tuvimos que traducir entre diferentes estilos de terminología, que no parecían aplicarse a Kadena o usar etiquetas diferentes de las que esperábamos.
Kadena usa un modelo basado en cuentas para rastrear tokens en lugar de un modelo basado en UTXO como Bitcoin. Además, a diferencia de Ethereum, por ejemplo, Kadena tiene abstracción entre el nombre de una cuenta y las claves asociadas con una cuenta. Funcionalmente, esta característica permite a los usuarios de Kadena proteger sus cuentas con lo que llamamos "guardias". Los guardias pueden ser desde una función hasta un "conjunto de teclas" (una lista de teclas múltiples) o incluso una sola tecla. Los guardias pueden representar múltiples firmas requeridas, o pueden tener vencimientos y condiciones de tiempo. Para obtener más información sobre el sistema de guardia de Kadena, consulte este artículo.
Naturalmente, Rosetta no tiene disposiciones específicas en la especificación para el paradigma de protección de conjunto de claves de la cuenta de Kadena, por lo que a veces tuvimos que ser creativos al convertir las palabras en la documentación en lo que pensábamos que era la intención antes de determinar cómo nos integraríamos con Rosetta Dada nuestra arquitectura única.
Por ejemplo, Rosetta usa el modelo AccountIdentifier para asociar la cuenta de un usuario en un intercambio a la cuenta equivalente en blockchain. Tiene tres propiedades, "dirección", "subcuenta" y "metadatos".
Para Kadena, "dirección" es un nombre de usuario, al que llamamos nombre de cuenta. Por lo tanto, las instrucciones para "metadatos" sugieren que, dado que estamos utilizando un modelo de nombre de usuario, proporcionaremos en metadatos un blob de Objetos que contenga todas las claves públicas asociadas con el campo de dirección. (Tenga en cuenta que la especificación supone que la dirección "posee" una clave pública, pero Kadena no tiene un paradigma en el que una dirección tenga el control exclusivo de una clave. Para Kadena, un usuario puede firmar muchas cuentas diferentes con la misma clave, conjuntos de teclas, protectores de teclas, etc.)
Este campo de "metadatos" nos causó un poco de enigma. No solo es posible tener múltiples conjuntos de claves asociados con una dirección y muchas direcciones asociadas con los mismos conjuntos de claves, sino que bajo el paradigma de "protección", también puede tener múltiples bloqueos de tiempo diferentes u otras funciones que protegen una cuenta.
Al final, resolvimos este problema de la manera más detallada posible: en el objeto de metadatos AccountIdentifier, devolvemos un blob de todos los conjuntos de claves y guardias asociados con la cuenta y asumimos que el solicitante sabe lo suficiente sobre el paradigma de guardia de Kadena para saber qué te estas poniendo.
El trabajo más pesado que tuvimos que hacer para implementar Rosetta fue desarrollar la solicitud de bloqueo. La expectativa con la solicitud de Bloqueo es que devolverá cada operación de cambio de saldo en un bloque. A primera vista, esa expectativa parece trivial, pero para una transacción de blockchain, el número de operaciones de cambio de saldo comienza a explotar con bastante rapidez.
Considere un contrato inteligente en el que desea ejecutar una operación simple, como sumar los números 1 y 2. Aquí solo hay una transacción: el contrato inteligente que contiene “(+ 1 2)”. No se produce la transferencia de tokens, pero debido a las tarifas de gas, la respuesta a la solicitud de bloqueo se representa como tres operaciones separadas: 1) La cuenta del remitente recibe tokens debitados para ejecutar la transacción, 2) al minero se le acredita la tarifa de gas, y 3 ) El remitente se acredita por cualquier tarifa de gas no utilizada, ya que el gas se estima en el front-end y se concilia en el back-end de cada transacción.
Ahora imagine la complejidad involucrada en una transacción de "transferencia-creación", en la cual el remitente está creando una nueva cuenta y transfiriendo fondos a esa nueva cuenta, todo en una sola transacción: el nivel de complejidad es bastante alto. La interfaz también debe tener en cuenta no solo las operaciones realizadas utilizando los contratos inteligentes prefabricados incluidos en el Contrato de monedas de Kadena, sino también cualquier contrato inteligente arbitrario escrito por los usuarios con el lenguaje de contrato inteligente del Pacto.
Para nuestro equipo, implementar Rosetta fue una forma útil de examinar nuestros puntos finales de datos existentes desde la perspectiva de un intercambio: la especificación de Rosetta es un proxy para saber qué importan los intercambios cuando solicitan datos de una cadena de bloques. Descubrimos que los datos que pensábamos que serían útiles no se solicitaban en absoluto y vimos que estábamos limitados en varias áreas que no habíamos previsto. La implementación de Rosetta se sintió como un control de salud para nuestra API, y nuestros puntos finales de Chainweb Node definitivamente se hicieron más estrictos con el trabajo completado.
Será interesante ver qué otros proyectos e intercambios adoptan Rosetta con el tiempo, cómo sus experiencias reflejan y difieren de las nuestras, y cómo evolucionará la especificación. Como industria, generalmente hemos otorgado una importancia superior a la innovación y la divergencia, pero Rosetta parece una oportunidad para que todos nos beneficiemos de alguna estandarización que puede resultar en una mayor adopción.
