Wie handhabt man Ether-Einzahlungen wie Börsen?

Sie haben zusätzlich zu Ihrer Hauptfrage, wie mit Ether-Einzahlungen umzugehen ist, eine Reihe von Fragen gestellt.

Das Hauptproblem, mit dem Sie sich auseinandersetzen möchten, ist das Problem der doppelten Ausgaben. Wenn jemand auf Ihre Dapp-Börse einzahlt, wie stellen Sie sicher, dass die Gelder nicht doppelt ausgegeben werden, und wie gehen Sie mit Geldern um, die eingezahlt und dann aufgrund eines Forks effektiv nicht ausgegeben werden?

Die Antwort liegt in gewisser Weise bei Ihnen als DAPP Exchange-Entwickler – Sie entscheiden. Warum also nicht 24 Blöcke wählen oder, wie es eine Börse tut, 360 Blöcke? Je nachdem, was Ihnen das nötige Vertrauen gibt.

Mir ist klar, dass dies keine technische Antwort ist, aber es gibt ein funktionales Problem damit, hauptsächlich, dass der Benutzer, der einen Kauf- oder Verkaufsauftrag einreicht, zur gleichen Zeit warten muss, bis er abgeschlossen oder in das Auftragsbuch eingetragen wird. Sie müssen also Stabilität gegen Benutzerfreundlichkeit eintauschen.

Sie sollten sich auch darüber im Klaren sein, dass Sie aufgrund der Natur des Blockerstellungsprozesses Bestellungen nicht schnell oder auf die gleiche Weise wie bei einem zentralisierten Dienst bearbeiten können. Dies liegt daran, dass ein Knoten nicht alle Aufträge (d. h. Transaktionen) kennen kann, die irgendwo im Netzwerk platziert werden, und zwar in dem Moment, in dem er versucht, Aufträge zu verarbeiten, die er über das Netzwerk erhalten hat.

Auch dies ist ein wesentlicher Unterschied zu einem zentralisierten Dienst, und Sie sollten dies ebenfalls als Teil derselben Lösung betrachten.

Mir sind keine verfügbaren Bibliotheken bekannt, die Ihnen eine schnelle Antwort geben könnten, aber es scheint eine Reihe von Projekten zu geben.

Was ist die neueste Empfehlung für die Anzahl der Sendebestätigungen mit dem Homestead-Release?

Laut den Web3-APIs sind 12 Blöcke gut, um sicherzustellen, dass es keinen Fork gibt. Was TX-Bestätigungen betrifft ... Ich würde sagen, 5 ist immer noch der Defacto-Betrag, den Sie dort haben möchten. Das wird sich offensichtlich mit Serenity ändern, und ich bin mir nicht sicher, wie ich darauf antworten soll, angesichts der enormen Veränderungen, die Casper mit sich bringen wird. Folgen Sie dem Blog von Vitalik, damit Sie diese Dinge bei der Entwicklung im Hinterkopf behalten können.

Gibt es Bibliotheken oder Dienste, die Beispielimplementierungen bereitstellen?

hmmm ... Sie möchten wahrscheinlich mit Ereignissen und dieser Handhabung arbeiten ... nicht sicher über Ihren Sendebestätigungsbereich ... es scheint keine vorgefertigten Tools für diese Zwecke zu geben ... wahrscheinlich müssten Hacken Sie etwas in einem der Clients zusammen (ich würde empfehlen, Parity dafür zu verwenden, weil Sie etwas Schnelles wollen ... und Parity ist blitzschnell).

Was ist die grobe Pseudo-Code-Implementierung, um dies selbst zu handhaben?

etwas wie das

js:

var i = myEthereumEvents
myEthereumEvents.watchAllEvents() {
    if (eventHit)
         var boolean = contract.promisifiedCheckBalanceOfPeer()
         if (boolean)
              contract.exchangeTokenValue()
}

Jetzt müssen Sie wahrscheinlich Zinsen für einige von ihnen sammeln und eine Art Lastausgleich in Solidity erstellen ... das wird Ihrerseits einiges Nachdenken erfordern ... es gibt dort unzählige Beispiele für die Erstellung von Metacoins, würden Sie nur Müssen Sie es so einrichten, dass es die Token-Lieferung anderer Ketten nachahmt? Dies könnte helfen, die erforderliche Menge zu sichern ... andererseits sprechen Sie möglicherweise von etwas ganz anderem und möchten etwas rein von einer Austauschseite ... Eine Sache, die ich auf jeden Fall empfehlen würde, ist, die schnelle Synchronisierung auszuschalten und die Menge zu überwachen der eingehenden Transaktionen und passen sich entsprechend an Ihre Algorithmen an.

Lassen Sie mich wissen, ob dies Ihre Frage beantwortet.