MagicBlock publicó Validator v1.0 el 6 de octubre de 2026, marcando la primera versión principal del entorno de ejecución especializado de la Máquina Virtual Solana que impulsa sus Ephemeral Rollups. Después de más de un año y medio de desarrollo, pruebas y refinamiento, esta versión consolidará funciones ya utilizadas en producción, al tiempo que mejora el rendimiento bajo carga, la recuperación ante fallos y las herramientas para operadores. Los desarrolladores ahora pueden delegar cuentas seleccionadas a un entorno de ejecución rápido y co-localizado que procesa trabajos con tiempos de bloque de aproximadamente 10 milisegundos, y luego confirma los resultados de vuelta al mainnet de Solana. 

Cuatro validadores operan actualmente en el mainnet en Asia, Europa, Estados Unidos y una instancia de entorno de ejecución confiable. La actualización llega mientras las aplicaciones en juegos, comercio y pagos buscan latencia y privacidad que la capa base por sí sola no puede ofrecer, manteniendo al mismo tiempo acceso completo a los programas y liquidez de Solana. El validador v1.0 convierte los Ephemeral Rollups en un motor en tiempo real listo para producción, brindando a los desarrolladores manejo de intenciones en múltiples pasos, almacenamiento temporal más económico, acciones de liquidación atómica y economías más claras, todo ello manteniéndose completamente anclado a Solana.

Los paquetes de intención permiten que una aplicación solicite una secuencia de pasos desde una sola transacción de rollup en lugar de ensamblar esos pasos por sí misma. El validador gestiona el orden de ejecución, reduciendo el código de coordinación que los desarrolladores anteriormente tenían que mantener. En la práctica, esto significa que un juego puede actualizar el estado del jugador, activar un pago y programar una acción posterior sin llamadas independientes en la cadena para cada elemento. El diseño mantiene el programa Solana como el orquestador principal, mientras que el rollup maneja el trabajo de alta frecuencia. Según las notas oficiales de lanzamiento en GitHub, estos paquetes forman parte de un conjunto más amplio de flujos de aplicación que también incluyen acciones posteriores a la delegación y devoluciones de llamada. Debido a que las cuentas permanecen bloqueadas contra escrituras conflictivas en la cadena base durante la sesión, la secuencia se mantiene consistente incluso si las condiciones de red varían. Este enfoque reduce el riesgo de ejecución parcial y hace que los flujos en tiempo real complejos sean más confiables para los desarrolladores que necesitan resultados deterministas.

El impacto práctico se ve más claramente en los flujos de pago y juegos. Un usuario puede autorizar una sola transacción firmada en el mainnet de Solana; el validador luego ejecuta la parte privada o de alta velocidad dentro del rollup y establece el estado final nuevamente. La publicación del blog de MagicBlock explica que la combinación de intenciones y funciones relacionadas elimina la necesidad de que los desarrolladores gestionen manualmente los pasos intermedios. Aplicaciones tempranas en producción ya han demostrado sesiones multijugador y bucles de intercambio que parecen continuos, en lugar de interrumpidos por los tiempos de bloque. Al transferir la responsabilidad de secuenciación al validador, la versión reduce la superficie de posibles errores y libera tiempo de ingeniería para la lógica de la aplicación. El cambio también se alinea con el objetivo declarado del proyecto de permitir que las aplicaciones escalen el cómputo según sea necesario, manteniéndose completamente compuestas con programas y pools de liquidez existentes de Solana.

Las Magic Actions permiten que los programas de Solana utilicen el estado actualizado del rollup durante la propia transacción de liquidación. Cuando una acción se incluye en la misma transacción de Solana que un commit, se ejecuta de forma atómica: el éxito avanza tanto el commit como la acción; el fallo revierte toda la transacción. Esta garantía elimina una clase común de problemas de estado parcial que anteriormente requerían lógica de recuperación personalizada. Los callbacks devuelven el resultado al rollup para que la aplicación pueda reaccionar inmediatamente. La desasignación automatizada simplifica aún más la devolución de las cuentas a la capa base. Las notas de lanzamiento de GitHub listan estas capacidades bajo flujos de liquidación y señalan una mejora en el manejo del orden de los commits y la consistencia de los blockhash. Juntas, crean un bucle más cerrado entre el entorno de alta velocidad y la seguridad del mainnet de Solana.

