A Nostr 2.0 pode ser construída sobre o Bitcoin como uma Camada 2, fornecendo armazenamento seguro de dados fora da cadeia, assim como a Lightning Network fornece pagamentos instantâneos fora da cadeia como uma Camada 2.
Este artigo explicará como o relé Nostr sincroniza seus dados enquanto mantém sua natureza leve, permitindo que os usuários excluam seletivamente os dados, que não estão disponíveis nas blockchains da Camada 1. Ao mesmo tempo, em comparação com o armazenamento de grandes quantidades de dados no blockchain Bitcoin, devido à capacidade e velocidade limitadas dos blocos Bitcoin, pode ser mais barato armazenar dados usando relés Nostr.
O projeto de ciência da computação simples a seguir melhora as propriedades de distribuição das redes Nostr sob o critério padronizado do teorema CAP. CAP significa Consistência, Disponibilidade e Tolerância à Partição
**O relé Nostr não sabe quando um arquivo de configuração está incompleto, o relé não tem consistência (C no teorema CAP). **
O relé não tem consistência (C no teorema CAP)
Consistência significa que os bancos de dados sincronizados em cada computador são os mesmos. Os retransmissores Nostr não podem fazer sincronização minimizada por confiança de maneira semelhante a como os blockchains sincronizam seus dados bloco a bloco. Ao contrário dos nós completos do Bitcoin, o banco de dados armazenado pelo relé Nostr geralmente está incompleto. Além de solicitar cegamente todas as postagens assinadas por um usuário específico, o Nostr relay não pode descobrir dados ausentes.
Problemas de consistência/sincronização do Nostr:
Se dois usuários enviarem suas respectivas postagens para diferentes retransmissores Nostr, esses dois usuários podem não conseguir ver as postagens um do outro porque o Nostr não é como um blockchain. No blockchain, toda vez que houver um novo registro, todos os nós completos sincronizarão o blockchain. Todos os nós completos adicionarão esses dados como um bloco ao seu blockchain ao mesmo tempo. Cada nó completo no blockchain Bitcoin possui exatamente o mesmo blockchain.
Se quisermos que os usuários Nostr sempre possam ver as postagens uns dos outros, todos os retransmissores Nostr precisam identificar os dados ausentes nos perfis de usuário para que possam solicitar as peças ausentes de outros retransmissores ou usuários Nostr.
Use raiz Merkle semanalmente na cadeia e hashes completos da árvore para sincronizar o relé Nostr
Cerca de uma vez por semana, os usuários podem organizar todas as suas postagens em uma árvore Merkle.
Cada folha na árvore Merkle contém um hash de uma postagem, assim como cada folha no Bitcoin contém um hash de uma transação.
Uma vez que um usuário tenha organizado todo o seu perfil em uma árvore Merkle, ele publicará a raiz Merkle em OP_RETURN on-chain, abaixo de uma transação Bitcoin normal. É por isso que o Nostr 2.0 não requer um hard fork do blockchain para funcionar. OP_RETURN é uma seção abaixo de uma transação Bitcoin que permite que uma pequena nota seja anexada antes da assinatura do remetente.
Além disso, o usuário fará o hash de toda a árvore e fará o upload para a cadeia junto com a raiz Merkle (em OP_RETURN). A raiz Merkle é apenas o hash do galho superior, não a árvore inteira. O hash de toda a árvore é essencial para que usuários e retransmissores possam detectar se faltam dados de perfil.
Para obter um hash da árvore inteira, coloque a raiz Merkle na raiz do arquivo de texto. Em seguida, coloque o ramo Merkle na linha abaixo da raiz. Em seguida, coloque as folhas de Merkle na fileira abaixo do galho. Depois que a árvore estiver organizada conforme descrito, faça o hash de uma vez. Abaixo está um exemplo de um hash de árvore inteira de como seria um hash de árvore inteira para a árvore Merkle mostrada acima. Hashing da árvore inteira (hashing de todos os dados da árvore Merkle de uma só vez)
Merkle root e hashes de árvore inteira fornecem duas funções principais:
As raízes Merkle permitem que usuários e retransmissores baixem uma parte de um arquivo de configuração por vez, como poder baixar uma transação sem precisar baixar o bloco inteiro.
O hashing da árvore inteira permite que usuários e retransmissores saibam se seus arquivos de configuração armazenados estão incompletos. Ao contrário de uma raiz Merkle, todo o hash da árvore só corresponderá se você tiver todos os bits na árvore Merkle.
Este método barato pode ser usado para atualizar todo o arquivo de configuração em uma frequência semanal ou definida pelo usuário. O Nostr ainda funcionará como agora, mas os usuários podem ocasionalmente pagar alguns satélites para sincronizar seus dados entre os retransmissores Nostr, se quiserem que suas postagens sejam vistas por todos os usuários.
Usuários e retransmissores podem baixar postagens para uma ramificação por vez. Depois de cada ramificação, eles misturam essa ramificação com outra ramificação mais próxima da raiz Merkle para verificar se ela corresponde à raiz Merkle na cadeia (semelhante ao SPV). Se essas ramificações forem combinadas para corresponder à raiz Merkle, elas saberão que a ramificação faz parte do perfil do usuário, mesmo que ainda não tenham o perfil completo do usuário. Os usuários podem baixar diferentes ramificações do mesmo arquivo de configuração de muitos troncos Nostr diferentes, verificando a validade de cada ramificação e garantindo que o arquivo de configuração baixado esteja completo.
O download de garfos um por um evita ataques de atraso que podem derrubar muitas redes distribuídas, e é por isso que raízes e garfos Merkle são usados no white paper do Bitcoin para proteger carteiras leves SPV.
**Por que uma raiz Merkle não pode funcionar como um hash de árvore inteira? **
**Se os retransmissores Nostr dependessem apenas da raiz Merkle, eles não seriam capazes de saber quando a árvore Merkle estava completa, uma vez que cada par de ramos mais próximo da raiz Merkle teria hash na mesma raiz Merkle. **
Para garantir que o perfil do usuário esteja completo, o retransmissor ou usuário fará o hash de toda a árvore Merkle atualizada e verificará se ele corresponde a todo o hash da árvore na cadeia. Se todos os hashes da árvore corresponderem, os dados do usuário estarão completos. Se todo o hash da árvore não corresponder, um retransmissor ou usuário pode informar a outros retransmissores seu último número de folha e solicitar a ramificação ausente até que todo o hash da árvore corresponda. Para acompanhar todas as novas raízes Merkle sendo adicionadas a cada semana, os retransmissores Nostr devem se tornar nós completos do Bitcoin. Os retransmissores Nostr 2.0 são indiretamente pagos para armazenar o blockchain do Bitcoin enquanto aumentam a segurança do Bitcoin e do Nostr.
Limites de armazenamento Nostr: regra prática do usuário
Como os retransmissores têm o direito de escolher o que armazenar, ao contrário dos nós completos do Bitcoin, os retransmissores Nostr podem perder alguns dados do usuário. Portanto, os usuários só devem armazenar dados no relé Nostr, se os usuários puderem fazer backups localmente. O serviço auto-hospedado do Web5 permite que os usuários sincronizem backups com todos os seus dispositivos locais, o que reduzirá o risco para usuários preocupados em usar o Nostr. No final das contas, apenas o blockchain é onde os dados são verdadeiramente imutáveis. Dito isso, o Nostr é uma solução híbrida bastante segura que ainda funcionará bem para muitos aplicativos. As compensações estão listadas abaixo:
Três camadas de minimização de confiança
Camada 1: armazenamento de dados imutável e caro que é extremamente difícil de censurar. (Os blocos na cadeia sincronizam todos os nós completos do Bitcoin)
Nível 2: Armazenamento de dados mutável e barato, censura moderadamente difícil. (árvore Merkle off-chain e hash on-chain, relé Nostr síncrono sob demanda)
Armazenamento de dados local sincronizado com todos os dispositivos locais, fácil de ser censurado. (centralização local)
Compensações fundamentais entre blockchains baseados em consenso de Nakamoto e Nostr
**Quanto mais relés Nostr armazenam dados para um determinado endereço, mais difícil é censurar esses dados. Isso significa que dados populares hospedados por muitos retransmissores Nostr podem ser mais difíceis de censurar do que dados impopulares que raramente são baixados. **
**Por outro lado, o blockchain de consenso Nakamoto impede a censura com base na idade dos dados. Quanto mais dados existirem no blockchain, mais difícil será excluí-los usando um ataque de 51%. **
Como podemos verificar que certos garfos pertencem a usuários específicos, os retransmissores Nostr podem ser pagos toda vez que passam um pequeno dado para um usuário. Para conseguir isso, o usuário precisa baixar o head da blockchain (como no SPV) para poder realizar as funções típicas de uma carteira leve. O usuário aproveitará a funcionalidade SPV da carteira leve para buscar uma transação específica da cadeia, que incluirá a raiz Merkle do perfil do usuário e todo o hash da árvore em seu OP_RETURN. Os usuários agora podem pagar o relé para baixar o perfil desse usuário, ramificação por ramificação, e verificar cada ramificação, fazendo hash para corresponder à raiz Merkle na cadeia.
Para enviar sats (a menor unidade de Bitcoin) para o relé Nostr em troca de fornecer dados, usamos o design ZKCP (Pagamentos Condicionais de Conhecimento Zero) de Gregory Maxwell (famoso desenvolvedor do Bitcoin Core) [1] Uma versão evoluída do ZKCSP: Prova de recuperabilidade [2] Combinado com Lightning Network.
De acordo com a descrição do white paper do ZKCSP:
"...não há necessidade de um terceiro confiável...Também implementamos o protocolo ZKCSP para o caso de prova de recuperabilidade, onde o cliente paga ao servidor pela prova de que os dados do cliente foram armazenados corretamente no servidor." [2]
Um usuário inicia um contrato inteligente Lightning com vários financiadores.
O usuário envia solicitações para financiadores ao redor. O financiador assina o pedido.
Os usuários enviam solicitações assinadas pelos financiadores diretamente aos retransmissores Nostr conectados a esses financiadores.
Os usuários agora iniciam construções ZKCSP para garantir que os retransmissores Nostr sejam pagos pelos financiadores somente após a entrega correta dos dados solicitados.
Uma vez que a etapa 3 ocorra, o usuário fará alterações em cima da solicitação original assinada pelo financiador antes de iniciar a construção do ZKCSP na etapa 4. O usuário adicionará um extra ao pedido original, especificando o valor a ser deduzido dos saldos do usuário e do financiador (devem ser o mesmo valor, mais a taxa do financiador), que o usuário anexará à mensagem original conteúdo para assinar.
**Se o usuário especificar enviar mais sats do que possui, ou mais do que o financiador congelou naquele retransmissor Nostr, o retransmissor Nostr rejeitará a solicitação, pois o retransmissor não poderá receber o pagamento. **
Desta forma, os usuários podem se conectar com muitos retransmissores Nostr enquanto congelam seus fundos com apenas alguns financiadores. Uma abordagem semelhante pode ser adotada com a Lightning Network, em que financiadores com confiança minimizada são intermediários sem permissão entre usuários e comerciantes. Jumps relâmpago P2P normais também estão disponíveis no Nostr 2.0, mas isso pode ser útil se o roteamento e o balanceamento de canal falharem com frequência.
Desbloqueio da lista branca Nostr Relay pago
Os retransmissores Nostr podem colocar certas chaves na lista de permissões se desejarem armazenar dados visualizados por todos esses usuários. Se os retransmissores Nostr não puderem colocar na lista de permissões os usuários que desejam armazenar dados, eles armazenarão todos os dados enviados a eles. Se os usuários sempre puderem enviar dados para os retransmissores gratuitamente, eles nunca precisarão pagar pelos retransmissores Nostr. A Nostr pode oferecer opções pagas apenas se o retransmissor tiver a opção de recusar o armazenamento de dados que não podem ser pagos. Retransmissões gratuitas ainda existem, mas a opção de retransmissões pagas não existe atualmente.
Em vez de tentar armazenar todos os dados Nostr gratuitamente, um retransmissor Nostr pago pode usar uma lista de permissões para armazenar seletivamente todos os dados que seus usuários pagantes visualizam diariamente. Alguns relés Nostr continuarão a operar em um modelo livre, mas em maior escala isso não é sustentável, pois a maioria dos relés livres são apenas entusiastas entusiastas. Lista de permissões (mesmo que pudéssemos atribuir com segurança uma chave pública a cada perfil Nostr), dando aos retransmissores Nostr a capacidade de decidir quais dados armazenar não seriam possíveis.
Uma chave pública por perfil desbloqueia o recurso de lista branca: o endereço Bitcoin torna-se sua chave pública Nostr.
Este sistema finalmente nos permite atribuir uma chave pública a cada arquivo de configuração.
Não há nenhum benefício para os usuários que criam novas chaves públicas para cada postagem... pois todas estão associadas aos seus perfis! Isso não é o mesmo que um endereço Bitcoin. Ao contrário do Bitcoin, ter usuários com várias chaves públicas no mesmo aplicativo não melhora a privacidade.
**A chave pública do perfil Nostr deve corresponder à chave pública da transação Bitcoin contendo o hash semanal (a raiz Merkle de todas as postagens do usuário e todo o hash da árvore). Ao contrário dos usuários Nostr que usam assinaturas Schnorr, eles precisarão usar uma carteira Bitcoin (carteira móvel/carteira leve ou nó completo) para assinar. **
A beleza disso é que cada conta Nostr será representada por seu endereço Bitcoin**, o que significa que os usuários podem enviar pagamentos diretamente para contas Nostr sem solicitar duas chaves públicas diferentes. Isso reduz o custo cognitivo de novos usuários no sistema. Em vez de usar nomes de usuários, os usuários ainda precisam enviar chaves públicas ou DNS uns aos outros para se encontrarem no Nostr. **
Se outros aplicativos Nostr usarem chaves públicas diferentes, eles ainda poderão ser anexados à mesma identidade descentralizada (DID) - dessa forma, a maneira como sua conta é identificada permanece consistente entre os aplicativos. No entanto, esta regra de consenso Nostr limitará o uso de apenas uma chave pública por perfil em cada aplicativo Nostr.
O DHT atua como uma tabela de classificação para descoberta de pares.
Os relés podem usar uma tabela de hash distribuída (DHT) para encontrar outros relés. Os relés podem compartilhar sua lista de permissões em uma tabela de hash distribuída listando a chave pública onde os dados são armazenados. Desta forma, os relés com forks de dados ausentes para uma determinada chave pública podem escanear o DHT e se conectar diretamente aos endereços IP de outros retransmissores que alegam armazenar esses forks ausentes. Os relés podem fazer o download de ramificações ausentes diretamente desses relés Nostr.
Os retransmissores também poderão encontrar os retransmissores mais ativos, verificando quantas transações ZKCSP anteriores esses retransmissores resolveram na cadeia - recentes e de todos os tempos. Neste sistema, todos os retransmissores Nostr tornam-se nós completos, portanto, a auditoria de transações anteriores de outros retransmissores será indolor. Isso tornaria a confiança dispendiosa, já que as transações on-chain sempre exigem taxas de transação. Se um retransmissor Nostr abrir muitos canais para construir confiança consigo mesmo, a fim de ganhar a confiança de outros retransmissores, ele terá que pagar muitas taxas de transação para manter a reputação falsa toda semana. Depois que o invasor falhar em fornecer o ramo ausente, o tempo limite fará com que o relé se desconecte - portanto, este é apenas um ataque temporário e caro (assim como um ataque de 51% é um ataque temporário e caro).
O DHT não é tão anônimo quanto a mineração, já que a chave pública de cada retransmissor Nostr será listada ao lado do endereço IP no DHT, mas evitará a necessidade de retransmissores enviarem solicitações cegamente pela rede - em uma escala grande o suficiente. irá sobrecarregar a rede. Os retransmissores Nostr que procuram mais privacidade podem usar uma VPN ou outro serviço de proteção IP.
Os usuários não terão acesso a esse mesmo sistema de confiança porque não são nós completos. No entanto, os usuários podem confiar nisso.
Os criadores estão indiretamente conectados a centenas de relés Nostr
Como os usuários armazenam automaticamente todos os cabeçalhos de bloco em suas carteiras leves, os usuários podem ver quem são os mineradores mais ativos. Os mineradores que se tornarem financiadores permitirão que os usuários filtrem os mineradores mais populares para que não precisem vincular fundos cegamente a financiadores aleatórios que não têm correlação com a viabilidade da rede.
**Financiadores (mineradores) só precisam bloquear seus sats com o relé Nostr, sem passar os dados entre os usuários e o relé. **O financiador (minerador) só precisa assinar a solicitação do usuário para que o usuário possa interagir diretamente com todos os relés Nostr aos quais o financiador está conectado - 4 etapas para ZKCSP+Lightning conforme acima.
para concluir
A Lightning Network não existiria sem o blockchain de consenso Nakamoto do Bitcoin, pois os usuários não teriam onde armazenar suas provas agrupadas de transações fora da cadeia.
Assim como os usuários agrupam todas essas transações da Lightning Network e colocam pequenas provas no blockchain, agruparemos todos os dados Nostr e colocaremos pequenas provas no blockchain. Da mesma forma que a Lightning Network fornece pagamentos instantâneos na segunda camada, a Nostr pode fornecer armazenamento de dados na segunda camada sem o risco de uma sidechain insegura. **
**Ele usa a mesma abordagem da Lightning Network, com o blockchain de consenso Nakamoto do Bitcoin na primeira camada e Nostr+ZKCSP Lightning na segunda camada. **
Ver original
O conteúdo serve apenas de referência e não constitui uma solicitação ou oferta. Não é prestado qualquer aconselhamento em matéria de investimento, fiscal ou jurídica. Consulte a Declaração de exoneração de responsabilidade para obter mais informações sobre os riscos.
Nostr2.0: como a camada de armazenamento de dados sob a cadeia Bitcoin Layer 2
Autor: Colby Serpa Compilador: DAOrayaki
A Nostr 2.0 pode ser construída sobre o Bitcoin como uma Camada 2, fornecendo armazenamento seguro de dados fora da cadeia, assim como a Lightning Network fornece pagamentos instantâneos fora da cadeia como uma Camada 2.
Este artigo explicará como o relé Nostr sincroniza seus dados enquanto mantém sua natureza leve, permitindo que os usuários excluam seletivamente os dados, que não estão disponíveis nas blockchains da Camada 1. Ao mesmo tempo, em comparação com o armazenamento de grandes quantidades de dados no blockchain Bitcoin, devido à capacidade e velocidade limitadas dos blocos Bitcoin, pode ser mais barato armazenar dados usando relés Nostr.
O projeto de ciência da computação simples a seguir melhora as propriedades de distribuição das redes Nostr sob o critério padronizado do teorema CAP. CAP significa Consistência, Disponibilidade e Tolerância à Partição
**O relé Nostr não sabe quando um arquivo de configuração está incompleto, o relé não tem consistência (C no teorema CAP). **
O relé não tem consistência (C no teorema CAP)
Consistência significa que os bancos de dados sincronizados em cada computador são os mesmos. Os retransmissores Nostr não podem fazer sincronização minimizada por confiança de maneira semelhante a como os blockchains sincronizam seus dados bloco a bloco. Ao contrário dos nós completos do Bitcoin, o banco de dados armazenado pelo relé Nostr geralmente está incompleto. Além de solicitar cegamente todas as postagens assinadas por um usuário específico, o Nostr relay não pode descobrir dados ausentes.
Problemas de consistência/sincronização do Nostr:
Se dois usuários enviarem suas respectivas postagens para diferentes retransmissores Nostr, esses dois usuários podem não conseguir ver as postagens um do outro porque o Nostr não é como um blockchain. No blockchain, toda vez que houver um novo registro, todos os nós completos sincronizarão o blockchain. Todos os nós completos adicionarão esses dados como um bloco ao seu blockchain ao mesmo tempo. Cada nó completo no blockchain Bitcoin possui exatamente o mesmo blockchain.
Se quisermos que os usuários Nostr sempre possam ver as postagens uns dos outros, todos os retransmissores Nostr precisam identificar os dados ausentes nos perfis de usuário para que possam solicitar as peças ausentes de outros retransmissores ou usuários Nostr.
Use raiz Merkle semanalmente na cadeia e hashes completos da árvore para sincronizar o relé Nostr
Merkle root e hashes de árvore inteira fornecem duas funções principais:
Este método barato pode ser usado para atualizar todo o arquivo de configuração em uma frequência semanal ou definida pelo usuário. O Nostr ainda funcionará como agora, mas os usuários podem ocasionalmente pagar alguns satélites para sincronizar seus dados entre os retransmissores Nostr, se quiserem que suas postagens sejam vistas por todos os usuários.
Usuários e retransmissores podem baixar postagens para uma ramificação por vez. Depois de cada ramificação, eles misturam essa ramificação com outra ramificação mais próxima da raiz Merkle para verificar se ela corresponde à raiz Merkle na cadeia (semelhante ao SPV). Se essas ramificações forem combinadas para corresponder à raiz Merkle, elas saberão que a ramificação faz parte do perfil do usuário, mesmo que ainda não tenham o perfil completo do usuário. Os usuários podem baixar diferentes ramificações do mesmo arquivo de configuração de muitos troncos Nostr diferentes, verificando a validade de cada ramificação e garantindo que o arquivo de configuração baixado esteja completo.
O download de garfos um por um evita ataques de atraso que podem derrubar muitas redes distribuídas, e é por isso que raízes e garfos Merkle são usados no white paper do Bitcoin para proteger carteiras leves SPV.
**Por que uma raiz Merkle não pode funcionar como um hash de árvore inteira? **
**Se os retransmissores Nostr dependessem apenas da raiz Merkle, eles não seriam capazes de saber quando a árvore Merkle estava completa, uma vez que cada par de ramos mais próximo da raiz Merkle teria hash na mesma raiz Merkle. **
Para garantir que o perfil do usuário esteja completo, o retransmissor ou usuário fará o hash de toda a árvore Merkle atualizada e verificará se ele corresponde a todo o hash da árvore na cadeia. Se todos os hashes da árvore corresponderem, os dados do usuário estarão completos. Se todo o hash da árvore não corresponder, um retransmissor ou usuário pode informar a outros retransmissores seu último número de folha e solicitar a ramificação ausente até que todo o hash da árvore corresponda. Para acompanhar todas as novas raízes Merkle sendo adicionadas a cada semana, os retransmissores Nostr devem se tornar nós completos do Bitcoin. Os retransmissores Nostr 2.0 são indiretamente pagos para armazenar o blockchain do Bitcoin enquanto aumentam a segurança do Bitcoin e do Nostr.
Limites de armazenamento Nostr: regra prática do usuário
Como os retransmissores têm o direito de escolher o que armazenar, ao contrário dos nós completos do Bitcoin, os retransmissores Nostr podem perder alguns dados do usuário. Portanto, os usuários só devem armazenar dados no relé Nostr, se os usuários puderem fazer backups localmente. O serviço auto-hospedado do Web5 permite que os usuários sincronizem backups com todos os seus dispositivos locais, o que reduzirá o risco para usuários preocupados em usar o Nostr. No final das contas, apenas o blockchain é onde os dados são verdadeiramente imutáveis. Dito isso, o Nostr é uma solução híbrida bastante segura que ainda funcionará bem para muitos aplicativos. As compensações estão listadas abaixo:
Três camadas de minimização de confiança
Compensações fundamentais entre blockchains baseados em consenso de Nakamoto e Nostr
**Quanto mais relés Nostr armazenam dados para um determinado endereço, mais difícil é censurar esses dados. Isso significa que dados populares hospedados por muitos retransmissores Nostr podem ser mais difíceis de censurar do que dados impopulares que raramente são baixados. **
**Por outro lado, o blockchain de consenso Nakamoto impede a censura com base na idade dos dados. Quanto mais dados existirem no blockchain, mais difícil será excluí-los usando um ataque de 51%. **
Como podemos verificar que certos garfos pertencem a usuários específicos, os retransmissores Nostr podem ser pagos toda vez que passam um pequeno dado para um usuário. Para conseguir isso, o usuário precisa baixar o head da blockchain (como no SPV) para poder realizar as funções típicas de uma carteira leve. O usuário aproveitará a funcionalidade SPV da carteira leve para buscar uma transação específica da cadeia, que incluirá a raiz Merkle do perfil do usuário e todo o hash da árvore em seu OP_RETURN. Os usuários agora podem pagar o relé para baixar o perfil desse usuário, ramificação por ramificação, e verificar cada ramificação, fazendo hash para corresponder à raiz Merkle na cadeia.
Para enviar sats (a menor unidade de Bitcoin) para o relé Nostr em troca de fornecer dados, usamos o design ZKCP (Pagamentos Condicionais de Conhecimento Zero) de Gregory Maxwell (famoso desenvolvedor do Bitcoin Core) [1] Uma versão evoluída do ZKCSP: Prova de recuperabilidade [2] Combinado com Lightning Network.
De acordo com a descrição do white paper do ZKCSP:
"...não há necessidade de um terceiro confiável...Também implementamos o protocolo ZKCSP para o caso de prova de recuperabilidade, onde o cliente paga ao servidor pela prova de que os dados do cliente foram armazenados corretamente no servidor." [2]
Uma vez que a etapa 3 ocorra, o usuário fará alterações em cima da solicitação original assinada pelo financiador antes de iniciar a construção do ZKCSP na etapa 4. O usuário adicionará um extra ao pedido original, especificando o valor a ser deduzido dos saldos do usuário e do financiador (devem ser o mesmo valor, mais a taxa do financiador), que o usuário anexará à mensagem original conteúdo para assinar.
**Se o usuário especificar enviar mais sats do que possui, ou mais do que o financiador congelou naquele retransmissor Nostr, o retransmissor Nostr rejeitará a solicitação, pois o retransmissor não poderá receber o pagamento. **
Desta forma, os usuários podem se conectar com muitos retransmissores Nostr enquanto congelam seus fundos com apenas alguns financiadores. Uma abordagem semelhante pode ser adotada com a Lightning Network, em que financiadores com confiança minimizada são intermediários sem permissão entre usuários e comerciantes. Jumps relâmpago P2P normais também estão disponíveis no Nostr 2.0, mas isso pode ser útil se o roteamento e o balanceamento de canal falharem com frequência.
Desbloqueio da lista branca Nostr Relay pago
Os retransmissores Nostr podem colocar certas chaves na lista de permissões se desejarem armazenar dados visualizados por todos esses usuários. Se os retransmissores Nostr não puderem colocar na lista de permissões os usuários que desejam armazenar dados, eles armazenarão todos os dados enviados a eles. Se os usuários sempre puderem enviar dados para os retransmissores gratuitamente, eles nunca precisarão pagar pelos retransmissores Nostr. A Nostr pode oferecer opções pagas apenas se o retransmissor tiver a opção de recusar o armazenamento de dados que não podem ser pagos. Retransmissões gratuitas ainda existem, mas a opção de retransmissões pagas não existe atualmente.
Em vez de tentar armazenar todos os dados Nostr gratuitamente, um retransmissor Nostr pago pode usar uma lista de permissões para armazenar seletivamente todos os dados que seus usuários pagantes visualizam diariamente. Alguns relés Nostr continuarão a operar em um modelo livre, mas em maior escala isso não é sustentável, pois a maioria dos relés livres são apenas entusiastas entusiastas. Lista de permissões (mesmo que pudéssemos atribuir com segurança uma chave pública a cada perfil Nostr), dando aos retransmissores Nostr a capacidade de decidir quais dados armazenar não seriam possíveis.
Uma chave pública por perfil desbloqueia o recurso de lista branca: o endereço Bitcoin torna-se sua chave pública Nostr.
Este sistema finalmente nos permite atribuir uma chave pública a cada arquivo de configuração.
Não há nenhum benefício para os usuários que criam novas chaves públicas para cada postagem... pois todas estão associadas aos seus perfis! Isso não é o mesmo que um endereço Bitcoin. Ao contrário do Bitcoin, ter usuários com várias chaves públicas no mesmo aplicativo não melhora a privacidade.
**A chave pública do perfil Nostr deve corresponder à chave pública da transação Bitcoin contendo o hash semanal (a raiz Merkle de todas as postagens do usuário e todo o hash da árvore). Ao contrário dos usuários Nostr que usam assinaturas Schnorr, eles precisarão usar uma carteira Bitcoin (carteira móvel/carteira leve ou nó completo) para assinar. **
A beleza disso é que cada conta Nostr será representada por seu endereço Bitcoin**, o que significa que os usuários podem enviar pagamentos diretamente para contas Nostr sem solicitar duas chaves públicas diferentes. Isso reduz o custo cognitivo de novos usuários no sistema. Em vez de usar nomes de usuários, os usuários ainda precisam enviar chaves públicas ou DNS uns aos outros para se encontrarem no Nostr. **
Se outros aplicativos Nostr usarem chaves públicas diferentes, eles ainda poderão ser anexados à mesma identidade descentralizada (DID) - dessa forma, a maneira como sua conta é identificada permanece consistente entre os aplicativos. No entanto, esta regra de consenso Nostr limitará o uso de apenas uma chave pública por perfil em cada aplicativo Nostr.
O DHT atua como uma tabela de classificação para descoberta de pares.
Os relés podem usar uma tabela de hash distribuída (DHT) para encontrar outros relés. Os relés podem compartilhar sua lista de permissões em uma tabela de hash distribuída listando a chave pública onde os dados são armazenados. Desta forma, os relés com forks de dados ausentes para uma determinada chave pública podem escanear o DHT e se conectar diretamente aos endereços IP de outros retransmissores que alegam armazenar esses forks ausentes. Os relés podem fazer o download de ramificações ausentes diretamente desses relés Nostr.
Os retransmissores também poderão encontrar os retransmissores mais ativos, verificando quantas transações ZKCSP anteriores esses retransmissores resolveram na cadeia - recentes e de todos os tempos. Neste sistema, todos os retransmissores Nostr tornam-se nós completos, portanto, a auditoria de transações anteriores de outros retransmissores será indolor. Isso tornaria a confiança dispendiosa, já que as transações on-chain sempre exigem taxas de transação. Se um retransmissor Nostr abrir muitos canais para construir confiança consigo mesmo, a fim de ganhar a confiança de outros retransmissores, ele terá que pagar muitas taxas de transação para manter a reputação falsa toda semana. Depois que o invasor falhar em fornecer o ramo ausente, o tempo limite fará com que o relé se desconecte - portanto, este é apenas um ataque temporário e caro (assim como um ataque de 51% é um ataque temporário e caro).
O DHT não é tão anônimo quanto a mineração, já que a chave pública de cada retransmissor Nostr será listada ao lado do endereço IP no DHT, mas evitará a necessidade de retransmissores enviarem solicitações cegamente pela rede - em uma escala grande o suficiente. irá sobrecarregar a rede. Os retransmissores Nostr que procuram mais privacidade podem usar uma VPN ou outro serviço de proteção IP.
Os usuários não terão acesso a esse mesmo sistema de confiança porque não são nós completos. No entanto, os usuários podem confiar nisso.
Os criadores estão indiretamente conectados a centenas de relés Nostr
Como os usuários armazenam automaticamente todos os cabeçalhos de bloco em suas carteiras leves, os usuários podem ver quem são os mineradores mais ativos. Os mineradores que se tornarem financiadores permitirão que os usuários filtrem os mineradores mais populares para que não precisem vincular fundos cegamente a financiadores aleatórios que não têm correlação com a viabilidade da rede.
**Financiadores (mineradores) só precisam bloquear seus sats com o relé Nostr, sem passar os dados entre os usuários e o relé. **O financiador (minerador) só precisa assinar a solicitação do usuário para que o usuário possa interagir diretamente com todos os relés Nostr aos quais o financiador está conectado - 4 etapas para ZKCSP+Lightning conforme acima.
para concluir
A Lightning Network não existiria sem o blockchain de consenso Nakamoto do Bitcoin, pois os usuários não teriam onde armazenar suas provas agrupadas de transações fora da cadeia.
Assim como os usuários agrupam todas essas transações da Lightning Network e colocam pequenas provas no blockchain, agruparemos todos os dados Nostr e colocaremos pequenas provas no blockchain. Da mesma forma que a Lightning Network fornece pagamentos instantâneos na segunda camada, a Nostr pode fornecer armazenamento de dados na segunda camada sem o risco de uma sidechain insegura. **
**Ele usa a mesma abordagem da Lightning Network, com o blockchain de consenso Nakamoto do Bitcoin na primeira camada e Nostr+ZKCSP Lightning na segunda camada. **