Alle msg.sender.balance zum Vertrag übertragen, ohne dass der Benutzer den msg.value eingeben muss?

Gibt es eine Möglichkeit, das gesamte user.balance auf den Vertrag oder die externe Zahlungsadresse zu übertragen, ohne dass der Benutzer den msg.value eingeben muss?

Die intuitivste Version, die ich hatte, sieht auf Solidity 0.5.0 ein bisschen so aus:

address(this).transfer(msg.sender.balance)

Es scheint jedoch, dass die Vertragsadresse von Natur aus nicht zahlbar ist, also habe ich versucht, sie zuerst in eine zahlbare Adresse umzuwandeln:

address payable payableContract = address(uint160(address(this)))

Aber es scheint auch nicht zu funktionieren. Jemand schlug mir vor, mich bei Contract Factory umzusehen, was das Problem lösen könnte. Was wäre der beste Weg, um es zu umgehen, um das gleiche Ergebnis zu erzielen?

Ein Vertrag kann den Ether eines Benutzers nicht erzwingen.
@smarx Gibt es eine Möglichkeit für den Benutzer, die Transaktion vorab zu autorisieren?
Die einzige Möglichkeit, das Guthaben eines externen Kontos zu übertragen, besteht darin, dass dieses Konto eine Transaktion sendet, die diesen Ether abführt.
@smart Wie ein Treuhandvertrag?
Reden Sie von Eth-Balance oder ERC20-Balance? Ich werde Ihnen zeigen, was Sie tun _können_, aber die Konzentration auf das eine oder andere wird es vereinfachen.
@RobHitchens-B9lab Ideal für beide, aber das Übertragen von Äther ist wichtiger für das, was ich gerade baue.

Antworten (1)

Sie müssen den Fluss der Dinge umkehren, sonst ergibt das keinen Sinn.

Es gibt keine Möglichkeit, einen Vertrag zu codieren, um Geld von einer Benutzer-Brieftasche zu überweisen. Nicht alle, nicht einige, nicht alle.

address(this).transfer(msg.sender.balance)

Das heißt, das Ziel ( to) ist address(this)und der Betrag ist der msg.senderSaldo von . from: addressist implizit address(this) , weil nichts anderes möglich ist . Daher fromwird in der Syntax nicht erwähnt.

Was Sie eigentlich möchten, ist, dass der Benutzer eine Transaktion unterzeichnet, die sein Geld an Ihren Vertrag sendet. Ich weiß nicht, warum es ihr gesamtes Gleichgewicht sein muss, und das klingt für mich wie ein weiterer Design-Fehltritt, aber hier ist, wie Sie es tun würden.

Es ist ein Front-End-Anliegen. Nochmals zur Betonung, denn nur der Benutzer kann die Überweisung seiner eigenen Gelder autorisieren. Auf der Vertragsseite können Sie ihn nur empfangen, die Transaktion validieren und möglicherweise ablehnen, wenn etwas nicht stimmt.

function depositFunds() public payable {
  // carry on
  // msg.value and msg.sender inform about who and how much
}

Am Frontend würden Sie Web3 oder eine ähnliche Bibliothek verwenden, um dem Benutzer zu helfen, eine gültige Transaktion mit amount: as much as possible, to: your contract, {gas: amount, gasPrice: bid}.

Der Benutzer muss für Benzin bezahlen, und dies verringert die Höhe der verfügbaren Mittel, die Sie an Ihren Vertrag senden können. Das müssen Sie berücksichtigen. Ihr Frontend muss Folgendes herausfinden:

  • Gasschätzung für die Transaktion
  • gasPrice (Verbrauchte Etherkosten = Gasschätzung * gasPrice)
  • Zum Senden verfügbares Guthaben (Guthaben des Benutzers - verbrauchte Kosten), sodass der Benutzer genau 0 verbleibendes Guthaben hat.

Wenn der Browser (oder Server) die Berechnung durchführt, wird dem Benutzer die Option angeboten, eine Transaktion zu unterzeichnen, indem x Betrag gesendet und y für Gas geboten wird, mit einer Gasschätzung von z, was ihm einen Endsaldo von 0.

