enlight-me / decentralized-land-admin Goto Github PK

OLAdmin :

• Name : DeLA (Decentrelized LandAmin)
  *contracts
• add RRR
• add dispute
  struct Transaction {
  address destination;
  uint value;
  bytes data;
  bool executed;
  }
  const ProjectStatus = Object.freeze({'Waiting':0, 'Rejected':1, 'Approved':2, 'Disabled':3})

*client:

• dispute/bid

• Implement OrbitDB for managment of features geometries
• save geometry hash to wkbHash of the smart contract
• allow user to sketch his parcel on the map (Survey Points)

• At least one contract uses a library or inherits from another contract
• Implement/ use a library or an EthPM package in your project. If your project does not require a library or an EthPM package, demonstrate how you would do that in a contract called LibraryDemo.sol
• use Interface https://blog.colony.io/writing-upgradeable-contracts-in-solidity-6743f0eecc88/

The dashboard should display the stats of the whole dApp state :

• owners / parcels
• parcels / geographic regions

https://js.ipfs.io/
https://github.com/ipfs/js-ipfs/tree/master/examples#js-ipfs-examples-and-tutorials
https://www.youtube.com/watch?v=8CMxDNuuAiQ

https://github.com/egalano/ipfs-deploy

• Write a sentence or two explaining what the tests are covering, and explain why you wrote those tests
• 5 tests written in Javascript or Solidity (or both) ( If the contract is so simple as to not require 5 tests for full coverage, it is okay to issue 5 points for less than 5 tests)
• Tests are properly structured (Each test sets up context, executes a call on the function to be tested, and verifies that the result is correct)
• All tests pass

conform to the specifications : https://solidity.readthedocs.io/en/latest/layout-of-source-files.html#comments

https://en.wikipedia.org/wiki/Doxygen

• A development server to serve the front end interface of the application (It can be something as simple as the lite-server used in the truffle pet shop tutorial)
• The app displays/recognize the current ethereum account
• I can sign transactions using Metamask (or another web3 provider)
• The app interface reflects updates to the contract state
• You should be able to visit a URL and interact with the application

https://docs.openzeppelin.com/contracts/2.x/access-control

• add import "./Roles.sol" to LAParcel
• add CircuitBreaker to LARegistry
• add killer to LAParcel

 function kill()
    {
           if(msg.sender == owner()) selfdestruct(address(uint160(owner()))); // cast owner to address payable
    }

The router must add a new record to the spatialite DB with :

• the owner
• the geohash
• the CSC Index
• the transaction address

The parcel registry should be handled by the dApp.

• In case dggsIndex is already claimed log an error
• Add user address Index too

Admins can access a dashboard of all data
Roles in https://docs.openzeppelin.com/contracts/2.x/access-control

• CircuitBreaker
• mortal

Use directly the events listner from block = 0

• Click on the map should trigger "Add Feature to the Ledger"
• Map should display all the parcels / Users parcels with a specific theme
• Drawer should display the list of the users parcels

Switch to functionnal components

• App.js
• Map
• Drawer
• AppBar

Use react hooks for global state variables

• createContext / useContext
• useState

• Project includes a file called deployed_addresses.txt that describes where the deployed testnet contracts live (which testnet and address)
• Deploy your application onto one of the test networks. Include a document called deployed_addresses.txt that describes where your contracts live (which testnet and address).
• You can verify your contract source code using etherscan for the appropriate testnet https://etherscan.io/verifyContract

Make state variables private to restrict access from other contracts

Use rhombus or XYO.network to implement oracles
For CSFeatures we can use OGC Simple Feature Access - Part 1: Common Architecture
https://www.opengeospatial.org/standards/sfa

• use router (pages : Home page / Dashborad / Map)
• Manage Parcel Dialog as Bottom Drawer

The LAParcel and LA ParcelRegistry Smart contracts variables and the UI must be conform to LADM:

• parcelType -> landUseCode (residential/commercial/industrial/agricultural)
• extAddressID -> extAddress
• type_code (type of land parcel : parcel / building)
• source_reference (documents...)
• status_code (transaction)
  "pending"; "current"; "cancelled"; "completed"; "loaded"; "lodged"; "historic"; "approved";
  "previous";"archived"; "assigned"; "requisitioned"; "unassigned"; "rejected";"dead";
  "to-be-transferred";
• name_firstpart / name_lastpart
• dggsIndex -> referencePoint

• zoom into
• zoom to map

When the user Click on the map the coordinates should be converted to H3.
After that a contract is called to Add CSC Index to the ledger

handle parcels events :

• update

"addDocument";
"approve";
"archive";
"dispatch";
"withdraw";
"cancel";
"requisition";
"validate";
"lapse";
"lodge";
"assign";
"unAssign";
"resubmit";
"transfer";
"validateFailed";
"validatePassed";

https://blog.indorse.io/ethereum-upgradeable-smart-contract-strategies-456350d0557c

• Add array in Features to store the address of the disputer
• Add multis signature https://github.com/gnosis/MultiSigWallet
• some functions calls should be restricted when state is Disputed
• https://github.com/Zokrates/ZoKrates

Update :

• contract / test
• UI for disputes
• implement notifications in the AppBar (when dispute arise)

The event add CSC Index must be handled and the params must be sent to the server's addCSCIndex

Implement a web3 listener to handle contract events and add spatial Features to the SpatiaLite Database.
This will allow handling events from any contract call, not just those from the dApp Frontend UI.

• Project includes a file called avoiding_common_attacks.md that explains at least 3 common attacks and how the app mitigates user risk.
• explains what measures you took to ensure that your contracts are not susceptible to common attacks. (Module 9 Lesson 3)
• Explain what measures you’ve taken to ensure that your contracts are not susceptible to common attacks (at least 3)
• use MythX
• use Mythril
• use Slither

The signaled areas should have incentives for whom that contribute.

• Add token in contracts
• Update tests
• UI

handle parcels events :

• revoke

• and metamask account change:

https://metamask.github.io/metamask-docs/Advanced_Concepts/Provider_API#ethereum.on(eventname%2C-callback)

Record your screen as you demo the application, showing and explaining how you included the required components.

• A document called design_pattern_desicions.md that explains why you chose to use the design patterns that you did
• Project includes a file called design_pattern_desicions.md that adequately describes at least 2 design patterns implemented in the project
• Circuit breaker pattern outlined here https://consensys.github.io/smart-contract-best-practices/software_engineering/#circuit-breakers-pause-contract-functionality
• explain what other design patterns have you used / not used. Why did you choose the patterns that you did? Why not others?

• A project README.md that explains your project. What does your project do? How do you set it up?
• I can run the app on a development server locally for testing/grading (or connecting to Rinkeby/Ropsten if required)
• Your project should be a truffle project
• All of your contracts should be in a contracts directory
• Truffle compile should successfully compile contracts
• Migration contract and migration scripts should work
• Truffle migrate should successfully migrate contracts to a locally running ganache-cli test blockchain on port 8545
• All tests should be in a tests directory
• Running truffle test should migrate contracts and run your tests

• use github actions or travis CI
• create github pages for the app and deploy the build with Rinkeby config

• Project uses IPFS (The app is hosted on IPFS or allows users to interact with IPFS.)
• Serve the UI from IPFS or a traditional web server
• The project uses and upgradable design pattern for the smart contracts (Interfaces)
• At least one contract is written in Vyper or LLL
• The app uses uPort for user authentication and/or signing and sending transactions
• The app uses the Ethereum Name Service to resolve human readable names to Ethereum addresses
• The project uses an Oracle service such as Oraclize

Creating several user stories can help the evaluator understand what your dApp is and how potential users are supposed to interact with it. User stories outline how users will interact with the application. They should be descriptions of end goals of the application rather than descriptions of features.

• Developement platform
• Crowd sourcing
• Doing business / Property registration index
• Fight against land corruption
• use https://github.com/SOLA-FAO/latest-release/blob/master/1503a/docs/registry_user_guide_%20v1503a.docx