Este documento cubre los fundamentos de las direcciones de las cuentas Polkadot y Kusama y cómo existen en la cadena. Para una explicación más profunda de la criptografía que hay detrás de ellas, por favor mira la página de criptografía.

Formato de las Direcciones #

El formato de dirección utilizado en las cadenas basadas en Substrate es SS58. SS58 es una modificación de Base-58-check de Bitcoin con algunos cambios menores. En particular, el formato contiene un prefijo de tipo de dirección que identifica una dirección como perteneciente a una red específica.

Por ejemplo:

• Las direcciones Polkadot siempre comienzan con el número 1.
• Las direcciones Kusama siempre comienzan con una letra mayúscula, como C D, F, G, H, J.
• Las direcciones de Substrate Genérico siempre empiezan por el número 5.

Estos prefijos, así como la forma de validar las direcciones, se desglosan en la documentación de Substrate SS58. Nunca utiliza expresiones regulares para la validación de direcciones.

Es importante entender que los diferentes formatos de red son simplemente otras representaciones de la misma clave pública en un par de claves privada-pública generadas por una herramienta de generación de direcciones. Como resultado, las direcciones a través de las cadenas basadas en Substrate son compatibles siempre que el formato se convierta correctamente.

A partir del Runtime 28, el formato de dirección por defecto es el tipo MultiAddress.

Este enum es una envoltura de direcciones multiformato para las cuentas en la cadena (on-chain) y nos permite describir el formato de dirección por defecto de Polkadot para representar muchos tipos de direcciones diferentes. Esto incluye variantes de 20 bytes, 32 bytes y bytes crudos arbitrarios. También permite una mejora en la búsqueda de indices originales.

• Muchas wallets te permiten convertir entre formatos. También existen herramientas independientes; puedes encontrarlas en la sección de herramientas de conversión de direcciones.

Generación, Derivación y Portabilidad de Direcciones #

Una cuenta válida requiere una clave privada que pueda firmar en una de las curvas y esquemas de firma admitidos.

La mayoría de las wallets (billeteras) dan muchos pasos desde una frase mnemotécnica hasta una clave de cuenta, lo que afecta a la capacidad de utilizar la misma frase mnemotécnica en varias wallets. Las wallets que utilizan diferentes medidas llegarán a un conjunto diferente de direcciones a partir de la frase mnemónica exacta.

Generación de semillas #

La mayoría de las wallets generan una frase mnemónica para que los usuarios hagan una copia de seguridad de sus wallets y generen una clave privada a partir de la mnemónica. No todas las wallets utilizan el mismo algoritmo para convertir la frase mnemónica en clave privada.

A continuación se muestra una frase mnemónica típica generada por la herramienta Subkey.

También se muestra su correspondiente par de claves privada/pública.

Las wallets basadas en Subkey y Polkadot-JS utilizan el diccionario BIP39 para la generación de mnemónicos, pero utilizan el array de bytes de entropía para generar la clave privada, mientras que las wallets BIP39 completas (como Ledger) utilizan 2048 rondas de PBKDF2 en el mnemónico. El mismo mnemónico puede generar diferentes claves privadas en otras wallets debido a los distintos algoritmos criptográficos utilizados.

Para más información, consulta el repositorio Substrate BIP39.

Rutas de derivación #

Si quieres crear y gestionar varias cuentas en la red utilizando la misma semilla, puedes utilizar rutas de derivación. Podemos pensar en las cuentas derivadas como cuentas hijas de la cuenta raíz creada usando la frase semilla original. Muchas herramientas de generación de claves de Polkadot soportan la derivación dura y blanda. Por ejemplo, si tienes la intención de crear una cuenta para ser usada en la cadena Polkadot, puedes derivar una cuenta hija de la clave dura (hard key) usando // después de la frase mnemotécnica.

y una cuenta hija de llave blanda (soft key) utilizando / después de la frase mnemotécnica

Si deseas crear otra cuenta para usar la cadena Polkadot utilizando la misma semilla, puedes cambiar el número al final del string anterior. Por ejemplo, /1, /2 y /3 crearán diferentes cuentas derivadas.

Puedes utilizar cualquier letra o número en la ruta de derivación siempre que tenga sentido para ti; no tienen que seguir ningún patrón específico. También puedes combinar varias derivaciones en tu ruta. Por ejemplo, //bill//account//1 y //john/polkadot/initial son válidos. Para recrear una cuenta derivada, debes conocer tanto la semilla como la ruta de derivación, por lo que debes utilizar una secuencia bien definida (por ejemplo, //0, //1, //2…) o asegurarte de anotar cualquier ruta de derivación que utilices.

• No es posible generar una cuenta derivada sin conocer también la ruta de derivación.

Derivación Suave vs. Dura #

Una derivación suave permite que alguien pueda “retroceder” para averiguar la clave privada de la cuenta inicial si conoce la clave privada de la cuenta derivada. También es posible determinar que diferentes cuentas generadas a partir de la misma semilla están vinculadas a esa semilla. Una ruta de derivación dura no permite ninguna de las dos cosas: aunque se conozca una clave privada derivada, no es factible averiguar la clave privada de la dirección raíz, y es imposible demostrar que la primera cuenta está vinculada con la segunda. Estos métodos de derivación tienen sus casos de uso, dado que las claves privadas de todas las cuentas derivadas son totalmente seguras. A menos que tengas una necesidad específica de una derivación suave, se recomienda generar la cuenta utilizando una ruta de derivación dura.

Consulta la documentación de Subkey para obtener detalles y ejemplos de formatos de rutas de derivación. Las aplicaciones Polkadot-JS y Extensión y Parity Signer admiten rutas de derivación personalizadas utilizando la misma sintaxis que Subkey.

Algunas wallets añadirán automáticamente rutas de derivación al final de la frase mnemónica generada. Esto generará semillas separadas para rutas separadas, permitiendo claves de firma separadas con el mismo mnemónico, por ejemplo, <mnemonic phrase>//polkadot y <mnemonic phrase>//kusama. Aunque puedes guardar correctamente la frase mnemotécnica, utilizarla en otra wallet no generará las mismas direcciones a menos que ambas wallets utilicen las mismas rutas de derivación.

Tanto Polkadot como Kusama tienen rutas registradas en el registro BIP44.

Advertencia: Debes tener tanto la clave privada parent como la ruta de derivación para llegar a la clave de una dirección. No utilices rutas de derivación personalizadas a menos que te sientaz cómodo con tu comprensión de este tema.

Portabilidad #

La información anterior nos lleva a la portabilidad: la capacidad de utilizar una frase mnemotécnica o semilla en varias wallets. La portabilidad depende de varios factores:

• Ruta de derivación
• Formato mnemónico
• Derivación de la semilla
• Esquema de la firma

Si quieres utilizar el mismo mnemónico en varias wallets, asegúrate de que siguen métodos compatibles para generar claves y firmar mensajes. Si no encuentras documentación comprensible, contacta a los responsables del proyecto.

* Las claves Ed25519 tienen una compatibilidad limitada con BIP39.

† Registro BIP44

‡ Ed25519 y BIP32 basados en Khovratovich

§ Sr25519 previsto

Para los Curiosos: Cómo Funcionan los Prefijos #

El documento SS58 establece que:

• Polkadot tiene un tipo de dirección de 00000000b, por lo que 0 está en decimal.
• Kusama (Polkadot Canary) tiene un tipo de dirección de 00000010b, por lo que 2 está en decimal.
• Generic Substrate tiene 00101010b como tipo de dirección, 42 está en decimal.

Como el alfabeto de Base58-check no tiene el número 0, el valor más bajo es efectivamente 1. Así que 00000000b es 1 en Base58-check. Si intentamos decodificar una dirección Polkadot como 1FRMM8PEiWXYax7rpS6X4XZX1aAAxSWx1CrKTyrVYhV24fg, el resultado es 000aff6865635ae11013a83835c019d44ec3f865145943f487ae82a8e7bed3a66b29d7. El primer byte es 00, que efectivamente es 00000000 en binario y 0 en decimal y por tanto coincide con el tipo de dirección de Polkadot.

Miremos las direcciones de Substrate. Si decodificamos 5CK8D1sKNwF473wbuBP6NuhQfPaWUetNsWUNAAzVwTfxqjfr, obtenemos 2a0aff6865635ae11013a83835c019d44ec3f865145943f487ae82a8e7bed3a66b77e5. El primer byte es 2a, que convertido de hexadecimal a decimal es 42. 42 es 00101010 en binario, tal y como indica el documento SS58.

