Os 'modelos de confiança' merecem seu título?

Uma das propriedades mais valiosas de muitos aplicativos blockchain é a falta de confiança : a capacidade do aplicativo de continuar operando da maneira esperada sem precisar depender de um ator específico para se comportar de uma maneira específica.

Mesmo quando seus interesses podem mudar e levá-los a agir de alguma maneira diferente e inesperada no futuro.

Os aplicativos Blockchain nunca são totalmente confiáveis, mas alguns aplicativos estão muito mais próximos de serem confiáveis do que outros. Se quisermos fazer movimentos práticos em direção à minimização da confiança, queremos ter a capacidade de comparar diferentes graus de confiança.

Primeiro, minha definição simples de confiança em uma frase: confiança é o uso de quaisquer suposições sobre o comportamento de outras pessoas . Se antes da pandemia você andava na rua sem se certificar de manter dois metros de distância de estranhos para que eles não pudessem de repente pegar uma faca e esfaquear você, isso é uma espécie de confiança: ambos confiam que as pessoas raramente são completamente perturbadas , e confio que as pessoas que administram o sistema jurídico continuem a fornecer fortes incentivos contra esse tipo de comportamento.

Quando você executa um pedaço de código escrito por outra pessoa, você confia que ela escreveu o código honestamente (seja devido ao seu próprio senso de decência ou devido a um interesse econômico em manter sua reputação), ou pelo menos que existem pessoas suficientes verificando o código que um bug seria encontrado.

Não cultivar sua própria comida é outro tipo de confiança: confiar que um número suficiente de pessoas perceberá que é do interesse delas cultivar alimentos para que possam vendê-los a você. Você pode confiar em diferentes tamanhos de grupos de pessoas e existem diferentes tipos de confiança.

Para fins de análise de protocolos blockchain, costumo dividir a confiança em quatro dimensões:

• Quantas pessoas você precisa para se comportar como você espera?

  
  

• De quantos?

  
  

• Que tipos de motivações são necessárias para que essas pessoas se comportem? Eles precisam ser altruístas ou apenas em busca de lucro? Eles precisam ser descoordenados ?

  
  

• Até que ponto o sistema falhará se as suposições forem violadas?

Por ora, vamos nos concentrar nos dois primeiros. Podemos desenhar um gráfico:

Quanto mais verde, melhor. Vamos explorar as categorias com mais detalhes:

• 1 de 1 : existe exatamente um ator e o sistema funciona se (e somente se) esse ator fizer o que você espera que ele faça. Este é o modelo tradicional "centralizado" e é o que estamos tentando fazer melhor.

  
  

• N de N : o mundo "distópico". Você conta com um monte de atores, todos os quais precisam agir conforme o esperado para que tudo funcione, sem backups se algum deles falhar.

  
  

• N/2 de N : é assim que os blockchains funcionam - eles funcionam se a maioria dos mineradores (ou validadores de PoS) forem honestos. Observe que N/2 de N se torna significativamente mais valioso quanto maior for o N; uma blockchain com alguns mineradores/validadores dominando a rede é muito menos interessante do que uma blockchain com seus mineradores/validadores amplamente distribuídos. Dito isso, queremos melhorar até mesmo esse nível de segurança, daí a preocupação em sobreviver a ataques de 51% .

  
  

• 1 de N : existem muitos atores e o sistema funciona desde que pelo menos um deles faça o que você espera. Qualquer sistema baseado em provas de fraude se enquadra nessa categoria, assim como configurações confiáveis, embora nesse caso o N seja geralmente menor. Observe que você deseja que o N seja o maior possível!

  
  

• Poucos de N : há muitos atores, e o sistema funciona desde que pelo menos um pequeno número fixo deles faça o que você espera que eles façam. As verificações de disponibilidade de dados se enquadram nessa categoria.

  
  

• 0 de N : os sistemas funcionam como esperado sem nenhuma dependência de atores externos. Validar um bloco verificando-o você mesmo se enquadra nessa categoria.

Embora todos os baldes diferentes de "0 de N" possam ser considerados "confiáveis", eles são muito diferentes uns dos outros!

Confiar que uma determinada pessoa (ou organização) funcionará conforme o esperado é muito diferente de confiar que uma única pessoa em qualquer lugar fará o que você espera que ela faça.

"1 de N" é indiscutivelmente muito mais próximo de "0 de N" do que de "N/2 de N" ou "1 de 1". Um modelo 1 de N talvez pareça um modelo 1 de 1 porque parece que você está passando por um único ator, mas a realidade dos dois é muito diferente: em um sistema 1 de N, se o ator com quem você está trabalhando no momento desaparecer ou se tornar mau, você pode simplesmente mudar para outro, enquanto em um sistema 1 de 1 você está ferrado.