Para desarrolladores, la propiedad atómica es más importante cuando se mueve el valor. Una aplicación de trading puede confirmar una actualización de precio y ejecutar simultáneamente una transferencia relacionada sin el riesgo de que una tenga éxito mientras la otra falla. El mismo patrón admite la distribución de recompensas en juegos o la finalización de pagos privados. Debido a que la acción se ejecuta dentro de la transacción de liquidación, el sistema en su conjunto hereda las garantías de consenso de Solana en lugar de inventar un mecanismo de finalidad separado. Las mejoras en las herramientas del operador, incluyendo rastreo estructurado y métricas de latencia ampliadas, ayudan a los equipos a observar estos pasos atómicos en producción. El resultado neto es menos fallos en casos límite y un modelo mental más claro: el rollup acelera el trabajo, la capa base registra el resultado definitivo, y las Magic Actions mantienen ambos sincronizados sin código de coordinación adicional.

Las acciones posteriores a la delegación permiten que una aplicación organice tareas que comienzan en el momento en que una cuenta llega al rollup. Estas acciones pueden incluir instrucciones cifradas, habilitando flujos de trabajo privados sin exponer estados intermedios. Combinadas con paquetes de intención, la función admite una ruta de pago privada completa: un usuario firma una vez en el mainnet, el rollup ejecuta la parte confidencial dentro de un entorno de ejecución confiable, y el resultado final se liquida nuevamente en Solana. La documentación de MagicBlock describe el modelo de privacidad como dependiente del hardware Intel TDX, donde el área del procesador sellada protege el estado de la máquina anfitriona. La compensación es la confianza en el proveedor de hardware, lo cual el proyecto declara abiertamente. Las transferencias de tokens continúan utilizando interfaces y SDK estándar de Solana, por lo que los monederos y programas existentes siguen siendo compatibles.

Este diseño reduce la cantidad de pasos que el usuario debe comprender. Anteriormente, los flujos privados a menudo requerían múltiples firmas o cuentas intermedias. Con las acciones posteriores a la delegación, la complejidad se traslada detrás de una sola autorización. Los ejemplos en producción ya incluyen estrategias de comercio confidenciales y estado multijugador privado. Las notas de lanzamiento confirman que las instrucciones cifradas forman parte de las adiciones al flujo de trabajo de la aplicación en la v1.0. Al mantener la privacidad opcional y limitada a las cuentas delegadas, el sistema evita obligar a cada aplicación a un modo confidencial, mientras sigue ofreciéndola donde sea necesario. El enfoque también preserva la composibilidad: una vez que se resuelve la parte privada, las cuentas resultantes pueden interactuar con cualquier otro programa de Solana como de costumbre.

Los Magic ATAs permiten a un usuario enviar tokens a un destinatario en el rollup sin necesidad de crear primero la cuenta de tokens asociada del destinatario en Solana ni pagar su depósito exento de renta. La cuenta de tokens asociada es la estructura estándar de Solana que almacena un token específico para un monedero dado; crearla cuesta SOL, lo que muchos usuarios prefieren no gastar por adelantado. Los Magic ATAs aplazan o eliminan ese costo para actividades en el rollup, reduciendo la fricción en transferencias de alta frecuencia o temporales. La función funciona con las mismas interfaces Token-2022 y estándar de tokens ya admitidas por el validador. Dado que las cuentas permanecen temporales mientras están en el rollup, el costo económico se mantiene proporcional al uso real en lugar de al almacenamiento permanente.

En contextos de juegos y micropagos, la diferencia es significativa. Los jugadores pueden recibir recompensas o realizar transferencias dentro de la sesión sin necesidad de pausar para financiar cuentas de tokens. Las aplicaciones de trading pueden dirigir saldos temporales con mayor fluidez. La publicación oficial en el blog destaca esto como parte del esfuerzo más amplio para reducir los pasos entre un usuario y un pago. Combinado con la ejecución sin gas dentro del rollup, los Magic ATAs ayudan a que la experiencia general se acerque a la respuesta de las aplicaciones web tradicionales, mientras aún asienta resultados verificables en Solana. El cambio también se alinea con el énfasis del proyecto en mantener los datos temporales económicos, un tema que continúa con la introducción de cuentas efímeras.

