search

iotexproject / halogrants

👟 Apply for a IoTeX Halo Grant. Help build the IoTeX ecosystem!
MIT License
72 stars 46 forks source link

Power your dApp with Verifiable Real-world Data #36

Open simonerom opened 3 years ago

simonerom commented 3 years ago

Power your dApp with Verifiable Real-world Data

Welcome!

Thank you for your interest in IoTeX. You are welcome to participate in our competitions. Also, take a look at the other prizes:

Please join our Discord to discuss the bounties.

Bounty Prize

2500 USDT to the most creative submission

The Challenge

Pebble Tracker is a multi-sensor IoT board that converts real-world phenomena into verifiable, blockchain-ready data. We would like you to create a simple dApp that gets periodically fed by these verifiable data messages containing sensor values, verifies the message signature, and takes specific actions based on the sensor's values.

Below we provide the basic specifications, but anyone is free to extend it and get creative:

  1. Use our Pebble Simulator to generate a set of Pebble sensor data points along with their signature.
  2. Create a smart contract that stores a list of "registered" devices. The contract owner can allow or block/delete devices. Anyone can "register" a new device (use the device IMEI and Public key for identification).
  3. The contract should have a method to receive a Pebble data message and verify both data source device and data integrity.
  4. The contract will reject data messages that come from non-whitelisted devices or whose signature is invalid.
  5. For valid data messages, The contract will take some action based on the sensor values it received (e.g., store the latest values, transfer funds if a specific event is detected, etc...)
  6. Create a frontend for the smart contract that allows users to log in with Metamask; allows any user to register a device, and the contract owner to allowlist, block, or delete registered devices, and displays any data relevant to the smart contract (e.g., display all devices, display latest data per device, display token transfers, contract balance, etc...)

For the Smart Contract, you are required to use Solidity 0.5.13, for the frontend we suggest our dApp sample (though not a strict requirement)

Acceptance Criteria

Judging Criteria

Misc/References

Useful links

Data message verification is the key concept behind the verifiability of Pebble Tracker data: you can both verify the source (i.e. the device public key) of the data, and the integrity of the data in one single step using the signature included in the Pebble Tracker data messages:

...
"signature": {
  "r":"4c05a4fa3eba782780a517ba03ef6fdd65e5b560a027808b47fcc6ed2b864169",
  "s":"05bde29104febe10c096c550b91f5d8ed2cf0d15fe48e164ee0e9765dda76f34"
}

rand s are the two components of the elliptic curve signature (using secp256k1 curve) of the data message, obtained by signing the keccak256 hash of the JSON object rendered to a string without any formatting. A possible example to verify the message signature would be the following, using the solidity ecrecover function:

// The verification function is called with all Pebble IoT data values, including the signature `r` and `s` components
function receiveData(string temperature, string latitude, string longitude, ..., bytes32 r,  bytes32 s)

// buildJsonString should just rebuild the original pebble data message into an unformatted
// json string using the data passed to receiveData(), and returns the string cast to bytes  
bytes32 hash = keccak256(buildJsonString(temperature, latitude, longitude, ...));

// Recover device address from the data message signature 
bool hit;      
address deviceAddress;
// the signature version "v" can be either 27 or 28, the device does not provide it so
// we test both of them       
for (uint8 v = 27; v < 29; v++) {        
  deviceAddress = ecrecover(hash, v, r, s);        
  if (whitelist[deviceAddress] == 1) { 
    hit = true;          
    break;        
  }     
}

If ecrecover() returns a valid, non-zero address, this means that the data integrity is assured (i.e. the data passed to the contract correspond to those originally signed by the device). If the returned address is also included among the whitelisted devices then both the source and integrity of the data are verified, all is good and the contract can go ahead processing the sensors data (which is now trusted data!) and taking the specific actions required by the dApp.

IoTeX Useful Links

Discuss: Please join our Discord Dev Chat to ask questions or reach out to Simone_IoTeX on Discord if you need any help.

Docs: IoTeX Docs | Ethereum Compatibility | DID | Full Nodes

Follow Us: iotex.io | Telegram | Twitter | Medium | Reddit

gitcoinbot commented 3 years ago

Issue Status: 1. Open 2. Started 3. Submitted 4. Done

This issue now has a funding of 2500.0 USDT (2500.0 USD @ $1.0/USDT) attached to it.

gitcoinbot commented 3 years ago

Issue Status: 1. Open 2. Started 3. Submitted 4. Done

Work has been started.

These users each claimed they can complete the work by 19 hours ago. Please review their action plans below:

1) jpick713 has been approved to start work.

The project will allow monitoring of VOC emissions from a kiln to conform to environmental regulations and also though temperature and humidity tracking give insight into MC% at a given time and possibly trigger actions once certain conditions are met.

Learn more on the Gitcoin Issue Details page.

gitcoinbot commented 2 years ago

Issue Status: 1. Open 2. Started 3. Submitted 4. Done

Work for 2500.0 USDT (2500.00 USD @ $1.0/USDT) has been submitted by:

gitcoinbot commented 2 years ago

Issue Status: 1. Open 2. Started 3. Submitted 4. Done

Work for 2500.0 USDT (2500.00 USD @ $1.0/USDT) has been submitted by:

  1. @65black
  2. @nicky-ru

@simonerom please take a look at the submitted work: