Introdución: o camiño cara á verificabilidade

A principal vantaxe de Web3 é a verificabilidade: os usuarios poden verificar como funcionan os sistemas. Esta característica explica por que moitos dentro e fóra da industria criptográfica describen a web3 como un paso cara a unha internet máis transparente e verificable.

A diferenza das plataformas Web2 como Facebook ou Instagram, onde os algoritmos e as regras permanecen opacos mesmo cando están documentados, os protocolos criptográficos están deseñados para unha auditabilidade completa. Aínda que se compartan, carece da capacidade de verificar se a plataforma funciona como se especifica. Isto é o contrario do cripto, onde cada protocolo está deseñado para ser o máis auditable posible, ou polo menos, espérase que o sexa.

Hoxe, exploraremos "The Verge", unha sección da serie de seis partes publicada recentemente por Vitalik sobre o futuro de Ethereum , para analizar os pasos que Ethereum está a dar para lograr a verificabilidade, a sustentabilidade e a escalabilidade no futuro. Baixo o título "The Verge", discutiremos como as arquitecturas blockchain poden facerse máis verificables, as innovacións que traen estes cambios a nivel de protocolo e como proporcionan aos usuarios un ecosistema máis seguro. Imos comezar!

Que significa "verificabilidade"?

As aplicacións Web2 funcionan como "caixas negras": os usuarios só poden ver as súas entradas e as saídas resultantes, sen visibilidade de como funciona realmente a aplicación. En cambio, os protocolos de criptomoeda normalmente fan que o seu código fonte estea dispoñible para o público ou, como mínimo, teñen plans para facelo. Esta transparencia serve para dous propósitos: permite aos usuarios interactuar directamente co código do protocolo se así o desexan e axúdalles a comprender exactamente como funciona o sistema e que regras o rexen.

"Descentraliza o que poidas, verifica o resto".

A verificabilidade garante que os sistemas sexan responsables e, en moitos casos, garante que os protocolos funcionen segundo o previsto. Este principio pon de relevo a importancia de minimizar a centralización, xa que moitas veces leva a estruturas opacas e non responsables nas que os usuarios non poden verificar as operacións. En cambio, deberíamos esforzarnos por descentralizar o máximo posible e facer que os elementos restantes sexan verificables e responsables cando a descentralización non sexa viable.

A comunidade de Ethereum parece aliñarse con esta perspectiva, xa que a folla de ruta inclúe un fito (chamado "The Verge") destinado a facer que Ethereum sexa máis verificable. Non obstante, antes de mergullarse en The Verge, necesitamos entender que aspectos das cadeas de bloques deben verificarse e que partes son cruciais desde a perspectiva dos usuarios.

As cadeas de bloques funcionan esencialmente como reloxos globais. Nunha rede distribuída con preto de 10.000 ordenadores, unha transacción pode levar unha cantidade significativa de tempo en propagarse desde o nodo de orixe a todos os outros nodos. Por este motivo, os nodos da rede non poden determinar a orde exacta das transaccións -se unha chegou antes ou despois doutra- xa que só teñen as súas propias perspectivas subxectivas.

Debido a que a orde das transaccións é importante, as redes blockchain usan métodos especializados chamados " algoritmos de consenso " para garantir que os nós permanecen sincronizados e procesan as secuencias de transaccións na mesma orde. Aínda que os nodos non poden determinar a orde de transacción globalmente, os mecanismos de consenso permiten que todos os nodos se poñan de acordo na mesma secuencia, permitindo que a rede funcione como unha única computadora cohesionada.

Máis aló da capa de consenso, tamén está a capa de execución que existe en todas as cadeas de bloques. A capa de execución está configurada polas transaccións que os usuarios queren executar. Unha vez que as transaccións foron ordenadas con éxito por consenso, cada transacción debe aplicarse ao estado actual na capa de execución. Se estás a preguntar: "Cal é o estado?", é probable que teñas visto blockchains en comparación coas bases de datos ou, máis concretamente, coa base de datos dun banco porque as blockchains, como os bancos, manteñen un rexistro dos saldos de todos.

Se tes 100 $ no estado que chamamos "S" e queres enviar 10 $ a outra persoa, o teu saldo no seguinte estado, "S+1", será de 90 $. Este proceso de aplicación de transaccións para pasar dun estado a outro é o que chamamos STF (función de transición de estado) .

En Bitcoin, o STF limítase principalmente a cambios de equilibrio, polo que é relativamente sinxelo. Non obstante, a diferenza de Bitcoin, o STF de Ethereum é moito máis complexo porque Ethereum é unha cadea de bloques totalmente programable cunha capa de execución capaz de executar código.

Nunha cadea de bloques, hai tres compoñentes fundamentais que necesitas ou podes verificar:

1. Estado : pode querer ler un dato na cadea de bloques, pero non ten acceso ao estado xa que non executa un nodo completo . Polo tanto, solicita os datos a través dun provedor de RPC (Remote Procedure Call) como Alchemy ou Infura. Non obstante, debes verificar que os datos non foron manipulados polo provedor de RPC.
2. Execución : como se mencionou anteriormente, as cadeas de bloques utilizan un STF. Debes verificar que a transición de estado se executou correctamente, non por transacción, senón bloque por bloque.
3. Consenso : As entidades de terceiros, como os RPC, poden proporcionarche bloques válidos que aínda non foron incluídos na cadea de bloques. Así, debes verificar que estes bloques foron aceptados por consenso e engadidos á cadea de bloques.

eu

Se isto parece confuso ou pouco claro, non te preocupes. Repasaremos cada un destes aspectos en detalle. Comecemos por como verificar o estado da cadea de bloques.

Como verificar o estado da cadea de bloques?

O "estado" de Ethereum refírese ao conxunto de datos almacenados na cadea de bloques en calquera momento. Isto inclúe saldos de contas (contas de contrato e contas de propiedade externa ou EOA), código de contrato intelixente, almacenamento de contratos e moito máis. Ethereum é unha máquina baseada no estado porque as transaccións procesadas na máquina virtual Ethereum (EVM) alteran o estado anterior e producen un novo estado.

Cada bloque de Ethereum contén un valor que resume o estado actual da rede despois dese bloque: o stateRoot . Este valor é unha representación compacta de todo o estado de Ethereum, que consiste nun hash de 64 caracteres.

Como cada nova transacción modifica o estado, o stateRoot rexistrado no bloque seguinte actualízase en consecuencia. Para calcular este valor, os validadores de Ethereum usan unha combinación da función hash de Keccak e unha estrutura de datos chamada Merkle Tree para organizar e resumir diferentes partes do estado.

As funcións hash son funcións unidireccionais que transforman unha entrada nunha saída de lonxitude fixa. En Ethereum, as funcións hash como Keccak úsanse para xerar resumos de datos, que serven como unha especie de pegada dixital para a entrada. As funcións hash teñen catro propiedades fundamentais:

1. Determinismo : a mesma entrada sempre producirá a mesma saída.
2. Lonxitude de saída fixa : independentemente da lonxitude da entrada, a lonxitude de saída sempre é fixa.
3. Propiedade unidireccional : é practicamente imposible derivar a entrada orixinal da saída.
4. Singularidade : ata un pequeno cambio na entrada produce unha saída completamente diferente. Así, unha entrada específica mapea a unha saída practicamente única.

Grazas a estas propiedades, os validadores de Ethereum poden realizar a STF (Función de transición de estado) para cada bloque —executando todas as transaccións do bloque e aplicándoas ao estado— e despois verificar se o estado indicado no bloque coincide co estado obtido despois do STF. . Este proceso garante que o propoñente do bloque actuou con honestidade, converténdoo nunha das principais responsabilidades dos validadores.

Non obstante, os validadores de Ethereum non hash todo o estado directamente para atopar o seu resumo. Debido á natureza unidireccional das funcións de hash, o hash directamente do estado eliminaría a verificabilidade, xa que a única forma de reproducir o hash sería posuír todo o estado.

Dado que o estado de Ethereum ten un tamaño de terabytes, non é práctico almacenar todo o estado en dispositivos cotiáns como teléfonos ou ordenadores persoais. Por este motivo, Ethereum usa unha estrutura de árbore Merkle para calcular o stateRoot, preservando a verificabilidade do estado na medida do posible.

Unha árbore de Merkle é unha estrutura de datos criptográficos utilizada para verificar de forma segura e eficiente a integridade e corrección dos datos. As árbores Merkle baséanse en funcións hash e organizan xerarquicamente os hash dun conxunto de datos, o que permite a verificación da integridade e corrección destes datos. Esta estrutura en árbore consta de tres tipos de nós:

1. Nodos folla : estes nodos conteñen os hash de pezas de datos individuais e están situados no nivel inferior da árbore. Cada nodo da folla representa o hash dun dato específico na árbore de Merkle.
2. Nodos de rama : estes nodos conteñen os hash combinados dos seus nodos fillos. Por exemplo, nunha árbore de Merkle binaria (onde N = 2), os hash de dous nodos fillos concatenan e volven facer un hash para producir o hash dun nodo de rama a un nivel superior.
3. Nodo raíz : o nodo raíz está no nivel máis alto da árbore de Merkle e representa o resumo criptográfico de toda a árbore. Este nodo úsase para verificar a integridade e corrección de todos os datos dentro da árbore.

Se estás a preguntar como construír unha árbore deste tipo, só hai dous pasos sinxelos:

• Creación de nodos de folla : cada dato é procesado mediante unha función hash e os hash resultantes forman os nodos de folla. Estes nodos sitúanse no nivel máis baixo da árbore e representan o resumo criptográfico dos datos.

• Combinar e hash : os hash dos nós das follas agrúpanse (por exemplo, en parellas) e combínanse, seguidos de hash. Este proceso crea nodos de rama no seguinte nivel. O mesmo proceso repítese para os nodos de rama ata que só queda un hash.

O hash final obtido na parte superior da árbore chámase raíz de Merkle. O Merkle Root representa o resumo criptográfico de toda a árbore e permite a verificación segura da integridade dos datos.

Como usamos as raíces de Merkle para verificar o estado de Ethereum?

As probas de Merkle permiten que o verificador valide de forma eficiente pezas específicas de datos proporcionando unha serie de valores hash que crean un camiño desde os datos de destino (un nodo da folla) ata a raíz de Merkle almacenada na cabeceira do bloque. Esta cadea de hash intermedios permite que o verificador confirme a autenticidade dos datos sen necesidade de hash todo o estado.

A partir do punto de datos específico, o verificador combínao con cada hash "irmán" proporcionado no Merkle Proof e os hash paso a paso na árbore. Este proceso continúa ata que se produce un único hash. Se este hash calculado coincide co Merkle Root almacenado, os datos considéranse válidos; en caso contrario, o verificador pode determinar que os datos non se corresponden co estado reclamado.

Exemplo: verificación dun punto de datos coa proba de Merkle

Digamos que recibimos os datos #4 dun RPC e queremos verificar a súa autenticidade mediante Merkle Proof. Para iso, o RPC proporcionaría un conxunto de valores hash ao longo do camiño necesario para chegar á raíz de Merkle. Para os datos 4, estes hash irmáns incluirían Hash #3, Hash #12 e Hash #5678.

1. Comeza cos datos 4 : primeiro, haxeamos os datos #4 para obter o hash #4.
2. Combinar con irmáns : entón combinamos o Hash #4 co Hash #3 (o seu irmán no nivel da folla) e unímolos para producir o Hash #34.
3. Mover arriba da árbore : a continuación, collemos o Hash #34 e combinámolo co Hash #12 (o seu irmán no seguinte nivel superior) e haxémolos para obter Hash #1234.
4. Paso final : por último, combinamos o Hash #1234 co Hash #5678 (o último irmán proporcionado) e haxémolos xuntos. O hash resultante debe coincidir co Merkle Root (Hash #12345678) almacenado na cabeceira do bloque.

Se a raíz Merkle calculada coincide coa raíz do estado do bloque, confirmamos que os datos #4 son realmente válidos neste estado. Se non, sabemos que os datos non pertencen ao estado reclamado, o que indica unha posible manipulación. Como podes ver, sen proporcionar os hash de todos os datos nin esixir que o verificador reconstruíse toda a árbore de Merkle desde cero, o Prover pode probar que os datos #4 existen no estado e que non foron alterados durante a súa viaxe, utilizando só tres hashes. Esta é a razón principal pola que Merkle Proofs considérase eficiente.

Aínda que Merkle Trees son sen dúbida eficaces para proporcionar verificación de datos segura e eficiente en grandes sistemas de cadea de bloques como Ethereum, son realmente o suficientemente eficientes? Para responder a isto, debemos analizar como o rendemento e o tamaño de Merkle Tree afectan a relación Prover-Verifier.

Dous factores clave que afectan o rendemento da árbore de Merkle

1. Factor de ramificación r: número de nodos fillos por rama.
2. Tamaño total dos datos : o tamaño do conxunto de datos que se representa na árbore.

Efecto do factor de ramificación:

Usemos un exemplo para comprender mellor o seu impacto. O factor de ramificación determina cantas ramas emerxen de cada nodo da árbore.

• Pequeno factor de ramificación (p. ex., Árbore Merkle binaria) : se se usa unha árbore Merkle binaria (factor de ramificación de 2), o tamaño da proba é moi pequeno, o que fai que o proceso de verificación sexa máis eficiente para o verificador. Con só dúas ramas en cada nodo, o verificador só necesita procesar un hash irmán por nivel. Isto acelera a verificación e reduce a carga computacional. Non obstante, o factor de ramificación reducido aumenta a altura da árbore, o que require máis operacións de hash durante a construción da árbore, o que pode ser oneroso para os validadores.
• Factor de ramificación maior (p. ex., 4) : un factor de ramificación maior (p. ex., 4) reduce a altura da árbore, creando unha estrutura máis curta e ancha. Isto permite que Full Nodes constrúa a árbore máis rápido xa que se necesitan menos operacións hash. Non obstante, para o verificador, isto aumenta o número de hashes irmáns que deben procesar en cada nivel, o que leva a un tamaño de proba maior. Máis hashs por paso de verificación tamén significan custos computacionais e de ancho de banda máis elevados para o verificador, o que supón un cambio efectivo da carga dos validadores aos verificadores.

O efecto do tamaño total dos datos

A medida que crece a cadea de bloques de Ethereum, con cada nova transacción, contrato ou interacción do usuario que se engade ao conxunto de datos, a árbore de Merkle tamén debe expandirse. Este crecemento non só aumenta o tamaño da árbore senón que tamén afecta o tamaño da proba e o tempo de verificación.

• Os nodos completos deben procesar e actualizar o conxunto de datos en crecemento regularmente para manter a árbore de Merkle.
• Os verificadores, pola súa banda, deben validar probas máis longas e complexas a medida que o conxunto de datos crece, o que require tempo de procesamento e ancho de banda adicionais.

Este tamaño crecente de datos aumenta a demanda tanto en nodos completos como en verificadores, polo que é máis difícil escalar a rede de forma eficiente. En resumo, aínda que Merkle Trees ofrecen un certo grao de eficiencia, non chegan a ser unha solución óptima para o conxunto de datos en continuo crecemento de Ethereum. Por este motivo, durante a fase The Verge , Ethereum pretende substituír Merkle Trees por unha estrutura máis eficiente coñecida como Verkle Trees . Verkle Trees teñen o potencial de ofrecer probas de tamaños máis pequenos mantendo o mesmo nivel de seguridade, o que fai que o proceso de verificación sexa máis sostible e escalable tanto para os probadores como para os verificadores.

The Verge: revolucionando a verificabilidade en Ethereum

The Verge desenvolveuse como un fito na folla de ruta de Ethereum destinada a mellorar a verificabilidade, reforzar a estrutura descentralizada da cadea de bloques e mellorar a seguridade da rede. Un dos obxectivos principais da rede Ethereum é permitir que calquera persoa poida executar facilmente un validador para verificar a cadea, creando unha estrutura onde a participación estea aberta a todos sen centralización.

A accesibilidade deste proceso de verificación é unha das características clave que distingue as cadeas de bloques dos sistemas centralizados. Aínda que os sistemas centralizados non ofrecen capacidades de verificación, a corrección dunha cadea de bloques está enteiramente en mans dos seus usuarios. Non obstante, para manter esta garantía, a execución dun validador debe ser accesible para todos, un desafío que, baixo o sistema actual, está limitado debido aos requisitos de almacenamento e cálculo.

Desde a transición a un modelo de consenso Proof-of-Stake con The Merge , os validadores de Ethereum tiveron dúas responsabilidades principais:

1. Garantir o consenso : apoiar o bo funcionamento dos protocolos de consenso tanto probabilísticos como deterministas e aplicar o algoritmo de elección de garfo.
2. Comprobación da precisión do bloque : despois de executar as transaccións nun bloque, comproba que a raíz da árbore de estado resultante coincide coa raíz de estado declarada polo propoñente.

