Como uma plataforma blockchain aberta e programável, a Ethereum não é apenas a infraestrutura da moeda digital, mas também fornece aos desenvolvedores um ambiente para criar aplicativos descentralizados (DAPP) e contratos inteligentes. Devido à sua flexibilidade e escalabilidade, o Ethereum se tornou um participante importante no ecossistema de criptomoedas e atraiu desenvolvedores e usuários em todo o mundo.
No conteúdo da última edição da Cregis Research, discutimos o valor da abstração de contas (AA), então estendemos um tópico complicado: em junho, V God, o fundador do Ethereum, apontou em seu blog que o Ethereum está enfrentando atualmente alguns desafios e problemas importantes, esses problemas precisam ser resolvidos para promover o desenvolvimento do Ethereum, caso contrário, o Ethereum falhará, então as três direções de transformação são: carteira de contrato inteligente, proteção de privacidade e expansão da Camada 2. Após uma transformação bem-sucedida, o Ethereum melhorará em termos de desempenho, experiência do usuário e proteção de privacidade.
Claro, essas mudanças também trazem novos desafios. Os problemas e a importância das carteiras de contrato inteligente (CA) foram analisados claramente na edição anterior. A Cregis Research resumiu algumas das questões restantes e selecionou alguns pontos-chave que estão intimamente relacionados à sua experiência diária e revisitou o ponto de vista de V God há meio mês.
Novos problemas trazidos pelas três transformações do Ethereum
2. Por que o Ethereum deve mudar?
A principal razão pela qual o Ethereum precisa mudar decorre dos desafios de escalabilidade, segurança e proteção da privacidade.
Em primeiro lugar, vamos revisar a discussão na última edição da Cregis Research: Cregis Research: The Archaeology of Ethereum Account Structure and the Value of Account Abstraction, que mencionou: Ethereum rodando em um ambiente descentralizado ainda enfrenta o maior ponto problemático: linear ambiente É impossível realizar transações de alta simultaneidade e compilação de código complexo, o que é um desafio de escalabilidade.
Devido à atual capacidade limitada de processamento de transações da Ethereum, os custos de transação podem se tornar altos quando o tráfego de rede aumenta. Esse alto custo de transação dificulta a popularização do Ethereum no mercado convencional, portanto, o Ethereum precisa aumentar sua capacidade de processamento e reduzir os custos de transação por meio da expansão L2, como rollups.
Em segundo lugar, a segurança da carteira também é uma questão importante. As carteiras EOA (representadas por várias carteiras plug-in) que geram pares de chaves públicas-privadas puramente por meio de frases iniciais estão sendo roubadas em um fluxo interminável. hackers, os usuários individuais têm demandas cada vez mais intensificadas por segurança de ativos. , e ao mesmo tempo não estão dispostos a sacrificar a experiência do usuário (usuários corporativos escolherão uma solução MPC totalmente auto-hospedada para segurança de ativos e estão dispostos a sacrificar a conveniência de rede on-chain interação), o que requer que a Ethereum altere a segurança da carteira e promova carteiras de contratos inteligentes.
Finalmente, a proteção da privacidade é outro desafio importante. Todas as transações no Ethereum L1 são públicas porque o EOA está vinculado a ativos; sejam usuários individuais comuns, baleias gigantes ou instituições corporativas, eles podem sofrer atualmente com a angústia de endereços de ativos sendo marcados e rastreados. Portanto, o Ethereum precisa ser aprimorado ainda mais para implementar cálculos de privacidade não maliciosos para garantir que não apenas os ativos na cadeia, mas também as informações DID, como identidades e sistemas de crédito na cadeia, possam ser protegidos no futuro; O mecanismo de enfrentamento pode garantir que os perpetradores não podem escapar do rastreamento e sacar sem problemas.
Três, as 3 perguntas mais importantes (comentários resumidos e adicionados pela Cregis Research)
Como os usuários gerenciam vários endereços de carteira
Comparada com a Web 3.0, a Web 2.0 tem a mesma vantagem que ainda mantém: os usuários podem usar um recurso social (endereço de e-mail, número de celular, etc.) o mesmo mecanismo de consenso pode ser usado (por exemplo: BSC, ERC-20, TRC-20), mas com o advento do plano de expansão L 2, os usuários terão vários endereços L 2 completamente diferentes e camadas 1 e 2 diferentes as redes podem usar diferentes linguagens de programação e componentes intermediários, o que leva a problemas na reserva de endereço; e antes do ambiente multi-chain bridging representado por Polkadot ou o ambiente multi-chain de propósito geral L 2 mencionado na visão futura do Cregis, os usuários também podem precisam gerenciar vários endereços de cadeias heterogêneas, o que aumenta a complexidade do gerenciamento de endereços.
Por fim, a proposta de endereços furtivos para proteção da privacidade, se amplamente utilizada, permitirá que os usuários tenham mais endereços para aumentar a proteção de sua privacidade. Portanto, torna-se mais difícil reservar um endereço.
Como os usuários percebem o pagamento invisível? (especialmente em um ambiente multi-endereço)
Supondo que o L2 no ecossistema Ethereum se desenvolva conforme o esperado no futuro, mesmo que a maioria dos ativos nativos sejam tokens ERC-20, os usuários podem ter vários endereços L2, e escolher o endereço correto para enviar ativos ou pagar torna-se mais complicado. Tradicionalmente, os usuários só precisavam saber o endereço da outra parte para enviar um pagamento, mas agora eles precisam saber a rede da Camada 2 e o endereço correspondente aceito pela outra parte, e etapas adicionais são necessárias para garantir que os fundos sejam enviados para o endereço correto destino.
Problema de pagamento furtivo de várias contas no ambiente L 2
Embora a conta de contrato (CA) construída usando contratos inteligentes possa resolver facilmente o problema de endereçamento, ela não pode fornecer diretamente a função de proteção de privacidade.
Vitalik propôs uma solução de proteção de privacidade nos primeiros dias do Ethereum: endereço furtivo. Os endereços furtivos podem ajudá-lo a manter a privacidade ao realizar transações em moeda digital sem serem rastreados por outras pessoas. A seguir, o Cregis compartilhará algumas etapas para resolver problemas de privacidade:
(Fluxo de trabalho completo de endereço furtivo)
Um endereço furtivo é um endereço que pode ser gerado pelo remetente ou pelo beneficiário, mas controlado apenas pelo beneficiário. Esse tipo de endereço pode melhorar a privacidade do Ethereum em vários cenários. Nesse modo, Bob (o beneficiário) gera uma chave de consumo e usa essa chave para gerar um meta-endereço invisível: B, h = hash(x). Ele passa esse metaendereço para Alice (a pagadora). Alice pode realizar uma computação neste meta-endereço, gerando o endereço furtivo pertencente a Alice para Bob: b-1. Ela pode enviar quaisquer ativos que desejar para esse endereço e Bob terá controle total sobre eles.
O processo de geração do endereço furtivo precisa operar a função de curva elíptica: Bob gera uma chave m e calcula M = G * m, onde G é um ponto público de geração da curva elíptica. Alice gera uma chave temporária r e publica a chave pública temporária R = G * r. Alice pode calcular um segredo compartilhado S = M * r e Bob pode calcular o mesmo segredo compartilhado S = m * R.
Após o endereço furtivo de Bob: b-1 é gerado, quando é necessário negociar com Alice, Alice gera um valor: c, e publica um dado criptografado de c que somente Bob pode descriptografar; quando a transação é executada, ela é verificada por prova de conhecimento zero: Bob fornece O valor x fornecido por Alice e o valor c fornecido por Alice pode fazer k=hash(hash(x), c), e a transação é concluída após a verificação estar correta. Como o endereço original de Bob não é exposto durante esse processo, e apenas o valor criptografado x é fornecido, a prova de conhecimento zero é responsável apenas por verificar o conteúdo de k e não mostrará a relação entre B e b-1.
Como o produto de carteira protege os ativos e a privacidade do usuário ao mesmo tempo?
Em um ambiente on-chain tradicional, as carteiras se preocupam principalmente com a proteção de chaves privadas, mas em um mundo ZKP (Zero-Knowledge Proof), as carteiras precisam proteger as credenciais de autenticação e os dados do usuário. Um exemplo é o ZKpass, um sistema de identidade baseado em ZK-SNARK e MPC, que permite aos usuários gerar provas básicas para verificação de identidade, e ao mesmo tempo faz o processo de verificação de identidade sem apresentar nenhuma informação real através do MPC.
No entanto, como a própria tag de dados criptografados (estilhaço de chave) substitui a chave privada do EOA, a custódia da tag de dados criptografados se torna mais problemática, pois os usuários precisam fazer uma troca entre manter os dados localmente ou confiar em terceiros para manter uma cópia criptografada. Ao mesmo tempo, as carteiras que oferecem suporte à recuperação social precisam gerenciar a recuperação de ativos e a recuperação da chave de criptografia para garantir um equilíbrio entre segurança e usabilidade. Portanto, no futuro previsível, as estratégias de segurança das carteiras de nível empresarial e carteiras pessoais terão direções completamente diferentes. Tomando as carteiras de nível empresarial como exemplo, os usuários de carteiras de nível empresarial precisam do ambiente de segurança mais rigoroso para proteger os fundos. é uma alta probabilidade de abandono: 1. Carteiras contratuais que podem ter vulnerabilidades humanas; 2. Carteiras MPC de custódia mista com riscos de terceiros, escolha carteiras MPC privatizadas com o mesmo nível de segurança das carteiras de hardware; Em alguns cenários, porque você sempre quer para obter a melhor experiência do usuário, você pode escolher um produto com algumas operações centralizadas.
Além disso, o endereço blockchain não atende aos requisitos de verificação de identidade na ecologia, então as soluções de ENS (blockchain domain name) e SBT (soul binding token) são gradualmente aceitas pelo público, mas ainda existem problemas que não foram resolvido: o primeiro é difícil resolver o problema de nomes duplicados trazido pelo mundo tradicional. Embora o último não tenha o problema de nomes duplicados, não há aplicações ecológicas suficientes para utilizar plenamente as funções DID realizadas por ele, e mesmo os cenários de aplicação atuais podem ser considerados muito finos.
4. Resumo
Acredito que todos já entendem que a carteira é apenas uma parte importante do tópico [Transformação do Ethereum] que está em alta no círculo monetário global há quase 3 meses. A ambição de V God não é apenas realizar a ambição de "Ethereum complementa os defeitos do Bitcoin", mas também espera que Ethereum possa realmente criar um mundo em que todos possam entrar, altamente conectado com o mundo real e retenha o conceito de descentralização.
Ver original
O conteúdo é apenas para referência, não uma solicitação ou oferta. Nenhum aconselhamento fiscal, de investimento ou jurídico é fornecido. Consulte a isenção de responsabilidade para obter mais informações sobre riscos.
Observação da pesquisa da Cregis: novos problemas causados por três transformações do Ethereum
I. Introdução
No conteúdo da última edição da Cregis Research, discutimos o valor da abstração de contas (AA), então estendemos um tópico complicado: em junho, V God, o fundador do Ethereum, apontou em seu blog que o Ethereum está enfrentando atualmente alguns desafios e problemas importantes, esses problemas precisam ser resolvidos para promover o desenvolvimento do Ethereum, caso contrário, o Ethereum falhará, então as três direções de transformação são: carteira de contrato inteligente, proteção de privacidade e expansão da Camada 2. Após uma transformação bem-sucedida, o Ethereum melhorará em termos de desempenho, experiência do usuário e proteção de privacidade.
Claro, essas mudanças também trazem novos desafios. Os problemas e a importância das carteiras de contrato inteligente (CA) foram analisados claramente na edição anterior. A Cregis Research resumiu algumas das questões restantes e selecionou alguns pontos-chave que estão intimamente relacionados à sua experiência diária e revisitou o ponto de vista de V God há meio mês.
Novos problemas trazidos pelas três transformações do Ethereum
2. Por que o Ethereum deve mudar?
A principal razão pela qual o Ethereum precisa mudar decorre dos desafios de escalabilidade, segurança e proteção da privacidade.
Em primeiro lugar, vamos revisar a discussão na última edição da Cregis Research: Cregis Research: The Archaeology of Ethereum Account Structure and the Value of Account Abstraction, que mencionou: Ethereum rodando em um ambiente descentralizado ainda enfrenta o maior ponto problemático: linear ambiente É impossível realizar transações de alta simultaneidade e compilação de código complexo, o que é um desafio de escalabilidade.
Devido à atual capacidade limitada de processamento de transações da Ethereum, os custos de transação podem se tornar altos quando o tráfego de rede aumenta. Esse alto custo de transação dificulta a popularização do Ethereum no mercado convencional, portanto, o Ethereum precisa aumentar sua capacidade de processamento e reduzir os custos de transação por meio da expansão L2, como rollups.
Em segundo lugar, a segurança da carteira também é uma questão importante. As carteiras EOA (representadas por várias carteiras plug-in) que geram pares de chaves públicas-privadas puramente por meio de frases iniciais estão sendo roubadas em um fluxo interminável. hackers, os usuários individuais têm demandas cada vez mais intensificadas por segurança de ativos. , e ao mesmo tempo não estão dispostos a sacrificar a experiência do usuário (usuários corporativos escolherão uma solução MPC totalmente auto-hospedada para segurança de ativos e estão dispostos a sacrificar a conveniência de rede on-chain interação), o que requer que a Ethereum altere a segurança da carteira e promova carteiras de contratos inteligentes.
Finalmente, a proteção da privacidade é outro desafio importante. Todas as transações no Ethereum L1 são públicas porque o EOA está vinculado a ativos; sejam usuários individuais comuns, baleias gigantes ou instituições corporativas, eles podem sofrer atualmente com a angústia de endereços de ativos sendo marcados e rastreados. Portanto, o Ethereum precisa ser aprimorado ainda mais para implementar cálculos de privacidade não maliciosos para garantir que não apenas os ativos na cadeia, mas também as informações DID, como identidades e sistemas de crédito na cadeia, possam ser protegidos no futuro; O mecanismo de enfrentamento pode garantir que os perpetradores não podem escapar do rastreamento e sacar sem problemas.
Três, as 3 perguntas mais importantes (comentários resumidos e adicionados pela Cregis Research)
Como os usuários gerenciam vários endereços de carteira
Comparada com a Web 3.0, a Web 2.0 tem a mesma vantagem que ainda mantém: os usuários podem usar um recurso social (endereço de e-mail, número de celular, etc.) o mesmo mecanismo de consenso pode ser usado (por exemplo: BSC, ERC-20, TRC-20), mas com o advento do plano de expansão L 2, os usuários terão vários endereços L 2 completamente diferentes e camadas 1 e 2 diferentes as redes podem usar diferentes linguagens de programação e componentes intermediários, o que leva a problemas na reserva de endereço; e antes do ambiente multi-chain bridging representado por Polkadot ou o ambiente multi-chain de propósito geral L 2 mencionado na visão futura do Cregis, os usuários também podem precisam gerenciar vários endereços de cadeias heterogêneas, o que aumenta a complexidade do gerenciamento de endereços.
Por fim, a proposta de endereços furtivos para proteção da privacidade, se amplamente utilizada, permitirá que os usuários tenham mais endereços para aumentar a proteção de sua privacidade. Portanto, torna-se mais difícil reservar um endereço.
Como os usuários percebem o pagamento invisível? (especialmente em um ambiente multi-endereço)
Supondo que o L2 no ecossistema Ethereum se desenvolva conforme o esperado no futuro, mesmo que a maioria dos ativos nativos sejam tokens ERC-20, os usuários podem ter vários endereços L2, e escolher o endereço correto para enviar ativos ou pagar torna-se mais complicado. Tradicionalmente, os usuários só precisavam saber o endereço da outra parte para enviar um pagamento, mas agora eles precisam saber a rede da Camada 2 e o endereço correspondente aceito pela outra parte, e etapas adicionais são necessárias para garantir que os fundos sejam enviados para o endereço correto destino.
Problema de pagamento furtivo de várias contas no ambiente L 2
Embora a conta de contrato (CA) construída usando contratos inteligentes possa resolver facilmente o problema de endereçamento, ela não pode fornecer diretamente a função de proteção de privacidade.
Vitalik propôs uma solução de proteção de privacidade nos primeiros dias do Ethereum: endereço furtivo. Os endereços furtivos podem ajudá-lo a manter a privacidade ao realizar transações em moeda digital sem serem rastreados por outras pessoas. A seguir, o Cregis compartilhará algumas etapas para resolver problemas de privacidade:
(Fluxo de trabalho completo de endereço furtivo)
Um endereço furtivo é um endereço que pode ser gerado pelo remetente ou pelo beneficiário, mas controlado apenas pelo beneficiário. Esse tipo de endereço pode melhorar a privacidade do Ethereum em vários cenários. Nesse modo, Bob (o beneficiário) gera uma chave de consumo e usa essa chave para gerar um meta-endereço invisível: B, h = hash(x). Ele passa esse metaendereço para Alice (a pagadora). Alice pode realizar uma computação neste meta-endereço, gerando o endereço furtivo pertencente a Alice para Bob: b-1. Ela pode enviar quaisquer ativos que desejar para esse endereço e Bob terá controle total sobre eles.
O processo de geração do endereço furtivo precisa operar a função de curva elíptica: Bob gera uma chave m e calcula M = G * m, onde G é um ponto público de geração da curva elíptica. Alice gera uma chave temporária r e publica a chave pública temporária R = G * r. Alice pode calcular um segredo compartilhado S = M * r e Bob pode calcular o mesmo segredo compartilhado S = m * R.
Após o endereço furtivo de Bob: b-1 é gerado, quando é necessário negociar com Alice, Alice gera um valor: c, e publica um dado criptografado de c que somente Bob pode descriptografar; quando a transação é executada, ela é verificada por prova de conhecimento zero: Bob fornece O valor x fornecido por Alice e o valor c fornecido por Alice pode fazer k=hash(hash(x), c), e a transação é concluída após a verificação estar correta. Como o endereço original de Bob não é exposto durante esse processo, e apenas o valor criptografado x é fornecido, a prova de conhecimento zero é responsável apenas por verificar o conteúdo de k e não mostrará a relação entre B e b-1.
Como o produto de carteira protege os ativos e a privacidade do usuário ao mesmo tempo?
Em um ambiente on-chain tradicional, as carteiras se preocupam principalmente com a proteção de chaves privadas, mas em um mundo ZKP (Zero-Knowledge Proof), as carteiras precisam proteger as credenciais de autenticação e os dados do usuário. Um exemplo é o ZKpass, um sistema de identidade baseado em ZK-SNARK e MPC, que permite aos usuários gerar provas básicas para verificação de identidade, e ao mesmo tempo faz o processo de verificação de identidade sem apresentar nenhuma informação real através do MPC.
No entanto, como a própria tag de dados criptografados (estilhaço de chave) substitui a chave privada do EOA, a custódia da tag de dados criptografados se torna mais problemática, pois os usuários precisam fazer uma troca entre manter os dados localmente ou confiar em terceiros para manter uma cópia criptografada. Ao mesmo tempo, as carteiras que oferecem suporte à recuperação social precisam gerenciar a recuperação de ativos e a recuperação da chave de criptografia para garantir um equilíbrio entre segurança e usabilidade. Portanto, no futuro previsível, as estratégias de segurança das carteiras de nível empresarial e carteiras pessoais terão direções completamente diferentes. Tomando as carteiras de nível empresarial como exemplo, os usuários de carteiras de nível empresarial precisam do ambiente de segurança mais rigoroso para proteger os fundos. é uma alta probabilidade de abandono: 1. Carteiras contratuais que podem ter vulnerabilidades humanas; 2. Carteiras MPC de custódia mista com riscos de terceiros, escolha carteiras MPC privatizadas com o mesmo nível de segurança das carteiras de hardware; Em alguns cenários, porque você sempre quer para obter a melhor experiência do usuário, você pode escolher um produto com algumas operações centralizadas.
Além disso, o endereço blockchain não atende aos requisitos de verificação de identidade na ecologia, então as soluções de ENS (blockchain domain name) e SBT (soul binding token) são gradualmente aceitas pelo público, mas ainda existem problemas que não foram resolvido: o primeiro é difícil resolver o problema de nomes duplicados trazido pelo mundo tradicional. Embora o último não tenha o problema de nomes duplicados, não há aplicações ecológicas suficientes para utilizar plenamente as funções DID realizadas por ele, e mesmo os cenários de aplicação atuais podem ser considerados muito finos.
4. Resumo
Acredito que todos já entendem que a carteira é apenas uma parte importante do tópico [Transformação do Ethereum] que está em alta no círculo monetário global há quase 3 meses. A ambição de V God não é apenas realizar a ambição de "Ethereum complementa os defeitos do Bitcoin", mas também espera que Ethereum possa realmente criar um mundo em que todos possam entrar, altamente conectado com o mundo real e retenha o conceito de descentralização.