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?

  • 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

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.