Para cumprir coa segunda responsabilidade, os validadores deben ter acceso ao estado anterior ao bloqueo. Isto permítelles executar as transaccións do bloque e derivar o estado posterior. Non obstante, este requisito impón unha gran carga aos validadores, xa que necesitan xestionar importantes requisitos de almacenamento.

Aínda que Ethereum está deseñado para ser viable e os custos de almacenamento foron diminuíndo a nivel mundial, o problema é menos sobre o custo e máis sobre a dependencia de hardware especializado para validadores. The Verge pretende superar este desafío creando unha infraestrutura onde se poida realizar a verificación completa incluso en dispositivos con almacenamento limitado, como teléfonos móbiles, carteiras de navegador e mesmo reloxos intelixentes, o que permite que os validadores funcionen nestes dispositivos.

Primeiro paso para lograr a verificabilidade: verificación eficiente do estado

A transición a Verkle Tree s é unha parte fundamental deste proceso. Inicialmente, The Verge centrouse en substituír as estruturas Merkle Tree de Ethereum por Verkle Trees. O motivo principal para adoptar Verkle Trees é que Merkle Trees supón un obstáculo importante para a verificabilidade de Ethereum. Aínda que Merkle Trees e as súas probas poden funcionar de forma eficiente en escenarios normais, o seu rendemento degrada drasticamente no peor dos casos .

Segundo os cálculos de Vitalik, o tamaño medio da proba é duns 4 KB , o que parece manexable. Non obstante, no peor dos casos, o tamaño da proba pode aumentar a 330 MB . Si, leches correctamente: 330 MB.

A extrema ineficiencia das árbores Merkle de Ethereum nos peores escenarios deriva de dúas razóns principais:

1. Uso de árbores hexárias : Ethereum usa actualmente Merkle Trees cun factor de ramificación de 16. Isto significa que verificar un só nodo require proporcionar os 15 hash restantes na rama. Dado o tamaño do estado de Ethereum e o número de ramas, isto crea unha carga substancial no peor dos casos.

2. Non merkelización do código : en lugar de incorporar o código do contrato á estrutura da árbore, Ethereum simplemente hash o código e usa o valor resultante como un nodo. Tendo en conta que o tamaño máximo dun contrato é de 24 KB , este enfoque impón unha carga importante para lograr a verificabilidade total.

O tamaño da proba é directamente proporcional ao factor de ramificación. Ao reducir o factor de ramificación diminúe o tamaño da proba. Para resolver estes problemas e mellorar os peores escenarios, Ethereum podería cambiar de árbores hexárias a árbores binarias de Merkle e comezar a mercar códigos de contrato. Se o factor de ramificación en Ethereum redúcese de 16 a 2 e os códigos de contrato tamén se mercantilizan, o tamaño máximo da proba podería reducirse a 10 MB .

Aínda que esta é unha mellora significativa, é importante ter en conta que este custo aplícase á verificación dun só dato . Incluso unha simple transacción para acceder a varios datos requiriría probas maiores. Dado o número de transaccións por bloque e o estado en continuo crecemento de Ethereum, esta solución, aínda que é mellor, aínda non é totalmente viable.

Por estes motivos, a comunidade de Ethereum propuxo dúas solucións distintas para resolver o problema:

1. Verkle Trees
2. Probas STARK + Árbores Merkle binarias

Verkle trees e compromisos vectoriais

As Verkle Tree , como o nome indica, son estruturas arbóreas similares ás Merkle Trees . Non obstante, a diferenza máis significativa reside na eficacia que ofrecen durante os procesos de verificación. En Merkle Trees , se unha rama contén 16 pezas de datos e queremos verificar só unha delas, tamén se debe proporcionar unha cadea de hash que cobre as outras 15 pezas. Isto aumenta significativamente a carga computacional da verificación e resulta en grandes tamaños de proba.

Pola contra, Verkle Trees utiliza unha estrutura especializada coñecida como " Compromisos vectoriales baseados en curvas elípticas ", máis concretamente, un compromiso vectorial baseado no Argumento do produto interno (IPA) . Un vector é esencialmente unha lista de elementos de datos organizados nunha secuencia específica. O estado de Ethereum pódese pensar como un vector: unha estrutura onde se almacenan numerosas pezas de datos nunha orde particular, sendo cada elemento crucial. Este estado comprende varios compoñentes de datos, como enderezos, códigos de contrato e información de almacenamento, onde a orde destes elementos xoga un papel fundamental no acceso e a verificación.

Os compromisos vectoriales son métodos criptográficos utilizados para probar e verificar elementos de datos dentro dun conxunto de datos. Estes métodos permiten verificar simultáneamente tanto a existencia como a orde de cada elemento nun conxunto de datos. Por exemplo, Merkle Proofs , usado en Merkle Trees, tamén se pode considerar unha forma de compromiso vectorial . Aínda que Merkle Trees requiren todas as cadeas hash relevantes para verificar un elemento, a estrutura demostra inherentemente que todos os elementos dun vector están conectados nunha secuencia específica.

A diferenza de Merkle Trees, Verkle Trees empregan compromisos vectoriais baseados en curvas elípticas que ofrecen dúas vantaxes fundamentais:

• Os compromisos vectoriais baseados en curvas elípticas eliminan a necesidade de detalles de elementos distintos dos datos que se verifican . En Merkle Trees cun factor de ramificación de 16, a verificación dunha única rama require proporcionar os outros 15 hash. Dado o gran tamaño do estado de Ethereum, que implica moitas ramas, isto crea unha ineficiencia significativa. Non obstante, os compromisos vectoriais baseados en curvas elípticas eliminan esta complexidade, permitindo a verificación con menos datos e esforzo computacional.
• Mediante probas múltiples, as demostracións xeradas por compromisos vectoriais baseados en curvas elípticas pódense comprimir nunha única proba de tamaño constante . O estado de Ethereum non só é grande, senón que tamén crece continuamente, o que significa que o número de ramas que necesitan verificación para acceder á raíz de Merkle aumenta co paso do tempo. Non obstante, con Verkle Trees, podemos "comprimir" as probas de cada rama nunha única proba de tamaño constante usando o método detallado no artigo de Dankrad Feist . Isto permite aos verificadores validar toda a árbore cunha pequena proba en lugar de verificar cada rama individualmente. Isto tamén significa que Verkle Trees non se ve afectado polo crecemento do estado de Ethereum.

Estas características dos compromisos vectoriais baseados en curvas elípticas reducen significativamente a cantidade de datos necesarios para a verificación, o que permite a Verkle Trees producir probas pequenas e de tamaño constante mesmo no peor dos casos. Isto minimiza a sobrecarga de datos e os tempos de verificación, mellorando a eficiencia de redes a gran escala como Ethereum. Como resultado, o uso de compromisos vectoriais baseados en curvas elípticas en Verkle Trees permite un manexo máis manexable e eficiente do estado en expansión de Ethereum.

Como todas as innovacións, Verkle Trees ten as súas limitacións. Un dos seus principais inconvenientes é que dependen da criptografía de curva elíptica, que é vulnerable ás computadoras cuánticas . As computadoras cuánticas posúen moito maior poder computacional que os métodos clásicos, o que supón unha ameaza importante para os protocolos criptográficos baseados en curvas elípticas. Os algoritmos cuánticos poderían romper ou debilitar estes sistemas criptográficos, xerando preocupacións sobre a seguridade a longo prazo de Verkle Trees.

Por este motivo, aínda que Verkle Trees ofrece unha solución prometedora para a apatridia, non son a solución definitiva. Non obstante, figuras como Dankrad Feist enfatizaron que, aínda que se necesita unha coidadosa consideración ao integrar a criptografía resistente á cuántica en Ethereum, vale a pena sinalar que os compromisos KZG que se usan actualmente para os blobs en Ethereum tampouco son resistentes aos cuánticos. Así, Verkle Trees pode servir como solución provisional, proporcionando á rede tempo adicional para desenvolver alternativas máis robustas.

Probas STARK + árbores Binary Merkle

Verkle Trees ofrece tamaños de proba máis pequenos e procesos de verificación eficientes en comparación con Merkle Trees, o que facilita a xestión do estado en constante crecemento de Ethereum. Grazas aos compromisos vectoriales baseados en curvas elípticas , pódense xerar probas a gran escala con significativamente menos datos. Non obstante, a pesar das súas impresionantes vantaxes, a vulnerabilidade de Verkle Trees aos ordenadores cuánticos fai que sexan só unha solución temporal.

