Kadena Public : Comenzando con las transferencias

Kadena comenzó a habilitar las transferencias de tokens de Kadena (KDA) el 17 de diciembre. La red ha experimentado un serio crecimiento a medida que pasamos de testnet a mainnet, con más de 1,000,000 de bloques minados por más de 10,000 GPU (a una tasa de hash promedio entre 10-15 TH / segundo) en la red principal. Hemos dependido en gran medida de la comunidad para ayudar a establecer las mejores prácticas mineras en la red.

Ahora, los tokens ganados por los mineros son transferibles hacia y desde otras cuentas (peer-to-peer). Debido a que las transferencias son una parte integral de cualquier ecosistema , hemos decidido publicar esta publicación como una introducción al sistema de contrato inteligente del Pacto. Nos gustaría ilustrar las innumerables formas de transferir tokens y resaltar algunas de las tecnologías disponibles para que los usuarios lo hagan. Desglosaremos este tutorial en tres pasos de diferentes niveles de sofisticación: usar Pact para crear un contrato inteligente, el portal de transferencia independiente y transferir con Chainweaver Wallet.

Con suerte, esto lo emocionará para comenzar su viaje con Kadena. ¡Empecemos!

El contrato de monedas de Kadena

El contrato de monedas de Kadena se puso a disposición como una transacción en la génesis, lo que significa que el token es un contrato de la misma manera que cualquier otro contrato existe en la cadena de bloques (sin embargo, es algo especial con la forma en que cada nodo Chainweb interactúa con él de forma nativa). Si bien aún no tenemos un explorador de módulos para que la gente explore el código del módulo (próximamente cuando se activan los contratos inteligentes), puede explorar la fuente y el RFC del Proceso de Mejora de Kadena (KIP-0002) para el token de activos fungible (KDA ) en el que se basa para tener una idea tanto del lenguaje del Pacto como de las operaciones fundamentales disponibles en el contrato. Las más notables entre ellas son las especificaciones sobre cómo transferir KDA hacia y desde cuentas en la cadena de bloques. Revisaremos las cuentas y los tipos de transferencias disponibles en las próximas secciones, y luego pasaremos a un tutorial sobre cómo poner en práctica las transferencias junto con algunas de las herramientas disponibles.

¿Cómo se estructuran las cuentas de Kadena?

La cadena de bloques de Kadena es única en el sentido de que cada cadena es una cadena de bloques separada para la cual se mantiene un consenso global, y no existe una noción global de "cuenta" o "dirección". Sin embargo, en cada cadena hay un registro de conjunto de claves que se asegura de que no se duplique el conjunto de claves. Esto significa que el decisor final de lo que identifica de forma única a un usuario de es su conjunto de claves en una cadena determinada (lea aquí para obtener más información sobre conjuntos de claves). Si elige que su conjunto de claves solo exista en la cadena 0, esa es su prerrogativa y está perfectamente bien. Sin embargo, los usuarios pueden encontrar que simplifica las cosas si definen su conjunto de claves en todas las cadenas para evitar confusiones, a pesar de que existe una posibilidad criptográfica nula de que alguien más pueda tener las mismas claves en una cadena diferente.

Cada contrato inteligente tiene la capacidad de mantener su propio libro mayor (un almacén de valores clave) que define las estructuras de datos con las que trabaja. En el caso del contrato de monedas, cada entrada en el libro mayor de contratos de monedas se especifica mediante un nombre de cuenta (cualquier cadena LATIN-1 entre 3 y 256 caracteres) como clave, con un valor de saldo decimal y un conjunto de claves que rige la cuenta. Los nombres de cuenta pueden ser cualquier cosa siempre que se ajusten a esa especificación. Podrías ser "Emily", "Stone Cold Steve", o simplemente la clave pública asociada con tu conjunto de claves como nombre de cuenta. Muchos usuarios consideran que este último es el más fácil de recordar. Dado que la posibilidad de superposición es insignificante, les ayuda a recordar qué claves se supone que deben usar para esa cuenta en particular. Apoyo esto, ya que las dos cuentas "emily" y "Emily" son distintas y puede ser fácil olvidar cuál es la suya. Llamamos a las cuentas que no son simplemente la cadena de clave pública "cuentas de vanidad" (como las placas de vanidad), para distinguir las convenciones de nombres.

Entonces, para resumir,

clave: nombre de cuenta -> valor: {saldo, claves}

¡Es así de simple! Ahora, hablemos sobre los tipos de transferencias disponibles con este token.

