As assinaturas BLS estão em toda parte, desde o consenso do Ethereum até o EigenLayer. Mas é fácil usá-los errados. O que são assinaturas BLS? Vamos falar sobre a maneira certa e a maneira errada de usá-los:

Mas primeiro, o que são assinaturas BLS? As assinaturas BLS são um primitivo criptográfico usado para assinar mensagens, como ECDSA. Veja como a matemática funciona. É construído em cima de pares de curvas elípticas. Mas o que os torna tão especiais? Por que usar esses pares sofisticados?

O recurso matador 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, mais eficiente em termos de espaço e tempo! E na cadeia, as otimizações são extremamente importantes para a economia de gás.

Para uma análise aprofundada de como as assinaturas BLS funcionam, juntamente com o processo de construção de agregação e assinaturas múltiplas, confira a postagem completa do blog vinculada no final deste tópico! Agora, vamos ver como as assinaturas BLS podem dar errado e como o EigenLayer as usa (corretamente, evitando essas armadilhas)!

EigenLayer é uma camada de restaking para Ethereum. Nos AVSes EigenLayer, os validadores assinam os resultados de seus cálculos de validação. O agregador coleta todas essas assinaturas e as coloca na cadeia. As assinaturas agregadas são verificadas on-chain.

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 fazer com que essas tarefas calculem 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 é atingido, o agregador mescla todas as assinaturas BLS em uma assinatura agregada exclusiva e a envia de volta ao contrato AVS. O contrato verifica se a assinatura está correta e abre um período desafiador quando um desafiante pode dar prova de que a validação estava incorreta e, em caso afirmativo, os operadores que se comportam mal são cortados.

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

No entanto, as assinaturas múltiplas, se usadas incorretamente, vêm com um problema sério chamado ataques de teclas não autorizadas. Digamos que um usuário honesto tenha uma chave pública, 'pk_0'. Um invasor que já viu 'pk_0' pode escolher sua chave pública como pk_1 = sk_1⋅G_1—pk_0. O invasor não saberia a chave privada associada à chave pública. No entanto, a verificação de assinatura múltipla daria o seguinte:

Apenas 'sk_1' é necessário para assinar uma mensagem que resulta em uma assinatura múltipla 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, escolhendo a chave não autorizada, sendo:

Essa é uma ameaça perigosa, pois, em nosso exemplo anterior de AVS, um agregador mal-intencionado que teria registrado anteriormente uma chave não autorizada poderia enviar assinaturas agregadas não assinadas pelos validadores, mas ainda assim ser aceitas pelo contrato. Isso levaria a que os validadores fossem cortados, mesmo que não se comportassem mal.

Portanto, para evitar um ataque de chave não autorizada, o método comum é solicitar que os usuários provem que sabem que a chave privada corresponde à 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 usuário é solicitado a assinar sua chave pública ou qualquer outra mensagem de identificação. No AVS, a mensagem é o endereço do operador. No contrato EigenLayer, a prova de posse é verificada pela função 'registerBLSPublicKey':

A função 'pubkeyRegistrationMessageHash' é usada para fazer o 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 EigenDA AVS:

A prova de posse é basicamente uma assinatura BLS. No entanto, também não é aconselhável usar assinaturas múltiplas durante a etapa de prova de posse, por exemplo, para registrar várias chaves públicas para um único participante. Nesse caso, o participante alcançaria um ataque de divisão zero. Nesse caso, o participante poderia registrar chaves que seriam canceladas quando somadas e poderiam ignorar a prova de posse.

Vimos que as assinaturas múltiplas do 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 em sua implantação prática. No entanto, as assinaturas múltiplas introduzem riscos de segurança, como ataques de chave não autorizada, que exigem proteções como prova de posse. Mas com a atualização do Pectra suportando BLS12-381, podemos ver mais implementações e melhorias no Solidity e, portanto, esperamos que este post ajude a evitar bugs e vulnerabilidades de implementação conhecidos.

Para um mergulho mais profundo nas assinaturas BLS, na criação de agregação e nas assinaturas múltiplas, confira nossa postagem no blog publicada recentemente abaixo: