ElectroCrypt is a voting platform that augments prevalent blockchain powered e-voting systems with the integration of cloud technology, in order to provide strong security, flexible ballot casting, attack mitigation, and public auditing for transparency.
During ideation and development phase, we brainstormed and came up with newer ways of improving the system.
This issue will be updated as we keep coming up with newer viable ideas.
1. Meta Transactions - Gas Station Network
Meta Transactions are also known as "Gasless Transactions". The concept of meta transactions allows users to interact with the decentralized applications having ONLY a public/private keys pair.
A user with an account can craft a transaction in a similar way to how the ‘normal’ transaction is created, sign it with the own private key, but instead of sending it on-chain (which is usually the last step that requires paying ETH for gas), they send it to so-called a ‘relayer’, or the actual ‘sender’.
Any relayer can submit and execute the meta transaction, paying gas on behalf of the user in exchange from other forms of compensation specified in the meta transaction message. Ether or tokens can be used to pay relayers.
Matic has two Relayer networks available -
1. Biconomy & 2. GSN
Ethereum Gas Station Network (GSN) abstracts away gas to minimize onboarding & UX friction for dapps. With GSN, gasless clients can interact with Ethereum contracts without users needing ETH for transaction fees.
We can implement GSN in future that would allow Election Organizers save gas cost for each election creation
2. Address Cross Contract Replay attacks using Upgradebale Contracts -
We have addressed replay attacks on Matic on issue #8 . Moreover, we can also address cross contract replay attacks.
A real life use case of coss-contract replay attack on our system
1. We deploy out 2 contracts on matic testnet.
Each of these contracts get their own deployed address after that.
2. Then we realize we need to modify some codes on both of the contracts
3. Both of the new contracts’s _ABI_ are then generated and deployed again on the same blockchain.
Note that this time both contract’s deployed address is different now from the previous ones.
4. Accordingly, we also update the deployed contract address on front end Web3 in order to communicate.
5. This time, during election, if someone hacks into election auditor’s web portal and executes a new transaction to the previous contract’s address,
they will be able to cast the current votes and signatures on the previous deployed contract.
(This is what **cross-contract replay attack** is)
It basically means if a deployed contract address is available on the blockchain, anyone can try to make transaction to that using previous parameters.
All We need to make sure is that none is able to simulate this case using Upgradeable contracts.
OpenZeppelin library's 'Upgradeable contracts' allows upgrading existing contracts without changing the deployed address.
If we have a storage and proxy contract, it is possible to perform Update functions to the already deployed contracts through openzeppelin-cli.
During ideation and development phase, we brainstormed and came up with newer ways of improving the system.
This issue will be updated as we keep coming up with newer viable ideas.
1. Meta Transactions - Gas Station Network
2. Address Cross Contract Replay attacks using Upgradebale Contracts -
We have addressed replay attacks on Matic on issue #8 . Moreover, we can also address cross contract replay attacks.
A real life use case of coss-contract replay attack on our system
All We need to make sure is that none is able to simulate this case using Upgradeable contracts.