forked from DECA/DAOTask
Compare commits
6 Commits
Author | SHA1 | Date |
---|---|---|
itzelot01 | 4c8d1ea51d | |
itzelot01 | eff4d47aa7 | |
itzelot01 | 74e14dabd6 | |
itzelot01 | ed4ed8c95e | |
itzelot01 | fa524bef13 | |
itzelot01 | 323edcae68 |
|
@ -0,0 +1,84 @@
|
|||
# DECA Architecture
|
||||
## Abstract
|
||||
The project development will be done modularly and will be splitted into
|
||||
multiple subprojects which require the proper research and development.The
|
||||
Goal is to develop all the architecture require for the [DECA Protocol](https://docs.google.com/presentation/d/1H4V5X0X-9jnulwmmQBKk7PiStqKoPh_t_h7F0R3kLw0/edit#slide=id.p)
|
||||
|
||||
## Project Overview
|
||||
|
||||
### General Diagrams
|
||||
|
||||
|
||||
### Development
|
||||
|
||||
- [ ] Module 0: Modify tunk to be IPFS compatible (Possibly use CAR)
|
||||
- [ ] Module 1: YEW DAPP that connects to HELIA (Typescript)
|
||||
- [ ] Module 2: YEW DAPP that connects to the DECA Contract using Ethers-web3
|
||||
- [ ] Module 3: YEW DAPP that includes and updated version of OrbitDB and extracts data from Ethers-Web3(Depends on 1,2)
|
||||
- [ ] Module 4: Fleek YEW integration with Docker (for the IPNS/DNS and CI/CD).
|
||||
- [ ] Module 7: ERC1155 Development and testing (cctokens, DECA2, SBt)
|
||||
- [ ] Module 8: DAO (Vaults, ranking/quadratic voting, whitelist, etc)
|
||||
- [ ] Module 9: Liquidity Pools DeFi
|
||||
- [ ] Module 10: Lending DeFi
|
||||
- [ ] Module 11: Integration(requires from 1-8)
|
||||
|
||||
### Research
|
||||
|
||||
- [ ] Module 5: Architecture specifications for DECA Protocol (R&D, Class Diagrams).
|
||||
- [ ] Module 6: Tokenomics Ultrasound Model (Research and Dev)
|
||||
|
||||
### Security Testing
|
||||
|
||||
- [ ] Module 11: Security Audit
|
||||
|
||||
### Future R&D
|
||||
- [ ] Use Cases.
|
||||
- [ ] Payto DAO (SmartWallet)
|
||||
- [ ] Zero Knowledge Proof Carbon Offset (Privacy and Fungibility).
|
||||
|
||||
|
||||
## Module Description
|
||||
|
||||
### Module 0
|
||||
|
||||
This module is to ensure that the trunk build website (yew mostly)
|
||||
builds a decentralizable website and assets. Consider using CAR
|
||||
management for the assets.
|
||||
|
||||
[Module 0 Specification](./module0.md)
|
||||
|
||||
### Module 1
|
||||
|
||||
This module will ensure that the website and its assets runs in a HELIA instance.
|
||||
This will add seeds and thus network speed to the content distribution. All the
|
||||
assets should be integrated in the project so that it does not depend on centralized
|
||||
systems. This module is important to ensure frontend decentralization.
|
||||
|
||||
[Module 1 Specification](./module1.md)
|
||||
|
||||
### Module 2
|
||||
|
||||
This module will include its own ethers wasm implementation, so that it connects
|
||||
to the Ethereum blockchain and perform some testing operations. The Goal is to
|
||||
ensure the ethers connector can be decentralized and included in the project code.
|
||||
This module is important to ensure comunication with the smart contracts in a
|
||||
decentralized way.
|
||||
|
||||
[Module 2 Specification](./module2.md)
|
||||
|
||||
### Module 7
|
||||
|
||||
![dig1](./assets/diagram1.svg)
|
||||
> dig1. Shows the front end DAPP architecture for SBT
|
||||
|
||||
### Module N
|
||||
|
||||
|
||||
|
||||
> Important Note: all modules should be tested in a decentralized environment
|
||||
|
||||
|
||||
## References
|
||||
[^1]: https://github.com/web3-storage/ipfs-car
|
||||
[^2]: https://ipld.io/specs/transport/car/
|
||||
|
File diff suppressed because one or more lines are too long
After Width: | Height: | Size: 15 KiB |
|
@ -0,0 +1,22 @@
|
|||
@startuml
|
||||
package "YEW DAPP" {
|
||||
[Fetch NFTs URIS] -d-> [Display NFTs]
|
||||
[Ethers-web] -u-> [Fetch NFTs URIS]
|
||||
[Fetch Assets from EthersURI] -d-> [Display NFTs]
|
||||
[Pin All IPFS Assets] -u-> [Fetch Assets from EthersURI]
|
||||
[Pin All IPFS Assets] <-d- [Helia]
|
||||
}
|
||||
|
||||
cloud "Ethereum" {
|
||||
[ERC721]
|
||||
}
|
||||
|
||||
cloud "IPFS"{
|
||||
[NFTs Image Assets]
|
||||
[URI Properties Assets]
|
||||
[YEW Assets]
|
||||
}
|
||||
|
||||
[Helia] <-d- [IPFS]
|
||||
[Ethers-web] -d-> [Ethereum]
|
||||
@enduml
|
|
@ -0,0 +1,31 @@
|
|||
# Module 0 Specification
|
||||
|
||||
## Goal
|
||||
|
||||
This module is to ensure that the trunk build website (yew mostly)
|
||||
builds a decentralizable website and assets. Consider using CAR
|
||||
management for the assets.
|
||||
|
||||
|
||||
## ToDo
|
||||
- [ ] Research CAR
|
||||
- [ ] Detect and Report issue (Update this specification)
|
||||
- [ ] Research and test possible solutions.
|
||||
- [ ] Implement solution to achieve the goal.
|
||||
|
||||
## Report
|
||||
|
||||
### CAR Specification
|
||||
* [CAR library](https://github.com/web3-storage/ipfs-car)[^1]
|
||||
* [CAR Reference](https://ipld.io/specs/transport/car/)[^2]
|
||||
|
||||
### Trunk found issues
|
||||
|
||||
### Possible solutions
|
||||
|
||||
## Notes and further developments.
|
||||
|
||||
## References
|
||||
|
||||
[^1]: https://github.com/web3-storage/ipfs-car
|
||||
[^2]: https://ipld.io/specs/transport/car/
|
|
@ -0,0 +1,93 @@
|
|||
# Module 1 Specification
|
||||
|
||||
## Goal
|
||||
|
||||
This module will ensure that the website and its assets runs in a HELIA instance.
|
||||
This will add seeds and thus network speed to the content distribution. All the
|
||||
assets should be integrated in the project so that it does not depend on centralized
|
||||
systems. This module is important to ensure frontend decentralization.
|
||||
|
||||
|
||||
## Dependencies
|
||||
- [ ] Module 0
|
||||
|
||||
## ToDo
|
||||
|
||||
- [ ] Research HELIA.
|
||||
- [ ] How to solve the website hashing paradigm.
|
||||
- [ ] Detect and Report issue (Update this specification).
|
||||
- [ ] Research and test possible solutions.
|
||||
- [ ] Implement solution to achieve the goal.
|
||||
|
||||
## Report
|
||||
|
||||
* Upon doing research on helia, we found that some of the methods on implementing JavaScript on Rust with callback and using yew have problems with the
|
||||
imports of Helia.
|
||||
The following are issues found with the different methods:
|
||||
1. With web-pack: While trying to import Helia's libraries on a previosly working app using callback to implement JavaScript on a yew template, we
|
||||
stumbled upon an error in which we couldn't install the Helia library due to there being too many packages.
|
||||
Possible solutions implemented:
|
||||
- Importing Helia from the import link instead of installing the library, though one of the problems with this solution is that you can't do imports
|
||||
and at the same time export a function with the JS callback on Rust. It was necessary to first import the Helia library and then use it for the export function.
|
||||
- Adding the import links to the index.html like script modules.
|
||||
|
||||
2. After not finding a concrete solution that would help us with the import, I decided to follow the yew tutorial drive through libraries that was very well
|
||||
documented but a little outdated since it was using yew version 12. Now the problem was the it had two errors that wouldn't let me run the app.
|
||||
Specific errors found:
|
||||
* error [E0433]: failed to resolve: unresolved import (a function from the wasm-bindgen.rs that comes from the version of wasm-bindgen that you installed).
|
||||
* error [E0425]: cannot find the function 'wasm_bindgen_initialized' in this scope (also coming from wasm-bindgen.rs).
|
||||
|
||||
|
||||
Possible solutions implemented:
|
||||
|
||||
- Updating to the newest version of wasm_bindgen.
|
||||
- Trying to change the imports of wasm_bindgen.
|
||||
- Adding the dependency to de Cargo.toml file.
|
||||
> None of these solutions worked
|
||||
|
||||
3. Currently using the yew-interop to asynchronously Load CSS or Javascript libraries which allows you to import libraries from links and also implements
|
||||
JavaScript scripts to Rust.
|
||||
Using the example provided in the examples GitHub repository to know how to have the correct structure and succesfully import everything necessary for the app.
|
||||
|
||||
### HELIA Specification
|
||||
* [Helia library](https://github.com/ipfs/helia)[^1]
|
||||
* [Helia Examples](https://github.com/ipfs-examples/helia-examples/tree/main/examples/helia-webpack)[^2]
|
||||
* [Helia Example by Phind](https://www.phind.com/search?cache=v6nzolbm7xl10xvhgfih6bvz)[^3]
|
||||
|
||||
### Hashing paradigm
|
||||
|
||||
To have a self decentralized website we need to add a hash to the code this hash
|
||||
known as CID is generated based on all the assets hashed data, so it makes a
|
||||
paradigm problem to add the hash if its not know previously in the code, because
|
||||
if we add it to the code of the site, the project hash will change.
|
||||
|
||||
### Possible solutions
|
||||
|
||||
1. Using SmartContract: Use a smart contract with an IPNS and a ENS
|
||||
(Ethereum Name Service NFT) which points to an IPNS that will be updated by the
|
||||
project developer. This gives us the flexibility to update, and security that
|
||||
the blockchain offers. This can also be an alternative to avoid MITM and other
|
||||
security issues.
|
||||
|
||||
* Pros: ToDo
|
||||
|
||||
* Cons: ToDo
|
||||
2.
|
||||
|
||||
## Notes and further developments.
|
||||
|
||||
1. Make the ENS Updateable by a DAO and a smart wallet.
|
||||
|
||||
## References
|
||||
|
||||
[^1]: https://github.com/ipfs/helia
|
||||
[^2]: https://github.com/ipfs-examples/helia-examples/tree/main/examples/helia-webpack
|
||||
[^3]: https://dev.to/davidedelpapa/yew-tutorial-05-drive-through-libraries-2gj5
|
||||
[^4]: https://github.com/Madoshakalaka/yew-interop
|
||||
[^5]: https://github.com/Madoshakalaka/yew-interop/tree/master/example
|
||||
[^6]: https://rustwasm.github.io/wasm-bindgen/examples/import-js.html
|
||||
|
||||
|
||||
|
||||
|
||||
|
|
@ -0,0 +1,38 @@
|
|||
# Module 2 Specification
|
||||
|
||||
## Goal
|
||||
|
||||
This module will include its own ethers wasm implementation, so that it connects
|
||||
to the Ethereum blockchain and perform some testing operations. The Goal is to
|
||||
ensure the ethers connector can be decentralized and included in the project code.
|
||||
This module is important to ensure comunication with the smart contracts in a
|
||||
decentralized way.
|
||||
|
||||
## Dependencies
|
||||
- [ ] Module 0
|
||||
- [ ] Module 1
|
||||
|
||||
## ToDo
|
||||
- [ ] Basic understading YEW
|
||||
- [ ] Basic understading Ethers-rs(similar sintax to ethers-web)
|
||||
- [ ] Fork main chain
|
||||
- [ ] Create a base project to interact with DECA Smart Contract
|
||||
- [ ] Create some general access to functions for th DECA Smart Contract
|
||||
|
||||
## Report
|
||||
|
||||
### ethers-web Specification
|
||||
* [Ethers-web library](https://github.com/quay-rs/ethers-web/tree/main)[^1]
|
||||
* [Ethers-rs docs](https://docs.rs/ethers/latest/ethers/index.html)[^2]
|
||||
|
||||
|
||||
## Notes and further developments.
|
||||
|
||||
> Note1: Ethers-rs will be depercated in favor of [alloy](https://github.com/alloy-rs/)[^3] (yet alloy is not
|
||||
production ready).
|
||||
|
||||
## References
|
||||
|
||||
[^1]: https://github.com/quay-rs/ethers-web/tree/main
|
||||
[^2]: https://docs.rs/ethers/latest/ethers/index.html
|
||||
[^3]: https://github.com/alloy-rs/
|
Loading…
Reference in New Issue