Por último, veamos las direcciones Kusama. La decodificación de CpjsLDC1JFyrhm3ftC9Gs4QoyrkHKhZKtK7YqGTRFtTafgp nos da 020aff6865635ae11013a83835c019d44ec3f865145943f487ae82a8e7bed3a66b0985 con el primer byte siendo 02, tal como se especifica. Si probamos con una dirección Kusama que empiece por una letra completamente diferente, como J4iggBtsWsb61RemU2TDWDXTNHqHNfBSAkGvVZBtn1AJV1a, seguimos obteniendo 02 como primer byte: 02f2d606a67f58fa0b3ad2b556195a0ef905676efd4e3ec62f8fa1b8461355f1142509. Parece contradictorio que algunas direcciones tengan siempre el mismo prefijo y otras, como la de Kusama, puedan variar de forma salvaje, pero no es más que una peculiaridad de la codificación de Base58-check.

Obtención y Gestión de una Dirección #

La forma más sencilla para el usuario de crear una dirección Polkadot o Kusama es a través de la UI Polkadot-JS. Recuerda hacer una copia de seguridad de la frase semilla utilizada para generar tu cuenta – las cuentas se almacenan sólo en tu navegador, por lo que la purga de la caché borrará también tus cuentas. Tendrás que volver a crearlas usando la frase semilla que te dio la UI – esto también restaurará todos tus saldos anteriores.

Un método más conveniente y recomendado para mantener las cuentas almacenadas en tu computadora es utilizar la extensión Polkadot{.js}. Esta extensión recuerda tus cuentas y te permite borrar el caché de tu computadora sin miedo. Aun así, no te olvides de hacer una copia de seguridad de tu frase semilla: si pierdes el acceso a esta computadora o la extensión se estropea de algún modo sin remedio, la frase te será muy útil.

Ten en cuenta que, dado que esto guarda tus cuentas en el navegador, no es seguro guardar reservas importantes. Por definición, un navegador es una “wallet caliente” y susceptible de sufrir una amplia gama de ataques, así que mantén tus fondos en una wallet fría cuando se trate de cantidades no triviales. Para mejorar la seguridad, puedes guardar de forma segura la frase inicial de tus cuentas y eliminar todo rastro de las mismas de tu computadora después de crearlas.

Además de la extensión y la interfaz de usuario por defecto, las direcciones Polkadot y Kusama también pueden crearse con la herramienta Subkey. Subkey está pensada para usuarios cómodos con el uso de la línea de comandos y puede parecer intimidante, pero es bastante accesible. Sigue las instrucciones de la documentación de Subkey. Cuando se utiliza correctamente, Subkey es el método más seguro disponible para crear una cuenta.

También existe el muy seguro Parity Signer. Este guarda tus claves en un teléfono móvil con espacio de aire. Sin embargo, requiere la obtención de un viejo teléfono compatible con Android o iOS que te sientas cómodo utilizando sólo para Parity Signer.

La integración de la wallet de hardware es posible con Ledger. Una guía completa está disponible aquí.

Alternativamente, puedes encontrar otras wallets en la página de Wallet, pero ten en cuenta que algunos de ellos no están auditados y no están oficialmente afiliados a la Fundación Web3 o al proyecto Polkadot a menos que se indique lo contrario.

Tipos de Saldo #

En Polkadot, hay cuatro tipos de saldo diferentes que indican si tu saldo puede ser utilizado para transferencias, para pagar las tarifas, o debe permanecer congelado y sin usar debido a un requisito en la cadena.

La estructura AccountData define los tipos de saldo en Substrate. Los cuatro tipos de saldos incluyen free, reserved, misc_frozen (miscFrozen en camel-case), y fee_frozen (feeFrozen en camel-case).

En general, el saldo utilizable de la cuenta es la cantidad que está free (libre) menos los fondos que se consideran congelados (misc_frozen o fee_frozen) y que dependen del motivo por el que se van a utilizar los fondos. Si los fondos se van a utilizar para transferencias, el importe utilizable es el importe libre menos los fondos misc_frozen. Sin embargo, si los fondos se van a utilizar para pagar las comisiones de las transacciones, el importe utilizable sería los fondos libres menos fee_frozen.