Tipos de transferencias disponibles

Le mostré cómo construir una simple transferencia de monedas, pero ahora hablemos sobre los tipos de transferencias disponibles para usted, el usuario. El contrato de monedas tiene 3 en total para abordar diferentes casos de uso:

coin.transfer: esta función es para transferencias entre dos cuentas existentes en la misma cadena, para algún número decimal de tokens. Este es el que mostré arriba, y es la más básica de las transferencias. Funciona exactamente como podría imaginar.coin.transfer-create: en el caso de que el destinatario de la transferencia tal vez no exista, transfer-create es cómo transferiría monedas de forma segura a la cuenta receptora. Si el destinatario ya existe, coin.transfer-create funciona exactamente como coin.transfer lo haría con una sola excepción. Debe conocer el conjunto de claves de la cuenta a la que está transfiriendo y proporcionarlo como parámetro para la función. Cuando existe la cuenta receptora, el conjunto de claves que ha pasado se compara con el conjunto de claves en el archivo de la cuenta para asegurarse de que sean las mismas para ejecutar la transferencia como se esperaba. Sin embargo, cuando la cuenta no existe, se creará una cuenta utilizando la cuenta del destinatario y el conjunto de claves con el saldo transferido desde la cuenta del remitente. En general, esta función es más segura que coin.transfer, pero esa seguridad tiene el costo de la conveniencia. Recomiendo usar este siempre que sea posible.coin.transfer-crosschain: esta función es especialmente interesante ya que es la única forma de transferir tokens de una cadena a otra, y es un proceso más complicado que requiere que aprenda sobre las continuas defpact en Pacto. Planeo cubrir esto en un tutorial separado, donde tengo la oportunidad de explicar tanto Defpact como Simple Payment Verification (SPV) en Pact y lo genial que es (¡lo siento, Thanos!). Mientras tanto, solo sepa que hay una forma de transportar tokens a través de blockchains de forma nativa, disponible en Kadena (y Pact).

Pact es el lenguaje de contrato inteligente que se ejecuta en el corazón de la cadena de bloques pública de Kadena. Hemos producido un montón de tutoriales sobre cada aspecto del ecosistema del lenguaje Pact, pero revisaremos algunos aquí para ilustrar nuestro caso de uso. Esto se hará con Pact 3.3, la versión actualmente disponible de Pact.

Crear una solicitud de API

Los contratos inteligentes están escritos en Pacto. Para llevarlos realmente a un bloque en la cadena de bloques, deben enviarse a un nodo de la cadena de bloques. Esto se realiza formateando una solicitud de API y enviando la solicitud al punto final apropiado. Pact tiene esta funcionalidad integrada en el lenguaje en forma de pacto, una familia de comandos. Para utilizar el pacto -a, se debe crear una plantilla de solicitud de API que tome la forma de un script YAML que apunte (o contenga) el código del Pacto, que luego se convierte en la representación JSON adecuada. Un usuario puede enviar este JSON en una solicitud de cURL (o, por ejemplo, una solicitud de Postman) a la cadena de bloques para su procesamiento.

Por ejemplo, si quisiera transferir 1.0 KDA de mi cuenta de vanidad, Emily a Nick-Cage porque soy un gran admirador, construiría una solicitud de plantilla YAML como la siguiente (nota: usando un par de claves de quemador generado por pact – g para fines demostrativos):

Nick Cage puede ser alimentado

Esto se ve complicado. Desafortunadamente, lo es, por eso automatizamos todo esto en la billetera. Todo lo que tienes que hacer es alternar las perillas con lo que sea apropiado. Sin embargo, aún es bueno saber qué configuraciones puede alternar para lograr una especificación de transacción óptima. La anatomía de esta solicitud se puede desglosar de la siguiente manera:

