Análise dos Princípios dos STARKs da Binius e Reflexões sobre a sua Otimização
1. Introdução
Ao contrário dos SNARKs baseados em curvas elípticas, os STARKs podem ser vistos como SNARKs baseados em hash. Uma das principais razões para a baixa eficiência atual dos STARKs é que a maioria dos números em programas reais é bastante pequena, como índices em loops for, valores booleanos, contadores, etc. No entanto, para garantir a segurança das provas baseadas em árvores de Merkle, ao expandir os dados usando codificação de Reed-Solomon, muitos valores redundantes adicionais ocupam todo o domínio, mesmo que o valor original em si seja muito pequeno. Para resolver esse problema, reduzir o tamanho do domínio tornou-se uma estratégia chave.
A largura de codificação do 1º geração de STARKs é de 252 bits, a largura de codificação do 2º geração de STARKs é de 64 bits, a largura de codificação do 3º geração de STARKs é de 32 bits, mas a largura de codificação de 32 bits ainda apresenta um grande desperdício de espaço. Em comparação, o domínio binário permite operações diretas nos bits, codificando de forma compacta e eficiente, sem desperdício de espaço, ou seja, a 4ª geração de STARKs.
Em comparação com as descobertas recentes de campos finitos, como Goldilocks, BabyBear e Mersenne31, a pesquisa sobre campos binários remonta à década de 1980. Atualmente, os campos binários já são amplamente utilizados na criptografia, exemplos típicos incluem:
Padrão de Criptografia Avançada ( AES ), baseado no domínio F28;
Galois código de autenticação de mensagem ( GMAC ), baseado no domínio F2128;
Código QR, utilizando codificação Reed-Solomon baseada em F28;
O protocolo FRI original e o zk-STARK, bem como a função de hash Grøstl que entrou na final do SHA-3, que é baseada no campo F28, é um algoritmo de hash muito adequado para recursão.
Quando se utiliza um domínio menor, a operação de extensão de domínio torna-se cada vez mais importante para garantir a segurança. O domínio binário utilizado pela Binius depende completamente da extensão de domínio para garantir a sua segurança e viabilidade prática. A maioria dos polinómios envolvidos nos cálculos do Prover não precisa de entrar na extensão de domínio, operando apenas no domínio base, o que permite uma alta eficiência em domínios pequenos. No entanto, a verificação de pontos aleatórios e os cálculos FRI ainda precisam aprofundar-se em extensões de domínio maiores para garantir a segurança necessária.
Ao construir sistemas de prova com base em domínios binários, existem 2 problemas práticos: ao calcular a representação da trace em STARKs, o tamanho do domínio deve ser maior que o grau do polinômio; ao comprometer a árvore de Merkle em STARKs, é necessário realizar a codificação de Reed-Solomon, e o tamanho do domínio deve ser maior que o tamanho após a extensão da codificação.
A Binius propôs uma solução inovadora que lida com esses dois problemas separadamente e representa os mesmos dados de duas maneiras diferentes: primeiro, usando um polinômio multivariável ( especificamente um polinômio multilinear ) em vez de um polinômio univariável, representando toda a trajetória de cálculo através de seus valores em "hipercubos" (; em segundo lugar, como cada dimensão do hipercubo tem comprimento 2, não é possível realizar uma extensão padrão de Reed-Solomon como nos STARKs, mas o hipercubo pode ser visto como um quadrado ), com base no qual é feita a extensão de Reed-Solomon. Este método, ao garantir a segurança, melhora consideravelmente a eficiência de codificação e o desempenho computacional.
2. Análise dos Princípios
A construção da maioria dos sistemas SNARKs atualmente geralmente inclui as seguintes duas partes:
Prova Interativa de Oracle Polinomial Teórica da Informação (: PIOP ): PIOP, como o núcleo do sistema de prova, transforma a relação de cálculo de entrada em igualdades polinomiais verificáveis. Diferentes protocolos PIOP permitem que o provador envie polinômios gradualmente por meio da interação com o validador, permitindo que o validador verifique se o cálculo está correto consultando os resultados de avaliação de um pequeno número de polinômios. Os protocolos PIOP existentes incluem: PIOP PLONK, PIOP Spartan e PIOP HyperPlonk, cada um com diferentes maneiras de lidar com expressões polinomiais, o que impacta o desempenho e a eficiência de todo o sistema SNARK.
Esquema de Compromisso Polinomial (Polynomial Commitment Scheme, PCS): O esquema de compromisso polinomial é utilizado para provar se uma equação polinomial gerada por PIOP é válida. O PCS é uma ferramenta criptográfica que permite ao provador comprometer-se com um determinado polinômio e, posteriormente, verificar o resultado da avaliação desse polinômio, enquanto oculta outras informações sobre o polinômio. Os esquemas de compromisso polinomial mais comuns incluem KZG, Bulletproofs, FRI(Fast Reed-Solomon IOPP) e Brakedown, entre outros. Diferentes PCS possuem diferentes desempenhos, segurança e cenários de aplicação.
De acordo com as necessidades específicas, escolha diferentes PIOP e PCS, e combine com um campo finito ou curva elíptica apropriados, pode-se construir sistemas de prova com diferentes atributos. Por exemplo:
• Halo2: combina PLONK PIOP e Bulletproofs PCS, e é baseado na curva Pasta. O Halo2 foi projetado com foco na escalabilidade e na remoção da configuração confiável do protocolo ZCash.
• Plonky2: utiliza PLONK PIOP e FRI PCS combinados, e é baseado no domínio de Goldilocks. Plonky2 foi projetado para alcançar recursividade eficiente. Ao projetar esses sistemas, a escolha de PIOP e PCS deve corresponder ao campo finito ou à curva elíptica utilizada, a fim de garantir a correção, desempenho e segurança do sistema. A escolha dessas combinações não só afeta o tamanho da prova SNARK e a eficiência de verificação, mas também determina se o sistema pode alcançar transparência sem a necessidade de configurações confiáveis, e se pode suportar recursos de extensão como provas recursivas ou provas agregadas.
Binius: HyperPlonk PIOP + Brakedown PCS + campos binários. Especificamente, Binius inclui cinco tecnologias-chave para alcançar sua eficiência e segurança. Primeiro, a aritmética baseada em torres de campos binários (towers of binary fields) constitui a base de seus cálculos, permitindo operações simplificadas dentro do campo binário. Em segundo lugar, Binius adaptou a verificação de produtos e permutações do HyperPlonk em seu protocolo de prova Oracle interativo (PIOP), garantindo verificações consistentes seguras e eficientes entre variáveis e suas permutações. Terceiro, o protocolo introduziu uma nova prova de deslocamento multilinear, otimizando a eficiência da verificação de relações multilineares em pequenos campos. Quarto, Binius utilizou uma versão aprimorada da prova de busca Lasso, oferecendo flexibilidade e robusta segurança ao mecanismo de busca. Por fim, o protocolo emprega um esquema de compromisso polinomial de pequenos campos (Small-Field PCS), permitindo a implementação de um sistema de provas eficiente sobre campos binários, reduzindo a sobrecarga normalmente associada a grandes campos.
( 2.1 Domínio finito: aritmética baseada em torres de campos binários
O domínio binário em torre é a chave para a implementação de cálculos rápidos e verificáveis, principalmente devido a dois aspectos: cálculos eficientes e aritmética eficiente. O domínio binário suporta essencialmente operações aritméticas altamente eficientes, tornando-o uma escolha ideal para aplicações criptográficas que são sensíveis a requisitos de desempenho. Além disso, a estrutura do domínio binário suporta um processo de aritmética simplificado, onde as operações executadas no domínio binário podem ser representadas de forma algébrica compacta e fácil de verificar. Essas características, juntamente com a capacidade de aproveitar plenamente suas características hierárquicas através da estrutura em torre, tornam o domínio binário particularmente adequado para sistemas de prova escaláveis, como o Binius.
O termo "canonical" refere-se à representação única e direta de um elemento no campo binário. Por exemplo, no campo binário mais básico F2, qualquer string de k bits pode ser mapeada diretamente para um elemento do campo binário de k bits. Isso difere dos campos primos, que não conseguem fornecer essa representação canônica dentro de um número fixo de bits. Embora um campo primo de 32 bits possa ser contido em 32 bits, nem toda string de 32 bits pode corresponder exclusivamente a um elemento do campo, enquanto o campo binário possui essa conveniência de mapeamento um a um. Nos campos primos Fp, os métodos de redução comuns incluem a redução de Barrett, a redução de Montgomery, e métodos de redução especial para campos finitos específicos como Mersenne-31 ou Goldilocks-64. No campo binário F2k, os métodos de redução comuns incluem a redução especial ) usada no AES, a redução de Montgomery ### usada no POLYVAL e a redução recursiva ( como a Tower ). O artigo "Exploring the Design Space of Prime Field vs. Binary Field ECC-Hardware Implementations" aponta que o campo binário não requer o transporte em operações de adição e multiplicação, e que a operação de quadrado no campo binário é muito eficiente, pois segue a regra simplificada (X + Y )2 = X2 + Y 2.
Como mostrado na Figura 1, uma string de 128 bits: esta string pode ser interpretada de várias maneiras no contexto do domínio binário. Pode ser vista como um elemento único no domínio binário de 128 bits, ou pode ser interpretada como dois elementos do domínio de torre de 64 bits, quatro elementos do domínio de torre de 32 bits, 16 elementos do domínio de torre de 8 bits, ou 128 elementos do domínio F2. Essa flexibilidade de representação não requer nenhum custo computacional, apenas uma conversão de tipo da string de bits (typecast), que é uma propriedade muito interessante e útil. Ao mesmo tempo, elementos de domínio menores podem ser empacotados em elementos de domínio maiores sem necessidade de custo computacional adicional. O protocolo Binius aproveita essa característica para melhorar a eficiência computacional. Além disso, o artigo "On Efficient Inversion in Tower Fields of Characteristic Two" explora a complexidade computacional da multiplicação, quadrado e operação de inversão em um domínio binário de torre n bits ( que pode ser decomposto em subdomínios m bits ).
( 2.2 PIOP: versão adaptada do HyperPlonk Product e PermutationCheck------aplicável ao campo binário
O design do PIOP no protocolo Binius foi inspirado no HyperPlonk e utiliza uma série de mecanismos de verificação centralizados para validar a correção de polinômios e conjuntos multivariados. Estas verificações centrais incluem:
GateCheck: Verificar se o testemunho secreto ω e a entrada pública x satisfazem a relação de cálculo do circuito C)x,ω(=0, para garantir que o circuito funcione corretamente.
PermutationCheck: Verificar se os resultados da avaliação de dois polinómios multivariáveis f e g no hipercubo booleano são uma relação de permutação f)x### = f(π)x(), para garantir a consistência das permutações entre as variáveis do polinómio.
LookupCheck: verificar se a avaliação do polinômio está na tabela de busca dada, ou seja, f(Bμ( ⊆ T)Bμ), garantindo que certos valores estejam dentro do intervalo especificado.
MultisetCheck: Verifica se dois conjuntos multivariados são iguais, ou seja, {(x1,i,x2,)}i∈H={(y1,i,y2,)}i∈H, garantindo a consistência entre vários conjuntos.
ProductCheck: verificar se a avaliação de um polinómio racional no hipercubo booleano é igual a um determinado valor declarado ∏x∈Hμ f(x) = s, para garantir a correção do produto polinomial.
ZeroCheck: Verificar se um polinómio multivariado é zero em qualquer ponto do hipercubo booleano ∏x∈Hμ f(x) = 0, ∀x ∈ Bμ, para garantir a distribuição dos zeros do polinómio.
SumCheck: Verifica se a soma de um polinómio multivariável é igual ao valor declarado ∑x∈Hμ f(x) = s. Ao transformar o problema da avaliação de um polinómio multivariável em um problema de avaliação de um polinómio univariável, reduz a complexidade computacional para a parte de verificação. Além disso, o SumCheck também permite o processamento em lote, introduzindo números aleatórios para construir combinações lineares que realizam a verificação de múltiplas instâncias de soma.
BatchCheck: Baseado no SumCheck, valida a correção da avaliação de múltiplos polinómios multivariáveis, para aumentar a eficiência do protocolo.
Embora a Binius tenha muitas semelhanças de design de protocolo com a HyperPlonk, a Binius fez melhorias nas seguintes 3 áreas:
Otimização do ProductCheck: no HyperPlonk, o ProductCheck requer que o denominador U seja sempre diferente de zero no hipercubo, e o produto deve ser igual a um valor específico; a Binius simplificou esse processo de verificação, especializando esse valor para 1, reduzindo assim a complexidade computacional.
Tratamento do problema de divisão por zero: HyperPlonk não conseguiu lidar adequadamente com a situação de divisão por zero, resultando na incapacidade de afirmar que U é não nulo no hipercubo; Binius tratou corretamente este problema, mesmo quando o denominador é zero, o ProductCheck do Binius pode continuar a processar, permitindo a generalização para qualquer valor de produto.
Verificação de Permutação entre Colunas: HyperPlonk não possui esta funcionalidade; Binius suporta a Verificação de Permutação entre várias colunas, o que permite ao Binius lidar com situações de arranjo polinomial mais complexas.
Portanto, Binius através de
Ver original
Esta página pode conter conteúdos de terceiros, que são fornecidos apenas para fins informativos (sem representações/garantias) e não devem ser considerados como uma aprovação dos seus pontos de vista pela Gate, nem como aconselhamento financeiro ou profissional. Consulte a Declaração de exoneração de responsabilidade para obter mais informações.
Binius STARKs: Sistema de prova de conhecimento zero eficiente sob domínio binário
Análise dos Princípios dos STARKs da Binius e Reflexões sobre a sua Otimização
1. Introdução
Ao contrário dos SNARKs baseados em curvas elípticas, os STARKs podem ser vistos como SNARKs baseados em hash. Uma das principais razões para a baixa eficiência atual dos STARKs é que a maioria dos números em programas reais é bastante pequena, como índices em loops for, valores booleanos, contadores, etc. No entanto, para garantir a segurança das provas baseadas em árvores de Merkle, ao expandir os dados usando codificação de Reed-Solomon, muitos valores redundantes adicionais ocupam todo o domínio, mesmo que o valor original em si seja muito pequeno. Para resolver esse problema, reduzir o tamanho do domínio tornou-se uma estratégia chave.
A largura de codificação do 1º geração de STARKs é de 252 bits, a largura de codificação do 2º geração de STARKs é de 64 bits, a largura de codificação do 3º geração de STARKs é de 32 bits, mas a largura de codificação de 32 bits ainda apresenta um grande desperdício de espaço. Em comparação, o domínio binário permite operações diretas nos bits, codificando de forma compacta e eficiente, sem desperdício de espaço, ou seja, a 4ª geração de STARKs.
Em comparação com as descobertas recentes de campos finitos, como Goldilocks, BabyBear e Mersenne31, a pesquisa sobre campos binários remonta à década de 1980. Atualmente, os campos binários já são amplamente utilizados na criptografia, exemplos típicos incluem:
Padrão de Criptografia Avançada ( AES ), baseado no domínio F28;
Galois código de autenticação de mensagem ( GMAC ), baseado no domínio F2128;
Código QR, utilizando codificação Reed-Solomon baseada em F28;
O protocolo FRI original e o zk-STARK, bem como a função de hash Grøstl que entrou na final do SHA-3, que é baseada no campo F28, é um algoritmo de hash muito adequado para recursão.
Quando se utiliza um domínio menor, a operação de extensão de domínio torna-se cada vez mais importante para garantir a segurança. O domínio binário utilizado pela Binius depende completamente da extensão de domínio para garantir a sua segurança e viabilidade prática. A maioria dos polinómios envolvidos nos cálculos do Prover não precisa de entrar na extensão de domínio, operando apenas no domínio base, o que permite uma alta eficiência em domínios pequenos. No entanto, a verificação de pontos aleatórios e os cálculos FRI ainda precisam aprofundar-se em extensões de domínio maiores para garantir a segurança necessária.
Ao construir sistemas de prova com base em domínios binários, existem 2 problemas práticos: ao calcular a representação da trace em STARKs, o tamanho do domínio deve ser maior que o grau do polinômio; ao comprometer a árvore de Merkle em STARKs, é necessário realizar a codificação de Reed-Solomon, e o tamanho do domínio deve ser maior que o tamanho após a extensão da codificação.
A Binius propôs uma solução inovadora que lida com esses dois problemas separadamente e representa os mesmos dados de duas maneiras diferentes: primeiro, usando um polinômio multivariável ( especificamente um polinômio multilinear ) em vez de um polinômio univariável, representando toda a trajetória de cálculo através de seus valores em "hipercubos" (; em segundo lugar, como cada dimensão do hipercubo tem comprimento 2, não é possível realizar uma extensão padrão de Reed-Solomon como nos STARKs, mas o hipercubo pode ser visto como um quadrado ), com base no qual é feita a extensão de Reed-Solomon. Este método, ao garantir a segurança, melhora consideravelmente a eficiência de codificação e o desempenho computacional.
2. Análise dos Princípios
A construção da maioria dos sistemas SNARKs atualmente geralmente inclui as seguintes duas partes:
Prova Interativa de Oracle Polinomial Teórica da Informação (: PIOP ): PIOP, como o núcleo do sistema de prova, transforma a relação de cálculo de entrada em igualdades polinomiais verificáveis. Diferentes protocolos PIOP permitem que o provador envie polinômios gradualmente por meio da interação com o validador, permitindo que o validador verifique se o cálculo está correto consultando os resultados de avaliação de um pequeno número de polinômios. Os protocolos PIOP existentes incluem: PIOP PLONK, PIOP Spartan e PIOP HyperPlonk, cada um com diferentes maneiras de lidar com expressões polinomiais, o que impacta o desempenho e a eficiência de todo o sistema SNARK.
Esquema de Compromisso Polinomial (Polynomial Commitment Scheme, PCS): O esquema de compromisso polinomial é utilizado para provar se uma equação polinomial gerada por PIOP é válida. O PCS é uma ferramenta criptográfica que permite ao provador comprometer-se com um determinado polinômio e, posteriormente, verificar o resultado da avaliação desse polinômio, enquanto oculta outras informações sobre o polinômio. Os esquemas de compromisso polinomial mais comuns incluem KZG, Bulletproofs, FRI(Fast Reed-Solomon IOPP) e Brakedown, entre outros. Diferentes PCS possuem diferentes desempenhos, segurança e cenários de aplicação.
De acordo com as necessidades específicas, escolha diferentes PIOP e PCS, e combine com um campo finito ou curva elíptica apropriados, pode-se construir sistemas de prova com diferentes atributos. Por exemplo:
• Halo2: combina PLONK PIOP e Bulletproofs PCS, e é baseado na curva Pasta. O Halo2 foi projetado com foco na escalabilidade e na remoção da configuração confiável do protocolo ZCash.
• Plonky2: utiliza PLONK PIOP e FRI PCS combinados, e é baseado no domínio de Goldilocks. Plonky2 foi projetado para alcançar recursividade eficiente. Ao projetar esses sistemas, a escolha de PIOP e PCS deve corresponder ao campo finito ou à curva elíptica utilizada, a fim de garantir a correção, desempenho e segurança do sistema. A escolha dessas combinações não só afeta o tamanho da prova SNARK e a eficiência de verificação, mas também determina se o sistema pode alcançar transparência sem a necessidade de configurações confiáveis, e se pode suportar recursos de extensão como provas recursivas ou provas agregadas.
Binius: HyperPlonk PIOP + Brakedown PCS + campos binários. Especificamente, Binius inclui cinco tecnologias-chave para alcançar sua eficiência e segurança. Primeiro, a aritmética baseada em torres de campos binários (towers of binary fields) constitui a base de seus cálculos, permitindo operações simplificadas dentro do campo binário. Em segundo lugar, Binius adaptou a verificação de produtos e permutações do HyperPlonk em seu protocolo de prova Oracle interativo (PIOP), garantindo verificações consistentes seguras e eficientes entre variáveis e suas permutações. Terceiro, o protocolo introduziu uma nova prova de deslocamento multilinear, otimizando a eficiência da verificação de relações multilineares em pequenos campos. Quarto, Binius utilizou uma versão aprimorada da prova de busca Lasso, oferecendo flexibilidade e robusta segurança ao mecanismo de busca. Por fim, o protocolo emprega um esquema de compromisso polinomial de pequenos campos (Small-Field PCS), permitindo a implementação de um sistema de provas eficiente sobre campos binários, reduzindo a sobrecarga normalmente associada a grandes campos.
( 2.1 Domínio finito: aritmética baseada em torres de campos binários
O domínio binário em torre é a chave para a implementação de cálculos rápidos e verificáveis, principalmente devido a dois aspectos: cálculos eficientes e aritmética eficiente. O domínio binário suporta essencialmente operações aritméticas altamente eficientes, tornando-o uma escolha ideal para aplicações criptográficas que são sensíveis a requisitos de desempenho. Além disso, a estrutura do domínio binário suporta um processo de aritmética simplificado, onde as operações executadas no domínio binário podem ser representadas de forma algébrica compacta e fácil de verificar. Essas características, juntamente com a capacidade de aproveitar plenamente suas características hierárquicas através da estrutura em torre, tornam o domínio binário particularmente adequado para sistemas de prova escaláveis, como o Binius.
O termo "canonical" refere-se à representação única e direta de um elemento no campo binário. Por exemplo, no campo binário mais básico F2, qualquer string de k bits pode ser mapeada diretamente para um elemento do campo binário de k bits. Isso difere dos campos primos, que não conseguem fornecer essa representação canônica dentro de um número fixo de bits. Embora um campo primo de 32 bits possa ser contido em 32 bits, nem toda string de 32 bits pode corresponder exclusivamente a um elemento do campo, enquanto o campo binário possui essa conveniência de mapeamento um a um. Nos campos primos Fp, os métodos de redução comuns incluem a redução de Barrett, a redução de Montgomery, e métodos de redução especial para campos finitos específicos como Mersenne-31 ou Goldilocks-64. No campo binário F2k, os métodos de redução comuns incluem a redução especial ) usada no AES, a redução de Montgomery ### usada no POLYVAL e a redução recursiva ( como a Tower ). O artigo "Exploring the Design Space of Prime Field vs. Binary Field ECC-Hardware Implementations" aponta que o campo binário não requer o transporte em operações de adição e multiplicação, e que a operação de quadrado no campo binário é muito eficiente, pois segue a regra simplificada (X + Y )2 = X2 + Y 2.
Como mostrado na Figura 1, uma string de 128 bits: esta string pode ser interpretada de várias maneiras no contexto do domínio binário. Pode ser vista como um elemento único no domínio binário de 128 bits, ou pode ser interpretada como dois elementos do domínio de torre de 64 bits, quatro elementos do domínio de torre de 32 bits, 16 elementos do domínio de torre de 8 bits, ou 128 elementos do domínio F2. Essa flexibilidade de representação não requer nenhum custo computacional, apenas uma conversão de tipo da string de bits (typecast), que é uma propriedade muito interessante e útil. Ao mesmo tempo, elementos de domínio menores podem ser empacotados em elementos de domínio maiores sem necessidade de custo computacional adicional. O protocolo Binius aproveita essa característica para melhorar a eficiência computacional. Além disso, o artigo "On Efficient Inversion in Tower Fields of Characteristic Two" explora a complexidade computacional da multiplicação, quadrado e operação de inversão em um domínio binário de torre n bits ( que pode ser decomposto em subdomínios m bits ).
( 2.2 PIOP: versão adaptada do HyperPlonk Product e PermutationCheck------aplicável ao campo binário
O design do PIOP no protocolo Binius foi inspirado no HyperPlonk e utiliza uma série de mecanismos de verificação centralizados para validar a correção de polinômios e conjuntos multivariados. Estas verificações centrais incluem:
GateCheck: Verificar se o testemunho secreto ω e a entrada pública x satisfazem a relação de cálculo do circuito C)x,ω(=0, para garantir que o circuito funcione corretamente.
PermutationCheck: Verificar se os resultados da avaliação de dois polinómios multivariáveis f e g no hipercubo booleano são uma relação de permutação f)x### = f(π)x(), para garantir a consistência das permutações entre as variáveis do polinómio.
LookupCheck: verificar se a avaliação do polinômio está na tabela de busca dada, ou seja, f(Bμ( ⊆ T)Bμ), garantindo que certos valores estejam dentro do intervalo especificado.
MultisetCheck: Verifica se dois conjuntos multivariados são iguais, ou seja, {(x1,i,x2,)}i∈H={(y1,i,y2,)}i∈H, garantindo a consistência entre vários conjuntos.
ProductCheck: verificar se a avaliação de um polinómio racional no hipercubo booleano é igual a um determinado valor declarado ∏x∈Hμ f(x) = s, para garantir a correção do produto polinomial.
ZeroCheck: Verificar se um polinómio multivariado é zero em qualquer ponto do hipercubo booleano ∏x∈Hμ f(x) = 0, ∀x ∈ Bμ, para garantir a distribuição dos zeros do polinómio.
SumCheck: Verifica se a soma de um polinómio multivariável é igual ao valor declarado ∑x∈Hμ f(x) = s. Ao transformar o problema da avaliação de um polinómio multivariável em um problema de avaliação de um polinómio univariável, reduz a complexidade computacional para a parte de verificação. Além disso, o SumCheck também permite o processamento em lote, introduzindo números aleatórios para construir combinações lineares que realizam a verificação de múltiplas instâncias de soma.
BatchCheck: Baseado no SumCheck, valida a correção da avaliação de múltiplos polinómios multivariáveis, para aumentar a eficiência do protocolo.
Embora a Binius tenha muitas semelhanças de design de protocolo com a HyperPlonk, a Binius fez melhorias nas seguintes 3 áreas:
Otimização do ProductCheck: no HyperPlonk, o ProductCheck requer que o denominador U seja sempre diferente de zero no hipercubo, e o produto deve ser igual a um valor específico; a Binius simplificou esse processo de verificação, especializando esse valor para 1, reduzindo assim a complexidade computacional.
Tratamento do problema de divisão por zero: HyperPlonk não conseguiu lidar adequadamente com a situação de divisão por zero, resultando na incapacidade de afirmar que U é não nulo no hipercubo; Binius tratou corretamente este problema, mesmo quando o denominador é zero, o ProductCheck do Binius pode continuar a processar, permitindo a generalização para qualquer valor de produto.
Verificação de Permutação entre Colunas: HyperPlonk não possui esta funcionalidade; Binius suporta a Verificação de Permutação entre várias colunas, o que permite ao Binius lidar com situações de arranjo polinomial mais complexas.
Portanto, Binius através de