A Secret Network traz privacidade nativa para contratos inteligentes. Com chaves de visualização e permissões, os usuários recebem recursos de controle de acesso em seus dados, ativos e NFTs. Qual a diferença entre os dois temas?

Ao permitir que os desenvolvedores criem aplicativos que preservam a privacidade e capacitam os usuários a assumir o controle de seus dados, a Secret Network pode oferecer o que nenhuma blockchain pública por padrão pode: controle de acesso nativo.

Atualmente, existem duas implementações de design técnico para obter controle de acesso: visualização de chaves e permissões de consulta. Veremos essas especificações mais de perto e como as duas diferem uma da outra.

Viewing Keys — Visualização de chaves: os problemas que elas resolvem e criam

A Secret Network criptografa os dados do usuário por padrão. Quando um usuário converte ativos públicos como ETH, BNB e SCRT em seu equivalente privado (sETH, sBNB, sSCRT), metadados, como saldos, ficam ocultos de todos os usuários na rede, incluindo o usuário que possui esses ativos. Portanto, apesar do benefício adicional à segurança, a criptografia cria um problema de experiência do usuário.

Como nossos usuários devem interagir com aplicativos na rede se não puderem ver a quantidade de tokens em suas carteiras?

Os tokens secretos (também conhecidos como tokens compatíveis com SNIP) são criados com base nos padrões existentes do ecossistema Cosmos. Portanto, a identidade de um consultador (alguém solicitando dados) não pode ser autenticada criptograficamente. Em outras palavras, sem um mecanismo para verificar a identidade de um usuário, as informações básicas do usuário não podem ser descriptografadas. Para resolver este problema, as chaves de visualização foram implementadas como parte da especificação SNIP-20.

Criando chaves de visualização (esquerda) e consultando com chaves de visualização (direita)

Observando o diagrama acima, podemos ver o caso de uso típico de uma chave de visualização.

1. Alice não pode ver seu saldo, então ela cria uma chave de visualização (senha) para um token SNIP específico.

2. O contrato inteligente responsável por gerenciar o token SNIP salva Alice e sua senha no estado atual do contrato.

3. Em outro momento, qualquer pessoa, como Bob, pode solicitar para ver o saldo de Alice. Se Bob recebeu permissão para usar a chave de visualização de Alice, ele receberá o saldo da conta dela do contrato inteligente com sucesso.

As chaves de visualização funcionam como senhas criptografadas. Ao permitir que os usuários criem e compartilhem essas senhas com aplicativos de terceiros, as chaves de visualização destacam a qualidade do controle de acesso fornecido aos usuários na Secret Network. Alice é a proprietária de suas chaves de visualização e, sem elas, outras pessoas não podem acessar seus dados confidenciais.

Infelizmente, as chaves de visualização contribuem para um atrito significativo em relação à experiência geral do usuário na rede e criam um caminho para o surgimento de problemas técnicos durante períodos de alto tráfego. Dados cruciais da conta sendo ocultados dos usuários sem a visualização de chaves é um recurso que, na melhor das hipóteses, confunde temporariamente os novos usuários e, na pior das hipóteses, atua como um impedimento para a adoção da rede. Como as chaves de visualização são armazenadas no estado de um contrato inteligente, os usuários devem enviar uma transação e pagar uma pequena taxa para cobrir o custo do gás para criar essas senhas criptografadas. Portanto, ao usar as chaves de visualização, há um pequeno custo inicial para novos usuários que podem simplesmente querer ver o saldo da conta. No caso de pontes de ativos públicos, como BNB (Binance Coin), esse problema de UX é amplificado pelo fato de que novos usuários provavelmente não terão SCRT para cobrir o custo do gás. Sem SCRT para pagar pelo gás, uma transação nunca pode ser enviada, uma chave de visualização não pode ser criada e o usuário não pode visualizar seu saldo de sBNB privado recém-conectado.

Além disso, em tempos de tráfego intenso, a criação de muitas teclas de visualização, às vezes desnecessárias, em rápida sucessão provou sobrecarregar a rede. Por exemplo, a primeira coleção NFT privada por padrão na Rede Secret, Anons, gerou um uso significativo para a rede. Os usuários, com medo de perder a moeda pública, correram para o site dos Anons para garantir seus NFTs. O processo de mintagem para Anons guiou os usuários ao longo de um caminho de UX que exigia que os usuários criassem chaves de visualização antes de mintarem. Devido à natureza de um NFT mint onde o tempo é sensível e os tokens são escassos, uma grande quantidade de usuários interagiu com o contrato inteligente Anons para criar chaves de visualização, uma enxurrada de transações foi gerada, o que por sua vez levou à interrupção da rede e um lançamento atrasado para o projeto Anons.

Os muito procurados Anons listados no Stassh Marketplace

À medida que a rede está entupida de solicitações, os nós começam a ficar fora de sincronia e as transações começam a falhar. Os usuários que recebem solicitações com falha provavelmente responderão enviando mais solicitações apenas para agravar o problema. Portanto, para resolver esses desafios técnicos e de UX, um novo método de consulta de dados privados de usuários foi implementado.

Para resumir, os principais desafios associados à visualização de chaves são:

1. A visualização de chaves exige que os novos usuários paguem uma taxa única e antecipada por informações básicas da conta, como saldos, históricos de transações etc.

2. Em tempos de alto tráfego, a UI/UX construída em torno de chaves de visualização pode levar à criação de muitas transações desnecessárias que podem diminuir o desempenho do nó, resultando em problemas em cascata para a rede.

Query Permits — Permissões de consulta: o método de consulta alternativo

As permissões de consulta foram introduzidas na especificação de projeto SNIP-24. A documentação descreve as permissões como um método de consulta superior quando comparado à visualização de chaves. Ao considerar o exemplo anterior de Alice, uma usuária que deseja verificar o saldo de sua conta privada, podemos entender melhor como as permissões funcionam e por que elas são uma melhoria drástica para os usuários da Secret.

A consulta permite o uso de uma técnica criptográfica conhecida como criptografia de chave pública acoplada a assinaturas digitais. Uma permissão é uma mensagem formatada. Ele descreve vários argumentos, como a quais tokens a permissão se aplica e quais permissões a permissão deve permitir (por exemplo, a permissão deve permitir que o consultador visualize o histórico de transações de um usuário, saldo etc.). Esta mensagem é assinada por Alice usando a chave privada de sua conta. Quando Alice envia uma consulta, ela envia sua permissão assinada como argumento para um contrato inteligente. Uma vez recebido, o contrato inteligente, usando a chave pública de Alice, pode validar sua identidade com base na assinatura que ela forneceu. Se a identidade de Alice for confirmada, o contrato inteligente retornará seus dados conforme solicitado.

Observe que, diferentemente das chaves de visualização, o contrato inteligente nunca muda seu estado para salvar a identidade de Alice. Portanto, não há transação associada ao uso de permissões de consulta e não há taxa para solicitar informações básicas do usuário. Esta é uma grande melhoria de UX para os usuários finais. Além disso, como não há transação associada a permissões de consulta, não há risco de as permissões prejudicarem o desempenho da rede durante períodos de alto tráfego.

Embora as licenças melhorem significativamente a experiência do usuário, elas vêm com uma compensação. As permissões de consulta consomem mais recursos em nós que executam a rede. Como a identidade de um usuário nunca é salva, uma permissão sempre deve ser validada a cada solicitação de consulta. Esse processo é mais caro em termos de poder de computação quando comparado à visualização de chaves, que exigem apenas uma verificação básica em relação aos dados armazenados no estado de um contrato inteligente. No entanto, a melhoria geral na experiência do usuário e na estabilidade da rede vale a pressão adicional colocada nos nós para validar as permissões.

Projetando para a experiência do usuário

Devido à novidade das permissões de consulta, os aplicativos descentralizados criados na Secret Network os utilizaram em vários graus de sucesso. Se usadas incorretamente, as permissões podem criar uma UX mais friccional do que as chaves de visualização, por isso é vital que os desenvolvedores considerem o impacto que as permissões de consulta têm no design da interface do usuário e da experiência do usuário. Esta seção tem como objetivo fornecer um pequeno conjunto de recomendações para os desenvolvedores seguirem ao usar permissões de consulta.

As permissões de consulta devem ser armazenadas

As permissões são mensagens efêmeras que devem ser passadas para um contrato inteligente sempre que uma consulta é feita. Forçar um usuário a gerar novamente uma permissão com cada consulta é sem dúvida uma experiência de usuário pior do que pagar uma taxa única para criar uma chave de visualização. Portanto, após a criação de uma permissão, ela deve ser salva no navegador (por exemplo, em localStorage), para que possa ser reutilizada posteriormente. Se as permissões forem salvas, os desenvolvedores podem fornecer uma experiência perfeita para os usuários enviando consultas futuras sem que o usuário final perceba que uma solicitação foi feita.

As licenças armazenadas devem ser usadas para sempre ou até que sejam revogadas.

Para reiterar, não há necessidade de recriar uma licença depois de gerada. Fornecer aos usuários uma maneira simples de revogar permissões deve ser integrado à interface de usuário de um aplicativo. As permissões podem ser revogadas enviando uma mensagem de revogação cujo único parâmetro é o nome da permissão a ser revogada.

As permissões de consulta podem ser aplicadas a vários tokens secretos

Em vez de forçar um usuário a criar uma nova permissão para cada token secreto que seu aplicativo pode usar, é melhor permitir que vários tokens sejam usados ​​sob a mesma permissão. Mais tokens podem ser especificados na matriz allowed_tokens da mensagem de permissão. Os desenvolvedores devem considerar o domínio de seu aplicativo e permitir vários tokens de acordo.

Seguindo essas diretrizes simples para permissões de consulta, os desenvolvedores podem fornecer uma experiência de usuário definitivamente melhor para seus aplicativos na Secret Network. Para mais detalhes sobre permissões e sua implementação, dê uma olhada na documentação do SNIP-24 encontrada no Secret Foundation GitHub.

Conclusão

A Secret Network é uma solução blockchain de camada 1 que combina a resiliência da privacidade e a revolução dos contratos inteligentes escaláveis. As soluções de segurança geralmente vêm à custa da experiência do usuário. Os desenvolvedores da Secret Network assumem uma postura ativa na liberação de novos usuários para que todos possam acessar o financiamento privado descentralizado com facilidade. A visualização de chaves foi a primeira implementação de controle de acesso para usuários finais, mas teve um custo, tanto para a experiência do usuário quanto para a estabilidade da rede. As permissões de consulta são uma melhoria dos tokens de preservação de privacidade da Secret Network. À medida que os desenvolvedores criam novos aplicativos e refatoram as ferramentas existentes de acordo com esse novo padrão, os usuários finais poderão explorar o ecossistema com a mesma facilidade que fariam em uma cadeia pública por padrão. Ao proteger os dados do usuário e fornecer aos usuários ferramentas simples de controle de acesso, como chaves de visualização e permissões, a Secret Network dá um passo adiante em direção a um futuro em que a privacidade está na vanguarda do movimento Web3.

Dúvidas e caso queira se envolver no projeto da Secret Network, junte-se a nossas redes:

Telegram Secret em português: https://t.me/secret_portuguese

Canal Youtube Secret Network em português: https://www.youtube.com/c/SecretNetworkHubPTBR

Twitter Secret português: https://twitter.com/scrt_portuguese

Instagram: https://www.instagram.com/secretportuguese/

Discord: https://discord.gg/Ug5yx3MN