Following our previous exploration of data verification’s importance in Vehicle-to-Network connectivity, we now turn our attention to the intricate steps involved in Soarchain’s data verification process.
In the realm of connected vehicles and smart mobility, the Soarchain ecosystem is a game-changer. It’s a public Proof-Of-Stake (PoS) blockchain that enables any vehicle or road user to communicate application-specific data to the consumers of that data through any protocol that can act as a relay to the internet. The goal? To create a global fleet that streams large amounts of data to the cloud, unlocking countless data collection, device management applications, and third-party services.
One of the key aspects of Soarchain is vehicle-to-network (V2N) connectivity. It’s a mechanism that allows data to be transmitted to a decentralized entity called a “runner”. But how does this process work? And how does Soarchain ensure the integrity and authenticity of the data? Let’s dive in.
The Journey of Data in Soarchain’s V2N Network
Proof-of-Availability mechanism
Data Collection and Signing
The journey of data in Soarchain’s V2N network begins with the Soarchain mobile app. This app collects GPS, accelerometer, and barometer sensor data and passes them to the Motus Mini, a tamper-proof device that serves as the V2N broadcaster.
The collected data is timestamped and signed using a private key securely stored inside the physical crypto module within the Motus Mini. The signed data is then returned back to the Soarchain mobile app.
Data Broadcasting and Storage
The Soarchain mobile app takes the signed data and publishes it over MQTT to topics that are listened to by the V2N Runner network. A Runner, upon receiving the message, verifies the plausibility and the structure of the message, stores it, and appends it to the Merkle tree created off of its storage buffer.
This means that each V2N message is a leaf of this Merkle Tree. The runner then distributes the received V2N message to the broadcaster’s surrounding Motus Minis.
Claim Issuance
Once a Runner’s buffer storage is filled with a certain number of messages (currently 512 messages), it issues a signed “V2N Claim” to the V2N challenger network over MQTT. This claim indicates that the Runner has collected a certain number of V2N messages and is ready to receive a “V2N Challenge” to prove this claim.
The claim includes the number of messages, the Merkle tree root of the current state of the storage buffer, and the Runner’s public key.
Challenge Creation and Response
A challenger, upon receiving the claim, creates a challenge based on that claim. The challenge includes a set of random indexes referring to the requested leaves (each representing a V2N message) of the Merkle tree.
The challenger stores the challenge object, gives it an ID, signs it using its private key, and sends it over MQTT to the Runner that previously issued the claim.
The runner receives the challenge object, extracts the requested Merkle Tree leaf indexes, and queries them from its storage. It then constructs a challenge-response object containing the requested leaves, signs it, and sends it back to the challenger.
Merkle Tree Verification and Reward Distribution
Upon receiving the challenge response, the challenger embarks on the task of verifying the Merkle tree. This process involves using the information provided in the challenge response, along with the previously stored challenge object, to confirm the integrity of the Merkle tree.
In the event that the Merkle tree fails this verification process, the challenger takes action by issuing a “punish” transaction to the Soarchain blockchain. This transaction serves as a penalty, indicating that the score of the respective runner should be decreased due to the invalidity of its proof.
On the other hand, if the Merkle tree passes the verification process, the challenger issues a “reward” transaction to the Soarchain blockchain. This transaction signifies that the runner and the Motus Minis that broadcasted the messages corresponding to the randomly selected leaves of the Merkle tree are to be rewarded. The reward is calculated based on their current score.
This process is a critical part of the Proof-of-Availability (PoAV) mechanism, ensuring that the selected Motus Minis are rewarded for their contribution to the Soarchain V2N connectivity ecosystem.
Looking Ahead
This deep dive into the data verification process in Soarchain’s V2N network reveals the meticulous steps taken to ensure the integrity and authenticity of the data. It’s a testament to Soarchain’s commitment to creating a reliable, trustworthy ecosystem where everyone plays by the rules.
In our next article, we’ll explore the distributed MQTT network used for moving messages around. This network plays a crucial role in how we distribute V2N messages broadcasted by a Motus Mini to its surrounding Motus minis.
So, stay tuned as we continue to unravel the intricacies of Soarchain’s V2N connectivity and how it’s shaping the future of connected vehicles and smart mobility.
Comments