protocolo RGB

¿Qué es RGB

RGB es un protocolo de contrato inteligente escalable y confidencial aplicable a Bitcoin y a la Lightning Network, desarrollado por la Asociación de Normas LNP/BP. Adopta los conceptos de propiedad privada y conjunta, ofreciendo una forma de computación distribuida completa de Turing, sin necesidad de una cadena de bloques, operando como un sistema de contrato inteligente de estado parcial validado por el cliente y sin confianza.

Historia del desarrollo del Protocolo RGB

Historia del protocolo RGB

RGB fue concebido inicialmente por Giacomo Zucco de la BHB Network en 2016 como un 'sistema de activos no basado en blockchain'. Ese mismo año, Peter Todd introdujo los conceptos de sellos de un solo uso y validación del lado del cliente. Inspirado por estas ideas, RGB fue propuesto en 2018. En 2019, el desarrollador principal Maxim Orlovsky asumió un papel principal en el desarrollo del código RGB y el diseño del estándar fundamental. Maxim Orlovsky y Giacomo Zucco fundaron la Asociación de Estándares LNP/BP.https://www.lnp-bp.org) para llevar RGB desde el concepto hasta la aplicación, con el apoyo de Fulgur Ventures, Bitfinex, Fundación Hojo, Pandora Prime y DIBA. Tras un extenso desarrollo, RGB lanzó su primera versión estable, V0.10, en abril de 2023. En enero de 2024, los desarrolladores principales de RGB anunciaron que la versión V0.11 sería lanzada a principios del primer semestre del año.

Últimos desarrollos en el Protocolo RGB

Las nuevas características de RGB V0.10 han sido analizadas a fondo en otros informes. Mientras que V0.11 aún no ha sido lanzado oficialmente, aquí hay algunos de los últimos desarrollos de los desarrolladores y la comunidad:

• Próximo soporte para L-BTC

• Actualizaciones sobre la interoperabilidad y puentes entre activos RGB y activos Liquid

Sin embargo, RGB V0.11 será incompatible con V0.10, lo que llevará a costos significativos de migración para los proyectos actuales. Además, debido al lento progreso en el desarrollo, muchos proyectos están esperando actualmente el lanzamiento de V0.11.

Filosofía de diseño RGB y principios de funcionamiento

Los contratos inteligentes RGB utilizan validación del lado del cliente, lo que significa que todos los datos se almacenan fuera de las transacciones de Bitcoin, es decir, en la cadena de bloques de Bitcoin o en el estado de los canales Lightning. Esto permite que el sistema opere en la parte superior de la Red Lightning sin cambios en la red principal de BTC o los protocolos de la Red Lightning, sentando las bases para la escalabilidad y privacidad del protocolo.

RGB utiliza sellos de un solo uso definidos en Bitcoin UTXOs, lo que permite a cualquier persona con un registro del historial del estado del contrato inteligente verificar su singularidad. En otras palabras, RGB aprovecha los scripts de Bitcoin para implementar su modelo de seguridad y definir la propiedad y los derechos de acceso.

RGB es un Grafo Acíclico Dirigido (DAG) de transiciones de estado, donde los contratos están completamente aislados entre sí, y nadie conoce su existencia excepto los propietarios de los contratos (o aquellos a quienes el propietario revela la información del contrato).

Un Grafo Acíclico Dirigido (DAG) es una estructura de grafo especial que puede explicar vívidamente sistemas o relaciones complejas. En un DAG, cada borde puede ser pensado como una calle de sentido único en una ciudad, que representa el aspecto "dirigido" del grafo. Suponga en esta red de calles, sin importar cómo viaje, es imposible regresar al punto de partida y formar un bucle cerrado; esto representa la naturaleza "acíclica" del grafo. En un DAG, no hay una secuencia de nodos que le permita comenzar desde un nodo, viajar a través de una serie de bordes y regresar al mismo nodo.

Aplicando este concepto al sistema RGB, cada contrato puede ser visto como un nodo en el gráfico, y las relaciones entre contratos (como la transferencia de propiedad) pueden ser vistas como bordes dirigidos. Esta estructura asegura que las relaciones entre contratos sean claras y ordenadas, sin formar bucles cerrados, lo que significa que un contrato no puede afectarse a sí mismo directa o indirectamente.

Este diseño asegura que los compromisos en la transmisión de estado sean únicos e inmutables, evitando el doble gasto y logrando transiciones de estado eficientes y consistentes.

Sumergiéndose en los contratos RGB

Después de entender los principios básicos del diseño arquitectónico de RGB, veamos la parte del contrato. En el mundo actual de los contratos inteligentes, se requiere que los creadores organicen o ejecuten el desarrollo del código del contrato inteligente por sí mismos. La filosofía de diseño de RGB considera esta práctica indeseable, lo que conduce a una mayor vulnerabilidad del código del contrato y múltiples ataques de hackers. Por lo tanto, RGB tiene como objetivo reducir el riesgo de vulnerabilidades en el desarrollo y la necesidad de auditorías al introducir el concepto de "Patrones de Esquema". Los "Patrones de Esquema" son el código real de los contratos inteligentes. Los editores pueden usarlos como "plantillas de contrato" sin necesidad de codificar o auditar el código personalizado escrito para ellos por algún contratista aleatorio.

Escalabilidad flexible y buena interoperabilidad

