Как лучше всего использовать смарт-контракт налоговых платежей?

Я только что познакомился со смарт-контрактами Ethereum, и у меня есть проект, связанный с преподавателями, который подразумевает их использование.

Идея состоит в том, чтобы создать DApp, который позволяет клиентам (лицам) платить налоги (в Ethereum) государственному учреждению.

Моя проблема в том, что я не могу решить, какая высокоуровневая версия смарт-контракта соответствует лучшим практикам:

  1. Глобальный смарт-контракт

    • учреждение создает его
    • учреждение добавляет в него клиентов
    • имеет адрес учреждения
    • имеет список клиентов (уникальные идентификаторы)
    • проверяет условия платежа (например, уплаченная сумма == налог, плательщик находится в списке клиентов, получатель - учреждение)

  2. Смарт-контракт на клиента

    • учреждение создает его на основе информации о клиенте
    • содержит адрес учреждения
    • содержит клиента (уникальный идентификатор)
    • проверяет условия платежа (например, уплаченная сумма == налог, плательщиком является клиент, получателем является учреждение)

  3. Общий смарт-контракт

    • учреждение создает его
    • проверяет условия оплаты (например, уплаченная сумма == налог)

Жизнеспособны ли приведенные выше идеи в контексте Ethereum — смарт-контракты?

Если да, то какой из них правильный?

Если нет, то как должен выглядеть правильный смарт-контракт, исходя из моей идеи?

На самом деле это не ответ, но рассмотрите возможность использования оракула, такого как oraclize.it, для получения налоговых ставок и т. Д. ... если вы не хотите делать это на стороне клиента: P
Спасибо за вариант, но я должен реализовать его сам :)
Я имею в виду изменение налоговых ставок, это выглядит довольно глупо, не полагаться на какого-то доверенного посредника для получения этих данных.

Ответы (3)

Немного сложно понять, насколько тщательный подход вам нужен. Но позвольте предложить вам один вариант:

  • Учреждение заключает контракт
  • Учреждение добавляет в контракт список объектов- лиц
  • Объект person содержит следующие данные:

1) Адрес Ethereum (каждый человек должен иметь адрес Ethereum, привязанный к нему лично)

2) Сумма налога, которую необходимо заплатить (в эфирах)

После этого контракт гарантирует, что люди каким-то образом платят налоги. После даты X учреждение выдает транзакцию по контракту функции makeSureTaxesArePaid, которая следит за тем, чтобы все налоги были уплачены. Если нет, что-то происходит. Все налоги, уплаченные по договору, могут быть впоследствии изъяты из договора его владельцем (создателем).

Так что это довольно близко к вашей первоначальной первой идее.

Это имеет смысл и действует как вторая точка данных о том, что использовать. Я предполагаю, что 2-й все-таки слишком дорогой. А как насчет третьего решения, общего, созданного для каждого типа налога? Плохо ли не хранить состояние клиентов в контракте и помещать его куда-то еще? (т.е. на стороне сервера учреждения)
В общем, вы не можете хранить много данных на Ethereum — он просто становится слишком дорогим. Так что храните как можно меньше.

С моей точки зрения, у меня нет сомнений: первое решение — лучшая практика.

Он гарантирует, что все необходимые действия, отличные от уплаты налогов, возлагаются на учреждение, которое извлекает выгоду из денег, т. е. не взимает с тех, кто платит налоги, дополнительную работу или дополнительные расходы; кроме того, он, естественно, согласован (наоборот, второй требует согласования между учреждением и всеми налогоплательщиками); кроме того, не требуется клонировать N контрактов, отличающихся только адресом клиента. Помните, что вы платите газ за каждый развернутый контракт и за каждый байт, занятый в блокчейне: слишком много дубликатов в решении 2!

Третье решение действительно плохое и не дешевле.

Решение, предложенное Лаури, может быть полезно, если у какого-либо клиента есть другая сумма налогов к уплате, но ваш вопрос не дает нам информации по этому вопросу.

Короче говоря: используйте первое решение!

Надеюсь это поможет!

Я согласен, что второе решение было бы слишком дорогим для хранения и управления внутри блокчейна. Почему 3-е решение действительно плохое и не дешевле? Контракт такого типа будет создан только для каждого типа налога, поэтому клиенты, которые должны платить этот вид налога, будут вызывать функции для него. Однако проблема заключается в том, что состояние должно храниться где-то еще (на стороне учреждения).
Что касается налогов, это не имеет большого значения, если суммы разные. Предложение Лаури можно легко упростить, чтобы поддерживать только одну сумму.
Третье решение плохое, потому что оно не содержит всей информации, необходимой для продолжения, а затем требует дополнительной работы вне блокчейна для работы. Кроме того, эта информация не должна записываться в блокчейн и, следовательно, в будущем ей нельзя будет доверять.

ОП не сказал, является ли это налогом с продаж, подоходным налогом или чем-то еще, поэтому у нас нет информации о том, как он рассчитывается. Я собираюсь использовать налоговую форму/схему перечисления налогов, так как это кажется наиболее вероятным.

На первый взгляд это звучит как приложение «запрос платежа» и не более того. Если конфиденциальность вызывает беспокойство, то для ее защиты требуются усердные усилия, и следует воздерживаться от размещения ненужной информации в блокчейне.

Я бы склонялся к варианту 1. Для наглядности:

учреждение создает его

  • учреждение добавляет в него адреса клиентов
  • имеет адрес договора учреждения
  • имеет список клиентов ( уникальные идентификаторы адресов )
  • проверяет условия платежа (например, уплаченная сумма == налог, плательщик находится в списке клиентов , получатель - учреждение ) С точки зрения контракта, получатель не может быть кем-либо, кроме себя.

и ...

  • Учреждение определяет причитающиеся налоги и информирует контракт. Это может быть офчейн-процесс, при котором конечный результат фиксируется в контракте.
  • Необязательно, версия авторитетного документа вне сети, который поддерживает чистый результат в контракте. Что-то вроде (псевдо) хеша (налогоплательщик, год/период, номер редакции документа).
  • У учреждения есть способ вывести собранные налоговые поступления. Пересылка возможна, но обычно не рекомендуется.
  • Контроль доступа (кто/что может снять, изменить обязательства налогоплательщика) через белые списки адресов.

Адреса и суммы обязательств и квитанций будут открыты для просмотра всеми, что может быть нежелательно. Рассмотрите возможность изучения методов обфускации для поддержки гарантий конфиденциальности, включая анализ метаданных.

Надеюсь, поможет.

Как лучше всего использовать смарт-контракт налоговых платежей?
СпросиСетьПолитика конфиденциальности1y, 0v