Arguiblemente el evento más importante en la historia de Ethereum, The Merge, tuvo lugar el 15 de septiembre de 2022. Marcó la transición de la red de a , cambiando fundamentalmente cómo Ethereum alcanza el consenso. Pero, ¿por qué se llama 'la Fusión' y no 'la transición'? Prueba de Trabajo Prueba de Participación Antes de la Fusión, Ethereum operaba el consenso de Prueba de Trabajo, un mecanismo que requería que los 'mineros' resolvieran complejos acertijos criptográficos para validar transacciones y crear nuevos bloques. La Prueba de Trabajo es genial, pero viene con muchas limitaciones, como el uso de una inmensa potencia computacional que conduce a un alto consumo de electricidad y preocupaciones ambientales, baja capacidad de transacción debido a su tiempo de verificación más lento, lo que representa un desafío para la adopción institucional, una mayor posibilidad de riesgo de centralización, ya que podría consolidarse en unas pocas entidades mineras poderosas, etc. Estas y otras razones fueron las motivaciones que impulsaron a la Fundación Ethereum, apenas tres años después de su creación, a comenzar a construir un nuevo Consenso llamado Prueba de Participación, diseñado para resolver la mayoría de los problemas que desafiaron a la Prueba de Trabajo. El 1 de diciembre de 2020, Ethereum lanzó su primera versión de Prueba de Participación, una nueva cadena llamada cadena Beacon. La cadena Beacon no procesaba transacciones de usuarios. Su único propósito era coordinar validadores y alcanzar el consenso utilizando un nuevo mecanismo llamado Gasper. Las transacciones todavía se procesaban en la cadena principal de Prueba de Trabajo, por lo que ambas cadenas, la cadena principal de Ethereum y la cadena Beacon, se ejecutaban en paralelo. Durante casi dos años, estas dos cadenas operaron de forma independiente. Luego, el 15 de septiembre de 2022, la cadena original abandonó su consenso basado en minería y se conectó directamente a la cadena Beacon. Así, dos cadenas se convirtieron en una. Es por eso que se llama la Fusión, no la transición. Hoy en día, Ethereum opera como una blockchain de dos capas. La capa de consenso, que solía ser la cadena Beacon, maneja las propuestas de bloques, las atestaciones y la finalidad. La capa de ejecución, la cadena original de Ethereum, maneja el procesamiento de transacciones. Es posible que haya oído referirse a estas como Eth2 y Eth1, respectivamente, pero la Fundación Ethereum ha desaprobado esa nomenclatura porque implicaba dos redes separadas en lugar de dos capas de un solo sistema. Este artículo se centra en la capa de consenso. Específicamente, cómo opera la cadena Beacon como una máquina de estados. ¿Qué es el Estado Beacon (BeaconState)? Para comprender cómo transiciona la máquina de estados, primero debemos entender qué contiene realmente el estado en el génesis de la cadena. El estado de la cadena Beacon se representa mediante un único objeto llamado BeaconState. Contiene todo lo que la capa de consenso necesita para funcionar. A veces se le conoce como el "objeto Dios". La especificación agrupa los campos por propósito, que es la forma más clara de repasarlos. class BeaconState(Container): genesis_time: uint64 genesis_validators_root: Root slot: Slot fork: Fork latest_block_header: BeaconBlockHeader block_roots: Vector[Root, SLOTS_PER_HISTORICAL_ROOT] state_roots: Vector[Root, SLOTS_PER_HISTORICAL_ROOT] historical_roots: List[Root, HISTORICAL_ROOTS_LIMIT] eth1_data: Eth1Data eth1_data_votes: List[Eth1Data, EPOCHS_PER_ETH1_VOTING_PERIOD * SLOTS_PER_EPOCH] eth1_deposit_index: uint64 validators: List[Validator, VALIDATOR_REGISTRY_LIMIT] balances: List[Gwei, VALIDATOR_REGISTRY_LIMIT] randao_mixes: Vector[Bytes32, EPOCHS_PER_HISTORICAL_VECTOR] slashings: Vector[Gwei, EPOCHS_PER_SLASHINGS_VECTOR] previous_epoch_attestations: List[PendingAttestation, MAX_ATTESTATIONS * SLOTS_PER_EPOCH] current_epoch_attestations: List[PendingAttestation, MAX_ATTESTATIONS * SLOTS_PER_EPOCH] justification_bits: Bitvector[JUSTIFICATION_BITS_LENGTH] previous_justified_checkpoint: Checkpoint current_justified_checkpoint: Checkpoint finalized_checkpoint: Checkpoint Versionado: genesis_time: uint64 genesis_validators_root: Root slot: Slot fork: Fork Las primeras cuatro variables responden a la pregunta "¿qué cadena somos y dónde estamos en esa cadena?". Estos campos anclan la identidad de la cadena y le dicen a cada nodo qué reglas de protocolo seguir. El tiempo de génesis es una marca de tiempo Unix que se establece al comienzo de la cadena y nunca cambia. La marca de tiempo de génesis de la cadena Beacon es 1606824023, que es exactamente el 1 de diciembre de 2020 a las 12:00:23 PM UTC. Si alguna vez ha consultado 'block.timestamp' desde un contrato inteligente, ese valor se calcula a partir de este campo. La raíz de los validadores de génesis, al igual que la marca de tiempo, también se agregó al comienzo de la cadena. Básicamente, actúa como el separador de dominio; se mezcla con la firma del validador durante las propuestas de bloques y las atestaciones para diferenciar la red principal de Ethereum de cualquier otra cadena. Una Ranura (Slot) es simplemente un contador que nos dice dónde está la cadena en el tiempo. Se incrementa cada 12 segundos, independientemente de si se produce un bloque. Mientras que una Bifurcación (Fork) es un objeto que contiene tres campos: la versión anterior de la cadena, la versión actual de la cadena y la época. Cuando se realizó la primera actualización en la cadena beacon el 27 de octubre de 2021, las versiones cambiaron de Fase 0 a Altair. La versión actual, en el momento de escribir este artículo, es Fulu y la versión anterior es Electra. Al igual que la raíz del validador, el hash de la versión se agrega a las firmas para diferenciar una versión de bifurcación de otra. Una Época (Epoch), por otro lado, es un conjunto de 32 ranuras, que son , aproximadamente 6.4 minutos. Aquí es donde ocurren las verificaciones de finalidad, las penalizaciones por slashing, la cola de salida y cualquier otra cosa genial específica del consenso. Aquí es donde opera Casper FFG, la parte final de Gasper. 12 segundos x 32 Historia latest_block_header: BeaconBlockHeader block_roots: Vector[Root, SLOTS_PER_HISTORICAL_ROOT] state_roots: Vector[Root, SLOTS_PER_HISTORICAL_ROOT] historical_roots: List[Root, HISTORICAL_ROOTS_LIMIT] Esta sección responde a la pregunta: "¿Qué ha sucedido en esta cadena?". Estas variables le dan a la cadena una memoria compacta de su propio pasado, lo que permite a los validadores referenciar y verificar estados anteriores sin almacenar todo. El encabezado del bloque más reciente almacena el encabezado del bloque procesado más recientemente. Se utiliza para evitar bloques duplicados porque, antes de procesar un nuevo bloque, la cadena verifica que la raíz del padre del bloque coincida con la raíz del encabezado del bloque más reciente. Tanto los campos de raíces de bloques como los de raíces de estado son listas que almacenan las raíces de bloques y estados pasados, respectivamente, hasta que se llenan. En cada ranura, las raíces se escriben en sus respectivos arrays en el índice . Esto permite a la cadena buscar cómo era el estado en cualquier ranura reciente dentro de la ventana de 27 horas. La raíz histórica agrega el hash fusionado del array de raíces de bloques y raíces de estado cuando se llenan. La lista no tiene límites, pero crece lentamente, con una sola entrada cada 27 horas. slot%8192 Eth1 eth1_data: Eth1Data eth1_data_votes: List[Eth1Data, EPOCHS_PER_ETH1_VOTING_PERIOD * SLOTS_PER_EPOCH] eth1_deposit_index: uint64 Antes de la fusión, Eth2 (cadena Beacon) necesitaba rastrear lo que estaba sucediendo en Eth1 (cadena PoW), específicamente las transacciones de depósito donde los nuevos validadores bloqueaban 32 ETH. Podrías preguntarte por qué los 32 ETH destinados a la Prueba de Participación estaban bloqueados en la cadena Prueba de Trabajo en lugar de en la cadena Beacon. La respuesta es simplemente porque la cadena Beacon en sí misma no tenía capacidad de transferencia de tokens ni de procesamiento de transacciones, ya que no podía manejar depósitos de tokens de forma nativa. Eth1 data contiene tres subcampos: la , que es la raíz merkle del árbol de depósitos del contrato de depósito; el , el número total de depósitos realizados en el contrato; y el , el hash del bloque eth1 al que se hace referencia. raíz de depósito recuento de depósitos hash del bloque La cadena Beacon no puede confiar simplemente en la visión de un solo validador de la cadena Eth1 porque diferentes validadores pueden ver estados diferentes debido a retrasos en la red, por lo que utiliza un mecanismo de votación que permite al proponente del bloque incluir su visión de los datos actuales de Eth1 en su bloque. Esas votaciones se acumulan en esta lista durante un período de votación y, si algún valor obtiene más de la mitad de los votos durante ese período, se convierte en los nuevos datos de Eth1. Al final del período de votación, la lista se borra y la votación comienza de nuevo. Eth Deposit Index rastrea cuántos depósitos del contrato de depósito se han procesado hasta ahora. Cuando la cadena procesa un nuevo bloque, verifica si hay depósitos no procesados comparando este índice con el campo de recuento de depósitos en Eth1 data. Si el recuento de depósitos es mayor, el bloque debe incluir los siguientes depósitos hasta el depósito máximo por bloque, que en ese momento era 16. Registro validators: List[Validator, VALIDATOR_REGISTRY_LIMIT] balances: List[Gwei, VALIDATOR_REGISTRY_LIMIT] Esta variable básicamente almacena una lista de quién está participando en el consenso y cuánta participación tienen. Un dato interesante sobre el campo de validadores es que solo crece y nunca se reduce; incluso después de que un validador se retira, su entrada permanece en la lista. Actualmente, hay 2,210,484 entradas, y solo 962,941 están activas. El campo Validador tiene ocho subcampos: , que es básicamente la clave pública del validador; , a donde va su participación cuando se retiran; , su saldo redondeado a la baja al Gwei más cercano, utilizado para calcular recompensas y penalizaciones, y solo se actualiza en los límites de la época con histéresis para evitar que parpadee hacia arriba y hacia abajo; , un indicador booleano utilizado para denotar si un validador ha sido slashing; , el número de época cuando el validador se volvió elegible para ser activado; , la época en que se activó; , la época en que se fue; y finalmente , la época en que su saldo puede ser retirado. pubKey withdrawable_credentials effective_balance slashed activation_eligibility_epoch activation_epoch exit_epoch withdrawable_epoch Para señalar por qué tenemos un campo de saldo efectivo en la lista de validadores y un campo de saldos directamente en el estado de beacon es que el campo de saldo efectivo no se actualiza en el momento en que lo hacen sus saldos reales, hay un búfer para evitar que vaya y venga. Sin histéresis, un validador que ronda los 32 ETH, digamos fluctuando entre 31.99 y 32.01 cada época debido a recompensas y penalizaciones, tendría su saldo efectivo cambiando entre 31 y 32 cada época. Eso significaría volver a hacer Merkleizar el objeto validador constantemente y cambiar su peso en los cálculos de comités en cada época. Aleatoriedad randao_mixes: Vector[Bytes32, EPOCHS_PER_HISTORICAL_VECTOR] randao_mixes es una lista de tamaño fijo de 65,536 (aproximadamente 2^16) entradas. Cada vez que un validador propone un bloque, agrega lo que llamamos una 'revelación de randao' a la lista. Esta revelación es básicamente el número de época actual firmado por el validador. Después de firmar, la cadena lo toma y lo XORea con la última mezcla para la época actual, lo que produce una nueva mezcla. Todos los proponentes en una época hacen lo mismo para obtener la mezcla acumulada final para la próxima época. La mezcla randao se utiliza para determinar el comité y los proponentes de bloques para la próxima época. El comité, que son todos los validadores activos divididos en las 32 ranuras, se determina mediante el algoritmo de barajado 'swap-or-not'. Este algoritmo básicamente simplemente intercambia el índice del validador aleatoriamente con la mezcla. Para la selección del proponente de bloque, la cadena hashea la mezcla randao para formar una semilla. Luego itera a través de todos los validadores activos comenzando en un desplazamiento aleatorio derivado de esa semilla. Para cada candidato, verifica si un hash de la semilla y el índice del validador, dividido por el saldo efectivo del validador, supera un umbral. Si lo hace, el validador se convierte en el proponente; si no, salta al siguiente. En la práctica, encuentra uno rápidamente ya que la mayoría de los validadores activos tienen un saldo de 32 ETH. Slashings slashings: Vector[Gwei, EPOCHS_PER_SLASHINGS_VECTOR] Un validador es slashingado por dos razones: proponer dos bloques diferentes para la misma ranura intentando crear una bifurcación, o hacer atestaciones contradictorias. El campo slashings es una lista fija de 8192 entradas, una por época. Contiene la suma de todo el saldo efectivo del validador que fue slashingado. Este campo se utiliza para calcular el monto de la penalización. Atestaciones previous_epoch_attestations: List[PendingAttestation, MAX_ATTESTATIONS * SLOTS_PER_EPOCH] current_epoch_attestations: List[PendingAttestation, MAX_ATTESTATIONS * SLOTS_PER_EPOCH] Cada validador activo atesta una vez por época, y estas atestaciones son las que impulsan tanto la regla de elección de bifurcación (LMD-GHOST) como el mecanismo de finalidad (Casper FFG). Una atestación contiene seis subcampos: la para la que atesta el validador; la es el bloque que el validador considera la cabeza de la cadena, se considera un voto LMD-GHOST del validador utilizado para determinar la elección de bifurcación; la es el punto de control de época que el validador cree que está justificado, y el es la época actual para la que atesta el validador, ambos combinados forman el voto Casper FFG que se utiliza en la finalidad. En pocas palabras, el validador está atestando que la época de origen debe ser finalizada y la época de destino debe ser justificada. Los indican qué validador en el comité ha atestado. Dado que es más económico combinar cosas como bits en un byte, el bit de agregación se almacena en un campo de bits para la eficiencia de la memoria. Finalmente, tenemos la del validador sobre los datos de atestación. ranura raíz del bloque beacon fuente objetivo bits de agregación firma Finalidad justification_bits: Bitvector[JUSTIFICATION_BITS_LENGTH] previous_justified_checkpoint: Checkpoint current_justified_checkpoint: Checkpoint finalized_checkpoint: Checkpoint Finalidad significa que un bloque y todas sus transacciones nunca pueden ser revertidos. En la cadena Beacon, la finalidad es absoluta. Una vez que una época se finaliza, la única forma de revertirla es si se sacrifica 1/3 de todo el ETH en stake, lo que costaría miles de millones de dólares. Justification bits es un vector de bits de longitud 4, básicamente rastrea si las últimas cuatro épocas fueron justificadas. El punto de control justificado anterior es el punto de control que se justificó en la época anterior. El punto de control justificado actual es el punto de control justificado más reciente, mientras que el punto de control finalizado es el punto de control finalizado más reciente. Una época se justifica cuando 2/3 del stake total activo atesta un enlace de supermayoría que apunta a esa época como objetivo. La finalidad ocurre cuando se obtienen dos puntos de control justificados seguidos. En el momento en que se justifica el segundo, el primero se actualiza a finalizado, aunque hay más matices. La Máquina de Estados Ahora que sabemos qué contiene el estado, podemos ver cómo cambia. Cada 12 segundos, llega una nueva ranura. Si se propone un bloque, la función de transición de estado toma el estado actual y ese bloque, realiza validaciones, actualizaciones y produce un nuevo estado. Este proceso se divide en tres etapas según la especificación: procesamiento de ranuras, procesamiento de bloques y procesamiento de épocas. Procesamiento de Ranuras El Procesamiento de Ranuras se ejecuta cada vez que la cadena necesita avanzar de una ranura a la siguiente, ya sea que se haya producido un bloque o no. Tres cosas suceden cuando una ranura avanza de N a N+1. Primero, la raíz del estado para la ranura N se actualiza para preservar un registro de cómo era la ranura en esa ranura. En segundo lugar, el encabezado del bloque más reciente que almacena el encabezado del bloque procesado más recientemente también se actualiza; recuerde que este campo se utiliza para evitar bloques duplicados. Además, la raíz de ese encabezado completado se escribe en la raíz del bloque. Por último, el contador de ranuras se incrementa en uno. Te preguntarás qué sucede con el estado cuando un proponente pierde su ranura. Bueno, todo el estado todavía se actualiza; las raíces de los bloques de esa ranura, por ejemplo, contendrán la raíz del mismo encabezado de bloque más reciente ya que no llegó ningún bloque nuevo para reemplazarlo. Después de incrementar la ranura, la cadena verifica si acaba de cruzar un límite de época, lo que se puede hacer fácilmente con `slot mod 32 == 0`. Si es así, el procesamiento de épocas entra en juego antes de que suceda cualquier otra cosa. Por lo tanto, técnicamente, por cada 32 ranuras, el procesamiento de épocas se ejecuta junto con el procesamiento de ranuras; en otras palabras, el procesamiento de épocas se ejecuta después de que avanza la ranura pero antes de que se procese el bloque para esa ranura. Un último dato a tener en cuenta: cuando llegamos al punto en que los arrays de raíces de estado y raíces de bloques están llenos, es decir, en la posición `slot mod 8192 == 0`, antes de que ambos arrays comiencen a ser sobrescritos por nuevos datos, ya que parece circular, la cadena hashea los dos campos juntos y los agrega al estado histórico. Procesamiento de Bloques El procesamiento de bloques se ejecuta cuando se propone realmente un bloque para una ranura. Después de que el procesamiento de ranuras avanza el estado a la ranura correcta, el procesamiento de bloques toma el bloque firmado y aplica su contenido al estado. Tiene dos partes principales: la validación del encabezado del bloque y el procesamiento del cuerpo del bloque. Antes que nada, la cadena verifica algunas cosas como si el encabezado del bloque coincide con la ranura de estado actual y si el índice del proponente del bloque es realmente el validador que el randao seleccionó. Por último, comprueba si la raíz del padre del bloque coincide con la raíz del encabezado del bloque más reciente; si se valida, el encabezado del bloque se almacena como el encabezado del bloque más reciente en el estado. A continuación, el proponente debe incluir una revelación de randao, que, como dije antes, es básicamente el número de época actual firmado por el validador. La cadena verifica la firma con la clave pública del proponente. Es fácil darse cuenta de que este método actual es determinista, es decir, la firma del validador siempre será la misma para el mismo número de época; es cierto, de hecho, el propósito de hacerlo de esta manera es permitir que cualquiera use la clave pública del validador para verificar el número de época que el validador firmó realmente. Tenga en cuenta que un proponente no puede omitir la revelación de randao; si propone un bloque, debe incluirla; la única forma de omitir el proceso es no proponer un bloque en primer lugar. Después de eso, el proponente también incluirá su visión del estado del contrato de depósito de la cadena Eth1 como un voto de datos Eth1. Si algún valor de datos Eth1 en la lista de votos alcanza una mayoría, se convierte en los nuevos datos Eth1 en el estado. Durante el procesamiento de bloques, el campo de slashing del proponente contiene evidencia de que un validador firma dos encabezados de bloque diferentes para la misma ranura; la cadena verifica ambas firmas y, si son válidas, los slashinga primero estableciendo su indicador de slashing en verdadero y agregando su saldo efectivo al array de slashings. Además, para los atestadores, si hay alguna atestación contradictoria, la cadena la verifica e identifica a los validadores culpables a través de su firma, y luego slashinga a esos validadores, de la misma manera y proceso que el slashing del proponente de bloque. Las nuevas atestaciones en el bloque se validan, la atestación se convierte en una atestación pendiente agregando dos nuevos campos, que son el retraso de inclusión y el índice del proponente, y luego se agregan a la atestación de la época actual o de la época anterior. No mucho después de que se agregan, ya que no afectan el estado de inmediato, permanecen allí hasta que el procesamiento de épocas las evalúa. Se procesan los depósitos de nuevos validadores del contrato de depósito Eth1; el bloque debe incluir todos los depósitos pendientes hasta el depósito máximo de 16. La cadena verifica la prueba de merkle de cada depósito contra la raíz de depósito para garantizar que sea correcta. Si la clave pública del depositante es nueva, se agrega una nueva entrada de validador, así como el saldo correspondiente. Un validador puede señalar que desea salir enviando una salida voluntaria firmada. La cadena verifica que el validador ha estado activo durante al menos 256 épocas y que la época actual es al menos la época de salida especificada. Si todo está en orden, se establecen la época de salida y la época de retiro del validador. Después de que se procesa todo lo anterior, hay una última pero importante pieza: la raíz del estado calculada por el otro nodo se compara con la raíz del estado incluida en el bloque. Si no coinciden, todo el bloque es rechazado. Procesamiento de Épocas El procesamiento de épocas se activa en el límite de la época, es decir, en cada paso `slot mod 32 = 0`. Se ejecuta durante el procesamiento de ranuras cuando el contador de ranuras cruza hacia una nueva época. Es la etapa más compleja, ya que la mayoría de las cosas geniales del consenso suceden aquí. Primero, entran en juego la justificación y la finalidad, aquí es donde Casper FFG hace su trabajo; el proceso puede parecer complejo, pero es muy fácil. En pocas palabras, la cadena observa las atestaciones de la época anterior y cuenta los saldos efectivos de los validadores que atestaron con el objetivo correcto. Si esa suma es al menos 2/3 del saldo activo total, la época objetivo se justifica, y si dos épocas consecutivas se justifican, la anterior se finaliza. ¡Fácil! Un dato que no señalé en la etapa de procesamiento de bloques es que, para cada etapa, los validadores acumulan recompensas; reciben recompensas por incluir atestaciones o por agregar evidencia de slashing, o incluso por recompensas base normales. Estas recompensas acumuladas son evaluadas por la cadena durante la época anterior en la etapa de procesamiento de épocas, y ajustan su saldo en consecuencia. Si la cadena no se ha finalizado en más de cuatro épocas, entra en juego lo que se describe como "la fuga de inactividad". Además de las penalizaciones normales por perder atestaciones, los validadores que no participan reciben una penalización adicional por inactividad que crece cuadráticamente con cada época desde la última época finalizada. En otras palabras, cuanto más tarde se finaliza un bloque, mayor es tu penalización. Quizás te preguntes cuál es el propósito de hacer esto. Bueno, cuando un bloque no se ha finalizado durante un tiempo, significa que no hay una votación mayoritaria sobre ese bloque, y dado que la votación para la finalidad se mide por el peso del saldo efectivo de un validador, básicamente cuántos ETH tiene el validador, una reducción en la cantidad de su saldo efectivo reduce su poder de voto. Por lo tanto, Ethereum lo utiliza como una forma de forzar la finalidad de los bloques. Cabe destacar que durante una fuga de inactividad, incluso los atestadores correctos no reciben recompensas. Todo cambia a modo de penalización pura para acelerar el reequilibrio. Otro evento importante que ocurre en esta etapa es la activación de validadores cuyas épocas de elegibilidad de activación han sido alcanzadas. Además, los validadores cuyas épocas de salida han llegado, son eliminados del conjunto activo de validadores. A continuación, recuerde que el saldo efectivo no se actualiza con cada ranura y época, porque se aplica la histéresis. Solo se actualiza si el saldo real ha subido lo suficiente por encima del umbral superior de aumento del saldo efectivo actual; el saldo efectivo aumenta en 1 ETH, y si cae por debajo del umbral inferior, disminuye en 1 ETH. Por último, la mezcla randao de la época actual se copia en la ranura de la próxima época. Como puede ver claramente, el procesamiento de épocas es la parte más complicada de la máquina de estados y no es amigable computacionalmente, por lo tanto, siempre conduce a mucho trabajo de optimización para los ingenieros que construyen los clientes de la cadena. De la Fase 0 a Fulu El BeaconState que hemos recorrido hasta ahora es la versión de Fase 0, la original. Pero la cadena Beacon es un sistema vivo. Cada bifurcación de la capa de consenso ha modificado el BeaconState, ya sea agregando nuevos campos, eliminando los antiguos o simplemente cambiando cómo operan algunos de los existentes. Por ejemplo, en la bifurcación Altair, las listas de atestaciones de épocas anteriores y actuales se eliminaron por completo para ser reemplazadas por la de épocas anteriores y actuales; la diferencia es que, mientras que la anterior almacena objetos de atestación completos, el nuevo tipo de participación solo los almacena en forma de bits. Ahora, cada validador recibe solo tres bits por época que representan si acertó la fuente, la época y la cabeza. Esto condujo a una drástica reducción en el tamaño de la memoria. Bellatrix, la bifurcación de la fusión, introdujo el campo de carga útil de ejecución en el beaconState; este campo se utiliza para conectar la capa de consenso y la capa de ejecución. Los campos Eth1 se mantuvieron, pero sus roles disminuyeron ya que ya no eran necesarios. participación La bifurcación Capella introdujo capacidades de retiro para el validador; lo registra agregando un nuevo campo llamado el índice de retiro siguiente al beaconState. Las raíces históricas fueron reemplazadas por resúmenes históricos que almacenan la raíz del bloque y la raíz del estado en una estructura en lugar de hashearlos juntos. La bifurcación Deneb, por otro lado, tuvo casi ningún impacto en el beaconState, porque la bifurcación se refería principalmente a los blobs. En Electra y Fulu, el cambio clave fue aumentar el saldo efectivo máximo de 32 ETH a 2048 ETH, lo que llevó a la introducción de nuevos campos en el beaconState. Cada bifurcación se construyó sobre la anterior, y el BeaconState creció de 21 campos en la Fase 0 a más de 30 en Fulu. Una cosa es consistente: de la Fase 0 a Fulu, el estado ha crecido, las bifurcaciones agregan campos, las bifurcaciones eliminan campos, pero la arquitectura se ha mantenido igual. Conclusión La cadena Beacon a menudo se describe como compleja, sí, estoy de acuerdo, porque es compleja. Pero en su núcleo, es básicamente un ciclo de: existe un estado, llega una entrada, el estado existente se actualiza para producir un nuevo estado, y luego se repite. ¡Simple! Lo que hace que la cadena Beacon sea realmente notable no es ningún campo individual, sino cómo todo se conecta para darnos esta increíble tecnología que tenemos hoy. Referencias Especificaciones de Consenso de Ethereum (Fase 0) Especificación Anotada de Ethereum por Ben Edgington eth2book.info Gasper: Combinando GHOST y Casper (Artículo Original) Casper the Friendly Finality Gadget (Artículo Original) Implementación del Cliente Lighthouse Explorador de la Cadena Beacon de Ethereum Blog de la Fundación Ethereum sobre la Fusión Especificación Anotada de Ethereum por Vitalik Buterin
