-
Notifications
You must be signed in to change notification settings - Fork 91
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Formal verification #926
Comments
I heard great things about Certora. If you search the ubiquity org for me writing the term "Certora" you can see that I listed a security checklist with a lot of what you filed issues for. |
I guess you mean this topic: #197 This issue doesn't include only 2 topics you mentioned at #197:
Regarding the bug bounty program, we have an implicit rule (which we applied at least 2 times) to reward 10% of the funds at risk. So I think a simple mention of bug bounty program somewhere at https://ubq.fi/ is enough, without going into details of severity, possibility, etc... Regarding the incident handling, all of the tutorials that I read goes simply to:
The most important is step 1 which pauses contracts. If it is not on time then all other mitigation steps don't make sense. So a separate incident response tutorial seems to be a low priority issue right now. |
Certora is closed sourced and has a pretty steep learning curve. I've had great experience using https://github.com/a16z/halmos which seems to be the most user friendly out of all of the tools. |
They asked me to schedule a call with them. I am under the impression that we can bring on one of their engineers to implement things. If you're interested I can consider your availability before booking |
Of course they asked for a call since they need to sell the product. Certora is a proprietary paid "formal verification as a service" company. They bring on one of the engineers since the product is really complicated. I'd rather use one of the open-sourced solutions and have one of the core team members to solve this issue in order to keep the context/knowledge in Ubiquity DAO instead of outsourcing solving this issue. |
Still an active issue? |
Yes |
/start @Keyrxng |
@gentlementlegen like I suggested please revert the code since start is broken |
/start |
! This issue is already assigned. Please choose another unassigned task. |
@0x4007 should be good to go for now hopefully. |
@sushant-rumsan, @Keyrxng, this task has been idle for a while. Please provide an update. |
/start |
Tip
|
Basically we have 2 invariants that should be proved (one, two). In some cases formal verification is not possible if there're too many code paths to prove. Not sure if https://github.com/a16z/halmos or https://docs.runtimeverification.com/kontrol are able to prove that invariants. |
Hey, thanks for pointing this out. I'm currently researching all the presented solutions to find the one that fits best. I'll keep you updated on my progress |
start |
|
/help |
Available Commands
|
/wallet 0x0013f4217f6a8B48A92f7EA5d811A5F8D8364B93 |
+ Successfully registered wallet address |
/start |
Tip
|
We should implement formal verification for LibUbiquityPool.
So collaborator who's going to take this issue should carefully study the LibUbiquityPool and think of the invariants that should be tested.
Invariants could be:
Possible solutions for formal verification:
We already had a try with formal verification, you may find related scripts here.
What should be done:
UbiquityPoolFacet.formal.t.sol
so we could distinguish unit, fuzz, invariant and formal verification tests)development
branch (keep in mind that github action runnners can run for 6 hours). We don't need to run formal verification tests on eash PR since they're really time consuming.The text was updated successfully, but these errors were encountered: