Was ist die Best Practice für einen Smart Contract für Steuerzahlungen?

Ich habe gerade Ethereum Smart Contracts kennengelernt und habe ein fakultätsbezogenes Projekt, das deren Verwendung impliziert.

Die Idee ist, eine DApp zu erstellen, die es Kunden (Personen) ermöglicht, Steuern (in Ethereum) an eine öffentliche Institution zu zahlen.

Mein Problem ist, dass ich nicht entscheiden kann, welche High-Level-Version von Smart Contract den Best Practices folgt:

  1. Globaler intelligenter Vertrag

    • Institution schafft es
    • Institution fügt Kunden hinzu
    • hat die Anschrift der Einrichtung
    • hat eine Liste von Kunden (eindeutige Kennungen)
    • prüft die Zahlungsbedingungen (z. B. gezahlter Betrag == Steuer, der Zahler steht in der Kundenliste, der Empfänger ist die Institution)

  2. Smart Contract pro Kunde

    • Institution erstellt es basierend auf Kundeninformationen
    • hält die Adresse der Institution
    • hält einen Client (eindeutige Kennung)
    • prüft die Zahlungsbedingungen (z. B. gezahlter Betrag == Steuer, Zahler ist Auftraggeber, Empfänger ist Institution)

  3. Generischer Smart Contract

    • Institution schafft es
    • prüft die Zahlungsbedingungen (z. B. gezahlter Betrag == Steuer)

Sind die oben genannten Ideen im Zusammenhang mit Ethereum – Smart Contracts umsetzbar?

Wenn ja, welches ist das Richtige?

Wenn nein, wie soll der passende Smart Contract basierend auf meiner Idee aussehen?

Dies ist nicht wirklich eine Antwort, aber ziehen Sie in Betracht, ein Orakel wie oraclize.it zu verwenden , um Steuersätze usw. zu ermitteln ... es sei denn, Sie möchten dies clientseitig tun: P
Danke für die Alternative, aber die muss ich selbst umsetzen :)
Ich meine, Steuersätze ändern sich, es scheint irgendwie dumm, sich nicht auf einen vertrauenswürdigen Vermittler für diese Daten zu verlassen.

Antworten (3)

Es ist ein bisschen schwierig zu wissen, wie gründlich man vorgehen muss. Aber lassen Sie mich Ihnen eine Alternative anbieten:

  • Institution erstellt Vertrag
  • Die Institution fügt dem Vertrag eine Liste von Personenobjekten hinzu
  • Ein Personenobjekt enthält die folgenden Daten:

1) Ethereum-Adresse (jede Person muss eine persönliche Ethereum-Adresse haben)

2) Steuerbetrag, der gezahlt werden muss (in Ether)

Danach stellt der Vertrag sicher, dass die Leute die Steuern auf irgendeine Weise zahlen. Nach dem Datum X gibt die Institution eine Transaktion zum Vertrag an eine makeSureTaxesArePaidFunktion aus, die sicherstellt, dass alle Steuern bezahlt wurden. Wenn nicht, passiert etwas. Alle an den Vertrag gezahlten Steuern können später von seinem Eigentümer (Ersteller) aus dem Vertrag zurückgezogen werden.

Das kommt Ihrer ursprünglichen ersten Idee also ziemlich nahe.

Dies ist sinnvoll und dient als zweiter Datenpunkt für die Verwendung. Ich nehme an, der 2. ist doch einfach zu teuer. Was ist mit der 3. Lösung, der generischen, die pro Steuerart erstellt wird? Ist es eine schlechte Praxis, den Status der Kunden nicht im Vertrag zu speichern und an einer anderen Stelle abzulegen? (dh serverseitig der Institution)
Generell kann man auf Ethereum nicht viele Daten speichern – es wird einfach zu teuer. Also so wenig wie möglich lagern.

Aus meiner Sicht habe ich keine Zweifel: Die erste Lösung ist die beste Praxis.

Es stellt sicher, dass alle erforderlichen Maßnahmen, abgesehen von der Zahlung von Steuern, der Institution obliegen, die von dem Geld profitiert, dh es wird nicht erhoben, wer Steuern für Mehrarbeit oder Mehrausgaben zahlt; außerdem ist es natürlich koordiniert (im Gegensatz dazu erfordert das zweite eine Koordination zwischen der Institution und allen Steuerzahlern); außerdem ist es nicht erforderlich, N Verträge zu klonen, die sich nur für die Client-Adresse unterscheiden. Denken Sie daran, dass Sie Gas für jeden einzelnen bereitgestellten Vertrag und für jedes in der Blockchain belegte Byte bezahlen: zu viele Duplikate in Lösung 2!