(code | codeFile): Este campo es el código sin formato que desea ejecutar o una referencia a un archivo .pact que contiene el contrato inteligente que desea ejecutar.publicMeta: Este campo contiene todos los metadatos específicos de necesarios para interactuar con la pública de Kadena. Habla por si mismo. Un usuario debe especificar cuánto gas está dispuesto a pagar y a qué precio, a dónde lo envía, quién es el remitente, etc. El tiempo de creación y TTL definen qué período de tiempo puede enviar su transacción a la cadena de bloques . El tiempo de creación es el tiempo en que su transacción se puede enviar por primera vez (especificada como el número de segundos desde 1970, es decir, desde la época POSIX) y el TTL (tiempo de vida) es cuántos segundos será válida antes de ser eliminada del mempool En la práctica, también puede ir a duckduckgo.com y buscar 'unix epoch' para obtener la hora actual, pero generalmente solo iré a Node.js y ejecutaré lo siguiente: Math.round ((nueva fecha) .getTime () / 1000) -15;Identificación de red: Este campo describe la ID de la red receptora. Dado que Pact es independiente de , esto puede ser Tendermint o Polkadot, o cualquiera de las innumerables cadenas de bloques compatibles o que se admitirán en el futuro. Actualmente, la identificación de red para la red principal de Kadena es mainnet01, pero a través de este tutorial, me ejecutaré en testnet04 para asegurarme de que no haya transacciones reales en la cadena de bloques principal.keyPairs: Los campos público / privado se explican por sí mismos: debe firmar la transacción de alguna manera. El campo menos obvio es para las capacidades permitidas en la transacción. Las capacidades son una parte integral del modelo de seguridad del Pacto. Si un contrato inteligente en particular admite capacidades, entonces se le permite decir exactamente qué operaciones permite (el firmante) usar sus claves. En el caso del contrato de monedas de Kadena, permitimos que mi par de llaves se use para pagos de gas, así como una transferencia de una cantidad específica. El flujo de control del contrato puede automatizar y poner en práctica estas operaciones, pero el contrato de monedas requiere su opinión por razones de seguridad.tipo: Esto solo será ejecutable para scripts únicos, o cont para continuaciones de custodia. En nuestro caso, estamos ejecutando una transacción única.

Para obtener una especificación más completa de las opciones disponibles, consulte la documentación de Pact API Request Formatter y los tutoriales en pact-lang.org. Aquí hay una plantilla que se puede copiar y pegar para sus solicitudes:

código:
datos:
Identificación de red:
publicMeta:
chainId:
remitente:
gasLimit:
gasPrecio:
ttl:
tiempo de creación:
keyPairs:
– público:
secreto:
tapas:
tipo: exec

Y aquí está el que utilicé para que puedas cargar el culto por ti mismo y cambiar todos los campos entre corchetes:

código: | –
(transferencia de monedas 1.0)
publicMeta:
chainId: "0"
remitente:
Límite de gas: 600
Precio de gas: 0.0000001
ttl: 600
tiempo de creación:
networkId: "mainnet01"
keyPairs:
– público:
secreto:
tapas:
– nombre: "coin.TRANSFER"
args: (, , 1.0)
– nombre: "coin.GAS"
args: ()
tipo: exec

Una vez que tengo este archivo YAML resuelto, genero la siguiente solicitud JSON usando pact -a y pasando el archivo YAML como parámetro:

Nick Cage espera impaciente …

Ahora, tengo un objeto JSON que puedo publicar en el punto final / send de la API de Pact Service para la cadena de bloques de Kadena. En la práctica, esta será una solicitud POST con el objeto JSON formateado en un punto final de nodo que toma la siguiente forma: https: //:/chainweb/0.0//cadena// pact / api / v1 / send. Aquí hay un ejemplo de solicitud de cURL que estoy usando:

curl –location –request POST 'https://us2.testnet.chainweb.com/chainweb/0.0/testnet04/chain/0/pact/api/v1/send'
– encabezado 'Tipo de contenido: aplicación / json'
–Hojas-primas '{ "cmds": ({ "troceo": "", "F7jzCyUgwcBUWYVe3xEFw66X45NHgheNrqm8LL9gMIU sigs": ({ "sig": "c0024309593b8b28b356c5edfed957c1dd7e163eecc446a327fa8d4db76faccc111b11786fe9cc6fc200ceab137d53f4df46ab76aa7f268be183289f282db20e"}), "CMD": "{" IDDERED ": "testnet04 ", "payload ": { "exec ": { "data ": null, "code ": "(coin.transfer n " emily " n " nick-cage " n 1.0) "}}, "firmantes ": ({ "pubKey ": "368059ab25bec92f19a4f8ce172030e5d672e4879aaae8d5be8b705dd3dfae7f ", "clist " : ({ "args ": ( "emily ", "nick-cage ", 1), "nombre ": "coin.TRANSFER "})}), "meta " : { "creationTime ": 1576691834, "ttl ": 600, "gasLimit ": 100000, "chainId ": "0 ", "gasPrice ": 1.0e-7, "remitente ": "emily "}, "nonce ": "2019-12-18 17: 58: 40.212918 UTC "} "})} '

