Le 2 février , Pandora, un projet centré sur la fragmentation NFT , a a été lancé. Sa fonctionnalité essentielle est ERC404, une norme de jeton qui combine ERC20 et ERC721 et possède les caractéristiques de liquidité native et de fragmentation NFT. En tant que protocole récemment lancé, ERC404 a déclenché de nombreuses discussions communautaires. Le volume d'échanges quotidien de son premier projet, Pandora, a également dépassé 50 millions de dollars. D'autres projets basés sur ERC404 ou des normes de jetons similaires sont prêts à être lancés.
Étant donné que l'ERC404 était directement open source pour la communauté pour des expériences sans la discussion et l'examen d'une proposition d'amélioration d'Ethereum (EIP) et d'une demande de commentaires d'Ethereum (ERC), le protocole lui-même comporte de nombreux domaines qui doivent être améliorés. L'équipe de sécurité de Beosin effectuera une analyse détaillée du mécanisme de conception et du code du contrat de l'ERC404 pour aider les utilisateurs de crypto-monnaie à comprendre l'ERC404.
Qu'est-ce que l'ERC404 ?
ERC404 est un nouveau protocole expérimental qui "fusionne" deux normes de jetons : ERC20 et ERC721. Pour dire simplement, ERC404 permet aux NFT d'être divisés et échangeés comme des jetons ERC20. Les jetons ERC404 sont à la fois des jetons ERC20 et des NFT, c'est-à-dire qu'un jeton ERC404 peut être considéré comme un jeton ERC20 ou un NFT.
Lorsqu'un utilisateur achète un jeton ERC404, le portefeuille de l'utilisateur recevra automatiquement un NFT Replicant. Lorsque l'utilisateur vend le jeton, le NFT correspondant sera automatiquement détruit.
Prenons Pandora, le premier projet de ERC404, comme exemple. Le jeton ERC404 de ce projet est PANDORA, et son Replicant NFT correspondant est Pandora Replicants. L'offre totale de jetons PANDORA est de 10 000, donc l'offre totale correspondante de NFT Pandora est également de 10 000.
Lorsqu'un utilisateur achète des jetons PANDORA sur Uniswap, détenir 1 jeton PANDORA équivaut à détenir 1 Pandora NFT en en même temps. Vous pouvez puis choisir de vendre des jetons PANDORA ou vous aller sur des marchés de négociation NFT tels que OpenSea pour vendre Pandora NFT. Il est également possibilité pour les utilisateurs d'acheter des NFT Pandora d'abord et de choisir ensuite de vendre des jetons PANDORA sur DEX.
Étant donné que l'ERC404 implique deux caractéristiques des jetons ERC20 et des NFT, voici les caractéristiques de conception de l'ERC404, qui sont également des éléments auxquels les utilisateurs doivent prêter attention :
1.
If ERC404 tokens are traded as ERC20 tokens, decimals will be involved and considered. ERC404 stipulates that the number of tokens is rounded down to the corresponding NFT number. For example, if a user holds 2.9 PANDORA tokens, he/she only holds 2 Pandora NFT from an NFT perspective.
2.
In ERC404 v1, if ERC404 tokens are traded as ERC20 tokens, the corresponding NFT will be destroyed and a new NFT will be generated during trading. In this way, each time a new NFT is generated, its ID number will be added from the highest ID number of the original NFT. ERC404 v2 changes this burning mechanism, which will be explained later. Since Pandora NFT is set to have a rarity, users will trade Pandora tokens to increase the rarity of Pandora NFT for arbitrage, and replace the original NFT with a rarer Pandora NFT.
3.
In the case of ERC404 v1, if a user holds 2.9 PANDORA tokens and sells 1 PANDORA token, the token has no rarity, but the corresponding NFT has different rarity. When selling 1 token, the last Pandora NFT received by the user will be destroyed first so users need to pay attention to the rarity of the NFT corresponding to the PANDORA token. It is recommended that one address only stores one PANDORA token, corresponding to one Pandora NFT, or users can directly trade their Pandora NFTs.
Analyse du code ERC404
ERC404 v1 a été publié sur Github par Acme, un ancien ingénieur logiciel chez Coinbase, et dispose de de nombreux espaces d'amélioration. Avec l'aide de la communauté, l'équipe ERC404 construit et améliore actuellement ERC404 et lance ERC404 V2 le 15 février. ERC404 V2 réduit considérablement la consommation de gaz et optimise le mécanisme d'achat et de vente de jetons ERC404. Son dernier référentiel de code est https://github.com/Pandora-Labs-Org/erc404.
Cette fois, nous utiliserons l'outil Beosin VaaS pour scanner le contrat intelligent ERC404 v2, analyser les codes ERC404 v2 et fournir des suggestions de sécurité pour les projets ERC404 avec les experts en sécurité de Beosin :
Les contrats de ERC404 v2 incluent principalement ERC404.sol, ERC721Receiver.sol et DoubleEndedQueue.sol. DoubleEndedQueue est une nouvelle structure de données introduite par l'équipe ERC404 pour changer la logique de l'échange de jeton et la gravure NFT.
ERC404 v2, similaire à v1, est une implémentation hybride de ERC721 et ERC20, permettant aux jetons ERC721 d'être représentés comme des jetons ERC20. Parmi eux, chaque jeton ERC721 correspond à un nombre fixe de jetons ERC20 (déterminé par le paramètre des unités). Lors du transfert de jetons ERC721, les jetons ERC20 correspondants sont transférés en unités.
Par rapport à la v1, ERC404 v2 présente les améliorations suivantes :
1.
Support EIP-2612
ERC404 v2 prend en charge EIP-2612, permettant des transactions sans gaz via des messages signés (autorisations). "DOMAIN_SEPARATOR" est calculé dans le constructeur et peut être recalculé si l'ID de chaîne change, ce qui améliore la compatibilité de son contrat.
constructeur (nom de la mémoire de chaîne_, symbole de la mémoire de chaîne, uint8 decimals_) {
nom = nom_ ;
symbole = symbole_ ;
if (décimales_ < 18) {
revenir DecimalsTooLow();
}
décimales = décimales_ ;
unités = 10 ** décimales ;
// Initialisation EIP-2612
INITIAL_CHAIN_ID = block.chainid ;
INITIAL_DOMAIN_SEPARATOR = _computeDomainSeparator();
}
2.
Safe Transfer Checking
La fonction safeTransferFrom dans son contrat suit onERC721Received() dans la norme ERC721 et vérifiera le destinataire pour s'assurer que le destinataire peut gérer les jetons ERC721 (par par exemple, le destinataire est un contrat).
fonction safeTransferFrom(
adresse de_,
Adressé à_,
uint256 id_,
octets de mémoire données_
) virtuel public {
if (id_ > minted || id == 0) {
revenir InvalidId();
}
transferFrom(from_, to_, id_);
si (
to_.code.length != 0 &&
ERC721Receiver(to_).onERC721Received(msg.sender, from_, id_, data_) !=
ERC721Receiver.onERC721Received.selector
) {
revenir UnsafeRecipient();
}
}
3. Logique de création et de gravure améliorée
Contrairement à la v1, lors de l'échange de jetons ERC404 v2, le NFT correspondant ne sera pas détruit. Au lieu de cela, tous les ID NFT sont stockés dans une file d'attente à double pour la réutilisation. De cette manière, le NFT correspondant à ERC404 est le identique au jeton ERC721 typique. Identique aux pièces de monnaie. Cette approche non seulement réduit la consommation de gaz, mais simplifie également la logique de transfert de ERC404.
Les améliorations de ERC404 v2 rend ERC404 plus évolutif et durable, mais il existe quelques risques de sécurité dignes d'attention :
1.
Whitelist Function
ERC404 permet à certaines adresses de liste blanche de transférer des jetons ERC721 en interne, qui peuvent être utilisés pour optimiser la consommation de gaz de contrats ou d'adresses spécifiques. Cependant, cela peut également entraîner des problèmes de centralisation ou un potentiel d'abus.
le contrat abstrait ERC404 est IERC404 {
.......
mapping(address => bool) public erc721TransferExempt ;
......
// Gère les exemptions ERC-721.
fonction _transferERC20WithERC721(
//économisez du gaz en négociant en interne
}
}
2.
Transfer Function Problem
La fonction transferFrom gère les transferts ERC20 et ERC721 et distingue la logique des deux normes de jetons en bas sur le paramètre valueOrId_ . Les développeurs ou les utilisateurs peuvent faire des erreurs lors de l'appel de cette fonction, car cette fonction a une présomption que si la valeur du transfert est supérieure à la valeur du compte de fractionnement, le transfer est un transfert de jetons ERC20.
fonction transfertDe(
adresse de_,
Adressé à_,
uint256 valeurOrId_
) retours virtuels publics (bool) {
......
if (valueOrId_ <= _minted) {
// L'intention est de transférer en tant que jeton ERC-721 (id).
uint256 identifiant = valueOrId_;
......
}
3.
Gas optimization
Bien que ERC404 v2 ait considérablement réduit les frais de gaz requis pour l'interaction avec l'utilisateur par par à la v1, il reste encore beaucoup de place pour l'amélioration. Par exemple, le contrat ERC404 v2 utilise un revert d'erreur personnalisé NotFound() au au de l'instruction require avec un message d'erreur, ce qui augmente sa consommation de gaz.
4.
Lack of emergency pause function
En tant que protocole nouvellement né, ERC404 peut présenter des vulnérabilités contractuelles potentielles qui ne peuvent être ignorées. Par conséquent, lorsque l'équipe élabore le contrat, une fonction de pause d'urgence doit être envisagée à mettre en place dans le contrat et un plan de réponse aux risques doit être formulé pour réagir rapidement et corriger les vulnérabilités lorsque des risques surviennent.
Auparavant, Beosin a mentionné les suggestions de sécurité ci-dessus à l'équipe du projet lors de la réalisation de l'audit d'Avatar, un projet innovant basé sur l'ERC404, qui a aidé l'équipe Avatar à améliorer la sécurité de ses contrats intelligents et à assurer le fonctionnement sûr du projet Avatar. Cet audit comprend une vérification formelle et un audit manuel par des experts en sécurité pour garantir que le code ne présente aucune vulnérabilité logique :
Dans l'ensemble, ERC404 tente de résoudre les problèmes d'indivisibilité NFT et de liquidité insuffisante dans une nouvelle perspective. Par par avec les précédents projets de fragmentation NFT , il part de des normes de jetons natifs , qui est plus simple et plus efficace à implémenter et fournit de nouvelles méthodes pour négocier NFT. Cependant, ERC404 est un contrat relativement complexe parmi les contrats symboliques. Les développeurs doivent prêter attention aux caractéristiques de l'ERC20 et de l'ERC721 et aux risques qui peuvent être introduits par l'ajout de nouvelles fonctions. Les équipes de sécurité doivent examiner attentivement l'interaction entre les fonctions ERC20 et ERC721 lors des audits, ainsi que l'impact des divers risques d'optimisation et de centralisation du gaz dans les contrats ERC404.
Beosin est l'une principale entreprise mondiale de sécurité blockchain. Elle possède des bureaux à Singapour, en Corée, au Japon et dans plus de 10 autres pays. Avec la mission de « Sécurisation de l'écosystème Blockchain », Beosin fournit une solution de sécurité blockchain « tout-en-un » couvrant l'audit de contrat intelligent , la surveillance et alerte des risques, KYT/AML et le traçage de crypto. Beosin a déjà audité plus de 3 000 contrats intelligents et les projets ERC404 sont bienvenus pour demander notre consultation et audits.