Esta página sirve como introducción de alto nivel al protocolo Polkadot con terminología que puede ser específica de Polkadot, diferencias notables con otras cadenas con las que puedes haber trabajado, e información práctica para tratar con la cadena.
Tokens #
- Decimales de tokens:
* Polkadot (DOT): 10
* Kusama (KSM): 12 - Unidad base: “Planck¨
- Tipo de balance: u128
Redenominación #
Polkadot realizó una encuesta, que finalizó el 27 de julio de 2020 (bloque 888_888), en la que los stakeholders decidieron redenominar el token DOT. La redenominación no cambia el número de unidades base (llamadas “plancks” en Polkadot) en la red. El único cambio es que un solo token DOT tendrá 1e10 plancks en lugar de los 1e12 plancks originales. Consulta las entradas del blog de Polkadot en las que se explican los detalles y los resultados de la votación.
La redenominación entró en vigor 72 horas después de que se habilitaran las transferencias, en el bloque 1_248_326, lo que ocurrió aproximadamente a las 16:50 UTC del 21 de agosto de 2020.
Addresses (Direcciones) #
En Polkadot (y en la mayoría de las cadenas de Substrate), las cuentas de usuario se identifican mediante un AccountId de 32 bytes (256 bits). Esto es a menudo, pero no siempre, la clave pública de un par de claves criptográficas.
Polkadot (y Substrate) utilizan el formato de address (dirección) SS58. Este es un amplio “meta-formato” diseñado para manejar muchos esquemas criptográficos y cadenas diferentes. Tiene mucho en común con el formato Base58Check de Bitcoin, como un prefijo de versión, un sufijo de suma de comprobación basada en hash y codificación en base-58.
Consulta la página SS58 en la documentación de Substrate para obtener información sobre la codificación y una lista más completa de prefijos de red.
NO UTILICES EXPRESIONES REGULARES (REGEX) PARA VALIDAR DIRECCIONES
Verifícalas siempre utilizando el prefijo y la suma de comprobación de la address (dirección). La API de Substrate Sidecar proporciona una ruta accounts/{accountId}/validate que devuelve una respuesta booleana isValid para una address (dirección) proporcionada.
Prefijos SS58 relevantes para esta guía:
- Polkadot: 0
- Kusama: 2
- Westend 42
Criptografía #
Polkadot admite los siguientes pares de claves criptográficas y algoritmos de firma:
- Ed25519
- Sr25519 – Firmas Schnorr sobre el grupo Ristretto
- Firmas ECDSA en secp256k1
Ten en cuenta que la address (dirección) de una clave secp256k1 es la codificación SS58 del hash de la clave pública para reducir la clave pública de 33 a 32 bytes.
Depósito existencial #
Polkadot, y la mayoría de las cadenas basadas en Substrate, utilizan un depósito existencial (ED) para evitar que las cuentas dust inflen el estado de la cadena. Si una cuenta cae por debajo del ED, será reaped (cosechada), es decir, completamente eliminada del almacenamiento y el nonce reiniciado. El ED de Polkadot es 1 DOT, mientras que el de Kusama es 33,3333 microKSM (0,0000333333 KSM). Siempre puedes verificar el depósito existencial comprobando el estado de la cadena para la constante balances.existentialDeposit.
Del mismo modo, si envías una transferencia con valor inferior al ED a una cuenta nueva, fallará. Las wallets (billeteras o monederos) custodios deben establecer una cantidad mínima de retiros que sea mayor que el ED para garantizar retiros exitosos.
Las wallets y custodios que realizan un seguimiento de los nonces de cuenta con fines de auditoría deben tener cuidado de que no se cosechen cuentas, ya que los usuarios podrían volver a fondear la dirección e intentar realizar transacciones desde ella. El pallet Balances proporciona una función transfer_keep_alive que devolverá un error y abortará en lugar de realizar la transferencia si al hacerlo se cosechara (reaping) la cuenta del remitente.
IMPORTANTE: EL DEPÓSITO EXISTENCIAL ES UNA PROPIEDAD DE LA RELAY CHAIN
Tu cuenta en la Relay Chain no tiene un impacto directo en las parachains ya que tienes cuentas separadas en cada parachain. Sin embargo, las parachains pueden definir un depósito existencial propio, pero éste es independiente del ED de la Relay Chain.
DEPÓSITO EXISTENCIAL PARA STATEMINT
La parachaina Statemint tiene un depósito existencial más bajo (0,1 DOT) que la Relay Chain (1 DOT), así como comisiones de transacción más bajas. Se recomienda encarecidamente gestionar las transferencias de saldo en Statemint. La integración de Statemint se discute en la siguiente página de la guía.
Balance Libre vs. Reservado vs. Bloqueado vs. Vesting #
La información del balance de la cuenta se almacena en AccountData. Polkadot maneja principalmente dos tipos de balances (saldos): libre y reservado.
Para la mayoría de las operaciones, el balance libre es lo que te interesa. Es el “poder” de una cuenta en staking y gobernanza, por ejemplo. El balance reservado representa los fondos que han sido reservados por alguna operación y siguen perteneciendo al titular de la cuenta, pero no pueden utilizarse.
Los bloqueos son una abstracción sobre el balance libre que impiden el gasto para determinados fines. Varios bloqueos pueden operar sobre la misma cuenta, pero se solapan en lugar de sumarse. Los bloqueos se añaden automáticamente a las cuentas cuando se realizan tareas en la red (por ejemplo, alquilar un slot de parachain o votar), no son personalizables. Por ejemplo, una cuenta puede tener un balance libre de 200 DOT con dos bloqueos: 150 DOT para Transfer y 100 DOT para Reserve. La cuenta no podría hacer una transferencia que llevara su balance libre por debajo de 150 DOT, pero una operación podría resultar en la reserva de DOT de tal manera que el balance libre estuviera por debajo de 150, pero por encima de 100 DOT.
Los bonding tokens para staking y votación en los referendos de gobernanza utilizan ambos bloqueos.
Vesting es otra abstracción que utiliza bloqueos en el balance libre. El vesting establece un bloqueo que disminuye con el tiempo hasta que todos los fondos son transferibles.
Más información:
Extrinsics y events #
Formato de bloque #
Un bloque Polkadot consta de un block header (cabecera) y un block body (cuerpo). The block body se compone de extrinsics que representan la generalización del concepto de transacciones. Los extrinsics pueden contener cualquier dato externo que la cadena subyacente desee validar y rastrear.
El block header es una 5-tuple que contiene los siguientes elementos:
parent_hash: un hash Blake2b de 32 bytes del parent block header codificado en SCALE.number:un número entero que representa el índice del bloque actual en la cadena. Es igual al número de los bloques antecesores. El estado génesis tiene el número 0.state_root:el root (la raíz) del Merkle tree (árbol Merkle), utilizada como almacenamiento para el sistema.extrinsics_root:campo reservado para que el Runtime valide la integridad de los extrinsics que componen block body.digest: campo utilizado para almacenar cualquier dato auxiliar específico de la cadena, que podría ayudar a los light clients (clientes ligeros) a interactuar con el bloque sin necesidad de acceder al almacenamiento completo, así como datos relacionados con el consenso, incluida la firma del bloque.
Un nodo que crea o recibe un bloque debe hacer gossip a la red (es decir, a los demás nodos). Otros nodos de la red seguirán este anuncio y podrán solicitar información sobre el bloque. Para más detalles sobre el proceso, consulta aquí en Polkadot Spec.
Extrinsics #
Un extrinsic es un array (matriz) codificado en SCALE que consta de un version number, signature, y diversos tipos de data que indican la función resultante en runtime que debe llamarse, incluidos los parámetros necesarios para que se ejecute dicha función.
Los extrinsics constituyen información procedente del mundo exterior y adoptan tres formas:
- Inherentes
- Transacciones firmadas (signed transactions)
- Transacciones sin firma (unsigned transactions)
Como proveedor de infraestructuras, tratarás casi exclusivamente con transacciones firmadas. Sin embargo, verás otros extrinsics dentro de los bloques que descodifiques. Encuentra más información en la documentación de Substrate.
Los extrinsics inherentes no están firmados y contienen información que no es demostrablemente cierta, pero que los validadores aceptan basándose en alguna medida de razonabilidad. Por ejemplo, un timestamp (marca de tiempo) no se puede probar, pero los validadores pueden estar de acuerdo en que está dentro de cierta diferencia de tiempo en el reloj de su sistema. Los inherentes se difunden como parte de los bloques producidos en lugar de hacer gossip como extrinsics individuales.
Las transacciones firmadas contienen una firma de la cuenta que emitió la transacción y que está dispuesta a pagar un fee para que la transacción se incluya en la cadena. Dado que el valor de incluir transacciones firmadas on-chain (en la cadena) puede reconocerse antes de su ejecución, pueden hacer gossip en la red entre nodos con un bajo riesgo de spam. Las transacciones firmadas se ajustan al concepto de transacción en Ethereum o Bitcoin.
Algunas transacciones no pueden ser firmadas por una cuenta de pago y utilizan transacciones no firmadas. Por ejemplo, cuando un usuario reclama su DOT del contrato indicador DOT de Ethereum a una nueva address (dirección) DOT, la nueva dirección no tiene todavía fondos con los que pagar fees.
Polkadot Host no especifica o limita los aspectos internos de cada extrinsics y esos son definidos y tratados por el Runtime.
Transaction Mortality #
Los extrinsics pueden ser mortales o inmortales. La carga útil de la transacción incluye un número de bloque y un checkpoint de hash de bloque a partir del cual la transacción es válida y un periodo de validez (también llamado “era” en algunos lugares) que representa el número de bloques después del checkpoint (punto de control) para los que la transacción es válida. Si el extrinsic no se incluye en un bloque dentro de esta ventana de validez, se descartará de la cola de transacciones.
La cadena sólo almacena como referencia un número limitado de hashes de bloques anteriores. Puedes consultar este parámetro, llamado BlockHashCount, desde el estado de la cadena o los metadatos. Este parámetro se establece en 2400 bloques (unas cuatro horas) en la génesis. Si el periodo de validez es mayor que el número de bloques almacenados on-chain, entonces la transacción sólo será válida mientras haya un bloque con el que comprobarla, es decir, el valor mínimo del periodo de validez y el recuento hash de bloques.
Establecer el checkpoint de bloque a cero, utilizando el hash de génesis, y un periodo de validez de cero hará que la transacción sea “inmortal”.
NOTA: Si una cuenta es reaped (cosechada) y un usuario vuelve a fondear la cuenta, entonces podría reproducir una transacción inmortal. Utiliza siempre por defecto un extrinsic mortal.
Identificadores únicos para extrinsics #
PRECAUCIÓN
Asumir que el hash de una transacción es un identificador único es el error número uno que cometen los servicios de indexación y los custodios. Este error causará grandes problemas a sus usuarios. Asegúrate de leer detenidamente esta sección.
Muchos proveedores de infraestructura en blockchains existentes, por ejemplo Ethereum, consideran el hash de una transacción como un identificador único. En las cadenas basadas en Substrate como Polkadot, el hash de una transacción sólo sirve como una huella digital de la información dentro de una transacción, y hay veces en que dos transacciones con el mismo hash son ambas válidas. En el caso de que una no sea válida, la red gestiona adecuadamente la transacción y no cobra una fee de transacción al remitente ni tiene en cuenta la transacción en la totalidad del bloque.
Imaginemos este ejemplo artificioso con una cuenta reaped (cosechada). La primera y la última transacción son idénticas y ambas válidas.
Además, no todos los extrinsics de una cadena basada en Substrate proceden de una cuenta de par de claves pública/privada; Substrate, más bien, tiene el concepto de “origin” de envío, que podría crearse a partir de una cuenta de clave pública, pero también podría formarse a partir de otros medios como la gobernanza. Estos origins no tienen un nonce asociado como una cuenta. Por ejemplo, la gobernanza podría enviar la misma llamada con los mismos argumentos varias veces, como “aumentar el conjunto de validadores en un 10%”. Esta información de envío (y por tanto su hash) sería la misma, y el hash sería un representante fiable de la llamada, pero su ejecución tendría efectos diferentes dependiendo del estado de la cadena en el momento del envío.
La forma correcta de identificar unívocamente un extrinsic en una cadena basada en Substrate es utilizar el ID del bloque (height o hash) y el índice del extrinsic. Substrate define un bloque como una header y un array de extrinsics; por lo tanto, un índice en el array a un height (altura) canónico siempre identificará de forma única una transacción. Esta metodología se refleja en la propia base de código de Substrate, por ejemplo para hacer referencia a una transacción anterior del pallet Multisig.
Events #
Mientras que los extrinsics representan información del mundo exterior, los events (eventos) representan información de la cadena. Los extrinsics pueden desencadenar events. Por ejemplo, el pallet Staking emite un event Reward cuando se reclaman recompensas de staking para informar al usuario de cuánto se ha ingresado en la cuenta.
Si quieres monitorear depósitos en una dirección, ten en cuenta que varias transacciones pueden iniciar una transferencia de balance (como balances.transferKeepAlive y una transacción utility.batch con una transferencia dentro de ella). No bastará con supervisar únicamente las transacciones balances.transfer. Asegúrate de supervisar los events de cada bloque en busca de events que contengan tus direcciones de interés. Supervisa los events en lugar de los nombres de las transacciones para asegurarte de que puedes acreditar correctamente los depósitos.
Fees #
Polkadot utiliza fees (tarifas) basadas en el peso que, a diferencia del gas, se cobran pre-dispatch (antes del envío). Los usuarios también pueden añadir una “tip (propina)” para aumentar la prioridad de las transacciones durante periodos congestionados. Consulta la página de tarifas de transacción para más información.
Codificación #
Las herramientas de integración de Parity deberían permitirte tratar con datos decodificados. Si deseas evitarlas e interactuar directamente con los datos de la cadena o implementar tu propio códec, Polkadot codifica los datos de bloques y transacciones utilizando el códec SCALE.
Actualizaciones de Runtime #
Las actualizaciones de runtime permiten a Polkadot cambiar la lógica de la cadena sin necesidad de un hard fork. Un hard fork requeriría que los operadores de los nodos actualizaran manualmente sus nodos a la última versión del runtime. En un sistema distribuido, este es un proceso complejo de coordinar y comunicar. Polkadot puede actualizarse sin un hard fork. Se sigue la lógica del runtime existente para actualizar el runtime Wasm almacenado en la blockchain a una nueva versión. La actualización se incluye entonces en la propia blockchain, lo que significa que todos los nodos de la red la ejecutan.
Por lo general, no es necesario que actualices tus nodos manualmente antes de la actualización del runtime, ya que empezarán a seguir automáticamente la nueva lógica de la cadena. Sólo es necesario actualizar los nodos cuando el runtime requiera nuevas funciones del host o se produzca un cambio en la red o en el consenso.
Las transacciones construidas para una determinada versión de runtime no funcionarán en versiones posteriores. Por lo tanto, una transacción construida en base a una versión de runtime no será válida en versiones de runtime posteriores. Si no crees que puedas enviar una transacción antes de la actualización, es mejor esperar y construirla después de que se produzca la actualización.
Aunque actualizar tus nodos no es generalmente necesario para seguir una actualización, recomendamos seguir las versiones de Polkadot y actualizar a tiempo, especialmente para versiones de alta prioridad o críticas.
Smart Contracts #
La Relay Chain Polkadot no soporta smart contracts (contratos inteligentes).
Otras redes #
Además de ejecutar una red privada, Polkadot tiene otras dos redes donde se puede probar la infraestructura antes de desplegar a la mainnet Polkadot.
Red Canaria Kusama: Kusama es el primo de vanguardia de Polkadot. Muchas características de riesgo hacen deploy en Kusama antes de llegar a Polkadot.
Westend Testnet: Westend es la red de pruebas (testnet) de Polkadot y utiliza el runtime de Polkadot.
Otras preguntas frecuentes #
¿Puede cambiar el balance de una cuenta sin la correspondiente transacción on-chain?
No, pero no todos los cambios de balance son en una transacción, algunos son en events. Tendrás que ejecutar un nodo de archivo y escuchar los events y transacciones para realizar un seguimiento de toda la actividad de la cuenta. Esto se aplica especialmente a las operaciones de bloqueo si estás calculando el balance como el balance gastable, es decir, el balance libre menos el bloqueo máximo.
¿Qué profundidad de cadena se considera “segura”?
Polkadot utiliza un mecanismo de finalidad determinista. Una vez que un bloque ha finalizado, no puede ser revertido excepto por un hard fork. Kusama ha tenido hard forks que han tenido que revertir cuatro bloques finalizados para cancelar una actualización de runtime. Utilizar una profundidad de finalización de diez bloques debería ser seguro.
Ten en cuenta que la producción de bloques y la finalización son procesos aislados en Polkadot, y la cadena puede tener un head largo sin finalizar.
¿Los usuarios necesitan interactuar con algún smart contract?
No, los usuarios interactúan directamente con la lógica de la cadena.
¿Tiene Polkadot state rent?
No, Polkadot utiliza el depósito existencial para evitar cuentas dust y otros mecanismos económicos como el bloqueo o la reserva de tokens para operaciones que utilizan estado.
¿Cuál es una fuente externa para ver la altura actual de la cadena?