Es ist mir unklar, warum jemand solchen Bedingungen zustimmen würde.

Ich hoffe es hilft.

Hey Rob, schätze wirklich deine Mühe und Zeit, diese Frage zu beantworten. Ich genieße Ihre Nächstenliebe und Details in der Antwort. Wir wollen etwas bauen, das im Wesentlichen erfordert, dass Alice eine ausstehende Transaktion vorautorisiert, die ihr gesamtes Guthaben zu einem späteren Zeitpunkt an Bob sendet. Daher besteht eine der größten Designherausforderungen darin, dass wir nicht wissen, wie diese zukünftige msg.balance aussehen wird, wenn bestimmte Bedingungen erfüllt sind.
Der einfachste Ansatz besteht darin, Alice dazu zu bringen, einige Gelder in einen Vertrag zu investieren, der nur an Bob freigegeben wird. Bob würde sehen können, dass die Gelder für ihn gesperrt sind. Vieles hängt von dem tatsächlichen Anwendungsfall ab, den Sie im Sinn haben.
Gibt es andere Ansätze, die es kreativ umgehen können?
Wie gefragt, nichts Offensichtliches, aber die Art und Weise, wie Sie "vollständiges Guthaben senden" beschreiben, erscheint mir nicht vernünftig. Ich denke, Sie könnten einem Anwendungsfall versteckte Annahmen auferlegen, die auf andere Weise angegangen werden sollten. Wenn Sie mein Klient wären, würde ich Sie fragen, was Alice und Bob wissen und tun müssen, und so lange fragen, bis Sie es erklären, ohne mir zu sagen, wie es Ihrer Meinung nach codiert werden sollte.
Ich könnte ELIF sagen, erkläre es, als wäre ich ein Endbenutzer, erkläre es, damit meine Mutter es verstehen kann.
Ah. Eine Möglichkeit, dies anzugehen, ist ein Wallet-Vertrag (nicht EOA). Verschiedene Vertragsparteien haben unterschiedliche Privilegien. Der übliche Eigentümer kann ein einzelner Unterzeichner sein, der die üblichen Aufgaben erledigen kann. Ein Quorum von Treuhändern könnte möglicherweise über eine Entscheidung wie eine Beschlagnahme entscheiden. Es ist kein Vertrag, der versucht, der Brieftasche unmögliche Dinge anzutun. Es ist eine Brieftasche, die als Vertrag implementiert ist. Eine andere Möglichkeit, dies anzugehen, besteht darin, den privaten Schlüssel des Eigentümers mit Löschcodierung zu versehen, damit etwa 2/3-Fragmente ihn wieder zusammensetzen können. Vielen Dank, dass Sie meine Antwort akzeptiert haben, wenn Sie sie nützlich finden.
Wie verwenden wir eine Brieftasche, die als Kontakt implementiert ist? Übrigens gefallen mir deine Vorschläge
Wir werden dafür bestraft, dass wir zu gesprächig sind. Es wäre eine gute neue Frage. Im Wesentlichen machen Sie einen Vertrag, der Befehle weiterleitet, die der Vertragsinhaber sendet. Sie könnten Multisig-Wallets nach einigen Ideen durchsuchen. Es hätte möglicherweise einen "Eigentümer" und eine Reihe von Delegierten, die abstimmen können, um die Kontrolle über zu übernehmen transferOwnership(). Natürlich müssen viele Details durchdacht werden, sodass alles im Voraus vereinbart wird. Der Eigentümer müsste die Delegierten von Zeit zu Zeit wechseln.
Danke für alle bisherigen Ratschläge. Suche seit einer Stunde nach Multi-Sig-Wallets. Die Ethereum-Community braucht definitiv mehr Leute wie dich. Du bist der Mann, Rob!
Alle msg.sender.balance zum Vertrag übertragen, ohne dass der Benutzer den msg.value eingeben muss?
AntwortenHierDatenschutz-Bestimmungen1y, 0v