Los contratos RGB se definen de forma declarativa, no imperativa. Esto significa que la lógica del contrato no está definida por una serie de comandos o pasos, sino por un conjunto de reglas que describen su comportamiento y transiciones de estado, formando un Grafo Acíclico Dirigido (DAG) de cambios de estado. La clave de las operaciones de estado local radica en el Esquema. Las operaciones en los contratos RGB son locales, no globales. Cada nodo (o estado) tiene sus propias reglas y solo es responsable de sus transiciones de estado. Esto es diferente de los algoritmos globales en plataformas como Ethereum, que requieren que cada estado siga el mismo algoritmo. Esta característica hace que RGB sea suficientemente flexible y escalable, al mismo tiempo que proporciona una buena interoperabilidad.

Creación simplificada de contratos inteligentes

El esquema define qué tipos de estados globales y de propiedad, sellos y metadatos están permitidos en las transiciones de estado. RGB utiliza el lenguaje Contractum para escribir Esquemas RGB y AluVM (Máquina Virtual de la Unidad Aritmética Lógica), lo que simplifica la escritura de contratos inteligentes RGB. AluVM se basa en un diseño de registro sin acceso aleatorio a la memoria, lo que lo hace muy adecuado para contratos inteligentes, ejecución de código remoto, computación distribuida y en el borde, proporcionando una base para varios casos de uso avanzados de contratos inteligentes.

¿Cómo RGB garantiza seguridad y privacidad

Desde el diseño de RGB en sí:

• Privacidad sin difusión global: Como se mencionó, la validación del lado del cliente de RGB significa que el proceso de validación solo ocurre entre pares directamente involucrados, no en toda la red. Este enfoque de no difusión global mejora la privacidad y la resistencia a la censura porque los detalles del estado del contrato solo son visibles para los participantes relevantes, y los mineros no pueden ver los detalles de la transacción.

• Privacidad de datos en un entorno de sandbox: Por otro lado, RGB almacena todos los datos de operación en un alijo. Dado que RGB no se basa en blockchain, el almacenamiento no se replica en otros nodos pares. El almacenamiento controlado localmente por los usuarios reduce el riesgo de ataques externos y filtraciones de datos, garantizando la privacidad de los datos. RGB es una plataforma informática donde cada programa ("contrato inteligente") está aislado en su entorno de sandbox, ofreciendo una mejor escalabilidad y seguridad que las plataformas basadas en blockchain. Sin embargo, los datos fuera de la cadena también significan que existe un riesgo de pérdida.

• Además de la validación y el almacenamiento, el sistema de facturación también garantiza seguridad y privacidad. Las operaciones de contrato en RGB se llevan a cabo creando facturas, que pueden contener múltiples solicitudes de operaciones de contrato. Al permitir a los usuarios especificar y verificar explícitamente las operaciones de contrato, se mejora la precisión y la seguridad de las operaciones. Al mismo tiempo, el sistema de facturación admite la transmisión privada de solicitudes de operaciones de contrato entre usuarios, mejorando la privacidad de las transacciones. Las transiciones de estado, como las transferencias de tokens, se ejecutan a través de facturas y comandos específicos.

Desde la Perspectiva de Interactuar con BTC

El diseño de RGB está altamente ligado a UTXOs. En las interacciones con la red principal de BTC, los usuarios crean contratos fuera de la cadena para emitir activos RGB y asignarlos a los UTXOs de Bitcoin, similar a la Red Lightning. Luego, las transferencias de activos, las interacciones de contratos y las validaciones se realizan fuera de la cadena como se introdujo anteriormente.

RGB se beneficia de los protocolos de firma mejorados multisig, basados en adaptadores y de Contratos Bloqueados en el Tiempo Puntual (PTLCs) aportados por las firmas Schnorr, pero sus beneficios se basan puramente en los de Bitcoin (es decir, de forma indirecta). No hay nada en RGB que requiera firmas (por lo tanto, Schnorr no realiza cambios internos), ni utiliza scripts de Bitcoin (por lo tanto, el nuevo Tapscript no es útil).

El Laboratorio de Seguridad de BTC, cofundado por ScaleBit, es un laboratorio de seguridad de BTC dedicado que trabaja en los últimos desarrollos del protocolo RGB. Su objetivo es proteger la seguridad del contrato, promoviendo conjuntamente el crecimiento continuo y el fortalecimiento del protocolo RGB y la construcción de la infraestructura del ecosistema BTC.

Visión general de los Proyectos del Ecosistema RGB

BiHelix

• Sitio web: https://www.bihelix.net/

• BiHelix es una infraestructura del ecosistema de Bitcoin optimizada para nodos, construida en la cadena de bloques nativa de Bitcoin, que incorpora el protocolo RGB y la Red Lightning. Su objetivo es facilitar el desarrollo, ampliar los casos de uso de Bitcoin y abordar los desafíos de escalabilidad e incompletitud de Turing a los que se enfrenta la cadena de bloques de Bitcoin. BiHelix se esfuerza por crear un mundo criptográfico descentralizado más justo para mineros, validadores, proveedores de servicios de nodos, intercambios y usuarios. Como la primera infraestructura construida en el protocolo RGB, BiHelix desarrollará la próxima generación de escenarios de aplicaciones de Bitcoin a gran escala. El proyecto se encuentra actualmente en la etapa de desarrollo y aún no está abierto para la interacción; manténgase atento.

  Características del proyecto

• Umbral de usuario bajo: Utiliza el protocolo SLR (Security-Lightning-RGB), reempaquetando RGB y la Red Lightning con soluciones innovadoras para que los nodos de rayos logren pagos universales.

• Alta confiabilidad y escalabilidad: Emplea una arquitectura de servicio en la nube madura, aprovechando completamente las características de rust-lightning para admitir funciones de fábrica de canales, gestionar eficientemente los canales y crear canales en gran cantidad.

• Protección de seguridad y privacidad: transmisión y almacenamiento fuera de la cadena de datos de estado, utilizando pruebas recursivas de conocimiento cero, entre otras tecnologías, para aleatorizar pagos multipartitos y selección de ruta para protección de privacidad.

