dojo
dojo copied to clipboard
dojoengine
feat(sozo): require manual confirmation from user before sending transaction if any anomaly is detected
Is your feature request related to a problem? Please describe.
Since we are planning stabilization and people would now be using sozo on mainnet, on which deployments and doing any kind of operation has real cost. We should try to add safety nets if any anomaly is detected.
For example, if:
- currently the gas price is very high
- if for any reason the transaction is costing much more than normal (say they call a function recusively, etc...)
Describe the solution you'd like
We can prompt the user to confirm the transaction displaying the cost in ETH that the transaction would cost if the cost is much higher than usual (definition of usual is up for debate). Also we would need to provide an argument to override this for environments where manual input is not possible like scripts, etc...
Describe alternatives you've considered
We already have --max-fee-raw in sozo arguments but most people don't normally use it, maybe instead we should configure this in the manifest file by default and user can increase the limit when required.
@lambda-0x are you taking outside contributors for this? if yes, I'd like to try this out
Should definitely be open @okhaimie-dev! Thanks for considering the contribution here. @lambda-0x how do you plan to detect "anomaly"?
@okhaimie-dev thanks for reaching out, for sure its open for contribution. but what exactly needs to be done is not decided. i opened the issue early for discussion.
@glihm simplest would be use amount of ETH that would be used for the transaction although this depends on the size of contracts which can vary based on project and gas cost which can very based on time.
I just wanted a way to have an upper limit on the transaction cost as a safety feature. open to suggestion on exact triggers.
@okhaimie-dev thanks for reaching out, for sure its open for contribution. but what exactly needs to be done is not decided. i opened the issue early for discussion.
@glihm simplest would be use amount of ETH that would be used for the transaction although this depends on the size of contracts which can vary based on project and gas cost which can very based on time.
I just wanted a way to have an upper limit on the transaction cost as a safety feature. open to suggestion on exact triggers.
I think it's not that easy to have an upper limit without sampling an history of transactions fees. We may have a simpler approach and have users configuring Sozo and set themselves the max fee they are ready to pay. This at the end fallback in the exact usage of --max-fee-raw. We may enhance it by having some env variable, or adding some units to make it easier to use?
@glihm can I contribute to this issue?
Feel free to contribute to the discussion as we're not sure yet how this would be implemented, and @okhaimie-dev commented first so we may assign to him if he still interested.
Don't hesitate to check other issues and we should add new first issues soon.
This at the end fallback in the exact usage of --max-fee-raw. We may enhance it by having some env variable, or adding some units to make it easier to use?
yeah exactly, but i fear people won't be configuring those unless they understand the risks of it. One other way we can approach this is heavily suggesting to use --max-fee-raw during mainnet deployments in the documentation.
I am applying to this issue via OnlyDust platform.
My background and how it can be leveraged
I am a MERN stack developer with basic foundation in solidity
How I plan on tackling this issue
I will try to find out the best optimal way so that gas fees can be reduced.
I am applying to this issue via OnlyDust platform.
My background and how it can be leveraged
I'm a blockchain developer, proficient in solidity, JavaScript/typescript and Rust, contributed in many open source projects
How I plan on tackling this issue
Implement a safety net in Sozo to prompt user confirmation if the transaction cost exceeds a usual threshold. Display the cost in ETH and allow an override argument for automated environments, enhancing stability on mainnet.
I am applying to this issue via OnlyDust platform.
My background and how it can be leveraged
I’m a Full Stack Developer and Blockchain Specialist with expertise in both front-end and back-end technologies, including JavaScript, React.js, Node.js, and Solidity for smart contracts. My experience spans developing secure, user-friendly web applications and handling blockchain projects with real-world financial implications. This background equips me to contribute effectively to projects that require a strong focus on security, usability, and efficient problem-solving.
How I plan on tackling this issue
I would define anomalies like high gas prices or unusual transaction costs, implement detection mechanisms in sozo, and trigger a user prompt for manual confirmation when an anomaly is detected. Additionally, I’d provide an override option for automated environments, thoroughly test the feature, and update the documentation for clarity. This ensures secure and user-friendly transaction handling on the mainnet.
hey guys please dont comment without reading the previous comments, this issue was opened to have a discussion about this. we haven't decided if we actually want to add a manual confirmation or strongly suggest people using --max-fee-raw in the documentation to avoid the issue mentioned in here.
I am applying to this issue via OnlyDust platform.
My background and how it can be leveraged
Hi, I’m Jose Mario from Costa Rica. With over 15 years of full-stack development experience, I am actively involved with Dojo Coding and am currently expanding my expertise in Rust, Cairo, and Solidity. I recently made my first contribution on Sozo and would love to continue contributing to this amazing project
How I plan on tackling this issue
Option #1:
Debug the migrate command using the spawn-and-move example and analyze the implementation of the TransactionOptions struct. Check for the presence of the --max-fee-raw argument; if it's missing, set its value from the manifest file or environment variable. Calculate the total migration cost of gas, compare it with the max fee raw, and prompt for manual confirmation if an anomaly is detected.
Option #2:
Recommend using the --max-fee-raw argument during mainnet deployments in the documentation.
Option #3:
Implement Option #1 and Option #2, and include updated documentation for the new implementation, covering manifest files, environment variables, and related changes.
Will close for now since we have v3 enabled, and happy to re-open once we have determined the correct behavior.