Las cuentas efímeras brindan un hogar para datos temporales en el rollup a una fracción del costo de financiamiento de cuentas de capa base equivalentes. Los desarrolladores pueden crear, redimensionar y cerrar libremente estas cuentas; cuando se libera espacio, el depósito de almacenamiento correspondiente se devuelve. Una sesión de juego, un hilo de chat o un cálculo intermedio pueden generar grandes cantidades de estado sin consumir permanentemente el alquiler de Solana. Una vez que los datos ya no son necesarios, la cuenta se cierra simplemente y se recupera el depósito. Este modelo se ajusta mucho mejor al ciclo de vida de muchas aplicaciones en tiempo real que el almacenamiento permanente en cadena.

La ventaja económica se multiplica para las aplicaciones que abren y cierran muchas sesiones de corta duración. En lugar de pagar saldos completos exentos de alquiler para cada estructura temporal, los equipos pagan solo mientras los datos sean útiles. Las notas de lanzamiento de GitHub incluyen cuentas efímeras entre las adiciones clave del flujo de trabajo de la aplicación. Debido a que las cuentas se encuentran dentro del entorno delegado, heredan la misma protección de bloqueo contra escrituras conflictivas en la capa base. Cuando ocurre el asentamiento, solo es necesario escribir de vuelta a Solana el estado final relevante. Por lo tanto, el diseño reduce tanto el costo como la inflación del estado, manteniendo al mismo tiempo el modelo de seguridad de la cadena subyacente. Los desarrolladores que anteriormente evitaban estados temporales ricos por razones de costo ahora tienen una opción práctica.

Validator v1.0 mejora la sincronización de cuentas desde la capa base. La sincronización ahora es más paralela y basada en demanda, con rutas sin bloqueo, suscripciones y recuperaciones de cuentas por lotes, además de cobertura escalonada en gRPC y WebSocket. El agrupamiento de conexiones, la memoria caché de cuentas vacías y la reducción de la sobrecarga de instrumentación disminuyen aún más el uso de recursos. Estos cambios reducen la carga que los validadores de rollup imponen sobre los puntos finales de Solana RPC y mejoran la resistencia cuando las actualizaciones llegan tarde o las conexiones se interrumpen. El trabajo pendiente de liquidación puede recuperarse tras un reinicio, abordando una brecha de recuperación anterior.

El efecto práctico es una mayor confiabilidad bajo tráfico de producción. Las aplicaciones que abren muchas sesiones simultáneas ya no corren fácilmente el riesgo de transmisiones bloqueadas o reconexiones fallidas en silencio. Las herramientas del operador incorporan una interfaz de línea de comandos, diagnósticos de recuperación de cuentas e integración con Geyser, lo que facilita monitorear e investigar problemas. Las notas de la versión también documentan el manejo reforzado de actualizaciones de cuentas obsoletas o fuera de orden y condiciones de carrera durante la clonación. En conjunto, estas mejoras mueven el entorno de ejecución de una herramienta experimental hacia una infraestructura en la que los equipos pueden confiar para servicios continuos en tiempo real. El enfoque en la eficiencia bajo carga refleja la observación del proyecto de que muchas funciones ya estaban activas; la v1.0 simplemente las coloca sobre una base más sólida.

La recuperación de liquidación permite reintentar intenciones de liquidación pendientes tras reinicios de validadores. Los flujos de commit-finalización y la desasignación automatizada ofrecen un control más claro sobre cuándo el estado vuelve a Solana. Las notas de lanzamiento muestran una reproducción del libro mayor mejorada, comportamiento de caché, límites de compactación y vaciado al apagado. Estos cambios abordan carreras, flujos estancados y problemas de ordenación que anteriormente podían dejar las aplicaciones en estados inconsistentes. Las mejoras en la eficiencia de recursos, incluyendo la compactación y programación de replicación ajustadas, reducen la competencia entre la ejecución de transacciones y el mantenimiento en segundo plano.

Para operadores, las ganancias se manifiestan en menos intervenciones manuales tras reinicios inesperados. Para desarrolladores, las ganancias se manifiestan en una finalidad más predecible. Una aplicación puede confiar en el validador para completar o recuperar limpiamente una secuencia de liquidación en lugar de implementar su propia lógica de reintento. La combinación de soporte de recuperación y Acciones Mágicas atómicas reduce aún más la posibilidad de resultados parciales. Las mejoras en observabilidad, rastreo estructurado y métricas ampliadas de ciclo de vida y latencia brindan a los equipos los datos necesarios para diagnosticar los casos límite restantes. La dirección general es hacia un entorno de ejecución que falle de forma segura y se recupere automáticamente, lo cual es esencial una vez que las aplicaciones en tiempo real trasciendan la fase de prueba de concepto y pasen a operación continua.

Un nuevo servicio de replicación introduce coordinación primario/réplica, instantáneas de AccountsDb para réplicas y verificaciones determinísticas de blockhash. Los nodos réplica pueden seguir a un primario, mejorando la capacidad de recuperación ante fallos de nodo único. Las notas de lanzamiento marcan explícitamente el modo réplica y el protocolo de desafío como experimentales en la versión 1.0.0. Las instantáneas y el soporte de recuperación, por lo tanto, constituyen una base preliminar en lugar de una red descentralizada terminada. El proyecto afirma que la descentralización y una red sin permisos siguen siendo prioridades importantes más allá de este lanzamiento.

Incluso en su forma experimental, el servicio fortalece el camino hacia una mayor disponibilidad. Las aplicaciones que requieren tiempo de actividad continuo se benefician de la capacidad de conmutar por error o verificar el estado desde una réplica. Las comprobaciones deterministas de blockhash ayudan a mantener la coherencia entre nodos. Las ampliaciones de las herramientas del operador facilitan la gestión de la relación principal/réplica. Aunque la participación completamente sin permisos y los mecanismos a prueba de fraude aún están por venir, la inclusión del servicio de replicación señala que la ingeniería de confiabilidad ahora se encuentra junto al desarrollo de funciones. Los equipos que evalúan la plataforma para producción pueden tratar por lo tanto la replicación como una capacidad emergente en lugar de ausente.

El soporte de tiempo de ejecución se amplía a sBPF v3, compatibilidad con Token-2022, precompilados criptográficos y syscalls adicionales. Los parámetros de alquiler se alinean con la cadena base, y la simulación de transacciones se mejora. Estas actualizaciones mantienen al validador efímero al día con la evolución de Solana, reduciendo el riesgo de que los programas escritos para mainnet fallen dentro de un rollup. Las notas de lanzamiento también registran actualizaciones a las dependencias de tiempo de ejecución dirigidas a Solana 4.x. Las mejoras de compatibilidad reducen la barrera para que los programas existentes de Solana utilicen el entorno de alta velocidad sin modificaciones.

Los desarrolladores que ya utilizan extensiones de Token-2022 o primitivas criptográficas más recientes pueden ahora integrar estas funciones en sesiones en tiempo real. La simulación mejorada ayuda a detectar problemas antes de que lleguen a producción. La alineación de los parámetros de alquiler evita desajustes económicos sutiles entre el rollup y la capa base. En conjunto, los cambios refuerzan el principio de diseño según el cual los Ephemeral Rollups extienden Solana en lugar de reemplazarla. Las aplicaciones continúan componiéndose con el conjunto completo de programas y liquidez del mainnet, acelerando únicamente las partes que requieren menor latencia o privacidad opcional.

Junto con el lanzamiento del software, la tarifa de la sesión de delegación aumenta a 0.003 SOL y la tarifa de commit a 0.001 SOL. Las transacciones ordinarias dentro del rollup siguen siendo gratuitas. Aproximadamente el 90 por ciento de las tarifas recolectadas van al operador del validador y el 10 por ciento al protocolo, según la documentación de tarifas del proyecto. Las sesiones y los commits son los puntos en los que el rollup interactúa con Solana, por lo que las tarifas solo se aplican a esas interacciones de la capa base. Solana Compass analytics registró entre 770 y 950 transacciones diarias que involucraban el Programa de Delegación durante la semana que terminó el 5 de octubre de 2026, proporcionando una línea base para el volumen que ahora estará sujeto a las nuevas tarifas.