Die dritte Lösung ist wirklich schlecht und nicht billiger.

Die von Lauri vorgeschlagene Lösung kann nützlich sein, wenn ein Kunde einen anderen Steuerbetrag zu zahlen hat, Ihre Frage uns jedoch keine Informationen zu dieser Angelegenheit gibt.

Kurz gesagt: erste Lösung verwenden!

Hoffe das hilft!

Ich stimme zu, dass die zweite Lösung zu teuer wäre, um sie innerhalb der Blockchain zu speichern und zu verwalten. Warum ist die 3. Lösung wirklich schlecht und nicht billiger? Ein solcher Vertrag würde nur pro Steuerart erstellt, also würden die Kunden, die seine Steuerart zahlen müssen, Funktionen darauf aufrufen. Das Problem dabei ist jedoch, dass der Status an anderer Stelle (auf der Seite der Institution) gespeichert werden muss.
Bei den Steuern spielt es keine Rolle, ob die Beträge unterschiedlich sind. Lauris Vorschlag kann leicht vereinfacht werden, um nur einen einzigen Betrag zu unterstützen.
Die dritte Lösung ist schlecht, weil sie nicht alle Informationen enthält, die zum Fortfahren erforderlich sind, und dann zusätzliche Arbeit außerhalb der Blockchain erfordert, um zu funktionieren. Darüber hinaus dürfen diese Informationen nicht in der Blockchain gespeichert werden und sind dann in Zukunft nicht vertrauenswürdig.

OP hat nicht gesagt, ob dies Umsatzsteuer, Einkommenssteuer oder etwas anderes ist, daher haben wir keine Informationen darüber, wie sie berechnet wird. Ich gehe mit einem Steuerformular / Steuerüberweisungssystem, da es am wahrscheinlichsten erscheint.

Oberflächlich betrachtet klingt das nach einer „Zahlungsanfrage“-App und wenig mehr. Wenn die Vertraulichkeit ein Problem darstellt, müssen sorgfältige Anstrengungen unternommen werden, um sie zu schützen, und man sollte davon absehen, unnötige Informationen in die Blockchain aufzunehmen.

Ich würde zu Option 1 tendieren. Zur Verdeutlichung:

Institution schafft es

  • Institution fügt Kundenadressen hinzu
  • has ist die Adresse des Institutionsvertrags
  • hat eine Liste von Kunden ( eindeutige Identifikatoren Adressen )
  • prüft die Zahlungsbedingungen (z. B. gezahlter Betrag == Steuer, der Zahler steht in der Kundenliste , der Empfänger ist die Institution ) Empfänger kann aus Vertragssicht nur er selbst sein.

Und ...

  • Die Institution ermittelt die geschuldeten Steuern und teilt den Vertrag mit. Dies kann ein Off-Chain-Prozess sein, bei dem das Nettoergebnis vertraglich vereinbart wird.
  • Optional eine Version des maßgeblichen Off-Chain-Dokuments, das das Nettoergebnis im Vertrag unterstützt. So etwas wie (Pseudo-)Hash (Steuerzahler, Jahr/Zeitraum, Revisionsnummer des Dokuments).
  • Die Institution hat eine Möglichkeit, die erhobenen Steuereinnahmen abzuheben. Eine Weiterleitung ist möglich, wird aber nicht generell empfohlen.
  • Zugriffskontrolle (wer/was kann sich zurückziehen, Steuerpflichten ändern) durch Adress-Whitelists.

Die Adressen und Beträge von Verpflichtungen und Quittungen sind für jedermann einsehbar, was möglicherweise nicht wünschenswert ist. Erwägen Sie die Untersuchung von Verschleierungsmethoden, um die Zusicherung der Vertraulichkeit zu unterstützen, einschließlich Metadatenanalyse.

Ich hoffe es hilft.

Was ist die Best Practice für einen Smart Contract für Steuerzahlungen?
AntwortenHierDatenschutz-Bestimmungen1y, 0v