1. ¿Puede el Consenso Arreglar las Cadenas de Bloques?

Los mecanismos de consenso garantizan que cada computadora en la red esté de acuerdo en qué transacciones se validan de manera consistente y segura y se agregan a la cadena de bloques, según un conjunto de reglas de consenso.

Cada blockchain intenta lograr un equilibrio con respecto al trilema del blockchain: equilibrar la velocidad, la seguridad y la descentralización. Los proyectos a menudo solo pueden priorizar dos características a expensas de una tercera.

Los mecanismos de consenso son esenciales para evitar que actores malintencionados logren alterar con éxito la red o sus datos. Previenen el doble gasto y mantienen todo sincronizado, asegurando que cada nodo en la cadena de bloques produzca la misma secuencia de transacciones para cada bloque.

Piensa en ellos como las reglas de un juego descentralizado, guiando a los participantes hacia una “verdad” unificada. Aquí tienes un resumen de los mecanismos de consenso clave:

Prueba de Trabajo (PoW): Los mineros resuelven acertijos complejos con potencia informática para agregar bloques, y son recompensados con criptomonedas. Es seguro pero consume mucha energía y es lento (por ejemplo, Bitcoin, Ethereum anterior a 2022).

Prueba de participación (PoS): Los validadores apuestan criptomonedas para tener la oportunidad de crear bloques. Este método es eficiente en energía y más rápido, pero puede favorecer a participantes más ricos (por ejemplo, Ethereum después de 2022, Cardano).

Delegated Proof of Stake (DPoS): Los titulares de tokens votan por delegados para validar transacciones, ofreciendo velocidad y escalabilidad pero arriesgando la centralización (por ejemplo, EOS, Tron).

Prueba de Autoridad (PoA): Nodos de confianza validan basados en identidad, lo que lo hace rápido y eficiente pero menos descentralizado (por ejemplo, VeChain).

A pesar de la promesa de descentralización presentada por las cadenas de bloques, rara vez se traducen en el rendimiento esperado, especialmente para las blue chips:

Bitcoin promedia 7 transacciones por segundo (TPS).

Ethereum post-PoS alcanza 15-30 TPS.

Visa, por el contrario, promedia 1,700 TPS diariamente.

Estas brechas provocan retrasos, congestión y altas tarifas, exponiendo desafíos de escalabilidad.

1.2 Nuevos Modelos de Consenso

Emergentes Layer-1s (L1) como@Hyperliquidx, @Monad_xyz, y @Soniclabsestán llevando a nuevos mecanismos de consenso diseñados específicamente para resolver estos desafíos, aumentando la velocidad, la escalabilidad y el impacto al mismo tiempo que fomentan la confianza.

Este artículo ofrece un examen profundo de cómo estos proyectos abordan el trilema de la cadena de bloques, avanzando en el diseño del consenso. Nos adentramos en el trasfondo de cada proyecto, mecanismos de consenso, relación con Ethereum, soluciones de escalabilidad, aplicaciones prácticas, enfoques de financiamiento y gobernanza, y desafíos principales.

2 Hyperliquid

Hyperliquid es una cadena de bloques L1 construida para el comercio descentralizado de alta velocidad y bajo costo. Se divide en dos pilares:

HyperCore: un motor en cadena para futuros perpetuos y libros de órdenes al contado con finalidad en un bloque.

HyperEVM: una plataforma de contratos inteligentes compatible con Ethereum.

Mientras que las L1 tradicionales enfrentan compensaciones entre la descentralización, el rendimiento y la accesibilidad, Hyperliquid busca superar estos desafíos al ofrecer un ecosistema de trading en cadena de alto rendimiento y completamente en cadena.

HyperCore puede procesar hasta 200,000 órdenes por segundo, un pico teórico establecido para crecer con las actualizaciones de software del nodo.

HyperEVM introduce la plataforma de contratos inteligentes de Ethereum a Hyperliquid, ofreciendo la liquidez y herramientas financieras de HyperCore como recursos abiertos.

Con HyperCore y HyperEVM, el equipo tiene como objetivo permitir la interacción sin problemas entre aplicaciones descentralizadas (dApps) y componentes de blockchain sin sacrificar la eficiencia o la experiencia del usuario.

2.1 Mecanismo de Consenso