El cambio en las tarifas vincula los ingresos del protocolo más directamente con el trabajo de abrir sesiones y escribir los resultados de nuevo. También financia el camino hacia los incentivos para operadores y verificadores necesarios para una mayor descentralización. El proyecto ha introducido reembolsos en SOL para direcciones que aportan una parte significativa de la actividad y ya ha seleccionado un grupo inicial de delegadores activos. Los reembolsos sirven como una prueba temprana de recompensas basadas en el uso antes del lanzamiento de cualquier token de red. Los desarrolladores cuyas aplicaciones generan un volumen elevado pueden esperar, por lo tanto, un descuento parcial a las nuevas tarifas, mientras que el modelo general sigue basándose en el uso medible de la red en lugar de emisiones especulativas.

Las recompensas de SOL se dirigen a direcciones que generan una parte significativa de la actividad del protocolo. MagicBlock afirma que ya se ha seleccionado un grupo inicial de delegadores activos e invita a otros constructores de aplicaciones a postularse. El programa se presenta como un primer paso hacia los incentivos programables descritos en los materiales de tokenonomía del proyecto. Comenzar con SOL en lugar de un nuevo token permite al equipo afinar los parámetros de recompensa con datos de uso real. Las recompensas sostenibles para operadores y verificadores se presentan como esenciales para el objetivo a largo plazo de una red más descentralizada.

El mecanismo de reembolso crea un bucle de retroalimentación en el que un mayor uso de la aplicación permite pagar las tarifas y devolver una parte de esas tarifas a los participantes más activos. Este enfoque difiere de las emisiones puramente inflacionarias al vincular las recompensas a un trabajo medible. Dado que los criterios de selección y las tasas exactas aún no son públicos, los equipos que evalúan la economía deberán ponerse en contacto directamente con el proyecto. Sin embargo, la existencia del programa indica que el diseño económico avanza en paralelo con la madurez del software del Validator v1.0. Para los desarrolladores cuyas aplicaciones ya generan un volumen significativo de sesiones, los reembolsos ofrecen un beneficio concreto a corto plazo mientras se sigue desarrollando la estructura general de incentivos.

Los operadores reciben una interfaz de usuario terminal, diagnósticos de recuperación de cuentas e integración y salida de Geyser. El rastreo estructurado y las métricas ampliadas de ciclo de vida y latencia mejoran la observabilidad. Estas herramientas facilitan el monitoreo de la salud del validador, la investigación de problemas y la comprensión del rendimiento bajo carga. Las notas de lanzamiento también enumeran funciones de mantenimiento de AccountsDb, como la desfragmentación y el soporte para reducción, que ayudan a mantener el almacenamiento eficiente durante sesiones de larga duración.

Herramientas mejoradas reducen la carga operativa de ejecutar rollups en producción. Los equipos pueden diagnosticar problemas de sincronización, medir la latencia y recuperarse de fallos con datos más claros. La combinación de lógica de recuperación mejorada y métricas más ricas acorta el tiempo entre un incidente y su resolución. A medida que más operadores de terceros se unen a la red, las herramientas estandarizadas se convierten en un requisito previo para garantizar una calidad de servicio consistente. Por lo tanto, Validator v1.0 avanza tanto las funciones orientadas a la aplicación como la base operativa necesaria para respaldarlas a escala.

La documentación enumera cuatro validadores de rollup activos en el mainnet de Solana: uno cada uno en Asia, Europa y Estados Unidos, además de uno que se ejecuta dentro de un entorno de ejecución confiable. La distribución geográfica respalda la afirmación del proyecto sobre la co-localización para reducir la latencia de extremo a extremo. Las aplicaciones pueden redirigir sesiones hacia el validador más cercano o más adecuado, reduciendo el retraso de red para los usuarios en esas regiones. La instancia TEE proporciona la raíz de confianza del hardware para flujos de trabajo privados. El historial de versiones muestra que la 0.16.1 se lanzó un día antes de la etiqueta 1.0.0, lo que indica una iteración continua hasta el lanzamiento del hito.

La presencia de múltiples validadores en funcionamiento demuestra que la tecnología ya está en producción y no es meramente experimental. Aplicaciones en tiempo real en gaming y trading han utilizado versiones anteriores para lograr latencias de extremo a extremo reportadas por debajo de 50 milisegundos. Con las mejoras en confiabilidad y flujo de trabajo en la v1.0, esas mismas aplicaciones obtienen un manejo y recuperación multi-paso más robustos. La distribución geográfica también prepara la red para una mayor descentralización: operadores adicionales podrán unirse una vez que los componentes de réplica y desafío experimentales maduren. Para los desarrolladores, el valor inmediato es la capacidad de elegir un punto final de baja latencia mientras aún se asienta cada resultado en el mainnet de Solana.

