Am 2. Februar wurde Pandora gestartet, ein Projekt mit Schwerpunkt auf NFT-Fragmentierung. Sein Kernmerkmal ist ERC404, ein Token-Standard, der ERC20 und ERC721 kombiniert und die Eigenschaften nativer Liquidität und NFT-Fragmentierung aufweist. Als neu gestartetes Protokoll hat ERC404 umfangreiche Diskussionen in der Community ausgelöst. Das tägliche Handelsvolumen seines ersten Projekts, Pandora, hat ebenfalls 50 Millionen US-Dollar überschritten. Weitere Projekte, die auf ERC404 oder ähnlichen Token-Standards basieren, stehen zur Einführung bereit.
Da ERC404 ohne Diskussion und Überprüfung eines Ethereum Improvement Proposal (EIP) und eines Ethereum Request for Comments (ERC) direkt als Open Source für Experimente der Community zur Verfügung gestellt wurde, weist das Protokoll selbst viele Bereiche auf, die verbessert werden müssen. Das Beosin-Sicherheitsteam wird eine detaillierte Analyse des Designmechanismus und des Vertragscodes von ERC404 durchführen, um Krypto-Benutzern das Verständnis von ERC404 zu erleichtern.
Was ist ERC404?
ERC404 ist ein neues experimentelles Protokoll, das zwei Token-Standards „fusioniert“, ERC20 und ERC721. Einfach ausgedrückt ermöglicht ERC404, NFTs aufzuteilen und wie ERC20-Token zu handeln. ERC404-Token sind sowohl ERC20-Token als auch NFTs, d. h. ein ERC404-Token kann als ein ERC20-Token oder ein NFT angesehen werden.
Wenn ein Benutzer ein ERC404-Token kauft, erhält die Wallet des Benutzers automatisch ein Replikant-NFT. Wenn der Benutzer das Token verkauft, wird das entsprechende NFT automatisch vernichtet.
Nehmen wir Pandora, das erste Projekt von ERC404, als Beispiel. Der ERC404-Token dieses Projekts ist PANDORA und der entsprechende Replikant-NFT ist Pandora Replicants. Das Gesamtangebot an PANDORA-Token beträgt 10.000, also beträgt das entsprechende Gesamtangebot an Pandora-NFTs ebenfalls 10.000.
Wenn ein Benutzer PANDORA-Token auf Uniswap kauft, entspricht der Besitz von 1 PANDORA-Token dem gleichzeitigen Besitz von 1 Pandora-NFT. Sie können dann wählen, ob Sie PANDORA-Token verkaufen oder auf NFT-Handelsmärkten wie OpenSea Pandora-NFT verkaufen möchten. Benutzer können außerdem zuerst Pandora-NFTs kaufen und sich dann für den Verkauf von PANDORA-Token auf DEX entscheiden.
Da ERC404 zwei Eigenschaften von ERC20-Tokens und NFTs beinhaltet, sind Folgendes die Designmerkmale von ERC404, auf die Benutzer auch achten müssen:
1.
Wenn ERC404-Token als ERC20-Token gehandelt werden, sind Dezimalstellen beteiligt und werden berücksichtigt. ERC404 schreibt vor, dass die Anzahl der Token auf die entsprechende NFT-Nummer abgerundet wird. Wenn ein Benutzer beispielsweise 2,9 PANDORA-Token besitzt, besitzt er/sie aus NFT-Sicht nur 2 Pandora-NFT.
2.
Wenn in ERC404 v1 ERC404-Token als ERC20-Token gehandelt werden, wird während des Handels das entsprechende NFT zerstört und ein neues NFT generiert. Auf diese Weise wird jedes Mal, wenn ein neues NFT generiert wird, seine ID-Nummer von der höchsten ID-Nummer des ursprünglichen NFT abgezogen. ERC404 v2 ändert diesen Brennmechanismus, was später erläutert wird. Da Pandora NFT eine gewisse Seltenheit aufweisen soll, werden Benutzer Pandora-Token handeln, um die Seltenheit von Pandora NFT zwecks Arbitrage zu erhöhen und das ursprüngliche NFT durch ein selteneres Pandora NFT zu ersetzen.
3.
Wenn ein Benutzer im Fall von ERC404 v1 2,9 PANDORA-Token besitzt und 1 PANDORA-Token verkauft, hat der Token keine Seltenheit, aber der entsprechende NFT hat eine andere Seltenheit. Beim Verkauf von 1 Token wird zuerst das letzte vom Benutzer erhaltene Pandora-NFT vernichtet, daher müssen Benutzer auf die Seltenheit des dem PANDORA-Token entsprechenden NFT achten. Es wird empfohlen, dass eine Adresse nur einen PANDORA-Token speichert, der einem Pandora-NFT entspricht, oder dass Benutzer ihre Pandora-NFTs direkt handeln können.
ERC404-Codeanalyse
ERC404 v1 wurde auf Github von Acme, einem ehemaligen Softwareentwickler bei Coinbase, veröffentlicht und bietet viel Raum für Verbesserungen. Mit Hilfe der Community baut und verbessert das ERC404-Team derzeit ERC404 und hat am 15. Februar ERC404 v2 auf den Markt gebracht. ERC404 v2 reduziert den Gasverbrauch erheblich und optimiert den Mechanismus zum Kauf und Verkauf von ERC404-Token. Das aktuellste Code-Repository ist https://github.com/Pandora-Labs-Org/erc404.
Dieses Mal verwenden wir das Beosin-VaaS-Tool, um den ERC404-v2-Smart-Contract zu scannen, die ERC404-v2-Codes zu analysieren und zusammen mit den Beosin-Sicherheitsexperten Sicherheitsvorschläge für ERC404-Projekte zu machen:
Die Verträge von ERC404 v2 umfassen hauptsächlich ERC404.sol, ERC721Receiver.sol und DoubleEndedQueue.sol. DoubleEndedQueue ist eine neue Datenstruktur, die vom ERC404-Team eingeführt wurde, um die Logik des Token-Handels und des Verbrennens von NFT zu ändern.
ERC404 v2 ist, ähnlich v1, eine Hybridimplementierung von ERC721 und ERC20, wodurch ERC721-Token als ERC20-Token dargestellt werden können. Dabei entspricht jeder ERC721-Token einer festen Anzahl von ERC20-Token (bestimmt durch den Einheitenparameter). Beim Übertragen von ERC721-Token werden die entsprechenden ERC20-Token in Einheiten übertragen.
Im Vergleich zu v1 weist ERC404 v2 die folgenden Verbesserungen auf:
1.
Unterstützt EIP-2612
ERC404 v2 unterstützt EIP-2612 und ermöglicht gaslose Transaktionen durch signierte Nachrichten (Berechtigungen). „DOMAIN_SEPARATOR“ wird im Konstruktor berechnet und kann neu berechnet werden, wenn sich die Ketten-ID ändert, was die Kompatibilität des Vertrags verbessert.
Konstruktor(String-Speichername_, String-Speichersymbol_, uint8 Dezimalstellen_) {
name = name_;
symbol = symbol_;
wenn (Dezimalstellen_ < 18) {
DecimalsTooLow() zurücksetzen;
}
Dezimalstellen = Dezimalstellen_;
Einheiten = 10 ** Dezimalstellen;
// EIP-2612 Initialisierung
INITIAL_CHAIN_ID = Block.Chain-ID;
INITIAL_DOMAIN_SEPARATOR = _computeDomainSeparator();
}
2.
Sichere Überweisungsprüfung
Die Funktion safeTransferFrom in ihrem Vertrag folgt onERC721Received() im ERC721-Standard und überprüft den Empfänger, um sicherzustellen, dass der Empfänger ERC721-Token verarbeiten kann (z. B. wenn der Empfänger ein Vertrag ist).
Funktion safeTransferFrom(
Adresse von_,
richten an_,
uint256 id_,
Bytes Speicher Daten_
) öffentlich virtuell {
wenn (id_ > geprägt || id == 0) {
InvalidId(); zurücksetzen
}
transferFrom(von_, nach_, id_);
Wenn (
to_.code.length != 0 &&
ERC721Receiver(an_).beiERC721Empfangen(msg.sender, von_, id_, data_) !=
ERC721Receiver.aufERC721Received.selector
) {
UnsafeRecipient() zurücksetzen;
}
}
3. Verbesserte Präge- und Brennlogik
Anders als bei v1 wird beim Handel mit ERC404 v2-Token der entsprechende NFT nicht zerstört. Stattdessen werden alle NFT-IDs zur Wiederverwendung in einer doppelseitigen Warteschlange gespeichert. Auf diese Weise ist der ERC404 entsprechende NFT derselbe wie der typische ERC721-Token. Dasselbe wie Coins. Dieser Ansatz reduziert nicht nur den Gasverbrauch, sondern vereinfacht auch die Übertragungslogik von ERC404.
Die Verbesserungen von ERC404 v2 machen ERC404 skalierbarer und nachhaltiger, aber es gibt immer noch einige Sicherheitsrisiken, die Aufmerksamkeit verdienen:
1.
Whitelist-Funktion
ERC404 ermöglicht bestimmten Whitelist-Adressen die interne Übertragung von ERC721-Token, was zur Optimierung des Gasverbrauchs bestimmter Verträge oder Adressen verwendet werden kann. Dies kann jedoch auch Zentralisierungsprobleme oder Missbrauchspotenzial mit sich bringen.
abstrakter Vertrag ERC404 ist IERC404 {
.......
Mapping (Adresse => bool) öffentliche erc721TransferExempt;
......
// Behandelt ERC-721-Ausnahmen.
Funktion _transferERC20WithERC721(
//Benzin sparen durch internen Handel
}
}
2.
Übertragungsfunktionsproblem
Die Funktion „transferFrom“ verarbeitet ERC20- und ERC721-Übertragungen und unterscheidet die Logik der beiden Token-Standards anhand des Parameters „valueOrId_“. Entwicklern oder Benutzern können beim Aufrufen dieser Funktion Fehler unterlaufen, da diese Funktion davon ausgeht, dass es sich bei der Übertragung um eine Übertragung von ERC20-Token handelt, wenn der Wert der Übertragung größer ist als der Wert der Prägeanzahl.
Funktion transferFrom(
Adresse von_,
richten an_,
uint256 WertOderId_
) öffentliche virtuelle Rückgabewerte (bool) {
......
wenn (WertOderId_ <= _minted) {
// Beabsichtigt ist die Übertragung als ERC-721-Token (ID).
uint256 id = WertOderId_;
......
}
3.
Gasoptimierung
Obwohl ERC404 v2 die für die Benutzerinteraktion erforderliche Gasgebühr im Vergleich zu v1 deutlich reduziert hat, gibt es immer noch viel Raum für Verbesserungen. Beispielsweise verwendet der ERC404 v2-Vertrag einen benutzerdefinierten Error Revert NotFound() anstelle der Require-Anweisung mit einer Fehlermeldung, was seinen Gasverbrauch erhöht.
4.
Fehlende Notpausenfunktion
Als neugeborenes Protokoll weist ERC404 möglicherweise potenzielle Vertragsschwachstellen auf, die nicht ignoriert werden können. Wenn das Team den Vertrag entwickelt, sollte daher eine Notfallpausenfunktion in Betracht gezogen und im Vertrag eingerichtet werden. Außerdem sollte ein Risikoreaktionsplan formuliert werden, um bei auftretenden Risiken schnell reagieren und Schwachstellen beheben zu können.
Zuvor hatte Beosin dem Projektteam die oben genannten Sicherheitsvorschläge gemacht, als es das Audit von Avatar abschloss, einem innovativen Projekt auf Basis von ERC404, das dem Avatar-Team dabei half, die Sicherheit seiner Smart Contracts zu verbessern und den sicheren Betrieb des Avatar-Projekts zu gewährleisten. Dieses Audit umfasst eine formelle Überprüfung und ein manuelles Audit durch Sicherheitsexperten, um sicherzustellen, dass der Code keine logischen Schwachstellen aufweist:
Insgesamt versucht ERC404, die Probleme der Unteilbarkeit von NFT und der unzureichenden Liquidität aus einer neuen Perspektive zu lösen. Im Vergleich zu vorherigen NFT-Fragmentierungsprojekten geht es von nativen Token-Standards aus, die einfacher und effektiver zu implementieren sind und neue Methoden für den NFT-Handel bieten. Allerdings ist ERC404 unter den Token-Verträgen ein relativ komplexer Vertrag. Entwickler müssen auf die Eigenschaften von ERC20 und ERC721 sowie auf die Risiken achten, die durch das Hinzufügen neuer Funktionen entstehen können. Sicherheitsteams müssen bei Audits die Interaktion zwischen den ERC20- und ERC721-Funktionen sowie die Auswirkungen verschiedener Gasoptimierungs- und Zentralisierungsrisiken in den ERC404-Verträgen sorgfältig prüfen.
Beosin ist ein weltweit führendes Unternehmen für Blockchain-Sicherheit. Es hat Niederlassungen in Singapur, Korea, Japan und über 10 weiteren Ländern. Mit der Mission „Blockchain-Ökosystem sichern“ bietet Beosin eine „All-in-One“-Blockchain-Sicherheitslösung, die Smart Contract Audit, Risikoüberwachung und -warnung, KYT/AML und Crypto Tracing umfasst. Beosin hat bereits mehr als 3000 Smart Contracts geprüft, und ERC404-Projekte können gerne unsere Beratung und Prüfungen anfordern.