Framework/ Processes for development related swarms - Request for Feedback

šŸ Community Learning
#1

Hey 1Hive Dev team, I am taking up the responsibility of documenting a framework/ process that will provide some guidelines for future and current developers that will be using 1Hive as a launch pad after this discussion with Luke on the forum https://forum.1hive.org/t/alvin-and-the-dripp-ocalypse/3757/30.

For the moment my plan of action is to collate inputs from various Devs on their own routine that is followed when developing, reviewing, testing and post-release of a smart contract. I then intend to put all the feedback I get from the various Devs into a document format with separate sections addressing each stage of dev from concept to release. I would also ideally like to come up with some sort of a pre-release check list which can be used as a quality control process and ensure we do not have more dripp-apocalypses.

I have never really developed a smart contract so I may not understand the intricacies and so will lean on your collective experience here to see if I can come up with something that will be useful long term for 1Hive. I would really like all devs within 1Hive to may be give a few minutes of your time to comment and provide me any inputs that you think will help me in getting this framework completed.

I have prepared a questionnaire that I hope will help flush out some of the information I need:

  1. What are some current processes that are followed when starting development of a smart contract?
  2. Is there a list a libraries that are recommended to be used e.g OpenZepplin?
  3. Is there a list of simple checks like ā€˜Functions that do x need to be declared privateā€™ etc.
  4. Is there an established process to ensure that each iteration of code goes through a review? Do we have an established team that does reviews of code?
  5. Do you know if there is a list of lessons learnt from previous hacks that have been collated and published in one place? As each hackā€™s reason would have been a specific part of vulnerable code that allowed the exploit to happen. I assume if these can be collated it would be like a checklist that could be used to by each new dev to avoid known pitfalls.
  6. Could we brainstorm and get a list of things that must be checked during dev and prior to release of SC?
  7. What about pre-release checks - i.e where the keys are stored for minting of tokens, who deploys the contract, who checks prior to deployment, etc.

I am open to any sort of comment/ criticism on this issue and my approach to documenting the framework. So please be honest and give any feedback necessary to steer me in the right direction.

Tagging people I know that could give me feedback - @lkngtn @anisoptera @Monstrosity @metaverde @luigy @FriedRengi @willjgriff @fabriv

6 Likes
#2

I feel like in the absence of an audit we should at least have a panel at 1Hive that looks at the code, compares it to what it was cloned from if cloned, and looks at the tests/how it was tested.
Also, I may be in error, but it feels like anything that gets deployed in the defi world should be testnet deployed first.
Iā€™m not a Solidity dev (yet), so I donā€™t want to suggest any specifics regarding hard and fast rules.
If we could get @willjgriff to run all would-be collaborators over the coalsā€¦ respect Will.

2 Likes
#3

Thanks metaā€¦ appreciate the feedback. I was also thinking that some sort of a diff tool to be used to highlight changes from standard libraries in the code which would ensure that focus time is spent on changes that are new. I have been asking the same question around other DeFI discords and mostly the suggestions I am getting is consistent - Use standard code from libraries such as open zepplin, study existing hacks and ensure previous vulnerabilities are plugged, review code thoroughly prior to any release, testing extensively if possible using a white hacker to actually stress test code.

I am not sure how we are set up in 1Hive for dev of SCsā€¦ but waiting for some senior devs to provide me comment and feedback so that I understand the current processes followed. I am really curious to know what type of stress tests and reviews our shiny new farming contracts go through taking into account that they may have a few million in AUM when they are fully deployed.

1 Like