• Amigable para desarrolladores: Proporciona herramientas de desarrollo completas, incluida documentación de código abierto, herramientas, etc., e introduce el mecanismo de consenso social Schema, lo que facilita a los desarrolladores construir aplicaciones.

  Cartera Iris

• Sitio web: https://play.google.com/store/apps/details?id=com.iriswallet.testnet&pli=1

• IRIS Wallet, la primera billetera Android desarrollada por el equipo de Bitfinex, está dedicada a la integración RGB y herramientas relacionadas con RGB, soportando activos fungibles y no fungibles. Iris Wallet permite operaciones de activos RGB desde la emisión hasta el gasto y la recepción, empaquetando todas las funcionalidades en una aplicación de billetera familiar mientras abstrae tantos detalles técnicos como sea posible. Actualmente es una aplicación experimental recomendada para pequeñas cantidades de Bitcoin y activos de bajo valor.

  DIBA

• Sitio web: https://diba.io/

• DIBA es el primer mercado de NFT en Bitcoin que utiliza el Protocolo RGB y la Lightning Network. Su objetivo es dar forma a la comprensión de los activos artísticos sin custodia en la cadena de bloques de Bitcoin.

  Bitmask

• Sitio web: https://bitmask.app/

• Creado por DIBA, Bitmask es la primera billetera de NFT en el ecosistema RGB, operable en navegadores web e interactuando con contratos RGB similares a MetaMask en Ethereum. Actualmente se actualiza con frecuencia, a la espera del lanzamiento de V0.11.

  Pandora Prime Inc

• Sitio web: https://pandoraprime.ch/

• Ubicada en Verify Valley, Suiza, Pandora Prime también es miembro fundador de LNP/BP. Pandora Prime se dedica a ser pionera en Bitcoin Finance utilizando la combinación de contratos inteligentes RGB y Lightning Network. Comienzan con activos programables en Bitcoin (RGBTC y CHFN), que pueden escalar el rendimiento de las transacciones a niveles de VISA/MasterCard a través de Lightning Network, al tiempo que proporcionan facilidades para facilitar el intercambio de estos activos. Sus productos incluyen MyCitadel (billetera), RGB Explorer (navegador) y Pandora Network, entre otros.

  MyCitadel

• Sitio web: https://mycitadel.io/

• Una marca de Pandora Prime, MyCitadel es la primera billetera GUI que admite RGB, creada por desarrolladores de RGB en 2021. Ofrece billeteras de escritorio multiplataforma y billeteras iOS/iPad. La billetera móvil puede manejar activos RGB fungibles.

  Explorador RGB

• Sitio web: https://rgbex.io/

• Desarrollado por Pandora Prime, RGB Explorer es el primer navegador que ofrece registro de activos RGB y contratos inteligentes. Actualmente, admite RGB 20, RGB 21, RGB 25, mostrando activos como LNPBP, RGBTC, dCHF y RGBEX.

  Bitlight Labs (anteriormente Cosminmart)

• Sitio web: https://bitlightlabs.com/

• Bitlight Labs desarrolla infraestructura basada en el protocolo RGB, preparándose para implementar múltiples aplicaciones en la Red Lightning, incluyendo la Billetera Bitlight para utilidad RGB y Bitswap, un creador de mercado automatizado para BitcoinFi en la Red Lightning y el protocolo RGB.

RGB Memes & NFT

1. PPRGB

   • X: @PepeRgb20

   • PPRGB se emite actualmente en la red Liquid, a la espera de mapearse a RGB después del lanzamiento de RGB V0.11 (V0.11 también está desarrollando funciones de código para la interfaz con Liquid).

2. Inscripción MRGB

   • La inscripción MRGB es un token basado en el cliente del protocolo RGB para validación de estado y sistema de contratos inteligentes. Opera en las capas dos y tres (fuera de la cadena) del ecosistema de Bitcoin y proporcionará código de protocolo subyacente de código abierto, lo que permitirá a todas las cadenas públicas BRC20 usar directamente este sistema. Esta innovación aporta un potencial significativo a las cadenas públicas BRC20, incluyendo la reducción del consumo de GAS, la aceleración de la velocidad de transacción y la mejora del rendimiento general. Al adoptar el sistema MRGB, las cadenas públicas BRC20 podrán procesar transacciones de manera más eficiente y reducir los costos de transacción para los usuarios. Mientras tanto, el token de inscripción MRGB también servirá como un consumible en el proceso de transacción, aumentando así la liquidez y la escalabilidad de BTC.

3. Sello de un solo uso

   • X: @Single_Use_Seal

   • Seal, es una colección de 10k PFP, raras UDA y tokens en RGB20 y RGB21, nombrada en honor al concepto de Sello de Uso Único de Peter Todd. Actualmente esperando que las carteras Bitlight y Bitmask se actualicen a la versión v0.11 de RGB, después de lo cual se emitirán en ellas.

4. Bitman

   • X: @bitmancity

   • Emitirá 10k UDA en diba, posiblemente a través de una venta wl+public, con la misión de "transmitir el espíritu de BTC". El proyecto tiene un propósito loable y dará wl a los contribuyentes del ecosistema BTC, con la mayoría de los ingresos de la venta pública donados a LNP/BP.

BitVM

¿Por qué BitVM?

BitVM (Bitcoin Virtual Machine) introduce un sistema que permite verificar cualquier cálculo en la cadena de bloques de Bitcoin sin comprometer su seguridad o alterar la red. Este desarrollo abre la puerta a cálculos complejos, como contratos inteligentes completos de Turing, con todos los cálculos procesados fuera de la cadena para reducir la congestión en la cadena de bloques de Bitcoin.

"En pocas palabras, BitVM es un modelo computacional capaz de expresar contratos completos de Turing en la red de Bitcoin." Al igual que RGB, BitVM no requiere modificaciones a las reglas de consenso de la red.

El 9 de octubre de 2023, Robin Linus, cofundador del desarrollador de blockchain ZeroSync, publicó el libro blanco de BitVM. En comparación con RGB, BitVM es mucho más joven.

Arquitectura de diseño de BitVM

Arquitectura

Similar a Optimistic Rollups y la propuesta Merkelize All The Things (MATT), basado en pruebas de fraude y protocolos de desafío-respuesta, no requiere cambios en las reglas de consenso de Bitcoin. BitVM demuestra que Bitcoin es Turing-completo al codificar pruebas de fraude dentro de grandes Taptrees.

Diseño de Circuitos Gate

El Compromiso de Valor de Bit es el componente más básico, que permite al comprometido establecer el valor específico de un bit en “0” o “1”. Cualquier función computable puede ser representada como un circuito booleano, formando compromisos de puertas lógicas. Construidos a través de puertas NAND (puertas lógicas universales), cada puerta tiene su propio compromiso. Cualquier circuito puede ser expresado combinando compromisos de puertas. Cada paso de ejecución se compromete en un Tapleaf y se combina dentro de la misma dirección Taproot.

BitVM utiliza la actualización Taproot de Bitcoin al crear una estructura similar a un circuito binario (llamado un taptree) para lograr su funcionalidad. Dentro de este sistema, las condiciones de gasto para cada UTXO, representadas por instrucciones en un Script, forman la unidad básica del programa. Estas instrucciones generan salidas binarias (0 o 1) dentro de una dirección Taproot, construyendo así todo el taptree. La salida del taptree se puede considerar el resultado de la ejecución de un circuito binario, similar a un programa ejecutable. La complejidad de los programas que un taptree puede ejecutar depende del número y la complejidad de las direcciones Taproot que lo componen. En resumen, BitVM realiza la capacidad de ejecutar programas más complejos en la red de Bitcoin al traducir las instrucciones de Script de Bitcoin en operaciones binarias.

Los roles participantes son dos partes

Actualmente, el modelo está limitado a dos partes y no se puede expandir para incluir a más participantes. Además, para que BitVM funcione correctamente, se requiere un gran número de prefirmas (cálculos fuera de la cadena), lo que hace que BitVM sea bastante complejo y potencialmente ineficiente.

Pruebas de fraude y protocolo de desafío-respuesta

Tanto el probador como el retador depositan una cantidad igual de BTC en una transacción como apuesta (como entrada), y la salida de esta transacción incluirá un circuito lógico. Una serie de transacciones están pre-firmadas durante la fase de configuración para refutar afirmaciones incorrectas. BitVM se asemeja a Optimistic Rollups porque realiza la mayor parte de la computación fuera de la cadena y presenta algunas de estas computaciones en la cadena para resolver disputas cuando surgen.

Los Optimistic Rollups son una solución de escalado de segunda capa que reduce la carga en la capa base al mover la computación y el almacenamiento de datos fuera de la cadena. Luego agrupa múltiples transacciones y las publica en la cadena principal. Los Optimistic Rollups asumen que todas las transacciones son válidas. Sin embargo, si los participantes de la red notan un comportamiento deshonesto, pueden iniciar una prueba de fraude. Una prueba de fraude es evidencia de un cálculo inexacto de alguien. Se producen después de una inspección.

Computación fuera de la cadena

Casi todas las actividades en BitVM se realizan fuera de la cadena. Esto incluye iniciar tareas de computación, compartir datos y verificar reclamos enviados. BitVM generalmente no realiza cálculos en la cadena de bloques de Bitcoin. Los cálculos y verificaciones solo se publican en la cadena cuando hay una disputa debido a sospecha de fraude. Sin embargo, si hay una disputa, una pequeña parte del proceso de disputa se ejecuta efectivamente en la cadena, solo lo suficiente para determinar qué parte es deshonesta.

Con los conocimientos anteriores, podemos entender mejor los principios específicos de la interacción de dos partes de BitVM.

El modelo de interacción de dos partes de BitVM implica un probador y un verificador. En este sistema, el probador primero crea y envía un contrato inteligente o programa, luego envía fondos a una dirección raíz maestra controlada conjuntamente. Estos fondos se mantienen en un arreglo de multisig de 2 de 2. El probador también necesita compartir suficiente información con el verificador para demostrar que su programa puede producir la salida prometida.

La tarea del verificador es ejecutar el código del probador y verificar si la salida coincide con las expectativas. Si la salida no coincide, el verificador desafiará al probador. Este proceso de interacción de desafío-respuesta implica el intercambio de datos fuera de la cadena y el uso de transacciones pre-firmadas para verificar la corrección de la computación.

Si se descubre un error computacional, el verificador puede demostrar públicamente el comportamiento deshonesto del probador a través de una prueba de fraude en cadena. En el sistema BitVM, si se demuestra que la respuesta del probador es incorrecta, perderá la apuesta y los fondos. Por el contrario, si todas las respuestas son correctas, el probador retendrá sus fondos. Este mecanismo de incentivos económicos está diseñado para prevenir comportamientos deshonestos.

En última instancia, esta interacción garantiza que la verificación computacional solo se transfiera a la cadena de bloques de Bitcoin en caso de disputa, realizando así la gran mayoría de cálculos fuera de la cadena. Este diseño mantiene la eficiencia de la red de Bitcoin al mismo tiempo que proporciona la capacidad de ejecutar programas más complejos en Bitcoin.