Particularmente, observe que mesmo a correção do software que você está executando normalmente depende de um modelo de confiança "alguns de N" para garantir que, se houver erros no código, alguém os detectará.

Com esse fato em mente, tentar muito ir de 1 de N a 0 de N em algum outro aspecto de um aplicativo é como fazer uma porta de aço reforçado para sua casa quando as janelas estão abertas.

Outra distinção importante é: como o sistema falha se sua suposição de confiança for violada? Em blockchains, dois tipos mais comuns de falha são falha de vivacidade e falha de segurança .

Uma falha de vivacidade é um evento no qual você fica temporariamente incapaz de fazer algo que deseja (por exemplo, sacar moedas, obter uma transação incluída em um bloco, ler informações do blockchain).

Uma falha de segurança é um evento no qual algo acontece ativamente que o sistema deveria evitar (por exemplo, um bloco inválido é incluído em um blockchain).

Aqui estão alguns exemplos de modelos de confiança de alguns protocolos da camada 2 da blockchain. Eu uso " pequeno N " para me referir ao conjunto de participantes do próprio sistema da camada 2, e " big N " para me referir aos participantes do blockchain; a suposição é sempre que o protocolo da camada 2 tem uma comunidade menor que a própria blockchain.

Também limito meu uso da palavra "falha de vivacidade" a casos em que as moedas ficam presas por um período de tempo significativo; não ser mais capaz de usar o sistema, mas ser capaz de retirar quase instantaneamente não conta como uma falha de vivacidade.

• Canais (incluindo canais de estado, rede relâmpago): 1 de 1 confiança para vivacidade (sua contraparte pode congelar temporariamente seus fundos, embora os danos disso possam ser mitigados se você dividir moedas entre várias contrapartes), N/2 de confiança big-N por segurança (um ataque blockchain 51% pode roubar suas moedas)

  
  

• Plasma (assumindo operador centralizado): 1 de 1 confiança para vivacidade (o operador pode congelar temporariamente seus fundos), N/2 de big-N confiança para segurança (ataque de 51% em blockchain).

  
  

• Plasma (assumindo operador semi-descentralizado, por exemplo, DPOS): N/2 de confiança de N pequeno para vivacidade, N/2 de confiança de N grande para segurança.

  
  

• Rollup otimista : 1 de 1 ou N/2 de confiança pequena N para vivacidade (depende do tipo de operador), N/2 de confiança grande N para segurança.

  
  

• ZK rollup : 1 de small-N trust para vivacidade (se o operador não incluir sua transação, você pode retirar, e se o operador não incluir sua retirada imediatamente, ele não pode produzir mais lotes e você pode retirar sozinho com a ajuda de qualquer nó completo do sistema rollup); sem riscos de falha de segurança

  
  

• ZK rollup (com aprimoramento de retirada de luz ) : sem riscos de falha de vivacidade, sem riscos de falha de segurança

Finalmente, há a questão dos incentivos: o ator em quem você confia precisa ser muito altruísta para agir como esperado, apenas um pouco altruísta, ou ser racional é suficiente? A busca por provas de fraude é "por padrão" ligeiramente altruísta, embora o quão altruísta seja depende da complexidade da computação (veja o dilema do verificador ), e há maneiras de modificar o jogo para torná-lo racional.

Ajudar outras pessoas a se retirar de um rollup ZK é racional se adicionarmos uma maneira de micropagar pelo serviço, portanto, há realmente poucos motivos para preocupação de que você não consiga sair de um rollup com qualquer uso significativo.

Enquanto isso, os maiores riscos dos outros sistemas podem ser atenuados se concordarmos como comunidade em não aceitar cadeias de ataque de 51% que revertem muito longe na história ou censuram bloqueios por muito tempo.

Conclusão: quando alguém disser que um sistema "depende da confiança", pergunte com mais detalhes o que ele quer dizer! Eles significam 1 de 1, ou 1 de N, ou N/2 de N? Eles estão exigindo que esses participantes sejam altruístas ou apenas racionais? Se altruísta, é uma despesa pequena ou uma despesa enorme?

E se a suposição for violada - você só precisa esperar algumas horas ou dias ou possui ativos que estão parados para sempre? Dependendo das respostas, sua própria resposta para usar ou não esse sistema pode ser muito diferente.

Originalmente publicado como “ Trust Models ”