Aínda que a comunidade de Ethereum ve a Verkle Trees como unha ferramenta a curto prazo para gañar tempo, o foco a longo prazo está na transición a solucións resistentes á cuántica . Aquí é onde STARK Proof s e Binary Merkle Trees presentan unha alternativa sólida para construír unha infraestrutura de verificación máis sólida para o futuro.

No proceso de verificación do estado de Ethereum, o factor de ramificación de Merkle Trees pódese reducir (de 16 a 2) usando Binary Merkle Trees . Este cambio é un paso fundamental para reducir o tamaño das probas e facer que os procesos de verificación sexan máis eficientes. Non obstante, mesmo no peor dos casos, os tamaños das probas aínda poden alcanzar os 10 MB , o que é importante. Aquí é onde entran en xogo os STARK Proof , que comprimen estas grandes probas binarias Merkle a só 100-300 kB .

Esta optimización é especialmente vital cando se teñen en conta as limitacións de operar validadores en clientes lixeiros ou dispositivos con hardware limitado, especialmente se se ten en conta que as velocidades medias de descarga e carga de dispositivos móbiles a nivel mundial son de aproximadamente 7,625 MB/s e 1,5 MB/s, respectivamente. Os usuarios poden verificar transaccións con probas pequenas e portátiles sen necesidade de acceder ao estado completo, e os validadores poden realizar tarefas de verificación de bloques sen almacenar todo o estado.

Este enfoque de dobre beneficio reduce tanto o ancho de banda como os requisitos de almacenamento para os validadores, ao tempo que acelera a verificación, tres melloras clave que apoian directamente a visión de escalabilidade de Ethereum.

Desafíos clave para as probas STARK

1. Alta carga computacional para probadores : o proceso de xeración de probas STARK é computacionalmente intensivo, especialmente no lado do probador, o que pode aumentar os custos operativos.
2. Ineficiencia nas probas de pequenos datos: aínda que as probas STARK destacan no manexo de grandes conxuntos de datos, son menos eficientes ao probar pequenas cantidades de datos, o que pode dificultar a súa aplicación en certos escenarios. Cando se trata de programas que implican pasos ou conxuntos de datos máis pequenos, o tamaño de proba relativamente grande dos STARK pode facelos menos prácticos ou rendibles.

A seguridade cuántica ten un custo: carga computacional Prover-Side

A Merkle Proof dun bloque pode incluír aproximadamente 330.000 hash e, no peor dos casos, este número pode chegar a 660.000 . Nestes casos, unha proba STARK debería procesar uns 200.000 hashes por segundo . Aquí é onde entran en xogo funcións hash amigables con zk como Poseidon , optimizadas especificamente para probas STARK para reducir esta carga.

Poseidon está deseñado para funcionar de forma máis fluida con probas de ZK en comparación cos algoritmos hash tradicionais como SHA256 e Keccak . A razón principal desta compatibilidade reside en como funcionan os algoritmos hash tradicionais: procesan as entradas como datos binarios (0s e 1s).

Por outra banda, as probas ZK traballan con campos primos, estruturas matemáticas que son fundamentalmente diferentes. Esta situación é análoga aos ordenadores que funcionan en binario mentres os humanos usan un sistema decimal na vida cotiá. Traducir datos baseados en bits a formatos compatibles con ZK implica unha sobrecarga computacional importante. Poseidon resolve este problema operando de forma nativa dentro de campos primarios , acelerando drasticamente a súa integración con probas de ZK.

Non obstante, dado que Poseidon é unha función hash relativamente nova, require unha análise de seguridade máis extensa para establecer o mesmo nivel de confianza que as funcións hash tradicionais como SHA256 e Keccak. Para iso, iniciativas como a Iniciativa de Criptanálisis de Poseidon , posta en marcha pola Fundación Ethereum, invitan aos expertos a probar e analizar rigorosamente a seguridade de Poseidón, garantindo que poida soportar o escrutinio adversario e converterse nun estándar sólido para aplicacións criptográficas. Por outra banda, funcións máis antigas como SHA256 e Keccak xa foron probadas amplamente e teñen un historial de seguridade comprobado, pero non son compatibles con ZK, o que provoca caídas de rendemento cando se usan con probas STARK.

Por exemplo, as probas STARK que usan estas funcións hash tradicionais só poden procesar entre 10.000 e 30.000 hash. Afortunadamente, os avances na tecnoloxía STARK suxiren que este rendemento podería aumentar en breve ata 100.000 a 200.000 hashes, mellorando significativamente a súa eficiencia.

A ineficiencia dos STARK para probar datos pequenos

Aínda que as probas STARK destacan na escalabilidade e transparencia para grandes conxuntos de datos, mostran limitacións ao traballar con elementos de datos pequenos e numerosos. Nestes escenarios, os datos que se están a probar adoitan ser pequenos, pero a necesidade de varias probas permanece inalterada. Os exemplos inclúen:

1. Validación da transacción posterior a AA : coa abstracción de conta (AA), as carteiras poden apuntar ao código do contrato, ignorando ou personalizando pasos como nonce e verificación de sinatura, que actualmente son obrigatorios en Ethereum. Non obstante, esta flexibilidade na validación require comprobar o código do contrato ou outros datos asociados no estado para probar a validez da transacción.
2. Chamadas RPC de clientes lixeiros : os clientes lixeiros consultan datos de estado da rede (por exemplo, durante unha solicitude eth_call) sen executar un nodo completo. Para garantir a corrección deste estado, as probas deben apoiar os datos consultados e confirmar que coincide co estado actual da rede.
3. Listas de inclusión : os validadores máis pequenos poden usar mecanismos de lista de inclusión para garantir que as transaccións se inclúan no seguinte bloque, limitando a influencia dos poderosos produtores de bloques. Non obstante, validar a inclusión destas transaccións require verificar a súa corrección.

Nestes casos de uso, as probas STARK ofrecen pouca vantaxe. Os STARK, que enfatizan a escalabilidade (como destaca a "S" no seu nome), funcionan ben para conxuntos de datos grandes pero loitan con escenarios de datos pequenos. Pola contra, os SNARK , deseñados para ser breves (como subliña a "S" no seu nome), céntranse en minimizar o tamaño das probas, ofrecendo claras vantaxes en ambientes con ancho de banda ou limitacións de almacenamento.

As probas STARK adoitan ter un tamaño de 40 a 50 KB , o que é unhas 175 veces maior que as probas de SNARK, que son só 288 bytes . Esta diferenza de tamaño aumenta tanto o tempo de verificación como os custos de rede. A razón principal das probas máis grandes de STARK é a súa dependencia na transparencia e os compromisos polinómicos para garantir a escalabilidade, o que introduce custos de rendemento en escenarios de pequenos datos. Nestes casos, métodos máis rápidos e eficientes no espazo como Merkle Proofs poden ser máis prácticos. Merkle Proofs ofrece baixos custos computacionais e actualizacións rápidas, polo que son axeitados para estas situacións.

Como se resume na táboa, Ethereum ten catro camiños potenciais para escoller:

Verkle Trees

1. Verkle Trees recibiu un amplo apoio da comunidade de Ethereum, con reunións quincenais celebradas para facilitar o seu desenvolvemento. Grazas a este traballo e probas consistentes, Verkle Trees destaca como a solución máis madura e ben investigada entre as alternativas actuais. Ademais, as súas propiedades homomórficas aditivas eliminan a necesidade de volver calcular cada rama para actualizar a raíz do estado, a diferenza de Merkle Trees, o que fai que Verkle Trees sexa unha opción máis eficiente. En comparación con outras solucións, Verkle Trees enfatiza a sinxeleza, uníndose a principios de enxeñería como "manténgalo sinxelo" ou "simple is the best". Esta sinxeleza facilita tanto a integración en Ethereum como a análise de seguridade.

2. Non obstante, as árbores Verkle non son cuánticas seguras, o que impide que sexan unha solución a longo prazo. Se se integra en Ethereum, esta tecnoloxía probablemente teña que ser substituída no futuro cando se precisen solucións resistentes á cuántica. Incluso Vitalik ve Verkle Trees como unha medida temporal para gañar tempo para que madurezan os STARK e outras tecnoloxías. Ademais, os compromisos vectoriais baseados en curvas elípticas utilizados en Verkle Trees impoñen unha maior carga computacional en comparación coas funcións hash simples. Os enfoques baseados en hash poden ofrecer tempos de sincronización máis rápidos para nós completos. Ademais, a dependencia de numerosas operacións de 256 bits fai que Verkle Trees sexa máis difícil de probar usando SNARK nos sistemas de proba modernos, o que complica os esforzos futuros para reducir o tamaño das probas.

   
   