Cuando haya aceptado su solicitud, recibirá una clave de solicitud, la clave única asociada con su solicitud mientras se procesa.

Nick Cage está al borde de su asiento

Para ver los resultados de su transacción, POST que solicite el objeto JSON clave a los puntos finales / poll o / listen. Cuando la transacción se haya extraído y exista en algún bloque, recibirá una respuesta. Tenga en cuenta que puede tomar algunas alturas de bloque (es decir, 30-90 segundos) para ver su transacción, y no recibirá resultados durante ese tiempo. Aquí hay un ejemplo de una solicitud / poll cURL y la respuesta:

curl –location –request POST 'https://us2.testnet.chainweb.com/chainweb/0.0/testnet04/chain/0/pact/api/v1/poll'
– encabezado 'Tipo de contenido: aplicación / json'
–data-raw '{
"requestKeys": (
"BYHjcdTqqMTROLasn82ka-DpYhE9Q1K3nFxt5vcXxGQ"
)
} '¡A Nick Cage le acaban de pagar!

¡Éxito!

Nos damos cuenta de que este es un proceso técnicamente intensivo de bajo nivel, pero al igual que todas las API en la web, existen herramientas que automatizan esta experiencia y proporcionan diversos niveles de IU sofisticada para ayudar a que el proceso sea perfecto. Entraremos en estas herramientas a continuación, pero primero, hablemos sobre las transacciones de ejecución en seco para asegurarnos de que tengan éxito.

Uso de transacciones locales / en seco

La cadena de bloques Kadena sigue el ejemplo que Ethereum estableció al cobrar el límite de gas especificado en una transacción en caso de que la transacción falle. Esto ocurre por algunas razones muy importantes:

Incentiva a los usuarios a enviar solo transacciones que saben que tendrán éxito o recibir una penalización. Esto cierra un vector DOS serio para los operadores de nodos. Los mineros son compensados ​​por los costos computacionales de las transacciones fallidas, que pueden fallar por una variedad de razones no deterministas, como los conjuntos de datos de la base de datos que explotan en tamaño hasta el punto que las transacciones no pueden cubrirlos. en menor medida, incentiva la automatización y los modos de transacción "seguros", como el uso de billetera o script que contribuyen a un ecosistema robusto.

Por sí solo, este sería un sistema bastante castigador. Después de todo, es inevitable que los nuevos usuarios no estén familiarizados con la forma de realizar transacciones con . Y aún más inevitable que las personas cometan errores al realizar transacciones. Para proporcionar tanta información como sea posible, cada nodo de Kadena tiene un punto final dedicado llamado / local en el que un usuario puede ejecutar sus transacciones en seco y descubrir los costos y resultados de una transacción determinada.

Como se mencionó anteriormente, el pacto -a es una familia de comandos. El comando que genera una solicitud local válida es pact -l -a, y se puede usar con cualquier solicitud YAML existente para producir un objeto JSON compatible con el punto final / local de cualquier nodo. La identificación de la cadena no importa en este caso, el punto final aceptará cualquier comando válido, pero es bueno proporcionar información precisa para producir comentarios válidos para la ejecución en seco. Como se indicó anteriormente, reutilizaremos la solicitud de transferencia existente de "emily" a "nick-cage":

Ahora, enviemos esto al pacto -l -a. Esto generará el siguiente objeto JSON:

Nick Cage está siendo alimentado localmente

Luego, enviemos esto al punto final / local. Esta vez, en lugar de recibir una clave de solicitud, recibimos las salidas directamente junto con algunos metadatos adicionales no incluidos con las salidas de una transacción / envío:

Las salidas muestran los resultados, los registros, una clave de solicitud, todos los metadatos utilizados en la transacción, junto con el tiempo de bloque más actualizado, el hash del bloque principal y la altura del bloque en esa cadena. No solo sabe si su transacción tendrá éxito, sino que tendrá todo el contexto que necesita para descubrir por qué falló. Veamos cómo se ve la falla en este modo utilizando un usuario que no existe como el destinatario de nuestra transferencia:

Lol definitivamente no es Nick Cage

Nuestro destinatario, "Lol definitivamente no soy Nick Cage", no existe en la cadena de bloques, por lo que recibí confirmación de que mi transacción falló. Esta información se envía junto con la pila de llamadas, el tipo de error, el mensaje de falla específico y en donde la moneda contrae el código que lo llamó fallido.