Inicialmente, Hyperliquid empleó el algoritmo de consenso Tendermint. Sin embargo, era necesario una solución más avanzada para respaldar mejor el trading de alta frecuencia y lograr una mayor capacidad de transacción.

Para abordar esto, Hyperliquid desarrolló un mecanismo de consenso llamado HyperBFT. Este sistema híbrido combina PoS con Tolerancia a Fallas Bizantinas (BFT), y está optimizado para un alto rendimiento, baja latencia y seguridad sólida.

El modelo de PoS se basa en el protocolo HotStuff, donde los validadores generan bloques mediante el staking$HYPEtokens. El enfoque híbrido de HyperBFT es más eficiente en términos energéticos que los métodos tradicionales de PoW, manteniendo al mismo tiempo una seguridad robusta.

2.2 Escalabilidad y Velocidad

HyperBFT logra una finalidad mediana de 0.2 segundos y una latencia inferior a 0.9 segundos. El libro de órdenes en cadena imita la precisión del intercambio centralizado, admitiendo un apalancamiento de 50x, trading con un clic y órdenes de stop-loss.

Hyperliquid se destaca en escenarios de alto rendimiento, procesando 200,000 TPS simultáneamente sin particionamiento. Actualmente, esto está limitado principalmente por la latencia de red y la dispersión de validadores.

2.3 Desafíos

Bajo número de validadores (seguridad): Hyperliquid es relativamente centralizado, con solo 16 validadores en comparación con la vasta red de más de 800k validadores de Ethereum. Su objetivo es expandir su conjunto de validadores a medida que la red crece, alineándose con su objetivo de descentralización.

Resistencia no probada contra importantes ciberataques, planteando preguntas sobre su descentralización y robustez a largo plazo. Esta centralización plantea riesgos de seguridad, especialmente en lo que respecta a los $2.3 mil millones $USDCen el puente, objetivo de un intento de piratería en 2024.

Impacto de la centralización: En marzo de 2025, Hyperliquid se enfrentó a un incidente con el$JELLYtoken. Un trader manipuló el sistema de liquidación de la plataforma creando tres cuentas y tomando posiciones apalancadas: dos largas por un total de $4.05 millones y una corta de $4.1 millones en$JELLYfuturos. Esto llevó a un aumento de precios del 400% y el trader se auto-liquidó, lo que hizo que la bóveda de Hyperliquid asumiera una posición corta de $6 millones. Esto resultó en pérdidas no realizadas para los proveedores de liquidez, estimadas entre $700,000 y $10 millones. Sin embargo, después de la intervención de Hyperliquid, la bóveda obtuvo una ganancia de $700,000, ya que Hyperliquid terminó por retirar la listado$JELLYcontrato, lo que desató debates sobre descentralización y transparencia en la gobernanza.

Riesgos de operaciones apalancadas: el 13 de marzo de 2025, una ballena liquidó $ETHposiciones largas a través de operaciones de alto apalancamiento, lo que resultó en una pérdida de aproximadamente $4 millones en la Bóveda HLP. Tales eventos resaltan la vulnerabilidad de la plataforma a la manipulación del mercado y la necesidad de estrategias sólidas de gestión de riesgos.

Competencia: El código cerrado de Hyperliquid y la ausencia de penalizaciones automatizadas para validadores limitan la transparencia y la resistencia. La competencia de plataformas de alto rendimiento como Solana, L1 emergentes como Monad y MegaETH y DEXs avanzados como dYdX presentan desafíos.

Escalabilidad: Hyperliquid está diseñado para la escalabilidad, manejando hasta 200,000 TPS con finalidad en menos de un segundo. Sin embargo, condiciones extremas como operaciones apalancadas masivas pueden presentar desafíos como tensión de liquidez o retrasos en la coordinación de validadores.

3. Monad

Monad es un L1 compatible con EVM para escalabilidad y rendimiento, utilizando ejecución paralela y MonadBFT.

Monad apunta a hasta 10k TPS con bloques producidos cada 500 ms y finalizados en un segundo. Promueve la descentralización mientras aborda los cuellos de botella de Ethereum (por ejemplo, velocidades lentas, altas tarifas y escalabilidad limitada). Su red de prueba se lanzó el 19 de febrero de 2025, con especulaciones sobre el lanzamiento de la red principal en el tercer o cuarto trimestre de 2025.