1. ¿Qué cambia exactamente Validator v1.0 para los usuarios existentes de Ephemeral Rollup? 

Las aplicaciones existentes continúan funcionando porque muchas de las funciones ya estaban activas; la versión 1.0 principalmente fortalece el rendimiento, la recuperación y los flujos de trabajo de múltiples pasos, haciendo que las mismas aplicaciones sean más confiables y requieran menos código de coordinación personalizado. Los desarrolladores obtienen paquetes de intención, acciones mágicas atómicas y desasignación automatizada sin reescribir la lógica central, mientras que los operadores reciben herramientas de monitoreo mejoradas y un comportamiento de reinicio optimizado.

2. ¿Cómo afectan las nuevas tarifas de sesión y compromiso a los costos de la aplicación? 

Cada sesión de delegación ahora cuesta 0.003 SOL, y cada commit después del primero cuesta 0.001 SOL, mientras que las transacciones ordinarias de rollup siguen siendo gratuitas. Las aplicaciones de alto volumen pueden solicitar reembolsos de SOL que compensen una parte de estas tarifas. El costo neto depende por lo tanto de la frecuencia de las sesiones y la elegibilidad para reembolsos, y no del número de transacciones internas.

3. ¿El modelo de privacidad se basa en pruebas de conocimiento cero o en hardware? 

La privacidad actualmente depende de entornos de ejecución confiables Intel TDX que protegen el estado del rollup del equipo anfitrión. El proyecto documenta explícitamente la suposición de confianza en el proveedor de hardware. Las instrucciones cifradas y las acciones posteriores a la delegación permiten flujos de trabajo privados mientras aún se resuelven resultados verificables de nuevo en el mainnet de Solana.

4. ¿Pueden los programas ordinarios de Solana ejecutarse dentro de un Ephemeral Rollup sin modificaciones? 

La compatibilidad se ha ampliado para incluir Token-2022, sBPF v3, precompilados criptográficos y simulación mejorada de transacciones. Por lo tanto, la mayoría de los programas escritos para el mainnet actual de Solana pueden ejecutarse dentro del rollup, aunque los desarrolladores deben seguir probando los resultados de la simulación y la alineación de los parámetros de alquiler.

5. ¿Qué sigue siendo experimental en la versión 1.0.0? 

El modo réplica y el protocolo de desafío están explícitamente marcados como experimentales. El nuevo servicio de replicación proporciona coordinación primaria/réplica y instantáneas, pero la verificación completamente sin permisos y los mecanismos de prueba de fraude aún están en desarrollo.

6. ¿Cómo funciona la recuperación de liquidación tras un reinicio del validador? 

Las intenciones de liquidación pendientes se recuperan y reintentan tras reinicios. La reproducción mejorada del libro mayor, el comportamiento de la memoria caché y el orden de compromiso reducen la probabilidad de que un reinicio deje las aplicaciones en un estado inconsistente. La desasignación automatizada simplifica aún más el retorno de las cuentas a la capa base.

7. ¿Dónde pueden los desarrolladores encontrar la documentación de integración y el código fuente? 

La documentación oficial se encuentra en docs.magicblock.gg y el código del validador, incluyendo las notas completas de la versión v1.0.0, está disponible en el repositorio magicblock-labs/magicblock-validator en GitHub. Ambos recursos se actualizaron simultáneamente con el anuncio del 6 de octubre de 2026.

8. ¿Cuál es la trayectoria a más largo plazo hacia una red más descentralizada? 

El proyecto enumera la descentralización y una red sin permisos como prioridades más allá de la versión 1.0. La replicación, los protocolos de desafío, los incentivos para los operadores y el token de red eventual se describen como componentes necesarios. El programa actual de reembolso de SOL sirve como una prueba inicial de recompensas basadas en el uso que más adelante se pueden ampliar.

Este contenido es únicamente con fines informativos y no constituye asesoramiento de inversión. Las inversiones en criptomonedas conllevan riesgos. Por favor, realiza tu propia investigación (DYOR).

Aviso: Esta página fue traducida utilizando tecnología de IA para tu conveniencia. Para obtener la información más precisa, consulta la versión original en inglés.