Como se mencionó anteriormente, hay algunas herramientas disponibles que automatizan la construcción de solicitudes de API (y transferencias en particular). Están disponibles en algunas formas diferentes.

Scripts de transferencia comunitaria

Existe un script de transferencia de comunidad independiente que automatiza la construcción de transferencias al proporcionar campos web que completan la información necesaria para su solicitud de API y llama a nuestra API Javascript Pact Lang que envía las transacciones por usted:

Puede configurar esto en su navegador utilizando el index.html provisto, o puede ejecutarlo como un script independiente con nodo como se describe en el archivo README.md del proyecto. Si lee la primera sección detenidamente, todo le resultará muy familiar y podrá imaginar cómo se crea y envía el YAML a través de esta información. Sin embargo, verá que hay una falta de gas y TTL / creationTime. Esto se debe a que hemos elegido algunos valores predeterminados razonables que deberían facilitar aún más el proceso. Este script ejecutará coin.transfer o coin.transfer-create según los parámetros que usted proporcione. Los operadores de piscinas y los mineros de energía como BigShoots lo han configurado en sus nodos como cortesía para otros usuarios (gracias BigShoots).

Cartera Chainweaver

Si está en Mac (el único sistema operativo actualmente compatible, con Linux y Windows en camino), puede hacer uso de la oferta interna de Smart Wallet de Kadena: la billetera Chainweaver.

Chainweaver Wallet presenta un IDE de Pacto completo (incluido un REPL) para crear contratos inteligentes e interactuar con contratos inteligentes existentes en la cadena de bloques de Kadena, además de sus características de servicio de cuentas. Le recomiendo que ejecute la billetera desde la perspectiva de un redactor de contratos inteligente (y, por transparencia, un empleado de Kadena).

Chainweaver Wallet, editor de contratos de Chainweaver y IDE de pacto

Chainweaver tiene una excelente interfaz de usuario para enviar y recibir tokens utilizando un formato de dirección novedoso para los usuarios de Chainweaver al que llamamos Dirección Kadena. En la pestaña Carteras, localice su cuenta de Chainweaver y simplemente haga clic en la pestaña "enviar", que lo llevará a una pequeña ventana emergente en la que puede pegar la Dirección Kadena de la cuenta receptora. Dependiendo del contexto, Chainweaver puede detectar si existe una cuenta receptora en particular y en qué cadena, y elegirá si usar coin.transfer, coin.transfer-create o coin.transfer-crosschain dependiendo de ese contexto. Incluso automatizará el paso manual anterior de construir una prueba SPV en el caso de una transferencia de cadena cruzada. Muy elegante

Trabajar con cuentas que no son de Chainweaver

Desafortunadamente, las cuentas existentes de Kadena no son importables a través de Chainweaver hasta que esa funcionalidad se entregue a mediados de enero. Sin embargo, puede crear una cuenta en Chainweaver y transferir sus tokens de su cuenta existente de Kadena a la nueva cuenta de Chainweaver e importarlos de esa manera.

Tenga en cuenta que su dirección de Kadena NO ES el nombre de su cuenta de contrato de monedas. Es un formato específico de Chainweaver, que no tiene nada que ver con su cuenta de contrato de monedas, ¡así que tenga cuidado! Es muy conveniente cuando se trabaja con otras cuentas de Chainweaver, pero no se deben hacer suposiciones sobre su relevancia para el resto de la cadena de bloques.

Opciones de billetera adicionales

Damos la bienvenida a cualquier adición de billetera como proyectos comunitarios y estaremos encantados de ayudarlo a configurarlo con un repositorio dedicado en nuestra organización Kadena Community GitHub si tiene una presentación. Ya hay uno, cortesía de nuestro Kadena Colin Woodbury (@fosskers). Escribió una fantástica billetera CLI llamada Bag of Holding, que puede operar desde su terminal:

Bag of Holding funciona esencialmente como una buena interfaz de usuario en torno a la creación y ejecución de solicitudes de API como se describe anteriormente en este artículo. Es sólido, simple, confiable y (creo) se ve muy bien.

Ahí lo tienes: una introducción a las transacciones del Pacto a través de transferencias. Nuestras herramientas están en las primeras etapas. Agradecemos la ayuda de la comunidad para documentar estas herramientas y construir otras nuevas en el camino. Siempre estamos felices de representar herramientas bendecidas por la comunidad si son mejores que las nuestras. Damos la bienvenida a cualquier persona que contribuya al repositorio de proyectos de la Comunidad de Kadena con su propio proyecto o agregue a los existentes. Hasta ahora, los proyectos de la comunidad han producido una gran billetera terminal con Bag of Holding y un minero de GPU increíblemente rápido por cortesía de Alex Khonovalov, Edmund Noble y una miríada de otros miembros de la comunidad increíblemente inteligentes.

