Sistema de nombres de Bitcoin

El Sistema de Nombres de Bitcoin (BNS) es un sistema de red que vincula nombres de usuario de Stacks con estado fuera de la cadena sin depender de ningún punto de control central.

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 humano. Cada nombre es elegido por su creador.

• Los nombres tienen propiedad fuerte. Solo el propietario del nombre puede cambiar el estado al que este resuelve. Específicamente, un nombre es propiedad de una o más claves privadas ECDSA.

La cadena de bloques Stacks asegura que la vista BNS de cada nodo esté sincronizada con todas las demás en el mundo, por lo que las consultas en un nodo serán iguales en otros nodos. Los nodos de la cadena de bloques Stacks permiten que el propietario de un nombre enlaza hasta 40 Kb de estado fuera de la cadena a su nombre, que será replicado a todos los demás nodos de la cadena de bloques 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 caro. Esto se debe a que registrar y modificar nombres requiere que una o más transacciones se envíen a la cadena de bloques subyacente, y los nodos BNS no las procesarán hasta que estén suficientemente confirmadas. Los usuarios y desarrolladores necesitan adquirir y gastar la criptomoneda requerida (STX) para enviar transacciones BNS.

Motivación detrás de los sistemas de nombres

Confiamos en 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, estás usando 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, estás usando tu cliente Git para resolver el nombre de la rama a un hash de confirmación. 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 verdaderas sobre los nombres? En BNS, los nombres son globalmente únicos, los nombres tienen significado humano y los nombres tienen propiedad fuerte. 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 redes sociales, los nombres son globalmente únicos y legibles por humanos, pero no tienen propiedad fuerte. El operador del sistema tiene la decisión final sobre a qué resuelve cada nombre.

  • Problema: Los clientes deben confiar en que el sistema tomará la decisión correcta sobre a qué resuelve un nombre dado. Esto incluye confiar en que nadie excepto los administradores del sistema pueda hacer estos cambios.

• En Git, los nombres de las ramas tienen significado humano y propiedad fuerte, pero no son globalmente únicos. Dos nodos Git diferentes pueden resolver el mismo nombre de rama a estados de repositorio diferentes 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 claves. Son globalmente únicos y criptográficamente poseídos, 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 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 lo convierte en una herramienta poderosa para construir todo tipo de aplicaciones de 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 phishers.

• 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 la denominación:

• 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 exactamente a un espacio de nombres. Cualquiera puede crear un espacio de nombres, pero para que el espacio de nombres se persista, 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 mediante el envío de transacciones a la cadena de bloques. Ejemplos de nombres incluyen verified.podcast y muneeb.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 colectivamente anclados 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.id y podsaveamerica.verified.podcast. A diferencia de los espacios de nombres y nombres BNS, el estado de los subdominios BNS no 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 nombres:

Característica	Espacios de nombres	Nombres BNS	Subdominios BNS
Globalmente único	X	X	X
Con significado humano	X	X	X
Propiedad 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 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:

• Qué tan costoso es registrarlos

• Cuánto tiempo duran antes de tener que ser renovados

• Quién (si alguien) recibe las tarifas de registro de nombres

• Quién está autorizado a sembrar el espacio de nombres con sus nombres iniciales

