RN :PES1UG21CS577
S
PBM STMT NO: 5
NAME: SHREYA R
1) A
rchitectural:well-known software patterns: peer-to-peer, layered, pipefilter, and access control; four
architectural views: structural, interactional, transactional, and security patterns
Access controller architecture is used.
eb Interface: This component serves as the user interface through which users interact with the attendance system.
W
It can be accessed by students, faculty, and administrators. The web interface allows users to view attendance
records, submit attendance (for faculty), and perform administrative tasks such as user management.
tudent: Students are the end-users of the system. They can access the web interface to view their attendance
S
records.
aculty: Faculty members are the access controllers in the blockchain network. Faculty members are responsible for
F
taking attendance. They use the web interface to submit attendance records for each class session. The attendance
data submitted by faculty is then added to the blockchain.
lockchain: The blockchain serves as the underlying decentralized ledger for storing attendance records. Each block in
B
the blockchain contains a cryptographic hash of the previous block, creating a chain of blocks. This ensures the
immutability and integrity of the attendance data. In this proof of concept, the blockchain operates on a centralized
flask server. However, in a real-world scenario, it would typically be decentralized, distributed across multiple nodes.
dmin: Administrators have the highest level of access to the system. They manage user accounts, monitor system
A
performance, and potentially handle any disputes or issues related to attendance records.
2) Type of blockchain to be used:
rivate blockchain is preferred. The nodes that are present in the blockchain are the students. The
P
ACN(Access Controller Node) could be most advantageously the faculty member responsible for engaging the
lecture. In such a case the students have a valid reason to trust the ACN to a good extent. If the Faculty node
is found faulty, one of the students can be chosen as ACN. But since it is highly unlikely that the Faculty
member can be malicious and add faulty information to the blockchain, the most likely scenario will be that the
faculty member itself is the ACN. If a new faculty member is to engage in a lecture, his identity is added to the
blockchain, and chosen as ACN. The student nodes, which will act as peer nodes in the network will validate
the entry by the Faculty, based on either QR code validation success/fail, RFID scan success/fail, SRN entry
success/fail for a particular attendance entry of some student.
3) T
he stakeholders involved:
Student, Faculty, Admin(Department Admin Office)
4) Interaction between modules:
odules involved:
M
Student, faculty, blockchain, admin, access control mechanism
ttendance Taking Process:
A
The faculty member logs in to the web interface and initiates the attendance-taking process.
The faculty module generates attendance entries for students present in the class, using appropriate validation
methods such as QR code scanning or RFID scanning.
The ACN validates attendance entries and submits them to the blockchain module.
The blockchain module verifies the validity of attendance entries and adds them to the blockchain ledger.
Students can later log in to the system and view their updated attendance records through the student module.
ole Transition:
R
In case of a faulty faculty member or the need for a new ACN (e.g., due to a change in faculty), the system
allows for the transition of the ACN role.
A new faculty member's identity is added to the blockchain, and they are chosen as the new ACN.
The new ACN then assumes responsibility for initiating the attendance-taking process and ensuring the
accuracy of attendance records.
5) Algorithms involved, pseudocode expected:
Practical Byzantine Fault tolerance algorithm is used for consensus. There is no PoW or PoS. This can be
considered as a PoA scenario.
Psuedocode:
//Consensus algorithm - simplified pbft
Procedure PBFT_Consensus(Block block):
Send Prepare(Message) to all other nodes
Wait for Prepare(Message) from a threshold number of nodes
if received Prepare(Message) from enough nodes then
Send Commit(Message) to all other nodes
Wait for Commit(Message) from a threshold number of nodes
if received Commit(Message) from enough nodes then
Add block to the blockchain
Broadcast BlockAdded(Message) to all nodes
Return true
else
Return false
else
Return false
//Transaction validation based on attendance entry(qr, rfid, srn entry)
Procedure Select_ACN():
if current_faculty_node is_valid() then
return current_faculty_node
else
return previous_student_node
//Blockvalidation
Procedure Validate_Attendance_Entry(Attendance_Entry entry):
if entry is_valid() then
return true
else
return false
Procedure Validate_Block(Block block):
if block.previous_hash is valid and matches the hash of the last block in the blockchain then
for each attendance_entry in block.attendance_entries do
if not Validate_Attendance_Entry(attendance_entry) then
return false
return true
else
return false
