¿Por qué ejecutar un nodo completo de Ethereum?

🍎 Contribuye a la salud de la red de Ethereum.

• Verifica todas las transacciones en la red por ti mismo.

• No confíes, verifica.

📡 Transmite tus transacciones a través de tu propio nodo.

• Elimina la dependencia de terceros e intermediarios como Infura o Alchemy.

• Aumenta la resistencia a la censura a través de la descentralización.

Ejecutar un nodo completo tiene requisitos de hardware muy similares a los de ejecutar un nodo validador. La única diferencia es que los nodos validadores proponen bloques.

Si sigues cualquiera de las guías de staking en solitario y completas todos los pasos excepto el proceso de depósito (que requiere 32 ETH), ¡estarás ejecutando un nodo completo!

• #agregador-de-atestaciones

• #atestacion

• #beacon-chain

• #bloque

• #proponente-de-bloque

• #nodo-de-almacenamiento

• #estado-del-bloque

  • #propuesto-proposed

  • #programado-scheduled

  • #perdido-omitido-missed-skipped

  • #huerfano-orphaned

• #cadena-canonica

• #cabeza-de-cadena

• #checkpoints

• #software-cliente

• #comites

• #capa-de-consenso

• #contrato-de-deposito

• #efectividad

• #epoca

• #capa-de-ejecucion

• #finalizacion

  • #problemas-de-finalidad

• #fork

• #nodo-completo

• #bloque-genesis

• #hard-fork

• #voto-principal

• #fuga-de-inactividad

• #distancia-de-inclusion

• #datos-de-entrada

• #justificacion

• #clientes-ligeros

• #mev

• #mempool

• #nodo

• #operador

• #tasa-de-participacion

• #peers

• #tarifas-de-prioridad

• #llave-privada

• #proof-of-stake-pos

• #llave-publica

• #firmar

• #ofensa-deducibles

  • #violacion-de-atestacion

  • #violacion-de-atestacion

• #nodo-slasher

• #slot

• #staker-individual

• #voto-de-origen

• #staker

• #staking-cli

• #destinatario-de-tarifas-sugerido

• #comite-de-sincronizacion

• #voto-destino

• #validadores

  • #elegible-para-activacion-y-activacion-estimada

  • #indice-unico

  • #saldo-actual-y-saldo-efectivo

• #ciclo-de-vida-del-validador

  • #1.-depositar

  • #2.-pendiente

  • #3.-validador-activo

  • #4.-slashing-validator

  • #5.-salida-del-validad

• #grupo-de-validadores

• #cola-de-validacion

• #frase-semilla-mnemotecnico

• #direccion-de-retiro

nodo de almacenamiento

• Almacena todo lo que se mantiene en un #nodo-completo y crea un archivo de estados históricos.

• Los nodos de archivo son necesarios si desea consultar algo como el saldo de una cuenta en un bloque en particular.

• Estos datos representan unidades de terabytes (más de 20 TB para Geth), lo que hace que los nodos de archivo sean menos atractivos para la mayoría de los usuarios, pero pueden ser útiles para servicios como exploradores de bloques, proveedores de billeteras y análisis de cadenas.

La sincronización de software clientes en cualquier modo que no sea de archivo dará como resultado la eliminación de los datos extra de la cadena de bloques. Esto significa que no un nodo completo no cuenta con todos los estados históricos, pero el nodo completo puede recrearlos a pedido.

No se requiere que los nodos de archivo participen en la validación de bloques y, en teoría, pueden construirse desde cero simplemente reproduciendo los bloques desde génesis.

****Fuente ↗

atestación

Votos de #validadores que confirman la validez de un #bloque. En momentos designados, cada validador es responsable de publicar diferentes certificaciones que declaran formalmente la visión actual de la cadena del validador, incluido el último #checkpoints finalizado y la #cabeza-de-cadena actual.

Cada validador activo crea una atestación por #epoca (~6,5 minutos), que consta de los siguientes componentes:

Un componente importante relacionado con la eficacia es el voto de cabeza de cadena. Este es un voto que hace el validador sobre lo que cree que es el último bloque válido en la cadena al momento de certificar. La estructura de una votación principal en cadena consta de los siguientes componentes:

• Slot - Define dónde cree el validador que se encuentra el cabezal de cadena actual.

• Hash - Define lo que el validador cree que es el cabezal de cadena actual.

La combinación define de forma única un punto en la cadena de bloques. Al combinar suficientes votos de cabeza de cadena, la red Ethereum llega a un consenso sobre el estado de la cadena.

Fuente (ethereum.org) ↗ Fuente (Attestant) ↗

agregador de atestaciones

Aunque los datos en cada atestación son relativamente pequeños, se acumulan rápidamente con decenas de miles de validadores. Como estos datos se almacenarán para siempre en la cadena de bloques, es importante minimizarlos, y esto se hace a través de un proceso conocido como agregación de atestación.

La agregación toma múltiples atestaciones que han elegido votar con el mismo comité, voto principal en cadena y voto definitivo, y las fusiona en una única atestación agregada.

Una atestación agregada difiere en dos aspectos de una atestación simple. En primer lugar, se enumeran varios validadores. En segundo lugar, la firma es una firma agregada hecha a partir de las firmas de las atestaciones simples coincidentes. Las atestaciones agregadas son muy eficientes para almacenar, pero introducen comunicaciones adicionales y cargas computacionales.

Si se requiriera que cada validador agregara todas las atestaciones, sobrecargaría rápidamente la red con la cantidad de comunicaciones requeridas para pasar cada atestación a cada validador. Del mismo modo, si la agregación fuera puramente opcional, los validadores no se molestarían en desperdiciar sus propios recursos al hacerlo. En su lugar, la red elige un subconjunto de validadores para llevar a cabo tareas de agregación. Les interesa hacer un buen trabajo, ya que es más probable que se incluyan atestaciones agregadas con un mayor número de validadores en la cadena de bloques, por lo que es más probable que el validador sea recompensado.

Los validadores que realizan este proceso de agregación se conocen como agregadores.

Fuente ↗

beacon chain

Una parte importante del trabajo de la beacon chain es almacenar y administrar el registro de #validadores - el conjunto de participantes responsables de ejecutar el sistema Ethereum #proof-of-stake-pos.

Este registro se utiliza para:

• Assigns validators their duties.

• Asigna a los validadores sus funciones.

• Finaliza los #checkpoints.

• Realice una generación de números aleatorios (RNG) a nivel de protocolo.

• Avanza la #beacon-chain. Vote en la #chain-head elegir el fork.

Fuente ↗

bloque

Un bloque es una unidad de información agrupada que incluye una lista ordenada de transacciones e información relacionada con el consenso. Los bloques son propuestos por validadores de Proof of Stake (PoS)), momento en el que se comparten en toda la red peer-to-peer, donde todos los demás nodos pueden verificarlos fácilmente de forma independiente. Las reglas de consenso rigen qué contenidos de un bloque se consideran válidos, y la red ignora cualquier bloque no válido. El orden de estos bloques y las transacciones en ellos crean una cadena determinista de eventos cuyo final representa el estado actual de la red.

proponente de bloque

Un #validadores elegido por #beacon-chain para proponer el siguiente #bloque. Solo puede haber un bloque válido por #slot.

estado del Bloque

Propuesto (Proposed)

El bloque fue propuesto por un validador.

Programado (Scheduled)

Los validadores están enviando datos actualmente.

Perdido/omitido (Missed/skipped)

El proponente no propuso el bloque dentro del plazo dado, por lo que el bloque se perdió/se saltó.

Huérfano (Orphaned)

Para entender esto, miremos el diagrama debajo de "1, 2, 3, ..., 9" representan los slots (ranuras).

1. El validador en el slot 1 propone el bloque "a".

2. El validador en el slot 2 propone "b".

3. El slot 4 se está omitiendo porque el validador no propuso un bloque (por ejemplo, fuera de línea).

4. En el slot 5/6 se produce una bifurcación: el validador (5) propone un bloque, pero el validador (6) no recibe estos datos (por ejemplo, el bloque no los alcanzó lo suficientemente rápido). Por lo tanto, Validator(6) propone su bloque con la información más reciente que ve de validator(3).

5. La regla de elección de fork (bifurcación) ↗ es la clave aquí: decide cuál de las cadenas disponibles es la canónica.

cadena canónica

La cadena canónica es la cadena que se acuerda que es la cadena "principal" y no un fork.

cabeza de cadena

El último bloque recibido por un validador. Esto no significa necesariamente que sea la cabeza de la #cadena-canonica.

checkpoints

La #beacon-chain tiene un tempo dividido en #slots (12 segundos) y #epocas (32 slots). El primer slot en cada época es un checkpoint. Cuando una gran mayoría de validadores da fe del vínculo entre dos checkpoints, se pueden justificar y luego, cuando se justifica otro checkpoint encima, se pueden finalizar.

software cliente

Una implementación del software Ethereum que verifica las transacciones en un bloque. Estos pueden ser clientes de capa de consenso o clientes de capa de ejecución. Cada validador necesita tanto un cliente de capa de ejecución como un cliente de capa de consenso.

comités

Un grupo de al menos 128 #validadores asignados para validar bloques en cada #slot. Uno de los validadores del comité es el agregador, responsable de agregar las firmas de todos los demás validadores del comité que acuerdan una #atestacion. No debe confundirse con los #comite-de-sincronizacion.

capa de consenso

La capa de consenso de Ethereum es la red de Clientes de consenso.

contrato de depósito

El contrato de depósito es la puerta de entrada a Ethereum #proof-of-stake-pos y se administra a través de un contrato inteligente en Ethereum. El contrato inteligente acepta cualquier transacción con una cantidad mínima de 1 ETH y #datos-de-entrada válidos. Los nodos de #beacon-chain escuchan el contrato de depósito y usan los datos de entrada para acreditar cada validador.

Más información sobre el contrato de depósito

efectividad

El tiempo medio que tardan las certificaciones de un validador en incluirse en la cadena.

Revisa nuestra página sobre validator effectiveness

época

1 época = 32 slots Representa el número de 32 slots (12 segundos) y tarda aproximadamente 6,4 minutos. Las épocas juegan un papel importante cuando se trata de la cola y la finalidad del validador.

epresents the number of 32 slots (12 seconds) and takes approximately 6.4 minutes. Epochs play an important role when it comes to the validator queue and finality.

capa de ejecución

La capa de ejecución de Ethereum es la red de clientes de ejecución.

finalización

En Ethereum #proof-of-stake-pos al menos dos tercios de los validadores deben ser honestos, por lo tanto, si hay dos #epoca en competencia y un tercio de los #validadores deciden ser maliciosos, recibirán una penalización. Los validadores honestos serán recompensados.

Para determinar si se ha finalizado una época, los validadores deben ponerse de acuerdo sobre las últimas dos épocas seguidas, luego todas las épocas anteriores se pueden considerar finalizadas.

problemas de finalidad