Al momento de redactar esto, con mucho el mayor espacio de nombres BNS 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—se envían en su lugar a un "agujero negro" donde quedan no gastables (la intención es desalentar a los ocupantes 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 de longitud, y se componen de los caracteres a-z, 0-9, -, y _.

Subdominios

Los nombres BNS tienen propiedad fuerte porque el propietario de su clave privada puede generar transacciones válidas que actualizan su hash de archivo de zona y propietario. Sin embargo, esto tiene el costo de requerir que el propietario del 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. Al igual que sus contrapartes en cadena, los subdominios son globalmente únicos, tienen propiedad fuerte 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 transmiten a la red BNS en lotes. Una sola transacción en la 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 las operaciones de subdominio válidas de transacciones válidas serán almacenadas. NAME_UPDATE Por ejemplo, el nombre

una vez escribió el hash del archivo de zona verified.podcast 247121450ca0e9af45e85a82e61cd525cd7ba023 , que es el hash del siguiente archivo de zona:$TTL 3600

1yeardaily TXT "owner=1MwPD6dH4fE3gQ9mCov81L1DEQWT7E85qH" "seqn=0" "parts=1" "zf0=JE9SSUdJTiAxeWVhcmRhaWx5CiRUVEwgMzYwMApfaHR0cC5fdGNwIFVSSSAxMCAxICJodHRwczovL3BoLmRvdHBvZGNhc3QuY28vMXllYXJkYWlseS9oZWFkLmpzb24iCg=="
2dopequeens TXT "owner=1MwPD6dH4fE3gQ9mCov81L1DEQWT7E85qH" "seqn=0" "parts=1" "zf0=JE9SSUdJTiAyZG9wZXF1ZWVucwokVFRMIDM2MDAKX2h0dHAuX3RjcCBVUkkgMTAgMSAiaHR0cHM6Ly9waC5kb3Rwb2RjYXN0LmNvLzJkb3BlcXVlZW5zL2hlYWQuanNvbiIK"
10happier TXT "owner=1MwPD6dH4fE3gQ9mCov81L1DEQWT7E85qH" "seqn=0" "parts=1" "zf0=JE9SSUdJTiAxMGhhcHBpZXIKJFRUTCAzNjAwCl9odHRwLl90Y3AgVVJJIDEwIDEgImh0dHBzOi8vcGguZG90cG9kY2FzdC5jby8xMGhhcHBpZXIvaGVhZC5qc29uIgo="
31thoughts TXT "owner=1MwPD6dH4fE3gQ9mCov81L1DEQWT7E85qH" "seqn=0" "parts=1" "zf0=JE9SSUdJTiAzMXRob3VnaHRzCiRUVEwgMzYwMApfaHR0cC5fdGNwIFVSSSAxMCAxICJodHRwczovL3BoLmRvdHBvZGNhc3QuY28vMzF0aG91Z2h0cy9oZWFkLmpzb24iCg=="
359 TXT "owner=1MwPD6dH4fE3gQ9mCov81L1DEQWT7E85qH" "seqn=0" "parts=1" "zf0=JE9SSUdJTiAzNTkKJFRUTCAzNjAwCl9odHRwLl90Y3AgVVJJIDEwIDEgImh0dHBzOi8vcGguZG90cG9kY2FzdC5jby8zNTkvaGVhZC5qc29uIgo="
30for30 TXT "owner=1MwPD6dH4fE3gQ9mCov81L1DEQWT7E85qH" "seqn=0" "parts=1" "zf0=JE9SSUdJTiAzMGZvcjMwCiRUVEwgMzYwMApfaHR0cC5fdGNwIFVSSSAxMCAxICJodHRwczovL3BoLmRvdHBvZGNhc3QuY28vMzBmb3IzMC9oZWFkLmpzb24iCg=="
onea TXT "owner=1MwPD6dH4fE3gQ9mCov81L1DEQWT7E85qH" "seqn=0" "parts=1" "zf0=JE9SSUdJTiBvbmVhCiRUVEwgMzYwMApfaHR0cC5fdGNwIFVSSSAxMCAxICJodHRwczovL3BoLmRvdHBvZGNhc3QuY28vb25lYS9oZWFkLmpzb24iCg=="
10minuteteacher TXT "owner=1MwPD6dH4fE3gQ9mCov81L1DEQWT7E85qH" "seqn=0" "parts=1" "zf0=JE9SSUdJTiAxMG1pbnV0ZXRlYWNoZXIKJFRUTCAzNjAwCl9odHRwLl90Y3AgVVJJIDEwIDEgImh0dHBzOi8vcGguZG90cG9kY2FzdC5jby8xMG1pbnV0ZXRlYWNoZXIvaGVhZC5qc29uIgo="
36questionsthepodcastmusical TXT "owner=1MwPD6dH4fE3gQ9mCov81L1DEQWT7E85qH" "seqn=0" "parts=1" "zf0=JE9SSUdJTiAzNnF1ZXN0aW9uc3RoZXBvZGNhc3RtdXNpY2FsCiRUVEwgMzYwMApfaHR0cC5fdGNwIFVSSSAxMCAxICJodHRwczovL3BoLmRvdHBvZGNhc3QuY28vMzZxdWVzdGlvbnN0aGVwb2RjYXN0bXVzaWNhbC9oZWFkLmpzb24iCg=="
_http._tcp URI 10 1 "https://dotpodcast.co/"
Cada

registro en este archivo de zona codifica una creación de subdominio. Por ejemplo, TXT 1yeardaily.verified.podcast resuelve a: "address": "1MwPD6dH4fE3gQ9mCov81L1DEQWT7E85qH",

{
  "blockchain": "bitcoin",
  "last_txid": "d87a22ebab3455b7399bfef8a41791935f94bc97aee55967edd5a87f22cce339",
  "status": "registered_subdomain",
  "zonefile_hash": "e7acc97fd42c48ed94fd4d41f674eddbee5557e3",
  "zonefile_txt": "$ORIGIN 1yeardaily\n$TTL 3600\n_http._tcp URI 10 1 \"https://ph.dotpodcast.co/1yeardaily/head.json\"\n"
  Esta información fue extraída del
}

1yeardaily registro de recursos en el archivo de zona para TXT Ciclo de vida del subdominio verified.podcast.

Creación

1

Una operación de creación de subdominio es creada por el propietario del subdominio y codificada en un

registro en el archivo de zona del propietario del nombre en cadena. El propietario del nombre en cadena transmite el archivo de zona al emitir una TXT transacción, que ancla la creación del subdominio en la cadena. NAME_UPDATE Actualización

2

Las actualizaciones de subdominios se realizan fuera de la cadena creando operaciones firmadas con 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 transmitirlas vía

. Las operaciones se ordenan por un número de secuencia y requieren una firma válida que enlace con la clave pública de la operación anterior. NAME_UPDATETransferencia

3

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

. El archivo de zona del propietario del nombre en cadena que transmite debe estar presente en la red Atlas para probar la ausencia de operaciones en conflicto. NAME_UPDATEReglas 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 de subdominio previa

  • Una firma de la clave privada correspondiente sobre la operación completa de subdominio

  • Si dos operaciones correctamente firmadas pero en conflicto 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.id puede 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 probar la ausencia de operaciones en conflicto.

• 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 cooperativo 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 subdominio son baratos, los desarrolladores pueden ejecutar registradores de subdominios para sus aplicaciones. Por ejemplo, el nombre

personal.id se utiliza 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 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 de protocolo emergente 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:

did:stack:v0:{address}-{index}

Donde:

{address}

• es un hash de clave pública en cadena (por ejemplo, una dirección de Bitcoin). {index}

• se refiere al ésimo nombre que creó esta dirección. Ejemplos:

→

• se utiliza para registrar nombres de usuario sin requerir que los usuarios gasten Bitcoin. did:stack:v0:1dARRtzHPAFRNE7Yup2Md9w18XEQAtLiV-0 (primer nombre creado por esa dirección) jude.id

• did:stack:v0:16EMaNw3pkn3v6f2BgnSSs53zAKH4Q8YJg-1 did:stack:v0:1dARRtzHPAFRNE7Yup2Md9w18XEQAtLiV-0 (la dirección había creado un nombre 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 resoluble, 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

• URI registro de recurso que apunte a un JSON Web Token firmado La clave pública que firmó el JSON Web Token (y está incluida con él) debe hacer hash a la dirección que posee el nombre

• No todos los nombres tendrán DIDs que 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

• es el 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 con es un hash de clave pública en cadena (por ejemplo, una dirección de Bitcoin). o 1 , lo que significa 3p2pkh p2sh y direcciones). Para los subdominios BNS fuera de la cadena, el

• 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 con es un hash de clave pública en cadena (por ejemplo, una dirección de Bitcoin). S M , lo que significa , respectivamente.El

campo para el DID de un subdominio es distinto del se refiere al campo para el DID de un nombre BNS, incluso si la misma dirección creó ambos nombres y subdominios. Ejemplo: se refiere al El nombre

• abcdefgh123456.id did:stack:v0:16EMaNw3pkn3v6f2BgnSSs53zAKH4Q8YJg-0 did:stack:v0:1dARRtzHPAFRNE7Yup2Md9w18XEQAtLiV-0 El subdominio jude.id

• jude.statism.id creado 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).—la diferencia es el byte de versión base58check (63 frente a 0).