Novas soluções criptográficas, redes complementares, proteção de enclave e muito mais. Dê uma primeira olhada no Secret 2.0, uma evolução massiva de nossa arquitetura como um hub de privacidade para Web3!

Olá para a comunidade!

Hoje estou escrevendo para falar sobre o passado, presente e futuro da Secret Network — e para compartilhar alguns planos que até agora nunca foram compartilhados.

O ecossistema Secret sempre se orgulhou de nossa capacidade de iterar rapidamente e estar na vanguarda das tecnologias pragmáticas de preservação de privacidade que podem ser implantadas em produção. Sete anos atrás, fomos a primeira equipe a falar sobre privacidade para a Web3, quando publiquei meus whitepapers originais (incluindo “Decentralizing Privacy”, agora com mais de 2.000 citações e o artigo atualmente mais citado sobre privacidade no blockchain). Há mais de dois anos, a Secret se tornou o primeiro contrato inteligente L1 que preserva a privacidade, o que ainda é o caso até hoje.

Mas à medida que a Secret Network cresce, juntamente com a própria Web3, chegou a hora de pensarmos mais sobre nossa visão de privacidade e como garantir que estejamos sempre na vanguarda da pesquisa e do desenvolvimento. Nunca queremos ficar presos a um máximo local; em vez disso, queremos sempre ser líderes de mercado em soluções de privacidade Web3 que estejam ativas em produção. Sempre queremos impulsionar nossas soluções para serem mais seguras, com melhor desempenho, mais rápidas e com custo mais baixo — especialmente à medida que a adoção aumenta.

Referimo-nos a todo o desenvolvimento até este ponto como “Secret 1.0”: uma blockchain de Camada 1 ativa e um ecossistema relativamente maduro de aplicativos de preservação de privacidade em produção. Hoje falaremos sobre “Secret 2.0”: onde novas pesquisas e desenvolvimentos estão levando o ecossistema a seguir.

Um lançamento completo da visão coletiva da Secret 2.0 exigiria um whitepaper detalhado com tudo, desde minúcias técnicas até economia. Hoje não é esse lançamento. Mas neste post, gostaria de compartilhar algumas partes críticas de um roadmap para elevar as soluções de privacidade da Secret ainda outro nível:

1. Trazendo uma rede complementar — uma criptografia totalmente homomórfica (FHE) de limite de camada 1 que, juntamente com os enclaves, fornece a melhor solução de privacidade da categoria

2. Hardening SGX (e outros enclaves suportados) usando técnicas criptográficas e técnicas práticas de engenharia

Com essas melhorias, o futuro da Secret parece mais uma brilhante constelação de soluções de privacidade interconectadas do que uma única estrela. Vamos dar uma olhada nos dois caminhos estratégicos acima e como eles ajudarão a definir a Secret como o hub de privacidade para toda a Web3!

No final deste post, também incluiremos uma chamada à ação para pesquisadores, desenvolvedores e parceiros interessados ​​em contribuir para a Secret 2.0. Se você é um pesquisador independente, desenvolvedor ou equipe interessada em participar desse esforço, entre em contato com o SCRT Labs usando o e-mail: info@scrtlabs.com

Quer saber mais sobre onde a Secret já está hoje? Veja mais aqui.

https://scrt.network/

Criptografia totalmente homomórfica de limite para contratos secretos

Sempre afirmamos que a missão da Secret é trazer as soluções de privacidade mais pragmáticas e práticas para os sistemas de produção. A privacidade é muito importante para ser discutida apenas em um ambiente acadêmico — ela é necessária para os usuários de hoje. No entanto, estamos atentos a todos os novos avanços acadêmicos para entender quando e como novas soluções podem ser implantadas em produção para o benefício de desenvolvedores e usuários. A segurança é um espaço em constante evolução!

Já comentamos no passado que enclaves seguros eram (e realmente ainda são) a única tecnologia atualmente pronta para uso em uma rede de contrato inteligente generalizável. Os enclaves fornecem desempenho mais rápido por um custo menor em mais casos de uso. É por isso que nos concentramos em seu uso na Secret 1.0.

No entanto, sempre consideramos como a combinação de várias tecnologias pode levar a melhores soluções prontas para produção. Graças aos avanços recentes, agora estamos explorando a criptografia totalmente homomórfica (FHE) como uma opção séria para fortalecer a Secret como um hub de privacidade.

