Corrected

i18n/es/white-paper.md

@@ -60,7 +60,7 @@ El gestor de paquetes sabe qué software de código abierto necesita un paquete
 
 Sabe que la cima de la torre selecciona cuidadosamente sus dependencias, y que esta selección cuidadosa continúa hacia abajo. El gestor de paquetes está ubicado de manera única en el conjunto de herramientas del desarrollador para permitir una distribución de valor automatizada y precisa basada en la contribución real y práctica.
 
-Proponemos un registro descentralizado e inmutable diseñado para distribuir valor basado en el “Prueba de Contribución” único del Protocolo tea, un algoritmo que determina la contribución de cada proyecto y su impacto en la utilidad y salud del sistema. El valor puede entrar en el gráfico en puntos ápice, como bibliotecas esenciales, y distribuirse a las dependencias de esos paquetes y sus dependencias de manera recursiva, ya que el registro conoce todo el graph de código abierto.
+Proponemos un registro descentralizado e inmutable diseñado para distribuir valor basado en el “Prueba de Contribución” único del Protocolo tea, un algoritmo que determina la contribución de cada proyecto y su impacto en la utilidad y salud del sistema. El valor puede entrar en el gráfico en puntos ápice, como bibliotecas esenciales, y distribuirse a las dependencias de esos paquetes y sus dependencias de manera recursiva, ya que el registro conoce todo el grafo de código abierto.
 
 Además, creemos que la información proporcionada por el Prueba de Contribución del protocolo debe estar disponible para que los desarrolladores evalúen si pueden confiar en un proyecto y su autor. Esta información puede basarse en la reputación, el reconocimiento de la comunidad, datos obtenidos de sistemas de identidad descentralizada ("[DID](https://www.w3.org/TR/did-core/)") otros gestores de paquetes o mecanismos de incentivos que potencialmente dependen de que los participantes de la red pongan valor en riesgo.
 
