DEV Community: Gaurav Jadkar

IOT and Embedded Systems Relation

Gaurav Jadkar — Mon, 02 Nov 2026 08:26:12 +0000

IoT Is Growing, But Are We Building Secure Enough Embedded Systems?

Why security must become an engineering requirement from the first stage of IoT development, rather than an update added after deployment.

Introduction

A smart home can control its lighting through a mobile application. An industrial sensor can monitor equipment remotely. A wearable device can continuously collect personal information.

These applications demonstrate how embedded systems and the Internet of Things (IoT) are becoming part of everyday life.

But there is an important question that deserves more attention:

Are we building these connected devices with security as a priority, or are we focusing mainly on functionality?

In my view, one of the biggest engineering challenges in IoT is not simply connecting more devices to the internet. It is ensuring that those devices remain secure throughout their lifecycle.

A device that works perfectly but cannot protect its data, restrict unauthorized access, or receive secure updates is not a complete engineering solution.

The problem starts at the design stage

When developers begin building an embedded product, the initial focus is often on functionality.

Can the sensor collect accurate readings? Can the microcontroller process the information? Can the device communicate with a mobile application?

These are important questions, but security should be considered alongside them.

Consider a simple smart door-lock system.

Its primary function is to control access to a door. However, what happens if an unauthorized person gains access to its communication interface?

The problem is no longer limited to software. It can affect a physical environment.

This is why embedded security requires a broader engineering perspective. Hardware, firmware, communication protocols, authentication, and software updates must work together.

Five security considerations every IoT developer should understand

A. Device identity and authentication

Every connected device should have a reliable identity.

Without appropriate authentication, an attacker may attempt to impersonate a legitimate device or access services that should be restricted.

Developers should consider unique device credentials, secure provisioning, and authentication between devices and backend services.

B. Protecting transmitted and stored data

IoT devices can process sensitive information, including location, operational data, and personal information.

Developers should identify which information needs protection and implement appropriate encryption and access controls.

Security should cover both data stored on the device and information transmitted across networks.

C. Secure firmware updates

One of the most important considerations is how a device receives software updates.

Imagine deploying thousands of connected devices. A security vulnerability is discovered after deployment.

How will manufacturers distribute a fix?

A secure update mechanism should authenticate updates, restrict unauthorized installation, and provide a controlled update process.

Without this capability, devices may remain exposed even after a vulnerability has been identified.

D. Restricting access to interfaces

Embedded devices may expose communication interfaces through USB, serial connections, wireless protocols, or network services.

Developers should identify which interfaces are necessary and restrict access to authorized entities.

Leaving unnecessary services or interfaces accessible increases the potential attack surface.

E. Monitoring device security

Security does not end when a device is manufactured or deployed.

Manufacturers and operators need ways to understand the device's security status, identify problems, and respond to incidents.

This requires considering logging, diagnostics, vulnerability reporting, and maintenance throughout the product lifecycle.

What established security guidance tells us

This is not just an individual engineering concern.

The National Institute of Standards and Technology (NIST) published NISTIR 8259A, which defines a core baseline of IoT device cybersecurity capabilities.

Its guidance identifies seven technical capability areas:

Device identification.
Device configuration.
Data protection.
Logical access to interfaces.
Software update.
Cybersecurity state awareness.
Device security.

These capabilities provide a useful starting point for thinking about security during product design.

