ethereum · wackerow · Aug 19, 2024 · Aug 9, 2024 · Aug 9, 2024 · Aug 9, 2024
@@ -31,7 +31,7 @@ Client diversity also offers resilience to attacks. For example, an attack that
 
 A bug in a consensus client with over 33% of the Ethereum nodes could prevent the consensus layer from finalizing, meaning users could not trust that transactions would not be reverted or changed at some point. This would be very problematic for many of the apps built on top of Ethereum, particularly DeFi.
 
-<Emoji text="🚨" me="1rem" /> Worse still, a critical bug in a client with a two-thirds majority could cause the chain to <a href="https://www.symphonious.net/2021/09/23/what-happens-if-beacon-chain-consensus-fails/" target="_blank">incorrectly split and finalize</a>, leading to a large set of validators getting stuck on an invalid chain. If they want to rejoin the correct chain, these validators face slashing or a slow and expensive voluntary withdrawal and reactivation. The magnitude of a slashing scales with the number of culpable nodes with a two-thirds majority slashed maximally (32 ETH).
+<Emoji text="🚨" className="me-4" /> Worse still, a critical bug in a client with a two-thirds majority could cause the chain to <a href="https://www.symphonious.net/2021/09/23/what-happens-if-beacon-chain-consensus-fails/" target="_blank">incorrectly split and finalize</a>, leading to a large set of validators getting stuck on an invalid chain. If they want to rejoin the correct chain, these validators face slashing or a slow and expensive voluntary withdrawal and reactivation. The magnitude of a slashing scales with the number of culpable nodes with a two-thirds majority slashed maximally (32 ETH).
 
 Although these are unlikely scenarios, the Ethereum eco-system can mitigate their risk by evening out the distribution of clients across the active nodes. Ideally, no consensus client would ever reach a 33% share of the total nodes.
 