Uma nova rede complementar baseada em FHE (nome a ser revelado) está planejada para se parecer muito com a Secret, e atualmente estamos trabalhando em uma maneira interessante de interconectar as duas de maneira benéfica. Mas para os propósitos desta postagem no blog, gostaria de me concentrar no design técnico dessa cadeia e em como ela pode fornecer a solução mais segura para resolver o problema de privacidade.

A rede aproveitará a Criptografia Totalmente Homomórfica para privacidade, que é um esquema que permite calcular dados criptografados. Essencialmente, ele mantém a invariante de:

Os esquemas FHE melhoraram o desempenho aos trancos e barrancos nos últimos anos, e a tendência parece continuar. Por meio do uso de GPUs, FPGAs e, eventualmente, ASICs, podemos esperar um aumento de 1.000 a 10.000 vezes nos próximos anos. Os avanços são promissores e agora há boas razões para acreditar que o FHE pode se tornar escalável o suficiente em um prazo bastante curto.

Mas há um problema. O próprio FHE só pode funcionar com uma única chave, então como lidamos com um ambiente multiusuário como é o caso das blockchains? Precisamos essencialmente usar uma variante de computação multipartidária (MPC) de FHE chamada Threshold FHE. Como o nome sugere, o Threshold FHE permite que cada servidor execute qualquer computação sobre os dados criptografados, mas para descriptografar a saída, um certo limite de nós deve trabalhar em conjunto para descriptografar.

Então, como isso se encaixa em nossa rede de companheiros? Essencialmente, com um esquema Threshold FHE adequado, podemos fazer com que os validadores compartilhem a chave secreta de criptografia entre si. Isso pode ser alcançado facilmente com um protocolo DKG simples que é altamente eficiente. Usando o compartilhamento de segredo proativo móvel, podemos essencialmente mover compartilhamentos de validadores que saem para aqueles que entram. A parte “proativa” garantiria que qualquer invasor não pudesse corromper os validadores lentamente ao longo do tempo, pois exige que os validadores atualizem seus compartilhamentos da chave a cada determinado número de blocos.

Com essa configuração, enviar uma transação de contrato inteligente para a rede é bastante trivial:

1. O usuário envia uma transação chamando uma função em um contrato específico, enquanto criptografa todos os seus dados usando a chave pública da chave de rede compartilhada.

2. Todos os validadores executam o consenso como de costume, enquanto computam os dados criptografados. Isso é basicamente semelhante a como a Secret funciona hoje, exceto que a computação é feita diretamente nos dados criptografados sem descriptografá-los em um enclave.

3. Usando esse esquema, podemos obter privacidade de entrada, estado e saída, como na Secret hoje. (Para privacidade de saída, todos os validadores devem executar um protocolo de troca de chave que faça uma recriptografia de proxy de limite para alternar a saída para ser descriptografável com uma chave conhecida apenas pelo usuário.)

Uma observação importante a ser mencionada é que cada validador receberá uma parte da chave descriptografia de acordo com sua participação. Seria necessário 67% do poder de staking para descriptografar a rede. Este número está alinhado com o número de votos para aprovar um bloco, então faz sentido.

Um problema com esse design é que os validadores podem fazer conluio, e o conluio é trivial e indetectável (escreva algumas linhas de código que permitem aos validadores trocar os compartilhamentos de chave secreta fora da cadeia). Por esse motivo, acreditamos que para este trabalho precisaremos combinar essas técnicas criptográficas com SGX ou um TEE semelhante (idealmente vários TEEs usando várias arquiteturas). Ao fazer isso, aumentamos a barreira ao ataque — agora você precisa fazer com que todos os validadores conluiam, o que se torna extremamente improvável quando os TEEs são usados.

No entanto, também é importante observar que executar o FHE dentro de um enclave provavelmente é uma má ideia. Como mencionado, o dimensionamento do FHE dependerá do suporte de GPUs, FPGAs ou ASICs, que hoje não são compatíveis com enclaves. Felizmente, deve ser fácil ver que só precisamos da chave de descriptografia de limite em caso de troca de chave ou descriptografia de limite. Toda a computação criptografada real pode ocorrer fora do enclave, o que ajudaria muito no desempenho. Além disso, limitar os próprios enclaves para se concentrar no armazenamento de um compartilhamento de chave e na execução de um protocolo de descriptografia de chave/limite específico significa que seria muito mais fácil proteger esse enclave de possíveis ataques.

Endurecimento SGX e outros enclaves

A introdução de soluções criptográficas como FHE em nossa constelação de privacidade melhorará significativamente a oferta da Secret para desenvolvedores e usuários. No entanto, há muito mais que podemos fazer nesse meio tempo para fortalecer nossa rede existente — bem como melhorar sua flexibilidade futura. A maioria dessas ideias também busca combinar criptografia mais avançada com SGX, de uma forma que aproveite os benefícios dos enclaves seguros, mas não dependa apenas deles.

