As assinaturas BLS estão em todo o lado, desde o consenso do Ethereum até ao EigenLayer. Mas é fácil usá-las de forma errada. O que são assinaturas BLS? Vamos falar sobre a maneira certa e a maneira errada de as usar:

Mas primeiro, o que são assinaturas BLS? As assinaturas BLS são um primitivo criptográfico usado para assinar mensagens, como o ECDSA. Aqui está como a matemática funciona. Elas são construídas sobre emparelhamentos de curvas elípticas. Mas o que as torna tão especiais? Por que usar esses emparelhamentos sofisticados?

A característica matadora do BLS: agregação de assinaturas. Você pode combinar muitas assinaturas BLS em uma única assinatura. Isso permite que você transmita e verifique N assinaturas de uma só vez, sendo mais eficiente em termos de espaço e tempo! E na blockchain, otimizações são extremamente importantes para economizar gás.

Para uma análise aprofundada de como funcionam as assinaturas BLS, juntamente com o processo de construção de agregações e multi-assinaturas, confira o post completo do blog linkado no final deste tópico! Agora, vamos ver como as assinaturas BLS podem falhar e como a EigenLayer as utiliza (corretamente, evitando essas armadilhas)!

EigenLayer é uma camada de restaking para Ethereum. Nos AVSes do EigenLayer, os validadores assinam os resultados das suas computações de validação. O agregador coleta todas essas assinaturas e as coloca na cadeia. As assinaturas agregadas são verificadas na cadeia.

A tarefa contém o número do bloco quando a tarefa foi criada e um limite que indica a porcentagem de validação do operador, que é necessária para validar a tarefa. Os operadores que optaram pelo AVS podem receber essas tarefas para calcular a resposta da tarefa e, em seguida, o operador pode enviar a resposta com sua assinatura BLS da tarefa para o agregador. Assim que o limite de respostas idênticas for alcançado, o agregador mescla todas as assinaturas BLS em uma única assinatura agregada e a envia de volta ao contrato AVS. O contrato verifica se a assinatura está correta e abre um período de contestação em que um desafiador pode apresentar provas de que a validação estava incorreta, e, se assim for, os operadores que se comportaram mal são penalizados.

No contrato, a verificação acontece na função `trySignatureAndApkVerification`:

No entanto, as multi-assinaturas, se usadas incorretamente, apresentam um sério problema chamado ataques de chave maliciosa. Digamos que um usuário honesto tem uma chave pública, `pk_0`. Um atacante que já viu `pk_0` pode escolher sua chave pública como pk_1 = sk_1⋅G_1—pk_0. O atacante não saberia a chave privada associada à chave pública. No entanto, a verificação da multi-assinatura daria o seguinte:

Apenas `sk_1` é necessário para assinar uma mensagem resultando em uma multi-assinatura válida, mesmo que o primeiro usuário não a tenha assinado. Isso é facilmente generalizado para qualquer número `r` de usuários honestos ao escolher a chave maliciosa, sendo:

Esta é uma ameaça perigosa, uma vez que, no nosso exemplo anterior de AVS, um agregador malicioso que tivesse anteriormente registado uma chave fraudulenta poderia enviar assinaturas agregadas não assinadas pelos validadores, mas ainda assim ser aceito pelo contrato. Isto levaria a que os validadores fossem penalizados mesmo que não tivessem agido de forma inadequada.

Assim, para prevenir um ataque de chave maliciosa, o método comum é solicitar aos usuários que provem que sabem que a chave privada corresponde à sua chave pública, conhecido como prova de posse. Assim, na primeira etapa de registro, o usuário é solicitado a registrar sua chave pública juntamente com a prova de posse π de forma que:

Basicamente, o utilizador é solicitado a assinar a sua chave pública ou qualquer outra mensagem de identificação. No AVS, a mensagem é o endereço do operador. No contrato do EigenLayer, a prova de posse é verificada pela função `registerBLSPublicKey`:

A função `pubkeyRegistrationMessageHash` é utilizada para hash do separador de domínio personalizado `PUBKEY_REGISTRATION_TYPEHASH` e do endereço do operador.

Após o registro, a chave pública é adicionada ao contrato. Podemos verificar seu valor chamando a função `getRegisteredPubkey`. Aqui está um exemplo de uma chave pública BLS registrada para o EigenDA AVS:

A prova de posse é basicamente uma assinatura BLS. No entanto, também não é aconselhável usar multi-assinaturas durante a etapa de prova de posse, por exemplo, para registrar várias chaves públicas para um único participante. Se assim for, o participante conseguiria realizar um ataque de zero dividido. Nesse caso, o participante poderia registrar chaves que se cancelariam quando somadas e poderiam contornar a prova de posse.

Vimos que as multi-assinaturas BLS oferecem uma oportunidade significativa de otimização. A implementação do EigenLayer demonstra o poder das assinaturas BLS e também destaca as complexidades envolvidas na sua implementação prática. No entanto, as multi-assinaturas introduzem riscos de segurança, como ataques de chave maliciosa, que necessitam de salvaguardas como a prova de posse. Mas com a atualização Pectra a suportar BLS12-381, podemos ver mais implementações e melhorias em Solidity, e assim esperamos que este post ajude a evitar bugs de implementação e vulnerabilidades conhecidas.

Para uma análise mais profunda sobre assinaturas BLS, construção de agregação e multi-assinaturas, confira nosso post de blog recentemente publicado abaixo: