ERC721 OwnedTokens-Array-Längenbeschränkungen für Besitzer mit Tausenden von Token

Im ERC721Token-Vertrag frage ich mich die Grenzen von:

 mapping (address => uint256[]) private ownedTokens;

Ich bin daran interessiert, Benutzern Funktionen bereitzustellen, die möglicherweise Tausende von ERC721-Token haben.

Was sind die Obergrenzen für die Rückgabe des gesamten Arrays in OwnedTokens-Abrufen?

Ich versuche, mir mögliche Paging-Mechanismen auszudenken, indem ich das ERC721-Token unterklassifiziere, aber es scheint eine völlig neue ERC721-Implementierung zu erfordern.

Wir beabsichtigen auch, den Token-Besitz außerhalb der Kette zwischenzuspeichern, aber es wird Zeiten geben, in denen wir Besitz-Arrays mit der Kette synchronisieren müssen.

Könntest du den ERC721TokenVertrag verlinken, von dem du sprichst?
Link hinzugefügt, Zeppelin Solidity ist die Quelle, danke!
Das scheint ein bisschen nicht standardisiert und, wie Sie betont haben, in der Skalierbarkeit begrenzt. Der aktuelle ERC 721-Vorschlag verwendet tokenOfOwnerByIndexstattdessen das Abrufen von Tokens einzeln. Ich denke, eine Art Paginierung wäre noch besser.

Antworten (2)

Ich habe die Dinge für eine große Anzahl von Zehntausenden von Token getestet. Ich stellte fest, dass die aktuelle Implementierung des erc721 von Zeppelin Solidity keine schnelle Aufzählung zulässt, wenn die Token des Besitzers in die 1000er gehen

Da die Member-Mapping-Variablen des ERC721 alle privat sind, ist es nicht möglich, direkt auf ownTokens zuzugreifen:

mapping (address => uint256[]) private ownedTokens;

Wenn wir das also auf intern ändern, können wir direkt ändern:

mapping (address => uint256[]) internal ownedTokens;

Ich kann dann den ERC721 mit einem Enumerator unterklassen:

  function tokenOfOwnerByIndex(address _owner, uint256 _index) 
    external 
    view 
    returns (uint256 _tokenId) 
  {
    require(_index < balanceOf(_owner));
    return ownedTokens[_owner][_index];
  }

Dies ist viel schneller und kann für Paging-Zwecke über 80 Token in einer Sekunde durchlaufen.

Es hört sich so an, als ob die Crew von Zeppelin Solidity sich dessen bewusst ist und an der Behebung des Problems arbeitet: github.com/OpenZeppelin/zeppelin-solidity/pull/682

Dieses spezielle Problem, die Skalierbarkeit, wird im Standard behandelt. Wir haben eine Implementierung, die VIELE Token erfolgreich einsetzt und der nicht das Benzin ausgeht:

Wir haben Testnet einen Vertrag, XXXXERC721, bereitgestellt, der 340282366920938463463374607431768211456 verschiedene Taten (2^128) instanziiert und verfolgt. Das reicht aus, um jede IPV6-Adresse einem Ethereum-Kontoinhaber zuzuweisen oder den Besitz von Nanobots mit einer Größe von wenigen Mikrometern und einer Gesamtgröße von halb so groß wie die Erde zu verfolgen. Sie können es aus der Blockchain abfragen. Und jede Funktion braucht weniger Gas als das Abfragen des ENS.

Und ja, das ist ein Verweis auf XKCD 865.

Referenz: https://github.com/ethereum/EIPs/pull/841

haha danke! Referenz für XKCD-Referenz: explainxkcd.com/wiki/index.php/865:_Nanobots
ERC721 OwnedTokens-Array-Längenbeschränkungen für Besitzer mit Tausenden von Token
AntwortenHierDatenschutz-Bestimmungen1y, 0v