0

I have just been introduced to Ethereum Smart Contracts and I have a faculty-related project that implies the usage of them.

The idea is to create a DApp which allows clients (persons) pay taxes (in Ethereum) to a public institution.

My problem is that I cannot decide which high-level version of smart contract follows the best practices:

  1. Global Smart Contract

    • institution creates it
    • institution adds clients to it
    • has the address of institution
    • has a list of clients (unique identifiers)
    • checks the payment conditions (e.g. amount paid == tax, the payer is in the list of clients, the receiver is the institution)
  2. Smart Contract per client

    • institution creates it based on client information
    • holds the address of institution
    • holds a client (unique identifier)
    • checks the payment conditions (e.g. amount paid == tax, the payer is the client, the receiver is the institution)
  3. Generic Smart Contract

    • institution creates it
    • checks the payment conditions (e.g. amount paid == tax)

Are the above ideas viable in the Ethereum - Smart Contracts context?

If yes, which one is the right one?

If not, how should the right Smart Contract look like based on my idea?

bumped to the homepage by Community 14 hours ago

This question has answers that may be good or bad; the system has marked it active so that they can be reviewed.

  • This is not really an answer, but consider using an oracle such as oraclize.it for grabbing tax rates, etc ... unless you want to do client-side :P – GrandFleet Nov 7 '18 at 0:08
  • Thanks for the alternative but I have to implement it myself :) – xSkyripper Nov 7 '18 at 7:28
  • I mean tax rates change, it seems kinda foolish, not to rely on some trusted intermediary for this data. – GrandFleet Nov 7 '18 at 18:22
0

It's a bit difficult to know how thorough an approach you need. But let me offer you one alternative:

  • Institution creates contract
  • Institution adds a list of person objects to the contract
  • A person object contains the following data:

1) Ethereum address (each person has to have an Ethereum address tied to him personally)

2) Amount of tax that needs to be paid (in Ethers)

After that the contract makes sure people pay the taxes in some fashion. After date X institution issues a transaction to the contract to a makeSureTaxesArePaid function which makes sure all taxes have been paid. If not, something happens. All taxes paid to the contract can be later withdrawn from the contract by its owner (creator).

So this is pretty close to your original first idea.

  • This makes sense and acts as a 2nd datapoint on what to use. I assume the 2nd is just too expensive after all. What about the 3rd solution, the generic one created per tax type? Is it a bad practice not to store the state of the clients on the contract and put it somewhere else? (i.e. server-side of the institution) – xSkyripper Nov 7 '18 at 7:31
  • In general you can't store much data on Ethereum - it simply gets too expensive. So store as little as possible. – Lauri Peltonen Nov 7 '18 at 22:51
0

From my point of view I have no doubts: first solution is the best practice.

It ensures that all the action needed, different from paying taxes, are in charge to the institution, which will benefits from money, I.e. do not charge who pays taxes of extra-work or extra-expenditure; furthermore it is naturally coordinated (on the contrary the second one require coordinations between institution and all of the tax payers); furthermore do not require to clone N contracts different for the client address only. Remember that you pay gas for each single contract deployed and for any byte occupied in blockchain: too much duplicates in solution 2!

Third solution is truly poor and it is not cheaper.

The solution proposed by Lauri can be useful if any client has a different amount of taxes to pay, but your question do not give us information on the matter.

In short: use first solution!

Hope this helps!

  • I agree that the 2nd solution would be too expensive to store and manage inside the blockchain. Why is the 3rd solution truly poor and not cheaper? A contract of that kind would be created only per tax type thus the clients that have to pay its kind of tax would call functions on it. The problem with it though is that the state must be stored somewhere else (on the institution side). – xSkyripper Nov 7 '18 at 7:21
  • About the taxes, it doesn't really matter if the amounts are different. Lauri's suggestion can be easily simplified to support only a single amount. – xSkyripper Nov 7 '18 at 7:29
  • The third solution is poor because it does not contain all the information needed to proceed and, then, require extra work off-blockchain in order to work. Furthermore that information shall be not recorded in the blockchain and, then, shall be not trustable in the future. – Rick Park Nov 7 '18 at 8:10
0

OP didn't say if this is sales tax, income tax, or something else so we have no information about how it is calculated. I'm going with a tax form/tax remittance scheme as it seems the most likely.

On the surface, this sounds like a "request payment" app, and little more. If confidentiality is a concern, then it takes diligent efforts to protect it and one should refrain from putting unnecessary information on the blockchain.

I would incline to option 1. For clarity:

institution creates it

  • institution adds client addresses to it
  • has is the address of institution contract
  • has a list of clients (unique identifiers addresses)
  • checks the payment conditions (e.g. amount paid == tax, the payer is in the list of clients, the receiver is the institution) From the contract's perspective, the receiver can't be anyone other than itself.

and ...

  • The institution determines taxes owed and informs the contract. This can be an off-chain process, with the net result committed to the contract.
  • Optionally, a version of the authoratative off-chain document that supports the net result in the contract. Something like (pseudo) hash(taxpayer, year/period, document revision number).
  • The institution has a way to withdraw tax revenue collected. Forwarding is possible, but not generally recommended.
  • Access control (who/what can withdraw, alter taxpayer obligations) through address whitelists.

The addresses and amounts of obligations and receipts will be open to examination by everyone and that might not be desirable. Consider investigating methods of obfuscation to support assurances about confidentiality including metadata analysis.

Hope it helps.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.