Fundadores y orígenes4 min de lecturaEthereum (ETH)

ERC-1155: cómo enviar un inventario de juego de una sola vez

Una espada y varias pociones no se cuentan de la misma manera. ERC-1155 les dio un contrato común y una forma de viajar juntas, sin convertir cada objeto en un único.

ERC-1155: cómo enviar un inventario de juego de una sola vez

Resumen clave en 3 puntos

  • El detonante / ParadojaERC-1155 registra varios tipos de tokens y sus respectivos saldos dentro de un contrato.
  • El punto de inflexiónUna transferencia por lotes empareja identificadores y cantidades entre una dirección y otra.
  • El legado históricoCompartir una interfaz no garantiza imágenes permanentes, compatibilidad entre juegos ni escasez.

Cronología de los hechos

17 de junio de 2018Una propuesta para varios tipos de tokens

La propuesta reúne activos fungibles y no fungibles en una misma interfaz.

17 de junio de 2019Se anuncia el estado Final

El coautor Witek Radomski anuncia la finalización del estándar tras su desarrollo comunitario.

El inventario no cabía en una sola categoría

Imaginemos que entregamos a otro jugador una mochila con una espada especial y tres pociones idénticas. La espada importa como objeto individual; las pociones, como cantidad. Es un ejemplo explicativo, no el relato de una operación real. También permite entender ERC-1155: una interfaz que reúne activos de distinta naturaleza, en lugar de tratar todo el inventario como una moneda o una colección de objetos únicos.[1]

La propuesta se creó el 17 de junio de 2018. Un año después, Witek Radomski, de Enjin, anunció que había alcanzado el estado Final. Describió el trabajo interno iniciado en 2017 y el posterior proceso comunitario de estandarización. La especificación reconoce a seis autores. Una estructura nacida de las necesidades de los objetos de juego se convirtió en una interfaz compartida que podían implementar monederos y aplicaciones, no en un formato exclusivo de un juego.[1][2]

El ID indica qué; el saldo, cuánto

Un contrato ERC-1155 guarda un saldo para cada combinación de cuenta e identificador de token. En nuestro inventario imaginario, un ID puede representar un tipo de poción con muchas unidades intercambiables; otro, una espada cuya oferta total limita la implementación a una unidad. Asignarle un ID no vuelve escaso al objeto. Las reglas de emisión siguen determinando si pueden aparecer más copias.[1]

Esto no significa que necesitara un contrato nuevo por cada individual. Una colección ya podía contener numerosos tokens distintos en un solo contrato. La diferencia es que, en ERC-1155, un ID puede identificar un tipo con una cantidad. Los activos fungibles y no fungibles comparten así la misma estructura contable. La pregunta pasa de «¿qué token único?» a «¿de qué tipo y cuántas unidades?».[1]

La mochila viaja en un lote

La operación safeBatchTransferFrom recibe listas de identificadores y de sus correspondientes cantidades. Un remitente puede trasladar la espada y tres pociones a un mismo destinatario con una sola llamada. Esto permite reducir el trabajo de realizar transacciones separadas para cada tipo. No constituye por sí solo un intercambio entre dos partes: el pago o la transferencia de activos en sentido contrario exige lógica adicional de la aplicación.[1]

Los contratos receptores también participan. Según las reglas habituales de transferencia segura del estándar, deben devolver el valor de aceptación esperado; si rechazan la operación, la transacción se revierte. Esa comprobación ayuda a detectar receptores incompatibles. No garantiza que después puedan devolver los objetos: la guía de OpenZeppelin advierte expresamente que los desarrolladores deben añadir también la función para transferirlos hacia fuera.[1][3]

La propiedad es solo una parte del juego

ERC-1155 estandariza saldos, transferencias y registros de eventos, no el comportamiento de una espada en combate. Los metadatos pueden remitir a un documento JSON separado con el nombre, la imagen y las propiedades. La especificación permite esa separación; no exige conservar cada imagen o regla del juego permanentemente en la cadena. Otro juego aún debe decidir si reconoce el objeto y qué permite hacer con él.[1]

Los permisos tienen otra frontera importante. La operación estándar setApprovalForAll autoriza a un operador a gestionar los tokens del titular dentro de ese contrato, no solo una poción elegida. La comodidad trae consigo un alcance que la interfaz debe explicar. La aportación duradera de ERC-1155 es una gramática común para un inventario diverso. El juego, las imágenes y la decisión de ceder el control siguen necesitando sus propias reglas.[1]

Universo Narrativo Conectado

Historias conectadas con este personaje o suceso

Explora las repercusiones históricas y los vínculos entre figuras y momentos clave.

Fuentes y referencias

  1. [1]Fuente 1: Especificación ERC-1155: saldos, lotes, receptores y metadatosEthereum Improvement Proposals · 2018-06-17Consultado 2026-09-22
  2. [2]Fuente 2: Anuncio de Witek Radomski sobre el estado Final en 2019Enjin · 2019-06-17Consultado 2026-09-22
  3. [3]Fuente 3: OpenZeppelin: implementación de objetos y contratos receptoresOpenZeppelinConsultado 2026-09-22