Blockchain project application

IT Minor Credential Management System

Blockchain Technology

Last Name:________________________

First Name: ________________ Date _____

Part I. Overview

You have been appointed Lead Blockchain Engineer on FAMU University's Registrar team. The existing credential system is incomplete: it lacks access control, batch processing, event logging, and expiry enforcement. In this lab, you deploy an upgraded smart contract and work through each of those four systems from scratch. CIS chairperson, by finishing this lab, students will be able to

(a) develop a system that will enable them to issue CIS minor credentials on the blockchain

(b) (Ethereum) (b) implement and test RBAC (role--based access control) on the smart contract

(c) students will be able to read and understand events emitted by the smart contract

The full project stack uses Django, Angular, IPFS, MetaMask, and PostgreSQL. This lab simulates the backend pipeline in Google Colab using Ganache and web3.py.

Concepts covered in this lab:

· Role-Based Access Control (RBAC) — Registrar vs. Verifier accounts

· Batch credential issuance — entire graduating cohort in one transaction

· On-chain event log — querying CredentialIssued events as an audit trail

· Credential expiry — time-based validity enforcement inside the contract

Part II. Lab Environment Setup

Open the provided Google Colab notebook. Run every cell in order . do not skip any cell. Each cell depends on state built by the cells before it.

Google Colab Lab Notebook

Two private keys are required in Cell 3: one for the Registrar (Account 0) and one for the Verifier (Account 1)..

Part III. Tasks

Task 0 — Environment Setup (Cells 1–3)

Learning Outcomes

· Understand the toolchain required to run a local Ethereum development environment inside Google Colab.

· Distinguish between the Registrar and Verifier roles before writing a single line of contract code.

· Practice connecting a Python web3.py client to a locally running Ganache blockchain.

1. Run Cell 1. Wait for the final confirmation before continuing.

What Python packages does Cell 1 install, and why is py-solc-x needed specifically?

2. Run Cell 2 to start Ganache. Note that only 5 accounts are created this time.

Copy the addresses for Account 0 (Registrar) and Account 1 (Verifier) from the output.

3. Run Cell 3. Paste both private keys when prompted.

Screenshot the Cell 3 output showing both labeled addresses and their ETH balances.

[ Paste screenshot / copy output here ]

Why does this lab require two separate private keys instead of one? What is the security principle behind separating these roles?

Task 1 — Smart Contract (Cell 4)

In this task you are expected to read and interpret the smart contract //what the task will do

Learning Outcomes

· Read and interpret a Solidity smart contract that implements role-based access control, batch operations, event emission, and expiry logic.

· Understand how Solidity modifiers enforce access rules at the function level before any business logic executes.

· Connect the contract's data structures to real-world credentialing requirements such as audit trails and time-limited validity.

Read Cell 4 carefully before answering. Do not run it yet.

4. Locate the RBAC section in the contract source.

What are the two modifiers defined in the contract? Copy their names and write one sentence explaining what each one does.

5. Find the batchIssue() function.

The function starts with a require() that checks four array lengths. Why is this check necessary? What would happen without it?

6. Find the CredentialIssued event definition.

List all five fields emitted by this event and explain what each field tells an auditor.

Event Field	What it tells an auditor

7. Find the verifyCredential() function.

The function checks four conditions before returning (true, 'credential is valid'). List them in the order they appear in the code.

Task 2 — Compile, Deploy, and Grant Roles (Cell 5)

We want to deploy the blockchain using the contract using py-solc-x and web3.py

Learning Outcomes

· Compile a Solidity contract from Python using py-solc-x and deploy it to a local chain via web3.py.

· Understand how the constructor initializes on-chain state and why the deployer account automatically receives elevated permissions.

· Trace the full deployment flow from Python function call to confirm on-chain transaction receipt.

8. Run Cell 5.

Screenshot the output showing the deployed contract address and the confirmation that the Verifier role was granted.

[ Paste screenshot / copy output here ]

The last two print statements check verifiers(registrar.address) and verifiers(verifier.address). Both return True. Why does the Registrar automatically count as a Verifier even though they are a different role?