Si hay menos del 66,6% del total de votos posibles (la #tasa-de-participacion) en una época específica, la época no se puede justificar. Como se mencionó en "Finalización", se requieren tres épocas consecutivas justificadas para alcanzar la finalización. Mientras la cadena no pueda alcanzar este estado, tiene problemas de finalidad.

there are less than 66.6% of the total possible votes (the participation rate) in a specific epoch, the epoch cannot be justified. As mentioned in "Finalization", three justified epochs in a row are required to reach finality. As long as the chain cannot reach this state it has finality issues.

During finality issues, the validator entry queue will be halted and new validators will not be able to join the network, however, inactive validators with less than 16 ETH balance will be exited from the network. This leads to more stability in the network and a higher participation rate, allowing the chain to eventually finalize.

fork

Un cambio en el protocolo que provoca la creación de una cadena alternativa o una divergencia temporal en dos posibles rutas de bloques. Ver también #hard-fork

nodo completo

Almacena y mantiene los datos completos de la cadena de bloques en el disco. Provee datos de blockchain a solicitud y ayuda a respaldar la red participando en la validación de bloques y verificando todos los bloques y estados. Todos los estados se pueden derivar de un nodo completo.

Fuente ↗

bloque Génesis

El primer bloque en una cadena de bloques, utilizado para inicializar una red en particular y su criptomoneda.

hard fork

Se produce un hard fork cuando se envía una actualización a la red Ethereum y la nueva versión del software se bifurca de la versión anterior. Por lo general, requiere que los operadores actualicen su software de validación para permanecer en el lado correcto del fork. Ver también #fork

voto principal

El validador ha votado oportunamente por la #cabeza-de-cadena correcto.

fuga de inactividad

Si Beacon Chain ha pasado más de cuatro #epocas sin #finalizacion, se activa un protocolo de emergencia llamado "fuga de inactividad". El fin último de la fuga de inactividad es crear las condiciones necesarias para que la cadena recupere la finalidad. La finalidad requiere una mayoría de 2/3 del ether total apostado para acordar los puntos de #checkpoints. Si los validadores que representan más de 1/3 del total de validadores se desconectan o no envían las #atestacion correctas, entonces no es posible que una gran mayoría de 2/3 finalice los #checkpoints. La fuga de inactividad permite que la participación perteneciente a los validadores inactivos se desangre gradualmente hasta que controlen menos de 1/3 de la participación total, lo que permite que los validadores activos restantes finalicen la cadena. Por grande que sea el grupo de validadores inactivos, los validadores activos restantes eventualmente controlarán >2/3 de la apuesta. ¡La pérdida de participación es un fuerte incentivo para que los validadores inactivos se reactiven lo antes posible!

distancia de inclusión

La distancia de inclusión de un #slot es la diferencia entre el slot en el que se realiza una #atestacion y el número de slot más bajo del bloque en el que se incluye la #atestacion. Por ejemplo, una atestación realizada en el slot s e incluida en el bloque en la ranura s + 1 tiene una distancia de inclusión de 1. Si, en cambio, la atestación se incluyera en el bloque en el slot s + 5, la distancia de inclusión sería 5.

El valor de una certificación de la red Ethereum depende de su distancia de inclusión, siendo preferible una distancia de inclusión baja. Esto se debe a que cuanto antes se presente la información a la red, más útil será.

Para reflejar el valor relativo de una certificación, la recompensa otorgada a un validador por certificar se escala de acuerdo con la distancia de inclusión. Específicamente, la recompensa se multiplica por 1/d, donde d es la distancia de inclusión.

datos de entrada

Los datos de entrada, también llamados datos de depósito, son una secuencia de 842 caracteres generada por el usuario. Representa la #llave-publica y la llave pública de retiro, que fueron firmadas con la #llave-privada del validador. Los datos de entrada deben agregarse a la transacción del #contrato-de-deposito para que la #beacon-chain los identifique.

Más información sobre el contrato de depósito

justificación

El 66,6% del total de validadores necesitan dar fe a favor de la inclusión de un bloque en la #cadena-canonica. Esta condición actualiza el bloque a "justificado". Es poco probable que los bloques justificados se reviertan, pero pueden hacerlo bajo ciertas condiciones.

Cuando se justifica otro bloque encima de un bloque justificado, se actualiza a "finalizado". Finalizar un bloque es un compromiso de incluir el bloque en la cadena canónica.

Más información sobre la justificación ↗

clientes ligeros

Un cliente de Ethereum que no almacena una copia local de la cadena de bloques ni valida bloques y transacciones. Ofrece las funciones de una billetera y puede crear y transmitir transacciones.

MEV

MEV o "valor extraíble máximo", es un tema controversial. Los operadores de nodos pueden extraer MEV aceptando bloques creados por "buscadores", a través de un pequeño programa secundario llamado "mev-boost ↗". En este caso, el cliente de la capa de consenso, como Nimbus, Teku, etc., cuando se le solicite obtener un bloque para proponer, obtendrá bloques de los relés MEV a través de mev-boost y del cliente de la capa de ejecución, como Besu, Geth, etc. y luego elija el bloque del relé que mejor pague. Actualmente, la capa de ejecución no comunica su pago esperado y solo se elegiría cuando el relevo no ofrezca ningún bloque. Para esto, se debe confiar en que el relé entregará bloques válidos. Las recompensas de MEV se pagan a la misma dirección del destinatario de la tarifa sugerida que las tarifas prioritarias.

Las recompensas de MEV se pagan a la misma dirección del destinatario de la tarifa sugerida que las tarifas prioritarias.

ewards from MEV are paid to the same suggested fee recipient address as priority fees.

Source ↗

mempool

Cuando un nodo Ethereum recibe una transacción, no se agrega instantáneamente a un bloque. La transacción se lleva a cabo en un área de espera o una zona de amortiguamiento.

La transacción pasa por una serie de niveles de verificación, como comprobar si la salida es mayor que la entrada, si la firma es válida o no, etc., y luego solo se agrega a un bloque. La transacción no se agrega a un bloque si falla alguna de estas validaciones. El papel de un mempool surge mientras una transacción pasa por estos controles. Simplemente se mantiene en esta sala de espera o en un mempool. Tan pronto como se confirma la transacción, se elimina del mempool y se agrega a un bloque. Mempool no es una referencia maestra compartida universalmente por todos los nodos. No hay un mempool "único". Esto significa que cada nodo configura sus propias reglas para el mempool del nodo. De hecho, un nodo puede ser el primero en recibir una transacción, pero es posible que no haya propagado la transacción al resto de la red.

Fuente ↗

nodo

Una instancia de software de cliente de Ethereum que esté conectada a otras computadoras que también ejecuten software de Ethereum, formando una red. Un nodo no necesita necesariamente un validador, pero un validador requiere un nodo. Ejecutar un nodo por sí solo no genera ningún ingreso, pero contribuye a la solidez de la red.

operador

Una persona que mantiene un validador.

tasa de participación

La tasa de participación es el porcentaje de validadores que están en línea y realizando sus funciones.

Si el conjunto de validadores es de 1000 validadores y 250 validadores están fuera de línea o rara vez hacen propuestas o certificaciones, entonces se podría estimar que la tasa de participación es del 75 %.

Fuente ↗

peers

Otros nodos que ejecutan clientes de Ethereum que se conectan entre sí a través de una red de igual a igual (peer to peer). La comunicación entre peers es la forma en que la red Ethereum permanece descentralizada ya que no hay un punto único de falla.

tarifas de prioridad

Casi todas las transacciones en Ethereum establecen una tarifa de prioridad ↗ para incentivar a los #proponente-de-bloque a incluir la transacción como una prioridad más alta que otras. Cuanto mayor sea la tarifa en relación con otras transacciones que actualmente esperan en el #mempool Esta tarifa se paga al proponente del bloque. Todas las tarifas de prioridad en un bloque se agregan y pagan en un solo cambio de estado directamente al #destinatario-de-tarifas-sugerido establecido por el proponente del bloque. Esta dirección podría ser una billetera de hardware, una billetera de software o incluso un contrato de múltiples firmas.

llave privada

(Private Key) Un número secreto que permite a los usuarios de Ethereum demostrar la propiedad de una cuenta o contratos mediante la producción de una firma digital.

proof of stake (PoS)

Un método por el cual un protocolo de cadena de bloques de criptomonedas tiene como objetivo lograr un consenso distribuido. PoS pide a los usuarios que demuestren la propiedad de una cierta cantidad de criptomonedas (su "participación" en la red) para poder participar en la validación de transacciones.

llave publica

Un número, derivado a través de una función unidireccional de una #llave-privada, que puede ser compartido públicamente y utilizado por cualquier persona para verificar una firma digital realizada con la clave privada correspondiente.

firmar

Demostrar criptográficamente que un mensaje o transacción fue aprobado por el titular de una #llave-privada.

ofensa deducibles

Si su validador comete un delito que puede implicar deducciones (slashing), será forzado a salir del grupo de validadores y se le deducirá ETH según las circunstancias del evento. Por lo general, esto será 1-2 ETH, pero podría ser significativamente más ↗.

Esto no es algo de lo que deba preocuparse demasiado, hay pasos simples que puede seguir para asegurarse de no invocar un evento de slashing.

Hay tres formas que probocan esto, todas las cuales equivalen a la propuesta deshonesta o la certificación de bloques.

violación de atestación

• Votación doble: Firma de dos #atestaciones diferentes en una #epoca.

• Votos envolventes: Atestar a un bloque que "rodea" a otro (efectivamente cambiando la historia).

Infracción del proponente

• Propuesta de doble bloque: Proponer y #firmar firmar dos bloques diferentes para un mismo #slot.

nodo slasher

El slasher es una entidad propia, pero requiere un #beacon-chain para recibir atestaciones. Para encontrar actividad maliciosa por parte de los validadores, los slashers iteran a través de todas las atestaciones recibidas hasta que se encuentra una ofensa dedicul que se puede cortar. Los recortes encontrados se transmiten a la red y el siguiente #proponente-de-bloque agrega la prueba al #bloque. El proponente del bloque recibe una recompensa por cortar al validador malicioso. Sin embargo, el denunciante (Slasher) no recibe una recompensa.

slot

32 slots = 1 #epoca Un período de tiempo de 12 segundos en el que un validador elegido al azar tiene tiempo para proponer un bloque. El número total de validadores se divide en #committees y uno o más comités individuales son responsables de dar fe de cada puesto. Se elegirá un validador del comité para que sea el agregador, mientras que los otros 127 validadores dan fe. Después de cada época, los validadores se mezclan y fusionan en nuevos comités. Cada espacio puede tener o no un bloque, ya que un validador podría perder su propuesta (por ejemplo, puede estar desconectado o enviar su bloque demasiado tarde). Hay un mínimo de 128 validadores por comité.

staker individual

Un operador que ejecuta un validador en la red Ethereum sin un protocolo entre su validador y #beacon-chain

voto de origen

El validador ha votado oportunamente por el origen correcto del checkpoint.

staker

Alguien que ha depositado ETH en un validador para asegurar la red. Puede ser alguien que ejecuta un validador (un operador) o alguien que depositó su ETH en un grupo, donde otra persona es el operador del validador.

staking CLI

Una herramienta de línea de comandos utilizada para generar claves de validación y depositar archivos de datos.

• https://github.com/ethereum/staking-deposit-cli

destinatario de tarifas sugerido

El destinatario de la tarifa es una dirección de Ethereum nominada por un validador de #beacon-chain para recibir las tarifas de transacciones de usuarios y #mev.

comité de sincronización

Un comité de sincronización es un grupo de #validadoresseleccionados al azar que se actualizan cada ~27 horas. Su propósito es agregar sus #firmar a encabezados de bloque válidos. Los comités de sincronización permiten a los #clientes-ligeros realizar un seguimiento de la #chain-head jefe de la cadena de bloques sin necesidad de acceder a todo el conjunto de validadores. Ocurre cada 2 años en promedio, sin embargo, puede haber "períodos secos" varias veces más largos que el promedio sin que se dé uno. Entonces, si su validador es seleccionado... ¡felicidades! 🥳

voto destino

El validador ha votado a tiempo por el destino correcto del checkpoint.

validadores

Un nodo en un sistema de #proof-of-stake-pos responsable de almacenar datos, procesar transacciones y agregar nuevos bloques a la cadena de bloques. Para activar el software de validación, debe poder aportar 32 ETH. El trabajo de los validadores es proponer bloques y firmar atestaciones. Tiene que estar en línea durante al menos el 50% del tiempo para tener retornos positivos. Un validador lo ejecuta un operador (un ser humano), en el hardware (una computadora) y se empareja con un nodo (muchos miles de validadores pueden ejecutarse en un nodo)

elegible para activación y activación estimada

Se refiere a validadores pendientes. El depósito ha sido reconocido por #beacon-chain en la marca de tiempo de "Elegible para activación". Si hay una cola de validadores pendientes ↗, se calcula una marca de tiempo estimada para la activación.

índice único

Cada validador recibe un índice único en función de cuándo se agregan desde el validator queue.

saldo actual y saldo efectivo

El saldo actual es la cantidad de ETH que tiene el validador a partir de ahora. El saldo efectivo representa un valor calculado por el saldo actual. Se utiliza para determinar el tamaño de una recompensa o penalización que recibe un validador. El saldo efectivo nunca puede ser superior a 32 ETH.

Para aumentar el saldo efectivo, el validador requiere "saldo efectivo + 1.25 ETH". En otras palabras, si el saldo efectivo es de 20 ETH, se requiere un saldo actual de 21,25 ETH para tener un saldo efectivo de 21 ETH. El saldo efectivo se ajustará una vez que caiga 0,25 por debajo del umbral, como se ve en los ejemplos anteriores.

Aquí hay ejemplos de cómo cambia el saldo efectivo:

• Si el saldo actual es 32,00 ETH, el saldo efectivo es 32,00 ETH.

• Si el saldo actual se redujo de 22 ETH a 21,76 ETH, el saldo efectivo será de 22,00 ETH.

• Si el saldo actual aumenta a 22,25 y el saldo efectivo es de 21 ETH, el saldo efectivo aumentará a 22 ETH.

ciclo de vida del validador

1. Depositar

Se han depositado 32 ETH en el #contrato-de-deposito y este estado se mantendrá durante unas 7 horas. Esto ofrece seguridad en caso de que la cadena Ethereum sea atacada.

2. Pendiente

Esperando la activación en el Beacon Chain.

Antes de que los validadores ingresen al la #cola-de-validacion, necesitan ser votados por otros validadores activos. Esto ocurre cada 4 horas.

3. Validador activo

Actualmente atestando y proponiendo bloques.

El validador permanecerá activo hasta que:

• Su saldo cae por debajo de 16 ETH (expulsado).

• Salida voluntaria.

• Sea slashed.

4. Slashing validator

El validador ha sido malicioso y será cortado y expulsado del sistema.

Una Penalty es una recompensa negativa (por ejemplo, por desconectarse). Un Slashing es un penalidad grande (≥ 1/32 de saldo en juego) y una salida contundente... . - Justin Drake

5. Salida del validador

• Expulsado: El saldo del validador cayó por debajo de un umbral y fue expulsado por la red.

• Salida: Salida voluntaria, el titular de la clave de retiro tiene la capacidad de retirar el saldo actual del saldo del validador correspondiente.

grupo de validadores

El número de validadores actualmente activos que aseguran la red Ethereum. El grupo de validadores actual se puede ver aquí ↗.

cola de validación

La cola de validación es una cola de primero en entrar, primero en salir para activar y salir de los validadores en el #beacon-chain.

• Hasta 327680 validadores activos en la red, se pueden activar 4 validadores por #epoca. Por cada (4 * 16384) = 65536 validadores activos, la tasa de activación del validador aumenta en uno.

• 5 validadores por época requiere 327680 validadores activos, lo que permite 1125 validadores por día.

• 6 validadores por época requiere 393216 validadores activos, lo que permite 1350 validadores por día.

• 7 validadores por época requiere 458752 validadores activos, lo que permite 1575 validadores por día.

• 8 validadores por época requiere 524288 validadores activos, lo que permite 1800 validadores por día.

• 9 validadores por época requiere 589824 validadores activos, lo que permite 2025 validadores por día.

• 10 validadores por época requiere 655360 validadores activos, lo que permite 2200 validadores por día.

• La cantidad de activaciones escala con la cantidad de validadores activos y el límite es el conjunto de validadores activos dividido por 64.

La salida de validadores funciona de la misma manera, con la cantidad de validadores que pueden salir de Beacon Chain por tasa diaria limitada para preservar la estabilidad de la red.

frase semilla / mnemotécnico

La frase semilla o mnemotécnica es un conjunto de palabras (generalmente de 12, 18 o 24 palabras) que se utiliza para generar sus claves de validación. Su mnemónico es la copia de seguridad de sus claves de validación y será la ÚNICA forma de retirar su ETH cuando llegue el momento y nadie puede ayudarlo a recuperar su mnemónico si lo pierde.

dirección de retiro

Una dirección que se puede configurar opcionalmente al crear una clave de validación que se usará para retirar ETH apostado. Si esta dirección no se configura en el momento de la creación de la clave, se puede configurar en el momento del retiro. Para obtener más información sobre cómo configurar la dirección de retiro en la creación de la clave, consulte nuestra respuesta a las preguntas frecuentes.

Hacer staking es el acto de depositar 32 ETH para activar el software validador. Como validador serás responsable de almacenar datos, procesar transacciones y añadir nuevos bloques a la cadena de bloques. Esto mantendrá a Ethereum seguro para todos y te hará ganar ETH en el proceso.

💰Gana recompensas

Las recompensas se dan por acciones que ayuden a alcanzar el consenso en la red. Obtendrás recompensas por ejecutar software que agrupe transacciones en nuevos bloques y compruebe el trabajo de otros validadores, porque eso es lo que hace que la cadena funcione de manera segura.

🔒 Mayor seguridad

La red se fortalece contra ataques a medida que se aumenta el staking en ETH, dado que se requiere más ETH para controlar la mayoría de la red. Para que exista una amenaza, se necesitaria tener la mayoría de validadores, lo que significa que necesitaría controlar la mayoría de ETH en el sistema. ¡Y eso es muy difícil!

🌿 Más sostenible

Los participantes no necesitan ordenadores con alto consumo de energía para participar en la «prueba de participación», tan solo un ordenador doméstico o un teléfono móvil. Esto hace que Ethereum sea mejor para el medio ambiente.

¿Cómo hacer staking con sus ETH?

🏡 Solo Staking (staking individual)

• De mayor impacto

• Completo control

• Recompensas completas

• Sin confianza

El staking individual en Ethereum es el patrón de oro por apostar. Proporciona recompensas de participación plena, mejora la descentralización de la red y nunca requiere que confíes sus fondos a nadie más.

Quienes estén planteándose hacer staking individualmente deberían tener al menos 32 ETH y un ordenador exclusivamente dedicado, conectado a internet ~24/7. Algunos conocimientos técnicos son útiles, aunque ahora existen herramientas fáciles de usar para simplificar este proceso.

☁️ Staking como servicio

• Tus 32 ETH

• Sus claves de validador

• Operación de nodo de confianza

Si no quieres o no te sientes cómodo tratando con hardware, pero quieres usar tus 32 ETH, las opciones de staking como servicio le permiten delegar la parte difícil mientras gana recompensas de bloques.

Estas opciones generalmente te guiarán a través de la creación de un conjunto de credenciales de validador, subiendo sus claves de firma y depositando sus 32 ETH. Esto permite que el servicio lo valide en tu nombre.

Este método de participación requiere un cierto nivel de confianza en el proveedor. Para limitar el riesgo de la contraparte, las claves para retirar tu ETH normalmente se mantienen en tu posesión.

🪺 Staking en grupo

• Participa con cualquier cantidad

• Gana recompensas

• Simple

• Popular

Ahora existen varias soluciones de participación para ayudar a los usuarios que no tienen o no se sienten cómodos apostando sus 32 ETH.

Muchas de estas opciones incluyen lo que se conoce como la «participación líquida», que implica un token de liquidez ERC-20 que representa su ETH apostado.

La participación líquida permite una salida fácil y en cualquier momento, y hace que la participación sea tan simple como un intercambio de tókenes. Esta opción también permite a los usuarios tener la custodia de sus activos en su propia cartera de Ethereum.

Las apuestas agrupadas no son originarias de la red Ethereum y los terceros están construyendo estas soluciones y tienen sus propios riesgos.

🏢 Exchanges centralizados

• De menor impacto

• Suposiciones de mayor confianza

Muchos exchanges centralizados brindan servicios de staking si aún no se siente cómodo con ETH en su propia cartera. Pueden ser una alternativa para permitirle obtener algo de rendimiento de su cartera de ETH con un mínimo de supervisión o esfuerzo.

La desventaja aquí es que los exchanges centralizados consolidan grandes agrupaciones de ETH para ejecutar un gran número de validadores. Esto puede ser peligroso para la red y sus usuarios, ya que crean un gran blanco central y un punto de fallo, haciendo la red más vulnerable a ataques o errores.

Como puede haber notado, hay muchas maneras de hacer staking en Ethereum. Estas rutas apuntan a una amplia variedad de usuarios y en última instancia son únicos y varían en términos de riesgos, recompensas y supuestos de confianza. Algunos son más descentralizados, probados en producción y/o arriesgados que otros. Proporcionamos información sobre proyectos populares en el espacio, aunque le aconsejamos que siempre investigue por su propia cuenta antes de enviar ETH a cualquier lugar.

Una vez que tenga configurada su nodo validador y esté ejecutando tanto un cliente de capa de ejecución como un cliente de capa de consenso, está listo para comenzar el proceso de depósito.

Los depósitos de participación se procesan a través de la plataforma de lanzamiento de ethereum.org:

https://launchpad.ethereum.org/en/overview ↗

Las siguientes capturas de pantalla muestran el proceso de depósito (Inglés).

Elige el cliente de ejecución

Elige un cliente de consenso

Genere los pares de llaves

¿Cuál es tu sistema operativo actual?

Selecciona esta opción

¿Cómo quieres generar tus claves?

• Descargar la aplicación CLI

• Descargar la aplicación GUI de generación de claves

• Construir desde el código fuente

No deberías preocuparte por el tiempo de inactividad, pero comprender lo que sucede cuando tu validador está fuera de línea puede ayudarte a ganar confianza como validador en solitario.

Escenario de ejemplo

• Comienzas como validador en solitario en casa con 32 ETH.

• Todo va bien y después de unos meses, el saldo de tu validador es de 32,5 ETH.

• Entonces... ¡tu validador se desconecta! 🚨 Si esto sucede de verdad, consulta la guía "Mi ".

Fuga por inactividad

• Tan pronto como tu validador ya no participe en la red, comenzará a ETH.

  • Cuando estás desconectado, por cada atestación perdida, la fuga por inactividad podría ser de alrededor de -0,000011 ETH (la fuga por inactividad es ligeramente menor que una atestación exitosa).

  • Por una atestación exitosa normal, podrías ser recompensado con 0,000014 ET.

• Si tienes una falla catastrófica y no puedes volver a conectar tu validador en línea durante 5 días, entonces tomará aproximadamente 5 días de estar en línea para volver al mismo saldo que cuando ocurrió la falla.

Propuestas de bloque perdidas

Si estás desconectado, no podrás producir un bloque. Pero ¿con qué frecuencia ocurren las propuestas de bloque para un solo validador? Actualmente, en promedio, un validador propondrá un bloque cada 2-3 meses.

Entonces, en este escenario de ejemplo, incluso si estás desconectado por 5 días, hay solo una pequeña posibilidad de que te pierdas una propuesta de bloque. ¿Pero qué pasa si pierdes una propuesta de bloque?

¿Puedo recibir deducciones por estar desconectado?

¿Qué pasa si no puedo recuperar mi validador y / o quiero dejar de hacer staking?

Conclusión

¡No entre en pánico!

La penalización por faltar a las atestaciones es exactamente la misma que la recompensa por una exitosa. Cualquier penalización por tiempo de inactividad se recuperará en la misma cantidad de tiempo de actividad.

. Dependiendo del tamaño del , un único validador en promedio sólo propondrá un bloque cada pocos meses. Si tienes la mala suerte de estar desconectado en el momento en que se le pide a tu validador que proponga un bloque, también está bien.

La red Ethereum es robusta y está diseñada para manejar estas situaciones. Si pierdes tu propuesta de bloque, la que debería haber contenido tu bloque estará vacía. Además de las perdidas por no proponer el bloque, no hay penalizaciones ni deducciones que ocurran por una propuesta de bloque perdida.

Los sistemas automáticos de conmutación por error y de copia de seguridad pueden parecer una buena idea, pero son mucho mucho más propensos a causar un evento de deducción (por ejemplo, doble propuesta) que un proceso de recuperación manual. Perder algunos días de recompensas puede parecer malo en ese momento, ¡pero ser reducido y perder potencialmente MESES de recompensas es mucho peor!

Volviendo a estar en línea

• TODO

  • Resolución de problemas iniciales

  • Resincronización

Recompensas por staking

Los pagos de recompensas se procesan automáticamente para las cuentas de validadores activos con un balance efectivo máximo de 32 ETH.

Cualquier balance por encima de los 32 ETH obtenido a través de las recompensas no contribuye realmente al principal ni aumenta el peso de este validador en la red, y se retira automáticamente como un pago de recompensa cada pocos días. Aparte de proporcionar una dirección de retiro una vez, estas recompensas no requieren ninguna acción por parte del operador del validador. Todo esto se inicia en la capa de consenso, por lo que no se requiere gas (fee de transacción) en ningún paso.

Salir completamente del staking

Es necesario proporcionar una dirección de retiro antes de que se puedan transferir fondos desde el balance de una cuenta de validador.

Los usuarios que deseen salir por completo del staking y retirar todo su balance también deben firmar y transmitir un mensaje de "voluntary exit" (salida voluntaria) con las claves del validador, lo cual iniciará el proceso de salida del staking. Esto se hace con tu cliente de validador y se envía a tu nodo de beacon, y no requiere gas.

El proceso de salida de un validador del staking lleva un tiempo variable, según la cantidad de personas que están saliendo al mismo tiempo. Una vez completado, esta cuenta ya no será responsable de realizar tareas de validación en la red, no será elegible para recompensas y ya no tendrá sus ETH "en staking". En este momento, la cuenta se marcará como completamente "withdrawable".

Una vez que se haya marcado una cuenta como "withdrawable" y se hayan proporcionado las credenciales de retiro, no hay nada más que el usuario deba hacer aparte de esperar. Las cuentas son barridas automáticamente y de forma continua por los proponentes de bloques en busca de fondos salientes elegibles, y el saldo de tu cuenta se transferirá en su totalidad (también conocido como "full withdrawal") durante la próxima .

¿Cómo funcionan los pagos de retiro?

Se determina si un validador es elegible para un retiro o no por el estado de la propia cuenta del validador. En ningún momento se necesita la intervención del usuario para determinar si una cuenta debe iniciar un retiro o no; todo el proceso se realiza automáticamente por la capa de consenso en un ciclo continuo.

Barriendo los validadores

Cuando un validador está programado para proponer el siguiente bloque, se le exige construir una cola de retiro con un máximo de 16 retiros elegibles. Esto se hace comenzando originalmente con el índice del validador 0, determinando si hay un retiro elegible para esta cuenta según las reglas del protocolo y agregándolo a la cola en caso de que exista. El validador designado para proponer el siguiente bloque continuará donde lo dejó el último, avanzando en orden indefinidamente.

Verificación de una cuenta para retiros

Mientras un proponente está revisando los validadores en busca de retiros posibles, cada validador que se verifica se evalúa en función de una breve serie de preguntas para determinar si se debe iniciar un retiro y, de ser así, cuántos ETH se deben retirar.

1. ¿Se ha proporcionado una dirección de retiro? Si no se ha proporcionado una dirección de retiro, la cuenta se omite y no se inicia ningún retiro.

2. ¿El validador ha salido y es retirable ("withdrawable")? Si el validador ha salido por completo y hemos alcanzado la época en la que se considera que su cuenta es "withdrawable", se procesará un retiro completo. Esto transferirá todo el saldo restante a la dirección de retiro.

3. ¿El saldo efectivo ha alcanzado el máximo de 32 ETH? Si la cuenta tiene credenciales de retiro, no ha salido por completo y tiene recompensas superiores a 32 esperando, se procesará un retiro parcial que transferirá solo las recompensas superiores a 32 a la dirección de retiro del usuario.

Durante el ciclo de vida de un validador, solo se realizan dos acciones que influyen directamente en este flujo:

• Proporcionar credenciales de retiro para habilitar cualquier forma de retiro.

• Salir de la red, lo que iniciará un retiro completo.

Gas free

Este enfoque de retiros de staking evita que los stakers tengan que enviar manualmente una transacción solicitando una cantidad específica de ETH para retirar. Esto también significa que no se requiere gas (fee de transacción) y los retiros tampoco compiten por el espacio existente de bloques de la capa de ejecución.

¿Con qué frecuencia recibiré mis recompensas de staking?

Un máximo de 16 retiros pueden procesarse en un solo bloque. A ese ritmo, se pueden procesar hasta 115,200 retiros de validadores por día (suponiendo que no haya slots perdidos). Como se mencionó anteriormente, los validadores sin retiros elegibles se omitirán, lo que disminuirá el tiempo necesario para completar la barrida.

Ampliando este cálculo, podemos estimar el tiempo que llevará procesar una cantidad determinada de retiros:

Como puedes ver, esto se ralentiza a medida que hay más validadores en la red. Un aumento en los bloques perdidos podría disminuirlo proporcionalmente, pero esto generalmente representa el lado más lento de los resultados posibles.

El slashing es una palabra que asusta. Pero, ¿qué es exactamente, cómo puede suceder y cuánto debe preocuparte?

¿Qué es el Slashing?

El slashing es un término utilizado para describir la respuesta de la red Ethereum a un validador que actúa en contra de las reglas de la red. Los validadores realizan una serie de tareas (por ejemplo, atestaciones y proponer bloques).

Si alguien quisiera atacar la red Ethereum, podría proponer múltiples bloques o atestiguar múltiples bloques en conflicto. Para desincentivar los ataques a la red, en un sistema Proof of Stake (PoS), los validadores tienen algo en juego, que actualmente son 32 ETH por validador. Cuando un validador infringe las reglas de la red, sucederán dos cosas:

1. Se toma una cantidad de ETH del saldo inicial de 32 ETH depositados inicialmente al lanzar el validador.

2. El validador es expulsado forzosamente y eliminado del pool de validadores.

La cantidad de ETH tomada como penalización varía según el estado de la red. Si un pequeño número de validadores son objeto de un slashing al mismo tiempo, entonces una estimación aproximada de la penalización por slashing es de 1 o 2 ETH. En un evento Black Swan increíblemente raro, cuando una gran parte de la red está simultáneamente desconectada o infringiendo las reglas (por ejemplo, en un ataque coordinado), entonces la penalización por slashing puede ser de hasta el 100% de la apuesta.

Ser expulsado forzosamente de la cola de validadores actualmente bloquea tu staking, ya que los retiros no están habilitados. Cuando los retiros estén habilitados, podrás volver a apostar tus ETH restantes (si todavía tienes los 32 requeridos), después de pasar por la cola de salida y la cola de activación.

¡Es aleatoria!

Con qué frecuencia un validador recibe propuestas de bloque y es seleccionado para formar parte de un comité de sincronización de forma completamente aleatoria. Mientras no vea propuestas perdidas, no hay absolutamente nada que pueda hacer para aumentar la frecuencia

Que sea totalmente aleatoria puede resultar un poco confuso, sin embargo, es completamente normal que un validador no reciba una propuesta durante 9 meses, o que también que reciba dos propuestas en una semana. Con un conjunto lo suficientemente grande, esto se equilibra, pero para un grupo pequeño de validadores, la aleatoriedad puede sentirse no un poco inquietante.

Puedes consultar las últimas estadísticas sobre la frecuencia de propuestas de bloque en Lucky Staker ↗.

Puedes usar la herramienta de ethdo ↗ de attestant.io ↗para consultar la frecuencia promedio actual de propuestas y comités de sincronización. Desde finales de 2022, hay aproximadamente una propuesta cada 2 meses y la participación en comités de sincronización es cada 2,5 años.

Realmente no hay nada que pueda hacer?

Dentro de la comunidad nos gusta bromear con que tal vez encendiendo algunas Vitalik prayer candles ↗ puedan aumentar las probabilidades, pero realmente no, no existe forma en que se pueda aumentar la probabilidad de las propuestas ya que es totalmente aleatoria.

¡No entres en pánico!

Perder algunas atestaciones es completamente normal y extremadamente de bajo costo. La penalización por perder una atestación es exactamente la misma que la recompensa por una exitosa. Entonces, con alrededor de 240 atestaciones por día por validador, ¡perder una o dos sigue siendo una tasa de atestación exitosa de más del 99%!

Comprendiendo las atestaciones perdidas, baja efectividad y mejorando tu configuración

Hay dos causas de perder una atestación o tener una baja efectividad con tu validador. Algunas causas están bajo tu control como staker y algunas causas están fuera de tu control.

Incluso con una configuración perfecta, podrías perder algunas atestaciones o votar incorrectamente durante una atestación disminuyendo tu efectividad de vez en cuando. Las causas que están fuera de tu control a menudo están relacionadas con la propagación de la red o relacionadas con que algunos de tus peers se retrasen en realizar sus propias tareas.

Para profundizar y aprender todo sobre la tarea de atestación, los tiempos, la efectividad y la propagación de la red, revisa estos excelentes artículos.

Understanding Attestation Misses ↗ (inglés) por Adrian Sutton

Exploring ETH2: Attestation Inclusion ↗(inglés) por Adrian Sutton

Defining Attestation Effectiveness ↗ (inglés) por Jim McDonald

Como staker, no puedes hacer mucho sobre las causas que están fuera de tu control. Lo que puedes hacer es trabajar en los elementos de tu configuración que están bajo tu control para maximizar tus recompensas. Incluso si tienes una configuración que funcionaba bien antes del merge, es posible que con el trabajo adicional que se está introduciendo, alguna parte que tu configuración pasó por alto podría ser la causa de atestaciones adicionales perdidas o una menor efectividad desde que se realizó el merge. Por eso deberías revisar todos estos elementos.

1. Asegúrate de que tus clientes estén actualizados. Las actualizaciones del cliente a menudo incluyen optimizaciones y mejoras que ayudarán a realizar tus tareas a tiempo.

2. Asegúrate de que tu máquina tenga consistentemente suficientes recursos (CPU, RAM, disco, etc). Usar una máquina dedicada puede ayudar. Si tus clientes están escasos de alguno de estos recursos, probablemente será una causa de más atestaciones perdidas y menor efectividad.

3. Asegúrate de que tu hora esté correctamente sincronizada. El protocolo del beacon chain es bastante sensible al tiempo. chrony es una buena herramienta para mejorar la sincronización de tu tiempo. En distribuciones de Ubuntu o Debian, la instalación de chrony a menudo es tan fácil como sudo apt install chrony. En Windows, puedes usar estas instrucciones ↗ para mejorar la sincronización de tu tiempo.

4. Asegúrate de tener buena latencia, ancho de banda y calidad de internet. Para validadores de hogar, es poco realista pedir una ISP o conexión a internet dedicada para tu validador, pero asegúrate de que tus otros usos de la red no interfieran demasiado con tu validador. En caso de duda, verifica si puedes obtener un mejor plan de tu proveedor o verifica si hay un proveedor alternativo en tu área que pueda mejorar tu internet.

5. Asegúrate de tener consistentemente suficientes pares. Monitorear el recuento de pares de tus clientes no es una mala idea si tienes la capacidad técnica.

6. Asegúrate de tener puertos abiertos correctamente configurados que permitan conexiones entrantes. No solo puede mejorar la salud de tu configuración de networking y el recuento de tus pares, sino que también mejorará la salud de la red Ethereum en su conjunto. Para probar si tus puertos están abiertos, puedes usar el comprobador de puertos abiertos de StakeHouse. Llamando a curl https://eth2-client-port-checker.vercel.app/api/checker?ports=30303, 9000 debería devolver un resultado que incluya 30303 y 9000 en el campo open_ports si esos puertos están abiertos desde Internet. 30303 es el puerto P2P predeterminado para Geth y 9000 es el puerto P2P predeterminado para muchos clientes de consenso. Ajusta estos valores si usas puertos personalizados o si usas clientes que tienen puertos predeterminados diferentes. Consulta la documentación de tu cliente para encontrar más información sobre esto.

Una vez que tengas todo eso en su lugar, hay poco más que puedas hacer para ayudar. Puede haber algunos beneficios marginales al conectarse con más peers a costa de un mayor uso de recursos, especialmente de ancho de banda. Bajo circunstancias normales, el recuento predeterminado de pares de tus clientes debería ser bueno. Monitorear la calidad de Internet con herramientas como las de pingman ↗ puede ayudar a identificar la causa de algunas de estas atestaciones perdidas si están relacionadas con la red, pero probablemente seguirá estando fuera de tu control.

Fuente ↗

TODO

"Acogedores primero, conocedores después"

Bienvenido a la Base de Conocimientos de EthStaker!

Una colección imparcial y de código abierto de información y conceptos útiles sobre cómo hacer staking en Ethereum. Si estás buscando empezar a hacer staking en Ethereum o simplemente aprender más sobre cómo la red está asegurada a través de validadores Proof of Stake (PoS), ¡has venido al lugar correcto!

🔗 Links útiles

• Para Empezar

• Preguntas Frecuentes de Staking

🚀 Para empezar

• What is Ethereum staking? (inglés)

• Running a node without any ETH (inglés)

• Deposit process explained (inglés)

🚨 ¡AYUDA!

• My validator is offline! What do I do? (inglés)

• Missed attestations! What can I do? (inglés)

• I'm worried about downtime 😔 (inglés)

• I'm worried about slashing 🔪 (inglés)

💰 Recompensas

• How does my validator earn ETH? (inglés)

• Block proposal frequency (inglés)

💻 Hardware

• Hardware requirements (inglés)

• Hardware examples (inglés)

⛓️ Clientes Validadores

• Validator clients explained (inglés)

• Execution clients (inglés)

• Consensus clients (inglés)

• Checkpoint sync (inglés)

• Validator effectiveness (inglés)

• MEV boost (inglés)

¿Puedo contribuir a la base de conocimientos de EthStaker?

Sí. Este es un sitio de documentación vivo, lo que significa que necesitamos la ayuda de la comunidad para mantener y actualizar el contenido. Cualquier contribución, desde escribir secciones enteras y traducciones hasta corregir errores ortográficos y gramaticales, será muy apreciada.

Puedes ganar GitPOAPs contribuyendo directamente a la Base de Conocimientos de EthStaker (un contribuidor↗) y haciendo una pregunta que lleve a la creación de contenido (un simpatizante↗).

Para sugerir cambios o añadir contenidos nuevos visita nuestro EthStaker Github↗ o si tienes alguna pregunta únete a nuestro Discord↗ en el canal en español.

✏️ Involucrate

• How to contribute (inglés)

• ¿Puedo ser sancionado por estar desconectado?

• ¿Puedo dejar de correr mi validador durante unos días y luego volver a iniciarlo?

• ¿Puedo retirar mi ETH en cualquier momento?

• ¿Cómo se incentiva a los validadores a permanecer activos y honestos?

• ¿Por cuanto tiempo son válidos los mensajes de salida pre firmados?

• ¿Cuánto ETH necesito para hacer staking y convertirme en validador?

• Estoy abrumado y no sé por donde empezar, ¿qué puedo hacer?

• ¡Propuse un bloque! ¿Qué gané?

• ¿Se muestra la dirección de depósito u origen en algún lugar?

• ¿Hay una penalización por perder una propuesta de bloque?

• ¿Hay una penalización por perder una certificación?

• ¿Hay alguna ventaja en tener más de 32 ETH en participación?

• ¿Debería establecer una dirección de retiro al configurar mi validador?

• ¿Qué es un validador exactamente?

• ¿Qué pasa si pierdo las llaves de mi validador?

• ¿Qué pasa si pierdo la frase semilla o mnemónica de mi validador?

• ¿Y si quiero dejar de participar?

• ¿Qué es un operador de nodos?

• ¿Qué es un cliente del validador?

• ¿Qué es el contrato de depósito?

• ¿Cuál es la forma más fácil de participar individualmente desde casa?

• ¿Cuál es el compromiso de tiempo de correr un validador?

• ¿Cuándo debería recargar el balance de mi validador?

• ¿Por qué tengo que tener fondos en participación?

• ¿Por qué el máximo de 32 ETH?

¿Puedo ser sancionado por estar desconectado?

No. Realmente la única condición que puede causar una sanción es si usas las llaves de tu validador en dos nodos al mismo tiempo (como una conmutación por error / configuración de redundancia, donde tu nodo de respaldo se enciende accidentalmente mientras el principal sigue en funcionamiento). No permitas que esto suceda y no serás sancionado. No se puede ser sancionado por estar desconectado por mantenimiento.

¿Puedo dejar de correr mi validador durante unos días y luego volver a iniciarlo?

Sí, pero con penalizaciones pequeñas. Consulta Estoy preocupado por el tiempo de inactividad.

¿Puedo retirar mi ETH en cualquier momento?

Los retiros no están actualmente habilitados en la Beacon chain. Esto significa que todo el ETH depositado quedará bloqueado en el contrato de staking hasta un momento futuro (abril 2023) en el que se permitirán los retiros tras una actualización de la red.

Puedes ver más información en la página de preguntas frecuentes de la Ethereum Foundation (en inglés) https://notes.ethereum.org/@launchpad/withdrawals-faq

Si tu validador propone un bloque, parte de las recompensas estarán disponibles de forma inmediata en forma de fees de prioridad y MEV (si estás usando un relay con MEV-Boost).

En el futuro, cuando los retiros estén habilitados, podrás retirar tu ETH al salir del validador y esperar en la cola de retiro.

¿Cómo se incentiva a los validadores a permanecer activos y honestos?

Como validador, eres recompensado por proponer / atestiguar bloques que se incluyan en la cadena. Por otro lado, puedes ser penalizado por estar desconectado y comportarte de manera maliciosa, por ejemplo, atestiguando bloques inválidos o contradictorios.

El concepto clave es el siguiente:

• Las recompensas se otorgan por acciones que ayuden a la red a llegar a un consenso.

• Hay pequeñas penalizaciones por acciones involuntarias que obstaculizan el consenso.

• Grandes penalizaciones (o 'slashings') por acciones maliciosas.

En otras palabras, maximizas tus recompensas al proporcionar el mayor beneficio a la red.

¿Por cuanto tiempo son válidos los mensajes de salida pre firmados?

Los mensajes de salida pre firmados sólo se mantienen válidos para dos hard forks. Tras estos deberás generar nuevos.

Esto se debe a https://github.com/ethereum/consensus-specs/blob/dev/specs/phase0/beacon-chain.md#get_domain, específicamente la línea:

fork_version = state.fork.previous_version if epoch < state.fork.epoch else state.fork.current_version

Un mensaje de salida firmado en cualquier época anterior al último hard fork se agrupa en una "versión anterior" y se le asigna su versión del fork. Esto significa que si tu operación fue firmada hace dos forks, la función de verificación tiene la versión del fork incorrecta, y por lo tanto el dominio equivocado, la raíz equivocada y fallará al verificar.

¿Cuánto ETH necesito para hacer staking y convertirme en validador?

Cada par de llaves asociado con un validador requiere bloquear 32 ETH para activarse, lo cual representa tu balance inicial, además de tu poder de voto inicial y máximo para cualquier validador.

Estoy abrumado y no sé por donde empezar, ¿qué puedo hacer?

Hay muchas opciones para participar haciendo staking en Ethereum, esto sin duda puede ser abrumador.

Tómalo con calma. Primero aprende sobre las opciones que tienes y escoge la que más te convenga. No hay necesidad de apurarse y perder el sueño.

Si escoges "staking individual en casa" y quieres correr tu propio validador, decide entre las diferentes opciones de hardware (e.j. Intel NUC) y sigue una guía de staking en una red de prueba primero. Busca guías de staking para la red de pruebas Goerli. Toma notas, averigua que sucede cuando desconectas el cable de alimentación del validador, como actualizar, etc. En resumen, obtén experiencia con tu nodo antes de hacer staking en la red principal de Ethereum.

Igualmente, no tienes que enfrentar los problemas tu solo.

No dudes en hacernos cualquier pregunta y únete a nuestra comunidad de Discord.

¡Propuse un bloque! ¿Qué gané?

Los validadores que participan en asegurar la Beacon chain y realizan sus "deberes" son recompensados por ello mediante la emisión de ETH nuevo. Además, los validadores reciben fees de prioridad pagados por los usuarios, y MEV (Maximal Extractable Value) opcionalmente.

Puedes ver las recompensas por bloques propuestos de un validador mirando la dirección del receptor de los fees en etherscan.io↗ bajo Produced Blocks.

Puedes ver una explicación detallada aquí: ¿Cómo gana ETH mi validador?

¿Se muestra la dirección de depósito u origen en algún lugar?

Si, la dirección de depósito u origen se muestra en el validador. Sin embargo, no se usa para nada en el protocolo. La capa de consenso no tiene registro de desde qué dirección se realizó el depósito de un validador, pero queda registrado en el historial de la capa de ejecución al igual que todas las demás transacciones.

La dirección de depósito u origen se puede ver en beaconcha.in bajo Deposits -> Ethereum Deposits -> From Address.

¿Hay una penalización por perder una propuesta de bloque?

No. Si pierdes una propuesta de bloque, la ranura que debería contener tu bloque estará vacía. A parte de las recompensas perdidas por perder la propuesta del bloque, no hay ninguna penalidad o sanción que ocurra por una propuesta de bloque perdida.

¿Hay una penalización por perder una certificación?

Perder algunas certificaciones es completamente normal y extremadamente económico. La penalidad por perder una certificación es exactamente la misma que la recompensa por una exitosa. Por lo tanto, con alrededor de 240 certificaciones al día por validador, perder uno o dos sigue siendo una tasa exitosa de más del 99%.

¿Hay alguna ventaja en tener más de 32 ETH en participación?

No. No hay ninguna ventaja en tener más de 32 ETH en participación.

Depositar más de 32 ETH en el mismo set de llaves no incrementa el potencial de recompensas, o acumula recompensas por encima de 32 ETH ya que cada validador está limitado a un balance de 32. Esto significa que se participa en incrementos de 32 ETH, cada uno con su único set de llaves y balance.

¿Debería establecer una dirección de retiro al configurar mi validador?

Establecer una dirección de retiro cuando creas las llaves de tu validador puede ser útil ya que no tendrás que configurarla de nuevo cuando se habiliten los retiros.

La interfaz de línea de comando de depósito de participación puede establecer una dirección de retiro cuando se crea el json de depósito. Si un usuario decide no hacerlo, normalmente por omisión, entonces establece el hash de la llave pública de retiro en su lugar. En algún momento futuro, posiblemente con la actualización Shangai/Capella, habrá una herramienta que tome la mnemónica y firme un mensaje para efectuar un cambio único de credenciales v0, llave de retiro, a credenciales v1, dirección de retiro.

Y eso es todo. Una vez tu validador usa credenciales v1, la dirección de retiro no puede ser cambiada. Bajo el diseño actual, las barridas son automáticas, igual que los retiros completos: Los retiros completos ocurren solo cuando se completa la salida del validador.

Es poco probable que se cree una herramienta para exportar la llave de retiro, tampoco sería muy útil. Necesitas la llave de retiro como mucho dos veces:

• Una vez para generar la llave de firma (solo si no estableciste una dirección de retiro en ese momento).

• Una vez más para firmar un mensaje para establecer una.

En ambos casos la llave puede ser generada dentro del CLI, ser usada para su propósito, y después descartarse sin haber sido escrita en el disco.

Sin embargo, hay algunos casos a tomar en cuanta donde es preferible no establecer una dirección de depósito al principio:

• Si planeas migrar tu validador a una piscina en el futuro (e.j. RocketPool), no podrás hacer esta migración si configuras una dirección de retiro cuando creas las llaves de tu validador. Necesitarías esperar a que se habiliten los retiros, esperar en la fila de retiros y después volver a entrar a un validador, potencialmente teniendo que esperar una fila de activación también.

¿Qué es un validador exactamente?

Un validador es una entidad virutal que vive en la Beacon chain, representado por un balance, llave pública y otras propiedades. También participa en el consenso de la red de Ethereum.

¿Qué pasa si pierdo las llaves de mi validador?

Si hay una falla catastrófica de tu validador y pierdes sus llaves no te preocupes. Estas pueden ser fácilmente recuperadas siempre y cuando tengas la frase semilla o mnemónica de tu validador. Simplemente sigue las mismas instrucciones que cuando generaste por primera vez las llaves de tu validador, e instálalas en una nueva máquina validadora.

Tienes que estar 100% seguro de que las máquinas anteriores no volverán a estar en línea, ya que esto resultará en un evento de penalización.

¿Qué pasa si pierdo la frase semilla o mnemónica de mi validador?

Si pierdes la frase semilla usada para generar las llaves de tu validador, entonces es probable que el ETH en participación no se pueda recuperar.

De todas formas, si tienes una dirección de retiro, las llaves del validador son suficientes para firmar una salida voluntaria, lo que resultaría en un retiro a esa dirección. También está el caso especial si tienes un mensaje de salida voluntario previamente firmado, pero estos normalmente solo son usados por servicios de staking y los ponemos en esta guía para mantenerla completa.

¿Y si quiero dejar de participar?

Si no puedes recuperar tu validador o decides que quieres dejar de participar, tienes la opción de salir de tu validador. Aunque los retiros no están habilitados, puedes hacer que tu validador salga de la red. Esto significa que, aunque no vas a poder tener el balance de tu validador de inmediato (hasta que se activen los retiros), no vas a ser penalizado por estar fuera de línea una vez el validador sale de la fila de retiro. Salir de un validador es un proceso de una vía ahora mismo. Para más detalles sobre como salir de tu validador, revisa nuestra guía.

¿Qué es un operador de nodos?

Un operador de nodos es un humano que se asegura de que el software del cliente esta corriendo de forma apropiada, manteniendo el hardware según sea necesario.

¿Qué es un cliente del validador?

Un cliente del validador es el software que actúa a nombre del validador al sostener y usar sus llaves privadas para hacer certificaciones acerca del estado de la cadena. Un único cliente validador puede tener multiples pares de llaves, controlando varios validadores.

¿Qué es el contrato de depósito?

Puedes pensar en el contrato de depósito como una transferencia de fondos desde una cuenta de Ethereum hasta una cuenta de un validador de prueba de participación. Especifica quién está participando, quién está validando, cuánto ETH hay participando, y quién puede retirar los fondos.

¿Cuál es la forma más fácil de participar individualmente desde casa?

Configurar tu propio validador para participar individualmente desde casa no es complicado.

Puedes seguir estas guías de participación paso a paso, lo que no te tomará mucho tiempo. Puedes revisar también el compromiso de tiempo.

De todas formas, hay opciones de hardware pre-configuradas como Dappnode↗ o Avado↗, que pueden hacer todo más fácil y eliminar la necesidad de interactuar con la interfaz de línea de comando o Linux en general. También puedes instalar el software de código abierto de Dappnode ↗ en tu propio hardware para tener una experiencia de participación más intuitiva.

¿Cuál es el compromiso de tiempo de correr un validador?

La mayoría del compromiso de tiempo por participar es el aprendizaje y configuración inicial. Te tomará probablemente un día o dos de prueba y error para tener todo listo (quizás más, y eso también está bien). Una vez tengas todo listo solo vas a tener que actualizar una vez al mes más o menos (toma diez minutos) y arreglar apagones u otros problemas, los cuales no son frecuentes.

¿Cuándo debería recargar el balance de mi validador?

La respuesta a esta pregunta depende bastante de cuanto ETH tengas a tu disposición. Ciertamente deberías recargar si tu balance está cerca de 16 ETH. Esto es para asegurarte de que no salgas del conjunto de validadores (lo cual pasa automáticamente si tu balance cae por debajo de 16 ETH). En el otro lado del espectro, si tu balance está por los 31 ETH, probablemente no merezca la pena añadir el ETH restante para llegar a 32.

¿Por qué tengo que tener fondos en participación?

Como un validador, tienes que tener fondos en participación para que puedas ser penalizado por comportarte de forma deshonesta. En otras palabras, para mantenerte honesto, tus acciones tienen que tener consecuencias financieras.

¿Por qué el máximo de 32 ETH?

Cada 32 ETH se activa un conjunto de llaves de validador. Estas llaves se usan para firmar el estado de la red. Mientras más bajo sea la cantidad de ETH requerido, más firmas deberán ser guardadas por la red. 32 ETH fue escogido como un balance entre permitir que participen la mayor cantidad de personas posibles sin inhibir la descentralización de la red al llenar el espacio de cada bloque con firmas.

Limitar la cantidad máxima a 32 ETH por validador fomenta la descentralización del poder, ya que evita que un solo validador tenga un voto excesivamente grande sobre el estado de la cadena. También limita la cantidad de ETH que puede salir de participación en un momento dado, ya que la cantidad de validadores que pueden salir en cada periodo es limitado. Esto ayuda a proteger la red contra ciertos ataques.

Aunque el voto de un validador se pondera por la cantidad que tiene en participación, el peso de voto comienza y tiene un límite en 32. Es posible caer por debajo de esto con un rendimiento deficiente del nodo, pero no es posible elevarlo. No deposites más de 32 ETH para un solo validador. No crecerán las recompensas y estarán bloqueados hasta que se habiliten los retiros.

La importancia de usar una UPS

Es altamente recomendado el el uso de un UPS (Sistema de Alimentación Ininterrumpida) para tu nodo o validador. Al conectarlo, te aseguras de que no se apague repentinamente en caso de una pérdida de energía eléctrica inesperada.

Una desconexión repentina puede causar varios problemas considerables, como:

• Corrupción de la base de datos

  • Esto requerirá que (dependiendo de la gravedad de la corrupción) elimines la base de datos almacenada y la vuelvas a sincronizar desde cero. Dependiendo de la velocidad de tu SSD, esto podría dejarte sin conexión por un tiempo.

• Corrupción del sistema operativo

  • Esto requerirá una reinstalación del sistema operativo. Luego, tendrás que volver a configurar la máquina, instalar un cliente de ejecución y consenso, configurar tus validadores y luego sincronizar ambos clientes.

• Fallas en el hardware

  • Si falla tu disco duro, deberás conseguir e instalar uno nuevo, luego volver a completar los pasos anteriores (instalar un sistema operativo y sincronizar los clientes).

Si ocurre un corte de energía y no se daña ningún componente físico, todavía podría hay una posibilidad de estar en peligro. Cuando se restablece la energía, es posible experimentar un aumento repentino de la misma que puede sobrecargar y quemar componentes, lo que significaría más tiempo fuera de línea mientras investiga qué componentes están dañados y luego los reemplaza.

Dependiendo del modelo de UPS y el sistema operativo que esté utilizando, puede configurar su UPS para que apague los computadores conectados de manera segura una vez que el nivel de la batería caiga por debajo de cierto punto. Esto es increíblemente poderoso para proteger sus datos y su computadora.

Mi UPS (1600VA/960W) me costó aproximadamente $200 USD y proporciona alrededor de una hora de energía a todos los dispositivos conectados. Tengo tanto mi nodo como mi router conectados, por lo que en caso de un corte de energía, el nodo seguirá en línea trabajando. ¡He tenido algunos cortes de energía breves desde que me convertí en validador, por lo que me ha sido de gran ayuda!

Configurando el auto start

Si las cosas se apagan mientras duermes o no estás en casa, los siguientes pasos son muy útiles para hacer que las cosas se inicien automáticamente.

Como configurar tu computadora para que se encienda automáticamente después de una desconexión.

En tu BIOS, es muy probable que haya una configuración de energía, allí deberías poder encontrar una opción para que tu computadora se encienda automáticamente una vez que se restablezca la energía.

Si no puedes encontrar la configuración, es posible que debas consultar la guía del usuario de tu placa madre.

NOTA - Para ingresar a tu BIOS, deberás presionar un botón específico después de encender la máquina (y antes de que se cargue el sistema operativo). Las teclas más comunes son "DEL", "F1", "F2", "F10".

Esto varía según las placas madre, y si no estás seguro de cuál es la tuya, verifica la información POST una vez que la PC se inicie, ya que puede mostrarla en la pantalla. O puedes consultar la guía del usuario de tu placa madre. O puedes hacer lo que yo hago, que es extender tus manos sobre el teclado y presionar las teclas mencionadas anteriormente todas a la vez y esperar a que una de ellas funcione.

Si estás en una máquina virtual, configura los servidores para iniciar

Si estás usando un hipervisor para alojar tus nodos/validadores, entonces debes configurar las máquinas virtuales para que se enciendan automáticamente una vez que la computadora haya iniciado. Esto también te ahorrará tener que iniciarlos manualmente si reinicias la computadora principal.

Using services and configuring auto start (No sé como traducir esto))

