Project about PASOX and PBFT in distributed systems, lot of questions asked like what if we would change TCP in place of UDP in PASOX – here was my version as pure Indian Cinema person – I remembered it in this way, panch parmeshwar appointed for a decision send by client.py, now separate routes given to them by docker and kubernets them so they will work on different sockets and work in different compartment/seats, jaise sanjeev kumar ne sholay mein jhoota test kiya tha viru aur jai ka aisa toxiproxy jhoothe delays karte rahte hain, abhi panchhon ladne nahin lage isliye hamesha election hota rahta hai, jab tak senior member apne ko neta declare nahin karta hai, agar senior member ko kuch ho jaye to next senior elected leader ho jata hai, agar network fail ho jaye to crash ke barabar hi hai, phir bhi senior member track karta rahta hai ki mera proposal top per hai ya nahin, agar hai to thik nahin to chuchap bechara apni gaddi chod deta hai, ab isme kuch badmash hai jo jhothi afwahein phailate rahte hai PBFT, adversary message bhej ke, ab chuki digitally mathematically signed seal ke saath RSA signature ke saath wala hi message accept hota hai afwahaon ke liye to wo reject ho jata hai aur heartbeat chalta rahta hai, lekin agar leader crash ho jaye PASOX to bhir se election shuru ho jata hai, Abhi PASOX mein message Gabbar chod diya uski parwah nahin karta hai ki pahuncha ya kya hua, lekin sabhay tarike se bheje to handshake graceful exit hota hai then PASOX mein bhi TCP use kar sakte hain. Abhi gabbar ke members paanch hi hain to Bully algorithm kaam kar jayega, lekin agar Jyada ho jaaye to Raft ya Google Chubby use kar sakte hain. Wanted Bhai shikar karne jaaye aur unko late ho jaaye to message pahunchta nahin hai, then Uday Bhai declared himself as leader, saare log soochte hain Uday ko follow karen ya Wanted Bhai ko, isko split brain kahte hain. Ye saare conecpt hain PASOX or PBFT mein.
Agar ye hindi mein samajh mein nahin aaya to, computer ke language mein nichhe hai. Above is only for Hindi people who want to understand PASOX and PBFT in their language.
Resilient State Machine Replication using Paxos and PBFT
Fundamentals of Distributed Systems
This project implements a resilient distributed state machine replication system capable of tolerating both crash faults and Byzantine faults. The system maintains a replicated append-only transaction ledger across a cluster of five distributed nodes.
Two operational modes are supported:
Mode A – Crash Fault Tolerance
Leader Election + Paxos Consensus
Mode B – Byzantine Fault Tolerance
PBFT Consensus with Digital Signatures
The system is implemented entirely in Python and deployed using Docker Compose.
2. System Architecture
The architecture consists of:
• Five consensus nodes
• One adversary node
• One client application
• Docker networking infrastructure
• Cryptographic key management module
Architecture Diagram:
Client
↓
Leader / Primary Node
↓
Consensus Layer
↓
Replicated Ledger
↓
Persistent Storage
All nodes maintain a local copy of the transaction ledger.
3. Process Coordination Strategy
3.1 Leader Election
The Bully Algorithm is used for leader election.
Each node periodically exchanges heartbeat messages.
If a node does not receive a heartbeat within the configured timeout period:
1. It assumes the leader has failed.
2. It initiates an election.
3. Higher-ID nodes participate.
4. The highest active node becomes leader.
This mechanism prevents split-brain situations and enables automatic recovery after
node failures.
3.2 Heartbeat Monitoring
The elected leader periodically broadcasts:
HEARTBEAT
messages to all peers.
Follower nodes maintain timestamps of the most recent heartbeat.
Failure detection is based on heartbeat expiration.
4. Paxos Implementation
4.1 Overview
Mode A uses Basic Paxos for crash fault tolerance.
The elected leader acts as the Paxos Proposer.
Each transaction passes through four phases:
1. Prepare
2. Promise
3. Accept
4. Accepted
After a majority quorum is reached, the transaction is committed.
4.2 Paxos Workflow
Client Transaction
↓
PREPARE
↓
PROMISE
↓
ACCEPT
↓
ACCEPTED
↓
COMMIT
↓
Ledger Update
4.3 Fault Tolerance
The system continues to operate despite failure of up to two nodes.
Consensus is achieved using majority voting.
5. PBFT Implementation
5.1 Overview
Mode B overrides Paxos and uses Practical Byzantine Fault Tolerance.
The elected leader acts as the PBFT Primary.
PBFT protects the system against malicious behavior and message forgery.
5.2 PBFT Phases
Each transaction proceeds through:
1. PRE-PREPARE
2. PREPARE
3. COMMIT
After sufficient quorum is achieved:
Transaction → Committed
5.3 PBFT Workflow
Client Transaction
↓
Primary
↓
PRE-PREPARE
↓
PREPARE
↓
COMMIT
↓
Ledger Update
6. Cryptographic Key Distribution
6.1 Key Generation
Each node generates:
• RSA Private Key
• RSA Public Key
using the Python cryptography library.
6.2 Message Signing
PBFT messages are digitally signed before transmission.
The sender signs:
• Sequence Number
• Payload
• Message Type
using its private key.
6.3 Verification
Receiving nodes verify:
• Sender identity
• Message authenticity
• Signature integrity
before processing messages.
This prevents spoofing and unauthorized message injection.
7. Byzantine Adversary Design
A dedicated adversary node was implemented.
The adversary intentionally:
• Sends invalid PREPARE messages
• Sends forged COMMIT messages
• Uses invalid signatures
Example:
Sender = 999
Signature = FAKE_SIGNATURE
Honest nodes reject these messages during signature verification.
8. Docker Deployment
The complete system is deployed using Docker Compose.
Components:
• Node 1
• Node 2
• Node 3
• Node 4
• Node 5
• Adversary Node
• Toxiproxy Network Simulator
Each service runs within an isolated Docker container.
9. Chaos Testing
Network failures and crashes were simulated.
Scenarios tested:
Test 1
Leader Crash
Expected Result:
Automatic leader re-election.
Observed Result:
New leader successfully elected.
Test 2
Continued Transaction Processing
Expected Result:
Consensus continues after leader failure.
Observed Result:
Transactions committed successfully.
Test 3
Byzantine Attack
Expected Result:
Invalid messages rejected.
Observed Result:
Nodes detected invalid sender and signature.
10. Experimental Results
Scenario A – Normal Operation
Result:
All nodes successfully committed transactions.
Consensus latency remained low.
Scenario B – Leader Failure
Result:
Heartbeat timeout detected.
Election completed successfully.
Consensus resumed with new leader.
Scenario C – Byzantine Attack
Result:
Malicious messages were rejected.
Ledger consistency preserved.
11. Challenges Faced
1. Integration of leader election with consensus protocols.
2. Handling asynchronous message delivery.
3. Preventing duplicate PBFT commits.
4. Managing cryptographic key distribution.
5. Simulating realistic fault conditions.
12. Conclusion
A resilient distributed consensus engine was successfully designed and implemented.
The system demonstrates:
• Stable leader election
• Crash fault tolerance using Paxos
• Byzantine fault tolerance using PBFT
• Cryptographic authentication
• Fault recovery through chaos testing
The implementation satisfies the requirements of resilient state machine replication
under both crash and Byzantine failure models.
