¿Cuál es la mejor práctica para un contrato inteligente de pago de impuestos?

Me acaban de presentar los contratos inteligentes de Ethereum y tengo un proyecto relacionado con la facultad que implica su uso.

La idea es crear una DApp que permita a los clientes (personas) pagar impuestos (en Ethereum) a una institución pública.

Mi problema es que no puedo decidir qué versión de alto nivel del contrato inteligente sigue las mejores prácticas:

  1. Contrato inteligente global

    • la institución lo crea
    • la institución le agrega clientes
    • tiene la dirección de la institución
    • tiene una lista de clientes (identificadores únicos)
    • comprueba las condiciones de pago (por ejemplo, cantidad pagada == impuestos, el pagador está en la lista de clientes, el receptor es la institución)

  2. Contrato inteligente por cliente

    • la institución lo crea en base a la información del cliente
    • tiene la dirección de la institución
    • tiene un cliente (identificador único)
    • comprueba las condiciones de pago (por ejemplo, cantidad pagada == impuestos, el pagador es el cliente, el receptor es la institución)

  3. Contrato inteligente genérico

    • la institución lo crea
    • comprueba las condiciones de pago (por ejemplo, cantidad pagada == impuestos)

¿Son viables las ideas anteriores en el contexto de Ethereum - Smart Contracts?

En caso afirmativo, ¿cuál es el correcto?

Si no, ¿cómo debería ser el contrato inteligente adecuado según mi idea?

Esta no es realmente una respuesta, pero considere usar un oráculo como oraclize.it para obtener tasas de impuestos, etc. a menos que quiera hacerlo del lado del cliente: P
Gracias por la alternativa pero tengo que implementarlo yo mismo :)
Me refiero a que las tasas de impuestos cambian, parece un poco tonto, no confiar en algún intermediario confiable para estos datos.

Respuestas (3)

Es un poco difícil saber qué tan completo es el enfoque que necesita. Pero déjame ofrecerte una alternativa:

  • Institución crea contrato
  • La institución agrega una lista de objetos personales al contrato
  • Un objeto persona contiene los siguientes datos:

1) Dirección de Ethereum (cada persona debe tener una dirección de Ethereum vinculada a él personalmente)

2) Importe del impuesto a pagar (en éteres)

Después de eso, el contrato asegura que las personas paguen los impuestos de alguna manera. Después de la fecha X, la institución emite una transacción del contrato a una makeSureTaxesArePaidfunción que se asegura de que se hayan pagado todos los impuestos. Si no, algo sucede. Todos los impuestos pagados al contrato pueden ser retirados posteriormente del contrato por su propietario (creador).

Así que esto es bastante parecido a su primera idea original.

Esto tiene sentido y actúa como un segundo punto de datos sobre qué usar. Supongo que el segundo es demasiado caro después de todo. ¿Qué pasa con la tercera solución, la genérica creada por tipo de impuesto? ¿Es una mala práctica no almacenar el estado de los clientes en el contrato y ponerlo en otro lugar? (es decir, del lado del servidor de la institución)
En general, no puede almacenar muchos datos en Ethereum, simplemente se vuelve demasiado costoso. Así que almacene lo menos posible.

Desde mi punto de vista no tengo dudas: la primera solución es la mejor práctica.

Asegura que todas las acciones necesarias, distintas al pago de impuestos, estén a cargo de la institución, la cual se beneficiará del dinero, es decir, no cobrar a quien paga impuestos por trabajo o gasto extra; además es naturalmente coordinado (por el contrario el segundo requiere coordinaciones entre la institución y todos los contribuyentes); además, no es necesario clonar N contratos diferentes solo para la dirección del cliente. Recuerde que paga gas por cada contrato individual implementado y por cualquier byte ocupado en blockchain: ¡demasiados duplicados en la solución 2!

La tercera solución es verdaderamente pobre y no es más barata.

La solución propuesta por Lauri puede ser útil si algún cliente tiene una cantidad diferente de impuestos a pagar, pero su pregunta no nos da información al respecto.

En resumen: ¡utilice la primera solución!

¡Espero que esto ayude!

Estoy de acuerdo en que la segunda solución sería demasiado costosa para almacenar y administrar dentro de la cadena de bloques. ¿Por qué la tercera solución es verdaderamente pobre y no más barata? Un contrato de ese tipo se crearía solo por tipo de impuesto, por lo que los clientes que tienen que pagar su tipo de impuesto llamarían funciones sobre él. Sin embargo, el problema con esto es que el estado debe almacenarse en otro lugar (en el lado de la institución).
Sobre los impuestos, realmente no importa si las cantidades son diferentes. La sugerencia de Lauri se puede simplificar fácilmente para admitir solo una cantidad.
La tercera solución es deficiente porque no contiene toda la información necesaria para proceder y, luego, requiere trabajo adicional fuera de blockchain para poder funcionar. Además, esa información no se registrará en la cadena de bloques y, por lo tanto, no será confiable en el futuro.

OP no dijo si esto es impuesto sobre las ventas, impuesto sobre la renta u otra cosa, por lo que no tenemos información sobre cómo se calcula. Voy con un formulario de impuestos/esquema de remesas de impuestos, ya que parece lo más probable.

En la superficie, esto suena como una aplicación de "solicitud de pago", y poco más. Si la confidencialidad es una preocupación, se requieren esfuerzos diligentes para protegerla y uno debe abstenerse de colocar información innecesaria en la cadena de bloques.

Me inclinaría por la opción 1. Para mayor claridad:

la institución lo crea

  • la institución le agrega direcciones de clientes
  • tiene es la dirección de la institución contrato
  • tiene una lista de clientes ( identificadores únicos de direcciones )
  • comprueba las condiciones de pago (por ejemplo, cantidad pagada == impuestos, el pagador está en la lista de clientes , el receptor es la institución ) Desde la perspectiva del contrato, el receptor no puede ser nadie más que él mismo.

y ...

  • La institución determina los impuestos adeudados e informa el contrato. Esto puede ser un proceso fuera de la cadena, con el resultado neto comprometido con el contrato.
  • Opcionalmente, una versión del documento autorizado fuera de la cadena que respalde el resultado neto del contrato. Algo así como (pseudo) hash (contribuyente, año/período, número de revisión del documento).
  • La institución tiene una forma de retirar los ingresos fiscales recaudados. El reenvío es posible, pero generalmente no se recomienda.
  • Control de acceso (quién/qué puede retirar, modificar obligaciones del contribuyente) a través de listas blancas de direcciones.

Las direcciones y montos de las obligaciones y recibos estarán abiertos al examen de todos y eso podría no ser deseable. Considere investigar métodos de ofuscación para respaldar las garantías sobre la confidencialidad, incluido el análisis de metadatos.

Espero eso ayude.

¿Cuál es la mejor práctica para un contrato inteligente de pago de impuestos?
RespuestasAquíPolítica de privacidad1y, 0v