Es una práctica común configurar tu nodo de ejecución, nodo de consenso y validadores de consenso como servicios y establecer su inicio automático una vez que el sistema operativo se haya iniciado. Esto se puede hacer con systemd.

Somer Esat ha escrito excelentes guías y tiene algunos ejemplos que se pueden consultar, uno de los cuales se puede encontrar aquí. En esa guía, hay tres ejemplos: "geth.service", "lighthousebeacon.service" y "lighthousevalidator.service".

Al seguir estos tres pasos, podrás minimizar el tiempo de inactividad de tu sistema.

Abanico del NUC ruidoso

Si estás utilizando un NUC, es posible que notes que el ventilador es bastante ruidoso y puede resultar molesto para los oídos. Esto se debe a una configuración llamada turbo boost que está habilitada de forma predeterminada.

Los validadores que participan en la seguridad del Beacon Chain y ejecutan "tareas" son recompensados por esto mediante la nueva emisión de ETH. Además, los validadores reciben tarifas prioritarias pagadas por los usuarios y opcionalmente MEV. Los validadores son recompensados por ejecutar esos deberes mediante la nueva emisión de ETH en el "saldo del validador". El APY actual se puede ver en la plataforma de lanzamiento oficial↗.

*Varía según el número total de validadores en la red. La estimación mostrada es aproximada para 435,000 validadores activos.

**Estos están sujetos a la aleatoriedad; puede haber "rachas secas" varias veces más largas que el promedio sin recibir una.

Las recompensas proporcionadas en el Consenso actualmente no son líquidas. Están bloqueadas en la cadena hasta que se implementen los retiros. Las recompensas proporcionadas en la Ejecución, sin embargo, son líquidas y se pueden acceder instantáneamente.

Fuente↗

Penalizaciones de validador

Si el validador está fuera de línea y no está ejecutando sus deberes, será penalizado a una tasa ligeramente menor que las recompensas por el mismo período de tiempo.

Los validadores son penalizados por pequeñas cantidades de ETH si están desconectados y no realizan sus deberes asignados. Esto se llama leaking. Si un validador viola una de las reglas principales de la cadena Beacon y parece estar atacando la red, puede ser slashed. Slash es una salida forzosa de su validador sin su permiso, acompañada de una multa relativamente grande que elimina parte del saldo de ETH de su validador.

Realísticamente, la única condición que puede causar un slashing es si ejecuta las claves de su validador en dos nodos al mismo tiempo (como una configuración de conmutación por error / redundancia, donde su nodo de respaldo se enciende accidentalmente mientras su nodo principal todavía se está ejecutando). No deje que esto suceda y no tendrá slashing. El slashing no puede ocurrir por estar fuera de línea para mantenimiento.

A continuación, se muestra una tabla que muestra las penalizaciones que pueden ocurrirle a un validador:

*Varía según el número total de validadores en la red. La estimación mostrada es aproximada para 435,000 validadores activos.

Fuente ↗

This is a simple NUC that I set up for my home staking validator. It was very easy to build - around 10 minutes to unpack everything, slot in the RAM and SSD, and turn it on.

I decided on the larger form factor for the NUC (there's a normal and a slim version) to avoid any problems with restricted airflow and overheating. I'm also not constrained on space so I didn't mind having a slightly larger form factor on my shelf.

2TB SSD is the right amount for me as I won't need to upgrade it within the next 1-2 years and possibly by that time there may be improvements made in the protocol and/or clients that allow for smaller states, needing less storage.

You don't need 64GB of RAM but I wanted to have extra in case I needed it in the future, but 16GB would have been fine.

Total cost: £1165 (October 2022)

The machine only needed three parts:

To open the NUC, simply unscrew the four retaining screws, and detach the ribbon cable.

The ribbon cable has a small plastic retainer that can be unclipped by hand.

With the ribbon cable removed, the NUC will look like this:

The first component to insert is the SSD. There is a retaining screw that needs to be removed before the SSD is inserted (1).

The SSD is placed in the slot that says "NVMe ONLY" (2). It can only fit one way because of the little notch, so there's nothing to worry about.

Replace the SSD retaining screw (1).

The SSD in place should look like this:

Insert the RAM into the slots. Again, they can only fit one way because of the little notch.

The finished setup should look like this:

Replace the NUC base plate and secure the four retaining screws... and that's it!

All you need to do now is plug in the power cable and press the power button to turn it on 🥳

Este es un equipo ensamblado que armé para validar en solitario. Decidí componentes de alta calidad a un buen precio para que no sean obsoletos rápidamente. Hay 6 cosas principales a tener en cuenta:

• Tarjeta Madre

• Microprocesador

• Memoria RAM

• Disco Duro

• Fuente de Alimentación

• Gabinete

Me decidí por una placa base mini ITX Z690l que es de factor pequeño, la tarjeta es moderna para albergar microprocesadores Intel de 12.ª generación que durarán muchos años de arduo trabajo.

Un microprocesador Intel Corei5-12400 con gráficos integrados, la relación con o sin gráficos integrados es muy poca la diferencia en el costo, además te ahorras en la compra de una tarjeta gráfica.

Una memoria RAM DDR5 de 16 GB con RGB le queda genial a tu equipo ensamblado, además de los 6000 MHz que alcanza.

Un disco duro SSD 2TB PCI Express 3.0 NV1 M.2 NVMe.

La fuente de alimentacion EVGA Supernova 750 GM es muy importante para el montaje, me decidí por una EVGA para la mini ITX que no hace ruido, que es modular, te ahorras cables que no necesitas y el ventilador solo se activa cuando es necesario, la forma SFX es más pequeña que la habitual.

Finalmente, el Gabinete Cooler Master NR200P SFF - Mini-ITX, extraíble y con gran acceso para modificar los componentes de hardware, incluidos los ventiladores.

Sin duda, es una sabia decisión construir tu propio nodo validador. Son componentes de calidad, puedes ahorrar más comprando otras placas base u otro tipo de RAM.

$280 USD - Placa base Z690I AORUS ULTRA LITE LGA 1700/ Intel Z690/ Mini-ITX/ DDR5/ Dual M.2/ PCIe 3.0/ USB 3.2 Gen2X2 Type-C/2.5 GbE LAN

$225 USD - Microprocesador Intel Procesador Core i5-12400 - S-1700-2.50GHz - 6-Core - 18MB Smart Cache (12va. Generación - Alder Lake)

$125 USD - Memoria RAM 16GB DDR5 XPG ECC CL40 XMP 6000MHz RGB

$145 USD - Disco Duro SSD 2TB PCI Express 3.0 NV1 M.2 NVMe

$115 USD - Fuente de alimentación EVGA Supernova 750 GM, 80 Plus Gold 750W, totalmente modular, modo ecológico con ventilador FDB, factor de forma SFX

$125 USD - Gabinete Cooler Master NR200P SFF - Mini-ITX

TOTAL: $1015 USD (septiembre 2022) Saludos ##StakeFromHome #Mexico

Aquí hay una lista de configuraciones de ejemplo para realizar stake en casa creadas por la comunidad EthStaker:

• Computadora ensamblada

Un full node es uno que se ejecute tanto en el como en el .

Aquí puedes ver de forma sencilla que es lo que se requiere para ejecutar un full node en la red de Ethereum:

• Una conexión a Internet estable. Cuanto más tiempo permanezca en línea, mejores serán sus recompensas. Una conexión a Internet irregular llega a perjudicar sus ganancias.

• Al menos 10 Mbps de ancho de banda tanto de subida como de bajada. Un full node suele requerir alrededor de 8 Mbps a 10 Mbps de tráfico de red, dependiendo de su configuración.

• Que no haya un límite de datos por parte de su proveedor de internet. Ejecutar un nodo completo consumirá muchos datos, hasta más de 2 TB por mes de solo datos de cadena! Esto se puede mitigar en cierta forma con algunos ajustes de configuración en los clientes ETH, pero como regla general, no es recomendable ejecutar un nodo completo si su plan de Internet tiene un límite de datos mensual.

• Servicio de electricidad estable. Por la misma razón que se necesita una conexión a Internet estable, también es necesario tener energía confiable. Esto se puede mitigar con una gran UPS (batería de respaldo) para manejar cortes de energía breves.

• Una computadora que cumpla con los requerimentos suficientes. Esto es bastante flexible porque realmente depende del cliente de ejecución y consenso que use y de las configuraciones que configure. La computadora puede ser una máquina local o puede ser un Servidor Privado Virtual (VPS) alojado en la nube. A continuación podrá encontrar información al respecto:

Algunos de los requísitos que son considerados como mínimos para ejecutar un full node son:

• Sistema operativo Linux o macOS

• CPU de cuatro núcleos (o doble núcleo hiperprocesado); se admiten tanto x64 como arm64

• 16 GB de RAM (preferiblemente DDR4)

• 2 TB de espacio libre en disco SSD.

  • Un disco duro de plato giratorio no es lo suficientemente rápido para manejar las constantes lecturas y escrituras aleatorias que requiere la actividad de la cadena de bloques. Es obligatorio el uso de una unidad de estado sólido.

• La configuración ideal y lo más práctico es tener una computadora dedicada para el staking. Intenta limitar los procesos adicionales que se ejecutan en tu equipo de staking, especialmente si se trata de algo que se conecta con el mundo exterior. Cada proceso adicional y cada archivo descargado es otra oportunidad.

• Tus ETH estarán bloqueados en la hasta mediados de 2023, . Por lo que tiene sentido comprar hardware de buena calidad. Pero no te alarmes, esto no es como la minería que tiene márgenes ajustados, aquí la inversión se recuperará rápidamente.

• ¡Usa Linux, es fácil! En un futuro previsible, Linux recibirá un mejor soporte tanto de los equipos de clientes como de la comunidad en general. Si eliges Linux, tendrás acceso a más guías y más soporte técnico de la comunidad en general. Linux es ligero, estable, seguro y no te obliga a reiniciar para las actualizaciones frecuentemente.

• ¡Usa un ! Es bueno tanto para la salud de Ethereum como para la salud de tu bolsillo.

• ¡Se recomienda fuertemente un respaldo con una UPS! En el deben de estar conectados tanto el módem como el router. Muchos proveedores de servicios de internet tienen generadores para respaldar las comunicaciones de servicios de emergencia, lo que significa que el Internet sigue funcionando durante un corte de energía siempre que tu equipo esté alimentado. Tu proveedor de servicios de Internet puede ser el mismo. Aparte de los cortes de energía, no tener que apagar tu computadora cada vez que la alimentación eléctrica falle es algo que se agradece bastante cuando haces staking desde casa.

• Todo lo que se mencionó aquí aplica tanto para los que hacen staking solos y también para los que son operadores de nodos de una minipool de 16 ETH. con .

Ejemplos de hardware

Opciones de Hardware

Raspberry Pi

Precio: Bajo costo.

Rendimiento: Es posible ejecutar un nodo de ejecución y consenso en una Raspberry Pi, específicamente, Nimbus, que fue diseñado para ejecutarse en dispositivos como una Raspberry Pi. Poder ejecutar nodos de Ethereum en hardware de baja potencia es excelente para la descentralización y un objetivo honorable, sin embargo, ejecutar un validador es diferente.

Es importante considerar, que la falta de potencia de procesamiento y memoria del Pi es un riesgo en algunas situaciones, como un período sin finalización. La recompensa de ahorrar unos pocos cientos de dólares en comparación con hardware más potente no se acerca siquiera a compensar el riesgo de un tiempo de inactividad prolongado debido a la falta de potencia de procesamiento o memoria.

Consumo energético: aproximadamente 8 watts.

Computadora portátil o de escritorio vieja

Precio: Bajo costo.

CPU: Para hacer stake en la red principal, se recomienda fuertemente una CPU que obtenga una puntuación de al menos 6000 o mejor en Passmark. Para los tiempos de sincronización inicial, el rendimiento de un solo hilo es mejor que tener muchos núcleos.

Memoria: A menos de que utilice un sistema operativo extremadamente básico, se recomienda un mínimo de 16 GB de RAM para la red principal.

Almacenamiento: Se requiere un SSD. No es necesario preocuparse por SATA vs NVMe, ambos serán lo suficientemente rápidos. Comprar uno con una especificación alta de terabytes escritos ayudará con la longevidad. La capa de ejecución y consenso de Ethereum se acerca a 1 TB de tamaño, por lo que se recomienda un disco de 2 TB o más.

Advertencias: La estabilidad y el tiempo de actividad son esenciales para maximizar las ganancias. Si utiliza una computadora de escritorio antigua, considere reemplazar la PSU y los ventiladores. Comprar una PSU de clasificación titanio o platino también ayudará a ahorrar en la factura mensual de electricidad. Si planea hacer stake con una computadora portátil antigua, tenga en cuenta que tienen una capacidad reducida para manejar el calor debido a su factor de forma, y en casos poco frecuentes, ejecutarse mientras está enchufada las 24 horas del día, los 7 días de la semana, puede causar problemas con la batería.

Laptop nueva

Si piensas en adquirir una computadora portátil nueva no es necesario que inviertas en una de muy alta gama, ya que aspectos como la pantalla, el teclado o el trackpad no son necesario una vez que tengas configurada tu máquina de staking. Simplemente puedes conectarte a la máquina de staking de forma remota desde tu ordenador normal. La configuración de perfil bajo en realidad sería una desventaja al tener en cuenta el rendimiento térmico. Por otro lado, los portátiles típicamente no incluyen un puerto ethernet lo que significa que estarás confiando en el WiFi. Esto no debería de representar algún problema, ya que el WiFi es muy confiable ahora, pero no hay nada como la simplicidad y confiabilidad de una conexión directa.

Computadora de escritorio prefabricada.

Esta es probablemente la opción más simple y tiene la ventaja de que se puede ir mejorando en el futuro.

Precio: Mediano costo.

Consumo energético: alrededor de 30 watts.

Computadora de escritorio personalizada

Esto es básicamente lo mismo que usar una preconstruida. Sin embargo, construir su propia computadora de escritorio le da la opción de elegir aspectos aún más personalizables, como un case que le guste y comprar componentes de mayor calidad. Para aquellos de ustedes que nunca han construido una computadora, es más fácil que Lego, porque solo se pueden ensamblar de una manera. Además, no obtendrá piezas extrañas que serán difíciles de reemplazar en caso de que alguna vez fallen. Desafortunadamente, en las computadoras preconstruidas, a veces se hacen concesiones con componentes como la fuente de alimentación para calmar a los contadores y aumentar los márgenes. ¡Puntos de estilo por agregar una tarjeta RAID!

Intel NUC

Precio: Mediano costo.

Consumo energético: 20-25 watts.

Los NUC son muy lindos, y su pequeño factor de forma les da un factor de aprobación significativamente alto. Desafortunadamente, esto viene con un precio un poco más alto y un rendimiento ligeramente inferior que la opción de escritorio más grande. Sin embargo, estas son pequeñas desventajas. Probablemente esta es la mejor opción para la mayoría de las personas.

Servidor

Precio : Alto costo.

Consumo energético: Es bastante considerable, un servidor moderno consume alrededor de 100 watts, uno más antiguo, puede estar alrededor de 150 watts.

Los servidores empresariales están repletos de características y están diseñados específicamente para hacer exactamente lo que un validador intenta hacer: funcionar las 24 horas del día, los 7 días de la semana, los 365 días del año. Tienen fuentes de alimentación redundantes en caso de que una se rompa, en su mayoría tienen 2 CPUs, por lo que en el improbable caso de que una falle, puedes sacarla y reiniciar con solo una.

Por otro lado, tienen tarjetas RAID incorporadas para que puedas tener almacenamiento redundante. Tienen bandejas de unidades intercambiables en caliente, por lo que si una de tus unidades falla, ni siquiera necesitas apagarlo. Todos los componentes son de alta calidad y están diseñados para durar. También obtienes herramientas de monitoreo y mantenimiento que no se incluyen en el equipo de consumo como iDRAC e iLo.

Definitivamente, señalaría que, si bien los servidores son excelentes para el staking, es mejor que optes por adentrarte adentrarse un poco en el tema y geek out. Se requiere cierta investigación para saber lo que estás buscando antes de salir a comprar un servidor y existe la posibilidad de que te encuentres con un problema técnico extraño que tendrás que solucionar.

Precio: Mediano costo

Rendimiento: El DAppNodeXtreme es una buena opción si buscas un sistema operativo personalizado con una UX fácil. Un DAppNode box es solo un NUC preconfigurado con su software. Si tienes suficiente confianza para instalar un sistema operativo por ti mismo, puedes ahorrar un poco de dinero comprando un NUC normal e instalando DAppNode tú mismo. También puedes instalar el sistema operativo DAppNode en cualquier computadora. Si no quieres lidiar con la instalación de sistemas operativos y buscas una UX fácil, comprar un DAppNode box es una forma conveniente y simple de comenzar.

Consumo energético: 20-25watts.

Avado es una solución fácil para realizar staking desde casa para personas con conocimientos técnicos limitados o poco tiempo. Los dispositivos Avado vienen preconfigurados con una interfaz de usuario amigable que permite usar y administrar el dispositivo desde cualquier parte del mundo.

Usar un Avado es conveniente, seguro y fiel al espíritu de la descentralización.

Precio: Mediano costo.

Rendimiento: Definitivamente actualiza a 16GB de memoria. La CPU será más que suficientemente rápida con una puntuación de 15.108 en PassMark. Asegúrate de obtener 2TB o más de almacenamiento, ya que la memoria y el almacenamiento interno están integrados en la placa base y requieren soldadura y conocimientos técnicos avanzados para actualizarlos.

Definitivamente actualice a 16GB de memoria. La CPU será lo suficientemente rápida con una puntuación de aprobación de 15,108. Asegúrese de tener un plan para obtener al menos 2TB o más de almacenamiento, la memoria interna y el almacenamiento están integrados en la placa base y requieren soldadura y avanzados conocimientos técnicos para actualizarlos.

Consumo energético: Ligeramente menor que el NUC, pero no lo suficiente para marca alguna diferencia real.

Importante! No es posible ejecutar Linux en la nueva arquitectura ARM que utiliza. Es más caro que el NUC y también carece de actualizabilidad y facilidad de servicio, pero para los fanáticos de Mac OS, esta es una gran opción que funcionará muy bien.

Servidor virtual privado (VPS)

Precio: Alrededor de entre $20 - $50 por mes.

Rendimiento: Es directamente proporcional a la cantidad que puedas permitirte adquirir.

Si vives en algún lugar propenso a desastres naturales o tienes una red eléctrica o conexión a internet inestable pero aún quieres hacer solo staking, esta es una buena opción. Si tienes un servicio electricidad e internet estables, ejecutar tu propio hardware sería una solución más barata y rentable a largo plazo. Debes evaluar los pros y los contras de esto para tu propia situación. Recuerda que si uno de los proveedores de VPS falla, significará que todas las personas que usan ese servicio de VPS también se verán afectadas, y las penalizaciones por inactividad serán mucho mayores que si tienes tiempos de inactividad no correlacionados por ti mismo.

Para proteger tu servidor de intentos de conexión brute-force en SSH, puedes instalar fail2ban.

Este programa supervisará las conexiones entrantes y bloqueará las direcciones IP que intenten iniciar sesión repetidamente con credenciales incorrectas.

Puedes modificar la configuración de maxretry que es el número de intentos permitidos antes de bloquear la dirección ofensiva.

Guarda el archivo y reinicia el servicio.

¡Felicitaciones! Has mejorado con éxito la seguridad de tu nodo 🥳

Un firewall es un mecanismo de seguridad que supervisa las conexiones de red entrantes y salientes y puede aceptar o rechazar el tráfico basándose en un conjunto de reglas configurables. Se recomienda fuertemente tener uno configurado para mejorar la seguridad de la configuración de su nodo validador.

Existen dos tipos de firewalls:

Software firewalls

Los software firewalls se ejecutan en la máquina individual y la protegen de otros dispositivos dentro de la red local en la que se encuentra.

Se recomienda descartar todo el tráfico por defecto y establecer reglas individuales que lo permitan cuando sea necesario, de forma que el tráfico sólo pueda entrar en la máquina en la que está explícitamente permitido.

Por ejemplo, si ejecutas tu cliente de ejecución y cliente de consenso en máquinas diferentes, puedes configurar una regla de firewall en tu nodo de ejecución para que sólo permita el tráfico en el puerto 8551 desde la dirección IP de tu nodo de consenso. Si estás ejecutando Ubuntu Server, un firewall ya estará instalado por defecto bajo (inglés), sólo tendrás que configurarlo y habilitarlo. Si estás ejecutando Geth y Prysm y tienes el software funcionando en diferentes máquinas, podrías establecer la siguiente configuración.

Ejecución (Asumiendo Geth con IP 192.168.1.50)

Consenso (Asumiendo Prysm con IP 192.168.1.51)

Desde aquí se pueden desbloquear puertos adicionales como SSH, la API HTTP de consenso (si también está ejecutando su validador en otra máquina) o la API RPC de ejecución (si desea interactuar con la red Ethereum utilizando su propio nodo).

Hardware firewalls

Hardware firewalls are run on dedicated devices (Usually your router) and can manage traffic both within networks and between networks.

One way to really fortify your setup is to configure a dedicated subnet on your router solely for your nodes/validators and have the firewall drop traffic from any other subnet from reaching this subnet (Also known as blocking all RFC 1918 traffic)

Should your regular everyday computer (Or any other device on your network) become compromised, the infiltrator won't even know about your nodes as they are sitting on another subnet that is completely blocked off.

Los hardware firewalls se ejecutan en dispositivos dedicados (normalmente el router) y pueden gestionar el tráfico tanto dentro de las redes como entre ellas.

Una forma de fortalecer su configuración es configurar una subred dedicada en su router únicamente para sus nodos/validadores y hacer que el cortafuegos impida que el tráfico de cualquier otra subred llegue a esta subred (también conocido como bloqueo de todo el tráfico RFC 1918).

Si su ordenador (o cualquier otro dispositivo de su red) se ve comprometido, el infiltrado ni siquiera sabrá de la existencia de sus nodos, ya que éstos se encuentran en otra subred que está completamente bloqueada.

Ethereum es una red peer-to-peer (P2P) con miles de nodos que deben ser capaces de comunicarse entre sí utilizando protocolos estandarizados. La "capa de red" es el conjunto de protocolos que permiten que esos nodos se encuentren y intercambien información. Esto incluye la difusión de información ("gossiping") de uno a muchos a través de la red, así como el intercambio de solicitudes y respuestas entre nodos específicos de uno a uno. Cada nodo debe cumplir con reglas de red específicas para asegurarse de que está enviando y recibiendo la información correcta.

El software del cliente se divide en dos partes (clientes de ejecución y clientes de consenso), cada una con su propio conjunto de protocolos de red distintos. Además de comunicarse con otros nodos de Ethereum, los clientes de ejecución y de consenso deben comunicarse entre sí. Esta página brinda una explicación introductoria de los protocolos que permiten esta comunicación.

Los difunden transacciones a través de la red peer-to-peer de la capa de ejecución. Esto requiere comunicación encriptada entre pares autenticados. Cuando se selecciona a un validador para proponer un bloque, las transacciones registradas localmente en el nodo se envian a los clientes de consenso a través de una conexión RPC local, que se empaquetarán en bloques Beacon.

Posteriormente, los difunden los bloques Beacon a través de su red p2p. Esto requiere dos redes p2p separadas: una que conecta clientes de ejecución para la difusión de transacciones y otra que conecta clientes de consenso para la difusión de bloques.

Es muy importante que reenvíe los puertos (port forwarding) a sus clientes de ejecución y consenso de Ethereum, esto asegura que pueda conectarse con otros nodos de manera eficiente.

Su cliente de ejecución y consenso seguirá funcionando sin el reenvío de puertos, pero puede notar que tardará mucho tiempo en encontrar pares, y también puede tener problemas para conectarse con un número significativo de ellos. Así que es en su mejor interés (y muy recomendable) configurarlo para reenvíos.

A continuación se muestra una lista de los puertos por defecto que el software está configurado para escuchar.

Si tu nodo está corriendo y los puertos han sido redireccionados, puedes usar una herramienta online para comprobar si los puertos han sido redireccionados correctamente.

Para más información sobre cómo redirigir los puertos, lo mejor es buscar instrucciones en google, asegúrate de incluir la marca y el modelo de tu router, ya que los pasos específicos para redirigir los puertos variarán en función de tu router.

IP estáticas

También se recomienda configurar el nodo con una IP estática. Esta puede estar codificada en la propia máquina o configurada como una reserva en tu servidor DHCP (que normalmente es tu router).

Si a tu nodo se le asigna una dirección IP dinámica, siempre existe la posibilidad de que a tu máquina se le asigne una dirección IP diferente y el reenvío de puertos deje de funcionar, ya que apuntarán a la IP antigua.

Lectura adicional: (Inglés)

La comunidad de Ethereum mantiene varios clientes de ejecución de código abierto (anteriormente conocidos como 'clientes Eth1' o simplemente 'clientes de Ethereum'), desarrollados por diferentes equipos, utilizando diferentes lenguajes de programación. Esto hace que la red sea más fuerte y diversa. El objetivo ideal es lograr diversidad sin que ningún cliente domine, para reducir cualquier punto único de falla.

Geth

Go Ethereum (Geth, abreviado) es una de las implementaciones originales del protocolo de Ethereum. Actualmente, es el cliente más extendido, con la mayor base de usuarios y variedad de herramientas tanto para usuarios como para desarrolladores. Está escrito en Go, es completamente código abierto y tiene licencia bajo GNU LGPL v3.

Besu

Besu Hyperledger Besu es un cliente de Ethereum de nivel empresarial para redes públicas y con permisos. Ejecuta todas las características de Ethereum Mainnet, desde el seguimiento hasta GraphQL, tiene un amplio monitoreo y cuenta con el respaldo de ConsenSys, tanto en canales comunitarios abiertos como a través de SLAs comerciales para empresas. Está escrito en Java y tiene licencia Apache 2.0.

Besu tiene una extensa documentación que te puede servir de guía a través de todos los detalles sobre sus características y configuraciones.

Nethermind

Nethermind Nethermind es una implementación de Ethereum creada con el stack tecnológico de C# .NET, con licencia LGPL-3.0, que se ejecuta en todas las principales plataformas, incluyendo ARM. Ofrece un excelente rendimiento con:

• Una máquina virtual optimizada.

• Acceso al estado.

• Redes y características avanzadas como paneles de control Prometheus/Grafana, soporte de registro empresarial seq, trazado de JSON RPC y complementos de análisis.

Erigon

Erigon, anteriormente conocido como Turbo-Geth, comenzó como una bifurcación de Go Ethereum orientada a la velocidad y eficiencia del espacio en disco. Erigon es una implementación completamente reestructurada de Ethereum, escrita actualmente en Go pero con implementaciones en otros lenguajes en desarrollo. El objetivo de Erigon es proporcionar una implementación de Ethereum más rápida, modular y optimizada. Puede realizar una sincronización completa de nodo de archivo utilizando alrededor de 2TB de espacio en disco en menos de 3 días.

La sincronización de checkpoints, también conocida como sincronización de subjetividad débil, ofrece una experiencia de usuario superior para sincronizar el Beacon Node. Se basa en suposiciones de subjetividad débil↗, lo cual permite sincronizar la Beacon Chain desde un punto de control reciente en lugar de hacerlo desde el génesis. La sincronización de puntos de control acelera significativamente el tiempo de sincronización inicial con suposiciones de confianza similares a las de la sincronización desde el génesis.

En la práctica, esto significa que tu nodo se conecta a un servicio remoto para descargar estados finalizados recientes y continúa verificando los datos a partir de ese punto. Para esto es importante confiar en que los terceros proporcionen los datos correctos sobre la información correcta sobre los estados que fueron finalizados, por lo que es necesario tener cuidado con la elección del proveedor.

Validar con una fuente confiable conocida

Debes validar el slot y el state_root contra una fuente conocida y confiable. Esto puede ser un amigo, alguien de la comunidad que conozcas o cualquier otra fuente en la que confíes. Existe una lista mantenida de puntos finales de sincronización de checkpoints alojados públicamente aquí↗, pero se recomienda usar tu propia fuente confiable en primer lugar, si es posible.

Es importante que conozcas la dirección IP y el puerto de tu nodo beacon.

Obtener el número de slot y el valor de state

Opción A:

1. Verifica los registros de tu cliente de consenso.

2. Encuentra el número de slot.

3. Encuentra el valor de state root.

Opción B:

1. Ingresa http://YOUR_NODE_IP:YOUR_NODE_PORT/eth/v1/beacon/headers/finalized en tu buscador

2. Encuentra el número de slot.

3. Encuentra el valor de state root.

Opción C:

1. Instala curl y jq.

2. En una ventana de terminal nueva, ejecuta:

   Copy

   curl -s http://YOUR_NODE_IP:YOUR_NODE_PORT/eth/v1/beacon/headers/finalized | jq .'data.header.message'

Si el número de sloty el valor de state_root de tu validador coinciden con el número de slot y el valor de state_root de múltiples fuentes confiables, entonces es una coincidencia exitosa. ¡Felicitaciones! 🎉

Sin embargo, si los valores de slot y state_root no coinciden, se recomienda comenzar desde cero borrando tu nodo de la Beacon Chain y reiniciando el proceso de sincronización desde el principio.

Detalles técnicos sobre la sincronización de los puntos de control↗

Debilidades subjetivas↗

Protección de cortes Lighthouse

El cliente del validador Lighthouse incluye un mecanismo para proteger sus validadores contra cortes accidentales, conocido como la base de datos de protección contra cortes. Esta base de datos registra cada bloque y atestación firmada por los validadores, y el cliente del validador usa esta información para evitar firmar mensajes que se pueden recortar..

Documentacion sobre cortes Lighthouse ↗

Información y guías de MEV Boost

• Beaconcha.in Relays ↗

• CoinCashew MEV-boost guide ↗

• Flashbots docs ↗

• Flashbots GitHub ↗

• Inclusion Watch ↗

• mevboost.org ↗ - Tracker con estadísticas en tiempo real para relays MEV-Boost y builders de bloques.

• mevboost.pics ↗

• MEV-Explore ↗ - Dashboard y explorador de transacciones en vivo para transacciones MEV.

• MEV Panda ↗

• MEV relay list ↗

• MEV Watch ↗

• Rated Network ↗

• Relay Monitor ↗

• Relay Scan ↗

• Tornado Warnings ↗

• Transparency dashboard ↗

• Uptime Monitor ↗

Esta es una lista de guías de apuestas de alta calidad que se recomiendan en ethereum.org ↗:

• CoinCashew's Ethereum 2.0 Guide - Linux (CLI) ↗

• Somer Esat - Linux (CLI) ↗

• Rocket Pool Node Operators - Linux, macOS (CLI) ↗

Es de vital importancia para la salud y la sostenibilidad a largo plazo de Ethereum que haya un ecosistema de clientes diverso y equilibrado. Existen varios clientes desarrollados y mantenidos de forma independiente porque la diversidad de clientes hace que la red sea más resistente a los ataques y los errores. Múltiples clientes es una fortaleza exclusiva de Ethereum; otras cadenas de bloques se basan en la infalibilidad de un solo cliente. Sin embargo, no es suficiente simplemente tener varios clientes disponibles, deben ser adoptados por la comunidad y el total de nodos activos distribuidos de manera relativamente uniforme entre ellos.

Considere ejecutar un cliente minoritario para admitir Ethereum.

Puede encontrar más información sobre la diversidad de clientes en ethereum.org ↗

Para servir como validador, tanto el Cliente de Consenso (CL) como el Cliente de Ejecución (EL) deben estar actualizados con la red. Hay un par de técnicas para comprobarlo.

Todos estos datos de verificación de salud deberían conducir a una herramienta de monitoreo de su elección.

Comprobación de salud interna

La mayoría de los nodos tienen API de verificación de estado expuestas, que devuelven HTTP 5xx si el nodo no se sincroniza correctamente y HTTP 200 OK si todo está bien. Esa es la versión más simple y básica del chequeo de salud.

Comprobación de marcas de tiempo

Una estrategia más se basa en la marca de tiempo (timestamp) del último bloque.

Para el EL es una respuesta a eth_getBlockByNumber("latest", false).

Tiene un campo llamado timestamp. Al conocer el timestamp de un bloque y la tasa de producción de bloques (1 bloque por 12 segundos), es posible ver qué tan "antiguo" es el bloque actual del nodo.

Dado que a veces se pueden pasar por alto las propuestas de bloque, no tiene sentido mantener este umbral demasiado ajustado, pero si tiene más de 5 minutos, tiene sentido marcar el nodo como "no saludable" y notificar a su herramienta de monitoreo.

Comprobación de la fuente de la verdad (Forks)

Finalmente, el caso cuando los bloques se sincronizan, pero estás en la bifurcación incorrecta. La detección de eso podría ocurrir en el EL muy fácilmente, usando el hash de bloque devuelto poreth_getBlockByNumber("latest", false).

Puede comparar estos hashes entre los nodos y también entre las fuentes externas de verdad.

It’s easy to just set thresholds to every possible monitored metric and add an alarm to it. But that could lead to fatigue, distractions, and also ignoring alerts, see Las alertas deben ser muy específicas. Es fácil simplemente establecer umbrales para cada métrica monitoreada posible y agregarle una alarma. Pero eso podría provocar fatiga, distracciones y también ignorar alertas, consulte este articulo para obtener más detalles.

Las alertas nunca deben ignorarse, incluso si cree que tiene una idea de qué las causó.

Para obtener buenos consejos sobre las alertas en general, consulte “My Philosophy on Alerting”.

Herramientas Saas

• Pager Duty

• VictorOps

On-Call

Hay una práctica en cada servicio en la nube, llamada "estar de guardia". Eso significa que, en algún momento, hay una persona responsable de reaccionar ante las alertas, independientemente de cuándo sucedan.

Eso significa estar listo para actuar en medio de la noche, los fines de semana, etc. Esa es una posición tediosa y agotadora, por lo que es mejor rotar a las personas con frecuencia en eso.

Un ejemplo de la política de guardia se puede encontrar en este GitLab On-Call Handbook.

Respuesta al incidente

¿Qué buscar primero?

1. ¿Está el nodo en funcionamiento? ¿El cliente del validador está funcionando? ¿CPU/RAM/espacio en disco está bien?

2. Lea los registros. ¿Hay suficientes peers? ¿El número de validadores encontrado por el cliente del validador es el esperado?

3. ¿Está su nodo sincronizado/se está sincronizando? Si es así, ¿está en el fork correcto ? Tome /v1/beacon/headers/head API y verifíquelo con cualquier explorador de bloques público o en una comunidad.

4. ¿Se está finalizando la red? eth/v1/beacon/headers/finalized API -- debe moverse cada 6,2 minutos.

Fugas de inactividad

La fuga de inactividad significa que su nodo fue elegido para realizar una determinada tarea (certificar el cabezal de la cadena o producir un bloque) y no hizo su trabajo a tiempo.

Las fugas de inactividad tienen penalizaciones relativamente pequeñas. Degradarán el rendimiento del Validador en términos de rendimiento anual. Eso significa que tiene alguna opción sobre cómo manejarlos:

1. Reaccione lo antes posible: utilícelo si tiene un equipo de DevOps adecuado y desea optimizar el rendimiento del nodo y el mejor APY posible. Asegurar rotaciones regulares en el equipo de guardia.

2. Reaccione solo durante el "horario comercial", pero los fines de semana, solo notifique, digamos, de 9:00 a 21:00 todos los días. Eso reduce en gran medida la tensión en el personal de guardia.

3. Reaccione solo durante el horario comercial, igual que (2), pero no notifique los fines de semana.

Retrasos en las certificaciones (rendimiento subóptimo del nodo)

Largos tiempos de procesamiento de bloques

Incidentes de seguridad

Posibles ataques de red

¿A qué canales comunicarse si cree que se trata de un ataque a la red?

Posible vulnerabilidad

¿A qué canales comunicarse si se trata de una posible vulnerabilidad?

TBD

• Explicación de las alertas básicas que deben incorporar (slots retrasados, baja tasa de participación, tiempos de procesamiento de bloques, etc.)

• ¿Por cuánto tiempo almacenar los datos?

• Recomendación genérica sobre mejores prácticas de alertas/métricas

Respuesta al incidente

¿Qué buscar primero? ¿Cuándo da la alarma? Primeros pasos requeridos durante la respuesta a la incidencia.

Aunque tengas un disco SSD grande instalado, hay casos en los que Ubuntu solo reporta 200GB de espacio disponible, causando que el sistema se quede sin espacio de disco cuando está sincronizando.

El mensaje de error es similar a:

Fatal: Failed to register the Ethereum service: write /var/lib/goethereum/geth/chaindata/383234.ldb: no space left on device

Para corregir este asunto, asumiendo que tienes un SSD con mayor capacidad de 200GB, expande la asignación de espacio a la LVM siguiendo los siguientes pasos:

sudo lvdisplay # Check your logical volume size

sudo lvm # Attach the lvm console
lvextend -l +100%FREE /dev/ubuntu-vg/ubuntu-lv
lvextend -l +100%FREE -r /dev/ubuntu-vg/ubuntu-lv
exit

sudo resize2fs /dev/ubuntu-vg/ubuntu-lv
df -h # Check results

¡Enhorabuena! Ahora estás usando todo el espacio disponible en el disco para tu maquina de staking. 🥳

La efectividad de un validador se puede entender como la utilidad de una attestation para la red, eniendo en cuenta tanto la producción de bloques como la idistancia de inclusión.

Proceso de inclusión de attestations

¿Cómo se incluyen las attestations en la red de Ethereum? En grandes rasgos el proceso es el siguiente:

Esta es una visión simplificada de la attesting, pero puede ser un buen punto de partida.

1. Cada validador que realiza una attestation genera datos sobre el estado de la cadena.

2. La attestation se propaga por la red de Ethereum hacia los agregadores aggregators relevantes.

3. Cada agregador relevante que recibe la attestation la agrega con otras attestations que tienen las mismas reclamaciones.

4. La attestation agregada se propaga por la red de Ethereum a todos los nodos.

5. Cualquier validador que esté proponiendo un bloque y aún no haya visto la attestation agregada en la cadena, la añade al bloque.

Cuando una attestation tiene una distancia de inclusión mayor que 1, es importante entender por qué. Hay varias razones posibles:

Retraso en la generación de attestation

Un validador puede tener problemas que resulten en un retraso en la generación de la attestation. Por ejemplo, puede tener información desactualizada sobre el estado de la cadena, o el validador puede tener poca potencia y tardar un tiempo significativo en generar y firmar la attestation. Independientemente de la razón, una attestation retrasada tiene un efecto potencial en los pasos restantes del proceso.

Retraso en la generación de la attestation agregada

Una vez que un validador ha generado una attestation, esta debe propagarse a través de la red hasta los agregadores. La naturaleza de este proceso implica que una propagación temprana es crucial para asegurar que la attestation sea recibida por un agregador a tiempo para su integración en la attestation agregada antes de su difusión. Los validadores deben asegurarse de estar conectados con suficientes pares variados para garantizar una propagación rápida hacia los agregadores.

Retraso en la propagación de la attestation

Un aggregator puede retrasar el proceso de agregación de las attestations. Esto ocurre con mayor frecuencia cuando el nodo ya está sobrecargado debido a la generación de attestations, pero también puede deberse a la velocidad del algoritmo de agregación cuando hay un gran número de validadores que deben ser agregados.

Retraso en la propagación de la attestation agregada

Al igual que con el retraso en la propagación de la attestation, la attestation agregada también debe circular por la red y puede sufrir los mismos retrasos.

Fallo en la producción de bloques

Para que una attestation se convierta en parte de la cadena, debe ser incluida en un bloque. Sin embargo, la producción de bloques no está garantizada. Un bloque puede no ser producido porque un validador está fuera de línea o está desincronizado con el resto de la red, lo que resulta en la producción de un bloque con datos inválidos que es rechazado por la cadena. Sin un bloque, no hay forma de incluir la attestation en la cadena en ese slot, lo que resulta en una distancia de inclusión mayor a la óptima.

El fallo en la producción de bloques tiene un segundo impacto, que es el aumento del número total de attestations elegibles para ser incluidas en el próximo bloque que se produce. Si hay más attestations disponibles de las que pueden caber en un bloque, es probable que el productor incluya las attestations que ofrecen la mayor recompensa, es decir, aquellas con la menor distancia de inclusión. Esto puede resultar en que las attestations que no lograron su bloque óptimo también pierdan los bloques posteriores debido a que se vuelven menos atractivas para su inclusión.

El hecho de que la producción de bloques esté fuera del control del validador (excepto en los bloques que el validador mismo produce) requiere la definición del término "earliest inclusion slot" (slot de inclusión más temprano), donde el earliest inclusion slot es el primer slot mayor que el slot de la attestation en el que se produce un bloque válido. Esto toma en cuenta el hecho de que las attestations no pueden ser incluidas en bloques que no existen y no refleja la efectividad del validador.

Actividad maliciosa

Es posible que una persona malintencionada se niegue a incluir cualquier attestation en sus agregados, o a incluir attestations en sus bloques. La primera situación se mitiga al tener varios agregadores para cada grupo de attestations, y la segunda se por el costo de excluir una attestation agregada. Sin embargo, en última instancia, si el costo de excluir una attestation de un bloque es compensado económicamente o se considera que tiene un valor político más alto, no hay nada que un validador que realiza attestation pueda hacer para forzar su inclusión por parte de un validador que produce bloques.

Calculating Attestation Effectiveness

El cálculo de la efectividad de una attestation se puede entender como qué tan útil es para la red, teniendo en cuenta tanto la producción de bloques como la distancia de inclusión. Se define formalmente como:

(earliest inclusion slot - slot de la attestation) / (slot de inclusión real - slot de la attestation)

La efectividad se representa como un valor porcentual. Una attestation que no logra ser incluida con la máxima distancia de inclusión de 32 se considera que tiene una efectividad de 0. Aquí tienes algunos ejemplos de cálculos de efectividad:

Efectividad de la attestation agregada

La efectividad de una única attestation es interesante pero no es muy útil por sí sola. Al calcular la efectividad agregada de múltiples attestations, tanto a lo largo del tiempo como entre múltiples validadores, se obtiene una visión más precisa de la efectividad general de un grupo de validadores. La efectividad agregada se puede calcular como un promedio simple de la efectividad individual de las attestations, por ejemplo, un promedio móvil de 7 días que abarque a todos los validadores en un grupo determinado.

Source ↗

Nota: Este artículo asume que ya está familiarizado con todos los componentes involucrados en los nodos de Ethereum

La implementación de actualizaciones de software es una tarea de operación común. A menudo se pasa por alto durante la ampliación del servicio. Asegurarse de que la nueva versión se implemente a tiempo es particularmente importante para ejecutar la infraestructura de Ethereum o blockchain en general porque:

• Las nuevas actualizaciones y forks solo son compatibles con la nueva versión; si no lo hace a tiempo, el nodo dejará de sincronizarse o producirá bloques no válidos. En el peor de los casos, hará que los validadores se desconecten y reciban penalizaciones.

• Las nuevas versiones pueden contener parches de seguridad. Reforzará la red y su sistema, previniendo pérdidas financieras o de datos.

Si bien es crucial comprender la importancia de las actualizaciones de software oportunas, también es esencial reconocer los desafíos asociados con su implementación efectiva. En la siguiente sección, analizaremos las dificultades de mantener el software actualizado a escala y las mejores prácticas para superar estos obstáculos.

Desafíos

Desafíos técnicos

La gestión de actualizaciones de software se vuelve cada vez más compleja a medida que crece la cantidad de nodos y clientes en una red. Cuando se opera a escala, los desafíos, como los cambios bruscos en las configuraciones y los errores recién introducidos, pueden afectar significativamente el proceso de actualización. Además, la actualización en entornos de producción es más difícil debido a la necesidad de minimizar el tiempo de inactividad.

Desafíos no técnicos

Aparte de los problemas técnicos, varios desafíos no técnicos pueden dificultar el proceso de actualización:

• Despriorización: as actualizaciones de software a menudo se pueden considerar buenas y no esenciales, lo que genera software obsoleto y posibles vulnerabilidades de seguridad.

• Diferentes esquemas de control de versiones: Los esquemas de control de versiones incoherentes entre clientes pueden complicar el proceso de actualización y aumentar la probabilidad de errores.

• Demasiadas versiones de software para rastrear: Supervisar y administrar numerosas versiones de software que requieren actualizaciones periódicas puede ser una tarea abrumadora, especialmente en entornos a gran escala con múltiples nodos y clientes.

Si bien estos desafíos pueden parecer abrumadores, la adopción de estrategias, procesos y mejores prácticas efectivos puede optimizar el proceso de actualización del software. En las siguientes secciones, analizaremos las posibles soluciones para abordar los desafíos que enfrentan los operadores de validadores de Ethereum durante las actualizaciones de software.

Soluciones

1. Mantenga un inventario de lo que tiene en el sistema

Si aún no lo ha hecho, considere realizar un seguimiento de sus implementaciones y configuraciones en un repositorio de Git o adoptar prácticas de GitOps para optimizar el control de versiones y la coherencia.

Un inventario de software es un registro completo de todos los componentes de software dentro de su sistema, incluidas las implementaciones, versiones y configuraciones del cliente. Mantener un inventario de software actualizado es crucial para las actualizaciones de software exitosas, ya que lo ayuda a planificar y ejecutar mejor las actualizaciones al tiempo que minimiza el riesgo de problemas inesperados. Los siguientes enfoques pueden ayudarlo a lograr un inventario de software bien organizado:

• Métricas: Muchos clientes exponen la información de la versión a través de sus métricas de Prometheus, lo que simplifica la creación de un panel de Grafana que muestra la información de la versión para todas sus cargas de trabajo. Al visualizar estos datos, puede monitorear fácilmente las versiones de software e identificar cualquier discrepancia que pueda requerir atención.

• Herramientas Third-party: Aproveche las herramientas de terceros para ayudar a administrar su inventario de software. Hay muchas herramientas de código abierto disponibles para generar informes de inventario. Si está usando Kubernetes, puede usar Kubernetes Inventory Docker image or Anchore's k8s-inventory para ayudarlo a rastrear las versiones del cliente en sus implementaciones.

• Solución interna: Desarrolle una solución interna personalizada adaptada a sus necesidades específicas, como un simple script de shell. La creación de una solución que se ajuste a los requisitos de su organización permite una integración perfecta con sus sistemas y procesos existentes. Develop a custom in-house solution tailored to your specific needs, such as a simple shell script. Creating a solution that fits your organization's requirements allows for seamless integration with your existing systems and processes.

2. Manténgase informado sobre los nuevos lanzamientos de software

Para mantener su software actualizado, es esencial mantenerse informado sobre las últimas versiones y mejoras. La mayoría de los proyectos de software publican nuevos lanzamientos en GitHub, lo que lo convierte en un punto de partida ideal para suscribirse a eventos de nuevos lanzamientos para todos los clientes que usa. Hay varias herramientas y servicios disponibles para ayudarlo a lograr esto:

• Suscripción integrada de GitHub: use la función de suscripción nativa en GitHub para recibir notificaciones sobre nuevos lanzamientos de sus repositorios seguidos.

• NewReleases.io: NewReleases.io es un servicio útil que le permite realizar un seguimiento de los nuevos lanzamientos en varias plataformas, incluido GitHub.

• Otras alternativas: Explore servicios alternativos para monitorear nuevos lanzamientos de software y elegir el que mejor se adapte a sus necesidades.

Alternativamente, puede desarrollar un bot personalizado adaptado a sus requisitos para realizar un seguimiento de los nuevos lanzamientos y mantenerse informado sobre las últimas actualizaciones.

3. Plan para actualizaciones de software

La planificación adecuada es crucial para la ejecución fluida de las actualizaciones de software. Al incorporar la planificación de actualizaciones de software en su proceso de gestión de proyectos, puede garantizar una implementación oportuna, abordar el riesgo de pérdida de prioridad y mitigar posibles problemas técnicos debido a más tiempo para investigar y prepararse.

• Asegúrese de hablar sobre las actualizaciones de software en la sesión de planificación: por ejemplo, si su equipo usa Scrum y realiza la planificación cada dos semanas, asigne 20 minutos solo para revisar todas las nuevas versiones de software. Esta práctica ayudará a garantizar que las actualizaciones se prioricen y se completen dentro del marco de tiempo designado.

• Verifique los plazos y los cambios importantes: cuando revise los lanzamientos, asegúrese de verificar los plazos asociados con las actualizaciones de software, como bifurcaciones duras o parches de seguridad, y planifique en consecuencia. Además, examine las notas de la versión para conocer los cambios importantes que pueden requerir trabajo adicional o ajustes a sus configuraciones existentes. Tenga en cuenta que algunos cambios, como las actualizaciones de la base de datos, pueden ser irreversibles y deben implementarse con cuidado.

4. Automatice el proceso de actualización de software

La automatización puede agilizar significativamente el proceso de actualización de software, minimizando el riesgo de error humano y reduciendo el tiempo necesario para completar la actualización. La implementación de la automatización en su proceso de actualización puede aumentar la eficiencia y garantizar que las actualizaciones se apliquen de manera consistente. Estas son algunas tareas de ejemplo que pueden beneficiarse de la automatización:

• Pull requests automatizados: utilice herramientas o scripts que crean automáticamente pull requests cuando se detectan nuevas versiones de software, actualizando la definición de implementación en consecuencia. Este enfoque garantiza que su sistema se mantenga actualizado con las últimas versiones de software y reduce el esfuerzo manual necesario para iniciar las actualizaciones.

• Rollout y rollback automatizados: Utilice herramientas como Argo Rollouts para definir los criterios de aceptación y lanzar nuevas versiones automáticamente. Este método es particularmente útil si necesita varias horas para confirmar el éxito de cada implementación. Además, estas herramientas a menudo brindan capacidades de reversión integradas, lo que garantiza que su sistema pueda recuperarse rápidamente de cualquier problema que surja durante el proceso de actualización.

Al incorporar la automatización en su estrategia de actualización de software, puede mejorar en gran medida la eficiencia y confiabilidad general de su proceso de actualización, asegurando que sus nodos Ethereum permanezcan seguros y actualizados.

Conclusión

Mantener el software actualizado requiere compromiso y es una parte esencial del funcionamiento de una infraestructura blockchain segura y estable, como Ethereum. Al comprender los desafíos asociados con las actualizaciones de software e implementar soluciones efectivas, como mantener un inventario de software preciso, mantenerse informado sobre nuevos lanzamientos, planificar actualizaciones y automatizar el proceso de actualización, puede garantizar actualizaciones de software oportunas y exitosas.

Estas herramientas se pueden utilizar como una alternativa a la Staking Deposit CLI ↗ para ayudar con la generación de claves.

Fuente↗

Si estás fuera de casa durante largos períodos de tiempo, este tutorial es para ti!

Pregunta: ¿Por qué debo configurar un servidor VPN? No es más fácil simplemente reenviar los puertos y conectarse?

Respuesta-Un servidor VPN introduce otra capa de seguridad. Para conectarte a tu nodo a través de SSH, primero tienes que conectarte a un VPN y luego hacer SSH a tu nodo. Esto introduce otra barrera y hace que las intrusiones sean mucho más difíciles.

Requisitos

• Necesitarás una dirección IP pública estática o un DNS para tu red doméstica.

• Este tutorial asume que tienes instalado y funcionando Ubuntu Server 22.04 LTS. ¡Si no lo tienes, no te preocupes! Puedes consultar en el siguiente enlace un tutorial sobre cómo hacerlo.

Recomendaciones

• Por motivos de seguridad, recomiendo configurar el servidor VPN en una máquina separada que no sea su máquina de validación. Esto incluso puede ser una máquina virtual.

Ya teniendo presente lo anterior, empecemos!

Paso 1 ) Ejecute los comandos para asegurarse de que su máquina esté actualizada.