3.1 Mecanismo de Consenso

La arquitectura de Monad se centra en su mecanismo de consenso personalizado MonadBFT, una evolución optimizada del protocolo BFT HotStuff.

Integra la ejecución en pipeline y una comunicación eficiente para distinguirse de los diseños tradicionales de blockchain.

MonadBFT: Este algoritmo convierte el proceso de tres fases de HotStuff en dos, mejorando la velocidad de los validadores. Los validadores rotan como líderes: uno propone un bloque y reúne votos anteriores en un certificado de quórum (QC), una prueba de consenso para certificar el bloque anterior. Un mecanismo de tiempo de espera mantiene la red robusta si un líder falla, garantizando la seguridad en entornos parcialmente síncronos.

Ejecución Paralela: La ejecución paralela se refiere a la capacidad de procesar múltiples tareas o transacciones simultáneamente, en lugar de una a la vez. Los nodos acuerdan el orden de las transacciones primero, luego ejecutan transacciones de manera concurrente en múltiples hilos utilizando un enfoque optimista. Esto garantiza la consistencia con resultados secuenciales mientras aumenta significativamente el rendimiento.

PoS: Los validadores apuestan tokens para participar, asegurando la red a través de incentivos económicos. Este sistema PoS equilibra la velocidad y la seguridad, con activos apostados que desalientan acciones maliciosas.

MonadBFT ofrece finalidad escalable y fiable para dApps en tiempo real al reducir la sobrecarga de comunicación,

El diagrama a continuación ilustra el proceso de canalización de MonadBFT, mostrando cómo los validadores (Alice, Bob, Charlie, David, etc.) proponen, votan y finalizan bloques (N, N+1, N+2, etc.) a través de rondas superpuestas.

Cada bloque avanza a través de etapas: propuesto, votado y finalizado. Los validadores rotan el liderazgo, produciendo QCs para certificar bloques.

3.2 Escalabilidad y Velocidad

Monad combina la eficiencia de MonadBFT con la ejecución paralela, lo que le permite superar a los L1 tradicionales al manejar transacciones de forma concurrente, evitando el particionamiento y garantizando una finalización rápida. Su capacidad teórica podría ser mayor a la mencionada anteriormente (10k TPS, finalidad en menos de un segundo), aunque los resultados en el mundo real dependen de la latencia de la red y la distribución de los validadores.

3.3 Desafíos

Complejidad de ejecución: la ejecución paralela optimista de Monad podría conducir a inconsistencias, retrocesos o vulnerabilidades (por ejemplo, explotaciones de casos límite). Sus características avanzadas (MonadBFT y ejecución paralela) añaden complejidad, aumentando los costos de desarrollo y mantenimiento, especialmente para equipos más pequeños. Esto puede obstaculizar el crecimiento y la seguridad, desafiando a equipos más pequeños y haciéndolo más favorable para equipos con más recursos y experiencia en desarrollo.

Latencia de red: TPS del mundo real y finalidad dependen de la distribución de validadores y latencia, lo que puede implicar un rendimiento deficiente.

Escala no probada: antes de la red principal, la afirmación de 10,000 TPS de Monad sigue sin probarse, con posibles errores o cuellos de botella.

Competencia: Plataformas de alto rendimiento como Sonic, Arbitrum y Solana podrían desafiar la adopción por parte de desarrolladores y usuarios.

Curva de aprendizaje: A pesar de la compatibilidad con EVM, los sistemas únicos de Monad (MonadBFT, MonadDB) pueden ralentizar la integración de desarrolladores.

Centralización: El control temprano de la Fundación y un modelo de token concentrado podrían centralizar el poder, amenazando la descentralización y la seguridad a largo plazo.

4. Sonic

Sonic es un L1 compatible con EVM para un alto rendimiento y finalidad de transacción en sub-segundo, evolucionando desde el ecosistema Fantom Opera.

Sonic introduce mejoras operativas destacadas: su último protocolo de consenso, SonicCS 2.0, logra un aumento de 2 veces en la velocidad de consenso y una reducción del 68% en el uso de memoria por época (de 420 MB a 135 MB), reduciendo las demandas de recursos para validadores y mejorando la escalabilidad.

Estas actualizaciones abordan varios desafíos de la cadena de bloques:

Procesamiento lento de transacciones

Altos costos operativos

