-
Notifications
You must be signed in to change notification settings - Fork 2.1k
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
Openbrush follow-up grant application #621
Conversation
Thanks for the application. I'm happy to see OpenBrush moving forward. We will look into it as soon as possible. |
@cmichi Please have a look at your convenience. |
applications/openbrush-follow-up.md
Outdated
| 0a. | License | MIT | | ||
| 0b. | Documentation | We will provide inline documentation, example of upgradable contracts. | | ||
| 0c. | Testing Guide | We will add tests to cover upgradability of contracts. | | ||
| 1. | Implement delegated call | We will find and provide the idea of how [delegeted call](https://docs.soliditylang.org/en/v0.4.21/introduction-to-smart-contracts.html#delegatecall-callcode-and-libraries) can be implemented in `contract-pallet`. Help with it's implementation. | |
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.
Why is the delegatecall
needed for upgrade ability? AFAIK it is only needed for library contracts which are not relevant here. Correct me if I am wrong. I was under the impression that paritytech/substrate#8909 implemented everything needed for upgradeable 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.
The idea of an upgradeable contract in Solidity, that you will execute the code of another contract in the context of the current contract(you will affect the storage of the current contract by the code of callee contract).
This change doesn't allow that. It allows only to call another without the ability to return back by the TAIL_CALL
flag.
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.
I know what delegatecall is. I just didn't know it was used for upgradeability. But it makes sense I guess. But you need to make sure that the new version does not change the storage layout, right?
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, the developer of the upgradable contract must worry about layout. We will create a list of rules that the developer must follow in order not to break the layout. OpenZeppelin did the same for solidity. Also, our library will provide the implementation of standards in upgradable form too.
@xgreenx After a brief discussion internally, I would suggest that for now you remove milestone 6 from your deliverables, as this overlaps with the |
It sounds good for us:) Does ink! team plan to implement all points from the milestone, or only 1 and 2? |
I'm not 100% sure at this stage, I guess we'll find out once we get there :) |
Done=) Later we will create a grant related to upgradability. Based on the results from ink! and substrate team we will define the scope of that grant. |
Thanks for the update, @xgreenx. Two more questions:
|
We already have started the process of creation of standards for tokens, because it takes time for approval from the community=)
If you want, I can put all of them into the milestone, but it will take a lot of rows=) Add examples of how the next contracts can be implemented: |
No need to add a deliverable for each of these. I just wanted to make sure we are talking about the same thing. Having them listed here is sufficient for me. |
Congratulations and welcome to the Web3 Foundation Grants Program! Please refer to our Milestone Delivery repository for instructions on how to submit milestones and invoices, our FAQ for frequently asked questions and the support section of our README for more ways to find answers to your questions. |
Hey @0xMarkian & @xgreenx, can I ask what the status of M5 and related issues is? Is this still on the roadmap? I remember vaguely seeing it discussed somewhere on here, but can't find it anymore. |
I also can't find where we discuss it=) Maybe in the old element.
I think we need to create a delivery report. |
That would be great. Thanks! |
Thanks @xgreenx does your team still plan on submitting a delivery report? |
Hey! This milestone was created as a part of Supercolony's work, so we are not sure that we can deliver it as a part of Brushfam. Is it a problem, and if it is, does there exist some solution to it? |
That is indeed not so trivial. I'll check with our legal team if we can assign the grant to you. Otherwise, we might have to cancel the old one and sign a new one. |
@Artemka374 We would need confirmation from SuperColony that they are willing to transfer the grant to Brushfam. Do you think that would be possible? |
Hey @semuelle, thanks a lot for making the inquiry! However, I believe Brushfam cannot receive compensation for this milestone as it wasn't executed by us, but rather by SuperColony. |
Thanks for the quick reply, @0xMarkian. My question was specifically for the purpose of transferring the grant from SuperColony to BrushFam so that you could deliver and get compensated for it. It would, however, require SuperColony's written approval. If that fails, of course we'd be happy to review your delivery of M5. I understand that it isn't your responsibility, though, and would be voluntary. I can see that the work was done, so I wouldn't expect you to put more work into it now. |
Hey, thanks for understanding. Let us know if M5 delivery will be of help for w3f. If so we will do it! |
From my point of view, OpenBrush is doesn't need our stamp of approval anymore. If you're not reliant on it, we'd simply cancel the last milestone and call it a day. |
Hey, apologies, missed this message. Yes, sounds good to me! |
Thanks for the straightforward resolution, @0xMarkian. The remaining milestone is officially cancelled. |
Thank you @semuelle ! |
Project Abstract
The mission of this project is to make ink! usable and facilitate WASM ecosystem adoption.
To be successful with this mission, we have outlined several steps that would need to be taken.
OpenZeppelin on Ethereum.
ink!
and in Substrate'spallet-contracts
. We are committed to doing that in the context of this project.It is an application for a follow-up grant. The initial grant covered the first and second milestones:
This grant aims to cover milestones 3-6.
For which grant level are you applying?
Application Checklist
project_name.md
) and updated.