Desarrollado conjuntamente por Virtuals Protocol y el equipo dAI de la Ethereum Foundation
Especificación: https://eips.ethereum.org/EIPS/eip-8183
Discusión: ethereum-magicians.org/t/erc-8183-agentic-commerce/27902
Únete a la comunidad de desarrolladores: https://t.me/erc8183
Comercio: requisito previo para la IA descentralizada
Para que los agentes de IA sean accesibles, descentralizados, no controlados por una sola plataforma, no dependientes de un único proveedor y no sujetos a un único punto de fallo, el comercio resulta esencial. No puede ser una idea secundaria, sino la infraestructura fundamental. Y ese comercio debe estar siempre abierto y sin permisos. Este es el "espacio digital compartido sin propietario" que @ethereum fue creado para generar.
¿Por qué? Porque la descentralización en la capa de IA y agentes requiere una multitud de agentes y servicios independientes. Por ejemplo, si solo un agente puede generar imágenes y deja de prestar servicio, la generación de imágenes se centraliza, independientemente del protocolo. Si solo un proveedor controla la ejecución de operaciones, la gestión de fondos depende de una sola parte. Y si solo una plataforma controla la infraestructura de liquidación, cada proveedor y cliente queda sujeto a sus reglas, aunque haya mil agentes en ella.
Esto requiere comercio abierto: cualquier agente debe poder comprar un servicio y ofrecerlo. Sin filtros, sin jardines cerrados. Sin intermediario obligatorio.
Por qué blockchain
Sin embargo, el comercio solo funciona cuando todas las partes pueden confiar en que el acuerdo será cumplido. Si un cliente paga por adelantado, ¿cómo sabe que el proveedor entregará? Si un proveedor entrega primero, ¿cómo sabe que el cliente pagará? Alguien debe custodiar los fondos, verificar si el trabajo se realizó y hacer cumplir el resultado: liberar el pago al completar, reembolsar en caso de fallo. Es la confianza (o su ausencia) lo que da lugar a entidades centralizadas o filtros.
En la arquitectura tradicional, ese alguien es una plataforma. Una empresa que mantiene el depósito en garantía, controla la máquina de estados y decide quién cobra y cuándo. Eso funciona hasta que deja de funcionar. La plataforma puede cambiar las reglas, congelar fondos, eliminar proveedores o cerrar. Cada participante depende del buen comportamiento continuo de la plataforma. Esto es centralización, no a nivel de protocolo, sino a nivel de ejecución. No es incorrecto, pero es necesario en un sistema que carece de confianza. El objetivo es la des-totalización: impedir que cualquier entidad tenga control total sobre cómo transaccionan los agentes. Lo hemos comprobado: los desarrolladores buscan infraestructura confiable sin depender del buen comportamiento de una sola plataforma.
Un contrato inteligente en una cadena descentralizada es una solución. El depósito en garantía, la máquina de estados y la certificación del evaluador residen en código público, inmutable y sin propietario. El contrato actúa como ejecutor neutral, lo que genera señales significativas para la reputación de las partes involucradas.
La liquidación en cadena también produce algo que una plataforma centralizada no puede: registros portables, verificables e inmutables. Cada trabajo completado, cada certificación de evaluador, cada hash de entregable queda registrado en cadena, visible para cualquier agente, en cualquier plataforma, a través de cualquier interfaz. Estos registros alimentan los sistemas de reputación y la identidad de los agentes. Sin liquidación en cadena, no hay historial verificable. Sin historial verificable, no hay reputación portable. Sin reputación portable, cada interacción de agente comienza desde cero en confianza.
Por eso se necesita un estándar onchain. El depósito en garantía, las transiciones de estado, la certificación. Estas son las partes que deben ser neutrales, seguras y ejecutables.
La búsqueda, negociación y comunicación pueden ocurrir dentro o fuera de la cadena, a través de la interfaz más natural. Un agente puede interactuar mediante HTTP usando el protocolo x402, donde la experiencia se asemeja a APIs estándar o solicitudes HTTPS. El agente no tiene por qué interactuar directamente con la cadena. Firma un solo mensaje y un facilitador gestiona la liquidación en cadena y los estándares. O los agentes pueden interactuar directamente mediante MCP o A2A. La interfaz es flexible, pero la liquidación principal debe ser sin confianza, programática y en cadena. Infraestructura que los sistemas centralizados no proporcionarán, porque socava su control.
La economía de agentes
Los modelos IA y agentes mejoran y se vuelven más capaces cada mes. Tareas que requerían experiencia humana hace un año, como escribir código en producción, generar medios profesionales, analizar datos financieros o coordinar flujos de trabajo multi-etapa, ahora las realizan agentes con calidad comparable o superior. Y la capacidad sigue acelerando. La trayectoria de la IA hace inevitable la nueva economía.
A medida que los agentes adquieren más capacidad, asumen trabajos de mayor valor. Un agente que puede generar imágenes indistinguibles de la fotografía profesional es un servicio por el que merece la pena pagar. Un agente que puede analizar una cartera y ejecutar operaciones optimizadas gestiona dinero real. Un agente que puede revisar documentos legales y señalar riesgos realiza una labor que cuesta cientos de dólares por hora cuando lo hace un humano.
Esta es la transición clave: la IA y los agentes se convierten en participantes económicos generadores de valor y servicios.
Y a medida que la IA se vuelve universalmente accesible, cualquier individuo, organización o dispositivo podría operar mediante agentes. Entonces la economía cambia. Los agentes no solo interactúan y sirven a humanos; interactúan y sirven entre ellos. Por ejemplo, un agente que coordina una campaña contrata agentes de contenido, distribución y análisis. La economía se convierte en una red de agentes transaccionando con agentes, a velocidad de máquina, a escala global.
Cuando los agentes pueden realizar trabajos valiosos y todos tienen acceso a agentes, el resultado es una economía donde la mayoría de la actividad comercial fluye a través de sistemas autónomos. Para esto estamos construyendo.
El problema: comercio sin confianza entre agentes
Una economía de agentes requiere comercio entre agentes. Y el comercio entre agentes que nunca han interactuado, que abarcan distintas organizaciones y cadenas, debe ser sin confianza.
Cuando los humanos transaccionan, se contratan o incluso contratan un servicio, la confianza está en el centro. En estos casos, la confianza se media por plataformas, opiniones, sistemas legales y normas sociales. Cuando un agente contrata a otro agente, ninguno de esos mecanismos aplica. No hay reputación social que consultar. No hay recurso legal o reputacional que opere a la velocidad de las transacciones de máquina. No hay plataforma ni regulador que establezca la ejecución.
Así que la pregunta es: ¿cómo hacer comercio entre agentes sin confianza?
No se puede simplemente enviar dinero y esperar lo mejor. Una transferencia de tokens no es comercio. Es un pago sin garantías. No hay registro de lo acordado. No hay mecanismo para retener fondos hasta que el trabajo sea satisfactorio. No hay evaluación que produzca señales para que otros agentes consulten. No hay recurso si el proveedor nunca entrega.
Se necesita un compromiso estructurado: fondos retenidos en depósitos en garantía descentralizados y programables, trabajo presentado como artefactos verificables, un evaluador que certifique si el entregable cumple los términos y resultados deterministas. Mecanismos que aseguren que los fondos se liberan al completar, se reembolsan al rechazar y se reclaman si expiran. Todo lo cual contribuye a la identidad y reputación de todas las partes involucradas.
ERC-8183: el trabajo como elemento primitivo
En estrecha colaboración con el equipo dAI de @ethereumfndn, formalizamos esto como estándar. ERC-8183: Agentic Commerce, es un estándar abierto y sin permisos para aplicaciones de comercio entre agentes, con depósito en garantía y certificación del evaluador programados como contratos inteligentes onchain.
ERC-8183 define un solo núcleo: el Trabajo (Job). Cada Trabajo consta de tres partes: Cliente, Proveedor y Evaluador. Cada parte se define solo por su dirección de billetera, permitiendo una amplia aplicación y uso del elemento primitivo.
Los componentes y principios clave detrás del elemento Trabajo son: (i) especificación y descripción del trabajo, que es un registro claro de la tarea, servicio o trabajo vinculado al pago (ii) el propio pago, que se asegura en un depósito programado e imparcial hasta un estado terminal y se libera programáticamente, (iii) presentación registrada, verificable y rastreable del entregable que protege tanto al cliente como al proveedor y (iv) certificación del evaluador, que resulta en señales significativas para la identidad y reputación de las partes involucradas, proporcionando incentivos alineados para una liquidación sin confianza.
Esto motiva el flujo del Trabajo a través de cuatro estados clave, asegurando transacciones sin confianza:
Open → Funded → Submitted → Terminal (Completed / Rejected / Expired)
En resumen, un Trabajo se inicializa cuando un Cliente crea un trabajo con un Proveedor y posteriormente lo financia, asegurando el pago en depósito. Un Proveedor realiza el trabajo y llama a submit, poniendo el entregable (o una referencia de este) en cadena. Un Evaluador revisa la presentación y llama a complete (liberando fondos al proveedor) o reject (reembolsando al cliente). Si ni el proveedor ni el evaluador actúan antes del plazo (hora de expiración), el trabajo expira y el cliente recupera sus fondos.
El estándar es deliberadamente mínimo y constituye el elemento atómico. No especifica flujos de negociación, estructuras de tarifas, resolución de disputas, protocolos de comunicación ni mecanismos de descubrimiento. Especifica el ciclo de vida del trabajo, la superficie mínima viable para el comercio entre agentes sin confianza.
El evaluador
Uno de los conceptos clave y decisiones de diseño en ERC-8183 es el concepto de Evaluador, y cómo el evaluador se define simplemente como una dirección. Siempre es un agente, en el sentido más amplio de la palabra.
Para tareas subjetivas como escritura, diseño o análisis, el evaluador puede ser un agente IA que lee la presentación, la compara con la solicitud y toma una decisión. Para tareas deterministas como computación, generación de pruebas o transformación de datos, el evaluador es un contrato inteligente que envuelve un verificador ZK. El proveedor presenta una prueba, el evaluador la verifica en cadena y llama a complete o reject automáticamente. Para compromisos de alto riesgo, el evaluador puede ser un multi-sig, una DAO o un validador respaldado por staking.
El estándar no distingue entre estos. Una dirección llama a complete o reject. Si esa dirección ejecuta un agente impulsado por LLM o un circuito ZK, no es asunto del protocolo. Esto permite que la misma interfaz funcione para un trabajo de generación de imágenes de 0,10 $ y para una gestión de fondos de 100 000 $.
Hooks: extensibilidad modular
El elemento Trabajo es deliberadamente mínimo. Pero el comercio no lo es. Las aplicaciones reales necesitan validación personalizada, actualización de reputación, distribución de tarifas, transferencias de fondos, mecanismos de puja y lógica específica de dominio que varía entre casos de uso. Un trabajo de evaluación de contenido, un intercambio de tokens y una posición en un mercado de predicción requieren lógicas fundamentalmente distintas.
ERC-8183 resuelve esto con hooks. Un hook es un contrato inteligente opcional adjunto a un Trabajo al crearlo. Recibe callbacks antes y después de cada acción, permitiendo ejecutar lógica personalizada alrededor del ciclo de vida principal sin modificarlo. El hook se identifica por un único selector de función (qué transición está ocurriendo) y recibe los parámetros relevantes. Puede imponer condiciones previas, bloquear acciones inválidas, desencadenar efectos secundarios o ejecutar transferencias de tokens adicionales, todo dentro de la misma transacción que el cambio de estado central.
Si no se establece un hook, el contrato se ejecuta normalmente. Una implementación sin hook cumple plenamente con ERC-8183. Los hooks son aditivos, no obligatorios. Este diseño mantiene el contrato principal pequeño y la interfaz estable. Los nuevos casos de uso se soportan mediante nuevos contratos hook, manteniendo la lógica de extensión en cadena, programática y sin confianza, igual que el núcleo.
Ejemplos de aplicaciones comerciales
El Trabajo central gestiona el comercio de servicios directo: pagar, entregar, evaluar. Pero la economía en la que operan los agentes no es directa. Algunos trabajos implican gestionar el capital de un cliente, no solo recibir una tarifa. Algunos requieren precios competitivos antes de asignar un proveedor. Algunos necesitan verificaciones de confianza que consulten datos externos de reputación. Estos son modelos económicos fundamentalmente distintos, y los hooks permiten que la misma interfaz principal de Trabajo soporte esta diversidad y hacen de ERC-8183 un elemento comercial versátil.
-
Los trabajos de servicio son la base y no requieren hook. Un cliente paga por generación de contenido, análisis de datos o revisión de código. El flujo de depósito y evaluación central lo gestiona completamente.
-
Los trabajos de transferencia de fondos van más allá de una tarifa de servicio. El cliente aporta capital (tokens para intercambiar, fondos para invertir), el proveedor lo transforma y la salida debe regresar. Un hook puede gestionar este flujo de capital bidireccional junto al depósito principal, asegurando que el proveedor deposite tokens de salida antes de completar el trabajo. Esto cubre una amplia gama de aplicaciones como yield farming, intercambios de tokens, rebalanceo de carteras, cualquier trabajo donde el proveedor maneja el dinero del cliente o requiere capital inicial para ejecutar y realizar una tarea, no solo ganar una tarifa.
-
Los trabajos de puja invierten el modelo de asignación. En vez de que el cliente elija un proveedor de antemano, los proveedores compiten en precio. Un hook verifica pujas firmadas criptográficamente en el momento de la asignación, demostrando que el proveedor seleccionado se comprometió con el precio reclamado. Ninguna parte puede fabricar o negar los términos.
-
Los trabajos restringidos por reputación imponen confianza a nivel de protocolo. Un hook consulta ERC-8004 antes de permitir acciones, bloqueando proveedores de baja reputación o exigiendo términos más estrictos para agentes no probados.
-
Los trabajos preservadores de privacidad utilizan hooks para permitir comercio sin exposición de datos. En vez de publicar datos sensibles de la tarea en cadena, un Privacy Hook puede exigir que el campo 'Submission' contenga una prueba de conocimiento cero (ZKP) o una referencia a un entorno cifrado (como un TEE). Esto asegura que, aunque el pago sea sin confianza y público, la propiedad intelectual o datos personales reales permanezcan como un 'santuario', accesibles solo para los agentes autorizados.
-
Los trabajos evaluados por riesgo o de underwriting pueden imponer underwriting a nivel de protocolo mediante hooks. Un hook puede exigir colateral en staking de proveedores o underwriters, consultar puntuaciones de reputación ERC-8004 y otros métricas relevantes antes de la asignación, imponer bonos que se pierden en evaluaciones fallidas o consultar oráculos externos de riesgo. Estos procesos de aprobación previamente opacos pueden volverse transparentes, programables y competitivos. Por ejemplo, pueden servirse distintas tolerancias de riesgo; uno que atienda agentes establecidos y de alta confianza podría requerir controles mínimos, mientras que otro en dominios de alto riesgo podría exigir colateral significativo.
Cada una de estas aplicaciones podría implementarse como un contrato hook diferente, manteniendo la funcionalidad central y el estándar del elemento Trabajo. Nuevos modelos económicos, aplicaciones comerciales o variantes de lógica personalizada son nuevos hooks. Hemos introducido los primeros hooks, que son ejemplos para demostrar lo posible, pero creemos que solo hemos arañado la superficie y los hooks más interesantes aún no se han escrito. ¿Cómo será el comercio entre agentes para seguros, colaboración creativa, coordinación de cadenas de suministro? No lo sabemos aún, y ese es el punto. Además, el comercio entre agentes evolucionará de formas que ninguno de nosotros puede anticipar plenamente, nuevos modelos económicos, nuevos mecanismos de confianza, nuevas formas de colaboración entre máquinas. El estándar está diseñado para crecer con esa evolución, no para limitarla. Este estándar debe construirse abiertamente, y merece serlo porque las mejores ideas vendrán del ecosistema, y esperamos descubrirlas juntos.
Simbiosis con ERC-8004
ERC-8183 no existe de forma aislada. Es simbiótico con ERC-8004 ("Trustless Agents"), el estándar Ethereum para identidad, reputación y validación de agentes.
ERC-8004 resuelve la búsqueda y la confianza: cómo los agentes se encuentran y evalúan la fiabilidad. Pero sus registros solo son valiosos según la actividad que registran. La identidad sin comercio o acciones es un perfil vacío. La reputación requiere interacciones reales para medir. La validación necesita entregables definidos para verificar.
ERC-8183 proporciona el comercio que alimenta la capa de confianza de ERC-8004. Cada trabajo es una señal de reputación. Cada presentación es un entregable que los validadores pueden evaluar. Cada evaluación es una certificación que otros agentes pueden consultar.
Los dos estándares forman un ciclo que potencialmente permite una auto-organización mayor y más poderosa entre agentes mediante interacciones sin confianza:
Discovery (8004) → Commerce (8183) → Reputation (8004) → Better Discovery → More Trustless Commerce
Ninguno está completo sin el otro. Juntos, forman la base del comercio y la interacción entre agentes sin confianza.
Más allá de los pagos
ERC-8183 no es un protocolo de pagos. Es un estándar de comercio.
Un pago mueve dinero. Pero el comercio requiere más que mover dinero. El comercio es todo lo que rodea el pago y lo hace confiable y funcional: lo que se acordó, si el trabajo se realizó, quién lo verificó y qué ocurre si no fue así. En el mundo tradicional, el comercio funciona por lo que rodea el pago: evaluación de riesgos y underwriting de comerciantes antes de poder aceptar pagos, extensión de crédito para que los compradores puedan transaccionar antes de disponer de fondos, detección de fraude en miles de millones de transacciones en tiempo real, mecanismos de devolución de cargos y disputas que protegen a los compradores cuando los servicios fallan, y sistemas de reputación que acumulan confianza tras interacciones repetidas. Estas funciones son lo que hacen valiosos a los procesadores de pagos, redes de tarjetas y plataformas; no el movimiento de fondos en sí, sino la infraestructura de confianza alrededor.
Cuando el comercio se mueve a la cadena, estas funciones no desaparecen. Deben reconstruirse de forma programática, abierta y sin confianza. Esto es ERC-8183.
El modelo de depósito en garantía y certificación del evaluador del elemento Trabajo es análogo a los mecanismos de devolución de cargos con términos de liquidación programables y definidos de antemano. Usar la reputación en cadena de ERC-8004 y otras métricas e historial en cadena como parte de ERC-8183 es análogo al underwriting propietario con historial portable y verificable.
Los hooks sustituyen la evaluación de riesgos centralizada por lógica modular, competitiva y auditable que cualquier facilitador puede desplegar. El resultado no es solo una forma de mover dinero en cadena, sino una forma de reconstruir toda la infraestructura de confianza del comercio, de forma abierta y sin permisos.
Los protocolos e interfaces de pago existentes, ya sean procesadores tradicionales o protocolos de transferencia de stablecoins como x402, ofrecen experiencias fluidas y nativas de Internet que gestionan el movimiento de fondos. ERC-8183 gestiona el ciclo de vida completo que convierte un pago en una transacción sin confianza: especificación, depósito en garantía, presentación del entregable, certificación del evaluador y liquidación determinista. Un agente puede interactuar mediante x402 o HTTP en la capa de interfaz mientras la liquidación subyacente pasa por ERC-8183 en cadena. Son complementarios.
Irreversibilidad, depósito en garantía y el problema de la devolución de cargos
Otra preocupación con los pagos independientes es la irreversibilidad. Cuando se carga una tarjeta y el servicio es insatisfactorio, el consumidor disputa y revierte el cargo. Cuando se transfiere un pago, el dinero se va. Esto es una objeción real y válida para pagos y transferencias brutas.
ERC-8183 mantiene este concepto central en su contrato estructuralmente. Los fondos se retienen en depósito hasta que un evaluador certifique que el entregable cumple los términos acordados. El camino de rechazo reembolsa al cliente. El camino de expiración recupera automáticamente. Esto es un equivalente programable y sin confianza al modelo de autorización y captura que hace funcionar el comercio con tarjetas, salvo que los términos se codifican de antemano y se ejecutan por código, no se resuelven a posteriori por una red con incentivos propios.
Para pre-autorización de montos inciertos, una reserva de hotel, un servicio donde el alcance puede ampliarse, la flexibilidad de los hooks puede diseñarse para bloquear un monto máximo y liquidar un monto final determinado por entradas verificables al completar. La arquitectura soporta los patrones que hacen flexibles los comportamientos de confianza en el comercio con tarjetas, manteniendo la liquidación transparente, abierta, sin confianza y en cadena.
La nueva ola de participantes económicos
La ola IA está creando nuevos participantes económicos, tanto compradores como comerciantes, más rápido que cualquier cambio previo. Millones de desarrolladores y no desarrolladores están construyendo y lanzando microservicios, APIs y herramientas usando asistentes IA de codificación, muchos sin entidad legal, sin sitio web y sin historial de transacciones. Agentes de empresas tecnológicas y frameworks open-source están incorporando millones de usuarios con agentes IA personales y asistentes.
Los sistemas de pago tradicionales tendrán dificultades para servir a estos comerciantes. No porque falte tecnología, sino porque cuando un procesador aprueba a un Proveedor, absorbe el riesgo de ese proveedor: fraude, devoluciones de cargos, disputas. Un comerciante sin historial, entidad ni antecedentes es demasiado arriesgado para suscribir.
ERC-8183 es sin permisos por diseño. Un proveedor es una dirección de billetera. Sin onboarding, sin underwriting, sin filtro. El elemento Trabajo da a estos comerciantes no solo una forma de cobrar, sino un ciclo de comercio completo: especificación del trabajo, pago en depósito, presentación verificable del entregable y certificación del evaluador, proporcionando la base de una transacción confiable.
La incapacidad para suscribir nuevos proveedores puede tratarse como una brecha temporal. Un estándar abierto comprime este plazo estructuralmente. Cualquier facilitador puede desplegar ERC-8183 hoy. El ecosistema evoluciona por experimentación, no por consenso institucional. Pero más fundamentalmente, ERC-8183 combinado con ERC-8004 no solo puentea la brecha de underwriting, sino que resuelve la causa raíz. La razón por la que los procesadores no pueden suscribir nuevos comerciantes es la ausencia de historial verificable. ERC-8183 produce ese historial. Cada trabajo completado se registra en cadena: el hash del entregable, la certificación del evaluador, el resultado. Ese historial es portable, verificable y no pertenece a nadie.
Importante: el historial no queda bloqueado en una sola plataforma. Hoy, la plataforma A conoce tu tasa de devoluciones de cargos, la plataforma B conoce tu puntuación de vendedor, pero no puedes llevar ese historial contigo. En ERC-8183, la reputación es el propio activo portable del comerciante, legible por cualquier facilitador, en cualquier cadena, a través de cualquier interfaz que lea el estándar. ERC-8183 alimenta la identidad y reputación en cadena (ERC-8004) y proporciona datos para underwriting.
Construyendo juntos el futuro del comercio entre agentes y la IA descentralizada
ERC-8183 es un estándar abierto para el comercio entre agentes sin confianza. Así puedes participar:
Construye con ERC-8183. Sé facilitador. Despliega ERC-8183 en tu cadena. Crea SDKs. Desarrolla wrappers. Construye scanners y trackers. Desarrolla nuevas interfaces y experiencias, y haz que liquiden de forma segura y verificable en cadena con ERC-8183. Crea frameworks de agentes que interactúen nativamente con el estándar.
Explora, experimenta y crea hooks. ¿Necesitas pagos por hitos o resolución de disputas? Desarrolla hooks. Este es el espacio para creatividad y evolución en una amplia diversidad de aplicaciones.
Desarrolla y registra evaluadores. Los evaluadores son clave para garantizar el comercio entre agentes seguro y sin confianza, pero escasean. Desarrolla evaluadores para dominios específicos, especialmente para dominios y servicios plenamente verificables. Regístralos en ERC-8004. Contribuye de forma significativa a la reputación e identidad de agentes.
Contribuye y da feedback. Este es un estándar colectivo. Solo se convertirá en lo que necesita ser mediante experimentación amplia, uso real, feedback honesto e iteración. Si falta algo, proponlo. Si algo está mal, desafíalo. La especificación es abierta, el repositorio es abierto, la discusión es abierta. Esto evoluciona juntos.
La economía de agentes se construirá sobre estándares abiertos o sobre jardines cerrados. Elegimos estándares abiertos. Un espacio digital compartido.
ERC-8004 para confianza. ERC-8183 para comercio. Todo lo demás es tuyo para construir.
¿Quieres más?
Especificación ERC-8183: https://eips.ethereum.org/EIPS/eip-8183
Especificación ERC-8004: eips.ethereum.org/EIPS/eip-8004
Discusión ERC-8183: ethereum-magicians.org/t/erc-8183-agentic-commerce/27902
Únete a la comunidad en Telegram: https://t.me/erc8183
Aviso legal:
-
Este artículo se reimprime de [virtuals_io]. Todos los derechos de autor pertenecen al autor original [virtuals_io]. Si hay objeciones a esta reimpresión, contacta con el equipo de Gate Learn, que lo gestionará de forma inmediata.
-
Aviso de responsabilidad: las opiniones y puntos de vista expresados en este artículo son únicamente del autor y no constituyen ningún tipo de asesoramiento de inversión.
-
Las traducciones del artículo a otros idiomas las realiza el equipo de Gate Learn. Salvo que se indique, está prohibido copiar, distribuir o plagiar los artículos traducidos.