Ecosistemas fragmentados

Con una identidad renovada, Sonic incentiva a los desarrolladores redistribuyendo hasta el 90% de las tarifas de transacción de la red a través de su programa de Monetización de Tarifas (FeeM), fomentando la creación y adopción de dApp.

4.1 Mecanismo de Consenso

El consenso de Lachesis de Sonic combina Grafos Acíclicos Dirigidos (DAGs) con Tolerancia a Fallas Bizantinas Asincrónicas (ABFT), avanzando más allá de la base de Fantom Opera.

ABFT: permite a los validadores procesar transacciones e intercambiar bloques de forma asincrónica. Esto elimina las demoras secuenciales de los sistemas basados en Tolerancia a Fallas Bizantinas Prácticas (PBFT), mejorando el rendimiento y la resiliencia.

DAG: Las transacciones se representan como vértices y las dependencias como bordes DAG, lo que permite adiciones de bloques concurrentes. Esto acelera la validación en comparación con los diseños de cadena lineal, formando una estructura interconectada similar a una red en lugar de una sola cadena.

PoS: Los validadores apuestan un mínimo de 500k $Stokens para participar, agrupando transacciones en bloques de eventos dentro de DAG locales. Se alcanza consenso cuando los validadores suficientes confirman estos bloques como "raíces" en la cadena principal, logrando una finalidad de sub-segundo. Este sistema de PoS equilibra velocidad, seguridad y descentralización, con tokens apostados que disuaden el mal comportamiento.

La figura a continuación ilustra un DAG para un nodo específico:

Los eventos naranjas representan eventos de líder candidato

Los eventos amarillos indican eventos de líder comprometidos.

Los eventos posicionados entre estos líderes pueden ser secuenciados en una cadena, lo que permite la extracción de una lista de transacciones para construir un bloque.

4.2 SonicCS 2.0 - Su última actualización de mecanismo de consenso

Sonic recientemente actualizó su mecanismo de consenso con SonicCS 2.0, presentado el 27 de marzo de 2025. Este protocolo aprovecha un enfoque basado en DAG con elecciones superpuestas, reduciendo el esfuerzo computacional y el uso de memoria en un 68%. Experimentos con 200 épocas de datos de la red principal de Sonic demuestran una aceleración promedio de 2.04 veces (que varía de 1.37 a 2.62 veces) y una eficiencia de memoria significativa, reforzando la capacidad de Sonic para procesar más de 10k TPS con finalidad en menos de un segundo. SonicCS 2.0 está programado para implementarse en la red principal pronto, con un informe técnico detallado próximo.

4.3 Escalabilidad y Velocidad

El consenso híbrido Lachesis de Sonic fusiona la adaptabilidad de DAG con la integridad de ABFT, ofreciendo una finalidad de transacción rápida y segura sin necesidad de fragmentación. Este diseño soporta una escalabilidad fluida a medida que crece la demanda de la red.

SonicCS 2.0 puede potencialmente impulsar el rendimiento de la red principal de Sonic más cerca de las estimaciones teóricas de 396,825 TPs. Sin embargo, es importante señalar que los resultados prácticos dependen de la latencia de la red y la distribución de los validadores. Según @AndreCronjetechel TPS máximo en tiempo real medido en Sonic ya era de alrededor de 5,140, lo cual es bastante impresionante.

Sonic es completamente compatible con EVM, optimizando el rendimiento dentro de este marco en lugar de reemplazarlo con una máquina virtual distinta. Las operaciones vectorizadas de SonicCS 2.0 y las elecciones superpuestas mejoran la eficiencia del validador y el rendimiento de la dApp.

Fuente: Chainspect

4.4 Desafíos

Complejidad del consenso: Bajo una carga alta, el mecanismo de consenso de Sonic puede introducir dependencias intrincadas o retrasos en la validación, lo que pone en riesgo la eficiencia o posibles explotaciones.

Adaptación del desarrollador: Si bien compatible con EMV, las características avanzadas de Sonic (por ejemplo, la votación vectorizada de SonicCS 2.0) pueden requerir que los desarrolladores ajusten los flujos de trabajo, lo que podría ralentizar la adopción.

Latencia de red: La finalidad en menos de un segundo y 10k TPS dependen de la distribución de validadores y la latencia, lo que podría degradar el rendimiento en el mundo real.

