De la clave pública a la dirección: formatos en distintas redes

Una dirección es una representación del protocolo, no un identificador universal

Una dirección de blockchain es una forma específica de una red para referirse a una cuenta, un destino o un conjunto de condiciones de gasto. Muchas direcciones están relacionadas, en última instancia, con la criptografía de clave pública, pero el proceso para convertir una clave pública en una dirección que se muestra no es universal. Algunas redes aplican un hash a una clave pública, otras codifican la clave pública directamente y otras permiten destinos derivados de la lógica de un programa o de múltiples condiciones. Por consiguiente, decir que «una dirección es solo una clave pública» es una generalización excesiva. Del mismo modo, las direcciones no contienen un nombre personal verificado, y un mismo texto de dirección puede tener significados distintos en diferentes redes.

Una codificación define cómo los bytes se convierten en caracteres legibles. Base58 utiliza un alfabeto elegido para evitar ciertos caracteres que pueden confundirse visualmente. El sistema hexadecimal utiliza base 16, con los dígitos del 0 al 9 y las letras de la a a la f. Bech32 utiliza un alfabeto distinto e incluye un mecanismo de suma de verificación para detectar muchos errores de transcripción. Un prefijo puede ayudar a indicar una red o una familia de direcciones, pero no constituye una verificación independiente de la propiedad. Los lectores deben reconocer los formatos y dejar la validación definitiva al software que comprende la red específica y sus reglas.

Bitcoin: distintas formas de describir las condiciones de gasto

Las direcciones de Bitcoin suelen representar destinos de salida: las condiciones bajo las cuales se pueden gastar posteriormente las monedas incluidas en una salida específica. En un patrón antiguo de pago a hash de clave pública (P2PKH), el destino codifica un hash asociado a una clave pública y suele mostrarse mediante Base58Check; en la red principal de Bitcoin, a menudo comienza con «1». Las direcciones de pago a hash de script (P2SH) suelen comenzar con «3» en la red principal y representan el hash de un script de canje, en lugar de simplemente la clave pública de una persona. Un script P2SH puede contener condiciones que no son visibles solo a partir de la dirección.

Las salidas nativas de Segregated Witness (SegWit), versión 0, utilizan la codificación de direcciones Bech32 de acuerdo con la Propuesta de mejora de Bitcoin (BIP) 173 y suelen comenzar con «bc1q» en la red principal. Las salidas nativas de testigo de versión 1 y posteriores utilizan Bech32m, según la BIP 350; las direcciones Taproot suelen comenzar con «bc1p». Las reglas exactas de gasto dependen del programa de testigo y del tipo de script. Estas cadenas son ejemplos de familias de direcciones, no reglas de validación exhaustivas. Una persona no debe inferir que cualquier cadena arbitraria que comience con «bc1p» es, por lo tanto, válida. El software debe verificar la longitud, el alfabeto, la suma de verificación, la versión de testigo y otras restricciones descritas en la especificación aplicable.

Por qué coexisten los formatos antiguos y los nuevos

Un formato de dirección forma parte de un protocolo y de su ecosistema de aplicaciones. Las nuevas técnicas de codificación pueden mejorar la detección de errores o admitir nuevos tipos de gasto, mientras que los tipos de destino anteriores siguen presentes en los registros históricos y a menudo continúan siendo utilizables. Esta coexistencia no implica que un formato mostrado represente un activo distinto. Tampoco significa que un usuario pueda convertir un destino de forma segura a otro formato cambiando su prefijo. La conversión no consiste en editar texto: se deben preservar las condiciones de gasto subyacentes y las reglas del protocolo. Cuando un analista encuentra varios formatos, primero debe determinar si pertenecen a la misma red y qué información transmite cada uno.

Ethereum: direcciones de cuenta de 20 bytes

Las direcciones de las cuentas controladas externamente de Ethereum se forman convencionalmente con los últimos 20 bytes de un hash Keccak-256 de una clave pública representada de la forma adecuada. Suelen mostrarse con el prefijo «0x» seguido de 40 caracteres hexadecimales. Ethereum también tiene cuentas de contrato, cuyas direcciones identifican código desplegado y no se derivan de una clave privada convencional correspondiente de la misma manera. La Propuesta de mejora de Ethereum 55 (EIP-55), codificación de direcciones con suma de verificación y uso de mayúsculas y minúsculas, utiliza la capitalización de las letras de la cadena hexadecimal como mecanismo opcional para detectar errores tipográficos. También se pueden utilizar representaciones completamente en minúsculas; la validación de la suma de verificación con mayúsculas y minúsculas mezcladas ayuda a detectar algunos errores, pero no puede establecer la identidad del destinatario.

Numerosas redes compatibles con la Máquina Virtual de Ethereum utilizan una sintaxis de direcciones que también comienza con «0x». Que una secuencia de 20 bytes coincida en dos redes no significa que ambas compartan saldos o historiales de transacciones. Un token en una red de este tipo puede estar asociado a una dirección de contrato inteligente, mientras que el saldo de un usuario se registra en el estado del contrato. La dirección del contrato, la dirección de cuenta del usuario, un identificador de transacción y el símbolo legible de un activo se refieren a cosas distintas. Confundirlos puede dar lugar a informes erróneos, incluso cuando todos los caracteres copiados sean correctos.

Solana: direcciones basadas en valores de 32 bytes

Una dirección de cuenta de Solana es un valor de 32 bytes que se muestra en Base58. Un tipo de dirección es una clave pública asociada a un par de claves Ed25519; otro es una dirección derivada de un programa (PDA), calculada a partir de un identificador de programa y semillas según las reglas de direcciones de Solana. Una PDA no tiene una clave privada correspondiente que pueda firmar de la forma habitual. En su lugar, un programa autorizado puede actuar en nombre de esa dirección mediante reglas de ejecución definidas. Este ejemplo ilustra por qué no se puede describir cada dirección como un hash abreviado de una clave pública. En el modelo de cuentas de Solana, la dirección de cuenta identifica el estado, mientras que el campo de propietario de la cuenta determina qué programa puede modificar esos datos conforme a las reglas de la red.

Reconocer, validar y atribuir

Una dirección puede parecer válida y, sin embargo, pertenecer a la red equivocada. Una suma de verificación puede detectar muchos errores tipográficos accidentales, pero una dirección bien formada aún puede identificar a un destinatario no previsto o un programa con un comportamiento inesperado. Las capturas de pantalla que ocultan los caracteres del medio también pueden ocultar sustituciones. Antes de interpretar un registro de pago, hay que distinguir la validez sintáctica de la compatibilidad con la red, y ambas de la identidad humana del titular. Una etiqueta de explorador como «billetera de servicio» es una afirmación proporcionada por un operador o una fuente de datos, no algo que esté codificado matemáticamente en la mayoría de las cadenas de direcciones.

1. Identifique la red exacta y, cuando corresponda, el entorno de red, como la red principal o una red de prueba.
2. Determine si la cadena es una dirección de cuenta, una dirección de contrato, un destino de salida, un identificador de transacción u otro objeto.
3. Valide el valor completo con un analizador adecuado para la red, no solo por su prefijo.
4. Para atribuirlo, recopile pruebas independientes; no equipare la coincidencia de una suma de verificación con una persona o institución verificada.

Los formatos de direcciones están optimizados intencionalmente para que las máquinas los interpreten con exactitud, no para que las personas los memoricen. En un informe del sector público, una formulación adecuada sería «esta transacción hace referencia al destino X en la red Y», no «la persona Z recibió los fondos», a menos que otras pruebas justifiquen esa atribución. La siguiente lección muestra cómo aparecen estas distinciones entre direcciones e identificadores en los registros que ofrecen los exploradores de bloques. El siguiente módulo del curso tratará la gestión práctica de claves, frases semilla y relaciones de custodia.

Enfoque del examen: Compare las familias de direcciones Bitcoin Base58Check, Bech32 y Bech32m; las direcciones hexadecimales de Ethereum y EIP-55; y las cuentas Solana Base58, incluidas las direcciones derivadas de programas. Explique por qué una dirección no es universalmente una clave pública ni una identidad verificada, y por qué un texto idéntico en distintas redes no implica un estado idéntico.