Non obstante, é importante ter en conta que Verkle Trees, debido á súa non dependencia do hash, son significativamente máis demostrables que Merkle Trees.

STARKs + funcións hash conservadoras

1. A combinación de STARK con funcións hash conservadoras ben establecidas como SHA256 ou BLAKE proporciona unha solución robusta que reforza a infraestrutura de seguridade de Ethereum. Estas funcións hash foron amplamente utilizadas e probadas amplamente tanto en ámbitos académicos como prácticos. Ademais, a súa resistencia cuántica mellora a resistencia de Ethereum fronte ás ameazas futuras que supoñen as computadoras cuánticas. Para escenarios críticos para a seguridade, esta combinación ofrece unha base fiable.

2. Non obstante, o uso de funcións hash conservadoras nos sistemas STARK introduce limitacións de rendemento significativas. Os requisitos computacionais destas funcións hash dan lugar a unha alta latencia de proba , coa xeración de probas que leva máis de 10 segundos. Esta é unha gran desvantaxe, especialmente en escenarios como a validación de bloques que esixen baixa latencia. Aínda que esforzos como as propostas de gas multidimensionais intentan aliñar a latencia do peor caso e do caso medio, os resultados son limitados. Ademais, aínda que os enfoques baseados en hash poden facilitar tempos de sincronización máis rápidos, é posible que a súa eficiencia non se axuste aos obxectivos de escalabilidade máis amplos dos STARK. Os longos tempos de cálculo das funcións hash tradicionais reducen a eficiencia práctica e limitan a súa aplicabilidade.

   STARKs + Funcións Hash relativamente novas

• Os STARK combinados con funcións hash de nova xeración compatibles con STARK (por exemplo, Poseidon) melloran significativamente o rendemento desta tecnoloxía. Estas funcións hash están deseñadas para integrarse perfectamente cos sistemas STARK e reducir drasticamente a latencia do probador . A diferenza das funcións hash tradicionais, permiten a xeración de probas en tan só 1-2 segundos . A súa eficiencia e a baixa sobrecarga computacional melloran o potencial de escalabilidade dos STARK, facéndoos moi eficaces para manexar grandes conxuntos de datos. Esta capacidade fai que sexan particularmente atractivos para aplicacións que requiren un alto rendemento.

• Non obstante, a relativa novidade destas funcións hash require unha ampla análise e probas de seguridade. A falta de probas exhaustivas introduce riscos ao considerar a súa implementación en ecosistemas críticos como Ethereum. Ademais, dado que estas funcións de hash aínda non están amplamente adoptadas, os procesos de proba e validación necesarios poderían atrasar os obxectivos de verificabilidade de Ethereum . O tempo necesario para garantir plenamente a súa seguridade pode facer que esta opción sexa menos atractiva a curto prazo, pospoñendo potencialmente as ambicións de escalabilidade e verificabilidade de Ethereum.

  Merkle Trees a base de celosía

1. Merkle Trees baseado en celosía ofrece unha solución con visión de futuro que combina a seguridade cuántica coa eficiencia de actualización de Verkle Trees. Estas estruturas abordan as debilidades tanto de Verkle Trees como de STARK e considéranse unha opción prometedora a longo prazo. Co seu deseño baseado en celosía, proporcionan unha forte resistencia ás ameazas da computación cuántica, aliñándose co foco de Ethereum en protexer o seu ecosistema para o futuro. Ademais, ao conservar as vantaxes de actualización de Verkle Trees, pretenden ofrecer unha seguridade mellorada sen sacrificar a eficiencia.
2. Non obstante, a investigación sobre Merkle Trees baseada en celosía aínda está nos seus primeiros estadios e é en gran parte teórica. Isto xera incerteza significativa sobre a súa implementación práctica e o seu rendemento. Integrar tal solución en Ethereum requiriría unha ampla investigación e desenvolvemento, así como probas rigorosas para validar os seus potenciais beneficios. Estas incertezas e complexidades infraestruturais fan que Merkle Trees baseada en celosía sexa pouco probable que sexa unha opción viable para Ethereum nun futuro próximo, o que pode atrasar o progreso cara aos obxectivos de verificabilidade da rede.

Que pasa coa execución: probas de validez da execución de EVM

Todo o que comentamos ata agora xira en torno a eliminar a necesidade de que os validadores almacenen o estado anterior, que usan para pasar dun estado a outro. O obxectivo é crear un ambiente máis descentralizado onde os validadores poidan desempeñar as súas funcións sen manter terabytes de datos estatais.

Aínda coas solucións que mencionamos, os validadores non necesitarían almacenar todo o estado, xa que recibirían todos os datos necesarios para a execución a través de testemuñas incluídas no bloque. Non obstante, para pasar ao seguinte estado e, polo tanto, verificar o stateRoot enriba do bloque, os validadores aínda deben executar o STF eles mesmos. Este requisito, á súa vez, supón outro desafío para a natureza e a descentralización sen permiso de Ethereum.

Inicialmente, The Verge imaginouse como un fito centrado unicamente na transición da árbore do estado de Ethereum de Merkle Trees a Verkle Tree para mellorar a verificabilidade do estado. Co paso do tempo, con todo, evolucionou nunha iniciativa máis ampla destinada a mellorar a verificabilidade das transicións estatais e do consenso . Nun mundo onde o trío de Estado, Execución e Consenso é totalmente verificable, os validadores de Ethereum poderían operar en practicamente calquera dispositivo cunha conexión a Internet que se poida clasificar como Cliente Lixeiro . Isto achegaría a Ethereum a lograr a súa visión de "verdadeira descentralización".

Cal é a definición do problema, de novo?

Como mencionamos anteriormente, os validadores executan unha función chamada STF (Función de transición de estado) cada 12 segundos. Esta función toma o estado anterior e un bloque como entradas e produce o estado seguinte como saída. Os validadores deben executar esta función cada vez que se propoña un novo bloque e verificar que o hash que representa o estado enriba do bloque, comunmente denominado raíz do estado , é correcto.

Os altos requisitos do sistema para converterse nun validador derivan principalmente da necesidade de realizar este proceso de forma eficiente.

Se queres converter un frigorífico intelixente (si, incluso un frigorífico) nun validador de Ethereum coa axuda dalgún software instalado, afrontas dous obstáculos importantes :

1. O teu frigorífico probablemente non disporá de internet o suficientemente rápido, o que significa que non poderá descargar os datos e as probas necesarias para a execución nin sequera coas solucións de verificación estatal que comentamos ata agora.

2. Aínda que tivese acceso aos datos necesarios para STF, non terá a potencia computacional necesaria para realizar a execución de principio a fin ou para construír unha nova árbore de estado.

   
   

Para resolver os problemas provocados por que os Clientes Lixeiros non teñan acceso nin ao estado anterior nin á totalidade do último bloque, The Verge propón que o propoñente realice a execución e achegue unha proba ao bloque. Esta proba incluiría a transición da raíz de estado anterior á raíz de estado seguinte, así como o hash do bloque. Con isto, os clientes lixeiros poden validar a transición de estado usando só tres hash de 32 bytes , sen necesitar unha proba de zk.

Non obstante, dado que esta proba funciona mediante hash, sería incorrecto dicir que só valida a transición de estado . Pola contra, a proba anexa ao bloque debe validar varias cousas á vez :

Estado raíz no bloque anterior = S, Estado raíz no seguinte bloque = S + 1, Bloque hash = H

1. O bloque en si debe ser válido e a proba de estado que hai no seu interior, xa sexa unha proba de Verkle ou STARK, debe verificar con precisión os datos que acompañan ao bloque. En resumo: validación do bloque e a proba de estado que o acompaña .
2. Cando o STF se execute utilizando os datos necesarios para a súa execución e incluídos no bloque correspondente a H , os datos que deben cambiar de estado deben actualizarse correctamente. En resumo: Validación da transición estatal .
3. Cando se reconstruíu unha nova árbore de estado cos datos actualizados correctamente, o seu valor raíz debe coincidir con S + 1 . En resumo: Validación do proceso de construción da árbore .

