# Cómo funciona BNSv2

## Descripción general de la arquitectura

BNSv2 está implementado entre dos contratos de Clarity: `.BNS-V2` y `.zonefile-resolver` . Estos dos contratos de Clarity gestionan colectivamente:

1. Registro y gestión de namespaces
2. Registro de nombres (preorder/reveal y fast-claim)
3. Almacenamiento de registros (a través de zonefile-resolver)
4. Transferencias de propiedad
5. Renovaciones
6. Mercado (listar, retirar de la lista, comprar)
7. Designación del nombre principal

Todo el estado vive en la cadena y puede verificarse públicamente.

<table><thead><tr><th width="162.8984375"></th><th>Mainnet</th><th>Testnet</th></tr></thead><tbody><tr><td>BNSv2</td><td><code>SP2QEZ06AGJ3RKJPBV14SY1V5BBFNAW33D96YPGZF.BNS-V2</code></td><td><code>ST2QEZ06AGJ3RKJPBV14SY1V5BBFNAW33D9SZJQ0M.BNS-V2</code></td></tr><tr><td>Resolutor de zonefile</td><td><code>SP2QEZ06AGJ3RKJPBV14SY1V5BBFNAW33D96YPGZF.zonefile-resolver</code></td><td><code>ST2QEZ06AGJ3RKJPBV14SY1V5BBFNAW33D9SZJQ0M.zonefile-resolver</code></td></tr></tbody></table>

#### 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 namespace
2. El resolutor comprueba que el nombre sea válido, no esté revocado y esté dentro de su período de renovación (llamada entre contratos a BNS-V2)
3. Devuelve los datos del zonefile (propietario, búfer del zonefile, estado 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 se requieren servidores DNS centralizados ni dependencias fuera de la cadena para la corrección.

{% hint style="info" %}
BNSv2 dejó de usar los subdominios fuera de la cadena al estilo V1 (red Atlas / registros TXT) y la compatibilidad con DID. Ahora los subdominios se definen dentro del zonefile de un nombre, almacenado en la cadena. Para la documentación heredada de BNSv1, navegue [aquí](https://docs.stacks.co/learn/network-fundamentals/bitcoin-name-system).
{% endhint %}

***

## 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 integrado en el software del nodo de Stacks para la replicación y distribución de zonefiles. En BNSv1, las apps y APIs de BNS solo reconocían los zonefiles que formaban parte de la red Atlas.

El `zonefile-resolver` el contrato almacena un `(opcional (buff 8192))`. El contrato en sí 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 conjunto, esta arquitectura ofrece una solución flexible y escalable, combinando la seguridad y la inmediatez del almacenamiento en la cadena con la extensibilidad y eficiencia del almacenamiento descentralizado fuera de la cadena.

Estos cambios pueden resumirse de dos maneras:

1. Los zonefiles, o enlaces a zonefiles, ahora viven en la cadena
2. Los zonefiles ahora están desacoplados del contrato BNS-V2. Los zonefiles ahora viven en la cadena 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 los zonefiles. El contrato permite almacenar zonefiles de hasta 8.192 bytes (8 KB) directamente en la cadena, asociando el zonefile de forma determinista con su nombre y namespace correspondientes. Esto garantiza que los zonefiles más pequeños estén disponibles de inmediato, sean resistentes a manipulaciones y estén protegidos por las garantías subyacentes de la blockchain.

{% code title="Mapa de datos para la información del zonefile de un nombre" %}

```clarity
;; mapa de zonefile: almacena la información del zonefile para cada nombre en un namespace
;; 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
    }
)
```

{% endcode %}

Los zonefiles se almacenan técnicamente como JSON UTF-8 codificado en hexadecimal. La longitud máxima, si se define en el contrato, es de 8.192 bytes (8 KB). El siguiente esquema JSON es el formato estándar utilizado por las aplicaciones BNSv2 y la API oficial. El contrato en sí almacena bytes sin procesar y no impone esta estructura.

{% code title="Estructura del zonefile" expandable="true" %}

```json
{
	"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 (por ejemplo, .png, .jpg, .svg)
	"name": "Nombre del 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": "ejemplo",
			"value": "datos personalizados"
		}
		// ...
	],
	"subdomains": [
		{
			"test": {
				"owner": "SP....",
				"bio": "Biografía del subdominio..",
				"website": "www.url.com",
				"pfp": "www.mypfp.com/image.png",
				"name": "Nombre del usuario",
				"location": "Ciudad, país",
				"social": [
					{
						"platform": "x",
						"username": "@nombredeusuario"
					}
				],
				"addresses": [
					{
						"network": "Bitcoin",
						"address": "bc1...",
						"type": "payment"
					}
				]
			}
		}
		// ...
	],
	"externalSubdomainsFile": "www.url.com/subdomains.json" // opcional: archivo externo que contiene definiciones de subdominios
}
```

{% endcode %}

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

Consulta el [SDK de BNSv2](https://github.com/Strata-Labs/bns-v2-sdk) para más información sobre los zonefiles.


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://docs.stacks.co/learn/es/network-fundamentals/bitcoin-name-system/architecture.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.
