Excelente modelo de desarrollo en contrato NFT

Los siguientes son los patrones de desarrollo más comunes observados en los mejores contratos compilados por extranjeros:

• Reemplace ERC721Enumerable con contador para ahorrar gas.
• Utilice ERC721A para lograr una fundición por lotes eficiente.
• Utilice menta en lugar de safeMint
• Utilice el árbol Merkle para implementar el mecanismo de lista blanca
• Contratos de metadatos actualizables/intercambiables
• Proteger contra robots
• Evite los francotiradores de NFT (lanzamiento dirigido de NFT raros)
• otros modos

Reemplace ERC721Enumerable con contador para ahorrar gas.

Primero, una breve descripción, el estándar ERC-721 consta de 2 extensiones:

• ERC721Metadatos
• ERC721Enumerable

El estándar central 721 es muy simple: solo necesita implementar las siguientes funciones para cumplir con el estándar central 721:

2 extensiones agregan estas funciones arriba:

Entonces, ¿dónde está el problema con ERC721Enumerable?

OpenZeppelin proporciona implementaciones listas para usar para todas estas interfaces. Ninguna de ellas es perfecta, pero 2 implementaciones (ERC721 y ERC721Metadata) hacen un trabajo bastante bueno. Sin embargo, la implementación de ERC721Enumerable supone un gran desperdicio de gas. Consume mucho gas y desperdicia espacio de almacenamiento. Vea cómo implementan la interfaz ERC721Enumerable:

Puedes imaginar lo inútil que es realizar un seguimiento de tantos mapas y matrices. (Por cierto, se actualizan antes/después de la transferencia). El código anterior está (erróneamente) optimizado para funciones de lectura, mientras que debería optimizarse para funciones de escritura (ya que las funciones de lectura son en su mayoría gratuitas). La mayoría de los desarrolladores por contrato son demasiado vagos y simplemente heredan las 3 interfaces de OpenZeppelin. Pero puedes hacerlo mejor.

Solución: si la única función que necesita de la interfaz ERC721Enumerable es totalSupplyentonces puede usar un número entero y usarlo como contador para realizar un seguimiento de cuánto se ha acuñado el NFT. Su contrato ya no implementará toda la interfaz Enumerable, pero ahorrará mucho combustible. La buena noticia es que solo necesita implementar la interfaz central ERC721 para cumplir con los requisitos de ERC721. (Es decir, incluso si no implementa la interfaz Enumerable, el mercado NFT no tendrá problemas para analizar su contrato).

La advertencia es que ya no tendrá una asignación de tokenID al propietario y viceversa, pero esta información se puede rastrear fuera de la cadena mediante eventos de Ethereum. Creo que OpenSea API ya proporciona esto. Además, el uso de The Graph simplifica la infraestructura web2 asociada con los eventos de Ethereum.

El contrato utiliza un contador en lugar de heredar el ERC721Enumerable de OZ con:

• Aquelarre criptográfico
• azuki

Crédito a Shiny Object por la exploración.

Acuñación por lotes eficiente con ERC721A

La mayoría de los contratos NFT amplían la implementación de OpenZeppelin. Pero no está optimizado para la acuñación por lotes. En comparación con la acuñación única, la acuñación por lotes puede ahorrar considerablemente algunos costos.

Por ejemplo, en lugar de activar un evento de transferencia para cada menta, podría simplemente activar un evento y especificar el lote completo de mentas en el evento. Otro ejemplo es actualizar los saldos de los propietarios solo una vez por lote, no después de cada acuñación.

Al darse cuenta de que existen algunas optimizaciones posibles para la acuñación por lotes, el equipo de Azuki creó ERC721A, una implementación de ERC721 optimizada para la acuñación por lotes. Así es como se compara con la implementación de OZ:

¿Cómo logra ERC721A estos ahorros? Utilice principalmente estas optimizaciones:

• Deshazte del ERC721Enumerable de OZ
• Actualice los datos solo una vez por lote en lugar de actualizarlos después de cada acuñación de monedas.
• Utilice un diseño de almacenamiento más eficiente: si NFT consecutivos tienen el mismo propietario, no almacene información redundante sobre el propietario (solo una vez para el primer NFT de propiedad). Estos datos se pueden inferir en tiempo de ejecución leyendo a la izquierda hasta que se encuentre la información del propietario.
• Solo se activa un evento de transferencia por lote. (Este es un cambio reciente más relevante , no forma parte del ERC721A original)

Puede leer más sobre ERC721A en el sitio web de Azuki .

Si necesita toda la funcionalidad de la interfaz Enumerable, puede usar la interfaz ERC721AQueryable de Azuki, que es una versión optimizada de ERC721Enumerable.

Contrato utilizando ERC721A:

• azuki
• ciudad de los duendes
• la espera
• pájaros lunares

Utilice menta en lugar de safeMint

safeMintOriginalmente tenía como objetivo evitar que las NFT se perdieran en los contratos. Si el destinatario del NFT es un contrato y no tiene un método de transferencia NFT, el NFT permanecerá en el contrato para siempre.

Por lo tanto, el contrato receptor debe implementar la interfaz ERC721Receiver para permitir que el contrato NFT verifique si el receptor recibe correctamente el NFT. Si un contrato implementa la interfaz del receptor, indica que sabe qué hacer con el NFT después de recibirlo:

Si su receptor es solo una cuenta normal, no un contrato, no es necesario que lo utilice safeMint. Si está 100% seguro de que el contrato del receptor puede manejar NFT, tampoco es necesario que los utilice safeMint.

Puedes ahorrar algo de gasolina usando mint en lugar de safeMint. Lo mismo ocurre con el uso transferen lugar de safeTransfer.

Los contratos que hacen esto son:

• Aquelarre criptográfico

Utilice el árbol Merkle para implementar el mecanismo de lista blanca

Si utiliza un árbol Merkle para implementar su lista blanca, puede ahorrar mucho almacenamiento (y gas). Un árbol Merkle es una estructura de datos eficiente que le permite almacenar un conjunto de direcciones al costo de una sola dirección. La desventaja es que el tiempo de búsqueda no es O(1) . Pero *O(n)* también es bastante bueno.

Todo lo que necesitas agregar a tu contrato son estas funciones:

Puede utilizar la biblioteca MerkleProof de OpenZeppelin para el paso de verificación.

Luego modificarías tu función de transmisión de esta manera:

Básicamente, simplemente agregue un parámetro adicional a la función mint: merkleProof. Se trata de una matriz de hashes de direcciones que forman la ruta desde la dirección mintable hasta la dirección raíz. Puede calcular esta ruta en su sitio web para cada dirección de acuñación permitida. Lea más sobre esto aquí .

Contratos que utilizan árboles Merkle:

• Aquelarre criptográfico
• OKPC

Contratos de metadatos actualizables/reemplazables

Si más adelante deseas actualizar la presentación de tu NFT o cambiar entre la representación dentro y fuera de la cadena, debes hacer que el contrato de metadatos sea reemplazable. como esto:

Los contratos que utilizan este método son:

• OKPC
• Esferas de reloj

Prevenir la acuñación de bots

Puedes tomar 2 medidas de seguridad para evitar que los robots extraigan todos tus tokens.

1. Limite la cantidad minable de cada billetera
2. comprobar msg.sender == tx.origin. Cuando un contrato llama a su función de acuñación, msg.senderserá la dirección del contrato, pero tx.originserá la dirección de la persona que llama al contrato. Puede encontrar más información aquí .

Protección contra francotiradores de NFT

El francotirador de NFT se produce cuando alguien sabe qué tokens son raros y sabe el orden en que se acuñaron. Por lo tanto, eligen el momento adecuado para acuñar un montón de NFT, con el objetivo de obtener NFT raros.

Desea evitar que los NFT sean atacados para garantizar una distribución justa de tokens para todos. Hablemos de cómo prevenir los ataques de NFT (al menos hasta cierto punto). El francotirador de NFT consta de 2 preguntas:

1. Metadatos de tokens expuestos (permite a los francotiradores inferir la rareza de los tokens)
2. Acuña fichas en un orden definido (deja que los francotiradores deduzcan el momento correcto para acuñar fichas raras).

Puede resolver el primer problema no divulgando metadatos hasta que se haya acuñado el token (más información aquí ). O puede utilizar la divulgación progresiva por lotes. Además, se leerán y utilizarán todos los datos de la cadena. Así que no verifique su contrato hasta que comience la acuñación.

El segundo problema se puede resolver aleatorizando el orden de acuñación. La aleatorización en cadena es difícil. Ethereum no tiene un generador de números aleatorios incorporado, por lo que la gente ha estado usando varios trucos, como usar el número de bloque actual como semilla y/o combinarlo con direcciones de minero para mayor aleatoriedad. Dado que esto no es realmente aleatorio, los francotiradores avanzados detectan fácilmente este tipo de trucos.

Se podría utilizar un oráculo aleatorio (Chainlink), pero incluso entonces, un francotirador avanzado puede  偷看 evitarlo con NFT, lo que se puede lograr: si los NFT acuñados no son raros, revertir la transacción (ejemplo aquí ). Desafortunadamente, no existe una forma 100% de resolver el segundo problema. Una cosa que podría hacer es agregar un mecanismo de lista blanca, pero eso solo funcionaría si toda la colección de NFT pudiera restringirse a la comunidad incluida en la lista blanca.

Ethereum es realmente un bosque oscuro y, si no tienes cuidado, te pueden disparar. Lea más sobre los ataques de francotiradores de NFT aquí .

otros modos

• Haga que el contrato sea extraíble ERC-721 y ERC-20: la mayoría de los contratos simplemente implementan la función de extracción de ETH, olvidándose de los problemas de ERC-721 y ERC-20. Pero a veces la gente envía tokens a contratos por error o por cualquier otro motivo. Agregue una función de extracción para que no se queden atrapados en su contrato (consulte el  contrato Crypto Coven para ver un ejemplo de implementación ).
• Haga que sus datos sean inmutables: cree un NFT dentro de la cadena o use una prueba de hash si se procesa fuera de la cadena .
• Autorización previa de OpenSea para listados con tarifa 0: (obsoleto desde Seaport). Anteriormente , era posible preautorizar el contrato OpenSea para que los titulares de NFT no tuvieran que invocarlo setApproval. Pero con la introducción de Seaport, esto ya no es necesario (consulte el  contrato Crypto Coven para ver un ejemplo de implementación ).