A disponibilidade de dados é um dos principais gargalos na expansão do blockchain.
**Escrito por: **zer0kn0wledge.era
** Compilado por: Kate, Marsbit **
Nota: Este artigo é do Twitter @expctchaos, que é um pesquisador do @ChaosDAO. O conteúdo do tweet original é organizado pela MarsBit da seguinte forma:
0/ Disponibilidade de dados (DA) é o principal gargalo de dimensionamento
Felizmente @CelestiaOrg, @AvailProject e @eigenlayer vão mudar o jogo DA e permitir novos níveis de escalabilidade
Mas como funciona e como o #EigenDA é diferente do DA 15 como #Celestia e #Avail?
1/ Se você não está familiarizado com problemas de disponibilidade de dados, confira meu post abaixo, onde descrevo a situação de disponibilidade de dados em detalhes 👇
2/ Em geral, existem dois tipos principais de soluções de processamento de dados
🔷DA on-chain
🔷DA off-chain
3/ E "verificação de validade pura" significa que o processamento de dados pode ser off-chain sem garantias, porque provedores de serviços de dados off-chain podem ficar offline a qualquer momento...
4/ …#StarkEx, #zkPorter e #Arbitrum Nova são exemplos de cenários de verificação que dependem do DAC, um grupo de terceiros bem conhecidos para garantir a disponibilidade de dados
5/ Por outro lado, #EigenDA, @CelestiaOrg e @AvailProject são o que poderíamos chamar de solução DA universal
No entanto, existem algumas diferenças entre o EigenDA e as outras duas soluções
6/ Se quiser saber como funciona o @CelestiaOrg, acesse o link abaixo
7/ Eu cobri @AvailProject no passado também, então para saber mais confira aqui
8/ Se precisar de uma atualização sobre @eigenlayer, confira o tópico abaixo 👇
9/ Portanto, no post de hoje, queremos focar na comparação entre as cadeias #EigenDA e DA L1 de @eigenlayer, como @CelestiaOrg ou @AvailProject
10/ Vamos supor um rollup baseado em Ethereum e usando Celestia for DA (também conhecido como Celestium)
Portanto, os contratos L2 no Ethereum verificam a prova de validade ou prova de fraude como de costume, e o DA é fornecido pela Celestia
11/ Em @CelestiaOrg e @AvailProject, não há contratos inteligentes ou cálculos, apenas a disponibilidade garantida de dados
12/ Mas vamos dar uma olhada mais de perto
Em @CelestiaOrg, os dados tx são publicados na Celestia pelo classificador L2, o verificador Celestia assina a raiz Merkle da prova DA e, em seguida, é enviado para o contrato ponte DA no Ethereum para verificação e armazenamento
13/ Comparado ao armazenamento de DA on-chain, isso reduz muito o custo de ter uma forte garantia de DA, além de fornecer garantias de segurança do Celestia (em vez de um DAC centralizado)
14/ A redução de custo mudará as regras do jogo em todo o campo rollup, porque o custo de calldata gerado pela publicação de dados no Ethereum L1 representa 80-90% do custo rollup
Para obter mais informações sobre o custo de dados de chamada, confira a postagem abaixo 👇
15/ Mas o que diabos aconteceu em #Celestia?
Os blobs de dados postados em @CelestiaOrg (essencialmente como dados brutos) são propagados pela rede P2P e o consenso sobre o blob de dados é alcançado usando o consenso Tendermint
16/ Todo nó completo #Celestia deve baixar todo o blob de dados. Isso é diferente para nós leves que podem usar Data Availability Sampling (DAS) para garantir a disponibilidade de dados
17/ Para mais informações sobre DAS e light nodes, por favor veja o post abaixo
18/ Também voltaremos ao DAS mais adiante neste tópico, mas por enquanto o foco está nos nós completos
Então, de volta ao @CelestiaOrg, que continua a se comportar de maneira L1, contando com transmissão e consenso em blobs de dados
19/ Portanto, exige muito dos nós completos da rede (128 MB/s de download e 12,5 MB/s de upload).
Ainda assim, @CelestiaOrg estava buscando uma taxa de transferência moderada (1,4 MB/s) no início, o que parece baixo devido aos requisitos de nó completo
20/ No entanto, a rede pode dimensionar a taxa de transferência adicionando nós leves. Quanto mais nós leves de amostragem de dados, maior o tamanho do bloco pode estar sob a condição de garantir segurança e descentralização
21/ Por outro lado, @eigenlayer tem uma arquitetura diferente, sem consenso próprio e sem rede peer-to-peer
Então, como isso funciona?
Primeiro, o nó EigenDA deve realocar $ETH no contrato @eigenlayer. Portanto, os nós #EigenDA são um subconjunto de validadores Ethereum
22/ Depois de receber o blob de dados, um comprador DA (como um rollup, também conhecido como dispersor) o codifica com um código de eliminação e gera um compromisso KZG…
23/… onde o tamanho da prova depende da taxa de redundância do código de eliminação e publica o compromisso da KZG com o contrato inteligente #EigenDA
24/ Compromisso KZG codificado distribuído pelo dispersor para nós #EigenDA
Depois de receber o compromisso KZG, esses nós o comparam com o compromisso KZG do contrato inteligente EigenDA e assinam o comprovante após a confirmação
25/ Depois disso, o dispersor coleta essas assinaturas uma a uma, gera uma assinatura agregada e a publica no contrato inteligente #EigenDA, e o contrato inteligente verifica a assinatura
26/ Mas como podemos ter certeza de que um nó EigenDA realmente armazenou um blob de dados se o nó #EigenDA simplesmente assinou uma prova de que armazenou o blob de dados codificado neste fluxo de trabalho, e o contrato inteligente EigenDA apenas verifica a exatidão do agregado dados de assinatura?
27/ #EigenDA usa um método de prova de custódia para conseguir isso
Mas vamos dar um passo para trás e olhar para esta cena onde se torna importante
28/ Vamos supor que alguns validadores preguiçosos não estão realizando as tarefas atribuídas a eles (por exemplo, garantir que os dados estejam disponíveis)
Em vez disso, eles fingem que fizeram o trabalho e aprovam o resultado final (relatando falsamente a disponibilidade de dados quando não estão disponíveis).
29/ Conceitualmente, prova de guarda é como prova de fraude:
Qualquer um pode enviar uma prova (validador preguiçoso) para o contrato inteligente #EigenDA, que será verificado pelo contrato inteligente
29/ Lazy validator é cortado se a validação for bem-sucedida (porque é um erro objetivamente atribuível)
30/ E o consenso?
@CelestiaOrg usa Tendermint como seu protocolo de consenso, que tem finalidade de slot único. Ou seja, quando um bloco passa pelo consenso #Celestia, está feito. Isso significa que a finalidade é basicamente tão rápida quanto o tempo de bloqueio (15 segundos).
31/ @AvailProject usa composição de protocolo para atingir a finalidade. BABE é um mecanismo de produção de blocos com finalidade probabilística e GRANDPA é um gadget final. Embora o GRANDPA possa completar blocos em um slot, ele também pode completar vários blocos em uma rodada
32/ Como @eigenlayer é um conjunto de contratos inteligentes no Ethereum, ele também herda o mesmo tempo de finalização do Ethereum (12 a 15 minutos) para dados que precisam ser encaminhados ao contrato rollup para comprovar a disponibilidade dos dados
33/ No entanto, se o rollup usar @eigenlayer, isso pode ser feito mais rapidamente, dependendo do mecanismo de consenso usado, etc.
Além disso, o middleware protegido pelos validadores de restaking da @eigenlayer focados em fornecer liquidações rápidas, como o EigenSettle, pode fornecer fortes garantias de segurança econômica, permitindo a pré-confirmação da finalidade. No entanto, garantias de hard finality ainda vêm do Ethereum L1
34/ Hora de revisitar os conceitos de amostragem de disponibilidade de dados
Na maioria dos blockchains, os nós precisam baixar todos os dados da transação para verificar a disponibilidade dos dados. O problema que isso cria é que, quando o tamanho do bloco aumenta, o número de nós de dados que precisam ser verificados também aumenta.
35/ Data Availability Sampling (DAS) é uma técnica que permite que os light nodes verifiquem a disponibilidade de dados baixando apenas uma pequena parte dos dados do bloco
36/ Isso fornece segurança para nós leves para que eles possam validar blocos inválidos (somente DA e consenso) e permite que o blockchain dimensione a disponibilidade de dados sem aumentar os requisitos de nó
37/ DAS requer pelo menos um nó completo honesto e um número suficiente de clientes leves
38/ Mas como garantir a segurança dos light nodes?
Clientes leves tradicionais têm suposições de segurança mais fracas em comparação com nós completos, pois validam apenas cabeçalhos de bloco
Portanto, light clients não podem detectar se um bloco inválido foi produzido por uma maioria desonesta de produtores de blocos
39/ Os nós leves com amostragem de disponibilidade de dados são atualizados em segurança, porque se a camada DA fizer apenas consenso e disponibilidade de dados, eles podem verificar se blocos inválidos são produzidos
40/ Ambos @CelestiaOrg e @AvailProject terão amostragem de disponibilidade de dados para que seus light nodes tenham segurança minimizada pela confiança.
41/ Isso é diferente de Ethereum e @eigenlayer
Ethereum com #EIP4844 não possui amostragem de disponibilidade de dados, portanto, seus clientes leves não terão segurança minimizada pela confiança
42/ Como o Ethereum também possui seu ambiente de contrato inteligente, os clientes leves também precisam verificar a execução (via fraude ou prova de validade), em vez de confiar na maioria das suposições de honestidade
43/ @eigenlayer (a menos que haja um DAS), o cliente leve, se suportado, contará com uma maioria honesta de nós de reativação
Portanto, a segurança de #EigenDA é baseada principalmente no conjunto de validadores Ethereum, herdando a primitiva de corte Ethereum e garantindo a segurança econômica de DA
44/ Portanto, mais participação das partes interessadas no #EigenDA significa maior segurança. A redução dos requisitos de nó também contribui para uma melhor descentralização
45/ A codificação de eliminação é um mecanismo importante que permite a amostragem de disponibilidade de dados. A codificação de eliminação expande os blocos fazendo cópias adicionais dos dados. Dados adicionais criam redundância, fornecendo garantias de segurança mais fortes para o processo de amostragem
46/ No entanto, os nós podem tentar codificar dados incorretamente para interromper a rede. Para se defender desse ataque, os nós precisam de uma maneira de verificar se a codificação está correta - é aqui que entram as provas.
47/ Ethereum, @eigenlayer e @AvailProject usam um esquema de prova de validade para garantir que os blocos sejam codificados corretamente. A ideia é semelhante às provas de validade usadas pelo zk rollup. @eigenlayer discutiu isso anteriormente neste tópico
48/ Cada vez que um bloco é gerado, o verificador deve fazer um compromisso com os dados verificados pelo nó usando a prova KZG para provar que o bloco está codificado corretamente
49/ Embora gerar compromissos para provas KZG exija mais sobrecarga computacional para produtores de bloco, quando os blocos são pequenos, gerar compromissos não traz muita sobrecarga. No entanto, isso mudou...
50/… à medida que os blocos aumentam, o ônus do compromisso da prova KZG é muito maior
Portanto, o tipo de nó responsável por gerar esses compromissos pode ter requisitos de hardware maiores
51/ Por outro lado, @CelestiaOrg implementa provas de fraude para codificação de eliminação. Portanto, os nós #Celestia não precisam verificar se os blocos estão codificados corretamente. eles padronizam para estar correto
52/ O benefício é que os produtores de blocos não precisam fazer o trabalho caro de gerar compromissos codificados com eliminação
Mas há uma compensação, porque os light nodes precisam esperar um pouco antes de assumir que um bloco está codificado corretamente e completá-lo em sua visão
53/ A principal diferença entre os esquemas de codificação à prova de fraude e à prova de validade é a compensação entre a sobrecarga do nó para gerar compromissos e a latência para nós leves
54/ Esta tabela resume bem a comparação
Ver original
O conteúdo é apenas para referência, não uma solicitação ou oferta. Nenhum aconselhamento fiscal, de investimento ou jurídico é fornecido. Consulte a isenção de responsabilidade para obter mais informações sobre riscos.
Como as soluções de disponibilidade de dados funcionam e como elas diferem?
**Escrito por: **zer0kn0wledge.era
** Compilado por: Kate, Marsbit **
Nota: Este artigo é do Twitter @expctchaos, que é um pesquisador do @ChaosDAO. O conteúdo do tweet original é organizado pela MarsBit da seguinte forma:
0/ Disponibilidade de dados (DA) é o principal gargalo de dimensionamento
Felizmente @CelestiaOrg, @AvailProject e @eigenlayer vão mudar o jogo DA e permitir novos níveis de escalabilidade
Mas como funciona e como o #EigenDA é diferente do DA 15 como #Celestia e #Avail?
1/ Se você não está familiarizado com problemas de disponibilidade de dados, confira meu post abaixo, onde descrevo a situação de disponibilidade de dados em detalhes 👇
2/ Em geral, existem dois tipos principais de soluções de processamento de dados
3/ E "verificação de validade pura" significa que o processamento de dados pode ser off-chain sem garantias, porque provedores de serviços de dados off-chain podem ficar offline a qualquer momento...
4/ …#StarkEx, #zkPorter e #Arbitrum Nova são exemplos de cenários de verificação que dependem do DAC, um grupo de terceiros bem conhecidos para garantir a disponibilidade de dados
5/ Por outro lado, #EigenDA, @CelestiaOrg e @AvailProject são o que poderíamos chamar de solução DA universal
No entanto, existem algumas diferenças entre o EigenDA e as outras duas soluções
6/ Se quiser saber como funciona o @CelestiaOrg, acesse o link abaixo
7/ Eu cobri @AvailProject no passado também, então para saber mais confira aqui
8/ Se precisar de uma atualização sobre @eigenlayer, confira o tópico abaixo 👇
9/ Portanto, no post de hoje, queremos focar na comparação entre as cadeias #EigenDA e DA L1 de @eigenlayer, como @CelestiaOrg ou @AvailProject
10/ Vamos supor um rollup baseado em Ethereum e usando Celestia for DA (também conhecido como Celestium)
Portanto, os contratos L2 no Ethereum verificam a prova de validade ou prova de fraude como de costume, e o DA é fornecido pela Celestia
11/ Em @CelestiaOrg e @AvailProject, não há contratos inteligentes ou cálculos, apenas a disponibilidade garantida de dados
12/ Mas vamos dar uma olhada mais de perto
Em @CelestiaOrg, os dados tx são publicados na Celestia pelo classificador L2, o verificador Celestia assina a raiz Merkle da prova DA e, em seguida, é enviado para o contrato ponte DA no Ethereum para verificação e armazenamento
13/ Comparado ao armazenamento de DA on-chain, isso reduz muito o custo de ter uma forte garantia de DA, além de fornecer garantias de segurança do Celestia (em vez de um DAC centralizado)
14/ A redução de custo mudará as regras do jogo em todo o campo rollup, porque o custo de calldata gerado pela publicação de dados no Ethereum L1 representa 80-90% do custo rollup
Para obter mais informações sobre o custo de dados de chamada, confira a postagem abaixo 👇
15/ Mas o que diabos aconteceu em #Celestia?
Os blobs de dados postados em @CelestiaOrg (essencialmente como dados brutos) são propagados pela rede P2P e o consenso sobre o blob de dados é alcançado usando o consenso Tendermint
16/ Todo nó completo #Celestia deve baixar todo o blob de dados. Isso é diferente para nós leves que podem usar Data Availability Sampling (DAS) para garantir a disponibilidade de dados
17/ Para mais informações sobre DAS e light nodes, por favor veja o post abaixo
18/ Também voltaremos ao DAS mais adiante neste tópico, mas por enquanto o foco está nos nós completos
Então, de volta ao @CelestiaOrg, que continua a se comportar de maneira L1, contando com transmissão e consenso em blobs de dados
19/ Portanto, exige muito dos nós completos da rede (128 MB/s de download e 12,5 MB/s de upload).
Ainda assim, @CelestiaOrg estava buscando uma taxa de transferência moderada (1,4 MB/s) no início, o que parece baixo devido aos requisitos de nó completo
20/ No entanto, a rede pode dimensionar a taxa de transferência adicionando nós leves. Quanto mais nós leves de amostragem de dados, maior o tamanho do bloco pode estar sob a condição de garantir segurança e descentralização
21/ Por outro lado, @eigenlayer tem uma arquitetura diferente, sem consenso próprio e sem rede peer-to-peer
Então, como isso funciona?
Primeiro, o nó EigenDA deve realocar $ETH no contrato @eigenlayer. Portanto, os nós #EigenDA são um subconjunto de validadores Ethereum
22/ Depois de receber o blob de dados, um comprador DA (como um rollup, também conhecido como dispersor) o codifica com um código de eliminação e gera um compromisso KZG…
23/… onde o tamanho da prova depende da taxa de redundância do código de eliminação e publica o compromisso da KZG com o contrato inteligente #EigenDA
24/ Compromisso KZG codificado distribuído pelo dispersor para nós #EigenDA
Depois de receber o compromisso KZG, esses nós o comparam com o compromisso KZG do contrato inteligente EigenDA e assinam o comprovante após a confirmação
25/ Depois disso, o dispersor coleta essas assinaturas uma a uma, gera uma assinatura agregada e a publica no contrato inteligente #EigenDA, e o contrato inteligente verifica a assinatura
26/ Mas como podemos ter certeza de que um nó EigenDA realmente armazenou um blob de dados se o nó #EigenDA simplesmente assinou uma prova de que armazenou o blob de dados codificado neste fluxo de trabalho, e o contrato inteligente EigenDA apenas verifica a exatidão do agregado dados de assinatura?
27/ #EigenDA usa um método de prova de custódia para conseguir isso
Mas vamos dar um passo para trás e olhar para esta cena onde se torna importante
28/ Vamos supor que alguns validadores preguiçosos não estão realizando as tarefas atribuídas a eles (por exemplo, garantir que os dados estejam disponíveis)
Em vez disso, eles fingem que fizeram o trabalho e aprovam o resultado final (relatando falsamente a disponibilidade de dados quando não estão disponíveis).
29/ Conceitualmente, prova de guarda é como prova de fraude:
Qualquer um pode enviar uma prova (validador preguiçoso) para o contrato inteligente #EigenDA, que será verificado pelo contrato inteligente
29/ Lazy validator é cortado se a validação for bem-sucedida (porque é um erro objetivamente atribuível)
30/ E o consenso?
@CelestiaOrg usa Tendermint como seu protocolo de consenso, que tem finalidade de slot único. Ou seja, quando um bloco passa pelo consenso #Celestia, está feito. Isso significa que a finalidade é basicamente tão rápida quanto o tempo de bloqueio (15 segundos).
31/ @AvailProject usa composição de protocolo para atingir a finalidade. BABE é um mecanismo de produção de blocos com finalidade probabilística e GRANDPA é um gadget final. Embora o GRANDPA possa completar blocos em um slot, ele também pode completar vários blocos em uma rodada
32/ Como @eigenlayer é um conjunto de contratos inteligentes no Ethereum, ele também herda o mesmo tempo de finalização do Ethereum (12 a 15 minutos) para dados que precisam ser encaminhados ao contrato rollup para comprovar a disponibilidade dos dados
33/ No entanto, se o rollup usar @eigenlayer, isso pode ser feito mais rapidamente, dependendo do mecanismo de consenso usado, etc.
Além disso, o middleware protegido pelos validadores de restaking da @eigenlayer focados em fornecer liquidações rápidas, como o EigenSettle, pode fornecer fortes garantias de segurança econômica, permitindo a pré-confirmação da finalidade. No entanto, garantias de hard finality ainda vêm do Ethereum L1
34/ Hora de revisitar os conceitos de amostragem de disponibilidade de dados
Na maioria dos blockchains, os nós precisam baixar todos os dados da transação para verificar a disponibilidade dos dados. O problema que isso cria é que, quando o tamanho do bloco aumenta, o número de nós de dados que precisam ser verificados também aumenta.
35/ Data Availability Sampling (DAS) é uma técnica que permite que os light nodes verifiquem a disponibilidade de dados baixando apenas uma pequena parte dos dados do bloco
36/ Isso fornece segurança para nós leves para que eles possam validar blocos inválidos (somente DA e consenso) e permite que o blockchain dimensione a disponibilidade de dados sem aumentar os requisitos de nó
37/ DAS requer pelo menos um nó completo honesto e um número suficiente de clientes leves
38/ Mas como garantir a segurança dos light nodes?
Clientes leves tradicionais têm suposições de segurança mais fracas em comparação com nós completos, pois validam apenas cabeçalhos de bloco
Portanto, light clients não podem detectar se um bloco inválido foi produzido por uma maioria desonesta de produtores de blocos
39/ Os nós leves com amostragem de disponibilidade de dados são atualizados em segurança, porque se a camada DA fizer apenas consenso e disponibilidade de dados, eles podem verificar se blocos inválidos são produzidos
40/ Ambos @CelestiaOrg e @AvailProject terão amostragem de disponibilidade de dados para que seus light nodes tenham segurança minimizada pela confiança.
41/ Isso é diferente de Ethereum e @eigenlayer
Ethereum com #EIP4844 não possui amostragem de disponibilidade de dados, portanto, seus clientes leves não terão segurança minimizada pela confiança
42/ Como o Ethereum também possui seu ambiente de contrato inteligente, os clientes leves também precisam verificar a execução (via fraude ou prova de validade), em vez de confiar na maioria das suposições de honestidade
43/ @eigenlayer (a menos que haja um DAS), o cliente leve, se suportado, contará com uma maioria honesta de nós de reativação
Portanto, a segurança de #EigenDA é baseada principalmente no conjunto de validadores Ethereum, herdando a primitiva de corte Ethereum e garantindo a segurança econômica de DA
44/ Portanto, mais participação das partes interessadas no #EigenDA significa maior segurança. A redução dos requisitos de nó também contribui para uma melhor descentralização
45/ A codificação de eliminação é um mecanismo importante que permite a amostragem de disponibilidade de dados. A codificação de eliminação expande os blocos fazendo cópias adicionais dos dados. Dados adicionais criam redundância, fornecendo garantias de segurança mais fortes para o processo de amostragem
46/ No entanto, os nós podem tentar codificar dados incorretamente para interromper a rede. Para se defender desse ataque, os nós precisam de uma maneira de verificar se a codificação está correta - é aqui que entram as provas.
47/ Ethereum, @eigenlayer e @AvailProject usam um esquema de prova de validade para garantir que os blocos sejam codificados corretamente. A ideia é semelhante às provas de validade usadas pelo zk rollup. @eigenlayer discutiu isso anteriormente neste tópico
48/ Cada vez que um bloco é gerado, o verificador deve fazer um compromisso com os dados verificados pelo nó usando a prova KZG para provar que o bloco está codificado corretamente
49/ Embora gerar compromissos para provas KZG exija mais sobrecarga computacional para produtores de bloco, quando os blocos são pequenos, gerar compromissos não traz muita sobrecarga. No entanto, isso mudou...
50/… à medida que os blocos aumentam, o ônus do compromisso da prova KZG é muito maior
Portanto, o tipo de nó responsável por gerar esses compromissos pode ter requisitos de hardware maiores
51/ Por outro lado, @CelestiaOrg implementa provas de fraude para codificação de eliminação. Portanto, os nós #Celestia não precisam verificar se os blocos estão codificados corretamente. eles padronizam para estar correto
52/ O benefício é que os produtores de blocos não precisam fazer o trabalho caro de gerar compromissos codificados com eliminação
Mas há uma compensação, porque os light nodes precisam esperar um pouco antes de assumir que um bloco está codificado corretamente e completá-lo em sua visão
53/ A principal diferença entre os esquemas de codificação à prova de fraude e à prova de validade é a compensação entre a sobrecarga do nó para gerar compromissos e a latência para nós leves
54/ Esta tabela resume bem a comparação