diff --git a/public/content/translations/es/developers/docs/consensus-mechanisms/index.md b/public/content/translations/es/developers/docs/consensus-mechanisms/index.md index aa85d7ae093..d15094c2a47 100644 --- a/public/content/translations/es/developers/docs/consensus-mechanisms/index.md +++ b/public/content/translations/es/developers/docs/consensus-mechanisms/index.md @@ -56,7 +56,7 @@ Los validadores crean bloques. Un validador se selecciona aleatoriamente en cada Un sistema de prueba de participación es criptoeconómicamente seguro, porque un atacante que intente tomar el control de la cadena debe destruir una cantidad masiva de ETH. Un sistema de recompensas alienta a participantes individuales a comportarse honestamente, y las penalizaciones desaniman a los participantes a actuar malintencionadamente. -Más información sobre la [prueba de participación](/developers/docs/consensus-mechanisms/pos/). +Más información sobre la [prueba de participación](/developers/docs/consensus-mechanisms/pos/) ### Una guía visual {#types-of-consensus-video} diff --git a/public/content/translations/es/developers/docs/consensus-mechanisms/pos/attack-and-defense/index.md b/public/content/translations/es/developers/docs/consensus-mechanisms/pos/attack-and-defense/index.md index 67f18ad0995..be54e89e119 100644 --- a/public/content/translations/es/developers/docs/consensus-mechanisms/pos/attack-and-defense/index.md +++ b/public/content/translations/es/developers/docs/consensus-mechanisms/pos/attack-and-defense/index.md @@ -4,138 +4,142 @@ description: Conozca mejor los vectores de ataque conocidos en la prueba de part lang: es --- -Los ladrones y saboteadores buscan constantemente oportunidades para atacar el software cliente de Ethereum. Esta página describe los vectores de ataque conocidos en la capa de consenso de Ethereum y describe cómo se pueden defender esos ataques. La información de esta página está resumida de una [versión más larga](https://mirror.xyz/jmcook.eth/YqHargbVWVNRQqQpVpzrqEQ8IqwNUJDIpwRP7SS5FXs). +Los ladrones y saboteadores buscan constantemente oportunidades para atacar el software de cliente de Ethereum. Esta página describe los vectores de ataque conocidos en la capa de consenso de Ethereum y describe cómo se pueden defender esos ataques. La información en esta página está adaptada de una [versión más larga](https://mirror.xyz/jmcook.eth/YqHargbVWVNRQqQpVpzrqEQ8IqwNUJDIpwRP7SS5FXs). -## Prerrequisitos {#prerequisites} +## Requisitos previos {#prerequisites} -Se requieren algunos conocimientos básicos de la[prueba de participación](/developers/docs/consensus-mechanisms/pos/). Además, será útil tener una comprensión básica de la [capa de incentivos](/developers/docs/consensus-mechanisms/pos/rewards-and-penalties) y del algoritmo de elección de bifurcación de Ethereum, [LMD-GHOST](/developers/docs/consensus-mechanisms/pos/gasper). +Se necesita algo de conocimiento básico sobre la [prueba de participación](/developers/docs/consensus-mechanisms/pos/). Además, también es de utilidad tener una comprensión básica de la [capa de incentivos de Ethereum](/developers/docs/consensus-mechanisms/pos/rewards-and-penalties) y del algoritmo de selección de bifurcación (/developers/docs/consensus-mechanisms/pos/gasper). ## ¿Qué quieren los atacantes? {#what-do-attackers-want} -Un error común es pensar que un atacante exitoso puede generar nuevo ether o drenar ether de cuentas arbitrarias. Nada de esto es posible, porque todas las transacciones las ejecutan todos los clientes de ejecución de la red. Deben cumplir con las condiciones básicas de validez (por ejemplo, las transacciones están firmadas con la clave privada del remitente, el remitente tiene suficiente saldo, etc.) o de lo contrario simplemente se revierten. Hay tres clases de resultados a las que un atacante podría apuntar de manera realista: reorganización, doble finalidad o retraso de finalización. +Un error común es pensar que un atacante exitoso puede generar nuevo ether o drenar ether de cuentas arbitrarias. Nada de esto es posible, porque todas las transacciones las ejecutan todos los clientes de ejecución de la red. Deben cumplir con las condiciones básicas de validez (por ejemplo, las transacciones están firmadas con la clave privada del remitente, el remitente tiene suficiente saldo, etc.) o de lo contrario simplemente se revierten. Hay tres clases de resultados a las que un atacante podría apuntar de manera realista: reorganizaciones, doble finalidad o retraso de finalización. -Una **«reorg»** es una reorganización de bloques en un nuevo orden, tal vez con alguna adición o sustracción de bloques en la cadena predilecta. Una reorg maliciosa podría garantizar que se incluyan o excluyan bloques específicos, lo que permite el doble gasto o la extracción de valor mediante transacciones (MEV) frontrunning (ventajistas) y backrunning (consecuentes). Las reorg también podrían utilizarse para evitar que ciertas transacciones se incluyan en la cadena predilecta, una forma de censura. La forma más extrema de reorganización es la «reversión de la finalidad», que elimina o reemplaza los bloques que se han finalizado previamente. Esto solo es posible si el atacante destruye más de 1/3 del total del ether en participación, esta garantía se conoce como «finalidad económica» y lo aborderemos más adelante. +Una **"reorg"** es una modificiación de bloques en un nuevo orden, posiblemente con la adición o eliminación de algunos bloques en la cadena canónica. Una reorganización maliciosa podría garantizar que se incluyan o excluyan bloques específicos, lo que permite el doble gasto o la extracción de valor mediante transacciones (MEV) frontrunning (ventajistas) y backrunning (consecuentes). Las reorganizaciones también podrían utilizarse para evitar que ciertas transacciones se incluyan en la cadena predilecta: una forma de censura. La forma más extrema de reorganización es la «reversión de la finalidad», que elimina o reemplaza los bloques que se han finalizado previamente. Esto solo es posible si el atacante destruye más del 1/3 del total del ether en participación, esta garantía se conoce como «finalidad económica» y la aborderemos más adelante. -**Doble finalidad** es la condición improbable pero grave en la que dos bifurcaciones pueden finalizar simultáneamente, creando una desunión permanente en la cadena. Esto es teóricamente posible para un atacante dispuesto a arriesgar el 34 % del total de ether en participación. La comunidad se vería obligada a coordinar fuera de la cadena y llegar a un acuerdo sobre qué cadena seguir, lo que requeriría fuerza en la capa social. +La **"doble finalidad"** es una condición poco probable aunque grave en la que dos bifurcaciones logran finalizar simultáneamente, creando una división permanente en la cadena. Esto es teóricamente posible para un atacante dispuesto a arriesgar el 34 % del total de ether en participación. La comunidad se vería obligada a coordinar fuera de la cadena y llegar a un acuerdo sobre qué cadena seguir, lo que requeriría fuerza en la capa social. Un ataque de **retraso de finalidad** impide que la red alcance las condiciones necesarias para finalizar secciones de la cadena. Sin finalidad, es difícil confiar en las aplicaciones financieras construidas sobre Ethereum. El objetivo de un ataque de retraso de finalidad es simplemente interrumpir Ethereum en lugar de beneficiarse directamente, a menos que el atacante tenga alguna posición estratégica corta. Un ataque a la capa social podría tener como objetivo socavar la confianza del público en Ethereum, devaluar el ether, reducir la adopción o debilitar a la comunidad de Ethereum para dificultar la coordinación fuera de banda. -Ahora que ya sabemos por qué un adversario podría atacar Ethereum, en las siguientes secciones examinaremos _cómo_ podrían hacerlo. +Habiendo establecido por qué un adversario podría atacar Ethereum, las siguientes secciones examinan _cómo_ podrían llevarse a cabo dichos ataques. ## Métodos de ataque {#methods-of-attack} ### Ataques de capa 0 {#layer-0} -En primer lugar, las personas que no participan activamente en Ethereum (ejecutando el software del cliente) pueden atacar apuntando a la capa social (Capa 0). La capa 0 es la base sobre la que se construye Ethereum y, como tal, representa una superficie potencial para los ataques con consecuencias que crean una reacción en cadena por el resto del bloque. Algunos ejemplos podrían incluir: +En primer lugar, las personas que no participan activamente en Ethereum (ejecutando el software del cliente) pueden atacar apuntando a la capa social (capa 0). La capa 0 es la base sobre la que se construye Ethereum y, como tal, representa una superficie potencial para ataques con consecuencias que creen una reacción en cadena en el resto del bloque. Algunos ejemplos podrían incluir: + +- Una campaña de desinformación podría socavar la confianza que la comunidad tiene en la hoja de ruta de Ethereum, los equipos de desarrolladores, las aplicaciones, etc. Lo que a su vez podría disminuir el número de personas dispuestas a participar en la seguridad de la red, degradando tanto la descentralización como la seguridad criptoeconómica. -- Una campaña de desinformación podría erosionar la confianza que la comunidad tiene en la hoja de ruta de Ethereum, los equipos de desarrolladores, las aplicaciones, etc. Esto podría disminuir el número de personas dispuestas a participar en la seguridad de la red, degradando tanto la descentralización como la seguridad criptoeconómica. - Ataques dirigidos y/o intimidaciones hacia la comunidad de desarrolladores. Esto podría ocasionar la salida voluntaria de los desarrolladores y ralentizar el progreso de Ethereum. -- La regulación exagerada también podría considerarse un ataque a la capa 0, ya que podría disincentivar rápidamente la participación y la adopción. -- Infiltración de operadores expertos con malas intenciones en la comunidad de desarrolladores cuyo objetivo es ralentizar el progreso mediante procrastinación en debates, el retraso de las decisiones clave, la creación de correos basura, etc. +- La regulación excesiva también podría considerarse un ataque a la capa 0, ya que podría disincentivar rápidamente la participación y la adopción. + +- La infiltración de operadores expertos con malas intenciones en la comunidad de desarrolladores cuyo objetivo es ralentizar el progreso mediante procrastinación en debates, el retraso de las decisiones clave, la creación de correos basura, etc. + - Sobornos a operadores clave en el ecosistema de Ethereum para influir en la toma de decisiones. Lo que hace que estos ataques sean especialmente peligrosos es que, en muchos casos, se requiere muy poco capital o conocimientos técnicos. Un ataque de capa 0 podría ser un multiplicador de un ataque criptoeconómico. Por ejemplo, si una parte interesada mayoritariamente maliciosa logra la censura o la reversión de la finalidad, socavar la capa social podría dificultar la coordinación de una respuesta de la comunidad fuera de banda. Defenderse contra los ataques de capa 0 probablemente no sea sencillo, pero se pueden establecer algunos principios básicos. Uno es mantener una alta relación general de ruido para la información pública sobre Ethereum, creada y propagada por miembros honestos de la comunidad a través de blogs, servidores de Discord, especificaciones anotadas, libros, pódcasts y Youtube. Aquí en ethereum.org nos esforzamos por mantener la información precisa y traducirla a tantos idiomas como sea posible. Inundar un espacio con información y memes de alta calidad es una defensa eficaz contra la desinformación. -Otro escudo importante contra los ataques de la capa social es una clara declaración de misión y un protocolo de gobernanza. Ethereum se ha posicionado como el campeón de la descentralización y la seguridad entre capas 1 de contratos inteligentes, a la vez que valora altamente la escalabilidad y la sostenibilidad. Cualesquiera que sean los desacuerdos que surjan en la comunidad Ethereum, afectan mínimamente a estos principios básicos. Evaluar una narrativa contra estos principios básicos y examinarlos a través de sucesivas rondas de revisión en el proceso de EIP (propuesta de mejora de Ethereum), podría ayudar a la comunidad a distinguir a los operadores buenos de los malos y limitar el alcance de los maliciosos en la dirección futura de Ethereum. +Otro escudo importante contra los ataques de capa social es una clara declaración de misión y un protocolo de gobernanza. Ethereum se ha posicionado como el campeón de la descentralización y la seguridad entre capas 1 de contratos inteligentes, a la vez que valora altamente la escalabilidad y la sostenibilidad. Cualesquiera que sean los desacuerdos que surjan en la comunidad Ethereum, afectan mínimamente a estos principios básicos. Evaluar una narrativa contra estos principios básicos y examinarlos a través de sucesivas rondas de revisión en el proceso de EIP (propuesta de mejora de Ethereum), podría ayudar a la comunidad a distinguir a los operadores buenos de los malos y limitar el alcance de los maliciosos en la dirección futura de Ethereum. -Por último, es fundamental que la comunidad de Ethereum permanezca abierta y receptiva para todos los participantes. Una comunidad con guardianes y exclusividad es especialmente vulnerable al ataque social porque es fácil construir narrativas de «nosotros y ellos». El tribalismo y el maximalismo tóxico dañan a la comunidad y erosionan la seguridad de la capa 0. Los ethereans con un interés personal en la seguridad de la red deben ver su conducta en línea y en el mundo real como una contribución directa a la seguridad de la capa 0 de Ethereum. +Por último, es fundamental que la comunidad de Ethereum permanezca abierta y receptiva para todos los participantes. Una comunidad con guardianes y exclusividad es especialmente vulnerable al ataque social porque es fácil construir narrativas de «nosotros y ellos». El tribalismo y el maximalismo tóxico dañan a la comunidad y erosionan la seguridad de la capa 0. Los «ethereans» con interés personal en la seguridad de la red deben ver su conducta en línea y en el mundo real como una contribución directa a la seguridad de la capa 0 de Ethereum. -### Cómo atacar el protocolo {#attacking-the-protocol} +### Atacar el protocolo {#attacking-the-protocol} -Cualquiera puede ejecutar el software cliente de Ethereum. Para añadir un validador a un cliente, un usuario debe participar con 32 ether en el contrato de depósito. Un validador permite a un usuario participar activamente en la seguridad de la red de Ethereum proponiendo y certificando nuevos bloques. El validador ahora tiene una voz que puede usar para influir en el contenido futuro de la cadena de bloques y puede hacerlo honestamente y hacer crecer su bloque de ether a través de recompensas, o puede tratar de manipular el proceso para su propio beneficio, arriesgando su participación. Una forma de montar un ataque es acumular una mayor proporción de la participación total y luego usarla para superar a los validadores honestos. Cuanto mayor sea la proporción de la participación controlada por el atacante, mayor será su poder de voto, especialmente en ciertos hitos económicos que exploraremos más adelante. Sin embargo, la mayoría de los atacantes no podrán acumular suficiente ether para atacar de esta manera, por lo que en su lugar tienen que usar técnicas sutiles para manipular a la mayoría honesta para que actúe de cierta manera. +Cualquiera puede ejecutar el software cliente de Ethereum. Para añadir un validador a un cliente, un usuario debe participar con 32 ether en el contrato de depósito. Un validador permite a un usuario participar activamente en la seguridad de la red de Ethereum proponiendo y certificando nuevos bloques. El validador ahora tiene una voz que puede usar para influir en el contenido futuro de la cadena de bloques y puede hacerlo honestamente y hacer crecer su bloque de ether a través de recompensas, o puede tratar de manipular el proceso para su propio beneficio, arriesgando su participación. Una forma de montar un ataque es acumular una mayor proporción de la participación total y luego usarla para superar a los validadores honestos. Cuanto mayor sea la proporción de la participación controlada por el atacante, mayor será su poder de voto, especialmente en ciertos acontecimientos económicos estelares que exploraremos más adelante. Sin embargo, la mayoría de los atacantes no podrán acumular suficientes ether para atacar de esta manera, por lo que en su lugar tienen que usar técnicas sutiles para coaccionar a la mayoría honesta para que actúe de cierta manera. -Fundamentalmente, todos los ataques de participación pequeña son variaciones sutiles en dos tipos de mal comportamiento del validador: subactividad (no certificar/proponer o hacerlo tarde) o sobreactividad (proponer/acreditar demasiadas veces en una ranura). En sus formas más suave, estas acciones son manejadas fácilmente por el algoritmo de elección de bifurcación y la capa de incentivos, pero hay formas inteligentes de jugar el sistema en beneficio de un atacante. +Fundamentalmente, todos los ataques de participación pequeña son variaciones sutiles de dos tipos de mal comportamiento del validador: subactividad (no certificar/proponer o hacerlo tarde) o sobreactividad (proponer/acreditar demasiadas veces en una ranura). En su versión más descafeinada, estas acciones las maneja fácilmente el algoritmo de elección de bifurcación y la capa de incentivos, no obstante hay formas inteligentes de trucar el sistema en beneficio de un atacante. -### Ataques que utilizan pequeñas cantidades de ETH {#attacks-by-small-stakeholders} +### Ataques utilizando pequeñas cantidades de ETH{#attacks-by-small-stakeholders} -#### reorgs {#reorgs} +#### reorganizaciones{#reorgs} -Varios documentos han explicado los ataques a Ethereum que logran reorgs o retrasos en la finalidad con solo una pequeña proporción del total de ether en participación. Estos ataques generalmente se basan en que el atacante retiene cierta información de otros validadores y luego la libera de alguna manera matizada y/o en algún momento oportuno. Su objetivo es desplazar a algún bloque honesto de la cadena predilecta. [Neuder et al 2020](https://arxiv.org/pdf/2102.02247.pdf) mostró cómo un validador atacante puede crear y certificar un bloque (`B`) para una ranura en particular `n+1`, pero abstenerse de propagarlo a otros nodos de la red. En su lugar, se aferran a ese bloque certificado hasta la siguiente ranura `n+2`. Un validador honesto propone un bloque (`C`) para la ranura `n+2`. Casi simultáneamente, el atacante puede liberar su bloque retenido (`B`) y sus certificados retenidos para ello, y también certificar que `B` es la cabeza de la cadena con sus votos para la ranura `n+2`, negar la existencia de un bloque honesto `C`. Cuando se libera el bloque honesto `D`, el algoritmo de elección de bifurcación ve `D` construido sobre `B` es más pesado que `D` construido sobre `C`. Por lo tanto, el atacante ha logrado eliminar el bloque honesto `C` en la ranura `n+2` de la cadena predilecta utilizando una reorg ex antes de 1 bloque. [Un atacante con el 34 %](https://www.youtube.com/watch?v=6vzXwwk12ZE) de la apuesta tiene muy buenas posibilidades de tener éxito en este ataque, como se explica [en esta nota](https://notes.ethereum.org/plgVdz-ORe-fGjK06BZ_3A#Fork-choice-by-block-slot-pair). En teoría, sin embargo, este ataque podría intentarse con participaciones más pequeñas. [Neuder et al 2020](https://arxiv.org/pdf/2102.02247.pdf) describieron este ataque trabajando con una participación del 30 %, pero más tarde se demostró que era viable con [2 % de la participación total](https://arxiv.org/pdf/2009.04987.pdf) y luego de nuevo [validador único](https://arxiv.org/abs/2110.10086#) Utilizando técnicas de equilibrio que examinaremos en la siguiente sección. +Varios documentos han explicado los ataques a Ethereum que logran reorganizaciones o retrasos en la finalidad con solo una pequeña proporción del total de ether en participación. Estos ataques generalmente se basan en que el atacante retiene cierta información de otros validadores y luego la libera de alguna manera matizada y/o en algún momento oportuno. Su objetivo es desplazar a algún bloque honesto de la cadena predilecta. [Neuder y otros 2020](https://arxiv.org/pdf/2102.02247.pdf) mostraron cómo un validador atacante puede crear y certificar un bloque (`B`) para una ranura específica `n+1`, pero abstenerse de propagarlo a otros nodos en la red. En su lugar, retienen ese bloque certificado hasta el siguiente slot `n+2`. Un validador honesto propone un bloque ('C') para la ranura 'n+2'. Casi simultáneamente, el atacante puede liberar su bloque retenido (`B`) junto con las certificaciones retenidas para dicho bloque y, además, certificar que `B` es la cabecera de la cadena con sus votos para la ranura `n+2`, negando efectivamente la existencia del bloque honesto `C`. Cuando se libera el bloque honesto `D`, el algoritmo de selección de bifurcación detecta que `D` construido sobre `B` es más pesado que `D` construido sobre `C`. Por lo tanto, el atacante ha logrado eliminar el bloque honesto `C` en la ranura `n+2` de la cadena predilecta utilizando una reorganización 1-block ex. [Un atacante con el 34 %](https://www.youtube.com/watch?v=6vzXwwk12ZE) de la participación tiene una alta probabilidad de tener éxito en este ataque, como se explica [en esta nota](https://notes.ethereum.org/plgVdz-ORe-fGjK06BZ_3A#Fork-choice-by-block-slot-pair). En teoría, sin embargo, este ataque podría intentarse con participaciones más pequeñas. [Neuder y otros 2020](https://arxiv.org/pdf/2102.02247.pdf) describieron este ataque funcionando con un 30 % de participación, pero más tarde se demostró que era viable con un [2 % del total de la participación](https://arxiv.org/pdf/2009.04987.pdf) y luego nuevamente para un [único validador](https://arxiv.org/abs/2110.10086#) utilizando técnicas de equilibrio que examinaremos en la siguiente sección. ![ex-ante re-org](reorg-schematic.png) -Un diagrama conceptual del ataque de reorg de un bloque descrito anteriormente (adaptado de https://notes.ethereum.org/plgVdz-ORe-fGjK06BZ_3A#Fork-choice-by-block-slot-pair) +Un diagrama conceptual del ataque de reorganización de un bloque descrito anteriormente (adaptado de https://notes.ethereum.org/plgVdz-ORe-fGjK06BZ_3A#Fork-choice-by-block-slot-pair) -Un ataque más sofisticado puede dividir el validador honesto establecido en grupos discretos que tienen diferentes puntos de vista de la cabeza de la cadena. Esto se conoce como un **ataque de equilibrio**. El atacante espera su oportunidad de proponer un bloque, y cuando llega se equivocan y proponen dos. Envían un bloque a la mitad del conjunto de validadores honestos y el otro bloque a la otra mitad. El equívoco sería detectado por el algoritmo de elección de bifurcación y se recortaría y expulsaría de la red al proponente de bloques, pero los dos bloques todavía existirían y tendrían aproximadamente la mitad del conjunto de validadores que certifican cada bifurcación. Mientras tanto, los validadores maliciosos restantes retienen sus certificaciones. Luego, al liberar selectivamente las certificaciones que favorecen una u otra bifurcación a suficientes validadores justo cuando se ejecuta el algoritmo de elección de bifurcación, inclinan el peso acumulado de las certificaciones a favor de una u otra bifurcación. Esto puede continuar indefinidamente, con los validadores atacantes manteniendo una división uniforme de validadores en las dos bifurcaciones. Dado que ninguna de las dos bifurcaciones puede atraer a una supermayoría de 2/3, la red no finalizaría. +Un ataque más sofisticado puede dividir el validador honesto establecido en grupos discretos que tienen diferentes puntos de vista de la cabeza de la cadena. Esto se conoce como **ataque de equilibrio**. El atacante espera su oportunidad de proponer un bloque, y cuando llega se equivoca y propone dos. Envía un bloque a la mitad del conjunto de validadores honestos y el otro bloque a la otra mitad. E algoritmo de elección de bifurcación detectaría la equivocación y se recortaría y expulsaría de la red al proponente de bloques, sin embargo los dos bloques todavía existirían y tendrían aproximadamente la mitad del conjunto de validadores que certifican cada bifurcación. Mientras tanto, los validadores maliciosos restantes retienen sus certificaciones. Luego, al liberar selectivamente las certificaciones que favorecen una u otra bifurcación a suficientes validadores justo cuando se ejecuta el algoritmo de elección de bifurcación, inclinan el peso acumulado de las certificaciones a favor de una u otra bifurcación. Esto puede continuar indefinidamente, con los validadores atacantes manteniendo una división uniforme de validadores en las dos bifurcaciones. Dado que ninguna de las dos bifurcaciones puede atraer a una supermayoría de 2/3, la red no finalizaría. **Los ataques de rebote** son similares. Los validadores atacantes vuelven a retener los votos. En lugar de liberar los votos para mantener una división uniforme entre dos bifurcaciones, utilizan sus votos en momentos oportunos para justificar los puntos de control que se alternan entre la bifurcación A y la bifurcación B. Este vaivén de justificación entre dos bifurcaciones evita que haya pares de puntos de control de origen y destino justificados que se pueden finalizar en cualquiera de las cadenas, deteniendo la finalidad. -Tanto los ataques de rebote como los de equilibrio dependen de que el atacante tenga un control muy preciso de la sincronización de los mensajes en toda la red, lo cual es poco probable. No obstante, las defensas están integradas en el protocolo en forma de ponderación adicional dada a los avisos de mensajes en comparación con los lentos. Esto se conoce como [impulso del peso del proponente](https://github.com/ethereum/consensus-specs/pull/2730). Para defenderse de los ataques de rebote, se actualizó el algoritmo de selección de bifurcación para que el último punto de control justificado sólo pueda cambiar al de una cadena alternativa durante el [primer 1/3 de las ranuras en cada época](https://ethresear.ch/t/prevention-of-bouncing-attack-on-ffg/6114). Esta condición evita que el atacante ahorre votos para desplegarlos más tarde: el algoritmo de elección de bifurcación simplemente se mantiene fiel al punto de control que eligió en el primer 1/3 de la época durante el cual los validadores más honestos habrían votado. +Tanto los ataques de rebote como los de equilibrio dependen de que el atacante tenga un control muy preciso de la sincronización de los mensajes en toda la red, lo cual es poco probable. No obstante, las defensas están integradas en el protocolo en forma de ponderación adicional dada a los avisos de mensajes en comparación con los lentos. Esto se conoce como [impulso de peso del proponente](https://github.com/ethereum/consensus-specs/pull/2730). Para defenderse contra los ataques de rebote, el algoritmo de selección de bifurcación se ha actualizado de manera que el último punto de control justificado solo puede cambiar al de una cadena alternativa durante el [primer 1/3 de las ranuras en cada época](https://ethresear.ch/t/prevention-of-bouncing-attack-on-ffg/6114). Esta condición evita que el atacante ahorre votos para desplegarlos más tarde: el algoritmo de elección de bifurcación simplemente se mantiene fiel al punto de control que eligió en el primer 1/3 de la época durante el cual los validadores más honestos habrían votado. -Combinadas, estas medidas crean un escenario en el que un proponente de bloques honesto emite su bloque muy rápidamente después del inicio de la ranura, luego hay un período de ~1/3 de una ranura (4 segundos) en el que ese nuevo bloque podría hacer que el algoritmo de elección de bifurcación cambie a otra cadena. Después de esa misma fecha límite, las certificaciones que lleguen de validadores lentos se ponderan en comparación con los que llegaron antes. Esto favorece poderosamente a los proponentes de avisos y validadores a la hora de determinar la cabeza de la cadena y reduce sustancialmente la probabilidad de un ataque de equilibrio o rebote exitoso. +Combinadas, estas medidas crean un escenario en el que un proponente de bloques honesto emite su bloque muy rápidamente después del inicio de la ranura, luego hay un período de ~1/3 de una ranura (4 segundos) en el que ese nuevo bloque podría hacer que el algoritmo de elección de bifurcación cambie a otra cadena. Después de esa misma fecha límite, las certificaciones que lleguen de validadores lentos se ponderan en comparación con aquellas que llegaron antes. Esto favorece poderosamente a los proponentes de avisos y validadores a la hora de determinar la cabeza de la cadena y reduce sustancialmente la probabilidad de un ataque de equilibrio o rebote exitoso. -Vale la pena señalar que el impulso del proponente por sí solo solo se defiende contra las «reorgs baratas», es decir, las intentadas por un atacante con una pequeña participación. De hecho, el impulso de la propuesta en sí mismo puede ser jugado por partes interesadas más grandes. Los autores de [esta publicación](https://ethresear.ch/t/change-fork-choice-rule-to-mitigate-balancing-and-reorging-attacks/11127) describen cómo un atacante con el 7 % de participación puede desplegar sus votos estratégicamente para engañar a los validadores honestos para que construyan su bifurcación, reorganizando un bloque honesto. Este ataque se ideó asumiendo condiciones de latencia ideales que son muy poco probables. Las probabilidades siguen siendo muy altas para el atacante, y la mayor participación también significa más capital en riesgo y un desincentivo económico más fuerte. +Vale la pena señalar que el impulso del proponente por sí solo solo se defiende contra las «reorganizaciones baratas», es decir, las que intenta un atacante con una pequeña participación. De hecho, el impulso de la propuesta en sí mismo pueden lanzarlo partes interesadas más grandes. Los autores de [esta publicación](https://ethresear.ch/t/change-fork-choice-rule-to-mitigate-balancing-and-reorging-attacks/11127) describren como un atacante con el 7 % de la participación puede implementar sus votos estrategicamente para engañar a los validadores honestos, reorganizando bloques confiables, para construir sus bifurcaciones. Este ataque se ideó asumiendo condiciones de latencia ideales que son muy poco probables. Las probabilidades siguen siendo muy altas para el atacante, y la mayor participación también significa más capital en riesgo y un desincentivo económico más fuerte. -También se propuso un [ataque de equilibrio dirigido específicamente a la regla LMD](https://ethresear.ch/t/balancing-attack-lmd-edition/11853), que se sugirió que fuera viable a pesar del aumento del proponente. Un atacante establece dos cadenas competidoras equivocando su propuesta de bloque y propagando cada bloque a aproximadamente la mitad de la red cada uno, estableciendo un equilibrio aproximado entre las bifurcaciones. Luego, los validadores confabulados equivocan sus votos, programándolo para que la mitad de la red reciba sus votos para bifurcación `A` primero y la otra mitad reciba sus votos para bifurcación`B` primero. Dado que la regla LMD descarta la segunda certificación y mantiene solo la primera para cada validador, la mitad de la red ve votos para `A` y ninguno para `B`, la otra mitad ve votos para `B` y ninguno para `A`. Los autores describen la regla LMD que le da al adversario un «poder notable» para montar un ataque de equilibrio. +También se propuso [un ataque de equilibrio específicamente dirigido a la regla LMD](https://ethresear.ch/t/balancing-attack-lmd-edition/11853), el cual sugirió que sería variable a pesar de la intención de quienes proponen. Un atacante establece dos cadenas competidoras equivocando su propuesta de bloque y propagando cada bloque a aproximadamente la mitad de la red cada uno, lo que establece un equilibrio aproximado entre las bifurcaciones. Seguidamente, los validadores que están en colusión confunden sus votos, sincronizándolos de manera que la mitad de la red reciba sus votos para la primera bifurcación `A` y la otra mitad reciba sus votos para la primera bifurcación `B`. Dado que la regla LMD descarta la segunda certificación y conserva solo la primera para cada validador, la mitad de la red observa votos para `A` y ninguno para `B`, mientras que la otra mitad ve votos para `B` y ninguno para `A`. Los autores describen la regla LMD que le da al adversario un «poder notable» para montar un ataque de equilibrio. -Este vector de ataque LMD fue cerrado por [actualizando el algoritmo de elección de bifurcación](https://github.com/ethereum/consensus-specs/pull/2845) para que descarte por completo los validadores equívocos de la consideración de elección de bifurcación. Los validadores equívocos también tienen su influencia futura descontada por el algoritmo de elección de bifurcación. Esto evita el ataque de equilibrio descrito anteriormente, al tiempo que mantiene la resiliencia contra los ataques avalanchas. +Este vector de ataque LMD se cerró mediante [la actualización del algoritmo de selección de bifurcación](https://github.com/ethereum/consensus-specs/pull/2845) para que descarte por completo a los validadores que confunden sus votos de la consideración en la selección de bifurcación. Los validadores equívocos también tienen su influencia futura descontada por el algoritmo de elección de bifurcación. Esto evita el ataque de equilibrio descrito anteriormente, al tiempo que mantiene la resiliencia contra los ataques avalanchas. -Otra clase de ataque, llamada [**ataques de avalancha**](https://ethresear.ch/t/avalanche-attack-on-proof-of-stake-ghost/11854/3), se describió en un artículo[en marzo de 2022](https://arxiv.org/pdf/2203.01315.pdf). Para montar un ataque avalancha, el atacante necesita controlar a varios proponentes de bloques consecutivos. En cada una de las ranuras de los proponentes de bloque, el atacante retiene su bloque, recogiéndolos hasta que la cadena honesta alcance un peso de subárbol igual con los bloques retenidos. Luego, los bloques retenidos se liberan para que sean equívocos al máximo. Los autores sugieren que el impulso del proponente, la defensa principal contra los ataques de equilibrio y de rebote no protegen contra algunas variantes de ataques avalancha. Sin embargo, los autores también solo demostraron el ataque a una versión altamente idealizada del algoritmo de selección de bifurcación de Ethereum (usaron GHOST sin LMD). +Otra clase de ataque conocido como [**ataques de avalancha**](https://ethresear.ch/t/avalanche-attack-on-proof-of-stake-ghost/11854/3) se describió en un [documento de marzo de 2022](https://arxiv.org/pdf/2203.01315.pdf). Para montar un ataque avalancha, el atacante necesita controlar a varios proponentes de bloques consecutivos. En cada una de las ranuras de los proponentes de bloque, el atacante retiene su bloque, recogiéndolo hasta que la cadena honesta alcanza un peso de subárbol igual con los bloques retenidos. Seguidamente, los bloques retenidos se liberan para que sean equívocos al máximo. Los autores sugieren que el impulso del proponente, la defensa principal contra los ataques de equilibrio y de rebote no protegen contra algunas variantes de ataques avalancha. Sin embargo, los autores solo demostraron asímismo el ataque a una versión altamente idealizada del algoritmo de selección de bifurcación de Ethereum (usaron GHOST sin LMD). -El ataque avalancha se ve mitigado por la parte LMD del algoritmo de elección de bifurcación LMD-GHOST. LMD significa «last message driven» (último mensaje dirigido) y se refiere a una tabla mantenida por cada validador que contiene el último mensaje recibido de otros validadores. Ese campo solo se actualiza si el nuevo mensaje es de una ranura posterior a la que ya está en la tabla para un validador en particular. En la práctica, esto significa que en cada ranura, el primer mensaje recibido es el que aceptó y cualquier mensaje adicional es una equivocación que se debe ignorar. Dicho de otra manera, los clientes de consenso no cuentan las equivocaciones: utilizan el primer mensaje que llega de cada validador y las equivocaciones simplemente se descartan, evitando los ataques avalancha. +El ataque de avalancha se ve mitigado por la parte LMD del algoritmo de elección de bifurcación LMD-GHOST. LMD significa «last message driven» (último mensaje dirigido) y se refiere a una tabla mantenida por cada validador que contiene el último mensaje recibido de otros validadores. Ese campo solo se actualiza si el nuevo mensaje es de una ranura posterior a la que ya está en la tabla para un validador en particular. En la práctica, esto significa que en cada ranura, el primer mensaje recibido es el que se ha aceptado y cualquier mensaje adicional es una equivocación que se debe ignorar. Dicho de otra manera, los clientes de consenso no cuentan las equivocaciones: utilizan el primer mensaje que llega de cada validador y las equivocaciones simplemente se descartan, evitando los ataques avalancha. -Hay varias otras posibles actualizaciones futuras de la regla de elección de bifurcación que podrían aumentar la seguridad proporcionada por el impulsor-proponente. Una es [view-merge](https://ethresear.ch/t/view-merge-as-a-replacement-for-proposer-boost/13739), donde los certificadores congelan su vista de la opción de bifurcación `n` segundos antes del inicio de una ranura y el proponente luego ayuda a sincronizar la vista de la cadena a través de la red. Otra actualización potencial es [finalidad de una sola ranura](https://notes.ethereum.org/@vbuterin/single_slot_finality), que protege contra los ataques basados en el tiempo del mensaje al finalizar la cadena después de una sola ranura. +Hay distintas actualizaciones posibles futuras de la regla de elección de bifurcación que podrían aumentar la seguridad proporcionada por el impulsor-proponente. Una de ellas es [view-merge](https://ethresear.ch/t/view-merge-as-a-replacement-for-proposer-boost/13739), donde los certificadores congelan su vista de la selección de bifurcación `n` segundos antes del comienzo de una ranura, y quien propone luego ayuda a sincronizar la vista de la cadena a través de la red. Otra posible actualización es [finalidad de un solo slot](https://notes.ethereum.org/@vbuterin/single_slot_finality), que protege contra ataques basados en el tiempo de los mensajes al finalizar la cadena después de solo una ranura. -#### Retraso de finalidad {#finality-delay} +#### Retraso de finalidad{#finality-delay} -[El mismo documento](https://econcs.pku.edu.cn/wine2020/wine2020/Workshop/GTiB20_paper_8.pdf) que describió por primera vez el ataque de reorganización de un solo bloque de bajo coste también describió un ataque de retraso de finalidad (también conocido como «fracaso de vivacidad») que se basa en que el atacante sea el proponente de bloques para un bloque de límite de época. Esto es fundamental porque estos bloques de límites de época se convierten en los puntos de control que Casper FFG utiliza para finalizar partes de la cadena. El atacante simplemente retiene su bloqueo hasta que suficientes validadores honestos utilicen sus votos de FFG a favor del bloqueo límite de la época anterior como el objetivo de finalización actual. Luego liberan su bloqueo retenido. Certifican su bloqueo y los validadores honestos restantes también crean bifurcaciones con diferentes puntos de control de destino. Si lo cronometran bien, evitarán la finalidad, porque no habrá una supermayoría de 2/3 que acredite ninguna de las dos bifurcaciones. Cuanto menor sea la participación, más preciso debe ser el momento, porque el atacante controla menos certificaciones directamente, y menor es la probabilidad de que el atacante controle al validador que propone un determinado bloque de límite de época. +[El mismo documento] +(https://econcs.pku.edu.cn/wine2020/wine2020/Workshop/GTiB20_paper_8.pdf) que primero relató el ataque de reorganización de un solo bloque de bajo coste también describió un ataque de retraso de finalidad (también conocido como «liveness failure» en inglés), el cual depende de que el atacante sea quien propone el bloque para un bloque límite de época. Esto es fundamental porque estos bloques de límites de época se convierten en los puntos de control que Casper FFG utiliza para finalizar partes de la cadena. El atacante simplemente retiene su bloqueo hasta que suficientes validadores honestos utilicen sus votos de FFG a favor del bloqueo límite de la época anterior como el objetivo de finalización actual. Luego liberan su bloqueo retenido. Certifican su bloqueo y los validadores honestos restantes también crean bifurcaciones con diferentes puntos de control de destino. Si lo sincronizan bien, evitarán la finalidad, porque no habrá una supermayoría de 2/3 que certifique ninguna de las dos bifurcaciones. Cuanto menor sea la participación, más precisa debe ser la sincronización, porque el atacante controla menos certificaciones directamente, y menor es la probabilidad de que el atacante controle al validador que propone un determinado bloque de límite de época. -#### Ataques de largo alcance {#long-range-attacks} +#### Ataques de alto alcance {#long-range-attacks} -También hay una clase de ataque específico para las cadenas de bloques de prueba de participación que involucra a un validador que participó en el bloque inicial manteniendo una bifurcación separada de la cadena de bloques junto con la honesta, convenciendo finalmente al validador honesto de cambiar a ella en algún momento oportuno mucho más tarde. Este tipo de ataque no es posible en Ethereum debido al dispositivo de finalidad que garantiza que todos los validadores estén de acuerdo en el estado de la cadena honesta a intervalos regulares («puntos de control»). Este simple mecanismo neutraliza a los atacantes de largo alcance, porque los clientes de Ethereum simplemente no reorganizan los bloques finalizados. Los nuevos nodos que se unen a la red lo hacen encontrando un hash de estado reciente fiable (un «[punto de control](https://blog.ethereum.org/2014/11/25/proof-stake-learned-love-weak-subjectivity/) de sujetividad débil») y usándolo como un bloque de pseudoinicial para construir sobre él. Esto crea una «pasarela de confianza» para que un nuevo nodo entre en la red antes de que pueda comenzar a verificar la información por sí mismo. +Existe también una clase de ataque específico para las cadenas de bloques de prueba de participación dirigido a un validador que participó en el bloque inicial, manteniendo una bifurcación separada de la cadena de bloques junto con la honesta, en el que se logra finalmente que el validador honesto cambié a ella en algún momento oportuno mucho más adelante. Este tipo de ataque no puede producirse en Ethereum, debido al dispositivo de finalidad que garantiza que todos los validadores estén de acuerdo en el estado de la cadena honesta a intervalos regulares («puntos de control»). Este simple mecanismo neutraliza a los atacantes de largo alcance, porque los clientes de Ethereum simplemente no reorganizan los bloques finalizados. Los nuevos nodos que se unen a la red lo hacen encontrando un hash de estado reciente de confianza (un “[punto de referencia de debilidad subjetiva](https://blog.ethereum.org/2014/11/25/proof-stake-learned-love-weak-subjectivity/)”) y usándolo como un bloque pseudo-origen sobre el cual construir. Esto crea una «pasarela de confianza» para que un nuevo nodo entre en la red antes de que pueda comenzar a verificar la información por sí mismo. -#### Denegación de servicio {#denial-of-service} +#### Negación del servicio {#denial-of-service} -El mecanismo PoS de Ethereum selecciona un solo validador del grupo de validadores totales establecido para ser un proponente de bloques en cada ranura. Esto se puede calcular utilizando una función conocida públicamente y es posible que un adversario identifique al siguiente proponente de bloques un poco antes de su propuesta de bloques. Luego, el atacante puede enviar correo basura al proponente del bloque para evitar que intercambie información con sus compañeros. Para el resto de la red, parecería que el proponente de bloques estuviera fuera de línea y la ranura simplemente se quedaría vacía. Esto podría ser una forma de censura contra validadores específicos, impidiéndoles agregar información a la cadena de bloques. La implementación de elecciones de un solo líder secreto (SSLE) o elecciones de no solo un líder secreto mitigará los riesgos de DoS, porque solo el proponente del bloque sabe que han sido seleccionados y la selección no se puede conocer de antemano. Esto aún no se ha implementado, pero es un área activa de [investigación y desarrollo](https://ethresear.ch/t/secret-non-single-leader-election/11789). +El mecanismo PoS de Ethereum selecciona un solo validador del grupo de validadores totales establecido para ser un proponente de bloques en cada ranura. Esto se puede calcular utilizando una función conocida públicamente y es posible que un adversario identifique al siguiente proponente de bloques un poco antes de su propuesta de bloques. Luego, el atacante puede enviar correo basura al proponente del bloque para evitar que intercambie información con sus compañeros. Para el resto de la red, parecería que el proponente de bloques estuviera fuera de línea y que la ranura se quedara simplemente vacía. Lo que podría ejercer como forma de censura contra validadores específicos, impidiéndoles agregar información a la cadena de bloques. La implementación de elecciones de un solo líder secreto (SSLE) o elecciones de no solo un líder secreto mitigará los riesgos de DoS, porque solo el proponente del bloque sabe que han sido seleccionados y la selección no se puede conocer de antemano. Esto aún no se ha implementado, sin embargo, es un área activa de [I+D](https://ethresear.ch/t/secret-non-single-leader-election/11789). -Todo esto apunta al hecho de que es muy difícil atacar con éxito a Ethereum con una pequeña participación. Los ataques viables que se han descrito aquí requieren un algoritmo de elección de bifurcación idealizado, condiciones de red improbables o los vectores de ataque ya se han cerrado con parches relativamente menores para el software del cliente. No se descarta, por descontado, la posibilidad de que existan días cero en la naturaleza, pero demuestra el nivel extremadamente alto de aptitud técnica, el conocimiento de la capa de consenso y la suerte que se requiere para que un atacante de participación minoritaria sea efectivo. Desde la perspectiva de un atacante, su mejor apuesta podría ser acumular la mayor cantidad de ether posible y regresar armado con una mayor proporción de la participación total. +Todo esto apunta al hecho de que es muy difícil atacar con éxito a Ethereum con una pequeña participación. Los ataques viables que se han descrito aquí requieren un algoritmo de elección de bifurcación idealizado, unas condiciones de red improbables o vectores de ataque que ya se han cerrado con parches relativamente menores para el software del cliente. No se descarta, por descontado, la posibilidad de que existan días cero no planificados, pero demuestra el nivel extremadamente alto de habilidades técnicas, el conocimiento de la capa de consenso y la suerte que se requiere para que un atacante de participación minoritaria sea efectivo. Desde la perspectiva de un atacante, su mejor apuesta podría ser acumular la mayor cantidad de ether posible y regresar armado con una mayor proporción de la participación total. -### Atacantes que usan >= 33 % de la participación total {#attackers-with-33-stake} +### Atacantes que usan >=33 % del total de participación {#attackers-with-33-stake} -Todos los ataques mencionados anteriormente en este artículo tienen más probabilidades de tener éxito cuando el atacante tiene más ether en juego para votar, y más validadores que podrían ser elegidos para proponer bloques en cada ranura. Por lo tanto, un validador malicioso podría tener como objetivo controlar la mayor cantidad de ether en participación posible. +Todos los ataques mencionados anteriormente en este artículo tienen más probabilidades de tener éxito cuando el atacante tiene más ether en juego para votar, y más validadores que podrían ser elegidos para proponer bloques en cada ranura. Por lo tanto, un validador malicioso podría tener como objetivo el control de la mayor cantidad de ether en participación posible. -El 33 % del ether en participación es un punto de referencia para un atacante porque con algo mayor que esta cantidad tienen la capacidad de evitar que la cadena finalice sin tener que controlar finamente las acciones de los otros validadores. Simplemente pueden desaparecer todos juntos. Si 1/3 o más del ether en participación está atestado maliciosamente o falla en ser atestado, entonces no puede existir una supermayoría de 2/3 y la cadena no puede finalizar. La defensa contra esto es la pérdida de inactividad. La pérdida de inactividad identifica a aquellos validadores que no están certificando o están certificando lo contrario que la mayoría. El ether apostado en propiedad de estos validadores no certificadores se desvanece gradualmente hasta que finalmente representan colectivamente menos de 1/3 del total para que la cadena pueda finalizar de nuevo. +El 33 % del ether en participación es un punto de referencia para un atacante, porque con un porcentaje ligeramente superior tiene la capacidad de evitar que la cadena finalice sin tener que controlar finamente las acciones de los otros validadores. Simplemente pueden desaparecer todos juntos. Si 1/3 o más del ether en participación está certificado maliciosamente o no logra certificarlo, entonces no puede existir una supermayoría de 2/3 y la cadena no puede finalizar. La forma de defenderse de ello es la pérdida de inactividad. La pérdida de inactividad identifica a aquellos validadores que no logran certificar o que están certificando lo contrario que la mayoría. El ether apostado en propiedad de estos validadores no certificadores se desvanece gradualmente hasta que finalmente representa colectivamente menos de 1/3 del total para que la cadena pueda finalizar de nuevo. El propósito de la pérdida de inactividad es hacer que la cadena finalice de nuevo. No obstante, el atacante también pierde una parte de su ether apostado. La inactividad persistente entre los validadores que representan el 33 % del total de ether apostado es muy cara, a pesar de que los validadores no están recortados. -Suponiendo que la red Ethereum sea asíncrona (es decir, que haya retrasos entre los mensajes que se envían y se reciben), un atacante que controla el 34 % de la participación total podría causar una doble finalidad. Esto se debe a que el atacante puede equivocarse cuando se le elige para ser un productor de bloques, y luego votar dos veces con todos sus validadores. Esto crea una situación en la que existe una bifurcación de la cadena de bloques, cada una con el 34 % del ether en participación votando por ella. Cada bifurcación solo requiere que el 50 % de los validadores restantes voten a su favor para que ambas bifurcaciones sean apoyadas por una supermayoría, en cuyo caso ambas cadenas pueden finalizar (porque el 34 % de los validadores atacantes + la mitad del 66 % restante = al 67 % en cada bifurcación). Los bloques en competencia tendrían que ser recibidos por alrededor del 50% de los validadores honestos, por lo que este ataque es viable solo cuando el atacante tiene cierto grado de control sobre el momento en que los mensajes se propagan a través de la red para que puedan empujar a la mitad de los validadores honestos en cada cadena. El atacante destruiría necesariamente toda su participación (34% de ~10 millones de ether con el conjunto de validadores de hoy) para lograr esta doble finalidad porque el 34% de sus validadores tendrían doble voto simultáneamente, una ofensa que se puede cortar con la máxima penalización de correlación. La defensa contra este ataque es el gran coste de destruir el 34 % del total de ether apostado. Recuperarse de este ataque requeriría que la comunidad de Ethereum coordinara «fuera de banda» y acordara seguir una u otra de las bifurcaciones e ignorar la otra. +Suponiendo que la red Ethereum sea asíncrona (es decir, que haya retrasos entre los mensajes que se envían y se reciben), un atacante que controla el 34 % de la participación total podría causar una doble finalidad. Esto se debe a que el atacante puede equivocarse cuando se le elige para ser un productor de bloques, y luego votar dos veces con todos sus validadores. Lo que produce una situación en la que existe una bifurcación de la cadena de bloques, cada una con el 34 % del ether en participación votando por ella. Cada bifurcación solo requiere que el 50 % de los validadores restantes voten a su favor para que ambas bifurcaciones sean apoyadas por una supermayoría, en cuyo caso ambas cadenas pueden finalizar (porque el 34 % de los validadores atacantes + la mitad del 66 % restante = al 67 % en cada bifurcación). Alrededor del 50 % de los validadores honestos tendrían que recibir los bloques en competencia, por lo que este ataque es viable solo cuando el atacante tiene cierto grado de control sobre el momento en que los mensajes se propagan a través de la red para que puedan empujar a la mitad de los validadores honestos en cada cadena. El atacante destruiría necesariamente toda su participación (34 % de ~10 millones de ether con el conjunto de validadores de hoy) para lograr esta doble finalidad, porque el 34 % de sus validadores tendrían doble voto simultáneamente: una ofensa que se puede castigar con la máxima penalización de correlación. La defensa contra este ataque es el gran coste de destruir el 34 % del total de ether apostado. Recuperarse de este ataque requeriría que la comunidad de Ethereum coordinara «fuera de banda» y acordara seguir una u otra de las bifurcaciones e ignorar la otra. -### Atacantes que usan ~50% de la participación total {#attackers-with-50-stake} +### Atacantes que usan el ~50 % del total de la participación {#attackers-with-50-stake} -Al 50 % del ether en participación, un grupo malicioso de validadores podría teóricamente dividir la cadena en dos bifurcaciones de igual tamaño y luego simplemente usar todo su 50 % de participación para votar en contra del conjunto de validadores honestos, manteniendo así las dos bifurcaciones y evitando la finalidad. La fuga de inactividad en ambas bifurcaciones eventualmente llevaría a ambas cadenas a finalizar. Llegados a este punto, la única opción es recurrir a una recuperación social. +Al 50 % del ether en participación, un grupo malicioso de validadores podría teóricamente dividir la cadena en dos bifurcaciones de igual tamaño y luego simplemente usar su 50 % de participación entero para votar en contra del conjunto de validadores honestos, manteniendo así las dos bifurcaciones y evitando la finalidad. La fuga de inactividad en ambas bifurcaciones eventualmente llevaría a ambas cadenas a finalizar. Llegados a este punto, la única opción es recurrir a una recuperación social. -Es muy poco probable que un grupo adversario de validadores pudiera controlar constantemente con precisión el 50 % de la participación total, dado un grado de flujo en los números de validadores honestos, la latencia de la red, etc. El enorme coste de montar un ataque de este tipo, combinado con la baja probabilidad de éxito parece ser un importante freno para un atacante racional, especialmente cuando una pequeña inversión adicional en la obtención de _más de_ 50 % desbloquea mucha más potencia. +Es muy poco probable que un grupo adversario de validadores pueda controlar de manera uniforme el 50 % exacto del total de la participación, dado el grado de fluctuación en el número de validadores honestos, la latencia de la red, etc. El enorme coste de llevar a cabo un ataque de este tipo, combinado con la baja probabilidad de éxito, parece ser un fuerte desincentivo para un atacante racional, especialmente cuando una pequeña inversión adicional para obtener _más de_ 50 % desbloquea mucho más poder. -Con el >50 % de la participación total, el atacante podría dominar el algoritmo de elección de bifurcación. En este caso, el atacante podría dar fe con el voto mayoritario, dándoles el control suficiente para hacer reorgs cortas sin necesidad de engañar a los clientes honestos. Los validadores honestos seguirían su ejemplo porque su algoritmo de elección de bifurcación también consideraría a la cadena favorita del atacante como la más pesada, por lo que la cadena podría finalizar. Esto permite al atacante censurar ciertas transacciones, hacer reorganizaciones de corto alcance y extraer el MEV máximo reordenando los bloques a su favor. La defensa contra esto es el enorme coste de una participación mayoritaria (actualmente poco menos de 19.000 millones de dólares) que ponen en riesgo un atacante, porque es probable que la capa social intervenga y adopte una bifurcación de minoría honesta, devaluando dramáticamente la participación del atacante. +Con >50 % del total de la participación, el atacante podría controlar el algoritmo de selección de bifurcación. En este caso, el atacante podría certificar con el voto mayoritario, dándoles el control suficiente para hacer reorganizaciones cortas sin necesidad de engañar a los clientes honestos. Los validadores honestos seguirían su ejemplo porque su algoritmo de elección de bifurcación también consideraría a la cadena favorita del atacante como la más pesada, por lo que la cadena podría finalizar. Esto permite al atacante censurar ciertas transacciones, hacer reorganizaciones de corto alcance y extraer el MEV máximo reordenando los bloques a su favor. La defensa contra esto es el enorme coste de una participación mayoritaria (actualmente poco menos de 19.000 millones de dólares) que ponen en riesgo un atacante, porque es probable que la capa social intervenga y adopte una bifurcación de minoría honesta, con la consiguente y notable devaluación de la participación del atacante. -### Atacantes que usan >=66 % de la participación total {#attackers-with-66-stake} +### Atacantes que usan >=66 % del total de la participación {#attackers-with-66-stake} -Un atacante con el 66 % o más del total de ether apostado puede finalizar su cadena preferida sin tener que coaccionar a ningún validador honesto. El atacante puede votar por su bifurcación preferida y luego finalizarla, simplemente porque puede votar con una supermayoría deshonesta. Como parte interesada de la supermayoría, el atacante siempre controlaría el contenido de los bloques finalizados, con el poder de gastar, rebobinar y gastar de nuevo, censurar ciertas transacciones y reorganizar la cadena a voluntad. Al comprar ether adicional para controlar el 66 % en lugar del 51 %, el atacante está comprando efectivamente la capacidad de hacer antiguas reorgs pasadas y reversiones de finalidad (es decir, cambiar el pasado, así como controlar el futuro). Las únicas defensas reales aquí son el enorme coste del 66 % del total de ether en participación, y la opción de recurrir a la capa social para coordinar la adopción de una bifurcación alternativa. Podemos ahondar en esto con más detalle en la siguiente sección. +Un atacante con el 66 % o más del total de ether apostado puede finalizar su cadena preferida sin tener que coaccionar a ningún validador honesto. El atacante puede votar por su bifurcación preferida y luego finalizarla, simplemente porque puede votar con una supermayoría deshonesta. Como parte interesada de la supermayoría, el atacante siempre controlaría el contenido de los bloques finalizados, con el poder de gastar, rebobinar y gastar de nuevo, censurar ciertas transacciones y reorganizar la cadena a su antojo. Al comprar ether adicional para controlar el 66 % en lugar del 51 %, el atacante está comprando la capacidad de hacer antiguas reorganizaciones pasadas y reversiones de finalidad (es decir, cambiar el pasado, así como controlar el futuro). Las únicas defensas reales existentes son el enorme coste del 66 % del total de ether en participación, y la opción de recurrir a la capa social para coordinar la adopción de una bifurcación alternativa. Ahondemos en ello con más detalle en la siguiente sección. -## Las personas: la última línea de defensa {#people-the-last-line-of-defense} +## Personas: la última línea de defensa{#people-the-last-line-of-defense} -Si los validadores deshonestos logran finalizar su versión preferida de la cadena, la comunidad de Ethereum se encuentra en una situación difícil. La cadena predilecta incluye una sección deshonesta incorporada en su historia, mientras que los validadores honestos pueden terminar siendo castigados por certificar una cadena alternativa (honesta). Tenga en cuenta que una cadena finalizada pero incorrecta también podría surgir de un error en un cliente mayoritario. Al fin y al cabo, la última alternativa es confiar en la capa social, la capa 0, para resolver la situación. +Si los validadores deshonestos logran finalizar su versión preferida de la cadena, la comunidad de Ethereum se encuentra en una situación difícil. La cadena predilecta incluye una sección deshonesta incorporada en su historia, mientras que los validadores honestos pueden terminar siendo castigados por certificar una cadena alternativa (honesta). Tenga en cuenta que una cadena finalizada pero incorrecta también podría surgir de un error en un cliente mayoritario. Al fin y al cabo, la última alternativa es confiar en la capa social —es decir, la capa 0— para resolver la situación. -Uno de los puntos fuertes del consenso PoS de Ethereum es que hay una [gama de estrategias defensivas](https://youtu.be/1m12zgJ42dI?t=1712) que la comunidad puede emplear frente a un ataque. Una respuesta mínima podría ser el obligar a salir por la fuerza a los validadores de los atacantes de la red sin ninguna penalización adicional. Para volver a entrar en la red, el atacante tendría que unirse a una cola de activación que garantice que el conjunto de validadores crezca gradualmente. Por ejemplo, agregar suficientes validadores para duplicar la cantidad de ether apostado tarda unos 200 días, comprando efectivamente los validadores honestos 200 días antes de que el atacante pueda intentar otro ataque del 51 %. No obstante, la comunidad también podría optar por penalizar al atacante más duramente, revocando las recompensas pasadas o quemando alguna parte (hasta el 100 %) de su capital en participación. +Una de las fortalezas del consenso PoS de Ethereum es que existen [variedad de estrategias defensivas](https://youtu.be/1m12zgJ42dI?t=1712) que la comunidad puede implementar frente a un ataque. Una respuesta mínima podría ser el obligar a salir por la fuerza a los validadores de los atacantes de la red sin ninguna penalización adicional. Para volver a entrar en la red, el atacante tendría que unirse a una cola de activación que garantiza que el conjunto de validadores crezca gradualmente. Por ejemplo, añadir la cantidad de validadores suficientes para duplicar la cantidad de ether apostado tarda unos 200 días, lo que compra efectivamente los validadores honestos 200 días antes de que el atacante pueda intentar otro ataque del 51 %. No obstante, la comunidad también podría optar por penalizar más duramente al atacante, revocando las recompensas pasadas o quemando alguna parte (hasta el 100 %) de su capital en participación. -Cual sea la penalización impuesta al atacante, la comunidad también tiene que decidir juntos si la cadena deshonesta, a pesar de ser la favorecida por el algoritmo de elección de bifurcación codificado en los clientes de Ethereum, es de hecho inválida y que la comunidad debería construir encima de la cadena honesta en su lugar. Los validadores honestos podrían acordar colectivamente construir sobre una bifurcación de la cadena de bloques Ethereum aceptada por la comunidad que podría, por ejemplo, haberse bifurcado de la cadena canónica antes de que comenzara el ataque o eliminar por la fuerza los validadores de los atacantes. Se incentivaría a los validadores honestos a construir sobre esta cadena, porque evitarían las penalizaciones que se les aplican por no certificar ―y con razón― la cadena del atacante. Los intercambios, los atajos y las aplicaciones construidas en Ethereum presumiblemente preferirían estar en la cadena honesta y seguirían a los validadores honestos a la cadena de bloques honesta. +Sea cual sea la penalización impuesta al atacante, la comunidad también tiene que decidir juntos si la cadena deshonesta —a pesar de ser la favorecida por el algoritmo de elección de bifurcación codificado en los clientes de Ethereum— es, de hecho, inválida y si la comunidad debería construir encima de la cadena honesta en su lugar. Los validadores honestos podrían acordar colectivamente construir sobre una bifurcación de la cadena de bloques Ethereum aceptada por la comunidad que podría, por ejemplo, haberse bifurcado de la cadena predilecta antes de que comenzara el ataque o eliminar por la fuerza los validadores de los atacantes. Se incentivaría a los validadores honestos a construir sobre esta cadena, porque evitarían las penalizaciones que se les aplican por no certificar ―y con razón― la cadena del atacante. Los intercambios, los atajos y las aplicaciones construidas en Ethereum presumiblemente preferirían estar en la cadena honesta y seguirían a los validadores honestos a la cadena de bloques honesta. -Sin embargo, este sería un desafío sustancial para la gobernanza. Algunos usuarios y validadores sin duda perderían como resultado del cambio de regreso a la cadena honesta, las transacciones en bloques validadas después del ataque podrían potencialmente revertirse, interrumpiendo la capa de la aplicación, y simplemente socava la ética de algunos usuarios que tienden a creer que «el código es normativo». Lo más probable es que los intercambios y las aplicaciones hayan vinculado las acciones fuera de la cadena a las transacciones en cadena que ahora se pueden revertir, iniciando una cascada de retractaciones y revisiones que serían difíciles de deshacer de manera justa, especialmente si las ganancias mal obtenidas se han mezclado, se han depositado en DeFi u otros derivados con efectos secundarios para los usuarios honestos. Sin duda, algunos usuarios, tal vez incluso institucionales, ya se habrían beneficiado de la cadena deshonesta, ya sea por ser astutos o por casualidad fortuita, y podrían oponerse a una bifurcación para proteger sus ganancias. Ha habido llamadas para ensayar la respuesta de la comunidad a los ataques del >51% para que se pudiera ejecutar rápidamente una mitigación coordinada sensata. Vitalik ha vislumbrado un poco de luz hablando al respecto en ethresear.ch [aquí](https://ethresear.ch/t/timeliness-detectors-and-51-attack-recovery-in-blockchains/6925) y [aquí](https://ethresear.ch/t/responding-to-51-attacks-in-casper-ffg/6363) y en Twitter [aquí](https://twitter.com/skylar_eth/status/1551798684727508992?s=20&t=oHZ1xv8QZdOgAXhxZKtHEw). El objetivo de dar una respuesta social coordinada debe ser muy específico y focalizarse sobre el castigo del atacante y la minimización de los efectos para otros usuarios. +Sin embargo, este sería un desafío sustancial para la gobernanza. Algunos usuarios y validadores sin duda perderían como resultado del cambio de regreso a la cadena honesta, las transacciones en bloques validadas después del ataque podrían potencialmente revertirse, interrumpiendo la capa de la aplicación, y esto simplemente socava la ética de algunos usuarios que tienden a creer que «el código es normativo». Lo más probable es que los intercambios y las aplicaciones hayan vinculado las acciones fuera de la cadena a las transacciones en cadena que ahora se pueden revertir, iniciando una cascada de retractaciones y revisiones que serían difíciles de deshacer de manera justa, especialmente si las ganancias mal obtenidas se han mezclado, se han depositado en DeFi u otros derivados con efectos secundarios para los usuarios honestos. Sin duda, algunos usuarios, tal vez incluso institucionales, ya se habrían beneficiado de la cadena deshonesta, ya sea por ser astutos o por pura casualidad, y podrían oponerse a una bifurcación para proteger sus ganancias. Ha habido solicitudes para ensayar la respuesta de la comunidad a los ataques de más del 51 % para que se pueda ejecutar rápidamente una mitigación coordinada y sensata. Existe una discusión convincente por parte de Vitalik en ethresear.ch [aquí](https://ethresear.ch/t/timeliness-detectors-and-51-attack-recovery-in-blockchains/6925) y [aquí](https://ethresear.ch/t/responding-to-51-attacks-in-casper-ffg/6363) y en Twitter [aquí](https://twitter.com/skylar_eth/status/1551798684727508992?s=20&t=oHZ1xv8QZdOgAXhxZKtHEw). El objetivo de dar una respuesta social coordinada debe ser muy específico y centrarse en el castigo del atacante y la minimización de los efectos para otros usuarios. -La gobernanza es un tema de por sí complicado. Gestionar una respuesta de emergencia de capa 0 a una cadena de finalización deshonesta sería, sin duda, un desafío para la comunidad de Ethereum, pero [ha sucedido](/history/#dao-fork-summary) - [dos veces](/history/#tangerine-whistle) en la historia de Ethereum. +La gobernanza es un tema de por sí complicado. Gestionar una respuesta de emergencia de capa 0 a una cadena de finalización deshonesta sin duda sería un desafío para la comunidad de Ethereum, pero [ha sucedido](/history/#dao-fork-summary) —[dos veces](/history/#tangerine-whistle)— en la historia de Ethereum). No obstante, hay algo bastante satisfactorio en una contingencia en la vida real. Al fin y al cabo, incluso con este excelente bloque de tecnología que tenemos, si alguna vez sucediera lo peor, la gente real tendría que coordinar su salida. ## Resumen {#summary} -Esta página explora algunas de las formas que los atacantes podrían intentar explotar el protocolo de prueba de participación de Ethereum. Se exploraron los reorgs y los retrasos en la finalidad de los atacantes con proporciones cada vez mayores del total de ether en participación. En general, un atacante más rico tiene más posibilidades de éxito porque su participación se traduce en el poder de voto que puede usar para influir en el contenido de futuros bloques. En ciertas cantidades de umbral de etherapostado, los niveles de potencia del atacante suben: +Esta página explora algunas de las formas en las que los atacantes podrían intentar explotar el protocolo de prueba de participación de Ethereum. Se exploraron las reorganizaciones y los retrasos en la finalidad de los atacantes con proporciones cada vez mayores del total de ether en participación. En general, un atacante más rico tiene más posibilidades de éxito, porque su participación se traduce en el poder de voto que puede usar para influir en el contenido de futuros bloques. En ciertas cantidades de umbral de ether apostado, los niveles de potencia del atacante suben: 33 %: retraso de finalidad @@ -147,17 +151,17 @@ Esta página explora algunas de las formas que los atacantes podrían intentar e También hay una serie de ataques más sofisticados que requieren pequeñas cantidades de ether en participación, pero dependen de un atacante muy sofisticado que tenga un control fino sobre la secuenciación de los mensajes para influir en el validador honesto establecido a su favor. -En general, a pesar de estos posibles vectores de ataque, el riesgo de un ataque exitoso es bajo, ciertamente menor que los equivalentes de prueba de trabajo. Esto se debe al enorme costo del etyer en participación puesto en riesgo por un atacante con el objetivo de abrumar a los validadores honestos con su poder de voto. La capa de incentivo integrada de "zanahoria y palo" protege contra la mayoría de las malas conductas, especialmente para los atacantes de baja participación. También es poco probable que los ataques de rebote y equilibrio más sutiles tengan éxito porque las condiciones reales de la red hacen que el control fino de la entrega de mensajes a subconjuntos específicos de validadores sea muy difícil de lograr, y los equipos de clientes han cerrado rápidamente los vectores conocidos de rebote, equilibrio y ataques avalancha con parches simples. +En general, a pesar de estos posibles vectores de ataque, el riesgo de un ataque exitoso es bajo, ciertamente menor que los equivalentes de prueba de trabajo. Esto se debe al enorme coste del ether apostado, puesto en riesgo por un atacante con el objetivo de abrumar a los validadores honestos con su poder de voto. La capa de incentivo integrada de «zanahoria y palo» protege contra la mayoría de las malas conductas, especialmente para los atacantes de baja participación. También es poco probable que los ataques de rebote y equilibrio más sutiles tengan éxito, porque las condiciones reales de la red hacen que el control preciso de la entrega de mensajes a subconjuntos específicos de validadores sea muy difícil de lograr, y los equipos de clientes han cerrado rápidamente los vectores conocidos de rebote, equilibrio y ataques avalancha con parches simples. -Los ataques del 34%, el 51% o el 66% probablemente requerirían coordinación social fuera de banda para resolverse. Si bien esto probablemente resultara doloroso para la comunidad, la capacidad de una comunidad para responder fuera de banda es un potente freno para un atacante. La capa social de Ethereum es el último respaldo: un ataque técnicamente exitoso todavía podría ser neutralizado por la comunidad que acepte adoptar una bifurcación honesta. Se produciría una carrera entre el atacante y la comunidad de Ethereum: los miles de millones de dólares gastados en un ataque del 66 % probablemente serían borrados por un ataque de coordinación social exitoso si se consigue lo suficientemente rápido, dejando al atacante con bolsas pesadas de ether ilíquido en una cadena deshonesta conocida e ignorada por la comunidad de Ethereum. La probabilidad de que esto termine siendo rentable para el atacante es lo suficientemente baja como para ser un elemento disuasorio efectivo. De ahí la importancia de la inversión para mantener una capa social cohesiva con valores estrechamente alineados. +Los ataques del 34 %, el 51 % o el 66 % probablemente requerirían coordinación social fuera de banda para resolverse. Si bien esto probablemente resultara doloroso para la comunidad, la capacidad de una comunidad para responder fuera de banda es un potente freno para un atacante. La capa social de Ethereum es el último respaldo: un ataque técnicamente exitoso todavía podría ser neutralizado por la comunidad que acepte adoptar una bifurcación honesta. Se produciría una carrera entre el atacante y la comunidad de Ethereum: los miles de millones de dólares gastados en un ataque del 66 % probablemente serían borrados por un ataque de coordinación social exitoso, si se consigue lo suficientemente rápido, dejando al atacante con bolsas pesadas de ether ilíquido en una cadena deshonesta conocida e ignorada por la comunidad de Ethereum. La probabilidad de que esto termine siendo rentable para el atacante es lo suficientemente baja como para ser un elemento disuasorio efectivo. De ahí la importancia de la inversión para mantener una capa social cohesiva con valores estrechamente alineados. -## Más información {#further-reading} +## Lecturas recomendadas {#further-reading} -- [Versión más detallada de esta página](https://mirror.xyz/jmcook.eth/YqHargbVWVNRQqQpVpzrqEQ8IqwNUJDIpwRP7SS5FXs) -- [Vitalik acerca de la finalidad del acuerdo](https://blog.ethereum.org/2016/05/09/on-settlement-finality/) -- [Función de LMD GHOST](https://arxiv.org/abs/2003.03052) -- [Función de Casper-FFG](https://arxiv.org/abs/1710.09437) -- [Función de Gasper](https://arxiv.org/pdf/2003.03052.pdf) -- [Especificaciones de consenso de aumento de peso del proponente](https://github.com/ethereum/consensus-specs/pull/2730) +- [Versiones más detalladas en esta página](https://mirror.xyz/jmcook.eth/YqHargbVWVNRQqQpVpzrqEQ8IqwNUJDIpwRP7SS5FXs) +- [Vitalik sobre la finalidad de la liquidación](https://blog.ethereum.org/2016/05/09/on-settlement-finality/) +- [Documento LMD GHOST](https://arxiv.org/abs/2003.03052) +- [Documento Casper-FFG](https://arxiv.org/abs/1710.09437) +- [Documento de Gasper](https://arxiv.org/pdf/2003.03052.pdf) +- [Especificaciones de consenso para el aumento de peso de quien propone](https://github.com/ethereum/consensus-specs/pull/2730) - [Ataques de rebote en ethresear.ch](https://ethresear.ch/t/prevention-of-bouncing-attack-on-ffg/6114) -- [Investigación SSLE](https://ethresear.ch/t/secret-non-single-leader-election/11789) +- [búsqueda SSLE](https://ethresear.ch/t/secret-non-single-leader-election/11789) diff --git a/public/content/translations/es/developers/docs/consensus-mechanisms/pos/index.md b/public/content/translations/es/developers/docs/consensus-mechanisms/pos/index.md index 10ade89903a..dea6849ab68 100644 --- a/public/content/translations/es/developers/docs/consensus-mechanisms/pos/index.md +++ b/public/content/translations/es/developers/docs/consensus-mechanisms/pos/index.md @@ -24,7 +24,7 @@ En la prueba de trabajo (PoW) el tiempo de los bloques se determinaba por la dif La siguiente explicación detalla íntegramente cómo se ejecuta una transacción en la prueba de participación de Ethereum. -1. Un usuario crea y firma una [transacción](/developers/docs/transactions/) con su clave privada. De esto suele encargarse una cartera o una biblioteca como [ether. s](https://docs.ethers.io/v5/), [web3js](https://docs.web3js.org/), [web3py](https://web3py.readthedocs.io/en/v5/), etc., pero realmente, es el usuario quien hace una solicitud a un nodo usando la API de Ethereum [JSON-RPC](/developers/docs/apis/json-rpc/). El usuario define la cantidad de gas que está dispuesto a pagar como propina a un validador para animarle a incluir la transacción en un bloque. Las[propinas](/developers/docs/gas/#priority-fee)se pagan al validador, mientras que las[tarifas de base](/developers/docs/gas/#base-fee) se queman. +1. Un usuario crea y firma una [transacción](/developers/docs/transactions/) con su clave privada. Esto usualmente se maneja con una cartera o una biblioteca como [ethers.js](https://docs.ethers.org/v6/), [web3js](https://docs.web3js.org/), [web3py](https://web3py.readthedocs.io/en/v5/) etc., pero internamente el usuario está realizando consultas a un nodo usando la [API JSON-RPC](/developers/docs/apis/json-rpc/) de Ethereum. El usuario define la cantidad de gas que está dispuesto a pagar como propina a un validador para animarle a incluir la transacción en un bloque. Las[propinas](/developers/docs/gas/#priority-fee)se pagan al validador, mientras que las[tarifas de base](/developers/docs/gas/#base-fee) se queman. 2. La transacción se envía a un [cliente de ejecución](/developers/docs/nodes-and-clients/#execution-client) de Ethereum que verifica su validez. Esto implica asegurarse de que el emisor tenga suficientes ETH para realizar la transacción y firmarla con la clave correcta. 3. Si la transacción es válida, el cliente de ejecución la añade a su zona de espera local (lista de transacciones pendientes) y también la difunde a otros nodos a través de la red de intercambio de información (o Gossip) de la capa de ejecución. Cuando otros nodos se enteran de la transacción, la añaden también a su zona de espera local. Los usuarios avanzados podrían abstenerse de transmitir su transacción y, en su lugar, redirigirla a constructores de bloques especializados como las [subastas de Flashbots](https://docs.flashbots.net/flashbots-auction/overview). Esto les permite organizar las transacciones en los próximos bloques para obtener la máxima ganancia ([MEV](/developers/docs/mev/#mev-extraction)). 4. Uno de los nodos validadores de la red es el proponente de bloques para la vacante actual, habiendo sido seleccionado previamente de forma pseudoaleatoria utilizando RANDAO. Este nodo es responsable de construir y difundir el siguiente bloque que se añadirá a la cadena de bloques de Ethereum y de actualizar el estado global. El nodo se compone de tres partes: un cliente de ejecución, un cliente de consenso y un cliente validador. El cliente de ejecución agrupa las transacciones de la zona de espera local en una «carga útil de ejecución» y las ejecuta localmente para generar un cambio de estado. Esta información se transmite al cliente de consenso donde la carga útil de ejecución se recoge como parte de un «bloque de baliza» que también contiene información sobre recompensas, penalizaciones, recortes, certificaciones y demás que permiten a la red acordar la secuencia de bloques en la cabeza de la cadena. La comunicación entre los clientes de ejecución y consenso se describe con más detalle en [Cómo conectar a los clientes de consenso y ejecución](/developers/docs/networking-layer/#connecting-clients). diff --git a/public/content/translations/es/developers/docs/consensus-mechanisms/pos/keys/index.md b/public/content/translations/es/developers/docs/consensus-mechanisms/pos/keys/index.md index 6127752417f..3f2ffc439b8 100644 --- a/public/content/translations/es/developers/docs/consensus-mechanisms/pos/keys/index.md +++ b/public/content/translations/es/developers/docs/consensus-mechanisms/pos/keys/index.md @@ -23,7 +23,7 @@ La clave de firma del validador consta de dos elementos: - Clave **privada** de validador - Clave **pública** de validador -El propósito de la clave privada del validador es firmar operaciones en cadena, como propuestas de bloque y certificaciones. Debido a esto, estas claves deben estar en una cartera en línea. +El propósito de la clave privada de validador es firmar operaciones en cadena, como propuestas de bloque y certificados. Debido a esto, estas claves deben estar en una cartera en línea. Esta flexibilidad tiene la ventaja de mover las claves de firma del validador muy rápidamente de un dispositivo a otro, sin embargo, si se han perdido o se han robado, un ladrón puede ser capaz de **actuar maliciosamente** de varias maneras: @@ -56,6 +56,8 @@ La separación de las claves del validador de las claves de la cuenta de Ethereu ![esquema de la clave del validador](validator-key-schematic.png) +**Nota**: Salir de las funciones de participación y retirar el balance del validador actualmente requiere firmar un [mensaje de salida voluntaria (VEM)](https://mirror.xyz/ladislaus.eth/wmoBbUBes2Wp1_6DvP6slPabkyujSU7MZOFOC3QpErs&1) con la clave de validador. Sin embargo, [EIP-7002](https://eips.ethereum.org/EIPS/eip-7002) es una propuesta que permitirá a un usuario activar la salida de un validador y retirar su balance firmando mensajes de salida con la clave de retirada en el futuro. Esto reducirá las suposiciones de confianza al permitir que los participantes que delegan ETH a [proveedores de participación como servicio](https://ethereum.org/en/staking/saas/#what-is-staking-as-a-service) mantengan el control de sus fondos. + ## Derivar claves de una frase semilla {#deriving-keys-from-seed} Si cada 32 ETH en participación requiriera un nuevo conjunto de 2 claves completamente independientes, la gestión de claves se volvería rápidamente difícil de manejar, especialmente para los usuarios que ejecutan múltiples validadores. En su lugar, se pueden derivar múltiples claves de validación de un solo secreto común y el almacenamiento de ese único secreto permite el acceso a múltiples claves de validación. @@ -94,3 +96,5 @@ Cada rama está separada por un `/`, por lo que `m/2` significa comenzar con la - [Publicación en el blog de Ethereum Foundation por Carl Beekhuizen](https://blog.ethereum.org/2020/05/21/keys/) - [Generación de claves EIP-2333 BLS12-381](https://eips.ethereum.org/EIPS/eip-2333) +- [EIP-7002: Salidas activables por la capa de ejecución](https://research.2077.xyz/eip-7002-unpacking-improvements-to-staking-ux-post-merge) +- [Gestión de claves a gran escala](https://docs.ethstaker.cc/ethstaker-knowledge-base/scaled-node-operators/key-management-at-scale) diff --git a/public/content/translations/es/developers/docs/consensus-mechanisms/pos/rewards-and-penalties/index.md b/public/content/translations/es/developers/docs/consensus-mechanisms/pos/rewards-and-penalties/index.md index 8fc8a8cb37f..1f3d546976d 100644 --- a/public/content/translations/es/developers/docs/consensus-mechanisms/pos/rewards-and-penalties/index.md +++ b/public/content/translations/es/developers/docs/consensus-mechanisms/pos/rewards-and-penalties/index.md @@ -84,6 +84,8 @@ El diseño de recompensa, penalización y recorte del mecanismo de consenso anim - [Incentivos en el protocolo híbrido Casper de Ethereum](https://arxiv.org/pdf/1903.04205.pdf) - [Especificaciones anotadas de Vitalik](https://github.com/ethereum/annotated-spec/blob/master/phase0/beacon-chain.md#rewards-and-penalties-1) - [Consejos para la prevención de recortes en Eth2](https://medium.com/prysmatic-labs/eth2-slashing-prevention-tips-f6faa5025f50) +- [EIP-7251 explicado: Aumento del saldo máximo efectivo para validadores](https://research.2077.xyz/eip-7251_Increase_MAX_EFFECTIVE_BALANCE) +- [Análisis de las penalizaciones por recortes bajo EIP-7251](https://ethresear.ch/t/slashing-penalty-analysis-eip-7251/16509) _Fuentes_ diff --git a/public/content/translations/es/events/index.md b/public/content/translations/es/events/index.md new file mode 100644 index 00000000000..a2079753e73 --- /dev/null +++ b/public/content/translations/es/events/index.md @@ -0,0 +1,24 @@ +--- +title: Eventos de Ethereum +description: Cómo involucrarse en la comunidad Ethereum. +lang: es +hideEditButton: true +--- + +# Próximos eventos {#events} + +**Cada mes, se celebran grandes eventos de Ethereum en todo el mundo.** Plantéese asistir a alguno cerca suyo para conocer a más gente en la comunidad, aprender sobre oportunidades de empleo y desarrollar nuevas habilidades. + + + +Esta es una lista no exhaustiva mantenida por nuestra comunidad. ¿Sabe de algún evento próximo de Ethereum para añadir a esta lista? [¡Por favor, añádalo](https://github.com/ethereum/ethereum-org-website/blob/dev/src/data/community-events.json)! + +## Encuentros sobre Ethereum {#meetups} + +¿No ve ningún evento que le venga bien? Intente asistir a un encuentro. Los encuentros son eventos más pequeños celebrados por grupos de entusiastas de Ethereum, es decir, son una oportunidad para que las personas interesadas en Ethereum se reúnan, hablen acerca de Ethereum y se enteren de las últimas novedades. + + + +¿Le interesaría organizar su propia reunión? Eche un vistazo a [BUIDL Network](https://consensys.net/developers/buidlnetwork/): una iniciativa de ConsenSys para ayudar a apoyar las comunidades de encuentros de Ethereum. + +Esta es una lista no exhaustiva mantenida por nuestra comunidad. Aquí [encontrará más información sobre los encuentros de Ethereum](https://www.meetup.com/topics/ethereum/). ¿Sabe de algún un grupo de encuentros activo para añadir a esta lista? [¡Por favor, añádalo!](https://github.com/ethereum/ethereum-org-website/blob/dev/src/data/community-meetups.json) diff --git a/public/content/translations/es/glossary/index.md b/public/content/translations/es/glossary/index.md index 8cf0f205c9d..b3dc1eb91dc 100644 --- a/public/content/translations/es/glossary/index.md +++ b/public/content/translations/es/glossary/index.md @@ -2,1130 +2,498 @@ title: Glosario de Ethereum description: Un glosario incompleto de términos técnicos y no técnicos relacionados con Ethereum lang: es -sidebarDepth: 2 --- # Glosario {#ethereum-glossary} - - ## \# {#section-numbers} -### Ataque del 51 % {#51-attack} + -Un tipo de ataque a una [red](#network) descentralizada donde un grupo obtiene el control de la mayoría de los [nodos](#node). Esto les permitiría defraudar a la cadena de bloques al revertir [transacciones](#transaction) y gastar el doble de [ether](#ether) y otras fichas criptográficas. + ## A {#section-a} -### cuenta {#account} - -Un objeto que contiene una [dirección](#address), balance, [nonce](#nonce) y, opcionalmente, un código fuente y almacenamiento. Una cuenta puede ser una [cuenta de contrato](#contract-account) o una [cuenta de propiedad externa (EOA)](#eoa). - - - Cuentas de Ethereum - - -### dirección {#address} - -Generalmente, representa una cuenta de propiedad externa, o [EOA](#eoa) o un [contrato](#contract-account) que se puede recibir (cuenta destino) o enviar (dirección original) [transacciones](#transaction) en la cadena de bloques. En concreto, son 160 bits del [Keccak hash](#keccak-256) de una [clave pública](#ecdsa) [ECDSA](#public-key). - -### interfaz binaria de la aplicación (ABI) {#abi} + -La forma estándar de interactuar con [contratos](#contract-account) en el ecosistema Ethereum, tanto desde fuera de la cadena de bloques como para las interacciones entre contratos. + - - ABI - + -### interfaz de programación de aplicaciones {#api} + -Una Interfaz de Programación de Aplicaciones (API) es un conjunto de definiciones acerca de cómo utilizar un software. Una API se encuentra entre una aplicación y un servidor web, y facilita la transferencia de datos entre ellos. + -### ASIC {#asic} + -Circuito integrado para aplicaciones específicas. Esto generalmente se refiere a un circuito integrado, hecho a la medida para la minería de criptomonedas. + -### assert {#assert} + -En [Solidity](#solidity), `assert(false)` se compila en `0xfe`, un código operativo inválido, que agota todo el [gas](#gas) restante y revierte todos los cambios. Cuando una sentencia `assert()` falla, algo muy malo e inesperado está sucediendo y tendrá que arreglar su código. Debería usar `assert()` para evitar condiciones que nunca jamás deberían ocurrir. - - - Seguridad en contratos inteligentes - - -### certificación {#attestation} - -Una afirmación hecha por una entidad de que algo es verdadero. En el contexto de Ethereum, los validadores de consenso deben de afirmar cuál creen que es el estado de la cadena. En los momentos designados, cada validador es responsable de publicar diferentes certificaciones que declaran formalmente la visión de la cadena de este validador, incluyendo el úlitmo punto de control finalizado y el jefe actual de la cadena. - - - Certificaciones - + ## B {#section-b} -### Tarifa de base {#base-fee} - -Cada [bloque](#block) tiene un precio conocido como «tarifa de base». Es la tarifa mínima de [gas](#gas) que un usuario debe pagar para incluir la transacción en el siguiente bloque. - - - Gas y tarifas - - -### Cadena de baliza {#beacon-chain} - -La cadena de baliza fue la cadena de bloques que introdujo la [prueba de participación](#pos) y los [validators](#validadores) en Ethereum. Se ejecutó junto con la prueba de trabajo de la cadena principal de Ethereum desde diciembre de 2020 hasta que las dos cadenas se fusionaron en septiembre de 2022 para formar el Ethereum actual. - - - Cadena de baliza - - -### big-endian {#big-endian} - -Una representación de números de posición donde el dígito más significativo es el primero en la memoria. Lo contrario de «little-endian», donde el dígito menos significativo es el primero. - -### bloque {#block} - -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 los proponen los validadores de prueba de participación, en el momento en que se comparten en toda la red entre pares, donde todos los demás nodos pueden verificarlos fácilmente de forma independiente. Las reglas de consenso rigen qué contenido de un bloque se considera válido. La red ignora los bloques que se consideren no válidos. El orden de estos bloques y las transacciones en ese sentido crean una cadena determinista de eventos con un final que representa el estado actual de la red. - - - Bloques - - -### explorador de bloque {#block-explorer} - -Una interfaz que permite a un usuario buscar información desde y sobre una cadena de bloques. Esto incluye la recuperación de transacciones individuales, actividades asociadas con direcciones específicas e información sobre la red. - -### encabezado de bloque {#block-header} - -El encabezado del bloque es una colección de metadatos sobre un bloque y un resumen de las transacciones incluidas en la carga útil de ejecución. - -### propagación de bloques {#block-propagation} - -El proceso de transmitir un bloque confirmado a todos los otros nodos de la red. - -### proponente de bloques {#block-proposer} - -El validador específico elegido para crear un bloque en una [ranura](#slot) particular. - -### recompensa de bloque {#block-reward} + -La cantidad de ether recompensada al proponente de un nuevo bloque válido. + -### estado del bloque {#block-status} + -Los estados en los que puede existir un bloque. Los posibles estados incluyen: + -- Propuesto: un validador ha propuesto el bloque. -- Programado: los validadores están enviando datos actualmente. -- Perdido/omitido: el proponente no propuso un bloqueo dentro del plazo elegible. -- Huérfano: el [algoritmo de elección de bifurcación](#fork-choice-algorithm) ha reorganizado el bloque. + -### tiempo del bloque {#block-time} + -El intervalo de tiempo que tardan los bloques en ser añadidos a la cadena de bloques. + -### validación del bloque {#block-validation} + -El proceso de comprobar que un nuevo bloque contiene transacciones y firmas válidas, se basa en la cadena histórica más pesada y sigue todas las demás reglas de consenso. Los bloques válidos se añaden al final de la cadena y se propagan a otros en la red. Los bloques no válidos no se tienen en cuenta. + -### cadena de bloques {#blockchain} + -Una secuencia de [bloques](#block), cada uno de los cuales se vincula a su predecesor hasta el [bloque inicial](#genesis-block) haciendo referencia al hash del bloque anterior. La integridad de la cadena de bloques está asegurada criptográficamente mediante un mecanismo de consenso basado en la prueba de participación. + - - ¿Qué es una cadena de bloques o «blockchain»? - + -### nodo de arranque {#bootnode} + -Los nodos que se pueden utilizar para iniciar el proceso de descubrimiento al ejecutar un nodo. Las terminales de estos nodos se registran en el código fuente de Ethereum. + -### código de bytes {#bytecode} + -Un conjunto abstracto de instrucciones diseñado para una ejecución eficiente por parte de un software que lo interpreta o una máquina virtual. A diferencia del código fuente legible por humanos, el código de bytes se expresa en formato numérico. + -### Bifurcación Byzantium {#byzantium-fork} - -La primera de dos [ bifurcaciones duras de código](#hard-fork) para la etapa de desarrollo [Metropolis](#metropolis). Incluyó EIP-649 con el retraso de la [bomba de dificultad](#difficulty-bomb) Metropolis y la reducción de recompensa de bloques, donde la [Era de hielo](#ice-age) se retrasó 1 año y la recompensa del bloque se redujo de 5 a 3 ether. + ## C {#section-c} -### Casper-FFG {#casper-ffg} - -Casper-FFG es un protocolo de consenso de prueba de participación utilizado junto con el algoritmo de elección de bifurcación [LMD-GHOST](#lmd-ghost) para permitir que los [clientes de consenso](#consensus-client) se pongan de acuerdo sobre la cabeza de la cadena de baliza. - -### punto de control {#checkpoint} - -La [cadena de baliza](#beacon-chain) tiene un tempo dividido en ranuras (12 segundos) y épocas (32 ranuras). La primera ranura de cada época es un punto de control. Cuando una [supermayoría](#supermajority) de los validadores certifica el vínculo entre dos puntos de control, se pueden [justificar](#justification) y luego, cuando otro puesto de control esté justificado encima, pueden estar [finalizados](#finality). - -### compilación {#compiling} - -Convierte el código escrito en un lenguaje de programación de alto nivel (por ejemplo, [Solidity](#solidity)) en otro lenguaje de menor nivel (por ejemplo, bytecode de la [EVM](#bytecode)). - - - Compilación de contratos inteligentes - - -### comité {#committee} + -Un grupo de al menos 128 [validadores](#validator) asignados para validar bloques en cada ranura. Uno de los validadores del comité es el agregador, responsable de agregar las firmas de todos los demás validadores del comité que acuerden una certificación. No debe confundirse con el [comité de sincronización](#sync-committee). + -### inviabilidad computacional {#computational-infeasibility} + -Un proceso es computacionalmente inviable si lleva un tiempo poco factible (por ejemplo, miles de millones de años) hacerlo para cualquier persona que posiblemente tenga un interés en llevarlo a cabo. + -### consenso {#consensus} + -Cuando una supermayoría de nodos en la red tienen los mismos bloques en su mejor cadena de bloques validada localmente. No se debe confundir con [reglas de consenso](#consensus-rules). + -### cliente de consenso {#consensus-client} + -Los clientes de consenso (como Prysm, Teku, Nimbus, Lighthouse, Lodestar) ejecutan el algoritmo de consenso de la [prueba de participación](#pos) de Ethereum permitiendo a la red alcanzar un acuerdo sobre la cabeza de la cadena de bloques. Los clientes de consenso no participan en la validación/retransmisión de transacciones ni en la ejecución de transiciones de estado. Esto se realiza mediante [clientes de ejecución](#execution-client). + -### capa de consenso {#consensus-layer} + -La capa de consenso de Ethereum es la red de [clientes de consenso](#consensus-client). + -### reglas de consenso {#consensus-rules} + -Reglas de validación de bloques que siguen los nodos completos para permanecer en consenso con otros nodos. No se debe confundir con [consenso](#consensus). + -### Considerado para la inclusión (CFI) {#cfi} + -Un núcleo [EIP](#eip) que aún no está activo en la red principal, y a los desarrolladores de clientes les parece bien la idea, por lo general. Suponiendo que cumpla con todos los requisitos para la inclusión de la red principal, podría incluirse en una actualización de la red (no necesariamente la siguiente). + -### Bifurcación Constantinople {#constantinople-fork} - -Segunda parte de la etapa [Metropolis](#metropolis), prevista inicialmente para mediados de 2018. Se espera que incluya el cambio a un algoritmo de consenso híbrido de [prueba de trabajo](#pow)/[prueba de participación](#pos), entre otros cambios. - -### cuenta de contrato {#contract-account} - -Cuenta que contiene un código que se ejecuta cada vez que recibe una [transacción](#transaction) de otra [cuenta](#account) ([EOA](#eoa) o [contrato](#contract-account)). - -### transacción de creación de contrato {#contract-creation-transaction} - -Una [transacción especial](#transaction) que incluye el código de inicio de un contrato. El destinatario se establece como `null` (nulo) y el contrato se implementa en una dirección generada a partir de la dirección del usuario y `nonce`. Se utiliza para registrar un [contrato](#contract-account) y guardarlo en la cadena de bloques de Ethereum. - -### criptoeconomía {#cryptoeconomics} - -La economía de las criptomonedas. + ## D {#section-d} -### Đ {#d-with-stroke} - -Đ (D con un trazo) se usa en inglés antiguo, inglés medio, islandés y feroés para indicar una letra mayúscula «Eth». Se utiliza en palabras como ĐEV o ĐApp (aplicación descentralizada), donde Đ es la letra nórdica «eth». El eth en mayúsculas (Ð) también se utiliza para simbolizar la criptomoneda Dogecoin. Esto se ve comúnmente en la documentación más antigua de Ethereum, aunque se usa con menos frecuencia hoy en día. - -### DAG {#dag} - -DAG significa Directed Acyclic Graph (Grafo Acíclico Dirigido). Es una estructura de datos compuesta por nodos y enlaces entre ellos. Antes de La Fusión, Ethereum usaba un DAG en su algoritmo [proof-of-work](#pow), [Ethash](#ethash), pero ya no se usa en la [prueba de participación](#pos). - -### DApp {#dapp} - -Aplicación Descentralizada. Como mínimo, es un [contrato inteligente](#smart-contract) y una interfaz de usuario web. En términos más generales, un DApp es una aplicación web que se basa en servicios de infraestructura abiertos, descentralizados y entre pares. Además, muchas DApps incluyen almacenamiento descentralizado y/o un protocolo y plataforma de mensajes. - - - Introducción a las dapps - - -### disponibilidad de datos {#data-availability} - -La propiedad de un estado que cualquier nodo conectado a la red podría descargar cualquier parte específica del estado que desee. - -### descentralización {#decentralization} - -El concepto de mover el control y la ejecución de procesos fuera de una entidad central. - -### Organización Autónoma Descentralizada (DAO) {#dao} - -Una empresa u otra organización que funciona sin gestión jerárquica. DAO también puede referirse a un contrato llamado «The DAO» lanzado el 30 de abril de 2016, que luego fue hackeado en junio de 2016; esto finalmente produjo una [bifurcación fuerte](#hard-fork) (con nombre de código DAO) en el bloque 1.192.000, que revirtió el contrato DAO hackeado y provocó que Ethereum y Ethereum Classic se dividieran en dos sistemas competidores. - - - Organizaciones Autónomas Descentralizadas (DAO) - - -### Intercambio Descentralizado (DEX) {#dex} - -Un tipo de [DApp](#dapp) que le permite intercambiar tókenes entre pares en la red. Necesita [ether](#ether) para usar uno (para pagar [comisiones de transacción](#transaction-fee)), pero no están sujetos a restricciones geográficas como los intercambios centralizados; cualquiera puede participar. + - - Intercambios descentralizados - + -### títulos de propiedad {#deed} + -Ver [Tókenes no fungibles (NFT)](#nft). + -### contrato de depósito {#deposit-contract} + -La puerta de entrada a la participación en Ethereum. El contrato de depósito es un contrato inteligente en Ethereum que acepta depósitos de ETH y gestiona los saldos de los validadores. No se puede activar un validador sin depositar ETH en este contrato. El contrato requiere ETH y datos de entrada. Estos datos de entrada incluyen la clave pública del validador y la clave pública de retirada, firmadas por la clave privada del validador. Estos datos son necesarios para que la red de la [prueba de participación](#pos) identifique y apruebe a un validador. + -### DeFi {#defi} + -Abreviatura de «Finanzas Descentralizadas», que es una amplia categoría de [DApps](#dapp) que tiene como objetivo proporcionar servicios financieros respaldados por la cadena de bloques, sin intermediarios, para que cualquier persona con una conexión a Internet pueda participar. + - - Finanzas descentralizadas (DeFi) - + -### dificultad {#difficulty} + -Una configuración de toda la red en redes [prueba de trabajo](#pow) que controla cuánto cálculo promedio se requiere para encontrar un nonce válido. La dificultad viene representada por el número de ceros iniciales que se requieren en el hash de bloque resultante para que se considere válido. Este concepto ha quedado obsoleto en Ethereum desde la transición a la prueba de participación. + -### bomba de dificultad {#difficulty-bomb} + -Aumento exponencial planificado en la [dificultad](#pow) [de la prueba de trabajo](#difficulty) que se ha diseñado para motivar la transición a [prueba de participación](#pos), reduciendo las posibilidades de una [bifurcación](#hard-fork). La bomba de dificultad ha quedado obsoleta con la [transición a la prueba de participación](/roadmap/merge). + -### firma digital {#digital-signatures} + -Una cadena corta de datos que un usuario produce para un documento utilizando una [clave privada](#private-key) de manera que cualquiera con la correspondiente [clave pública](#public-key), la firma y el documento pueda verificar que (1) el documento está «firmado» por el propietario de esa clave privada en particular, y que (2) el documento no se ha modificado una vez firmado. + -### descubrimiento {#discovery} - -El proceso por el cual un nodo Ethereum encuentra otros nodos a los que conectarse. - -### Tabla de Hash Distribuida (DHT) {#distributed-hash-table} - -Una estructura de datos que contiene pares `(clave, valor)` utilizados por los nodos de Ethereum para identificar a los pares a los que conectarse y determinar qué protocolos usar para comunicarse. - -### doble gasto {#double-spend} - -Una bifurcación de cadena de bloques deliberada, en la que un usuario con una cantidad suficientemente grande de poder/participación en minería envía una transacción para pasar algo de moneda fuera de la cadena (por ejemplo, salir al dinero fiduciario o hacer una compra fuera de la cadena) y luego reorganizar la cadena de bloques para eliminar esa transacción. Un doble gasto exitoso deja al atacante con sus activos tanto en la cadena como fuera de la cadena. - ## E {#section-e} -### Algoritmo de Firma Digital de Curva Elíptica (ECDSA) {#ecdsa} - -Algoritmo criptográfico utilizado por Ethereum para garantizar que los fondos solo los pueden gastar sus propietarios. Es el método preferido para crear claves públicas y privadas. Relevante para la [generación de la dirección](#address) de la cuenta y la [verificación de la transacción](#transaction). - -### cifrado {#encryption} - -El cifrado es la conversión de datos electrónicos en una forma ilegible por cualquier persona, excepto el propietario de la clave de descifrado correcta. - -### entropía {#entropy} - -En el contexto de la criptografía, significa una falta de previsibilidad o nivel de aleatoriedad. Cuando se genera información secreta, como las [claves privadas](#private-key), los algoritmos suelen basarse en una fuente de alta entropía para garantizar que la salida sea impredecible. - -### época {#epoch} - -Un período de 32 [ranuras](#slot), cada una de las cuales es de 12 segundos, por un total de 6,4 minutos. Los [comités de validación](#committee) se barajean cada época por razones de seguridad. Cada época tiene la oportunidad de que la cadena sea [finalizada](#finality). A cada validador se le asignan nuevas responsabilidades al comienzo de cada época. - - - Prueba de participación - - -### equivocación {#equivocation} - -Un validador que envía dos mensajes que se contradicen entre sí. Un ejemplo simple es un remitente de transacciones que envía dos transacciones con el mismo nonce. Otro es un proponente de bloques que propone dos bloques a la misma altura de bloque (o para la misma ranura). - -### Eth1 {#eth1} - -«Eth1» es un término que se refiere a la red principal de Ethereum, la cadena de prueba de trabajo (PoW) existente. Este término ha sido desestimado a favor de la «capa de ejecución». [Conozca más acerca de este cambio de nombre](https://blog.ethereum.org/2022/01/24/the-great-eth2-renaming/). - - - Más sobre las actualizaciones de Ethereum - - -### Eth2 {#eth2} - -«Eth2» es un término que hace referencia a un conjunto de actualizaciones del protocolo de Ethereum, incluyendo la transición de Ethereum a la prueba de participación. Desde entonces, este término ha quedado obsoleto a favor de la «capa de consenso». [Conozca más acerca de este cambio de nombre](https://blog.ethereum.org/2022/01/24/the-great-eth2-renaming/). - - - Más sobre las actualizaciones de Ethereum - - -### Propuesta de mejora de Ethereum(EIP) {#eip} - -Documento de diseño que proporciona información a la comunidad de Ethereum, describiendo una nueva característica propuesta o sus procesos o entorno (ver [ERC](#erc)). - - - Introducción a EIP - - -### Servicio de Nombres de Ethereum (ENS) {#ens} - -El registro ENS es un único [contrato inteligente](#smart-contract) central que proporciona una asignación de nombres de dominio a propietarios y resolutores, como se describe en [EIP](#eip) 137. - -[Más información en ens.domains](https://ens.domains) - -### cliente de ejecución {#execution-client} - -Los clientes de ejecución (anteriormente conocidos «clientes Ethereum»), como Besu, Erigon, Go-Ethereum (Geth), Nethermind, tienen la tarea de procesar y transmitir transacciones y administrar el estado de Ethereum. Ejecutan los cálculos de cada transacción utilizando la [Máquina Virtual Ethereum](#evm) para garantizar que se sigan las reglas del protocolo. - -### capa de ejecución {#execution-layer} + -La capa de ejecución de Ethereum es la red de [clientes de ejecución](#execution-client). + -### Cuenta de Propiedad Externa (EOA) {#eoa} + -Las cuentas de propiedad externa (o EOA) son [cuentas](#account) que están controladas por [claves privadas](#private-key), normalmente generadas utilizando una [frase semilla](#hd-wallet-seed). A diferencia de los contratos inteligentes, las cuentas de propiedad externa son cuentas sin ningún código asociado a ellas. Normalmente, estas cuentas se gestionan con una [cartera](#wallet). + -### Ethereum Solicita Comentarios (ERC) {#erc} + -Una etiqueta dada a algunas [EIP](#eip) que intentan definir un estándar específico de uso de Ethereum. + - - Introducción a EIP - + -### Ethash {#ethash} + -Un algoritmo de [prueba de trabajo](#pow) que se utilizó en Ethereum antes de hacer la transición a la [prueba de participación](#pos). + -[Más información](/developers/docs/consensus-mechanisms/pow/mining/mining-algorithms/ethash) + -### ether {#ether} + -Criptomoneda nativa utilizada por el ecosistema Ethereum, que cubre los costes del [gas](#gas) al ejecutar las transacciones. También escrito como ETH o su símbolo Ξ, el símbolo griego Xi en mayúscula. + - - Moneda para nuestro futuro digital - + -### eventos {#events} + -Permite el uso de las instalaciones de registro de la [EVM](#evm). Las [DApps](#dapp) pueden recibir eventos y utilizarlos para activar las llamadas de retorno de JavaScript en la interfaz de usuario. + - - Eventos y registros - + -### Máquina virtual de Ethereum (EVM) {#evm} + -Una máquina virtual basada en la pila que ejecuta [bytecode](#bytecode). En Ethereum, el modelo de ejecución determina cómo se modifica el estado del sistema, dada una serie de instrucciones mediante bytecode y una pequeña tupla de datos del entorno. Esto se especifica a través de un modelo formal de una máquina virtual. + - - Máquina virtual de Ethereum - + -### Lenguaje ensamblador EVM {#evm-assembly-language} + -Una forma legible de [bytecode](#bytecode) de EVM. + ## F {#section-f} -### función de reserva {#fallback-function} + -Una función por defecto llamada en ausencia de datos o de un nombre de función declarado. + -### faucet (grifo) {#faucet} + -Un servicio realizado a través de un [contrato inteligente](#smart-contract) que dispensa fondos en forma de ethers gratuitos de prueba que puede utilizarse en una red de prueba. + - - Faucets de red de prueba - + -### finalidad {#finality} + -La finalidad es la garantía de que un conjunto de transacciones anteriores a un momento dado no cambiará y no podrá revertirse. + - - Finalidad de la prueba de participación - - -### finney {#finney} - -Una denominación de [ether](#ether). 1 finney = 1015 [wei](#wei). 103 finney = 1 ether. - -### bifurcación {#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. - -### algoritmo de elección de bifurcación {#fork-choice-algorithm} - -El algoritmo utilizado para identificar la cadena de bloques en cabeza. En la capa de ejecución la cabeza de la cadena se identifica como la que tiene la mayor dificultad total detrás de ella. Esto significa que la verdadera cabeza de la cadena es la que ha requerido más trabajo para minarla. En la capa de consenso el algoritmo observa las certificaciones acumuladas de validadores ([LMD_GHOST](#lmd-ghost)). - -### prueba de fraude {#fraud-proof} - -Modelo de seguridad para ciertas soluciones de [capa 2](#layer-2) en las que, para aumentar la velocidad, las transacciones se [enrollan](#rollups) (rollup) en lotes y se envían a Ethereum en una única transacción. Se supone que son válidos, pero se pueden poner en tela de juicio si se sospecha el fraude. Una prueba de fraude ejecutará entonces la transacción para ver si se ha producido el fraude. Este método aumenta la cantidad de transacciones posibles manteniendo la seguridad. Algunos [rollups](#rollups) utilizan [pruebas de validez](#validity-proof). - - - Agregaciones Optimistas - - -### frontier {#frontier} - -Etapa inicial de desarrollo de prueba de Ethereum, que duró desde julio de 2015 hasta marzo de 2016. + ## G {#section-g} -### gas {#gas} - -Un combustible virtual utilizado en Ethereum para ejecutar contratos inteligentes. La [EVM](#evm) utiliza un mecanismo de contabilidad para medir el consumo de gas y limitar el consumo de recursos informáticos (ver [Turing completo](#turing-complete)). - - - Gas y tarifas - - -### límite de gas {#gas-limit} - -La cantidad máxima de [gas](#gas) que puede consumir una [transacción](#transaction) o un [bloque](#block). - -### precio de gas {#gas-price} + -Precio en ether de una unidad de gas especificada en una transacción. + -### bloque inicial {#genesis-block} + -El primer bloque de una [cadena de bloque](#blockchain), utilizado para inicializar una red concreta y su criptomoneda. + -### geth {#geth} + -Go Ethereum. Una de las implementaciones más destacadas del protocolo Ethereum, escrito en Go. - -[Más información en geth.ethereum.org](https://geth.ethereum.org/) - -### gwei {#gwei} - -Abreviatura de gigawei, una denominación de [ether](#ether), comúnmente utilizada para fijar el precio del [gas](#gas). 1 gwei = 109 [wei](#wei). 109 gwei = 1 ether. + ## H {#section-h} -### bifurcación fuerte {#hard-fork} - -En discrepancia permanente con la [cadena de bloque](#blockchain); también conocida como cambio de «hardforking». Una suele ocurrir cuando los nodos no actualizados no pueden validar los bloques creados por los nodos actualizados que siguen las nuevas [reglas de consenso](#consensus-rules). No debe confundirse con una bifurcación, una bifurcación suave, una bifurcación de software o una bifurcación Git. - -### hash {#hash} - -Una huella digital de longitud fija de una entrada de tamaño variable, producida por una función hash. (Ver [keccak-256](#keccak-256)). - -### tasa de hash {#hash-rate} - -La cantidad de cálculos hash realizados por segundo por computadoras que ejecutan software de minería. + -### Cartera HD {#hd-wallet} + -Una [cartera](#wallet) que utiliza el protocolo de creación y transferencia de claves jerárquicas deterministas (HD). + -[Más información en github.com](https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki) + -### Semilla de cartera HD {#hd-wallet-seed} - -Un valor utilizado para generar la [clave privada](#private-key) maestra y el código de la cadena maestra para una [cartera](#wallet) HD. La semilla de cartera puede representarse mediante palabras mnemotécnicas, lo que permite a los humanos copiar, respaldar y restaurar las claves privadas con mayor facilidad. - -### homestead {#homestead} - -La segunda etapa de desarrollo de Ethereum, lanzada en marzo de 2016 en el bloque 1.150.000. + ## I {#section-i} -### índice {#index} - -Una estructura de red destinada a optimizar la consulta de información de toda la [cadena de bloques](#blockchain) proporcionando una ruta eficiente a su fuente de almacenamiento. - -### Protocolo de Intercambio de Direcciones de Clientes (ICAP) {#icap} - -Codificación de direcciones de Ethereum que es parcialmente compatible con la numeración internacional de cuentas bancarias (IBAN), ofreciendo una codificación polivalente, con suma de comprobación e interoperable para las direcciones de Ethereum. Las direcciones ICAP utilizan un nuevo código de pseudopaís IBAN: XE, que significa «eXtended Ethereum», tal como se utiliza en las monedas no jurisdiccionales (por ejemplo, XBT, XRP, XCP). - -### Era de hielo {#ice-age} + -Una [bifurcación fuerte](#hard-fork) de Ethereum en el bloque 200.000 para introducir un incremento exponencial de [dificultad](#difficulty) (también conocido como [bomba de dificultad](#difficulty-bomb)), motivando una transición a la[prueba de participación](#pos). + -### Entorno de Desarrollo Integrado (IDE) {#ide} + -Una interfaz de usuario que normalmente combina un editor de código, compilador, tiempo de ejecución y depurador. + - - Entornos de desarrollo integrados - - -### problema de código implementado inmutable {#immutable-deployed-code-problem} - -Una vez que el código de un [contrato](#smart-contract) (o [biblioteca](#library)) se implementa, se vuelve inmutable. Las prácticas habituales de desarrollo de software se basan en la posibilidad de corregir posibles errores y añadir nuevas funciones, por lo que esto supone un reto para el desarrollo de contratos inteligentes. - - - Implementación de contratos inteligentes - - -### transacción interna {#internal-transaction} - -[Transacción](#transaction) enviada desde una [cuenta de contrato](#contract-account) a otra cuenta de contrato o a una [EOA](#eoa) (ver [mensaje](#message)). + -### emisión - -La acuñación de nuevo ether para recompensar la propuesta, la certificación y la denuncia de irregularidades. - ## K {#section-k} -### Función de Derivación de Clave (KDF) {#kdf} - -También conocida como «algoritmo de estiramiento de contraseñas», lo utilizan los formatos [keystore](#keystore-file) (o banco de claves) para protegerse contra los ataques de fuerza bruta, de diccionario y de tabla de arcoíris en el cifrado de frases de contraseña, mediante el hashing repetido de la frase de contraseña. + - - Seguridad de los contratos inteligentes - + -### almacén de claves {#keyfile} + -El par clave/dirección privada de cada cuenta existe como un solo archivo de clave en un cliente de Ethereum. Estos son archivos de texto JSON que contienen la llave privada cifrada de la cuenta, que solo se puede descifrar con la contraseña introducida durante la creación de la cuenta. - -### keccak-256 {#keccak-256} - -Función criptográfica [hash](#hash) utilizada en Ethereum. Keccak-256 se ha normalizado como [SHA](#sha)-3. + ## L {#section-l} -### capa 2 {#layer-2} - -Un área de desarrollo centrada en la superposición de capas sobre el protocolo de Ethereum. Estas mejoras están relacionadas con las velocidades de [transacción](#transaction), el abaratamiento de las [comisiones de transacción](#transaction-fee) y la privacidad de las transacciones. - - - Capa 2 - + -### LevelDB {#level-db} + -Es un almacenamiento en disco de código abierto, livianamente implementado, [biblioteca](#library) de propósito único con conexiones a diferentes plataformas. + -### biblioteca {#library} + -Un tipo especial de [contrato](#smart-contract) sin funciones pagaderas, sin función de reserva y sin almacenamiento de datos. Por lo tanto, no puede recibir ni guardar ether o almacenar datos. Una biblioteca sirve como un código implementado previamente al que puede acceder otro contrato para realizar funciones de computación de solo lectura. + - - Bibliotecas de contratos inteligentes - + -### cliente ligero {#light-client} - -Un cliente de Ethereum que no almacena una copia local de la [cadena de bloque](#blockchain), o bien valida bloques y [transacciones](#transaction). Ofrece las funciones de una [cartera](#wallet) y puede crear y transmitir transacciones. + -### LMD_GHOST {#lmd-ghost} - -El [algoritmo de opción de bifurcación](#fork-choice-algorithm) usado por los clientes de consenso de Ethereum para identificar la cabeza de la cadena. LMD-GHOST es un acrónimo que significa «último mensaje dirigido codicioso observado del subárbol más pesado», e indica que la cabeza de la cadena es el bloque con la mayor acumulación de certificaciones en su historia. - ## M {#section-m} -### Red principal {#mainnet} - -Abreviatura de «red principal», esta es la principal [cadena de bloques](#blockchain) pública de Ethereum. ETH, valor real y consecuencias reales. También se conoce como la capa 1 cuando se habla sobre las soluciones de escalabilidad de la [capa 2](#layer-2). (Consulte también la [red de pruebas](#testnet)). + - - Redes de Ethereum - + -### memoria dura {#memory-hard} + -Las funciones de memoria dura son procesos que experimentan una disminución drástica en la velocidad o la viabilidad cuando la cantidad de memoria disponible disminuye aunque sea ligeramente. Un ejemplo es el algoritmo de minería de Ethereum[Ethash](#ethash). + -### Árbol de Merkle Patricia Trie {#merkle-patricia-tree} + -Es una estructura de datos usada en Ethereum, orientada a la eficiencia para almacenar pares de claves. + -### mensaje {#message} + -Una [transacción interna](#internal-transaction) que nunca se serializa y solo se envía dentro de la [EVM](#evm). + -### llamada de mensaje {#message-call} + -El acto de transmitir un [mensaje](#message) de una cuenta a otra. Si la cuenta de destino está relacionada con el código de la [EVM](#evm), la VM se iniciará con el estado de este objeto y el mensaje en cuestión. + -### Metropolis {#metropolis} - -La tercera fase de desarrollo de Ethereum, que se lanzó en octubre de 2017. - -### minado {#mining} - -El proceso de hacer hash repetidamente de un encabezado de bloque mientras se incrementa un [nonce](#nonce) hasta que el resultado contenga un número arbitrario de ceros binarios a la izquierda. Este es el proceso mediante el cual se añaden nuevos [bloques](#block) a la cadena de bloques [de una prueba de trabajo](#blockchain). Así fue como se aseguró Ethereum antes de pasar a la [prueba de participación](#pos). - -### minería {#miner} - -Es un [nodo](#node) de red que encuentra [pruebas de trabajo](#pow) válidas para bloques nuevos, mediante el hashing de pase repetido (ver [Ethash](#ethash)). Los mineros ya no forman parte de Ethereum, fueron reemplazados por validadores cuando Ethereum se trasladó a la [prueba de participación](#pos). - - - Minado - - -### mint {#mint} - -Acuñar (o mintear) es el proceso de crear nuevos tókenes y ponerlos en circulación para que puedan usarse. La creación de un nuevo token sin la participación de la autoridad central es un mecanismo descentralizado. + ## N {#section-n} -### red {#network} - -Si nos referimos a la red de Ethereum, se trata de una red de punto a punto que propaga transacciones y bloques a cada nodo de Ethereum (que participe en la red). - - - Redes - - -### tasa de hash de red {#network-hashrate} - -El [hashrate](#hashrate) colectivo producido por toda una red minera. La minería en Ethereum se desató cuando Ethereum pasó a la [prueba de participación](#pos). - -### Tókenes No Fungibles (NFT) {#nft} - -También conocido como «título de propiedad», se trata de un estándar de token presentado mediante la propuesta de ERC-721. Los NFT se pueden rastrear y comercializar, no obstante, cada token es único y distinto; no son intercambiables como ETH y [ los tókenes ERC-20](#token-standard). Los NFT pueden representar la propiedad de activos digitales o físicos. - - - Tókenes No Fungibles (NFT) - - - Estándar de token no fungible ERC-721 - + -### nodo {#node} + -Un cliente de software que participa en la red. + - - Nodos y clientes - + -### nonce {#nonce} - -En criptografía, un valor que solo puede utilizarse una vez. Una cuenta nonce es un contador de transacciones en cada cuenta, que se utiliza para evitar ataques de repetición. + ## O {#section-o} -### bloque ommer (tío) {#ommer} - -Cuando un [minero de prueba de trabajo](#miner) encuentra un [bloque](#block) válido, otro minero puede haber publicado un bloque competidor que se agrega primero a la punta de la cadena de bloques. Esto es válido, pero el bloque obsoleto se puede incluir mediante bloques nuevos a modo de _ommers_ y recibir una recompensa parcial de bloque. El término «ommer» es el término de género neutral preferido para el hermano de un bloque padre, aunque algunas veces, se le denomina «tío». Esto era relevante para Ethereum cuando era una red [prueba de trabajo](#pow), pero los ommers no son una característica de [prueba de participación](#pos) Ethereum porque se selecciona precisamente un proponente de bloque en cada ranura. - -### acumulaciones optimistas (Optimistic rollups) {#optimistic-rollup} - -Un [rollup](#rollups) de transacciones que usan [pruebas de fraude](#fraud-proof) para ofrecer transacciones incrementadas en rendimiento en la [capa 2](#layer-2) mientras usa la seguridad proporcionada por la [red principal](#mainnet) (capa 1). A diferencia de [Plasma](#plasma), una solución de capa 2 parecida, las Optimistic rollups pueden gestionar tipos de transacciones más complejos; todos los que sean posibles en la [EVM](#evm). En comparación con los [Zero-knowledge Rollups](#zk-rollups), tienen problemas de latencia porque la transacción se puede desafiar mediante la prueba de fraude. + - - Rollups optimistas - + -### Oráculos {#oracle} + -Un oráculo es un puente entre la [cadena de bloques](#blockchain) y el mundo real. Actúan como [API en cadena](#api) que se pueden consultar para obtener información y usarse en [ contratos inteligentes](#smart-contract). + - - Oráculos - + ## P {#section-p} -### paridad {#parity} - -Una de las implementaciones interoperables más destacadas del software cliente de Ethereum. - -### par {#peer} - -Ordenadores conectados que ejecutan el software cliente Ethereum que tienen copias idénticas de la [cadena de bloques](#blockchain). - -### red entre pares {#peer-to-peer-network} + -Una red de ordenadores ([peers](#peer)) que colectivamente son capaces de realizar funcionalidades sin la necesidad de servicios centralizados basados en servidores. + -### Plasma {#plasma} + -Una solución de escala fuera de la cadena que usa [pruebas de fraude](#fraud-proof), como [Optimistic rollups (acumulaciones optimistas)](#optimistic-rollups). Plasma se limita a transacciones simples como transferencias básicas de tókenes e intercambios. + - - Plasma - + -### clave privada (clave secreta) {#private-key} + -Un número secreto que permite a los usuarios de Ethereum probar la propiedad de una cuenta o contratos mediante la producción de una firma digital (consulte [clave pública](#public-key), [dirección](#address), [ECDSA](#ecdsa)). + -### cadena privada {#private-chain} + -Una cadena de bloques totalmente privada es aquella con acceso autorizado, que no está disponible públicamente para su uso. + -### prueba de participación (PoS) {#pos} + -Un método mediante el que un protocolo de cadena de bloques de criptomonedas intenta lograr el [consenso](#consensus) distribuido. La PoS solicita 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 las transacciones. + - - Prueba de participación - - -### prueba de trabajo (PoW, por sus siglas en inglés) {#pow} - -Una cantidad de datos (la prueba) que precisa encontrar un cálculo significativo. - - - Prueba de trabajo - - -### clave pública {#public-key} - -Un número, derivado de una función de un solo sentido a partir de una [clave privada](#private-key), que se puede compartir públicamente y que cualquiera puede utilizar para verificar una firma digital hecha con la correspondiente clave privada. + ## R {#section-r} -### recibo {#receipt} - -Datos que devuelve un cliente de Ethereum para representar el resultado de una [transacción](#transaction) particular, que incluyen un [hash](#hash) de la transacción, su número de [bloque](#block), la cantidad de [gas](#gas) utilizado y, en caso de implementación de un [contrato inteligente](#smart-contract), la [dirección](#address) del contrato. - -### ataque de reentrada {#re-entrancy-attack} - -Un ataque que consiste en un contrato del atacante que solicita un contrato de víctima de modo que, durante la ejecución, la víctima vuelve a solicitar el contrato del atacante de manera recurrente. Las consecuencias de esta acción pueden ser, entre otras, el robo de fondos mediante la omisión de partes del contrato de la víctima que actualizan el saldo la información de las cantidades retiradas. + - - Reentrada - + -### recompensa {#reward} + -Una cantidad de ether incluida en cada nuevo bloque como recompensa que la red concede al [minero](#miner) que ha dado con la solución de la [prueba de trabajo](#pow). + -### Prefijo de Longitud Recursiva (PRL) {#rlp} + -Un estándar de codificación diseñado por los desarrolladores de Ethereum para codificar y serializar objetos (estructuras de datos) de complejidad y longitud arbitrarias. - -### acumulaciones (rollups) {#rollups} - -Un tipo de solución de escalabilidad de [capa 2](#layer-2) que agrupa varias transacciones y las envía a la [cadena principal de Ethereum](#mainnet) mediante una única transacción. Esto permite disfrutar de reducciones en el coste del [gas](#gas) y, como consecuencia, aumentos en el caudal de [transacciones](#transaction). Existen Optimistic Rollups (acumulaciones optimistas) y Zero-knowledge Rollups (acumulaciones de conocimiento cero) que utilizan diferentes métodos de seguridad para ofrecer estos beneficios de escalabilidad. - - - Agregaciones - + -### RPC {#rpc} - -**Llamada de procedimiento remoto (RPC)** es un protocolo que un programa utiliza para solicitar un servicio de un programa ubicado en otro ordenador de una red sin tener que entender los detalles de la red. - ## S {#section-s} -### Algoritmo Seguro de Hash (SHA) {#sha} - -Una familia de funciones de hash criptográficas publicadas por el NIST (siglas del Instituto Norteamericano de Estándares y Tecnología). - -### Serenity {#serenity} - -El estado de desarrollo de Ethereum que inicio una serie de actualizaciones de escalabilidad y sustentabilidad, antes conocida como «Ethereum 2.0», o «Eth2». - - - Actualizaciones de Ethereum - - -### serialización {#serialization} - -El proceso de convertir una estructura de datos en una secuencia de bytes. - -### fragmento/cadena de fragmentos {#shard} - -Las cadenas de fragmentos son secciones discretas de la cadena de bloques total de las que pueden ser responsables los subconjuntos de validadores. Esto ofrecerá un mayor rendimiento de transacciones para Ethereum y mejorará la disponibilidad de datos para [capa 2](#layer-2) soluciones como [optimistic rollups](#optimistic-rollups) y [ZK-rollups](#zk-rollups). - - - Danksharding - - -### cadena lateral {#sidechain} + -Una solución escalable que utiliza una cadena separada con diferentes o la mayoría de las veces [reglas de consenso](#reglas-de-consenso). Se necesita un puente para conectar estas cadenas laterales a la [red principal](#mainnet). Los[rollups](#rollups)también usan cadenas laterales, pero trabajan en colaboración con la [red principal](#mainnet). + - - Cadenas laterales - + -### firma {#signing} + -Demostración criptográfica de que una transacción ha sido aprobada por el titular de una clave privada específica. + -### singleton {#singleton} + -Un término de programación informática que describe un objeto del que solamente puede existir una instancia única. + -### recortador {#slasher} + -Un recortador es una entidad que escanea certificaciones en busca de conductas deplorables que se puedan penalizar con recortes. Los acuchillamientos se transmiten a la red, y el siguiente proponente de bloques añade la prueba al bloque. El proponente de bloques recibe entonces una recompensa por acuchillar el validador malicioso. + -### ranura {#slot} + -Un período de tiempo (12 segundos) en el que un [validador](#validator) puede proponer nuevos bloques en el sistema de [prueba de participación](#pos). Una ranura puede estar vacía. 32 ranuras componen una [época](#epoch). + - - Prueba de participación - + -### contrato inteligente {#smart-contract} + -Un programa que se ejecuta en la infraestructura informática de Ethereum. + - - Introducción a los contratos inteligentes - + -### SNARK {#snark} + -SNARK significa «Succinct Non-Interactive Argument of Knowledge» o (argumento breve no interactivo de conocimiento), el cual es una [prueba de conocimiento cero](#prueba-de-conocimiento-cero). + - - Rollups de Conocimiento Cero - + -### bifurcación suave {#soft-fork} + -Una divergencia en una [cadena de bloques](#blockchain) que se produce cuando cambian las [reglas de consenso](#consensus-rules). A diferencia de una [bifurcación dura](#hard-fork), una bifurcación blanda es compatible con versiones anteriores; los nodos actualizados pueden validar los bloques creados por nodos no actualizados, siempre y cuando sigan las nuevas reglas de consenso. + -### Solidity {#solidity} + -Un lenguaje de programación (imperativo) procesal con sintaxis similar a JavaScript, C++ o Java. El lenguaje más popular y utilizado para los [contratos inteligentes](#smart-contract) de Ethereum. Creado por Dr. Gavin Wood. + - - Solidez - + -### Ensamblador en línea Solidity {#solidity-inline-assembly} + -Lenguaje ensamblador de la [EVM](#evm) en un programa [Solidity](#solidity). La compatibilidad de Solidity con el ensamblado en línea facilita la escritura de determinadas operaciones. + -### Spurious Dragon {#spurious-dragon} - -Una [bifurcación dura](#hard-fork) de la cadena de bloques de Ethereum, que se produjo en el bloque 2.675.000 para abordar más vectores de ataque de denegación de servicio y limpiar el estado (consulta [Tangerine Whistle](#tangerine-whistle)). Además, es un mecanismo de protección de ataque por repetición (consulte [nonce](#nonce)). - -### monedas estables {#stablecoin} - -Un [token ERC-20](#token-standard) con un valor vinculado al valor de otro activo. Hay monedas estables respaldadas por monedas fiduciarias como dólares, metales preciosos como el oro y otras criptomonedas como el Bitcoin. - - - El ETH no es la única criptografía de Ethereum - - -### apostar {#staking} - -Depositar una cantidad de [ether](#ether) (su participación) para convertirse en un validador y asegurar la [red](#network). Un validador comprueba las [transacciones](#transaction) y propone [bloques](#block) bajo un modelo de consenso de [prueba de participación](#pos). Apostar le proporciona un incentivo económico para actuar en el mejor interés de la red. Obtendrá recompensas por llevar a cabo sus tareas como [validador](#validator), pero perderá cantidades diferentes de ETH si no las lleva a cabo. - - - Apueste sus ETH para convertirse en un validador de Ethereum - - -### participaciones agrupadas {#staking-pool} - -El ETH combinado de más de un participante de Ethereum, utilizado para alcanzar los 32 ETH necesarios para activar un conjunto de claves de validador. Un operador de nodo utiliza estas claves para participar en el consenso y las [recompensas de bloque](#block-reward) se dividen entre los participantes que contribuyen. Los grupos de participación o la delegación de participación no son nativos del protocolo Ethereum, pero la comunidad ha construido muchas soluciones. - - - Participación agrupada - - -### STARK {#stark} - -STARK significa «argumento de conocimiento transparente escalable», el cual es un tipo de [prueba cero de conocimiento](#prueba-cero-de-conocimiento). - - - Agrupaciones de conocimiento cero - - -### estado {#state} - -Una instantánea de todos los saldos y datos en un momento determinado en la cadena de bloques, que normalmente se refiere a la condición en un bloque en particular. - -### canales de estado {#state-channels} - -Una solución de [capa 2](#layer-2) en la que un canal está configurado entre los participantes y les permite realizar transacciones de manera libre y económica. Solo se envía una [transacción](#transaction) para configurar el canal y cerrar el canal la cual es enviada a la [red principal](#mainnet). Esto permite realizar transacciones muy elevadas, pero depende en gran medida de si conocemos el número de participantes y el cierre de fondos por adelantado. - - - Canales de estado - - -### supermayoría {#supermajority} - -Supermayoría es el término otorgado para una cantidad superior a 2/3 (66 %) del total del ether apostado que asegura Ethereum. Los bloques necesitan el voto de la supermayoría para [finalizar](#finalizado) en la cadena de baliza. - -### sincronización {#syncing} - -El proceso de descargar toda la última versión de una cadena de bloques en un nodo. - -### comité de sincronización {#sync-committee} - -Un comité de sincronización es un grupo seleccionado al azar de [validadores](#validator) que se actualizan cada ~27 horas. Su propósito es agregar sus firmas para validar los encabezados de los bloques. Los comités de sincronización permiten a los [clientes ligeros](#light-client) realizar un seguimiento de la cabeza de la cadena de bloques sin necesidad de acceder a todo el conjunto de validadores. - -### szabo {#szabo} - -Una denominación de [ether](#ether). 1 szabo = 1012 [wei](#wei), 106 szabo = 1 ether. + ## T {#section-t} -### Tangerine Whistle {#tangerine-whistle} - -Una [bifurcación dura](#hard-fork) de la cadena de bloques de Ethereum, que se produjo en el bloque 2.463.000 para cambiar el cálculo de [gas](#gas) para ciertas operaciones intensivas de E/S, así como para eliminar el estado acumulado de un ataque de denegación de servicio, que explotó el bajo coste de gas de esas operaciones. - -### Dificultad Total Terminal (TTD) {#terminal-total-difficulty} - -La dificultad total es la suma de la dificultad minera de Ethash para todos los bloques hasta algún punto específico de la cadena de bloques. La dificultad total terminal es un valor específico para la dificultad total que se utilizó como disparador para que los clientes de ejecución desactivaran sus funciones de minería y bloqueo de intercambio de información, lo que permite a la red hacer la transición a la prueba de participación. - -### red de prueba {#testnet} - -Una red que se usa para simular el comportamiento de la red principal de Ethereum (lea sobre la [red principal](#mainnet)). + - - Redes de pruebas - + -### token {#token} + -Un bien virtual negociable definido en contratos inteligentes en la cadena de bloques Ethereum. + -### estándar de token {#token-standard} + -Presentado mediante la propuesta de ERC-20, esto proporciona una estructura de [contrato inteligente](#smart-contract) estandarizada para tókenes fungibles. A diferencia de los [NFT](#nft), a los tókenes de un mismo contrato se les puede hacer un seguimiento, comercializarlos y son intercambiables entre sí. + - - Estándar de token ERC-20 - + -### transacción {#transaction} - -Datos comprometidos con la cadena de bloques de Ethereum, firmados por una [cuenta](#account)originaria, con una [dirección](#address) específica. La transacción contiene metadatos como el [límite de gas](#gas-limit) para esa transacción. - - - Transacciones - - -### comisión de la transacción {#transaction-fee} - -Una comisión que debe pagar siempre que utilice la red de Ethereum. Los ejemplos incluyen el envío de fondos desde su [cartera](#wallet) o una interacción [DApp](#dapp), como intercambiar tókenes o comprar un objeto de colección. Se puede entender como un cargo por servicio. Esta comisión cambiará según el nivel de actividad de la red. Esto se debe a que es probable que los [validadores](#validator), las personas responsables de procesar su transacción, dan prioridad a las transacciones con comosiones más altas, por lo que la congestión obliga a subir el precio. - -A nivel técnico, sus comosiones de transacción están relacionadas con la cantidad de [gas](#gas) que requiera su transacción. - -La reducción de las comosiones de transacción es un tema candente en este momento. Consulte [Capa 2](#layer-2). - -### desconfianza {#trustlessness} - -La capacidad de una red para mediar en las transacciones sin que ninguna de las partes involucradas tenga que confiar en un tercero. - -### Turing completo {#turing-complete} - -Un concepto que lleva el nombre del matemático y científico informático inglés Alan Turing. Un sistema de reglas de manipulación de datos (como el conjunto de instrucciones de un ordenador, un lenguaje de programación o un autómata celular) se dice que es «Turing completo» o «computacionalmente universal» si se puede utilizar para simular cualquier máquina de Turing. + ## V {#section-v} -### validador {#validator} - -Un [nodo](#node) en un sistema de [prueba de participación](#pos) responsable de almacenar datos, procesar transacciones y agregar nuevos bloques a la cadena de bloques. Para activar el software del validador, debe ser capaz de [participar con](#staking) 32 ETH. - - - Prueba de participación - - - Participación en Ethereum - - -### ciclo de vida del validador {#validator-lifecycle} - -La secuencia de estados en los que puede existir un validador. Estos incluyen: - -- Depositado: el validador ha depositado al menos 32 ETH en el [contrato de depósito](#deposit-contract). -- Pendiente: el validador está en la cola de activación a la espera de ser votado en la red por los validadores existentes. -- Activo: actualmente certificando y proponiendo bloques. -- Recortando: penaliza a un validador que haya exhibido una mala conducta y se le está recortando. -- Salida: se ha señalado al validador como candidado para salir de la red, ya sea voluntariamente o porque haya sido expulsado. + -### prueba de validez {#validity-proof} + -Modelo de seguridad para ciertas soluciones de [capa 2](#layer-2) en las que, para aumentar la velocidad, las transacciones se [agrupan](/#rollups) en lotes y se envían a Ethereum en una única transacción. El cálculo de la transacción se realiza fuera de la cadena y, a continuación, se suministra a la cadena principal con una prueba de su validez. Este método aumenta la cantidad de transacciones posibles manteniendo la seguridad. Algunos [rollups](#rollups) utilizan [pruebas de fraude](#fraud-proof). + - - Agrupaciones de conocimiento cero - + -### validium {#validium} - -Una solución fuera de la cadena que utiliza [pruebas de validación](#validity-proof) para mejorar el rendimiento de las transacciones. A diferencia de las [acumulaciones de conocimiento cero](#zk-rollup), los datos válidos no se almacenan en la capa 1 de la [red principal](#mainnet). - - - Validium - - -### Vyper {#vyper} - -Un lenguaje de programación de alto nivel con sintaxis de tipo Python. Se diseñó para acercarse a un lenguaje funcional puro. Creado por Vitalik Buterin. - - - Vyper - + ## W {#section-w} -### cartera {#wallet} - -Un software que contiene [claves privadas](#private-key). Se utiliza para acceder y controlar las cuentas de [Ethereum](#account) e interactuar con [contratos inteligentes](#smart-contract). No es necesario almacenar las claves en una cartera y, además, se pueden recuperar del almacenamiento sin conexión (es decir, con una tarjeta de memoria o un papel) para mejorar la seguridad. A pesar de su nombre, las carteras nunca almacenan las monedas o tókenes reales. - - - Carteras de Ethereum - - -### Web 3.0 {#web3} + -La tercera versión de la web. Propuesto por primera vez por el Dr. Gavin Wood, Web3 representa una nueva visión y enfoque para las aplicaciones web, desde aplicaciones de propiedad y gestión centralizada, hasta aplicaciones basadas en protocolos descentralizados (ver [DApp](#dapp)). + - - Web2 versus Web3 - - -### wei {#wei} - -La denominación más pequeña de un [ether](#ether). 1018 wei = 1 ether. + ## Z {#section-z} -### dirección cero {#zero-address} - -Una dirección de Ethereum, compuesta completamente de ceros, que se utiliza con frecuencia como dirección para eliminar los tókenes de la circulación de su propiedad. Se hace una distinción entre los tókenes eliminados formalmente del índice de un contrato inteligente a través del método burn() y los enviados a esta dirección. - -### prueba de conocimiento cero {#zk-proof} - -Una prueba de conocimiento cero es un método criptográfico que permite a los individuos probar que un enunciado o declaración es real sin tener que transmitir información adicional. - - - Agrupaciones de conocimiento cero - - -### acumulación (rollup) de conocimiento cero {#zk-rollup} + -Un [rollup](#rollups) de transacciones que utilizan [pruebas de validez](#validity-proof) a fin de ofrecer un aumento de los rendimientos de [capa 2](#layer-2), mientras se utiliza la seguridad proporcionada por la [red principal](#mainnet) (capa 1). Aunque no pueden gestionar tipos de transacción complejos, como [Optimistic Rollups](#optimistic-rollups), no tienen problemas de latencia porque las transacciones probablemente son válidas cuando se envían. + - - Acumulaciones de conocimiento cero - + ## Fuentes {#sources} -_Proporcionado parcialmente en [Dominar Ethereum](https://github.com/ethereumbook/ethereumbook) por[Andreas M. Antonopoulos, Gavin Wood](https://ethereumbook.info) bajo CC-BY-SA_ +_Proporcionado en parte por [Mastering Ethereum](https://github.com/ethereumbook/ethereumbook) de [Andreas M. Antonopoulos, Gavin Wood](https://ethereumbook.info) bajo la licencia CC-BY-SA_ ## Contribuir a esta página {#contribute-to-this-page} -¿Nos hemos dejado algo? ¿Hay algo que no sea correcto? ¡Ayúdenos a mejorar contribuyendo con este glosario en GitHub! +¿Hemos olvidado algo? ¿Hay algo incorrecto? ¡Ayúdenos a mejorar contribuyendo a este glosario en GitHub! -[Más información sobre cómo contribuir.](/contributing/adding-glossary-terms) +[Aprenda cómo contribuir](/contributing/adding-glossary-terms) diff --git a/public/content/translations/es/guides/index.md b/public/content/translations/es/guides/index.md index 0ecf8412216..e13fa859248 100644 --- a/public/content/translations/es/guides/index.md +++ b/public/content/translations/es/guides/index.md @@ -12,7 +12,7 @@ lang: es 1. [Cómo «crear» una cuenta de Ethereum](/guides/how-to-create-an-ethereum-account/): cualquiera puede crear una cartera de forma gratuita. Esta guía le mostrará por dónde empezar. -2. [Cómo usar una cartera](/guides/how-to-use-a-wallet/): una introducción a las características básicas de cualquier cartera y cómo usarlas. +2. [Cómo utilizar una cartera](/guides/how-to-use-a-wallet/) - Aprende a enviar y recibir tókenes en tu cartera y cómo conectar tu cartera a distintos proyectos. ## Aspectos básicos de la seguridad diff --git a/public/content/translations/es/how-to-create-an-ethereum-account/index.md b/public/content/translations/es/how-to-create-an-ethereum-account/index.md new file mode 100644 index 00000000000..a518e5bd293 --- /dev/null +++ b/public/content/translations/es/how-to-create-an-ethereum-account/index.md @@ -0,0 +1,73 @@ +--- +title: Cómo "crear" una cuenta de Ethereum +description: Guía paso a paso sobre la creación de una cuenta de Ethereum utilizando una billetera. +lang: es +--- + +# Cómo crear una cuenta de Ethereum + +**Cualquiera puede crear una cuenta de Ethereum de forma gratuita. ** Solo tiene que instalar una aplicación de billetera cripto. Las billeteras digitales crean y administran su cuenta de Ethereum. Permiten enviar transacciones, comprobar sus saldos y conectarlo a otras aplicaciones creadas en Ethereum. + +Con una billetera también puede instantáneamente iniciar sesión en cualquier plataforma de intercambio de tokens, juegos o mercados de [NFT](/glossary/#nft). No hay necesidad de registro individual; se comparte una cuenta para todas las aplicaciones construidas en Ethereum. + +## Paso 1: Elija una billetera + +Una cartera es una aplicación que te ayuda a gestionar tu cuenta de Ethereum. Hay docenas de billeteras diferentes para elegir: móviles, de escritorio o incluso extensiones de navegador. + + + + Lista de carteras + + +Si es nuevo, puede seleccionar el filtro «Nuevo en cripto» en la página «encontrar una cartera» para identificar las carteras que deben incluir todas las características necesarias adecuadas para principiantes. + +![Selección de filtros en la página «encontrar una cartera»](./wallet-box.png) + +También hay otros filtros de perfil para satisfacer sus necesidades. Estos son ejemplos de carteras de uso común: debería de hacer su propia investigación antes de confiar en cualquier software. + +## Paso 2: Descargue e instale la aplicación de la cartera + +Una vez que haya decidido una cartera específica, visite su sitio web oficial o la tienda de aplicaciones, descárguela e instálela. Todas deberían ser gratuitas. + +## Paso 3: Abra la aplicación y cree su cuenta de Ethereum + +La primera vez que abra su nueva cartera, es posible que se le pida que elija entre crear una nueva cuenta o importar una existente. Haga clic en «crear una nueva cuenta». **Este es el paso durante el cual el software de la billetera genera su cuenta de Ethereum. ** + +## Paso 4: Guarde su frase de recuperación + +Algunas aplicaciones le pedirán que guarde una "frase de recuperación" secreta (a veces llamada "frase semilla" o "mnemónica"). ¡Mantener esta frase segura es extremadamente importante! Esta se utiliza para generar su cuenta de Ethereum y se puede utilizar para enviar transacciones. + +**Cualquier persona que conozca la frase puede tomar el control de todos los fondos.** Nunca la comparta con nadie. Esta frase debe contener entre 12 a 24 palabras generadas al azar (el orden de las palabras importa). + +
+ +
¿Billetera instalada?
Aprenda a usarla.
+ + Cómo utilizar una cartera + + +
+ +¿Interesado en otras guías? Eche un vistazo a nuestras [Guías paso a paso](/guides/). + +## Preguntas más frecuentes + +### ¿Son mi cartera y mi cuenta de Ethereum lo mismo? + +No. La cartera es una herramienta de gestión que le ayuda a gestionar cuentas. Una sola billetera puede acceder a varias cuentas, y varias billeteras pueden acceder a una sola cuenta. La frase de recuperación se utiliza para crear cuentas y da permiso a una aplicación de billetera para administrar activos. + +### ¿Puedo enviar bitcoin a una dirección de Ethereum o ether a una dirección de bitcoin? + +No, no puede. Bitcoin y ether existen en dos redes separadas (es decir, cadenas de bloques diferentes), cada una con sus propios formatos de contabilidad y dirección. Ha habido varios intentos de unir las dos redes diferentes, de las cuales la más activa actualmente es [Wrapped Bitcoin o WBTC](https://www.bitcoin.com/get-started/what-is-wbtc/). Esto no es un aval, ya que WBTC es una solución de custodia (es decir, un solo grupo de personas controla ciertas funciones críticas) y se proporciona aquí sólo para propósitos informativos. + +### Si tengo una dirección de ETH, ¿tengo la misma dirección en otras cadenas de bloques? + +Puede usar la misma [dirección](/glossary/#address) en todas las cadenas de bloques que utilicen software subyacente similar a Ethereum (conocido como "compatible con EVM"). Esta [lista](https://chainlist.org/) le mostrará qué csdenas de bloques puede usar con la misma dirección. Algunas cadenas de bloques, como Bitcoin, implementan un conjunto de reglas de red completamente por separado y necesitará una dirección diferente con un formato diferente. Si tiene una billetera de contrato inteligente, debe consultar el sitio web de su producto para obtener más información sobre qué cadenas de bloques son compatibles, ya que generalmente estas tienen un alcance limitado pero más seguro. + +### ¿Tener mi propia cartera es más seguro que mantener mis fondos en una casa de cambio? + +Tener su propia cartera significa que usted asume la responsabilidad de la seguridad de sus activos. Desafortunadamente, hay muchos ejemplos de casas de cambio fallidas que perdieron el dinero de sus clientes. Ser propietario de una billetera (con una frase de recuperación) elimina el riesgo asociado con la confianza en alguna entidad para mantener sus activos. Sin embargo, tiene que protegerla por su cuenta y evitar estafas de phishing, aprobar transacciones accidentalmente o exponer la frase de recuperación, interactuar con sitios web falsos y otros riesgos de autocustodia. Los riesgos y beneficios son diferentes. + +### Si pierdo mi teléfono/cartera de hardware, ¿necesito usar la misma aplicación de cartera nuevamente para recuperar los fondos perdidos? + +No, puede usar una cartera diferente. Siempre y cuando tenga la frase de recuperación, puede introducirla en la mayoría de las carteras y se restaurará su cuenta. Actúe con suma cautela si alguna vez necesita hacer esto: lo mejor es asegurarse de que no está conectado a Internet al recuperar su cartera, para que su frase de recuperación no se filtre accidentalmente. A veces es imposible recuperar los fondos perdidos sin la frase de recuperación. diff --git a/public/content/translations/es/roadmap/index.md b/public/content/translations/es/roadmap/index.md index 3e86766cb89..f56b402a6af 100644 --- a/public/content/translations/es/roadmap/index.md +++ b/public/content/translations/es/roadmap/index.md @@ -109,6 +109,7 @@ El sharding está dividiendo la cadena de bloques de Ethereum para que los subco ## ¿Busca actualizaciones técnicas específicas? {#looking-for-specific-technical-upgrades} +- [Pectra](/roadmap/pectra): La bifurcación dura Praga/Electra aporta un nuevo enfoque a la abstracción de cuentas y mejora la escalabilidad, entre otras cosas. - [Danksharding](/roadmap/danksharding): Danksharding hace que las acumulaciones de capa 2 sean mucho más baratas para los usuarios al añadir «masas» de datos a los bloques de Ethereum. - [Retiradas de participación](/staking/withdrawals): la actualización de Shanghai/Capella posibilitó las retiradas de participación en Ethereum, lo que permitió a las personas desbloquear su ETH en participación. - [Finalidad de una sola ranura](/roadmap/single-slot-finality): en lugar de esperar quince minutos, los bloques podrían proponerse y finalizarse en la misma ranura. Esto resulta más práctico para las aplicaciones y mucho más difícil de atacar. diff --git a/public/content/translations/es/roadmap/verkle-trees/index.md b/public/content/translations/es/roadmap/verkle-trees/index.md index 1a2447e8678..6488f14c99e 100644 --- a/public/content/translations/es/roadmap/verkle-trees/index.md +++ b/public/content/translations/es/roadmap/verkle-trees/index.md @@ -57,6 +57,8 @@ Las redes de prueba del árbol de Verkle ya están en funcionamiento, pero todav - [Árboles Verkle para la falta de estado](https://verkle.info/) - [Dankrad Feist explica los árboles Verkle en PEEPanEIP](https://www.youtube.com/watch?v=RGJOQHzg3UQ) +- [Árboles Verkle para el resto de nosotros](https://research.2077.xyz/verkle-trees) +- [Anatomía de una prueba Verkle](https://ihagopian.com/posts/anatomy-of-a-verkle-proof) - [Guillaume Ballet explica los árboles Verkle en ETHGlobal](https://www.youtube.com/watch?v=f7bEtX3Z57o) - [«Cómo los árboles de Verkle hacen que Ethereum sean claro y directo» por Guillaume Ballet en Devcon 6](https://www.youtube.com/watch?v=Q7rStTKwuYs) - [Piper Merriam sobre clientes sin estado en ETHDenver 2020](https://www.youtube.com/watch?v=0yiZJNciIJ4) diff --git a/public/content/translations/es/web3/index.md b/public/content/translations/es/web3/index.md index 94021a37c16..253d530414f 100644 --- a/public/content/translations/es/web3/index.md +++ b/public/content/translations/es/web3/index.md @@ -6,6 +6,10 @@ lang: es # Introducción a Web3 {#introduction} +
+ +
+ La centralización ha ayudado a miles de millones de personas a conectarse a Internet y ha creado la infraestructura sólida y estable en la que vive. Al mismo tiempo, un grupúsculo de entidades centralizadas mantienen un férreo control de grandes extensiones de Internet, decidiendo unilateralmente qué se debe y qué no se debe permitir. Web3 es la respuesta a este dilema. En vez de tener una Web monopolizada por las grandes compañías de tecnología, la Web3 adopta la descentralización y se construye, opera y permanece en propiedad de sus usuarios. Web3 pone el poder en manos de los usuarios y no de las grandes empresas. Antes de hablar de Web3, vamos a explorar cómo hemos llegado aquí. diff --git a/src/intl/es/common.json b/src/intl/es/common.json index dc47cad0437..3b4ad3f704d 100644 --- a/src/intl/es/common.json +++ b/src/intl/es/common.json @@ -11,6 +11,7 @@ "adding-products": "Añadir productos", "adding-staking-products": "Añadir productos de participación", "adding-wallets": "Añadir carteras", + "ai-agents": "Agentes de IA", "aria-toggle-menu-button": "Cambiar botón de menú", "aria-toggle-search-button": "Cambiar botón de búsqueda", "beacon-chain": "Cadena de baliza", @@ -221,6 +222,7 @@ "nav-about-description": "Un proyecto público de código abierto para la comunidad Ethereum", "nav-advanced-description": "Conozca los temas más complejos", "nav-advanced-label": "Recursos avanzados", + "nav-ai-agents-description": "Descubra el mundo de los agentes de IA en Ethereum", "nav-basics-description": "Entienda lo esencial de Ethereum", "nav-basics-label": "Lo básico", "nav-bridges-description": "Web3 ha evolucionado en un ecosistema de cadenas de bloques primarios de capa 1 y soluciones de escalabilidad de capa 2", diff --git a/src/intl/es/glossary-tooltip.json b/src/intl/es/glossary-tooltip.json index 1e338427134..18136f91946 100644 --- a/src/intl/es/glossary-tooltip.json +++ b/src/intl/es/glossary-tooltip.json @@ -96,7 +96,7 @@ "multisig-term": "Multifirma", "multisig-definition": "Multisig (firma múltiple) se refiere a una billetera o cuenta digital que requiere múltiples firmas o aprobaciones para ejecutar transacciones, lo que mejora la seguridad.", "nft-term": "Token no fungible (o NFT del inglés «Non Fungible Token»)", - "nft-definition": "Un token no fungible (NFT) es un artículo digital único que puede poseer, como arte u objetos de colección, verificado por la tecnología de la cadena de bloques. Más sobre los tokens no fungibles (NFT).", + "nft-definition": "Un artículo digital único que puede poseer, como arte u objetos de colección, verificado por la tecnología de la cadena de bloques. Más información sobre los tókenes no fungibles (NFT).", "node-term": "Nodo", "node-definition": "Un cliente de software que participa en la red. Más sobre nodos y clientes.", "ommer-term": "Bloque Ommer (tío)", diff --git a/src/intl/es/glossary.json b/src/intl/es/glossary.json index 96021ab51e1..30bdb2b8f6d 100644 --- a/src/intl/es/glossary.json +++ b/src/intl/es/glossary.json @@ -112,7 +112,7 @@ "distributed-hash-table-term": "Tabla de Hash Distribuida (DHT)", "distributed-hash-table-definition": "Una estructura de datos que contiene pares (clave, valor) utilizada por los nodos de Ethereum para identificar pares a los que conectarse y determinar qué protocolos utilizar para comunicarse.", "double-spend-term": "Doble gasto", - "double-spend-definition": "Una bifurcación deliberada de la cadena de bloques en la que un usuario con una cantidad suficientemente grande de potencia de minado/participación envía una transacción moviendo moneda fuera de la cadena (por ejemplo, saliendo a dinero fiat o realizando una compra fuera de la cadena) y luego reorganizando la cadena de bloques para eliminar esa transacción. Un doble gasto exitoso deja al atacante con sus activos dentro y fuera de la cadena.", + "double-spend-definition": "Una bifurcación deliberada de la cadena de bloques en la que un usuario con una cantidad suficientemente grande de potencia de minado/participación envía una transacción que mueve moneda fuera de la cadena (por ejemplo, sacando a dinero fiduiciario o realizando una compra fuera de la cadena) y posteriomente reorganiza la cadena de bloques para eliminar esa transacción. Un doble gasto bien hecho deja al atacante con sus activos tanto dentro como fuera de la cadena.", "ecdsa-term": "Algoritmo de Firma Digital de Curva Elíptica (ECDSA)", "ecdsa-definition": "Un algoritmo criptográfico utilizado por Ethereum para garantizar que los fondos solo puedan ser gastados por sus propietarios. Es el método preferido para crear claves públicas y privadas. Relevante para la generación de direcciones de cuentas y la verificación de transacciones.", "encryption-term": "Encriptación", @@ -136,7 +136,7 @@ "erc-20-term": "ERC-20", "erc-20-definition": "ERC-20 es el estándar que la mayoría de los tokens de la red Ethereum utilizan para su creación.
Ejemplos populares son las monedas estables como DAI y USDC o los tokens de intercambio como UNI de Uniswap. Similar a cualquier forma de dinero alternativo que tengamos en los sistemas tradicionales... es decir, puntos de recompensa, sistemas de crédito o incluso acciones, etc.", "erc-721-term": "ERC-721", - "erc-721-definition": "Los NFT (tokens no fungibles) se crean utilizando un conjunto estándar de reglas conocidas como ERC-721.
Los tokens NFT pueden representar la propiedad de cualquier cosa única, como el arte digital o los coleccionables, y cada token tiene sus propias características y valor especiales. Cada NFT es único y se distingue fácilmente de cualquier otro NFT.", + "erc-721-definition": "Los NFT (tókenes no fungibles) se crean usando un conjunto estándar de reglas conocidas como ERC-721
Los tókenes NFT pueden representar la propiedad de cualquier cosa única, como el arte digital o los coleccionables, y cada token tiene sus propias características y valor especiales. Cada NFT es único y se distingue fácilmente de cualquier otro NFT.", "execution-client-term": "Cliente de ejecución", "execution-client-definition": "Los clientes de ejecución (anteriormente conocidos como \"clientes Eth1\"), como Besu, Erigon, Go-Ethereum (Geth), Nethermind, tienen la tarea de procesar y transmitir transacciones y administrar el estado de Ethereum. Realizan los cálculos de cada transacción utilizando la Máquina Virtual de Ethereum para garantizar que se sigan las reglas del protocolo.", "execution-layer-term": "Capa de ejecución", @@ -252,21 +252,21 @@ "network-hashrate-term": "Hashrate de red", "network-hashrate-definition": "El hashrate colectivo producido por toda una red de minado. El minado en Ethereum se desactivó cuando Ethereum pasó a la prueba de participación.", "nft-term": "Token no fungible (o NFT del inglés «Non Fungible Token»)", - "nft-definition": "Un token no fungible (NFT) es un artículo digital único que puede poseer, como arte u objetos de colección, verificado por la tecnología de la cadena de bloques. Más sobre los tokens no fungibles (NFT).", + "nft-definition": "Un artículo digital único que puede poseer, como arte u objetos de colección, verificado por la tecnología de la cadena de bloques. Más información sobre los tókenes no fungibles (NFT).", "node-term": "Nodo", "node-definition": "Un cliente de software que participa en la red. Más sobre nodos y clientes.", "nonce-term": "Nonce", "nonce-definition": "En criptografía, un valor que solo se puede usar una vez. Un nonce de cuenta es un contador de transacciones en cada cuenta que se utiliza para evitar ataques de repetición.", "offchain-term": "Fuera de la cadena", - "offchain-definition": "Fuera de la cadena significa cualquier transacción o dato que exista fuera de la cadena de bloques. Debido a que la comisión de cada transacción en cadena puede ser costosa e ineficiente, herramientas de terceros, como los oráculos que manejan datos de precios, o las soluciones de capa 2 que tienen un mayor rendimiento de transacciones, manejan gran parte del trabajo de procesamiento fuera de la cadena y envían información a la cadena a intervalos menos frecuentes.", + "offchain-definition": "Fuera de la cadena significa cualquier transacción o dato que exista fuera de la cadena de bloques. Debido a que la comisión de cada transacción en cadena puede ser costosa e ineficiente, herramientas de terceros —como los oráculos que manejan datos de precios; o las soluciones de capa 2, que ejecutan a un mayor rendimiento de transacciones— manejan gran parte del trabajo de procesamiento fuera de la cadena y envían información a la cadena a intervalos menos frecuentes.", "ommer-term": "Bloque Ommer (tío)", "ommer-definition": "Cuando un minero de prueba de trabajo encuentra un bloque válido, otro minero puede haber publicado un bloque en competencia que se agrega primero a la punta de la cadena de bloques. Este bloque válido, pero estancado, puede ser incluido por bloques más nuevos como ommers y recibir una recompensa de bloque parcial. El término \"ommer\" es el término de género neutral preferido para el hermano de un bloque padre (principal), pero a veces también se lo conoce como \"tío\" (uncle). Esto era común para Ethereum cuando era una red de prueba de trabajo. Ahora que Ethereum utiliza prueba de participación, solo se selecciona un proponente de bloques por ranura.", "onchain-term": "En cadena", - "onchain-definition": "Se refiere a acciones o transacciones que ocurren en la cadena de bloques y que están disponibles públicamente.

Piénselo como escribir algo en un gran cuaderno compartido que todo el mundo puede ver y comprobar, asegurándose de que lo que se escribe (como enviar dinero digital o hacer un contrato) es permanente y no se puede cambiar ni borrar.", + "onchain-definition": "Se refiere a acciones o transacciones que ocurren en la cadena de bloques y que están disponibles públicamente.

Es como escribir algo en un gran cuaderno de notas que todo el mundo puede ver y comprobar, asegurándose de que lo que se escribe (como enviar dinero digital o hacer un contrato) es permanente y no se puede cambiar ni borrar.", "optimistic-rollup-term": "Acumulaciones optimistas (Optimistic rollups)", "optimistic-rollup-definition": "Un Rollup Optimista es una solución de Capa 2 que acelera las transacciones en Ethereum, asumiendo que son válidas por defecto, a menos que se las cuestione o ponga en duda. Más información acerca de los Rollups Optimistas.", "oracle-term": "Oráculo", - "oracle-definition": "Un oráculo es un puente entre la cadena de bloques y el mundo real. Actúan como API en cadena a las que se les puede solicitar información y utilizar en contratos inteligentes. Más información sobre los oráculos.", + "oracle-definition": "Un oráculo es un puente entre la cadena de bloques y el mundo real. Actúan como las API en cadena a las que se les puede solicitar información y utilizar en contratos inteligentes. Más información sobre los oráculos.", "peer-term": "Par", "peer-definition": "Ordenadores conectados que ejecutan software cliente de Ethereum que tienen copias idénticas de la cadena de bloques.", "peer-to-peer-network-term": "Red entre pares (o peer-to-peer)", @@ -274,7 +274,7 @@ "permissionless-term": "No hay permisos", "permissionless-definition": "Sin permisos o significa que cualquiera puede unirse y utilizar un sistema como Ethereum. Está abierto a participación de todo el mundo y no requiere ninguna aprobación.", "plasma-term": "Plasma", - "plasma-definition": "Una solución fuera de la cadena que utiliza pruebas de fraude, como los rollups optimistas. Plasma se limita a transacciones sencillas como transferencias básicas de tokens e intercambios. Más información sobre Plasma.", + "plasma-definition": "Una solución de escalabilidad fuera de la cadena que utiliza pruebas de fraude, como los rollups optimistas. Plasma se limita a transacciones sencillas como transferencias básicas de tókenes e intercambios. Más información sobre plasma.", "private-key-term": "Clave privada", "private-key-definition": "Una clave privada es un código secreto que demuestra que usted es el propietario de su dinero digital y le permite gastarlo, como un PIN para su cuenta. NO LA COMPARTA.", "public-goods-term": "Bienes públicos", @@ -298,7 +298,7 @@ "recovery-phrase-term": "Frase semilla/frase de recuperación", "recovery-phrase-definition": "Una lista de palabras que recibe cuando crea una billetera digital. Actúa como una contraseña que puede ayudarle a recuperar su billetera en caso de perder el acceso a ella, asegurándose de que no pierda su dinero digital o sus tokens.", "re-entrancy-attack-term": "Ataque de reentrada", - "re-entrancy-attack-definition": "Un ataque que consiste en que un contrato atacante llama a una función de un contrato víctima, de tal forma que durante la ejecución la víctima vuelve a llamar el contrato atacante, de forma recursiva. Esto puede resultar, por ejemplo, en el robo de fondos al saltarse partes del contrato víctima que actualizan saldos o cuentan importes de retiro.< href=\"/developers/docs/smart-contracts/security/#re-entrancy\">Más información acerca de la reentrancia.", + "re-entrancy-attack-definition": "Un ataque que consiste en que un contrato atacante llama a una función de un contrato víctima, de tal forma que durante la ejecución la víctima vuelve a llamar al contrato atacante, reiteradamente. Esto puede ocasionar, por ejemplo, en el robo de fondos al saltarse partes del contrato víctima que actualizan saldos o recuentan importes de retiradaRE-Fascinación. Más información acerca de la reentrada.", "reward-term": "Recompensa", "reward-definition": "Una cantidad de ether otorgada a los validadores que realizan determinadas funciones, incluyendo proponer un bloque o participar en un comité de sincronización, en cada ranura.", "rlp-term": "Prefijo de longitud recursiva (o PRL)", @@ -380,7 +380,7 @@ "validity-proof-term": "Prueba de validez", "validity-proof-definition": "Un modelo de seguridad para ciertas soluciones de capa 2 en el que, para aumentar la velocidad, las transacciones se agrupan en lotes y se envían a Ethereum en una sola transacción. El cálculo de la transacción se realiza fuera de la cadena y luego se suministra a la cadena principal con una prueba de su validez. Este método aumenta la cantidad de transacciones posibles, al tiempo que se mantiene la seguridad. Algunos rollups usan a prueba de fraude. Más sobre los rollups de conocimiento cero.", "validium-term": "Validium", - "validium-definition": "Una solución fuera de la cadena que utiliza pruebas de validez para mejorar el rendimiento de las transacciones. A diferencia de los rollups de conocimiento cero, los datos de validium no se almacenan en la red principal de la capa 1. Más sobre validium.", + "validium-definition": "Una solución fuera de la cadena que utiliza pruebas de validez para mejorar el rendimiento de las transacciones. A diferencia de los rollups de conocimiento cero, los validum (o datos fuera de la cadena) no se almacenan en la red principal de la capa 1. Más información sobre validium.", "vyper-term": "Vyper", "vyper-definition": "Un avanzado lenguaje de programación con sintaxis tipo Python. Intenta acercarse más a un lenguaje funcional puro. Creado por Vitalik Buterin. Más sobre Vyper.", "wallet-term": "Cartera", diff --git a/src/intl/es/page-index.json b/src/intl/es/page-index.json index 5ef8bae1510..890fc921a6c 100644 --- a/src/intl/es/page-index.json +++ b/src/intl/es/page-index.json @@ -1,13 +1,14 @@ { "page-index-activity-description": "Actividad de todas las redes Ethereum", "page-index-activity-tag": "Actividad", - "page-index-activity-header": "El ecosistema más fuerte", + "page-index-activity-header": "El ecosistema más resistente", + "page-index-activity-action": "Más actividad de Ethereum", "page-index-bento-header": "Una nueva forma de utilizar Internet", - "page-index-bento-assets-action": "Más información sobre NFT", + "page-index-bento-assets-action": "Más información acerca de NFT", "page-index-bento-assets-content": "Se pueden convertir en tókenes obras de arte, certificados o incluso bienes inmuebles. Cualquier cosa puede ser un token comercializable. La propiedad es pública y verificable.", "page-index-bento-assets-title": "El Internet de los activos", "page-index-bento-dapps-action": "Explorar apps", - "page-index-bento-dapps-content": "Las aplicaciones de Ethereum funcionan sin vender sus datos. Proteja su privacidad.", + "page-index-bento-dapps-content": "Las aplicaciones de Ethereum funcionan sin vender sus datos para proteger su privacidad.", "page-index-bento-dapps-title": "Apps innovadoras", "page-index-bento-defi-action": "Explorar DeFi", "page-index-bento-defi-content": "Miles de millones de personas no pueden abrir cuentas bancarias ni utilizar libremente su dinero. El sistema financiero de Ethereum siempre es abierto e imparcial.", @@ -17,7 +18,7 @@ "page-index-bento-networks-title": "La red de redes", "page-index-bento-stablecoins-action": "Más información", "page-index-bento-stablecoins-content": "Las monedas estables, o stablecoins, son monedas que mantienen un valor estable. Su precio coincide con el del dólar estadounidense o con el de otros activos estables.", - "page-index-bento-stablecoins-title": "Cripto sin volatilidad", + "page-index-bento-stablecoins-title": "Criptomonedas sin volatilidad", "page-index-builders-action-primary": "Portal del creador", "page-index-builders-action-secondary": "Documentación", "page-index-builders-description": "Ethereum alberga el ecosistema de desarrolladores más grande y dinámico de la Web3. Use JavaScript y Python, o aprenda un lenguaje de contratos inteligentes como Solidity o Vyper para crear su propia aplicación.", @@ -99,7 +100,7 @@ "page-index-values-privacy-legacy-content-0": "No podemos esperar que los gobiernos, corporaciones u otras grandes organizaciones sin rostro nos concedan privacidad por su beneficencia.", "page-index-values-privacy-legacy-content-1": "La mayoría de las aplicaciones recopilan la mayor cantidad posible de información personal para poder enviarle marketing personalizado.", "page-index-values-privacy-ethereum-label": "Privacidad orientada", - "page-index-values-privacy-ethereum-content-0": "La comunidad de Ethereum respeta la privacidad. Tiene derecho a usar aplicaciones sin revelar su identidad ni su información de contacto.", + "page-index-values-privacy-ethereum-content-0": "La comunidad de Ethereum respeta la privacidad. Tiene derecho a usar aplicaciones sin revelar su identidad ni proporcionar sus datos de contacto.", "page-index-values-integration-legacy-label": "Fragmentación", "page-index-values-integration-legacy-content-0": "La mayoría de las aplicaciones lo presionan para crear cuentas separadas, lo que hace que sea difícil recordar todos sus datos de inicio de sesión y registros.", "page-index-values-integration-ethereum-label": "Integración", @@ -116,5 +117,5 @@ "page-index-values-open-legacy-label": "Cerrado a la mayoría", "page-index-values-open-legacy-content-0": "Las empresas protegen su propiedad intelectual y no la comparten. Nadie fuera de la empresa puede ver cómo funcionan las cosas, solucionar problemas ni realizar mejoras. Es difícil para las personas crear nuevas herramientas o personalizarlas.", "page-index-values-open-ethereum-label": "Abierto a todos", - "page-index-values-open-ethereum-content-0": "Ethereum es público para todos. Cualquiera puede ver, usar y mejorar el código, haciéndolo mejor para todos." + "page-index-values-open-ethereum-content-0": "Ethereum es de código abierto. Cualquiera puede ver, usar y mejorar el código, haciéndolo mejor para todos." } diff --git a/src/intl/es/page-layer-2-networks.json b/src/intl/es/page-layer-2-networks.json new file mode 100644 index 00000000000..306664efcef --- /dev/null +++ b/src/intl/es/page-layer-2-networks.json @@ -0,0 +1,84 @@ +{ + "page-layer-2-networks-hero-description": "Usar Ethereum hoy por hoy equivale a interactuar con cientos de redes y aplicaciones diferentes. Todas ellas respaldadas por Ethereum como hilo argumental.", + "page-layer-2-networks-meta-title": "Ethereum Capa 2: Explorar redes", + "page-layer-2-networks-more-advanced-title": "¿Busca una descripción general más avanzada?", + "page-layer-2-networks-more-advanced-descripton-1": "Muchos de los proyectos están", + "page-layer-2-networks-more-advanced-descripton-2": "aún en ciernes y son algo experimentales.", + "page-layer-2-networks-more-advanced-descripton-3": "Para obtener más información sobre la tecnología, los riesgos y las suposiciones de confianza de estas redes, recomendamos consultar L2BEAT, que proporciona un marco integral de evaluación de riesgos para cada proyecto, y growthepie para el análisis general de datos.", + "page-layer-2-networks-more-advanced-link-1": "Visite l2beat.com", + "page-layer-2-networks-more-advanced-link-2": "Visite growthepie.xyz", + "page-layer-2-networks-callout-1-description": "La robustez y la seguridad de Ethereum proporcionan una plataforma en la que otras redes pueden basarse.", + "page-layer-2-networks-callout-2-title": "¿Interesado en más detalles?", + "page-layer-2-networks-callout-2-description": "¿Siente curiosidad por la tecnología y las razones de este enfoque de escalado? Obtenga más información sobre las ideas y los distintos enfoques tecnológicos.", + "page-layer-2-networks-n/a-label": "N/P", + "page-layer-2-networks-n/a-description": "No aplicable a la red principalk de Ethereum.", + "page-layer-2-networks-robust-label": "Robustez", + "page-layer-2-networks-robust-description": "Red completamente descentralizada y segura que no puede ningún individuo ni grupo —incluidos sus creadores— puede manipular ni detener.\n\nEsta es una red que cumple con la visión de descentralización de Ethereum.", + "page-layer-2-networks-maturing-label": "Madurez", + "page-layer-2-networks-maturing-description": "Una red en transición para ser descentralizada. Un grupo de actores aún podría detener la red en situaciones extremas.", + "page-layer-2-networks-developing-label": "Desarrollo", + "page-layer-2-networks-developing-description": "Un operador centralizado ejecuta la red pero añade características de seguridad para reducir riesgos de centralización.", + "page-layer-2-networks-emerging-label": "Emerger", + "page-layer-2-networks-emerging-description": "Un operador centralizado ejecuta la red. Los datos son públicamente visibles en Ethereum para verificar si el operador está siendo honesto.", + "page-layer-2-networks-network-maturity": "Madurez de la red", + "page-layer-2-networks-network-maturity-with-colon": "Madurez de la red:", + "page-layer-2-networks-network-maturity-description": "Observa la etapa de desarrollo, los riesgos asociados con el uso de la red y el tamaño del ecosistema de la red.", + "page-layer-2-networks-summary-metric": "Este es un resumen métrico basado en el análisis de riesgos realizado por", + "page-layer-2-networks-no-results-title": "Sin resultados", + "page-layer-2-networks-no-results-description": "No hay redes coincidentes con su criterio, intente añadir algunos filtros", + "page-layer-2-networks-reset-filters": "Restablecer filtros", + "page-layer-2-networks-age": "Antigüedad", + "page-layer-2-networks-show-how-long": "Muestra cuánto tiempo han estado operativas las redes.", + "page-layer-2-networks-data-from": "Datos desde", + "page-layer-2-networks-period": ".", + "page-layer-2-networks-wallet-support": "Soporte para la cartera", + "page-layer-2-networks-how-many-wallet-support": "Indica cuántas aplicaciones de cartera admiten el uso de la red.", + "page-layer-2-networks-active-address": "Direcciones activas", + "page-layer-2-networks-active-address-weekly": "Direcciones activas (semanalmente)", + "page-layer-2-networks-active-address-number": "Número de direcciones activas en la red en los últimos 7 días.", + "page-layer-2-networks-fee-token": "Token de comisión", + "page-layer-2-networks-token-used-to-pay": "El vale que se usa para pagar por transacciones y utilizar la red.", + "page-layer-2-networks-network-usage": "Uso de la red", + "page-layer-2-networks-network-usage-overview": "Un vistazo al uso de la red. Conteo de transación medidas en áreas respectivas en los últimos 30 días.", + "page-layer-2-networks-no-data-available": "No hay datos disponibles", + "page-layer-2-networks-links": "Enlaces", + "page-layer-2-networks-official-website": "Sitio web oficial", + "page-layer-2-networks-risk-analysis": "Análises de riesgo", + "page-layer-2-networks-assessment-by-l2beat": "Evaluación por L2BEAT", + "page-layer-2-networks-detailed-analytics": "Analísticas detalladas", + "page-layer-2-networks-assessment-by-growthepie": "Evaluación por growthepie", + "page-layer-2-networks-bridge-to": "Conectar a", + "page-layer-2-networks-view-apps": "Ver aplicaciones", + "page-layer-2-networks-select-wallet": "Seleccionar cartera", + "page-layer-2-networks-search-wallets": "Buscar carteras...", + "page-layer-2-networks-no-wallet-found": "No se han encontrado carteras", + "page-layer-2-networks-robust-description-1": "Red totalmente descentralizada y segura que ningún individuo o grupo —ni siquiera sus creadores— puede manipular ni detener.", + "page-layer-2-networks-robust-description-2": "Esta es una red que cumple con la visión de descentralización de Ethereum.", + "page-layer-2-networks-developing-description-1": "Un único operador gestiona la red con visibilidad pública de datos para mayor transparencia.", + "page-layer-2-networks-emerging-description-1": "Un único operador ejecuta la red en un entorno privado y vela por la transparencia.", + "page-layer-2-networks-networks-showing": "Redes que aparecen", + "page-layer-2-networks-market-share": "Cuota de mercado", + "page-layer-2-networks-market-share-description": "Valor total bloqueado en contratos de custodia en Ethereum.", + "page-layer-2-networks-avg-transaction-fee": "Cuota de transacción media", + "page-layer-2-networks-transaction-fee": "Comisión de la transacción", + "page-layer-2-networks-transaction-fee-description": "El coste medio de transacción para transferencias, intercambios, acuñación y otras actividades.", + "page-layer-2-networks-transaction-see-networks": "Ver redes", + "page-layer-2-network-maturity-component-1": "Revisamos el progreso de la red hacia", + "page-layer-2-network-maturity-component-2": "Alineamiento Ethereum", + "page-layer-2-network-maturity-component-3": "valor total bloqueado (VTB)", + "page-layer-2-network-maturity-component-4": "tiempo de vida para producción", + "page-layer-2-network-maturity-component-5": "y consideraciones de riesgo", + "page-layer-2-network-maturity-component-6": "Estos niveles ayudan a rastrear el desarrollo de la red y proporcionan una forma normalizada de que la comunidad evalúe el progreso.", + "page-layer-2-network-maturity-component-7": "El progreso técnico por sí solo no es suficiente, la adopción por parte del usuario y la antigüedad son partes esenciales de la fuerza y madurez general en cualquier red.", + "page-layer-2-network-maturity-component-8": "Madurez", + "page-layer-2-network-maturity-component-9": "Requisitos", + "page-layer-2-network-maturity-component-10": "• Etapa 2", + "page-layer-2-network-maturity-component-11": "Al menos 1000 M $ TVL", + "page-layer-2-network-maturity-component-12": "• Etapa 1", + "page-layer-2-network-maturity-component-13": "• Al menos 150 M $TVL", + "page-layer-2-network-maturity-component-14": "• Más de 6 meses en producción", + "page-layer-2-network-maturity-component-15": "• Etapa 0", + "page-layer-2-network-maturity-component-16": "• Evaluación del riesgo: 3/5 (L2beat)", + "page-layer-2-network-maturity-component-17": "• Evaluación del riesgo: 2/5 (L2beat)", + "page-layer-2-network-maturity-component-18": "• Al menos 150 M $ TVL o más de 6 meses en producción" +} diff --git a/src/intl/es/page-staking.json b/src/intl/es/page-staking.json index 004f7c9bc3e..9b78f4d98be 100644 --- a/src/intl/es/page-staking.json +++ b/src/intl/es/page-staking.json @@ -10,7 +10,7 @@ "comp-withdrawal-comparison-new-link": "Visite Staking Launchpad", "comp-withdrawal-credentials-placeholder": "Índice del validador", "comp-withdrawal-credentials-error": "¡Vaya! Vuelva a comprobar el número de índice del validador e inténtelo de nuevo.", - "comp-withdrawal-credentials-upgraded-1": "El índice de validador {{validatorIndex}} está listo para empezar a recibir recompensas!", + "comp-withdrawal-credentials-upgraded-1": "El índice de validador {validatorIndex} está listo para comenzar a recibir recompensas", "comp-withdrawal-credentials-upgraded-2": "Credenciales de retirada vinculadas a la dirección de ejecución:", "comp-withdrawal-credentials-not-upgraded-1": "Este validador necesita una actualización.", "comp-withdrawal-credentials-not-upgraded-1-testnet": "Este validador de la red de pruebas Holesky necesita ser actualizado.", diff --git a/src/intl/es/page-upgrades-index.json b/src/intl/es/page-upgrades-index.json index bb504573c12..2cc607a7888 100644 --- a/src/intl/es/page-upgrades-index.json +++ b/src/intl/es/page-upgrades-index.json @@ -97,7 +97,7 @@ "page-upgrades-question-6-answer-5": "También puede unirse al foro sobre la investigación y el desarrollo de Ethereum en ethresearch.", "page-upgrades-question-6-title": "¿Qué tengo que hacer con mi dapp?", "page-upgrades-question-6-desc": "La Fusión se diseñó para tener un impacto mínimo en los desarrolladores de dapp, aunque hubo un par de pequeños cambios que vale la pena mencionar.", - "page-upgrades-question-6-answer-1": "Los desarrolladores de Dapp familiarizados con el Ethereum antes de la fusión deben estar al tanto de algunos cambios. Estos cambios incluyen la estructura y la sincronización de bloques, algunos cambios en el código de operación, fuentes de aleatoriedad en la cadena y del concepto de finalización de época.", + "page-upgrades-question-6-answer-1": "Los desarrolladores de DApp familiarizados con Ethereum antes de la Fusión deben estar al tanto de algunos cambios. Cambios que incluyen la estructura y la secuenciación de los bloques, algunas modificaciones en los códigos operativos, las fuentes de aleatoriedad en la cadena y el concepto de finalización de época.", "page-upgrades-question-6-answer-1-link": "Cómo La Fusión ha afectado a la capa de aplicación de Ethereum\n", "page-upgrades-question-6-answer-2": "Apenas ha afectado a las aplicaciones.", "page-upgrades-question-7-desc": "Hay numerosos equipos diferentes de toda la comunidad trabajando en las diversas actualizaciones de Ethereum.", diff --git a/src/intl/es/page-what-is-ethereum.json b/src/intl/es/page-what-is-ethereum.json index 87bea2ebe04..4e145d8d878 100644 --- a/src/intl/es/page-what-is-ethereum.json +++ b/src/intl/es/page-what-is-ethereum.json @@ -1,5 +1,5 @@ { - "page-what-is-ethereum-alt-img-bazaar": "Ilustración de una persona que entra en un bazar, que pretende representar a Ethereum", + "page-what-is-ethereum-alt-img-bazaar": "Ilustración de una persona mirando hacia un mercado, que representa Ethereum.", "page-what-is-ethereum-alt-img-comm": "Ilustración de miembros de la comunidad de Ethereum trabajando juntos", "page-what-is-ethereum-alt-img-lego": "Ilustración de una mano que construye el logo de ETH hecho de ladrillos Lego", "page-what-is-ethereum-banking-card": "Banca para todos", diff --git a/src/intl/es/template-usecase.json b/src/intl/es/template-usecase.json index b76e86377aa..285b579db9d 100644 --- a/src/intl/es/template-usecase.json +++ b/src/intl/es/template-usecase.json @@ -1,4 +1,5 @@ { + "template-usecase-dropdown-ai-agents": "Agentes de IA", "template-usecase-dropdown-defi": "Finanzas descentralizadas (DeFi)", "template-usecase-dropdown-nft": "Tókenes No Fungibles (NFT)", "template-usecase-dropdown-dao": "Organizaciones Autónomas Descentralizadas (DAO)",