Reference: "NISTIR 8259A – IoT Device Cybersecurity Capability Core Baseline" (https://csrc.nist.gov/pubs/ir/8259/a/final).

The OWASP Operational Technology Top 10 also highlights concerns such as unmanaged external access, known vulnerabilities, inadequate access control, and missing hardening.

Reference: "OWASP Operational Technology Top 10" (https://ot.owasp.org/v/2025/the-top-10/).

The important takeaway is that IoT security is not a single feature. It is a combination of technical capabilities, development decisions, and ongoing manufacturer responsibilities.

Is security always too expensive for low-cost IoT devices?

One argument often raised is that stronger security increases development costs.

This concern is understandable.

Low-cost embedded devices operate with limitations in processing power, memory, battery capacity, and manufacturing budgets.

However, I don't think the correct response is to treat security as optional.

Instead, developers should make risk-based decisions.

For example:

Avoid enabling unnecessary communication interfaces.
Use established cryptographic libraries rather than inventing cryptographic algorithms.
Protect credentials during provisioning.
Design firmware updates into the architecture.
Apply access restrictions according to the device's actual use case.

Not every device requires the same security architecture. A battery-powered temperature sensor and an industrial controller have different risk profiles.

But every device should have an appropriate security strategy.

The goal is not to add the most expensive security technology. It is to avoid preventable weaknesses through better engineering decisions.

Why embedded engineers need to think beyond hardware and firmware

Traditionally, embedded development has involved working with microcontrollers, peripheral interfaces, sensors, communication protocols, and firmware.

Today, connected devices require engineers to understand a wider set of technologies.

An embedded engineer working on IoT products may need knowledge of:

C and C++ programming.
Microcontroller architecture.
UART, SPI, and I2C communication.
TCP/IP and wireless communication.
Secure boot and firmware updates.
Cryptographic fundamentals.
Authentication and access control.
Hardware and firmware security testing.

This does not mean every embedded engineer must become a cybersecurity specialist.

It means that understanding security fundamentals is becoming an important part of building reliable connected systems.

My perspective: Security should be part of the first prototype

I believe the industry should change how it evaluates successful IoT products.

A prototype should not be considered successful simply because the sensor works, the data reaches a dashboard, or the mobile application displays the correct values.

Engineers should also ask:

Who can access the device?
How are its credentials protected?
Can its firmware be updated securely?
What happens if communication is interrupted?
How does the system respond to unauthorized access?

These questions should be included in the development process rather than postponed until a security review.

The earlier these considerations are addressed, the easier it is to make informed architectural decisions.

Conclusion

The future of IoT will not be determined only by how many devices we connect or how many features we add.

It will also depend on whether those devices can operate reliably and securely throughout their lifecycle.

For aspiring embedded engineers and developers, this creates an important opportunity to develop skills that combine hardware, firmware, networking, and cybersecurity.

My position is simple: a connected device should not be considered complete merely because it works. It should also be designed to operate securely.

Consensus Engine

Gaurav Jadkar — Mon, 02 Nov 2026 08:10:05 +0000

Building a Quorum-Based Consensus Engine in Python: A Beginner's Guide

Learn how validators, voting mechanisms, and quorum thresholds work by implementing a simplified blockchain consensus simulation.

Introduction

How can a group of independent participants agree that a proposed block should be accepted?

This is one of the fundamental questions behind blockchain consensus.

In a decentralized network, participants need a mechanism to agree on decisions without relying entirely on a central authority. Consensus mechanisms address this problem by defining how participants propose, validate, and approve changes to a shared state.

In this tutorial, we'll build a simplified quorum-based consensus engine using Python.

We'll implement a validator registry, collect votes, calculate the required quorum, and determine whether a proposed block should be approved.

This is an educational simulation, not a production blockchain consensus protocol. It does not implement network communication, cryptographic signatures, Byzantine fault tolerance, or fork resolution.

Understanding the consensus model

Before writing code, let's understand the components.

Our simulation contains three main elements:

Validators: Participants responsible for evaluating a proposal and casting votes.

Proposals: The blocks or decisions that validators are asked to approve.

Quorum: The minimum number of affirmative votes required to approve a proposal.

For this example, imagine a network containing six validators.

We require four approvals before accepting a proposed block.

      Proposed Block
            |
    -----------------
    |       |       |
  Voter   Voter   Voter ...
    |       |       |
    -----------------
            |
      Vote Collection
            |
      Quorum Check
            |
    -----------------
    |               |
  Approved        Rejected

Creating the validator registry

Let's begin by creating a class that manages the validators.

class Validators:

def __init__(self):
    self.validators = []

def add_validator(self, validator_id):
    if validator_id in self.validators:
        raise ValueError("Validator already exists")

    self.validators.append(validator_id)

def get_validators(self):
    return self.validators.copy()

The constructor initializes an empty validator list.

The "add_validator()" method registers a validator and prevents duplicate identifiers.

The "get_validators()" method returns a copy of the registered validator list.

Let's create six validators:

registry = Validators()

for validator_id in range(1001, 1007):
registry.add_validator(validator_id)

print(registry.get_validators())

Expected output:

[1001, 1002, 1003, 1004, 1005, 1006]

We now have six registered validators.

Defining the quorum requirement

A quorum represents the minimum number of approvals needed for a proposal to pass.

For a fixed absolute quorum, the calculation is straightforward.

total_validators = 6
required_quorum = 4

Our example requires four affirmative votes out of six validators.

A different consensus model might calculate quorum as a fraction of the total validator population.

For example, a two-thirds threshold for six validators would require:

required_quorum = 4

The exact quorum policy depends on the consensus protocol being designed.

Collecting validator votes

Now let's implement a voting mechanism.

Each validator can approve or reject a proposal.

class Voting:

def __init__(self):
    self.votes = {}

def cast_vote(self, validator_id, decision):
    if decision not in ("yes", "no"):
        raise ValueError("Invalid vote")

    if validator_id in self.votes:
        raise ValueError("Validator has already voted")

    self.votes[validator_id] = decision

def get_approvals(self):
    return sum(
        1 for vote in self.votes.values()
        if vote == "yes"
    )

The "votes" dictionary stores each validator's decision.

For example:

voting = Voting()

voting.cast_vote(1001, "yes")
voting.cast_vote(1002, "yes")
voting.cast_vote(1003, "no")
voting.cast_vote(1004, "yes")
voting.cast_vote(1005, "yes")

We can now calculate the number of affirmative votes.

print(voting.get_approvals())

Output:

Four validators have approved the proposal.

Implementing the consensus decision

We now need a function that compares the approval count with the required quorum.

def check_consensus(voting, required_quorum):

approvals = voting.get_approvals()

if approvals >= required_quorum:
    return "Quorum achieved"

return "Quorum not achieved"

Let's execute it:

result = check_consensus(voting, required_quorum)

print(result)

Output:

Quorum achieved

Our proposal has received the required number of approvals.

If the proposal receives fewer than four approvals, it will not pass the quorum check.

Notice that this is only a simplified approval rule. A production protocol also needs rules for validator eligibility, vote authenticity, conflicting proposals, timeouts, and finality.

Connecting the components

We have now implemented three important components:

Validator registration.
Vote collection.
Quorum verification.

Their relationship can be represented as:

The key design principle is separation of responsibilities.

The validator registry manages participants, the voting component manages decisions, and the consensus function evaluates the final approval condition.

This makes the system easier to extend and test.

Testing different scenarios

A useful way to evaluate the implementation is to test different voting combinations.

These tests verify that the decision logic behaves as expected.

Additional tests should cover duplicate votes, invalid validator IDs, invalid decisions, and missing votes.

What would be required for a real blockchain?

A simplified Python simulation is a useful starting point, but it should not be confused with a complete consensus protocol.

A production implementation would require several additional mechanisms:

Network communication: Validators need to exchange proposals and votes.

Cryptographic verification: Votes must be authenticated to prevent impersonation.

Fault tolerance: The protocol must define how it behaves when validators fail or act maliciously.

Finality: The system needs clear rules for when a block becomes irreversible under the protocol's assumptions.

State management: Accepted blocks must be connected to a consistent chain or replicated state.

These are substantial engineering challenges beyond simple quorum counting.

Conclusion

Building a quorum-based consensus simulation provides a practical way to understand how distributed decision-making works.

By implementing validator registration, vote collection, and quorum verification in Python, we have explored the basic structure of a consensus engine.

The next challenge is moving from a local simulation to a distributed environment where multiple independent nodes communicate, verify decisions, and maintain a consistent state.

That is where consensus engineering becomes particularly interesting.

Technologies: Python | Object-Oriented Programming | Consensus Fundamentals

Project extension: Explore proposer selection, block validation, cryptographic signatures, and distributed validator communication.

Vehiclerentalsystem

Gaurav Jadkar — Mon, 02 Nov 2026 08:05:19 +0000

Building a Vehicle Rental Smart Contract Using Solidity

A practical introduction to structs, mappings, modifiers, and booking management in Ethereum smart contracts.

Introduction

Imagine renting a vehicle without depending entirely on a centralized rental management system. Vehicle information, customer registration, and booking records could be managed through a smart contract, with the rules enforced by code.

This is one practical application of blockchain technology.

In this tutorial, we'll explore how to build a basic Vehicle Rental Smart Contract using Solidity. The project focuses on managing vehicle records, registering users, creating rental bookings, and maintaining booking statuses.

This is an educational prototype developed and tested using Remix IDE. It is not deployed to a blockchain network, and its payment logic calculates rental amounts without transferring cryptocurrency.

By the end, you'll understand how several important Solidity concepts work together in a practical application.

Understanding the project architecture

Before writing Solidity code, let's identify what our application needs to manage.

The contract has three primary components:

Vehicle management: Stores vehicle details, rental prices, availability, seating capacity, and ownership.
User management: Stores registered customer information.
Booking management: Maintains booking records, rental duration, calculated amounts, and booking status.

The relationship looks like this:

      Vehicle Rental Contract
                |
      ---------------------
      |         |         |
   Vehicle    User     Booking
   Records   Records    Records
      |         |         |
   Vehicle   Customer   Rental
   Details   Details    Details

This structure helps separate the responsibilities of different parts of the contract.

Setting up the development environment

For this project, I used "Remix IDE" (https://remix.ethereum.org/), a browser-based development environment for Solidity smart contracts.

You don't need to install a complete local blockchain development environment to follow the basic implementation.

Steps:

Open Remix IDE.
Create a new Solidity file named "VehiclRental.sol".
Add the Solidity version declaration.
Open the Solidity Compiler tab.
Select a compatible compiler version.
Compile the contract and review any errors.

The project uses Solidity version "0.8.13".

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.13;

contract VehicleRental {

}

The SPDX identifier specifies the source-code license, while the pragma declaration specifies the compatible Solidity compiler version.

Defining the data structures

One of the most useful Solidity features is the "struct" keyword.

A struct allows us to group related information into a single custom data type.

Our application requires three primary structures.

Vehicle structure

A vehicle needs information such as its registration number, name, rental price, availability, seating capacity, and owner.

struct Vehicle {
string veh_no;
string name;
uint price;
bool availability;
uint seating_cap;
address owner;
}

Each field serves a particular purpose:

"veh_no": Vehicle registration identifier.
"name": Vehicle name.
"price": Rental price.
"availability": Whether the vehicle is available.
"seating_cap": Maximum seating capacity.
"owner": Blockchain address of the vehicle owner.

User structure

We also need to maintain customer information.

struct User {
address renter;
string name;
uint age;
string phone_no;
}

The "renter" field identifies the customer's blockchain address.

Booking structure

The booking structure connects the customer with the rented vehicle.

enum BookingStatus {
Pending,
Booked,
Completed,
Cancelled
}

struct Booking {
uint book_id;
uint rent_time;
uint return_time;
uint total_amt;
string veh_no;
address renter;
BookingStatus status;
}

Using an enum instead of arbitrary status strings makes the booking states easier to manage.

For example, a booking can move through different stages:

Pending → Booked → Completed
|
└──────────→ Cancelled

This is a simplified conceptual flow; the contract must enforce valid state transitions in its functions.

Using mappings to store information

Now that our data structures are ready, we need a way to access their records.

Solidity provides mappings for key-value storage.

Our contract uses three mappings:

mapping(string => Vehicle) vehicles;
mapping(uint => Booking) bookings;
mapping(address => User) users;

Here's what each mapping does:

Mapping| Purpose
"vehicles"| Retrieves vehicle records using a vehicle identifier
"bookings"| Retrieves booking records using a booking ID
"users"| Retrieves user records using their wallet address

Mappings are particularly useful when an application needs to retrieve records using unique identifiers.

An important detail: Solidity mappings do not provide a built-in way to enumerate all their keys. If we need to display every vehicle or booking, we must maintain additional lists or use an appropriate off-chain indexing solution.

Implementing access control with modifiers

Smart contracts need rules that determine who can execute particular functions.

For example:

Only registered customers should be able to perform customer-specific operations.
Only vehicle owners should be allowed to manage their vehicles.
A booking should only be created for an existing vehicle.

Solidity modifiers help implement these restrictions.

A simplified example:

modifier onlyRegisteredUser() {
require(
users[msg.sender].renter == msg.sender,
"User not registered"
);
_;
}

The "require()" statement checks a condition before the function continues.

The underscore represents the location where the modified function's code executes.

Other modifiers in this project include:

"onlyOwner": Restricts an operation to the vehicle owner.
"vehicleExist": Checks whether a vehicle exists before processing an operation.

These checks help prevent unauthorized operations, although modifiers alone do not guarantee complete contract security.

Calculating rental amounts

One of the important parts of a vehicle rental application is calculating the total rental cost.

The basic calculation is:

Total rental amount = Rental price × Rental duration

For example:

Suppose a vehicle costs 500 units per rental period and is booked for three periods.

Rental price = 500
Duration = 3

Total amount = 500 × 3
= 1500

The actual implementation needs to define its time unit clearly and validate the rental and return times.

For example, if timestamps are used, the contract should reject a return time that is not later than the rental time.

An illustrative validation is:

require(
returnTime > rentTime,
"Invalid rental duration"
);

The project calculates the booking amount and stores it in the booking record. It does not currently execute an ETH transfer.

This distinction is important: calculating a payment amount is not the same as processing a blockchain payment.

Managing booking status

A rental application needs to track the current state of every booking.

Our "BookingStatus" enum provides four possible states:

"Pending": The booking has been created but is not yet confirmed.
"Booked": The booking has been confirmed.
"Completed": The rental process has been completed.
"Cancelled": The booking has been cancelled.

These states make the booking lifecycle easier to understand and manage.

A production implementation should validate every status transition and define what happens to vehicle availability when a booking is confirmed, completed, or cancelled.

Compiling and testing with Remix IDE

After implementing the contract, the next step is to compile and test it.

In Remix:

Open the Solidity Compiler.
Select a compatible Solidity compiler version.
Compile the contract.
Open the Deploy & Run Transactions panel.
Select the appropriate Remix execution environment.
Deploy the contract to that environment.
Interact with the available functions and inspect their outputs.

For an educational prototype, test scenarios should include:

Registering a customer.
Registering a vehicle.
Attempting to register a duplicate vehicle identifier.
Creating a booking for an existing vehicle.
Attempting to book a nonexistent vehicle.
Checking the calculated rental amount.
Testing unauthorized access.
Checking booking status updates.

These are suggested test cases, not a claim that every scenario has already passed.

Limitations and future improvements

Building this project helped me understand how Solidity data structures, mappings, modifiers, and enums work together.

However, the current implementation is an educational prototype rather than a production-ready rental platform.

Some important improvements would include:

On-chain payments

Implement payable functions and a secure payment/refund mechanism, with appropriate handling of failed transactions.

Stronger booking validation

Prevent overlapping bookings and ensure vehicle availability is updated consistently.

Security testing

Test access-control restrictions, input validation, reentrancy risks where applicable, and other potential vulnerabilities.

Deployment

Deploy to an Ethereum testnet and verify contract behaviour in a blockchain environment.

Frontend integration

Build a web interface that allows customers and vehicle owners to interact with the contract through a wallet.

Conclusion

A Vehicle Rental Smart Contract is a useful beginner project for understanding how blockchain applications manage structured data and enforce rules through code.

Through this implementation, I explored Solidity structs, enums, mappings, modifiers, booking records, and rental amount calculations.

The most important lesson was that writing a smart contract is not simply about translating application logic into Solidity. It also requires thinking about access control, data consistency, transaction behaviour, and security.

This project is an initial step in my journey towards developing more practical blockchain applications.

Next step: Extending the prototype with secure payment handling, comprehensive tests, and testnet deployment.

Project source code: "Vehicle Rental Smart Contract – GitHub" (https://github.com/gauravjadkar/Vehicle-Rental-Smart-Contract-solidity-)

Technologies: Solidity 0.8.13 | Remix IDE