DAOsign #1770
DAOsign #1770
Conversation
|
|
There was a problem hiding this comment.
Thanks for the application. Could you sign our terms and conditions (see the message above)? Also, could you specify which open source license you are planning to use as well as integrate the default deliverables (0a., 0b., etc.) into the second milestone? Furthermore, it's not fully clear to me why you want to integrate the eip712 and eip2771 as ink! smart contracts. Could you add a more detailed explanation as well as potentially link to the existing standards? In most cases, it makes sense to adjust the standards rather than simply reusing them.
|
pinging @Burmenska |
|
Hello , thanks @semuelle for the ping. T&C are signed, I'll be back to you with the answers shortly. |
|
@semuelle hello! the application was updated but there is some error in the CI/CD. can you please help me to resolve it? |
|
Hi @Burmenska. Thanks for the update. Don't worry about the CI, this is just for internal bookkeeping. |
There was a problem hiding this comment.
Thanks again for the application, @Burmenska! I have a couple of comments/questions:
adaptation means that user data is converted to a binary bit
I don't understand this part, can you explain? A bit doesn't hold a lot of information. :)
- There is already a standard an an implementation of ERC721 in ink!: code, website. I would suggest reusing their implementation and removing this deliverable altogether.
- You can leave the license as 'TBD' for now, but please note that it would have to be one approved by OSI.
- Meta transactions require an off-chain relayer. Could you add this to the deliverables?
- Related: there is no Docker deliverable in your milestones. For testing purposes, especially when it includes a relayer, some kind of setup automation would be very helpful.
- Can you be more specific in the specification of your deliverables? Specifications should be verifiable, so ideally for a smart contract it should list its functions or functionality.
- What does 'Application Private Key Management' mean?
- Wouldn't it make sense to split the EIP2771 work into a separate milestone? The rest of the platform works without it, correct? I'm mainly asking because I think this work would be interesting for many others in the ink!/Substrate ecosystem, and having a separate milestone would help
|
hello @semuelle , thanks for your comments, happy to answer, see below: There is already a standard an an implementation of ERC721 in ink!: code, website. I would suggest reusing their implementation and removing this deliverable altogether. Thanks for the link, will update the deliverables. You can leave the license as 'TBD' for now, but please note that it would have to be one approved by OSI. Meta transactions require an off-chain relayer. Could you add this to the deliverables? Related: there is no Docker deliverable in your milestones. For testing purposes, especially when it includes a relayer, some kind of setup automation would be very helpful. Can you be more specific in the specification of your deliverables? Specifications should be verifiable, so ideally for a smart contract it should list its functions or functionality. What does 'Application Private Key Management' mean? Wouldn't it make sense to split the EIP2771 work into a separate milestone? The rest of the platform works without it, correct? I'm mainly asking because I think this work would be interesting for many others in the ink!/Substrate ecosystem, and having a separate milestone would help From the development standpoint, within the RUST workspace we plann to include EIP2771 as a separate subrepository . From the reporting standpoint, it is included into a bigger milestone but if you believe, that it makes sense to separate it, let me know pls. It should not impact neither scope nor duration of the project. |
My understanding of ERC2771 is that a relayer accepts and forwards messages off-chain. It's named
Yes, interfaces are ideal.
There should be some kind of specification for each deliverable that we can refer to during the evaluation, so we can verify that everything was delivered as expected. I don't know what private keys you are planning to store, so I cannot comment on what needs to be included in the application and if.
That works.
Thanks. Please ping me here when you are done updating, I'll have another look then. |
|
pinging @Burmenska |
There was a problem hiding this comment.
Thanks for the update. But to already mention it. Please specify the license already at this stage. You can always amend it later. "most likely there will be Apache 2.0" could mean anything, even a non-open-source license, which is mandatory for this grants program.
|
Hi @semuelle CTO of DAOsign here. Let me step back and start from the beginning. DAOsign propose to store Agreements Proofs on Polkadot chain using Ink! smart contracts. And provide methods to verify signature on-chain. There are two types of users in DAOsign:
Proofs are implemented in EIP-712 standard and signed using user’s EVM private key (using Metamask for example). We are supporting this standard in Ink! smart contract to be able to verify signature. Creator can select option where to store proofs: only on IPFS or also on Polkadot. If they select Polkadot then Creator needs to pay some fee that will be used for transaction gas fee. For that, we are also implementing EIP-2771 standard to allow Agreement Signers gas-free delegation to publish proof on-chain. Here is a sequence diagram describing our process:
We are working on Smart Contract implementation for EVM-based chains, and you can take a look at the code here. This code is still in progress, but it gives some understanding of our approach. Documentation is also available. Answering to your question:
ERC2771 gives as ability to execute delegated call from Signer without making them to pay gas fee. Does it make sense? Let me know if you have any questions or concerns, |
|
Here is technical design and documentation for EVM-based chain integration: |
There was a problem hiding this comment.
Thanks for the updates, @Burmenska and @ramilexe. Some follow-up questions:
applications/DAOsign.md
Outdated
| | 0a. | License | Apache 2.0 | | ||
| | 0b. | Documentation | We will provide both **inline documentation** of the code and a basic **tutorial** that explains how a user can upload/generate the agreement, add signers/observers and complete the signature process with storing signature proofs either in test or mainnet, which will show how the new functionality works. | | ||
| | 0c. | Testing and Testing Guide | Core functions will be fully covered by comprehensive unit tests to ensure functionality and robustness. In the guide, we will describe how to run these tests. | | ||
| | 0d. | Delivery format | We will provide a website that will include the agreement creation, modification and signing functionality for users with further proofs storing on Polkadot chain. |
There was a problem hiding this comment.
0d is usually a Dockerfile or some other setup automation tool to help us and others test the project. Ideally, this would run a local node, deploy and instantiate the contracts or run unit tests on the smart contracts.
There was a problem hiding this comment.
@semuelle @keeganquigley added docker step as 0d
There was a problem hiding this comment.
Thanks @ramilexe typically this is required for all milestones, as I would think the local contract node would be needed for M2 as well. But an npm/yarn package should suffice if its easy to get up and running.
There was a problem hiding this comment.
@keeganquigley I don't see how docker could help with npm/yarn modules. It will be used docker from previous milestone to spin up node with smart contract
There was a problem hiding this comment.
@ramilexe Docker just helps for quickly spinning up a contracts-node to run the smart contract. So no worries, that's fine if it will be the same as the previous milestone.
There was a problem hiding this comment.
@ramilexe I just realised that M2 still doesn't contain the Docker deliverable. Could you please add it? As already mentioned by @keeganquigley it's sufficient if it's the same as in M1, but I think it'd make it easier to evaluate it you'd deliver.
There was a problem hiding this comment.
@takahser @keeganquigley I thought we agreed we don't need docker for M2 because it will contain Javascript library and frontend that usually delivered as a npm module, not docker container
There was a problem hiding this comment.
@ramilexe I think the idea was to use the same docker config file(s) as in M1 to test the integration with the js library. You can add a note that indicates that. Alternatively, you can add a note to the SDK indicating that it will be compatible with the docker deliverable from M1.
There was a problem hiding this comment.
Added docker to m2. Is it ok?
Create a DAOsign application file
Project description update
Adding an information about project purpose
Add info about team members
Adding milestone details
Polkadot address update
|
@takahser the idea of gas relayer is to allow users to submit transaction without having native token for gas fee. To achieve that, gas relayer takes responsibility for signing the transaction (using relayer's private key) and paying gas fee.
We only lose native tokens held on this private key. Nothing more. Because our EIP-712 implementation on Ink! in
It is possible to run multiple relayers. Using the same private key is not necessary because are permissionless. So, the key management is not an issue.
Here is a simple illustration that show how gas relayer works. Taken from here: https://docs.opengsn.org/#the-problem
|
|
Btw, it seems CLA action doesn't accept my comment |
There was a problem hiding this comment.
@Burmenska and @ramilexe thank you for the grant application.
It is an interesting solution. I have some doubts. In the future plans part of the application says: "After the ink! version of the DAOsign protocol stack is fully tested, we would like to implement a pallet version for Polkadot ecosystems". I think the technical solution would be facilitated if the implementation is a pallet and not a smart contract. For example, there is no need for a Relayer to create transactions that don't pay gas fees. This could be performed by calling extrinsics that don't pay fees.
Are you considering having a parachain in the future? Have you already tried to design this system using pallets? Maybe would be easier to develop. If you plan to have pallets in the future, would be a shorter path to go straight for a pallet implementation.
If you plan to use smart contracts, in which network do you plan to deploy it?
|
pinging @Burmenska and @ramilexe |
|
Hi @dsm-w3f Thank you for your feedback. |
There was a problem hiding this comment.
Thanks @Burmenska for the changes and for your thorough answers. The application looks a lot better to me now than last time I looked at it, and I'm willing to go forward with it as well. LGTM.
|
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. |
|
@semuelle @Noc2 @keeganquigley @dsm-w3f @nikw3f , great news, we greatly appreciate the level of detail and attention you paid to our application, as well as all your questions. We are thrilled about receiving the grant and are super enthusiastic about this partnership.we will review the requirements to the delivery process together @ramilexe and I'll be back to you in case of any questions. Thanks! |
|
Don't hesitate to contact us if you have any questions, @Burmenska. |
* DAOsign application Create a DAOsign application file * Delete DAOsign * Create DAOsign.md Project description update * Update DAOsign.md Adding an information about project purpose * Update DAOsign.md Add info about team members * Update DAOsign.md Adding milestone details * Update DAOsign.md Polkadot address update * Update DAOsign.md * Update DAOsign.md * Update DAOsign.md * Update DAOsign.md Project description details * Update DAOsign.md Update the roadmap * Update DAOsign.md * Update DAOsign.md * Update DAOsign.md * Update DAOsign.md * Update DAOsign.md Final iteration with Ramil. * Update DAOsign.md * Update DAOsign.md provide the requested information * Update DAOsign.md minor updates to the application: - license info - reusing brush-contracts info included * Update DAOsign.md Updated a license information and added an example of the smart contracts * update * correct name of the pallet * update deliverables to deploy to Astar testnet fix typos * update m2 deliverables * Update DAOsign.md updated a registered address * Update applications/DAOsign.md Co-authored-by: S E R A Y A <[email protected]> * add UI design * add link to Proof technical design * * added description for Off-chain Relayer * realign milestones cost * updated seq diagram * Update applications/DAOsign.md Co-authored-by: S E R A Y A <[email protected]> * add docker to m2 * added relayer as a separate milestone 3 --------- Co-authored-by: ramil <[email protected]> Co-authored-by: S E R A Y A <[email protected]>
|
Hi @Burmenska are you able to provide an update on M1? |
|
hello @keeganquigley, thanks for your patience. @ramilexe , DAOsign CTO already has everything in place and is preparing a PR. I will update you once the pull request is committed, it should happen in the nearest days. |
|
Hi @keeganquigley |
|
Hi @Burmenska @ramilexe how is milestone 2 coming along? Are you able to provide an update? |
|
Hi @Burmenska @ramilexe are you still working on this grant? As I noticed there haven't been any commits to the repo in quite some time. Thanks for any info you can provide. |
|
Hello @keeganquigley , I hope you’re doing well. I’m really sorry for the delivery delays and for the inconvenience it caused you. I haven’t been part of the DAOsign team since April and unfortunately can’t provide updates on this matter. However, let me pass your request to @ramilexe and another colleague who is currently responsible for grants delivery and I'll let you know once I'll have some update. If there's anything else, I can help with, please let me know. Thanks and have a great day! |
|
Thanks for the update @Burmenska much appreciated. @ramilexe let me know if you can confirm. |
|
Hi @keeganquigley |
|
Hi @Burmenska @ramilexe I think we still haven't received a delivery for this yet, correct? |
|
Hi @ramilexe are you still planning to submit a delivery soon? Otherwise we would likely cancel the grant due to inactivity. |
|
@keeganquigley , sorry, as I previously mentioned , I'm not a part of DAOsign team since April 2024. Still, let me pass your request to the team, perhaps @ramilexe just missed it. |
Project Abstract
Grant level
Application Checklist
project_name.md).@_______:matrix.org(change the homeserver if you use a different one)