El 2 de febrero se lanzó Pandora, un proyecto centrado en la fragmentación de NFT. Su característica principal es ERC404, un estándar de token que combina ERC20 y ERC721 y tiene las características de liquidez nativa y fragmentación de NFT. Como protocolo recientemente lanzado, ERC404 ha desencadenado extensos debates comunitarios. El volumen diario de operaciones de su primer proyecto, Pandora, también ha superado los 50 millones de dólares. Más proyectos basados en ERC404 o estándares de tokens similares están listos para ser lanzados.
Dado que ERC404 fue de código abierto directamente para la comunidad para experimentos sin la discusión y revisión de una propuesta de mejora de Ethereum (EIP) y una solicitud de comentarios de Ethereum (ERC), el protocolo en sí tiene muchas áreas que necesitan mejorar. El equipo de seguridad de Beosin llevará a cabo un análisis detallado del mecanismo de diseño y el código de contrato de ERC404 para ayudar a los usuarios de criptomonedas a comprender ERC404.
¿Qué es ERC404?
ERC404 es un nuevo protocolo experimental que "fusiona" dos estándares de token, ERC20 y ERC721. En pocas palabras, ERC404 permite dividir y comercializar NFT como tokens ERC20. Los tokens ERC404 son tanto tokens ERC20 como NFT, es decir, un token ERC404 puede considerarse como un token ERC20 o un NFT.
Cuando un usuario compra un token ERC404, la billetera del usuario recibirá automáticamente un NFT replicante. Cuando el usuario venda el token, el NFT correspondiente se destruirá automáticamente.
Tomemos como ejemplo Pandora, el primer proyecto de ERC404. El token ERC404 de este proyecto es PANDORA, y su NFT Replicante correspondiente es Pandora Replicants. El suministro total de tokens PANDORA es 10 000, por lo que el suministro total correspondiente de NFT de Pandora también es 10 000.
Cuando un usuario compra tokens PANDORA en Uniswap, tener 1 token PANDORA equivale a tener 1 NFT de Pandora al mismo tiempo. Luego, puede optar por vender tokens PANDORA o ir a mercados comerciales de NFT como OpenSea para vender NFT de Pandora. También es posible que los usuarios compren NFT de Pandora primero y luego elijan vender tokens de PANDORA en DEX.
Dado que ERC404 implica dos características de los tokens ERC20 y NFT, las siguientes son las características de diseño de ERC404, que también son cosas a las que los usuarios deben prestar atención:
1.
Si los tokens ERC404 se comercializan como tokens ERC20, se incluirán y tendrán en cuenta los decimales. ERC404 estipula que el número de tokens se redondea hacia abajo al número NFT correspondiente. Por ejemplo, si un usuario tiene 2,9 tokens PANDORA, solo tiene 2 NFT de Pandora desde una perspectiva NFT.
2.
En ERC404 v1, si los tokens ERC404 se comercializan como tokens ERC20, el NFT correspondiente se destruirá y se generará un nuevo NFT durante la negociación. De esta manera, cada vez que se genere un nuevo NFT, su número de ID se agregará a partir del número de ID más alto del NFT original. ERC404 v2 cambia este mecanismo de grabación, que se explicará más adelante. Dado que Pandora NFT está configurado para tener una rareza, los usuarios intercambiarán tokens de Pandora para aumentar la rareza de Pandora NFT para el arbitraje y reemplazarán el NFT original con un Pandora NFT más raro.
3.
En el caso de ERC404 v1, si un usuario posee 2,9 tokens PANDORA y vende 1 token PANDORA, el token no tiene rareza, pero el NFT correspondiente tiene una rareza diferente. Al vender 1 token, el último NFT de Pandora recibido por el usuario se destruirá primero, por lo que los usuarios deben prestar atención a la rareza del NFT correspondiente al token de PANDORA. Se recomienda que una dirección almacene solo un token PANDORA, correspondiente a un NFT de Pandora, o los usuarios puedan intercambiar directamente sus NFT de Pandora.
Análisis de código ERC404
ERC404 v1 fue lanzado en Github por Acme, un ex ingeniero de software de Coinbase, y tiene muchos espacios para mejorar. Con la ayuda de la comunidad, el equipo de ERC404 está actualmente construyendo y mejorando ERC404 y lanzó ERC404 v2 el 15 de febrero. ERC404 v2 reduce en gran medida el consumo de gas y optimiza el mecanismo de compra y venta de ERC40 4 fichas. Su repositorio de código más reciente es https://github.com/Pandora-Labs-Org/erc404.
Esta vez usaremos la herramienta Beosin VaaS para escanear el contrato inteligente ERC404 v2, analizar los códigos ERC404 v2 y proporcionar sugerencias de seguridad para proyectos ERC404 con expertos en seguridad de Beosin:
Los contratos de ERC404 v2 incluyen principalmente ERC404.sol, ERC721Receiver.sol y DoubleEndedQueue.sol. DoubleEndedQueue es una nueva estructura de datos introducida por el equipo ERC404 para cambiar la lógica del comercio de tokens y la grabación de NFT.
ERC404 v2, similar a la v1, es una implementación híbrida de ERC721 y ERC20, que permite que los tokens ERC721 se representen como tokens ERC20. Entre ellos, cada token ERC721 corresponde a un número fijo de tokens ERC20 (determinado por el parámetro de unidades). Al transferir tokens ERC721, los tokens ERC20 correspondientes se transfieren en unidades.
En comparación con la versión 1, ERC404 v2 tiene las siguientes mejoras:
1.
Soporte EIP-2612
ERC404 v2 es compatible con EIP-2612, lo que permite transacciones sin gas a través de mensajes firmados (permisos). "DOMAIN_SEPARATOR" se calcula en el constructor y se puede volver a calcular si el ID de la cadena cambia, lo que mejora la compatibilidad de su contrato.
constructor(cadena memoria nombre_, cadena memoria símbolo_, uint8 decimales_) {
nombre = nombre_;
símbolo = símbolo_;
if (decimales_ < 18) {
revertir decimales demasiado bajos();
}
decimales = decimales_;
unidades = 10 ** decimales;
// Inicialización EIP-2612
INITIAL_CHAIN_ID = block.chainid;
INITIAL_DOMAIN_SEPARATOR = _computeDomainSeparator();
}
2.
Comprobación de transferencia segura
La función SafeTransferFrom en su contrato sigue a ERC721Received() en el estándar ERC721 y verificará al destinatario para asegurarse de que pueda manejar tokens ERC721 (por ejemplo, el destinatario es un contrato).
función transferencia segura desde (
dirección de_,
frente a_,
uint256 id_,
bytes memoria datos_
) público virtual {
if (id_ > acuñado || id == 0) {
revertir InvalidId();
}
transferirDe(de_, a_, id_);
si (
to_.code.length != 0 &&
ERC721Receiver(to_).onERC721Received(msg.sender, from_, id_, data_) !=
Receptor ERC721 en Selector recibido ERC721
) {
revertir UnsafeRecipient();
}
}
3. Lógica mejorada de acuñación y quema
A diferencia de la v1, al intercambiar tokens ERC404 v2, el NFT correspondiente no se destruirá. En cambio, todos los ID de NFT se almacenan en una cola de doble extremo para su reutilización. De esta forma, el NFT correspondiente a ERC404 es el mismo que el típico token ERC721. Lo mismo que las monedas. Este enfoque no solo reduce el consumo de gas, sino que también simplifica la lógica de transferencia de ERC404.
Las mejoras de ERC404 v2 hacen que ERC404 sea más escalable y sostenible, pero todavía existen algunos riesgos de seguridad dignos de atención:
1.
Función de lista blanca
ERC404 permite que ciertas direcciones de la lista blanca transfieran tokens ERC721 internamente, que se pueden usar para optimizar el uso de gas de contratos o direcciones específicas. Sin embargo, esto también puede generar problemas de centralización o la posibilidad de abuso.
contrato abstracto ERC404 es IERC404 {
.......
mapeo (dirección => bool) público erc721TransferExempt;
......
// Maneja las exenciones ERC-721 .
función _transferERC20WithERC721(
//ahorrar gasolina mediante el comercio interno
}
}
2.
Problema de función de transferencia
La función transferFrom maneja transferencias ERC20 y ERC721 y distingue la lógica de los dos estándares de token según el parámetro valueOrId_. Los desarrolladores o usuarios pueden cometer errores al llamar a esta función, porque esta función tiene la presunción de que si el valor de la transferencia es mayor que el valor del recuento de acuñación, la transferencia se trata de una transferencia de tokens ERC20.
transferencia de función desde (
dirección de_,
frente a_,
uint256 valorOrId_
) devoluciones virtuales públicas (bool) {
......
if (valueOrId_ <= _minted) {
// La intención es transferir como token ERC-721 (id).
uint256 id = valorOrId_;
......
}
3.
Optimización de gas
Aunque ERC404 v2 ha reducido significativamente la tarifa de gas requerida para la interacción del usuario en comparación con v1, todavía hay mucho espacio para mejorar. Por ejemplo, el contrato ERC404 v2 utiliza una reversión de error personalizada NotFound() en lugar de la declaración require con un mensaje de error, lo que aumenta su consumo de gas.
4.
Falta de función de pausa de emergencia
Como protocolo recién nacido, ERC404 puede tener posibles vulnerabilidades contractuales que no se pueden ignorar. Por lo tanto, cuando el equipo desarrolla el contrato, se debe considerar establecer una función de pausa de emergencia en el contrato y se debe formular un plan de respuesta al riesgo para responder rápidamente y corregir las vulnerabilidades cuando surjan riesgos.
Anteriormente, Beosin mencionó las sugerencias de seguridad anteriores al equipo del proyecto al completar la auditoría de Avatar, un proyecto innovador basado en ERC404, que ayudó al equipo de Avatar a mejorar la seguridad de sus contratos inteligentes y garantizar el funcionamiento seguro de Avatar. proyecto. Esta auditoría incluye una verificación formal y una auditoría manual por parte de expertos en seguridad para garantizar que el código no tenga vulnerabilidades lógicas:
En general, ERC404 intenta resolver los problemas de indivisibilidad de NFT y liquidez insuficiente desde una nueva perspectiva. En comparación con los proyectos de fragmentación de NFT anteriores, comienza con estándares de tokens nativos, que son más simples y más efectivos de implementar y proporcionan nuevos métodos para el comercio de NFT. Sin embargo, ERC404 es un contrato relativamente complejo entre los contratos simbólicos. Los desarrolladores deben prestar atención a las características de ERC20 y ERC721 y a los riesgos que pueden introducirse al agregar nuevas funciones. Los equipos de seguridad deben examinar cuidadosamente la interacción entre las funciones ERC20 y ERC721 durante las auditorías, así como el impacto de diversos riesgos de centralización y optimización de gas en los contratos ERC404.
Beosin es una empresa líder mundial en seguridad blockchain. Tiene oficinas en Singapur, Corea, Japón y otros más de 10 países. Con la misión de "Segurizar el ecosistema Blockchain", Beosin proporciona una solución de seguridad blockchain "todo en uno" que cubre auditoría de contratos inteligentes, alerta y monitoreo de riesgos, KYT/AML y seguimiento de criptomonedas. Beosin ya ha auditado más de 3000 contratos inteligentes y los proyectos ERC404 son bienvenidos para solicitar nuestra consulta y auditoría.