Inicie sesión en la máquina y autentíquese como superusuario usando el siguiente comando:

sudo -i

Ahora ejecute el siguiente comando para asegurarse de que el sistema operativo y los paquetes estén actualizados. Actualice cualquier paquete que no lo esté.

apt-get update && apt-get upgrade

Paso 2) Instalar las necesidades de OpenVPN.

Para ello, ejecute el siguiente comando:

apt-get install ca-certificates wget net-tools gnupg

Step 3) Importe la clave GPG de OpenVPN y agregue el repositorio oficial..

Ejecute los siguientes tres comandos:

• Este comando cargará la clave pública CPG de OpenVPN.

curl -fsSL https://as-repository.openvpn.net/as-repo-public.gpg | gpg --dearmor > /etc/apt/trusted.gpg.d/as-repo-public.gpg

• Este comando añadirá el repositorio de OpenVPN en su dispositivo.

echo "deb http://as-repository.openvpn.net/as/debian jammy main">/etc/apt/sources.list.d/openvpn-as-repo.list

• Este último revisará las actualizaciones en todos los repositorios utilizados.

apt-get update

Paso 4) Instalar el servidor de acceso OpenVPN

¡Ahora comienza la diversión! Para instalarlo, ejecuta el siguiente comando:

apt-get install openvpn-as

¡Hurra! Acabas de instalar el servidor de acceso OpenVPN. Presta atención a esta parte de la depuración, ya que contiene información valiosa.

La interfaz de administración (Admin UI) se utiliza para realizar cambios en la configuración del servidor y agregar usuarios.

La interfaz de cliente (Client UI) es para tus dispositivos, aquí podrás descargar perfiles/certificados de usuario. Esa parte la haremos más adelante.

Paso 5) Configurando el servidor para el acceso remoto.

Navega a la URL de la interfaz de administración. Es posible que recibas una advertencia de certificado, pero puedes ignorarla de forma segura y continuar. Una vez completado, verás la siguiente interfaz de usuario (UI).

Por favor, inicia sesión, lee y acepta el Acuerdo de Licencia de Usuario Final (EULA) y estaremos listos para continuar.

Necesitamos realizar algunos cambios en la red, para ello, dirígete a Configuración > Configuración de Red.

Paso 5.1) - Cambiar el puerto del tráfico VPN.

Por favor, encuentra la sección "Multi-Daemon Mode" y cambia ambos puertos de los valores predeterminados. Esto se hace por motivos de seguridad. Los puertos pueden tener el mismo número. Yo elegí el 9514, pero esto es solo un ejemplo, te recomiendo que elijas tus propios puertos.

Paso 5.2) - Agregando nuestra IP pública

Por favor, no navegues lejos de la página de "Configuración de red" por ahora. Pero necesitarás abrir la siguiente URL en una nueva pestaña.

Copia tu dirección IP de este sitio web y pégala en el campo "Hostname or IP Address" ubicado en la parte superior de la página de "Network Settings". Este campo ya estará completado con tu dirección IP privada, debes sobrescribirla con tu dirección IP pública.

Paso 5.3) Opcional - Configurar la interfaz de administración y la interfaz de cliente para que se ejecuten en puertos diferentes.

Este paso es opcional, pero por motivos de seguridad, lo recomiendo fuertemente.

Vamos a configurar la interfaz de administración y la interfaz de cliente para que se ejecuten en puertos diferentes, ya que solo necesitamos acceder públicamente a la interfaz de cliente.

En la misma página "Configuración de red", desplázate hacia abajo hasta la parte inferior y busca "Servidor web del cliente". Activa la opción "Usar una dirección IP o puerto diferente".

Ahora podemos cambiar en qué puerto queremos que se ejecute el servidor web del cliente. Puedes elegir cualquier puerto que desees. En este caso, seleccioné el puerto 9515.

A partir de aquí, por favor haz clic en "Guardar configuración" y luego en "Actualizar servidor en ejecución".

Una vez que el servidor en ejecución se haya actualizado, es posible que debas actualizar tu navegador y volver a iniciar sesión en la interfaz de administración.

Paso 5.4) Solo para usuarios avanzados: Agregar una ruta estática.

Si eres un usuario avanzado, es posible que hayas configurado tu servidor OpenVPN en una subred diferente a la de tus nodos/validadores de Ethereum.

Si ese es el caso, deberás navegar a "Configuración > Configuración de VPN" y agregar una ruta estática para tu red de validadores. Si no están en subredes separadas, continúa con el paso 6.

Paso 6) Agregar cuentas de usuario.

Paso 6.1) - Crear un nuevo usuario y establecer una contraseña

Por favor, dirígete a "Gestión de usuarios" > "Permisos de usuario".

Desde aquí, puedes agregar un nuevo usuario. Escribe un nombre de usuario y marca la casilla "Permitir inicio de sesión automático", luego selecciona la opción "Más configuraciones".

Ahora puedes establecer una contraseña para la cuenta en las nuevas opciones que aparecen cuando haces clic en "Más configuraciones".

Una vez hecho esto, por favor, guarda la configuración haciendo clic en "Guardar configuración" y luego actualiza el servidor en ejecución haciendo clic en "Actualizar servidor en ejecución" nuevamente.

Paso 6.2) Solo para usuarios avanzados: Permitir acceso a otra red.

Si eres uno de los afortunados que tuvieron que realizar el paso 5.4, es posible que también necesites agregar la subred de tus nodos/validadores de Ethereum a la cuenta de usuario.

Paso 7) Desbloquear los puertos locales.

Si estás utilizando un firewall local (lo cual se recomienda), es posible que necesites desbloquear los puertos locales según cómo lo hayas configurado.

Estos son los puertos que configuraste en el paso 5.1 y el paso 5.3, además del puerto 943 (el puerto de administración predeterminado). Puedes cambiar el puerto de la interfaz de administración si lo deseas, pero como no tiene acceso externo, no es realmente necesario.

sudo ufw allow 943
sudo ufw allow 9514 <Change to your "Multi-Daemon Mode" port>
sudo ufw allow 9515 <Change to your "Client Web Server" port>
sudo ufw enable
sudo ufw status numbered

Ya casi terminamos!

Paso 8) Reenvío de puertos..

Para este paso, deberás iniciar sesión en tu enrutador y reenviar los puertos a la máquina donde se ejecuta el servidor de acceso OpenVPN. El flujo de trabajo exacto depende del enrutador, así que te recomiendo buscar instrucciones en línea que sean específicas para el fabricante y modelo de tu enrutador.

Deberás reenviar dos puertos, tanto TCP como UDP.

You will need to forward two ports, both TCP/UDP.

• El/los puerto(s) que ingresaste para "Multi-Daemon Mode" (yo utilicé el 9514).

• El puerto que ingresaste para "Client Web Server" (yo utilicé el 9515).

Una vez completado, por favor, accede al siguiente sitio web y introduce tus puertos para verificar si se han reenviado correctamente.

Paso 9) - Configurar un dispositivo para el acceso VPN.

Si has llegado hasta aquí, ¡felicidades! Te alegrará saber que lo más difícil ya está hecho.

Por favor, completa este paso en el dispositivo en el que deseas configurar el acceso remoto.

Abre la interfaz de usuario web para clientes: Puedes utilizar tanto tu IP pública como tu IP privada para este paso. En mi caso, accedí a https://192.168.3.111:9515.

Una vez dentro, inicia sesión utilizando la cuenta de usuario que creaste en el paso 6. Si tienes éxito, verás la siguiente pantalla.

Paso 9.1) - Instalar el cliente de OpenVPN

Selecciona el sistema operativo que estás utilizando.

Desde aquí puedes seleccionar un cliente para tu dispositivo.

• Si estás en Windows o Mac, se descargará automáticamente el software cliente de OpenVPN y te guiará a través del resto del proceso.

• Si estás en Linux, Android o iOS, te llevará a una página externa con instrucciones adicionales.

Paso 9.2) Descarga el perfil de usuario del cliente

Por favor, descarga el perfil de usuario "autologin".

Una vez hecho esto, deberás importar el perfil en el software de OpenVPN. El propio software (Windows o Mac) o las páginas externas (Linux, Android o iOS) te mostrarán cómo hacerlo.

Paso 10) - Conectarse a la VPN

¡Tienes suerte, este paso final es el más fácil!

• Si estás usando una computadora portátil o de escritorio, por favor conéctate a otra red como un punto de acceso móvil.

• Si estás usando un teléfono, por favor desconéctate de tu WiFi y asegúrate de estar conectado a Internet a través de tu proveedor de telefonía móvil.

Ahora verifica tu dirección IP en > https://www.whatismyip.com/

Regresa al software de OpenVPN y presiona "Conectar", y estarás conectado en cuestión de segundos.

Luego verifica tu dirección IP nuevamente en > https://www.whatismyip.com/

Si la conexión fue exitosa, verás que ahora coincide con tu dirección IP de casa, ya que estás conectado a tu conexión de Internet doméstica. Desde aquí, puedes acceder de forma segura a tus nodos/validadores de Ethereum a través de SSH.

Si puedes conectarte a tu red doméstica pero no puedes acceder por SSH a tus servidores, es posible que debas ajustar el firewall en tu nodo de Ethereum para aceptar conexiones SSH entrantes desde la dirección IP de tu servidor de OpenVPN.

FAQ

Más adelante se añadirá la sección de preguntas frecuentes.

Existen varios clientes de consenso (anteriormente conocidos como clientes 'Eth2') que respaldan las actualizaciones de consenso. Estos clientes ejecutan la Beacon Chain y proporcionan un mecanismo de consenso de prueba de prueba de participación (PoS) a los clientes de ejecución.

Todos los clientes de consenso siguen la misma especificación ↗. Si un cliente no cumple con esta especificación, no podrá llegar a un consenso con el resto de la red.

Lighthouse

Lighthouse es una implementación de cliente de consenso escrita en Rust bajo la licencia Apache-2.0. Es mantenida por Sigma Prime y ha sido estable y lista para producción desde el inicio de Beacon Chain. Es utilizado por varias empresas, grupos de participación y particulares. Su objetivo es ser seguro, eficiente y compatible en una amplia gama de entornos, desde PC de escritorio hasta implementaciones automatizadas sofisticadas.

Loadstar

Lodestar es una implementación de cliente de consenso lista para producción escrita en Typescript bajo la licencia LGPL-3.0. Es mantenida por ChainSafe Systems y es el más nuevo de los clientes de consenso para solistas, desarrolladores e investigadores. Lodestar consta de un nodo beacon y un cliente validador impulsado por implementaciones en JavaScript de los protocolos de Ethereum. Lodestar tiene como objetivo mejorar la usabilidad de Ethereum con clientes ligeros, ampliar la accesibilidad a un grupo más amplio de desarrolladores y contribuir aún más a la diversidad del ecosistema.

Nimbus

Nimbus es una implementación de cliente de consenso escrita en Nim bajo la licencia Apache-2.0. Es un cliente listo para producción utilizado por solistas y grupos de participación (staking pools). Nimbus está diseñado para ser eficiente en recursos, lo que facilita su ejecución en dispositivos con restricciones de recursos e infraestructuras empresariales sin comprometer la estabilidad o el rendimiento de las recompensas. Un menor consumo de recursos significa que el cliente tiene un margen de seguridad mayor cuando la red está bajo estrés.

Implementado por Trinity, funciona como una sincronización rápida, pero también descarga los datos necesarios para ejecutar los bloques más recientes, lo que te permite consultar la cadena dentro de los primeros minutos desde el inicio.

• Sincroniza el estado primero y te permite realizar consultas RPC en poco tiempo.

• Aún se encuentra en desarrollo y no es completamente confiable. La sincronización en segundo plano se ralentiza y las respuestas de RPC pueden fallar en ocasiones.

Prysm

Prysm es un cliente de consenso de código abierto y completo, escrito en Go bajo la licencia GPL-3.0. Cuenta con una interfaz de usuario web opcional y prioriza la experiencia del usuario, la documentación y la configurabilidad tanto para usuarios individuales como institucionales que participan en la validación de la red Ethereum 2.0 desde sus hogares (stake-at-home).

Teku

Teku es uno de los clientes originales del Beacon Chain desde el inicio. Junto con los objetivos habituales de seguridad, robustez, estabilidad, facilidad de uso y rendimiento, Teku se enfoca específicamente en cumplir totalmente con los diversos estándares de los clientes de consenso.

Teku ofrece opciones de implementación muy flexibles. El nodo del Beacon Chain y el cliente validador se pueden ejecutar juntos como un único proceso, lo cual es extremadamente conveniente para los validadores individuales, o los nodos se pueden ejecutar por separado para operaciones de validación más sofisticadas. Además, Teku es completamente interoperable con Web3Signer↗ para la seguridad de las claves de firma y la protección contra penalizaciones por incumplimiento.

Teku está escrito en Java y tiene una licencia Apache 2.0. Es desarrollado por el equipo de Protocolos en ConsenSys, que también es responsable de Besu y Web3Signer.

Para instalar Linux en una máquina física, aquí están los pasos a seguir:

1. Descarga una imagen de distribución de Linux en tu computadora de uso diario.

2. Crea un USB con la imagen de distribución.

3. Arranca tu máquina de staking desde el USB.

4. Selecciona las opciones correctas para tu instalación.

Descargar una imagen de distribución de Linux

Hay muchas distribuciones de Linux disponibles. Si eres un usuario experimentado de Linux, probablemente ya sepas qué distribución quieres usar según tus habilidades y conocimientos. Sin embargo, si eres un usuario nuevo de Linux o simplemente quieres algo sencillo de instalar y usar, la distribución de Linux recomendada es Ubuntu Linux.

Hay dos tipos de distribuciones entre las que puedes elegir:

• Desktop: https://ubuntu.com/download/desktop↗

• Server: https://ubuntu.com/download/server↗

La versión de escritorio (Desktop) viene con una interfaz gráfica similar a Windows o macOS. Para las máquinas de staking, la versión de escritorio no es ideal ya que tiene un sobrecargo adicional que no es necesario, pero puede ser más fácil para los nuevos usuarios que se sienten más cómodos con una interfaz gráfica.

La versión de servidor (Server) es meramente una interfaz de línea de comandos. Esto puede parecer intimidante al principio, pero al seguir las guías de solo staking, simplemente copiarás y pegarás comandos, por lo que no es demasiado difícil. Puedes conectarte de forma remota a tu máquina de staking de manera segura utilizando protocolos como SSH, pero la forma más fácil de comenzar es conectar directamente un teclado y un monitor. Siempre se puede utilizar SSH más adelante.

Crea un USB con la imagen de distribución

Hay muchas herramientas disponibles para grabar imágenes de disco en unidades USB. Una que es de código abierto y que funciona en múltiples plataformas es https://www.balena.io/etcher↗. Simplemente selecciona la imagen de distribución de Linux que descargaste anteriormente, selecciona el USB y ¡a flashear!

Arranca tu máquina de staking desde el USB

Este paso debería ser tan fácil como insertar el USB que has grabado con la imagen de disco en el paso anterior y luego encender tu máquina de staking. En algunos casos, es posible que debas forzar la máquina a arrancar desde el USB en lugar de cualquier sistema operativo actualmente instalado. Esto se puede hacer editando el orden de arranque en el BIOS y permitiendo el arranque desde USB. Google es el mejor lugar para encontrar información sobre cómo arrancar desde un USB si encuentras algún problema en esta etapa.

Selecciona las opciones correctas para tu instalación

Una vez que hayas arrancado desde el USB, se te presentará un menú de instalación. Utiliza las teclas de flecha (arriba y abajo) para mover la selección y utiliza la tecla de retorno (enter) para seleccionar la opción.

Después de seleccionar Try or Install Ubuntu Server, verás una pantalla como esta. No necesitas hacer nada en este punto, el sistema simplemente se está iniciando.

Una vez que el sistema se haya iniciado, se te presentará el asistente de instalación. El primer paso es seleccionar el idioma.

Selecciona el idioma (diseño) del teclado.

Selecciona el tipo de instalación que deseas utilizar. Para este caso, selecciona Ubuntu Server.

Selecciona una red. Si tu máquina de apuestas utiliza un cable Ethernet para una conexión directa a la red (recomendado), esta opción debería estar preseleccionada. Si utilizas WiFi, selecciona los detalles correspondientes.

Selecciona un proxy si es necesario. Si estás utilizando una red doméstica estándar y no sabes qué significa esta opción, no te preocupes, déjala en blanco.

Selecciona desde dónde deseas descargar las actualizaciones del sistema operativo. Esta ubicación puede seleccionarse en función de tu ubicación geográfica para que las descargas sean más rápidas. Sin embargo, es más fácil seleccionar la opción predeterminada que ya está preseleccionada.

Selecciona la configuración de almacenamiento. Dado que tu máquina de staking es probablemente una máquina dedicada, la mejor opción es Use an entire disk (usar un disco completo). No te preocupes por el cifrado, ya que deseas que tu máquina pueda reiniciarse automáticamente y los discos cifrados hacen que ese proceso sea mucho más complejo.

Se te mostrará una pantalla de resumen de la configuración de almacenamiento. Por defecto, Linux puede que no utilice todo el espacio en disco disponible. En la captura de pantalla anterior, se muestra el tamaño del almacenamiento local como 1,171 terabytes, pero la pantalla de confirmación a continuación muestra solo 100 GB en uso.

