chore: Add OpenZeppelin example

[claudioantonio]

• Added files that were tested successfully on Testmet: https://preview.bugbuster.app/bounty/24
• Added minimal automated test to be improved later
• Executed make test locally also successfully

[vercel]

The latest updates on your projects. Learn more about Vercel for Git ↗︎

Name	Status	Preview	Comments	Updated (UTC)
bug-buster	✅ Ready (Inspect)	Visit Preview	💬 Add feedback	Jan 30, 2025 5:22pm

[guidanoli]

It would be nice to have a valid exploit to test the bounty and add that to the unit test bench in Lua. Instead of deploying and sending a transaction to an exploit contract, we could have the exploit contract be a Forge script, which would allow us to broadcast transactions on behalf of any EOA, including the contract owner. We could avoid the long compilation process by defining a minimal Vm interface with just the functions we need. What do you think?

[claudioantonio]

It would be nice to have a valid exploit to test the bounty and add that to the unit test bench in Lua.

No doubt!

Instead of deploying and sending a transaction to an exploit contract, we could have the exploit contract be a Forge script, which would allow us to broadcast transactions on behalf of any EOA, including the contract owner. We could avoid the long compilation process by defining a minimal Vm interface with just the functions we need. What do you think?

The long compilation time is only a problem when doing it inside the machine. 😉

doubt: You mentioned above this test improvement as a "nice to have" thing and I agree. Do you think we should delay the publishing of the second tutorial until we implement this test improvement?

[guidanoli]

The long compilation time is only a problem when doing it inside the machine.

You're right, but if the exploit is now a Forge script, the hacker would have to use vm.startBroadcast to send their transaction, which would require them to either use the forge-std lib built into the Cartesi Machine, or define a timmed-down version of it.

Do you think we should delay the publishing of the second tutorial until we implement this test improvement?

I do think it is important to test code before publishing it, yes.