Sistema de nombres de Bitcoin
Bitcoin Name System (BNS) es un sistema de red que vincula nombres de usuario de Stacks a estado fuera de cadena sin depender de puntos centrales de control.
La cadena de bloques Stacks V1 implementó BNS mediante operaciones de nombres de primer orden. En Stacks V2, BNS se implementa en su lugar mediante un contrato inteligente cargado durante el bloque génesis.
Los nombres en BNS tienen tres propiedades:
Los nombres son globalmente únicos. El protocolo no permite colisiones de nombres, y todos los nodos bien comportados resuelven un nombre dado al mismo estado.
Los nombres tienen significado para los humanos. Cada nombre es elegido por su creador.
Los nombres son fuertemente poseídos. Solo el propietario del nombre puede cambiar el estado al que se resuelve. Específicamente, un nombre es propiedad de una o más claves privadas ECDSA.
La cadena de bloques Stacks asegura que la vista de BNS de cada nodo esté sincronizada con la de todos los demás nodos del mundo, por lo que las consultas en un nodo serán las mismas en otros nodos. Los nodos de la cadena de bloques Stacks permiten que el propietario de un nombre vincule hasta 40 Kb de estado fuera de cadena a su nombre, que será replicado a todos los demás nodos de la cadena de bloques Stacks mediante una red P2P.
La mayor consecuencia para los desarrolladores es que en BNS, leer el estado de un nombre es rápido y barato, pero escribir el estado de un nombre es lento y caro. Esto se debe a que registrar y modificar nombres requiere que se envíen una o más transacciones a la cadena de bloques subyacente, y los nodos BNS no las procesarán hasta que estén suficientemente confirmadas. Los usuarios y desarrolladores deben adquirir y gastar la criptomoneda requerida (STX) para enviar transacciones BNS.
Motivación detrás de los sistemas de nombres
Dependemos de los sistemas de nombres en la vida cotidiana, y juegan un papel crítico en muchas aplicaciones diferentes. Por ejemplo, cuando buscas a un amigo en una red social, estás usando el sistema de nombres de la plataforma para resolver su nombre a su perfil. Cuando buscas un sitio web, usas el Servicio de Nombres de Dominio para resolver el nombre de host a la dirección IP de su host. Cuando revisas una rama de Git, tu cliente Git resuelve el nombre de la rama a un hash de confirmación. Cuando buscas la clave PGP de alguien en un servidor de claves, resuelves su ID de clave a su clave pública.
¿Qué tipo de cosas queremos que sean verdaderas sobre los nombres? En BNS, los nombres son globalmente únicos, significativos para los humanos y fuertemente poseídos. Sin embargo, si observas estos ejemplos, verás que cada uno de ellos solo garantiza dos de estas propiedades. Esto limita cuán útiles pueden ser.
En DNS y redes sociales, los nombres son globalmente únicos y legibles por humanos, pero no están fuertemente poseídos. El operador del sistema tiene la decisión final sobre a qué se resuelve cada nombre.
Problema: Los clientes deben confiar en que el sistema tomará la decisión correcta sobre a qué se resuelve un nombre dado. Esto incluye confiar en que nadie excepto los administradores del sistema pueda hacer estos cambios.
En Git, los nombres de ramas son significativos para los humanos y fuertemente poseídos, pero no son globalmente únicos. Dos nodos Git diferentes pueden resolver el mismo nombre de rama a estados de repositorio no relacionados y diferentes.
Problema: Dado que los nombres pueden referirse a estados conflictivos, los desarrolladores tienen que idear algún otro mecanismo para resolver ambigüedades.
En PGP, los nombres son IDs de clave. Son globalmente únicos y propiedad criptográfica, pero no legibles por humanos. Los IDs de clave PGP se derivan de las claves a las que hacen referencia.
Problema: Estos nombres son difíciles de recordar para la mayoría de los usuarios dado que no contienen información semántica relacionada con su uso en el sistema.
Los nombres BNS tienen las tres propiedades, y ninguno de estos problemas. Esto lo convierte en una herramienta poderosa para construir todo tipo de aplicaciones en red. Con BNS, podemos hacer lo siguiente y más:
Construir servicios de nombres de dominio donde los nombres de host no puedan ser secuestrados.
Construir plataformas de redes sociales donde los nombres de usuario no puedan ser robados por atacantes de phishing.
Construir sistemas de control de versiones donde las ramas de repositorio no entren en conflicto.
Construir infraestructura de clave pública donde sea fácil para los usuarios descubrir y recordar las claves de los demás.
Organización de BNS
Los nombres BNS están organizados en una jerarquía global de nombres. Hay tres capas diferentes en esta jerarquía relacionadas con el nombrado:
Espacios de nombres. Estos son los nombres de nivel superior en la jerarquía. Una analogía a los espacios de nombres de BNS son los dominios de nivel superior de DNS. Los espacios de nombres BNS existentes incluyen
.id,.podcast, y.helloworld. Todos los demás nombres pertenecen a exactamente un espacio de nombres. Cualquiera puede crear un espacio de nombres, pero para que el espacio de nombres sea persistido, debe ser lanzado para que cualquiera pueda registrar nombres en él. Los espacios de nombres no son propiedad de sus creadores.Nombres BNS. Estos son nombres cuyos registros se almacenan directamente en la cadena de bloques. La propiedad y el estado de estos nombres se controlan enviando transacciones a la cadena de bloques. Ejemplos de nombres incluyen
verified.podcastymuneeb.id. Cualquiera puede crear un nombre BNS, siempre que el espacio de nombres que lo contiene ya exista.Subdominios BNS. Estos son nombres cuyos registros se almacenan fuera de la cadena, pero están anclados colectivamente a la cadena de bloques. La propiedad y el estado de estos nombres viven dentro de los datos de la red P2P. Aunque los subdominios BNS son propiedad de claves privadas separadas, el propietario de un nombre BNS debe transmitir su estado de subdominio. Ejemplos de subdominios incluyen
jude.personal.idypodsaveamerica.verified.podcast. A diferencia de los espacios de nombres y nombres BNS, el estado de los subdominios BNS no forma parte de las reglas de consenso de la cadena de bloques.
Una matriz de comparación de características que resume las similitudes y diferencias entre estos objetos de nombre:
Característica
Espacios de nombres
Nombres BNS
Subdominios BNS
Globalmente único
X
X
X
Significativo para los humanos
X
X
X
Propiedad de una clave privada
X
X
Cualquiera puede crear
X
X
[1]
El propietario puede actualizar
X
[1]
Estado alojado en cadena
X
X
Estado alojado fuera de cadena
X
X
Comportamiento controlado por reglas de consenso
X
X
Puede tener una fecha de expiración
X
[1] Requiere la cooperación del propietario de un nombre BNS para transmitir sus transacciones
Espacios de nombres
Los espacios de nombres son los objetos de nombre de nivel superior en BNS. Controlan algunas propiedades sobre los nombres dentro de ellos:
Cuán caros son de registrar
Cuánto tiempo duran antes de tener que renovarse
Quién (si alguien) recibe las tarifas de registro de nombres
Quién tiene permitido sembrar el espacio de nombres con sus nombres iniciales
Al momento de redactar esto, con mucho el espacio de nombres BNS más grande es el .id espacio de nombres. Los nombres en el .id espacio de nombres están pensados para resolver identidades de usuarios. Los nombres cortos en .id son más caros que los nombres largos, y deben ser renovados por sus propietarios cada dos años. Las tarifas de registro de nombres no se pagan a nadie en particular: en su lugar se envían a un "agujero negro" donde se vuelven no gastables (la intención es desalentar a los ocupantes de IDs).
A diferencia de DNS, cualquiera puede crear un espacio de nombres y establecer sus propiedades. Los espacios de nombres se crean por orden de llegada, y una vez creados, duran para siempre.
Sin embargo, crear un espacio de nombres no es gratis. El creador del espacio de nombres debe quemar criptomoneda para hacerlo. Cuanto más corto sea el espacio de nombres, más criptomoneda debe quemarse (es decir, los espacios de nombres cortos son más valiosos que los largos). Por ejemplo, a Blockstack PBC le costó 40 BTC crear el .id espacio de nombres en 2015 (en la transacción 5f00b8e609821edd6f3369ee4ee86e03ea34b890e242236cdb66ef6c9c6a1b281).
Los espacios de nombres pueden tener entre 1 y 19 caracteres de longitud, y están compuestos por los caracteres a-z, 0-9, -, y _.
Subdominios
Los nombres BNS son fuertemente poseídos porque el propietario de su clave privada puede generar transacciones válidas que actualicen su hash de archivo de zona y propietario. Sin embargo, esto tiene el costo de requerir que el propietario de un nombre pague la transacción subyacente en la cadena de bloques. Además, este enfoque limita la tasa de registros y operaciones de nombres BNS al ancho de banda de transacciones de la cadena de bloques subyacente.
BNS supera esto con subdominios. Un subdominio BNS es un tipo de nombre BNS cuyo estado y propietario se almacenan fuera de la cadena de bloques, pero cuya existencia e historial de operaciones están anclados a la cadena. Como sus contrapartes en cadena, los subdominios son globalmente únicos, fuertemente poseídos y legibles por humanos. BNS les da su propio estado de nombre y claves públicas. A diferencia de los nombres en cadena, los subdominios pueden crearse y gestionarse de forma barata, porque se transmiten a la red BNS en lotes. Una sola transacción de cadena de bloques puede enviar hasta 120 operaciones de subdominio.
Esto se logra almacenando registros de subdominios en los archivos de zona de nombres BNS. Un propietario de nombre en cadena transmite operaciones de subdominio codificándolas como TXT registros dentro de un archivo de zona DNS. Para transmitir el archivo de zona, el propietario del nombre establece el nuevo hash del archivo de zona con una NAME_UPDATE transacción y replica el archivo de zona. Esto, a su vez, replica todas las operaciones de subdominio que contiene y ancla el conjunto de operaciones de subdominio a una transacción en cadena. Las reglas de consenso del nodo BNS aseguran que solo se almacenarán operaciones de subdominio válidas provenientes de NAME_UPDATE transacciones válidas.
Por ejemplo, el nombre verified.podcast escribió una vez el hash del archivo de zona 247121450ca0e9af45e85a82e61cd525cd7ba023, que es el hash del siguiente archivo de zona:
Cada TXT registro en este archivo de zona codifica una creación de subdominio. Por ejemplo, 1yeardaily.verified.podcast se resuelve a:
Esta información fue extraída del 1yeardaily TXT registro de recursos en el archivo de zona para verified.podcast.
Ciclo de vida del subdominio
Creación
Una operación de creación de subdominio es creada por el propietario del subdominio y codificada en un TXT registro en el archivo de zona del propietario del nombre en cadena. El propietario del nombre en cadena transmite el archivo de zona emitiendo una NAME_UPDATE transacción, que ancla la creación del subdominio en cadena.
Actualización
Las actualizaciones de subdominios se realizan fuera de la cadena creando operaciones firmadas con la clave privada del propietario del subdominio. Cualquier propietario de nombre en cadena puede incluir estas operaciones firmadas en su archivo de zona y transmitirlas vía NAME_UPDATE. Las operaciones se ordenan por un número de secuencia y requieren una firma válida que vincule con la clave pública de la operación anterior.
Transferencia
Para cambiar la dirección (hash de clave pública) que posee un subdominio, el propietario del subdominio firma una operación de transferencia de subdominio y pide a un propietario de nombre en cadena (típicamente quien creó el subdominio) que la transmita vía NAME_UPDATE. El archivo de zona del propietario del nombre en cadena que transmite debe estar presente en la red Atlas para demostrar la ausencia de operaciones conflictivas.
Reglas de secuencia y validación
Las operaciones de subdominio se ordenan por número de secuencia, comenzando en 0. Cada nueva operación debe incluir:
El siguiente número de secuencia
La clave pública que hace hash a la dirección de la transacción previa del subdominio
Una firma de la clave privada correspondiente sobre toda la operación de subdominio
Si dos operaciones correctamente firmadas pero conflictivas tienen el mismo número de secuencia, se acepta la que esté más temprano en la historia de la cadena de bloques. Las operaciones inválidas se ignoran.
Reglas de creación y gestión de subdominios
Una transacción de creación de subdominio solo puede ser procesada por el propietario del nombre en cadena que comparte su sufijo (por ejemplo, solo el propietario de
res_publica.idpuede transmitir creaciones para*.res_publica.id).Una transacción de transferencia de subdominio solo puede ser transmitida por el propietario del nombre en cadena que la creó.
Para enviar una creación o transferencia de subdominio, todos los archivos de zona del propietario del nombre en cadena deben estar presentes en la red Atlas. Esto permite demostrar la ausencia de operaciones conflictivas.
Una actualización de subdominio puede ser transmitida por cualquier propietario de nombre en cadena, pero el propietario del subdominio necesita encontrar un propietario de nombre en cadena cooperante para incluirla y transmitirla.
Para crear un subdominio, el propietario del subdominio genera la operación de creación y se la entrega al propietario del nombre en cadena. Una vez creado, el propietario del subdominio puede usar cualquier propietario de nombre en cadena para transmitir actualizaciones proporcionando operaciones firmadas empaquetadas en archivos de zona.
Registradores de subdominios
Debido a que los nombres de subdominios son baratos, los desarrolladores pueden ejecutar registradores de subdominios para sus aplicaciones. Por ejemplo, el nombre personal.id se usa para registrar nombres de usuario sin requerir que los usuarios gasten Bitcoin.
Hay una implementación de referencia disponible: https://github.com/stacks-network/subdomain-registrar. Los usuarios aún son propietarios de sus nombres de subdominio; el registrador ayuda a los desarrolladores a transmitir operaciones de subdominio.
BNS y estándares DID
Los nombres BNS cumplen con la especificación emergente del protocolo de la Decentralized Identity Foundation (DIF) para identificadores descentralizados (DIDs): http://identity.foundation
Cada nombre en BNS tiene un DID asociado. El formato DID para BNS es:
Dónde:
{address}es un hash de clave pública en cadena (por ejemplo una dirección Bitcoin).{index}se refiere aln-ésimonombre que esta dirección creó.
Ejemplos:
personal.id→did:stack:v0:1dARRtzHPAFRNE7Yup2Md9w18XEQAtLiV-0(primer nombre creado por esa dirección)jude.id→did:stack:v0:16EMaNw3pkn3v6f2BgnSSs53zAKH4Q8YJg-1(la dirección había creado un nombre anterior antes que este)
Propósito: un DID proporciona un identificador eterno para una clave pública. La clave pública puede cambiar, pero el DID no lo hará.
Para que un DID sea resolvible, todo lo siguiente debe ser verdadero para un nombre:
El nombre debe existir
El hash del archivo de zona del nombre debe ser el hash de un archivo de zona DNS bien formado
El archivo de zona DNS debe estar presente en los datos del nodo Stacks
El archivo de zona DNS debe contener un
URIregistro de recurso que apunte a un JSON Web Token firmadoLa clave pública que firmó el JSON Web Token (y que está incluida con él) debe hacer hash a la dirección que posee el nombre
No todos los nombres tendrán DIDs que se resuelvan a claves públicas. Los nombres creados por herramientas estándar tendrán DIDs que sí lo hagan.
Se está desarrollando una API RESTful.
Codificación DID para subdominios
Cada nombre y subdominio en BNS tiene un DID. La codificación difiere para que el software pueda determinar qué ruta de código tomar.
Para los nombres BNS en cadena, el
{address}es el mismo que la dirección Bitcoin que posee el nombre. Actualmente se soportan direcciones con byte de versión 0 y byte de versión 5 (direcciones que comienzan con1o3, lo que significap2pkhyp2shdirecciones).Para los subdominios BNS fuera de cadena, el
{address}tiene byte de versión 63 para subdominios poseídos por una sola clave privada, y byte de versión 50 para subdominios poseídos por un conjunto m-de-n de claves privadas. Es decir, las direcciones DID de subdominios empiezan conSoM, respectivamente.
El {index} el campo para el DID de un subdominio es distinto del {index} campo para el DID de un nombre BNS, incluso si la misma dirección creó ambos nombres y subdominios. Ejemplo:
El nombre
abcdefgh123456.id→did:stack:v0:16EMaNw3pkn3v6f2BgnSSs53zAKH4Q8YJg-0(primer nombre creado por esa dirección)El subdominio
jude.statism.idcreado por la misma dirección →did:stack:v0:SSXMcDiCZ7yFSQSUj7mWzmDcdwYhq97p2i-0
Nota: La dirección SSXMcDiCZ7yFSQSUj7mWzmDcdwYhq97p2i codifica el mismo hash de clave pública que 16EMaNw3pkn3v6f2BgnSSs53zAKH4Q8YJg—la diferencia es el byte de versión base58check (63 frente a 0).
Última actualización
¿Te fue útil?