Escala no probada: Antes del lanzamiento de la red principal Pre-SonicCS 2.0, la afirmación de 10k TPS carece de validación completa en el mundo real y es posible que aún no hayan surgido cuellos de botella o errores.

Dominio de L2: Las soluciones de L2 de Ethereum (por ejemplo, Optimism, zkSync) ofrecen un rendimiento similar a costos más bajos, aprovechando la amplia liquidez y ecosistemas de desarrolladores. El puente Sonic Gateway de Sonic ayuda a la interoperabilidad, pero competir como un L1 independiente sigue siendo un desafío.

Centralización: Los 500,000$SEl requisito de participación y el control temprano por la Fundación Sonic ponen en riesgo la centralización del poder, lo que potencialmente podría alienar a los usuarios centrados en la descentralización y debilitar la seguridad si la distribución de tokens favorece a los insiders.

5. Tabla Comparativa

6. Aprovechando el Ecosistema de Ethereum

Hyperliquid, Monad y Sonic aprovechan la compatibilidad con EVM, lo que permite a los desarrolladores implementar dApps en infraestructuras de alta velocidad utilizando herramientas familiares y contratos inteligentes. Esto proporciona transacciones de bajo costo y alta capacidad con una seguridad sólida, aprovechando el ecosistema de Ethereum sin necesidad de reescribir código.

Impulsando diversas dApps

Estas L1 ofrecen tiempos de confirmación de sub-segundo y una alta capacidad de TPS, lo que las hace ideales para una amplia gama de dApps que pueden implementarse de forma transparente.

Hyperliquid ofrece transacciones DEX rápidas y seguras con un libro de órdenes en cadena, lo que iguala la precisión del intercambio centralizado con una alta escalabilidad.

Sonic añade una finalidad rápida para aplicaciones DeFi eficientes, asegurando transacciones en menos de un segundo.

Monad mejora esto con 10,000 TYPS, tiempos de bloque de 1 segundo y finalidad de un solo slot.

Más allá de Web3: Potencial empresarial

La velocidad y la escalabilidad de estas redes las posicionan para su uso empresarial en finanzas, cadenas de suministro y pagos. Los minoristas pueden manejar pagos de alto volumen a costos reducidos, mientras que los proveedores de atención médica aseguran datos de pacientes en tiempo real con compatibilidad con sistemas existentes.

7. L2 como respuesta de Ethereum al problema de escalabilidad

¿Qué pasa con los L2s?

¿Por qué necesitamos nuevos blockchains L1 con mecanismos de consenso sofisticados en primer lugar?

Soluciones L2 como Arbitrum, Optimism y Base impulsaron la escalabilidad de L1 al procesar transacciones fuera de la cadena. Arbitrum alcanza hasta 4,000 TPS, mientras que Base apunta a miles con Flashblocks de 0.2 segundos para mediados de 2025.

Sin embargo, los L2 dependen de la seguridad y la finalidad de Ethereum, heredando sus características y limitaciones. Por ejemplo, la necesidad de pruebas de fraude en sistemas como rollups optimistas puede provocar retrasos, ya que las transacciones en las cadenas de OP Stack de Optimism se finalizan cuando sus datos se incluyen en un bloque de Ethereum finalizado. Esto puede afectar la experiencia del usuario, especialmente para aplicaciones que requieren una finalidad de transacción rápida.

Nuevas cadenas de bloques L1 como Hyperliquid, Monad y Sonic abordan estas limitaciones con mecanismos de consenso avanzados. A diferencia de las L2, estos L1 son altamente eficientes sin depender de la infraestructura de Ethereum, evitando complejidades como pruebas de fraude o cuellos de botella de tiempo de bloqueo de L1.

Sin embargo, la construcción de nuevos L1 introduce riesgos, desafiando potencialmente la descentralización o aumentando los costos. Si bien las blockchains L1 proporcionan una capa base de seguridad y descentralización, a menudo enfrentan desafíos de escalabilidad debido a los mecanismos de consenso y limitaciones de tamaño de bloque. Además, no tienen el rendimiento histórico y la confianza de Ethereum.

La necesidad de desarrollar nuevas blockchains L1 en presencia de soluciones L2 existentes es un tema de discusión en curso en Twitter:

Las capas 2 alivian la congestión de la capa 1 pero vinculan su escalabilidad a las restricciones de Ethereum. Son tan rápidas como Ethereum, pero esto no tiene en cuenta que la finalidad de todas las transacciones de la capa 2 depende de los tiempos de confirmación de bloques de la capa 1.

Al mismo tiempo, los nuevos L1 prometen independencia y velocidad, pero deben demostrar que pueden escalar de forma segura para miles de millones de usuarios.

La interacción entre las soluciones L1 y L2 plantea preguntas críticas sobre la arquitectura futura de las redes blockchain.

¿Se pueden abordar de manera efectiva los desafíos de escalabilidad de las cadenas de bloques L1 a través del desarrollo de nuevos mecanismos de consenso, o es esencial la integración de soluciones L2 a pesar de sus compromisos inherentes?

Estas consideraciones subrayan la necesidad de una investigación continua y un diálogo dentro de la comunidad blockchain para navegar por las complejidades de la escalabilidad, la seguridad y la descentralización.

Conclusión y Alimento para el Pensamiento

Una de las principales barreras en el mercado actual es la liquidez escasa y rotativa, que afecta tanto a los usuarios nuevos como a los existentes. La atención es baja y de corta duración, lo que hace que sea aún más desafiante asegurar una cuota de mercado en crecimiento en este sector abarrotado.

Por lo tanto, para impulsar la adopción, es esencial priorizar las necesidades tanto de los desarrolladores como de los usuarios.

Pero seamos honestos: la mayoría de los usuarios se preocupan más por la funcionalidad práctica que por la tecnología subyacente. Quieren una experiencia sin problemas, con transacciones rápidas y tarifas bajas que hagan que la red sea accesible, especialmente para microtransacciones.

La seguridad también es innegociable: los usuarios esperan salvaguardas sólidas para proteger sus activos y datos, fomentando la confianza en el sistema. Y, por supuesto, debe haber actividades en la cadena, que satisfagan diferentes tipos de necesidades de los usuarios.

Tanto los L1 como los L2 necesitan luchar por estos intereses para mantenerse relevantes. En lugar de centrarse únicamente en la 'mejor tecnología' e intentar 'sobremejorar' los mecanismos de consenso de su cadena, también deberían ser pragmáticos y centrarse en ofrecer a los usuarios y desarrolladores la mejor red para construir y utilizar sus aplicaciones.

Para concluir, nuevos L1s, como Hyperliquid, Monad y Sonic, abordan las dependencias L2 pero enfrentan desafíos, como se ve en el pequeño grupo de validadores de Hyperliquid, donde solo cuatro nodos aumentaron los riesgos de colusión, exponiendo vulnerabilidades. Expandir validadores, asegurar puentes e implementar umbrales de aprobación más altos, monitoreo en tiempo real y detección de anomalías puede fortalecer la resiliencia. Equilibrar la seguridad, la escalabilidad y la descentralización a través de la gestión proactiva de riesgos es clave para fomentar la confianza y sostener el crecimiento de DeFi, instando a los usuarios a escrutar las salvaguardias de la plataforma y a los desarrolladores a priorizar defensas sólidas.

Deja que los “devs hagan algo”: deja que ellos hagan el peso técnico pesado y definan el trade-off de los mecanismos de consenso, alimentando la búsqueda de equilibrio.

Además, no olvidemos a los usuarios: aquellos que simplemente disfrutan de aplicaciones receptivas, eficientes, descentralizadas y seguras.

Estos nuevos diseños están empujando los límites de lo que los modelos de consenso pueden lograr en cuanto a ritmo, seguridad e interoperabilidad.

Será interesante ver cómo evolucionan y cómo se entrelazan una vez que Monad (y otros competidores) estén en funcionamiento.

Descargo de responsabilidad:

1. Este artículo es reimpreso de [Laboratorios Castle]. Todos los derechos de autor pertenecen al autor original [@cryptorinweb3]. Si hay objeciones a esta reimpresión, por favor contacte al Gate Learnequipo, y lo resolverán rápidamente.
2. Descargo de responsabilidad: Las opiniones expresadas en este artículo son únicamente las del autor y no constituyen asesoramiento de inversión.
3. El equipo de Gate Learn realiza traducciones del artículo a otros idiomas. Queda prohibido copiar, distribuir o plagiar los artículos traducidos a menos que se mencione.