Para utilizar todo el espacio en disco disponible, utiliza las teclas de flecha para moverte a la fila ubuntu-lv y presiona la tecla de retorno/enter para seleccionar Edit. Ingresa el valor Max mostrado junto a Size en el campo de entrada y luego Save.

Después de confirmar la configuración de almacenamiento, se te presentará una pantalla adicional de confirmación para asegurarte de que estás listo para formatear y eliminar por completo cualquier dato existente en el disco de almacenamiento. Eso es lo que queremos, así que selecciona Continue.

Configurar el perfil de usuario es importante, ya que es la forma en que accederás a la máquina, tanto de forma directa como remota. Selecciona un nombre para tu usuario y el nombre para tu servidor que aparecerá en tu red local. Tu nombre de usuario se utiliza para iniciar sesión en la máquina y la contraseña protege tu cuenta de usuario.

En este punto, es una buena idea configurar el servidor SSH para no tener que instalarlo manualmente más adelante. Si no tienes la intención de conectarte por SSH a tu máquina de staking y solo te conectarás directamente con un teclado y un monitor, no necesitas esta opción. Para obtener información sobre conexiones SSH, consulta el tutorial Conectar con SSH.

Esta pantalla podría mostrarse pidiéndote seleccionar o deseleccionar snaps populares. No te preocupes por esta página, incluso podría estar vacía para ti. Simplemente continúa con la siguiente pantalla.

En este punto, la instalación comenzará utilizando todas las configuraciones que has proporcionado. Esto puede llevar algunos minutos (10 o más) según tu hardware y configuración. No necesitas hacer nada, simplemente espera hasta que se complete. Al finalizar el proceso de instalación, deberás reiniciar tu máquina. Selecciona Reboot Now y se te pedirá que retires el dispositivo de instalación (el USB que utilizaste durante la instalación).

Una vez que el sistema se reinicie, verás información de inicio similar al resultado que se muestra a continuación. Espera hasta que se complete y se te mostrará una pantalla de inicio de sesión.

Esta es la pantalla de inicio de sesión de tu máquina validadora. El nombre de esta máquina es eridian-validator.

Ingresa el nombre de usuario que creaste durante la instalación. Luego se te solicitará la contraseña. A medida que escribas tu contraseña, no se mostrará nada en la línea de comandos (¡parecerá que no está funcionando!), pero no te preocupes, esto es por seguridad y la escritura está funcionando correctamente.

¡Y... has ingresado correctamente!

¡Felicitaciones! Has instalado correctamente Ubuntu Linux Server en tu máquina de staking. 🥳

En este punto, te encuentras en la línea de comandos y puedes comenzar a trabajar con muchas de las guías de solo staking.

Esta página le mostrará cómo configurar su cliente de ejecución para atender solicitudes HTTP RPC.

Esto le permitirá interactuar directamente con la red Ethereum utilizando su propio nodo. ¡Ya no es necesario utilizar un servicio de terceros como Infura!

1) Configure su cliente de ejecución

Deberá agregar los siguientes indicadores a su cliente de ejecución.

2) Configura tu billetera

El siguiente ejemplo le mostrará cómo usar su punto final RPC con Metamask, ya que es una de las billeteras más utilizadas.

2.1) Abra Metamask, haga clic en el ícono de menú en la parte superior derecha y seleccione "Add network"

2.2) Desplácese hacia abajo y seleccione "Add a network manually"

2.3) Complete los detalles de su nodo

Los detalles específicos variarán dependiendo de su configuración local. Como estoy ejecutando Geth en la misma máquina que mi instalación de Metamask, estoy usando 127.0.0.1 como dirección IP.

Si su RPC no está disponible o es inaccesible, puede mostrar un error cuando ingrese la ID de la cadena y no le permitirá guardar la red.

2.4) Esté atento al mensaje de confirmación.

2.5) Cambie a su nueva red si Metamask aún no lo ha hecho

¡Éxito! Ahora puede usar Metamask como lo haría normalmente con el beneficio adicional de acceder a la red Ethereum a través de su propio nodo 🥳

Habiendo dicho eso, vamos a entrar en detalle. A continuación mostraremos algunas cosas que puedes hacer para minimizar el tiempo de inactividad.

Siempre habrán situaciones en las que tendrás tiempo de inactividad, esto es inevitable al ejecutar un validador, por lo tanto no esperes un registro de atestaciones perfecto. Sin embargo, hay algunas cosas que puedes hacer para minimizar el tiempo de inactividad.

Las siguientes ideas pueden o no ser factibles dependiendo de la cantidad de validadores que estés ejecutando. Te pedimos evaluar por ti mismo los pros y cons, y decide si es apropiado implementarlas según tus circunstancias.

Conectar tu nodo y router a un UPS

Esto asegurará que tu equipo no se apague abruptamente, lo que potencialmente salvará tu hardware de daños, así como evitará la corrupción de tu base de datos/sistema operativo, ahorrándote la necesidad de resincronizar o reinstalar. Puedes encontrar más información al respecto en la página de .

Ejecutar múltiples pares de clientes de Consenso-Ejecución

Siempre es buena práctica correr múltiples pares de clientes ya sea en diferentes SSDs o en máquinas separadas. Una máquina separada es importante siempre y cuando estés corriendo un número considerable de validadores, de lo contrario mantener diferentes SSDs será suficiente.

Es seguro ejecutar múltiples nodos para redundancia, pero no múltiples validadores. Por ejemplo, .

El beneficio de hacer esto es que no tendrás ningún tiempo de inactividad en caso de que uno de los pares de clientes se desconecte, se corrompa o si el SSD deje de funcionar y requiera mantenimiento manual para volver a estar en línea. Podrás solucionar el nodo dañado cuando se te sea posible y mientras tanto el validador seguirá activo sin inconvenientes utilizando el otro nodo beacon previamente configurado.

Incluso puedes llevarlo un paso más allá y tener tu cliente validador en un SSD separado (por ejemplo, junto con tu sistema operativo) y hacer que apunte a tus nodos beacon, ambos también en SSDs separados, reduciendo así los puntos de fallo en general.

Contar con hardware de repuesto listo para usar

Puede ser útil tener un SSD de repuesto listo para ser reemplazado en caso de fallo de hardware. Podrás iniciar inmediatamente el proceso de recuperación de tus nodos/validadores y, una vez completado, podrás comprar un disco de reemplazo en tu propio tiempo.

Si viajas con frecuencia, incluso podrías tenerlo conectado a tu máquina, manteniéndolo listo para su uso. Esto significa que tu nodo podría ser recuperado de forma remota, a menos que, por supuesto, el disco que falle sea tu disco del sistema operativo.

Habrá momentos en los que estés desconectado y falten atestaciones, no te estreses ni entres en pánico cuando esto suceda y concéntrate en volver a estar en línea. Por ejemplo, si estás desconectado durante 4 horas, te tomará 4 horas en línea para actualizar el balance de tu validador de vuelta.

Para obtener más información sobre el tiempo de inactividad, consulta nuestras publicaciones de ayuda:

Las actualizaciones de seguridad automáticas son útiles cuando no puedes acceder a tu máquina pero deseas que las actualizaciones de seguridad críticas se apliquen automáticamente.

Actualizar los paquetes del sistema nuevamente.

Reiniciar la máquina.

¡Felicitaciones! Has habilitado correctamente las actualizaciones automáticas en tu máquina de staking 🥳

Cuando migres llaves de validadores, tomate tu tiempo ¡Sin prisas!

Hay una variedad de escenarios donde necesitas mudar las llaves de validadores de una máquina a otra, aquí algunos ejemplos:

• ⬆️ Actualizando hardware.

• 🔧 Recuperándose de una falla de hardware.

• ☁️ Migrando de un servicio de hosting en la nube a una máquina casera de staking

En cualquiera de estos casos, el procedimiento debe ser el mismo. La cosa más importante a recordar es que la penalidad por estar offline es muy baja, así que no es urgencia optimizar el tiempo de inactividad. Un evento de slashing causado por una migración incorrecta de llaves incurrirá una penalidad equivalente a MESES de simplemente estar offline.

🚨 No vayas con prisa 🚨

Definiciones

Origen: De donde vienen las llaves. Destino: Hacia donde las llaves serán migradas

Pasos

1. Detén cliente de validación en la máquina origen.

2. Detén cliente de validación en la máquina destino.

3. Espera un MÍNIMO de dos finalizados antes de continuar.

4. Copia las llaves de los validadores a la máquina destino por medio de almacenamiento (Por ejemplo USB) o directamente de la máquina origen a la destino (Por ejemplo scp, rsync, etc...) Sí las llaves de los validadores se pierden durante un fallo de hardware .

5. Borra las llaves de la máquina origen. Esto asegura que incluso sí la máquina origen reinicia inesperadamente, las llaves para firmar de los validadores no existirán y no podrán ser usadas por el cliente validador

6. De estar disponible, exporta cualquier de la máquina origen e importala en la máquina destino.

7. Apaga la máquina origen y asegúrate al 100% que no se pueda reiniciar.

8. Arranca el cliente validador en la máquina destino.

9. Importa las llaves de validación.

10. Check the validator client logs to confirm everything is working correctly. Verifica los logs del cliente validador para confirmar que todo está funcionando correctamente.

¡Felicitaciones! Has migrado con éxito tus llaves de validación entre dos máquinas 🥳

Una razón común para que Geth falle puede ser el paro inesperado de una máquina validadora. Geth utiliza RAM para memoria temporal y durante un cierre ordenado alguna información importante será escrita en el disco; sin embargo, durante un cierre ordenado, no hay tiempo suficiente para escribir en el disco (por ejemplo: durante la perdida de energía electrica, así que se pierden datos importantes.) Esta perdida de datos lleva a una corrupción de la carpeta chaindata, el cual requiere de una resincronización.

Ubicación de Archivos

• Ubicación estándar de la carpeta chaindata.

• Ubicación estándar de la carpeta ancient.

Pasos (Si existe la carpeta antigua)

¡Buenas noticias! La resincronización requerida se puede hacer mucho más rápido que una resincronización completa simplemente manteniendo la carpeta ancient. La carpeta antigua contiene archivos que no se dañan durante un apagado inesperado.

1. Detiene Geth.

2. Mueve la carpeta ancient.

3. Borra el directorio chaindata y vuelve a crearlo.

4. Mueve la carpeta antigua de regreso al directorio chaindata que ahora está vacío.

5. Cambia el propietario del directorio chaindata al usuario Geth.

6. Inicia Geth.

¡Felicidades! Has iniciado éxitosamente una resincronización de Geth 🥳

Pasos (Si la carpeta antigua no existe)

Si la carpeta antigua no exista, no es un problema. Solo significa que necesitarás resincronizar Geth desde cero, el cual tomará más tiempo.

1. Detiene Geth.

2. Elimina el directorio chaindata y lo vuelves a crear.
3. Confirma el propietario y los permisos para la carpeta chaindata están configurados al usuario Geth.
4. Inicia Geth.

¡Felicidades! Has iniciado una resincronización de Geth exitosa. 🥳

Para realizar la salida de un validador, es necesario que se envíe un mensaje firmado desde su cliente de validación. Los detalles del proceso de salida son diferentes para cada cliente. Estos enlaces son para cada cliente específico:

La autenticación de dos factores implica requerir una segunda medida de seguridad además de su contraseña o clave SSH, generalmente en un dispositivo separado del principal.

Por ejemplo, puede estar familiarizado con el inicio de sesión en un sitio web, como un intercambio cripto, utilizando una contraseña y un código de Google Authenticator (o un código de SMS). Este proceso de dos pasos es un ejemplo de autenticación de dos factores.

SSH también se puede configurar para requerir un código de autenticación de Google, lo que significa que un atacante que de alguna manera comprometiera su clave SSH y su frase de contraseña aún necesitaría el dispositivo con la aplicación de autenticación (presumiblemente su teléfono). Esto agrega una capa adicional de seguridad a su sistema.

Comience instalando (o un equivalente compatible) en su teléfono si aún no lo tiene. Para los usuarios de Android, considere , que es una alternativa de código abierto que admite el bloqueo de contraseña y copias de seguridad convenientes.

A continuación, instale el módulo Google Authenticator en su nodo con este comando:

Ahora dile a PAM (pluggable authentication modules) para utilizar este módulo. Primero, abra el archivo de configuración:

Find @include common-auth (debe estar en la parte superior) y comentalo agregando un # delante de él, por lo que se ve así:

A continuación, agregue estas líneas en la parte superior del archivo:

Luego guarde y salga del archivo con Ctrl+O, Enter, y Ctrl+X.

Ahora que PAM sabe usar Google Authenticator, el siguiente paso es decirle a sshd que use PAM. Abra el archivo de configuración sshd :

Ahora cambia la linea KbdInteractiveAuthentication no a KbdInteractiveAuthentication yes entonces deberia verse así:

(Las versiones anteriores de SSH llaman a esta opción ChallengeResponseAuthentication en lugar de KbdInteractiveAuthentication.)

Agregue la siguiente línea al final del archivo, que le indica a sshd que necesita tanto una clave SSH como el código de Google Authenticator:

Todas las opciones añadidas a AuthenticationMethods serán necesarias cuando inicie sesión. Así que puede elegir, e.g. 2FA y contraseña, o una combinación de los tres métodos.

• publickey (SSH llave)

• password publickey (contraseña)

• keyboard-interactive (2FA código de verificación)

Luego guarde y salga del archivo con Ctrl+O, Enter, y Ctrl+X.

Ahora sshd esta configurado , necesitamos crear nuestros códigos 2FA. En tu terminal, ejecuta:

Primero, le preguntará acerca de los tokens basados ​​en el tiempo. Decir y a esta pregunta:

Ahora verá un gran código QR en su pantalla; escanéelo con su aplicación Google Authenticator para agregarlo. También verá su llave secreta y algunos códigos de respaldo con este aspecto:

Finalmente, te pedirá algunos parámetros más; los valores predeterminados recomendados son los siguientes:

Una vez que haya terminado, reinicie sshd para que obtenga la nueva configuración:

Cuando intente ingresar a su servidor SSH con sus claves SSH, ahora también se le debe solicitar un código de verificación 2FA, pero no una contraseña.

¡Bienvenido a la página de ideas de contribución de contenido de la base de conocimientos de EthStaker! Nos complace que se una a nuestra comunidad y ayude a aumentar nuestra base de conocimientos. Para que el proceso de contribución sea más accesible, hemos compilado una lista de temas e ideas para nuevos contenidos en los que puede contribuir. Nuestro objetivo es hacer que el staking de Ethereum sea más accesible, informativo y atractivo para todos.

If you're interested in contributing to one of these topics or have your own idea, please reach out to us on the #knowledge-base Discord channelOur team and community members are ready to help you get started, provide guidance, and answer any questions you might have.

Si está interesado en contribuir a uno de estos temas o tiene su propia idea, comuníquese con nosotros en el canal de Discord #knowledge-base. Nuestro equipo y los miembros de la comunidad están listos para ayudarlo a comenzar, brindarle orientación y responder cualquier pregunta que pueda tener.

Temas e ideas para contenido nuevo:

1. Tutoriales de replanteo

   1. Guías paso a paso para configurar un nodo de validación

   2. Cómo hacer stake usando billeteras y herramientas populares

   3. Solución de problemas comunes de staking

   4. Sugerencias de optimización del rendimiento del validador

2. Seguridad y Privacidad

   1. Prácticas recomendadas para proteger las claves del validador

   2. Consideraciones de privacidad para los participantes de Ethereum

3. Economía de apuestas

   1. Comprender la dinámica de las recompensas de staking y APR

   2. El papel del staking de Ethereum en DeFi

4. Comunidad y ecosistema

   1. Perfiles de pools y servicios de staking populares

   2. Eventos, reuniones y conferencias

5. Cómo contribuir:

   1. Únase al servidor EthStaker Discord: https://discord.io/ethstaker

   2. Dirígete al canal #knowledge-base.

   3. Exprese su interés en contribuir a un tema o idea específica o presentar su propia idea.

   4. Colabore con nuestro equipo y los miembros de la comunidad para reunir recursos, orientación y apoyo.

   5. Cree su contenido siguiendo las pautas de contenido de la base de conocimientos de EthStaker.

   6. Envíe su contenido para su revisión.

Estamos emocionados de tenerlo a bordo y esperamos trabajar juntos para hacer que el staking de Ethereum sea más accesible y atractivo para todos. ¡Construyamos una comunidad de staking de Ethereum más fuerte y con más conocimientos, una contribución a la vez!

Como se describe en el barrido de validadores, la única forma de recibir recompensas de la cadena Beacon o el depósito inicial de 32 ETH a la salida de un validador es que el validador haya establecido una dirección de retiro cambiando sus credenciales de retiro que inicia con 0x00 a la que inicia con 0x01.

Es posible durante la creación de un validador especificar una dirección de retiro de capa de ejecución, si lo ha hecho ya, no hay necesidad de actualizar sus credenciales. De hecho, una vez que las credenciales se establezcan en la dirección que inicia con 0x01, ya no es posible cambiarlas en el futuro. Por eso es imperativo que cuando se elija una dirección de retiro, se elija una sobre la que tenga control total, como una hardware wallet. Se recomienda fuertemente NO elegir una wallet donde no controle las claves privadas, como por medio de un exchange o a través de un tercero.

Tenga en cuenta: Si en algún momento está confundido con qué debería hacer, pida orientación a la comunidad de EthStaker. No hay preguntas tontas y siempre nos esforzamos por dar la bienvenida a quien llegue antes de ayudarles.

Usuarios de eth-docker: Hay una guía independiente si usas eth-docker aquí. La siguiente guía puede considerarse un complemento ya que los pasos son muy similares.

Advertencias

• Elija una dirección sobre la que tenga absoluto control: Se recomienda fuertemente carteras de hardware y carteras de Exchanges NO DEBE USARSE. Puede pensar que es conveniente enviar a una cartera "caliente" o a un exchange para evitar comisiones de transacción adicionales, pero usted está arriesgando no sólo sus recompensas, sino también el depósito inicial de 32 ETH.

• Una vez que sus credenciales de retiro han cambiado de 0x00 a 0x01 no se pueden cambiar en el futuro.

• Su clave mnemónica es necesaria para cambiar sus credenciales: Sus fondos serán bloqueados indefinidamente mientras sus credenciales de retiro sean 0x00. Sin su clave mnemónica, no será posible actualizar sus credenciales. Excepto para casos extremadamente raros donde se tenga control de la llave privada de la cuenta de retiro y el keystore. En todo caso le recomendamos buscar a fondo su clave mnemónica y no proseguir con este proceso si tiene problemas para localizarla.

• ¡Hágalo off-line! La seguridad es importante: Al hacer este cambio, estarás exponiendo su clave mnemónica por lo que es muy recomendable realizar esta acción sin conexión a internet u otras redes. Si hace este proceso mientras haya una conexión a internet u otra red se arriesga a que le sean robados su clave mnemónica y por ende sus validadores y recompensas.

• Todas las recompensas de la cadena Beacon y el depósito inicial serán enviados a la dirección especificada automáticamente sin intervención del usuario: La dirección especificada será la única ubicación donde las recompensas y el depósito inicial serán enviadas, una vez se haya establecido. Si la dirección especificada se compromete, se aconseja trabajar con un grupo de White Hats para recuperar sus fondos.

• No se deshaga de su clave mnemónica después de actualizar sus credenciales: Incluso después de que se cambien las credenciales, todavía se le aconseja mantener su clave mnemónica ya que se puede utilizar para regenerar los archivos de su keystore si esos archivos se pierden. Su clave mnemónica puede ser parte de su herencia en un futuro, así que cuídela bien.