Cómo funciona BNSv2

Descripción de la arquitectura

BNSv2 se implementa entre dos contratos Clarity: .BNS-V2 y .zonefile-resolver . Estos dos contratos Clarity colectivamente gestionan:

1. Registro y gestión de espacios de nombres

2. Registro de nombres (preorden/revelación y reclamación rápida)

3. Almacenamiento de registros (vía zonefile-resolver)

4. Transferencias de propiedad

5. Renovaciones

6. Mercado (listar, deslistar, comprar)

7. Designación de nombre primario

Todo el estado vive on-chain y es públicamente verificable.

	Mainnet	Testnet
BNSv2	SP2QEZ06AGJ3RKJPBV14SY1V5BBFNAW33D96YPGZF.BNS-V2	ST2QEZ06AGJ3RKJPBV14SY1V5BBFNAW33D9SZJQ0M.BNS-V2
Zonefile Resolver	SP2QEZ06AGJ3RKJPBV14SY1V5BBFNAW33D96YPGZF.zonefile-resolver	ST2QEZ06AGJ3RKJPBV14SY1V5BBFNAW33D9SZJQ0M.zonefile-resolver

Resolución de nombres

La resolución funciona de la siguiente manera:

1. Un usuario consulta el contrato zonefile-resolver con un nombre y un espacio de nombres

2. El resolvedor comprueba que el nombre es válido, no ha sido revocado y está dentro de su período de renovación (llamada entre contratos a BNS-V2)

3. Devuelve los datos del zonefile (propietario, buffer del zonefile, estado de revocado)

4. Las aplicaciones analizan el JSON del zonefile para extraer direcciones, perfiles, etc.

Para la propiedad/propiedades del nombre (sin datos de zonefile), se consulta directamente el contrato BNS-V2. No hay servidores DNS centralizados ni dependencias off-chain requeridas para la corrección.

BNSv2 descontinuó los subdominios fuera de la cadena al estilo V1 (red Atlas / registros TXT) y la compatibilidad con DID. Los subdominios ahora se definen dentro del zonefile de un nombre, almacenado on-chain. Para documentación heredada sobre BNSv1, navegue aquí.

---

Zonefiles

Los zonefiles también lucen significativamente diferentes en esta actualización.

Anteriormente, los zonefiles de BNS se construían sobre la red “atlas”. Atlas es un protocolo incorporado al software del nodo Stacks para la replicación y distribución de zonefiles. En BNSv1, las apps y APIs de BNS solo reconocían zonefiles que eran parte de la red Atlas.

El zonefile-resolver contrato almacena un (optional (buff 8192)). El propio contrato no tiene lógica específica de IPFS. Almacena bytes sin procesar — que a nivel de aplicación podrían ser un zonefile JSON completo o un CID/URL que apunte a almacenamiento externo.

En general, esta arquitectura ofrece una solución flexible y escalable, combinando la seguridad e inmediatez del almacenamiento on-chain con la extensibilidad y eficiencia del almacenamiento descentralizado off-chain.

Estos cambios se pueden resumir de dos maneras:

1. Los zonefiles, o enlaces a zonefiles, ahora viven on-chain

2. Los zonefiles ahora están desacoplados del contrato BNS-V2. Los zonefiles ahora viven on-chain y en su propio contrato: .zonefile-resolver. Este contrato es bastante limitado con un solo mapa y solo tres funciones: resolve-name, update-zonefile & revoke-name.

Bajo este diseño, un contrato inteligente dedicado es responsable de gestionar toda la funcionalidad relacionada con zonefiles. El contrato soporta almacenar zonefiles de hasta 8,192 bytes (8 KB) directamente on-chain, asociando el zonefile de manera determinista con su nombre y espacio de nombres correspondiente. Esto asegura que los zonefiles más pequeños estén inmediatamente disponibles, sean resistentes a la manipulación y estén protegidos por las garantías subyacentes de la blockchain.

Mapa de datos para la información del zonefile de un nombre

;; mapa de zonefile: Almacena información de zonefile para cada nombre en un espacio de nombres
;; Clave: {name: (buff 48), namespace: (buff 20)}
;; Valor: {owner: principal, zonefile: (optional (buff 8192)), revoked: bool}
(define-map zonefile {name: (buff 48), namespace: (buff 20)} 
    {
        owner: principal,
        zonefile: (optional (buff 8192)),
        revoked: bool
    }
)

Los zonefiles se almacenan técnicamente como JSON UTF-8 codificado en hex. La longitud máxima está definida en el contrato en 8,192 bytes (8 KB). El siguiente esquema JSON es el formato estándar usado por las aplicaciones BNSv2 y la API oficial. El propio contrato almacena bytes sin procesar y no hace cumplir esta estructura.

Estructura del zonefile

{
	"owner": "SP...",
	"btc": "bc1...",
	"bio": "Biografía del usuario...",
	"website": "www.url.com",
	"pfp": "www.mypfp.com/image.png", // debe ser un formato de imagen válido (p. ej. .png, .jpg, .svg)
	"name": "Nombre de usuario",
	"location": "Ciudad, País",
	"social": [
		{
			"platform": "x", 
			"username": "nombredeusuario"
		},
		{
			"platform": "telegram", 
			"username": "nombredeusuario"
		}
		// ...
	],
	"addresses": [
		{
			"network": "btc",
			"address": "bc1...",
			"type": "payment"
		},
		{
			"network": "btc",
			"address": "bc1...",
			"type": "ordinal"
		},
		{
			"network": "eth",
			"address": "0x123...",
			"type": "wallet"
		}
		// ...
	],
	"meta": [
		{
			"name": "example",
			"value": "datos personalizados"
		}
		// ...
	],
	"subdomains": [
		{
			"test": {
				"owner": "SP....",
				"bio": "Biografía del subdominio..",
				"website": "www.url.com",
				"pfp": "www.mypfp.com/image.png",
				"name": "Nombre de usuario",
				"location": "Ciudad, País",
				"social": [
					{
						"platform": "x",
						"username": "@username"
					}
				],
				"addresses": [
					{
						"network": "Bitcoin",
						"address": "bc1...",
						"type": "payment"
					}
				]
			}
		}
		// ...
	],
	"externalSubdomainsFile": "www.url.com/subdomains.json" // opcional: archivo externo que contiene definiciones de subdominios
}

La capa de API abstrae la lógica de resolución, determinando automáticamente si recuperar los datos del zonefile directamente desde el contrato o vía IPFS usando el CID almacenado. Como resultado, los clientes pueden resolver la información del zonefile para cualquier nombre y espacio de nombres a través de una interfaz consistente sin necesitar gestionar manualmente las distinciones de almacenamiento.

Consulta el SDK de BNSv2 para más información sobre los zonefiles.