 ICACT20260208 Slide.01
[Big Slide]
|
Chrome  Click!! |
 |
Hello everyone, im juyoung yoon from ewha womans university.
Today, I’ll present our work on a scalable and secure federated learning framework for IoV.
|
| ICACT20260208 Slide.02
[Big Slide]
|
Chrome Click!! |
 |
|
| ICACT20260208 Slide.03
[Big Slide]
|
Chrome Click!! |
 |
IoV is a real-time and highly dynamic environment connecting vehicles, RSUs, and the cloud, enabling services like autonomous driving model updates and real-time traffic optimization.
So, federated Learning is attractive in iov because it improves privacy that raw data stays on vehicles rather than being uploaded centrally.
However, FL alone does not guarantee trust. It still need model-update integrity, and we need accountability so malicious behavior can be traced when necessary.
To solve this, Blockchain can be used as a trust layer by providing integrity and auditability through an immutable distributed ledger,
but conventional consensus is often too heavy for IoV due to overhead and latency, and can also leak privacy through traceability.
So the core challenge is balancing privacy, security, and performance in large-scale IoV-FL.
|
| ICACT20260208 Slide.04
[Big Slide]
|
Chrome Click!! |
 |
Based on the trust gap, our paper makes two main contributions.
First, we design a stack-scripted verification layer for RSUs. Vehicle registration and model submission are standardized as stack-based scripts, so RSUs can perform rapid verification under the same set of rules.
At the same time, we achieve conditional privacy by binding each vehicle’s pseudonym while keeping a restricted traceability link so a trusted authority can trace only when necessary.
Second, we propose Committee-based Chained HotStuff. It addresses the leader bottleneck in original Chained HotStuff by delegating signature aggregation to a committee and enabling parallel block preparation, which reduces consensus latency and improves throughput and stability.
Together, these components form a practical IoV-FL framework that combines deterministic verification, on-chain pseudonym management, and scalable BFT consensus.
|
| ICACT20260208 Slide.05
[Big Slide]
|
Chrome Click!! |
 |
Related work has two main streams. First, privacy and pseudonym management: prior methods support conditional privacy, but pseudonym management can still be complex and add latency. Second, BFT consensus for IoV blockchain: PBFT scales poorly, and although HotStuff variants improve performance, but leader bottlenecks and QC waiting still remain.
Therefore this paper aims to address these limitations with an integrated framework.
|
| ICACT20260208 Slide.06
[Big Slide]
|
Chrome Click!! |
 |
So, this is the overall system architecture of the proposed IoV framework. We assume a three tier IoV architecture. First vehicle generates a key pair using an onboard HSM, creates an HID, trains its own local model using collected data and submits model parameters to nearby RSU
Each RSU verifies requests via stack scripts, and forms the blockchain network to store authentication and parameters.
And the server is a trusted authority that manages fl epochs and audit keys, approves pseudonym changes, and can trace past pseudonyms only under legitimate procedures using an encrypted on-chain pointer.
So our design goals are: unlinkability with conditional traceability via the server, data integrity and anti-forgery via signatures and stack-based policy verification, and scalability by keeping consensus among RSUs and offloading vehicles.
|
| ICACT20260208 Slide.07
[Big Slide]
|
Chrome Click!! |
.jpg) |
In our framework, RSUs verify messages using lightweight stack scripts, so every node enforces the same rules and can validate requests quickly.
Verification is expressed as opcodes, we use standard opcodes and also define custom opcodes to validate manufacturer certificates and binding certificates between HID and public keys.
|
| ICACT20260208 Slide.08
[Big Slide]
|
Chrome Click!! |
 |
First, when a new vehicle enters the iov environment, generates pseudonym and send registration request to nearby RSU. Then RSU verifies the request in three steps by using stack, and if it is approves, RSU issue a binding certificate and a register tx is recorded on chain.
|
| ICACT20260208 Slide.09
[Big Slide]
|
Chrome Click!! |
 |
After vehicle completes onboarding, it starts participating in federated learning by sending local model updates.
First vehicle sends a submit message to nearby rsu, then validates certificate and message ownership by using stack. If both checks pass, the RSU creates a ModelTx and stores it on-chain.
So this stage keeps verification lightweight at the edge while preserving an auditable on-chain record of model updates
|
| ICACT20260208 Slide.10
[Big Slide]
|
Chrome Click!! |
 |