Task 3 — Batch Enrollment (Cells 6–7)

Here we want to enroll multiple students at once and issue thier credentials on the blockchain

Learning Outcomes

· See how a single blockchain transaction can replace multiple sequential transactions, reducing cost and latency for large graduating cohorts.

· Understand how credential data is canonicalized, hashed, encrypted, and stored locally before the hash is committed on-chain.

· Observe how different expiry windows are assigned at enrollment time and stored as Unix timestamps inside the contract.

9. Run Cells 6 and 7.

Screenshot the full output of Cell 7, showing both batch_enroll() calls and the transaction hashes.

[ Paste screenshot / copy output here ]

How many blockchain transactions were used to enroll all 6 students? How many would the old one-student-at-a-time approach have required? What is the practical benefit of batching?

10. Look at Frank Junior's enrollment call in Cell 7.

Frank was enrolled with expiry='2y' while the other five received '5y'. What does the expiry_timestamp() function return for each, and where does that value end up in the smart contract?

In the batch_enroll() function, credentials are encrypted before being stored locally. What Python library handles this encryption, and what key management problem would arise in a real production deployment?

Task 4 — Reading the On-Chain Event Log (Cell 8)

Here we want students to be able to query and read logs emitted by the smart contract

Learning Outcomes

· Query and interpret on-chain events emitted by a smart contract, understanding why they serve as a permanent, tamper-proof audit trail.

· Recognize the difference between mutable contract state (which can be deleted via revocation) and immutable event logs (which cannot).

· Apply event filtering techniques to narrow an audit query to a specific time range or set of credentials.

11. Run Cell 8.

Screenshot the full audit log table printed by Cell 8.

[ Paste screenshot / copy output here ]

How many CredentialIssued events appear in the log? Does this number match the number of students enrolled? Explain any difference.

The code prints a warning: 'These events are immutable. Even revoked credentials remain in the log.' Why is this property valuable for an academic credentialing system? Give a concrete example.

A university administrator suspects a credential was issued on a specific date. Explain how you would modify the get_logs() call to filter events by block range rather than querying from block 0.

Task 5 — Role-Based Access Control Tests (Cell 9)

Here we want to test the RBAC mechanism

Learning Outcomes

· Verify empirically that the onlyRegistrar and onlyVerifier modifiers enforce access boundaries as designed.

· Understand the principle of least privilege: each account can only perform the minimum operations its role requires.

· Observe what on-chain error messages look like when a transaction is rejected by a modifier.

12. Run Cell 9 and observe all three test results.

Screenshot the Cell 9 output showing the result of all three RBAC tests.

[ Paste screenshot / copy output here ]

Fill in the table below based on what you observed:

Test	Who calls	Function called	Result (pass/reject)
RBAC Test A	Authorized Verifier	verifyCredential()
RBAC Test B	Stranger (Account 2)	verifyCredential()
RBAC Test C	Authorized Verifier	issueCredential()

Test C shows that even an authorized Verifier cannot issue credentials. What does this tell you about the principle of least privilege, and why is it important in a credentialing system?

Task 6 — Credential Expiry (Cell 10)

Learning Outcomes

· Understand how Unix timestamps are used inside a smart contract to enforce time-based validity without relying on any external clock.

· Observe the difference between a credential that is legitimately still active and one whose validity window has already closed.

· Think critically about when expiry is a sound security policy and how it should be designed to avoid locking out legitimate graduates.

13. Run Cell 10 and observe both parts.

Screenshot the Cell 10 output showing Frank's result (Part A) and the ghost student's result (Part B).

[ Paste screenshot / copy output here ]

Part A — Frank's 2-year credential is not yet expired. What exact expiry date does the output show for him? How was that date calculated?

Part B — The ghost student's credential was issued successfully on-chain but immediately fails verification. Write the exact reason string returned by verifyCredential() for the ghost student.

A hiring manager argues: 'If the credential was legitimately issued, why should it expire?' Write a counter-argument explaining why time-limited credentials are a sound security policy for academic institutions.