@@ -248,7 +248,7 @@ The Altair upgrade was the first scheduled upgrade for the [Beacon Chain](/roadm
 
 - [Read the Altair upgrade specification](https://github.com/ethereum/consensus-specs/tree/dev/specs/altair)
 
-#### <Emoji text=":tada:" size={1} me="0.5rem" />Fun fact! {#altair-fun-fact}
+#### <Emoji text=":tada:" size={1} className="me-2" />Fun fact! {#altair-fun-fact}
 
 Altair was the first major network upgrade that had an exact rollout time. Every upgrade prior had been based on a declared block number on the proof-of-work chain, where block times vary. The Beacon Chain does not require solving for proof-of-work, and instead works on a time-based epoch system consisting of 32 twelve-second "slots" of time where validators can propose blocks. This is why we knew exactly when we would hit epoch 74,240 and Altair became live!
 

@@ -31,7 +31,7 @@ Die Client-Vielfalt bietet auch eine gewisse Widerstandsfähigkeit gegen Angriff
 
 Ein Fehler in einem Konsensclient mit mehr als 33 % der Ethereum-Knoten könnte verhindern, dass die Konsensebene finalisieren kann. Das bedeutet, dass die Nutzer nicht darauf vertrauen können, dass Transaktionen nicht irgendwann rückgängig gemacht oder geändert werden. Dies wäre für viele der auf Ethereum aufbauenden Anwendungen, insbesondere DeFi, sehr problematisch.
 
-<Emoji text="🚨" mr="1rem" /> Schlimmer noch, ein kritischer Fehler in einem Client mit einer Zweidrittelmehrheit könnte dazu führen, dass die Chain <a href="https://www.symphonious.net/2021/09/23/what-happens-if-beacon-chain-consensus-fails/" target="_blank">nicht korrekt geteilt und finalisiert wird</a>. Dies wiederum würde dazu führen, dass eine große Anzahl von Validatoren auf einer ungültigen Chain stecken bleibt. Wenn sie sich der korrekten Chain wieder anschließen möchten, müssen diese Validatoren mit Slashing oder einem langsamen und teuren freiwilligen Rückzug und Reaktivierung rechnen. Das Ausmaß eines Slashings skaliert mit der Anzahl der schuldigen Knoten, wobei maximal eine Zweidrittelmehrheit geslashed werden kann (32 ETH).
+<Emoji text="🚨" className="mr-4" /> Schlimmer noch, ein kritischer Fehler in einem Client mit einer Zweidrittelmehrheit könnte dazu führen, dass die Chain <a href="https://www.symphonious.net/2021/09/23/what-happens-if-beacon-chain-consensus-fails/" target="_blank">nicht korrekt geteilt und finalisiert wird</a>. Dies wiederum würde dazu führen, dass eine große Anzahl von Validatoren auf einer ungültigen Chain stecken bleibt. Wenn sie sich der korrekten Chain wieder anschließen möchten, müssen diese Validatoren mit Slashing oder einem langsamen und teuren freiwilligen Rückzug und Reaktivierung rechnen. Das Ausmaß eines Slashings skaliert mit der Anzahl der schuldigen Knoten, wobei maximal eine Zweidrittelmehrheit geslashed werden kann (32 ETH).
 
 Obwohl dies unwahrscheinliche Szenarien sind, kann das Ethereum-Ökosystem das Risiko mindern, indem es die Verteilung der Clients auf die aktiven Knoten ausgleicht. Im Idealfall würde kein Konsensclient jemals einen Anteil von 33 % an der Gesamtzahl der Nodes erreichen.
 

@@ -149,7 +149,7 @@ Das Altair-Upgrade war das erste geplante Upgrade für die [Beacon Chain](/roadm
 
 - [Lesen Sie die Spezifikation zum Altair-Upgrade](https://github.com/ethereum/consensus-specs/tree/dev/specs/altair)
 
-#### <emoji text=":tada:" size={1} me="0.5rem" />Fun Fact! {#altair-fun-fact}
+#### <emoji text=":tada:" size={1} className="me-2" />Fun Fact! {#altair-fun-fact}
 
 Altair war das erste große Netzwerk-Upgrade, für das es einen genauen Einführungszeitpunkt gab. Jedes vorherige Upgrade basierte auf einer angegebenen Blocknummer auf der Proof-of-Work-Chain, bei der die Blockzeiten variieren. Die Beacon Chain erfordert kein Lösen von Proof-of-Work und arbeitet stattdessen mit einem zeitbasierten Epochensystem, das aus 32 zwölfsekündigen „Slots" besteht, in denen Validatoren Blöcke vorschlagen können. Deshalb wussten wir genau, wann wir Epoche 74.240 erreichen würden und Altair live gehen würde!
 

@@ -31,7 +31,7 @@ La diversidad de clientes también ofrece una mayor resiliencia frente a los ata
 
 Un error en un cliente de consenso con más del 33 % de los nodos de Ethereum podría impedir que la capa de consenso finalizara, lo que significa que los usuarios no podrían confiar en que las transacciones no se revirtieran o cambiarían en algún momento. Esto podría ser bastante problemático para muchas de las aplicaciones contruidas en Ethereum, especialmente las DeFi.
 
-<Emoji text="🚨" me="1rem" /> Peor aún, un error crítico en un cliente con dos tercios de mayoría haría que la cadena se <a href="https://www.symphonious.net/2021/09/23/what-happens-if-beacon-chain-consensus-fails/" target="_blank">dividiera y finalizara de manera incorrecta</a>, haciendo que un gran número de validadores se vieran involucrados en una cadena inválida. Si los validadores quisieran reincorporarse a la cadena correcta, se verían afectados por recortes o por un lento y costoso proceso de retirada y reactivación voluntaria. La magnitud de los recortes aumenta en función del número de nodos culpables, con un máximo de dos tercios de la mayoría (32 ETH) recortados.
+<Emoji text="🚨" className="me-4" /> Peor aún, un error crítico en un cliente con dos tercios de mayoría haría que la cadena se <a href="https://www.symphonious.net/2021/09/23/what-happens-if-beacon-chain-consensus-fails/" target="_blank">dividiera y finalizara de manera incorrecta</a>, haciendo que un gran número de validadores se vieran involucrados en una cadena inválida. Si los validadores quisieran reincorporarse a la cadena correcta, se verían afectados por recortes o por un lento y costoso proceso de retirada y reactivación voluntaria. La magnitud de los recortes aumenta en función del número de nodos culpables, con un máximo de dos tercios de la mayoría (32 ETH) recortados.
 
 A pesar de que es poco probable que se den estas situaciones, el ecosistema de Ethereum puede mitigar dichos riesgos igualando la distribución de clientes a través de los nodos activos. Idóneamente, ningún cliente de consenso podría alcanzar una participación del 33 % del total de los nodos.
 

@@ -150,7 +150,7 @@ La actualización Altair fue la primera programada para la [cadena de baliza](/r
 
 - [Lea las especificaciones de actualización Altair](https://github.com/ethereum/consensus-specs/tree/dev/specs/altair)
 
-#### <emoji text=":tada:" size={1} me="0.5rem" />¡Dato curioso! {#altair-fun-fact}
+#### <Emoji text=":tada:" size={1} className="me-2" />¡Dato curioso! {#altair-fun-fact}
 
 Altair fue la primera gran actualización de red que ha tenido un periodo de implementación preciso. Cada una de las actualizaciones anteriores se habían basado en un número de bloques declarados en la cadena de prueba de trabajo, donde los tiempos de bloque varían. La cadena de baliza no requiere resolución para la prueba de trabajo y, en lugar de ello, funciona en un sistema épocas basado en el tiempo, que consiste en «ranuras» de tiempo de doce segundos durante los cuales los validadores pueden proponer bloques. Por esta razón sabíamos exactamente cuándo alcanzaríamos la época 74.240 y Altair vería la luz.
 

@@ -31,7 +31,7 @@ La diversité des clients offre également une résilience aux attaques. Par exe
 
 Un bug dans un client de consensus avec plus de 33 % des nœuds Ethereum pourrait empêcher la finalisation couche de consensus, de sorte que les utilisateurs ne pourraient pas avoir confiance dans le fait que les transactions ne seraient pas annulées ou modifiées à un moment donné. Cela serait problématique pour de nombreuses applications basées sur Ethereum, en particulier pour la DeFi.
 
-<Emoji text="🚨" mr="1rem" /> Pire encore, un bogue critique dans un client avec une majorité des deux tiers pourrait causer <a href="https://www.symphonious.net/2021/09/23/what-happens-if-beacon-chain-consensus-fails/" target="_blank">le fractionnement et la finalisation incorrecte de la chaîne</a>, entraînant le blocage d'un grand nombre de validateurs sur une chaîne invalide. S'ils souhaitent rejoindre la bonne chaîne, ces validateurs sont confrontés à un délestage ou à un retrait volontaire et à une réactivation lente et coûteuse. La magnitude d'un délestage est proportionnelle au nombre de nœuds impliqués avec une majorité des deux tiers sanctionnée au maximum (32 ETH).
+<Emoji text="🚨" className="mr-4" /> Pire encore, un bogue critique dans un client avec une majorité des deux tiers pourrait causer <a href="https://www.symphonious.net/2021/09/23/what-happens-if-beacon-chain-consensus-fails/" target="_blank">le fractionnement et la finalisation incorrecte de la chaîne</a>, entraînant le blocage d'un grand nombre de validateurs sur une chaîne invalide. S'ils souhaitent rejoindre la bonne chaîne, ces validateurs sont confrontés à un délestage ou à un retrait volontaire et à une réactivation lente et coûteuse. La magnitude d'un délestage est proportionnelle au nombre de nœuds impliqués avec une majorité des deux tiers sanctionnée au maximum (32 ETH).
 
 Bien que ces scénarios soient peu probables, l’écosystème Ethereum peut atténuer leurs risques en éliminant la distribution des clients sur les nœuds actifs. Idéalement, aucun client de consensus ne devrait pouvoir atteindre 33 % du total des nœuds.
 

@@ -150,7 +150,7 @@ La mise à niveau Altair était la première mise à niveau répertoriée pour l
 
 - [Lire les spécifications de la mise à niveau Altair](https://github.com/ethereum/consensus-specs/tree/dev/specs/altair)
 
-#### <emoji text=":tada:" size={1} me="0.5rem" />Anecdote ! {#altair-fun-fact}
+#### <Emoji text=":tada:" size={1} className="me-2" />Anecdote ! {#altair-fun-fact}
 
 Altair a été la première mise à jour majeure du réseau à disposer d'un délai de mise en œuvre précis. Toutes les mises à niveau antérieures étaient basées sur un numéro de bloc déclaré sur la chaîne de preuve de travail, dans laquelle les durées de blocage varient. La chaîne phare ne nécessite pas de résoudre de preuve de travail, mais fonctionne sur la base d'un système de périodes composées de 32 créneaux de 12 secondes pendant lesquels les validateurs peuvent proposer des blocs. C'est pourquoi nous savions exactement quand nous atteindrions l'époque 74 240 et la date de sortie d'Altair !
 

@@ -31,7 +31,7 @@ A kliensdiverzitás nagyobb ellenállást jelent a támadásokkal szemben. Péld
 
 Egy olyan hiba a konszenzusos kliensben, amely az Ethereum-csomópontok több mint 33%-át érinti, meg tudja akadályozni azt, hogy a konszenzusréteg véglegesedjen, tehát a felhasználók nem tudhatják, hogy a tranzakcióik nem lesznek visszaforgatva vagy megváltoztatva valamikor. Ez rendkívül problémás helyzet az Ethereumra épült alkalmazások számára, főleg a decentralizált pénzügy (DeFi) területén.
 
-<Emoji text="🚨" me="1rem" /> Még ennél is rosszabb, ha egy kétharmados többséggel bíró kliensben történik hiba, ami miatt a lánc <a href="https://www.symphonious.net/2021/09/23/what-happens-if-beacon-chain-consensus-fails/" target="_blank">hibásan szétválik és véglegesedik</a>, így a validátorok egy jó része egy valótlan láncon ragad. Ha ezek a validátorok újra a helyes lánchoz akarnának csatlakozni, akkor súlyos büntetéssel, vagy egy lassú és költséges visszavonási és újraaktviálási folyamattal néznének szembe. A súlyos büntetés mértéke arányos a kétharmados többség hibás csomópontjainak számával, melynek a letétjét (32 ETH) teljesen megsemmisítik.
+<Emoji text="🚨" className="me-4" /> Még ennél is rosszabb, ha egy kétharmados többséggel bíró kliensben történik hiba, ami miatt a lánc <a href="https://www.symphonious.net/2021/09/23/what-happens-if-beacon-chain-consensus-fails/" target="_blank">hibásan szétválik és véglegesedik</a>, így a validátorok egy jó része egy valótlan láncon ragad. Ha ezek a validátorok újra a helyes lánchoz akarnának csatlakozni, akkor súlyos büntetéssel, vagy egy lassú és költséges visszavonási és újraaktviálási folyamattal néznének szembe. A súlyos büntetés mértéke arányos a kétharmados többség hibás csomópontjainak számával, melynek a letétjét (32 ETH) teljesen megsemmisítik.
 
 Habár ezek nem valószínű szcenáriók, az Ethereum ökoszisztémája képes a kockázatot csökkenteni azzal, hogy az aktív csomópontokon keresztül egyenlően oszlanak el a kliensek. Ideális esetben a teljes csomópontok 33%-át nem dominálja egy adott konszenzusos kliens.
 

@@ -248,7 +248,7 @@ Az Altair frissítés a [Beacon lánc](/roadmap/beacon-chain) első tervezett v
 
 - [Olvassa el az Altair frissítés specifikációit](https://github.com/ethereum/consensus-specs/tree/dev/specs/altair)
 
-#### <emoji text=":tada:" size={1} me="0.5rem" />Érdekesség! {#altair-fun-fact}
+#### <Emoji text=":tada:" size={1} className="me-2" />Érdekesség! {#altair-fun-fact}
 
 Az Altair volt az első nagyobb hálózati frissítés, aminek konkrét bevezetési ideje volt. Az összes korábbi frissítés egy adott blokkszám alapján történt a proof-of-work láncon, ahol a blokkonkénti idő változó. A Beacon láncnak nem kellett igazodnia a proof-of-workhöz, így időalapú korszakok rendszerén alapszik, amelyek 32 darab 12 másodperces slotból állnak, és a validátorok ezekben tudnak blokkot javasolni. Így pontosan lehetett tudni, hogy mikor következik a 74 240. korszak, hogy az Altair életbe léphessen!
 

@@ -150,7 +150,7 @@ Peningkatan Altair adalah peningkatan pertama yang terjadwal untuk [Rantai Suar]
 
 - [Baca spesifikasi peningkatan Altair](https://github.com/ethereum/consensus-specs/tree/dev/specs/altair)
 
-#### <Emoji text=":tada:" size={1} me="0.5rem" />Fakta menyenangkan! {#altair-fun-fact}
+#### <Emoji text=":tada:" size={1} className="me-2" />Fakta menyenangkan! {#altair-fun-fact}
 
 Altair adalah peningkatan besar dan pertama untuk jaringan yang memiliki waktu rollout yang pasti. Setiap peningkatan sebelumnya telah berdasarkan pada suatu nomor blok yang dideklarasikan pada rantai bukti kerja, dengan waktu blok yang bervariasi. Rantai Suar tidak mengharuskan penyelesaian bukti kerja, dan sebagai gantinya berfungsi pada sistem jangka waktu berbasis waktu yang terdiri dari 32 "slot" waktu dua belas detik di mana para validator dapat mengusulkan blok. Inilah alasan kami mengetahui secara pasti kapan kami akan mencapai jangka waktu 74.240 dan Altair mulai beroperasi!
 

@@ -31,7 +31,7 @@ La diversità dei client offre anche resistenza agli attacchi. Ad esempio, un at
 
 Un bug in un client di consenso con oltre il 33% dei nodi di Ethereum potrebbe impedire la finalizzazione del livello di consenso, il che significa che gli utenti non possono essere sicuri che le transazioni non vengano annullate o modificate ad un certo punto. Questo sarebbe molto problematico per molte delle app basate su Ethereum, in particolare, le DeFi.
 
-<Emoji text="🚨" me="1rem" /> Ancora peggio, un bug critico in un client con una maggioranza di due terzi potrebbe causare la <a href="https://www.symphonious.net/2021/09/23/what-happens-if-beacon-chain-consensus-fails/" target="_blank">una divisione e finalizzazione errata</a> della catena, bloccando un gran numero di validatori su una catena non valida. Se vogliono rientrare nella catena corretta, quei validatori devo sottoporsi a tagli (slashing) o a un prelievo volontario, costoso e lento, e alla riattivazione. L'ammontare del taglio (slashing) aumenta col numero di nodi colpevoli, potendo interessare al massimo una maggioranza di due terzi (32 ETH).
+<Emoji text="🚨" className="me-4" /> Ancora peggio, un bug critico in un client con una maggioranza di due terzi potrebbe causare la <a href="https://www.symphonious.net/2021/09/23/what-happens-if-beacon-chain-consensus-fails/" target="_blank">una divisione e finalizzazione errata</a> della catena, bloccando un gran numero di validatori su una catena non valida. Se vogliono rientrare nella catena corretta, quei validatori devo sottoporsi a tagli (slashing) o a un prelievo volontario, costoso e lento, e alla riattivazione. L'ammontare del taglio (slashing) aumenta col numero di nodi colpevoli, potendo interessare al massimo una maggioranza di due terzi (32 ETH).
 
 Sebbene questi siano scenari improbabili, l'ecosistema di Ethereum può mitigarne il rischio equilibrando la distribuzione dei client tra i nodi attivi. Idealmente, nessun client del consenso dovrebbe mai raggiungere una quota del 33% dei nodi totali.
 

@@ -150,7 +150,7 @@ L'aggiornamento Altair è stato il primo aggiornamento pianificato per la [Beaco
 
 - [Leggi le specifiche dell'aggiornamento di Altair](https://github.com/ethereum/consensus-specs/tree/dev/specs/altair)
 
-#### <emoji text=":tada:" size={1} me="0.5rem" />Curiosità! {#altair-fun-fact}
+#### <Emoji text=":tada:" size={1} className="me-2" />Curiosità! {#altair-fun-fact}
 
 Altair è stato il primo importante aggiornamento di rete che ha avuto un tempo di rollout esatto. Tutti gli aggiornamenti precedenti erano basati su un numero di blocco dichiarato su una catena proof-of-work, dove i tempi del blocco variavano. La Beacon Chain non richiede la risoluzione del proof-of-work e funziona invece su un sistema di epoche basato sul tempo che consiste in 32 "slot" di dodici secondi in cui i validatori possono proporre dei blocchi. Questo è il motivo per cui sapevamo esattamente quando avremmo raggiunto l'epoca 74.240 e Altair sarebbe diventato operativo!