Estándar multi-token ERC-1155: ¿Qué es el estándar multi-token ERC-1155?ERC-1155 es un estándar de tokens de Ethereum que permite gestionar muchos tipos de tokens al mismo tiempo mediante un único contrato inteligente.Un solo contrEstándar multi-token ERC-1155: ¿Qué es el estándar multi-token ERC-1155?ERC-1155 es un estándar de tokens de Ethereum que permite gestionar muchos tipos de tokens al mismo tiempo mediante un único contrato inteligente.Un solo contr
¿Qué es el estándar multi-token ERC-1155?
ERC-1155 es un estándar de tokens de Ethereum que permite gestionar muchos tipos de tokens al mismo tiempo mediante un único contrato inteligente.Un solo contrato ERC-1155 puede representar tokens fungibles, tokens no fungibles, tokens semifungibles o una combinación de estos tipos de activos.La especificación ERC-1155 oficial define consultas de saldo estandarizadas, transferencias individuales y por lotes, autorizaciones de operadores, callbacks de recepción, eventos y metadatos opcionales.
ERC-1155 está clasificado como un estándar Final de Ethereum Request for Comments.Se conoce comúnmente como estándar multi-token porque cada ID de token dentro de un contrato puede representar un activo cripto independiente.Cada ID de token puede tener su propia oferta, saldos, metadatos, rareza, finalidad y características económicas.ERC-1155 se diseñó para reducir el coste y la complejidad de desplegar e interactuar con grandes colecciones de activos blockchain.¿Por qué se creó ERC-1155?
Los modelos de tokens anteriores solían exigir contratos independientes para distintos activos fungibles o colecciones de NFT.Por ello, un videojuego blockchain con cientos de monedas, recursos, armas, personajes y artículos de eventos podía necesitar muchos contratos.Desplegar contratos repetidamente aumenta el bytecode, las tareas de administración e integración y los costes de transacción.ERC-1155 agrupa muchos tipos de tokens en un solo contrato y aplica un sistema común de transferencias y autorizaciones.También admite operaciones por lotes estandarizadas que permiten transferir varios ID de token en una sola transacción.Esto hace que el estándar sea útil para videojuegos, coleccionables digitales, sistemas de membresía, inventarios tokenizados, posiciones financieras, programas de recompensas y otras aplicaciones cripto con muchas categorías de activos.El estándar no se limita a los videojuegos: puede utilizarse siempre que un contrato necesite gestionar varios tipos de tokens de forma eficiente.Cómo funciona ERC-1155
Un contrato ERC-1155 mantiene un saldo independiente para cada combinación de dirección de cuenta e ID de token.Una dirección puede poseer diez unidades del ID de token 1, una unidad del ID de token 2 y ninguna del ID de token 3 dentro del mismo contrato.Cada ID de token puede comportarse como un activo fungible, un NFT único o un activo con una oferta limitada de unidades intercambiables.Cuando se transfieren tokens, el contrato reduce el saldo del remitente para cada ID pertinente y aumenta el saldo correspondiente del destinatario.El contrato emite eventos estandarizados para que las wallets y los indexadores puedan reconstruir la creación, las transferencias y la destrucción de tokens.Si el destinatario es un contrato inteligente, el contrato ERC-1155 llama a una función de recepción para confirmar que acepta los activos.Los nodos de Ethereum ejecutan estas reglas y verifican los cambios de saldo resultantes de acuerdo con el código del contrato desplegado.¿Qué es un ID de token en ERC-1155?
Un ID de token es un entero sin signo que identifica un tipo de token dentro de un contrato ERC-1155.El mismo ID de token puede existir en otro contrato sin representar el mismo activo.Por tanto, un activo ERC-1155 se identifica conjuntamente por su red blockchain, la dirección del contrato y el ID de token.El ID de token 25 podría representar un recurso fungible de un videojuego en un contrato y un coleccionable único en otro.El estándar no exige que los ID comiencen en cero, aumenten de forma secuencial o codifiquen un significado concreto.Los desarrolladores pueden asignar los ID según la arquitectura de su aplicación.Las aplicaciones deben consultar datos fiables del contrato en lugar de adivinar qué ID de token existen.Tokens fungibles en ERC-1155
Un ID de token ERC-1155 puede representar un activo fungible cuando existen varias unidades intercambiables de ese ID.Por ejemplo, el ID de token 1 podría representar una moneda de videojuego con un millón de unidades idénticas.Cada titular tiene un saldo cuantitativo asociado al ID de token 1.Normalmente, las unidades del mismo ID tienen propiedades idénticas definidas por el contrato.A diferencia de ERC-20, ERC-1155 no define en su interfaz principal una función independiente de oferta total, símbolo, nombre o decimales para cada ID de token.Los proyectos deben proporcionar la información necesaria sobre la oferta o la visualización mediante extensiones, metadatos o funciones personalizadas.Tokens no fungibles en ERC-1155
Un ID de token ERC-1155 puede representar un activo no fungible si su oferta se limita a una unidad.La dirección que posee esa única unidad actúa como titular del token.Otro ID de token del mismo contrato puede representar un artículo único diferente.Por ejemplo, el ID de token 1001 podría representar una espada y el ID de token 1002, una parcela de terreno virtual.El estándar principal no obliga a que la oferta máxima de un ID de token sea una unidad.La lógica de acuñación del contrato debe imponer la unicidad cuando se pretende que un ID funcione como NFT.Tokens semifungibles
Un token semifungible comienza con unidades intercambiables, pero posteriormente puede adquirir un significado distinto o un uso limitado.Las entradas para eventos son un ejemplo habitual: varias entradas de una misma sección pueden ser intercambiables antes del evento.Después de utilizarse, cada entrada puede convertirse en un registro coleccionable asociado a una experiencia concreta.Los artículos de videojuegos con ediciones limitadas o estados cambiantes también pueden utilizar un modelo semifungible.ERC-1155 no clasifica formalmente los ID como fungibles, no fungibles o semifungibles.La clasificación depende de la oferta del token, los metadatos, las reglas de transferencia y el diseño de la aplicación.Funciones principales de ERC-1155
La interfaz principal incluye funciones para consultar saldos, transferir tokens y gestionar autorizaciones de operadores.Las funciones obligatorias son
balanceOf
, balanceOfBatch
, setApprovalForAll
, isApprovedForAll
, safeTransferFrom
y safeBatchTransferFrom
.ERC-1155 también exige la detección de interfaces ERC-165.La interfaz principal no exige acuñación pública, quema, oferta total, royalties, nombres de tokens, símbolos ni decimales.Estas funciones pueden añadirse mediante extensiones o lógica de implementación personalizada.La función balanceOf
La función
balanceOf
devuelve la cantidad de un ID de token que posee una dirección.Requiere como entradas una dirección de cuenta y un ID de token.Esto difiere de ERC-20, donde un contrato suele representar un solo tipo de token y la función solo necesita la dirección de una cuenta.También difiere de ERC-721, donde
balanceOf
indica cuántos NFT distintos de una colección posee una dirección.Un saldo ERC-1155 puede ser cero, uno o cualquier entero superior permitido por el contrato.El estándar exige que falle una consulta de saldo para la dirección cero.La función balanceOfBatch
La función
balanceOfBatch
obtiene en una sola llamada los saldos de varias cuentas e ID de token.El emisor de la llamada proporciona una matriz de direcciones de cuenta y otra matriz correspondiente de ID de token.Cada valor devuelto corresponde a la cuenta y al ID situados en la misma posición de las matrices.Las dos matrices de entrada deben tener la misma longitud.Esta función permite consultar varios activos de una cuenta o un activo en varias cuentas.Las consultas de saldos por lotes reducen el número de llamadas independientes que necesitan las wallets, los videojuegos y las aplicaciones de análisis.La función safeTransferFrom
La función
safeTransferFrom
transfiere una cantidad de un ID de token de una dirección a otra.El emisor de la llamada debe ser el titular del token o un operador autorizado por dicho titular.El remitente debe tener saldo suficiente del ID de token seleccionado.El destinatario no puede ser la dirección cero.La función también acepta un campo de bytes que puede contener información específica de la aplicación.Si el destinatario es un contrato inteligente, debe aceptar la transferencia mediante el callback de recepción ERC-1155 obligatorio.Una transferencia correcta emite un evento
TransferSingle
.La función safeBatchTransferFrom
La función
safeBatchTransferFrom
transfiere varios ID de token y cantidades en una sola transacción.El emisor de la llamada proporciona matrices correspondientes de ID de token y valores.La cantidad indicada en cada posición de la matriz de valores se transfiere para el ID de token situado en la misma posición.Las matrices deben tener la misma longitud.El emisor de la llamada debe ser el titular o un operador autorizado, y el titular debe tener saldo suficiente para todos los elementos del lote.Si falla alguna transferencia necesaria, normalmente se revierte la transacción completa.Una transferencia por lotes correcta emite un único evento
TransferBatch
, en lugar de un evento de transferencia independiente para cada ID de token.Por qué son importantes las transferencias por lotes
Las transferencias por lotes permiten mover varios tipos de activos mediante una sola transacción blockchain.Un usuario de un videojuego podría transferir conjuntamente moneda, materiales, armadura y artículos coleccionables.Una aplicación también podría distribuir varios tipos de recompensas a un destinatario en una sola operación.Agrupar transferencias puede reducir los costes repetidos de transacción y el coste total frente a enviar muchas transacciones independientes.El ahorro concreto depende del número de ID, la implementación del contrato, los cambios de almacenamiento, las condiciones de la red y la lógica del destinatario.Los lotes muy grandes pueden consumir demasiado gas y fallar por el límite de gas del bloque.Las aplicaciones deben establecer límites razonables para el tamaño de los lotes controlados por los usuarios.Autorizaciones de operadores ERC-1155
ERC-1155 utiliza un modelo de autorización de operadores que abarca toda la colección.La función
setApprovalForAll
permite al titular autorizar o revocar a un operador.Un operador autorizado puede gestionar todos los ID de token ERC-1155 que posea ese titular dentro del contrato.La autorización cubre los saldos actuales y los tokens que el titular reciba posteriormente del mismo contrato.El estándar no ofrece en su interfaz principal una función para autorizar un solo ID de token o una cantidad limitada.Este permiso amplio facilita el uso de las aplicaciones, pero conlleva un riesgo de seguridad significativo.Los usuarios deben verificar la dirección del operador y el contrato antes de autorizarlo.La función isApprovedForAll
La función
isApprovedForAll
indica si una dirección tiene autoridad como operador sobre los tokens de otra dirección.Devuelve
true
o false
.La autorización solo se aplica al contrato ERC-1155 en el que se registró.No concede automáticamente autoridad sobre tokens ERC-20, NFT ERC-721 ni activos de otro contrato ERC-1155.Los usuarios deben revisar periódicamente las autorizaciones de operadores activas y revocar los permisos que ya no necesiten.Desconectar una wallet de un sitio web no elimina una autorización de operador almacenada on-chain.Extensiones para autorizaciones granulares
El modelo de autorización amplio de ERC-1155 puede no ser adecuado cuando un usuario quiere autorizar solo determinados ID de token o cantidades.Otros estándares o contratos personalizados pueden ofrecer permisos más limitados.La extensión de allowance ERC-5216 define cantidades autorizadas para ID de token ERC-1155 concretos.
La compatibilidad con estas extensiones es opcional y no debe darse por supuesta.Una wallet debe distinguir claramente entre una autorización limitada a un ID de token y una autorización estándar para toda la colección.Interfaz de recepción ERC-1155
Un contrato inteligente que recibe tokens ERC-1155 mediante una transferencia segura estándar debe implementar la función de recepción adecuada.La interfaz de recepción incluye
onERC1155Received
para una transferencia individual y onERC1155BatchReceived
para una transferencia por lotes.El identificador ERC-165 de la interfaz de recepción es
0x4e2312e0
.El contrato receptor revisa el operador, el titular anterior, los ID de token, las cantidades y los datos adjuntos.Debe devolver el valor de aceptación esperado; de lo contrario, la transferencia se revierte.Este sistema reduce las transferencias accidentales a contratos que no pueden procesar activos ERC-1155.Callback de recepción para una transferencia individual
La función
onERC1155Received
se llama después de actualizar el saldo del destinatario para una transferencia individual.El valor de aceptación esperado es
0xf23a6e61
.El receptor puede validar el contrato del token, el operador, el remitente, el ID de token, la cantidad y los datos adjuntos.Puede aceptar la transferencia devolviendo el valor requerido.Puede rechazarla revirtiendo la operación o devolviendo otro valor.Un contrato receptor nunca debe acreditar un depósito basándose únicamente en los datos del callback sin verificar el contrato de token que lo llama.Callback de recepción para transferencias por lotes
La función
onERC1155BatchReceived
gestiona la recepción de varios ID de token en una sola transferencia.El valor de aceptación esperado es
0xbc197c81
.Las matrices de ID y cantidades deben interpretarse respetando el orden correspondiente.El receptor debe validar sus longitudes y confirmar que todos los ID admitidos cumplen las reglas de la aplicación.Si devuelve un valor incorrecto o revierte la operación, falla toda la transferencia por lotes.Un receptor por lotes debe diseñarse con cuidado porque una sola transacción puede entregar muchos tipos de activos distintos.Callbacks de recepción y reentrancia
Los callbacks de recepción ERC-1155 ejecutan código de contratos externos antes de que finalice la transacción de transferencia original.Durante el callback, el contrato receptor puede volver a llamar al contrato del token o a otra aplicación.Esto crea una posible vía de reentrancia.La especificación ERC-1155 exige que se actualicen los saldos y los eventos de transferencia antes de llamar al hook del receptor.Los contratos de la aplicación deben proteger igualmente su propia contabilidad y lógica de autorización.Cuando la lógica prevista lo permita, las directrices de seguridad de Solidity recomiendan completar las comprobaciones y los cambios de estado importantes antes de las interacciones externas.
Los desarrolladores deben probar ambas funciones de recepción con contratos maliciosos que intenten reentrar en la misma función o en otra función.Eventos ERC-1155
El estándar principal define los eventos
TransferSingle
, TransferBatch
, ApprovalForAll
y URI
.Estos registros permiten a las wallets, los exploradores, los indexadores y los sistemas de análisis hacer un seguimiento de la actividad de los tokens.El estándar está diseñado para que los saldos de los tokens y los cambios de oferta puedan reconstruirse a partir de los eventos de transferencia.Las implementaciones deben emitir los eventos correctos cada vez que se crean, transfieren o destruyen tokens.Un evento siempre debe interpretarse junto con la dirección del contrato que lo emitió.El evento TransferSingle
El evento
TransferSingle
registra el operador, el remitente, el destinatario, el ID de token y la cantidad de un tipo de token.Una transferencia normal incluye direcciones de remitente y destinatario distintas de cero.En una acuñación, la dirección cero se utiliza como remitente.En una quema, la dirección cero se utiliza como destinatario.Las transferencias de valor cero también deben generar el evento correspondiente.Los observadores pueden utilizar estos registros para actualizar los saldos indexados.El evento TransferBatch
El evento
TransferBatch
registra varios ID de token y cantidades transferidos en una operación.Los ID y las cantidades aparecen en posiciones correspondientes de sus matrices.El evento también registra el operador, el remitente y el destinatario.En una acuñación por lotes, la dirección cero se utiliza como remitente; en una quema por lotes, como destinatario.Los indexadores deben procesar todos los elementos de las matrices para calcular correctamente los saldos y las ofertas.El evento ApprovalForAll
El evento
ApprovalForAll
registra si un titular ha habilitado o deshabilitado a un operador.Identifica al titular, al operador y el estado de la autorización.El evento no transfiere tokens por sí mismo.Cambia si el operador puede iniciar futuras transferencias desde la cuenta del titular.Revocar a un operador no revierte las transacciones completadas mientras el permiso estaba activo.Detección de interfaces ERC-1155
ERC-1155 exige compatibilidad con el estándar de detección de interfaces ERC-165.El identificador de la interfaz principal ERC-1155 es
0xd9b67a26
.Un contrato compatible debe devolver
true
cuando se llama a supportsInterface
con este valor.El estándar ERC-165 define cómo los contratos inteligentes publican y detectan las interfaces compatibles.
La detección de interfaces ayuda a las aplicaciones a evitar llamadas que no son compatibles.Un contrato puede afirmar falsamente que es compatible o implementar mal las funciones, por lo que una respuesta afirmativa no constituye una garantía de seguridad completa.Metadatos ERC-1155
ERC-1155 incluye una extensión opcional de URI de metadatos.La extensión añade una función
uri
que devuelve una ubicación de metadatos para un ID de token.Su identificador de interfaz es
0x0e89341c
.La ubicación devuelta suele apuntar a un documento JSON con información como el nombre, la descripción, la imagen, los atributos y los recursos externos.A diferencia de las interfaces de metadatos ERC-20 y ERC-721, el diseño principal de ERC-1155 no exige funciones
name
o symbol
on-chain.Los proyectos pueden añadirlas mediante extensiones personalizadas.Sustitución del marcador {id} en los metadatos
Una URI de metadatos ERC-1155 puede contener el marcador
{id}
.Las aplicaciones sustituyen este marcador por el ID de token solicitado, expresado en hexadecimal en minúsculas.El valor debe contener 64 caracteres, incluidos los ceros iniciales, y no debe incluir el prefijo
0x
.Esta estructura permite que una URI base describa las ubicaciones de metadatos de muchos ID de token.Las aplicaciones deben realizar correctamente la sustitución o podrían solicitar el archivo de metadatos equivocado.Riesgos del almacenamiento de metadatos
Los metadatos ERC-1155 pueden almacenarse en un servidor tradicional, una red direccionada por contenido o directamente on-chain.El contenido alojado en un servidor puede cambiar o desaparecer.El almacenamiento direccionado por contenido mejora la integridad cuando el identificador coincide con el archivo, pero sigue dependiendo de que el contenido continúe disponible.Los metadatos on-chain reducen la dependencia del alojamiento externo, pero aumentan los costes de almacenamiento y despliegue.Una URI modificable puede cambiar nombres, imágenes, atributos o descripciones después de que los usuarios hayan adquirido tokens.Los usuarios deben comprobar quién puede modificar los metadatos y si se espera que el contenido referenciado siga disponible.Acuñación de tokens ERC-1155
La acuñación crea unidades de tokens y las asigna a una dirección.La interfaz principal ERC-1155 no define una función pública de acuñación.Cada implementación decide quién puede acuñar, qué ID pueden crearse y si se aplican límites de oferta.Una acuñación debe emitir
TransferSingle
o TransferBatch
con la dirección cero como remitente.Si los tokens se acuñan para un contrato inteligente, normalmente se aplica el callback de recepción adecuado.Los usuarios deben revisar los permisos de acuñación en lugar de dar por sentado que un ID similar a un NFT tiene una oferta limitada permanentemente.Quema de tokens ERC-1155
La quema elimina permanentemente unidades de los saldos de acuerdo con la implementación del contrato.La interfaz principal no exige una función pública de quema.Un proyecto puede permitir que los titulares, los operadores autorizados, los administradores u otra lógica del protocolo quemen activos.Una quema debe emitir el evento de transferencia correspondiente con la dirección cero como destinatario.Quemar todas las unidades existentes de un ID no impide necesariamente que el contrato vuelva a acuñar ese ID.El resultado depende de las reglas de oferta y control de acceso del contrato.Oferta total de ERC-1155
El estándar principal ERC-1155 no define una función
totalSupply
.La oferta de cada ID de token puede calcularse a partir de los eventos de acuñación y quema cuando la implementación cumple las reglas de emisión de eventos exigidas.Un contrato puede añadir una extensión de seguimiento de oferta para facilitar las consultas on-chain.La API de implementación ERC-1155 actual incluye una extensión opcional que realiza un seguimiento de la oferta total por ID de token.
Las aplicaciones no deben dar por supuesto que todos los contratos ERC-1155 exponen las mismas funciones de oferta.Enumeración ERC-1155
ERC-1155 no define una función principal que enumere todos los ID de token o todos los titulares.El estándar espera que los sistemas off-chain reconstruyan la actividad de los tokens a partir de los eventos
TransferSingle
, TransferBatch
y URI
.Normalmente, un indexador comienza en el bloque de despliegue del contrato y procesa los eventos hasta el bloque más reciente.Si se omite un evento, pueden generarse saldos u ofertas incorrectos.Los contratos pueden añadir funciones de enumeración personalizadas, pero no están disponibles de forma universal.Royalties ERC-1155
El estándar principal ERC-1155 no define royalties para creadores.El estándar de royalties ERC-2981, opcional, puede proporcionar un destinatario de royalties y un importe de pago sugerido para la venta de un token.
ERC-2981 es compatible con ERC-1155 y puede establecer información de royalties predeterminada o específica para cada token.El estándar comunica información de pago, pero no obliga a todas las aplicaciones a abonarlo.La configuración de royalties también puede ser modificable si la implementación concede esa autoridad a un administrador.Errores estandarizados ERC-1155
El estándar ERC-1155 original no define errores personalizados modernos de Solidity.El estándar Final ERC-6093 define errores comunes para las implementaciones ERC-1155.
Entre ellos hay errores por saldos insuficientes, remitentes no válidos, destinatarios no válidos, falta de autorización del operador, operadores no válidos y longitudes de matriz no coincidentes.Los errores estandarizados pueden ayudar a las wallets y a los desarrolladores a explicar los fallos de transacción de forma coherente.Los contratos ERC-1155 existentes no están obligados a adoptarlos.ERC-1155 frente a ERC-20
ERC-20 suele representar un tipo de token fungible por contrato.ERC-1155 puede representar muchos ID de tokens fungibles y no fungibles dentro de un solo contrato.ERC-20 utiliza allowances numéricas para los operadores individuales, mientras que ERC-1155 utiliza en su interfaz principal una autorización de operador para toda la colección.ERC-1155 admite transferencias por lotes estandarizadas y callbacks de recepción.El estándar principal ERC-20 no ofrece ninguna de estas dos funciones.ERC-20 puede seguir siendo más sencillo cuando un proyecto solo necesita un activo cripto fungible.ERC-1155 frente a ERC-721
ERC-721 representa ID de tokens no fungibles de titularidad individual.Un ID de token ERC-721 válido tiene un único titular, en lugar de un saldo cuantitativo por cuenta.ERC-1155 almacena una cantidad para cada combinación de cuenta e ID de token.Esto permite que un ID tenga muchas unidades intercambiables mientras que otro ID del mismo contrato tenga una oferta de una unidad.ERC-1155 también admite transferencias por lotes estandarizadas, mientras que ERC-721 normalmente transfiere un NFT cada vez.ERC-721 puede ofrecer un modelo de titularidad más sencillo cuando todos los tokens son únicos.Casos de uso de ERC-1155
Los videojuegos blockchain pueden utilizar un contrato ERC-1155 para monedas, materiales, personajes, armas, terrenos y artículos de edición limitada.Los sistemas de eventos pueden emitir varias categorías y cantidades de entradas desde un contrato.Los proyectos de membresía pueden gestionar distintos niveles de acceso, grupos de vencimiento o paquetes de ventajas mediante ID de token separados.Los proyectos de coleccionables digitales pueden crear ediciones con varias copias intercambiables de cada obra.Las aplicaciones financieras pueden utilizar ID para representar fechas de vencimiento, derechos, grupos de riesgo o categorías de posiciones.Los sistemas de recompensas pueden distribuir varios tipos de puntos o artículos de logros en un solo lote.El estándar no verifica que un token represente un derecho legal válido ni un activo del mundo real.Riesgos del phishing de autorizaciones
Una aplicación maliciosa puede pedir al usuario que ejecute
setApprovalForAll
presentando la solicitud como una verificación o una conexión de wallet.Una vez autorizada, la dirección del operador puede transferir todos los ID de token ERC-1155 que el usuario posea en ese contrato.La autorización también puede aplicarse a los tokens que el usuario reciba posteriormente.Antes de firmar, los usuarios deben revisar la red, el contrato del token, la dirección del operador y el tipo de permiso.Revocar el acceso a un sitio web desde la interfaz de una wallet no revoca automáticamente la autorización blockchain.Nunca se necesita una frase de recuperación ni una clave privada para cancelar un permiso de operador ERC-1155.Riesgos del procesamiento por lotes
Las operaciones por lotes procesan matrices cuyos elementos deben permanecer correctamente alineados.Una discrepancia entre los ID y las cantidades debería hacer que la transacción falle.Un indexado incorrecto puede transferir una cantidad equivocada de un activo.Los lotes grandes pueden superar los límites de gas de la transacción o crear condiciones de denegación de servicio.Un receptor puede aceptar ciertos ID de token desde el punto de vista económico, pero no otros; por tanto, debe validar todo el lote antes de confirmar la recepción.Las aplicaciones deben limitar el tamaño de los lotes y probar ID de token repetidos o desordenados conforme a las reglas de su implementación.Riesgos de recepción y reentrancia
Las transferencias seguras llaman a código externo del receptor después de actualizar los saldos.Un receptor malicioso puede intentar reentrar en funciones de acuñación, transferencia, venta, staking, préstamo o retirada.Un contrato puede seguir siendo vulnerable aunque una función tenga protección contra la reentrancia si otra función expone un estado relacionado.Los desarrolladores deben aplicar una lógica coherente de transición de estado en las operaciones individuales y por lotes.Los callbacks de recepción deben verificar el contrato de token que los llama y no confiar automáticamente en los datos proporcionados por el usuario.Las pruebas de seguridad deben incluir transferencias anidadas, receptores que reenvían tokens, callbacks revertidos e interacciones entre contratos.Riesgos de oferta y autenticidad
Un ID de token ERC-1155 puede parecer único porque actualmente solo existe una unidad.Sin embargo, un acuñador autorizado todavía podría crear más unidades posteriormente.También se puede copiar el nombre de una colección, una imagen o un ID de token en otro contrato.La dirección del contrato y la red son elementos esenciales para identificar el activo.Antes de confiar en afirmaciones de escasez, los usuarios deben revisar la autoridad de acuñación, las extensiones de oferta, los permisos de administrador y los controles de actualización.La conformidad con ERC-1155 no demuestra autenticidad, respaldo, rareza ni valor financiero.Riesgos de los contratos actualizables
Un contrato ERC-1155 puede funcionar mediante un proxy actualizable.Un administrador autorizado puede tener la capacidad de cambiar la acuñación, las transferencias, las autorizaciones, los metadatos, las comisiones o el comportamiento de recepción.Las actualizaciones pueden corregir defectos, pero también introducir código malicioso o inseguro.Si se compromete una clave de actualización, todos los ID de token del contrato pueden quedar en riesgo.Los usuarios deben examinar la autoridad de actualización, los periodos de espera, los requisitos de multifirma y los controles de emergencia.Un contrato puede admitir la interfaz correcta y conservar permisos centralizados muy amplios.Cómo deben implementar ERC-1155 los desarrolladores
Los desarrolladores deben partir de una implementación mantenida y revisada activamente, en lugar de reescribir la lógica sensible de saldos sin una razón de peso.La guía de desarrollo ERC-1155 actual proporciona contratos principales y explica los saldos multi-token y las operaciones por lotes.
Las funciones de acuñación y administración deben utilizar controles de acceso explícitos.Las restricciones de oferta deben imponerse en la lógica del contrato, no limitarse a describir en la documentación del proyecto.Los desarrolladores deben emitir todos los eventos obligatorios y devolver los valores de interfaz ERC-165 correctos.Las pruebas deben cubrir transferencias individuales y por lotes, autorizaciones, quemas, acuñaciones, discrepancias entre matrices, receptores no válidos, callbacks maliciosos y cambios de metadatos.Cómo pueden evaluar los usuarios un token ERC-1155
El primer paso es verificar la red blockchain, la dirección del contrato y el ID de token.El segundo paso es determinar si el ID está pensado para ser fungible, no fungible o semifungible.El tercer paso es examinar la oferta actual, la autoridad de acuñación y los límites de oferta.El cuarto paso es revisar las autorizaciones de operador asociadas a la wallet.El quinto paso es examinar el almacenamiento de metadatos y determinar si estos pueden cambiar.El sexto paso es identificar las facultades de administración, pausa, congelación y actualización.El séptimo paso es entender si los callbacks de recepción o los contratos externos introducen riesgos adicionales.El octavo paso es revisar las auditorías y el código fuente verificado sin considerarlos garantías.El noveno paso es confirmar qué derechos o utilidad proporciona realmente el token.El décimo paso es probar un contrato desconocido con una cantidad limitada antes de transferir activos valiosos.Ejemplo de transferencia por lotes ERC-1155
Supongamos que Alice posee 100 unidades del ID de token 1, cinco unidades del ID de token 2 y una unidad del ID de token 3.Quiere enviar a Bob diez unidades del ID 1, dos unidades del ID 2 y una unidad del ID 3.Su wallet llama a
safeBatchTransferFrom
con matrices que contienen los tres ID y sus cantidades correspondientes.El contrato verifica los saldos de Alice y la autoridad del emisor de la llamada.Reduce los saldos de Alice y aumenta los de Bob para cada ID indicado.El contrato emite un único evento
TransferBatch
que describe todo el movimiento.Si Bob es un contrato inteligente, el contrato del token llama a
onERC1155BatchReceived
.Si el receptor devuelve el valor de aceptación correcto, la transacción se completa.Si falla alguna comprobación de saldo o requisito del receptor, se revierte toda la transferencia por lotes.Errores habituales con ERC-1155
Un error habitual es suponer que todos los ID de token ERC-1155 son NFT.Otro error es dar por sentado que una unidad es la oferta máxima de un ID de token.Un tercer error es conceder una autorización de operador sin entender que abarca todos los ID del contrato.Un cuarto error es creer que desconectar una wallet elimina las autorizaciones on-chain.Un quinto error es utilizar la disponibilidad de metadatos como prueba de que existe un token.Un sexto error es suponer que ERC-1155 define una función de oferta total para cada ID.Un séptimo error es procesar matrices por lotes sin comprobar que sus longitudes y posiciones coincidan.Un octavo error es ignorar los callbacks externos del receptor y la reentrancia.Un noveno error es tratar los royalties como si se aplicaran automáticamente.Un décimo error es considerar que la conformidad de la interfaz demuestra la autenticidad, la escasez o la seguridad.Preguntas frecuentes
¿Qué significa ERC-1155?
ERC-1155 es el estándar multi-token de Ethereum para gestionar muchos tipos de tokens fungibles, no fungibles y semifungibles en un mismo contrato.¿ERC-1155 es una criptomoneda?
ERC-1155 es un estándar técnico; los contratos que lo implementan pueden crear muchos tipos de activos cripto.¿Cuál es el ID de interfaz ERC-1155?
El ID de la interfaz principal ERC-1155 es
0xd9b67a26
.¿Cuál es el ID de interfaz del receptor ERC-1155?
El ID de la interfaz del receptor es
0x4e2312e0
.¿Puede ERC-1155 crear tokens fungibles?
Sí. Un ID de token puede tener muchas unidades intercambiables distribuidas entre varias cuentas.¿Puede ERC-1155 crear NFT?
Sí. Un ID de token puede funcionar como NFT cuando la oferta impuesta por el contrato se limita a una unidad.¿Qué es un token semifungible ERC-1155?
Es un token cuyas unidades son intercambiables en un contexto, pero que posteriormente pueden adquirir un significado, estado o utilidad distintos.¿Puede un contrato ERC-1155 contener varios tipos de activos?
Sí. Un contrato puede gestionar muchos ID con diferentes ofertas, metadatos y finalidades.¿Qué devuelve balanceOf?
Devuelve la cantidad que posee una cuenta de un ID de token ERC-1155 concreto.¿Qué hace balanceOfBatch?
Devuelve en una sola llamada los saldos de varios pares de cuenta e ID de token.¿Qué es safeBatchTransferFrom?
Transfiere varios ID de token y cantidades en una sola transacción y comprueba la recepción cuando el destinatario es un contrato.¿Qué hace setApprovalForAll?
Autoriza a un operador a gestionar todos los ID de token que posee quien realiza la llamada dentro de un contrato ERC-1155.¿Puede un usuario autorizar un solo ID de token?
No mediante la función de autorización principal, aunque las extensiones opcionales o los contratos personalizados pueden ofrecer permisos más limitados.¿Caduca una autorización de operador ERC-1155?
No. La autorización estándar sigue activa hasta que se revoca o la lógica personalizada del contrato modifica sus efectos.¿ERC-1155 exige comprobaciones de recepción segura?
Sí. Las transferencias estándar a contratos inteligentes deben seguir las reglas del callback de recepción individual o por lotes que corresponda.¿Puede un receptor ERC-1155 rechazar tokens?
Sí. El receptor puede revertir la operación o devolver un valor de aceptación incorrecto, lo que hace que falle la transferencia.¿ERC-1155 admite metadatos?
Sí. Define una extensión opcional de URI de metadatos con el ID de interfaz
0x0e89341c
.¿Todos los tokens ERC-1155 tienen nombre y símbolo?
No. El estándar principal no exige funciones on-chain de nombre o símbolo.¿ERC-1155 define decimales?
No. Cuando se necesita información sobre la denominación, las aplicaciones deben obtenerla de los metadatos o de la lógica específica del proyecto.¿ERC-1155 incluye totalSupply?
No. Para consultar la oferta total es necesario indexar eventos o utilizar una extensión opcional de seguimiento de oferta.¿Pueden cambiar los metadatos ERC-1155?
Sí. Los metadatos pueden cambiar cuando el contrato o el sistema de almacenamiento externo permite actualizaciones.¿ERC-1155 impone el pago de royalties?
No. La información de royalties requiere un estándar independiente, y el contrato principal del token no obliga automáticamente a pagarlos.¿Las transferencias por lotes ERC-1155 pueden ahorrar gas?
Sí. Transferir varios ID de token en una sola transacción puede reducir los costes repetidos de transacción.¿Los callbacks ERC-1155 pueden provocar reentrancia?
Sí. Los callbacks de recepción ejecutan código externo y pueden llamar a otras funciones del contrato antes de que finalice la transacción original.¿La conformidad con ERC-1155 demuestra que un token es seguro?
No. Un contrato compatible todavía puede tener código inseguro, permisos excesivos, metadatos modificables, controles de oferta débiles o afirmaciones fraudulentas.Conclusión
ERC-1155 es el estándar de Ethereum para gestionar muchos tipos de tokens mediante un solo contrato inteligente.Cada ID de token puede representar un activo fungible, un NFT único, un artículo semifungible u otro activo cripto basado en saldos.El estándar define consultas de saldo individuales y por lotes, transferencias seguras, autorizaciones de operadores para toda la colección, callbacks de recepción, eventos y detección de interfaces.Las operaciones por lotes pueden reducir los costes de transacción cuando es necesario consultar o transferir varios ID de token a la vez.Los callbacks obligatorios del receptor reducen las transferencias accidentales a contratos incompatibles, pero introducen riesgos de llamadas externas y reentrancia.El estándar principal no define acuñación pública, quema, oferta total, decimales, royalties ni metadatos permanentes.Estas propiedades dependen de las extensiones opcionales y de la implementación de cada contrato.Los usuarios deben verificar la red, la dirección del contrato, el ID de token, los controles de oferta, las autorizaciones de operadores, el sistema de metadatos y los permisos de administrador.Los desarrolladores deben utilizar implementaciones mantenidas, emitir todos los eventos obligatorios, proteger los callbacks del receptor, limitar la complejidad de los lotes y probar todas las vías de autorización.ERC-1155 proporciona una infraestructura multi-token flexible y eficiente, pero la compatibilidad técnica no garantiza autenticidad, escasez, valor financiero ni seguridad del contrato inteligente.También te puede interesar
WhatsMiner M30S++
¿Qué es WhatsMiner M30S++? WhatsMiner M30S++ es un minero ASIC de Bitcoin de MicroBT diseñado para la minería Proof of Work con SHA-256. Forma parte de la serie WhatsMiner M30 y se utiliza principalme
2026/10/15 11:08
Dominios Web3
¿Qué son los dominios Web3? Los dominios Web3 son nombres basados en blockchain que pueden sustituir direcciones largas de carteras, dirigir a contenido descentralizado, representar una identidad on-c
2026/10/15 11:08
Proyectos Web3
¿Qué son los proyectos Web3? Los proyectos Web3 son aplicaciones, protocolos, herramientas, redes y comunidades basados en blockchain que utilizan tecnología descentralizada para dar a los usuarios ma
2026/10/15 11:06
POPULAR
Criptomonedas de moda que están acaparando la atención del mercado
Volumen TOP
Las criptomonedas con mayor volumen de trading
Recién Añadidos
Criptomonedas recientemente listadas y disponibles para operar