**Projects Page:** Showcase page with detailed filtering and search infrastructure
**Project Detail Page:** Project details page to display detailed information about project with several modules like explained in the solution
**Articles Page:** Articles page to showcase informative articles related to the subject
**Article Detail Page:** Detail page for individual articles to display their full content
**Ranking Page:** Ranking page based on votes and token stats which is supported by CoinGecko api to showcase popular projects and articles
**Learn Page:** Useful resources to learn about polkadot ecosystem **UX Improvements & Testing:** I will work to improve the user experience by ensuring that the user interface is fully compatible with mobile and tablet devices. | +| **1.** | UI & UX Development | **Home Page:** Visually appealing and user-friendly homepage which includes latest articles, popular categories and many more
**Projects Page:** Showcase page with detailed filtering and search infrastructure
**Project Detail Page:** Project details page to display detailed information about project with several modules like explained in the solution
**Articles Page:** Articles page to showcase informative articles related to the subject
**Article Detail Page:** Detail page for individual articles to display their full content
**Ranking Page:** Ranking page based on votes and token stats which is supported by CoinGecko api to showcase popular projects and articles
**Learn Page:** Useful resources to learn about polkadot ecosystem
**UX Improvements & Testing:** I will work to improve the user experience by ensuring that the user interface is fully compatible with mobile and tablet devices. | | *2.* | Project Owner Dashboard | As part of this milestone, I will be implementing both the frontend and backend components of the Project Owner Dashboard. This involves designing and developing the user interface (UI) for the dashboard, as well as building the necessary backend infrastructure to support its functionality. To ensure the quality of my work, I will conduct thorough testing to ensure that the dashboard is user-friendly and performs as expected. My ultimate goal is to provide project owners with a seamless and efficient experience when updating their pages and publishing articles on our platform. ## Future Plans diff --git a/applications/CESS.md b/applications/CESS.md index cbdf1084ba5..28b2d83c6e3 100644 --- a/applications/CESS.md +++ b/applications/CESS.md @@ -78,7 +78,7 @@ Compared to the similar projects in the Polkadot ecosystem including Ocean, Data - **Contact Name:** Jessie Dai - **Contact Email:** jessie@cess.cloud -- **Website:**
\- Generate a new ID on client-side for the patient based on BIP39. (12 words passphrase)
\- Encrypted key store(private key) by patient user’s password (AES-256 GCM mode)
\- Implement the decentralized design using public key cryptography. (Client signed by private key) | +| 1 | Patient ID creation | \- Develop the patient ID creation tool in Dart.
\- Generate a new ID on client-side for the patient based on BIP39. (12 words passphrase)
\- Encrypted key store(private key) by patient user’s password (AES-256 GCM mode)
\- Implement the decentralized design using public key cryptography. (Client signed by private key) | | 2 | Patient profile management module | \- Patient profile off-chain management tools developed by JAVA
\- Support AWS S3 storage
\- Updating of patient profile
\- ECIES end-to-end data encryption to secure profile data transfer. | -| 3 | Patient ID on-chain authentication | \- zkSNARKs Groth16 based on Non-Interactive Zero-Knowledge Proof (NIZKP) developed by !ink Smart Contract
\- Receive credential by trust issuer (token file)
\- Zero-knowledge proof for on-chain authentication to prove patient ID without private information | +| 3 | Patient ID on-chain authentication | \- zkSNARKs Groth16 based on Non-Interactive Zero-Knowledge Proof (NIZKP) developed by xcm or runtime module or !ink Smart Contract
\- Receive credential by trust issuer (token file)
\- Zero-knowledge proof for on-chain authentication to prove patient ID without private information | | 4 | Challenge card dapp module | Provide a way for users to set personal goals, track their progress, and receive rewards for their efforts. Dapp developed in ink! smart contract.
\- Add challenge card
\- Add personalized mission
\- Delete challenge card
\- Receive daily mission
\- Receive rewards by mission completed
\- Receive rewards by challenge completed
\- Rewards by fungible tokens | | 5 | Create database | Create a docker container to start a mySQL database to store all the information, define the models to store and create tables and indexes. | | 6 | Database encryption module | We will implement a database encryption AES-256 GCM module of all stored and transmitted data to prevent unauthorized access or tampering. Developed by JAVA. | | 7 | Android apk | We will provide android apk for above challenge card data input and functional verification
We will provide android apk for user challenge card with wallet to receive rewards | | 8 | Testing | Achieve a testing coverage of the functionalities above 90% | -### Milestone 2 - CPatient Engagement and Data Sharing +### Milestone 2 - Patient Engagement and Data Sharing - **Estimated Duration:** 2 month - **Developers:** FTE x 4 - **(Product Design x 1, Dapp Engineer x 1, System Engineer x 1, APP Engineer x 1)** diff --git a/applications/CoinFabrik_On_Ink_Integration_Tests_2.md b/applications/CoinFabrik_On_Ink_Integration_Tests_2.md new file mode 100644 index 00000000000..684228a91ea --- /dev/null +++ b/applications/CoinFabrik_On_Ink_Integration_Tests_2.md @@ -0,0 +1,182 @@ +# CoinFabrik On Ink Integration Tests 2 +- **Team Name:** CoinFabrik (Nektra S.A) +- **Payment Address:** 0xf488039EDe6B38D7689fDCC6A9FC2dd0EF39D54e (USDC) +- **[Level](https://github.com/w3f/Grants-Program/tree/master#level_slider-levels):** 2 + +## Project Overview :page_facing_up: + +### Overview + +We have discovered that integration tests for ink! contracts lack some of the functionalities, or present implementation differences, when compared to E2E testing. + +Integration tests run significantly faster than E2E (end-to-end) tests. If a full range of functionalities were provided, it could reduce testing and QA times. + +Our intention is to `flatten the anvil` of ink! integration testing. With a properly flattened anvil, quality tools can be built. + + +### Project Details + +We have conducted a comprehensive analysis to identify any missing functionalities in integration tests and implementation differences with E2E tests, and to propose and develop new testing features based on our findings. This analysis was carried as part of a previous grant ([link](https://github.com/w3f/Grant-Milestone-Delivery/pull/998)). + +With this new grant, our objective is to implement our findings. Specifically, we aim to address functions in integration testing that have missing implementations or show differences when compared to e2e tests. We will add our contributions into the [ink! project repository](https://github.com/paritytech/ink ) following existing [contribution guidelines](https://github.com/paritytech/ink/blob/master/CONTRIBUTING.md). + +### Ecosystem Fit + +Having a comprehensive set of functionalities available for integration tests would bring numerous benefits to the entire community, including improved reliability, code quality and maturity, and faster feedback loops. + +Integration tests are useful during their development and they are quicker than E2E tests. We learned this while working on fuzzing detection techniques during the [Proof of Concept of Scout](https://github.com/CoinFabrik/web3-grant), which we performed in collaboration with [researchers from the University of Buenos Aires](https://lafhis.dc.uba.ar/home). We believe that having a complete set of functionalities for integration tests would be useful for other teams working in the development of ink! smart contracts. + +## Team :busts_in_silhouette: + +### Team members + +- Ariel Wassbein, Head of Research. +- Agustin Aon, Technical Lead. +- Valeria Caracciolo, Business Development. +- CoinFabrik's development and QA teams. + +### Contact + +- **Contact Name:** Valeria Caracciolo +- **Contact Email:** valeria.caracciolo@coinfabrik.com +- **Website:** https://www.coinfabrik.com/ + +### Legal Structure + +- **Registered Address:** Dr. Emilio Ravignani 2394, C1425 CABA, Argentina. +- **Registered Legal Entity:** Nektra S.A. + +### Team's experience + +We are a research and development company specialized in Web3, with a strong background in cybersecurity. Founded in 2014, we have worked on over 200 blockchain-related projects, EVM based and also for Solana, Algorand, and Polkadot. Beyond development, we offer security audits through a dedicated in-house team of senior cybersecurity professionals, currently working on code in Substrate, Solidity, Clarity, Rust, and TEAL. + +Our team has an academic background in computer science and mathematics, with work experience focused on cybersecurity and software development, including academic publications, patents turned into products, and conference presentations. Furthermore, we have an ongoing collaboration on knowledge transfer and open-source projects with the University of Buenos Aires. + +As well, CoinFabrik has been providing Quality Assurance as a service to development teams, accumulating valuable expertise in the field for a considerable period of time. Our clients highly appreciate this service, and as a result, we are eager to expand our capabilities to the ink! ecosystem. + + +### Team Code Repos + +- https://github.com/CoinFabrik +- https://github.com/CoinFabrik/on-ink-integration-tests +- https://github.com/CoinFabrik/scout +- https://github.com/CoinFabrik/web3-grant + +### Team LinkedIn Profiles (if available) + +- https://www.linkedin.com/in/arielwaissbein/ +- https://www.linkedin.com/in/agustin-aon/ +- https://www.linkedin.com/in/valeriacaracciolo/ + + +## Development Status :open_book: + +We have identified 24 functions exposed for their usage in integration and E2E tests in the file [env_access.rs](https://github.com/paritytech/ink/blob/master/crates/ink/src/env_access.rs) of the ink! repository. Of these 24 functions, we determined that there are 9 functions to work on with explicit plans, and 13 functions for which there might be implementation differences that remain to be analyzed. Two functions were deemed unfeasible for their implementation in the integration testing environment. + + +**Table 1: Status of functions exposed in integration and e2e testing environments.** +| Issue Number | Function | Implemented Integration Tests | Implemented Integration E2E Tests | Status | +|--------------|-----------------------------|-------------------------------|------------------------|------------------------------------------------------------------------------------------------| +| 1 | default_accounts() | Yes | Yes | Implementation Difference. | +| 2 | set_contract_storage() | Yes | Yes | Missing limitation on Integration Testing. | +| 3 | invoke_contract_delegate() | No | Yes | Missing Function Implementation on Integration Testing. | +| 4 | invoke_contract() | No | Yes | Missing Function Implementation on Integration Testing | +| 5 | gas_left() | No | Yes | Missing Function Implementation on Integration Testing. Unfeasible Implementation. | +| 6 | set_code_hash() | No | Yes | Missing Function Implementation on Integration Testing. | +| 7 | instantiate_contract() | No | Yes | Missing Function Implementation on Integration Testing. | +| 8 | caller_is_origin() | No | Yes | Missing Function Implementation on Integration Testing. | +| 9 | code_hash() | No | Yes | Missing Function Implementation on Integration Testing. | +| 10 | own_code_hash() | No | Yes | Missing Function Implementation on Integration Testing. | +| 11 | call_runtime() | No | Yes | Missing Function Implementation on Integration Testing. Unfeasible Implementation. | +| 12 | caller() | Yes | Yes | Pending Analysis for Corrections in Implementation Differences. | +| 13 | transferred_value() | Yes | Yes | Pending Analysis for Corrections in Implementation Differences. | +| 14 | weight_to_fee() | Yes | Yes | Pending Analysis for Corrections in Implementation Differences. | +| 15 | block_timestamp() | Yes | Yes | Pending Analysis for Corrections in Implementation Differences. | +| 16 | account_id() | Yes | Yes | Pending Analysis for Corrections in Implementation Differences. | +| 17 | balance() | Yes | Yes | Pending Analysis for Corrections in Implementation Differences. | +| 18 | block_number() | Yes | Yes | Pending Analysis for Corrections in Implementation Differences. | +| 19 | minimum_balance() | Yes | Yes | Pending Analysis for Corrections in Implementation Differences. | +| 20 | terminate_contract() | Yes | Yes | Pending Analysis for Corrections in Implementation Differences. | +| 21 | transfer() | Yes | Yes | Pending Analysis for Corrections in Implementation Differences. | +| 22 | hash_bytes() | Yes | Yes | Pending Analysis for Corrections in Implementation Differences. | +| 23 | hash_encoded() | Yes | Yes | Pending Analysis for Corrections in Implementation Differences. | +| 24 | ecdsa_recover() | Yes | Yes | Pending Analysis for Corrections in Implementation Differences. | + +For these two sets of functions, with explicit implementation plans and pending analysis, the following work remains to be performed. +- The implementation and correction of implementation differences of the 9 functions with explicit plans. These are the functions with issue numbers 1, 2, 3, 4, 6, 7, 8, 9, 10. +- An analysis of the remaining 13 functions, which are implemented both for integration and E2E tests, in order to first estimate and then correct implementation differences (if any). These correspond to functions issue numbers 12 through 24. +- QA: Adding tests to integrate the functions we add or modify to the [ink! project repository](https://github.com/paritytech/ink) following existing [contribution guidelines](https://github.com/paritytech/ink/blob/master/CONTRIBUTING.md). +- Report Describing our Contribution. + +Considering the dependency of several functions on the implementation of `instantiate_contract()`, we propose to split the work above into two milestones. All these implementations or modifications will be pushed into the [ink! project repository](https://github.com/paritytech/ink ) following existing [contribution guidelines](https://github.com/paritytech/ink/blob/master/CONTRIBUTING.md). + +We have also identified a bug in the e2e tests. When contracts are in a workspace with dependencies defined in `Cargo.toml`, and these dependencies are inherited in contracts, the e2e tests fail to compile. However, manually specifying dependencies in each contract resolves the issue. We've logged this bug on GitHub [Issue #1919](https://github.com/paritytech/ink/issues/1919) and will be addressing it as part of our work in Milestone 1. + +## Development Roadmap :nut_and_bolt: + +### Overview + +- **Total Estimated Duration:** 4 weeks +- **Full-Time Equivalent (FTE):** 4 FTE +(0.50 Project Manager, +0.50 Tech Lead, +1 Full time Sr Rust Developer, +1 Full Time SemiSr Rust Developer, +1 Full Time QA Specialist) +- **Total Costs:** 30,000 USD + +### Milestone 1: Execution and Further Analysis +- **Estimated duration:** 4 weeks +- **FTE:** 4 +- **Costs:** 30,000 USD + +| Number | Deliverable | Specification | +| ----- | ----------- | ------------- | +| 0a. | License | MIT +| 0b. | Documentation | We will write a comprehensive report that compares the functionalities of integration tests and E2E (End-to-End) tests. This report will focus on the functions to be implemented/corrected in this milestone, corresponding to issues 1-default_accounts(), 2-set_contract_storage() and 7-instantiate_contract().
Documentation and test cases will be provided for the 13 functions with remaining analysis. If implementation differences are found in these functions, an estimate for their correction and an implementation idea will also be provided in our report.
If applicable, we will suggest additional tests outside of the scope of this milestone. Particularly, for functions declared outside of the env_access.rs file, but that could be related to integration or e2e testing. +| 0c. | Testing and Testing Guide | The newly developed functionalities will be documented and tested following existing [contribution guidelines](https://github.com/paritytech/ink/blob/master/CONTRIBUTING.md). A testing guide will be included. +| 0d. | Docker | Does not apply at this stage. +| 0e. | Article | We will publish an updated report summary in our blog at https://blog.coinfabrik.com/. + **1** | Develop | We will develop the missing functionalities or correct implementation differences for functions 1-default_accounts(), 2-set_contract_storage() and 7-instantiate_contract(). All these implementations or modifications will be pushed into the [ink! project repository](https://github.com/paritytech/ink) following existing [contribution guidelines](https://github.com/paritytech/ink/blob/master/CONTRIBUTING.md).
If applicable, we will develop additional tests or make ad hoc improvements to the ink codebase necessary for the completion of this milestone. Particularly for functions declared outside the env_access.rs file that might be related to integration or end-to-end testing. + **2** | Review and Estimate | We will review the remaining 13 unanalysed functions, which are implemented both for integration and e2e tests. For these functions we will provide documentation, a test case and an implementation estimation if applicable. These correspond to functions issue numbers 12 through 24. + **3** | Quality Assurance | We will adhere to existing [contribution guidelines](https://github.com/paritytech/ink/blob/master/CONTRIBUTING.md) and add necessary tests to integrate the new implemented or corrected functions to the [ink! project repository](https://github.com/paritytech/ink). + + + +## Future Plans + +After finishing the Milestone 1: Execution and Further Analysis, we will submit a new grant proposal to continue with the implementation of the remaining functions. We will include specific references to developments associated with the estimations resulting from the further analysis of functions issue numbers 12 through 24. + +### Next Milestone: Execution +- **Estimated duration:** 4 weeks +- **FTE:** 4 +- **Costs:** 30,000 USD + + + +| Number | Deliverable | Specification | +| ----- | ----------- | ------------- | +| 0a. | License | MIT +| 0b. | Documentation | We will write a comprehensive report that compares the functionalities of integration tests and E2E (End-to-End) tests. This report will focus on the the functions to be implemented in this milestone, corresponding to issues 3-invoke_contract_delegate(), 4-invoke_contract(), 6-set_code_hash(), 8-caller_is_origin(), 9-code_hash(), 10-own_code_hash().
Our report will also document the implementation of any missing functionalities, or correct implementation differences, for the 13 functions with issues 12 through 24. For this group, we will document any additional work that was required in order to ensure consistency between integration and e2e tests.
If applicable, we will suggest additional tests outside of the scope of this milestone. Particularly, for functions declared outside of the env_access.rs file, but that could be related to integration or e2e testing. +| 0c. | Testing and Testing Guide | The newly developed functionalities will be documented and tested following existing [contribution guidelines](https://github.com/paritytech/ink/blob/master/CONTRIBUTING.md). A testing guide will be included. +| 0d. | Docker | Does not apply at this stage. +| 0e. | Article | We will publish an updated report summary in our blog at https://blog.coinfabrik.com/. + **1** | Development | We will implement the missing functionalities or resolve implementation differences for function issues 3-invoke_contract_delegate(), 4-invoke_contract(), 6-set_code_hash(), 8-caller_is_origin(), 9-code_hash(), 10-own_code_hash().
We will implement any missing functionalities, or correct implementation differences, for the 13 functions with issues 12 through 24. For this group, we will document any additional work required in order to ensure consistency between integration and e2e tests.
All these implementations or modifications will be pushed into the [ink! project repository](https://github.com/paritytech/ink) following existing [contribution guidelines](https://github.com/paritytech/ink/blob/master/CONTRIBUTING.md).
If applicable, we will develop additional tests or make ad hoc improvements to the ink codebase necessary for the completion of this milestone. Particularly for functions declared outside the env_access.rs file that might be related to integration or end-to-end testing. +**2** | Quality Assurance| We will adhere to existing [contribution guidelines](https://github.com/paritytech/ink/blob/master/CONTRIBUTING.md) and add necessary tests to integrate the new implemented or corrected functions to the [ink! project repository](https://github.com/paritytech/ink). + + +Moving forward, we have two projects in mind: + +- Research and develop an advanced testing automation solution for ink! smart contracts. +- Improve our open source bug-detection tool [Scout](https://coinfabrik.github.io/scout/ ). + + + +## Referral Program (optional) :moneybag: + +## Additional Information :heavy_plus_sign: + +**How did you hear about the Grants Program?** Richard Casey from Parity brought this program to our attention, and we have already successfully delivered two applications as a result. + +During our inquiries for this application, we briefly consulted Sam Ruberti from the ink! Team and David Hawig from the Web3 Foundation. Their encouragement motivated us to proceed with this presentation. + diff --git a/applications/CoinFabrik_On_Ink_Integration_Tests_3.md b/applications/CoinFabrik_On_Ink_Integration_Tests_3.md new file mode 100644 index 00000000000..f2c23693b53 --- /dev/null +++ b/applications/CoinFabrik_On_Ink_Integration_Tests_3.md @@ -0,0 +1,159 @@ +# CoinFabrik On Ink Integration Tests 3 +- **Team Name:** CoinFabrik (Nektra S.A) +- **Payment Address:** 0xf488039EDe6B38D7689fDCC6A9FC2dd0EF39D54e (USDC) +- **[Level](https://github.com/w3f/Grants-Program/tree/master#level_slider-levels):** 2 + +## Project Overview :page_facing_up: + +### Overview + +We have discovered that integration tests for ink! contracts lack some of the functionalities, or present implementation differences, when compared to E2E testing. + +Integration tests run significantly faster than E2E (end-to-end) tests. If a full range of functionalities were provided, it could reduce testing and QA times. + +Our intention is to `flatten the anvil` of ink! integration testing. With a properly flattened anvil, quality tools can be built. + + +### Project Details + +We have conducted a comprehensive analysis to identify any missing functionalities in integration tests and implementation differences with E2E tests, and to propose and develop new testing features based on our findings. This analysis was carried as part of two previous grants ([link1](https://github.com/w3f/Grant-Milestone-Delivery/pull/998), [link2](https://github.com/w3f/Grant-Milestone-Delivery/pull/1043)). As part of the latter grant, we have developed and resolved the issues with some of the functions with implementation differences or missing implementations: `default_accounts()`, `set_contract_storage()` and `instantiate_contract()`. + +With this new grant, our objective is to implement our findings. Specifically, we aim to address functions in integration testing that have missing implementations or show differences when compared to e2e tests. We will add our contributions into the [ink! project repository](https://github.com/paritytech/ink ) following existing [contribution guidelines](https://github.com/paritytech/ink/blob/master/CONTRIBUTING.md). + + +### Ecosystem Fit + +Having a comprehensive set of functionalities available for integration tests would bring numerous benefits to the entire community, including improved reliability, code quality and maturity, and faster feedback loops. + +Integration tests are useful during their development and they are quicker than E2E tests. We learned this while working on fuzzing detection techniques during the [Proof of Concept of Scout](https://github.com/CoinFabrik/web3-grant), which we performed in collaboration with [researchers from the University of Buenos Aires](https://lafhis.dc.uba.ar/home). We believe that having a complete set of functionalities for integration tests would be useful for other teams working in the development of ink! smart contracts. + +## Team :busts_in_silhouette: + +### Team members + +- Ariel Wassbein, Head of Research. +- Valeria Caracciolo, Business Development. +- CoinFabrik's development and QA teams. + + +### Contact + +- **Contact Name:** Valeria Caracciolo +- **Contact Email:** valeria.caracciolo@coinfabrik.com +- **Website:** https://www.coinfabrik.com/ + + +### Legal Structure + +- **Registered Address:** Dr. Emilio Ravignani 2394, C1425 CABA, Argentina +- **Registered Legal Entity:** Nektra S.A + + +### Team's experience + +We are a research and development company specialized in Web3, with a strong background in cybersecurity. Founded in 2014, we have worked on over 200 blockchain-related projects, EVM based and also for Solana, Algorand, and Polkadot. Beyond development, we offer security audits through a dedicated in-house team of senior cybersecurity professionals, currently working on code in Substrate, Solidity, Clarity, Rust, and TEAL. + +Our team has an academic background in computer science and mathematics, with work experience focused on cybersecurity and software development, including academic publications, patents turned into products, and conference presentations. Furthermore, we have an ongoing collaboration on knowledge transfer and open-source projects with the University of Buenos Aires. + +As well, CoinFabrik has been providing Quality Assurance as a service to development teams, accumulating valuable expertise in the field for a considerable period of time. Our clients highly appreciate this service, and as a result, we are eager to expand our capabilities to the ink! ecosystem. + + +### Team Code Repos + +- https://github.com/CoinFabrik +- https://github.com/CoinFabrik/on-ink_implementations +- https://github.com/CoinFabrik/on-ink-integration-tests +- https://github.com/CoinFabrik/scout +- https://github.com/CoinFabrik/web3-grant + +### Team LinkedIn Profiles (if available) + +- https://www.linkedin.com/in/arielwaissbein/ +- https://www.linkedin.com/in/valeriacaracciolo/ + + +## Development Status :open_book: + +We have identified and analyzed 24 functions exposed for their usage in integration and E2E tests in the file [env_access.rs](https://github.com/paritytech/ink/blob/master/crates/ink/src/env_access.rs) of the ink! repository. We documented these functions and provided test cases comparing their behaviour in integration and end-to-end tests. This analysis can be found in our [analysis repository](https://github.com/CoinFabrik/on-ink-integration-tests). + +Of these 24 functions, 4 functions showed behaviour differences when comparing their implementations for integration and e2e tests, 9 showed missing implementations for integration tests and the remaining 11 functions showed a consistent implementation across both environments. + +In the table below, we provide the status of each function after the developments and analysis made in our previous milestones. + +**Table 1: Status of functions exposed in integration and e2e testing environments.** +| Issue Number | Function | Implemented Integration Tests | Implemented E2E Tests | Status | +|--------------|-------------------------------|-------------------------------|----------------------------------|--------------------------------------------------------------------------| +| 1 | default_accounts() | Yes | Yes | Implementation Difference Corrected. [Pull request performed](https://github.com/paritytech/ink/pull/1955). | +| 2 | set_contract_storage() | Yes | Yes | Missing limitation on Integration Testing Implemented. [Pull request performed](https://github.com/paritytech/ink/pull/1961). | +| 3 | invoke_contract_delegate() | No | Yes | Missing Function Implementation on Integration Testing. | +| 4 | invoke_contract() | No | Yes | Missing Function Implementation on Integration Testing | +| 5 | gas_left() | No | Yes | Missing Function Implementation on Integration Testing. Unfeasible Implementation. | +| 6 | set_code_hash() | No | Yes | Missing Function Implementation on Integration Testing. | +| 7 | instantiate_contract() | No. [Pull request performed](https://github.com/paritytech/ink/pull/1963). | Yes | Missing Function Implementation on Integration Testing Performed. [Pull request performed](https://github.com/paritytech/ink/pull/1963). | +| 8 | caller_is_origin() | No | Yes | Missing Function Implementation on Integration Testing. | +| 9 | code_hash() | No | Yes | Missing Function Implementation on Integration Testing. | +| 10 | own_code_hash() | No | Yes | Missing Function Implementation on Integration Testing. | +| 11 | call_runtime() | No | Yes | Missing Function Implementation on Integration Testing. Unfeasible Implementation. | +| 12 | caller() | Yes | Yes | Ok. No difference observed in testing. | +| 13 | transferred_value() | Yes | Yes | Ok. No difference observed in testing. | +| 14 | weight_to_fee() | Yes | Yes | Implementation Difference. | +| 15 | block_timestamp() | Yes | Yes | Ok. No difference observed in testing. | +| 16 | account_id() | Yes | Yes | Ok. No difference observed in testing. | +| 17 | balance() | Yes | Yes | Implementation Difference. | +| 18 | block_number() | Yes | Yes | Ok. No difference observed in testing. | +| 19 | minimum_balance() | Yes | Yes | Ok. No difference observed in testing. | +| 20 | terminate_contract() | Yes | Yes | Ok. No difference observed in testing. | +| 21 | transfer() | Yes | Yes | Ok. No difference observed in testing. | +| 22 | hash_bytes() | Yes | Yes | Ok. No difference observed in testing. | +| 23 | hash_encoded() | Yes | Yes | Ok. No difference observed in testing. | +| 24 | ecdsa_recover() | Yes | Yes | Ok. No difference observed in testing. | + +In this milestone, we will develop the remaining functions that either lack implementations in integration tests or exhibit differences in implementation when compared to E2E tests. However, we will make exceptions for `gas_left()` and `call_runtime()`, as our analysis has deemed implementing these functions in integration tests unfeasible. + +**Observations for function `weight_to_fee()`:** + +For the function `weight_to_fee()`, we have observed in the [milestone report of our previous grant delivery](https://github.com/CoinFabrik/on-ink-integration-tests/blob/milestone-on-ink-integration-tests-2/assets/On-Ink-Integration-Tests-2-Milestone-Report.pdf) and in the provided [test case](https://github.com/CoinFabrik/on-ink-integration-tests/tree/main/test-cases/weight-to-fee) that the value obtained in e2e tests is fixed at 0 and cannot be modified. This incorrect behaviour of `weight_to_fee()` in E2E tests is also observed in paritytech/substrate-contracts-node. + +We have reviewed the function `weight_to_fee()` and found that it has multiple implementations. This complexity makes it challenging to identify which implementation is responsible for the E2E tests, especially given that the large size of the runtime significantly slows down debugging. + +To address this issue, we will submit an initial report to the ink! development team in the first week of this milestone and collaborate to devise an implementation plan. If we deem a resolution feasible, we will include it as part of this milestone. + + +## Development Roadmap :nut_and_bolt: + +### Overview + +- **Total Estimated Duration:** 4 weeks +- **Full-Time Equivalent (FTE):** 4 FTE (0.50 Project Manager, 0.50 Tech Lead, 1 Full time Sr Rust Developer, 1 Full Time SemiSr Rust Developer, 1 Full Time QA Specialist) +- **Total Costs:** 30,000 USD + +### Milestone 1: Execution +- **Estimated duration:** 4 weeks +- **FTE:** 4 +- **Costs:** 30,000 USD + +| Number | Deliverable | Specification | +| ----- | ----------- | ------------- | +| 0a. | License | MIT +| 0b. | Documentation | We will write a comprehensive report that compares the functionalities of integration tests and E2E (End-to-End) tests. This report will focus on the the functions to be implemented in this milestone, corresponding to issues `3-invoke_contract_delegate()`, `4-invoke_contract()`, `6-set_code_hash()`, `8-caller_is_origin()`, `9-code_hash()`, `10-own_code_hash()`, and `17-balance()`.
In the first week of this milestone, we will contact the ink! development team to provide an initial report on `14-weight_to_fee()`, documenting our efforts to identify the source of its implementation issues and seeking collaboration to assess the feasibility of resolving them. We will document any progress and implementations related to `14-weight_to_fee()` in our final milestone report.
We will document any additional work that was required in order to ensure consistency between integration and e2e tests.
If applicable, we will suggest additional tests outside of the scope of this milestone. Particularly, for functions declared outside of the `env_access.rs` file, but that could be related to integration or e2e testing. +| 0c. | Testing and Testing Guide | The newly developed functionalities will be documented and tested following existing [contribution guidelines](https://github.com/paritytech/ink/blob/master/CONTRIBUTING.md). A testing guide will be included. +| 0d. | Docker | Does not apply at this stage. +| 0e. | Article | We will publish an updated report summary in our blog at https://blog.coinfabrik.com/. + **1** | Development | We will implement the missing functionalities or resolve implementation differences for function issues `3-invoke_contract_delegate()`, `4-invoke_contract()`, `6-set_code_hash()`, `8-caller_is_origin()`, `9-code_hash()`, `10-own_code_hash()` and `17-balance()`.
We will also make the necessary changes to address the issues highlighted in our initial report on `14-weight_to_fee()`, provided that these changes are deemed feasible during our discussions with the ink! development team.
All these implementations or modifications will be pushed into the [ink! project repository](https://github.com/paritytech/ink) following existing [contribution guidelines](https://github.com/paritytech/ink/blob/master/CONTRIBUTING.md).
If applicable, we will develop additional tests or make ad hoc improvements to the ink codebase necessary for the completion of this milestone. Particularly for functions declared outside the `env_access.rs` file that might be related to integration or end-to-end testing. +**2** | Quality Assurance| We will adhere to existing [contribution guidelines](https://github.com/paritytech/ink/blob/master/CONTRIBUTING.md) and add necessary tests to integrate the new implemented or corrected functions to the [ink! project repository](https://github.com/paritytech/ink). + + +## Future Plans + +Moving forward, we have two projects in mind: +- Research and develop an advanced testing automation solution for ink! smart contracts. +- Improve our open source bug-detection tool [Scout](https://coinfabrik.github.io/scout/ ). + +## Referral Program (optional) :moneybag: + +## Additional Information :heavy_plus_sign: + +**How did you hear about the Grants Program?** Richard Casey from Parity brought this program to our attention, and we have already successfully delivered two applications as a result. + +During our inquiries for this application, we briefly consulted Sam Ruberti from the ink! Team and David Hawig from the Web3 Foundation. Their encouragement motivated us to proceed with this presentation. + diff --git a/applications/Contract_wizard.md b/applications/Contract_wizard.md index 4095fa0218f..488cc29d249 100644 --- a/applications/Contract_wizard.md +++ b/applications/Contract_wizard.md @@ -102,10 +102,10 @@ We are not only a dev shop company, but we create long term partnerships with th - https://github.com/protofire/kyber-pool-master-proxy-contract GitHub accounts of team members. -- https://github.com/alongoni
| -Number - | -Deliverable - | -Specification - | -
| 0a. - | -License - | -Apache 2.0 - | -
| 0b. - | -Documentation - | -We will provide inline documentation, video, medium articles & start creating the lightpaper of the project. - | -
| 0c. - | -Testing Guide - | -The code will have proper unit-test and guid coverage for Koi Metaverse modules - | -
| 1 - | -smart contract: NFT Lottery Draw - | -NFT lottery contract include: lottery function implemented by ink - | -
| 2 - | -smart contract: NFT Auction Sale - | -NFT auction contract include: fishList, fishGeneList, bid, refreshFishList, getMyFish functions implemented by ink - | -
| 3. - | -smart contract: NFT Minting - | -NFT minting contract include: myNft, getNft, earned, stakeNft, withdrawNft, withdrawNftAll, getReward functions implemented by ink - | -
| 4. - | -smart contract: Fish - | -fish contract include: gene, birthday, power, reproduction, growth implemented by ink - | -
| 5. - | -smart contract: Fish Tank - | -fish tank contract include: capacity, totalPower, fishList implemented by ink - | -
| 6a. - | -UI mock-ups - | -The UI design of product frontend and product workflow. - | -
| 6b. - | -Fish Genes and Images - | -The UI design and gene system of fish NFTs. - | -
| 7. - | -Front end - | -Implement web front-end based on react.js and polkadot.js. Modules include: NFT Lottery Draw, NFT Auction Sale, NFT Minting, Fish and Fish Tank. Fish Mining, Fish Breeding. - | -
| 8. - | -Test - | -We will provide a dockerfile to demonstrate the usage of our modules. - | -
+In the context of Substrate, the integration of Babe and Grandpa protocols, alongside the Staking Pallet, complements the PoCS mechanism +* Babe's deterministic block production process aligns with PoCS's commitment to security. Validators with higher reputation and weight history, as determined by the scarcity mapping, are incentivized to actively participate in proposing and validating blocks +* Staking Pallet (Validator Selection): The Staking Pallet integrates with PoCS as validators selected based on their scarcity scores, are entrusted with the responsibility of proposing and validating blocks. This delegation ensures that validators with a proven track record of actively participating in the network are granted the authority to contribute to the consensus process. +* Validator Reward Contract : Validator reward contract will act as a general middleware contract, which could be reusable across different apps/chains built over PoCS. We will build a validator contract which will not be a definitive but a reference contract which can be modified with a custom logic to implement custom reward distribution mechanisms.
+Outline of some basic functionalities: + 1. Claim Rewards: `claimRewards(address devAddress)` +This function allows a developer to claim their rewards from the Validator Reward. For this it will verify that the caller is the owner of the contract calling the function and ensure that the contract is delegated to the validator. + 2. Calculate Reward Percentage: `calculateRewardPercentage(address contractAddress)`: This function calculates the percentage of rewards that the developer is eligible to claim based on the stake score of the associated contract. + 3. Transfer Rewards: `transferRewards(address devAddress, uint256 rewardAmount)` +: This function transfers the calculated rewards to the developer from the contract. It ensures that the reward amount is valid and available in the contract. + + + Protocol design
+
+ 
+
2. Add attributes to PoCS pallet and derive them. (eg: Contract scarcity struct, its related mappings etc ) | + +### Milestone 2 — Pallet staking Update + +- **Estimated duration:** 6 weeks +- **FTE:** 3-3.5 +- **Costs:** 10,000 USD + +| Number | Deliverable | Specification | +|--------|:-------------------------:|:-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------:| +| 0a. | License | Apache 2.0 | +| 0b. | Documentation | Inline documentation of the code and a basic tutorial | +| 0c. | Testing and Testing Guide | Unit testing and testing tutorial| +| 0d. | Docker | Create docker image with updated pallets +| 0e. | Article | Publish article for integrations and additions of new pallet logic| +| 1. | Modify pallet staking for PoCS | Add custom functions and modify some existing functions of pallet staking and pallet contract to implement our attributes and make the pallets interact accordingly | + +### Milestone 3 — Validator Reward Contract, Testing and Documentation + +- **Estimated duration:** 5 weeks +- **FTE:** 3 +- **Costs:** 8,000 USD + +| Number | Deliverable | Specification | +|--------|:-------------------------:|:-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------:| +| 0a. | License | MIT license | +| 0b. | Documentation | Inline documentation of the code and a external contract documentation
We will publish an article/workshop that explains inner workings of PoCS and developer guide to build a PoCS enabled Substrate chain| +| 0c. | Testing and Testing Guide | Unit testing with our validator reward ink! contract | +| 0d. | Docker | Create docker image for entire consensus +| 0e. | Article | Publish lite paper for the consensus | +| 1 | Contract development | Design and implement a validator reward contract. (i.e Co-ordinator contract for rewarding).
Integrate it with PoCS consensus | +| 2. | Alpha testing and publish paper | Alpha testing of entire consensus. Since it is a new consensus design, we have a separate milestone for analyzation of results over conducting an end to end test of the protocol
Standalone yellow paper| + + +## Future Plans + +Once completed with this grant milestones, +- Further research on democracy and validator penalty conditions +- Moving towards testnet launch as a sister chain to Polkadot. Since it is first of its kind we will be actively discussing our future plans and research directions with the community. +- We will be focussing more on making PoCS pallets interoperable with current popular Substrate pallets. + +## Referral Program :moneybag: + +- **Referrer:** muddlebee(Anwesh) +- **Payment Address:** 14btqGNtzVpfwW9y5xYrcK7uSfgjGZKxcYAG3fJo6ujHUVS (Polkadot Asset Hub) + +## Additional Information :heavy_plus_sign: + +**How did you hear about the Grants Program?** + +Through recommendation from [Builders Tribe](https://buidlerstribe.com/) to apply for W3F grants + +**If there are any other teams who have already contributed (financially) to the project.** + +No, Self Funded + +**Previous grants you may have applied for** + +No diff --git a/applications/PolkaSignIn.md b/applications/PolkaSignIn.md index d3c06fa5f63..0f14601fd54 100644 --- a/applications/PolkaSignIn.md +++ b/applications/PolkaSignIn.md @@ -211,15 +211,15 @@ There is few solution combine the OAuth and self-custody wallet, and no such sol ### Team Code Repos -*
+ 
+
+ 
+
+ 
+
+ 
+
+ 
+
+ 
+
+ 
+
+ 
+
Winners:
@@ -103,14 +103,14 @@ e.g. If the total funding pool has $50000, you can’t assign a value larger tha
2) Then, we will have a percentage Schelling game to predict the price. That is, you can predict whether to increase or decrease the funding amount in percentage. Remember, it can’t be larger than (Total funding pool amount)^(4/5). Score values will remain from -10 to +10, -10 means 100% decrease, +10 means 100% increase
The range of -10 to +10 has a problem because the mean works best without extreme values. So, if someone gives -10, and others give 1, the mean result can get screwed due to the -10 outlier. So the trick is to remove outliers by computing the standard deviation. Remove all values more than one standard deviation away from the mean. Then, we calculate the new mean of the left values (it consists of 68.27% data of the set).
Code to calculate new mean:
-
3) Then, we will do quality score voting Schelling game that checks the project meets the quality guidelines. The score range is 0-5
4) The amount of funding will be directly proportional to (Predicted Price) * (Quality Score/5*2)
Code:
-
+
+### Overview 🎨
+
+ParaSpell is currently split into three main repositories at the moment. XCM Router, XCM API and XCM SDK will be merged into one monorepo package with the intention of sharing types and saving code:
+
+- XCM ROUTER - TBA: Meant to give developers the ability to exchange and transfer assets in one call in a seamless way that allows them to lift complexity from users.
+- [XCM SDK](https://github.com/paraspell/xcm-sdk): Meant to unify cross-chain experience on Polkadot and become a layer 2 protocol that allows for seamless integration of XCM into your dApps.
+- [XCM API](https://github.com/paraspell/xcm-api): Meant to ease the integration of XCM interoperability into your dApp, offload your dApp from heavy computing and save you costs.
+- [Docs](https://github.com/paraspell/docs): Extensive documentation for an overview of ParaSpell, a guide for SDK and API
+
+#### XCM SDK
+
+Few facts about XCM SDK:
+- The core component for XCM API
+- Comprehensive unification of XCM from 43 different Parachains
+- Allows for creating XCM calls with one-line
+- Simple to implement typescript package
+- Completely free with an MIT license
+
+XCM SDK allows developers to use XCM in all three available scenarios:
+- Parachain to Parachain - HRMP
+- Parachain to Relay chain - UMP
+- Relay chain to Parachain - DMP
+
+SDK contains many useful features that allow for easier integration:
+- Builder pattern implementation, easy to construct XCM calls, much more used recently for simplicity of implementation.
+
+- Suggestions, SDK contains TYPES that help to guide developers through integration. For example, they show compatible Parachains that can be used in calls.
+
+
+- Console printouts, SDK allows for printing into the console so developers can always check if the call they constructed is correct.
+
+
+- Exporting registered assets for each compatible node in many useful functions
+
+- Exporting supported XCM pallets for each compatible node in useful functions
+
+And more.
+
+#### XCM API
+XCM API currently supports 43 (this number changes a lot) XCM-compatible Parachains. It brings lots of advantages for developers.
+The advantages of LightSpell⚡️ XCM API for developers:
+- Provides the same functionality as XCM SDK with many benefits
+- Built-in user error prevention for seamless operation
+- Built-in Token authentication for DDoS prevention
+- Easy to use tech stack: Typescript, Nest.js, ParaSpell XCM-SDK
+- Completely free with an MIT license
+- Also designed for simple private deploy
+- API Offloads your server from heavy computing required to construct calls (You receive constructed message already)
+- API saves you server costs (Because of the reason mentioned above)
+- API features Package-less integration (No need to install anything compared to SDK alternatives)
+- API is simple to implement (Constructed to be as dev-friendly as possible)
+- API is already live on the following link: https://api.lightspell.xyz
+
+#### Docs
+Meet our comprehensive docs covering just about every topic developers will meet with when implementing XCM and our tools into their dAPPs.
+
+
+
+#### Architecture 🏗️
+##### Old
+The old design had SDK integrated into dApp:
+
+
+
+The replacement design with XCM API, there is no need for integrating XCM SDK. There is only a need to send the request. No more installing packages. Works way faster and offloads dApp from heavy computing to generate calls.
+
+
+
+##### New
+The newest architecture is similar to the one before it, however, dApps will now be able to call XCM Router through XCM API or integrate it as an independent package. XCM Router will benefit users with ease of exchanging and transferring assets to another chain as well as developers who can hide complex logic from users and integrate this feature with ease without the need for extensive research.
+
+
+
+This architecture is only proof of concept architecture. The final architecture may differ a little (Mostly because we want to make this as efficient as possible so if we find a better solution we will instead resort to it.
+#### Technology Stack 💻️
+- Vue.js
+- Node.js
+- Typescript
+- Polkadot API libraries
+- Nest.js
+
+### Ecosystem Fit 🌳
+
+#### XCM Router
+We strive to bring state-of-the-art technology to the ecosystem with any bright idea we get. SpellRouter XCM Router is no different. The implementation would become the first XCM Router in the Polkadot ecosystem.
+
+We aim to achieve XCM Router functionality by building a sovereign typescript package (for those who wish to implement it as a package) that will also be implemented in LightSpell XCM API (for those implementing LightSpell XCM API already). The core component for generating XCM calls will be ParaSpell XCM SDK. Other functionality regarding exchanges and logic will be unique to the Router itself. The XCM router will serve ecosystem users to transfer their assets cross-chain while giving them the ability to exchange them into different assets all in just one call (3 signatures). There were numerous suggestions for this tool in the ecosystem. Mainly because it brings the following benefits:
+
+- Ability to transfer assets cross-chain via XCM while being able to exchange them for another asset all within one call.
+- Offlift users from the complexity of moving assets to another chain in order to exchange tokens just to send them to another chain later
+- Developers able to hide asset exchange complexity and skip multiple implementation steps
+- Developers save the time required for complex research
+- Complex logic hidden in simple one-line calls
+
+An example of a Router call can be seen below:
+
+
+The choice of exchange Parachain will be automatic in a later version of XCM Router so users will only have to select exchange Parachain manually if they wish to.
+
+A high overview of Router functionality can be seen below:
+
+
+
+
+#### XCM API
+As mentioned in a tweet from Alice&Bob, we need Chain APIs to put XCM on steroids - [link](https://twitter.com/alice_und_bob/status/1664564442456109057?cxt=HHwWgsC9pdGi3JkuAAAA).
+
+We aim to achieve this by utilizing the XCM-SDK technology we built previously.
+Using XCM API compared to implementing XCM SDK into dApp can bring three main benefits:
+- Calls are generated much quicker
+- API is much simpler to implement than SDK
+- No need to install anything (Comes with the benefit of saving space and without issues with dependencies)
+
+Why we chose NestJS for XCM API:
+By choosing Nest.js as our backend HTTP REST API framework, we can harness the power of Node.js, leverage TypeScript's benefits, ensure maintainability through its modular architecture, and take advantage of its extensive community support. This enabled us to build a reliable, scalable, and well-documented XCM API that seamlessly integrates with the existing XCM SDK. In addition, Nest.js offers a powerful code generation feature that allows us to quickly scaffold boilerplate code for controllers, services, modules, and more. By utilizing the Nest.js code generator, we can significantly reduce development time and effort, ensuring rapid prototyping and efficient implementation of the XCM API endpoints. Compared to other TypeScript frameworks, Nest.js stands out with its modular architecture, seamless integration with Node.js, and strong community support, offering developers a scalable and maintainable solution.
+
+As API is now fully implemented we can observe its metrics for the first month it is deployed:
+
+
+We can see, that API serves between 500 to 1000 requests in a day. API uptime is 100%. API is completely free for everyone to use, implement or privately deploy.
+It now features various error prevention mechanisms (Valid wallet address check) and analytic tools to report errors that are not handled by API or report API usage (Strictly without collecting any sensitive user data).
+
+#### XCM SDK
+
+There are not many XCM & XCMP-related development tools released currently. We aim to aid this mostly empty space and help developers understand XCM & XCMP as the current state-of-the-art technology by providing documentation and a set of tools which help them do development tasks more easily and faster.
+
+In Polkadot and Kusama ecosystems, there are few XCM-related tools in development. For example, Moonbeam XCM SDK and Parity Asset Transfer API. We bring a comparison table that compares them to our ParaSpell XCM SDK.
+| Features | ParaSpell XCM SDK | Moonbeam XCM SDK | Parity Asset Transfer API|
+| -----: | ----------- | ------------- | -----------|
+|UMP Support|Implemented|Implemented|Implemented (only for 2 Chains)|
+|DMP Support|Implemented|Implemented|Implemented (only for 2 Chains)|
+|HRMP Support|Implemented|Implemented|To be implemented|
+|No. of chains implemented|45 incl. Relay chains (To change to more chains with next update)|42 incl. Relay chains|4 incl. Relay chains|
+|Support for NFT transfers|Planned to be implemented|Not implemented| Planned to be implemented|
+|Multi-asset transfer support|Planned to be implemented|Not implemented|Planned to be implemented|
+|Multi-location specification|Automatic|Automatic|Required in some scenarios|
+| Build pattern | Integrated as intuitive as possible | Integrated, not as intuitive to implement however | Only function style call construction|
+| Support for asset pallet operations | Integrated | Not integrated | Not integrated|
+| Support for HRMP Channel operations | Integrated users can open & close HRMP channels on their local chain (Useful feature for devs) | Not integrated | Not integrated|
+| Support for checking details that do not change | Integrated & also be covered with some error handling eg (too little amount being sent, not sufficient for XCM transfer) | Integrated in the form of a small "map" for different Tokens & Node IDs | Integrated in form of Map|
+
+We are currently in talks with several Parachain teams that like the idea of unified SDK for XCM transfers as much as we do. SDK that unifies XCM can be very helpful for the entire ecosystem in our opinion. With the introduction of XCM API and soon XCM Router this improves even further.
+
+Our target audiences are Web3 projects and starting/current blockchain developers.
+
+As SDK is also fully developed and its metrics are available to the public we can see, that it is still used a lot by developers in the ecosystem (Even after the API release).
+
+
+## Team :busts_in_silhouette:
+
+### Team members
+
+Dušan Morháč - Student, project Founder & Core Dev. Faculty of Informatics and Information Technologies STU in Bratislava
+
+Michael Absolon - Student, XCM SDK & XCM API Core Dev. Faculty of Informatics and Information Technologies STU in Bratislava
+
+### Contact
+
+- **Contact Name:** Dušan Morháč
+- **Contact Email:** dudo.morhac@gmail.com
+
+
+### Legal Structure
+
+- **Registered Address:** Tomášovská 453/2 Kalinovo 98501 Slovakia
+- **Registered Legal Entity:** Adam Morháč
+
+### Team's experience
+- Dušan is the founder & researcher behind this project and he has successfully presented it at the international conference ICECET2022 held in Prague from which there is an article regarding the XCMP & ParaSpell project. It is published by IEEE - [link](https://ieeexplore.ieee.org/document/9872938). He also successfully presented it at the ICBC 2023 conference held in Dubai. The article was published in [IEEE Enhancing XCMP Interoperability Across Polkadot Paraverse | IEEE Conference Publication](https://ieeexplore.ieee.org/document/10174872). Dušan studies Blockchain technology and had a bachelor's thesis about cross-blockchain sharing from which this idea was born. Dušan continues research on this idea in his Master's thesis. He is actively working on [LightSpell and ParaSpell](https://github.com/paraspell) full-time & has also participated in other ecosystem projects. Recently he attended Polkadot Blockchain Academy 2023 in Buenos Aires which gave him a lot of insight into the ecosystem and he also graduated from the academy successfully. Here is the [NFT that was minted as a certificate by Parity](https://singular.app/collectibles/statemine/20/12).
+
+And here is a certificate in physical form:
+
+
+
+- Michael is a dedicated TypeScript developer with 2 years of full-time experience in the Web2 sphere. Michael's expertise in this field was further solidified in 2019 when he won first place in the Junior Internet Web competition for his online multiplayer game, which was written in JavaScript. In addition to his professional background, Michael also achieved a bachelor's degree in the same computer science University as Dušan and he is currently pursuing a master's degree which focuses on Blockchain. His passion for technology led him to explore Blockchain technology in his free time. He was recently offered the opportunity to work on ParaSpell XCM SDK & LightSpell XCM API with Dušan and he delivered many of the key features SDK & API now offer.
+### Team Code Repos
+
+- https://github.com/paraspell/xcm-api
+- https://github.com/paraspell/xcm-sdk
+- https://github.com/paraspell/docs
+
+### Team Github Profiles 🧑🎓
+
+- https://github.com/dudo50 Dušan Morháč
+- https://github.com/michaeldev5 Michael Absolon
+
+### Team LinkedIn Profiles 🧑🎓
+
+- https://www.linkedin.com/in/dudo50/
+- https://www.linkedin.com/in/michael--absolon/
+
+## Development Status :open_book:
+We are currently finishing maintenance tasks and issues that are open in XCM SDK, XCM API and Docs repositories. After that, we wish to shift our focus to the development of an XCM Router which we already have laid out the structure for and we have basic functionality laid into small steps that will help us achieve making this state-of-the-art technology.
+
+As there are no XCM Routers currently in the ecosystem, this challenging task motivates us to fill the gap once again (Just like with XCM API).
+
+## Development Roadmap :nut_and_bolt:
+
+### Overview
+
+- **Total Estimated Duration:** 5 months
+- **Full-Time Equivalent (FTE):** 1 FTE
+- **Total Costs:** 22 000 USD
+
+### Milestone 1 - Create XCM Router and move all three tools into Monorepo
+
+- **Estimated duration:** 3 months ⌛️
+- **FTE:** 1
+- **Costs:** 12 000 USD 💰️
+
+| Number | Deliverable | Specification |
+| -----: | ----------- | ------------- |
+| 0a. | License | MIT |
+| 0b. | Documentation | We will provide both readme.md and official docs documentation |
+| 0c. | Testing and Testing Guide | Testing guide will be mentioned in official docs|
+| 0e. | Create Medium article about development of early Router | Add article covering early XCM Router version |
+| 1.a | Integrate early version of XCM Router I| This version will contain additional detail about exchange Parachain (XCM Router will not select exchange automatically yet, the developer has to select from a provided list). The first version will feature functions like patterns to create calls. [See an example of function pattern](https://paraspell.github.io/docs/sdk/xcmPallet.html#function-pattern-xcm-call-from-relay-chain-to-parachain) |
+| 1.b | Integrate early version of XCM Router II| Compared to the first version, this version will feature a Builder pattern to enhance the developer experience. [See an example of builder pattern](https://paraspell.github.io/docs/sdk/xcmPallet.html#builder-pattern-xcm-call-from-relay-chain-to-parachain) |
+| 2. | Update docs to cover early XCM Router version| Add comprehensive guide that covers usage of early XCM Router version|
+|3.|Create unit tests for XCM Router|Create unit tests for core features in XCM Router|
+
+### Milestone 2 - Enhance XCM Router and feature automatic tool updating
+
+- **Estimated duration:** 2.5 months ⌛️
+- **FTE:** 1
+- **Costs:** 10 000 USD 💰️
+
+| Number | Deliverable | Specification |
+| -----: | ----------- | ------------- |
+| 0a. | License | MIT |
+| 0b. | Documentation | We will provide both readme.md and official docs documentation |
+| 0c. | Testing and Testing Guide | Testing guide will be mentioned in official docs|
+| 0e. | Create Medium article about development of latest XCM Router | Add article covering new features & improvements brought with SpellRouter☄️ |
+| 1. | Integrate automatic exchange chain selection into XCM Router | Integrate automatic exchange chain selection into the router (If the user wishes they can manually insert it otherwise Router will select automatically). XCM Router will try to select an exchange with the best pool/price. To see the difference between automatic and manual selection feel free to see the [following image](https://user-images.githubusercontent.com/55763425/277431789-cc3892dc-4452-49e1-a201-19edbc6f20d8.png)|
+| 2. | Integrate XCM Router into LightSpell XCM API | Integrate core functionality of XCM Router into LightSpell XCM API |
+|3.a| Update unit tests for new XCM Router functionalities| Update unit tests for new XCM Router functionalities|
+|3.b| Create integration tests for XCM Router|Create integration tests for core features in XCM Router|
+|3.c| Update integration, unit and e2e tests for LightSpell XCM API| Add new integration,unit & e2e tests for core LightSpell XCM API XCM Router integration|
+| 4.a | Cover latest automatic exchange chain selection in XCM Router section (Docs) | Add comprehensive guide covering automatic selection in XCM Router section |
+| 4.b | Cover XCM Router integration in XCM API section (Docs) | Cover XCM Router integration in LightSpell XCM API Section |
+
+## Future Plans 🔭
+- We wish to implement XCM v3 NFT transfer support
+- Once XCMP is out, we deprecate HRMP in SDK in favour of it.
+- Continue shaping XCM API to be as developer-friendly as possible
+- Continue gaining project integrations
+- Make sure XCM API uptime is nearing 100% and API works as should at all times
+- Improve XCM Router and add new ways to simplify call constructions
+
+Our focus will always remain on developer experience as well as being open source, completely free, common good and helpful to others.
+Another future goal that we try to keep is to continue innovating in the XCM area - bringing new state-of-the-art tech.
+
+## Additional Information :heavy_plus_sign:
+
+**How did you hear about the Grants Program?** Personal recommendation
+
+##### Project achievements in chronological order ⌛️
+
+- 📙 Article about the project created & presented at international conference ICECET2022 held in Prague (450 out of 1000+ articles accepted) Link to IEEE publication - [IEEE Sharing Fungible Assets Across Polkadot Paraverse](https://ieeexplore.ieee.org/document/9872938/)
+- 🥈 2nd Prize, Build an XCM-related Tool for Moonbeam - Polkadot North America Hackathon [Hackathon entry](https://devpost.com/software/polkachange-cross-blockchain-transfer-tool)
+- 🥉 3rd Prize, EVM+ DApp for aUSD yield - Polkadot North America Hackathon [Hackathon entry](https://devpost.com/software/polkachange-cross-blockchain-transfer-tool)
+- 🎈 Web 3 Foundation base grant [Application](https://github.com/w3f/Grants-Program/pull/1118), [Delivery](https://github.com/w3f/Grant-Milestone-Delivery/pull/584)
+- 🐍 [Basilisk](https://bsx.fi/) treasury proposal 2 / 2 Approved [link](https://basilisk.subsquare.io/treasury/proposal/2), [link2](https://basilisk.subsquare.io/treasury/proposal/4)
+- 🔭 Web 3 Foundation phase 2 grant Milestone 3 / 3 delivered [Application](https://github.com/w3f/Grants-Program/pull/1245), [Delivery1](https://github.com/w3f/Grant-Milestone-Delivery/pull/670), [Delivery 2 & 3](https://github.com/w3f/Grant-Milestone-Delivery/pull/715)
+- 📕 Article about Polkadot & ParaSpell created & accepted to be presented at international cross-chain conference IEEE ICBC 2023 held in Dubai - [IEEE Enhancing XCMP Interoperability Across Polkadot Paraverse](https://ieeexplore.ieee.org/document/10174872)
+- 💼 Kusama Treasury Funding proposal number 1 - Upgrade SDK, [Application](https://kusama.subsquare.io/referenda/referendum/123s), [Delivery](https://docs.google.com/document/d/1lMY_8EtQ41IX7Zn9VIMAiG1k3oLYN0h_lVj8dWDwZ_k/edit?usp=sharing)
+- 🏗️ Web 3 Foundation phase 3 grant (Make SDK better) Milestone 1 / 1 delivered [Application](https://github.com/w3f/Grants-Program/pull/1589), [Delivery](https://github.com/w3f/Grant-Milestone-Delivery/pull/836)
+- 📘 Article about Polkadot & ParaSpell created & accepted to be presented at international cross-chain conference IEEE BCCA 2023 held in Kuwait [links TBA]
+- 🥈 Second place at sponsored prices Polkadot Global Series APAC 2023 Hackathon: Build a Connected Contract With Moonbeam [Linkedin post announcement](https://www.linkedin.com/posts/angelhack_polkadothackathonapac-koreablockchainweek-activity-7097217757724758016-8pJ_?utm_source=share&utm_medium=member_desktop)
+- 🥇 First place at Polkadot Global Series APAC 2023 Hackathon Finale [Finalist announcement post](https://www.linkedin.com/posts/angelhack_polkadothackathonapac-koreablockchainweek-activity-7097217757724758016-8pJ_?utm_source=share&utm_medium=member_desktop), [Final result](https://drive.google.com/drive/folders/1YxFJ4NO9_mMyNsXoPKboFfYHwHM1AJHv?usp=sharing), [Final result announcement post](https://www.linkedin.com/posts/angelhack_polkadothackathonapac-activity-7108072292718428160-i1dr?utm_source=share&utm_medium=member_desktop)
+- 🚀 Web 3 Foundation phase 4 grant (Build XCM-API) Milestone 1 / 1 delivered [Application](https://github.com/w3f/Grants-Program/pull/1817), [Delivery](https://github.com/w3f/Grant-Milestone-Delivery/pull/972)
+- 👷♂️ Maintenance funded by Kusama treasury from October 2023 until February 2024 [Referenda link](https://kusama.polkassembly.io/referenda/277)
diff --git a/applications/SpiderDAO.md b/applications/SpiderDAO.md
index 028a1ab0ba5..d3a81b81b1e 100644
--- a/applications/SpiderDAO.md
+++ b/applications/SpiderDAO.md
@@ -2,7 +2,7 @@
-* **Proposer:** [SpiderDAO] (* Study existing solutions and designs to see what technologies and approaches can be leveraged vs. being created
* Research decentralized storage competitive projects, including but not limited to Filecoin, Arweave, Sia, Storj as well as existing storage work in the Polkadot ecosystem
* Examine trade offs other decentralized storage providers have made including, but not limited to retrieval times, small v. large files, resiliency, cost efficacy, security & privacy, redundancy, user learning curve and environmental sustainability
* Begin to design features compatible with Polkadot’s technical approach and philosophy
* The research & design document will include the gathered requirements and the list of researched solutions & features that could meet those requirements, as well as all supporting evidence and documentation that led to those proposed requirements and features. The document will also expand its research on the “Key Questions and Anticipated Challenges” section | +| **0c.** | Feature Analysis | * In depth research of the technical feasibility of key features and components
*Evaluation of proposed feature sets, inclusive of a detailed compatibility/tradeoff matrix leading to a clearly defined set of proposed StorageHub features
* Stakeholders will be asked to provide feedback on those compatibility/tradeoffs and to help choose a good combination of features
* Definition and documentation of key use cases and scenarios | +| **0d.** | Article | * The main deliverable for the first month is v0.5 of the research & design document. The research and design document will include the feature analysis, proposed MVP feature set including key use cases, and address the points in (0b.) and (0c.) | + +### Milestone #2: Technical Deliverables +* Estimated Duration: 1 month +* FTE: 2.5 +* Costs: $42,250 (USD) + +| Number | Deliverable | Specification | +| -----: | ----------- | ------------- | +| **0a.** | License Type | CC BY 4.0 / GPLv3 | +| **0b.** | Documentation | * For the second milestone we will provide v1.0 of the research & design document. The v1.0 document will include a high level technical design & architecture of StorageHub, including major subsystems, incorporating and building upon research from the first v0.5 milestone
* This v1.0 research and design document will be shared with key stakeholders to obtain specific feedback that will help us continue to refine StorageHub
* In addition to this, we will also begin to build prototype code that supports and tests the v1.0 technical design considerations. A basic tutorial will be included that explains how a user can run our prototype code and send test transactions | +| **0c.** | Testing & Testing Guide | * Software developed for this milestone will be prototype quality, and thus will not have the tests required for production deployment. However, the prototype code will be sufficient to demonstrate viability or compatibility of key aspects of the design approach
* As outlined in (0b.), a basic tutorial will be included that explains how a user can run our prototype code and send test transactions | +| **0d.** | Docker | * We will provide a Dockerfile(s) that can be used to run the prototype associated with this milestone | +| **0e.** | Prototype Code | * We will create a Substrate and or RUST prototype to validate proposed designs described in the v1.0 design doc. In particular, the approach for the data provider role, and being able to store data in a redundant fashion, and retrieve data from the provider
* The source code for the prototype will be delivered as part of the second month milestone. The prototype will have limited features (e.g. not decentralized, limited API, etc) or might not be complete but will provide sufficient functionalities to demonstrate key parts of the proposed design
* We will provide a Dockerfile(s) that can be used to run the prototype associated with this milestone | +| **0f.** | Resource Estimation & Planning | * Estimate the time, budget, and resources required to implement a minimum viable feature set for the project
* Break down the feature into smaller tasks or user stories
* Create a proposed project plan that includes implementation milestones, and responsibilities
* Include proposed next steps in the research and design doc | +| **0g.** | Article | * The main deliverables for this milestone are defined as below
* Progressing the v0.5 document to a v1.0 state outlined in section (0b.)
* A Substrate and or RUST prototype to validate proposed designs described in the v1.0, outlined in section (0e.)
* A basic tutorial will be included that explains how a user can run our prototype code and send test transactions outlined in section (0c.) | + + +## Future Plans +* We are currently in the process of hiring fulltime resources that will be dedicated to this engineering effort. +* The intended long term plan is to successfully complete this initial grant to then set us up to apply for a follow on long term grant diff --git a/applications/SubDAO-Chrome-Extension.md b/applications/SubDAO-Chrome-Extension.md index 218b582fee8..0408a53932c 100644 --- a/applications/SubDAO-Chrome-Extension.md +++ b/applications/SubDAO-Chrome-Extension.md @@ -5,7 +5,7 @@ ## Project Overview :page_facing_up: -The previous application [SubDAO Network Application -
-
-Ecosystem metrics dashboards - The on-chain data is visually presented through charts that are categorized into the most significant and essential aspects:
-
+Dashboards overview - The overview of currently indexed and supported parachains:
+
+Ecosystem metrics dashboards - The on-chain data is visually presented through charts that are categorized into the most significant and essential aspects:
+
-Filtering - The ability to sort data based on the most useful indicators:
-
+Filtering - The ability to sort data based on the most useful indicators:
+
- -User activity analytics - A module that allows for an in-depth analysis of user behavior based on metrics such as DAU, MAU, retention or user segments:
-
+User activity analytics - A module that allows for an in-depth analysis of user behavior based on metrics such as DAU, MAU, retention or user segments:
+
#### **Proposal mockups - new standalone features:** -Dashboard creator - The drag and drop feature allows users to add metrics onto the dashboard:
-
+ +Dashboard creator - The drag and drop feature allows users to add metrics onto the dashboard:
+
Layout composer - Allowing for an easy modification of the dashboard's layout: -
+
-
+
**Technology Stack:** @@ -196,6 +196,7 @@ Tokenguard's public features and data are already being used by community users
+
## Team 👥
### Team members
@@ -228,10 +229,11 @@ Tokenguard’s clients include Swiss Sygnum Bank, [Bitcoin.com](http://bitcoin.c
### Current Traction & Business Model ###
Our current business model focuses on offering growth analytics solutions for parachains & dApps and allowed us to validate both product and services through collaborations with notable parachains such as Astar and Aleph Zero. We believe that **delivering free of charge community analytics will further enhance discovery of growth insights within the whole ecosystem**, allowing it to win the race for leading position in the web3 space.
-Teams we cooperate with appreciate our flexibility and user-oriented approach:-
*Tokenguard is the missing part for Astar ecosystem. Its analytics and tracking capabilities provide us with the crucial insights needed to understand on-chain activity and user behavior, allowing us to make data-driven decisions and optimize our strategies like never before.* **Maarten Henskens, Head of Foundation, Astar Network**
-
*We are happy to use Tokenguard, which offers Aleph Zero comprehensive on-chain user metrics and engagement data. Thanks to their analytics tool, we can make data-driven decisions and provide transparency to our community with easy-to-use dashboards.* **Antoni Zolciak, CMO, Aleph Zero**
+Teams we cooperate with appreciate our flexibility and user-oriented approach:
+
*Tokenguard is the missing part for Astar ecosystem. Its analytics and tracking capabilities provide us with the crucial insights needed to understand on-chain activity and user behavior, allowing us to make data-driven decisions and optimize our strategies like never before.* **Maarten Henskens, Head of Foundation, Astar Network**
+ +
*We are happy to use Tokenguard, which offers Aleph Zero comprehensive on-chain user metrics and engagement data. Thanks to their analytics tool, we can make data-driven decisions and provide transparency to our community with easy-to-use dashboards.* **Antoni Zolciak, CMO, Aleph Zero**
### Team Code Repos * [https://github.com/tokenguardio](https://github.com/tokenguardio) @@ -271,12 +273,12 @@ This proposal is the first part that is solely focused on preparation of the das | Number | Deliverable | Specification | TechStack | | ---| ---| --- | --- | -|
**0a.**
| License | MIT | --- | -|
**0b.**
| Documentation | We will provide inline documentation. | --- | -|
**0c.**
| Testing and Testing Guide | Core functions will be fully covered by comprehensive unit tests to ensure functionality and robustness. We will describe how to run these tests. | --- | -|
**0d.**
| Docker | We will provide a Dockerfile that can be used to test all the functionality delivered with this milestone. | --- | -|
1.
| Metrics visualisation
| Allowing visualisation from RAW data:
1. Data selection interface for user including axis and scale setup,
2. Creating a preliminary visaulisation design standard of common data types,
3. Preparing 5 customisable visualisation types which include linechart, barchart, piechart, multiline chart, stacked barchart.
4. Creating a mechanism to customize the visualisations for differently branded projects | ReactJS, MongoDB, Apache ECharts | -|
2.
| Dashboard layout | Creating a dashboard composer which allows:
1. Creating, saving, modifying and deleting new and existing dashboards,
2. Populating a dashboard with visualised metrics with drag & drop method,
3. Modifying the dashboard layout - changing the positions of charts, resizing and deleting them.
4. Enriching the dashboard with captions, titles and links. | ReactJS, React Grid Layout, MongoDB | +|
**0a.**
| License | MIT | --- | +|
**0b.**
| Documentation | We will provide inline documentation. | --- | +|
**0c.**
| Testing and Testing Guide | Core functions will be fully covered by comprehensive unit tests to ensure functionality and robustness. We will describe how to run these tests. | --- | +|
**0d.**
| Docker | We will provide a Dockerfile that can be used to test all the functionality delivered with this milestone. | --- | +|
1.
| Metrics visualisation
| Allowing visualisation from RAW data:
1. Data selection interface for user including axis and scale setup,
2. Creating a preliminary visaulisation design standard of common data types,
3. Preparing 5 customisable visualisation types which include linechart, barchart, piechart, multiline chart, stacked barchart.
4. Creating a mechanism to customize the visualisations for differently branded projects | ReactJS, MongoDB, Apache ECharts | +|
2.
| Dashboard layout | Creating a dashboard composer which allows:
1. Creating, saving, modifying and deleting new and existing dashboards,
2. Populating a dashboard with visualised metrics with drag & drop method,
3. Modifying the dashboard layout - changing the positions of charts, resizing and deleting them.
4. Enriching the dashboard with captions, titles and links. | ReactJS, React Grid Layout, MongoDB | @@ -287,12 +289,12 @@ This proposal is the first part that is solely focused on preparation of the das | Number | Deliverable | Specification | TechStack | | ---| ---| --- | --- | -|
**0a.**
| License | MIT | --- | -|
**0b.**
| Documentation | We will provide inline documentation. | --- | -|
**0c.**
| Testing and Testing Guide | Core functions will be fully covered by comprehensive unit tests to ensure functionality and robustness. We will describe how to run these tests. | --- | -|
**0d.**
| Docker | We will provide a Dockerfile(s) that can be used to test all the functionality delivered with this milestone. | --- | -|
1.
| API reading mechanism | Connecting frontend visualisations with underlying data through an API:
1. Description and schema for an API response,
2. Saving and modifying visualisation related data,
3. Saving and modifying dashboard related data,
4. Collecting user data in relation to dashboard and chosen metrics. | NodeJS, Express, OpenAPI, MongoDB | -|
3.
| Report & estimation | Detailed report on the dashboard composer design and cost estimation of all the features mentioned in "Project details" as well as additional features requested by Web3 Foundation.| --- | +|
**0a.**
| License | MIT | --- | +|
**0b.**
| Documentation | We will provide inline documentation. | --- | +|
**0c.**
| Testing and Testing Guide | Core functions will be fully covered by comprehensive unit tests to ensure functionality and robustness. We will describe how to run these tests. | --- | +|
**0d.**
| Docker | We will provide a Dockerfile(s) that can be used to test all the functionality delivered with this milestone. | --- | +|
1.
| API reading mechanism | Connecting frontend visualisations with underlying data through an API:
1. Description and schema for an API response,
2. Saving and modifying visualisation related data,
3. Saving and modifying dashboard related data,
4. Collecting user data in relation to dashboard and chosen metrics. | NodeJS, Express, OpenAPI, MongoDB | +|
3.
| Report & estimation | Detailed report on the dashboard composer design and cost estimation of all the features mentioned in "Project details" as well as additional features requested by Web3 Foundation.| --- | diff --git a/applications/TreasuryTracker.md b/applications/TreasuryTracker.md index 372dfdbbb36..c9bd57cb470 100644 --- a/applications/TreasuryTracker.md +++ b/applications/TreasuryTracker.md @@ -75,7 +75,7 @@ The target audience for our platform includes token holders interested in the lo While there are no projects in the ecosystem that address treasury components and provide the same level of analytics as our proposed platform, there are a few with related functionalities: - [doTreasury](https://www.dotreasury.com/dot/) focuses solely on treasury statistics, lacking the wider analytical range that our project aims to offer -- [Grant Management Web Application RFP](https://github.com/w3f/Grants-Program/blob/master/docs/RFPs/Under%20Development/grant_management_webapp.md) are focused on the W3F grants UI and are not including the analytics component our platform intends to deliver. +- [Grant Management Web Application RFP](https://github.com/w3f/Grants-Program/blob/master/docs/RFPs/grant_management_webapp.md) are focused on the W3F grants UI and are not including the analytics component our platform intends to deliver. diff --git a/applications/TuxedoDapp.md b/applications/TuxedoDapp.md new file mode 100644 index 00000000000..51aab0af508 --- /dev/null +++ b/applications/TuxedoDapp.md @@ -0,0 +1,260 @@ +# TuxedoDApp + +- **Team Name:** MLabs +- **Payment Address:** FIAT +- **[Level](https://github.com/w3f/Grants-Program/tree/master#level_slider-levels):** 2 + +## Project Overview :page_facing_up: + +Develop a Tuxedo Web Wallet and DApp + +### Overview + +Unlike traditional account-based systems, UTXO-based systems treat each transaction output as a distinct entity, introducing advantages in parallel processing and state transition simplicity. +The Tuxedo project endeavours to demonstrate the flexibility and interoperability of Polkadot by implementing UTXO as one of its paradigms. MLabs, with expertise in the Cardano ecosystem utilizing UTXO as its core model, sees an opportunity to contribute to Tuxedo's success, address identified issues, and engage in future collaborative activities. + +Our goal is to showcase the potential of Polkadot using the UTXO paradigm for the end user, leveraging Tuxedo. The project will consist of two key stages: + +- Stage 1: Developing a simple Web Wallet +- Stage 2: Developing a basic DApp + +### Project Details + +- Stage 1: Developing a simple Web Wallet + +Develop a user-friendly web wallet that allows users to manage their UTXOs on the Tuxedo-based Polkadot network which is similar to polkadot.js which will get the chain info(genesisHash, runtime metadata, chain runtime version, API version), block info +Focus on simplicity, security, and ease of use to provide a seamless experience for users interacting with UTXOs. + +**Technical Requirements** + +**Security:** : Private key storage: +The web-based wallet will provide a secure method for private key storage on the client side, such as a browser's secure storage or hardware wallets. + +**Functionality**: +1. Feature Parity Between Web-Based and CLI Wallets +The web-based wallet will be designed to mirror the core functionality of the CLI wallet, offering seamless UTXO synchronization and token handling, ensuring that users have an equivalent experience across both interfaces +Note: _Feature Parity_ means Means web-based and command-line interface (CLI) wallets, have the same set of features and functionalities, both versions provide an equivalent or identical user experience by offering the same core capabilities and options. + +2. Issues Fix in web-based wallet (https://github.com/Off-Narrative-Labs/Tuxedo/issues/62) +The current implementation of a CLI-based wallet allows sending inputs from multiple owners in a single transaction, but it only supports a single recipient for all specified outputs. + +3. Browser compatibility: +Web-based wallet will ensure compatibility with Chrome, Firefox and Edge. + +**Blockchain Integration**: +Web-based wallet will connect to the blockchain node to fetch relevant data. +We will check if there is any lib such as the one used by "https://polkadot.js.org/" to interact with the Tuxedo-based blockchain for easy integration. + +**Transactions**: +web-based wallet will implement transaction creation and signing on the client side. +We will consider using libraries that support the specific blockchain's transaction format for Tuxedo with UTXO instead of accounts. + +**Local Database**: +web-based wallet will consider using databases for storing non-sensitive user data. +Local database (e.g., IndexedDB, WebSQL, or a lightweight client-side database) to store relevant wallet data locally on the user's device. + +**Tech Stack**: +- polkadot\{.js} trying to re-use it if possible +- React Framework(React + Redux + React Router) OR Vue Framework (Vue.js with Vuex and the Vue Router) +- TypeScript +- webpack +- Babel for backward compatibility in older Browsers +- IndexedDB for Local database +- Jest as JavaScript testing framework + +Wallet Wireframes: [](https://drive.google.com/file/d/1nzE2_uqK5V4IwUJJPb92Q_WJk3RDR9UL/view?usp=sharing) + +- Stage 2: DApp Development + +Create a simple decentralized application to demonstrate the viability and maturity of the Tuxedo framework, as required by this opened ticket "Full Tuxedo App Implementation" https://github.com/Off-Narrative-Labs/Tuxedo/issues/76 +Showcase the unique features of UTXO-based transactions on Polkadot, emphasizing scalability and robustness. +Address identified gaps and limitations in the current Tuxedo product to enhance overall functionality. +We think that a successful showcase of a DApp is Cryptokitties which is provided in Tuxedo via pieces in "https://github.com/Off-Narrative-Labs/Tuxedo/tree/main/wardrobe/kitties". +We want to use this concept and extend the wardrobe codebase by implementing a basic web interface and allowing breeding, trading, searching, and updating the kitty features such as name, price and tradable status of kitties. +This DApp is intended for educational purposes only, and not for production use. The web wallet previously developed will be used for this DApp. + +**Technical Requirements** + +**Functionality**: +Kitties Creation with NFTs: +Represent each kitty as a unique NFT on the Tuxedo blockchain. +Use Tuxedo runtime pieces i.e. kitties to handle NFT-based kitties creation transactions. + +**Breeding and NFT Ownership**: +DApp ensures NFT ownership is transferred correctly during breeding transactions. +Leverage NFT attributes to determine genetics and other breeding-related factors. + +**Trading of kitties between users**: +DApp ensures Kitties can be traded between the users. +Ensure ownership is transferred successfully once trading is completed. + +**Updating the kitty details**: +DApp ensures Kittie's details such as name, tradable status(Yes or No) and Price can be updated. + +**Search kitties owned by other users**: +DApp helps search the kitties other users own based on the user's public key. +This displays the list of kitties owned by other users with all details required for trading such as Gender, Tradable status, Price, Parents, etc. + +**Blockchain Integration**: +Tuxedo Runtime pieces.(wardrobe/kitties ): +We need Leverage Tuxedo runtime pieces for implementing specific DApp functionalities in the UTXO model, with a focus on NFTs, if some modification is required or if some new functionality is required we may need to customize runtime logic to suit the requirements of the UTXO-based DApp. +For this scope, we plan to modify the kitties' pieces code to support below features: + +1. Generating the kitty without the parent when the user inserts the new key in the wallet (basically, 1 kitty is provided for free as an onboarding process) +2. Implementing the Trading of kitties between users +3. Searching kitties owned by other users +4. Adding/Updating more details of kitties such as Gender, Tradable status, Price, and Name. + +**Transaction Handling**: +DApp implements transaction handling logic in the web application to initiate UTXO-based transactions, including NFT-related transactions, on the Tuxedo blockchain. +Provide feedback to users on transaction status and confirmations. + +**Transaction Confirmation**: +DApp implements a transaction confirmation mechanism to ensure that users are informed about the progress and finalization of UTXO and NFT-based transactions such as Trade and Breed. + +**Personal Dashboard**: +We will develop a personal dashboard for users to view and manage their NFT-based Kitties collections. +Display detailed information about each NFT, including ownership history and transaction history. +Manage NFT means, it includes below : + +1. Viewing NFTs: + Users should be able to see a comprehensive list or visual representation of all the NFTs (kitties) they own. + Display detailed information about each NFT, including attributes such as below : + Name + parents(mom and dad) + free_breedings(numbers) + dna(H256 Hash value) + num_breedings(number) + Tradable(yes or No) + Price + Status (Ready for Raring, Tired (only for Dad), Had birth recently(only for Mom)). +2. Trade : + Users should be able to buy the kitty from other users via the search kitty screen or directly from the Trade Kitty screen by inputting the kitty & owner details. +3. Breed : + Users should be able to initiate breeding directly from the dashboard. +4. Update : + Users should be able to update features such as Tradable status, price, and name from the dashboard by clicking on any cell which will navigate to update the kitty screen. +5. Interactivity: + Make the dashboard interactive, allowing users to click on individual NFTs to access more detailed information or initiate specific actions. + +**Tech Stack:** +- Polkadot-JS APIs for getting block data +- React Framework(React + Redux + React Router) OR Vue Framework (Vue.js with Vuex and the Vue Router) +- TypeScript +- Babel for backward compatibility in older Browsers +- IndexedDB for Local database +- IPFS for storing metadata related to the kitty such as Name, Trade status, Price, etc. +- Jest as JavaScript testing framework + +DApp Wireframes: [](https://drive.google.com/file/d/1dCr5Wwi0L-fGPdwAQGFPDhmTeBQYPDy1/view?usp=sharing) + + +### Ecosystem Fit + +**Where and how does your project fit into the ecosystem?** + +- TuxedoDApp seeks to propel the Tuxedo project forward by addressing its current limitations and showcasing the capabilities of Polkadot with the UTXO paradigm. By developing a user-friendly web wallet and a simple DApp, we aim to provide a valuable use case for users of this ecosystem with limited experience in UTXO. + +**Who is your target audience?** + +- **Developers and Enthusiasts from other blockchains:** Developers interested in experimenting with another paradigm but also developers from other ecosystems more "bitcoin-based" that want to try Polkadot. + +- **New Learners in Blockchain Development:** Individuals who are new to blockchain development and want to learn by engaging with the Tuxedo framework. The Tuxedo Web Wallet and DApp can serve as educational tools, providing a practical environment for learners to understand and experiment with UTXO-based blockchain concepts. + +**Are there any other projects similar to yours in the Substrate/Polkadot/Kusama ecosystem?** + +- Tuxedo is unique and we are not aware of any DApp implemented as of today. + +## Team :busts_in_silhouette: + +### Team members + +- Mario Altimari +- Amit Nadiger + +### Contact + +- **Contact Name:** Mario Altimari +- **Contact Email:** marioaltimari@mlabs.city +- **Website:** https://www.mlabs.city + +### Legal Structure + +- **Registered Address:** Address of your registered legal entity, if available. Please keep it in a single line. MLabs LTD, 1st-floor Citibase Millbank Tower,21-24 Millbank, LONDON SW1P 4QP, United Kingdom +- **Registered Legal Entity:** MLabs LTD + +### Team's experience + +- Mario has witnessed the evolution of the web from its early days to the present, as an IT expert with more than two decades of experience. He has worked on various projects with different roles involving Web 1, Web 2 and Web 3 technologies, and has a deep understanding of the challenges and opportunities in each domain. +- Amit is a seasoned software professional with over 18 years of extensive experience in the industry. +His expertise spans a variety of programming languages, including C, C++, Java, Kotlin, and Rust, as well as diverse technologies such as Blockchain, Android app development, and AOSP (Android Open Source Project) development. +In the blockchain space, Amit has showcased his proficiency in Pallet Development. +He has successfully implemented advanced practices, including Prometheus and Grafana for metrics and telemetry, forkless upgrades of runtime, and pallets using polkadot.js.org. +Additionally, Amit has hands-on experience in Ink-based SmartContract development and deployment using a web interface in Substrate Blockchain, demonstrating his versatility in running nodes with different roles, such as Validator/Author and Full node, and configuring Aura and Grandpa through chain specification updates in customSpec.json. +His diverse skill set showcases a comprehensive understanding of blockchain technologies and their practical applications. +Amit has more than 100 technical blogs in Blockchain specifically in Substrate, Polkadot and Rust language, Wasm: https://www.linkedin.com/pulse/consolidated-article-categorization-amit-nadiger/ + +Nobody applied for a Web3 Foundation grant before. + +### Team Code Repos + +- Mario Altimari [https://github.com/AltiMario](https://github.com/AltiMario) +- Amit Nadiger [https://github.com/NadigerAmit](https://github.com/NadigerAmit) + +### Team LinkedIn Profiles (if available) + +- Mario Altimari https://www.linkedin.com/in/altimario/ +- Amit Nadiger https://www.linkedin.com/in/amit-nadiger-94a7224/ + +## Development Status :open_book: + +We have had conversations with the W3F team to validate the idea and find a starting point for collaboration + +## Development Roadmap :nut_and_bolt: + +### Overview + +- **Total Estimated Duration:** 3 months +- **Full-Time Equivalent (FTE):** 2 FTE +- **Total Costs:** $24000 (USD) + +### Milestone 1 — Stage 1: Developing a simple Web Wallet + +- **Estimated duration:** 1 month +- **FTE:** *1* +- **Costs:** $10000 (USD) + +| Number | Deliverable | Specification | +| -----: | ----------- | ------------- | +| **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 use the web wallet app for Tuxedo (Private key configuration, local URI to be used to connect to blockchain) and send test transactions, tuxedo balance, 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.** | Article | We will publish an **article**/workshop that explains how to use the web-based wallet which can be used to configure the user's private key and also get the information from the tuxedo based blockchain, how to do the transactions based on UTXO instead of account-based blockchain. | +| **0e.** | Docker image containing any changes/issue fix in Tuxedo core | Will provide the docker image containing any changes or issue fix in Tuxedo core for wallet implementation | +| **0f.** | Web-based wallet | We will create a web-based wallet that will have functionalities like Storing the private key of the user,(send and receive) Transaction support, all the functionalities provided by the CLI-based wallet (VerifyCoin, SpendCoins, InsertKey, GenerateKey, ShowKeys, RemoveKey, ShowBalance, ShowAllOutputs) | + +### Milestone 2 — Stage 2: Developing a basic DApp + +- **Estimated Duration:** 2 months +- **FTE:** 2 +- **Costs:** $14000 (USD) + +| Number | Deliverable | Specification | +| -----: | ----------- | ------------- | +| **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 use the DApp app to breed kitties, view the kitties using the dashboard | +| **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.** | Article | We will publish an **article**/workshop that explains how to use the DApp which can be used to "create the kitty as NFT", Breeding of kitties, and also how to use the Dashboard | +| **0e.** | Kitties Pieces: Docker image |Docker image containing the kitties which support new features such as "Mint kitty without mom and dad, Trade kitty, change ownership of kitty and search kitties" | +| **0f.** | DApp | We will create a web-based Daap to support functionality such as "create the kitty as NFT", managing the ownership of NFT/Kitties, Breeding, Trading kitties, and showing info (meaning of "Management of NFT" is mentioned above in Dashboard section ) | +| **0g.** | Personalized Dashboard | We will create a personal dashboard for users to view and manage their NFT-based kitty collections. Display detailed information about each NFT, including ownership and other details such as parents, dna, Tradable status, Price, etc | + +## Future Plans + +**Dynamic Wallet**: Making the wallet dynamic by using a standard metadata format such in FRAME, between the wallet and the blockchain, so that any newly created pieces can be tested without extra modification. For this priority activity, we expect not less than 3 months of work with a budget estimation under $30k + +## Referral Program (optional) :moneybag: + +## Additional Information :heavy_plus_sign: + +**How did you hear about the Grants Program?** Meeting with the Web3 Foundation team at the beautiful Sub0 conference in Lisbon diff --git a/applications/WeTEE_Network.md b/applications/WeTEE_Network.md new file mode 100644 index 00000000000..a92d60e6fbd --- /dev/null +++ b/applications/WeTEE_Network.md @@ -0,0 +1,310 @@ +# WeTEE Network + +- **Team Name:** WeTEE DAO +- **Payment Address:** 13Zsmt8cKKVLWTBLHC68d6jNG5cpi7ghFPGgG35gmpwqaxrz(USDT) +- **[Level](https://github.com/w3f/Grants-Program/tree/master#level_slider-levels):** 2 + +## Project Overview :page_facing_up: + +### Overview + +#### Background + +With the development of Web3, more and more applications will be directly deployed on chain, or partially store business data on chain. + +These applications mainly use a front-end / back-end separation architecture, that is, the applications consist of a user interface and a backend built by smart contracts. In theory, any type of application can run on a network with smart contract functionality, but at the same time, these applications also need to compromise for the relatively scarce computing resources on the decentralized network and the high latency in processing business data. + + + +On the other hand, Web2 has a vast number of applications and a mature technology architecture system. When application developers migrate their Web2 applications to Web3, they are faced with challenges such as addressing the compatibility problem between application and chain, handling application deployment issues, dealing with privacy concerns regarding application business data, and figuring out how to update applications to fix security vulnerabilities. + +In a nutshell, the familiar Web2 application development and deployment paradigms currently lack viable alternatives in the Web3 domain. This gap will likely hinder the emergence of Web3 applications and delay the progression of the Web3 application market. + +#### Current Problems + +- Web2 applications are typically deployed in a centralized manner, making business data prone to machine scanning. +- After Web2 applications are adapted to smart contracts, there will be a significant performance overhead and they will face network congestion. +- There is a risk of leakage of application business privacy data, resulting in financial losses for individuals and institutions. +- Smart contracts have inherent limitations and face restrictions in supporting private data, GameFi, AI, metaverse, etc. +- Web3 lacks software infrastructure similar to Web2, which cannot meet the diverse deployment requirements of Web3 applications. + +#### WeTEE Project + +WeTEE is a decentralized application deployment platform integrated with a Trusted Execution Environment (TEE). + +WeTEE consists of blockchain networks and multiple confidential computing clusters, collectively providing an efficient decentralised solution for confidential computing. + +Thread-level confidential container service providers need to provide hardware devices that support Intel SGX, and they are required to use IPv4 / IPv6 to access the Internet. + +1. At this stage, Substrate is mainly used as the blockchain framework to implement application deployment and billing-related smart contract functions. +2. After the application is deployed, its workload will be safeguarded by hardware protection to prevent data leakage. Even confidential computing providers will not be able to access the data. +3. It integrates with the existing cloud native toolchain for developers, typically requiring no code modifications, and in special cases, only a small amount of code modification is needed. +4. Developers can view information such as the resource usage and health status of applications in the Web interface provided by WeTEE. + +#### WeTEE Solutions + +WeTEE's technological approach is an all-encompassing solution incorporating a number of leading-edge technologies, striving to deliver the most superior and secure services across all facets such as the hardware layer, encryption layer, application layer, data layer, and user layer. Its design perspective ranges from considering fundamental hardware compatibility to enhancing user experience on the front-end, demonstrating unique design considerations and processes, resulting in a solution that is not only dependable but also highly feasible in practice. + + + +1. **In the hardware layer:** + WeTEE utilizes K3S / K8S technology to abstract underlying hardware disparities, effectively isolating compatibility issues caused by hardware variances. Concurrently, by leveraging Intel SGX, it establishes a confidential computing environment, ensuring a sufficient level of security and trust for the application's hardware operating environment. +2. **In the encryption layer:** + WeTEE fully capitalizes on the characteristics of TEE, establishing Worker nodes for confidential computations. These nodes can be deployed and validate confidential microservices on the original K3S / K8S, ensuring the system's security and scalability. +3. **In the chain management layer:** + WeTEE builds a high-performance decentralized organizational account, decentralized finance, and on-chain confidential computing management function by using Substrate technology. This enables WeTEE to not only serve individual developers but also provide enterprise-level services for DAO organizations' applications. +4. **In the application deployment layer:** + WeTEE integrates the K3S / K8S cloud-native tech stack, inheriting agile, stable, resilient, and easily scalable features. Such a framework makes it easier to deploy complex business applications, while also supporting their updates and iterations, aiming at further eliminating potential application vulnerabilities. +5. **In the data management layer:** + WeTEE adopts the "TEE Confidential Injection" approach, generating encrypted replicas among the server nodes to prevent accidental data loss, thus ensuring the security of business data. +6. **In terms of the user experience:** + WeTEE provides an intuitive Web UI interface, making it easy for application developers to deploy and monitor their applications. + +### Project Details + +#### Documentations + +- WeTEE Product PPT: [PPT Link](https://raw.githubusercontent.com/wetee-dao/chain/f01744e08489b3c9ac6c9c61c0c3cc3e396a3302/docs/deck/weteeBP%20(%20ENG%20).pdf) + +WeTEE has streamlined the development of blockchain applications, reduced the complexity of development, and expedited the transition from Web2 to Web3. + +Developers can leverage WeTEE to effortlessly implement the separation architecture between on-chain and off-chain applications at an extremely low cost, while maintaining the original business logic, making the integration and application of blockchain technology more accessible. Cutting-edge technologies such as intelligent compilation, hybrid operation, and data layering have been integrated into WeTEE, enabling it to effectively address the core issues of deploying applications in a blockchain environment. + + + +WeTEE allows developers to bypass the need for putting considerable time and energy into comprehending and conforming to blockchain technology, hence enabling them to swiftly concentrate on the essential function development of applications, significantly escalating development productivity. + +In the cryptocurrency world, data privacy has persistently been under the spotlight. The data privacy safeguarding mechanism utilized by WeTEE assures the security of user data throughout the computing and storing processes, ensuring user privacy rights, which brings about enhanced customers' trust in the product. + +Additionally, WeTEE adjusts the performance efficiency of both on-chain and off-chain operations to allow for faster transaction handling, thus delivering a smooth user experience and easing user interaction. Equally, WeTEE grants applications the ability for efficient iterations thereby better accommodating market variability and changes in user requirements, ensuring sustained competitive advantage for the application. + +WeTEE incorporates an intelligent compiler that possesses auto code analysis capabilities. This compiler can deeply parse the codes of Web2 applications and astutely identify the compilable sections related to business logic. WeTEE will extract these parts of code and automate its compilation into TEE application containers, improving application performance while ensuring security. The main features of the WeTEE intelligent compiler are as follows: + + + +1. **Backs Major Web Development Languages:** + Including but not limited to Rust, Go, JavaScript, Python, C, etc. +2. **Code Analysis Support:** + Facilitates static and dynamic code analysis and extracts the compilable sections. +3. **Auto Compilation:** + Compilable code runs through automatic compilation in accordance with pre-set WeTEE strategies, eliminating the need for manual intervention. +4. **Code Compilation Log:** + Upon completion of compilation, a detailed log will be generated, allowing developers to review the compilation process. + +WeTEE establishes a hybrid runtime for applications, functioning as middleware to enable seamless interaction between Web2 frontend and on-chain smart contracts backend. The main features of WeTEE hybrid runtime include: + +1. **Simplified Off-Chain Interface Calls:** + Developers can easily facilitate off-chain calls through the interface, reducing interaction costs between the application and the chain. +2. **Mapping of Business Logic On-Chain:** + In face of complex application business logic, WeTEE can automatically manage its on-chain execution mapping relationships. +3. **Private Data Off-Chain Processing:** + When processing data involving privacy, WeTEE will utilize off-chain computing power within the platform for privacy computations. +4. **Scalable Computing Power:** + The platform's off-chain computing power, used to handle compute-intensive tasks, can be expanded to compensate for any lack of on-chain computing power. +5. **Chain Interaction Encapsulation:** + The hybrid runtime encapsulates the interaction logic with the chain, allowing frontend to interact with the chain transparently, reducing privacy data leakage. + +When an application is processed by the WeTEE intelligent compiler and operates successfully within the WeTEE platform, developers typically do not have to worry about the application's running status. Nevertheless, as an application deployment platform, WeTEE still provides customers with essential and accurate application link tracking and monitoring capabilities, as well as timely fault warning and diagnostic abilities, ensuring the healthy operation of applications. The primary features of WeTEE's automated monitoring include: + + + +1. **Resource Monitoring:** + Regular gathering and statistics of key metrics such as CPU load, memory usage, storage space utilization, etc. +2. **Network Monitoring:** + Regular network status probes to perceive network changes. +3. **Chain Status Monitoring:** + Regular monitoring and inspection of interactive data on the chain. +4. **Application Health Monitoring:** + Regular monitoring of application response time, abnormal logs, and other metrics. +5. **Anomaly Behavior Monitoring:** + Based on generic anomaly behavior monitoring models, evaluate application behavior and report abnormal behaviors. +6. **Status Alert:** + Alerts will be triggered when the application's resource usage is about to exceed the threshold or when abnormal behaviors occur in the application. +7. **Fault Review:** + When an application experiences abnormal operation or crashes, WeTEE can provide application logs and other data, aiding in fault review and diagnosis. + +When application developers need to update their applications to provide new features or security patches, they can fully leverage the hot update mechanism provided by WeTEE for rapid application updates. WeTEE's hot update mechanism adopts the common hot update solution for current cloud-native applications, and has the following main features: + + + +1. **Code Hot Update:** + After the application code is updated, it will be automatically compiled and pushed online, reducing application downtime. +2. **Seamless Experience:** + The user side can be insensitive to application updates, improving user experience. +3. **Development Paradigm:** + Compatible with and supports cloud-native development habits. Application developers can continue to use familiar tools and processes. +4. **Change Flexibility:** + The hot update mechanism has extended the decentralized application update method, improving the adaptability and timeliness of the application. + +WeTEE deeply comprehends the potential challenges brought by decentralized application (DApp) development and deployment, and thus independently designs a feature to achieve seamless integration and easy deployment of DApps and Web2 applications. This feature not only automates many tedious operational tasks but also ensures the stability and efficiency of deployment. The key features of WeTEE's DApp one-click deployment function include: + +1. **One-click Deployment:** + With just a single operation, it can automatically deploy smart contracts on-chain and initiate off-chain services. +2. **DApp SDK:** + Provides a smart contract SDK for application developers, enabling rapid communication between on-chain and off-chain. +3. **Elastic Expansion:** + Equipped with the ability to sense application resource usage, it dynamically adjusts the application's resource quota according to preset policies. +4. **Application Assurance:** + In the event of application failure detection, it will automatically handle the situation in accordance with the application emergency plan and attempt fault recovery. + +Currently, WeTEE's application management mechanism will use a democratic-centered governance mechanism similar to Polkadot OpenGov to govern the network. + +WeTEE replaces the board with DAO and uses a reputation voting system for on-chain decision-making, allowing more people to participate in the chain governance and thus promoting better community development. You can participate in or supervise the WeTEE project research and development, and alter chain parameters by voting. + +#### Technology Stack + + + +WeTEE implements a mainstream industry layered architecture design to accurately isolate on-chain and off-chain data, with a specific emphasis on optimizing the security storage strategy for off-chain data. The primary advantage of this layered architecture is its ability to determine the optimal storage and processing solutions for diverse types of data, guaranteeing data safety and privacy, and achieving efficient resource utilization and management. + +- **On-chain Core Data:** + Within this layered architecture, on-chain data primarily comprises essential transaction details and key state updates. With the non-alterable and decentralized characteristics of the blockchain, WeTEE ensures that all pertinent data is impeccably recorded on the blockchain, thereby enhancing the transparency of business processes in applications and offering key support to ensure data authenticity and completeness. +- **Off-chain Data Encryption:** + Considering the storage needs of certain sensitive user data and a large amount of supplementary data, WeTEE has designed an encrypted storage solution for off-chain data. This encryption scheme employs hardware encryption techniques like Intel SGX / AMD SEV, ensuring that encrypted data retains integrity and offers error tolerance and recovery capabilities, significantly reducing the risk of data leakage. +- **Data Access Control:** + Simultaneously, while sensitive data is encrypted, WeTEE also incorporates proof of data ownership and stringent data access control mechanisms. By utilizing refined data access control policies, unauthorized access can be effectively prevented, thereby further securing the safety of private data. + +Through the above design, WeTEE's layered architecture, using distributed storage and dynamic scaling technology, effectively reduces storage costs. At the same time, the strict access control and encryption techniques significantly minimize the risk of information leakage, achieving efficient and safe storage for off-chain blockchain data. + +### Ecosystem Fit + +Within the existing Polkadot ecosystem, there is a discernible gap for requisite application deployment service platforms suited for Web 2.5. This gap is precisely where WeTEE presents its competence - by enabling application developers to expedite the development and deployment of diverse Web 2.5 applications. This accelerates the extension of Polkadot's application realms across a plethora of industries, notably within the sectors of social media, entertainment and finance. + +Web 2.5 applications play a pivotal role in attracting a broader spectrum of Web 2 users towards the growing Polkadot ecosystem. With the expansion of these user bases, Polkadot is not only gaining traction in numerical terms but it also represents a movement towards a more balanced and decentralized internet model. + +In addition, these Web 2.5 applications are potential catalysts for introducing a multitude of new commercial models in the Polkadot ecosystem. This can have a dual effect of fostering Polkadot's growth, as well as collaborating with traditional industries for shared advancements. As such, WeTEE's role in aiding application development projects is a substantial step towards increasing Polkadot's industry footprint. + +## Team :busts_in_silhouette: + +### Team members + +- Team leader + - BaiL - Senior Full-stack Development Engineer +- Team members + - Nomad - Senior Product Manager + +### Contact + +- **Contact Name:** BaiL +- **Contact Email:** bai@asyou.me +- **Website:** [WeTEE](https://www.wetee.app) + +### Legal Structure + +- **Registered Address:** Wickhams Cay Ⅱ, Road Town, Tortola, VG1110, British Virgin Lslands +- **Registered Legal Entity:** WETEE LIMITED + +### Team's experience + +- BaiL + - 12-years full stack software development experience + - Solid knowledge and experience with various programming language i.e. Go,Dart,Javascript,Rust + - Blockchain & Substrate enthusiast + +- Nomad + - 3-years UI/UX design experience + - 8-years senior product management experience, leading multiple Linux and Cloud-based products + - United nations sustainable development goals certificate Product Manager (UCPM) / Lean Product Manager (UCLPM) + +### Team Code Repos + +- Blockchain node：https://github.com/wetee-dao/chain +- Worker operator：https://github.com/wetee-dao/worker +- Entry of libos： https://github.com/wetee-dao/libos-entry + +## Development Status :open_book: + +We have accomplished the implementation of organization accounts and decentralized governance features based on Substrate-supported smart contracts. These accounts and governance functions accommodate tasks such as the management of organizational assets and voting-based decision making. Consequently, this establishes a transparent and verifiable method of governance for organizations. + +At the current stage, we are focused on establishing the first version of the on-chain cloud deployment platform for the project. Through Docker and Kubernetes related technologies, this module can automatically deploy smart contracts and back-end services to the blockchain with one click and invoke the computing resources of decentralized servers. + +## Development Roadmap :nut_and_bolt: + +### Overview + +- **Total Estimated Duration:** 3.5 months +- **Full-Time Equivalent (FTE):** 2 FTE +- **Total Costs:** 21,000 USD + +### Milestone 1 — Build the On-Chain Module + +- **Estimated duration:** 1 month +- **FTE:** 2 +- **Costs:** 6,000 USD + +| Number | Deliverable | Specification | +| -----: | ----------- | ------------- | +| **0a.** | License | Apache License 2.0 | +| **0b.** | Documentation | We will provide both **inline documentation** of the code and a basic **tutorial** that explains how a user can (for example) spin up one of our Substrate nodes and send test transactions, 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.** | Docker | We will provide a Dockerfile(s) that can be used to test all the functionality delivered with this milestone. | +| 01. | Substrate module: worker | This pallet provides modules for the registration and staking of miner nodes, as well as accepting proof-of-work data and detailed file hashes and addresses from miners, and also provides withdrawal functions for miners, as well as closure (which can only be executed if all services have already stopped/migrated), and also provides channels for users to complain about miner nodes.
1. Worker cluster register
2. Worker cluster mortgage
3. Worker cluster upload proof of work data
4. Worker cluster withdrawal
5. Worker cluster stop
6. Worker cluster report | +| 02. | Substrate module: app | This pallet provides users with the function of deploying and updating applications, as well as an interface for topping up applications. Users can prepay for the operation of the application, and miners can only unlock the fees paid by users after uploading proof of work.
1. TEE app create
2. TEE app update
3. TEE app set settings
4. TEE app recharge
5. TEE app stop | +| 03. | Substrate module: task |This pallet provides users with the function of deploying and updating periodic/temporary tasks, where users can set the execution time and cycle of tasks. It also provides an interface for users to recharge their applications, allowing them to prepay for the operation of the application. Miners can only obtain revenue after uploading proof-of-work for single-task work.
1. TEE task create
2. TEE task update
3. TEE task set execute settings
4. TEE task recharge
5. TEE task stop | + +### Milestone 2 — Build the Worker Module + +- **Estimated duration:** 1 month +- **FTE:** 2 +- **Costs:** 6,000 USD + +| Number | Deliverable | Specification | +| -----: | ----------- | ------------- | +| **0a.** | License | Apache License 2.0 | +| **0b.** | Documentation | We will provide both **inline documentation** of the code and a basic **tutorial** that explains how a user can (for example) spin up one of our Substrate nodes and send test transactions, 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.** | Docker | We will provide a Dockerfile(s) that can be used to test all the functionality delivered with this milestone. | +| 01. | TEE Image build guide | We will provide documentation to help programmers understand and execute compiling existing web2 programs into deployable mirrors on Wetee. Currently we provide documentation for compiling via Ego and Gramine. | +| 02. | App Example | We will provide example programs to help programmers understand and execute compiling existing web2 programs into deployable mirrors on Wetee. Currently we provide Examples in Golang, Python, C, C++, and Rust. | +| 03. | Worker K8S Operator |The k8s worker acts as a trusted controller in the wetee network. It securely stores deployment states, including manifests and defined secrets. Based on the manifests, the Worker uses remote attestation to authenticate the trusted execution environments of applications.
1. K8S Operator run in SGX
2. Listen to Wetee Node State
3. Worker cluster register
4. Worker cluster mortgage
5. Worker cluster withdrawal
6. Worker cluster stop | +| 04. | Worker App Deploy |The application controller of the miner node is responsible for pulling settings from the chain and synchronizing them into the k8s/k3s cluster to complete application deployment/update.
1. TEE app create
2. TEE app update
3. TEE app set settings
4. TEE app recharge
5. TEE app stop | +| 05. | Worker Task Deploy |Miner node task controller, responsible for executing assigned tasks, uploading execution logs, and synchronizing to the chain.
1. TEE task create
2. TEE task update
3. TEE task set execute settings
4. TEE task recharge
5. TEE task stop | + +### Milestone 3 — Worker Proof + +- **Estimated duration:** 1.5 month +- **FTE:** 2 +- **Costs:** 9,000 USD + +| Number | Deliverable | Specification | +| -----: | ----------- | ------------- | +| **0a.** | License | Apache License 2.0 | +| **0b.** | Documentation | We will provide both **inline documentation** of the code and a basic **tutorial** that explains how a user can (for example) spin up one of our Substrate nodes and send test transactions, 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.** | Docker | We will provide a Dockerfile(s) that can be used to test all the functionality delivered with this milestone. | +| **0e.** | Article | We will publish an **article**/workshop that explains what was done/achieved as part of the grant. (Content, language and medium should reflect your target audience described above.) | +| 01. | Worker remote attestation as proof of work | Remote attestation module, users can use it to check the confidential running status of the application in real time. The module will automatically generate worker proof and synchronize the hash of the remote proof file to the chain. Users or challengers can verify the verification status of the worker through the proof file.
1. Worker cluster remote attestation service
2. Worker upload remote attestation as proof of work | +| 02. | Worker log as proof of work | Synchronize the log of application running through libos to worker, and synchronize the hash file to the chain to prove the correctness and stability of program execution, users can view the application log to determine the status of program execution.
1. Worker cluster upload app log of app as proof of work | +| 03. | Worker monitoring as proof of work |Through libos, synchronize the resource usage status of the application to the worker, and synchronize the hash and resource usage data of the file to the chain. The chain will calculate the resources of the application and issue rewards for the worker.
1. Worker cluster upload app monitoring of app as proof of work | + +## Future Plans +When you express interest in the future development of WeTEE, our team is deeply encouraged, as your support leads us to believe that our code and products will achieve meaningful and valuable results. + +This grant will allow us to focus on developing core features, laying a reliable business foundation for WeTEE. Upon reviewing the outcomes of our submitted grant, you will be able to easily verify WeTEE's core business using the documentation guidance and Docker examples provided by WeTEE. + +The R&D of WeTEE can be divided into three major stages, each of which contains several small R&D stages or iterative cycles: +• Core R&D stage +• User experience optimization stage +• Ecosystem construction stage + +During the current core development stage, WeTEE will concentrate all research and development resources on WeTEE's own development, including on-chain workers, apps, tasks, as well as K3S/K8S operators relevant to physical servers, app deployment models, task deployment models, and worker attestation models. + +Once this part is completed, WeTEE will spend a small amount of time to reorganizing the code and conducting a retrospective on the completed work, after which the development will move into the next phase of core research and development. + +At this stage, the R&D content mainly includes the WeTEE test/main network, the WeTEE Dapp SDK, accessing the Polkadot mainnet using CoreTime, as well as the WeTEE monitoring system and the WeTEE Web user interface. + +After completing this stage of development, WeTEE will invite seed users to conduct usability testing and user acceptance testing, and operational work will be carried out in accordance with the requirements of WeTEE DAO. Following initial user feedback, targeted fixes and optimizations will be implemented to address any issues within WeTEE. + +The following will enter the third phase of core R&D, which is also the last core R&D phase in the current planning. In this phase, WeTEE will dynamically allocate R&D resources to the ‘blockchain-related’ or ‘hardware-related’ fields based on user and market feedback. +• Blockchain-related: + ◦ Integrate https://github.com/paritytech/frontier and support wallet applications such as Metamask + ◦ Improve the multi-language version of the SDK to help users better integrate accounts and business between Web2 apps and Web3 DApps + ◦ Improve the decentralized collaboration system of WeTEE, allowing WeTEE users to view the status of application clusters and application deployment events at any time +• Hardware-related: + ◦ Compatibility with AMD SEV confidential solution + ◦ Compatibility with Intel TDX confidential solution + ◦ Performance optimization of confidential computing, distributed storage, and network for server K3S/K8S. + +## Additional Information :heavy_plus_sign: + +The subproject DTIM of WeTEE won the first prize at the [Polkadot Hackathon 2023 Summer](https://dorahacks.io/hackathon/polkadot-hackathon-2023-summer/results). diff --git a/applications/Web3Go.md b/applications/Web3Go.md index fb34b12ee06..e11d0f40047 100644 --- a/applications/Web3Go.md +++ b/applications/Web3Go.md @@ -64,10 +64,10 @@ We have found several successful data analysis projects in the Ethereum ecosyste Similar projects -*
Generic Game Pallets, build special features used in games, they are fully supported in the UnitySDk
@@ -84,7 +84,7 @@ The service Layer project can be deployed to a server as DOTNet application offe #### PoC/MVP or other relevant prior work or research on the topic -Our alpha game is already running, check out our webpage (