BNSv1 (heredado)
El contenido de esta página se refiere al BNS v1 heredado.
Bitcoin Name System (BNS) es un sistema de red que vincula los nombres de usuario de Stacks con estado fuera de la cadena sin depender de ningún punto central 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 que se comportan correctamente resuelven un nombre dado al mismo estado.
Los nombres tienen significado humano. Cada nombre es elegido por su creador.
Los nombres están fuertemente poseídos. Solo el propietario del nombre puede cambiar el estado al que resuelve. Específicamente, un nombre es propiedad de una o más claves privadas ECDSA.
La cadena de bloques de Stacks garantiza que la vista BNS de cada nodo esté sincronizada con la de todos los demás nodos del mundo, de modo que las consultas en un nodo serán las mismas en otros nodos. Los nodos de la cadena de bloques de Stacks permiten que el propietario de un nombre vincule hasta 40 Kb de estado fuera de la cadena a su nombre, que se replicará a todos los demás nodos de la cadena de bloques de Stacks a través de 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 costoso. Esto se debe a que registrar y modificar nombres requiere que se envíe 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 necesaria (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 desempeñan un papel fundamental en muchas aplicaciones diferentes. Por ejemplo, cuando buscas a un amigo en redes sociales, estás usando el sistema de nombres de la plataforma para resolver su nombre a su perfil. Cuando buscas un sitio web, estás usando el Servicio de Nombres de Dominio para resolver el nombre de host a la dirección IP de su servidor. Cuando haces checkout de una rama de Git, estás usando tu cliente Git para resolver el nombre de la rama a un hash de commit. Cuando buscas la clave PGP de alguien en un servidor de claves, estás resolviendo su ID de clave a su clave pública.
¿Qué tipo de cosas queremos que sean ciertas sobre los nombres? En BNS, los nombres son globalmente únicos, los nombres tienen significado humano y los nombres están fuertemente poseídos. Sin embargo, si observas estos ejemplos, verás que cada uno de ellos solo garantiza dos de estas propiedades. Esto limita lo útiles que pueden ser.
En DNS y en las redes sociales, los nombres son globalmente únicos y legibles por humanos, pero no están fuertemente poseídos. El operador del sistema tiene la última palabra sobre a qué resuelve cada nombre.
Problema: los clientes deben confiar en que el sistema tome la decisión correcta sobre a qué resuelve un nombre dado. Esto incluye confiar en que nadie aparte de los administradores del sistema pueda hacer estos cambios.
En Git, los nombres de rama tienen significado humano y están fuertemente poseídos, pero no son globalmente únicos. Dos nodos de Git diferentes pueden resolver el mismo nombre de rama a estados de repositorio distintos y no relacionados.
Problema: dado que los nombres pueden referirse a estados en conflicto, 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 están poseídos criptográficamente, pero no son 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, ya que no llevan información semántica relacionada con su uso en el sistema.
Los nombres BNS tienen las tres propiedades, y ninguno de estos problemas. Esto los convierte en una herramienta poderosa para construir todo tipo de aplicaciones de red. Con BNS, podemos hacer lo siguiente y más:
Crear servicios de nombres de dominio en los que no se puedan secuestrar los nombres de host.
Crear plataformas de redes sociales en las que los nombres de usuario no puedan ser robados por estafadores.
Crear sistemas de control de versiones en los que las ramas del repositorio no entren en conflicto.
Crear infraestructura de clave pública en la que a los usuarios les resulte fácil descubrir y recordar las claves de los demás.
Organización de BNS
Los nombres BNS se organizan 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 de 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 exactamente a un espacio de nombres. Cualquiera puede crear un espacio de nombres, pero para que el espacio de nombres se conserve, 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 de blockchain. Entre los nombres de ejemplo se 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 difundir el estado de su subdominio. Entre los subdominios de ejemplo se incluyen
jude.personal.idypodsaveamerica.verified.podcast. A diferencia de los espacios de nombres y nombres BNS, el estado de los subdominios BNS es no parte de las reglas de consenso de la cadena de bloques.
Una matriz comparativa 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 humanos
X
X
X
Poseído por una clave privada
X
X
Cualquiera puede crear
X
X
[1]
El propietario puede actualizar
X
[1]
Estado alojado en la cadena
X
X
Estado alojado fuera de la cadena
X
X
Comportamiento controlado por reglas de consenso
X
X
Puede tener una fecha de expiración
X
[1] Requiere la cooperación de un propietario de nombre BNS para difundir sus transacciones
Espacios de nombres
Los espacios de nombres son los objetos de nombre de nivel superior en BNS. Controlan algunas propiedades de los nombres dentro de ellos:
Qué tan costoso es registrarlos
Cuánto duran antes de tener que renovarse
Quién (si alguien) recibe las tarifas de registro del nombre
Quién está autorizado a sembrar el espacio de nombres con sus nombres iniciales
Al momento de escribir esto, el espacio de nombres BNS con diferencia más grande es el .id espacio de nombres. Los nombres en el .id espacio de nombres están destinados a resolver identidades de usuario. Los nombres cortos en .id son más caros que los nombres largos, y sus propietarios deben renovarlos 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 acaparadores de ID).
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, y están compuestos por los caracteres a-z, 0-9, -, y _.
Subdominios
Los nombres BNS están fuertemente poseídos porque el propietario de su clave privada puede generar transacciones válidas que actualizan su hash de archivo de zona y su propietario. Sin embargo, esto tiene el costo de requerir que el propietario de un nombre pague por la transacción subyacente en la cadena de bloques. Además, este enfoque limita la velocidad de las registraciones 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 y historial de operaciones están anclados a la cadena de bloques. Al igual que sus equivalentes en cadena, los subdominios son globalmente únicos, están fuertemente poseídos y son 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 económica, porque se difunden a la red BNS en lotes. Una sola transacción de blockchain puede enviar hasta 120 operaciones de subdominio.
Esto se logra almacenando los registros de subdominio en los archivos de zona de los nombres BNS. Un propietario de un nombre en cadena difunde operaciones de subdominio codificándolas como TXT registros dentro de un archivo de zona DNS. Para difundir el archivo de zona, el propietario del nombre establece el nuevo hash del archivo de zona con una transacción NAME_UPDATE 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 las operaciones de subdominio válidas de NAME_UPDATE transacciones se almacenarán alguna vez.
Por ejemplo, el nombre verified.podcast una vez escribió 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 resuelve a:
Esta información se extrajo 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 de un propietario de nombre en cadena. El propietario del nombre en cadena difunde el archivo de zona emitiendo una transacción NAME_UPDATE que ancla la creación del subdominio en la cadena.
Actualización
Las actualizaciones de subdominio se realizan fuera de la cadena creando operaciones firmadas a partir de la clave privada del propietario del subdominio. Cualquier propietario de un nombre en cadena puede incluir estas operaciones firmadas en su archivo de zona y difundirlas mediante NAME_UPDATE. Las operaciones se ordenan por un número de secuencia y requieren una firma válida que enlaza 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 (normalmente el que creó el subdominio) que la difunda mediante NAME_UPDATE. El archivo de zona del propietario del nombre en cadena que difunde debe estar presente en la red Atlas para probar la ausencia de operaciones en conflicto.
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 hashea a la dirección de la transacción anterior del subdominio
Una firma de la clave privada correspondiente sobre toda la operación del subdominio
Si dos operaciones correctamente firmadas pero en conflicto tienen el mismo número de secuencia, se acepta la que aparece antes 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 difundir creaciones para*.res_publica.id).Una transacción de transferencia de subdominio solo puede ser difundida 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 de un nombre en cadena deben estar presentes en la red Atlas. Esto permite probar la ausencia de operaciones en conflicto.
Una actualización de subdominio puede ser difundida por cualquier propietario de un nombre en cadena, pero el propietario del subdominio necesita encontrar un propietario de nombre en cadena cooperador para incluirla y difundirla.
Para crear un subdominio, el propietario del subdominio genera la operación de creación y se la da al propietario del nombre en cadena. Una vez creado, el propietario del subdominio puede usar cualquier propietario de nombre en cadena para difundir actualizaciones proporcionando operaciones firmadas empaquetadas en archivos de zona.
Registradores de subdominios
Debido a que los nombres de subdominio 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 siguen siendo dueños de sus nombres de subdominio; el registrador ayuda a los desarrolladores a difundir 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:
Donde:
{address}es un hash de clave pública en cadena (por ejemplo, una dirección de Bitcoin).{index}se refiere aln-ésimonombre que creó esta dirección.
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 de este)
Propósito: un DID proporciona un identificador eterno para una clave pública. La clave pública puede cambiar, pero el DID no.
Para que un DID pueda resolverse, deben ser verdaderas todas las siguientes condiciones 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 de Stacks
El archivo de zona DNS debe contener un
URIregistro de recursos que apunte a un JSON Web Token firmadoLa clave pública que firmó el JSON Web Token (y que se incluye con él) debe hashear a la dirección que posee el nombre
No todos los nombres tendrán DIDs que resuelvan a claves públicas. Los nombres creados con herramientas estándar sí las tendrán.
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 lo mismo que la dirección de Bitcoin que posee el nombre. Actualmente, se admiten direcciones con byte de versión 0 y byte de versión 5 (direcciones que comienzan con1o3, es decirp2pkhyp2shdirecciones).Para los subdominios BNS fuera de la 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 comienzan conSoM, respectivamente.
El {index} 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 vs 0).
Última actualización
¿Te fue útil?