How would you modify the contract so that the Registrar can extend a credential's expiry without revoking and re-issuing it? Describe the new function you would add (no need to write Solidity — plain English is fine).

Task 7 — Audit Dashboard (Cell 11)

In this Task students will be expected to verify all the logs / events emitted by the smart contract

Learning Outcomes

· Combine on-chain state reads and event log queries to build a unified view of the credentialing system's current status.

· Understand what information is available from contract storage versus what is only available from the event log.

14. Run Cell 11.

Screenshot the complete dashboard table printed by Cell 11.

[ Paste screenshot / copy output here ]

The dashboard calls credentialCount() for each student. What does this function return, and what does it tell you that the event log alone cannot?

In the real Angular frontend, this dashboard would update in real time as new credentials are issued. Describe how web3.js event subscriptions could be used to keep the dashboard live without polling.

Task 8 — Your Turn (Cell 12)

In this task we want to try to issue a student credential with our own information , this will enable the student to understand the full system lifecycle of the credential issuance ,verification and revocation process

Learning Outcomes

· Apply every concept from the lab — batch enrollment, event filtering, revocation, and role management — to your own data independently.

· Practice reading and extending existing Python blockchain code rather than following a pre-written script step by step.

· Understand the full lifecycle of a credential: issuance, verification, revocation, and access removal, as the Registrar.

Complete all four steps in Cell 12. Each step is graded separately.

15. Step 1 — Enroll your own cohort.

Screenshot the batch_enroll() output for your cohort, showing your student IDs and the transaction hash.

[ Paste screenshot / copy output here ]

16. Step 2 — Filter the event log for your students only.

Screenshot the filtered event output showing only your cohort's CredentialIssued events.

[ Paste screenshot / copy output here ]

How did you identify which events belong to your students? Describe the filtering logic you used.

17. Step 3 — Revoke one credential.

Which student did you revoke, and what was the verifyCredential() reason string after revocation?

The revocation transaction is recorded on-chain, but so is the original issuance event. What does this dual record mean for an auditor trying to understand the full history of a credential?

18. Step 4 — Remove the Verifier role.

Screenshot the output showing the Verifier being rejected after role removal.

[ Paste screenshot / copy output here ]

After removing the Verifier, the verifiers mapping returns False for that address. But the VerifierRemoved event is still in the log. Why does this matter for accountability?

Part IV. Questions & Answers

Answer in complete sentences. Each question relates directly to something you observed in the lab.

Q1. The contract stores credentials in a mapping(bytes32 => Credential[]) — an array per student rather than a single record. What new capability does this array structure unlock that a single-record mapping cannot support?

Q2. batchIssue() executes a for-loop inside a single Ethereum transaction. What is the risk of making this batch too large, and how would you decide on a safe maximum batch size for a production deployment?

Q3. In this lab the Registrar account's private key is pasted directly into the Colab notebook. Explain why this approach would be unacceptable in a live production system and describe a safer alternative used in real Django/MetaMask integrations.

Q4. The verifyCredential() function is marked onlyVerifier. What happens when the Angular frontend calls this function — does it go through the Django backend, or can it call the contract directly? Explain the flow.

Q5. The audit log is built from on-chain events, not from the PostgreSQL database. Describe one scenario where the on-chain log and the PostgreSQL database could become out of sync, and explain how you would detect and resolve it.

Q6. Identify one security weakness introduced by the credential expiry mechanism as currently implemented and propose a concrete improvement.

Security Weakness	Proposed Improvement

Q7 : Gas Calculation

Learning Outcomes

· Measure and analyze the relationship between batch size and gas consumption, developing an intuition for how to optimize transaction costs in production.

· Understand the block gas limit as a hard constraint on how large a single batchIssue() call can be.

Run batchIssue() with cohorts of different sizes: 1 student, 3 students, 6 students, 10 students. Record the gas used for each call.

Fill in the table and answer: is gas usage linear with cohort size? What does this imply for choosing a batch size in production?

Cohort Size	Gas Used	Gas per Student	Notes
1
3
6
10

End of Lab — FAMU