# Conceptos básicos ## **Espacios de nombres** Los espacios de nombres son los dominios de nivel superior en BNS (p. ej., .btc, .id). Tienen el siguiente ciclo de vida: * **Preorden:** Se envía un hash con sal del espacio de nombres junto con un pago de quema * **Revelación:** Se revela el espacio de nombres real, junto con la información de precios y todas las propiedades del espacio de nombres
¿Qué sucede durante la revelación? Durante la revelación, el creador establece: `vida útil` (cuánto tiempo duran los nombres antes de necesitar renovación, 0 significa sin renovación), `namespace-import` principal, y el completo `price-function` (16 cubos, base, coeficiente, descuento-sin-letras, descuento-sin-vocales). Estos son parámetros críticos que definen el comportamiento del espacio de nombres para siempre. Los precios del espacio de nombres pueden actualizarse (mediante `namespace-update-price`) y pueden congelarse permanentemente (mediante `namespace-freeze-price` ). Una vez congelada, la función de precios nunca puede cambiarse. Estas son decisiones importantes de gobernanza. Además, los nombres pueden importarse antes del lanzamiento mediante `name-import`. Esto permite a los creadores del espacio de nombres precargar nombres (p. ej., para migración o nombres reservados) antes de abrir el registro al público.
* **Lanzamiento:** El espacio de nombres se vuelve activo, permitiendo registros de nombres #### **Espacios de nombres no gestionados vs gestionados** BNS-V2 admite dos tipos de espacios de nombres: **No gestionados** y **Gestionados**. Los espacios de nombres no gestionados están abiertos para que cualquiera registre nombres dentro de ellos, sujetos a las reglas de precios del espacio de nombres. Estos espacios de nombres operan de forma totalmente descentralizada, con restricciones mínimas sobre el registro y la gestión de nombres. Los espacios de nombres gestionados, por otro lado, introducen una capa adicional de control y personalización. Estos espacios de nombres están supervisados por un gestor designado que tiene privilegios y responsabilidades especiales. Los espacios de nombres gestionados pueden implementar reglas personalizadas para el registro de nombres, precios, transferencias y renovaciones. Esto permite casos de uso como crear espacios de nombres para comunidades específicas, implementar procesos de verificación adicionales o hacer cumplir determinadas convenciones de nomenclatura. Las diferencias clave entre los espacios de nombres no gestionados y los gestionados radican en su gobernanza y flexibilidad. Mientras que los espacios de nombres no gestionados ofrecen un entorno más abierto y sin restricciones, los espacios de nombres gestionados ofrecen mayor control y la capacidad de adaptar el espacio de nombres a requisitos o casos de uso específicos. #### Crear un espacio de nombres gestionado Los espacios de nombres gestionados son una de las mayores actualizaciones de esta versión de BNSv2. Diseñado para permitir un control y una flexibilidad significativamente mayores sobre un espacio de nombres, un espacio de nombres "gestionado" está controlado por un único principal (casi siempre un *contrato* principal). Para un comportamiento esperado, debes tener mucho cuidado al configurar este principal de contrato: si no se configura correctamente, es posible perder el control del espacio de nombres de forma permanente. Hay algunas decisiones importantes que tomar al crear un espacio de nombres gestionado: * ¿El contrato del gestor *alguna vez* necesitará ser cambiado? * ¿Cómo funcionará tu proceso de acuñación? * ¿Pueden los gestores transferir *cualquier* nombre? * ¿Serán comerciables tus nombres? * ¿Tu espacio de nombres requiere metadatos? Estas son decisiones críticas que uno debe considerar para preparar un espacio de nombres gestionado para el futuro. Para la primera pregunta, es casi seguro que *tendrás* que actualizar o eliminar el contrato del gestor; por lo tanto, es imperativo que el contrato del gestor incluya acceso a la función 'mng-manager-transfer'. Si el contrato del gestor inicial no incluye esta función, será imposible actualizar o eliminar el espacio de nombres para un nuevo contrato del gestor. Los espacios de nombres gestionados no requieren quemas de STX para el registro de nombres. La `mng-name-register` función establece `stx-burned: u0` en el preorden. Los precios son gestionados por completo por el contrato del gestor (podría ser gratuito, con bloqueo por token, basado en STX mediante la propia lógica del gestor, etc.). Esta es una diferencia fundamental con respecto a los espacios de nombres no gestionados. A continuación, el proceso de acuñación es mucho más personalizable en un espacio de nombres gestionado. A alto nivel, los espacios de nombres gestionados tienen acceso a las mismas dos rutas para el registro de nombres: 2 pasos / mng-name-preorder + mng-name-register, o un solo paso / fast-claim. Los contratos gestionados **deben** tener acceso a una o ambas de estas funciones para acuñar nombres con éxito en un espacio de nombres; además, el proceso de acuñación puede personalizarse en gran medida para permitir: acuñaciones gratuitas, acuñaciones con bloqueo por token, precios variables, soporte para tokens sip-10, etc... Una vez acuñados, debes tener especial cuidado para implementar las tres funciones estándar del mercado sip-09: list, unlist y buy. Los espacios de nombres gestionados *no son* comerciables por defecto, *deben* incluyen llamadas envueltas a las funciones list, unlist y buy en BNSv2, ya que esas funciones verifican específicamente contra 'contract-caller' (es decir, el contrato gestionado). Por último, la capacidad de permitir que el propio contrato del espacio de nombres gestionado *en sí mismo* transfiera cualquier nombre es una decisión crítica. Es casi seguro que **no** quieres permitir esto, ya que permitiría que el contrato transfiriera cualquier nombre a cualquier principal; sin embargo, hay algunos casos de uso en los que se requiere un control mucho más granular. Los nombres de espacios de nombres gestionados no expiran. El `mng-name-register` función establece `renewal-height: u0`, lo que significa que no hay un requisito de renovación automática. El gestor controla todo el ciclo de vida. *** ## **Nombres** Los nombres son los identificadores individuales dentro de un espacio de nombres (p. ej., alice.btc). Tienen las siguientes propiedades: * Únicos dentro de su espacio de nombres * Representados como NFT * Pueden transferirse y renovarse * Asociados con un zonefile, que almacena información adicional relacionada con el nombre en un `zonefile-resolver` contrato Un nombre BNS tiene dos componentes: ``` . ``` Ejemplo: ``` alice.id ``` * `alice` → el nombre * `id` → el espacio de nombres Los espacios de nombres definen las reglas y los precios para los registros de nombres. *** ## Propiedad Los nombres son propiedad de un principal de Stacks. La propiedad permite al titular: * Actualizar registros * Establecer el nombre como nombre principal * Poner el nombre a la venta en el mercado integrado * Transferir el nombre * Renovar el nombre * Configurar datos de resolución La propiedad se aplica íntegramente mediante la lógica del contrato inteligente. *** ## Zonefiles Cada nombre puede almacenar registros estructurados. El JSON del zonefile admite: dirección del propietario, dirección BTC, biografía, sitio web, PFP, nombre, ubicación, enlaces sociales (X, Telegram, etc.), direcciones multicanal (pago BTC, ordinal BTC, ETH, etc.), metadatos arbitrarios de pares clave-valor y definiciones de subdominios. Estos registros pueden incluir: * Mapeos de direcciones * Metadatos de texto * Datos específicos de la aplicación * Información de perfil Debido a que BNSv2 está implementado en Clarity, otros contratos pueden leer los datos de nombre directamente en la cadena. --- # 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/core-concepts.md?ask= ``` 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.