Gracias a todos los que contribuyeron, y no duden en hacerme sus preguntas en Discord: mi nombre es uno de @topos, @pitopos o @emilypi, dependiendo de dónde esté en Internet. Estoy pegado perpetuamente a mi pantalla, por lo que generalmente responderé si me encuentras. En caso de que esté durmiendo, puede haber un retraso.

Juego de llaves: Se refiere al esquema de autorización de Pact Keyset. Estos son un conjunto de claves públicas además de una función de predicado (por ejemplo, keys-all, keys-any, etc.) que decide la política de autorización para las claves del conjunto de claves. Por ejemplo, si tengo un conjunto de claves con el predicado keys-all, entonces todas las claves deben estar presentes como firmantes en una transacción para hacer algo con el conjunto de claves.Cuenta: Una entrada en el libro contable del contrato de monedas de Kadena (una tienda de valores clave). Consiste en una cadena de 3 a 256 caracteres LATIN-1 como clave, que apunta a un valor que consiste en un saldo decimal y un conjunto de claves que rigen la cuenta.Cuenta de vanidad: Llamamos cuentas "vanity" a las cuentas cuando tienen un nombre personalizado que no es solo la cadena de clave pública asociada con un conjunto de claves. Piense en ello como una placa de vanidad.Token (KDA): Cuando nos referimos al "token", nos referimos a la definición e implementación de la especificación de activos fungibles de Kadena, llamada fungible-v1 y coin, respectivamente. En la práctica, ¡esto solo significa el contrato de monedas!Contrato inteligente: Los módulos de pacto definen contratos inteligentes.Solicitud API: Una solicitud HTTP enviada a uno de los puntos finales disponibles en cualquier nodo Kadena .Transacción: Una solicitud de API enviada a los puntos finales / send o / local de un nodo, que ejecuta el código del Pacto. El envío de una solicitud de API al punto final / send produce una transacción que se incluye en un bloque, mientras que una solicitud a / local no lo hará.Capacidad: Esto se refiere al sistema de permisos de capacidad integrado en el lenguaje Pact. Más sobre esto por venir.Funcionamiento en seco: Una transacción enviada al punto final / local.Gas: Cuántas unidades de cálculo (es decir, tokens) se necesitan para ejecutar una transacciónLímite de gas: La cantidad de gas disponible para la transacción, especificada por el usuario.Precio del gas: El precio del gas que el usuario está dispuesto a pagar. Este es un multiplicador decimal para el límite de gas, lo que resulta en el suministro final de gas disponible para una transacción. El resultado se mide contra la cantidad de gas que se necesita para ejecutar una transacción para determinar la recompensa del minero, y cualquier reembolso que el usuario pueda recibir (es decir, el suministro total de gas menos el gas total utilizado).Identificación de la cadena: El identificador para una cadena dada en la cadena de bloques de Kadena. (Actualmente, son de 0 a 9).Tiempo de creación: Tiempo en segundos desde la época POSIX (es decir, desde el 01/01/1970: 00: 00: 00) que marca el momento más temprano en que una transacción debe considerarse un candidato para ser incluido en un bloque.TTL: Time-to-Live: la fecha de vencimiento en segundos durante cuánto tiempo se debe considerar una transacción para la candidatura en un bloque después de su hora de creación. Los TTL pueden ser como máximo 48 horas después de la creación inicial.Identificación de red: El identificador único para la red (por ejemplo, testnet04 o mainnet01)Par de claves: Un par de claves público / privado.Metadatos públicos: Los datos no transaccionales de una transacción utilizados para interactuar con la cadena de bloques (es decir, qué ID de cadena, TTL, creationTime, quién es el remitente, etc.)Nodo : Un nodo de KadenaBilletera: Un dispositivo, medio físico, programa o servicio que almacena las claves públicas y / o privadas. Se puede usar para rastrear la propiedad, recibir o gastar criptomonedas.Dirección de Kadena: El formato único y seguro en el que Chainweaver Wallet almacena cuentas.IDE: Entorno de desarrollo integradoREPL: Leer-evaluar-imprimir-bucle. Muchos idiomas tienen esto como un medio para obtener comentarios rápidos y ejecutar código.