O fundador da Ethereum, Vitalik Buterin (V god), publicou um blog "Quais são os casos de uso não financeiro da blockchain?" ". V God disse que sempre apoiou fortemente a tendência de usar blockchain para aplicações não financeiras, e as pessoas precisam ficar longe tanto da "onipotência blockchain" quanto do "minimalismo blockchain". Ele disse que vê valor no blockchain em muitos casos, às vezes para objetivos realmente importantes, como confiança e censura, às vezes apenas por conveniência.
V God também listou 8 cenários de aplicativos não financeiros que podem usar blockchain no artigo: alteração e recuperação de chave de conta de usuário, modificação e revogação de certificação, reputação negativa, prova de escassez, conhecimento público e outros aplicativos blockchain Interoperabilidade do programa, código aberto métricas, armazenamento de dados. Os dois aplicativos não financeiros que ele diz estar mais confiante até agora são: interoperabilidade com outros aplicativos blockchain e gerenciamento de contas.
A seguir está uma longa postagem no blog de V God, compilada por Odaily Planet Daily:
Recentemente, houve um aumento do interesse em aplicações não financeiras de blockchain, que sempre apoiei muito. No mês passado, escrevi um artigo em coautoria com Puja Ohlhaver e Glen Weyl, descrevendo uma visão mais detalhada do que os tokens vinculados à alma (SBTs) poderiam fazer em um ecossistema mais rico, onde essas moedas podem descrever vários relacionamentos. Isso gerou algumas discussões sobre se faz sentido usar blockchain em um ecossistema de identidade descentralizado.
A partir disso, ainda fazemos a pergunta: qual é o sentido de usar blockchain em aplicações não financeiras? Devemos caminhar para um mundo onde, mesmo com aplicativos de bate-papo descentralizados, todas as mensagens são processadas por meio de uma transação on-chain contendo informações criptografadas? Ou o blockchain é adequado apenas para o setor financeiro (por exemplo, porque os efeitos de rede significam que as moedas têm uma necessidade única de uma "visão global"), enquanto todos os outros aplicativos são melhor executados usando sistemas centralizados ou mais localizados?
Meu próprio ponto de vista é como a votação em blockchain (nota diária: V God sugere que ele é mais neutro e objetivo), nem "blockchain em todos os lugares" nem "minimalismo de blockchain" (minimalismo de blockchain) maximalista). Vejo o valor do blockchain em muitas situações, às vezes para objetivos realmente importantes, como confiança e resistência à censura, mas às vezes puramente por conveniência. Este post tentará descrever o blockchain, situações em que ele pode ou não ser útil de alguma forma. Observe que este artigo não é uma lista completa e muitas coisas foram deixadas de fora intencionalmente, nosso objetivo é esclarecer algumas categorias comuns.
1. Alteração e recuperação da chave da conta do usuário
Um dos maiores desafios em sistemas de contas criptográficas é o problema de troca de chaves, que pode acontecer de várias formas:
「1」Você está preocupado que sua chave atual possa ser perdida ou roubada e deseja mudar para uma chave diferente;
"2" você deseja mudar para um algoritmo de criptografia diferente (por exemplo, porque está preocupado com o surgimento de computadores quânticos em breve e deseja atualizar para um algoritmo pós-quântico);
"3" Sua chave foi perdida e você deseja recuperar o acesso à sua conta;
"4" Sua chave foi roubada e você deseja recuperar o acesso exclusivo à conta (o que você não deseja que o ladrão faça).
A implementação dos dois primeiros pontos é relativamente simples porque eles podem ser feitos de forma totalmente autônoma: você controla a chave X e deseja alternar para a chave Y, então publica uma mensagem assinada por X dizendo "Verifique-me com Y de agora em diante ." ', todos aceitam isso.
Observe, no entanto, que mesmo para esses cenários relativamente simples de alteração de chave, você não pode usar apenas criptografia. Considere a seguinte situação:
Você está preocupado que a chave A possa ser roubada, então você assina uma mensagem com A dizendo "Eu uso B agora";
Um ano depois, os hackers roubam a chave A, mas podem usar A para assinar mensagens dizendo "Eu uso C agora", onde C é sua própria chave;
Para os retardatários que recebem duas mensagens ao mesmo tempo, eles veem apenas que A não é mais usado, mas não sabem qual das duas mensagens "substituir A por B" ou "substituir A por C" tem uma classe de prioridade mais alta .
Isso é muito semelhante ao "problema de gasto duplo" encontrado ao projetar uma moeda descentralizada, exceto que o objetivo desta vez não é impedir que o antigo proprietário do token o envie novamente, mas impedir que a antiga chave que controla a conta poder trocar a chave. Assim como criar uma moeda descentralizada, fazer o gerenciamento de contas de forma descentralizada requer algo como um blockchain. O blockchain pode marcar as mensagens de mudança de chave para determinar qual veio primeiro, B ou C.
Para resolver "3" e "4" é mais difícil, minha solução preferida é carteira de recuperação social e assinatura múltipla. Em caso de perda ou roubo, seus amigos, familiares e outros contatos podem transferir o controle de sua conta para uma nova chave. Seu envolvimento também pode ser necessário para operações críticas, como transferência de grandes quantias de fundos ou assinatura de contratos importantes.
A "recuperação social" usando o compartilhamento de segredos é teoricamente possível, mas difícil na prática: se você não confia mais em alguns de seus contatos ou eles desejam alterar suas chaves, você não pode revogar os direitos de acesso em caso de Portanto, voltamos ao problema - é necessária alguma forma de registro on-chain.
Há uma ideia sutil, mas importante, no artigo de DeSoc: para manter a intransferibilidade, os perfis socialmente restaurados podem realmente precisar ser aplicados. Dito isso, mesmo que você venda sua conta, sempre poderá usar a recuperação social para recuperar a propriedade da conta. Isso resolveria problemas como motoristas com crédito ruim que compram contas verificadas em plataformas de compartilhamento de viagens. Esta é uma ideia especulativa e não precisa ser totalmente realizada para colher os outros benefícios de um sistema de identidade e reputação baseado em blockchain.
Observe que este é apenas um caso de uso limitado do blockchain até agora: é perfeitamente normal ter contas na cadeia, mas fazer outras coisas fora da cadeia. Esse tipo de visão híbrida tem seu lugar; Sign-in With Ethereum é um bom exemplo simples de como isso pode ser feito na prática.
2. Modificar e revogar a certificação
Alice frequenta o Example College para se formar e recebe um certificado digital de registro assinado pela chave do Example College. Infelizmente, seis meses depois, o Example College descobriu que Alice havia plagiado extensivamente e revogado seu diploma. Mas Alice continua andando por aí usando os antigos registros digitais, alegando para várias pessoas e instituições que ela é formada. Mesmo a prova pode vir com algumas permissões (por exemplo, fazer login no fórum online da faculdade), Alice pode tentar Como podemos evitar isso?
A abordagem do "minimalismo blockchain" é tornar o grau um NFT na cadeia, para que o Example College possa emitir uma transação na cadeia para revogar o NFT. Mas isso pode ser uma despesa necessária: emissões são comuns, revogações são raras; não queremos que o Example College emita transações desnecessariamente e pague por cada emissão. Portanto, podemos adotar uma solução híbrida: tornar o grau inicial uma mensagem assinada off-chain e revogação on-chain. Este é o método usado pelo OpenCerts.
Uma solução completamente fora da cadeia, defendida por muitos proponentes de credenciais verificáveis fora da cadeia, é fazer com que o Example College execute um servidor onde eles postem uma lista completa de certificados revogados (cada certificado pode ser acompanhado por um nonce para maior privacidade, uma revogação list pode ser apenas uma lista de números aleatórios).
Executar um servidor não é um grande fardo para uma universidade. Mas para outras organizações ou indivíduos menores, gerenciar "mais um script de servidor" e garantir que ele permaneça online pode ser um fardo significativo para a equipe de TI. Se dissermos às pessoas para "apenas usar servidores" por medo de blockchain, o resultado provável é que todos terceirizam tarefas para um provedor centralizado. É melhor manter o sistema descentralizado e usar apenas o blockchain – principalmente agora que rollups, sharding (sharding) e outras tecnologias estão finalmente começando a ficar online, tornando os blockchains cada vez mais baratos.
3. Reputação negativa
Outra área importante em que as assinaturas off-chain falham é a "reputação negativa" - ou seja, as provas que você está fazendo envolvem pessoas ou organizações que podem não querer que você veja suas provas. Estou usando "reputação negativa" como um termo técnico aqui: o caso de uso mais óbvio são críticas negativas sobre alguém, como críticas negativas ou relatos de comportamento negativo de alguém em determinados contextos; mas há outros cenários em que provas "negativas", o que não implica mau comportamento - como fazer um empréstimo para provar que você não fez muitos outros empréstimos ao mesmo tempo.
Para reclamações fora da cadeia, você pode fazer reputação positiva porque mostrá-la torna você mais respeitável (ou fazer uma prova de conhecimento zero) para o destinatário da reclamação; mas você não pode fazer reputação negativa porque as pessoas sempre optam por mostrar Faça uma declaração positiva e ignore todas as outras reivindicações ruins.
Portanto, escrever provas na cadeia pode realmente resolver os problemas acima. Para privacidade, podemos adicionar criptografia e provas de conhecimento zero: uma prova pode ser simplesmente um pedaço de dados registrado na cadeia, criptografado com a chave pública do destinatário, e o usuário pode provar que não tem reputação negativa executando um teste zero- prova de conhecimento, Isso requer percorrer todo o histórico registrado na cadeia. As provas estão na cadeia e o processo de verificação reconhece o blockchain, portanto é fácil verificar se a prova realmente atravessou todo o histórico e não pulou nenhum registro. Para viabilizar esse cálculo, os usuários podem usar cálculos verificáveis incrementalmente (como o Halo) para manter e provar uma árvore de registros, revelando partes da árvore quando necessário.
Provas de reputação negativa e revogação são, em certo sentido, um problema equivalente: você pode revogar uma prova adicionando outra prova de reputação negativa que diga "esta outra prova não é mais válida" e você pode revogar uma prova com reputação positiva Para obter a revogação de reputação negativa: o diploma de Alice da Example College pode ser revogado e substituído por um certificado de graduação que diga "Alice obteve um diploma de estudos de exemplo, mas ela plagiou muito".
** Uma reputação negativa é uma boa ideia? **
Uma crítica à reputação negativa que às vezes ouvimos é: a reputação negativa não é uma solução binária distópica de “letras escarlates” e não deveríamos tentar fazer coisas com reputação positiva? (Nota diária: a heroína do romance das letras escarlates é punida e precisa usar uma letra escarlate "A" simbolizando "adultério" em seu peito.)
Embora eu apoie o objetivo de evitar reputação negativa ilimitada, discordo da ideia de evitá-la totalmente. A reputação negativa é importante para muitos casos de uso. Os empréstimos não garantidos são extremamente valiosos para melhorar a eficiência do capital dentro e fora do espaço blockchain e podem claramente se beneficiar disso. A Unirep Social demonstrou uma plataforma de mídia social de prova de conceito que combina um alto grau de anonimato com um sistema de reputação negativa que preserva a privacidade para limitar o abuso.
Às vezes, uma reputação negativa pode fortalecer, enquanto uma reputação positiva pode ser exclusiva. Um fórum on-line onde todos têm o direito de postar até serem muito "punidos" por comportamento inadequado é mais igualitário do que um fórum que exige algum tipo de "prova de bom caráter" para poder falar. A maioria das pessoas marginalizadas que vivem "fora do sistema", por melhor que seja sua conduta, é difícil obter tal certificado.
Os leitores que são fortemente libertários pró-civis também podem considerar o caso de sistemas de reputação anônima para clientes profissionais do sexo: você quer privacidade, mas também pode querer um sistema - se um cliente abusa de uma profissional do sexo, outros podem ver e ficar longe com mais cuidado . Dessa forma, uma reputação negativa difícil de esconder pode, na verdade, fortalecer os vulneráveis e mantê-los seguros. O ponto aqui não é defender algum esquema específico para reputação negativa; em vez disso, é mostrar que a reputação negativa pode revelar um valor muito real e que um sistema bem-sucedido precisa apoiá-la de alguma forma.
A reputação negativa não precisa ser uma reputação negativa ilimitada: acho que sempre deve ser possível criar novos perfis com algum custo (possivelmente sacrificando a maior parte ou toda a reputação positiva existente). Existe um equilíbrio entre pouca responsabilidade e muita responsabilidade, e precisamos encontrar esse equilíbrio. Mas ter alguma tecnologia que possa permitir uma reputação negativa em primeiro lugar é um pré-requisito para desbloquear esse espaço de design.
4. Comprometido com a Escassez (Prova de Escassez)
Outro exemplo de valor blockchain é a emissão de um número limitado de provas. Se eu quiser endossar alguém (por exemplo, pode-se imaginar que uma empresa que esteja recrutando ou um programa de visto do governo considere tal endosso), um terceiro que veja o endosso pode se perguntar se estou desconfiado do endosso ou se é quase contanto que seja meu amigo fazendo isso. Como um pedido educado, irei endossá-los.
A solução ideal para esse problema seria tornar os endossos públicos, de forma que os endossos ficassem alinhados aos incentivos: se a pessoa que eu endossei fizesse algo errado, todos poderiam me dar um desconto no futuro. Mas, muitas vezes, também queremos proteger a privacidade. Assim, posso publicar o hash de cada endosso na cadeia para que todos possam ver quantos endossos eu emiti.
Um caso de uso mais eficiente é emitir vários de uma vez: se um artista deseja emitir N cópias de uma NFT de "edição limitada", ele pode emitir na cadeia um único hash contendo a raiz Merkle de sua NFT emitida. Um único problema os impede de emitir mais após o fato, e você pode emitir um número representando um limite (por exemplo, 100) com a raiz Merkle, o que significa que apenas os 100 ramos Merkle mais à esquerda são válidos.
Ao publicar uma única raiz Merkle e uma contagem máxima na cadeia, você pode enviar um número limitado de provas. Neste exemplo, existem apenas cinco ramificações Merkle válidas possíveis que satisfazem a verificação de prova. Leitores astutos podem notar uma semelhança conceitual com as cadeias de plasma.
Cinco, conhecimento público
Uma das propriedades poderosas dos blockchains é que eles criam conhecimento público: se eu publicar algo na cadeia, Alice pode ver; Alice pode ver Bob pode ver; Charlie pode ver Alice pode ver Até que Bob possa ver, e assim sobre.
O conhecimento comum é muitas vezes importante para a colaboração. Por exemplo, um grupo de pessoas pode querer falar sobre um assunto, mas só se sentirá confortável se um número suficiente de pessoas estiver falando ao mesmo tempo para que possam se esconder com segurança no meio da multidão. Uma maneira possível de conseguir isso é uma pessoa iniciar um "conjunto de compromissos" em torno de uma declaração específica e convidar outras pessoas a postar um hash (primeiro em particular) para indicar sua concordância. Somente se um número suficiente de pessoas participar dentro de um determinado período de tempo, todos os participantes precisarão declarar publicamente sua posição em sua próxima mensagem on-chain.
Tal projeto poderia ser implementado com uma combinação de provas de conhecimento zero e um blockchain (poderia ser feito sem um blockchain, mas isso exigiria criptografia de testemunha - não disponível atualmente; ou exigiria hardware confiável, cujas suposições de segurança são seriamente questionáveis). Há muito espaço de design em torno dessas ideias, que não é totalmente explorado hoje, mas crescerá rapidamente à medida que o ecossistema de ferramentas de blockchain e criptografia se desenvolver ainda mais.
6. Interoperabilidade com outros aplicativos blockchain
Este é um exemplo simples: algo deve estar on-chain para melhor interoperar com outros aplicativos on-chain. Provas de identidade humana como NFTs on-chain, permitindo que os projetos sejam lançados automaticamente ou concedam permissões a contas com provas de identidade humana. Colocar dados oracle on-chain facilita a leitura de projetos de finanças descentralizadas (DeFi). Nesses casos, o blockchain não elimina a necessidade de confiança, embora possa acomodar estruturas que gerenciam a confiança (como DAOs). O principal valor que existe na cadeia é simplesmente estar localizado com as coisas com as quais você está interagindo, o que requer o uso da cadeia de blocos por outros motivos.
Obviamente, você pode executar oráculos fora da cadeia e importar dados apenas quando precisar lê-los, mas, em muitos casos, isso seria realmente mais caro e introduziria complexidade e custos desnecessários para os desenvolvedores.
Sete, indicadores de código aberto
Um objetivo fundamental do papel da sociedade descentralizada é permitir a possibilidade de computação em gráficos de prova, e uma métrica muito importante é medir a descentralização e a diversidade. Por exemplo, muitas pessoas parecem pensar que o mecanismo de votação ideal permitiria a diversidade, dando mais peso a projetos que não são apenas apoiados por um grande número de tokens e até humanos, mas apoiados por pontos de vista genuinamente diversos.
O financiamento quadrático implementado no Gitcoin Grants também inclui alguma lógica que suporta explicitamente a diversidade para mitigar ataques. Lógica explícita para oferecer suporte à diversidade para mitigar ataques
Outra coisa que pode tornar a medição e a pontuação valiosas são os sistemas de reputação. Isso já existe nas avaliações de forma centralizada, mas pode ser feito de forma mais descentralizada, tornando o algoritmo transparente e protegendo mais a privacidade do usuário ao mesmo tempo.
Além de casos de uso fortemente acoplados como este (tentar medir o quão conectado alguém está e alimentar isso diretamente no mecanismo), há casos de uso mais amplos para ajudar uma comunidade a entender a si mesma. Quando se trata de medir a descentralização, áreas excessivamente concentradas podem precisar responder. Nesses casos, é inevitável executar algoritmos de computador em um grande número de provas e compromissos e executar operações realmente importantes na saída.
Em vez de tentar abolir as métricas quantitativas, deveríamos tentar criar métricas melhores
Kate Sills expressa seu ceticismo sobre calcular metas de reputação, um argumento que se aplica tanto à análise pública quanto a ZKs individuais que comprovam sua reputação (como Unirep Social): "O processo de avaliação de reclamações é muito subjetivo e dependente do contexto. Pessoas Haverá naturalmente desacordos sobre a credibilidade dos outros, e a confiança depende do contexto... (portanto) devemos ser extremamente céticos em relação a todas as propostas que afirmam que a 'computação' produz resultados objetivos."
Nesse caso, concordo que a subjetividade e o contexto precisam ser levados em consideração, mas discordo da afirmação de que evitar cálculos em torno da reputação é a coisa certa a fazer. A análise individualizada pura não irá muito além do "número de Dunbar", e qualquer sociedade complexa que tente apoiar a cooperação em larga escala deve contar com agregação e simplificação até certo ponto. (Nota diária: o número de Dunbar também é chamado de "a lei dos 150", que se refere ao limite máximo do número de pessoas que podem manter um relacionamento interpessoal próximo com uma determinada pessoa, geralmente considerado 150.)
Dito isso, acho que um ecossistema de prova aberto e participativo (em oposição ao ecossistema centralizado que temos hoje) pode alcançar o melhor dos dois mundos abrindo espaço para melhores métricas. Aqui estão alguns princípios que tais projetos podem seguir:
Intersubjetividade: por exemplo, a reputação não deve ser uma classificação global única; em vez disso, deve ser um cálculo mais subjetivo envolvendo a pessoa ou entidade que está sendo avaliada, o observador que visualiza a classificação e talvez até mesmo outros aspectos do ambiente local.
Neutralidade credível: O programa claramente não deve deixar espaço para elites poderosas manipulá-lo constantemente para seu próprio benefício. Algumas maneiras possíveis de conseguir isso são transparência máxima e menos alterações nos algoritmos.
Abertura: A capacidade de ter uma contribuição significativa e de examinar a produção dos outros por si mesmo deve estar aberta a qualquer pessoa, não apenas a alguns grupos poderosos.
Se não criarmos uma boa agregação de dados sociais em escala, corremos o risco de perder participação de mercado para uma pontuação de crédito social opaca e centralizada.
Nem todos os dados devem estar on-chain, mas expor alguns dados de maneira sensata pode ajudar a melhorar a legibilidade da comunidade para si mesma sem criar discrepâncias no acesso aos dados que poderiam ser abusadas para controle centralizado.
Oito, como armazenamento de dados
Este é um caso de uso realmente controverso, embora muitas pessoas adotem outros casos de uso de blockchain. No espaço blockchain, existe uma visão geral de que blockchains só devem ser usados quando houver uma necessidade real e não puder ser evitada, e que em outros lugares devemos usar outras ferramentas.
Em um mundo onde as taxas de transação são muito caras e os blockchains são terrivelmente ineficientes, esse argumento faz sentido. Mas em um blockchain com rollups e sharding e taxas de transação reduzidas a centavos, essa ideia é menos plausível. Em tal mundo, a diferença de redundância entre blockchain e armazenamento descentralizado não-blockchain pode ser apenas um fator de 100.
Mesmo em tal mundo, seria imprudente armazenar todos os dados na cadeia. Mas e os pequenos registros de texto? Absolutamente. Por que? Porque o blockchain é realmente um lugar muito conveniente para armazenar coisas. Eu mantenho uma cópia deste blog no IPFS. Mas o upload para o IPFS normalmente leva uma hora e requer gateways centralizados para fornecer acesso aos usuários em velocidades que se aproximam da latência no nível do site e, às vezes, os arquivos desaparecem e não podem mais ser visualizados. Por outro lado, despejar todo o blog on-chain resolveria completamente esse problema. É claro que, mesmo após a fragmentação, o blog é muito grande para realmente ser despejado na cadeia, o mesmo princípio se aplica a registros menores,
Alguns exemplos de pequenos casos de uso em que os dados podem ser armazenados na cadeia incluem:
Compartilhamento de segredo aprimorado: Divida a senha em N partes, onde qualquer parte M = NR pode recuperar a senha, mas você pode escolher o conteúdo de todas as N partes. Por exemplo, essas peças podem ser hashes de senhas, segredos gerados por outras ferramentas ou respostas a perguntas de segurança. Publicando partes R adicionais na cadeia (aparentemente aleatoriamente) e compartilhando segredos N-de-(N+R) para todo o conjunto.
Otimização ENS. O ENS pode se tornar mais eficiente combinando todos os registros em um hash, publicando apenas o hash na cadeia e exigindo que qualquer pessoa que acesse os dados busque os dados completos do IPFS. Mas isso adiciona uma complexidade significativa e aumenta a dependência de outro software. Portanto, mesmo que o comprimento de dados do ENS exceda 32 bytes, ele permanecerá na cadeia.
Metadados sociais - Dados associados à sua conta (por exemplo, para um login Ethereum) que você deseja tornar públicos e muito curtos. Isso é bom para registros de texto, mas geralmente não para dados maiores, como uma foto de perfil (que pode funcionar se a foto for um pequeno arquivo SVG).
Autenticação e direitos de acesso. Especialmente quando os dados armazenados têm menos de algumas centenas de bytes, pode ser mais conveniente armazenar os dados na cadeia do que colocar o hash na cadeia e os dados fora da cadeia.
Em muitos casos, a compensação não é apenas o custo, mas também a privacidade no caso extremo de chaves ou senhas comprometidas. Às vezes, a privacidade importa apenas até certo ponto e, em vez de se preocupar com chaves vazadas ou com a perda ocasional de privacidade da computação quântica, é melhor garantir que os dados sempre possam ser acessados de maneira confiável. Afinal, os dados fora da cadeia armazenados em sua "carteira de dados" também podem ser hackeados.
Mas, às vezes, os dados são particularmente confidenciais, e isso pode ser apenas outro argumento contra colocá-los na cadeia e armazená-los localmente como uma segunda camada de defesa. Observe, no entanto, que nesses casos a necessidade de privacidade é um argumento não apenas contra blockchains, mas contra todo armazenamento descentralizado.
para concluir
Da lista acima, os dois casos de uso em que pessoalmente me sinto mais confiante agora são "interoperabilidade com outros aplicativos blockchain" e "gerenciamento de contas". O primeiro já está na cadeia, o segundo é relativamente barato (precisa usar a cadeia uma vez por usuário, não uma vez por operação), tem um caso claro para isso e realmente não possui uma boa solução não baseada em blockchain .
"Reputação negativa" e "revogação da certificação" também são importantes, embora ainda sejam casos de uso relativamente antigos. Você pode fazer muito com a reputação confiando apenas na reputação positiva fora da cadeia, mas espero que os casos de revogação e reputação negativa se tornem mais claros com o tempo. Prevejo que alguém tentará fazer isso com um servidor centralizado, mas com o tempo deve ficar claro para todos: blockchain é a única forma de evitar a difícil escolha entre inconveniência e centralização.
Blockchains como armazenamento de dados para registros de texto curtos podem ser triviais ou significativos, mas espero que esses tipos de uso pelo menos continuem a acontecer. O Blockchain é realmente útil para recuperação de dados confiável e de baixo custo, independentemente de o aplicativo ter dois usuários ou dois milhões de usuários, os dados podem continuar a ser recuperados.
As métricas de código aberto ainda estão em um estágio conceitual muito inicial e resta saber o quanto elas podem fazer sem serem exploradas (como análises on-line, classificações de mídia social, etc. são frequentemente exploradas). E o jogo do conhecimento comum precisa convencer as pessoas a aceitar fluxos de trabalho inteiramente novos para coisas socialmente importantes, então certamente é uma ideia em estágio inicial também.
Não tenho certeza da extensão exata do uso de blockchain não financeiro nessas categorias, mas está claro que o blockchain como uma ferramenta capacitadora nessas áreas não deve ser descartado.
Ver original
O conteúdo serve apenas de referência e não constitui uma solicitação ou oferta. Não é prestado qualquer aconselhamento em matéria de investimento, fiscal ou jurídica. Consulte a Declaração de exoneração de responsabilidade para obter mais informações sobre os riscos.
Vitalik: Quais são os casos de uso não financeiro do blockchain?
V God também listou 8 cenários de aplicativos não financeiros que podem usar blockchain no artigo: alteração e recuperação de chave de conta de usuário, modificação e revogação de certificação, reputação negativa, prova de escassez, conhecimento público e outros aplicativos blockchain Interoperabilidade do programa, código aberto métricas, armazenamento de dados. Os dois aplicativos não financeiros que ele diz estar mais confiante até agora são: interoperabilidade com outros aplicativos blockchain e gerenciamento de contas.
A seguir está uma longa postagem no blog de V God, compilada por Odaily Planet Daily:
Recentemente, houve um aumento do interesse em aplicações não financeiras de blockchain, que sempre apoiei muito. No mês passado, escrevi um artigo em coautoria com Puja Ohlhaver e Glen Weyl, descrevendo uma visão mais detalhada do que os tokens vinculados à alma (SBTs) poderiam fazer em um ecossistema mais rico, onde essas moedas podem descrever vários relacionamentos. Isso gerou algumas discussões sobre se faz sentido usar blockchain em um ecossistema de identidade descentralizado.
A partir disso, ainda fazemos a pergunta: qual é o sentido de usar blockchain em aplicações não financeiras? Devemos caminhar para um mundo onde, mesmo com aplicativos de bate-papo descentralizados, todas as mensagens são processadas por meio de uma transação on-chain contendo informações criptografadas? Ou o blockchain é adequado apenas para o setor financeiro (por exemplo, porque os efeitos de rede significam que as moedas têm uma necessidade única de uma "visão global"), enquanto todos os outros aplicativos são melhor executados usando sistemas centralizados ou mais localizados?
Meu próprio ponto de vista é como a votação em blockchain (nota diária: V God sugere que ele é mais neutro e objetivo), nem "blockchain em todos os lugares" nem "minimalismo de blockchain" (minimalismo de blockchain) maximalista). Vejo o valor do blockchain em muitas situações, às vezes para objetivos realmente importantes, como confiança e resistência à censura, mas às vezes puramente por conveniência. Este post tentará descrever o blockchain, situações em que ele pode ou não ser útil de alguma forma. Observe que este artigo não é uma lista completa e muitas coisas foram deixadas de fora intencionalmente, nosso objetivo é esclarecer algumas categorias comuns.
1. Alteração e recuperação da chave da conta do usuário
Um dos maiores desafios em sistemas de contas criptográficas é o problema de troca de chaves, que pode acontecer de várias formas:
A implementação dos dois primeiros pontos é relativamente simples porque eles podem ser feitos de forma totalmente autônoma: você controla a chave X e deseja alternar para a chave Y, então publica uma mensagem assinada por X dizendo "Verifique-me com Y de agora em diante ." ', todos aceitam isso.
Observe, no entanto, que mesmo para esses cenários relativamente simples de alteração de chave, você não pode usar apenas criptografia. Considere a seguinte situação:
Para os retardatários que recebem duas mensagens ao mesmo tempo, eles veem apenas que A não é mais usado, mas não sabem qual das duas mensagens "substituir A por B" ou "substituir A por C" tem uma classe de prioridade mais alta .
Para resolver "3" e "4" é mais difícil, minha solução preferida é carteira de recuperação social e assinatura múltipla. Em caso de perda ou roubo, seus amigos, familiares e outros contatos podem transferir o controle de sua conta para uma nova chave. Seu envolvimento também pode ser necessário para operações críticas, como transferência de grandes quantias de fundos ou assinatura de contratos importantes.
A "recuperação social" usando o compartilhamento de segredos é teoricamente possível, mas difícil na prática: se você não confia mais em alguns de seus contatos ou eles desejam alterar suas chaves, você não pode revogar os direitos de acesso em caso de Portanto, voltamos ao problema - é necessária alguma forma de registro on-chain.
Há uma ideia sutil, mas importante, no artigo de DeSoc: para manter a intransferibilidade, os perfis socialmente restaurados podem realmente precisar ser aplicados. Dito isso, mesmo que você venda sua conta, sempre poderá usar a recuperação social para recuperar a propriedade da conta. Isso resolveria problemas como motoristas com crédito ruim que compram contas verificadas em plataformas de compartilhamento de viagens. Esta é uma ideia especulativa e não precisa ser totalmente realizada para colher os outros benefícios de um sistema de identidade e reputação baseado em blockchain.
Observe que este é apenas um caso de uso limitado do blockchain até agora: é perfeitamente normal ter contas na cadeia, mas fazer outras coisas fora da cadeia. Esse tipo de visão híbrida tem seu lugar; Sign-in With Ethereum é um bom exemplo simples de como isso pode ser feito na prática.
2. Modificar e revogar a certificação
Alice frequenta o Example College para se formar e recebe um certificado digital de registro assinado pela chave do Example College. Infelizmente, seis meses depois, o Example College descobriu que Alice havia plagiado extensivamente e revogado seu diploma. Mas Alice continua andando por aí usando os antigos registros digitais, alegando para várias pessoas e instituições que ela é formada. Mesmo a prova pode vir com algumas permissões (por exemplo, fazer login no fórum online da faculdade), Alice pode tentar Como podemos evitar isso?
A abordagem do "minimalismo blockchain" é tornar o grau um NFT na cadeia, para que o Example College possa emitir uma transação na cadeia para revogar o NFT. Mas isso pode ser uma despesa necessária: emissões são comuns, revogações são raras; não queremos que o Example College emita transações desnecessariamente e pague por cada emissão. Portanto, podemos adotar uma solução híbrida: tornar o grau inicial uma mensagem assinada off-chain e revogação on-chain. Este é o método usado pelo OpenCerts.
Uma solução completamente fora da cadeia, defendida por muitos proponentes de credenciais verificáveis fora da cadeia, é fazer com que o Example College execute um servidor onde eles postem uma lista completa de certificados revogados (cada certificado pode ser acompanhado por um nonce para maior privacidade, uma revogação list pode ser apenas uma lista de números aleatórios).
Executar um servidor não é um grande fardo para uma universidade. Mas para outras organizações ou indivíduos menores, gerenciar "mais um script de servidor" e garantir que ele permaneça online pode ser um fardo significativo para a equipe de TI. Se dissermos às pessoas para "apenas usar servidores" por medo de blockchain, o resultado provável é que todos terceirizam tarefas para um provedor centralizado. É melhor manter o sistema descentralizado e usar apenas o blockchain – principalmente agora que rollups, sharding (sharding) e outras tecnologias estão finalmente começando a ficar online, tornando os blockchains cada vez mais baratos.
3. Reputação negativa
Outra área importante em que as assinaturas off-chain falham é a "reputação negativa" - ou seja, as provas que você está fazendo envolvem pessoas ou organizações que podem não querer que você veja suas provas. Estou usando "reputação negativa" como um termo técnico aqui: o caso de uso mais óbvio são críticas negativas sobre alguém, como críticas negativas ou relatos de comportamento negativo de alguém em determinados contextos; mas há outros cenários em que provas "negativas", o que não implica mau comportamento - como fazer um empréstimo para provar que você não fez muitos outros empréstimos ao mesmo tempo.
Para reclamações fora da cadeia, você pode fazer reputação positiva porque mostrá-la torna você mais respeitável (ou fazer uma prova de conhecimento zero) para o destinatário da reclamação; mas você não pode fazer reputação negativa porque as pessoas sempre optam por mostrar Faça uma declaração positiva e ignore todas as outras reivindicações ruins.
Portanto, escrever provas na cadeia pode realmente resolver os problemas acima. Para privacidade, podemos adicionar criptografia e provas de conhecimento zero: uma prova pode ser simplesmente um pedaço de dados registrado na cadeia, criptografado com a chave pública do destinatário, e o usuário pode provar que não tem reputação negativa executando um teste zero- prova de conhecimento, Isso requer percorrer todo o histórico registrado na cadeia. As provas estão na cadeia e o processo de verificação reconhece o blockchain, portanto é fácil verificar se a prova realmente atravessou todo o histórico e não pulou nenhum registro. Para viabilizar esse cálculo, os usuários podem usar cálculos verificáveis incrementalmente (como o Halo) para manter e provar uma árvore de registros, revelando partes da árvore quando necessário.
Provas de reputação negativa e revogação são, em certo sentido, um problema equivalente: você pode revogar uma prova adicionando outra prova de reputação negativa que diga "esta outra prova não é mais válida" e você pode revogar uma prova com reputação positiva Para obter a revogação de reputação negativa: o diploma de Alice da Example College pode ser revogado e substituído por um certificado de graduação que diga "Alice obteve um diploma de estudos de exemplo, mas ela plagiou muito".
** Uma reputação negativa é uma boa ideia? **
Uma crítica à reputação negativa que às vezes ouvimos é: a reputação negativa não é uma solução binária distópica de “letras escarlates” e não deveríamos tentar fazer coisas com reputação positiva? (Nota diária: a heroína do romance das letras escarlates é punida e precisa usar uma letra escarlate "A" simbolizando "adultério" em seu peito.)
Embora eu apoie o objetivo de evitar reputação negativa ilimitada, discordo da ideia de evitá-la totalmente. A reputação negativa é importante para muitos casos de uso. Os empréstimos não garantidos são extremamente valiosos para melhorar a eficiência do capital dentro e fora do espaço blockchain e podem claramente se beneficiar disso. A Unirep Social demonstrou uma plataforma de mídia social de prova de conceito que combina um alto grau de anonimato com um sistema de reputação negativa que preserva a privacidade para limitar o abuso.
Às vezes, uma reputação negativa pode fortalecer, enquanto uma reputação positiva pode ser exclusiva. Um fórum on-line onde todos têm o direito de postar até serem muito "punidos" por comportamento inadequado é mais igualitário do que um fórum que exige algum tipo de "prova de bom caráter" para poder falar. A maioria das pessoas marginalizadas que vivem "fora do sistema", por melhor que seja sua conduta, é difícil obter tal certificado.
Os leitores que são fortemente libertários pró-civis também podem considerar o caso de sistemas de reputação anônima para clientes profissionais do sexo: você quer privacidade, mas também pode querer um sistema - se um cliente abusa de uma profissional do sexo, outros podem ver e ficar longe com mais cuidado . Dessa forma, uma reputação negativa difícil de esconder pode, na verdade, fortalecer os vulneráveis e mantê-los seguros. O ponto aqui não é defender algum esquema específico para reputação negativa; em vez disso, é mostrar que a reputação negativa pode revelar um valor muito real e que um sistema bem-sucedido precisa apoiá-la de alguma forma.
A reputação negativa não precisa ser uma reputação negativa ilimitada: acho que sempre deve ser possível criar novos perfis com algum custo (possivelmente sacrificando a maior parte ou toda a reputação positiva existente). Existe um equilíbrio entre pouca responsabilidade e muita responsabilidade, e precisamos encontrar esse equilíbrio. Mas ter alguma tecnologia que possa permitir uma reputação negativa em primeiro lugar é um pré-requisito para desbloquear esse espaço de design.
4. Comprometido com a Escassez (Prova de Escassez)
Outro exemplo de valor blockchain é a emissão de um número limitado de provas. Se eu quiser endossar alguém (por exemplo, pode-se imaginar que uma empresa que esteja recrutando ou um programa de visto do governo considere tal endosso), um terceiro que veja o endosso pode se perguntar se estou desconfiado do endosso ou se é quase contanto que seja meu amigo fazendo isso. Como um pedido educado, irei endossá-los.
A solução ideal para esse problema seria tornar os endossos públicos, de forma que os endossos ficassem alinhados aos incentivos: se a pessoa que eu endossei fizesse algo errado, todos poderiam me dar um desconto no futuro. Mas, muitas vezes, também queremos proteger a privacidade. Assim, posso publicar o hash de cada endosso na cadeia para que todos possam ver quantos endossos eu emiti.
Um caso de uso mais eficiente é emitir vários de uma vez: se um artista deseja emitir N cópias de uma NFT de "edição limitada", ele pode emitir na cadeia um único hash contendo a raiz Merkle de sua NFT emitida. Um único problema os impede de emitir mais após o fato, e você pode emitir um número representando um limite (por exemplo, 100) com a raiz Merkle, o que significa que apenas os 100 ramos Merkle mais à esquerda são válidos.
Cinco, conhecimento público
Uma das propriedades poderosas dos blockchains é que eles criam conhecimento público: se eu publicar algo na cadeia, Alice pode ver; Alice pode ver Bob pode ver; Charlie pode ver Alice pode ver Até que Bob possa ver, e assim sobre.
O conhecimento comum é muitas vezes importante para a colaboração. Por exemplo, um grupo de pessoas pode querer falar sobre um assunto, mas só se sentirá confortável se um número suficiente de pessoas estiver falando ao mesmo tempo para que possam se esconder com segurança no meio da multidão. Uma maneira possível de conseguir isso é uma pessoa iniciar um "conjunto de compromissos" em torno de uma declaração específica e convidar outras pessoas a postar um hash (primeiro em particular) para indicar sua concordância. Somente se um número suficiente de pessoas participar dentro de um determinado período de tempo, todos os participantes precisarão declarar publicamente sua posição em sua próxima mensagem on-chain.
Tal projeto poderia ser implementado com uma combinação de provas de conhecimento zero e um blockchain (poderia ser feito sem um blockchain, mas isso exigiria criptografia de testemunha - não disponível atualmente; ou exigiria hardware confiável, cujas suposições de segurança são seriamente questionáveis). Há muito espaço de design em torno dessas ideias, que não é totalmente explorado hoje, mas crescerá rapidamente à medida que o ecossistema de ferramentas de blockchain e criptografia se desenvolver ainda mais.
6. Interoperabilidade com outros aplicativos blockchain
Este é um exemplo simples: algo deve estar on-chain para melhor interoperar com outros aplicativos on-chain. Provas de identidade humana como NFTs on-chain, permitindo que os projetos sejam lançados automaticamente ou concedam permissões a contas com provas de identidade humana. Colocar dados oracle on-chain facilita a leitura de projetos de finanças descentralizadas (DeFi). Nesses casos, o blockchain não elimina a necessidade de confiança, embora possa acomodar estruturas que gerenciam a confiança (como DAOs). O principal valor que existe na cadeia é simplesmente estar localizado com as coisas com as quais você está interagindo, o que requer o uso da cadeia de blocos por outros motivos.
Obviamente, você pode executar oráculos fora da cadeia e importar dados apenas quando precisar lê-los, mas, em muitos casos, isso seria realmente mais caro e introduziria complexidade e custos desnecessários para os desenvolvedores.
Sete, indicadores de código aberto
Um objetivo fundamental do papel da sociedade descentralizada é permitir a possibilidade de computação em gráficos de prova, e uma métrica muito importante é medir a descentralização e a diversidade. Por exemplo, muitas pessoas parecem pensar que o mecanismo de votação ideal permitiria a diversidade, dando mais peso a projetos que não são apenas apoiados por um grande número de tokens e até humanos, mas apoiados por pontos de vista genuinamente diversos.
Outra coisa que pode tornar a medição e a pontuação valiosas são os sistemas de reputação. Isso já existe nas avaliações de forma centralizada, mas pode ser feito de forma mais descentralizada, tornando o algoritmo transparente e protegendo mais a privacidade do usuário ao mesmo tempo.
Além de casos de uso fortemente acoplados como este (tentar medir o quão conectado alguém está e alimentar isso diretamente no mecanismo), há casos de uso mais amplos para ajudar uma comunidade a entender a si mesma. Quando se trata de medir a descentralização, áreas excessivamente concentradas podem precisar responder. Nesses casos, é inevitável executar algoritmos de computador em um grande número de provas e compromissos e executar operações realmente importantes na saída.
Em vez de tentar abolir as métricas quantitativas, deveríamos tentar criar métricas melhores
Kate Sills expressa seu ceticismo sobre calcular metas de reputação, um argumento que se aplica tanto à análise pública quanto a ZKs individuais que comprovam sua reputação (como Unirep Social): "O processo de avaliação de reclamações é muito subjetivo e dependente do contexto. Pessoas Haverá naturalmente desacordos sobre a credibilidade dos outros, e a confiança depende do contexto... (portanto) devemos ser extremamente céticos em relação a todas as propostas que afirmam que a 'computação' produz resultados objetivos."
Nesse caso, concordo que a subjetividade e o contexto precisam ser levados em consideração, mas discordo da afirmação de que evitar cálculos em torno da reputação é a coisa certa a fazer. A análise individualizada pura não irá muito além do "número de Dunbar", e qualquer sociedade complexa que tente apoiar a cooperação em larga escala deve contar com agregação e simplificação até certo ponto. (Nota diária: o número de Dunbar também é chamado de "a lei dos 150", que se refere ao limite máximo do número de pessoas que podem manter um relacionamento interpessoal próximo com uma determinada pessoa, geralmente considerado 150.)
Dito isso, acho que um ecossistema de prova aberto e participativo (em oposição ao ecossistema centralizado que temos hoje) pode alcançar o melhor dos dois mundos abrindo espaço para melhores métricas. Aqui estão alguns princípios que tais projetos podem seguir:
Intersubjetividade: por exemplo, a reputação não deve ser uma classificação global única; em vez disso, deve ser um cálculo mais subjetivo envolvendo a pessoa ou entidade que está sendo avaliada, o observador que visualiza a classificação e talvez até mesmo outros aspectos do ambiente local.
Neutralidade credível: O programa claramente não deve deixar espaço para elites poderosas manipulá-lo constantemente para seu próprio benefício. Algumas maneiras possíveis de conseguir isso são transparência máxima e menos alterações nos algoritmos.
Abertura: A capacidade de ter uma contribuição significativa e de examinar a produção dos outros por si mesmo deve estar aberta a qualquer pessoa, não apenas a alguns grupos poderosos.
Se não criarmos uma boa agregação de dados sociais em escala, corremos o risco de perder participação de mercado para uma pontuação de crédito social opaca e centralizada.
Nem todos os dados devem estar on-chain, mas expor alguns dados de maneira sensata pode ajudar a melhorar a legibilidade da comunidade para si mesma sem criar discrepâncias no acesso aos dados que poderiam ser abusadas para controle centralizado.
Oito, como armazenamento de dados
Este é um caso de uso realmente controverso, embora muitas pessoas adotem outros casos de uso de blockchain. No espaço blockchain, existe uma visão geral de que blockchains só devem ser usados quando houver uma necessidade real e não puder ser evitada, e que em outros lugares devemos usar outras ferramentas.
Em um mundo onde as taxas de transação são muito caras e os blockchains são terrivelmente ineficientes, esse argumento faz sentido. Mas em um blockchain com rollups e sharding e taxas de transação reduzidas a centavos, essa ideia é menos plausível. Em tal mundo, a diferença de redundância entre blockchain e armazenamento descentralizado não-blockchain pode ser apenas um fator de 100.
Mesmo em tal mundo, seria imprudente armazenar todos os dados na cadeia. Mas e os pequenos registros de texto? Absolutamente. Por que? Porque o blockchain é realmente um lugar muito conveniente para armazenar coisas. Eu mantenho uma cópia deste blog no IPFS. Mas o upload para o IPFS normalmente leva uma hora e requer gateways centralizados para fornecer acesso aos usuários em velocidades que se aproximam da latência no nível do site e, às vezes, os arquivos desaparecem e não podem mais ser visualizados. Por outro lado, despejar todo o blog on-chain resolveria completamente esse problema. É claro que, mesmo após a fragmentação, o blog é muito grande para realmente ser despejado na cadeia, o mesmo princípio se aplica a registros menores,
Alguns exemplos de pequenos casos de uso em que os dados podem ser armazenados na cadeia incluem:
Compartilhamento de segredo aprimorado: Divida a senha em N partes, onde qualquer parte M = NR pode recuperar a senha, mas você pode escolher o conteúdo de todas as N partes. Por exemplo, essas peças podem ser hashes de senhas, segredos gerados por outras ferramentas ou respostas a perguntas de segurança. Publicando partes R adicionais na cadeia (aparentemente aleatoriamente) e compartilhando segredos N-de-(N+R) para todo o conjunto.
Otimização ENS. O ENS pode se tornar mais eficiente combinando todos os registros em um hash, publicando apenas o hash na cadeia e exigindo que qualquer pessoa que acesse os dados busque os dados completos do IPFS. Mas isso adiciona uma complexidade significativa e aumenta a dependência de outro software. Portanto, mesmo que o comprimento de dados do ENS exceda 32 bytes, ele permanecerá na cadeia.
Metadados sociais - Dados associados à sua conta (por exemplo, para um login Ethereum) que você deseja tornar públicos e muito curtos. Isso é bom para registros de texto, mas geralmente não para dados maiores, como uma foto de perfil (que pode funcionar se a foto for um pequeno arquivo SVG).
Autenticação e direitos de acesso. Especialmente quando os dados armazenados têm menos de algumas centenas de bytes, pode ser mais conveniente armazenar os dados na cadeia do que colocar o hash na cadeia e os dados fora da cadeia.
Em muitos casos, a compensação não é apenas o custo, mas também a privacidade no caso extremo de chaves ou senhas comprometidas. Às vezes, a privacidade importa apenas até certo ponto e, em vez de se preocupar com chaves vazadas ou com a perda ocasional de privacidade da computação quântica, é melhor garantir que os dados sempre possam ser acessados de maneira confiável. Afinal, os dados fora da cadeia armazenados em sua "carteira de dados" também podem ser hackeados.
Mas, às vezes, os dados são particularmente confidenciais, e isso pode ser apenas outro argumento contra colocá-los na cadeia e armazená-los localmente como uma segunda camada de defesa. Observe, no entanto, que nesses casos a necessidade de privacidade é um argumento não apenas contra blockchains, mas contra todo armazenamento descentralizado.
para concluir
Da lista acima, os dois casos de uso em que pessoalmente me sinto mais confiante agora são "interoperabilidade com outros aplicativos blockchain" e "gerenciamento de contas". O primeiro já está na cadeia, o segundo é relativamente barato (precisa usar a cadeia uma vez por usuário, não uma vez por operação), tem um caso claro para isso e realmente não possui uma boa solução não baseada em blockchain .
"Reputação negativa" e "revogação da certificação" também são importantes, embora ainda sejam casos de uso relativamente antigos. Você pode fazer muito com a reputação confiando apenas na reputação positiva fora da cadeia, mas espero que os casos de revogação e reputação negativa se tornem mais claros com o tempo. Prevejo que alguém tentará fazer isso com um servidor centralizado, mas com o tempo deve ficar claro para todos: blockchain é a única forma de evitar a difícil escolha entre inconveniência e centralização.
Blockchains como armazenamento de dados para registros de texto curtos podem ser triviais ou significativos, mas espero que esses tipos de uso pelo menos continuem a acontecer. O Blockchain é realmente útil para recuperação de dados confiável e de baixo custo, independentemente de o aplicativo ter dois usuários ou dois milhões de usuários, os dados podem continuar a ser recuperados.
As métricas de código aberto ainda estão em um estágio conceitual muito inicial e resta saber o quanto elas podem fazer sem serem exploradas (como análises on-line, classificações de mídia social, etc. são frequentemente exploradas). E o jogo do conhecimento comum precisa convencer as pessoas a aceitar fluxos de trabalho inteiramente novos para coisas socialmente importantes, então certamente é uma ideia em estágio inicial também.
Não tenho certeza da extensão exata do uso de blockchain não financeiro nessas categorias, mas está claro que o blockchain como uma ferramenta capacitadora nessas áreas não deve ser descartado.