forked from DECA/DAOTask
Compare commits
No commits in common. "develop" and "main" have entirely different histories.
84
README.md
84
README.md
|
@ -1,84 +0,0 @@
|
||||||
# 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
Before Width: | Height: | Size: 15 KiB |
|
@ -1,22 +0,0 @@
|
||||||
@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
|
|
31
module0.md
31
module0.md
|
@ -1,31 +0,0 @@
|
||||||
# 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/
|
|
93
module1.md
93
module1.md
|
@ -1,93 +0,0 @@
|
||||||
# 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
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
38
module2.md
38
module2.md
|
@ -1,38 +0,0 @@
|
||||||
# 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