Como um sistema distribuído, a Camada 1 requer altos custos de comunicação para chegar a um consenso, e uma grande quantidade de cálculos também consumirá gás caro. Portanto, como uma extensão da Camada1, o design da Camada2 pode efetivamente melhorar a eficiência da Camada1. Mas, dessa perspectiva, o design da Camada 2 ainda enfrenta o mesmo grande problema da Camada 1, que é como equilibrar o grau de descentralização e a eficiência.
zkRollup é uma solução de expansão da Camada 2 muito promissora, que é realizada movendo os cálculos para fora da cadeia e fornecendo provas de conhecimento zero para a cadeia da Camada 1. Na solução para realizar o zkRollup, o sistema FOX adota a estrutura principal atual e existem principalmente dois tipos de nós, a saber, Sequencer e Folder. Em termos simples, o Sequencer é responsável por classificar e empacotar as transações enviadas pelos usuários e atualizar o status na cadeia Layer 2. O Folder é responsável por gerar as provas das transações empacotadas pelo Sequencer e enviá-las ao Layer1.
Uma questão interessante é se os nós da Camada 2 devem ser descentralizados e, em caso afirmativo, como criar incentivos para garantir isso. Porque é concebível que a essência da baixa eficiência da Camada 1 seja que, para alcançar a descentralização, cada nó precise realizar uma grande quantidade de cálculos e comunicações. No entanto, o sistema da Camada 2 é usado para desacoplar o processo de cálculo. Se o modelo descentralizado que é completamente equivalente à Camada 1 ainda for usado nesta parte, ele causará congestionamento na Camada 2 pelo mesmo motivo, portanto, é necessário um trade-off ser feito aqui.
O projeto do mecanismo de incentivo é encorajar os nós a participar da manutenção do sistema Layer2, ajustando a maneira como os nós Layer2 obtêm taxas de incentivo e equilibrando as taxas pagas aos nós Layer2. Em essência, a fonte das taxas de incentivo recebidas pelos nós do Layer2 é a mesma do Ethereum, que vem das taxas de gás pagas pelos usuários que enviam transações. Este artigo discutirá no sistema FOX, como os nós FOX participam do sistema para coletar taxas de transação e os motivos para fazê-lo.
O papel do Gás
Primeiro, vamos revisar o papel das taxas de gás no sistema Ethereum. Os recursos de computação da camada 1 são limitados. Quando os usuários enviam uma transação, eles especificam a taxa de gás da transação. A taxa de gás está basicamente relacionada à complexidade da operação de execução da transação. Com base nisso, os usuários que estão dispostos a pagar um uma taxa de gás mais alta pode obter um implemento de transação de prioridade mais alta. Os incentivos dos mineradores vêm da soma das taxas de gás dos blocos embalados. Além disso, o mecanismo de taxa de gás também pode prevenir efetivamente contratos maliciosos (como loops infinitos) e limitar o tamanho do bloco, o que garante segurança até certo ponto.
Portanto, pode-se ver que o uso razoável das taxas de gás é essencialmente um agendamento e alocação razoáveis de recursos de computação na cadeia, e também é um jogo multipartidário entre as partes do projeto, mineradores e usuários. Um bom desenho do mecanismo de incentivo e o uso e distribuição de taxas são críticos para a operação do sistema.
Processo de transação na cadeia
Quando um usuário envia uma transação para o pool de transações no sistema FOX, uma taxa é adicionada para motivar o nó FOX e, em seguida, o nó Sequencer no sistema pega a transação do pool de transações para empacotamento e classificação, onde cada transação empacotada constitui blocos da Camada 2, e o Sequencer precisa executar cálculos de transação e transmitir os resultados do cálculo para o contrato FOX da Camada 1, e o Sequencer também precisa armazenar dados de transação no ZK-Ringer para garantir a disponibilidade de dados. Posteriormente, os resultados da classificação e os resultados do cálculo do Sequencer serão passados para o nó Folder, e o Folder calculará corretamente a prova (incluindo a parte de agregação da prova) e a passará para o contrato Layer1. Nesse processo, o resultado da execução da transação pelo Sequencer será atualizado diretamente para a Camada 2 após a conclusão da execução, e o nó de tempo em que a transação é realmente consensual pela Camada 1 pode ser considerado como após a verificação da prova da Pasta.
Verifica-se que neste processo, a taxa de tratamento inicial anexada pelo utilizador abrange várias finalidades:
Taxa de manuseio paga ao sequenciador
Taxa de manuseio paga ao Folder
Taxa de gás para o Sequencer enviar os resultados da transação para o Layer1
O sequenciador cobra pelo armazenamento de informações no ZK-Ringer
A taxa de Gás para Folder ligando para o contrato
Para isso, precisamos definir mecanismos específicos para motivar todas as partes a participar.
Mecanismo de Incentivo da FOX
O modelo de incentivo da FOX é relativamente novo. Primeiro, a fim de equilibrar as questões de descentralização e eficiência, dividimos as funções dos nós em nós Sequencer, responsáveis por classificar e executar transações, e nós Folder, responsáveis por gerar e agregar provas da exatidão da execução da transação. O nó da pasta FOX adota um modelo descentralizado, o que significa que qualquer minerador FOX pode acessar a rede como um gerador de provas. Para incentivar mais nós a participar, as pastas que enviarem com sucesso as provas corretas para o contrato Layer1 podem obter recompensas de token. Ao mesmo tempo, a fim de evitar o desperdício de poder de computação, ressaltamos que não apenas o primeiro remetente da prova pode obter recompensas, mas também dentro de uma janela de tempo e janela de quantidade após o envio bem-sucedido do primeiro remetente da prova (os parâmetros específicos aqui variam de acordo com condições do sistema), todos os certificadores corretos podem ser recompensados.
Figura 1: A versão original do modelo de incentivo
No entanto, sob esse mecanismo, uma pasta maliciosa terá um ataque muito astuto.
Quando uma Pasta maliciosa, denominada Adv, conclui a geração da prova, ela submete a prova ao contrato do Verificador na Camada 1 para verificação e, por outro lado, é conivente com alguns nós (ou nós controlados pela Pasta) e irá a prova calculada é divulgada a esses nós, e então eles podem enviar diretamente a prova calculada de Adv sem calculá-la, e também podem receber uma parte da recompensa, e eles não pagaram nenhum poder de computação durante esse processo. ou seja, Adv obtém múltiplos benefícios com menor poder computacional, e dificulta que outros nós concorram por Adv mesmo que gerem provas corretas.
Figura 2: Método de ataque da pasta maliciosa
Nesse ataque, o motivo do problema é que o Verifier não consegue distinguir se cada certificado é gerado independentemente pela Pasta, pois o valor do certificado é o mesmo. Para evitar esse problema, precisamos adicionar as informações de endereço exclusivo da Pasta ao certificado enviado pela Pasta, para que o certificado enviado por cada Pasta possa ser gerado independentemente por ela mesma e não possa ser enviado por outros nós.
O método de incorporar esta informação é muito inteligente, usando a heurística Fiat-Shamir (os leitores podem consultar o artigo anterior da FOX "Como transformar provas interativas em provas não interativas? Heurística Fiat-Shamir!" para detalhes técnicos). Calculado de acordo com o processo de geração de uma prova, uma das etapas, o provador, ou seja, a Pasta precisa gerar um valor de desafio aleatório através de uma função hash, e só precisa adicionar o endereço da Pasta na entrada desse hash, de modo que o valor do desafio e a Pasta correspondentes ao endereço ainda sejam um número aleatório que a Pasta não pode prever e controlar.
Afirmar estritamente a segurança desse método requer o uso dos conceitos de funções aleatórias teoricamente seguras em criptografia e indistinguibilidade, etc., que não discutiremos em detalhes aqui. Em termos simples, pode-se considerar que, devido à segurança da própria função hash e à segurança da estrutura heurística Fiat-Shamir, adicionar um valor fixo como a pré-imagem do hash não destruirá a imprevisibilidade da saída, portanto, o a segurança do algoritmo zkp original ainda é garantida.
Desta forma, cada Folder deve gerar provas de forma independente e não pode utilizar diretamente os resultados de outros nós, atingindo assim nosso objetivo.
Figura 3: Esquema de incentivo modificado
Conclusão
Da perspectiva do importante papel das taxas dos nós, este artigo apresenta a conexão entre as taxas e como motivar os nós a participar da manutenção do sistema.Ao mesmo tempo, aponta que um bom mecanismo de incentivo pode efetivamente manter a segurança do sistema. Com base nisso, discutimos em detalhes o mecanismo de incentivo para pasta de camada 2 adotado pela FOX e explicamos a racionalidade dessa abordagem e como usar habilmente a heurística Fiat-Shamir para conseguir isso.
referências
"In-Depth｜Iteration and Competition - The Road to Layer 2 Expansion of Ethereum" Guosheng Blockchain Research Institute
Ver original
This page may contain third-party content, which is provided for information purposes only (not representations/warranties) and should not be considered as an endorsement of its views by Gate, nor as financial or professional advice. See Disclaimer for details.
Fale sobre o mecanismo de incentivo da Camada 2: outro uso maravilhoso da heurística Fiat-Shamir no FOX
Prefácio
Como um sistema distribuído, a Camada 1 requer altos custos de comunicação para chegar a um consenso, e uma grande quantidade de cálculos também consumirá gás caro. Portanto, como uma extensão da Camada1, o design da Camada2 pode efetivamente melhorar a eficiência da Camada1. Mas, dessa perspectiva, o design da Camada 2 ainda enfrenta o mesmo grande problema da Camada 1, que é como equilibrar o grau de descentralização e a eficiência.
zkRollup é uma solução de expansão da Camada 2 muito promissora, que é realizada movendo os cálculos para fora da cadeia e fornecendo provas de conhecimento zero para a cadeia da Camada 1. Na solução para realizar o zkRollup, o sistema FOX adota a estrutura principal atual e existem principalmente dois tipos de nós, a saber, Sequencer e Folder. Em termos simples, o Sequencer é responsável por classificar e empacotar as transações enviadas pelos usuários e atualizar o status na cadeia Layer 2. O Folder é responsável por gerar as provas das transações empacotadas pelo Sequencer e enviá-las ao Layer1.
Uma questão interessante é se os nós da Camada 2 devem ser descentralizados e, em caso afirmativo, como criar incentivos para garantir isso. Porque é concebível que a essência da baixa eficiência da Camada 1 seja que, para alcançar a descentralização, cada nó precise realizar uma grande quantidade de cálculos e comunicações. No entanto, o sistema da Camada 2 é usado para desacoplar o processo de cálculo. Se o modelo descentralizado que é completamente equivalente à Camada 1 ainda for usado nesta parte, ele causará congestionamento na Camada 2 pelo mesmo motivo, portanto, é necessário um trade-off ser feito aqui.
O projeto do mecanismo de incentivo é encorajar os nós a participar da manutenção do sistema Layer2, ajustando a maneira como os nós Layer2 obtêm taxas de incentivo e equilibrando as taxas pagas aos nós Layer2. Em essência, a fonte das taxas de incentivo recebidas pelos nós do Layer2 é a mesma do Ethereum, que vem das taxas de gás pagas pelos usuários que enviam transações. Este artigo discutirá no sistema FOX, como os nós FOX participam do sistema para coletar taxas de transação e os motivos para fazê-lo.
O papel do Gás
Primeiro, vamos revisar o papel das taxas de gás no sistema Ethereum. Os recursos de computação da camada 1 são limitados. Quando os usuários enviam uma transação, eles especificam a taxa de gás da transação. A taxa de gás está basicamente relacionada à complexidade da operação de execução da transação. Com base nisso, os usuários que estão dispostos a pagar um uma taxa de gás mais alta pode obter um implemento de transação de prioridade mais alta. Os incentivos dos mineradores vêm da soma das taxas de gás dos blocos embalados. Além disso, o mecanismo de taxa de gás também pode prevenir efetivamente contratos maliciosos (como loops infinitos) e limitar o tamanho do bloco, o que garante segurança até certo ponto.
Portanto, pode-se ver que o uso razoável das taxas de gás é essencialmente um agendamento e alocação razoáveis de recursos de computação na cadeia, e também é um jogo multipartidário entre as partes do projeto, mineradores e usuários. Um bom desenho do mecanismo de incentivo e o uso e distribuição de taxas são críticos para a operação do sistema.
Processo de transação na cadeia
Quando um usuário envia uma transação para o pool de transações no sistema FOX, uma taxa é adicionada para motivar o nó FOX e, em seguida, o nó Sequencer no sistema pega a transação do pool de transações para empacotamento e classificação, onde cada transação empacotada constitui blocos da Camada 2, e o Sequencer precisa executar cálculos de transação e transmitir os resultados do cálculo para o contrato FOX da Camada 1, e o Sequencer também precisa armazenar dados de transação no ZK-Ringer para garantir a disponibilidade de dados. Posteriormente, os resultados da classificação e os resultados do cálculo do Sequencer serão passados para o nó Folder, e o Folder calculará corretamente a prova (incluindo a parte de agregação da prova) e a passará para o contrato Layer1. Nesse processo, o resultado da execução da transação pelo Sequencer será atualizado diretamente para a Camada 2 após a conclusão da execução, e o nó de tempo em que a transação é realmente consensual pela Camada 1 pode ser considerado como após a verificação da prova da Pasta.
Verifica-se que neste processo, a taxa de tratamento inicial anexada pelo utilizador abrange várias finalidades:
Para isso, precisamos definir mecanismos específicos para motivar todas as partes a participar.
Mecanismo de Incentivo da FOX
O modelo de incentivo da FOX é relativamente novo. Primeiro, a fim de equilibrar as questões de descentralização e eficiência, dividimos as funções dos nós em nós Sequencer, responsáveis por classificar e executar transações, e nós Folder, responsáveis por gerar e agregar provas da exatidão da execução da transação. O nó da pasta FOX adota um modelo descentralizado, o que significa que qualquer minerador FOX pode acessar a rede como um gerador de provas. Para incentivar mais nós a participar, as pastas que enviarem com sucesso as provas corretas para o contrato Layer1 podem obter recompensas de token. Ao mesmo tempo, a fim de evitar o desperdício de poder de computação, ressaltamos que não apenas o primeiro remetente da prova pode obter recompensas, mas também dentro de uma janela de tempo e janela de quantidade após o envio bem-sucedido do primeiro remetente da prova (os parâmetros específicos aqui variam de acordo com condições do sistema), todos os certificadores corretos podem ser recompensados.
Figura 1: A versão original do modelo de incentivo
No entanto, sob esse mecanismo, uma pasta maliciosa terá um ataque muito astuto.
Quando uma Pasta maliciosa, denominada Adv, conclui a geração da prova, ela submete a prova ao contrato do Verificador na Camada 1 para verificação e, por outro lado, é conivente com alguns nós (ou nós controlados pela Pasta) e irá a prova calculada é divulgada a esses nós, e então eles podem enviar diretamente a prova calculada de Adv sem calculá-la, e também podem receber uma parte da recompensa, e eles não pagaram nenhum poder de computação durante esse processo. ou seja, Adv obtém múltiplos benefícios com menor poder computacional, e dificulta que outros nós concorram por Adv mesmo que gerem provas corretas.
Figura 2: Método de ataque da pasta maliciosa
Nesse ataque, o motivo do problema é que o Verifier não consegue distinguir se cada certificado é gerado independentemente pela Pasta, pois o valor do certificado é o mesmo. Para evitar esse problema, precisamos adicionar as informações de endereço exclusivo da Pasta ao certificado enviado pela Pasta, para que o certificado enviado por cada Pasta possa ser gerado independentemente por ela mesma e não possa ser enviado por outros nós.
O método de incorporar esta informação é muito inteligente, usando a heurística Fiat-Shamir (os leitores podem consultar o artigo anterior da FOX "Como transformar provas interativas em provas não interativas? Heurística Fiat-Shamir!" para detalhes técnicos). Calculado de acordo com o processo de geração de uma prova, uma das etapas, o provador, ou seja, a Pasta precisa gerar um valor de desafio aleatório através de uma função hash, e só precisa adicionar o endereço da Pasta na entrada desse hash, de modo que o valor do desafio e a Pasta correspondentes ao endereço ainda sejam um número aleatório que a Pasta não pode prever e controlar.
Afirmar estritamente a segurança desse método requer o uso dos conceitos de funções aleatórias teoricamente seguras em criptografia e indistinguibilidade, etc., que não discutiremos em detalhes aqui. Em termos simples, pode-se considerar que, devido à segurança da própria função hash e à segurança da estrutura heurística Fiat-Shamir, adicionar um valor fixo como a pré-imagem do hash não destruirá a imprevisibilidade da saída, portanto, o a segurança do algoritmo zkp original ainda é garantida.
Desta forma, cada Folder deve gerar provas de forma independente e não pode utilizar diretamente os resultados de outros nós, atingindo assim nosso objetivo.
Figura 3: Esquema de incentivo modificado
Conclusão
Da perspectiva do importante papel das taxas dos nós, este artigo apresenta a conexão entre as taxas e como motivar os nós a participar da manutenção do sistema.Ao mesmo tempo, aponta que um bom mecanismo de incentivo pode efetivamente manter a segurança do sistema. Com base nisso, discutimos em detalhes o mecanismo de incentivo para pasta de camada 2 adotado pela FOX e explicamos a racionalidade dessa abordagem e como usar habilmente a heurística Fiat-Shamir para conseguir isso.
referências
"In-Depth｜Iteration and Competition - The Road to Layer 2 Expansion of Ethereum" Guosheng Blockchain Research Institute