Sensor TRX

Inspiration

We wanted to build an autonomous sensor oracle system that could verify charity claims on Alice (www.alice.si), a social impact network that helps identify provably effective charity projects. On Alice, charities only receive donations when a validator verifies that they have achieved their goals. But until now validators on Alice were all humans.

But we didn't want the hassle of having to create and manage Ethereum accounts for each sensor. We also wanted to avoid having sensors manage their own private keys and connecting directly to the blockchain. Those kinds of sensors are expensive, and if they get lost or damaged...or stolen by an arctic fox...then the Ξth they hold is lost forever.

What it does

With SensorTRX, sensors simply sign their data with an elliptic curve digital signature and broadcast it over the Internet. We implemented this with Telegram for the demo, but this could be expanded to any public messaging service e.g. P2P networks, Twitter, Riot, Torrent, etc.

Once the signed message is on Telegram, anyone can pick it up and relay it to the blockchain. In fact, they'll get a bounty if they do. BUT ONLY if the data sent by the sensor validates a claim made by the charity. Relayers can check (pre-validate) this condition beforehand with a simple free, off-chain query of the main SensorTRX project contract.

For example, our demo simulates a charity project working to reduce air pollution. The sensor will sign and broadcast data regularly, but all the readings won't always show an improvement in air quality. Relayers can avoid publishing this data to the blockchain for no reward with a simple pre-validation.

How we built it

The application consists of three modules:

• First: a sensor simulator that periodically broadcasts measurements signed with a dedicated private key. Currently we broadcast on a public Telegram channel.
• Second: we have built a "relayer" service that picks up these messages and verifies - off-chain with a simple query to the project contract - whether they match the claim validation conditions on the project contract (e.g. the quality of the air measured has improved by x%) within a certain time period, and also checks that the relayer bounty provided in exchange for relaying to blockchain is generous enough to cover more than transaction gas costs. Once the pre-validation is completed off-chain, the relayer can decide to submit the data/message to the project smart contract.
• Third: the sensor data/message sent by the relayer is verified on-chain, and if it satisfies the conditions to validate a charity claim and was signed by a whitelisted sensor, a bounty payment is sent to the Relayer's account.

Challenges we ran into

• Tooling is a challenge: old Truffle boxes haven't been kept up to date with the latest upgrades in the Javascript ecosystem, e.g. Drizzle is facetious, and the Parity node we were using was very unstable in warp mode.
• Handling elliptic curve signatures and recovery was a challenge as this may differ depending on the blockchain node implementation. We experimented with different types to find the most compatible solution for SensorTRX.
• Writing secure smart contracts and testing them for attack vectors is always a challenge. Debugging complex smart contract structures is also difficult and requires creativity.
• The integration with Telegram was challenging too. Their documentation is great for bots but less so for APIs and we had to dedicate several hours to debugging.

Accomplishments that we're proud of

We managed to implement a working solution in a very short time frame. We haven't slept but it was worth it. We were three core members of the Alice team (two programmers and one clown) but we couldn't have done it without Will who we met yesterday at the event. We're really proud of the way the team gelled and had fun powering through the night to get everything done.

What we learned

Arctic foxes are super cute and love eating lemmings and seaweed.

What's next for SensorTRX

We see SensorTRX as a key part of the broader set of Alice protocols to support charity projects. We have a lot of ideas on how to improve it:

• "Optimistic submission": this mechanism will avoid the cost of systematic on-chain verification using a stake and challenge mechanism similar to Truebit.
• Consensus formation: we want to allow multiple sensors to measure the same thing in order to form a more precise measurement and disregard unreliable/corrupt/malicious sensors.
• P2P discovery and broadcasting protocol for the relayers: this would allow a fully decentralised solution for any interested party.
• Libraries for popular sensor frameworks such as Arduino and Raspberry Pi so that they can quickly be added to a project.
• Data obfuscation/encryption for projects that require privacy, for example medical devices monitoring patient health.
• Integration with proof of location services like FOAM.
• Creating a market place for data providers to incentivise sensor owners to join the network.
• Creating our own cool Trxy mascot that isn't ripped from the Paradise Bay game.

Web app: sensor-trx.alice.si

GitHub: github.com/alice-si/sensor-trx