diff --git a/applications/Crowdloans-FET.md b/applications/Crowdloans-FET.md index a679a3760b1..539070101ab 100644 --- a/applications/Crowdloans-FET.md +++ b/applications/Crowdloans-FET.md @@ -3,6 +3,7 @@ - **Team Name:** Mutai Solutions - **Payment Address:** 0xE27F2E8321Fb4c32525a4ED86d2902dbA63491E4 Ethereum (USDT) - **[Level](https://github.com/w3f/Grants-Program/tree/master#level_slider-levels):** 1 +- **Status:** [Terminated](https://github.com/w3f/Grants-Program/pull/1280#issuecomment-1583327825) ## Project Overview :page_facing_up: diff --git a/applications/Substrate_Move_System_Pallet_1.md b/applications/Substrate_Move_System_Pallet_1.md new file mode 100644 index 00000000000..05cd4519156 --- /dev/null +++ b/applications/Substrate_Move_System_Pallet_1.md @@ -0,0 +1,187 @@ +# Substrate Move System Pallet (part 1) + +- **Team Name:** Eiger +- **Payment Address:** Fiat 14.04.2023, 16:50 UTC+3 +- **Level:** 3 + +## Project Overview ****📄**** + +This application is a response to the **[Move Smart Contract Pallet RFP](https://github.com/w3f/Grants-Program/blob/master/docs/RFPs/Open/move_smart_contract_pallet.md).** + +### Overview + +Some terminology first: + + - **Substrate Move System Pallet** - A Substrate system pallet that can be used as a building block for substrate-based chains, it exposes interfaces to interact with the Move virtual machine. + + - **Substrate Move** - A Move language fork that is Substrate compatible. + +Objectives: + +- The goal is to provide a Substrate system pallet that allows to deploy and interact with Smart Contracts written in the Move language, by providing a Move Virtual Machine (MoveVM) as a pallet. +- We plan on exploring a fork of the Move language, so it’s adjusted to work with the Substrate ecosystem, as well as developing a Substrate system pallet that allows the execution of Move smart contracts. +- The project directly improves the growth potential of the Substrate based ecosystem by providing support for one of the most modern smart contract programming languages and VM types out there - Move. +- We are interested in creating this project because we are firm believers in the modular vision of web3, and only by collaborative efforts on improving and unifying the technology between different chains and the languages, will we get better products as an outcome. + +**Goal** - Level up the growth possibilities of the Substrate ecosystem by providing a way to develop and execute Move smart contracts on Substrate. + +This is the first phase of a 3-phase development program: + +1. **In-Depth Exploration and Assessment of MoveVM and Substrate Integration** +2. MoveVM compatibility work and Subtrate Pallet development +3. Finalising the Substrate-Compatible MoveVM + +### Project Details + +**Prior work** + +We are basing the core architecture and many of the design decisions on the [Pontem networks developed system pallet for Move VM](https://github.com/pontem-network/pontem/tree/master/pallets/sp-mvm). They had maintained [their own fork of the Diems Move language](https://github.com/pontem-network/sp-move-vm), which was used as the base execution layer for their version. Both of these repositories have not been maintained for a very long time already. + +♻️ We aren't seeking to maintain any of the existing codebase; rather, we aim for a full revival through a new greenfield project. Our rationale for this stems from the substantial advancements made in the Rust, Substrate, and Move ecosystems since Pontem’s latest commits from over a year ago. We believe that handling potential code rot due to the passage of time might be more labor-intensive than starting afresh and drawing upon existing projects for more current guidelines. + +**Documentation of core components, architecture** + +1. **Substrate Move:** + + The first part of the project will be a MoveVM fork, as some major changes will need to be made to the codebase for it to be substrate compatible. For example: + + - `no_std` compatibility: Making it lightweight and suitable for use in Substrate runtimes. + - `wasm32` target compatibility: Adapting all the VM’s different components to work efficiently and securely on the wasm32 target architecture. + + We plan on creating and maintaining the fork in a manner that would allow us and the community to easily follow and track changes from the upstream, thus making the maintenance and change tracking to be much simpler. + + At the time of writing this application, we suspect that this will be needed because this is what also Pontem had to do to support it in their version. This will be further researched and assessed during the first milestone. + +2. **Move VM system pallet:** + + The second part of the project will be a Substrate virtual machine pallet in Substrate. This is a modular component that is needed to integrate a specific new VM into a Substrate runtime. It will serve as a bridge between the runtime and the Move VM, managing resources and translating data or actions between the two environments. + + +**API specifications** + +As a minimum, we plan on providing all of the RPC calls that the Pontem crate did. As the team progresses with the implementation, we might add or remove RPC calls as we best see fit. + +Move language has a concept of “gas” for executing contracts, whereas Polkadot uses “Weights”. Each Move transaction invocation requires providing a gas limit for execution, and it’s necessary to be able to transform the values between weight and gas: + +- `mvm_gasToWeight` +- `mvm_weightToGas` + +Estimating gas for different operations: + +- `mvm_estimateGasPublish` +- `mvm_estimateGasExecute` + +Working with the primitives of the Move language: + +- `mvm_getResource` +- `mvm_getModuleABI` +- `mvm_getModule` + +**Tech stack** + +We plan on using Rust for developing the system pallets and using existing Move language smart contracts for end-to-end testing of the whole workflow. + +**Notes** + +Because the Move language requires a fork to work with Substrate chains, and modifications to the address size, there might be incompatibilities with deploying existing Move Smart Contracts from other chains that make use of the address properties size, as well as the compiled ABI and bytecode for those contracts might be invalid. To deploy on our MoveVM system pallet, the forked toolchain must be used to re-compile all smart contracts. The address size of Move language is configurable via a feature switch with 32-bits being one of the options. + +### Ecosystem Fit + +Move is a smart contract programming language that emphasizes access control and scarcity, offering some unique advantages over other popular VMs in blockchain ecosystems. + +The importance of bringing the MoveVM to Polkadot was recognized over two years ago when [Pontem Network](https://pontem.network/) started working on a [Move virtual machine pallet](https://github.com/pontem-network/pontem/tree/master/pallets/sp-mvm) to execute Move smart contracts on Substrate-based chains. Although they discontinued the project and haven't updated the codebase for over a year, the W3F still keeps this RFP, which serves as evidence that porting the MoveVM is crucial for the future of the Polkadot network. + +We concur with this perspective and have actually been actively researching the MoveVM - exactly with a similar idea of helping port it over to other chains. + +## Team **👥** + +### Team members + +- **Roberts Ivanovs** ([Github](https://github.com/roberts-ivanovs), [Linkedin](https://www.linkedin.com/in/roberts-ivanovs-3b24b6159/)) is a Rust Software Engineer at Eiger. He has extensive experience using Rust for performance-sensitive backend work, the IoT industry, web development, and Solidity/dApp development. +- **Tomek Piotrowski** ([Github](https://github.com/tomekpiotrowski), [Linkedin](https://www.linkedin.com/in/tomasz-piotrowski-17466b4/)) Software Engineer at Eiger, specializing in Rust-based applications. With a strong background in software development, he has spent recent years focusing on the Rust programming language. At Eiger, Tomasz actively contributes to the advancement of Rust-based blockchains and their ecosystems. + +### Contact + +- **Contact Name:** Daren Tuzi +- **Contact Email:** [daren@eiger.co](mailto:daren@eiger.co) (Founder & CEO of Eiger) +- **Website:** [Eiger.co](https://www.eiger.co/) + +### Legal Structure + +- **Registered Address:** Linnankatu 3 A 24, 20100 Turku, Finland +- **Registered Legal Entity:** Eiger Oy**** + +### Team's experience + +Web3 promises to upgrade the very foundations of our society – from money, finance, and governance to media, gaming, and science. To deliver on that promise, decentralised technologies are to be integrated into the everyday experiences of billions of people. For engineering, this is a mountain of a challenge. + +Eiger was founded to develop infrastructure for web3 mass adoption. We help technology companies improve and integrate the core technologies of web3 to meet the climbing demands for scaling and performance. + +We currently employ 25+ senior web3 engineers across the globe and work with some of the most ambitious organisations in the industry, including Forte, Aleo, and XRP Labs, to name a few. + +### Team Code Repos + +As mentioned in the Teams section, Eiger already has extensive experience developing large infrastructural projects. Some chosen examples: + +- The SnarkOS for Aleo, the privacy-focused smart contract L1 platform going into production this summer. https://github.com/AleoHQ/snarkOS +- OrbitDB is a distributed, p2p, serverless database. https://github.com/orbitdb/orbit-db +- The rust implementation of IPFS, now archived. https://github.com/rs-ipfs/rust-ipfs +- The main implementation of Interledger in Rust, which we developed and maintained. https://github.com/interledger/interledger-rs +- Ziggurat - A Network protocol testing framework for ZCash, XRP, and Algorand. Notably, critical network vulnerabilities were found and reported to the core teams. https://github.com/runziggurat + +## Development Status **📖** + +- This application is a direct response to [this RFP](https://github.com/w3f/Grants-Program/blob/master/docs/RFPs/Open/move_smart_contract_pallet.md) +- [Move language Github](https://github.com/move-language/move/tree/main/language) +- [Pontem MoveVM fork](https://github.com/pontem-network/sp-move-vm) +- [Pontem MoveVM system pallet](https://github.com/pontem-network/pontem/tree/master/pallets/sp-mvm) + +We have not yet started our own development, we are still in the research phase. + +## Development Roadmap **🔩** + +### Overview + +- **Total Estimated Duration:** 1 month +- **Full-Time Equivalent (FTE):** 2 FTE +- **Total Costs:** 48 000 USD + +### **In-Depth Exploration and Assessment of MoveVM and Substrate Integration** + +**Goal**: Research Pontem Move VM solution, Move language and its ecosystem, and document all findings. Prepare a repository for developing the Substrate Move system pallet. + +| Number | Deliverable | Specification | +| --- | --- | --- | +| 0a. | License | Apache 2.0 and MIT | +| 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 | Content: article that explains all of the research and findings done in the research phase, and how it shapes the project in the future. The research would include: Medium: A markdown design decision document in the repository. | +| 1. | System Pallet: Substrate Move | We will create a Substrate system pallet that will provide the RPC calls as the initial interfaces for interacting with the Move VM. The Move VM port itself will not be implemented, all of the methods will be empty stubs.
Solid code practices will be in place: CI/CD, tests, documentation, linting, and publication of the library to http://crates.io. | +| 2. | Rust crate: Substrate Move | Forking the Move VM if deemed necessary. The alterations would include everything to create the virtual machine Substrate-compatible. | +| 3. | Rust crate: Substrate Move documentation | Documentation of the alteration made for the MoveVM to be Substrate-compatible. Also, the whole process of how it was ported will be described, either in form of markdown documentation or detailed commenting on GitHub issues and PRs. | + + +## Future Plans + +This is the first phase of a 3 steps development plan: + +1. **In-Depth Exploration and Assessment of MoveVM and Substrate Integration** +2. MoveVM compatibility work and Subtrate Pallet development +3. Finalising the Substrate-Compatible MoveVM + +The **next** step will be to submit a grant proposal to continue this work - creating the first iteration of a pallet capable of receiving, storing and executing Move smart contracts. + +We hope that upon the completion of all phases of creating the Substrate Move System Pallet , it will open doors for further collaboration and community input on the project. We strive to have the codebase well documented so that others might join in and contribute. + +While there are no long-term plans set in stone for the usage of this pallet, we have had incredibly exciting discussions about creating a parachain, possibly a [common good parachain](https://polkadot.network/blog/common-good-parachains-an-introduction-to-governance-allocated-parachain-slots/) (system parachain), that utilizes this MoveVM implementation and would run MoveVM contracts. As we near the completion of this initial development, we will be discussing these future plans more in-depth. + +## Additional Information **➕** + +**How did you hear about the Grants Program?** + +We learned about it when looking at open RFPs by the web3 foundation on their website. + +We wanted to get back up to date on what is happening in the Polkadot ecosystem, and working on grants, specifically RFPs, has been a great way to do so. + +Looking to apply to other RFPs currently open as well. Stay tuned! diff --git a/applications/dot_etl.md b/applications/dot_etl.md new file mode 100644 index 00000000000..e4fbf5ee1ce --- /dev/null +++ b/applications/dot_etl.md @@ -0,0 +1,164 @@ +# DOT-ETL + +- **Team Name:** Davanti +- **Payment Address:** 16m9eMpB3BuPSXwjvdCY6z63pTuvdnv8FjmmH33ZkYPCr9XC +- **[Level](https://github.com/w3f/Grants-Program/tree/master#level_slider-levels):** 2 + +## Project Overview :page_facing_up: + +### Overview + +This proposal is in response to the following RFP: [Analysis Website and Data Platform](https://github.com/w3f/Grants-Program/blob/master/docs/RFPs/Open/analysis-website-and-data-platform.md) + +The goal of the Dot-ETL project is to lower the friction required to conduct fine-grained and aggregated analysis of transactions on Polkadot network, via a framework to extract Polkadot transaction-level data to various offline formats: e.g. CSV / delimited, relational, columnar. Furthermore, we intend to develop a framework to ETL Substrate to [Google BigQuery](https://cloud.google.com/bigquery), orchestrated via [Google Cloud Composer](https://cloud.google.com/composer). + +The Polkadot and Kusama ecosystems have nurtured a significant developer community, and hosts a number of well-known parachains spanning a diverse series of domains, including Defi lending / liquidity, DEXs, NFTs, RWAs and securitization, as well as identity and privacy applications. While there has been a great deal of interest in developing on polkadot, there hasn't thus far been a simple means to query and visualize transaction-level data and aggregates. + +Dot-ETL will be similar in functionality to the [Ethereum ETL project](https://ethereum-etl.readthedocs.io/en/latest/). In the same way that the ETH-ETL offering Ethereum transaction data as a Public Dataset from Google has helped to establish higher TVL and adoption of the Ethereum network, the goal is that by making PolkaDot transactional data easily accessible without the majority of data engineering tasks that exist in extracting data in usable form from the blockchain will lead to greater development and interest for the protocol by mainstream users of platforms such as Google Cloud. Once data is supported and provided in this format, there are also other potential use cases that can expand adoption of PolkaDot data by the blockchain industry such as easily being able to host Chainlink oracles for this data and provide it in readily available form for a number of different cross-chain applications. The open nature of the google bigquery dataset would allow anyone to query and extract insights from on-chain activity via SQL, or even build visualizations on thedata. + +Upon successful completion of the primary data structures (blocks, extrinsics, events), we plan to provide a framework / pattern to extract extrinsics tailored to specific parachains. We may explore Defi and RWAs in more depth: we believe that providing focus on DeFi activity related to Real World Assets on Google Cloud is the most promising use of public data to attract attention to the ecosystem. + +We also intend to publish guides on how to query and use the dataset (i.e. medium articles, github wikis, gitbook document site). The source code for Dot-ETL will be made public through the Web3 foundation. + +The team has extensive technical background in backend software engineering and machine learning / data science, and domain knowledge in machine learning, financial services (both retail as well as institutional), lending, and quantitative risk management. Our expertise and extensive domain experience, particularly in real world usage of data in Fintech and DeFi, will allow for us to build with adoption and practical use in mind. + +### Project Details +(Technical Details) + +The Dot-ETL project will utilize prior work on the SubQuery project to index and source block/event/call data on the Polkadot blockchain. The SubQuery project is already able to index and parse block / extrinsic(transaction) / event data on Substrate, persist into a postgres data schema, and serve queries on the data via GraphQL. + +Our ETL framework will consume the indexed data on a managed SubQuery node via GraphQL, and save to Google BigQuery in a format similar to existing blockchain-etl projects. We plan to orchestrate this ETL to BigQuery via the Google Composer offering on GCP as Airflow DAGs, written in Python. + +The design of the ETL will allow for a varied series of output formats. Users of the framework can choose to download the code and run their own copy of the ETL locally against the SubQuery node, or they can utilize the GCP BigQuery offering. We expect most users of the ETL data to utilize the public offering. + +The architecture and process of executing airflow pipelines within GCP composer are fairly well-documented. We expect that the infrastructure / architectural components for Dot-ETL will be similar to standard deployments within GCP composer - we are unlikely to require anything truly bespoke. + +The first milestone of the project will focus around blocks, extrinsics and events in Substrate, and will produce the same base-level tables (blocks, extrinsics, events). Subsequent milestones will propose a means to extract specific extrinsics / events from particular pallets and parachains, with a possible focus on Defi / RWAs. **We believe that providing focus on DeFi activity related to Real World Assets on Google Cloud is the most promising use of public data to attract attention to the Polkadot ecosystem.** + +We're still investigating the appropriate schema details that will capture data in the most useful /optimal way, but believe that the core tables / schema will be very similar to that of the [Ethereum ETL project](https://ethereum-etl.readthedocs.io/en/latest/). + +There are two main components of the project. The first is the configuration of the SubQuery managed node that will index the components of Substrate that we are interested in. The second component is the Airflow DAG that will communicate with the SubQuery node via a GraphQL API. The DAG will write updates to underlying formats. The initial focus will be on writing to BigQuery tables, but the framework should be written such that other providers / database formats can be accommodated. While we may not write drivers / handlers for each provider or database type, the framework will be written in such a way that will allow the community to write specific handlers that can be easily plugged into the existing framework. + +### Ecosystem Fit + +Questions / Answers on Ecosystem Fit: + +**Q: Where and how does your project fit into the ecosystem?** + +A: Our aim is to provide a foundational framework and approach to ETLing Substrate data into the GCP BigQuery cloud storage medium (+ other mediums as needed). A robust illustrative example will allow others to build upon / extend the framework, and run and maintain the ETL process for general community use. By transforming into GCP BigQuery, we hope to drastically lower the friction required for anyone to analyze and produce insights on the data (developers, analysts, investors, enthusiasts). + +**Q: Who is your target audience (parachain/dapp/wallet/UI developers, designers, your own user base, some dapp's userbase, yourself)?** + +A: Everyone. By building a framework that will make data available in a way that can be queried via SQL, and in conjunction with a repository of query recipes and articles / guides / docs, we allow anyone with some base-level analysis interest to get up and running quickly. Because transaction-level data will also be available in a standard data query format on Google cloud, it will be possible to create any number of dashboards and visualizations on third-party / cloud-based analytic tools. + +**Q: What need(s) does your project meet?** + +A: Analysis / Insights - ability for people (all audience types) to query transaction data at any granularity. Putting this data into an approachable format opens the ability for users to create reports, visualizations, monitors and notifications. Better visibility => more engagement / better understanding => stronger community. Most users of data don't have the data engineering skills or capacity to extract data of this form onto a platform like Google Cloud platform, while remaining highly adept at querying, analyzing and modeling this type of data on such a platform. The DOT-ETl project is meant to remove the major data engineering barrier that exists for these individuals to take advantage of the technological offerings Google Cloud platform in working with PolkaDot data. + +**Q: Are there any other projects similar to yours in the Substrate / Polkadot / Kusama ecosystem? If so, how is your project different? If not, are there similar projects in related ecosystems?** + +A: There is already a team that has created substrate-etl on Google BigQuery. However, we believe there is value to creating redundancy by providing a competing approach to the problem. Our approach differs in two ways (technically): (a) use of the SubQuery indexer, whereas the competing team utilized their own indexer (polkaholic), (b) use of google composer / airflow. + +## Team :busts_in_silhouette: + +### Team members + +- Jonathan +- John + +### Contact + +- **Contact Name:** Jonathan Liang +- **Contact Email:** jonathan.h.liang@gmail.com +- **Website:** https://github.com/liangjh + +### Legal Structure + +- **Registered Address:** N/A +- **Registered Legal Entity:** N/A + +### Team's experience + +The team has extensive technical background backend software engineering and machine learning / data science, and domain knowledge in machine learning, financial services (both retail as well as institutional), lending, and quantitative risk management (market trading risk as well as bank capital). + +Jonathan has worked in both fintech in backend software engineering, as well as institutional financial firms (investment banks / hedge funds) in quantitative risk roles. Please see Jonathan's [Github (liangjh)](https://github.com/liangjh) for some public examples of projects he has built in his free time (private repos also available, pls contact to discuss). Jonathan is currently working on [Cascadius Finance](https://docs.cascadius.finance), a full-stack securitization protocol. + +John served as Head of Data Science & Modeling in FinTech startups, where he led and built teams for over nine years. He also has led adoption and integration of blockchain technology for FinTech clients, namely the [partnership between Visa, Circle and Tala](https://www.forbes.com/sites/ninabambysheva/2021/05/05/visa-partners-with-fintech-startup-tala-to-drive-crypto-adoption-in-emerging-markets/?sh=2b225df77e49). In addition he has notably worked with companies like JD.com, Baidu, Ford Motor Credit, Discover, and Synchrony in the development of machine learning models for financial application. He has regularly served as a thought leader and public figure for credit executives on the subject of machine learning, having spoken on multiple industry panels and at notable conferences such as Lendit Fintech, American Banker’s BankAI and the Marketplace Lending Summit. John has also achieved the level of Competitions Master from the Google owned company Kaggle, for his stellar and consistent performance in real world machine learning competitions. He has formerly reached the rank of one of the top 100 data scientists in the world for his performances with Kaggle. + +### Team Code Repos + +No team code repos at the moment. Please see individual Github repos (below) + +### Team LinkedIn Profiles (if available) + +- https://www.linkedin.com/in/liangjh +- https://www.linkedin.com/in/johncandido/ + + +## Development Status :open_book: + +We are currently in research phase; Development / coding has not started on this project yet. + + +## Development Roadmap :nut_and_bolt: + + +### Overview + +- **Total Estimated Duration:** 8 months +- **Full-Time Equivalent (FTE):** 0.25 +- **Total Costs:** 26,000 USD + +### Milestone 1 — ETL of Relay Chain + Google BigQuery Integration + +- **Estimated duration:** 3-4 months +- **FTE:** 1 +- **Costs:** 8,000 USD + +| Number | Deliverable | Specification | +| -----: | ----------- | ------------- | +| **0a.** | License | Apache 2.0 | +| **0b.** | Documentation | We will provide code document as well as a basic tutorial / instructions in the form of a README that will explain how a user can set up and run the components of the ETL to extract data to queryable formats | +| **0c.** | Testing and Testing Guide | We will have unit tests to ensure functionality. There will be concise instructions on how to run the tests in the guide / readme | +| **0d.** | Docker | The main infrastructural components, including subquery and airflow, will each be shipped with their own Dockerfile | +| 0e. | Article | We will publish an article and how-to guide on Medium that will introduce our work and how to set up the basic Dot-ETL (audience: developers). We will also reference prior work done in the space. | +| 1. | Create SubQuery Managed Node | Utilize SubQuery framework to create a running indexer node on SubQuery's managed services, reading and indexing blocks on the Polkadot network (may involve a few iterations for testing) | +| 2. | Define schema to store underlying base data structures (blocks, extrinsics, events) | Finalize stored format | +| 3. | Define framework interfaces to allow for extensibility | Multiple underlying storage formats can be extended by community (not just limited to BigQuery) | +| 4. | Airflow workflows to read SubQuery updates | Read updates from SubQuery node via GraphQL queries and write to BigQuery on a periodic timeframe| +| 5. | Deploy Airflow to Google Composer | deploy to google composer as a test / note: we won't be maintaining this going forward | +| 6. | Detailed developer guides | Developer-centric guides on how to extend the framework to interoperate with additional database frameworks and cloud platforms. | + + +### Milestone 2 — ETLs for Selected Parachains, Extensions + +- **Estimated Duration:** 3-4 months +- **FTE:** 1 +- **Costs:** 18,000 USD + +| Number | Deliverable | Specification | +| -----: | ----------- | ------------- | +| **0a.** | License | Apache 2.0 | +| **0b.** | Documentation | We will provide detailed documentation for work done on this portion of the grant. | +| **0c.** | Docker | We will provide a Dockerfile(s) that can be used to test all the functionality delivered with this milestone. | +| 0d. | Article | We will publish a follow-up (part 2) article on Medium describing the extensions to the original work | +| 1. | From base tables, extend to parsing 1-2 pallets | With milestone 1 completed and tables create for the core data structures (blocks, extrinsics, events), we can further process those base tables to produce more detailed tables for particular pallets | +| 2. | Framework / methodology to extend to additional pallets | Create a configurable framework that will allow a more imperative approach to defining more detailed ETLs that can be extended to parsing and creating tables on specific pallets | +| 3. | Detailed developer guide | Detailed developer guide on using and extending the framework above - goal is to allow developers to utilize the framework to define more sophisticated ETL steps on top of the base tables, all in python (+ orchestrated by airflow). | + +## Future Plans + +Our vision is to provide the framework which will power the go-to queryable data source for Substrate (polkadot / kusama) transactions - both for the main relay chain as well as for the respective parachains. Users of Dot-ETL can either query the public Google BigQuery database directly or create their own index node for any purpose. We expect the community to devise new use cases and applications for the underlying data. + +We intend to partner with / reach out to the following entities on the sponsorship / maintainance of the cloud-based query and storage formats (i.e. Google BigQuery): +- Polkadot and Web3 Foundation - +- Google Cloud Team - +- Blockchain-ETL (related to Google Cloud Team) + +We also intend to seek integration for this data within the blockchain industry through potential oracle partnerships with protocols like Chainlink. + +## Additional Information :heavy_plus_sign: + +**How did you hear about the Grants Program?** Web3 Foundation Website / Medium / Twitter / Element / Announcement by another team / personal recommendation / etc. + +By recommendation from someone who was already familiar with the Polkadot / Substrate / Kusama projects, as well as the Web3 Foundation's grants program. diff --git a/applications/index.md b/applications/index.md index 197e69c6850..7079f8a1a48 100644 --- a/applications/index.md +++ b/applications/index.md @@ -75,6 +75,8 @@ Use this page for an overview of all public grants and their status. Use the sid | [P2P.ORG](http://p2p.org/) | [Validator Monitoring Service](Validator_Monitoring_Service.md)| [GitHub](https://github.com/p2p-org/polkadot_monitoring_service) | ☐ | ☐ | ☐ | | [Colorful Notion](https://github.com/colorfulnotion) | [Deep Account Analytics in Three Tiers for the Polkadot Data Alliance](DeepAccountAnalytics-PolkadotDataAlliance.md)| [GitHub](https://github.com/colorfulnotion/) | ☐ | ☐ | ☐ | | [Dastanbek Samatov](https://dastansam.github.io/) | [ISO-8553 PoC implementation](ISO-8583-implementation.md)| [GitHub](https://github.com/dastanbeksamatov) | ☐ | ☐ | ☐ | +| [Eiger](https://www.eiger.co/) | [Substrate Move System Pallet, pt. 1](Substrate_Move_System_Pallet_1.md)| [GitHub](https://github.com/eigerco) | ☐ | ☐ | ☐ | +| [Davanti](https://github.com/liangjh) | [Dot-ETL Project](dot_etl.md)| [GitHub](https://github.com/liangjh) | ☐ | ☐ | ☐ | [🔝](#2023) @@ -172,7 +174,7 @@ Use this page for an overview of all public grants and their status. Use the sid | [Blaize.tech](https://blaize.tech/) | [Unified deployment for the collator node](unified_collator_node_deployment.md) | [GitHub](https://github.com/babebort-blaize) | ☐ | ☒ | ☒ | | [Odyssey B.V.](https://odyssey.org/) | [Momentum, an open source, metaverse for digital societies](odyssey_momentum.md) | [GitHub](https://github.com/momentum-xyz) | ☐ | ☐ | ☐ | | [Bela Supernova](https://bsn.si/) | [Rubeus Keeper Stage 2](Rubeus_keeper_st2.md) | [GitHub](https://github.com/bsn-si) | ☐ | ☒ | ☒ | -| [Coong Team](https://coong.xyz/) | [Coong Wallet](coong_wallet.md) | [GitHub](https://github.com/CoongCrafts) | ☐ | ☒ | ☐ | +| [Coong Team](https://coong.xyz/) | [Coong Wallet](coong_wallet.md) | [GitHub](https://github.com/CoongCrafts) | ☐ | ☒ | ☒ | | OCamlMyCaml | [PrivaDEX: Cross-Chain DEX Aggregator MVP](PrivaDEX_aggregator.md) | [GitHub](https://github.com/kapilsinha/privadex) | ☐ | ☒ | ☒ | | [Aband-Network](https://a.band/) | [Substrate Parachain PoS Template](substrate-parachain-PoS-template.md) | [GitHub](https://github.com/Aband-Network/substrate-parachain-PoS-template) | ☐ | ☒ | ☒ | | [MangoBOX labs](https://www.mangobox.xyz/) | [MangoSale Protocol](MangoSale_Protocol.md) | [GitHub](https://github.com/Mangoboxlabs) | ☐ | ☒ | ☐ | diff --git a/applications/substrate_client_java.md b/applications/substrate_client_java.md index 77c90a2a288..cda06048e78 100644 --- a/applications/substrate_client_java.md +++ b/applications/substrate_client_java.md @@ -1,6 +1,6 @@ # Substrate Client for Java -- **Team Name:** Doken +- **Team Name:** Seals - **Payment Address:** Information provided in the "W3F Technical Grant Application Form" ## Project Overview :page_facing_up: @@ -54,11 +54,11 @@ The best approach to reach project’s goals is to use annotations and code gene - [x] `@RpcEncoder`; - [x] `@RpcDecoder`; -- [ ] Pallet - - [ ] `@Pallet`; +- [x] Pallet + - [x] `@Pallet`; - [ ] `@Transaction`; - - [ ] `@Query`; - - [ ] `@EventHandler`. + - [x] `@Storage`; + - [x] `@Event`. These allow the generation of scale serializers, deserializers, RPC methods, code for interaction with pallet, etc. In the next sections you will find further examples. @@ -234,41 +234,41 @@ Our solution targets Substrate instead of Polkadot, and is implemented with code ### Team members -- Alexander Kalankhodzhaev, Team Leader -- Maria Manchovska, Product Manager -- Vadim Nabiev, Senior Developer +- Vadim Nabiev, Team Leader +- Arame Bandari, Product Manager +- Vahram Kobelyan, Senior Developer - Plamen Uzunov, Senior Java developer -- Teodor Georgiev, Software developer -- Maria Kostadinova, Information Designer +- Teodor Georgiev, Software developer ### Contact -- **Contact Name:** Alexander Kalankhodzhaev -- **Contact Email:** Alexander.Kalankhodzhaev@strategyobject.com +- **Contact Name:** Vadim Nabiev +- **Contact Email:** vadim.nabiev@strategyobject.com - **Website:** www.strategyobject.com Grateful if you could also copy the email address doken.network@gmail.com in all official communications. ### Legal Structure -- **Registered Address:** ul. "Tsaribrodska" 70, 1309 Sveta Troitsa, Sofia, Bulgaria -- **Registered Legal Entity:** Strategy Object EOOD +- **Registered Address:** Dubai Media City, Al Thuraya Tower 1 - Al Sufouh - Al Sufouh 2 - Dubai, United Arab Emirates +- **Registered Legal Entity:** Strategy Object FZ-LLC ### Team's experience -Alexander has over 14 years of experience as a software engineer and 3 years as a blockchain tech lead. Vadim has over 10 years as a software enfgineer and 2 years as Rust developer. Plamen is a Senior Engineer with over 15 years experience in particular in Java and cryptography. Teodor is a junior developer who recently joined the team, with a particular focus in Java development. +Vadim has over 10 years of experience as as a software enfgineer and 3 years as Rust developer. Plamen is a Senior Engineer with over 15 years experience in particular in Java and cryptography. Vahram is a Senior Engineer with over 7 years experience in particular in Java. Teodor is a junior developer who recently joined the team, with a particular focus in Java development. ### Team Code Repos -- [Strategy Object](https://github.com/orgs/strategyobject/) -- [Alexander](https://github.com/kalaninja/) -- [Vadim](https://github.com/vnabiev/) -- [Plamen](https://github.com/PapiUzunov/) +- [Strategy Object](https://github.com/strategyobject) +- [Vadim](https://github.com/vnabiev) +- [Vahram](https://github.com/VahramKobelyan) +- [Plamen](https://github.com/PapiUzunov) ### Team LinkedIn Profiles (if available) -- [Alexander](https://www.linkedin.com/in/kalaninja/) - [Vadim](https://www.linkedin.com/in/nabiev-v-r/) +- [Vahram](https://www.linkedin.com/in/kobelyan/) +- [Arame](https://www.linkedin.com/in/aramebandari/) - [Plamen](https://www.linkedin.com/in/plamen-uzunov-2761b47/) - [Teodor](https://www.linkedin.com/in/teodor-georgiev-248914192/) @@ -283,7 +283,7 @@ The current version of the substrate-client-java is available at https://github. ### Overview -- **Total Estimated Duration:** 7 months +- **Total Estimated Duration:** 24 months - **Full-Time Equivalent (FTE):** 2.9 FTE - **Total Costs:** Information provided in the "W3F Technical Grant Application Form" @@ -321,7 +321,7 @@ Implement a query api similar to the one of polkadot-js. Implement a transactions api similar to `api.tx` of polkadot-js. -- **Estimated duration:** 1 month +- **Estimated duration:** 2 months - **FTE:** 3 FTE - **Costs:** Information provided in the "W3F Technical Grant Application Form" @@ -331,41 +331,41 @@ Implement a transactions api similar to `api.tx` of polkadot-js. | 1. | Documentation | We will provide both **inline documentation** of the code and a basic **tutorial** that explains how a user can submit transactions. | | 2. | Testing | Core functions will be fully covered by unit and integration tests to ensure functionality and robustness. | | 3. | Wiki | We will publish a wiki page that explains the details of the implementation for transactions within the substrate-client-java library. | -| 4. | Transactions API | We will add transactions capabilities to the substrate-client-java. | - -### Milestone 4 — RPC sections and methods +| 4. | Transactions API | We will add transactions capabilities to the substrate-client-java. | -Implement RPC sections and methods that remained unimplemented from the previous steps. +### Milestone 4 — Handling of Metadata -- **Estimated duration:** 1 month +- **Estimated duration:** 2 months - **FTE:** 3 FTE - **Costs:** Information provided in the "W3F Technical Grant Application Form" | Number | Deliverable | Specification | | -----: | ----------- | ------------- | | 0a. | License | Apache 2.0 | -| 1. | Documentation | We will provide **inline documentation** of the declared RPC sections and methods. | -| 2. | Testing | Core functions will be fully covered by integration tests to ensure functionality and robustness. | -| 3. | Wiki | We will publish a wiki page that explains the details of the implementation for RPC sections and methods within the substrate-client-java library. | -| 4. | RPC methods | We will add missing RPC sections and methods to the substrate-client-java. | +| 1. | Documentation | We will provide both **inline documentation** of the code and a basic **tutorial** that explains about handling of metadata. | +| 2. | Testing | Core functions will be fully covered by unit and integration tests to ensure functionality and robustness. | +| 3. | Wiki | We will publish a wiki page that explains the details of metadata handling within the substrate-client-java library. | +| 4. | Metadata support | We will add metadata capabilities to the substrate-client-java. | -### Milestone 5 — Handling of Metadata +### Milestone 5 — RPC sections and methods -- **Estimated duration:** 1 month +Implement RPC sections and methods that remained unimplemented from the previous steps. + +- **Estimated duration:** 2 months - **FTE:** 3 FTE - **Costs:** Information provided in the "W3F Technical Grant Application Form" | Number | Deliverable | Specification | | -----: | ----------- | ------------- | | 0a. | License | Apache 2.0 | -| 1. | Documentation | We will provide both **inline documentation** of the code and a basic **tutorial** that explains about handling of metadata. | -| 2. | Testing | Core functions will be fully covered by unit and integration tests to ensure functionality and robustness. | -| 3. | Wiki | We will publish a wiki page that explains the details of metadata handling within the substrate-client-java library. | -| 4. | Metadata support | We will add metadata capabilities to the substrate-client-java. | +| 1. | Documentation | We will provide **inline documentation** of the declared RPC sections and methods. | +| 2. | Testing | Core functions will be fully covered by integration tests to ensure functionality and robustness. | +| 3. | Wiki | We will publish a wiki page that explains the details of the implementation for RPC sections and methods within the substrate-client-java library. | +| 4. | RPC methods | We will add missing RPC sections and methods to the substrate-client-java. | ### Milestone 6 — ED25519 -- **Estimated duration:** 1 month +- **Estimated duration:** 2 months - **FTE:** 2.5 FTE - **Costs:** Information provided in the "W3F Technical Grant Application Form" @@ -381,7 +381,7 @@ Implement RPC sections and methods that remained unimplemented from the previous Implement Constants API similar to `api.consts` of polkadot-js that allows access to the runtime constants. -- **Estimated duration:** 1 month +- **Estimated duration:** 2 months - **FTE:** 2.5 FTE - **Costs:** Information provided in the "W3F Technical Grant Application Form"