Este é um editorial de opinião de Shinobi, um educador autodidata no espaço Bitcoin e apresentador de podcast Bitcoin orientado para a tecnologia.
Sugiro, antes de ler isso, que você leia o artigo anterior que escrevi explicando o que é Nostr e como funciona em alto nível. Você deve ter uma boa ideia do design principal do sistema nesse ponto, então agora vamos dar uma olhada nos prováveis problemas que ocorrerão à medida que cresce a adoção. Com a plataforma se tornando popular para a comunidade Bitcoin, esses problemas devem ser observados.
Como discuti no artigo anterior, os pares de chaves pública/privada do usuário são parte integrante de como o Nostr funciona como um protocolo. Não há nomes de usuários ou qualquer tipo de identificador que um servidor de retransmissão esteja no controle para associar a usuários individuais. São simplesmente as chaves desses usuários que estão completamente sob seu controle.
Isso funciona como uma ligação estreita entre o usuário real e como eles são identificados por outros, o que impede que qualquer servidor de retransmissão desvincule essas duas coisas, ou seja, forneça o identificador de alguém para outro usuário. Isso resolve um dos maiores problemas fundamentais das plataformas utilizadas para a comunicação entre as pessoas: a falta de controle sobre as próprias identidades dos usuários. Mas também apresenta todos os problemas de gerenciamento de chaves que alguém que possui uma chave privada enfrenta. As chaves podem ser perdidas e as chaves podem ser comprometidas e, se tal evento ocorrer, os usuários não terão a quem recorrer para obter assistência, assim como no Bitcoin. Não há suporte ao cliente para recuperar nada. Você perde, é isso.
Isso inevitavelmente exigirá um esquema para que os usuários alternem de um par de chaves para outro de forma que seja verificável e detectável por outros usuários com os quais eles interagem por meio do protocolo. Todo o protocolo é baseado em provar que um evento veio de um usuário específico (chave de identidade), então todas essas garantias desaparecem quando as chaves de alguém são comprometidas.
Como você lida com isso? Basta ir verificar sua conta no Twitter? Bem, então esse não é um sistema muito descentralizado, em última análise, se você precisar usar uma plataforma centralizada onde eles não estão no controle de sua identidade para verificar sua identidade Nostr.
Outros usuários atestam a legitimidade de uma nova chave? Isso não aborda situações como comprometimentos de chave em massa ou não conhecer alguém próximo a eles o suficiente para confiar em seu atestado.
Nostr precisa de um esquema criptográfico real que vincule a rotação de uma chave a outra. Há uma proposta do desenvolvedor fiatjaf para um esquema básico que poderia resolver esse problema. A ideia básica seria pegar um longo conjunto de endereços derivados de uma única semente mestra e criar um conjunto de chaves “ajustadas” semelhantes a como as árvores Taproot são comprometidas com uma chave Bitcoin. Taproot pega a raiz da árvore Merkle da árvore Taproot e a “adiciona” à chave pública para criar uma nova chave pública. Isso pode ser replicado adicionando a raiz da árvore Merkle à chave privada para obter a chave privada correspondente para a nova chave pública. A ideia da Fiatjaf é encadear os compromissos indo do final para o início, de modo que cada chave ajustada contenha realmente uma prova de que a próxima chave ajustada foi usada para criá-la.
Então, imagine começar com a chave Z, a última da cadeia. Você ajustaria isso com alguma coisa e, em seguida, voltaria e criaria uma versão ajustada da chave Y usando a chave Z ajustada (Z’ + Y = Y’). A partir daqui, você pegaria Y’ e o usaria para ajustar X (Y’ + X = X’). Você faria isso de volta à chave A, para obter A’ e, a partir daí, começaria a usar essa chave. Quando está comprometido, o usuário pode transmitir um evento contendo a chave A não ajustada e a chave B’ ajustada. Isso conteria todos os dados necessários para mostrar que B’ foi usado para gerar A’, e os usuários poderiam parar imediatamente de seguir A’ e seguir B’. Eles saberiam definitivamente que B’ é a próxima chave desse usuário e deveriam segui-la.
Esta proposta ainda tem alguns problemas. Primeiro, você precisa gerar todas as chaves que usaria com antecedência e não há como alternar para um novo conjunto de chaves. Isso poderia ser resolvido comprometendo-se com uma chave mestra neste esquema que poderia autenticar tais rotações ou simplesmente gerando um conjunto muito grande de chaves desde o início. Qualquer um dos caminhos seria um curso válido a ser seguido, mas, em última análise, exigiria manter uma chave raiz ou material de chave seguro e expor apenas teclas de atalho individuais para clientes Nostr.
Este esquema, no entanto, não faz nada para proteger os usuários ou oferecer um mecanismo para recuperação de identidade no caso de o material da chave raiz ser perdido ou comprometido. Agora, isso não quer dizer que não haja benefício para o esquema de fiatjaf, com certeza há, mas é importante deixar claro que nenhuma solução resolve todos os problemas.
Para pontificar um pouco sobre possíveis soluções aqui, imagine, em vez de uma cadeia de chaves ajustadas como ele propõe, que uma chave seja ajustada com uma chave mestre fria que também deve ser usada para assinar o evento girando de uma chave para outra. Você tem a chave A’, que é derivada da adição de A e M (a chave mestra), e o evento de rotação seria A, M e B’ (gerado pela adição de B e M) com uma assinatura de M. M poderia ser um chave de limite multisig — dois de três, três de cinco, etc. Isso poderia potencialmente adicionar redundância contra perda, bem como fornecer um mecanismo seguro para rotação de chave. Isso também abre a porta para usar serviços para ajudar na recuperação ou espalhar algumas dessas chaves para amigos de confiança. Ele oferece a mesma flexibilidade que o multisig oferece com o próprio Bitcoin.
O NIP26 também é uma proposta que pode ser muito útil para lidar com esse problema. Isso especifica uma extensão de protocolo para eventos que permite a assinatura de uma chave para autorizar outra chave a postar eventos em seu nome. O “token”, ou prova de delegação de assinatura, seria então incluído em todos os eventos postados pela segunda chave pública em nome da primeira. Pode até ser limitado por tempo para que os tokens de delegação expirem automaticamente e precisem ser renovados.
Em última análise, seja como for resolvido, esse problema tem a ser resolvido para a Nostr a longo prazo. Um protocolo baseado inteiramente em pares de chaves públicas/privadas sendo usados como identidades não pode ganhar tração e adoção se a integridade dessas identidades não puder ser protegida e mantida para os usuários. Isso acabará se resumindo a ter que usar constantemente plataformas fora de banda e centralizadas para verificar novas chaves e coordenar as pessoas que seguem sua nova identidade quando algo é perdido ou comprometido e, nesse ponto, essas outras plataformas se tornam um meio de semear confusão. e se envolver em censura.
Questões de gerenciamento de chaves e segurança são grandes problemas com um espaço de design muito grande, cheio de compensações e pontos problemáticos, mas são problemas que terão que ser resolvidos no contexto do Nostr para que funcione. Em meu próximo artigo, resumirei alguns problemas que vejo surgindo em relação à arquitetura do servidor de retransmissão e problemas de dimensionamento que os desenvolvedores do Nostr terão que enfrentar, dadas as estruturas de dados básicas nas quais o Nostr é construído.
Para quem está lendo e se perguntando por que não mencionei identificadores descentralizados (DIDs): Sim, essa é uma solução potencial para esses problemas que, na minha opinião, é bastante abrangente. No entanto, os desenvolvedores Nostr parecem muito hesitantes em integrar DIDs no protocolo ou clientes devido ao fato de que isso criaria dependências externas fora do protocolo Nostr. Se você não está familiarizado com o funcionamento dos DIDs em nível técnico e está interessado, este artigo da Level 39 é um resumo muito bem escrito de como eles funcionam.
Este é um post de convidado por Shinobi. As opiniões expressas são inteiramente próprias e não refletem necessariamente as da BTC Inc ou da Bitcoin Magazine.
Fonte: bitcoinmagazine.com
