Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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
refactor(contracts): smart contracts optimizations #919
refactor(contracts): smart contracts optimizations #919
Changes from all commits
b10ff70
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thinking about that
TREE_ARITY
is called so many times in different contracts, and they should keep the same. Should we put it in somewhere and import it in these contracts?There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
mm maybe we could put it inside another contract shared by all of them though I think that would bloat things up a little bit 🤔 was looking and couldn't find a contract that was already in use by all of them (MACI, Poll, MP, Tally, etc) where we could add this constant..
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is that a good idea to have a contract holding the constants? or we just keep status quo?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
mm we have
SnarkConstants
holding some constants, though I'm not sure if it's a widely used pattern.. to avoid bloating contracts even more I would just keep this one constant inside each contract, at least for nowThere was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Then when it comes to deployment, if a user wants to alter the TREE_ARITY, they currently need to navigate through every contract file to modify the value. What if we convert it into an environmental variable for the sake of convenience during deployment?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Fair point, though they would also need to change the type of
AccQueue
in use, which currently is hardcoded to a quinary tree everywhere, mm 🤔There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
useful discussion here, there's definitely some more simplifying we can do given we always use quinary trees
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
by converting to env variable, you mean that it should be a value passed in the constructor when deploying the contracts?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
yes... but not sure if this is a good idea, just wanna reduce the risk that if some users deploy it and miss to change one of them?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
let's write this down and discuss together at the next team meeting? from next week we'll have a smart contract developer to ask all SC questions to 😈