Seguridad de BitVM

Desde la perspectiva del diseño arquitectónico, la seguridad de BitVM se basa principalmente en los siguientes aspectos:

Pruebas de fraude

En caso de disputa, los validadores pueden desafiar las declaraciones incorrectas del proponente a través de pruebas de fraude. Este mecanismo es similar a Optimistic Rollups y no requiere cambiar las reglas de consenso de Bitcoin.

Protocolo de desafío-respuesta

BitVM utiliza un protocolo de desafío-respuesta, donde los proponentes y validadores firman una serie de transacciones de antemano durante la fase de configuración del protocolo. Estas transacciones se utilizan para resolver problemas cuando surge una disputa.

Cómputo fuera de la cadena con verificación en cadena

BitVM permite que se ejecuten cálculos complejos fuera de la cadena, mientras que la verificación y la resolución solo tienen lugar en la cadena en caso de disputa. Este enfoque reduce el consumo de recursos en la cadena, al tiempo que mantiene la integridad y la seguridad de la cadena de bloques de Bitcoin.

Mecanismo de depósito y penalización

Si un proponente hace una declaración incorrecta, los validadores pueden confiscar su depósito. Este mecanismo asegura que los atacantes siempre pierdan su depósito por acciones indebidas.

Mecanismo de Contrato Bilateral

Este mecanismo proporciona una mejor privacidad en BitVM y reduce los costos de transacción, pero en comparación con el mecanismo multipartito de EVM, su universalidad se reduce un poco.

protocolo Nostr

¿Qué es el Protocolo Nostr

Nostr significa "Notas y Otras Cosas Transmitidas por Relés", lo que indica que es un protocolo de transmisión que implica relés, lo que sugiere que no es un protocolo de transmisión de igual a igual (P2P). Según el código de GitHubactualizar registros, este proyecto fue lanzado en noviembre de 2020. El protocolo tiene como objetivo crear el protocolo abierto más simple para una red social global resistente a la censura. Es un protocolo social descentralizado que permite a los usuarios crear, publicar y suscribirse a cualquier tipo de contenido sin control o intervención de plataformas o instituciones centralizadas. Nostr se inspira en Bitcoin y la Red Lightning, empleando mecanismos criptográficos y de consenso similares, así como una estructura de datos basada en eventos conocida como la Red Nostr.

Componentes del Protocolo Nostr

Par de claves pública y privada

Un par de claves pública y privada constituye una cuenta Nostr. A diferencia del sistema tradicional de nombre de usuario y contraseña, las cuentas Nostr utilizan un sistema de clave pública y privada similar a las criptomonedas. Para mayor simplicidad, la clave pública puede considerarse como el nombre de usuario y la clave privada como la contraseña. Es importante tener en cuenta que una vez que se pierde la clave privada, no se puede restablecer como una contraseña. Las claves públicas tienen el prefijo npub1 y las claves privadas nsec1. Es crucial asegurar la custodia de estas claves, ya que no pueden recuperarse si se pierden.

Cliente

Nostr es un protocolo para enviar información a través de Internet, que requiere un software de cliente para su uso. Los clientes pueden ser páginas web, software de escritorio o aplicaciones móviles. Los clientes leen información de los relés y envían datos recién generados a los relés para que otros clientes los lean. La información incluye firmas para garantizar que los datos sean enviados por el remitente auténtico. El cliente utiliza la clave privada para crear firmas. Al utilizar un cliente de escritorio o móvil por primera vez, la clave privada debe ser almacenada en él. La clave pública se puede obtener a partir de la clave privada. Para los clientes web, no se recomienda guardar la clave privada directamente en ellos; en su lugar, es mejor usar un complemento para guardar la clave privada.

Relay

Los relés pueden entenderse como los servidores backend del protocolo Nostr. Los clientes de Nostr envían información a los relés, que pueden (o no) almacenar la información y transmitirla a todos los clientes conectados. Es importante tener en cuenta que los relés no son constantes; pueden cambiar significativamente con el tiempo. El protocolo Nostr depende de los relés para almacenar y recuperar datos. Si un usuario experimenta velocidades lentas del cliente, podría deberse a la lentitud del relé conectado, y podría considerar agregar algunos otros relés.

NIPs

Los NIP (Posibilidades de Implementación de Nostr) son estándares utilizados para regular los relés y el software cliente compatibles con Nostr, especificando qué se debe, debería o podría implementarse. "NIP" se refiere a documentos de referencia que describen cómo opera el protocolo Nostr. Nostr es un protocolo descentralizado, no monopolizado por ninguna entidad centralizada (como Twitter), lo que significa que su dirección de desarrollo depende de todos los participantes. Podemos proponer y abogar por cambios y brindar comentarios sobre las ideas de otros. Como miembros activos de la comunidad del protocolo, todos tienen cierta opinión sobre la dirección futura del desarrollo de la red Nostr. Los NIP en la base de código principal han sido aprobados y se pueden agregar nuevas ideas a través de solicitudes de extracción.

Los NIP clave incluyen:

• NIP-04: Cifrado de mensajes, utilizando el algoritmo secp256k1 para el intercambio de claves de Diffie-Hellman, lo que permite el cifrado de extremo a extremo.

• NIP-05: Mapea claves públicas a nombres de dominio para recordar fácilmente, como mapear la clave pública del autor al @NomandJamesdominio.

• NIP-06: Frases mnemónicas, similares a las utilizadas en carteras de criptomonedas.