Na analoxía Prover-Verifier á que nos referimos anteriormente, é xeralmente xusto dicir que normalmente hai un equilibrio computacional entre os dous actores. Aínda que a capacidade das probas necesarias para que o STF sexa verificable para validar varias cousas ao mesmo tempo ofrece vantaxes significativas para o verificador , tamén indica que xerar tales probas para garantir a corrección da execución será relativamente difícil para o probador . Coa velocidade actual de Ethereum, hai que probar un bloque de Ethereum en menos de 4 segundos . Non obstante, mesmo o EVM Prover máis rápido que temos hoxe só pode probar un bloque medio en aproximadamente 15 segundos .[1]

Dito isto, hai tres camiños distintos que podemos tomar para superar este gran desafío:

1. Paralelización na proba e agregación : unha das vantaxes significativas das probas ZK é a súa capacidade de agregación . A capacidade de combinar varias probas nunha única proba compacta proporciona unha eficiencia substancial en termos de tempo de procesamento. Isto non só reduce a carga na rede, senón que tamén acelera os procesos de verificación de forma descentralizada. Para unha rede grande como Ethereum, permite a xeración máis eficiente de probas para cada bloque.

Durante a xeración de probas, cada pequena parte do proceso de execución (por exemplo, pasos de cálculo ou acceso a datos) pódese probar individualmente, e estas probas pódense agregar posteriormente nunha única estrutura. Co mecanismo correcto, este enfoque permite que as probas dun bloque se xeren rapidamente e de forma descentralizada por moitas fontes diferentes (por exemplo, centos de GPU). Isto aumenta o rendemento ao tempo que contribúe ao obxectivo de descentralización ao involucrar a un grupo máis amplo de participantes.

2. Usando sistemas de proba optimizados : os sistemas de proba de nova xeración teñen o potencial de facer que os procesos computacionais de Ethereum sexan máis rápidos e eficientes. Os sistemas avanzados como Orion , Binius e GKR poden reducir significativamente o tempo de proba para os cálculos de propósito xeral. Estes sistemas pretenden superar as limitacións das tecnoloxías actuais, aumentando a velocidade de procesamento ao tempo que consumen menos recursos. Para unha rede centrada na escalabilidade e na eficiencia como Ethereum, tales optimizacións proporcionan unha vantaxe significativa. Non obstante, a implementación completa destes novos sistemas require probas exhaustivas e esforzos de compatibilidade dentro do ecosistema.
3. Cambios no custo do gas : historicamente, os custos do gas para as operacións na máquina virtual de Ethereum (EVM) determináronse normalmente en función dos seus custos computacionais . Porén, hoxe en día, outra métrica gañou protagonismo: prover complexit y. Aínda que algunhas operacións son relativamente fáciles de probar, outras teñen unha estrutura máis complexa e tardan máis tempo en verificarse. Axustar os custos do gas non só baseándose no esforzo computacional senón tamén na dificultade de probar as operacións é fundamental para mellorar tanto a seguridade como a eficiencia da rede.

Este enfoque pode minimizar a diferenza entre os escenarios do peor e do caso medio , permitindo un rendemento máis consistente. Por exemplo, as operacións que son máis difíciles de probar poderían ter custos de gas máis elevados, mentres que as que son máis fáciles de probar poderían ter custos máis baixos. Ademais, substituír as estruturas de datos de Ethereum (como a árbore do estado ou a lista de transaccións ) con alternativas compatibles con STARK podería acelerar aínda máis os procesos de proba. Tales cambios axudarían a Ethereum a acadar os seus obxectivos de escalabilidade e seguridade ao tempo que fan máis realista a súa visión de verificabilidade .

Os esforzos de Ethereum para permitir probas de execución representan unha oportunidade importante para acadar os seus obxectivos de verificabilidade. Non obstante, alcanzar este obxectivo require non só innovacións técnicas, senón tamén un aumento dos esforzos de enxeñería e decisións críticas dentro da comunidade. Facer que os procesos de execución sexan verificables na capa 1 debe atopar un equilibrio entre ser accesible a unha ampla base de usuarios, preservar a descentralización e aliñarse coa infraestrutura existente.

Establecer este equilibrio aumenta a complexidade dos métodos utilizados para probar as operacións durante a execución, destacando a necesidade de avances como a xeración de probas paralelas . Ademais, os requisitos de infraestrutura destas tecnoloxías (por exemplo, táboas de busca ) deben ser implementados e operacionalizados, o que aínda esixe investigación e desenvolvemento substanciais.

Por outra banda, os circuítos especializados (por exemplo, ASIC, FPGA, GPU) deseñados especificamente para determinadas tarefas teñen un potencial significativo para acelerar o proceso de xeración de probas. Estas solucións proporcionan unha eficiencia moito maior en comparación co hardware tradicional e poden acelerar os procesos de execución.

Non obstante, os obxectivos de descentralización de Ethereum no nivel de capa 1 impiden que ese hardware sexa accesible só a un grupo selecto de actores. Como resultado, espérase que estas solucións teñan un uso máis extenso nos sistemas de capa 2. Non obstante, a comunidade tamén debe chegar a un consenso sobre os requisitos de hardware para a xeración de probas.

Xorde unha pregunta clave sobre o deseño: debería funcionar a xeración de probas en hardware de consumo, como portátiles de gama alta, ou requirir infraestrutura industrial? A resposta da forma a toda a arquitectura de Ethereum, permitindo unha optimización agresiva para as solucións de Capa 2 á vez que esixe enfoques máis conservadores para a Capa 1.

Finalmente, a implementación de probas de execución está directamente ligada aos outros obxectivos da folla de ruta de Ethereum. A introdución de probas de validez non só apoiaría conceptos como a apatridia, senón que tamén melloraría a descentralización de Ethereum facendo máis accesibles áreas como a aposta individual. O obxectivo é habilitar a aposta incluso nos dispositivos con especificacións máis baixas. Ademais, a reestruturación dos custos do gas no EVM en función da dificultade computacional e da probabilidade podería minimizar a diferenza entre os escenarios do caso medio e do peor dos casos .

Non obstante, tales cambios poderían romper a compatibilidade co sistema actual e obrigar aos desenvolvedores a reescribir o seu código. Por este motivo, a implementación de probas de execución non é só un desafío técnico, é unha viaxe que debe deseñarse para defender os valores a longo prazo de Ethereum.

Último paso para a verdadeira verificabilidade total: o consenso

O mecanismo de consenso de Ethereum esfórzase por establecer un equilibrio único que preserve a descentralización e a accesibilidade ao mesmo tempo que se conseguen obxectivos de verificabilidade. Neste marco, os métodos de consenso probabilísticos e deterministas ofrecen distintas vantaxes e desafíos.

O consenso probabilístico está construído sobre un modelo de comunicación de fofocas. Neste modelo, en lugar de comunicarse directamente con todos os nodos que representan a rede, un nodo comparte información cun conxunto de 64 ou 128 nodos seleccionados aleatoriamente. A selección da cadea dun nodo baséase nesta información limitada, o que introduce a posibilidade de erro. Non obstante, co paso do tempo, a medida que avanza a cadea de bloques, espérase que estas seleccións converxen cara á cadea correcta cunha taxa de erro do 0%.

Unha vantaxe da estrutura probabilística é que cada nodo non transmite a súa vista en cadea como unha mensaxe separada, o que reduce a sobrecarga de comunicación. En consecuencia, tal estrutura pode funcionar con moitos máis nós sen permisos e descentralizados con requisitos do sistema máis baixos.

En cambio, o consenso determinista opera a través dun modelo de comunicación de un para todos. Aquí, un nodo envía a súa vista en cadea como voto a todos os demais nodos. Este enfoque xera unha maior intensidade de mensaxe e, a medida que o número de nós crece, o sistema pode chegar aos seus límites.

Non obstante, a maior vantaxe do consenso determinista é a dispoñibilidade de votos concretos, que lle permiten saber exactamente que nodo votou por que garfo. Isto garante unha finalidade rápida e definitiva da cadea, garantindo que os bloques non poidan ter a súa orde modificada e facéndoos verificables.

Para proporcionar un mecanismo de consenso verificable ao tempo que se preserva a descentralización e unha estrutura sen permisos, Ethereum acadou un equilibrio entre slots e épocas. Os slots, que representan intervalos de 12 segundos, son as unidades básicas onde un validador se encarga de producir un bloque. Aínda que o consenso probabilístico empregado a nivel de slot permite que a cadea funcione de forma máis flexible e descentralizada, ten limitacións en canto á ordenación e verificabilidade definitivas.

