A partir dos eventos Multichain, veja a maneira correta de gerir a Carteira de cálculo mais longo
Recentemente, o CEO de um protocolo de cross-chain foi levado pela polícia, resultando na incapacidade de contato com sua equipe global, e a chave de acesso para operação do servidor de mais longo foi revogada. Este evento revelou a razão pela qual a operação do protocolo estava anômala, e também levantou uma questão importante: por que, mesmo adotando a tecnologia de mais longo, ainda enfrentamos tais riscos?
A resposta é, na verdade, muito simples. Embora o protocolo utilize tecnologia de mais longo para gerenciar fundos, a descentralização da tecnologia não equivale à descentralização da gestão. A verdadeira descentralização requer uma unificação entre a aplicação da tecnologia e a forma de gestão.
Casos semelhantes não são raros. Por exemplo, o Bitcoin é descentralizado, mas se um minerador monopolizar todo o poder de cálculo, então a descentralização do algoritmo perde seu significado; o Ethereum também é descentralizado, mas seu fundador ainda enfatiza a importância da tecnologia de validação distribuída para evitar o surgimento de tendências centralizadoras.
Ao aprofundar-se nos detalhes do anúncio, pode-se descobrir que a raiz do problema do protocolo reside no fato de que todos os servidores de nós estão, na verdade, operando sob a conta pessoal da nuvem do CEO. Esta centralização dos serviços de nós é essencialmente a mesma que o monopólio de todo o poder de computação por um único minerador, o que equivale a o CEO controlar todos os ativos usando uma carteira de assinatura única. Portanto, o problema do protocolo é que o CEO não deve controlar todos os fragmentos de computação mais longo e não forneceu uma solução de backup para situações extremas.
Então, como é que podemos aproveitar ao máximo as características da tecnologia de computação mais longa? Existem três pontos principais:
Aumentar a transparência e prevenir conflitos de interesse;
Seguir estritamente um método de custódia descentralizado, evitando a concentração excessiva de poder;
Elaborar um plano de ação para situações extremas.
Prevenção de conflitos de interesse: recusar operações não transparentes
Neste evento, uma determinada blockchain pública também foi severamente afetada. O fundador dessa blockchain afirmou em um fórum que anteriormente recebeu muitas garantias sobre a descentralização dos servidores, acesso e distribuição geográfica. No entanto, ficou provado posteriormente que essas garantias não foram cumpridas, e a equipe da blockchain não conseguiu ou não pôde verificar, optando por confiar de forma simples, resultando em perdas colaterais.
Pode-se ver que a solução de computação multipartidária deste protocolo de cross-chain é essencialmente uma "caixa preta". A razão para essa "caixa preta" é que o protocolo é simultaneamente o construtor do serviço e o utilizador do serviço, e essa sobreposição de funções traz inevitavelmente falta de transparência e espaço potencial para comportamentos maliciosos. A solução para este problema é introduzir um terceiro neutro e totalmente isento de conflitos de interesse, ou seja, utilizar serviços de computação multipartidária de terceiros com credibilidade suficiente, em vez de construir serviços próprios.
Os conflitos de interesse são comuns no domínio do Web3, por exemplo, algumas exchanges centralizadas desempenham simultaneamente as funções de fornecer serviços de negociação e de custodiar os ativos dos usuários, e podem lucrar com esses fundos, como participar na mineração em cadeia, fazer market making ou investir.
Voltando ao evento, se o protocolo de cross-chain utilizar serviços de computação multipartidária de terceiros que possuam credibilidade suficiente, pelo menos nas condições permitidas pelo protocolo, o prestador de serviços pode fornecer informações de verificação de custódia para as partes relevantes, eliminando assim a "caixa preta".
Custódia descentralizada: evitar risco de ponto único
A análise posterior indica que o risco de ponto único do CEO foi a causa direta deste evento. A abordagem correta deveria ser garantir a distribuição de servidores, acessos e localizações geográficas.
Uma solução ideal de cálculo multipartidário deve adotar uma assinatura multipartidária de 3-3 (também pode suportar configurações de assinatura de limiar t-n), onde duas partes são co-geridas pela plataforma, garantindo segurança através de criptografia de alta segurança e um ambiente de execução confiável. A assinatura da transação só pode ser concluída com a participação conjunta das três partes, evitando assim o risco de ponto único para o usuário.
Além disso, uma vez que os negócios costumam ser hierárquicos, o acesso também deve ser hierárquico. Um design de derivação de chaves privadas em múltiplos níveis pode ser adotado, permitindo que os gestores controlem o global, ao mesmo tempo em que compatibiliza os operadores de linha de frente na gestão de permissões específicas, evitando que riscos de ponto único impeçam todos os processos de negócios.
Finalmente, devem ser adotadas soluções como armazenamento distribuído multiativo online em locais distintos, backup em armazenamento frio offline em múltiplos níveis e serviços de recuperação de backup integrados com instituições especializadas, a fim de garantir o mais alto nível de garantia de distribuição geográfica. Esta série de mecanismos pode evitar ao máximo a perda de ativos ou a indisponibilidade de serviços devido a riscos de ponto único, incluindo níveis de chave privada, pessoal e ambiente externo.
Elaborar um plano de recuperação social em situações extremas
É preciso admitir que nenhuma solução é perfeita. Garantir a descentralização dos servidores, do acesso e da localização geográfica pode resolver alguns problemas, mas não todos. Muitos riscos ainda existem, como fatores de força maior no mundo físico. Quando inevitáveis, precisamos pensar em como responder quando essas situações extremas ocorrerem.
Com base nisso, pode-se conceber um "Modo SOS" para riscos de força maior no mundo físico. Este serviço pode ser oferecido como um serviço opcional não padrão aos utilizadores que necessitam, e ser projetado de forma personalizada de acordo com as necessidades reais. Além da fragmentação tradicional da chave privada, também serão configuradas várias fragmentações SOS, que serão geridas separadamente das fragmentações normais da chave privada.
Normalmente, os fragmentos SOS não têm qualquer função. No entanto, em situações específicas, os fragmentos SOS serão ativados, como quando o gestor dos fragmentos da chave privada os ativa manualmente em caso de emergência, quando a desconexão dos fragmentos da chave privada atinge um determinado limite de tempo, quando os fragmentos SOS iniciam ativamente um evento de emergência, ou quando é aprovada uma votação de governança de acordo com regras estabelecidas. Após a ativação do "modo SOS", os fragmentos SOS substituirão os fragmentos da chave privada, permitindo a transferência ou disposição de ativos em situações de emergência.
Para evitar que os detentores de fragmentos SOS abusem da situação, podem ser adicionadas algumas condições restritivas, como definir um atraso na ativação do modo "SOS", durante o qual os fragmentos de chave privada normais podem anular o "modo SOS"; ou após a transferência urgente de ativos no "modo SOS", pode ser definido um período de bloqueio, durante o qual não pode haver transferências adicionais, para evitar a perda de ativos.
Através dessas medidas, podemos maximizar a utilização das vantagens da tecnologia de mais longo, ao mesmo tempo em que minimizamos diversos riscos, garantindo a segurança dos ativos e a eficácia da gestão.
Ver original
Esta página pode conter conteúdos de terceiros, que são fornecidos apenas para fins informativos (sem representações/garantias) e não devem ser considerados como uma aprovação dos seus pontos de vista pela Gate, nem como aconselhamento financeiro ou profissional. Consulte a Declaração de exoneração de responsabilidade para obter mais informações.
14 gostos
Recompensa
14
7
Republicar
Partilhar
Comentar
0/400
HashBrownies
· 07-23 21:33
A gestão centralizada entra em conflito com a Descentralização.
Ver originalResponder0
ChainComedian
· 07-23 17:58
A concentração de poder é a maior vulnerabilidade.
Ver originalResponder0
PrivacyMaximalist
· 07-21 04:18
Se houver transparência, não é suficientemente descentralizado.
Gestão correta da Carteira de computação mais longo: transparência, Descentralização e resposta a situações extremas
A partir dos eventos Multichain, veja a maneira correta de gerir a Carteira de cálculo mais longo
Recentemente, o CEO de um protocolo de cross-chain foi levado pela polícia, resultando na incapacidade de contato com sua equipe global, e a chave de acesso para operação do servidor de mais longo foi revogada. Este evento revelou a razão pela qual a operação do protocolo estava anômala, e também levantou uma questão importante: por que, mesmo adotando a tecnologia de mais longo, ainda enfrentamos tais riscos?
A resposta é, na verdade, muito simples. Embora o protocolo utilize tecnologia de mais longo para gerenciar fundos, a descentralização da tecnologia não equivale à descentralização da gestão. A verdadeira descentralização requer uma unificação entre a aplicação da tecnologia e a forma de gestão.
Casos semelhantes não são raros. Por exemplo, o Bitcoin é descentralizado, mas se um minerador monopolizar todo o poder de cálculo, então a descentralização do algoritmo perde seu significado; o Ethereum também é descentralizado, mas seu fundador ainda enfatiza a importância da tecnologia de validação distribuída para evitar o surgimento de tendências centralizadoras.
Ao aprofundar-se nos detalhes do anúncio, pode-se descobrir que a raiz do problema do protocolo reside no fato de que todos os servidores de nós estão, na verdade, operando sob a conta pessoal da nuvem do CEO. Esta centralização dos serviços de nós é essencialmente a mesma que o monopólio de todo o poder de computação por um único minerador, o que equivale a o CEO controlar todos os ativos usando uma carteira de assinatura única. Portanto, o problema do protocolo é que o CEO não deve controlar todos os fragmentos de computação mais longo e não forneceu uma solução de backup para situações extremas.
Então, como é que podemos aproveitar ao máximo as características da tecnologia de computação mais longa? Existem três pontos principais:
Prevenção de conflitos de interesse: recusar operações não transparentes
Neste evento, uma determinada blockchain pública também foi severamente afetada. O fundador dessa blockchain afirmou em um fórum que anteriormente recebeu muitas garantias sobre a descentralização dos servidores, acesso e distribuição geográfica. No entanto, ficou provado posteriormente que essas garantias não foram cumpridas, e a equipe da blockchain não conseguiu ou não pôde verificar, optando por confiar de forma simples, resultando em perdas colaterais.
Pode-se ver que a solução de computação multipartidária deste protocolo de cross-chain é essencialmente uma "caixa preta". A razão para essa "caixa preta" é que o protocolo é simultaneamente o construtor do serviço e o utilizador do serviço, e essa sobreposição de funções traz inevitavelmente falta de transparência e espaço potencial para comportamentos maliciosos. A solução para este problema é introduzir um terceiro neutro e totalmente isento de conflitos de interesse, ou seja, utilizar serviços de computação multipartidária de terceiros com credibilidade suficiente, em vez de construir serviços próprios.
Os conflitos de interesse são comuns no domínio do Web3, por exemplo, algumas exchanges centralizadas desempenham simultaneamente as funções de fornecer serviços de negociação e de custodiar os ativos dos usuários, e podem lucrar com esses fundos, como participar na mineração em cadeia, fazer market making ou investir.
Voltando ao evento, se o protocolo de cross-chain utilizar serviços de computação multipartidária de terceiros que possuam credibilidade suficiente, pelo menos nas condições permitidas pelo protocolo, o prestador de serviços pode fornecer informações de verificação de custódia para as partes relevantes, eliminando assim a "caixa preta".
Custódia descentralizada: evitar risco de ponto único
A análise posterior indica que o risco de ponto único do CEO foi a causa direta deste evento. A abordagem correta deveria ser garantir a distribuição de servidores, acessos e localizações geográficas.
Uma solução ideal de cálculo multipartidário deve adotar uma assinatura multipartidária de 3-3 (também pode suportar configurações de assinatura de limiar t-n), onde duas partes são co-geridas pela plataforma, garantindo segurança através de criptografia de alta segurança e um ambiente de execução confiável. A assinatura da transação só pode ser concluída com a participação conjunta das três partes, evitando assim o risco de ponto único para o usuário.
Além disso, uma vez que os negócios costumam ser hierárquicos, o acesso também deve ser hierárquico. Um design de derivação de chaves privadas em múltiplos níveis pode ser adotado, permitindo que os gestores controlem o global, ao mesmo tempo em que compatibiliza os operadores de linha de frente na gestão de permissões específicas, evitando que riscos de ponto único impeçam todos os processos de negócios.
Finalmente, devem ser adotadas soluções como armazenamento distribuído multiativo online em locais distintos, backup em armazenamento frio offline em múltiplos níveis e serviços de recuperação de backup integrados com instituições especializadas, a fim de garantir o mais alto nível de garantia de distribuição geográfica. Esta série de mecanismos pode evitar ao máximo a perda de ativos ou a indisponibilidade de serviços devido a riscos de ponto único, incluindo níveis de chave privada, pessoal e ambiente externo.
Elaborar um plano de recuperação social em situações extremas
É preciso admitir que nenhuma solução é perfeita. Garantir a descentralização dos servidores, do acesso e da localização geográfica pode resolver alguns problemas, mas não todos. Muitos riscos ainda existem, como fatores de força maior no mundo físico. Quando inevitáveis, precisamos pensar em como responder quando essas situações extremas ocorrerem.
Com base nisso, pode-se conceber um "Modo SOS" para riscos de força maior no mundo físico. Este serviço pode ser oferecido como um serviço opcional não padrão aos utilizadores que necessitam, e ser projetado de forma personalizada de acordo com as necessidades reais. Além da fragmentação tradicional da chave privada, também serão configuradas várias fragmentações SOS, que serão geridas separadamente das fragmentações normais da chave privada.
Normalmente, os fragmentos SOS não têm qualquer função. No entanto, em situações específicas, os fragmentos SOS serão ativados, como quando o gestor dos fragmentos da chave privada os ativa manualmente em caso de emergência, quando a desconexão dos fragmentos da chave privada atinge um determinado limite de tempo, quando os fragmentos SOS iniciam ativamente um evento de emergência, ou quando é aprovada uma votação de governança de acordo com regras estabelecidas. Após a ativação do "modo SOS", os fragmentos SOS substituirão os fragmentos da chave privada, permitindo a transferência ou disposição de ativos em situações de emergência.
Para evitar que os detentores de fragmentos SOS abusem da situação, podem ser adicionadas algumas condições restritivas, como definir um atraso na ativação do modo "SOS", durante o qual os fragmentos de chave privada normais podem anular o "modo SOS"; ou após a transferência urgente de ativos no "modo SOS", pode ser definido um período de bloqueio, durante o qual não pode haver transferências adicionais, para evitar a perda de ativos.
Através dessas medidas, podemos maximizar a utilização das vantagens da tecnologia de mais longo, ao mesmo tempo em que minimizamos diversos riscos, garantindo a segurança dos ativos e a eficácia da gestão.