-
Notifications
You must be signed in to change notification settings - Fork 0
Home
A decentralized application running on the Ethereum blockchain, to empower real behavioral change driven by goal setting tied to financial incentivizes.
Database - Local blockchain, Ethereum’s Testnet Rinkeby blockchain.
Hosting - IPFS
Frontend - React/Redux/ReduxRouter with Webpack/Babel, Semantic-UI, Avataars
Domain name - tbd
Package Manager - NPM, ethPM
Programing language - Solidity 0.4.24
Frameworks - Trufffle
Development server - Node.js, ganache-cli
Transaction Signing - Metamask
Authentication - uPort
- Considering this question - 'What are the concerns that contracts are dealing with?'
- Users will have an ability to accept ether to their username; Each pledge will have a certain value tied to it; And keeping it all in one (potentially very complicated) contract seems to create a very nice large honey pot, and is much more difficult to audit.
- If the users hold their money inside their own single pledge contract, then it would be easier to protect the amount, and provide a much more clear way to audit.
- Child contracts are more expensive, but given the reasons above, I believe the implementation will be much more secure and auditable.
To keep track of pledges that belong to a single authenticated(by uPort) user.
Originally, I thought this would be a string because I wanted to store the MNID, but as it's a known issue that the EVM doesn't handle string[] well (i.e - can't return string[] from a contract function) - I took the next approach.
Usually the address key is a MetaMask address from which the transaction happens. But since many wallet addresses can belong to the same user, this approach didn't make sense in a system where we are using uPort to authenticate.
I chose the address key here to be the value returned by MNID.decode(). I'm thinking of storing the MNID from uPort as the ‘user address’ key, and not the actual wallet address. A pledge could only be modified if and only if the userNetworkSpecificAddress of the current authenticated user matches the userNetworkSpecificAddress of the creator of that Item.