Até agora, o mito do bem-estar no círculo monetário/indústria de blockchain continua, e a próxima área importante de "criação de riqueza" está focada na "pista de jogo". O projeto XAI está realizando um evento Odyssey. Se você estiver interessado, participe deste meu artigo na praça: Guia para iniciantes com custo zero do evento XAI Game Public Chain Odyssey.
Neste artigo, trarei para vocês uma explicação detalhada do nó Sentinela da cadeia pública do jogo XAI! Este artigo é relativamente técnico, portanto, se você estiver interessado em ganhar dinheiro, deverá lê-lo com atenção. Porque somente se você mesmo entender a “lógica” e melhorar sua cognição, poderá ter a oportunidade de ganhar dinheiro!
Se você quiser ver diretamente sobre o nó Sentry, leia a primeira parte diretamente sem ler depois; se quiser um loop lógico fechado, então você precisa ler a segunda, terceira e quarta partes!
O que quero enfatizar é que Xai recebe suporte técnico direto do Offchain Labs. Este tipo de suporte é inimaginável para outras cadeias Orbit! e é um componente chave do plano estratégico de Xai dentro do ecossistema Arbitrum.
Parte 1: Explicação do nó sentinela
O nó Sentry é um nó de observação que monitoriza o protocolo rollup Xai e se um bloco defeituoso for proposto, emitirá um alerta (por qualquer meio que o seu operador escolher) para que outros possam intervir. O objetivo do nó sentinela é resolver o dilema do verificador (ver Parte IV para obter detalhes sobre o dilema do verificador).
Clique aqui para ver o vídeo promocional:
Promoção de vídeo do Sentinel Node
Execute nós Xai e obtenha tokens Xai com um clique!
Os nós Sentinel podem ser executados em laptops, desktops ou até mesmo em instâncias de nuvem dos membros da comunidade. Enquanto o nó estiver em execução, existe um algoritmo probabilístico que determina se o operador do nó será recompensado com tokens esXai da rede. Ao apostar Xai, você aumenta a probabilidade do algoritmo. Se você não conhece o esXai, participe do meu artigo na praça: Interpretação da “Economia Token” do projeto XAI
1. Princípio de funcionamento do nó sentinela
O protocolo Attention Challenge v2 envolve vários participantes, incluindo a cadeia Xai, uma cadeia pai (Arbitrum One), um desafiante confiável, sentinelas Xai e suas chaves de licença, e um contrato de árbitro (árbitro). O desafiante cria um par de chaves BLS, registra a chave pública no contrato de árbitro e assina as reivindicações feitas pelo validador no protocolo cumulativo Xai no Arbitrum One. Estas assinaturas são verificadas pelo contrato do árbitro e registadas como contestações associadas à reclamação.
Os Xai Sentinels podem registar-se no contrato de árbitro através da compra de uma chave de licença do Sentinel para serem elegíveis para publicar declarações sobre reivindicações. Eles obtêm a raiz de estado da instrução correta que será a sucessora da instrução emissora. Se uma determinada condição for satisfeita, eles emitem uma declaração sobre a declaração invocando o contrato do árbitro. Se uma declaração de acompanhamento for criada e confirmada, e o Sentinel emitir a declaração correta, o Sentinel entrará em contato com o contrato de referência para emitir uma transação de resgate. O árbitro verificará diversas condições antes de pagar a recompensa ao Sentinela.
Esse protocolo garante que cada declaração consuma totalmente as mensagens da caixa de entrada que existiam quando sua declaração antecessora foi criada. Isto significa que uma vez criada uma declaração, as raízes de estado das suas declarações subsequentes corretas são totalmente determinadas e podem ser computadas por qualquer nó. Isso incentiva cada sentinela a determinar a próxima raiz de estado correta. A recompensa da sentinela é determinada pelo ID de permissão do estado da sentinela, pela raiz do estado subsequente e por um valor de desafio que não se torna conhecido até que a raiz do estado subsequente seja totalmente determinada.
2. Quem pode executar o nó?
Qualquer pessoa pode operar o Sentinel baixando o software, instalando-o e executando-o. No entanto, para receber recompensas simbólicas, pelo menos uma chave de licença do Sentinel deve ser adquirida.
Os compradores devem passar com êxito em uma verificação KYC para garantir que:
não nos Estados Unidos
Não sujeito a quaisquer sanções do OFAC dos EUA (o OFAC está refletido em uma lista de sanções dos EUA)
Os nós Sentinel que não estão em execução ou não possuem os fundos apropriados para pagar as taxas de gás (GAS) não acumularão recompensas, mesmo com uma chave de licença. Portanto, as operadoras desejarão garantir que seus nós sejam financiados, online e em funcionamento.
3. Contrato de árbitro (árbitro)
Referee é um contrato inteligente projetado para garantir o cumprimento de regras predefinidas, verificar a origem dos envios e distribuir recompensas aos vencedores dentro do sistema. O contrato inteligente de árbitro é um componente chave no ecossistema Xai, responsável por gerir e validar as reivindicações feitas pelos nós sentinela na rede. O contrato tem várias funções principais:
3.1 Envio de declaração
O contrato de árbitro permite que os nós sentinela enviem reivindicações aos desafios. Esta função só pode ser chamada pelo proprietário da chave de licença do Sentinel ou pelo endereço aprovado neste contrato. Esta função verifica se o desafio ainda está aberto para envio e se uma NodeLicense já foi enviada para este desafio.
3.2 Receba recompensas
O contrato contém um recurso que permite aos usuários reivindicar recompensas por reivindicações bem-sucedidas. Esta função verifica se o desafio foi fechado para envio e se o proprietário da chave do nó concluiu o KYC. Se essas condições forem atendidas e a reivindicação for elegível para pagamento, a recompensa será enviada ao usuário.
3.3 Crie hash de reivindicação e verifique o pagamento.
O contrato tem uma função que cria um hash do ID de permissão sentinela, ID do desafio, challengerSignedHash no desafio e raiz de estado subsequente. Em seguida, ele verifica se o hash está abaixo de um determinado limite, que é calculado com base no número total de licenças Sentinel emitidas. Se o hash estiver abaixo do limite, a reivindicação será elegível para pagamento.
O contrato de árbitro garante a integridade da rede Xai, validando as reivindicações e recompensando as bem-sucedidas, incentivando assim os nós sentinela a monitorizarem a rede com precisão e diligência.
4. Componente desafiador
O desafiante é uma entidade confiável no ecossistema Xai. Ele cria um par de chaves BLS e registra a chave pública no contrato de referência. Quando um validador faz uma reclamação no protocolo rollup Xai, o desafiante assina a reclamação usando a sua chave privada e submete a assinatura ao árbitro. O árbitro verifica a assinatura e registra-a como um desafio associado à declaração. Este processo garante a integridade das reivindicações feitas no protocolo cumulativo Xai.
5. Chave (permissão de chave do nó Sentinel, baseada em NFT)
A chave de licença do Sentinel é um token não fungível (NFT) exclusivo necessário para operar um nó Sentinel na rede Xai. As licenças Sentinel servem como prova de elegibilidade para que os nós enviem reivindicações e recebam recompensas. É cunhado enviando a quantidade correta de ETH, e o preço da cunhagem é determinado por um sistema de limite crescente.
O licenciamento de nós desempenha um papel fundamental no contrato de árbitro. Quando um nó deseja enviar uma reivindicação para um desafio, ele deve fornecer seu ID de permissão do Sentinel. O contrato de referência verifica se a licença do Sentinel é válida e se o nó é o proprietário da licença do Sentinel ou um operador aprovado (seção KYC acima). Se estas condições forem atendidas, a reivindicação do nó é submetida ao desafio.
As permissões do Sentinel também entram em jogo ao reivindicar recompensas por reivindicações bem-sucedidas. O contrato de referência verifica se o proprietário da licença Sentinel completou o KYC e se o extrato é elegível para pagamento. Se essas condições forem atendidas, a recompensa será enviada ao proprietário da licença Sentinel.
Em resumo, a permissão Sentinel é um componente chave na rede Xai, que regula o funcionamento dos nós Sentinel, a apresentação de reclamações e a distribuição de recompensas.
6. Baixe e execute o nó
Para executar um nó sentinela, os usuários só precisam baixar um pacote de software específico. Este pacote pode ser usado em um aplicativo de desktop ou como uma ferramenta de linha de comando em seu computador. Simplificando, esses aplicativos são ferramentas que tornam o software Sentinel mais fácil de usar. O objetivo deste pacote é automatizar todas as operações necessárias para executar o Sentinel, tornando-o muito simples de configurar e usar, mesmo que você não seja técnico.
Este pacote ajuda os usuários em tarefas como configuração, gerenciamento e interação com outras partes e possui uma interface fácil de usar que permite aos usuários visualizar e ajustar as configurações facilmente. Usando este pacote, os usuários podem se concentrar mais em como funcionar melhor e obter mais recompensas simbólicas. Os usuários podem optar por executar este pacote usando um aplicativo de desktop ou uma ferramenta de linha de comando, ambos muito fáceis de usar e tornam o processo de operação muito tranquilo.
7. Função de carteira Sentinela
No ecossistema Xai, a carteira Sentinel desempenha um papel fundamental na interação entre os nós Sentinel e os contratos inteligentes de arbitragem. A Sentinel Wallet atua como um agente intermediário e é responsável por enviar declarações ao árbitro em nome dos Sentinelas relevantes. Isto é conseguido através de funções específicas no contrato de referência que só podem ser chamadas pelo proprietário da chave de licença do Sentinel ou pelo endereço aprovado neste contrato.
A carteira Sentinel pode enviar uma declaração para o desafio chamando a função submitAssertionToChallenge no contrato de referência. Esta função verifica se o desafio ainda está aberto para envio e se a chave do nó já foi enviada para este desafio.
A Sentry Wallet também pode reivindicar recompensas por reivindicações bem-sucedidas, chamando a função ClaimReward no contrato de referência. Este recurso verifica se o desafio foi fechado para envio e se o proprietário da licença Sentinel concluiu uma verificação "KYC". Se essas condições forem atendidas e a reivindicação for elegível para pagamento, a recompensa será enviada ao proprietário do Sentinel.
Em resumo, a Carteira Sentinel atua como um mensageiro, facilitando a interação entre nós e árbitros, garantindo assim o bom funcionamento da rede Xai.
8. Licença
A relação entre o número de licenças e as capacidades de submissão do nó é fundamental. Embora seja possível que um nó tenha múltiplas licenças associadas a ele, é importante perceber que o número de licenças afeta diretamente a capacidade de commit do nó. Essencialmente, para garantir cotas de compromisso justas, a proporção de licenças para instâncias de nós é mantida em 1:1. Seguindo os princípios acima, o sistema estabelece uma abordagem estruturada para licenciamento, submissão de direitos e operação geral de nós dentro do ecossistema.
9. Requisitos de software e hardware do nó sentinela
O software do nó Sentinel suporta desktop Windows, Mac e Linux (requer 64 bits). A seguir estão os recursos atuais necessários para executar o software do nó Sentinel para até 100 chaves de licença:
4 GB de RAM
2 núcleos de CPU
60 GB de espaço em disco
Processador x86/X64 (suporta processador ARM, como chip Apple M1/M2)
Conexão de internet estável
Ao adicionar chaves adicionais a um nó, o ideal é que os recursos de hardware aumentem de acordo. Contudo, não é obrigatório atribuir uma máquina separada a cada chave. Espera-se que o sistema seja escalável para acomodar dezenas de chaves em uma única máquina, e possivelmente mais.
Nota: Esses requisitos de hardware estão sujeitos a alterações.
10. Recompensas estimadas da rede do nó Sentry
Modelo econômico do token XAI, consulte: Interpretação da "Economia Token" do projeto XAI
Aqui estão três cenários para estimar as recompensas Xai que você pode ganhar ao executar um nó Sentry. Esses três cenários são baseados nas seguintes suposições:
A soma de XAI e esXAI nunca ultrapassará 2.500.000.000. Dado que o ecossistema Xai é dinâmico, é impossível prever com precisão as recompensas mensais de tokens para cada chave Sentry.
100% do GÁS é queimado, então não há garantia de que a oferta será sempre inflacionária, pode ser deflacionária.
A Fundação Xai não venderá mais de 50.000 chaves Sentry (um nó pode carregar múltiplas chaves). Espera-se que isso leve de 2 a 3 anos. As chaves de sentinela ficam mais caras com o tempo.
O valor mensal de esXAI por chave Sentry também pode variar com base no número de participantes de staking no ecossistema.
O significado das três tabelas a seguir é que, sob diferentes circulações de tokens XAI e esXAI, o número de chaves de nó ativadas na rede e as recompensas de token mensais esperadas correspondentes por chave:
Estimativa do cenário A: Se houver um total de 750.000 tokens XAI e esXAI em circulação, cada chave Sentry receberá recompensas esXAI de acordo com a tabela a seguir:
Estimativa do Cenário B: Se houver um total de 1.250.000.000 tokens XAI e esXAI em circulação, então cada chave Sentry receberá recompensas esXAI de acordo com a tabela a seguir:
Estimativa do Cenário C: Se houver um total de 2.187.500.000 tokens XAI e esXAI em circulação, então cada chave Sentry receberá recompensas esXAI de acordo com a tabela a seguir:
Parte 2: XAI é desenvolvido e mantido pela Arbitrum (ARB), então temos que esclarecer a arquitetura da Arbitrum:
1. Decisão Nitro
Todas as cadeias Arbitrum são construídas em Arbitrum Nitro, que é a tecnologia subjacente para todas as cadeias do ecossistema. O Nitro executa uma versão bifurcada do Geth e usa o WebAssembly como sua máquina virtual subjacente à prova de fraude.
2. Qualquer decisão de confiança
Anytrust é um protocolo Arbitrum que gerencia a disponibilidade de dados por meio de um conjunto de licenciadores denominado Comitê de Disponibilidade de Dados (DAC). Este protocolo reduz as taxas de transação ao introduzir uma suposição de confiança adicional em relação à disponibilidade de dados, em vez de usar o mecanismo de disponibilidade de dados sem confiança do Ethereum.
3. Introdução ao Arbitrum 2 camadas que você talvez conheça
Arbitrum Nova é um exemplo de cadeia AnyTrust; Arbitrum One é outra cadeia alternativa que implementa o protocolo Arbitrum Rollup puramente sem confiança (e mais intensivo em gás L1). Ambas as cadeias são construídas em Nitro.
4. Cadeia orbital
O Arbitrum Orbit permite que terceiros criem suas próprias cadeias Arbitrum Rollup e AnyTrust autogerenciadas. A Arbitrum oferece tecnologias Rollup e AnyTrust para máxima flexibilidade na construção de cadeias Orbit. Como todas as cadeias do ecossistema Arbitrum, tanto a Arbitrum Rollups quanto a cadeia Arbitrum Anytrust Orbit são construídas usando Nitro como tecnologia subjacente.
5. Compreender a situação básica do Xai
Vamos entender Xai no contexto acima. Xai opera como uma rede Arbitrum Orbit, aproveitando a tecnologia Anytrust para velocidade máxima e custo mínimo. Ao contrário da maioria das cadeias Orbit “autogovernadas”, Xai se beneficia do suporte técnico direto do Offchain Labs. Este tipo de suporte é inimaginável para outras cadeias Orbit! e é um componente chave do plano estratégico de Xai dentro do ecossistema Arbitrum.
Parte 3: Depois de ter os conceitos acima, vamos entender melhor a arquitetura:
1.AnyTrust: infraestrutura revolucionária de blockchain
Dentro da estrutura AnyTrust e como uma variante de ponta da tecnologia Arbitrum Nitro, o Offchain Labs aproveita a inovação para resolver alguns dos desafios mais urgentes no espaço blockchain. AnyTrust nos traz uma nova perspectiva ao incorporar suposições leves de confiança, reduzindo significativamente os custos e garantindo forte disponibilidade e segurança de dados.
2. Reduza custos através de premissas de confiança
No núcleo do protocolo Arbitrum, todos os nós da Arbitrum (incluindo validadores que verificam a exatidão da cadeia e apostam nos resultados precisos) precisam acessar os dados de cada transação da camada dois (L2) na caixa de entrada da cadeia Arbitrum. Tradicionalmente, o rollup do Arbitrum garante o acesso aos dados publicando dados como dados de chamada na camada um (L1) Ethereum, um processo que gera taxas de gás Ethereum significativas, que é um importante componente de custo no Arbitrum.
3.Flexibilidade de conjuntos
Ketsets desempenham um papel fundamental na arquitetura do AnyTrust. Especificam as chaves públicas dos membros do comitê e o número de assinaturas necessárias para verificar o Certificado de Disponibilidade de Dados (DACert). Os Ketsets fornecem flexibilidade para alterar os membros do comitê e permitem que os membros do comitê atualizem suas chaves conforme necessário.
4. Certificados de Disponibilidade de Dados (DACerts)
No AnyTrust, um conceito básico é o certificado de disponibilidade de dados (DACert). Um DACert consiste no hash do bloco de dados, um prazo de expiração e uma prova de que os membros do comitê N-1 assinaram o par (hash, prazo de expiração). Esta prova inclui um hash do conjunto de chaves usado para a assinatura, um bitmap indicando quais membros do comitê assinaram e uma assinatura agregada BLS na curva BLS12-381, comprovando o signatário.
Devido à suposição de confiança 2 de N, o DACert serve como prova de que os dados de um bloco estarão disponíveis para pelo menos um membro honesto do comitê até um prazo de expiração especificado. Esta suposição de confiança é a base para a confiabilidade e segurança da disponibilidade de dados dentro da estrutura AnyTrust.
5. Mecanismo duplo de liberação de dados
AnyTrust introduz um método duplo de publicação de blocos de dados em L1. Além do método tradicional de publicação de blocos completos de dados, também permite a emissão de DACerts, que são certificados que comprovam a disponibilidade dos dados. O contrato de caixa de entrada L1 verifica a validade dos DACerts, incluindo referência aos Kesets válidos especificados no DACerts.
O código L2 responsável pela leitura dos dados da caixa de entrada foi projetado para lidar perfeitamente com ambos os formatos de dados. Quando um DACert é encontrado, ele realiza verificações de validade, incluindo garantir que o número de assinantes atenda aos requisitos do Ketsets, validando assinaturas agregadas e confirmando a expiração além do carimbo de data/hora L2 atual. DACerts válidos garantem que o bloco de dados esteja acessível e possa ser explorado pelo código L2.
6. Servidor de Disponibilidade de Dados (DAS)
Os membros do comitê operam o Data Availability Server (DAS), que fornece duas APIs principais:
(1) API do classificador: projetada para uso pelo classificador da cadeia Arbitrum, esta interface JSON-RPC permite que o classificador envie blocos de dados ao DAS para armazenamento.
(2) API REST: Projetado para maior acessibilidade, o protocolo RESTful baseado em HTTP(S) permite a recuperação de blocos de dados via hash. Ele é totalmente armazenável em cache e pode ser implantado em conjunto com proxies de cache ou CDNs para aumentar a escalabilidade e proteger contra possíveis ataques DoS.
7. Interação Classificador-Comitê
Quando o classificador Arbitrum pretende publicar um lote de dados através do comitê, ele envia os dados e um prazo de validade para todos os membros do comitê em paralelo via RPC. Cada membro do comitê armazena os dados, assina o par (hash, tempo de expiração) usando sua chave BLS e retorna a assinatura e o indicador de sucesso ao sequenciador. Depois que assinaturas suficientes são coletadas, o sequenciador as agrega para criar um DACert válido para pares (hash, tempo de expiração). Este DACert é então publicado no contrato de caixa de entrada L1, tornando-o acessível ao software da cadeia AnyTrust da L2. Caso o sequenciador não consiga coletar assinaturas suficientes dentro do período de tempo especificado, ele adota uma estratégia de "substituição para rollup" e publica os dados completos diretamente na cadeia L1. O software L2 se destaca na compreensão de ambos os formatos de publicação de dados (via DACert ou dados completos) e no tratamento adequado de cada formato. Em resumo, AnyTrust, como uma inovação revolucionária dentro do ecossistema Offchain Labs, representa um avanço crítico no tratamento da disponibilidade de dados, segurança e eficiência de custos da infraestrutura blockchain. Através de uma suposição de confiança sensata e de uma nova abordagem para publicação de dados, AnyTrust abre caminho para soluções blockchain mais escaláveis, acessíveis e seguras.
Parte 4: Com os conceitos acima em mente, vamos agora explicar porque os nós sentinela são importantes: o problema da verificação do trapaceiro, porque o dilema do validador é mais difícil do que você pensa e a solução!
O autor é Ed Felten, cientista-chefe da Arbitrum
Em sistemas blockchain, um padrão de design comum é fazer com que uma parte faça algum trabalho e garanta um depósito por comportamento correto e, em seguida, convide outras pessoas para verificar o trabalho e retirar esse depósito se pegarem o trabalhador trapaceando. Você poderia chamá-lo de padrão de design "desafio de afirmação". Fazemos isso no Arbitrum e vimos propostas como o Optimistic Rollup nas notícias recentemente.
Esses sistemas podem ser afetados pelo dilema do validador, que é basicamente a observação de que não faz sentido verificar o trabalho de alguém se você sabe que ele não trapaceará, mas se você não verificar, ele terá um incentivo para trapacear; Se você é um designer, quer provar que seu sistema é compatível com incentivos, o que significa que se todos se comportarem de forma consistente com seus incentivos, nenhuma trapaça ocorrerá. Esta é uma área onde a intuição pode levá-lo a errar. Este problema é muito mais difícil do que parece, como veremos quando analisarmos os incentivos dos partidos abaixo.
Um modelo super simples
Começamos construindo o modelo mais simples possível. Suponha que haja dois jogadores. O assertor faz uma afirmação, que pode ser verdadeira ou falsa. O verificador pode verificar a afirmação do afirmador, ou o verificador pode optar por não fazer nada, presumivelmente na suposição de que o afirmador provavelmente está dizendo a verdade. Assumimos que o custo da verificação do verificador é C. Se o verificador verificar e descobrir que o assertante trapaceou, o verificador receberá uma recompensa de R. (R inclui todos os benefícios obtidos para o examinador ao detectar trapaça. Isso inclui benefícios obtidos "fora do sistema", bem como quaisquer benefícios obtidos devido ao aumento da confiança no sistema.) Se o afirmador não for pego, sob trapaça, o verificador perde L, por exemplo, porque o assertor trapaceiro pode roubar de forma fraudulenta itens valiosos do verificador.
Agora temos duas ameaças com que nos preocupar: suborno e preguiça. Suborno é a possibilidade de o autor da afirmação subornar o verificador para não verificar, permitindo assim que o autor da afirmação trapaceie sem ser detectado. Podemos evitar que isso aconteça garantindo que o afirmador garanta um depósito muito grande que é maior do que o valor total no sistema e pague ao verificador quando a trapaça for detectada, de modo que o afirmador não esteja disposto a pagar uma recompensa maior do que a recompensa do verificador R's suborno. Isto evitará o suborno, mas exige que o sistema seja totalmente garantido, o que pode ser muito caro.
Outra ameaça é a preguiça, o risco de o verificador decidir não verificar o trabalho do assertor. (Lembre-se de que os verificadores podem dizer que estão verificando, mas na verdade não o fazem.) Vejamos os incentivos para os verificadores para ver se esta é uma estratégia razoável.
Suponha que o assertor trapaceie com probabilidade X. Agora, a utilidade do inspetor é a seguinte:
Se o revisor verificar: RX-C
Se o verificador não verificar: -XL
Verificar só vale a pena se a utilidade de verificar for maior que a utilidade de não verificar, ou seja, se X > C/(R+L). Aqui estão as más notícias: o assertor pode trapacear aleatoriamente, com probabilidade menor que C/(R+L), um verificador racional nunca verificará, então o assertor nunca será pego trapaceando.
Vamos inserir alguns números. Se o custo de verificação de cada transação for de US$ 0,10, e o verificador receber uma recompensa de US$ 75 se detectar trapaça, mas perder US$ 25 se não conseguir detectar trapaça, então quem afirma pode trapacear impunemente mil vezes. Se quisermos que este sistema execute milhares de transações, então temos um grande problema. Obviamente não há nada que possamos fazer neste modelo para reduzir a probabilidade de trapaça a zero. Só podemos esperar um sistema sobrecolateralizado para que o denominador de C/(R+L) se torne maior.
Este é um resultado surpreendentemente robusto – de uma forma ruim. Não depende de forma alguma dos incentivos do afirmador. Contanto que o assertor obtenha uma vantagem diferente de zero com uma trapaça bem-sucedida, ele poderá fazê-lo com alguma probabilidade, sabendo que não vale a pena o esforço do verificador para verificar. Este resultado também não depende de quanto tempo damos ao inspector para concluir o trabalho, ou se pagamos ao (suposto) inspector. Talvez você esteja pensando agora, o problema é que só existe um inspetor. Adicionar mais damas reduziria a probabilidade de trapaça? Surpreendentemente, isso não acontece.
Adicionar censores não ajuda a evitar trapaças
Novamente, vamos formular um modelo mais simples. Existem agora dois inspectores que actuam de forma independente. Cada verificador paga C se verificar, e se alguém verificar e pegar o assertor trapaceando, uma recompensa de R é paga ao verificador bem-sucedido ou, se ambos verificarem, a recompensa é dividida igualmente entre os dois. (Se desejar, você pode dar a um deles uma recompensa aleatória completa de R no caso de todos eles passarem. Isso não afeta a estratégia ou os resultados de ninguém.) Como antes, cada verificador perderá L se a assertiva trapacear sem conseguir capturado.
Permanece o caso de que se o assertor trapaceia menos que C/(R+L) do tempo, então não vale a pena para o verificador verificar, uma vez que a utilidade de verificar é menor que a utilidade de não verificar. Na verdade, o problema do incentivo é pior do que antes, porque o custo da verificação por verificador ainda é C, mas a recompensa esperada para um verificador bem-sucedido que detecta trapaça é menor que R, porque a recompensa às vezes precisa ser dividida - a recompensa esperada será estar em R/2 e R. Se a recompensa esperada for bR, onde b está entre 0,5 e 1, então o assertor pode trapacear por até C/(bR+L) tempo - isso é mais trapaça não detectada do que se houvesse apenas um verificador! (A matemática fica um pouco complicada porque o valor de b depende da estratégia do verificador, e sua estratégia depende de b, mas deve ficar claro que às vezes eles precisarão dividir a recompensa. Além disso, o valor efetivo de L também é reduzido , uma vez que não se faz isso, as damas não podem perder seu L por serem checadas por outras damas).
Um ponto em que a adição de censores realmente ajudaria seria na prevenção do suborno. Com duas damas, o afirmador deve pagar um suborno superior a R a cada afirmador, tornando o suborno duas vezes mais caro, permitindo a aposta de 50% em vez da aposta total. Mas a desvantagem é que a quantidade de trapaça aumenta.
Não vou entrar em toda a matemática aqui, mas sob suposições razoáveis, aumentar de uma peça para duas pode resultar em um aumento de 50% nas trapaças não detectadas.
Adicionar censores piora as coisas!
Você pode adicionar mais damas e as coisas vão piorar. À medida que o número de verificadores aumenta, o verificador precisa se preocupar mais com a recompensa sendo dividida de várias maneiras, de modo que a recompensa esperada para cada verificador bem-sucedido diminui gradualmente, fazendo com que a probabilidade de quem afirma trapacear com segurança aumente gradualmente. Desta perspectiva, o pior cenário é que todas as pessoas no mundo possam tornar-se censores. Isto não é infinitamente mau, uma vez que as coisas pioram à medida que mais censores são adicionados, mas certamente não ajudará a prevenir a fraude, mesmo que elimine efectivamente o risco de suborno.
Tem certeza de que seu sistema é compatível com incentivos?
Se você tem um sistema que se adapta a esse tipo de modelo e acha que ele é compatível com incentivos, você precisa pensar cuidadosamente sobre o porquê. Em particular, você precisa explicar por que o verificador faria o trabalho de verificação, mesmo que ache que é improvável que o afirmador trapaceie. Simplesmente ter uma grande penalidade por trapaça não é suficiente. Simplesmente ter uma recompensa por capturar trapaceiros não é suficiente. Simplesmente ter muitas damas não é suficiente - na verdade, pode piorar as coisas. Por que seu sistema está imune?
Este desafio se aplica a sistemas como o Optimistic Rollup. Quando falamos de Arbitrum, isso também se aplica a nós.
Levando em consideração o acima exposto, os métodos tradicionais de verificação de incentivos não alcançam os resultados desejados - existe uma taxa básica de trapaça abaixo da qual os verificadores considerarão que a verificação não vale a pena. Para concluir:
Existem dois jogadores, um afirmador, que afirma se ela é verdadeira ou falsa, e um verificador, que pode verificar a afirmação com algum custo computacional. Se o verificador verificar, sua utilidade é RX-C, se ele não verificar, sua utilidade é -XL, onde R é a recompensa por detectar trapaça, C é o custo de verificar e L é a perda do verificador por não detectar trapaça. , X é a probabilidade de trapaça do assertor (escolhida pelo assertor). Alguma álgebra mostra que se
Para resolver este problema e criar uma situação em que um revisor orientado por incentivos irá sempre verificar, temos de alterar os incentivos do revisor. O problema básico é que no modelo original, os incentivos positivos para os verificadores verificarem são todos proporcionais Se quisermos um incentivo de verificação que funcione independentemente, precisamos criar um incentivo de verificação ou um desincentivo para não verificar que seja independente das ações do afirmador.
TrueBit tenta fazer isso adicionando afirmações intencionalmente falsas ao conjunto de afirmações, essencialmente substituindo X por X mais uma constante. Existem alguns problemas com esta abordagem. (O artigo original do Arbitrum tem uma seção sobre questões de motivação do TrueBit.)
Concentre-se nos desafios
Usamos uma abordagem diferente que chamamos de foco no desafio. A ideia é que se o assertor estiver computando um valor f(x), ele primeiro emite x e um desafio criptográfico. Para responder corretamente ao desafio, o examinador precisa saber f(x). Somente após o desafio ter ocorrido é que o assertor publica f(x) - neste ponto, o verificador já fez o trabalho duro de calcular f(x), portanto não tem incentivo para ser preguiçoso. (Mais detalhes sobre o acordo seguem.)
Para reduzir o número de transações em cadeia que isso exige, organizaremos as coisas de modo que a resposta correta a um desafio de um verificador seja geralmente o silêncio. Mas, em casos raros, o verificador deve publicar uma transação muito pequena na cadeia. Se o verificador der a resposta errada - silêncio quando deveria ser liberado, ou silêncio quando deveria ser liberado - ele perderá um pequeno depósito.
Vamos adaptar o modelo de incentivo original para incorporar desafios de atenção. Precisamos de dois novos parâmetros (ambos podemos escolher): P, a porcentagem de tempo em que a resposta correta do verificador é postada, e A, a penalidade se o verificador der uma resposta errada. Agora, a utilidade do inspetor é:
Se marcado: RX-C
Se não, verifique: -LX-PA
A observação principal é que, desde que PA > C, a verificação é a estratégia ideal, não importa qual seja X (a probabilidade de trapaça).
Custo muito baixo
Para avaliar o custo, vejamos um exemplo concreto. Vamos supor que haja uma afirmação a cada cinco minutos e que o custo da verificação seja de US$ 0,001. Se definirmos a probabilidade P em 0,3%, o verificador terá que pagar um depósito de $3. Agora, o custo do verificador por afirmação é de US$ 0,0003 em taxas de gás (a taxa de gás de US$ 0,10 para postar sua resposta não silenciosa, multiplicada pela probabilidade de 0,3% que ele tem de postar), mais cerca de US$ 0,0003 para bloquear sua aposta de US$ 3 por cinco minutos. o custo dos juros é de $ 0,0006 por afirmação.
Extensão para vários inspetores
O desafio do foco se adapta bem a vários examinadores. O protocolo emite um desafio que afeta cada verificador de maneira diferente, forçando cada verificador a calcular f(x) por conta própria. Cada verificador terá o mesmo custo (em nosso caso, US$ 0,0006 por afirmação).
Em um sistema aberto, qualquer pessoa é elegível para verificar os cálculos, e você pode permitir que qualquer pessoa se registre como verificador e faça o pequeno depósito necessário. Isso os tornará elegíveis para receber desafios de atenção e potencialmente receber compensação de desenvolvedores de dapps. Qualquer um pode contestar as afirmações incorretas de um afirmador, mas apenas os examinadores registrados enfrentam desafios de atenção.
Detalhes técnicos do acordo
Agora que entendemos o que o foco nos desafios pode fazer por nós, vamos nos aprofundar nos detalhes técnicos de como eles funcionam.
Cada verificador possui uma chave privada k e uma chave pública gᵏ correspondente, definidas em um grupo apropriado. A chave pública de cada verificador é conhecida por todos. Também contaremos com uma função hash adequada H.
Para desafiar o cálculo de f(x), onde a função f é conhecida antecipadamente, o assertor gera um valor aleatório r e então emite (x, gʳ) como um desafio.
Um verificador que possua uma chave privada k deve responder ao desafio publicando uma pequena transação apenas se H(gʳᵏ, f(x)) < T, onde T é um limite adequadamente escolhido. Observe que apenas o assertor (que conhece r) e aquele verificador específico (que conhece sua chave privada k) podem calcular o hash, uma vez que são os únicos que podem calcular gʳᵏ. Observe também que calcular o hash requer conhecer f(x).
Depois que os verificadores tiverem algum tempo para postar suas respostas ao desafio, o assertor pode postar seu f(x) e se algum verificador discordar dele, será desafiado como de costume. Neste ponto, o assertor pode acusar qualquer verificador de respostas incorretas; o assertor deve emitir r para fundamentar a sua acusação. O minerador ou o contrato podem verificar se a acusação está correta e punir o infrator, mas se a afirmação de f(x) do autor da afirmação não for aceita como correta, a acusação será ignorada; Se algum verificador for multado, o reclamante receberá metade dos fundos confiscados e a outra metade será destruída.
Essa abordagem dá ao examinador os incentivos certos. Saber como um verificador deve responder a um desafio requer conhecer a chave privada desse verificador e f(x), portanto, cada verificador desejará calcular f(x). A menos que o verificador calcule f(x) ele mesmo, ele não poderá impor o protocolo com segurança. As respostas de outros verificadores não são úteis para determinar f(x) porque dependem das chaves privadas desses verificadores. Se um verificador depende de outra pessoa lhe dizendo f(x), ele não tem como verificar o valor reivindicado (a não ser calcular f(x) em si), e o verificador corre o risco de ser penalizado se estiver errado. Existe até um incentivo para uma das partes tentar enganar o verificador sobre f(x) - este é o afirmador, que lucra com o erro do verificador e pode usar esses lucros para subornar os “amigos” do verificador para fornecer ao verificador informações erradas. .
Otimização e conclusão
Existem vários truques para tornar este protocolo mais eficaz. Por exemplo, poderíamos agrupar uma afirmação com o próximo desafio numa transação em cadeia para que o desafio não aumente o número de transações. Se P for pequeno (por exemplo, 0,3% em nosso exemplo) e o número de verificadores não for muito grande, então os verificadores raramente precisarão escrever transações na cadeia, portanto, o impacto geral do protocolo no número de transações na cadeia será seja o menor.
Com uma implementação inteligente, o custo deste protocolo deve ser muito baixo em comparação com o custo inicial da emissão de declarações na cadeia. No nosso caso, adicionar desafios de atenção ao protocolo existente de desafio de asserção aumenta o custo total em menos de 1%.
E os ganhos são substanciais – obtemos um protocolo de verificação compatível com incentivos que é imune ao dilema do validador. Desde que pelo menos um verificador seja racional, as afirmações do afirmador serão sempre verificadas.
Para outras informações sobre o projeto, consulte: Cadeia pública de jogos Xai: banco de dados Binance Square
