Der kostengünstigste Weg, um einen Airdrop von Token durchzuführen

Ich mache ein Projekt, bei dem ich einen Token erstelle und versuche, ihn so vielen Leuten wie möglich per Airdrop zu schicken . Die Herausforderung besteht darin, den kostengünstigsten Weg zu finden, dies zu tun.

Ich hatte zwei Möglichkeiten:

  1. Erstellen Sie einen Smart Contract vom Typ „Token Vault“, senden Sie Tokens an ihn und übergeben Sie eine Reihe von Adressen und Salden an eine Funktion.

  2. Erstellen Sie einfach vor der Bereitstellung eine neue Funktion in meinem Token-Code, die genehmigen () ähnlich ist, aber ein Array von Adressen als Eingabe hat. Und lassen Sie die Leute danach einfach transferFrom() ausführen.

Wie Sie sehen können, sind diese beiden Optionen ziemlich ähnlich, und mein Hauptanliegen ist, dass ich für beide eine Reihe von Adressen übergeben muss. Soweit ich weiß, kostet es mich 21000 Gas + 1000 SSTORE-Operationen (20000 Gas-ID _spender ist nicht in der Zuordnung enthalten), wenn ich ein Array von 1000 Adressen übergeben möchte, insgesamt 20021000 Gas (wenn es tatsächlich möglich ist, 1000 auf einmal zu übergeben und nicht in getrennten Chargen). Die Berechnung der Kosten für diesen Moment ergibt 0,02 ETH oder 16,297 $, aber das liegt nur daran, dass der Gaspreis bei 1 wei atm liegt.

Stellen Sie sich vor, ich führe eine erfolgreiche Airdrop-Kampagne für Tausende von Menschen durch und das Netzwerk wird überlastet, weil ein weiteres CryptoKitties uns wochenlang einen durchschnittlichen Gaspreis zwischen 20 und 30 Wei belässt. Ja, der Preis für die Bereitstellung eines solchen Vertrags wird auf etwa 0,5 ETH explodieren.

Es ist kein kommerzielles Projekt, daher kommt Crowdsale (was mich im Vergleich zu dem, was ich vorhabe, sehr wenig kosten würde) nicht in Frage. Das Hauptziel des Projekts ist es, normale, nicht technisch/kryptoversierte Menschen mit der Ethereum-Plattform vertraut zu machen und sie zum ersten Mal dazu zu bringen, einfache Dinge zu tun: wie eine Brieftasche zu erstellen, ETH zu kaufen, mit intelligenten Verträgen zu interagieren usw.

Sie fragen sich vielleicht, warum ich in diesem Fall kein minbares Token erstelle, das die Leute für sich selbst prägen können, was mich effektiv 0 eth kostet, nachdem ich meinen Token-Vertrag bereitgestellt habe? Nun, ich glaube, dass der Token, um viele Menschen zu erreichen, einen hypothetischen Wert haben sollte, sonst würde niemand den Kampf auf sich nehmen, auch nur eine Brieftasche einzurichten und sie mit ETH zu laden. Und wenn Token frei geprägt werden können, selbst wenn es eine Begrenzung der Token pro Adresse gibt, wird dies einige Leute nicht davon abhalten, sie zu missbrauchen, indem sie mehrere Konten erstellen und große Summen für sich selbst ansammeln. Mit anderen Worten, ich möchte die Möglichkeit haben, das Gesamtangebot zu regulieren, damit die Leute den Airdrop-Prozess nicht missbrauchen und den Token wertlos machen können (was es sowieso ist,

Ich glaube, dass es eine Möglichkeit geben sollte, dies ohne teure Arrays von Adressen zu tun. Da ich jedoch null bis gar keine Programmiererfahrung habe, ist es nicht so offensichtlich. Vielleicht gibt es eine Möglichkeit, einige eindeutige Codes zu verwenden, die ich an Personen verteilen kann, die sie eingeben müssen, um ihre Airdrop-Token freizuschalten? Aber ich muss es so machen, dass ich nicht eine Reihe solcher Codes übergeben muss, die im Vertrag festgehalten werden müssen. Und zum Beispiel erfüllen diese Codes eine mathematische Funktion, wären aber für irgendjemanden außer mir sehr schwer oder unmöglich zu generieren.

Ich würde mich über euren Input freuen Jungs! Vielen Dank fürs Lesen und Entschuldigung für einen so langen Beitrag!

TLDR;

Suche nach der besten und kostengünstigsten Möglichkeit, Token fair zu verteilen, ohne eine Reihe von Adressen an den Token-Vertrag übergeben zu müssen.

Antworten (3)

Diese Option erfordert also ein anständiges Setup, ist aber in der Tat die billigste Option. Sie könnten eine Art Zahlungskanal erstellen, indem Sie eine große Menge an Token an einen Smart Contract binden. Sie könnten den Smart Contract so einrichten, dass nur berechtigte Adressen einen Airdrop anfordern können. Um den Airdrop anzufordern, müssen sie eine von Ihnen unterschriebene Nachricht einreichen.

Dies wäre unglaublich günstig, da jeder Benutzer die Transaktionskosten für den Versand der Coins selbst tragen würde.

Beispiel (aktualisieren):

Jeder Benutzer erhält eine bestimmte Nachricht h, die eine Kombination aus \x19Ethereum Signed Message\n32+ ist keccak256('user-address', 'airdrop-value'), die Sie signiert haben, zusammen mit den Signaturteilen vrs. Wenn sie an Ihren Vertrag senden, um ihr Geld abzuheben, stellen sie die erforderlichen Signaturdaten (h, v, r, s) zusammen mit den Werten bereit, aus denen sich die Nachricht zusammensetzt h, damit sie die eindeutige Nachricht an sie überprüfen, aber auch überprüfen können dass es von Ihnen unterschrieben wurde.

Ich musste das kürzlich selbst herausfinden und habe ein schnelles Python-Programm erstellt, mit dem Daten signiert und die erforderlichen Teile extrahiert werden können:

https://github.com/postables/Postables-Payment-Channel/blob/develop/python/signer.py

Danke für deinen Kommentar! Ich glaube, dass Sie völlig Recht haben. Zum jetzigen Zeitpunkt kann ich diese Funktion nicht selbst implementieren. Aber ich werde mein Bestes tun, um es herauszufinden, und wenn ich das tue, werde ich diesen Thread aktualisieren.
Übrigens, da die Nachricht für jeden Benutzer eindeutig sein muss. Muss ich in diesem Fall diese Nachrichten nicht auch im Vertrag speichern, damit sie abgeglichen werden können?
Die Lösung, die ich in meinen Verträgen verwende, erfordert, dass der Benutzer die Nachrichteninhalte bereitstellt, damit die Nachricht rekonstruiert werden kann. Ich werde meine Antwort aktualisieren

Vielleicht wird es nützlich sein, Open Source zu verwenden https://github.com/bulktokensending/bulktokensending Die bereitgestellte Version ist hier http://bulktokensending.online

Niemand hat Merkle Air-Drops erwähnt , vielleicht weil sie scheinbar erschienen, nachdem diese Frage und die gewählte Antwort erschienen waren?

Wie auch immer, klingt für mich nach einer besseren Lösung: Anstatt alle Empfängeradressen im Smart Contract zu speichern, was an sich kostspielig ist und die Kette aufbläht, Sie

  • Veröffentlichen Sie diese irgendwo (wie IPFS)
  • Erstellen Sie mit diesen Adressen einen Merkle-Baum
  • Speichern Sie die Wurzel des Baums im Smart Contract
  • Geben Sie Kunden die Möglichkeit, den Smart Contract mit einem Merkle-Nachweis vorzulegen, der zeigt, dass ihre Adresse in der Liste steht