As épocas, que abarcan 32 slots, introducen consenso determinista. Neste nivel, os validadores votan para finalizar a orde da cadea, garantindo a certeza e facendo que a cadea sexa verificable. Non obstante, aínda que esta estrutura determinista proporciona verificabilidade a través de votos concretos a nivel de época, non pode ofrecer unha verificabilidade plena dentro das propias épocas debido á estrutura probabilística. Para abordar esta brecha e fortalecer a estrutura probabilística dentro das épocas, Ethereum desenvolveu unha solución coñecida como Comité de sincronización.

Protocolo de cliente lixeiro de Altair: Comité de sincronización

O Comité de sincronización é un mecanismo introducido coa actualización de Altair para superar as limitacións do consenso probabilístico de Ethereum e mellorar a verificabilidade da cadea para clientes lixeiros. O comité está formado por 512 validadores seleccionados aleatoriamente que serven durante 256 épocas (~ 27 horas). Estes validadores producen unha sinatura que representa o xefe da cadea, o que permite aos clientes lixeiros verificar a validez da cadea sen necesidade de descargar os datos históricos da cadea. O funcionamento do Comité de Sincronización pódese resumir do seguinte xeito:

1. Formación do Comité : 512 validadores son seleccionados aleatoriamente entre todos os validadores da rede. Esta selección actualízase regularmente para manter a descentralización e evitar a dependencia dun grupo específico.
2. Xeración de sinaturas : os membros do comité producen unha sinatura que representa o estado máis recente da cadea. Esta sinatura é unha sinatura colectiva BLS creada polos membros e utilízase para verificar a validez da cadea.
3. Verificación de clientes lixeiros : os clientes lixeiros poden verificar a corrección da cadea simplemente comprobando a sinatura do comité de sincronización. Isto permítelles rastrexar de forma segura a cadea sen descargar os datos da cadea anterior.

Non obstante, o Comité de Sincronización foi obxecto de críticas nalgunhas áreas. Notablemente, o protocolo carece dun mecanismo para reducir os validadores por comportamento malicioso , aínda que os validadores seleccionados actúen intencionadamente contra o protocolo. Como resultado, moitos consideran que o comité de sincronización é un risco de seguridade e abstéñense de clasificalo completamente como un protocolo de cliente lixeiro . Non obstante, a seguridade do Comité de Sincronización foi matematicamente probada e pódense atopar máis detalles neste artigo sobre Cortes do Comité de Sincronización .

A ausencia dun mecanismo de corte no protocolo non é unha opción de deseño senón unha necesidade derivada da natureza do consenso probabilístico. O consenso probabilístico non ofrece garantías absolutas sobre o que observa un validador. Aínda que a maioría dos validadores informen que un garfo en particular é o máis pesado, aínda pode haber validadores excepcionais que observen un garfo diferente como máis pesado. Esta incerteza fai que sexa difícil probar a intención maliciosa e, polo tanto, imposíbel penalizar a mala conduta.

Neste contexto, en lugar de etiquetar o Comité de sincronización como inseguro, sería máis preciso describilo como unha solución ineficiente. O problema non se deriva do deseño ou funcionamento mecánicos do Comité de Sincronización senón da natureza inherente do consenso probabilístico. Dado que o consenso probabilístico non pode ofrecer garantías definitivas sobre o que observan os nodos, o Comité de Sincronización é unha das mellores solucións que se poden deseñar dentro deste modelo. Non obstante, isto non elimina as debilidades do consenso probabilístico para garantir a finalidade da cadea. O problema non reside no mecanismo senón dentro da estrutura de consenso actual de Ethereum.

Debido a estas limitacións, hai esforzos continuos no ecosistema de Ethereum para redeseñar o mecanismo de consenso e implementar solucións que proporcionen finalidade determinista en períodos máis curtos. Propostas como Orbit-SSF e 3SF pretenden remodelar a estrutura de consenso de Ethereum desde cero, creando un sistema máis eficaz para substituír o consenso probabilístico. Estes enfoques buscan non só acurtar o tempo de finalidade da cadea senón tamén ofrecer unha estrutura de rede máis eficiente e verificable. A comunidade de Ethereum segue desenvolvendo e preparando activamente estas propostas para unha futura implementación.

Snarkificación do consenso

The Verge ten como obxectivo mellorar os mecanismos de consenso actuais e futuros de Ethereum facéndoos máis verificables a través da tecnoloxía zk-proof, en lugar de substituílos por completo. Este enfoque busca modernizar os procesos de consenso de Ethereum preservando os seus principios fundamentais de descentralización e seguridade. A optimización de todos os procesos de consenso históricos e actuais da cadea coas tecnoloxías zk xoga un papel fundamental na consecución dos obxectivos de escalabilidade e eficiencia a longo prazo de Ethereum. As operacións fundamentais utilizadas na capa de consenso de Ethereum son de gran importancia nesta transformación tecnolóxica. Vexamos máis de cerca estas operacións e os retos aos que se enfrontan.

• ECADDs :
• Finalidade : esta operación úsase para agregar as claves públicas dos validadores e é vital para garantir a precisión e a eficiencia da cadea. Grazas á natureza agregable das sinaturas BLS, pódense combinar varias sinaturas nunha única estrutura. Isto reduce a sobrecarga de comunicación e fai que os procesos de verificación na cadea sexan máis eficientes. Asegurar a sincronización entre grandes grupos de validadores de forma máis eficaz fai que esta operación sexa crítica.
• Desafíos : como se mencionou anteriormente, os validadores de Ethereum votan a orde da cadea durante épocas. Hoxe, Ethereum é unha rede con aproximadamente 1,1 millóns de validadores . Se todos os validadores tentasen propagar os seus votos simultaneamente, crearía unha tensión significativa na rede. Para evitar isto, Ethereum permite que os validadores voten por slot durante unha época, onde só 1/32 de todos os validadores votan por slot. Aínda que este mecanismo reduce a sobrecarga de comunicación da rede e fai que o consenso sexa máis eficiente, dado o reconto de validadores de hoxe, uns 34.000 validadores votan en cada slot. Isto tradúcese en aproximadamente 34.000 operacións ECADD por slot .
• Maridaxes :
• Propósito : as operacións de emparellamento utilízanse para verificar sinaturas BLS , garantindo a validez das épocas da cadea. Esta operación permite a verificación por lotes de sinaturas. Non obstante, non é compatible con zk , polo que é moi custoso probar mediante a tecnoloxía zk-proof. Isto supón un gran desafío para crear un proceso de verificación integrado con tecnoloxías de coñecemento cero.
• Desafíos : as operacións de emparellamento en Ethereum están limitadas a un máximo de 128 atestados (sinaturas agregadas) por slot, o que resulta en menos operacións de emparellamento en comparación cos ECADD. Non obstante, a falta de compatibilidade con zk nestas operacións supón un desafío importante. Probar unha operación de emparellamento con probas zk é miles de veces máis caro que probar unha operación ECADD [2]. Isto fai que a adaptación das operacións de emparellamento para tecnoloxías de coñecemento cero sexa un dos maiores obstáculos nos procesos de verificación de consenso de Ethereum.
• Hash SHA256 :
• Propósito e: As funcións hash SHA256 úsanse para ler e actualizar o estado da cadea, garantindo a integridade dos datos da cadea. Non obstante, a súa falta de compatibilidade con zk leva a ineficiencias nos procesos de verificación baseados na proba de zk, o que supón un gran obstáculo para os futuros obxectivos de verificabilidade de Ethereum.
• Retos : as funcións hash SHA256 úsanse con frecuencia para ler e actualizar o estado da cadea. Non obstante, a súa antipatía zk entra en conflito cos obxectivos de verificación baseados na proba de zk de Ethereum. Por exemplo, entre dúas épocas, cada validador executa o STF de Consensus Layer de Ethereum para actualizar o estado con recompensas e penalizacións baseadas no rendemento do validador durante a época. Este proceso depende en gran medida das funcións hash SHA256, o que aumenta significativamente os custos nos sistemas baseados en zk-proof. Isto crea unha barreira substancial para aliñar o mecanismo de consenso de Ethereum coas tecnoloxías zk.

As operacións ECADD, Pairing e SHA256 utilizadas na capa de consenso actual xogan un papel fundamental nos obxectivos de verificabilidade de Ethereum. Non obstante, a súa falta de compatibilidade con zk supón importantes retos no camiño para acadar estes obxectivos. As operacións ECADD crean unha carga custosa debido ao alto volume de votos dos validadores, mentres que as operacións de emparellamento, a pesar de ser menos en número, son miles de veces máis caras de probar con zk-proofs.