Se considera que el saldo total de la cuenta es la suma de los fondos free (libres) y reserved (reservados) en la cuenta. Los fondos reservados se retienen debido a los requisitos de la cadena y normalmente se pueden liberar realizando alguna acción en la cadena. Por ejemplo, la paleta “Identity” reserva fondos mientras se registra una identidad en la cadena, pero al borrar la identidad, se pueden quitar la reserva de los fondos y dejarlos libres de nuevo.

Depósito Existencial y Cosecha #

Cuando generas una cuenta (dirección), sólo generas una clave que te permite acceder a ella. La cuenta no existe todavía en la cadena. Para ello, necesita el depósito existencial: 0,0000333333 KSM (en Kusama) o 1 DOT (en Polkadot mainnet).

Si una cuenta se sitúa por debajo del depósito existencial, esa cuenta será cosechada (reaped). La cuenta será borrada del estado del blockchain para conservar espacio, junto con cualquier fondo en esa dirección. No pierdes el acceso a la dirección cosechada -siempre que tengas la clave privada o la frase de recuperación, puedes seguir utilizando la dirección-, pero se necesita una recarga de otro depósito existencial para poder interactuar con la cadena.

Las tarifas de las transacciones no pueden hacer que una cuenta sea cosechada. Dado que las tarifas se deducen de la cuenta antes de cualquier otra lógica de transacción, las cuentas con saldos iguales al depósito existencial no pueden construir una transacción válida. Habrá que añadir fondos adicionales para cubrir las tarifas de transacción.

Aquí hay otra forma de pensar en los depósitos existenciales. ¿Notaste alguna vez esos archivos Thumbs.db en Windows o los archivos .DS_Store en Mac? Esos son basura; no tienen ningún propósito específico más que el de hacer las vistas previas un poco más rápidas. Si se guarda una carpeta vacía para ese tipo de archivos, puedes remover la carpeta para limpiar la basura de tu disco duro. Eso no significa que pierdas el acceso a esta carpeta para siempre – siempre puedes volver a crearla. Después de todo, tú tienes la llave: eres el propietario de la computadora. Sólo significa que quieres mantener tu computadora limpia hasta que quizás acabes necesitando esta carpeta de nuevo y entonces la vuelvas a crear. Tu dirección es como esta carpeta: se elimina de la cadena cuando no hay nada en ella, pero se vuelve a poner cuando tiene el depósito existencial.

Índices #

Una dirección Kusama o Polkadot puede tener un índice. Un índice es como una versión corta y fácil de recordar de una dirección. Reclamar un índice requiere un depósito que se libera cuando el índice se borra.

Los índices se rellenan por orden. Piensa en ellos como si fueran ranuras (slots) que van de 0 a cualquier número arbitrario:

Si las ranuras 0-2 están pobladas por las direcciones A, B y C, respectivamente, y añado un depósito existencial a la dirección X, esa dirección se pondrá automáticamente en la ranura 3. A partir de ahora, puedes enviarme dinero simplemente enviando a [3] en lugar de recordar mi dirección completa.

Pero, ¿Qué ocurre si una cuenta se vacía como se explicó anteriormente? En ese caso, el índice se vacía. En otras palabras, la ranura (slot) se libera de nuevo. Si alguien crea una nueva cuenta, pueden utilizar el mismo índice que otra dirección estaba utilizando antes.

Es posible congelar un índice y asignarlo permanentemente a una dirección. Esta acción consume un depósito, pero asegura que el índice nunca pueda ser reclamado a menos que sea liberado por la cuenta titular.

Para registrar un índice, envía un extrínseco de claim a la paleta de indices, y sigue con un extrínseco freeze. La forma más fácil de hacerlo es a través de la interfaz de PolkadotJS a través del menú Developer -> Extrinsics:

Para encontrar índices disponibles para reclamar, esta herramienta de ayuda puede ser útil.

Identidades #

