From ca0a8083d267c9de2c115762f01255ee4645bf53 Mon Sep 17 00:00:00 2001 From: Mario Altimari Date: Fri, 17 Nov 2023 15:30:41 +0000 Subject: [PATCH 01/27] TuxedoDapp application 1st iteration of the proposal --- applications/TuxedoDapp | 248 ++++++++++++++++++++++++++++++++++++++++ 1 file changed, 248 insertions(+) create mode 100644 applications/TuxedoDapp diff --git a/applications/TuxedoDapp b/applications/TuxedoDapp new file mode 100644 index 00000000000..03fb3b6ffec --- /dev/null +++ b/applications/TuxedoDapp @@ -0,0 +1,248 @@ + + +# 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 endeavors 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 current goal is showcasing the potential of Polkadot with the UTXO paradigm for the end user. The project will consist of two key stages: + +- Stage 1: Simple Web Wallet Creation +- Stage 2: Simple Dapp Development + +### Project Details + +- Stage 1: Simple Web Wallet Creation + +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, runtimeMetadata,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: +Web-based wallet will provide a secure method for private key storage on the client side, such as 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 + +2. Issues Fix in web based wallet :(issues/62) +Current implementation of 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 various browsers(Chrome,firefox,edge). + +**Blockchain Integration**: +Web-based wallet will connect to the blockchain node to fetch relevant data. +We will check if there 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. + +**Technology Stack**: +polkadot{.js} - We will try to re-use as much as possible +Vue.js with Vuex and the Vue Router +TypeScript +webpack +Babel - for backwards compatibility in older Browsers +Localdatabase : IndexedDB or WebSQL, or any lightweight client-side database to store relevant wallet data locally on the user's device. + +- 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 also used as an example in Tuxedo wardrobe https://github.com/Off-Narrative-Labs/Tuxedo/tree/main/wardrobe/kitties +We want to use this concept and extend the wardrobe codebase implementing a basic web interface and allowing the trading of generated pets between users. +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** + +**Peiece_contracts(Rust)**: +In order to support the smart contract on Tuxedo runtime, we need develop a piece (based on UTXO) which is similar to "pallet_contracts" which needs to be integrated in to Tuxedo runtime, incorporating UTXO-based logic. + +**Smart contracts**: +We need develop smart contracts using the Ink language and "Peiece_contracts: developed earlier to support the smart contract on Tuxedo. +Smart contracts are used to create and manage NFTs, allowing each pet to have its own distinct identity, ownership, transfer of ownserships and properties ,etc. + +**Functionality**: +Pet Creation with NFTs: +Represent each pet as a unique NFT on the Tuxedo blockchain. +Use Tuxedo runtime pieces i.e kitties . to handle NFT-based pet creation transactions. + +1. **Breeding and NFT Ownership**: +Dapp ensure NFT ownership is transferred correctly during breeding transactions. +Leverage NFT attributes to determine genetics and other breeding-related factors. + +2. **Trading NFTs**: +Dapp enable a marketplace for trading pets (NFTs) between users. +Implement an offer system for users to make and accept NFT-based offers for pet transactions. + +**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 need customize runtime logic to suit the requirements of the UTXO-based pet trading Dapp. + +**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. + +**Event Handling**: +Dapp Listen for UTXO and NFT-related events to update the user interface in real-time. +Utilize event-driven programming to respond to changes in the UTXO set and NFT ownership. + +**Transaction Confirmation**: +Dapp implements a transaction confirmation mechanism to ensure that users are informed about the progress and finalization of UTXO and NFT-based transaction + +**Personal Dashboard**: +We will develop a personal dashboard for users to view and manage their NFT-based pet collections. +Display detailed information about each NFT, including ownership history and transaction history. + +Tech Stack: +Smart Contracts using INK language +Peiece_contracts to be developed using Rust +IPFS (InterPlanetary File System) for storage +TypeScript +webpack + +### 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 ecosystem 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 implemented Dapp as of today. + +## Team :busts_in_silhouette: + +### Team members + +- Mario Altimari +- Amit Nadiger +- Karan Dev Sapra + +### 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/ +- Karan is a senior Rust/Substrate Engineer + +Noboby applied for a Web3 Foundation grants before. + + +### Team Code Repos + +- Mario Altimari [https://github.com/AltiMario](https://github.com/AltiMario) +- Amit Nadiger [https://github.com/NadigerAmit](https://github.com/NadigerAmit) +- Karan Dev Sapra [https://github.com/aang114](https://github.com/aang114) + +### Team LinkedIn Profiles (if available) + +- Mario Altimari https://www.linkedin.com/in/altimario/ +- Amit Nadiger https://www.linkedin.com/in/amit-nadiger-94a7224/ +- Karan Dev Sapra https://www.linkedin.com/in/karandevsapra/ + + +## 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:** 4 months +- **Full-Time Equivalent (FTE):** 1.5 FTE (Mario, Amit and Karan will work part-time on different areas) +- **Total Costs:** $30000 (USD) + +### Milestone 1 — Stage 1: Simple Web Wallet Creation + +- **Estimated duration:** 1.5 month +- **FTE:** *1.5* +- **Costs:** $10000 (USD) + +| Number | Deliverable | Specification | +| -----: | ----------- | ------------- | +| **0a.** | License | Apache 2.0 / GPLv3 / MIT / Unlicense | +| **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(Privite 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 users 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. | Web based wallet | We will create a web based wallet which will have functionalities like: Storing the private key of user,(send and receive) Transaction support, Basically all the functionalities provided by the CLI based wallet (AmoebaDemo,VerifyCoin,SpendCoins,InsertKey,GenerateKey,ShowKeys,RemoveKey,ShowBalance,ShowAllOutputs) | + + + +### Milestone 2 — Stage 2: Simple Dapp Development + +- **Estimated Duration:** 2.5 month +- **FTE:** 1.5 +- **Costs:** $20000 (USD) + +| Number | Deliverable | Specification | +| -----: | ----------- | ------------- | +| **0a.** | License | Apache 2.0 / GPLv3 / MIT / Unlicense | +| **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 for breed pets, trade pets , view and manage the pets using Tuxedo blockchain and personal 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 pet as NFT", managing the ownership of NFT/Pet, Breeding of pets and Trading and also how use the Dashboard | +| **0e.** | piece_contract | We will create a Piece_contract which is similar to pallet_contract(built using FRAME) which is required for running the smart contract on Tuxedo blockchain| +| **0f.** | Smart Contrcat | We will create a smart contract using the INK language which are used to create and manage NFTs, allowing each pet to have its own distinct identity, ownership, transfer of ownerships and properties,etc. | +| **0g.** | Dapp | We will create a web based Daap to support functionality such as "create the pet as NFT", managing the ownership of NFT/Pet, Breeding of pets and Trading. | +| **0h.** | Personalized Dashboard | We will create a personal dashboard for users to view and manage their NFT-based pet collections. Display detailed information about each NFT, including ownership history and transaction history | +... + + +## Future Plans + +Please include here + +**Authentication**: Web-based wallet will consider multi-factor authentication for enhanced security if required +**Backend Development**: +When we implement the authentication backend server is required to handle user authentication and manage connections to the blockchain node. +**Encrypting the local database:** +We will consider encrypting sensitive data stored in the local database, especially private keys. +**Piece development**: +We would like to develop undeveloped and required pieces which are equivalent to pallets in substrate framework which are built using FRAME . Ex: Babe , Sudo , System , membership ,etc . + + +## 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 From 2a8dc871f6773eb1ea304be327f7d27be14e6cfc Mon Sep 17 00:00:00 2001 From: Amit Nadiger Date: Fri, 17 Nov 2023 21:26:49 +0530 Subject: [PATCH 02/27] Update TuxedoDapp to remove the smart contract . Removed the smart contract part and piece_contract development , since it is not the scope of Dapp development . Smart contract development needs support from underlaying tuxedo runtime. --- applications/TuxedoDapp | 15 ++------------- 1 file changed, 2 insertions(+), 13 deletions(-) diff --git a/applications/TuxedoDapp b/applications/TuxedoDapp index 03fb3b6ffec..f673fa2eefe 100644 --- a/applications/TuxedoDapp +++ b/applications/TuxedoDapp @@ -73,13 +73,6 @@ This dapp is intended for educational purposes only, and not for production use. **Technical Requirements** -**Peiece_contracts(Rust)**: -In order to support the smart contract on Tuxedo runtime, we need develop a piece (based on UTXO) which is similar to "pallet_contracts" which needs to be integrated in to Tuxedo runtime, incorporating UTXO-based logic. - -**Smart contracts**: -We need develop smart contracts using the Ink language and "Peiece_contracts: developed earlier to support the smart contract on Tuxedo. -Smart contracts are used to create and manage NFTs, allowing each pet to have its own distinct identity, ownership, transfer of ownserships and properties ,etc. - **Functionality**: Pet Creation with NFTs: Represent each pet as a unique NFT on the Tuxedo blockchain. @@ -113,8 +106,6 @@ We will develop a personal dashboard for users to view and manage their NFT-base Display detailed information about each NFT, including ownership history and transaction history. Tech Stack: -Smart Contracts using INK language -Peiece_contracts to be developed using Rust IPFS (InterPlanetary File System) for storage TypeScript webpack @@ -220,10 +211,8 @@ We have had conversations with the W3F team to validate the idea and find a star | **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 for breed pets, trade pets , view and manage the pets using Tuxedo blockchain and personal 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 pet as NFT", managing the ownership of NFT/Pet, Breeding of pets and Trading and also how use the Dashboard | -| **0e.** | piece_contract | We will create a Piece_contract which is similar to pallet_contract(built using FRAME) which is required for running the smart contract on Tuxedo blockchain| -| **0f.** | Smart Contrcat | We will create a smart contract using the INK language which are used to create and manage NFTs, allowing each pet to have its own distinct identity, ownership, transfer of ownerships and properties,etc. | -| **0g.** | Dapp | We will create a web based Daap to support functionality such as "create the pet as NFT", managing the ownership of NFT/Pet, Breeding of pets and Trading. | -| **0h.** | Personalized Dashboard | We will create a personal dashboard for users to view and manage their NFT-based pet collections. Display detailed information about each NFT, including ownership history and transaction history | +| **0e.** | Dapp | We will create a web based Daap to support functionality such as "create the pet as NFT", managing the ownership of NFT/Pet, Breeding of pets and Trading. | +| **0f.** | Personalized Dashboard | We will create a personal dashboard for users to view and manage their NFT-based pet collections. Display detailed information about each NFT, including ownership history and transaction history | ... From b3b14333ae6fba37f361d4d363997e745e3cb940 Mon Sep 17 00:00:00 2001 From: Mario Altimari Date: Fri, 17 Nov 2023 20:13:19 +0000 Subject: [PATCH 03/27] Update TuxedoDapp cleaning up --- applications/TuxedoDapp | 71 +++++++++++++++++++---------------------- 1 file changed, 33 insertions(+), 38 deletions(-) diff --git a/applications/TuxedoDapp b/applications/TuxedoDapp index f673fa2eefe..913a0503b06 100644 --- a/applications/TuxedoDapp +++ b/applications/TuxedoDapp @@ -1,5 +1,4 @@ - # TuxedoDapp - **Team Name:** MLabs @@ -13,9 +12,9 @@ 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 endeavors 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. +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 current goal is showcasing the potential of Polkadot with the UTXO paradigm for the end user. The project will consist of two key stages: +Our current goal is to showcase the potential of Polkadot with the UTXO paradigm for the end user. The project will consist of two key stages: - Stage 1: Simple Web Wallet Creation - Stage 2: Simple Dapp Development @@ -24,27 +23,27 @@ Our current goal is showcasing the potential of Polkadot with the UTXO paradigm - Stage 1: Simple Web Wallet Creation -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, runtimeMetadata,chain runtime version,API version) , block info ,. +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: -Web-based wallet will provide a secure method for private key storage on the client side, such as browser's secure storage or hardware wallets. +**Security:** : Private key storage: +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 -2. Issues Fix in web based wallet :(issues/62) -Current implementation of cli based wallet allows sending inputs from multiple owners in a single transaction, but it only supports a single recipient for all specified outputs. +2. Issues Fix in web-based wallet :(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 various browsers(Chrome,firefox,edge). +Web-based wallet will ensure compatibility with at least one browser (Chrome, Firefox or Edge). **Blockchain Integration**: Web-based wallet will connect to the blockchain node to fetch relevant data. -We will check if there any lib such as the one used by "https://polkadot.js.org/" to interact with the Tuxedo based blockchain for easy integration. +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. @@ -60,7 +59,7 @@ Vue.js with Vuex and the Vue Router TypeScript webpack Babel - for backwards compatibility in older Browsers -Localdatabase : IndexedDB or WebSQL, or any lightweight client-side database to store relevant wallet data locally on the user's device. +Local database: IndexedDB or WebSQL, or any lightweight client-side database to store relevant wallet data locally on the user's device. - Stage 2: Dapp Development @@ -76,14 +75,14 @@ This dapp is intended for educational purposes only, and not for production use. **Functionality**: Pet Creation with NFTs: Represent each pet as a unique NFT on the Tuxedo blockchain. -Use Tuxedo runtime pieces i.e kitties . to handle NFT-based pet creation transactions. +Use Tuxedo runtime pieces i.e. kitties. to handle NFT-based pet creation transactions. 1. **Breeding and NFT Ownership**: -Dapp ensure NFT ownership is transferred correctly during breeding transactions. +Dapp ensures NFT ownership is transferred correctly during breeding transactions. Leverage NFT attributes to determine genetics and other breeding-related factors. 2. **Trading NFTs**: -Dapp enable a marketplace for trading pets (NFTs) between users. +Dapp enables a marketplace for trading pets (NFTs) between users. Implement an offer system for users to make and accept NFT-based offers for pet transactions. **Blockchain Integration**: @@ -95,7 +94,7 @@ Dapp implements transaction handling logic in the web application to initiate UT Provide feedback to users on transaction status and confirmations. **Event Handling**: -Dapp Listen for UTXO and NFT-related events to update the user interface in real-time. +Dapp Listen for UTXO and NFT-related events to update the user interface in real time. Utilize event-driven programming to respond to changes in the UTXO set and NFT ownership. **Transaction Confirmation**: @@ -116,9 +115,9 @@ webpack - 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 ecosystem more "bitcoin-based" that want to try Polkadot. +- **Developers and Enthusiasts from other blockchains:** Developers interested in experimenting with another paradigm but also developers from other ecosystem 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. +- **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?** @@ -130,7 +129,6 @@ webpack - Mario Altimari - Amit Nadiger -- Karan Dev Sapra ### Contact @@ -140,7 +138,7 @@ webpack ### 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 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 @@ -153,22 +151,19 @@ He has successfully implemented advanced practices, including Prometheus and Gra 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/ -- Karan is a senior Rust/Substrate Engineer -Noboby applied for a Web3 Foundation grants before. +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) -- Karan Dev Sapra [https://github.com/aang114](https://github.com/aang114) ### Team LinkedIn Profiles (if available) - Mario Altimari https://www.linkedin.com/in/altimario/ - Amit Nadiger https://www.linkedin.com/in/amit-nadiger-94a7224/ -- Karan Dev Sapra https://www.linkedin.com/in/karandevsapra/ ## Development Status :open_book: @@ -179,39 +174,39 @@ We have had conversations with the W3F team to validate the idea and find a star ### Overview -- **Total Estimated Duration:** 4 months -- **Full-Time Equivalent (FTE):** 1.5 FTE (Mario, Amit and Karan will work part-time on different areas) +- **Total Estimated Duration:** 3 months +- **Full-Time Equivalent (FTE):** 2 FTE - **Total Costs:** $30000 (USD) ### Milestone 1 — Stage 1: Simple Web Wallet Creation -- **Estimated duration:** 1.5 month -- **FTE:** *1.5* +- **Estimated duration:** 1 month +- **FTE:** *1* - **Costs:** $10000 (USD) | Number | Deliverable | Specification | | -----: | ----------- | ------------- | -| **0a.** | License | Apache 2.0 / GPLv3 / MIT / Unlicense | -| **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(Privite 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. | +| **0a.** | License | Apache 2.0 / GPLv3 / MIT | +| **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 users 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. | Web based wallet | We will create a web based wallet which will have functionalities like: Storing the private key of user,(send and receive) Transaction support, Basically all the functionalities provided by the CLI based wallet (AmoebaDemo,VerifyCoin,SpendCoins,InsertKey,GenerateKey,ShowKeys,RemoveKey,ShowBalance,ShowAllOutputs) | +| 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 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. | Web-based wallet | We will create a web-based wallet which will have functionalities like Storing the private key of the user,(send and receive) Transaction support, Basically all the functionalities provided by the CLI-based wallet (AmoebaDemo, VerifyCoin, SpendCoins, InsertKey, GenerateKey, ShowKeys, RemoveKey, ShowBalance, ShowAllOutputs) | ### Milestone 2 — Stage 2: Simple Dapp Development -- **Estimated Duration:** 2.5 month -- **FTE:** 1.5 +- **Estimated Duration:** 2 months +- **FTE:** 2 - **Costs:** $20000 (USD) | Number | Deliverable | Specification | | -----: | ----------- | ------------- | -| **0a.** | License | Apache 2.0 / GPLv3 / MIT / Unlicense | -| **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 for breed pets, trade pets , view and manage the pets using Tuxedo blockchain and personal dashboard | +| **0a.** | License | Apache 2.0 / GPLv3 / MIT | +| **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 pets, trade pets, view and manage the pets 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 pet as NFT", managing the ownership of NFT/Pet, Breeding of pets and Trading and also how use the Dashboard | -| **0e.** | Dapp | We will create a web based Daap to support functionality such as "create the pet as NFT", managing the ownership of NFT/Pet, Breeding of pets and Trading. | +|**0d.** | Article | We will publish an **article**/workshop that explains how to use the Dapp which can be used to "create the pet as NFT", managing the ownership of NFT/Pet, Breeding of pets and Trading and also how to use the Dashboard | +| **0e.** | Dapp | We will create a web-based Daap to support functionality such as "create the pet as NFT", managing the ownership of NFT/Pet, Breeding of pets and Trading. | | **0f.** | Personalized Dashboard | We will create a personal dashboard for users to view and manage their NFT-based pet collections. Display detailed information about each NFT, including ownership history and transaction history | ... @@ -226,7 +221,7 @@ When we implement the authentication backend server is required to handle user a **Encrypting the local database:** We will consider encrypting sensitive data stored in the local database, especially private keys. **Piece development**: -We would like to develop undeveloped and required pieces which are equivalent to pallets in substrate framework which are built using FRAME . Ex: Babe , Sudo , System , membership ,etc . +We would like to develop undeveloped and required pieces which are equivalent to pallets in Substrate framework which are built using FRAME. Ex: Babe, Sudo, System, membership, etc. ## Referral Program (optional) :moneybag: From 16deb1c18258b71e569fb8aeee7e74d7a371a3a2 Mon Sep 17 00:00:00 2001 From: Mario Altimari Date: Fri, 17 Nov 2023 20:38:34 +0000 Subject: [PATCH 04/27] Signed TuxedoDapp --- applications/TuxedoDapp | 3 +++ 1 file changed, 3 insertions(+) diff --git a/applications/TuxedoDapp b/applications/TuxedoDapp index 913a0503b06..a251072bc6e 100644 --- a/applications/TuxedoDapp +++ b/applications/TuxedoDapp @@ -230,3 +230,6 @@ We would like to develop undeveloped and required pieces which are equivalent to ## 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 + +[@AltiMario](https://github.com/AltiMario) +[@NadigerAmit](https://github.com/NadigerAmit) From 61b9fc1b37103bc0ddf019bf0e3210abad8dac85 Mon Sep 17 00:00:00 2001 From: Mario Altimari Date: Fri, 17 Nov 2023 20:56:30 +0000 Subject: [PATCH 05/27] final touch TuxedoDapp --- applications/TuxedoDapp | 15 ++++++--------- 1 file changed, 6 insertions(+), 9 deletions(-) diff --git a/applications/TuxedoDapp b/applications/TuxedoDapp index a251072bc6e..e99d18754dd 100644 --- a/applications/TuxedoDapp +++ b/applications/TuxedoDapp @@ -14,14 +14,14 @@ Develop a Tuxedo Web Wallet and Dapp 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 current goal is to showcase the potential of Polkadot with the UTXO paradigm for the end user. The project will consist of two key stages: +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: Simple Web Wallet Creation -- Stage 2: Simple Dapp Development +- Stage 1: Developing a simple Web Wallet +- Stage 2: Developing a basic Dapp ### Project Details -- Stage 1: Simple Web Wallet Creation +- 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. @@ -178,7 +178,7 @@ We have had conversations with the W3F team to validate the idea and find a star - **Full-Time Equivalent (FTE):** 2 FTE - **Total Costs:** $30000 (USD) -### Milestone 1 — Stage 1: Simple Web Wallet Creation +### Milestone 1 — Stage 1: Developing a simple Web Wallet - **Estimated duration:** 1 month - **FTE:** *1* @@ -194,7 +194,7 @@ We have had conversations with the W3F team to validate the idea and find a star -### Milestone 2 — Stage 2: Simple Dapp Development +### Milestone 2 — Stage 2: Developing a basic Dapp - **Estimated Duration:** 2 months - **FTE:** 2 @@ -230,6 +230,3 @@ We would like to develop undeveloped and required pieces which are equivalent to ## 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 - -[@AltiMario](https://github.com/AltiMario) -[@NadigerAmit](https://github.com/NadigerAmit) From db4ba6af30b029c4dd1019b22c940ff2731dad54 Mon Sep 17 00:00:00 2001 From: Amit Nadiger Date: Fri, 24 Nov 2023 17:24:41 +0530 Subject: [PATCH 06/27] Rename TuxedoDapp to TuxedoDapp.md Updated the file extension to .md --- applications/{TuxedoDapp => TuxedoDapp.md} | 0 1 file changed, 0 insertions(+), 0 deletions(-) rename applications/{TuxedoDapp => TuxedoDapp.md} (100%) diff --git a/applications/TuxedoDapp b/applications/TuxedoDapp.md similarity index 100% rename from applications/TuxedoDapp rename to applications/TuxedoDapp.md From eeef02cd78615f09631a68d4e3a1f908b42c88f3 Mon Sep 17 00:00:00 2001 From: Amit Nadiger Date: Fri, 24 Nov 2023 19:01:29 +0530 Subject: [PATCH 07/27] Update TuxedoDapp.md Updated below : 1. Meaning of Feature Parity 2. Updated browsers which will be supported . 3. Meaning and Scope of "Manage NFT" in M2(Dapp) section --- applications/TuxedoDapp.md | 35 ++++++++++++++++++++++++++++------- 1 file changed, 28 insertions(+), 7 deletions(-) diff --git a/applications/TuxedoDapp.md b/applications/TuxedoDapp.md index e99d18754dd..2b47eebf71d 100644 --- a/applications/TuxedoDapp.md +++ b/applications/TuxedoDapp.md @@ -33,13 +33,14 @@ Web-based wallet will provide a secure method for private key storage on the cli **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 +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 web-based and command-line interface (CLI) wallets, have the same set of features and functionalities and both versions provide an equivalent or identical user experience by offering the same core capabilities, options. -2. Issues Fix in web-based wallet :(issues/62) +3. Issues Fix in web-based wallet :(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 at least one browser (Chrome, Firefox or Edge). +4. 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. @@ -103,8 +104,28 @@ Dapp implements a transaction confirmation mechanism to ensure that users are in **Personal Dashboard**: We will develop a personal dashboard for users to view and manage their NFT-based pet collections. Display detailed information about each NFT, including ownership history and transaction history. - -Tech Stack: +Manage NFT means , it icludes below : +1. Viewing NFTs: + Users should be able to see a comprehensive list or visual representation of all the NFTs (pets) they own. + Display detailed information about each NFT, including attributes such as species, color, pattern, eyes, ears, tail, etc. +2. Ownership History: + Show the ownership history of each NFT, indicating when it was created, bred, or traded. + Provide transparency on how the ownership of each pet has changed over time. +3. Transaction History: + Display a record of all transactions involving each NFT, such as creation, breeding, and trading. + Include details like transaction timestamps, involved parties, and any fees associated with the transactions. +4. Breed and Trade Options: + User should be able to initiate breeding and trading directly from the dashboard. + Include options to send breeding requests, accept offers, and initiate trades. +5. Naming and Customization: + Enable users to customize and name their pets directly from the dashboard. + Allow for a personalized touch, letting users give distinct identities to their NFTs. +6. Transfer and Ownership Management: + Provide options for transferring ownership of NFTs to other users within the platform. +7. Interactivity: + Make dashboard interactive, allowing users to click on individual NFTs to access more detailed information or initiate specific actions. + +**Tech Stack:** IPFS (InterPlanetary File System) for storage TypeScript webpack @@ -206,7 +227,7 @@ We have had conversations with the W3F team to validate the idea and find a star | **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 pets, trade pets, view and manage the pets 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 pet as NFT", managing the ownership of NFT/Pet, Breeding of pets and Trading and also how to use the Dashboard | -| **0e.** | Dapp | We will create a web-based Daap to support functionality such as "create the pet as NFT", managing the ownership of NFT/Pet, Breeding of pets and Trading. | +| **0e.** | Dapp | We will create a web-based Daap to support functionality such as "create the pet as NFT", managing the ownership of NFT/Pet, Breeding of pets and Trading.(Meaning of "Managment of NFT" is mentioned above in Dashboard ) | | **0f.** | Personalized Dashboard | We will create a personal dashboard for users to view and manage their NFT-based pet collections. Display detailed information about each NFT, including ownership history and transaction history | ... From c48d8e14847a6347721359e8028240d91924a039 Mon Sep 17 00:00:00 2001 From: Amit Nadiger Date: Fri, 24 Nov 2023 20:19:45 +0530 Subject: [PATCH 08/27] Update TuxedoDapp.md Updated the semantic issues. --- applications/TuxedoDapp.md | 39 +++++++++++++++++++------------------- 1 file changed, 19 insertions(+), 20 deletions(-) diff --git a/applications/TuxedoDapp.md b/applications/TuxedoDapp.md index 2b47eebf71d..9b2e12210eb 100644 --- a/applications/TuxedoDapp.md +++ b/applications/TuxedoDapp.md @@ -1,4 +1,3 @@ - # TuxedoDapp - **Team Name:** MLabs @@ -7,7 +6,7 @@ ## Project Overview :page_facing_up: -Develop a Tuxedo Web Wallet and Dapp +Develop a Tuxedo Web Wallet and DApp ### Overview @@ -17,7 +16,7 @@ The Tuxedo project endeavours to demonstrate the flexibility and interoperabilit 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 +- Stage 2: Developing a basic DApp ### Project Details @@ -36,7 +35,7 @@ Web-based wallet will provide a secure method for private key storage on the cli 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 web-based and command-line interface (CLI) wallets, have the same set of features and functionalities and both versions provide an equivalent or identical user experience by offering the same core capabilities, options. -3. Issues Fix in web-based wallet :(issues/62) +3. 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. 4. Browser compatibility: @@ -62,14 +61,14 @@ webpack Babel - for backwards compatibility in older Browsers Local database: IndexedDB or WebSQL, or any lightweight client-side database to store relevant wallet data locally on the user's device. -- Stage 2: Dapp Development +- 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 also used as an example in Tuxedo wardrobe https://github.com/Off-Narrative-Labs/Tuxedo/tree/main/wardrobe/kitties +We think that a successful showcase of a DApp is Cryptokitties which is also used as an example in Tuxedo wardrobe https://github.com/Off-Narrative-Labs/Tuxedo/tree/main/wardrobe/kitties We want to use this concept and extend the wardrobe codebase implementing a basic web interface and allowing the trading of generated pets between users. -This dapp is intended for educational purposes only, and not for production use. The web-wallet previously developed will be used for this Dapp. +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** @@ -79,27 +78,27 @@ Represent each pet as a unique NFT on the Tuxedo blockchain. Use Tuxedo runtime pieces i.e. kitties. to handle NFT-based pet creation transactions. 1. **Breeding and NFT Ownership**: -Dapp ensures NFT ownership is transferred correctly during breeding transactions. +DApp ensures NFT ownership is transferred correctly during breeding transactions. Leverage NFT attributes to determine genetics and other breeding-related factors. 2. **Trading NFTs**: -Dapp enables a marketplace for trading pets (NFTs) between users. +DApp enables a marketplace for trading pets (NFTs) between users. Implement an offer system for users to make and accept NFT-based offers for pet transactions. **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 need customize runtime logic to suit the requirements of the UTXO-based pet trading Dapp. +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 need customize runtime logic to suit the requirements of the UTXO-based pet trading DApp. **Transaction Handling**: -Dapp implements transaction handling logic in the web application to initiate UTXO-based transactions, including NFT-related transactions, on the Tuxedo blockchain. +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. **Event Handling**: -Dapp Listen for UTXO and NFT-related events to update the user interface in real time. +DaAp Listen for UTXO and NFT-related events to update the user interface in real time. Utilize event-driven programming to respond to changes in the UTXO set and NFT ownership. **Transaction Confirmation**: -Dapp implements a transaction confirmation mechanism to ensure that users are informed about the progress and finalization of UTXO and NFT-based transaction +DApp implements a transaction confirmation mechanism to ensure that users are informed about the progress and finalization of UTXO and NFT-based transaction **Personal Dashboard**: We will develop a personal dashboard for users to view and manage their NFT-based pet collections. @@ -133,16 +132,16 @@ webpack ### 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. +- 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 ecosystem 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. +- **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 implemented Dapp as of today. +- Tuxedo is unique and we are not aware of any implemented DApp as of today. ## Team :busts_in_silhouette: @@ -215,7 +214,7 @@ We have had conversations with the W3F team to validate the idea and find a star -### Milestone 2 — Stage 2: Developing a basic Dapp +### Milestone 2 — Stage 2: Developing a basic DApp - **Estimated Duration:** 2 months - **FTE:** 2 @@ -224,10 +223,10 @@ We have had conversations with the W3F team to validate the idea and find a star | Number | Deliverable | Specification | | -----: | ----------- | ------------- | | **0a.** | License | Apache 2.0 / GPLv3 / MIT | -| **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 pets, trade pets, view and manage the pets using the dashboard | +| **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 pets, trade pets, view and manage the pets 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 pet as NFT", managing the ownership of NFT/Pet, Breeding of pets and Trading and also how to use the Dashboard | -| **0e.** | Dapp | We will create a web-based Daap to support functionality such as "create the pet as NFT", managing the ownership of NFT/Pet, Breeding of pets and Trading.(Meaning of "Managment of NFT" is mentioned above in Dashboard ) | +|**0d.** | Article | We will publish an **article**/workshop that explains how to use the DApp which can be used to "create the pet as NFT", managing the ownership of NFT/Pet, Breeding of pets and Trading and also how to use the Dashboard | +| **0e.** | DApp | We will create a web-based Daap to support functionality such as "create the pet as NFT", managing the ownership of NFT/Pet, Breeding of pets and Trading.(Meaning of "Managment of NFT" is mentioned above in Dashboard section ) | | **0f.** | Personalized Dashboard | We will create a personal dashboard for users to view and manage their NFT-based pet collections. Display detailed information about each NFT, including ownership history and transaction history | ... From 6dde7e19c88dd9dd64d92f8fc9a30208f8b762f2 Mon Sep 17 00:00:00 2001 From: Amit Nadiger Date: Sun, 26 Nov 2023 15:18:50 +0530 Subject: [PATCH 09/27] Update TuxedoDapp.md Updated the M2 features i.e DApp features supported to Kitties based on the features by Kitties pieces in blockchain code . --- applications/TuxedoDapp.md | 28 ++++++++++------------------ 1 file changed, 10 insertions(+), 18 deletions(-) diff --git a/applications/TuxedoDapp.md b/applications/TuxedoDapp.md index 9b2e12210eb..9ffc4cdb9a1 100644 --- a/applications/TuxedoDapp.md +++ b/applications/TuxedoDapp.md @@ -106,26 +106,18 @@ Display detailed information about each NFT, including ownership history and tra Manage NFT means , it icludes below : 1. Viewing NFTs: Users should be able to see a comprehensive list or visual representation of all the NFTs (pets) they own. - Display detailed information about each NFT, including attributes such as species, color, pattern, eyes, ears, tail, etc. -2. Ownership History: - Show the ownership history of each NFT, indicating when it was created, bred, or traded. - Provide transparency on how the ownership of each pet has changed over time. -3. Transaction History: - Display a record of all transactions involving each NFT, such as creation, breeding, and trading. - Include details like transaction timestamps, involved parties, and any fees associated with the transactions. -4. Breed and Trade Options: - User should be able to initiate breeding and trading directly from the dashboard. - Include options to send breeding requests, accept offers, and initiate trades. -5. Naming and Customization: - Enable users to customize and name their pets directly from the dashboard. - Allow for a personalized touch, letting users give distinct identities to their NFTs. -6. Transfer and Ownership Management: - Provide options for transferring ownership of NFTs to other users within the platform. -7. Interactivity: + Display detailed information about each NFT, including attributes such as below : + parents(mom and dad) + free_breedings(numbers) + dna(H256 Hash value) + num_breedings(number) + Status(Ready for raring ,Tired(Only for dad) , Had birth recenty(only for Mom)) . +3. Breed : + User should be able to initiate breeding directly from the dashboard. +4. Interactivity: Make dashboard interactive, allowing users to click on individual NFTs to access more detailed information or initiate specific actions. **Tech Stack:** -IPFS (InterPlanetary File System) for storage TypeScript webpack @@ -226,7 +218,7 @@ We have had conversations with the W3F team to validate the idea and find a star | **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 pets, trade pets, view and manage the pets 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 pet as NFT", managing the ownership of NFT/Pet, Breeding of pets and Trading and also how to use the Dashboard | -| **0e.** | DApp | We will create a web-based Daap to support functionality such as "create the pet as NFT", managing the ownership of NFT/Pet, Breeding of pets and Trading.(Meaning of "Managment of NFT" is mentioned above in Dashboard section ) | +| **0e.** | DApp | We will create a web-based Daap to support functionality such as "create the pet as NFT", managing the ownership of NFT/Pet, Breeding of pets and showing info.(Meaning of "Managment of NFT" is mentioned above in Dashboard section ) | | **0f.** | Personalized Dashboard | We will create a personal dashboard for users to view and manage their NFT-based pet collections. Display detailed information about each NFT, including ownership history and transaction history | ... From a3af1d5933d134c0ef3dfde5b2e8ce0bb2737b22 Mon Sep 17 00:00:00 2001 From: Amit Nadiger Date: Sun, 26 Nov 2023 17:06:33 +0530 Subject: [PATCH 10/27] Update TuxedoDapp.md updated M2 deliverables in all places in accordance with kitties pieces. --- applications/TuxedoDapp.md | 35 ++++++++++++++--------------------- 1 file changed, 14 insertions(+), 21 deletions(-) diff --git a/applications/TuxedoDapp.md b/applications/TuxedoDapp.md index 9ffc4cdb9a1..fce9e41d50a 100644 --- a/applications/TuxedoDapp.md +++ b/applications/TuxedoDapp.md @@ -1,4 +1,4 @@ -# TuxedoDapp +# TuxedoDApp - **Team Name:** MLabs - **Payment Address:** FIAT @@ -66,46 +66,39 @@ Local database: IndexedDB or WebSQL, or any lightweight client-side database to 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 also used as an example in Tuxedo wardrobe https://github.com/Off-Narrative-Labs/Tuxedo/tree/main/wardrobe/kitties -We want to use this concept and extend the wardrobe codebase implementing a basic web interface and allowing the trading of generated pets between users. +We think that a successful showcase of a DApp is Cryptokitties which is provided in Tuxedo warvia pieces in "https://github.com/Off-Narrative-Labs/Tuxedo/tree/main/wardrobe/kitties". +We want to use this concept and extend the wardrobe codebase implementing a basic web interface and allowing breeding of kitties from the users. 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**: -Pet Creation with NFTs: -Represent each pet as a unique NFT on the Tuxedo blockchain. -Use Tuxedo runtime pieces i.e. kitties. to handle NFT-based pet creation transactions. +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. -1. **Breeding and NFT Ownership**: +**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. -2. **Trading NFTs**: -DApp enables a marketplace for trading pets (NFTs) between users. -Implement an offer system for users to make and accept NFT-based offers for pet transactions. **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 need customize runtime logic to suit the requirements of the UTXO-based pet trading DApp. +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 customize runtime logic to suit the requirements of the UTXO-based DApp.(For this scope we plan not to modify the kitties pieces code as much as possible, since the scope is only DApp) **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. -**Event Handling**: -DaAp Listen for UTXO and NFT-related events to update the user interface in real time. -Utilize event-driven programming to respond to changes in the UTXO set and NFT ownership. - **Transaction Confirmation**: DApp implements a transaction confirmation mechanism to ensure that users are informed about the progress and finalization of UTXO and NFT-based transaction **Personal Dashboard**: -We will develop a personal dashboard for users to view and manage their NFT-based pet collections. +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 icludes below : 1. Viewing NFTs: - Users should be able to see a comprehensive list or visual representation of all the NFTs (pets) they own. + 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 : parents(mom and dad) free_breedings(numbers) @@ -215,11 +208,11 @@ We have had conversations with the W3F team to validate the idea and find a star | Number | Deliverable | Specification | | -----: | ----------- | ------------- | | **0a.** | License | Apache 2.0 / GPLv3 / MIT | -| **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 pets, trade pets, view and manage the pets using the dashboard | +| **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 pet as NFT", managing the ownership of NFT/Pet, Breeding of pets and Trading and also how to use the Dashboard | -| **0e.** | DApp | We will create a web-based Daap to support functionality such as "create the pet as NFT", managing the ownership of NFT/Pet, Breeding of pets and showing info.(Meaning of "Managment of NFT" is mentioned above in Dashboard section ) | -| **0f.** | Personalized Dashboard | We will create a personal dashboard for users to view and manage their NFT-based pet collections. Display detailed information about each NFT, including ownership history and transaction history | +|**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.** | 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 of kitties and showing info.(Meaning of "Managment of NFT" is mentioned above in Dashboard section ) | +| **0f.** | 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 ,etc | ... From ec2b6a2f5a177b1a4d4f4a5bd086b665673b9f5f Mon Sep 17 00:00:00 2001 From: Amit Nadiger Date: Tue, 28 Nov 2023 16:06:37 +0530 Subject: [PATCH 11/27] Update TuxedoDapp.md Updated DApp functionalities to support the trading, updating features, searching of kitties ,etc . --- applications/TuxedoDapp.md | 51 ++++++++++++++++++++++++++++---------- 1 file changed, 38 insertions(+), 13 deletions(-) diff --git a/applications/TuxedoDapp.md b/applications/TuxedoDapp.md index fce9e41d50a..1567bd7009f 100644 --- a/applications/TuxedoDapp.md +++ b/applications/TuxedoDapp.md @@ -33,7 +33,7 @@ Web-based wallet will provide a secure method for private key storage on the cli **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 web-based and command-line interface (CLI) wallets, have the same set of features and functionalities and both versions provide an equivalent or identical user experience by offering the same core capabilities, options. +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. 3. 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. @@ -67,7 +67,7 @@ Create a simple decentralized application to demonstrate the viability and matur 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 warvia pieces in "https://github.com/Off-Narrative-Labs/Tuxedo/tree/main/wardrobe/kitties". -We want to use this concept and extend the wardrobe codebase implementing a basic web interface and allowing breeding of kitties from the users. +We want to use this concept and extend the wardrobe codebase implementing a basic web interface and allowing breeding,trading,searching, updating the kitty features such as name , price,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** @@ -75,39 +75,61 @@ This DApp is intended for educational purposes only, and not for production use. **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. +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 ownerships is transferred successfully once trading is completed. + +**Updating the kitty details**: +DApp ensures Kitties details such as name, tradable status(Yes or No), Price can updated. + +**Search kitties owned by other users**: +DApp helps to serach the kitties owned by other users based on uer publick key. +This displayes the list of kitties ownsed by other user 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 customize runtime logic to suit the requirements of the UTXO-based DApp.(For this scope we plan not to modify the kitties pieces code as much as possible, since the scope is only DApp) +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 customize runtime logic to suit the requirements of the UTXO-based DApp. +For this scope we plan to modify the kitties' pieces code for supporting below features: +1. Generating the kitty without parent when 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 transaction +DApp implements a transaction confirmation mechanism to ensure that users are informed about the progress and finalization of UTXO and NFT-based transaction such as Trade, 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 icludes below : +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) - Status(Ready for raring ,Tired(Only for dad) , Had birth recenty(only for Mom)) . + 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 search kitty screen or directly from Trade Kitty screen by inputting the kitty & owner details. 3. Breed : - User should be able to initiate breeding directly from the dashboard. -4. Interactivity: + 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 dashboard interactive, allowing users to click on individual NFTs to access more detailed information or initiate specific actions. **Tech Stack:** @@ -194,8 +216,9 @@ We have had conversations with the W3F team to validate the idea and find a star | **0a.** | License | Apache 2.0 / GPLv3 / MIT | | **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 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. | Web-based wallet | We will create a web-based wallet which will have functionalities like Storing the private key of the user,(send and receive) Transaction support, Basically all the functionalities provided by the CLI-based wallet (AmoebaDemo, VerifyCoin, SpendCoins, InsertKey, GenerateKey, ShowKeys, RemoveKey, ShowBalance, ShowAllOutputs) | +| **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 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 dockr image containing any changes or issue fix in Tuxedo core for wallet implementation | +| **0f.** | Web-based wallet | We will create a web-based wallet which will have functionalities like Storing the private key of the user,(send and receive) Transaction support, Basically all the functionalities provided by the CLI-based wallet (AmoebaDemo, VerifyCoin, SpendCoins, InsertKey, GenerateKey, ShowKeys, RemoveKey, ShowBalance, ShowAllOutputs) | @@ -211,8 +234,9 @@ We have had conversations with the W3F team to validate the idea and find a star | **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.** | 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 of kitties and showing info.(Meaning of "Managment of NFT" is mentioned above in Dashboard section ) | -| **0f.** | 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 ,etc | +|**0e.** | Kitties Pieces: Docker image |Docker image containing the kitties which supports new features such as "Mint kitty without mom and dad , Trade kitty , change ownership of kitty and search keitties" | +| **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 | ... @@ -220,6 +244,7 @@ We have had conversations with the W3F team to validate the idea and find a star Please include here +**Dynamic Wallet**: Make the wallet dynamic by using standard metadata format like FRAME between wallet and the Blockchain , so that any newly created pieces can be tested without extra modification. **Authentication**: Web-based wallet will consider multi-factor authentication for enhanced security if required **Backend Development**: When we implement the authentication backend server is required to handle user authentication and manage connections to the blockchain node. From e5024b370bae9c05d5a056a8c0c5da58b40c3d68 Mon Sep 17 00:00:00 2001 From: Amit Nadiger Date: Tue, 28 Nov 2023 17:50:02 +0530 Subject: [PATCH 12/27] Update TuxedoDapp.md Updated the IPFS requirement to store meta data of kitty. --- applications/TuxedoDapp.md | 1 + 1 file changed, 1 insertion(+) diff --git a/applications/TuxedoDapp.md b/applications/TuxedoDapp.md index 1567bd7009f..4d31b9c3356 100644 --- a/applications/TuxedoDapp.md +++ b/applications/TuxedoDapp.md @@ -135,6 +135,7 @@ Manage NFT means , it includes below : **Tech Stack:** TypeScript webpack +IPFS for strong meta data of kitty such as Name , Trading status , Price ,etc. ### Ecosystem Fit From 6c935ee36549645a3d10a5db998d719d4126b882 Mon Sep 17 00:00:00 2001 From: Amit Nadiger Date: Tue, 28 Nov 2023 19:28:22 +0530 Subject: [PATCH 13/27] Update TuxedoDapp.md Wireframes links are updated. --- applications/TuxedoDapp.md | 20 ++++++++++++-------- 1 file changed, 12 insertions(+), 8 deletions(-) diff --git a/applications/TuxedoDapp.md b/applications/TuxedoDapp.md index 4d31b9c3356..b0e8057b536 100644 --- a/applications/TuxedoDapp.md +++ b/applications/TuxedoDapp.md @@ -61,6 +61,8 @@ webpack Babel - for backwards compatibility in older Browsers Local database: IndexedDB or WebSQL, or any lightweight client-side database to store relevant wallet data locally on the user's device. +Wireframes:https://drive.google.com/file/d/1NX8IlwDh-CwdMg2qLAlC--VSyiZgQOPY/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 @@ -83,14 +85,14 @@ 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 ownerships is transferred successfully once trading is completed. +Ensure ownership is transferred successfully once trading is completed. **Updating the kitty details**: -DApp ensures Kitties details such as name, tradable status(Yes or No), Price can updated. +DApp ensures Kitties details such as name, tradable status(Yes or No), Price can be updated. **Search kitties owned by other users**: -DApp helps to serach the kitties owned by other users based on uer publick key. -This displayes the list of kitties ownsed by other user with all details required for trading such as Gender, Tradable status, Price , Parents , etc. +DApp helps to search the kitties owned by other users 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 ): @@ -137,6 +139,8 @@ TypeScript webpack IPFS for strong meta data of kitty such as Name , Trading status , Price ,etc. +Wireframe:https://drive.google.com/file/d/1pLnz2rzjG2fU30rdXeBpnT6A4DvjPxhy/view?usp=sharing + ### Ecosystem Fit **Where and how does your project fit into the ecosystem?** @@ -149,7 +153,7 @@ IPFS for strong meta data of kitty such as Name , Trading status , Price ,etc. **Are there any other projects similar to yours in the Substrate/Polkadot/Kusama ecosystem?** -- Tuxedo is unique and we are not aware of any implemented DApp as of today. +- Tuxedo is unique and we are not aware of any DApp implemented as of today. ## Team :busts_in_silhouette: @@ -217,8 +221,8 @@ We have had conversations with the W3F team to validate the idea and find a star | **0a.** | License | Apache 2.0 / GPLv3 / MIT | | **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 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 dockr image containing any changes or issue fix in Tuxedo core for wallet implementation | +| **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 which will have functionalities like Storing the private key of the user,(send and receive) Transaction support, Basically all the functionalities provided by the CLI-based wallet (AmoebaDemo, VerifyCoin, SpendCoins, InsertKey, GenerateKey, ShowKeys, RemoveKey, ShowBalance, ShowAllOutputs) | @@ -252,7 +256,7 @@ When we implement the authentication backend server is required to handle user a **Encrypting the local database:** We will consider encrypting sensitive data stored in the local database, especially private keys. **Piece development**: -We would like to develop undeveloped and required pieces which are equivalent to pallets in Substrate framework which are built using FRAME. Ex: Babe, Sudo, System, membership, etc. +We would like to develop undeveloped and required pieces which are equivalent to pallets in the Substrate framework which are built using FRAME. Ex: Babe, Sudo, System, membership, etc. ## Referral Program (optional) :moneybag: From 7855824c6c0cedb871a1aa16ad1118d3ba87f383 Mon Sep 17 00:00:00 2001 From: Amit Nadiger Date: Tue, 28 Nov 2023 19:51:03 +0530 Subject: [PATCH 14/27] Update TuxedoDapp.md Fixed typos --- applications/TuxedoDapp.md | 16 ++++++++-------- 1 file changed, 8 insertions(+), 8 deletions(-) diff --git a/applications/TuxedoDapp.md b/applications/TuxedoDapp.md index b0e8057b536..a0acf67a9a7 100644 --- a/applications/TuxedoDapp.md +++ b/applications/TuxedoDapp.md @@ -69,7 +69,7 @@ Create a simple decentralized application to demonstrate the viability and matur 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 warvia pieces in "https://github.com/Off-Narrative-Labs/Tuxedo/tree/main/wardrobe/kitties". -We want to use this concept and extend the wardrobe codebase implementing a basic web interface and allowing breeding,trading,searching, updating the kitty features such as name , price,tradable status of kitties. +We want to use this concept and extend the wardrobe codebase implementing a basic web interface and allowing breeding,trading,searching, updating the kitty features such as name, price,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** @@ -92,7 +92,7 @@ DApp ensures Kitties details such as name, tradable status(Yes or No), Price can **Search kitties owned by other users**: DApp helps to search the kitties owned by other users 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. +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 ): @@ -101,7 +101,7 @@ For this scope we plan to modify the kitties' pieces code for supporting below f 1. Generating the kitty without parent when 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. +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. @@ -113,7 +113,7 @@ DApp implements a transaction confirmation mechanism to ensure that users are in **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 : +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 : @@ -124,7 +124,7 @@ Manage NFT means , it includes below : num_breedings(number) Tradable(yes or No) Price - Status(Ready for raring ,Tired(Only for dad) , Had birth recently(only for Mom)) . + 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 search kitty screen or directly from Trade Kitty screen by inputting the kitty & owner details. 3. Breed : @@ -137,7 +137,7 @@ Manage NFT means , it includes below : **Tech Stack:** TypeScript webpack -IPFS for strong meta data of kitty such as Name , Trading status , Price ,etc. +IPFS for storing meta data of kitty such as Name, Trading status, Price, etc. Wireframe:https://drive.google.com/file/d/1pLnz2rzjG2fU30rdXeBpnT6A4DvjPxhy/view?usp=sharing @@ -239,7 +239,7 @@ We have had conversations with the W3F team to validate the idea and find a star | **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 supports new features such as "Mint kitty without mom and dad , Trade kitty , change ownership of kitty and search keitties" | +|**0e.** | Kitties Pieces: Docker image |Docker image containing the kitties which supports new features such as "Mint kitty without mom and dad, Trade kitty, change ownership of kitty and search keitties" | | **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 | ... @@ -249,7 +249,7 @@ We have had conversations with the W3F team to validate the idea and find a star Please include here -**Dynamic Wallet**: Make the wallet dynamic by using standard metadata format like FRAME between wallet and the Blockchain , so that any newly created pieces can be tested without extra modification. +**Dynamic Wallet**: Make the wallet dynamic by using standard metadata format like FRAME between wallet and the Blockchain, so that any newly created pieces can be tested without extra modification. **Authentication**: Web-based wallet will consider multi-factor authentication for enhanced security if required **Backend Development**: When we implement the authentication backend server is required to handle user authentication and manage connections to the blockchain node. From 595b64d49301ce9ceccc0b13690b6fd0a8d15925 Mon Sep 17 00:00:00 2001 From: Mario Altimari Date: Tue, 28 Nov 2023 14:46:39 +0000 Subject: [PATCH 15/27] Future Plans update --- applications/TuxedoDapp.md | 80 ++++++++++++++++---------------------- 1 file changed, 34 insertions(+), 46 deletions(-) diff --git a/applications/TuxedoDapp.md b/applications/TuxedoDapp.md index a0acf67a9a7..65f9cfaa12f 100644 --- a/applications/TuxedoDapp.md +++ b/applications/TuxedoDapp.md @@ -25,7 +25,7 @@ Our goal is to showcase the potential of Polkadot using the UTXO paradigm for th 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** +**Technical Requirements** **Security:** : Private key storage: 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. @@ -35,15 +35,15 @@ Web-based wallet will provide a secure method for private key storage on the cli 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. -3. 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. +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. -4. Browser compatibility: +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. +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. @@ -51,10 +51,10 @@ We will consider using libraries that support the specific blockchain's transact **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. +Local database (e.g., IndexedDB, WebSQL, or a lightweight client-side database) to store relevant wallet data locally on the user's device. **Technology Stack**: -polkadot{.js} - We will try to re-use as much as possible +polkadot{.js} - We will try to re-use as much as possible Vue.js with Vuex and the Vue Router TypeScript webpack @@ -68,11 +68,11 @@ Wireframes:https://drive.google.com/file/d/1NX8IlwDh-CwdMg2qLAlC--VSyiZgQOPY/vie 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 warvia pieces in "https://github.com/Off-Narrative-Labs/Tuxedo/tree/main/wardrobe/kitties". -We want to use this concept and extend the wardrobe codebase implementing a basic web interface and allowing breeding,trading,searching, updating the kitty features such as name, price,tradable status of kitties. +We think that a successful showcase of a DApp is Cryptokitties which is provided in Tuxedo warvia 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** +**Technical Requirements** **Functionality**: Kitties Creation with NFTs: @@ -88,17 +88,18 @@ DApp ensures Kitties can be traded between the users. Ensure ownership is transferred successfully once trading is completed. **Updating the kitty details**: -DApp ensures Kitties details such as name, tradable status(Yes or No), Price can be updated. +DApp ensures Kitties details such as name, tradable status(Yes or No) and Price can be updated. **Search kitties owned by other users**: -DApp helps to search the kitties owned by other users based on the user 's public key. +DApp helps to search the kitties owned by other users 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 customize runtime logic to suit the requirements of the UTXO-based DApp. -For this scope we plan to modify the kitties' pieces code for supporting below features: -1. Generating the kitty without parent when user inserts the new key in the wallet.(Basically 1 kitty is provided for free as an onboarding process) +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. @@ -108,12 +109,13 @@ DApp implements transaction handling logic in the web application to initiate UT 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 transaction such as Trade, Breed. +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 : @@ -124,31 +126,33 @@ Manage NFT means, it includes below : num_breedings(number) Tradable(yes or No) Price - Status(Ready for raring,Tired(Only for dad), Had birth recently(only for Mom)) . + 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 search kitty screen or directly from Trade Kitty screen by inputting the kitty & owner details. + Users should be able to buy the kitty from other users via the search kitty screen or directly from 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 dashboard interactive, allowing users to click on individual NFTs to access more detailed information or initiate specific actions. + Make the dashboard interactive, allowing users to click on individual NFTs to access more detailed information or initiate specific actions. **Tech Stack:** TypeScript webpack -IPFS for storing meta data of kitty such as Name, Trading status, Price, etc. +IPFS for strong metadata of kitty such as Name, Trading status, Price, etc. -Wireframe:https://drive.google.com/file/d/1pLnz2rzjG2fU30rdXeBpnT6A4DvjPxhy/view?usp=sharing +Wireframes: https://drive.google.com/file/d/1pLnz2rzjG2fU30rdXeBpnT6A4DvjPxhy/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 ecosystem more "bitcoin-based" that want to try Polkadot. - + +- **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?** @@ -164,7 +168,7 @@ Wireframe:https://drive.google.com/file/d/1pLnz2rzjG2fU30rdXeBpnT6A4DvjPxhy/view ### Contact -- **Contact Name:** Mario Altimari +- **Contact Name:** Mario Altimari - **Contact Email:** marioaltimari@mlabs.city - **Website:** https://www.mlabs.city @@ -186,7 +190,6 @@ Amit has more than 100 technical blogs in Blockchain specifically in Substrate, Nobody applied for a Web3 Foundation grant before. - ### Team Code Repos - Mario Altimari [https://github.com/AltiMario](https://github.com/AltiMario) @@ -197,7 +200,6 @@ Nobody applied for a Web3 Foundation grant before. - 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 @@ -223,9 +225,7 @@ We have had conversations with the W3F team to validate the idea and find a star | **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 which will have functionalities like Storing the private key of the user,(send and receive) Transaction support, Basically all the functionalities provided by the CLI-based wallet (AmoebaDemo, VerifyCoin, SpendCoins, InsertKey, GenerateKey, ShowKeys, RemoveKey, ShowBalance, ShowAllOutputs) | - - +| **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 (AmoebaDemo, VerifyCoin, SpendCoins, InsertKey, GenerateKey, ShowKeys, RemoveKey, ShowBalance, ShowAllOutputs) | ### Milestone 2 — Stage 2: Developing a basic DApp @@ -238,30 +238,18 @@ We have had conversations with the W3F team to validate the idea and find a star | **0a.** | License | Apache 2.0 / GPLv3 / MIT | | **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 supports new features such as "Mint kitty without mom and dad, Trade kitty, change ownership of kitty and search keitties" | -| **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 | +| **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 -Please include here - -**Dynamic Wallet**: Make the wallet dynamic by using standard metadata format like FRAME between wallet and the Blockchain, so that any newly created pieces can be tested without extra modification. -**Authentication**: Web-based wallet will consider multi-factor authentication for enhanced security if required -**Backend Development**: -When we implement the authentication backend server is required to handle user authentication and manage connections to the blockchain node. -**Encrypting the local database:** -We will consider encrypting sensitive data stored in the local database, especially private keys. -**Piece development**: -We would like to develop undeveloped and required pieces which are equivalent to pallets in the Substrate framework which are built using FRAME. Ex: Babe, Sudo, System, membership, etc. - +**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 From 2406e17f6d8156fa90f2937ec242bbf56d5f5711 Mon Sep 17 00:00:00 2001 From: Mario Altimari Date: Tue, 28 Nov 2023 14:52:29 +0000 Subject: [PATCH 16/27] Cost reduction After a better analysis of the scope, we decided to cut the cost by 10% but maintain 3 months as the total estimated duration. --- applications/TuxedoDapp.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/applications/TuxedoDapp.md b/applications/TuxedoDapp.md index 65f9cfaa12f..90adf44bdb7 100644 --- a/applications/TuxedoDapp.md +++ b/applications/TuxedoDapp.md @@ -210,7 +210,7 @@ We have had conversations with the W3F team to validate the idea and find a star - **Total Estimated Duration:** 3 months - **Full-Time Equivalent (FTE):** 2 FTE -- **Total Costs:** $30000 (USD) +- **Total Costs:** $24000 (USD) ### Milestone 1 — Stage 1: Developing a simple Web Wallet From 5b089f2db1c057f993366934816ec7a26539a63c Mon Sep 17 00:00:00 2001 From: Mario Altimari Date: Tue, 28 Nov 2023 14:54:51 +0000 Subject: [PATCH 17/27] Update TuxedoDapp.md --- applications/TuxedoDapp.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/applications/TuxedoDapp.md b/applications/TuxedoDapp.md index 90adf44bdb7..158963c735a 100644 --- a/applications/TuxedoDapp.md +++ b/applications/TuxedoDapp.md @@ -231,7 +231,7 @@ We have had conversations with the W3F team to validate the idea and find a star - **Estimated Duration:** 2 months - **FTE:** 2 -- **Costs:** $20000 (USD) +- **Costs:** $14000 (USD) | Number | Deliverable | Specification | | -----: | ----------- | ------------- | From 15b290f95a598421378f8a914d4101bdd40f5a33 Mon Sep 17 00:00:00 2001 From: Amit Nadiger Date: Tue, 28 Nov 2023 20:57:21 +0530 Subject: [PATCH 18/27] Update TuxedoDapp.md fixed some typos and comments. --- applications/TuxedoDapp.md | 17 ++++++++--------- 1 file changed, 8 insertions(+), 9 deletions(-) diff --git a/applications/TuxedoDapp.md b/applications/TuxedoDapp.md index 158963c735a..baa94acdd08 100644 --- a/applications/TuxedoDapp.md +++ b/applications/TuxedoDapp.md @@ -43,7 +43,7 @@ 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. +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. @@ -58,8 +58,8 @@ polkadot{.js} - We will try to re-use as much as possible Vue.js with Vuex and the Vue Router TypeScript webpack -Babel - for backwards compatibility in older Browsers -Local database: IndexedDB or WebSQL, or any lightweight client-side database to store relevant wallet data locally on the user's device. +Babel - for backward compatibility in older Browsers +Local database: IndexedDB, WebSQL, or any lightweight client-side database to store relevant wallet data locally on the user's device. Wireframes:https://drive.google.com/file/d/1NX8IlwDh-CwdMg2qLAlC--VSyiZgQOPY/view?usp=sharing @@ -70,7 +70,7 @@ Showcase the unique features of UTXO-based transactions on Polkadot, emphasizing 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 warvia 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. +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** @@ -88,10 +88,10 @@ DApp ensures Kitties can be traded between the users. Ensure ownership is transferred successfully once trading is completed. **Updating the kitty details**: -DApp ensures Kitties details such as name, tradable status(Yes or No) and Price can be updated. +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 to search the kitties owned by other users based on the user's public key. +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**: @@ -238,11 +238,10 @@ We have had conversations with the W3F team to validate the idea and find a star | **0a.** | License | Apache 2.0 / GPLv3 / MIT | | **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 | +| **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 ) | +| **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 From c04366fa57a635fc5325b1efba462b58705d5031 Mon Sep 17 00:00:00 2001 From: Mario Altimari Date: Tue, 28 Nov 2023 16:40:59 +0000 Subject: [PATCH 19/27] wireframes shared in pdf format --- applications/TuxedoDapp.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/applications/TuxedoDapp.md b/applications/TuxedoDapp.md index baa94acdd08..105bb2e2ad0 100644 --- a/applications/TuxedoDapp.md +++ b/applications/TuxedoDapp.md @@ -61,7 +61,7 @@ webpack Babel - for backward compatibility in older Browsers Local database: IndexedDB, WebSQL, or any lightweight client-side database to store relevant wallet data locally on the user's device. -Wireframes:https://drive.google.com/file/d/1NX8IlwDh-CwdMg2qLAlC--VSyiZgQOPY/view?usp=sharing +Wireframes: https://drive.google.com/file/d/1sJ2eIvTEMzmwdEPkipes0OGU57OsUblH/view?usp=sharing - Stage 2: DApp Development From 6f0d4a2edd4d4c757c7a103e5c6880eca8a341ba Mon Sep 17 00:00:00 2001 From: Amit Nadiger Date: Tue, 5 Dec 2023 11:16:52 +0530 Subject: [PATCH 20/27] Update TuxedoDapp.md Updated the tech stack for DApp. --- applications/TuxedoDapp.md | 19 +++++++++++-------- 1 file changed, 11 insertions(+), 8 deletions(-) diff --git a/applications/TuxedoDapp.md b/applications/TuxedoDapp.md index 105bb2e2ad0..89a19a4ad15 100644 --- a/applications/TuxedoDapp.md +++ b/applications/TuxedoDapp.md @@ -28,7 +28,7 @@ Focus on simplicity, security, and ease of use to provide a seamless experience **Technical Requirements** **Security:** : Private key storage: -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. +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 @@ -102,7 +102,7 @@ For this scope, we plan to modify the kitties' pieces code to support below feat 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. +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. @@ -128,18 +128,21 @@ Manage NFT means, it includes below : 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 Trade Kitty screen by inputting the kitty & owner details. + 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. + 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:** -TypeScript -webpack -IPFS for strong metadata of kitty such as Name, Trading status, Price, etc. + React Framework(React + Redux + React Router) OR Vue Framework(Vue.js with Vuex and the Vue Router) + Polkadot-JS APIs such as API for getting block data + TypeScript + Babel - for backward compatibility in older Browsers + Local database: IndexedDB + IPFS for strong metadata of kitty such as Name, Trading status, Price, etc. Wireframes: https://drive.google.com/file/d/1pLnz2rzjG2fU30rdXeBpnT6A4DvjPxhy/view?usp=sharing @@ -183,7 +186,7 @@ Wireframes: https://drive.google.com/file/d/1pLnz2rzjG2fU30rdXeBpnT6A4DvjPxhy/vi - 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. +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/ From 944404a9e95ead9ec890bebfe6ad8ea5e5925623 Mon Sep 17 00:00:00 2001 From: Mario Altimari Date: Tue, 5 Dec 2023 09:55:44 +0000 Subject: [PATCH 21/27] Update license --- applications/TuxedoDapp.md | 20 ++++++++++---------- 1 file changed, 10 insertions(+), 10 deletions(-) diff --git a/applications/TuxedoDapp.md b/applications/TuxedoDapp.md index 89a19a4ad15..dd7f6ae6885 100644 --- a/applications/TuxedoDapp.md +++ b/applications/TuxedoDapp.md @@ -61,7 +61,7 @@ webpack Babel - for backward compatibility in older Browsers Local database: IndexedDB, WebSQL, or any lightweight client-side database to store relevant wallet data locally on the user's device. -Wireframes: https://drive.google.com/file/d/1sJ2eIvTEMzmwdEPkipes0OGU57OsUblH/view?usp=sharing +Wireframes: -- work in progress -- - Stage 2: DApp Development @@ -137,14 +137,14 @@ Manage NFT means, it includes below : Make the dashboard interactive, allowing users to click on individual NFTs to access more detailed information or initiate specific actions. **Tech Stack:** - React Framework(React + Redux + React Router) OR Vue Framework(Vue.js with Vuex and the Vue Router) - Polkadot-JS APIs such as API for getting block data - TypeScript - Babel - for backward compatibility in older Browsers - Local database: IndexedDB - IPFS for strong metadata of kitty such as Name, Trading status, Price, etc. + - React Framework(React + Redux + React Router) OR Vue Framework(Vue.js with Vuex and the Vue Router) + - Polkadot-JS APIs such as API for getting block data + - TypeScript + - Babel - for backward compatibility in older Browsers + - Local database: IndexedDB + - IPFS for strong metadata of kitty such as Name, Trading status, Price, etc. -Wireframes: https://drive.google.com/file/d/1pLnz2rzjG2fU30rdXeBpnT6A4DvjPxhy/view?usp=sharing +Wireframes: -- work in progress -- ### Ecosystem Fit @@ -223,7 +223,7 @@ We have had conversations with the W3F team to validate the idea and find a star | Number | Deliverable | Specification | | -----: | ----------- | ------------- | -| **0a.** | License | Apache 2.0 / GPLv3 / MIT | +| **0a.** | License | GPLv3 | | **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. | @@ -238,7 +238,7 @@ We have had conversations with the W3F team to validate the idea and find a star | Number | Deliverable | Specification | | -----: | ----------- | ------------- | -| **0a.** | License | Apache 2.0 / GPLv3 / MIT | +| **0a.** | License | GPLv3 | | **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 | From f26b0e49a46179e8da584e4f5196531115a84302 Mon Sep 17 00:00:00 2001 From: Amit Nadiger Date: Tue, 5 Dec 2023 15:39:01 +0530 Subject: [PATCH 22/27] Update TuxedoDapp.md Removed the Amoeba demo from wallet functionality. --- applications/TuxedoDapp.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/applications/TuxedoDapp.md b/applications/TuxedoDapp.md index dd7f6ae6885..0039cfc8e5a 100644 --- a/applications/TuxedoDapp.md +++ b/applications/TuxedoDapp.md @@ -228,7 +228,7 @@ We have had conversations with the W3F team to validate the idea and find a star | **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 (AmoebaDemo, VerifyCoin, SpendCoins, InsertKey, GenerateKey, ShowKeys, RemoveKey, ShowBalance, ShowAllOutputs) | +| **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 From 98ac7f23fb416663913f8bd0974f186b3b1b56a7 Mon Sep 17 00:00:00 2001 From: Mario Altimari Date: Tue, 5 Dec 2023 17:17:52 +0000 Subject: [PATCH 23/27] Added wallet wireframes --- applications/TuxedoDapp.md | 18 +++++++++--------- 1 file changed, 9 insertions(+), 9 deletions(-) diff --git a/applications/TuxedoDapp.md b/applications/TuxedoDapp.md index 0039cfc8e5a..d7669532ea1 100644 --- a/applications/TuxedoDapp.md +++ b/applications/TuxedoDapp.md @@ -53,15 +53,15 @@ We will consider using libraries that support the specific blockchain's transact 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. -**Technology Stack**: -polkadot{.js} - We will try to re-use as much as possible -Vue.js with Vuex and the Vue Router -TypeScript -webpack -Babel - for backward compatibility in older Browsers -Local database: IndexedDB, WebSQL, or any lightweight client-side database to store relevant wallet data locally on the user's device. - -Wireframes: -- work in progress -- +**Tech Stack**: +- polkadot{.js} - We will try to re-use as much as possible +- Vue.js with Vuex and the Vue Router +- TypeScript +- webpack +- Babel for backward compatibility in older Browsers +- Local database: IndexedDB, WebSQL, or any lightweight client-side database to store relevant wallet data locally on the user's device. + +Wallet Wireframes: [![Wallet wireframes](https://lh3.googleusercontent.com/d/1XxslvAv3H5BbjVa2sEYMSV3tjYpdKTbi=w3692-h1932-iv1)](https://drive.google.com/file/d/1XxslvAv3H5BbjVa2sEYMSV3tjYpdKTbi/view?usp=sharing) - Stage 2: DApp Development From 36f43a0b7dab520d3e500c938d31af530ba6b7b2 Mon Sep 17 00:00:00 2001 From: Mario Altimari Date: Tue, 5 Dec 2023 18:37:22 +0000 Subject: [PATCH 24/27] wireframes completed, new licence, added testing framework --- applications/TuxedoDapp.md | 30 ++++++++++++++++-------------- 1 file changed, 16 insertions(+), 14 deletions(-) diff --git a/applications/TuxedoDapp.md b/applications/TuxedoDapp.md index d7669532ea1..f2cd9a29124 100644 --- a/applications/TuxedoDapp.md +++ b/applications/TuxedoDapp.md @@ -54,21 +54,22 @@ web-based wallet will consider using databases for storing non-sensitive user da 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} - We will try to re-use as much as possible -- Vue.js with Vuex and the Vue Router +- 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 -- Local database: IndexedDB, WebSQL, or any lightweight client-side database to store relevant wallet data locally on the user's device. +- IndexedDB for Local database +- Jest as JavaScript testing framework -Wallet Wireframes: [![Wallet wireframes](https://lh3.googleusercontent.com/d/1XxslvAv3H5BbjVa2sEYMSV3tjYpdKTbi=w3692-h1932-iv1)](https://drive.google.com/file/d/1XxslvAv3H5BbjVa2sEYMSV3tjYpdKTbi/view?usp=sharing) +Wallet Wireframes: ![Wallet wireframes](https://lh3.google.com/u/0/d/1nzE2_uqK5V4IwUJJPb92Q_WJk3RDR9UL=w3692-h1932-iv2) - 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 warvia pieces in "https://github.com/Off-Narrative-Labs/Tuxedo/tree/main/wardrobe/kitties". +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. @@ -137,14 +138,15 @@ Manage NFT means, it includes below : Make the dashboard interactive, allowing users to click on individual NFTs to access more detailed information or initiate specific actions. **Tech Stack:** - - React Framework(React + Redux + React Router) OR Vue Framework(Vue.js with Vuex and the Vue Router) - - Polkadot-JS APIs such as API for getting block data - - TypeScript - - Babel - for backward compatibility in older Browsers - - Local database: IndexedDB - - IPFS for strong metadata of kitty such as Name, Trading status, Price, etc. +- 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 -Wireframes: -- work in progress -- +DApp Wireframes: ![DApp wireframes](https://lh3.google.com/u/0/d/1dCr5Wwi0L-fGPdwAQGFPDhmTeBQYPDy1=w3692-h1932-iv1) ### Ecosystem Fit @@ -223,7 +225,7 @@ We have had conversations with the W3F team to validate the idea and find a star | Number | Deliverable | Specification | | -----: | ----------- | ------------- | -| **0a.** | License | GPLv3 | +| **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. | @@ -238,7 +240,7 @@ We have had conversations with the W3F team to validate the idea and find a star | Number | Deliverable | Specification | | -----: | ----------- | ------------- | -| **0a.** | License | GPLv3 | +| **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 | From ace2472a93f9521230cde603e5c9c79e093f1d17 Mon Sep 17 00:00:00 2001 From: Mario Altimari Date: Tue, 5 Dec 2023 18:51:26 +0000 Subject: [PATCH 25/27] fixed linked images --- applications/TuxedoDapp.md | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/applications/TuxedoDapp.md b/applications/TuxedoDapp.md index f2cd9a29124..1a57fd2014a 100644 --- a/applications/TuxedoDapp.md +++ b/applications/TuxedoDapp.md @@ -62,7 +62,7 @@ Local database (e.g., IndexedDB, WebSQL, or a lightweight client-side database) - IndexedDB for Local database - Jest as JavaScript testing framework -Wallet Wireframes: ![Wallet wireframes](https://lh3.google.com/u/0/d/1nzE2_uqK5V4IwUJJPb92Q_WJk3RDR9UL=w3692-h1932-iv2) +Wallet Wireframes: [![Wallet wireframes](https://lh3.googleusercontent.com/d/1nzE2_uqK5V4IwUJJPb92Q_WJk3RDR9UL=-h1932-iv2)](https://drive.google.com/file/d/1nzE2_uqK5V4IwUJJPb92Q_WJk3RDR9UL/view?usp=sharing) - Stage 2: DApp Development @@ -146,7 +146,8 @@ Manage NFT means, it includes below : - IPFS for storing metadata related to the kitty such as Name, Trade status, Price, etc. - Jest as JavaScript testing framework -DApp Wireframes: ![DApp wireframes](https://lh3.google.com/u/0/d/1dCr5Wwi0L-fGPdwAQGFPDhmTeBQYPDy1=w3692-h1932-iv1) +DApp Wireframes: [![Wallet wireframes](https://lh3.googleusercontent.com/d/1dCr5Wwi0L-fGPdwAQGFPDhmTeBQYPDy1=w3692-h1932-iv1)](https://drive.google.com/file/d/1dCr5Wwi0L-fGPdwAQGFPDhmTeBQYPDy1/view?usp=sharing) + ### Ecosystem Fit From db384484f741977a27412a23644e6a5d4f309d58 Mon Sep 17 00:00:00 2001 From: AltiMario Date: Tue, 9 Jan 2024 12:53:58 +0800 Subject: [PATCH 26/27] GRANDPA formal verification 1st draft --- applications/grandpa_formal_verification.md | 578 ++++++++++++++++++++ 1 file changed, 578 insertions(+) create mode 100644 applications/grandpa_formal_verification.md diff --git a/applications/grandpa_formal_verification.md b/applications/grandpa_formal_verification.md new file mode 100644 index 00000000000..28eb758d9e4 --- /dev/null +++ b/applications/grandpa_formal_verification.md @@ -0,0 +1,578 @@ +# GRANDPA formal verification + +- **Team Name:** MLabs +- **Payment Address:** FIAT +- **[Level](https://github.com/w3f/Grants-Program/tree/master#level_slider-levels):** 3 + +## Project Overview :page_facing_up: + +This application is in response to the RFP ["Formal Guarantees for GRANDPA Finality Gadget"](https://grants.web3.foundation/docs/RFPs/formal_guarantees_for_grandpa) + +### Overview + +MLabs has extensive experience in formal verification processes gained through many Cardano projects, where formal verification is (in many cases) a key requirement. Mlabs would like to share its knowledge and expertise with Polkadot in this peculiar area of software development. + +## Project Details + +### **_The proof approach_** + +When mathematicians write proofs with 'pen and paper', they need to review them by themselves multiple times before they share them with the mathematical community. Even then they need to pass the scrutiny of multiple pairs before the proofs can be accepted. Although this process exists and is followed rigorously, mistakes can happen, and invalid results can reach the public, in those cases, mathematicians usually offer new proofs of statements and in very rare cases they retract the results. + +Proof assistants are more rigorous than people in the sense that unless we explicitly request for exculpation of proof, the proof assistant would reject to accept a non-rigorous proof. + +On the other side, proof assistants have the weakness that the validity of the proof is tied to various assumptions: + +- The implementation of the 'minimal kernel' of the proof assistants is done right. +- The language of implementation and its compiler/interpreter are right. +- The previous tools used to create the compiler/interpreter do a correct translation of them. + +In that direction, we can go back in time across multiple languages and compilers/interpreters, but even summing that all of them are correctly implemented, we also need to ensure that: + +- The machine that is running is in good condition and results are reproducible +In this aspect, we can go as far as to ensure that the machine can’t be a victim of cosmic rays or other rare cases that can cause the hardware fault. + +It is for this reason that although the '4 colors theorem' has been proven with the help of COQ, there is a controversy in the mathematical/logic community about its validity as a formal proof. +With this in mind, we propose an approach to the proofs that we hope can minimize the risks of faults by the mix of both the human procedure and the machine verification. + +The method consists of writing down two kinds of proofs, one the traditional 'pen and paper' proof, and the other implemented in the proof assistant. The idea is to do first the `pen and paper` proof and then iterate over the proof attempts in the proof assistant to refine the 'pen and paper' proof until we can convince the proof assistant that our proof is right. This way, we would end with two proofs that are closely related and verified by both humans and computers. + +An example of the successful application of a similar approach can be found in the paper + +As a consequence of this method, we can end with a large portion of 'technical lemmas', those are statements that aren’t needed for us humans but that the proof assistant needs, or otherwise it would reject the proof. This is an inevitable result to the best of our knowledge, and the growth of those 'technical lemmas' can be exponential over time. + +For this reason, we present a plan of work in which we try to discover as many of the required '_technical lemmas_' as possible in the shortest amount of time possible. This way, after the discovery of the 'technical lemmas', we can review the plan and adjust it. A possible outcome of this is that we may discover that the approach of formal verification of the GRANDPA protocol can’t be made in a reasonable time or an established budget. The early discovery of 'technical lemmas' would allow us to stop the work before spending too many resources. + +We can split the plan into three main sections: + +- Preamble, which corresponds to sections 2 and 3 of the GRANDPA paper. +- Safety, corresponds to section 4.1. +- Liveness, corresponds to section 4.2. + + Every section can also be divided into: + +- Search for required abstractions +- Modification of proofs and discovery of 'technical lemmas' +- Writing of the statements in the proof assistant without proofs +- Proofs of the statements +However, the '_Search of required abstractions_' would happen mainly in the '_Preamble section_'. +A detailed list of the required steps for every section is presented below. + +### Preamble + +1. Sketch proofs of section 2 lemmas +2. Split of section 2 proofs in more elemental lemmas +3. Formal proofs of the lemmas and formal definition of the `g` function outside the proof assistant +4. Proofs refactorization in a way that can be followed in COQ code +5. List all the required structures to define the `g` function and to express the GRANDPA algorithm +6. Split the list of required structures in implementable ones and those with only interfaces +7. Write the interface of all the structures in the list +8. Write the statements of all the lemmas and the principal conclusions +9. Implementation of the `g` function using only the interfaces +10. Implementation of the GRANDPA protocol using only the interfaces +11. Proofs of section 2 lemmas + +### Safety + +12. Refactor of proof sketches in section 4.1 using the developed abstractions. +13. Split the proofs of section 4.1 in more elemental lemmas. +14. Formal proofs of section 4.1 lemmas. +15. Refine proofs to make them as close to COQ reasoning as possible. +16. Write the statements to be proved in COQ. +17. Proof of the lemma 4.2 +18. Proof of Theorem 4.1 +19. Proof of Corollary 4.3 +20. Proof of intermediate lemmas. + +### Liveness + +21. Refactor of proof sketches of section 4.2 +22. Split of proofs of section 4.2 in more elemental lemmas. +23. Formal proofs of section 4.2 lemmas. +24. Refine proofs to make them as close to COQ reasoning as possible. +25. Write statements to be proved in COQ. +26. Proof of lemma 4.4. +27. Proof of lemma 4.5. +28. Proof of lemma 4.6. +29. Proof of lemma 4.7. +30. Proof of lemma 4.8. +31. Proof of lemma 4.9. +32. Proof of intermediate lemmas. + +### Disclaimer on code extraction + +When we say code extraction, we don’t mean full implementation of the mentioned functions or data types. We refer to literal extraction of the functions/data types as is to `Haskell` code without extraction of the required definitions for the result to be a compilable program in `Haskell`. +This allows us to replace some types and functions used in `COQ` with those already existing in the `Haskell` ecosystem. +The complete extraction of the protocol including all the needed types would require a complete implementation of the protocol and is out of the scope of this proposal. + +### Detailed activities + +#### 1. Sketch proofs of section 2 lemmas + +The lemmas 2.5 and 2.6 were stated without proof after the introduction of the required definitions and an informal discussion. This task is about refactoring such statements in an ordered sequence, highlighting the steps required for the proof, and ensuring that those two lemmas are true. +The latter part of the task concerns the lemma 2.5, in our exploration of the GRANDPA paper we had limited time and were unable to conclude its truthfulness. +The deliverable of this task is the sketch of the proofs in a readable format, such as PDF, but other formats may be acceptable. + +#### 2. Split section 2 proofs in more elemental lemmas + +For this task, we would review the sketch of the proofs and identify sections of it that may be difficult for a proof assistant to accept without further work, then establish such facts as separate lemmas. +The deliverable for this is modifications to the document of task 1. + +#### 3. Formal proofs of the lemmas and formal definition of the 'g' function outside the proof assistant + +Until now, we have only sketches of proofs, that is, informal proof written in a mixture of formal statements and regular English prose without much care for the details. This task is to take those sketches and transform them into more formal statements, with close attention to the details of the proofs. +In this process, we may find new technical lemmas. +The deliverable for this is more editions of the task 1 document. + +#### 4. Proofs refactorization in a way that can be followed in COQ code + +The deliverable of the previous task would give us formal proofs in an amicable form for COQ. However, we expect that we may discover even more technical lemmas if we refactor the proofs to make them as close to COQ code as possible. +Although we expect to find more technical lemmas, we also hope to have a semi-stable structure of proofs. +The deliverable for this is more editions of the task 1 document. + +#### 5. List all the required structures to define the `g` function and to express the GRANDPA algorithm + +The last refactor should highlight the necessary structures to implement the g function and the GRANDPA algorithm, this task consists of grouping all of them with the properties of such structures used in the proofs. +The time of this task is bound by the amount of structures and properties that are needed. + +#### 6. Split the list of required structures into implementable ones and those with only interfaces + +This is a critical task for the project. +In principle, all the structures used can be left as interfaces and all its properties may be assumed. Doing this will help with very complex structures but abusing it would introduce doubts on the resulting proof. + +The objective of this task is to equilibrate the pros and cons of leaving every structure as a simple interface or implementation of it. We also want to consider the replacement of some structures used in the paper with others more adequate for the proof assistant. + +A primer example is Sets and Blockchains. + +- Sets are known to be hard to reason using a proof assistant, and we may need to replace it with a more friendly structure. +- Blocks of chains can be implemented and this may help to generate very natural induction principles that would help in proofs. + +When we refer to 'implement' we don’t mean a full implementation that can be extracted but a minimal implementation that captures the properties we are looking for in the proof. + +For example, in the case of a Blockchain, we won’t implement the needed hash functions, but instead, we would implement it in a way that the concept of 'a' block B that is not the original block has a previous block B 'associated'. + +Of huge concern are the structures that would express the time relation, for now, we model them as regular functions that depend on the time, but we may need better models for inclusion of reasoning of the algorithm of GRANDPA. + +We also include the research for suitable libraries that implement the structures that require implementation in this task. + +The deliverable is the inclusion of all the results and considerations in the document of task 1. + +#### 7. Write the interface of all the structures in the list + +Although some structures may need an implementation, we begin by expressing all the structure's interfaces. + +This task also includes the setting of a reproducible environment for programming in COQ. + +Deliverable: Establishment of a repository with COQ code with all the necessary interfaces. + +#### 8. Write the statements of all the lemmas and the principal conclusions + +Translate the lemmas that we want to prove in COQ and modify the interface of structures as needed. + +**Deliverable:** Changes in the COQ code. + +#### 9. Implementation of the 'g' function using only the interfaces + +This requires some exploration, the implementation can be made in various ways and some of them would be better suited for proofs. +**Optional:** write a version using only system F features, allowing code extraction (need more time). + +All the considered alternatives of the '_g_' function should be preserved. +Sometimes when we want to prove something about a thing '_c_' we can find an equivalent representation of '_c_' as another thing '_a_' for which this task can be trivial. Once we have such an '_a_', we can proceed to establish how '_c_' and '_a_' are the '_same_' in some sense, and exploit the fact that we have our proof for '_a_' to get our proof for '_c_'. + +**Deliverable:** Addition of various versions of '_g_' to the code. + +#### 10. Implementation of the protocol using only the interfaces + +As in the last task, we need to explore different ways of implementing the algorithm, maybe with various versions of '_g_'. The explanation for this is the same as in task 9. + +**Deliverable:** Addition of various versions of the GRANDPA algorithm to the code. + +**Optional:** write a version using only system F features, allowing code extraction (need more time) + +#### 11. Proofs of section 2 lemmas + +For this, we can think of this task as successful if we can do it in a short time. +If we haven’t stopped at this point, it means that we see the proof of these two lemmas as something possible. +This task also includes the completion of all the technical lemmas involved so that we can claim that we have complete proof. +Deliverable: First proofs in code. +Optional: Code extraction to Haskell. + +#### 12. Refactor of proof sketches in section 4.1 using the developed abstractions + +Utilize the abstractions developed until now to express the lemmas of section 4.1 and its proofs sketch, this includes a change in the order of introduction of 4.2 and 4.1. + +**Deliverable:** Audition of the proof sketches to document task 1. + +#### 13. Split the proofs of section 4.1 in more elemental lemmas + +This is part of our effort to discover technical lemmas. +Thanks to the previous effort, some lemmas should be already proven, reducing the future amount of work. + +**Deliverable:** Addition of the refactors to document of task 1. + +#### 14. Formal proofs of section 4.1 lemmas + +We take the sketches of the previous task and use them to establish formal proofs. +We should use as much as we can of the already defined abstractions, their properties, and the existing technical lemmas. +We expect to find new technical lemmas, but not so much of them. + +**Deliverable:** Addition of the new proofs and lemmas to document task 1. + +#### 15. Refine proofs to make them as close to COQ reasoning as possible + +The previous proofs for section 4.1 should put us in the right direction, but we may have some concessions for humans before. This task must clean up all the results and format them in a way that the proof can be followed in COQ. + +**Deliverable:** Addition of the new proofs to document of task 1. + +#### 16. Write the statements to be proved in COQ + +Utilizing the previously developed structures, formalize the statements to be proved in COQ. +We may need to still do a few corrections, but those must be minimal. +Deliverable: Changes in the COQ code, including the new statements + +#### 17. Proof of the lemma 4.2 + +The lemma 4.2 is used in the proof of theorem 4.1, we need to state it before lemma 4.1 +While developing this poof, new auxiliary lemmas can be created and may be left as pending proofs. + + **Deliverable:** Proof of lemma 4.2 with maybe some assumptions to be proved. + +#### 18. Proof of Theorem 4.1 + +This is the main theorem establishing the safety of the protocol, it introduces an algorithm to find a set of Byzantine voters in case of failure. We may change on opinion later, but for now, we propose to implement the described algorithm separately and establish properties about it before we proceed to the proof. +Some assumptions may be left open while working on the proof. + +**Deliverable:** Proof of theorem 4.1 and establishment of the algorithm to find Byzantine voters in case of failure. + +#### 19. Proof of Corollary 4.3 + +This is an immediate consequence of theorem 4.1 in the proof assistant, but the translation to the assistant may make this a not immediate fact. + +**Deliverable:** Proof of corollary 4.3 + +#### 20. Proof of intermediate lemmas + +Over the way to proof 4.1, 4.2, and 4.3, we may leave some assumptions (lemmas), this is the task responsible to complete the more critical of them. +Critical here means, non-technical lemmas. +If the amount of non-technical lemmas is low, we can spend the rest of the time with the technical lemmas. + +**Deliverable:** A complete formal verification of the liveness of the algorithm. + +#### 21. Refactor of proof sketches of section 4.2 + +As with the other two sections, this task consists of modifying the proof sketches provided in the paper and modify them. Among other things, the result sketches must include the mention of all the steps necessary to prove the corresponding result. So, if a sketch includes a sentence like “An easy induction completes the proof of the proposition” we should replace it specifying in prose what the inductive hypothesis should be and sketches for the 0 and inductive step. +Even with this requirement, the proofs are expected to be sketches and not formal proofs. + +**Deliverable:** Addition of the liveness sketches to document of task 1. + +#### 22. Split of proofs of section 4.2 in more elemental lemmas + +In the previous proofs, the paper omitted the network involved as much as it could, and this approach worked fine. +However, in liveness, we need to explicitly work with the model of time. +These two facts mean that we may find many intermediate lemmas in this section, as we haven’t needed lemmas involving explicit times. This alone augments the expected required time for the task related to liveness compared with the times established for safety. + +**Deliverable:** Addition of new lemmas to document of task 1. + +#### 23. Formal proofs of section 4.2 lemmas + +This task is for the exchange of the previous proof sketches for new proofs that are completely formal. As mentioned in the previous task, we now depend heavily on time, this may mark an increase in the number of technical lemmas discovered in this task. + +**Deliverable:** Addition of technical lemmas and formal proofs for section 4.2 in the document of task 1. + +#### 24. Refine proofs to make them as close to COQ reasoning as possible + +We should make changes as needed in the proofs to make them friendly to COQ. As in the previous task, we expect the discovery of many technical lemmas. + +**Deliverable:** Addition of the new proofs to the document of task 1. + +#### 25. Write statements to be proved in COQ + +We may find that we need to some adjustments to express the statements to prove, which can increase by a little amount the required time for the translation. + +**Deliverable:** Addition of the statements to be proved in COQ. + +#### 26. Proof of lemma 4.4 + +Although we have used lemmas 2.5 and 2.6 in the previous section, the use was implicit, now the sketch of the proof of lemma 4.4 directly involves the use of both lemmas. This means that 4.4 is particularly dependent on them. + +**Deliverable:** Inclusion of the proof for lemma 4.4 in COQ. + +#### 27. Proof of lemma 4.5 + +This lemma leaves open the end of the proof with the sentence “An easy induction completes the proof of the proposition.”. There's a high probability that the previous steps split this proof, this task only involves the proof of the main statement of the lemma and leaves open the chance that the intermediate results may be proved later. + +**Deliverable:** Inclusion of proof of lemma 4.5 in COQ. + +#### 28. Proof of lemma 4.6 + +This lemma introduces 4 conclusions, although COQ can express this, it is better to write a separate lemma for every conclusion. We expect to do the split in the previous stages for liveness. This means that this particular task may be split in the future. + +**Deliverable:** Proofs of lemmas directly stating the results of lemma 4.6 + +#### 29. Proof of lemma 4.7 + +As in the previous case, this lemma states two conclusions, so we will split it and modify this task accordingly. + +**Deliverable:** Proof of lemmas directly stating the results of lemma 4.7 + +#### 30. Proof of lemma 4.8 + +This lemma relies on lemmas 4.6, 4.7, and 4.3 for its proof, according to our plan of work those must be already done. This means that apart from technical lemmas, this proof should be short. + +**Deliverable:** Proof of lemma 4.8 + +#### 31. Proof of lemma 4.9 + +This is the last proof and most of the lemmas and theorems are already done, the proof on the paper is also short and relies on 4.7 and 4.3. For this, we expect little difficulty in accomplishing the proof. + +**Deliverable:** Proof of lemma 4.9 + +#### 32. Proof of intermediate lemmas + +We expect that some intermediate lemmas for this section or previous ones are already open, this task is to complete as many of them as possible. There must already exist a hierarchy of priorities for those lemmas. As a guide, we shouldn’t leave open the non-technical lemmas, but we may leave without proof of some technical lemmas. + +## Project Details of the Alternative Approach + +### **_The Model Checker TLC_** + +Apart from the theorem-proving aspect, we can try to support the formal verification of GRANDPA Finality Gadget using TLA+ and TLC model checker. TLA+, short for Temporal Logic of Actions, is a powerful tool for designing, modelling, documenting, and verifying software systems, particularly those featuring concurrency and distributed nature. Here's a quick overview: + +### What it is + +**A formal specification language:** It allows you to precisely define the desired behaviour of a system in mathematical terms. + +**Exhaustively-testable pseudocode:** Think of it as drawing detailed blueprints for software, enabling thorough testing before a single line of code is written. +Combines set theory and temporal logic: This unique combination lets you define both safety (preventing bad things) and liveness (ensuring good things happen eventually). + +### What it's used for + +**Designing reliable systems:** Minimize bugs and unexpected behaviour by catching errors early in the design phase. + +**Formal verification:** Use automated tools (model checkers) to prove that your system's specifications are indeed met by its implementation. + +**Clear documentation:** TLA+ specifications serve as precise and unambiguous references for developers and stakeholders. + +**Property driven development (PDD):** The idea of PDD is that you should decide precisely what a program should do before writing the code that describes how the program does it. These are the properties the program's output should satisfy. + +### Key features + +**Expressive:** Define complex system behaviour with ease. + +**Modular:** Break down specifications into manageable pieces. + +**Scalable:** Handle systems of varying sizes and complexity. + +### Limitations + +**Convergence:** If the state-space of the model is too large, then it can take a lot of time to get a proof or disproof for that model. + +A system specification consists of a lot of ordinary mathematics glued together with a tiny bit of temporal logic. Using TLA+ to implement the specification can be cumbersome. TLA+ toolbox accepts the language PlusCal, which is very intuitive for coders. TLA+ toolbox can compile the PlusCal code to TLA+ code on the fly. Thus making it easy to use TLC model checker to check the properties. There are two different types of properties that we can provide in PlusCal: +Precondition: This condition is used to restrict the possible inputs of the design under test (DUT), to check the DUT only for valid inputs. This is also known as assumptions. + +**Postcondition:** This condition is used to check the correctness of the DUT. This is where we express the behaviours (lemmas, theorems) that should be satisfied by the DUT. + +When the properties fail, the model checker generates a counter-example. This counter-example helps to debug the specification and understand the reason for the failure. + +### Formal Verification Plan using Model Checker TLC + +Formal verification has two stages, in the first stage, we try to encode the specification in a modelling language. Then in the second stage we write properties that should be valid according to the specification. + +#### Modelling in TLA+/PlusCal + +This is the first step to apply model checking i.e., creating the model from the specification. In the following steps we will run the model checker (TLC in this case) on this model. TLA+/PlusCal is very algorithmic in nature, so we use the following specification of the finality to get the pseudocode of the algorithms. This works as a blueprint. For example, I list the algorithms and the expected time required to code them in TLA+/PlusCal. + +Initiate GRANDPA: + +![Initiate GRANDPA](https://lh3.googleusercontent.com/d/16Cs-jaz2wxpCg5dTkaatQSkGw-QivZSO=w1247-h1097-iv1 "Initiate GRANDPA") + +This represents the initial state of the finality protocol. Note that this algorithm calls the function Play-GRANDPA-round. Which is our next algorithm as shown below. + +Play GRANDPA-round: + +![Play GRANDPA-round](https://lh3.googleusercontent.com/d/15eJeB-0woALj_63vmQ108CYxpJDBsJYu=w1247-h1097-iv1 "Play GRANDPA-round") + +This is the main algorithm to encode in the PlusCal. + +Derive-Primary: + +![Derive-Primary](https://lh3.googleusercontent.com/d/1qqG3QSbKfrBppGYi1zBsPSnqm98uou-B=w1802-h1097-iv1 "Derive-Primary") + +This is the algorithm that chooses the primary voter in each round. + +Best Final Candidate: + +![Best Final Candidate](https://lh3.googleusercontent.com/d/1YElV6MyGJN0GJEcSopZu1l7tQr6g9iJL=w1247-h1097-iv1 "Best Final Candidate") + +This algorithm finds the best final candidate. + +GRANDPA-Ghost: + +![GRANDPA-Ghost](https://lh3.googleusercontent.com/d/1CH5_UyicbG8XSfq0FA6zs3nhRHflH8jf=w1247-h1097-iv1 "GRANDPA-Ghost") + +This algorithm implements the GRANDPA-Ghost algorithm. + +Best pre-Vote Candidate: + +![Best pre-Vote Candidate](https://lh3.googleusercontent.com/d/1KLWaEt5TLDNTw_YTt9cR971GP0slPIos=w1247-h1097-iv1 "Best pre-Vote Candidate") + +Algorithm to choose the best pre-vote candidate. + +Attempt to Finalize at Round: + +![Attempt to Finalize at Round](https://lh3.googleusercontent.com/d/10ZMhnjhviyl3Dd3uerTGLxn82fdpFWTv=w1247-h1097-iv1 "Attempt to Finalize at Round") + +This algorithm attempts to finalize a round. + +Finalizable: + +![Finalizable](https://lh3.googleusercontent.com/d/1n5eE50sFufTobwk3dsU9aVxlYYYHY4mU=w1247-h1097-iv1 "Finalizable") + +The final algorithm that finalizes? This should check the conditions of completability. + +Process-Catchup Request: + +![Process-Catchup Request](https://lh3.googleusercontent.com/d/1CnQuCsPJTZ3ZiODySANeaWBChcJea9Of=w1247-h1097-iv1 "Process-Catchup Request") + +Process catchup request algorithm to be encoded in TLA+/PlusCal. + +Process-Catchup Response: + +![Process-Catchup Response](https://lh3.googleusercontent.com/d/18i_lFPXmWBiQn2heGPGUh8VB82lJ7Zhe=w1247-h1097-iv1 "Process-Catchup Response") + +Similarly, the Process-Catchup-Response should be encoded in TLA+/PlusCal. + +#### Property Verification + +To formally verify the specification, we need to properly encode the properties that we want to check on these models. These properties can be of different types. Based on the properties, the model checker may or may not converge. When a property fails, there are four possible reasons, + +1. There is an error in the specification, +2. The properties we wrote are not correct +3. We are allowing some behavior that is not allowed as per the specification +4. We are not modelling it properly. + +That is why when we face a failure we must debug very carefully to find what is going wrong. Normally, the time required to debug a property failure is the same or more than the time required to code the model. + +Note that convergence issues can become very complicated quickly. Based on the parameters (variables) the state space of the specification can grow really quickly and soon it can go out of the scope of the model checker. Here we try different techniques to help the model checker. Some of the techniques are, + +1. Partitioning the model/ properties so that the individual parts can be formally verified easily +2. Reducing the state space by reducing the size of the parameters +3. Adding lemmas that help to cut down the state space + +### Ecosystem Fit + +Application in response to the RFP "Formal Guarantees for GRANDPA Finality Gadget" + +## Team :busts_in_silhouette: + +### Team members + +- Mario Altimari +- Luis Alberto Díaz +- Sparsa Roychowdhury + +### Contact + +- **Contact Name:** Mario Altimari +- **Contact Email:** +- **Website:** + +### 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 using many technologies. +- Luis TODO +- Sparsa TODO + +Mario Altimari applied for a Web3 Foundation grant before, but it is still in pending approval: TuxedoDapp by Mlabs + +### Team Code Repos + +- Mario Altimari [https://github.com/AltiMario](https://github.com/AltiMario) +- Luis TODO +- Sparsa TODO + +### Team LinkedIn Profiles (if available) + +- Mario Altimari +- Luis TODO +- Sparsa TODO + +## Development Status :open_book: + +We have had conversations with the W3F team, planning to start a collaboration in this area + +## Development Roadmap :nut_and_bolt: + +### Estimate for **_The proof approach_** + +|Description of the activity |Min effort expected |Max effort expected| +|----------------------------|--------------------|-------------------| +|List all the required structures to define the `g` function and to express the GRANDPA algorithm|4h|8h| +|Split the list of required structures in implementable ones and those with only interfaces|36h|58h| +|Write the interface of all the structures in the list|32h| | +|Write the statements of all the lemmas and the principal conclusions|8h| | +|Implementation of the `g` function using only the interfaces|8h| | +|Implementation of the GRANDPA protocol using only the interfaces|14h|22h| +|Proofs of section 2 lemmas|24h|40h| +|SUB TOTAL|126h|176h| +|Write the statements to be proved in COQ.|4h|8h| +|Proof of the lemma 4.2|8h|12h| +|Proof of Theorem 4.1|8h|20h| +|Proof of Corollary 4.3|4h|6h| +|Proof of intermediate lemmas.|24h|40h| +|SUB TOTAL|174h|214h| +|Write statements to be proved in COQ.|6h|8h| +|Proof of lemma 4.4.|12h|16h| +|Proof of lemma 4.5.|12h|16h| +|Proof of lemma 4.6.|18h|24h| +|Proof of lemma 4.7.|6h|10h| +|Proof of lemma 4.8.|6h|10h| +|Proof of lemma 4.9.|6h|10h| +|Proof of intermediate lemmas.|48h|68h| +|TOTAL|288h|376h| + +- **Total Estimated Duration:** 3 months +- **Full-Time Equivalent (FTE):** 1.5 FTE +- **Total Costs:** $33200 (USD) + +| Number | Deliverable | Specification | +| -----: | ----------- | ------------- | +| **0a.** | License | Apache 2.0 | +| **0b.** | Documentation | We will provide Proof of Lemmas, Theorem, Corollary as described in detail | +| **0c.** | Statements | We will provide statements proved using COQ as described in detail| + +### Estimate for the Alternative Approach **_The Model Checker TLC_** + +|Description of the algorithm|Encoding effort|Verification effort|Combined| +|----------------------------|---------------|-------------------|--------| +|Initiate GRANDPA|2h|2h|4h| +|Play GRANDPA-round|24h|24h|48h| +|Derive-Primary|1h|1h|2h| +|Best Final Candidate|4h|4h|8h| +|GRANDPA Ghost|4h|4h|8h| +|Best pre-Vote Candidate|2h|2h|4h| +|Attempt to Finalize at Round|4h|4h|8h| +|Finalizable|8h|8h|16h| +|Process Catchup Request|8h|8h|16h| +|Process Catchup Response|8h|8h|16h| +|TOTAL|||130h + +- **Total Estimated Duration:** 1 month +- **Full-Time Equivalent (FTE):** 1.5 FTE +- **Total Costs:** $13000 (USD) + +| Number | Deliverable | Specification | +| -----: | ----------- | ------------- | +| **0a.** | License | Apache 2.0 | +| **0b.** | Verification | We will provide encoding and property verification using TLA+ as described in detail| + +## Future Plans + +## 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 From 9c2e123c51f91d3602140a6ed4c2ad8da9c2eeba Mon Sep 17 00:00:00 2001 From: AltiMario Date: Tue, 9 Jan 2024 15:03:25 +0800 Subject: [PATCH 27/27] Revert "GRANDPA formal verification 1st draft" This reverts commit db384484f741977a27412a23644e6a5d4f309d58. --- applications/grandpa_formal_verification.md | 578 -------------------- 1 file changed, 578 deletions(-) delete mode 100644 applications/grandpa_formal_verification.md diff --git a/applications/grandpa_formal_verification.md b/applications/grandpa_formal_verification.md deleted file mode 100644 index 28eb758d9e4..00000000000 --- a/applications/grandpa_formal_verification.md +++ /dev/null @@ -1,578 +0,0 @@ -# GRANDPA formal verification - -- **Team Name:** MLabs -- **Payment Address:** FIAT -- **[Level](https://github.com/w3f/Grants-Program/tree/master#level_slider-levels):** 3 - -## Project Overview :page_facing_up: - -This application is in response to the RFP ["Formal Guarantees for GRANDPA Finality Gadget"](https://grants.web3.foundation/docs/RFPs/formal_guarantees_for_grandpa) - -### Overview - -MLabs has extensive experience in formal verification processes gained through many Cardano projects, where formal verification is (in many cases) a key requirement. Mlabs would like to share its knowledge and expertise with Polkadot in this peculiar area of software development. - -## Project Details - -### **_The proof approach_** - -When mathematicians write proofs with 'pen and paper', they need to review them by themselves multiple times before they share them with the mathematical community. Even then they need to pass the scrutiny of multiple pairs before the proofs can be accepted. Although this process exists and is followed rigorously, mistakes can happen, and invalid results can reach the public, in those cases, mathematicians usually offer new proofs of statements and in very rare cases they retract the results. - -Proof assistants are more rigorous than people in the sense that unless we explicitly request for exculpation of proof, the proof assistant would reject to accept a non-rigorous proof. - -On the other side, proof assistants have the weakness that the validity of the proof is tied to various assumptions: - -- The implementation of the 'minimal kernel' of the proof assistants is done right. -- The language of implementation and its compiler/interpreter are right. -- The previous tools used to create the compiler/interpreter do a correct translation of them. - -In that direction, we can go back in time across multiple languages and compilers/interpreters, but even summing that all of them are correctly implemented, we also need to ensure that: - -- The machine that is running is in good condition and results are reproducible -In this aspect, we can go as far as to ensure that the machine can’t be a victim of cosmic rays or other rare cases that can cause the hardware fault. - -It is for this reason that although the '4 colors theorem' has been proven with the help of COQ, there is a controversy in the mathematical/logic community about its validity as a formal proof. -With this in mind, we propose an approach to the proofs that we hope can minimize the risks of faults by the mix of both the human procedure and the machine verification. - -The method consists of writing down two kinds of proofs, one the traditional 'pen and paper' proof, and the other implemented in the proof assistant. The idea is to do first the `pen and paper` proof and then iterate over the proof attempts in the proof assistant to refine the 'pen and paper' proof until we can convince the proof assistant that our proof is right. This way, we would end with two proofs that are closely related and verified by both humans and computers. - -An example of the successful application of a similar approach can be found in the paper - -As a consequence of this method, we can end with a large portion of 'technical lemmas', those are statements that aren’t needed for us humans but that the proof assistant needs, or otherwise it would reject the proof. This is an inevitable result to the best of our knowledge, and the growth of those 'technical lemmas' can be exponential over time. - -For this reason, we present a plan of work in which we try to discover as many of the required '_technical lemmas_' as possible in the shortest amount of time possible. This way, after the discovery of the 'technical lemmas', we can review the plan and adjust it. A possible outcome of this is that we may discover that the approach of formal verification of the GRANDPA protocol can’t be made in a reasonable time or an established budget. The early discovery of 'technical lemmas' would allow us to stop the work before spending too many resources. - -We can split the plan into three main sections: - -- Preamble, which corresponds to sections 2 and 3 of the GRANDPA paper. -- Safety, corresponds to section 4.1. -- Liveness, corresponds to section 4.2. - - Every section can also be divided into: - -- Search for required abstractions -- Modification of proofs and discovery of 'technical lemmas' -- Writing of the statements in the proof assistant without proofs -- Proofs of the statements -However, the '_Search of required abstractions_' would happen mainly in the '_Preamble section_'. -A detailed list of the required steps for every section is presented below. - -### Preamble - -1. Sketch proofs of section 2 lemmas -2. Split of section 2 proofs in more elemental lemmas -3. Formal proofs of the lemmas and formal definition of the `g` function outside the proof assistant -4. Proofs refactorization in a way that can be followed in COQ code -5. List all the required structures to define the `g` function and to express the GRANDPA algorithm -6. Split the list of required structures in implementable ones and those with only interfaces -7. Write the interface of all the structures in the list -8. Write the statements of all the lemmas and the principal conclusions -9. Implementation of the `g` function using only the interfaces -10. Implementation of the GRANDPA protocol using only the interfaces -11. Proofs of section 2 lemmas - -### Safety - -12. Refactor of proof sketches in section 4.1 using the developed abstractions. -13. Split the proofs of section 4.1 in more elemental lemmas. -14. Formal proofs of section 4.1 lemmas. -15. Refine proofs to make them as close to COQ reasoning as possible. -16. Write the statements to be proved in COQ. -17. Proof of the lemma 4.2 -18. Proof of Theorem 4.1 -19. Proof of Corollary 4.3 -20. Proof of intermediate lemmas. - -### Liveness - -21. Refactor of proof sketches of section 4.2 -22. Split of proofs of section 4.2 in more elemental lemmas. -23. Formal proofs of section 4.2 lemmas. -24. Refine proofs to make them as close to COQ reasoning as possible. -25. Write statements to be proved in COQ. -26. Proof of lemma 4.4. -27. Proof of lemma 4.5. -28. Proof of lemma 4.6. -29. Proof of lemma 4.7. -30. Proof of lemma 4.8. -31. Proof of lemma 4.9. -32. Proof of intermediate lemmas. - -### Disclaimer on code extraction - -When we say code extraction, we don’t mean full implementation of the mentioned functions or data types. We refer to literal extraction of the functions/data types as is to `Haskell` code without extraction of the required definitions for the result to be a compilable program in `Haskell`. -This allows us to replace some types and functions used in `COQ` with those already existing in the `Haskell` ecosystem. -The complete extraction of the protocol including all the needed types would require a complete implementation of the protocol and is out of the scope of this proposal. - -### Detailed activities - -#### 1. Sketch proofs of section 2 lemmas - -The lemmas 2.5 and 2.6 were stated without proof after the introduction of the required definitions and an informal discussion. This task is about refactoring such statements in an ordered sequence, highlighting the steps required for the proof, and ensuring that those two lemmas are true. -The latter part of the task concerns the lemma 2.5, in our exploration of the GRANDPA paper we had limited time and were unable to conclude its truthfulness. -The deliverable of this task is the sketch of the proofs in a readable format, such as PDF, but other formats may be acceptable. - -#### 2. Split section 2 proofs in more elemental lemmas - -For this task, we would review the sketch of the proofs and identify sections of it that may be difficult for a proof assistant to accept without further work, then establish such facts as separate lemmas. -The deliverable for this is modifications to the document of task 1. - -#### 3. Formal proofs of the lemmas and formal definition of the 'g' function outside the proof assistant - -Until now, we have only sketches of proofs, that is, informal proof written in a mixture of formal statements and regular English prose without much care for the details. This task is to take those sketches and transform them into more formal statements, with close attention to the details of the proofs. -In this process, we may find new technical lemmas. -The deliverable for this is more editions of the task 1 document. - -#### 4. Proofs refactorization in a way that can be followed in COQ code - -The deliverable of the previous task would give us formal proofs in an amicable form for COQ. However, we expect that we may discover even more technical lemmas if we refactor the proofs to make them as close to COQ code as possible. -Although we expect to find more technical lemmas, we also hope to have a semi-stable structure of proofs. -The deliverable for this is more editions of the task 1 document. - -#### 5. List all the required structures to define the `g` function and to express the GRANDPA algorithm - -The last refactor should highlight the necessary structures to implement the g function and the GRANDPA algorithm, this task consists of grouping all of them with the properties of such structures used in the proofs. -The time of this task is bound by the amount of structures and properties that are needed. - -#### 6. Split the list of required structures into implementable ones and those with only interfaces - -This is a critical task for the project. -In principle, all the structures used can be left as interfaces and all its properties may be assumed. Doing this will help with very complex structures but abusing it would introduce doubts on the resulting proof. - -The objective of this task is to equilibrate the pros and cons of leaving every structure as a simple interface or implementation of it. We also want to consider the replacement of some structures used in the paper with others more adequate for the proof assistant. - -A primer example is Sets and Blockchains. - -- Sets are known to be hard to reason using a proof assistant, and we may need to replace it with a more friendly structure. -- Blocks of chains can be implemented and this may help to generate very natural induction principles that would help in proofs. - -When we refer to 'implement' we don’t mean a full implementation that can be extracted but a minimal implementation that captures the properties we are looking for in the proof. - -For example, in the case of a Blockchain, we won’t implement the needed hash functions, but instead, we would implement it in a way that the concept of 'a' block B that is not the original block has a previous block B 'associated'. - -Of huge concern are the structures that would express the time relation, for now, we model them as regular functions that depend on the time, but we may need better models for inclusion of reasoning of the algorithm of GRANDPA. - -We also include the research for suitable libraries that implement the structures that require implementation in this task. - -The deliverable is the inclusion of all the results and considerations in the document of task 1. - -#### 7. Write the interface of all the structures in the list - -Although some structures may need an implementation, we begin by expressing all the structure's interfaces. - -This task also includes the setting of a reproducible environment for programming in COQ. - -Deliverable: Establishment of a repository with COQ code with all the necessary interfaces. - -#### 8. Write the statements of all the lemmas and the principal conclusions - -Translate the lemmas that we want to prove in COQ and modify the interface of structures as needed. - -**Deliverable:** Changes in the COQ code. - -#### 9. Implementation of the 'g' function using only the interfaces - -This requires some exploration, the implementation can be made in various ways and some of them would be better suited for proofs. -**Optional:** write a version using only system F features, allowing code extraction (need more time). - -All the considered alternatives of the '_g_' function should be preserved. -Sometimes when we want to prove something about a thing '_c_' we can find an equivalent representation of '_c_' as another thing '_a_' for which this task can be trivial. Once we have such an '_a_', we can proceed to establish how '_c_' and '_a_' are the '_same_' in some sense, and exploit the fact that we have our proof for '_a_' to get our proof for '_c_'. - -**Deliverable:** Addition of various versions of '_g_' to the code. - -#### 10. Implementation of the protocol using only the interfaces - -As in the last task, we need to explore different ways of implementing the algorithm, maybe with various versions of '_g_'. The explanation for this is the same as in task 9. - -**Deliverable:** Addition of various versions of the GRANDPA algorithm to the code. - -**Optional:** write a version using only system F features, allowing code extraction (need more time) - -#### 11. Proofs of section 2 lemmas - -For this, we can think of this task as successful if we can do it in a short time. -If we haven’t stopped at this point, it means that we see the proof of these two lemmas as something possible. -This task also includes the completion of all the technical lemmas involved so that we can claim that we have complete proof. -Deliverable: First proofs in code. -Optional: Code extraction to Haskell. - -#### 12. Refactor of proof sketches in section 4.1 using the developed abstractions - -Utilize the abstractions developed until now to express the lemmas of section 4.1 and its proofs sketch, this includes a change in the order of introduction of 4.2 and 4.1. - -**Deliverable:** Audition of the proof sketches to document task 1. - -#### 13. Split the proofs of section 4.1 in more elemental lemmas - -This is part of our effort to discover technical lemmas. -Thanks to the previous effort, some lemmas should be already proven, reducing the future amount of work. - -**Deliverable:** Addition of the refactors to document of task 1. - -#### 14. Formal proofs of section 4.1 lemmas - -We take the sketches of the previous task and use them to establish formal proofs. -We should use as much as we can of the already defined abstractions, their properties, and the existing technical lemmas. -We expect to find new technical lemmas, but not so much of them. - -**Deliverable:** Addition of the new proofs and lemmas to document task 1. - -#### 15. Refine proofs to make them as close to COQ reasoning as possible - -The previous proofs for section 4.1 should put us in the right direction, but we may have some concessions for humans before. This task must clean up all the results and format them in a way that the proof can be followed in COQ. - -**Deliverable:** Addition of the new proofs to document of task 1. - -#### 16. Write the statements to be proved in COQ - -Utilizing the previously developed structures, formalize the statements to be proved in COQ. -We may need to still do a few corrections, but those must be minimal. -Deliverable: Changes in the COQ code, including the new statements - -#### 17. Proof of the lemma 4.2 - -The lemma 4.2 is used in the proof of theorem 4.1, we need to state it before lemma 4.1 -While developing this poof, new auxiliary lemmas can be created and may be left as pending proofs. - - **Deliverable:** Proof of lemma 4.2 with maybe some assumptions to be proved. - -#### 18. Proof of Theorem 4.1 - -This is the main theorem establishing the safety of the protocol, it introduces an algorithm to find a set of Byzantine voters in case of failure. We may change on opinion later, but for now, we propose to implement the described algorithm separately and establish properties about it before we proceed to the proof. -Some assumptions may be left open while working on the proof. - -**Deliverable:** Proof of theorem 4.1 and establishment of the algorithm to find Byzantine voters in case of failure. - -#### 19. Proof of Corollary 4.3 - -This is an immediate consequence of theorem 4.1 in the proof assistant, but the translation to the assistant may make this a not immediate fact. - -**Deliverable:** Proof of corollary 4.3 - -#### 20. Proof of intermediate lemmas - -Over the way to proof 4.1, 4.2, and 4.3, we may leave some assumptions (lemmas), this is the task responsible to complete the more critical of them. -Critical here means, non-technical lemmas. -If the amount of non-technical lemmas is low, we can spend the rest of the time with the technical lemmas. - -**Deliverable:** A complete formal verification of the liveness of the algorithm. - -#### 21. Refactor of proof sketches of section 4.2 - -As with the other two sections, this task consists of modifying the proof sketches provided in the paper and modify them. Among other things, the result sketches must include the mention of all the steps necessary to prove the corresponding result. So, if a sketch includes a sentence like “An easy induction completes the proof of the proposition” we should replace it specifying in prose what the inductive hypothesis should be and sketches for the 0 and inductive step. -Even with this requirement, the proofs are expected to be sketches and not formal proofs. - -**Deliverable:** Addition of the liveness sketches to document of task 1. - -#### 22. Split of proofs of section 4.2 in more elemental lemmas - -In the previous proofs, the paper omitted the network involved as much as it could, and this approach worked fine. -However, in liveness, we need to explicitly work with the model of time. -These two facts mean that we may find many intermediate lemmas in this section, as we haven’t needed lemmas involving explicit times. This alone augments the expected required time for the task related to liveness compared with the times established for safety. - -**Deliverable:** Addition of new lemmas to document of task 1. - -#### 23. Formal proofs of section 4.2 lemmas - -This task is for the exchange of the previous proof sketches for new proofs that are completely formal. As mentioned in the previous task, we now depend heavily on time, this may mark an increase in the number of technical lemmas discovered in this task. - -**Deliverable:** Addition of technical lemmas and formal proofs for section 4.2 in the document of task 1. - -#### 24. Refine proofs to make them as close to COQ reasoning as possible - -We should make changes as needed in the proofs to make them friendly to COQ. As in the previous task, we expect the discovery of many technical lemmas. - -**Deliverable:** Addition of the new proofs to the document of task 1. - -#### 25. Write statements to be proved in COQ - -We may find that we need to some adjustments to express the statements to prove, which can increase by a little amount the required time for the translation. - -**Deliverable:** Addition of the statements to be proved in COQ. - -#### 26. Proof of lemma 4.4 - -Although we have used lemmas 2.5 and 2.6 in the previous section, the use was implicit, now the sketch of the proof of lemma 4.4 directly involves the use of both lemmas. This means that 4.4 is particularly dependent on them. - -**Deliverable:** Inclusion of the proof for lemma 4.4 in COQ. - -#### 27. Proof of lemma 4.5 - -This lemma leaves open the end of the proof with the sentence “An easy induction completes the proof of the proposition.”. There's a high probability that the previous steps split this proof, this task only involves the proof of the main statement of the lemma and leaves open the chance that the intermediate results may be proved later. - -**Deliverable:** Inclusion of proof of lemma 4.5 in COQ. - -#### 28. Proof of lemma 4.6 - -This lemma introduces 4 conclusions, although COQ can express this, it is better to write a separate lemma for every conclusion. We expect to do the split in the previous stages for liveness. This means that this particular task may be split in the future. - -**Deliverable:** Proofs of lemmas directly stating the results of lemma 4.6 - -#### 29. Proof of lemma 4.7 - -As in the previous case, this lemma states two conclusions, so we will split it and modify this task accordingly. - -**Deliverable:** Proof of lemmas directly stating the results of lemma 4.7 - -#### 30. Proof of lemma 4.8 - -This lemma relies on lemmas 4.6, 4.7, and 4.3 for its proof, according to our plan of work those must be already done. This means that apart from technical lemmas, this proof should be short. - -**Deliverable:** Proof of lemma 4.8 - -#### 31. Proof of lemma 4.9 - -This is the last proof and most of the lemmas and theorems are already done, the proof on the paper is also short and relies on 4.7 and 4.3. For this, we expect little difficulty in accomplishing the proof. - -**Deliverable:** Proof of lemma 4.9 - -#### 32. Proof of intermediate lemmas - -We expect that some intermediate lemmas for this section or previous ones are already open, this task is to complete as many of them as possible. There must already exist a hierarchy of priorities for those lemmas. As a guide, we shouldn’t leave open the non-technical lemmas, but we may leave without proof of some technical lemmas. - -## Project Details of the Alternative Approach - -### **_The Model Checker TLC_** - -Apart from the theorem-proving aspect, we can try to support the formal verification of GRANDPA Finality Gadget using TLA+ and TLC model checker. TLA+, short for Temporal Logic of Actions, is a powerful tool for designing, modelling, documenting, and verifying software systems, particularly those featuring concurrency and distributed nature. Here's a quick overview: - -### What it is - -**A formal specification language:** It allows you to precisely define the desired behaviour of a system in mathematical terms. - -**Exhaustively-testable pseudocode:** Think of it as drawing detailed blueprints for software, enabling thorough testing before a single line of code is written. -Combines set theory and temporal logic: This unique combination lets you define both safety (preventing bad things) and liveness (ensuring good things happen eventually). - -### What it's used for - -**Designing reliable systems:** Minimize bugs and unexpected behaviour by catching errors early in the design phase. - -**Formal verification:** Use automated tools (model checkers) to prove that your system's specifications are indeed met by its implementation. - -**Clear documentation:** TLA+ specifications serve as precise and unambiguous references for developers and stakeholders. - -**Property driven development (PDD):** The idea of PDD is that you should decide precisely what a program should do before writing the code that describes how the program does it. These are the properties the program's output should satisfy. - -### Key features - -**Expressive:** Define complex system behaviour with ease. - -**Modular:** Break down specifications into manageable pieces. - -**Scalable:** Handle systems of varying sizes and complexity. - -### Limitations - -**Convergence:** If the state-space of the model is too large, then it can take a lot of time to get a proof or disproof for that model. - -A system specification consists of a lot of ordinary mathematics glued together with a tiny bit of temporal logic. Using TLA+ to implement the specification can be cumbersome. TLA+ toolbox accepts the language PlusCal, which is very intuitive for coders. TLA+ toolbox can compile the PlusCal code to TLA+ code on the fly. Thus making it easy to use TLC model checker to check the properties. There are two different types of properties that we can provide in PlusCal: -Precondition: This condition is used to restrict the possible inputs of the design under test (DUT), to check the DUT only for valid inputs. This is also known as assumptions. - -**Postcondition:** This condition is used to check the correctness of the DUT. This is where we express the behaviours (lemmas, theorems) that should be satisfied by the DUT. - -When the properties fail, the model checker generates a counter-example. This counter-example helps to debug the specification and understand the reason for the failure. - -### Formal Verification Plan using Model Checker TLC - -Formal verification has two stages, in the first stage, we try to encode the specification in a modelling language. Then in the second stage we write properties that should be valid according to the specification. - -#### Modelling in TLA+/PlusCal - -This is the first step to apply model checking i.e., creating the model from the specification. In the following steps we will run the model checker (TLC in this case) on this model. TLA+/PlusCal is very algorithmic in nature, so we use the following specification of the finality to get the pseudocode of the algorithms. This works as a blueprint. For example, I list the algorithms and the expected time required to code them in TLA+/PlusCal. - -Initiate GRANDPA: - -![Initiate GRANDPA](https://lh3.googleusercontent.com/d/16Cs-jaz2wxpCg5dTkaatQSkGw-QivZSO=w1247-h1097-iv1 "Initiate GRANDPA") - -This represents the initial state of the finality protocol. Note that this algorithm calls the function Play-GRANDPA-round. Which is our next algorithm as shown below. - -Play GRANDPA-round: - -![Play GRANDPA-round](https://lh3.googleusercontent.com/d/15eJeB-0woALj_63vmQ108CYxpJDBsJYu=w1247-h1097-iv1 "Play GRANDPA-round") - -This is the main algorithm to encode in the PlusCal. - -Derive-Primary: - -![Derive-Primary](https://lh3.googleusercontent.com/d/1qqG3QSbKfrBppGYi1zBsPSnqm98uou-B=w1802-h1097-iv1 "Derive-Primary") - -This is the algorithm that chooses the primary voter in each round. - -Best Final Candidate: - -![Best Final Candidate](https://lh3.googleusercontent.com/d/1YElV6MyGJN0GJEcSopZu1l7tQr6g9iJL=w1247-h1097-iv1 "Best Final Candidate") - -This algorithm finds the best final candidate. - -GRANDPA-Ghost: - -![GRANDPA-Ghost](https://lh3.googleusercontent.com/d/1CH5_UyicbG8XSfq0FA6zs3nhRHflH8jf=w1247-h1097-iv1 "GRANDPA-Ghost") - -This algorithm implements the GRANDPA-Ghost algorithm. - -Best pre-Vote Candidate: - -![Best pre-Vote Candidate](https://lh3.googleusercontent.com/d/1KLWaEt5TLDNTw_YTt9cR971GP0slPIos=w1247-h1097-iv1 "Best pre-Vote Candidate") - -Algorithm to choose the best pre-vote candidate. - -Attempt to Finalize at Round: - -![Attempt to Finalize at Round](https://lh3.googleusercontent.com/d/10ZMhnjhviyl3Dd3uerTGLxn82fdpFWTv=w1247-h1097-iv1 "Attempt to Finalize at Round") - -This algorithm attempts to finalize a round. - -Finalizable: - -![Finalizable](https://lh3.googleusercontent.com/d/1n5eE50sFufTobwk3dsU9aVxlYYYHY4mU=w1247-h1097-iv1 "Finalizable") - -The final algorithm that finalizes? This should check the conditions of completability. - -Process-Catchup Request: - -![Process-Catchup Request](https://lh3.googleusercontent.com/d/1CnQuCsPJTZ3ZiODySANeaWBChcJea9Of=w1247-h1097-iv1 "Process-Catchup Request") - -Process catchup request algorithm to be encoded in TLA+/PlusCal. - -Process-Catchup Response: - -![Process-Catchup Response](https://lh3.googleusercontent.com/d/18i_lFPXmWBiQn2heGPGUh8VB82lJ7Zhe=w1247-h1097-iv1 "Process-Catchup Response") - -Similarly, the Process-Catchup-Response should be encoded in TLA+/PlusCal. - -#### Property Verification - -To formally verify the specification, we need to properly encode the properties that we want to check on these models. These properties can be of different types. Based on the properties, the model checker may or may not converge. When a property fails, there are four possible reasons, - -1. There is an error in the specification, -2. The properties we wrote are not correct -3. We are allowing some behavior that is not allowed as per the specification -4. We are not modelling it properly. - -That is why when we face a failure we must debug very carefully to find what is going wrong. Normally, the time required to debug a property failure is the same or more than the time required to code the model. - -Note that convergence issues can become very complicated quickly. Based on the parameters (variables) the state space of the specification can grow really quickly and soon it can go out of the scope of the model checker. Here we try different techniques to help the model checker. Some of the techniques are, - -1. Partitioning the model/ properties so that the individual parts can be formally verified easily -2. Reducing the state space by reducing the size of the parameters -3. Adding lemmas that help to cut down the state space - -### Ecosystem Fit - -Application in response to the RFP "Formal Guarantees for GRANDPA Finality Gadget" - -## Team :busts_in_silhouette: - -### Team members - -- Mario Altimari -- Luis Alberto Díaz -- Sparsa Roychowdhury - -### Contact - -- **Contact Name:** Mario Altimari -- **Contact Email:** -- **Website:** - -### 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 using many technologies. -- Luis TODO -- Sparsa TODO - -Mario Altimari applied for a Web3 Foundation grant before, but it is still in pending approval: TuxedoDapp by Mlabs - -### Team Code Repos - -- Mario Altimari [https://github.com/AltiMario](https://github.com/AltiMario) -- Luis TODO -- Sparsa TODO - -### Team LinkedIn Profiles (if available) - -- Mario Altimari -- Luis TODO -- Sparsa TODO - -## Development Status :open_book: - -We have had conversations with the W3F team, planning to start a collaboration in this area - -## Development Roadmap :nut_and_bolt: - -### Estimate for **_The proof approach_** - -|Description of the activity |Min effort expected |Max effort expected| -|----------------------------|--------------------|-------------------| -|List all the required structures to define the `g` function and to express the GRANDPA algorithm|4h|8h| -|Split the list of required structures in implementable ones and those with only interfaces|36h|58h| -|Write the interface of all the structures in the list|32h| | -|Write the statements of all the lemmas and the principal conclusions|8h| | -|Implementation of the `g` function using only the interfaces|8h| | -|Implementation of the GRANDPA protocol using only the interfaces|14h|22h| -|Proofs of section 2 lemmas|24h|40h| -|SUB TOTAL|126h|176h| -|Write the statements to be proved in COQ.|4h|8h| -|Proof of the lemma 4.2|8h|12h| -|Proof of Theorem 4.1|8h|20h| -|Proof of Corollary 4.3|4h|6h| -|Proof of intermediate lemmas.|24h|40h| -|SUB TOTAL|174h|214h| -|Write statements to be proved in COQ.|6h|8h| -|Proof of lemma 4.4.|12h|16h| -|Proof of lemma 4.5.|12h|16h| -|Proof of lemma 4.6.|18h|24h| -|Proof of lemma 4.7.|6h|10h| -|Proof of lemma 4.8.|6h|10h| -|Proof of lemma 4.9.|6h|10h| -|Proof of intermediate lemmas.|48h|68h| -|TOTAL|288h|376h| - -- **Total Estimated Duration:** 3 months -- **Full-Time Equivalent (FTE):** 1.5 FTE -- **Total Costs:** $33200 (USD) - -| Number | Deliverable | Specification | -| -----: | ----------- | ------------- | -| **0a.** | License | Apache 2.0 | -| **0b.** | Documentation | We will provide Proof of Lemmas, Theorem, Corollary as described in detail | -| **0c.** | Statements | We will provide statements proved using COQ as described in detail| - -### Estimate for the Alternative Approach **_The Model Checker TLC_** - -|Description of the algorithm|Encoding effort|Verification effort|Combined| -|----------------------------|---------------|-------------------|--------| -|Initiate GRANDPA|2h|2h|4h| -|Play GRANDPA-round|24h|24h|48h| -|Derive-Primary|1h|1h|2h| -|Best Final Candidate|4h|4h|8h| -|GRANDPA Ghost|4h|4h|8h| -|Best pre-Vote Candidate|2h|2h|4h| -|Attempt to Finalize at Round|4h|4h|8h| -|Finalizable|8h|8h|16h| -|Process Catchup Request|8h|8h|16h| -|Process Catchup Response|8h|8h|16h| -|TOTAL|||130h - -- **Total Estimated Duration:** 1 month -- **Full-Time Equivalent (FTE):** 1.5 FTE -- **Total Costs:** $13000 (USD) - -| Number | Deliverable | Specification | -| -----: | ----------- | ------------- | -| **0a.** | License | Apache 2.0 | -| **0b.** | Verification | We will provide encoding and property verification using TLA+ as described in detail| - -## Future Plans - -## 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