Ademais, a antipatía zk das funcións hash SHA256 fai que probar a transición de estado da cadea de balizas sexa extremadamente difícil. Estes problemas destacan a necesidade dunha transformación integral para aliñar a infraestrutura existente de Ethereum con tecnoloxías de coñecemento cero.

Solución "Beam Chain": reimaxinar a capa de consenso de Ethereum

O 12 de novembro de 2024, durante a súa presentación en Devcon, Justin Drake presentou unha proposta chamada "Beam Chain " destinada a transformar fundamental e integralmente a capa de consenso de Ethereum. A cadea Beacon estivo no núcleo da rede de Ethereum durante case cinco anos. Non obstante, durante este período, non houbo cambios estruturais importantes na cadea Beacon. Pola contra, os avances tecnolóxicos progresaron rapidamente, superando con creces a natureza estática da cadea Beacon.

Na súa presentación, Justin Drake fixo fincapé en que Ethereum aprendeu leccións importantes durante estes cinco anos en áreas críticas como a comprensión de MEV , os avances nas tecnoloxías SNARK e a conciencia retrospectiva dos erros tecnolóxicos . Os deseños informados por estas novas aprendizaxes clasifícanse en tres alicerces principais: Produción de bloques , Replanteo e Criptografía . A seguinte imaxe resume estes deseños e a folla de ruta proposta:

• As caixas verdes e grises representan desenvolvementos incrementais que se poden implementar un por un cada ano. Este tipo de melloras, ao igual que as actualizacións anteriores, pódense integrar paso a paso sen interromper a arquitectura existente de Ethereum.

• As caixas vermellas , por outra banda, significan cambios de alta sinerxía , a gran escala e fundamentais que deben implementarse xuntos. Segundo Drake, estes cambios teñen como obxectivo avanzar a capacidade e verificabilidade de Ethereum nun gran salto.

  
  

Nesta sección, examinamos os pasos de Consenso, Estado e Execución de The Verge en detalle, e un dos problemas máis destacados destacados durante este proceso é o uso da función de hash SHA256 na cadea Beacon de Ethereum. Aínda que SHA256 xoga un papel central para garantir a seguridade da rede e as transaccións de procesamento, a súa falta de compatibilidade con zk supón un obstáculo importante para acadar os obxectivos de verificabilidade de Ethereum. O seu alto custo computacional e a súa incompatibilidade coas tecnoloxías zk fan que sexa un problema crítico que debe ser abordado nos desenvolvementos futuros de Ethereum.

A folla de ruta de Justin Drake, presentada durante a súa charla Devcon, prevé substituír SHA256 na cadea Beacon con funcións hash amigables con zk como Poseidon . Esta proposta ten como obxectivo modernizar a capa de consenso de Ethereum, facéndoa máis verificable, eficiente e aliñada coas tecnoloxías a proba de zk.

Neste contexto, vemos que Ethereum non só se enfronta a retos coas funcións hash non amigables con zk, senón que tamén necesita reavaliar as sinaturas dixitais utilizadas na súa capa de consenso para a seguridade a longo prazo. Co avance da computación cuántica, os algoritmos de sinatura dixital como ECDSA actualmente en uso poderían enfrontarse a ameazas importantes. Tal e como se indica nas directrices publicadas polo NIST , as variantes de ECDSA cun nivel de seguridade de 112 bits quedarán obsoletas en 2030 e completamente prohibidas en 2035 . Isto require unha transición para Ethereum e redes similares cara a alternativas máis resistentes, como sinaturas cuánticas seguras no futuro.

Neste punto, as sinaturas baseadas en hash xorden como solucións resistentes á cuántica que poderían desempeñar un papel fundamental para apoiar os obxectivos de seguridade e verificabilidade da rede. Abordar esta necesidade tamén elimina o segundo obstáculo importante para facer verificable a cadea Beacon: sinaturas BLS . Un dos pasos máis significativos que pode tomar Ethereum para garantir a seguridade cuántica é adoptar solucións post-cuánticas como sinaturas baseadas en hash e SNARK baseados en hash .

Como subliñou Justin Drake na súa presentación sobre Devcon , as funcións hash son inherentemente resistentes ás computadoras cuánticas debido á súa dependencia da resistencia previa á imaxe, converténdoas nun dos bloques fundamentais da criptografía moderna. Esta propiedade garante que mesmo os ordenadores cuánticos non poidan realizar unha enxeñaría inversa eficiente da entrada orixinal dun hash determinado, preservando a súa seguridade.

Os sistemas de sinatura baseados en hash permiten que os validadores e os certificadores xeren sinaturas totalmente baseadas en funcións hash, garantindo a seguridade post-cuántica á vez que proporcionan un maior nivel de verificabilidade en toda a rede, especialmente se se utiliza unha función hash compatible con SNARK. Este enfoque non só mellora a seguridade da rede, senón que tamén fai que a infraestrutura de seguridade a longo prazo de Ethereum sexa máis robusta e a proba de futuro.

Este sistema baséase na combinación de sinaturas baseadas en hash e SNARK baseados en hash (probas tipo STARK) para crear esquemas de sinatura agregables . As sinaturas agregables comprimen miles de sinaturas nunha única estrutura, reduíndoa a só uns centos de kilobytes de proba. Esta compresión diminúe significativamente a carga de datos na rede ao tempo que acelera moito os procesos de verificación. Por exemplo, os miles de firmas de validación producidas para un único slot en Ethereum poden representarse cunha única sinatura agregada, o que aforra espazo de almacenamento e potencia de cálculo.

Non obstante, a característica máis notable deste esquema é a súa agregación infinitamente recursiva . É dicir, un grupo de sinaturas pódese combinar baixo outro grupo e este proceso pode continuar ao longo da cadea. Con este mecanismo e tendo en conta os futuros avances tecnolóxicos, é xusto dicir que isto abre a porta a posibilidades que actualmente non son alcanzables con BLS.

Conclusión

O camiño de Ethereum cara á verificabilidade representa un cambio fundamental na tecnoloxía blockchain. A iniciativa Verge aborda as ineficiencias básicas a través de Verkle Trees para a verificación do estado e as probas STARK para transicións escalables.

Unha das propostas máis ambiciosas é a Beam Chain , un completo redeseño da capa de consenso de Ethereum. Ao abordar as limitacións da cadea Beacon e incorporar alternativas amigables con zk, este enfoque ten como obxectivo mellorar a escalabilidade de Ethereum preservando os seus principios fundamentais de descentralización e accesibilidade . Non obstante, a transición tamén destaca os retos aos que se enfronta Ethereum para equilibrar as demandas computacionais co seu obxectivo de manter unha rede inclusiva e sen permisos.

Co NIST que planea eliminar a criptografía de curva elíptica actual para 2035, Ethereum debe adoptar solucións resistentes á cuántica como sinaturas baseadas en hash e Poseidon. Estas solucións presentan os seus propios compromisos de eficiencia.

O uso de STARK na folla de ruta de Ethereum enfatiza aínda máis a escalabilidade e a verificabilidade. Aínda que destacan por ofrecer probas transparentes e resistentes aos cuánticos, a súa integración introduce desafíos relacionados cos custos computacionais da proba e as ineficiencias dos pequenos datos . Estes obstáculos deben abordarse para realizar plenamente a visión de Ethereum sobre a apatridia e a verificación eficiente de bloques, garantindo que a rede siga sendo robusta ante a crecente demanda.

A pesar destes avances, quedan retos fundamentais. Ethereum debe navegar por cuestións de compatibilidade con zk , escalabilidade de consenso e as complexidades da integración da criptografía resistente á cuántica . Ademais, a compatibilidade con versións anteriores da infraestrutura existente supón obstáculos prácticos que requiren solucións de enxeñería coidadosas para evitar interrupcións tanto para os desenvolvedores como para os usuarios.

O que distingue a Ethereum non son só as súas innovacións técnicas, senón o seu enfoque iterativo para resolver algúns dos problemas máis difíciles da cadea de bloques. O camiño a seguir, xa sexa a través de tecnoloxías como Beam Chain , Verkle Trees ou STARK proofs , depende dun esforzo colaborativo de desenvolvedores, investigadores e da comunidade máis ampla. Estes avances non tratan de lograr a perfección dun día para outro, senón de crear unha base para unha Internet transparente , descentralizada e verificable .

A evolución de Ethereum subliña o seu papel como actor crítico na configuración da era Web3. Ao abordar os retos actuais con solucións prácticas, Ethereum achégase a un futuro onde a verificabilidade , a resistencia cuántica e a escalabilidade convértense no estándar, non na excepción.