Nostr 2.0 puede construirse sobre Bitcoin como una Capa 2, proporcionando un almacenamiento seguro de datos fuera de la cadena, al igual que Lightning Network proporciona pagos instantáneos fuera de la cadena como una Capa 2.
Este artículo explicará cómo el relé Nostr sincroniza sus datos mientras mantiene su naturaleza liviana, lo que permite a los usuarios eliminar datos de manera selectiva, lo que no está disponible en las cadenas de bloques de Capa 1. Al mismo tiempo, en comparación con el almacenamiento de grandes cantidades de datos en la cadena de bloques de Bitcoin, debido a la capacidad y velocidad limitadas de los bloques de Bitcoin, puede resultar más económico almacenar datos utilizando los relés de Nostr.
El siguiente diseño informático simple mejora las propiedades de distribución de las redes Nostr bajo el criterio del teorema CAP estandarizado. CAP significa Consistencia, Disponibilidad y Tolerancia de Partición
**El relé Nostr no sabe cuándo un archivo de configuración está incompleto, el relé carece de consistencia (C en el teorema CAP). **
El relé carece de consistencia (C en el teorema CAP)
Coherencia significa que las bases de datos sincronizadas en cada computadora son las mismas. Los relés de Nostr no pueden realizar una sincronización de confianza minimizada de una manera similar a cómo las cadenas de bloques sincronizan sus datos bloque por bloque. A diferencia de los nodos completos de Bitcoin, la base de datos almacenada por el relé Nostr suele estar incompleta. Además de solicitar ciegamente todas las publicaciones firmadas por un usuario específico, Nostr Relay no puede descubrir los datos que faltan.
Problemas de consistencia/sincronización de Nostr:
Si dos usuarios cargan sus publicaciones respectivas en diferentes relés de Nostr, es posible que esos dos usuarios no puedan ver las publicaciones de los demás porque Nostr no es como una cadena de bloques. En la cadena de bloques, cada vez que hay un nuevo registro, todos los nodos completos sincronizarán la cadena de bloques. Todos los nodos completos agregarán estos datos como un bloque a su cadena de bloques al mismo tiempo. Cada nodo completo en la cadena de bloques de Bitcoin posee exactamente la misma cadena de bloques.
Si queremos que los usuarios de Nostr siempre puedan ver las publicaciones de los demás, entonces todos los repetidores de Nostr necesitan una forma de identificar los datos faltantes en los perfiles de usuario para que puedan solicitar las piezas faltantes de otros repetidores o usuarios de Nostr.
Use la raíz de Merkle semanal en cadena y los hashes de árbol completo para sincronizar el relé de Nostr
Aproximadamente una vez a la semana, los usuarios pueden organizar todas sus publicaciones en un árbol de Merkle.
Cada hoja del árbol de Merkle contiene un hash de una publicación, al igual que cada hoja de Bitcoin contiene un hash de una transacción.
Una vez que un usuario haya organizado todo su perfil en un árbol de Merkle, publicará la raíz de Merkle en OP_RETURN en la cadena, debajo de una transacción normal de Bitcoin. Es por eso que Nostr 2.0 no requiere una bifurcación dura de la cadena de bloques para funcionar. OP_RETURN es una sección debajo de una transacción de Bitcoin que permite agregar una pequeña nota antes de la firma del remitente.
Además, el usuario codificará todo el árbol y lo cargará en la cadena junto con la raíz de Merkle (en OP_RETURN). La raíz de Merkle es solo el hash de la rama superior, no el árbol completo. El hash de todo el árbol es esencial para que los usuarios y repetidores puedan detectar si faltan datos de perfil.
Para obtener un hash de todo el árbol, coloque la raíz de Merkle en la raíz del archivo de texto. Luego, coloque la rama de Merkle en la línea debajo de la raíz. Luego, coloque las hojas de Merkle en la fila debajo de la rama. Una vez que el árbol esté organizado como se describe, tritúrelo todo a la vez. A continuación se muestra un ejemplo de un hash de árbol completo de cómo se vería un hash de árbol completo para el árbol de Merkle que se muestra arriba. Hashing de árbol completo (hashing de todos los datos del árbol de Merkle a la vez)
Los hashes de árbol completo y raíz de Merkle proporcionan dos funciones clave:
Las raíces de Merkle permiten a los usuarios y repetidores descargar una parte de un archivo de configuración a la vez, como poder descargar una transacción sin tener que descargar el bloque completo.
El hash de árbol completo les permite a los usuarios y repetidores saber si sus archivos de configuración almacenados están incompletos. A diferencia de una raíz de Merkle, el hash de árbol completo solo coincidirá si tiene todos los bits en el árbol de Merkle.
Este método económico se puede utilizar para actualizar todo el archivo de configuración semanalmente o con una frecuencia definida por el usuario. Nostr seguirá funcionando como lo hace ahora, pero los usuarios ocasionalmente pueden pagar algunos sats para sincronizar sus datos entre los repetidores de Nostr si quieren que todos los usuarios vean sus publicaciones.
Los usuarios y repetidores pueden descargar publicaciones para una sucursal a la vez. Después de cada rama, mezclan esa rama con otra rama más cercana a la raíz de Merkle para verificar si coincide con la raíz de Merkle en la cadena (similar a SPV). Si esas ramas se juntan para coincidir con la raíz de Merkle, entonces sabrán que esa rama es parte del perfil de usuario, incluso si aún no tienen el perfil de usuario completo. Los usuarios pueden descargar diferentes ramas del mismo archivo de configuración desde muchos troncales de Nostr diferentes, mientras verifican la validez de cada rama y se aseguran de que el archivo de configuración descargado esté completo.
La descarga de bifurcaciones una por una evita los ataques de demora que podrían acabar con muchas redes distribuidas, razón por la cual las raíces y bifurcaciones de Merkle se utilizan en el documento técnico de Bitcoin para proteger las billeteras ligeras SPV.
**¿Por qué una raíz de Merkle no puede funcionar como un hash de árbol completo? **
**Si los relés de Nostr dependieran solo de la raíz de Merkle, no podrían saber cuándo se completó el árbol de Merkle, ya que cada par de ramas más cercanas a la raíz de Merkle se convertirían en la misma raíz de Merkle. **
Para asegurarse de que el perfil del usuario esté completo, el retransmisor o el usuario generará un hash de su árbol Merkle completo actualizado y verificará que coincida con el hash del árbol completo en la cadena. Si todos los valores hash del árbol coinciden, los datos del usuario están completos. Si el hash de árbol completo no coincide, entonces un retransmisor o usuario puede decirles a otros retransmisores su último número de hoja y solicitar la rama faltante hasta que coincida el hash de árbol completo. Para realizar un seguimiento de todas las nuevas raíces de Merkle que se agregan cada semana, los relés de Nostr deben convertirse en nodos completos de Bitcoin. Los relés de Nostr 2.0 se pagan indirectamente para almacenar la cadena de bloques de Bitcoin mientras mejoran la seguridad de Bitcoin y Nostr.
Límites de almacenamiento de Nostr: regla general del usuario
Dado que los repetidores tienen derecho a elegir qué almacenar, a diferencia de los nodos completos de Bitcoin, los repetidores de Nostr pueden perder algunos datos de usuario. Por lo tanto, los usuarios solo deben almacenar datos en el relé Nostr, si los usuarios pueden hacer copias de seguridad localmente. El servicio autohospedado de Web5 permite a los usuarios sincronizar las copias de seguridad con todos sus dispositivos locales, lo que reducirá el riesgo para los usuarios preocupados por el uso de Nostr. Al final del día, solo la cadena de bloques es donde los datos son verdaderamente inmutables. Dicho esto, Nostr es una solución híbrida bastante segura que seguirá funcionando bien para muchas aplicaciones. Las compensaciones se enumeran a continuación:
Tres capas de minimización de la confianza
Nivel 1: almacenamiento de datos inmutable y costoso que es extremadamente difícil de censurar. (Los bloques de la cadena sincronizan todos los nodos completos de Bitcoin)
Nivel 2: almacenamiento de datos mutable y barato, censura moderadamente difícil. (árbol de Merkle fuera de la cadena y hash en la cadena, relé Nostr síncrono bajo demanda)
Almacenamiento de datos local sincronizado con todos los dispositivos locales, fácil de censurar. (centralización local)
Compensaciones fundamentales entre las cadenas de bloques basadas en el consenso de Nakamoto y Nostr
**Cuantos más relés Nostr almacenen datos para una dirección en particular, más difícil será censurar esos datos. Esto significa que los datos populares alojados por muchos repetidores de Nostr pueden ser más difíciles de censurar que los datos impopulares que rara vez se descargan. **
**Por otro lado, la cadena de bloques de consenso de Nakamoto evita la censura en función de la antigüedad de los datos. Cuanto más tiempo existan los datos en la cadena de bloques, más difícil será eliminarlos con un ataque del 51 %. **
Dado que podemos verificar que ciertas bifurcaciones pertenecen a usuarios específicos, los repetidores de Nostr se pueden pagar cada vez que pasan un pequeño dato a un usuario. Para lograr esto, el usuario necesita descargar la cabeza de la cadena de bloques (como en SPV) para poder realizar las funciones típicas de una billetera ligera. El usuario aprovechará la funcionalidad SPV de la billetera ligera para obtener una transacción específica de la cadena, que incluirá la raíz de Merkle del perfil de usuario y el hash de árbol completo en su OP_RETURN. Los usuarios ahora pueden pagar el relevo para descargar el perfil de ese usuario rama por rama y verificar cada rama haciéndolas coincidir para que coincidan con la raíz de Merkle en la cadena.
Para enviar sats (la unidad más pequeña de Bitcoin) al relé Nostr a cambio de proporcionar datos, utilizamos el diseño ZKCP (Zero-Knowledge Conditional Payments) de Gregory Maxwell (famoso desarrollador de Bitcoin Core). [1] Una versión evolucionada de ZKCSP: prueba de recuperabilidad [2] Combinado con Lightning Network.
De acuerdo con la descripción del libro blanco de ZKCSP:
"... no se necesita un tercero de confianza... También implementamos el protocolo ZKCSP para el caso de prueba de recuperación, en el que el cliente paga al servidor por la prueba de que los datos del cliente se almacenaron correctamente en el servidor". [2]
Un usuario inicia un contrato inteligente Lightning con varios financiadores.
El usuario envía solicitudes a los financieros circundantes. El financista firma la solicitud.
Los usuarios envían solicitudes firmadas por financiadores directamente a los relés Nostr conectados a esos financiadores.
Los usuarios ahora inician construcciones ZKCSP para garantizar que los financistas paguen a los relevos de Nostr solo después de que se entreguen los datos solicitados correctamente.
Una vez que ocurra el paso 3, el usuario hará modificaciones además de la solicitud original firmada por el financista antes de iniciar la construcción de ZKCSP en el paso 4. El usuario agregará un extra además de la solicitud original, especificando el monto a deducir de los saldos del usuario y del financiador (deben ser el mismo monto, más la tarifa del financiador), que el usuario luego agregará al mensaje original. contenido a firmar.
**Si el usuario especifica enviar más sats de los que posee, o más de los que el financista ha congelado en ese repetidor de Nostr, entonces el repetidor de Nostr rechazará la solicitud ya que el repetidor no podrá recibir el pago. **
De esta manera, los usuarios pueden conectarse con muchos repetidores de Nostr mientras congelan sus fondos con solo unos pocos financiadores. Se podría adoptar un enfoque similar con Lightning Network, donde los financistas de confianza minimizada son intermediarios sin permiso entre usuarios y comerciantes. Los saltos relámpago P2P normales también están disponibles en Nostr 2.0, pero esto puede ser útil si el enrutamiento y el balanceo de canales fallan con frecuencia.
Lista blanca Desbloquear Nostr Relay pagado
Los relés de Nostr pueden incluir en la lista blanca ciertas claves si desean almacenar los datos vistos por todos estos usuarios. Si los relés de Nostr no pueden incluir en la lista blanca a los usuarios que desean almacenar datos, almacenarán los datos que se les envíen. Si los usuarios siempre pueden enviar datos a los repetidores de forma gratuita, entonces los usuarios nunca tendrán que pagar por los repetidores de Nostr. Nostr puede ofrecer opciones pagas solo si el repetidor tiene la opción de negarse a almacenar datos que no se pueden pagar. Todavía existen retransmisiones gratuitas, pero actualmente no existe la opción de retransmisiones pagas.
En lugar de intentar almacenar todos los datos de Nostr de forma gratuita, un relé de Nostr de pago puede utilizar una lista blanca para almacenar de forma selectiva todos los datos que los usuarios de pago ven a diario. Algunos repetidores de Nostr seguirán funcionando en un modelo gratuito, pero a mayor escala esto no es sostenible, ya que la mayoría de los repetidores gratuitos son solo entusiastas entusiastas. La inclusión en la lista blanca (incluso si pudiéramos asignar de forma segura una clave pública a cada perfil de Nostr) le da al relé de Nostr la capacidad de decidir qué datos almacenar no sería posible.
Una clave pública por perfil desbloquea la función de lista blanca: la dirección de Bitcoin se convierte en su clave pública de Nostr.
Este sistema finalmente nos permite asignar una clave pública a cada archivo de configuración.
No hay ningún beneficio para los usuarios que crean nuevas claves públicas para cada publicación... ¡ya que todas están asociadas con sus perfiles! Esto no es lo mismo que una dirección de Bitcoin. A diferencia de Bitcoin, que los usuarios tengan varias claves públicas dentro de la misma aplicación no mejora la privacidad.
**La clave pública del perfil de Nostr debe coincidir con la clave pública de la transacción de Bitcoin que contiene el hash semanal (la raíz de Merkle de todas las publicaciones del usuario y el hash de árbol completo). A diferencia de los usuarios de Nostr que usan firmas Schnorr, necesitarán usar una billetera Bitcoin (billetera móvil/billetera ligera o nodo completo) para firmar. **
Lo bueno de esto es que cada cuenta de Nostr estará representada por su dirección de Bitcoin**, lo que significa que los usuarios pueden enviar pagos directamente a las cuentas de Nostr sin solicitar dos claves públicas diferentes. Esto reduce el costo cognitivo de nuevos usuarios en el sistema. En lugar de usar nombres de usuario, los usuarios aún deben enviarse claves públicas o DNS para encontrarse en Nostr. **
Si otras aplicaciones de Nostr usan claves públicas diferentes, aún pueden adjuntarse a la misma identidad descentralizada (DID); de esta manera, la forma en que se identifica su cuenta permanece uniforme en todas las aplicaciones. Sin embargo, esta regla de consenso de Nostr limitará el uso de una sola clave pública por perfil en cada aplicación de Nostr.
DHT actúa como una tabla de clasificación para el descubrimiento de pares.
Los relés pueden usar una tabla hash distribuida (DHT) para encontrar otros relés. Los repetidores pueden compartir su lista blanca en una tabla hash distribuida enumerando la clave pública donde se almacenan los datos. De esta manera, los repetidores a los que les faltan bifurcaciones de datos para una determinada clave pública pueden escanear la DHT y conectarse directamente a las direcciones IP de otros repetidores que afirman almacenar esas bifurcaciones faltantes. Los relés pueden descargar ramas faltantes directamente desde estos relés de Nostr.
Los repetidores también podrán encontrar los repetidores más activos al verificar cuántas transacciones ZKCSP anteriores esos repetidores han resuelto en la cadena, recientes y de todos los tiempos. En este sistema, todos los relés de Nostr se convierten en nodos completos, por lo que la auditoría de transacciones anteriores de otros relés será sencilla. Esto haría que forjar confianza fuera costoso, ya que las transacciones en cadena siempre requieren tarifas de transacción. Si un repetidor de Nostr abre muchos canales para generar confianza consigo mismo con el fin de ganarse la confianza de otros repetidores, tendrá que pagar muchas tarifas de transacción para mantener la reputación falsa cada semana. Después de que el atacante no pueda suministrar la rama que falta, el tiempo de espera hará que el relé se desconecte, por lo que este es solo un ataque temporal y costoso (al igual que un ataque del 51% es un ataque temporal y costoso).
El DHT no es tan anónimo como la minería, ya que la clave pública de cada relé de Nostr aparecerá junto a la dirección IP en el DHT, pero evitará la necesidad de que los relés envíen solicitudes a ciegas a través de la red, a una escala lo suficientemente grande. sobrecargará la red. Los repetidores de Nostr que buscan más privacidad pueden usar una VPN u otro servicio de protección de IP.
Los usuarios no tendrán acceso a este mismo sistema de confianza por no ser nodos completos. Sin embargo, los usuarios pueden confiar en él.
Los colombófilos están indirectamente conectados a cientos de repetidores de Nostr
Dado que los usuarios almacenan automáticamente todos los encabezados de bloque en sus billeteras ligeras, los usuarios pueden ver quiénes son los mineros más activos. Los mineros que se convierten en financistas permitirán a los usuarios filtrar a los mineros más populares para que no tengan que vincular ciegamente los fondos con financistas aleatorios que no tienen correlación con la viabilidad de la red.
**Los financieros (mineros) solo necesitan bloquear sus satélites con el relé Nostr, sin pasar los datos entre los usuarios y el relé. **El financiero (minero) solo necesita firmar la solicitud del usuario para que el usuario pueda interactuar directamente con todos los relés de Nostr a los que está conectado el financiero: 4 pasos para ZKCSP+Lightning como se indicó anteriormente.
en conclusión
Lightning Network no existiría sin la cadena de bloques de consenso Nakamoto de Bitcoin, ya que los usuarios no tendrían dónde almacenar sus pruebas agrupadas de transacciones fuera de la cadena.
Al igual que los usuarios agrupan todas estas transacciones de Lightning Network y colocan pequeñas pruebas en la cadena de bloques, empaquetaremos todos los datos de Nostr y colocaremos pequeñas pruebas en la cadena de bloques. De la misma manera que Lightning Network proporciona pagos instantáneos en la segunda capa, Nostr puede proporcionar almacenamiento de datos en la segunda capa sin el riesgo de una cadena lateral insegura. **
**Utiliza el mismo enfoque que Lightning Network, con la cadena de bloques de consenso Nakamoto de Bitcoin en la primera capa y Nostr+ZKCSP Lightning en la segunda capa. **
Ver originales
El contenido es solo de referencia, no una solicitud u oferta. No se proporciona asesoramiento fiscal, legal ni de inversión. Consulte el Descargo de responsabilidad para obtener más información sobre los riesgos.
Nostr2.0: como la capa de almacenamiento de datos bajo la cadena Bitcoin Layer 2
Autor: Colby Serpa Compilador: DAOrayaki
Nostr 2.0 puede construirse sobre Bitcoin como una Capa 2, proporcionando un almacenamiento seguro de datos fuera de la cadena, al igual que Lightning Network proporciona pagos instantáneos fuera de la cadena como una Capa 2.
Este artículo explicará cómo el relé Nostr sincroniza sus datos mientras mantiene su naturaleza liviana, lo que permite a los usuarios eliminar datos de manera selectiva, lo que no está disponible en las cadenas de bloques de Capa 1. Al mismo tiempo, en comparación con el almacenamiento de grandes cantidades de datos en la cadena de bloques de Bitcoin, debido a la capacidad y velocidad limitadas de los bloques de Bitcoin, puede resultar más económico almacenar datos utilizando los relés de Nostr.
El siguiente diseño informático simple mejora las propiedades de distribución de las redes Nostr bajo el criterio del teorema CAP estandarizado. CAP significa Consistencia, Disponibilidad y Tolerancia de Partición
**El relé Nostr no sabe cuándo un archivo de configuración está incompleto, el relé carece de consistencia (C en el teorema CAP). **
El relé carece de consistencia (C en el teorema CAP)
Coherencia significa que las bases de datos sincronizadas en cada computadora son las mismas. Los relés de Nostr no pueden realizar una sincronización de confianza minimizada de una manera similar a cómo las cadenas de bloques sincronizan sus datos bloque por bloque. A diferencia de los nodos completos de Bitcoin, la base de datos almacenada por el relé Nostr suele estar incompleta. Además de solicitar ciegamente todas las publicaciones firmadas por un usuario específico, Nostr Relay no puede descubrir los datos que faltan.
Problemas de consistencia/sincronización de Nostr:
Si dos usuarios cargan sus publicaciones respectivas en diferentes relés de Nostr, es posible que esos dos usuarios no puedan ver las publicaciones de los demás porque Nostr no es como una cadena de bloques. En la cadena de bloques, cada vez que hay un nuevo registro, todos los nodos completos sincronizarán la cadena de bloques. Todos los nodos completos agregarán estos datos como un bloque a su cadena de bloques al mismo tiempo. Cada nodo completo en la cadena de bloques de Bitcoin posee exactamente la misma cadena de bloques.
Si queremos que los usuarios de Nostr siempre puedan ver las publicaciones de los demás, entonces todos los repetidores de Nostr necesitan una forma de identificar los datos faltantes en los perfiles de usuario para que puedan solicitar las piezas faltantes de otros repetidores o usuarios de Nostr.
Use la raíz de Merkle semanal en cadena y los hashes de árbol completo para sincronizar el relé de Nostr
Los hashes de árbol completo y raíz de Merkle proporcionan dos funciones clave:
Este método económico se puede utilizar para actualizar todo el archivo de configuración semanalmente o con una frecuencia definida por el usuario. Nostr seguirá funcionando como lo hace ahora, pero los usuarios ocasionalmente pueden pagar algunos sats para sincronizar sus datos entre los repetidores de Nostr si quieren que todos los usuarios vean sus publicaciones.
Los usuarios y repetidores pueden descargar publicaciones para una sucursal a la vez. Después de cada rama, mezclan esa rama con otra rama más cercana a la raíz de Merkle para verificar si coincide con la raíz de Merkle en la cadena (similar a SPV). Si esas ramas se juntan para coincidir con la raíz de Merkle, entonces sabrán que esa rama es parte del perfil de usuario, incluso si aún no tienen el perfil de usuario completo. Los usuarios pueden descargar diferentes ramas del mismo archivo de configuración desde muchos troncales de Nostr diferentes, mientras verifican la validez de cada rama y se aseguran de que el archivo de configuración descargado esté completo.
La descarga de bifurcaciones una por una evita los ataques de demora que podrían acabar con muchas redes distribuidas, razón por la cual las raíces y bifurcaciones de Merkle se utilizan en el documento técnico de Bitcoin para proteger las billeteras ligeras SPV.
**¿Por qué una raíz de Merkle no puede funcionar como un hash de árbol completo? **
**Si los relés de Nostr dependieran solo de la raíz de Merkle, no podrían saber cuándo se completó el árbol de Merkle, ya que cada par de ramas más cercanas a la raíz de Merkle se convertirían en la misma raíz de Merkle. **
Para asegurarse de que el perfil del usuario esté completo, el retransmisor o el usuario generará un hash de su árbol Merkle completo actualizado y verificará que coincida con el hash del árbol completo en la cadena. Si todos los valores hash del árbol coinciden, los datos del usuario están completos. Si el hash de árbol completo no coincide, entonces un retransmisor o usuario puede decirles a otros retransmisores su último número de hoja y solicitar la rama faltante hasta que coincida el hash de árbol completo. Para realizar un seguimiento de todas las nuevas raíces de Merkle que se agregan cada semana, los relés de Nostr deben convertirse en nodos completos de Bitcoin. Los relés de Nostr 2.0 se pagan indirectamente para almacenar la cadena de bloques de Bitcoin mientras mejoran la seguridad de Bitcoin y Nostr.
Límites de almacenamiento de Nostr: regla general del usuario
Dado que los repetidores tienen derecho a elegir qué almacenar, a diferencia de los nodos completos de Bitcoin, los repetidores de Nostr pueden perder algunos datos de usuario. Por lo tanto, los usuarios solo deben almacenar datos en el relé Nostr, si los usuarios pueden hacer copias de seguridad localmente. El servicio autohospedado de Web5 permite a los usuarios sincronizar las copias de seguridad con todos sus dispositivos locales, lo que reducirá el riesgo para los usuarios preocupados por el uso de Nostr. Al final del día, solo la cadena de bloques es donde los datos son verdaderamente inmutables. Dicho esto, Nostr es una solución híbrida bastante segura que seguirá funcionando bien para muchas aplicaciones. Las compensaciones se enumeran a continuación:
Tres capas de minimización de la confianza
Compensaciones fundamentales entre las cadenas de bloques basadas en el consenso de Nakamoto y Nostr
**Cuantos más relés Nostr almacenen datos para una dirección en particular, más difícil será censurar esos datos. Esto significa que los datos populares alojados por muchos repetidores de Nostr pueden ser más difíciles de censurar que los datos impopulares que rara vez se descargan. **
**Por otro lado, la cadena de bloques de consenso de Nakamoto evita la censura en función de la antigüedad de los datos. Cuanto más tiempo existan los datos en la cadena de bloques, más difícil será eliminarlos con un ataque del 51 %. **
Dado que podemos verificar que ciertas bifurcaciones pertenecen a usuarios específicos, los repetidores de Nostr se pueden pagar cada vez que pasan un pequeño dato a un usuario. Para lograr esto, el usuario necesita descargar la cabeza de la cadena de bloques (como en SPV) para poder realizar las funciones típicas de una billetera ligera. El usuario aprovechará la funcionalidad SPV de la billetera ligera para obtener una transacción específica de la cadena, que incluirá la raíz de Merkle del perfil de usuario y el hash de árbol completo en su OP_RETURN. Los usuarios ahora pueden pagar el relevo para descargar el perfil de ese usuario rama por rama y verificar cada rama haciéndolas coincidir para que coincidan con la raíz de Merkle en la cadena.
Para enviar sats (la unidad más pequeña de Bitcoin) al relé Nostr a cambio de proporcionar datos, utilizamos el diseño ZKCP (Zero-Knowledge Conditional Payments) de Gregory Maxwell (famoso desarrollador de Bitcoin Core). [1] Una versión evolucionada de ZKCSP: prueba de recuperabilidad [2] Combinado con Lightning Network.
De acuerdo con la descripción del libro blanco de ZKCSP:
"... no se necesita un tercero de confianza... También implementamos el protocolo ZKCSP para el caso de prueba de recuperación, en el que el cliente paga al servidor por la prueba de que los datos del cliente se almacenaron correctamente en el servidor". [2]
Una vez que ocurra el paso 3, el usuario hará modificaciones además de la solicitud original firmada por el financista antes de iniciar la construcción de ZKCSP en el paso 4. El usuario agregará un extra además de la solicitud original, especificando el monto a deducir de los saldos del usuario y del financiador (deben ser el mismo monto, más la tarifa del financiador), que el usuario luego agregará al mensaje original. contenido a firmar.
**Si el usuario especifica enviar más sats de los que posee, o más de los que el financista ha congelado en ese repetidor de Nostr, entonces el repetidor de Nostr rechazará la solicitud ya que el repetidor no podrá recibir el pago. **
De esta manera, los usuarios pueden conectarse con muchos repetidores de Nostr mientras congelan sus fondos con solo unos pocos financiadores. Se podría adoptar un enfoque similar con Lightning Network, donde los financistas de confianza minimizada son intermediarios sin permiso entre usuarios y comerciantes. Los saltos relámpago P2P normales también están disponibles en Nostr 2.0, pero esto puede ser útil si el enrutamiento y el balanceo de canales fallan con frecuencia.
Lista blanca Desbloquear Nostr Relay pagado
Los relés de Nostr pueden incluir en la lista blanca ciertas claves si desean almacenar los datos vistos por todos estos usuarios. Si los relés de Nostr no pueden incluir en la lista blanca a los usuarios que desean almacenar datos, almacenarán los datos que se les envíen. Si los usuarios siempre pueden enviar datos a los repetidores de forma gratuita, entonces los usuarios nunca tendrán que pagar por los repetidores de Nostr. Nostr puede ofrecer opciones pagas solo si el repetidor tiene la opción de negarse a almacenar datos que no se pueden pagar. Todavía existen retransmisiones gratuitas, pero actualmente no existe la opción de retransmisiones pagas.
En lugar de intentar almacenar todos los datos de Nostr de forma gratuita, un relé de Nostr de pago puede utilizar una lista blanca para almacenar de forma selectiva todos los datos que los usuarios de pago ven a diario. Algunos repetidores de Nostr seguirán funcionando en un modelo gratuito, pero a mayor escala esto no es sostenible, ya que la mayoría de los repetidores gratuitos son solo entusiastas entusiastas. La inclusión en la lista blanca (incluso si pudiéramos asignar de forma segura una clave pública a cada perfil de Nostr) le da al relé de Nostr la capacidad de decidir qué datos almacenar no sería posible.
Una clave pública por perfil desbloquea la función de lista blanca: la dirección de Bitcoin se convierte en su clave pública de Nostr.
Este sistema finalmente nos permite asignar una clave pública a cada archivo de configuración.
No hay ningún beneficio para los usuarios que crean nuevas claves públicas para cada publicación... ¡ya que todas están asociadas con sus perfiles! Esto no es lo mismo que una dirección de Bitcoin. A diferencia de Bitcoin, que los usuarios tengan varias claves públicas dentro de la misma aplicación no mejora la privacidad.
**La clave pública del perfil de Nostr debe coincidir con la clave pública de la transacción de Bitcoin que contiene el hash semanal (la raíz de Merkle de todas las publicaciones del usuario y el hash de árbol completo). A diferencia de los usuarios de Nostr que usan firmas Schnorr, necesitarán usar una billetera Bitcoin (billetera móvil/billetera ligera o nodo completo) para firmar. **
Lo bueno de esto es que cada cuenta de Nostr estará representada por su dirección de Bitcoin**, lo que significa que los usuarios pueden enviar pagos directamente a las cuentas de Nostr sin solicitar dos claves públicas diferentes. Esto reduce el costo cognitivo de nuevos usuarios en el sistema. En lugar de usar nombres de usuario, los usuarios aún deben enviarse claves públicas o DNS para encontrarse en Nostr. **
Si otras aplicaciones de Nostr usan claves públicas diferentes, aún pueden adjuntarse a la misma identidad descentralizada (DID); de esta manera, la forma en que se identifica su cuenta permanece uniforme en todas las aplicaciones. Sin embargo, esta regla de consenso de Nostr limitará el uso de una sola clave pública por perfil en cada aplicación de Nostr.
DHT actúa como una tabla de clasificación para el descubrimiento de pares.
Los relés pueden usar una tabla hash distribuida (DHT) para encontrar otros relés. Los repetidores pueden compartir su lista blanca en una tabla hash distribuida enumerando la clave pública donde se almacenan los datos. De esta manera, los repetidores a los que les faltan bifurcaciones de datos para una determinada clave pública pueden escanear la DHT y conectarse directamente a las direcciones IP de otros repetidores que afirman almacenar esas bifurcaciones faltantes. Los relés pueden descargar ramas faltantes directamente desde estos relés de Nostr.
Los repetidores también podrán encontrar los repetidores más activos al verificar cuántas transacciones ZKCSP anteriores esos repetidores han resuelto en la cadena, recientes y de todos los tiempos. En este sistema, todos los relés de Nostr se convierten en nodos completos, por lo que la auditoría de transacciones anteriores de otros relés será sencilla. Esto haría que forjar confianza fuera costoso, ya que las transacciones en cadena siempre requieren tarifas de transacción. Si un repetidor de Nostr abre muchos canales para generar confianza consigo mismo con el fin de ganarse la confianza de otros repetidores, tendrá que pagar muchas tarifas de transacción para mantener la reputación falsa cada semana. Después de que el atacante no pueda suministrar la rama que falta, el tiempo de espera hará que el relé se desconecte, por lo que este es solo un ataque temporal y costoso (al igual que un ataque del 51% es un ataque temporal y costoso).
El DHT no es tan anónimo como la minería, ya que la clave pública de cada relé de Nostr aparecerá junto a la dirección IP en el DHT, pero evitará la necesidad de que los relés envíen solicitudes a ciegas a través de la red, a una escala lo suficientemente grande. sobrecargará la red. Los repetidores de Nostr que buscan más privacidad pueden usar una VPN u otro servicio de protección de IP.
Los usuarios no tendrán acceso a este mismo sistema de confianza por no ser nodos completos. Sin embargo, los usuarios pueden confiar en él.
Los colombófilos están indirectamente conectados a cientos de repetidores de Nostr
Dado que los usuarios almacenan automáticamente todos los encabezados de bloque en sus billeteras ligeras, los usuarios pueden ver quiénes son los mineros más activos. Los mineros que se convierten en financistas permitirán a los usuarios filtrar a los mineros más populares para que no tengan que vincular ciegamente los fondos con financistas aleatorios que no tienen correlación con la viabilidad de la red.
**Los financieros (mineros) solo necesitan bloquear sus satélites con el relé Nostr, sin pasar los datos entre los usuarios y el relé. **El financiero (minero) solo necesita firmar la solicitud del usuario para que el usuario pueda interactuar directamente con todos los relés de Nostr a los que está conectado el financiero: 4 pasos para ZKCSP+Lightning como se indicó anteriormente.
en conclusión
Lightning Network no existiría sin la cadena de bloques de consenso Nakamoto de Bitcoin, ya que los usuarios no tendrían dónde almacenar sus pruebas agrupadas de transacciones fuera de la cadena.
Al igual que los usuarios agrupan todas estas transacciones de Lightning Network y colocan pequeñas pruebas en la cadena de bloques, empaquetaremos todos los datos de Nostr y colocaremos pequeñas pruebas en la cadena de bloques. De la misma manera que Lightning Network proporciona pagos instantáneos en la segunda capa, Nostr puede proporcionar almacenamiento de datos en la segunda capa sin el riesgo de una cadena lateral insegura. **
**Utiliza el mismo enfoque que Lightning Network, con la cadena de bloques de consenso Nakamoto de Bitcoin en la primera capa y Nostr+ZKCSP Lightning en la segunda capa. **