And the pseudonym is updated at the end of each federated learning epoch to reduce long term linkability while preserving conditional traceability.
First vehicle sends a Change request and the server validates the binding certificate, verifies ownership via signature, checks that the new HID has not been used.
If all checks pass, the server records a changetx.
So, External observers cannot directly link old and new pseudonyms and the server can trace when legitimate investigation is required.
|
| ICACT20260208 Slide.11
[Big Slide]
|
Chrome Click!! |
 |
So this is the part that how we store these records on-chain. Our ledger used two block types with different roles
The first is Identity block. It stores identity-lifecycle transactions, so the system can support conditional traceability when needed. And it is generated at the start of every epoch
The second is the Model block. It stores model-update transactions which creates an auditable history of federated learning contributions over epochs.
By separating identity records from model-update records, we keep the ledger structure clearer and easier to manage.
|
| ICACT20260208 Slide.12
[Big Slide]
|
Chrome Click!! |
 |
And Chained HotStuff is a pipelined BFT protocol where blocks are linked by quorum certificates, and finalization is typically based on a 3-chain QC relation.
However, in IoV-FL, the leader is still on the critical path: collecting votes, forming QCs, and driving each next proposal.
That creates a leader bottleneck and waiting time at replicas.So we need a CHS variant that offloads leader-heavy work and allows more parallel progress
|
| ICACT20260208 Slide.13
[Big Slide]
|
Chrome Click!! |
 |
So we proposed committee based chained hotstuff to remove leader bottleneck and reduce idle time during QC progression.
We devided into 3 roles, leader, committee and replicas,
And each step makes block and it is divided into four stage,
First propose stage. Leader broadcasts the block proposal, and in the vote stage, replicas validate and return signed votes to committee nodes
Then in aggregate nodes, committee collects votes and produces qc and send qc to leader nodes
After receiving qc, leader node makes another block which contains delivered QC.
As a result, committee based chained hotstuff reduces leader side workload concentration, improves consensus latency and throughtput, and provides better scalability
|
| ICACT20260208 Slide.14
[Big Slide]
|
Chrome Click!! |
 |
This is our experimental setup
we compared PBFT, original Chained hotstuff, and committee based chained hotstuff across 25 to 100 nodes
|
| ICACT20260208 Slide.15
[Big Slide]
|
Chrome Click!! |
 |
This figure shows throughput as the number of consensus nodes increases. As expected, throughput declines for all protocols when the network scales, but committee based chained hotstuff declines more slowly.
The main reason is that committee-based aggregation reduces leader-side bottlenecks and keeps the pipeline moving more efficiently under road.
|
| ICACT20260208 Slide.16
[Big Slide]
|
Chrome Click!! |
 |
This figure reports consensus latency as the number of nodes increases. Latency rises for all methods as expected, but committee based hotstuff consistently stays lowest across all tested scales.
This supports our design claim that committee-based aggregation reduces leader-side waiting and improves pipeline efficiency.”
|
| ICACT20260208 Slide.17
[Big Slide]
|
Chrome Click!! |
 |
As the number of nodes increases, throughput drops and latency rises for all protocols.
The key reason that committee based chained hotstuff performs better is workload redistribution. By removing vote collection and aggregation to a committee, we mitigate leader side concentration and reduce QC-related waiting
For IoV federated learning this means more stable consensus under frequent update traffic, but committee internal coordination can still add overhead which we note as a practical limitation.
|
| ICACT20260208 Slide.18
[Big Slide]
|
Chrome Click!! |
 |
To conclude, this work proposes a scalable and secure framework for federated learning in IoV. Our design combines deterministic stack-script verification at RSUs, on-chain HID–public key binding for conditional privacy and traceability, and committee-based Chained HotStuff for scalable consensus.
In evaluation, C-CHS consistently improves both throughput and latency compared with PBFT and original CHS, with larger gains at higher node counts.
A remaining limitation is committee-internal communication overhead.
As future work, we plan to develop a more efficient committee communication mechanism than the gossip protocol and to introduce reputation-based committee election.
|
| ICACT20260208 Slide.19
[Big Slide]
|
Chrome Click!! |
 |
Thank you for listening
|
| ICACT20260208 Slide.20
[Big Slide]
|
Chrome Click!! |
 |
|
