Can DApps run on an embedded device?

This article is written by James Brown, Co-Founder of AlphaWallet.

It turns out they actually can, in a native way, providing you tweak the code just right …

Some time ago I participated in an engineering design challenge. One of the teams were tasked with creating a device to water plants for 2 weeks while the owners were away. The device they came up was a electrical behemoth which featured pumps, electronic timer systems, hoses, multi level sumps, moisture sensors and scaffold arms. At the presentation the machine exploded spectacularly sending water everywhere.

1*7j0nb6bIn6fNPfzFHlZWlA

This is what you get when you ask a group of engineers to design ‘automatic plant waterer’. https://www.instructables.com/id/Arduino-Automatic-Watering-System-For-Plants/

We were then treated to the commercial solution — a piece of muslin cloth with one end dipped in a jar of water and the other in the plant pot. Capillary action drip fed the plant with water. Yes — the ideal solution is a piece of cloth and a jar of water.

The year before a team designed a system for terminally ill patients to be able to smoke in a hospital bed (hey it was the 90’s). The solution was exactly what you’d think of when you’re a school kid — inevitably involving a robot arm holding the cigarette with a motorised tray to catch and disposed of the ash. There was a bank of timing relays, sensors and stepper motors clunking away while the device moved a cigarette into and out of the patient’s mouth. In the presentation the machine comically assaulted one of the judges and ejected burning cigarettes into the audience before unceremoniously shaking ash over the presentation team. Perhaps the robot arm was programmed with Asimov’s laws of robotics and deemed that allowing the human to smoke violated the first law of robotics (don’t allow harm to come to human).

You may ask Robot may to help you smoke — Robot will try to obey providing it doesn’t endanger a human’s life. The robot may, if ordered to harm a human become locked up in an ethical dilemma, especially if this is happening anywhere between 1955 and 1990.

The commercial solution (designed by a retired fireman) was an ash tray with a hole in the side to hold the cigarette and a tube going into the patient’s mouth.

If you have been in the Ethereum space for a while and have a passing interest in IoT you may recall a team who were building a complete solution for powering IoT devices with Ethereum that made a lot of noise for a while. The solution the team built involved custom Raspberry Pi kernels, WiFi handshakes, a mix of outrageous European accents, hand rolled protocols, a lot of PR, promises to industry and requests for funding — this part seemed very well polished. It required a small team of engineers and software devs just to install it— if they could actually get it running.

In that vein, we have developed a IoT/DApp(*) system that tries to deliver the real world solution those early pioneers sought for.

  • Zero infrastructure — no proxy servers, no app.
  • Security entirely powered by ECDSA-the same cryptography that gives Bitcoin and Ethereum their trust. No custom protocols or proxies.
  • Tiny attack surface-there is only one way input can reach the device. By simple and robust constraints and input checking we can easily protect against buffer overrun attacks and so on.
  • No chance to do man-in-the-middle attacks, where a proxy server can translate the user’s input and re-key it. If you hold the token in your wallet there’s no way to stage a proxy attack.

Two lines of development make a simple solution possible — ERC875 Non-Fungible-Tokens and Web3E.

To showcase how these work together seamlessly we solved an issue at the AlphaWallet office. We were issued with only 2 entry cards but there are between 4 and 8 people working in the office. This creates somewhat of a problem considering three of us also live at the office (we’re a startup, don’t judge!).

The office door has a byzantine intercom system where you can let people in after they buzz using a sequence of button pressing on the intercom, but it only works after you buzz the door and within 10 seconds of buzzing.

Our system uses AlphaWallet and a DApp served from an ESP32 micro-controller device which is connected to a relay system that closes the connections on some switches after a would-be enter-er passes a cryptographic challenge. It will also work on any DApp enabled wallet browser like Chrome with Metamask plugin.

So, how does it work?

  • A DApp running on a micro-controller which serves the DApp web page to a wallet browser.
  • When a user connects to server, the microcontroller produces a random challenge string embedded in the web page/DApp that is served.
  • The user clicks on the ‘Open Gate’ button and a Web3 function call in the DApp JavaScript is intercepted by the wallet/Metamask, which prompts the user the sign the challenge string with their private key.
  • The DApp JavaScript embeds the resulting signature and the wallet address into a header which is sent back to the micro-controller as a redirect-URL (like adverts in emails do to analyse who clicked on their email).
  • The DApp uses the signature and the challenge it sent to perform an EC-recover.
  • The address calculated from the EC-recover is first compared with the address sent to check they match. If they match, we know the user owns the private key for that address. You could skip this stage.
  • The address is checked to see if it holds an ERC875 AlphaWallet office entry attestation token. If the address does, then the microcontroller begins the sequence to open the door.
  • Opening the door is a series of three button presses to simulate opening the intercom (usually the check the identity of the person asking for access), with intercom open the door open command is sent, then the intercom closed. Some electro-mechanical relays controlled from the device perform these actions.

The key point here is that instead of verbally confirming the enter-er — which is highly inefficient; this may happen upwards of 20 times per day — we instead issue the enter-er with an attestation that they are allowed to enter. Should the enter-er’s entry need to be revoked it’s as simple as using the ERC875 contract admin key (used to create the contract) to transfer the token back into the admin pool.

You can find the source code for the door app here:

alpha-wallet/Web3E-Application Applications Using Web3E. Contribute to alpha-wallet/Web3E-Application development by creating an account on GitHub. github.com

To run it you’ll need to install Platformio if you haven’t already done so. The Web3E library is now part of official libraries so it will download automatically. Full instructions for setting up the sample are on the github page above.

The ESP32 hardware was from these guys — they design and make the circuits boards themselves and have an interesting range of boards including one with e-paper that seems like it would have a good application in the crypto space.

(*)DApp

A while back someone came up with an idea for websites to interact with Ethereum via a wallet. They called any site that uses ethereum as the backend a Decentralised-Application or DApp. It’s decentralised because it depends on a decentralised network as opposed to consulting a database API.