Etf Network Proposal #2090
Etf Network Proposal #2090
Conversation
|
CLA Assistant Lite bot All contributors have signed the CLA ✍️ ✅ |
|
I have read and hereby sign the Contributor License Agreement. |
There was a problem hiding this comment.
Thanks a lot for the application. I have one initial question: have you already considered other sources of funding, like VCs or the treasury, in case you plan not to have a token? The grants program tries not to fund projects over a longer period of time since projects shouldn’t rely on us.
|
Hey @Noc2! We have considered other sources of funding for the subsequent phase of the project. Right now we have a small team and are trying to stay bootstrapped, so would like to forgo any VC involvement until we have a solid product (as our proposal is well thought out but still a bit experimental). The next phase of the project will delve into the cross-chain aspects of our idea and we are leaning towards creating a treasury proposal once we're ready for that, since if well executed it should provide value to other chains.
We do intend to have an inflationary token. Initially it is used to incentivize validators and as payments tx fees. In the future we intend to add a governance layer as well (to vote on network upgrades, features, constants, etc.). |
add more details to milestones
There was a problem hiding this comment.
Thanks for the changes @driemworks format looks good now. One additional request:
- We usually don't pay for hosting costs. Could you remove the last deliverable and perhaps lower the cost a bit?
|
@keeganquigley I updated the proposal to remove the cumulus-specific milestone and adjusted the costs accordingly. |
remove cumulus milestone
applications/etf_network.md
Outdated
| | **1.** | Future Proxy Manager | We implement a future proxy manager component as the initial piece. This component includes account derivation and proxy management (set self as future) capabilities. This will rely on the proxy utilities developed in the etf.js library during milestone (2). | | ||
| | **2.** | Scheduler UI | We develop a visual tool for defining a chain of delayed transactions. This component builds transactions using the txwrapper-etf, encrypts messages with the etf.js encryption functions, and signs transactions using polkadotjs. | | ||
| | **3.** | Explorer UI | We build a user interface to monitor the status of scheduled transactions and to access execution details. This interface will heavily rely on events emitted by the network. In addition, we explore the usage of tools such as Subquery to enhance and streamline this experience. | | ||
| | **4.** | Hosting | We host the UI on IPFS and also on Vercel to ensure decentralization of the application. Specifically, we will host our build on IPFS Infura. | |
There was a problem hiding this comment.
Thanks @driemworks I'm still seeing hosting costs listed in M4 as well, if you could remove them from here too.
There was a problem hiding this comment.
Removed! I left it as a 'note' under the milestone, since we still intend to do it. Just to make sure I understand, w3f doesn't fund hosting-specific tasks, would cumulus-compatibility and rococo-deployment tasks also fall under that too?
There was a problem hiding this comment.
@driemworks yes exactly, as we don't cover deployment costs. Looks good, I will mark as ready for review and ping the committee. Thanks!
keeganquigley
added
ready for review
There was a problem hiding this comment.
Thanks @driemworks I marked it as ready for review but I suppose I do have one more question. Would you be willing to reduce the rate, as it seems a bit high for 3 months with 3 FTE. Also have you thought about going for treasury funding, or otherwise how do you plan to fund the project after this grant?
|
We reduced our rates for each of the milestones. Regarding funding: We are planning on pursuing funding through the treasury in the next phase of the project, where we intend to use the outcome of this grant to enable cross-chain capabilities (with delayed transactions). We didn't want to go for treasury funding with the current proposal as it is a somewhat experimental design and doesn't immediately impact other parties in the ecosystem (but it will in the future). We are also open to/considering other external funding opportunities as well once we have a solid product ready. |
|
@keeganquigley We would like to make some changes to our proposal, specifically related to the proxy/nonce handling idea. Can we put the review on hold until we make that update? Likely by tomorrow. |
|
Thanks for the update @driemworks sure thing, I will mark it as on hold. Feel free to ping me once the changes have been implemented. |
keeganquigley
added
on hold
* update proposal with new delay tx approach * update mermaid indents * change mermaid formatting * add test diagram * fix diagrams * update milestones * move tlock auction to future work * cleanup * final updates * fix colors * fix colors * update milestones * move tlock auction description * final version
|
@keeganquigley I've made the updates, it's ready to go again. |
keeganquigley
added
ready for review
There was a problem hiding this comment.
@driemworks this looks interesting, but after already funding your team through 3 past grants and $60k I believe it'd be good to start exploring other funding alternatives as well, as we don't want teams to solely rely on our program for funding. We have recently launched the decentralized futures program that might be a good fit for your project. Other funding avenues include treasury (as already mentioned) or VC funding. Would you be open to consider any of these options?
| | **1.** | Scheduler UI (2 weeks) | We develop a visual tool for defining a chain of delayed transactions. This component builds transactions using the txwrapper-etf, encrypts messages with the etf.js encryption functions, and signs transactions using polkadotjs. | | ||
| | **2.** | Explorer UI (2 weeks) | We build a user interface to monitor the status of scheduled transactions and to access execution details. This interface will heavily rely on events emitted by the network. In addition, we explore the usage of too ls such as Subquery to enhance and streamline this experience. | |
There was a problem hiding this comment.
For UI-based deliverables we'd usually require some wireframes.
| | **0c.** | Testing and Testing Guide (.5 weeks) | Core functions will be fully covered by comprehensive unit tests to ensure functionality and robustness. This includes unit tests for the DPSS impl, its integration into Aura, the timelock-encryption modifications, and code modifications needed to run within a TEE. We will use the cargo tarpauling tool to ensure > 80% coverage on all new lines of code. We will also perform benchmarking of the DPSS implementation, as well as its integration in to Aura, and ensure any performance issues are well-documented if unabel to be entirely resolved. | | ||
| | **0d.** | Docker (.5 day) | We will provide a Dockerfile(s) for a node which uses the consensus mechanism build as part of deliverable (2). | | ||
| | **0e.** | Article (2 days) | We will publish a substack article detailing the deliverables, accomplishments, and obstacles encountered during the implementation of this milestone. | | ||
| | **1.** | Implement DPSS (2 weeks) | We implement a dynamic committee proactive secret sharing scheme using rust. This will be an open source implementation based on [this paper](https://eprint.iacr.org/2022/971.pdf). We implement this using Arkworks, and will experiement with replacing the paillier encryption + ZKP construction with el gamal + DLEQ proofs. We do this as part of the etf-crypto-primtives code base, which is part of the etf-sdk. We also perform benchmarking of our construction. We will also test performance of the implementation by running benchamrks (like with [hyperfine](https://github.com/sharkdp/hyperfine)). | |
There was a problem hiding this comment.
| | **1.** | Implement DPSS (2 weeks) | We implement a dynamic committee proactive secret sharing scheme using rust. This will be an open source implementation based on [this paper](https://eprint.iacr.org/2022/971.pdf). We implement this using Arkworks, and will experiement with replacing the paillier encryption + ZKP construction with el gamal + DLEQ proofs. We do this as part of the etf-crypto-primtives code base, which is part of the etf-sdk. We also perform benchmarking of our construction. We will also test performance of the implementation by running benchamrks (like with [hyperfine](https://github.com/sharkdp/hyperfine)). | | |
| | **1.** | Implement DPSS (2 weeks) | We implement a dynamic committee proactive secret sharing scheme using rust. This will be an open source implementation based on [this paper](https://eprint.iacr.org/2022/971.pdf). We implement this using Arkworks, and will experiment with replacing the paillier encryption + ZKP construction with el gamal + DLEQ proofs. We do this as part of the etf-crypto-primitives code base, which is part of the etf-sdk. We also perform benchmarking of our construction. We will also test the performance of the implementation by running benchmarks (like with [hyperfine](https://github.com/sharkdp/hyperfine)). | | |
|
@takahser thanks for the feedback. We were considering applying for the futures program instead, but we weren't sure if we should yet since we opened this proposal before the announcement. We're definitely open to going that route if it would be a better fit for the project (which seems to be the general consensus). We made a forum post about the project last week and have the template for the futures program, so we would essentially just need to transfer our proposal to the template and complete the application. I think we can go ahead and close out the proposal in that case. |
There was a problem hiding this comment.
Thanks for the update. In this case, I will close the application here. Let us know if you have any questions about the decentralized future program, and feel free to join the element channel here: https://matrix.to/#/#df:web3.foundation
|
@driemworks sounds good! Note that I'd still recommend you to include wireframes for the UI-based deliverables. This will allow the reviewers to get a better picture of what to expect from your proposal. Good luck! |
Project Abstract
This is a followup to cryptex.
The ETF Network (“encryption to the future”) is a substrate-based blockchain that uses a
proof-of-extractconsensus (working title), enabling timelock encryption. The ETF Network's consensus mechanism leverages identity-based encryption and DLEQ proofs to leak IBE secret keys with each block produced in a publicly verifiable way. In our initial grant, we delivered a proof of authority version of our consensus mechanism, along with rust and typescript libraries for enabling timelock encryption in standalone libraries and in the browser, along with a proof-of-concept auction application.Primarily, the goal of this follow-up grant is to develop a mechanism for secure delayed transactions on the ETF network, where transactions can remain encrypted in runtime storage until desired secrets are leaked. We intend to accomplish this by introducing a new proxy type, the
Futureproxy, which will be capable of using our timelock primitive to submit delayed transactions to the ETF Network. We also aim to ensure the security and scalability of the network by developing a proof-of-stake version of our consensus mechanism. We do this by implementing adynamic-committee proactive secret sharingscheme and integrating it with the Babe consensus mechanism. We will revisit the sealed bid auction developed in our previous grant, using delayed transactions rather than timelocked bids. As a result, this demonstrates the ability to participate in non-interactive, trustless MPC protocols via smart contracts. We will also develop browser-based tools (etf.js and a transaction manager dapp) that allows users to easily construct, manage, and monitor delayed transactions and a user's status as a Future proxy. We conclude by moving one step closer to be a parachain by ensuring Cumulus compatibility and deploying our testnet to rococo, along with our auction platform and the setup of robust telemetry and monitoring tools.Grant level
Application Checklist
project_name.md).@_______:matrix.org(change the homeserver if you use a different one)