Limiar a chave mestra

Recentemente, escrevi um post no fórum que descrevia como podemos adaptar um artigo recente de Momeni et al., que aproveita a Criptografia Baseada em Identidade (IBE) com compartilhamento de segredo para distribuir a chave mestra secreta, que é a principal fonte de entropia usada para gerar chaves de criptografia para transações de usuários, criptografias de estado, aleatoriedade na cadeia, etc.

A ideia proposta essencialmente divide a chave mestra atual, que está presente em cada enclave (e, portanto, quebrar um único enclave seria suficiente para descriptografar todos os dados), em compartilhamentos da chave, de modo que seriam necessários os compartilhamentos de 67% do validadores para realmente serem capazes de aprender a chave. Como todos esses compartilhamentos também vivem em enclaves, o mesmo argumento da cadeia Threshold FHE acima permanece: a necessidade de quebrar os enclaves da maioria da rede provavelmente é impraticável em qualquer situação.

A chave mestra compartilhada secreta será usada para gerar uma chave derivada para cada bloco. O interessante é que os usuários podem gerar a priori e de forma independente a chave pública correspondente para cada bloco, mantendo assim a criptografia do lado do cliente das transações não interativas como é o caso hoje. Além disso, todos os validadores também podem gerar sua parte derivada da chave secreta de forma independente e, para cada bloco, anexar isso como parte do mecanismo de consenso. Isso significa que os enclaves aprendem a chave de um bloco específico bem a tempo de executar os cálculos, mas nunca aprendem a chave mestra!

Podemos usar a mesma técnica de compartilhamento de segredo proativo móvel da cadeia FHE para garantir que os compartilhamentos de chave mestra sejam atualizados periodicamente e movidos de validadores antigos para novos, para melhorar a segurança e a disponibilidade.

Encaminhar sigilo?

O esquema acima usa essencialmente criptografia homomórfica e computação multipartidária (MPC) para evitar um possível vazamento da chave mestra, mesmo em uma catástrofe SGX. Da mesma forma, protege melhor contra o conluio, ao qual todas as técnicas de MPC são vulneráveis, mantendo todos os seus compartilhamentos de chave em seu enclave.

Isso é ótimo, mas ainda há um grande desafio a ser enfrentado. Os validadores aprendem a chave de um bloco uma vez a cada bloco. Se um adversário estiver em um enclave comprometido, ele poderá coletar chaves e descriptografar blocos lentamente. Isso ainda é limitado em escopo se você assumir que há uma janela de tempo limitada entre poder comprometer um enclave e consertá-lo. Ao longo dos anos, à medida que os enclaves se tornam cada vez mais testados em batalha, eles devem se tornar raros e improváveis, mas ainda são uma forma de ataque. Talvez mais preocupante, um novo validador que está apenas começando e deseja processar todo o estado histórico pode instantaneamente pegar um enclave comprometido e aprender toda a história.

Essa preocupação precisa ser abordada com alguma forma de sigilo de encaminhamento para blockchains que preservam a privacidade e provavelmente é relevante se você estiver usando enclaves de soluções criptográficas puras que precisam armazenar chaves na rede. O sigilo de encaminhamento significa essencialmente que qualquer chave específica que vaze não deve revelar mais do que um pouco de informação (por exemplo, uma única transação ou um bloco de dados). Isso é até certo ponto alcançado pela minha proposta acima, mas também deve haver um mecanismo que limite a capacidade de recuperar todas as chaves de uma só vez.

Este é atualmente um tópico de pesquisa aberto que estamos analisando e estamos convidando outros pesquisadores para colaborar conosco! Ele potencialmente tem muitas outras implicações também.

Cálculos de duas partes

Secret 1.0 tem uma propriedade muito interessante e peculiar — ele pode armazenar e operar em dados privados enquanto, como qualquer blockchain, garante que está sempre executando o código do contrato corretamente. Além disso, como qualquer outra blockchain, está sempre online.

Isso apresenta um tipo de aplicativo realmente interessante, em particular para dados extremamente confidenciais, como carteira e chaves criptográficas, senhas e seeds, onde podemos não querer confiar totalmente no SGX sozinho — mas de maneira semelhante, os próprios usuários não gostariam de confiam em si mesmos para gerenciar adequadamente essas chaves.

O caso de uso atual mais interessante e útil que vemos para isso é o de carteiras de limite imparáveis, mas isso deve servir apenas como exemplo. Essas carteiras basicamente dividem a chave da carteira entre um usuário e a Secret — cada um recebe um compartilhamento. Na Secret, um usuário pode definir uma política de acesso, de modo que, se sua chave estiver comprometida, a cadeia notará um comportamento suspeito (por exemplo, alguém tentando drenar sua carteira) e a bloqueará. Por outro lado, é bastante razoável supor que nenhum invasor será capaz de comprometer tanto o compartilhamento armazenado na rede quanto o compartilhamento da carteira do usuário, especialmente se continuarmos a usar técnicas como compartilhamento proativo de segredos que atualizam os compartilhamentos de tempos em tempos muitas vezes.

Para habilitar essa técnica, precisaríamos adicionar suporte e construir vários blocos de construção na Secret, como criptografia aditiva homomórfica e protocolos de assinatura de limite. Precisaremos adaptá-los para funcionar sem serem compilados no WASM para problemas de desempenho/custo de gás (semelhante ao que o Ethereum fez no passado com a verificação on-chain de certas provas de conhecimento zero). Um desses pilotos está atualmente planejado com um parceiro de design.

Isso deve ilustrar uma classe muito maior de cálculos de duas partes, em que o material confidencial de um usuário é dividido entre o próprio usuário e a Secret.

O que agora?

Aqui vou reafirmar o que sempre fez parte de nossa missão como Secret Network: trazer soluções pragmáticas de privacidade ao mercado para que possam ser usadas em produção por milhões de usuários globais.

O ecossistema Secret — desde seus principais desenvolvedores até seus validadores, seus dApps e seus usuários apaixonados — provou que faremos tudo o que for necessário para garantir que nossa visão de um futuro Web3 mais seguro se torne realidade. Isso significou construir e usar aplicativos que estão na vanguarda do nosso setor nos últimos anos. Agora estamos pedindo que você se junte a nós enquanto fortalecemos nossa rede desde sua primeira iteração até sua próxima forma mais poderosa: uma constelação de soluções de privacidade interconectadas que tornam a base coletiva cada vez mais forte.

Há muitos outros tópicos que poderíamos ter abordado neste post, incluindo dimensionamento vertical por meio de rollups, dimensionamento horizontal por meio de IBC e muito mais. Esta é apenas uma primeira olhada na Secret 2.0, que será um empreendimento altamente complexo que inclui um esforço substancial da comunidade.

Hoje temos dezenas de dApps privados por padrão ativos aproveitando a Secret Network; em poucos anos, pretendemos ter milhares. Hoje temos 250.000 contas na Secret; pretendemos adicionar muitos milhões a mais. Ao combinar essas melhorias técnicas com uma abordagem agressiva para o crescimento de desenvolvedores e usuários, podemos garantir que todos os usuários da Web3 tenham acesso a soluções de privacidade robustas.

Uma internet mais descentralizada exige que a privacidade seja verdadeiramente empoderadora. De forma semelhante, as soluções de privacidade exigirão que a descentralização seja sustentável. A Secret Network é onde a descentralização e a privacidade se cruzam — fornecendo a base certa para os usuários agora e no futuro.

Entrar em contato

Muito do que é proposto acima já é uma área ativa de pesquisa e desenvolvimento, mas estamos constantemente procurando os melhores parceiros enquanto continuamos perseguindo esse objetivo de adoção global. Se você é um pesquisador independente, desenvolvedor ou equipe interessada em participar desse esforço ou em uma joint venture, entre em contato com a SCRT Labs usando o e-mail: info@scrtlabs.com

https://scrtlabs.com/

A Secret Network também tem subsídios e outros recursos disponíveis para desenvolvedores que desejam contribuir com nossa missão de privacidade. Se você estiver interessado em criar seus próprios aplicativos secretos, confira nossos recursos para desenvolvedores e saiba como obter financiamento para apoiar seus projetos!

https://scrt.network/developers

Se você é alguém apaixonado por garantir que os usuários da web3 tenham as proteções de privacidade de dados que eles precisam e merecem, torne-se um Agente Secreto! É nossa missão garantir que a web descentralizada que estamos construindo seja realmente capacitada — e acessível a todos. Da conscientização e educação ao crescimento internacional e relações universitárias, há muitas maneiras de ajudar a expandir o ecossistema Secret e a disponibilidade global de tecnologias de privacidade na web3.

Confira o programa Agentes Secretos e junte-se a uma das melhores e mais comprometidas comunidades em todo o espaço blockchain!

https://scrt.network/agents

Avante e para cima!

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