• NIP-13: Prueba de trabajo. Este concepto es anterior a Bitcoin y se utiliza ampliamente en las capas de consenso de POW de blockchain y en el protocolo de susurro de Ethereum. Implica completar una prueba de trabajo computacionalmente intensiva antes de enviar un mensaje, que el servidor de retransmisión receptor verifica. Proporcionar esta prueba implica gastar potencia computacional, elevando el umbral para inundar los retransmisores con mensajes basura.

• NIP-22: Marcas de tiempo de mensajes. Informar a los servidores de retransmisión la hora en que se creó un mensaje, lo que permite a los relés aceptar selectivamente los mensajes. Las marcas de tiempo se pueden establecer para el pasado o el futuro.

• NIP-40: Tiempo de caducidad. Informar a los servidores de retransmisión cuándo expira un mensaje para que pueda ser eliminado.

• NIP-57: Enlaces de propinas de la Red Lightning.

• NIP-65: Lista recomendada de servicios de retransmisión.

Los eventos son los únicos Objetoestructura en Nostr. Cada evento tiene un tipopara indicar el tipo de evento (qué acción ha tomado el usuario o qué información ha recibido).

Funcionamiento del protocolo Nostr

El protocolo Nostr opera a través de relés. Estos relés permiten a los usuarios en el mismo relé enviarse archivos Json entre sí.

Para ayudar a entender esto, considera un diagrama simplificado:

El diagrama incluye 3 relés y 3 clientes, cada cliente utilizando una plataforma diferente.

En este diagrama:

• Bob puede ver todos los tweets de Alice pero ninguno de Mary (Bob ni siquiera es consciente de la existencia de Mary).

• Alice puede ver todos los tweets de Bob pero ninguno de Mary (Alice también desconoce la existencia de Mary).

• Mary puede ver los tweets tanto de Bob como de Alice porque ella escribe datos solo en Relay 3 pero puede leer datos de Relay 2 (que contiene los datos de Bob y Alice).

Profundización en los Contratos Nostr

Dado el protocolo Nostr como un protocolo abierto muy ligero, proporciona un conjunto de especificaciones de protocolo para plataformas de medios sociales descentralizadas. Realicemos un análisis de código simple del protocolo:

La base del protocolo es un servidor WebSocket (conocido como nostr-relay), que procesa y almacena una estructura de datos muy simple llamada Evento. Se muestra de la siguiente manera:

{  "id": "<32 bytes sha256 del evento serializado>",  "pubkey": "<clave pública de 32 bytes en hexadecimal del creador del evento>",  "created_at": "<marca de tiempo unix en segundos>",  "kind": "<entero>",  "tags": [    ["e", "<32 bytes en hexadecimal del id de otro evento>", "<URL de retransmisión recomendada>"],    ["p", "<32 bytes en hexadecimal de la clave>", "<URL de retransmisión recomendada>"],    ... // otros tipos de etiquetas pueden incluirse más adelante  ],  "content": "<cadena arbitraria>",  "sig": "<firma de 64 bytes del hash sha256 del evento serializado, que es el mismo que el campo 'id'>"}

Los eventos siempre están firmados (mediante firmas de tipo Schnorr) y contienen datos estructurados que pueden tener diferentes significados semánticos. El tipo Schnorr XOnlyPubkeys definido en BIP340 (actualmente utilizado con Bitcoin Taproot) se utiliza como "identidades" en todo el protocolo.

El cliente nostr es una aplicación que puede comunicarse con el relé nostr y puede utilizar suscriptores para suscribirse a cualquier conjunto de eventos.

Los filtros representan el conjunto de todos los eventos de Nostr en los que el cliente está interesado.

Los clientes no necesitan registrarse ni crear cuentas, ya que el cliente utiliza la clave pública del usuario para la identificación. Cada vez que el cliente se conecta al relé, envía el filtro de suscripción del usuario, y mientras estén conectados, el relé transmitirá los "eventos de interés" al cliente.

Los relés pueden almacenar en caché las suscripciones de los clientes, pero esto no es obligatorio. Los clientes deben manejar todo en el “lado del cliente”, mientras que los relés pueden ser tan tontos como una roca.

Los clientes no se comunican entre sí. Pero los Relays pueden hacerlo. Esto permite que los relays obtengan datos para el cliente que no tiene, y los clientes pueden suscribirse a eventos fuera del relay al que están conectados.

A primera vista, da la impresión de que Nostr como protocolo es inútil (¿por qué no simplemente firmar y volcar el JSON sin procesar y dejar que el cliente lo descifre?), pero una mirada más profunda revela que el modelo de 'servidor tonto, cliente inteligente' puede descubrir algunas ventajas significativas en la ingeniería del diseño de protocolos descentralizados.

Totalmente descentralizado como una característica clave de Nostr

Nostr sirve como la capa de protocolo para aplicaciones sociales, transfiriendo Notas y otras Cosas a través de Relevos sin depender de servidores centralizados. Su completa descentralización permite que cualquier aplicación acceda libremente a través de una red distribuida, proporcionando una plataforma social abierta y sin permisos. Por lo tanto, Nostr no ofrece un producto directo al consumidor para los usuarios, sino que se enfoca en implementar la infraestructura social necesaria a nivel de protocolo. La capacidad para la puesta en producción de productos es proporcionada por aplicaciones de terceros, y los usuarios de diferentes aplicaciones pueden interactuar socialmente entre sí.

La ventaja de Nostr radica en su provisión de una red social verdaderamente libre y abierta, sin verse afectada ni amenazada por ningún poder centralizado o intereses. Los usuarios pueden expresar libremente sus opiniones y creencias sin temor a la censura, prohibiciones o desplataformación; los creadores de contenido pueden establecer libremente sus modelos de incentivos sin preocuparse por ser privados de ingresos o enfrentarse a una competencia injusta. Los usuarios de Nostr también pueden elegir libremente sus círculos sociales sin temor a la manipulación, la desinformación o la infracción de la privacidad.

Nostr difiere significativamente de las redes sociales tradicionales y cuenta con las siguientes características y ventajas:

Descentralización: Nostr no depende de ningún servidor o plataforma centralizada, sino que utiliza la red Bitcoin para la transmisión y almacenamiento de información. Esto garantiza que los usuarios no tengan que preocuparse por el robo de datos, la censura o la eliminación, y no estén sujetos a las reglas o políticas de terceros.

Autonomía: Nostr permite a los usuarios controlar sus propios datos e identidad. Los usuarios pueden elegir libremente a quién quieren seguir y confiar, y expresar sus puntos de vista e ideas sin temor a ser prohibidos, bloqueados o degradados, y sin sufrir interferencias de anuncios o contenido recomendado. La verificabilidad de usuarios específicos también facilita la identificación de spam y contenido generado por bots.

Apertura: Nostr es un protocolo abierto en el que cualquiera puede participar y contribuir. Los usuarios pueden desarrollar y utilizar diferentes clientes, así como construir y ejecutar sus propios nodos (servidores que pueden reenviar y almacenar información de Nostr). Los usuarios también pueden crear y utilizar diferentes tipos y etiquetas, que son metadatos utilizados para diferenciar y categorizar la información de Nostr. La estructura es simple y flexible EventoEl formato admite varios tipos de publicación: publicaciones en redes sociales, contenido extenso, medios enriquecidos, comercio electrónico, etc. Además, la integración de Nostr con la Red Lightning ha facilitado un nuevo modelo de negocio más justo de valor por valor.

Preocupaciones de seguridad del Protocolo Nostr

Gestión de Clave Privada

El protocolo Nostr utiliza pares de claves públicas y privadas para las cuentas, lo que requiere que los usuarios administren correctamente sus claves privadas. Una vez perdida, la clave privada no se puede recuperar. Esto puede suponer un reto para la mayoría de los usuarios, que pueden carecer de los conocimientos técnicos y la experiencia necesarios para gestionar de forma segura las claves privadas.

Selección de retransmisión

En el protocolo Nostr, los usuarios deben elegir y verificar los relés por sí mismos. Elegir un relé no confiable o malicioso podría resultar en la filtración, manipulación o eliminación de su información.

Diseminación de información

En el protocolo Nostr, la información enviada por los usuarios no se propaga a través de múltiples relés. Esto significa que si su información no es recibida y almacenada por un número suficiente de relés, podría perderse o no ser vista por otros usuarios, exacerbando el problema de los silos de información.

Almacenamiento de información discrecional de Relays

Los relés en el protocolo Nostr pueden decidir libremente si recibir y almacenar la información de los usuarios. Esto podría llevar a que algunos relés elijan solo recibir y almacenar la información que consideren valiosa o que se alinee con sus intereses, mientras ignoran o rechazan otra información.

Extensiones de protocolo maliciosas

Si bien el protocolo Nostr define algunos tipos de eventos y funcionalidades básicas, también permite a los clientes y relés implementar selectivamente características adicionales. Esto podría llevar a la implementación de funcionalidades inseguras o maliciosas por parte de algunos clientes y relés, lo que afectaría la seguridad y privacidad de los usuarios.

Manejo de la información

Debido a la falta de una capa de consenso en el protocolo Nostr, algunos relés no procesan mensajes con una diferencia significativa en las marcas de tiempo y el tiempo UNIX, lo que deja espacio para que los clientes aprovechen esta discrepancia para falsificar mensajes.

Visión general del ecosistema Nostr

Jack Dorsey, cofundador de Twitter y un gran partidario del protocolo Nostr, donó 14.17 Bitcoins (aproximadamente $245,000) para apoyar su desarrollo en diciembre de 2022. Su perfil en X muestra de manera destacada su dirección personal de Nostr, lo que indica su aprecio por el protocolo.

Damus⚡️: Principales aplicaciones del protocolo Nostr

X：https://twitter.com/damusapp

Damus es una aplicación social que admite propinas de Bitcoin a través de la Lightning Network, reemplazando el común 'Me gusta' o pulgar hacia arriba con propinas. Las bajas tarifas de transacción de la Lightning Network hacen que las propinas sean prácticamente gratuitas. Además de Damus, las aplicaciones del protocolo Nostr incluyen la herramienta de comunicación Anigma, la herramienta de intercambio de texto Sendtr y el juego de ajedrez en línea Jeste, entre otros.

Socio principal de medios del Protocolo Nostr: TGFB

TGFB es una plataforma de educación cristiana sobre Bitcoin que tiene como objetivo educar y equipar a los cristianos para que comprendan Bitcoin y lo utilicen para glorificar a Dios y beneficiar a la humanidad. Una parte significativa de su contenido está dedicada a promover el protocolo Nostr a través de podcasts presentados por Jon y Jordan, explorando las implicaciones del protocolo desde una perspectiva cristiana. Se espera que la combinación del cristianismo, ampliamente conocido en EE. UU. y a nivel mundial, el ETF de Bitcoin aprobado por la SEC, y el protocolo Nostr construido sobre la vasta base de usuarios de Lightning Network, promueva significativamente la adopción y el apoyo al protocolo Nostr.

Protocolos Derivados Nostr

Activos de Nostr + Taproot

El Protocolo de Activos Nostr es un protocolo de código abierto que integra activos Taproot y pagos nativos de Bitcoin (denominados en Satoshis) en el ecosistema Nostr, apoyando interacciones con otros protocolos de pago, incluida la Red Lightning y activos Taproot.

Una vez que se introducen los activos, pueden enviarse y recibirse utilizando las claves públicas y privadas del protocolo Nostr, con liquidación y seguridad aún dependiendo de la Red Lightning. El Protocolo de Activos Nostr, aunque construido sobre la tecnología de Nostr, es un protocolo distinto que facilita funciones transaccionales básicas a través de los mensajes de Nostr.

El servicio de custodia completa del Protocolo de Activos Nostr implica que los usuarios depositen su Bitcoin u otros activos en una billetera controlada por el protocolo, y luego ejecuten instrucciones de implementación, acuñación y transferencia de tokens a través de mensajes Nostr.

Sin embargo, el servicio de custodia completo es controvertido debido a los posibles riesgos de seguridad. Los usuarios no pueden controlar completamente sus activos y, en caso de una violación de la plataforma o estafa de salida, podrían perder todos sus activos.

Además, tras su lanzamiento el 30 de octubre, Nostr experimentó una gran demanda de depósitos de activos, lo que llevó a un mantenimiento frecuente del sitio y a cierres, lo que generó preocupaciones sobre el historial del equipo y la fiabilidad del proyecto. El 8 de noviembre, el Protocolo de Activos Nostr respondió oficialmente a un comentario en chino en un tweet, con algunos usuarios aún cuestionando la credibilidad del proyecto. La comunidad de Nostr ha expresado una fuerte oposición al token asociado con este protocolo de extensión.

Nostr + Inscription

Noscription es un protocolo de token experimental basado en Nostr, que permite a los usuarios crear y negociar tokens similares a brc-20, distintos de los tokens de activos de Taproot.

Análisis Comparativo

Implementación de Protocolo

• BitVM exige capacidades computacionales extremadamente altas y actualmente solo existe en teoría. En términos de implementación comercial, RGB tiene una ventaja significativa con numerosas aplicaciones ya en uso. (La organización técnica detrás de RGB, LNP/BP, tiene pocos desarrolladores y es sin fines de lucro, lo que conduce a un progreso lento en el desarrollo). Por otro lado, Nostr, obstaculizado por los cuellos de botella comunes de SocialFi, también ha fracasado en avanzar aún más en el ecosistema de aplicaciones de su protocolo.

  Protección de la privacidad

• Tanto RGB como BitVM realizan cálculos fuera de la cadena, pero el protocolo RGB garantiza que terceros no puedan rastrear el historial de los activos RGB en la cadena de bloques. Solo cuando un usuario recibe un activo se entera de su historial, una característica que BitVM no puede lograr. El protocolo Nostr, al ser un protocolo social, tiene un alto grado de incertidumbre en la transmisión de información, lo que puede provocar fugas de información, bloqueos, pérdidas y manipulación maliciosa debido a vulnerabilidades.

  Compatibilidad nativa con BTC

• Tanto RGB como BitVM no requieren cambios en el protocolo de Bitcoin; Nostr está construido en la red Lightning nativa, ofreciendo una compatibilidad nativa relativamente buena y una experiencia de desarrollo fluida.

  Seguridad del Protocolo

• El protocolo RGB opera fuera de la cadena en un entorno de pruebas, asegurando la seguridad de los datos. Su sistema de facturación también garantiza la seguridad de los datos desde un punto de vista de diseño. En cuanto a la interacción con BTC, utiliza un mecanismo similar a la Red Lightning para la emisión de activos.

• BitVM utiliza un modelo Rollup, que también ejecuta datos fuera de la cadena. Las características de la máquina virtual, combinadas con pruebas de fraude y un modelo de desafío-respuesta, garantizan la seguridad de BitVM.

• Nostr utiliza un modelo de relé, donde el ingenioso diseño de transmisión de información entre relés y algoritmos de encriptación asegura la seguridad de la información dentro del protocolo Nostr.

En la industria Web3, no había ningún laboratorio específicamente centrado en la seguridad del ecosistema Bitcoin hasta la creación de BTC Security Lab, que llena este vacío al proporcionar soporte de seguridad profesional e investigación para el ecosistema Bitcoin. ScaleBit y BiHelix tienen como objetivo liderar la carrera en seguridad del ecosistema Bitcoin, estableciendo estándares de seguridad para la industria y promoviendo el desarrollo saludable del ecosistema.

Ecosistema y Comercialización

• Como protocolo social, Nostr supera tanto a BitVM como a RGB en base de usuarios y popularidad de tráfico, lo que hace que su expansión de protocolo de ecosistema y comercialización de aplicaciones sea más completa que las otras dos.

• El protocolo RGB ha estado presente durante un tiempo, con muchos proyectos esperando actualmente el lanzamiento de RGB V0.11.

• BitVM ha lanzado su whitepaper hace solo unos meses, y su ecosistema todavía está en desarrollo.

Se espera que el futuro de estos tres protocolos genere numerosas Dapps en los ámbitos de SocialFi, GameFi y DeFi, lo que traerá una nueva ola de popularidad al ecosistema de BTC.

Un agradecimiento especial a Ausdin.eth, 0xLayman, Echo, Venus por sus contribuciones a este informe.

Descargo de responsabilidad：

1. Este artículo es reimpreso de[chaincatcher]. Todos los derechos de autor pertenecen al autor original [Zhejiang University Blockchain Association, BiHelix, ScaleBit & BTC Security Lab]. Si hay objeciones a esta reimpresión, por favor contacte alGate Learnequipo y lo manejarán rápidamente.
2. Descargo de responsabilidad: Las opiniones expresadas en este artículo son únicamente las del autor y no constituyen ningún consejo de inversión.
3. Las traducciones del artículo a otros idiomas son realizadas por el equipo Gate Learn. A menos que se mencione, está prohibido copiar, distribuir o plagiar los artículos traducidos.