The Verge: un camiño para facer que Ethereum sexa verificable e sostible

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 , 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! serie de seis partes publicada recentemente por Vitalik sobre o futuro de Ethereum 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 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. a folla de ruta 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 " " 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. algoritmos de consenso 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: : pode querer ler un dato na cadea de bloques, pero non ten acceso ao estado xa que non executa un . 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. Estado nodo completo : 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. Execución : 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. Consenso eu Se isto parece confuso ou pouco claro, non te preocupes. Repasaremos cada un destes aspectos en detalle. Comecemos por como verificar da cadea de bloques. o estado 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 . Este valor é unha representación compacta de todo o estado de Ethereum, que consiste nun hash de 64 caracteres. stateRoot 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 para organizar e resumir diferentes partes do estado. Merkle Tree 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 ú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: Keccak : a mesma entrada sempre producirá a mesma saída. Determinismo : independentemente da lonxitude da entrada, a lonxitude de saída sempre é fixa. Lonxitude de saída fixa : é practicamente imposible derivar a entrada orixinal da saída. Propiedade unidireccional : ata un pequeno cambio na entrada produce unha saída completamente diferente. Así, unha entrada específica mapea a unha saída practicamente única. Singularidade 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 é 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: árbore de Merkle : 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. Nodos folla : 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. Nodos de rama : 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. Nodo raíz Se estás a preguntar como construír unha árbore deste tipo, só hai dous pasos sinxelos: : 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. Creación de nodos de folla : 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. Combinar e 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 permiten que o 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 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. de Merkle verificador raíz de Merkle 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. : primeiro, haxeamos os datos #4 para obter o hash #4. Comeza cos datos 4 : 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. Combinar con irmáns : 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. Mover arriba da árbore : 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. Paso final 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 r: número de nodos fillos por rama. Factor de ramificación : o tamaño do conxunto de datos que se representa na árbore. Tamaño total dos datos 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. : 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. Pequeno factor de ramificación (p. ex., Árbore Merkle binaria) : 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. Factor de ramificación maior (p. ex., 4) 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 , Ethereum pretende substituír por unha estrutura máis eficiente coñecida como . 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 Merkle Trees Verkle Trees The Verge: revolucionando a verificabilidade en Ethereum 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. The Verge 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 con , os validadores de Ethereum tiveron dúas responsabilidades principais: Proof-of-Stake The Merge : apoiar o bo funcionamento dos protocolos de consenso tanto probabilísticos como deterministas e aplicar o algoritmo de elección de garfo. Garantir o consenso : 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. Comprobación da precisión do bloque 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 s é unha parte fundamental deste proceso. Inicialmente, 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 . Verkle Tree The Verge peor dos casos Segundo os cálculos de Vitalik, o tamaño medio da proba é duns , o que parece manexable. Non obstante, no peor dos casos, o tamaño da proba pode aumentar a . Si, leches correctamente: 330 MB. 4 KB 330 MB A extrema ineficiencia das árbores Merkle de Ethereum nos peores escenarios deriva de dúas razóns principais: : 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. Uso de árbores hexárias : 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 , este enfoque impón unha carga importante para lograr a verificabilidade total. Non merkelización do código 24 KB 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 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 . árbores binarias de Merkle 10 MB Aínda que esta é unha mellora significativa, é importante ter en conta que este custo aplícase á verificación . 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. dun só dato Por estes motivos, a comunidade de Ethereum propuxo dúas solucións distintas para resolver o problema: Verkle Trees Probas STARK + Árbores Merkle binarias Verkle trees e compromisos vectoriais As , como o nome indica, son estruturas arbóreas similares ás . Non obstante, a diferenza máis significativa reside na eficacia que ofrecen durante os procesos de verificación. En , 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. Verkle Tree Merkle Trees Merkle Trees Pola contra, utiliza unha estrutura especializada coñecida como " ", máis concretamente, un compromiso vectorial baseado . 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. Verkle Trees Compromisos vectoriales baseados en curvas elípticas no Argumento do produto interno (IPA) 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, , usado en Merkle Trees, tamén se pode considerar unha forma de . 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. Os compromisos vectoriales Merkle Proofs compromiso vectorial A diferenza de Merkle Trees, Verkle Trees empregan que ofrecen dúas vantaxes fundamentais: compromisos vectoriais baseados en curvas elípticas . 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. Os compromisos vectoriais baseados en curvas elípticas eliminan a necesidade de detalles de elementos distintos dos datos que se verifican . 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 . 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. 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 artigo de Dankrad Feist 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 . 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. computadoras cuánticas 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 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 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. Dankrad Feist compromisos KZG Probas STARK + árbores Binary Merkle 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 , 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. Verkle Trees compromisos vectoriales baseados en curvas elípticas 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 . Aquí é onde s e presentan unha alternativa sólida para construír unha infraestrutura de verificación máis sólida para o futuro. solucións resistentes á cuántica STARK Proof Binary Merkle Trees No proceso de verificación do estado de Ethereum, o de Merkle Trees pódese reducir (de 16 a 2) usando . 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 , o que é importante. Aquí é onde entran en xogo , que comprimen estas grandes probas binarias Merkle a só . factor de ramificación Binary Merkle Trees os 10 MB os STARK Proof 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 : o proceso de xeración de probas STARK é computacionalmente intensivo, especialmente no lado do probador, o que pode aumentar os custos operativos. Alta carga computacional para probadores 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. Ineficiencia nas probas de pequenos datos: A seguridade cuántica ten un custo: carga computacional Prover-Side A Merkle Proof dun bloque pode incluír aproximadamente no peor dos casos, este número pode chegar a . Nestes casos, unha proba STARK debería procesar uns . Aquí é onde entran en xogo funcións hash amigables con zk como , optimizadas especificamente para probas STARK para reducir esta carga. 330.000 hash e, 660.000 200.000 hashes por segundo Poseidon Poseidon está deseñado para funcionar de forma máis fluida con probas de ZK en comparación cos algoritmos hash tradicionais como e . A razón principal desta compatibilidade reside en como funcionan os algoritmos hash tradicionais: procesan as entradas como datos binarios (0s e 1s). SHA256 Keccak 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 , acelerando drasticamente a súa integración con probas de ZK. de campos primarios 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 , 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. Iniciativa de Criptanálisis de Poseidon Por exemplo, as probas STARK que usan estas funcións hash tradicionais só poden procesar entre e 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. 10.000 30.000 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: : 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. Validación da transacción posterior a AA : 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. Chamadas RPC de clientes lixeiros : 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. Listas de inclusió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, , 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. os SNARK As probas STARK adoitan ter un tamaño de , o que é unhas que as probas de SNARK, que son só . 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 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. 40 a 50 KB 175 veces maior 288 bytes Merkle Proofs Como se resume na táboa, Ethereum ten catro camiños potenciais para escoller: 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 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. Verkle Trees homomórficas aditivas 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 ve Verkle Trees como unha medida temporal para gañar tempo para que madurezan os STARK e outras tecnoloxías. Ademais, os 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. Vitalik compromisos vectoriais baseados en curvas elípticas 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 A combinación de con funcións hash conservadoras ben establecidas como ou 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. STARK SHA256 BLAKE 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 , 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 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. latencia de proba as propostas de gas multidimensionais STARKs + Funcións Hash relativamente novas Os STARK combinados con (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 diferenza das funcións hash tradicionais, permiten a xeración de probas en tan só . 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. funcións hash de nova xeración compatibles con STARK a latencia do probador 1-2 segundos 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 . 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. atrasar os obxectivos de verificabilidade de Ethereum Merkle Trees a base de 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. Merkle Trees baseado en celosía 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, imaginouse como un fito centrado unicamente na transición da árbore do estado de Ethereum de a para mellorar a verificabilidade do estado. Co paso do tempo, con todo, evolucionou nunha iniciativa máis ampla destinada a mellorar a verificabilidade das . 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 . Isto achegaría a Ethereum a lograr a súa visión de "verdadeira descentralización". The Verge Merkle Trees Verkle Tree transicións estatais e do consenso Cliente Lixeiro Cal é a definición do problema, de novo? Como mencionamos anteriormente, os validadores executan unha función chamada 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 , é correcto. STF (Función de transición de estado) raíz do estado Os altos requisitos do sistema para converterse nun validador derivan principalmente da necesidade de realizar este proceso de forma eficiente. Se queres converter un (si, incluso un frigorífico) nun validador de Ethereum coa axuda dalgún software instalado, afrontas : frigorífico intelixente dous obstáculos importantes 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 nin sequera coas solucións de verificación estatal que comentamos ata agora. a execución Aínda que tivese acceso aos datos necesarios para STF, non terá a potencia computacional necesaria para realizar de principio a fin ou para construír unha nova árbore de estado. a execución Para resolver os problemas provocados por que os Clientes Lixeiros non teñan acceso nin ao nin á totalidade do último bloque, propón que o propoñente realice a e achegue unha proba ao bloque. Esta proba incluiría a transición da á así como o hash do bloque. Con isto, os clientes lixeiros poden validar a transición de estado usando só , sen necesitar unha proba de zk. estado anterior The Verge execución raíz de estado anterior raíz de estado seguinte, tres hash de 32 bytes Non obstante, dado que esta proba funciona mediante hash, sería incorrecto dicir que só valida a . Pola contra, a proba anexa ao bloque debe validar : transición de estado varias cousas á vez Estado raíz no bloque anterior = S, Estado raíz no seguinte bloque = S + 1, Bloque hash = H O bloque en si debe ser válido e a 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. . proba de estado En resumo: validación do bloque e a proba de estado que o acompaña Cando o STF se execute utilizando os datos necesarios para a súa execución e incluídos no bloque correspondente a , os datos que deben cambiar de estado deben actualizarse correctamente. . H En resumo: Validación da transición estatal 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 que nos referimos anteriormente, é xeralmente xusto dicir que normalmente hai un 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 , tamén indica que xerar tales probas para garantir a corrección da execución será relativamente difícil para o . Coa velocidade actual de Ethereum, hai que probar un bloque de Ethereum en menos de . Non obstante, mesmo o EVM Prover máis rápido que temos hoxe só pode probar un bloque medio en aproximadamente .[1] analoxía Prover-Verifier á equilibrio computacional verificador probador 4 segundos 15 segundos Dito isto, hai que podemos tomar para superar este gran desafío: tres camiños distintos : unha das vantaxes significativas das probas ZK é a súa . 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. Paralelización na proba e agregación capacidade de agregación 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. : 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 , e 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. Usando sistemas de proba optimizados Orion Binius GKR : historicamente, os custos do gas para as operacións na máquina virtual de Ethereum (EVM) determináronse normalmente en función dos seus . Porén, hoxe en día, outra métrica gañou protagonismo: 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. Cambios no custo do gas custos computacionais prover complexit Este enfoque pode minimizar a diferenza entre os escenarios e , 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 ou ) con 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 . do peor do caso medio árbore do estado a lista de transaccións alternativas compatibles con STARK visión de verificabilidade Os esforzos de Ethereum para permitir 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. probas de execución 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 . Ademais, os requisitos de infraestrutura destas tecnoloxías (por exemplo, ) deben ser implementados e operacionalizados, o que aínda esixe investigación e desenvolvemento substanciais. a xeración de probas paralelas táboas de busca Por outra banda, (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. os circuítos especializados Non obstante, 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. os obxectivos de descentralización de Ethereum no nivel de capa 1 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 non só apoiaría conceptos como 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 e . probas de validez a apatridia, do caso medio 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 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 mecanismo de consenso 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%. O consenso probabilístico 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 e descentralizados con requisitos do sistema máis baixos. sen permisos En cambio, opera a través dun 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. o consenso determinista modelo de comunicación 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 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. mecanismo de consenso verificable 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 é 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: Comité de sincronización : 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. Formación do Comité : 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. Xeración de sinaturas : 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. Verificación de clientes lixeiros Non obstante, o Comité de Sincronización foi obxecto de críticas nalgunhas áreas. Notablemente, o protocolo , 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 . Non obstante, a seguridade do Comité de Sincronización foi e pódense atopar máis detalles . carece dun mecanismo para reducir os validadores por comportamento malicioso protocolo de cliente lixeiro matematicamente probada 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 e 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. Orbit-SSF 3SF 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 : 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. Finalidade : como se mencionou anteriormente, os validadores de Ethereum votan a orde da cadea durante épocas. Hoxe, Ethereum é unha rede con aproximadamente . 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ó 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 votan en cada slot. Isto tradúcese en aproximadamente . Desafíos 1,1 millóns de validadores 1/32 34.000 validadores 34.000 operacións ECADD por slot : Maridaxes : as operacións de emparellamento utilízanse para verificar , garantindo a validez das épocas da cadea. Esta operación permite a verificación por lotes de sinaturas. Non obstante, non é , 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. Propósito sinaturas BLS compatible con zk : 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. Desafíos : Hash SHA256 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. Propósito : 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 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. Retos o STF de Consensus Layer 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 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. transición de estado da cadea de balizas 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, presentou unha proposta chamada " 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. Justin Drake "Beam Chain 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 , e . Os deseños informados por estas novas aprendizaxes clasifícanse en tres alicerces principais: , e . A seguinte imaxe resume estes deseños e a folla de ruta proposta: a comprensión de MEV os avances nas tecnoloxías SNARK a conciencia retrospectiva dos erros tecnolóxicos Produción de bloques Replanteo Criptografía representan 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 verdes e grises desenvolvementos incrementais , por outra banda, significan cambios , e que deben implementarse xuntos. Segundo Drake, estes cambios teñen como obxectivo avanzar a capacidade e verificabilidade de Ethereum nun gran salto. As caixas vermellas de alta sinerxía a gran escala fundamentais Nesta sección, examinamos os pasos de e de The Verge en detalle, e un dos problemas máis destacados destacados durante este proceso é o uso da 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. Consenso, Estado Execución función de hash SHA256 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 . 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. Poseidon 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 actualmente en uso poderían enfrontarse a ameazas importantes. Tal e como se indica nas directrices publicadas polo , . Isto require unha transición para Ethereum e redes similares cara a alternativas máis resistentes, como no futuro. ECDSA NIST as variantes de ECDSA cun nivel de seguridade de 112 bits quedarán obsoletas en 2030 e completamente prohibidas en 2035 sinaturas cuánticas seguras Neste punto, 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: . Un dos pasos máis significativos que pode tomar Ethereum para garantir a seguridade cuántica é adoptar solucións post-cuánticas como e . as sinaturas baseadas en hash sinaturas BLS sinaturas baseadas en hash SNARK baseados en hash Como subliñou Justin Drake na , 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. súa presentación sobre Devcon 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 e (probas tipo STARK) para crear . 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. de sinaturas baseadas en hash SNARK baseados en hash esquemas de sinatura agregables Non obstante, a característica máis notable deste esquema é a súa . É 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. agregación infinitamente recursiva 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 , un completo redeseño da capa de consenso de Ethereum. Ao abordar as limitacións da e incorporar alternativas amigables con zk, este enfoque ten como obxectivo mellorar a escalabilidade de Ethereum preservando os seus principios fundamentais de e . 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. Beam Chain cadea Beacon descentralización accesibilidade 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 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 e . 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. STARK custos computacionais da proba as ineficiencias dos pequenos datos A pesar destes avances, quedan retos fundamentais. Ethereum debe navegar por cuestións de , escalabilidade de consenso e as complexidades da integración . 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. compatibilidade con zk da criptografía resistente á cuántica O que distingue a Ethereum non son só as súas innovacións técnicas, senón o seu 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 , ou , 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 , e . enfoque iterativo Beam Chain Verkle Trees STARK proofs transparente descentralizada 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 , e convértense no estándar, non na excepción. a verificabilidade a resistencia cuántica a escalabilidade Nota do autor: unha versión deste artigo publicouse . aquí