@@ -70,7 +70,7 @@ Predecimos que la combinación de herramientas, información y recompensas de te
 
 Cada gestor de paquetes tiene su propio registro de paquetes, duplicando repetidamente los mismos metadatos. En algunos casos, este registro puede incluir [información que difiere del manifiesto del proyecto](https://www.bleepingcomputer.com/news/security/npm-ecosystem-at-risk-from-manifest-confusion-attacks/), permitiendo así que actores maliciosos potencialmente inyecten código nefasto sin que el usuario lo sepa. Es hora de que exista un registro único, integral y definitivo diseñado y gobernado por las comunidades que dependen de él. Este registro descentralizado e inmutable podría proporcionar seguridad, estabilidad y prevenir intenciones malévolas.
 
-Internet funciona con decenas de miles de componentes esenciales de código abierto. Es notable que hasta ahora, los incidentes causados por la eliminación de infraestructura esencial de código abierto hayan sido mínimos. El más famoso fue la [la eliminación de una dependencia de NPM left-pad](https://www.theregister.com/2016/03/23/npm\_left\_pad\_chaos/) en 2016, que se propagó a sistemas de integración continua y despliegue continuo, dejando a los desarrolladores en la estacada durante días. Este evento demostró que Internet en sí está basado en sistemas de desarrollo frágiles. Otros ejemplos involucraron la participación activa o intencional de los mantenedores de paquetes saboteando sus paquetes populares (ver [colors.js and faker.js](https://fossa.com/blog/npm-packages-colors-faker-corrupted/), así como [node-ipc](https://www.lunasec.io/docs/blog/node-ipc-protestware/)), o actores maliciosos buscando beneficiarse pretendiendo ayudar a mantener paquetes y corrompiéndolos para robar, por ejemplo, claves privadas de Bitcoin (Ver [event-stream](https://github.com/dominictarr/event-stream/issues/116)), o paquetes maliciosos con errores intencionales de ortografía, también conocidos como “[typosquatting](https://en.wikipedia.org/wiki/Typosquatting)”, con la esperanza de engañar a los usuarios para que los instalen, por ejemplo [crossenv vs. cross-env NPM packages](https://blog.npmjs.org/post/163723642530/crossenv-malware-on-the-npm-registry.html).
+Internet funciona con decenas de miles de componentes esenciales de código abierto. Es notable que hasta ahora, los incidentes causados por la eliminación de infraestructura esencial de código abierto hayan sido mínimos. El más famoso fue [la eliminación de una dependencia de NPM left-pad](https://www.theregister.com/2016/03/23/npm\_left\_pad\_chaos/) en 2016, que se propagó a sistemas de integración continua y despliegue continuo, dejando a los desarrolladores en la estacada durante días. Este evento demostró que Internet en sí está basado en sistemas de desarrollo frágiles. Otros ejemplos involucraron la participación activa o intencional de los mantenedores de paquetes saboteando sus paquetes populares (ver [colors.js and faker.js](https://fossa.com/blog/npm-packages-colors-faker-corrupted/), así como [node-ipc](https://www.lunasec.io/docs/blog/node-ipc-protestware/)), o actores maliciosos buscando beneficiarse pretendiendo ayudar a mantener paquetes y corrompiéndolos para robar, por ejemplo, claves privadas de Bitcoin (Ver [event-stream](https://github.com/dominictarr/event-stream/issues/116)), o paquetes maliciosos con errores intencionales de ortografía, también conocidos como “[typosquatting](https://en.wikipedia.org/wiki/Typosquatting)”, con la esperanza de engañar a los usuarios para que los instalen, por ejemplo [crossenv vs. cross-env NPM packages](https://blog.npmjs.org/post/163723642530/crossenv-malware-on-the-npm-registry.html).
 
 La integridad del software necesita ser garantizada a medida que la industria avanza hacia un futuro donde los activos digitales son parte del software. No podemos continuar dejándonos vulnerables a actores maliciosos que modifican el software.
 
@@ -104,9 +104,9 @@ Prueba de Contribución asigna una puntuación dinámica, denominada teaRank del
 
 Creemos que este enfoque beneficia al software fundamental alejado de la capa de aplicación (que tiende a ser la capa más visible para el público y atrae la mayor parte del interés) y extiende el mecanismo de recompensa para asegurar que todos los componentes de un proyecto, desde la cima del árbol hasta su base, sean recompensados por su contribución.
 
-Para calcular la puntuación de cada proyecto, teaRank se basa en los fundamentos establecidos por el algoritmo [Google's PageRank](https://en.wikipedia.org/wiki/PageRank). PageRank de Google es el componente definitorio del producto de búsqueda y se basa en la estructura similar a un graph de las páginas web. PageRank, en su esencia, es un algoritmo de distribución de probabilidad que asigna puntuaciones a los nodos en un graph, representando la probabilidad de que algo que navegue al azar por el graph llegue a un nodo particular. Este algoritmo es particularmente efectivo en una estructura de datos similar a un graph, como internet, porque cuantifica el impacto de cada nodo (o página web) basado en la cantidad y calidad de los bordes (enlaces) hacia él. Este algoritmo fue modificado con el tiempo para discernir mejor la topología de la web e identificar enlaces fraudulentos entre páginas web, permitiendo mitigar varios ataques.
+Para calcular la puntuación de cada proyecto, teaRank se basa en los fundamentos establecidos por el algoritmo [Google's PageRank](https://en.wikipedia.org/wiki/PageRank). PageRank de Google es el componente definitorio del producto de búsqueda y se basa en la estructura similar a un graph de las páginas web. PageRank, en su esencia, es un algoritmo de distribución de probabilidad que asigna puntuaciones a los nodos en un grafo, representando la probabilidad de que algo que navegue al azar por el graph llegue a un nodo particular. Este algoritmo es particularmente efectivo en una estructura de datos similar a un graph, como internet, porque cuantifica el impacto de cada nodo (o página web) basado en la cantidad y calidad de los bordes (enlaces) hacia él. Este algoritmo fue modificado con el tiempo para discernir mejor la topología de la web e identificar enlaces fraudulentos entre páginas web, permitiendo mitigar varios ataques.
 
-Dado que la estructura de graph de internet y el registro descentralizado del Protocolo tea comparten notables similitudes, PageRank inicialmente pareció ser un enfoque prometedor para el análisis. Sin embargo, tras experimentación adicional, se hizo evidente que las estrategias anti-spam de PageRank eran menos efectivas cuando se aplicaban a código abierto.
+Dado que la estructura de grafo de internet y el registro descentralizado del Protocolo tea comparten notables similitudes, PageRank inicialmente pareció ser un enfoque prometedor para el análisis. Sin embargo, tras experimentación adicional, se hizo evidente que las estrategias anti-spam de PageRank eran menos efectivas cuando se aplicaban a código abierto.
 
 La distinción clave radica en los metadatos del software de código abierto. A diferencia de las páginas web, la mayoría de los metadatos de paquetes de código abierto, como líneas de código y mensajes de commit, son generados por el usuario y susceptibles de ser falsificados. Los gestores de paquetes son vulnerables a campañas de spam, donde actores maliciosos inundan el registro con paquetes que contienen enlaces de phishing u otro contenido dañino. Los registros de los gestores de paquetes también pueden reflejar de manera inexacta las dependencias de proyectos específicos. Este problema, conocido como “[manifest confusion](https://www.bleepingcomputer.com/news/security/npm-ecosystem-at-risk-from-manifest-confusion-attacks/)” puede permitir a los actores maliciosos inyectar código nefasto o inflar artificialmente el impacto de dependencias de terceros, a menudo con fines nefastos.
 
@@ -223,7 +223,7 @@ Tras completar ambas operaciones, los catacatadores de tea recibirán un NFT com
 
 ### Paquetes Desactualizados o Corruptos
 
-La misión de tea es mejorar la sostenibilidad e integridad de la cadena de suministro de software permitiendo a los desarrolladores de código abierto capturar el valor que crean; sin embargo, las recompensas deben ser proporcionales a los esfuerzos desplegados por los mantenedores de paquetes y los catacatadores de tea. Los paquetes poco mantenidos, desactualizados o corruptos son claras indicaciones de que los mantenedores de paquetes no están cumpliendo con las expectativas de la comunidad o no están entregando en la confianza y el apoyo impresionados sobre ellos a través del staking de paquetes. Otra manifestación de paquetes desactualizados puede ser el uso continuado de un lenguaje heredado o una versión heredada de lenguajes multi-versión. Paquetes que permanecen desactualizados o corruptos durante demasiado tiempo indican que los catacatadores de tea necesitan revisar regular y consistentemente el trabajo de los mantenedores de paquetes.
+La misión de tea es mejorar la sostenibilidad e integridad de la cadena de suministro de software permitiendo a los desarrolladores de código abierto capturar el valor que crean; sin embargo, las recompensas deben ser proporcionales a los esfuerzos desplegados por los mantenedores de paquetes y los catacatadores de tea. Los paquetes poco mantenidos, desactualizados o corruptos son claras indicaciones de que los mantenedores de paquetes no están cumpliendo con las expectativas de la comunidad o no están cumpliendo con la confianza y el apoyo impresionados sobre ellos a través del staking de paquetes. Otra manifestación de paquetes desactualizados puede ser el uso continuado de un lenguaje heredado o una versión heredada de lenguajes multi-versión. Paquetes que permanecen desactualizados o corruptos durante demasiado tiempo indican que los catacatadores de tea necesitan revisar regular y consistentemente el trabajo de los mantenedores de paquetes.
 
 Los catacatadores de tea juegan un papel pivotal en las comunidades de código abierto, ya que sus revisiones y reclamaciones asociadas pueden influir en los usuarios de paquetes, guiándolos hacia o alejándolos de paquetes específicos. Para garantizar que las revisiones puedan ser confiables de manera continua, proponemos un mecanismo por el cual las revisiones publicadas por los catacatadores de tea deben estar asociadas con tokens TEA apostados. Los paquetes desactualizados o corruptos pueden ver una parte de su tesoro reducida, mientras que otra parte se envía al catacatador de tea que primero reconoció la falta de mantenimiento de cualquier paquete.
 
@@ -273,7 +273,7 @@ El diseño lineal recomendado debería permitir que los paquetes menos apostados
 
 Así como es necesario recompensar a los buenos actores, también es necesario identificar y penalizar a los malos actores. El software de código abierto ofrece muchas oportunidades para que los malos actores creen puntos de dolor y riesgos reputacionales para toda una comunidad de desarrolladores. Desde la apropiación indebida de trabajo hasta la alteración y redistribución de paquetes de software, o la inyección de código nefasto, la guerra entre buenos y malos actores continúa, a menudo con malos actores bien financiados que ven la contaminación de paquetes de código abierto como una oportunidad para beneficiarse financieramente. Las desventajas han sido relativamente mínimas, con paquetes potencialmente prohibidos de los estantes digitales o sujetos a una mala reputación.
 
-Para abordar directamente a los actores maliciosos e intensificar las repercusiones por acciones contrarias al código abierto, recomendamos implementar el mecanismo de slashing detallado en las secciones  “[Revisión de Paquetes por Terceros](white-paper.md#package-review-by-third-parties)” and “[Paquetes Desactualizados o Corruptos](white-paper.md#outdated-or-corrupt-packages)” sections.
+Para abordar directamente a los actores maliciosos e intensificar las repercusiones por acciones contrarias al código abierto, recomendamos implementar el mecanismo de slashing detallado en las secciones  “[Revisión de Paquetes por Terceros](white-paper.md#package-review-by-third-parties)” y “[Paquetes Desactualizados o Corruptos](white-paper.md#outdated-or-corrupt-packages)”.
 
 A medida que los catacatadores de tea evalúan y analizan el código en paquetes recién enviados, sugerimos que los catacatadores de tea reciban las herramientas e incentivos para identificar y resaltar código nefasto para que: