Replies: 2 comments 1 reply
-
It all depends on how the smart contract is implemented. You could set it up so that it has to wait for a set of oracles to all respond with their answers, and disallows votes to be cast directly on-chain.
When you make a meta-transaction (a signed transaction) whoever sends the tx is the one who pays the gas fee. So a user could sign a transaction, but they wouldn't pay the gas fee if someone else sends it for them! This is actually a common strategy used to help users out with gas fee payments.
This isn't quite accurate, although its also not technically wrong. When you send a transaction, it gets added to the mempool, and technically you're right, it could stay in there forever wait to get executed. But each node has limited space for transactions, and most nodes end up dropping transactions so their memory doesn't get clogged up with transactions that will never send. Great questions, let me know if that clears it up. |
Beta Was this translation helpful? Give feedback.
-
Hello everyone,
I am currently at the DAO section of the course. Patrick just explained how we could create a voting mechanism off-chain by posting signed voting transactions to IPFS for example.
My question is if a malicious entity just wants to hurt the DAO members, could it copy the signed transactions of the voters and send them to a node for execution? This way inflicting gas-fees on all voters? I got the idea from the recent merge and the risk of replay attacks.
As far as I know Ethereum has no concept of transaction expiration. Like, if the transaction was created 24h ago and isn't executed it will be dropped or something like that. Or are these kind of transactions submitted off-chain not exactly like on-chain transactions and therefore not executable?
Made me really curious!
Hope someone has an answer to this :)
Cheers
Beta Was this translation helpful? Give feedback.
All reactions