La Identities pallet (paleta de Identidades) integrada en Polkadot permite a los usuarios adjuntar metadatos en la cadena a sus cuentas. Los registradores independientes pueden verificar estos metadatos para proporcionar confianza. Para saber más sobre cómo establecer o liberar una identidad, cómo definir subcuentas o cómo convertirse en registrador, lee esta guía.

Cuentas Proxy #

Polkadot viene con un sistema generalizado de cuentas proxy que permite a los usuarios mantener las claves en el almacenamiento en frío, mientras que los proxies actúan en su nombre con funcionalidad restringida (o sin restricciones). Mira la página de proxies para más información.

Cuentas Multi-Firma #

Es posible crear una cuenta multifirma en las cadenas basadas en Substrate. Una cuenta multifirma se compone de una o varias direcciones y un umbral. El umbral define cuántos firmantes (direcciones participantes) deben estar de acuerdo en suscribir un extrínseco para que la llamada tenga éxito.

Por ejemplo, Alice, Bob y Charlie configuran una cuenta multifirma (multisig) con un umbral de 2. Esto significa que Alice y Bob pueden ejecutar cualquier llamada aunque Charlie no esté de acuerdo con ella. Del mismo modo, Charlie y Bob pueden ejecutar cualquier llamada sin Alice. Un umbral suele ser un número menor que el número total de miembros, pero también puede ser igual, lo que significa que todos tienen que estar de acuerdo.

Obtén más información sobre las cuentas multifirma en nuestro video explicativo técnico.

Las cuentas multifirma tienen varios usos:

• Asegurar tu propio dinero: utiliza firmantes adicionales como mecanismo 2FA para asegurar tus fondos. Un firmante puede estar en una computadora, y otro puede estar en otro o en un almacenamiento en frío. Esto ralentiza tus interacciones con la cadena, pero es muchísimo mas seguro.
• Decisiones del consejo: las entidades jurídicas, como las empresas y las fundaciones, utilizan las multifirmas (multi-sigs) para gobernar sobre la tesorería de la entidad de forma colectiva.
• Participación del grupo en la gobernanza: una cuenta multisig puede hacer todo lo que puede hacer una cuenta normal. Una cuenta multi-sig podría ser un miembro del consejo en la gobernanza de Kusama, donde un conjunto de miembros de la comunidad podría votar como una sola entidad.

Las cuentas multi-sig no pueden ser modificadas después de ser creadas. No es posible cambiar el conjunto de miembros o alterar el umbral, sino que se requiere la disolución de la cuenta multifirma actual y la creación de una nueva. Como tal, las direcciones de las cuentas multi-firma son determinísticas, es decir, siempre puedes calcular la dirección de una multi-firma conociendo los miembros y el umbral, sin que la cuenta exista todavía. Esto significa que se pueden enviar tokens a una dirección que aún no existe, y si las entidades designadas como destinatarias se reúnen en una nueva multi-sig bajo un umbral que coincida, tendrán inmediatamente acceso a estos tokens.

Generación de Direcciones de Cuentas Multifirma #

• NOTA: Las direcciones que se proporcionan a las wallets multisig deben estar ordenadas. Los siguientes métodos de generación ordenan las cuentas por ti, pero si implementas tu propio orden, ten en cuenta que las claves públicas se comparan byte a byte y se ordenan de forma ascendente antes de ser insertadas en la carga útil que se hash.

Las direcciones se generan de forma determinística a partir de los firmantes y el umbral de la wallet multisig. Para ver un ejemplo de código (en TypeScript) de la generación, puedes ver los internos de @w3f/msig-util aquí.

El @w3f/msig-util es una pequeña herramienta CLI que puede determinar la dirección de la multifirma basada en tus entradas.

$ npx @w3f/msig-util@1.0.7 derive --addresses 15o5762QE4UPrUaYcM83HERK7Wzbmgcsxa93NJjkHGH1unvr,1TMxLj56NtRg3scE7rRo8H9GZJMFXdsJk1GyxCuTRAxTTzU --threshold 1
npx: installed 79 in 7.764s
--------------------------------
Addresses: 15o5762QE4UPrUaYcM83HERK7Wzbmgcsxa93NJjkHGH1unvr 1TMxLj56NtRg3scE7rRo8H9GZJMFXdsJk1GyxCuTRAxTTzU
Threshold: 1
Multisig Address (SS58: 0): 15FKUKXC6kwaXxJ1tXNywmFy4ZY6FoDFCnU3fMbibFdeqwGw
--------------------------------

La UI de Polkadot-JS Apps también admite cuentas multi-sig, como se documenta en la página de Generación de Cuentas. Esto es más fácil que generarlas manualmente.

Realización de Transacciones con una Cuenta Multifirma #

Hay tres tipos de acciones que puede realizar con una cuenta multi-sig:

• Ejecutar una llamada.
• Aprobar una llamada.
• Cancelar una llamada.

En los escenarios en los que sólo se necesita una aprobación, se debe utilizar el método de conveniencia as_multi_threshold_1. Esta función sólo toma como argumentos los otros firmantes y la llamada en bruto.

Sin embargo, en cualquier caso que no sea el de una sola aprobación, es probable que necesites que más de uno de los firmantes apruebe la llamada antes de ejecutarla finalmente. Cuando crees una nueva llamada (call) o apruebes una llamada como multi-firma, tendrás que hacer un pequeño depósito. El depósito permanece bloqueado en la paleta hasta que se ejecuta la llamada. El depósito sirve para establecer un costo económico en el espacio de almacenamiento que la llamada multi-sig ocupa en la cadena y desalentar a los usuarios de crear operaciones multi-sig colgantes que nunca se ejecutan. El depósito se reservará en las cuentas del llamante, por lo que los participantes en las wallets multifirma deben tener fondos de sobra disponibles.

El depósito depende del parámetro del threshold (umbral) y se calcula de la siguiente manera:

Donde DepositBase y DepositFactor son constantes de cadena establecidas en el código de ejecución.

Actualmente, DepositBase es igual a deposit(1, 88) (el tamaño de la clave es 32; el valor tiene un tamaño de 4+4+16+32 = 56 bytes) y DepositFactor es igual a deposit(0, 32) (dirección adicional de 32 bytes).

La función de depósito en JavaScript está definida a continuación, copiada del código fuente de Rust.

De este modo, los valores del depósito pueden calcularse como se muestra en la siguiente tabla.

Consideremos un ejemplo de una multi firma en Polkadot con un umbral de 2 y 3 firmantes: Alice, Bob y Charlie. Primero, Alice creará la llamada en la cadena llamando a as_multi con la llamada en bruto. Al hacer esto Alice tendrá que depositar DepositBase + (2 * DepositFactor) = 20.152 DOT mientras espera que Bob o Charlie también aprueben la llamada. Cuando Bob llegue a aprobar la llamada y ejecute la transacción, no tendrá que realizar el depósito, y Alice recibirá su depósito de vuelta.

Ejemplo con Polkadot.JS #

Para este ejemplo, utilizaremos la red de prueba de Westend y las aplicaciones Polkadot.JS para crear una dirección multisig 2 de 3 y enviar una transacción con ella.

Aunque Westend pretende replicar la mainnet de Polkadot lo más fielmente posible, hay algunas diferencias notables:

• El depósito existencial es igual a 0,01 WND (Westies; la moneda nativa de Westend) en lugar de 1 DOT.
• El depósito de transacciones multi-firma es igual a ~1 WND en lugar de ~20,2 DOT.

Las fotos de abajo reflejan los valores en WND, pero las instrucciones son las mismas para DOT.

Para crear una dirección multisig y enviar una transacción con ella, necesitarás lo siguiente:

• Lista de las direcciones de los miembros de la multisig. Utilizaremos Alice, Bob y Charlie.
• Esto debe estar en la dirección que inicia una transacción multisig (en este ejemplo, Alice).- DOT para depositar en la dirección multisig.
• ~20,2 DOT de depósito reembolsable para enviar una transacción multisig.

Ya deberías tener tu cuenta con algunas monedas en ella.

Para generar la dirección multisig, tenemos que añadir las direcciones de los miembros multisig a la libreta de contactos en “Accounts > Address book” (Cuentas > Libreta de Direcciones).

Haz clic en “Add Contact” (Añadir contacto) en la parte superior derecha y proporciona la dirección y un nombre para cada dirección.

Aquí se han añadido Bob y Charlie.

A continuación, tenemos que crear la nueva dirección multifirma. Navega a la página de Accounts -Cuentas- (desde la barra de herramientas, “Accounts > Accounts” (Cuentas > Cuentas) y haz clic en el botón “+ Multisig”. Suministraremos las tres direcciones de miembros multisig con un valor “2” para el umbral.

Haz clic en “Create” (Crear), y deberías ver la nueva dirección multisig en esta página de Cuentas.

Ahora vamos a financiar la dirección. Para este ejemplo, transferiremos algunas monedas de la cuenta de Alicia a la dirección multisig. En la dirección de Alice, haz clic en “Send” (Enviar), selecciona la wallet multisig como destino y proporciona una cantidad. A continuación, haz clic en “Make Transfer” ( Realizar transferencia) y luego en “Sign and Submit” (Firmar y enviar).

Podemos ver que la cuenta multisig tiene ahora un saldo.

Para enviar una transacción, necesitamos que uno de los miembros la inicie. Utilicemos a Alice para iniciar la transacción.

Asegúrate de que Alice tiene suficientes monedas para cubrir el depósito de la transacción multisig y las tasas de transacción. A continuación, haz clic en “Send” (Enviar) bajo la “Multisig Test Address” (Dirección de prueba multisig), selecciona una dirección de destino (hemos generado una dirección localmente) y una cantidad de transferencia, y haz clic en “Make Transfer” (Hacer transferencia).

Para firmar como Alice, asegúrate de que está seleccionada como ‘multisig signatory’ (firmante multisig), haz clic en ‘Sign and Submit’ (Firmar y enviar) y firma la transacción.

Ahora verás una transacción pendiente, la ‘Multisig Test Address’ -Dirección de prueba multisig- (el icono púrpura junto al nombre de la cuenta), y si haces clic en la flecha desplegable a la derecha del saldo de Alice, verás que se ha “reservado” un valor equivalente al depósito multisig, lo que hace que ese valor sea intransferible hasta que se complete la transacción multisig.

A continuación, necesitamos una segunda firma. Vamos a obtenerla de Bob. En el navegador de Bob, repite lo siguiente de los pasos anteriores.

1. Añade Alice, Charlie y las direcciones de destino de la transacción multisig a la libreta de direcciones de Bob.
2. Crea una nueva dirección multisig con los mismos parámetros (las direcciones de Bob, Alice y Charlie, y un valor de umbral de ‘2’).

NOTA: Dado que la generación de direcciones multisig es determinística, si Bob (o cualquier otro miembro), en su computadora generara una dirección multisig utilizando las direcciones de Alice, Charlie y la suya, con un valor de umbral de ‘2’, produciría la misma dirección multisig que tiene Alice aquí.

Si se hace correctamente, deberíamos ver que se produce la misma dirección multisig en el navegador de Bob, y que también se muestra una transacción pendiente.

Alice inició la transacción subiendo una firma del hash de la transacción y el hash.

A continuación, para obtener la firma de Bob, éste debe elaborar la misma transacción multisig que hizo Alice proporcionando la misma dirección de destino y la misma cantidad de transferencia (en conjunto, los parámetros de la transacción), firmándola y enviándola. Estos parámetros de transacción permitirán a Bob producir y firmar la misma transacción (el mismo hash) que Alice firmó anteriormente.

Haz clic en ‘Make Transfer’ (Realizar transferencia) – asegúrate de que Bob es el ‘multisig signatory’ (firmante multisig), y haz clic en ‘Sign and Submit’ (Firmar y enviar).

NOTA: “Mensaje multisig con la llamada (para la aprobación final)” se habilita automáticamente; esto significa que, dado que la transacción alcanzará el umbral de firma, ejecutará la transacción real en la cadena después de añadir la segunda firma.

Suponiendo que no haya errores, la ‘Multisig Destination Account’ (Cuenta de destino multisig) tiene un saldo de 0,3 WND, y la cuenta de Alice ha liberado el depósito de la transacción multisig.

Decodificación de los Datos de la Llamada #

Puedes utilizar Polkadot-JS Apps para decodificar los datos de las llamadas, ya que la extensión sólo muestra los datos brutos de las mismas. Esto te permitirá saber lo que estás firmando.

• Los datos de llamada decodificados requieren que entiendas lo que los eventos o llamadas significan en el contexto de la transacción.

1. Antes de enviar una transacción, copia los datos de la llamada.

2. Navega por la pestaña Decode (Decodificar) de la sección Extrínseco y pega los datos de la llamada en la ventana “hex-encode call” (llamada codificada en hexadecimal). Asegúrate de haber seccionado la cuenta correcta.

3. Verifica que los datos son los esperados.

4. Navega de nuevo a la extensión Polkadot-JS y aprueba la transacción.

Otra forma de realizar esto es actualizar tus metadatos para esa cadena. Entonces podrás hacer que la extensión Polkadot-JS analice los datos de la llamada por ti.

Herramientas de Conversión de Direcciones #

Puedes utilizar las siguientes herramientas para convertir cualquier dirección SS58 para cualquier red para su uso en diferentes redes

• handy subscan tool
• simple address converter

Cómo Verificar la Dirección Asociada a una Clave Pública #

Puedes verificar la dirección asociada a tu clave pública a través de una serie de pasos de inspección, donde la clave es una dirección de base-16 (hexadecimal).

Uso de Subkey para Recuperar la Clave Pública de la Dirección SS58

Esto es para mostrar que la dirección SS58 se basa en la clave pública (también conocida como “Account ID”)

La sección Inspección de Claves de la Herramienta Subkey explica cómo utilizar el comando inspect para recalcular la clave pública y la dirección de su par de claves.

Comienza por inspeccionar la dirección de tu cuenta de Polkadot ejecutando el comando inspect contra la dirección de tu cuenta:

Toma nota del string hexadecimal de “Public key (hex)” -Clave pública (hex)-. Esta es la clave pública de tu cuenta.

Ejecutando el comando inspect en su clave pública junto con el parámetro –-public se devuelve la dirección SS58 para la red por defecto (substrate).

Usando la bandera --network, puedes definir la red que te gustaría inspeccionar, donde la dirección SS58 se basará en esa red. Ahora, ejecutando el comando inspect con --network polkadot devuelve tu dirección Polkadot original, verificando así la clave pública.

 Observarás que la Herramienta Subkey reconoce la red de direcciones correcta y devuelve la clave pública asociada. La clave pública se devuelve como una cadena hexadecimal (es decir, con el prefijo “0x“). Para ambas direcciones SS58, se devuelve la misma clave pública.

Verificación de direcciones

Considera el siguiente ejemplo:

Si te sientes lo suficientemente cómodo como para distinguir cada parámetro de la cuenta, puedes anteponer a la cadena de clave pública “0x” por tu cuenta:

De: DOTs de pago a la cuenta de Polkadot:192c3c7e5789b461fb1c7f614ba5eed0b22efc507cda60a5e7fda8e046bcdce, prefijamos la dirección por “0x” -> 0x192c3c7e5789b461fb1c7f614ba5eed0b22efc507cda60a5e7fda8e046bcdce.

Utilizando el handy subscan tool, puedes verificar ambas asociaciones de direcciones a tu clave pública. Copia tu clave pública en el cuadro de texto “Input Account or Public Key” (Introducir cuenta o clave pública) y haz clic en “Transform” (Transformar) en la parte inferior. En la parte derecha, las direcciones para Polkadot y Substrate que se devuelven en base a tu clave pública deberían coincidir con las que inspeccionaste.

• NOTA: Es posible que tengas que desplazarte hasta la parte inferior del menú para encontrar la dirección de Substrate basándose en los listados del menú. Observarás que muchas redes que también utilizan la misma dirección de Substrate.

Puedes verificar tu verificación de clave pública recordando que las direcciones de Polkadot comienzan con un “1”, mientras que las direcciones de Substrate generalmente comienzan con un “5” (las direcciones de Kusama comienzan con una letra mayúscula). Ver Addresses (Direcciones) para más detalles.

Además, se pueden consultar los Scripts de Utilidad para saber cómo se realiza la verificación: pubkeyToAddress.js demuestra cómo una sola clave pública interpreta una dirección Polkadot, Substrate o Kusama.

Recursos #

Understanding Accounts and Keys in Polkadot – Una explicación de para qué se usan los diferentes tipos de cuentas y claves en Polkadot, con Bill Laboon y Chinmay Patel de BlockX Labs.