Merge branch 'dev' into require-namespaces-refactor

Author: pettinarip

package.json

@@ -51,6 +51,7 @@
     "@types/react-dom": "^18.2.7",
     "eslint": "^8.45.0",
     "eslint-config-next": "^14.0.0",
+    "eslint-config-prettier": "^9.0.0",
     "eslint-plugin-simple-import-sort": "^10.0.0",
     "image-size": "^1.0.2",
     "mdast-util-toc": "^7.0.0",

public/content/developers/docs/nodes-and-clients/client-diversity/index.md

@@ -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="🚨" mr="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="🚨" 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).
 
 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.
 

public/content/history/index.md

@@ -156,7 +156,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} mr="0.5rem" />Fun fact! {#altair-fun-fact}
+#### <Emoji text=":tada:" size={1} me="0.5rem" />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!
 

public/content/translations/de/developers/docs/nodes-and-clients/client-diversity/index.md

@@ -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="🚨" me="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).
 
 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.
 

public/content/translations/de/history/index.md

@@ -155,7 +155,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} mr="0.5rem" />Fun Fact! {#altair-fun-fact}
+#### <emoji text=":tada:" size={1} me="0.5rem" />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!
 

public/content/translations/es/developers/docs/nodes-and-clients/client-diversity/index.md

@@ -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="🚨" mr="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="🚨" 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.
 
 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.
 

public/content/translations/es/history/index.md

@@ -156,7 +156,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} mr="0.5rem" />¡Dato curioso! {#altair-fun-fact}
+#### <emoji text=":tada:" size={1} me="0.5rem" />¡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.
 

public/content/translations/fa/zero-knowledge-proofs/index.md

@@ -174,7 +174,7 @@ ZK-STARKها، نسبت به ZK-SNARKها اثبات‌های بزرگ‌تری
 
 استفاده از MACI نیازمند اعتماد به هماهنگ‌کننده مبنی بر تبانی نکردن با رشوه‌دهندگان یا تلاش برای رشوه دادن رای‌دهندگان از سوی او است. هماهنگ‌کننده می‌تواند پیام‌های کاربران را رمزگشایی کند (برای ایجاد اثبات لازم است)، بنابراین آن‌ها می‌توانند نحوۀ رای دادن هر فرد را به‌ طور دقیق تایید کنند.
 
-اما در مواردی که هماهنگ‌کننده صادق است، MACI ابزاری قدرتمند برای تضمین سلامت رای‌گیری آنچین است. این امر بیان‌کنندۀ دلیل محبوبیت آن در میان برنامه‌های تامین مالی ثانویه (مانند [↗clr.fund](https://clr.fund/#/about/maci)) است که به‌شدت بر صحت آرای تک‌تک افراد متکی است.
+اما در مواردی که هماهنگ‌کننده صادق است، MACI ابزاری قدرتمند برای تضمین سلامت رای‌گیری آنچین است. این امر بیان‌کنندۀ دلیل محبوبیت آن در میان برنامه‌های تامین مالی ثانویه (مانند [clr.fund](https://clr.fund/#/about/maci)) است که به‌شدت بر صحت آرای تک‌تک افراد متکی است.
 
 [درباره MACI بیشتر بیاموزید](https://github.com/privacy-scaling-explorations/maci/blob/master/specs/01_introduction.md).
 

public/content/translations/fr/developers/docs/nodes-and-clients/client-diversity/index.md

@@ -31,7 +31,7 @@ La diversité des clients offre également une résilience aux attaques. Par exe
 
 Un bogue dans un client de consensus avec plus de 33 % des nœuds Ethereum pourrait empêcher la finalisation de la chaîne phare, 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="🚨" me="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).
 
 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.
 

public/content/translations/fr/history/index.md

@@ -156,7 +156,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} mr="0.5rem" />Anecdote ! {#altair-fun-fact}
+#### <emoji text=":tada:" size={1} me="0.5rem" />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 !