The device can measure temperature and sign measurements, and the host can post these measurements together with the timestamp and signature on-chain.
The project consists of two parts: a host application and device firmware. After the firmware is flashed to the device, the device can be connected to a PC with the host application via USB to perform necessary communication. The firmware provides sensor data upon request and uses Embedano SDK methods under the hood for keys derivation and signing. The firmware does not assemble transactions; it only provides sensor data together with required signatures and keys. Transaction assembly and submission happen on the host.
Device
- embedded devices connected to Host via USB. Device is flashed with firmware which is built with Embedano SDK, enabling the device to derive keys and sign data.
Host
- device (e.g., PC or laptop) that sends requests to embedded devices connected via USB using the host application.
Script address
- the address of the script which is used as on-chain storage or registry for the data collected by Host
from the Device
.
Device address
- enterprise address derived from the mnemonic phrase for the specified derivation path. This address is used to pay the minimum required Ada and balance transactions to the Script address
. Mnemonics and derivation paths are set by the Host
during requests to Device
.
Device address
should have some Ada, soHost
can balance transactions properly.cardano-cli
of version1.35.4
with access to appropriate node socket should be available inPATH
on theHost
- communications with cardano node (UTXO queries or submission) are performed withcardano-cli
under the hood.
Host
initiatesDevice
with the mnemonic phrase that will be used by Embedano SDK for keys derivation and signing.Host
requests temperature sensor readings fromDevice
, providing the timestamp of the operation (current time), and data required for keys derivation and signing (password and derivation path).Device
returns temperature data, timestamp, and concatenated bytes of both signed with private key.Host
requests a public key fromDevice
with the same signing credentials as in the previous request to buildDevice address
.Host
queriesDevice address
for available UTXOs and uses those and temperature data to build and balance the transaction - temperature data received fromDevice
added to script output's Datum.Host
calculates the transaction hash - transaction ID, and sends a request toDevice
to sign this ID.- After receiving the signed transaction ID from
Device
,Host
adds signed data to the witness set of balanced transaction, making the transaction signed. Host
submits the signed transaction.
Host
initiatesDevice
with the mnemonic phrase that will be used by Embedano SDK for keys derivation and signing.Host
queriesScript address
to get all available UTXOs (we assume that only UTXOs with temperature measurements are there).Host
requests a public key fromDevice
with the signing credentials that should correspond to the data stored on-chain (password and derivation path for key).- For each UTXO from
Script address
,Host
parses temperature data, timestamp, andsigned data
from UTXO Datum. Then performs bytes concatenation for temperature data and timestamp, makingverification data
. Using the public key acquired fromDevice
,verification data
, andsigned data
,Host
checks that temperature data and timestamp were indeed signed by the public key acquired fromDevice
.
The easiest way to run the demo is to use Nix, as the repository provides a ready-to-go Nix setup. The following instructions use Nix with flake.
From the root of the project, enter the Nix shell:
nix develop
To flash firmware onto the device, some prior setup is required. The specifics of the setup will depend on your hardware and software. To see an example for the NRF52 Development Kit board
and WSL2 Debian
, check out the live demo.
Current setup uses this cargo config and this script.gdb to run gdb
and flash firmware when cargo run
is executed.
To flash firmware, from the root of the repo switch to the device directory
cd examples/nrf52-demo/embedano-device
Make sure device is connected to the gdb
server and script.gdb
has correct IP set through "target extended-remote ..."
command. Then run cargo run
.
If everything goes well, script.gdb
should load firmware and start main loop. A new USB device should appear in the system, and the client application should be able to communicate with it through the newly opened serial port.
In the second terminal cd
to main stream example directory:
cd examples/nrf52-demo
This directory contains script submission_demo.sh serves as a shortcut to run the client application. You will need to pass device serial and mode of operation
as arguments.
To submit transaction containing sensor readings from the device:
./submissionsubmission_demo.sh "/dev/ttyACM0" submit
To verify sensor readings stored on chain:
./submission_demo.sh "/dev/ttyACM0" verify
The application then will start selected scenario according to selected mode of operation
. To get more information about modes please check out rust docs for demo-client
or live demo videos.
- Live demo - link
- Cortex-M quick start template
- Board nRF52840 DK - used in demo
- gdb-multiarch debugger
- J-Link software pack
- usbpid instruction
- 1st submitted transaction - id
90516bf936e764cbc2cc16164d706b4c542cacec76b9fc45c679b191e0fdd414
- 2nd submitted transaction - id
377f5e7bb8a2f865748a9456d6ad4ae9a6585dc94ea8b35e8a64dffc1e23ceab
- demo script address - addr_test1wr5qpejpzx7szat38a58v246jk6hmexcvnfza5nsdvperqgvjcfxd