Optimise the Smart Contract in the backend to reduce gas fees. about decentralized-expense-tracker HOT 10 CLOSED

Looking at the issue I believe I can contribute significantly, can you please assign me this issue.

from decentralized-expense-tracker.

Hey, @Arpaninformationtech @avalsonigara15 thanks for showing your interest.

Can you please explain what exactly you want to do? Like how do you plan to reduce the gas fees?

from decentralized-expense-tracker.

@J0SAL I wold optimize the smart contract in the following ways:
1.Use bytes32 instead of string storage for transaction IDs. Because fixed-size byte arrays are less expensive to store and manipulate than dynamic strings, this improvement will cut gas expenditures.

2.Use an array to store transaction IDs instead of a mapping: Instead of using a mapping to store transactions, use an array to store transaction IDs. This update eliminates the requirement for the "all_ids" mapping, lowering storage and gas costs.

3.Use uint32 instead of enum for transaction type: Because there are only two transaction kinds, use uint32 instead of enum. Because uint32 requires less data than enum types, this adjustment will cut storage costs.

4. Instead of using the "is_deleted" flag in the Transaction struct ,I would remove it and track deleted transactions using the deleted transaction count in the Tracker struct. This change will reduce storage costs and simplify the logic.
5. restructure the contract to make it more tight and secure.
6. and few more changes which i can figureout on the go

from decentralized-expense-tracker.

Hey @J0SAL
Being a student of smart contract auditorship I think my expertise aligns with the demands of the issue.
The changes can be:

1. the all_ids mapping can be removed and simply the [msg.sender][_id].amount would be checked if its not equla to 0. If it is not that means id already exists. This can save a lot of gas.
   2)We can remove the isdeleted flag and remove that particular entry from the array. This would reduce a lot of gas.
   3)Transaction and tracker structs can be merged. This would eliminate one more mapping from smart contract.
2. We can change 'i++' to '++i' in the for loop. This would reduce space as the contract doesnt have to keep track of previous variable value.

from decentralized-expense-tracker.

If possible please assign the task to me under GSSoC'23.

from decentralized-expense-tracker.

@J0SAL To optimize the smart contract and reduce gas fees, we can make the following improvements:

Using the Factory Pattern Approach(Clonning smart contract):
By using the factory pattern approach we can make instances of contract and can make (proxies) and can significantly reduce the gas fee.

Remove unnecessary string array tracker[msg. sender].transactions:
As we are storing an array of transaction IDs in the Tracker struct. However, this is not required as we have to iterate over the transactions mapping to get all the transaction details. By removing this array, we can save gas costs associated with maintaining and updating the array.

Use a mapping to track transaction existence:
Instead of using the all_ids mapping to check if a transaction ID already exists, we can modify the transactions mapping to use a bool variable to indicate the existence of a transaction. This way, we can eliminate the need for additional mapping and reduce gas costs.

Remove unnecessary is_deleted variable from the Transaction struct:
Since we are already using the is_deleted flag to mark a transaction as deleted, we can remove this variable from the Transaction struct. Instead, you can use the absence of a transaction in the transactions mapping to determine if it is deleted.

Optimize the getUserTransactions function:
The getUserTransactions function retrieves all transactions and filters out the deleted ones using an additional loop. This can be optimized by maintaining a separate counter for non-deleted transactions in the Tracker struct

from decentralized-expense-tracker.

hey @J0SAL Plzz assign me this issue I have explained what chances i will be making and explained the stuff

from decentralized-expense-tracker.

I would also like to contribute to this issue by using events instead of structs and mappings. In this way it will also be easier to filter out the data.

One possible problem might be that anyone will be able to see the other's data but the addresses are so designed that retrieving any information about the user would be nearly impossible.

Also using events will not only reduce gas fees but also allow tracability which could be a great feature for organisations looking to track down the monetary movement of an address.

from decentralized-expense-tracker.

@J0SAL I wold optimize the smart contract in the following ways: 1.Use bytes32 instead of string storage for transaction IDs. Because fixed-size byte arrays are less expensive to store and manipulate than dynamic strings, this improvement will cut gas expenditures.

2.Use an array to store transaction IDs instead of a mapping: Instead of using a mapping to store transactions, use an array to store transaction IDs. This update eliminates the requirement for the "all_ids" mapping, lowering storage and gas costs.

3.Use uint32 instead of enum for transaction type: Because there are only two transaction kinds, use uint32 instead of enum. Because uint32 requires less data than enum types, this adjustment will cut storage costs.

4. Instead of using the "is_deleted" flag in the Transaction struct ,I would remove it and track deleted transactions using the deleted transaction count in the Tracker struct. This change will reduce storage costs and simplify the logic.
5. restructure the contract to make it more tight and secure.
6. and few more changes which i can figureout on the go

@Arpaninformationtech Assigned to you.
Also, I hope you are aware that this would affect majorly all the functionalities of the contract.

from decentralized-expense-tracker.

Yes I am aware and I would take time and outmost care and precision to implement the above mentioned changes..

from decentralized-expense-tracker.