From c4868c9aa63df7fbed9236a55cfb389b96906ba6 Mon Sep 17 00:00:00 2001 From: FrancescoCastaldi Date: Sat, 21 Feb 2026 18:44:11 +0100 Subject: [PATCH 1/2] Fixed README.md --- README.md | 268 ++++++++++++++++++++++++++++++++++++++++++++++++------ 1 file changed, 241 insertions(+), 27 deletions(-) diff --git a/README.md b/README.md index 6662f1c..e15eb79 100644 --- a/README.md +++ b/README.md @@ -1,36 +1,250 @@ +```markdown # HospitalSanitizationTracker -DApp per tracciare le attività di sanificazione in ospedale usando tecnologia blockchain. -Progetto per il corso **Blockchain and Cryptocurrencies** (UniBO). +DApp per la tracciabilità delle attività di sanificazione ospedaliera tramite blockchain. +Progetto per il corso di Blockchain e Criptovalute – Università di Bologna. + +Proposal 7 – DLTs for Traceability in Supply Chain (AnaNSi Research Group) + +--- + +## Descrizione + +Sistema basato su smart contract Ethereum che permette a operatori autorizzati di registrare +e certificare le operazioni di sanificazione di aree ospedaliere. +Ogni evento è registrato in modo immutabile sulla blockchain e può essere consultato in qualsiasi momento. + +--- + +## Tecnologie Utilizzate + +- Solidity 0.8.20 +- Hardhat 2.28.0 +- Ethers.js (frontend) +- Node.js v22 +- Infura (RPC Provider) +- MetaMask (wallet) +- Rete: Ethereum **Sepolia Testnet** + +--- + +## Struttura Progetto + +```text +contracts/ + SanitizationTracker.sol # Smart contract principale + +scripts/ + deploy.js # Script di deploy (versione iniziale) + # Deploy finale effettuato con Hardhat Ignition + +test/ + SanitizationTracker.test.js # Suite di test (14/14 passati) + +frontend/ + index.html # Interfaccia web + app.js # Logica DApp + interazione con il contratto + style.css # Stili base (opzionale) +``` --- -## ROADMAP COMPLETA – Stato attuale +## Smart Contract – Funzionalità + +Il contratto `SanitizationTracker` implementa: + +- Registrazione aree da sanificare: + - `id` numerico univoco + - `name` + - flag `active` e `exists` +- Registrazione operatori autorizzati: + - `wallet` address + - `name` + - flag `active` e `exists` +- Registrazione eventi di sanificazione: + - `areaId` + - `operatorAddress` + - `timestamp` + - `outcome` (es. OK / FAIL) + - `notes` +- Lettura dati: + - `getAreaEvents(areaId)` per lo storico completo + - `getLastSanitization(areaId)` per l’ultimo evento + - `getEventCount(areaId)` per il numero di sanificazioni +- Controlli di accesso: + - `onlyAdmin` → solo l’admin (deployer) può registrare aree e operatori + - `onlyActiveOperator` → solo operatori registrati e attivi possono chiamare `sanitize` +- Eventi on-chain per tracciabilità: + - `AreaRegistered` + - `OperatorRegistered` + - `AreaSanitized` + +--- + +## Stato Avanzamento + +### [COMPLETATO] FASE 1 – Setup Ambiente +- Repository GitHub creato: `HospitalSanitizationTracker` +- Node.js installato (v22.13.1) +- Hardhat inizializzato e configurato (v2.28.0) +- Struttura cartelle progetto creata +- Dipendenze installate (`@nomicfoundation/hardhat-toolbox`, `dotenv`, ecc.) + +### [COMPLETATO] FASE 2 – Smart Contract +- Contratto `SanitizationTracker.sol` sviluppato +- Strutture dati: `Area`, `Operator`, `SanitizationEvent` +- Funzioni principali: + - `registerArea`, `setAreaActive` + - `registerOperator`, `setOperatorActive` + - `sanitize` + - `getAreaEvents`, `getEventCount`, `getLastSanitization` +- Modifiers di sicurezza: + - `onlyAdmin` + - `onlyActiveOperator` +- Eventi on-chain per ogni operazione rilevante +- Compilazione completata senza errori + +### [COMPLETATO] FASE 3 – Test +- Suite di test completa: 14/14 test passati +- Copertura: + - registrazione aree + - registrazione operatori + - registrazione eventi di sanificazione + - controlli di accesso e casi limite +- Compatibilità verificata con Node.js v22 e Hardhat v2.28.0 + +### [COMPLETATO] FASE 4 – Deploy su Testnet +- Rete: **Ethereum Sepolia Testnet** +- Indirizzo contratto: `0x679C6625f9479cf3b711F7a246C8F7a6655E4517` +- Data deploy: 21 Febbraio 2026 +- Verifica utilizzo contratto tramite DApp frontend +- Provider RPC: Infura +- Wallet deployer: account admin (indirizzo usato in `.env`) + +### [COMPLETATO] FASE 5 – Frontend DApp +- Interfaccia web (HTML/CSS/JS) per interazione col contratto +- Integrazione MetaMask per firma transazioni (ruoli admin/operator) +- Visualizzazione stato aree e storico delle sanificazioni per ogni area + +--- + +## Frontend DApp – Funzionalità + +La cartella `frontend/` contiene una DApp semplice ma completa. + +### Ruoli -### [COMPLETATO] FASE 1: Setup iniziale -- [x] Repository GitHub creato: `HospitalSanitizationTracker` -- [x] Node.js installato -- [x] Hardhat inizializzato e configurato -- [x] Struttura cartelle progetto creata +- **Admin** + - è l’account che ha fatto il deploy del contratto; + - può registrare nuove aree; + - può registrare nuovi operatori (indirizzi wallet). +- **Operator** + - è un account registrato dall’admin; + - può registrare eventi di sanificazione. -### [COMPLETATO] FASE 2: Smart Contract -- [x] Smart contract `SanitizationTracker.sol` sviluppato con: - - Strutture dati per aree, operatori ed eventi di sanificazione - - Funzioni principali: registrazione aree, registrazione operatori, registrazione sanificazioni, lettura eventi - - Modifiers per sicurezza: `onlyAdmin`, `onlyActiveOperator` - - Eventi per tracciabilità: `AreaRegistered`, `OperatorRegistered`, `AreaSanitized` -- [x] Compilazione smart contract riuscita -- [x] 14 test unitari creati e superati al 100% -- [x] Deploy su rete locale Hardhat testato +La DApp rileva il ruolo leggendo dal contratto se l’`address` connesso è l’`admin` oppure un `operator` registrato. + +### Sezioni principali (index.html) + +1. **Header** + - Bottone “Connect MetaMask” + - Indirizzo connesso + - Ruolo corrente (`admin`, `operator`, `guest`) + - Select “Desired role: Admin/Operator” con suggerimento dell’account da selezionare in MetaMask + +2. **Register Area (Owner)** + - Form per registrare una nuova area: + - `Area ID` + - `Area Name` + +3. **Register Operator (Owner)** + - Form per registrare un operatore: + - `Operator Address` (wallet del secondo account) + - `Name` + +4. **Record Sanitization (Operator)** + - Form per registrare un evento di sanificazione: + - `Area ID` + - `Outcome` (OK/FAIL) + - `Notes` + +5. **Area Status** + - Input `Area ID` + - Bottone “Get Status” + - Visualizza: + - dati area (id, nome, attiva, esiste) + - ultima sanificazione (timestamp, outcome, operatore) + +6. **Area Events** + - Input `Area ID` + - Bottone “Get Events” + - Mostra lo storico di tutti gli eventi di sanificazione per l’area scelta. + +--- + +## Installazione e Utilizzo + +```bash +# Installa dipendenze +npm install + +# Compila il contratto +npx hardhat compile + +# Esegui i test +npx hardhat test + +# (Opzionale) Deploy su Sepolia con Ignition +npx hardhat ignition deploy ignition/modules/SanitizationTracker.js --network sepolia +``` + +Assicurarsi di avere un file `.env` con: + +```env +INFURA_API_KEY= +PRIVATE_KEY= +``` + +--- + +## Esecuzione Frontend + +1. Portarsi nella cartella del progetto e aprire la sottocartella `frontend/`. +2. Avviare un semplice server statico, ad esempio: + +```bash +npx serve frontend +# oppure usare l'estensione "Live Server" di VS Code +``` + +3. Aprire il browser su `http://localhost:3000` (o la porta indicata). +4. In MetaMask selezionare la rete **Sepolia**. + +### Flusso tipico di test + +1. Connettersi con l’account **admin** (deployer). +2. Registrare almeno: + - un’area (es. ID = 101, Name = "Test 101"); + - un operatore usando l’indirizzo del secondo account MetaMask. +3. Passare al secondo account in MetaMask (operatore) e riconnettere la DApp. +4. Registrare una sanificazione per l’area 101. +5. Verificare lo stato e lo storico tramite le sezioni “Area Status” e “Area Events”. + +--- + +## Contratto Deployato + +| Campo | Valore | +|-------------|------------------------------------------------------------------------------------| +| Rete | Ethereum Sepolia Testnet | +| Indirizzo | `0x679C6625f9479cf3b711F7a246C8F7a6655E4517` | +| Data Deploy | 21 Febbraio 2026 | +| Etherscan | https://sepolia.etherscan.io/address/0x679C6625f9479cf3b711F7a246C8F7a6655E4517 | + +--- -### [COMPLETATO] FASE 3: Account Infura -- [x] Account Infura.io registrato -- [x] Progetto creato -- [x] API Key e RPC URL Sepolia ottenuti +## Autore -### [COMPLETATO] FASE 4: Deploy su Testnet Sepolia -- [x] Ottenuti SepoliaETH gratuiti da faucet -- [x] File `.env` configurato con: - ```env - INFURA_API_KEY= - PRIVATE_KEY= +Francesco Castaldi – Università di Bologna +Corso: Blockchain e Criptovalute +``` \ No newline at end of file From 80f9a9dedb4f61d7e1a0f81e85e7c816e1cbedab Mon Sep 17 00:00:00 2001 From: "Francesco.Castaldi" <85239014+FrancescoCastaldi@users.noreply.github.com> Date: Tue, 26 May 2026 23:48:28 +0200 Subject: [PATCH 2/2] ci: add GitHub Actions workflow + improve README badges and structure --- .env.example | 5 + .github/workflows/ci.yml | 30 ++++ README.md | 351 +++++++++++++++++++-------------------- 3 files changed, 204 insertions(+), 182 deletions(-) create mode 100644 .env.example create mode 100644 .github/workflows/ci.yml diff --git a/.env.example b/.env.example new file mode 100644 index 0000000..666c47f --- /dev/null +++ b/.env.example @@ -0,0 +1,5 @@ +# Infura RPC API Key (https://infura.io) +INFURA_API_KEY=your_infura_api_key_here + +# Private key of the deployer wallet (NO 0x prefix) +PRIVATE_KEY=your_private_key_here diff --git a/.github/workflows/ci.yml b/.github/workflows/ci.yml new file mode 100644 index 0000000..d0cf5fb --- /dev/null +++ b/.github/workflows/ci.yml @@ -0,0 +1,30 @@ +name: CI + +on: + push: + branches: [main] + pull_request: + branches: [main] + +jobs: + test: + name: Hardhat Tests + runs-on: ubuntu-latest + + steps: + - uses: actions/checkout@v4 + + - name: Set up Node.js + uses: actions/setup-node@v4 + with: + node-version: '22' + cache: 'npm' + + - name: Install dependencies + run: npm ci + + - name: Compile contracts + run: npx hardhat compile + + - name: Run tests + run: npx hardhat test diff --git a/README.md b/README.md index e15eb79..f993b63 100644 --- a/README.md +++ b/README.md @@ -1,250 +1,237 @@ -```markdown -# HospitalSanitizationTracker +
-DApp per la tracciabilità delle attività di sanificazione ospedaliera tramite blockchain. -Progetto per il corso di Blockchain e Criptovalute – Università di Bologna. + -Proposal 7 – DLTs for Traceability in Supply Chain (AnaNSi Research Group) +# 🏥 HospitalSanitizationTracker + +**DApp per la tracciabilità delle attività di sanificazione ospedaliera tramite blockchain** + +[![CI](https://github.com/FrancescoCastaldi/HospitalSanitizationTracker/actions/workflows/ci.yml/badge.svg)](https://github.com/FrancescoCastaldi/HospitalSanitizationTracker/actions/workflows/ci.yml) +[![Solidity](https://img.shields.io/badge/Solidity-0.8.20-363636?logo=solidity)](https://soliditylang.org/) +[![Hardhat](https://img.shields.io/badge/Hardhat-2.28.0-f0d20c?logo=javascript)](https://hardhat.org/) +[![Node](https://img.shields.io/badge/Node.js-v22-339933?logo=node.js)](https://nodejs.org/) +[![Network](https://img.shields.io/badge/Network-Sepolia_Testnet-6f3ff5?logo=ethereum)](https://sepolia.etherscan.io/address/0x679C6625f9479cf3b711F7a246C8F7a6655E4517) +[![Tests](https://img.shields.io/badge/Tests-14%2F14_passed-brightgreen?logo=mocha)]() +[![License: MIT](https://img.shields.io/badge/license-MIT-green.svg)](LICENSE) +[![Etherscan](https://img.shields.io/badge/Etherscan-Verified-blue?logo=ethereum)](https://sepolia.etherscan.io/address/0x679C6625f9479cf3b711F7a246C8F7a6655E4517) + +*Progetto per il corso di **Blockchain e Criptovalute** – Università di Bologna* +*Proposal 7 – DLTs for Traceability in Supply Chain (AnaNSi Research Group)* + +
--- -## Descrizione +## Indice -Sistema basato su smart contract Ethereum che permette a operatori autorizzati di registrare -e certificare le operazioni di sanificazione di aree ospedaliere. -Ogni evento è registrato in modo immutabile sulla blockchain e può essere consultato in qualsiasi momento. +1. [Descrizione](#descrizione) +2. [Tecnologie Utilizzate](#tecnologie-utilizzate) +3. [Architettura e Struttura Progetto](#architettura-e-struttura-progetto) +4. [Smart Contract – Funzionalità](#smart-contract--funzionalit%C3%A0) +5. [Frontend DApp – Funzionalità](#frontend-dapp--funzionalit%C3%A0) +6. [Installazione e Utilizzo](#installazione-e-utilizzo) +7. [Contratto Deployato](#contratto-deployato) +8. [Autore](#autore) --- -## Tecnologie Utilizzate +## Descrizione + +Sistema basato su smart contract Ethereum che permette a operatori autorizzati di **registrare e certificare le operazioni di sanificazione** di aree ospedaliere. -- Solidity 0.8.20 -- Hardhat 2.28.0 -- Ethers.js (frontend) -- Node.js v22 -- Infura (RPC Provider) -- MetaMask (wallet) -- Rete: Ethereum **Sepolia Testnet** +Ogni evento è registrato in modo **immutabile sulla blockchain** e può essere consultato in qualsiasi momento, garantendo trasparenza e non-ripudiabilità dei dati. --- -## Struttura Progetto +## Tecnologie Utilizzate -```text -contracts/ - SanitizationTracker.sol # Smart contract principale +| Tecnologia | Versione | Ruolo | +|---|---|---| +| Solidity | 0.8.20 | Linguaggio smart contract | +| Hardhat | 2.28.0 | Framework sviluppo/test/deploy | +| Ethers.js | v6 | Interazione contratto dal frontend | +| Node.js | v22 | Runtime JavaScript | +| Infura | – | RPC Provider (Sepolia) | +| MetaMask | – | Wallet per firma transazioni | +| Ethereum Sepolia | Testnet | Rete di deploy | -scripts/ - deploy.js # Script di deploy (versione iniziale) - # Deploy finale effettuato con Hardhat Ignition +--- -test/ - SanitizationTracker.test.js # Suite di test (14/14 passati) +## Architettura e Struttura Progetto -frontend/ - index.html # Interfaccia web - app.js # Logica DApp + interazione con il contratto - style.css # Stili base (opzionale) +``` +HospitalSanitizationTracker/ +├── .github/ +│ └── workflows/ +│ └── ci.yml # GitHub Actions CI +├── contracts/ +│ └── SanitizationTracker.sol # Smart contract principale +├── scripts/ +│ └── deploy.js # Script di deploy locale +├── ignition/ +│ └── modules/ +│ └── SanitizationTracker.js # Modulo Hardhat Ignition (deploy testnet) +├── test/ +│ └── SanitizationTracker.test.js # Suite di test (14/14) +├── frontend/ +│ ├── index.html # Interfaccia web DApp +│ ├── app.js # Logica DApp + interazione contratto +│ └── style.css # Stili +├── Photos/ +│ └── logo.png +├── artifacts/ # Output compilazione (gitignored) +├── cache/ # Cache Hardhat (gitignored) +├── hardhat.config.js +├── package.json +├── .env.example # Template variabili d'ambiente +└── .gitignore ``` --- ## Smart Contract – Funzionalità -Il contratto `SanitizationTracker` implementa: - -- Registrazione aree da sanificare: - - `id` numerico univoco - - `name` - - flag `active` e `exists` -- Registrazione operatori autorizzati: - - `wallet` address - - `name` - - flag `active` e `exists` -- Registrazione eventi di sanificazione: - - `areaId` - - `operatorAddress` - - `timestamp` - - `outcome` (es. OK / FAIL) - - `notes` -- Lettura dati: - - `getAreaEvents(areaId)` per lo storico completo - - `getLastSanitization(areaId)` per l’ultimo evento - - `getEventCount(areaId)` per il numero di sanificazioni -- Controlli di accesso: - - `onlyAdmin` → solo l’admin (deployer) può registrare aree e operatori - - `onlyActiveOperator` → solo operatori registrati e attivi possono chiamare `sanitize` -- Eventi on-chain per tracciabilità: - - `AreaRegistered` - - `OperatorRegistered` - - `AreaSanitized` +Il contratto `SanitizationTracker.sol` implementa le seguenti funzionalità: ---- +### Strutture Dati + +| Struct | Campi principali | +|---|---| +| `Area` | `id`, `name`, `active`, `exists` | +| `Operator` | `wallet`, `name`, `active`, `exists` | +| `SanitizationEvent` | `areaId`, `operatorAddress`, `timestamp`, `outcome`, `notes` | + +### Funzioni Principali + +| Funzione | Accesso | Descrizione | +|---|---|---| +| `registerArea(id, name)` | `onlyAdmin` | Registra una nuova area | +| `setAreaActive(id, active)` | `onlyAdmin` | Attiva/disattiva un'area | +| `registerOperator(wallet, name)` | `onlyAdmin` | Registra un nuovo operatore | +| `setOperatorActive(wallet, active)` | `onlyAdmin` | Attiva/disattiva un operatore | +| `sanitize(areaId, outcome, notes)` | `onlyActiveOperator` | Registra evento di sanificazione | +| `getAreaEvents(areaId)` | pubblico | Ritorna lo storico completo | +| `getLastSanitization(areaId)` | pubblico | Ritorna l'ultimo evento | +| `getEventCount(areaId)` | pubblico | Ritorna il numero di eventi | + +### Modificatori di Accesso -## Stato Avanzamento - -### [COMPLETATO] FASE 1 – Setup Ambiente -- Repository GitHub creato: `HospitalSanitizationTracker` -- Node.js installato (v22.13.1) -- Hardhat inizializzato e configurato (v2.28.0) -- Struttura cartelle progetto creata -- Dipendenze installate (`@nomicfoundation/hardhat-toolbox`, `dotenv`, ecc.) - -### [COMPLETATO] FASE 2 – Smart Contract -- Contratto `SanitizationTracker.sol` sviluppato -- Strutture dati: `Area`, `Operator`, `SanitizationEvent` -- Funzioni principali: - - `registerArea`, `setAreaActive` - - `registerOperator`, `setOperatorActive` - - `sanitize` - - `getAreaEvents`, `getEventCount`, `getLastSanitization` -- Modifiers di sicurezza: - - `onlyAdmin` - - `onlyActiveOperator` -- Eventi on-chain per ogni operazione rilevante -- Compilazione completata senza errori - -### [COMPLETATO] FASE 3 – Test -- Suite di test completa: 14/14 test passati -- Copertura: - - registrazione aree - - registrazione operatori - - registrazione eventi di sanificazione - - controlli di accesso e casi limite -- Compatibilità verificata con Node.js v22 e Hardhat v2.28.0 - -### [COMPLETATO] FASE 4 – Deploy su Testnet -- Rete: **Ethereum Sepolia Testnet** -- Indirizzo contratto: `0x679C6625f9479cf3b711F7a246C8F7a6655E4517` -- Data deploy: 21 Febbraio 2026 -- Verifica utilizzo contratto tramite DApp frontend -- Provider RPC: Infura -- Wallet deployer: account admin (indirizzo usato in `.env`) - -### [COMPLETATO] FASE 5 – Frontend DApp -- Interfaccia web (HTML/CSS/JS) per interazione col contratto -- Integrazione MetaMask per firma transazioni (ruoli admin/operator) -- Visualizzazione stato aree e storico delle sanificazioni per ogni area +- **`onlyAdmin`** → solo il deployer del contratto +- **`onlyActiveOperator`** → solo operatori registrati e attivi + +### Eventi On-Chain + +- `AreaRegistered(id, name)` +- `OperatorRegistered(wallet, name)` +- `AreaSanitized(areaId, operator, timestamp, outcome)` --- ## Frontend DApp – Funzionalità -La cartella `frontend/` contiene una DApp semplice ma completa. +La cartella `frontend/` contiene una DApp web completa che si connette al contratto tramite MetaMask. ### Ruoli -- **Admin** - - è l’account che ha fatto il deploy del contratto; - - può registrare nuove aree; - - può registrare nuovi operatori (indirizzi wallet). -- **Operator** - - è un account registrato dall’admin; - - può registrare eventi di sanificazione. - -La DApp rileva il ruolo leggendo dal contratto se l’`address` connesso è l’`admin` oppure un `operator` registrato. - -### Sezioni principali (index.html) - -1. **Header** - - Bottone “Connect MetaMask” - - Indirizzo connesso - - Ruolo corrente (`admin`, `operator`, `guest`) - - Select “Desired role: Admin/Operator” con suggerimento dell’account da selezionare in MetaMask - -2. **Register Area (Owner)** - - Form per registrare una nuova area: - - `Area ID` - - `Area Name` - -3. **Register Operator (Owner)** - - Form per registrare un operatore: - - `Operator Address` (wallet del secondo account) - - `Name` - -4. **Record Sanitization (Operator)** - - Form per registrare un evento di sanificazione: - - `Area ID` - - `Outcome` (OK/FAIL) - - `Notes` - -5. **Area Status** - - Input `Area ID` - - Bottone “Get Status” - - Visualizza: - - dati area (id, nome, attiva, esiste) - - ultima sanificazione (timestamp, outcome, operatore) - -6. **Area Events** - - Input `Area ID` - - Bottone “Get Events” - - Mostra lo storico di tutti gli eventi di sanificazione per l’area scelta. +| Ruolo | Descrizione | +|---|---| +| **Admin** | Account deployer; può registrare aree e operatori | +| **Operator** | Account registrato dall'admin; può registrare sanificazioni | +| **Guest** | Account non riconosciuto; accesso in sola lettura | + +> La DApp rileva automaticamente il ruolo leggendo l'`admin` address e la mappa degli `operators` direttamente dal contratto. + +### Sezioni dell'Interfaccia + +| # | Sezione | Ruolo richiesto | Funzione | +|---|---|---|---| +| 1 | **Header** | – | Connessione MetaMask, indirizzo connesso, ruolo rilevato | +| 2 | **Register Area** | Admin | Registra una nuova area (`ID` + `Name`) | +| 3 | **Register Operator** | Admin | Registra un operatore (`Wallet Address` + `Name`) | +| 4 | **Record Sanitization** | Operator | Registra evento (`Area ID`, `Outcome`, `Notes`) | +| 5 | **Area Status** | Tutti | Visualizza dati area + ultima sanificazione | +| 6 | **Area Events** | Tutti | Storico completo eventi per area | --- ## Installazione e Utilizzo +### Prerequisiti + +- Node.js v22+ +- MetaMask installato nel browser +- Account Sepolia con ETH di test ([Sepolia Faucet](https://sepoliafaucet.com/)) + +### Setup + ```bash -# Installa dipendenze +git clone https://github.com/FrancescoCastaldi/HospitalSanitizationTracker.git +cd HospitalSanitizationTracker npm install +cp .env.example .env +# Edita .env con INFURA_API_KEY e PRIVATE_KEY +``` + +### Comandi +```bash # Compila il contratto npx hardhat compile # Esegui i test npx hardhat test -# (Opzionale) Deploy su Sepolia con Ignition +# Deploy su Sepolia (Hardhat Ignition) npx hardhat ignition deploy ignition/modules/SanitizationTracker.js --network sepolia ``` -Assicurarsi di avere un file `.env` con: +### Avvio Frontend -```env -INFURA_API_KEY= -PRIVATE_KEY= +```bash +npx serve frontend +# oppure: estensione "Live Server" di VS Code ``` ---- - -## Esecuzione Frontend +Aprire il browser su `http://localhost:3000` e selezionare la rete **Sepolia** in MetaMask. -1. Portarsi nella cartella del progetto e aprire la sottocartella `frontend/`. -2. Avviare un semplice server statico, ad esempio: +### Flusso Tipico di Utilizzo -```bash -npx serve frontend -# oppure usare l'estensione "Live Server" di VS Code ``` +1. Connetti con account Admin (deployer) + └→ Registra un'area (es. ID=101, Name="Sala Operatoria") + └→ Registra un operatore (wallet del 2° account MetaMask) -3. Aprire il browser su `http://localhost:3000` (o la porta indicata). -4. In MetaMask selezionare la rete **Sepolia**. - -### Flusso tipico di test +2. Cambia account in MetaMask → Operatore + └→ Registra una sanificazione (Area 101, Outcome: OK, Notes: ...) -1. Connettersi con l’account **admin** (deployer). -2. Registrare almeno: - - un’area (es. ID = 101, Name = "Test 101"); - - un operatore usando l’indirizzo del secondo account MetaMask. -3. Passare al secondo account in MetaMask (operatore) e riconnettere la DApp. -4. Registrare una sanificazione per l’area 101. -5. Verificare lo stato e lo storico tramite le sezioni “Area Status” e “Area Events”. +3. Con qualsiasi account + └→ Consulta Area Status e Area Events per verificare lo storico +``` --- ## Contratto Deployato -| Campo | Valore | -|-------------|------------------------------------------------------------------------------------| -| Rete | Ethereum Sepolia Testnet | -| Indirizzo | `0x679C6625f9479cf3b711F7a246C8F7a6655E4517` | -| Data Deploy | 21 Febbraio 2026 | -| Etherscan | https://sepolia.etherscan.io/address/0x679C6625f9479cf3b711F7a246C8F7a6655E4517 | +| Campo | Valore | +|---|---| +| **Rete** | Ethereum Sepolia Testnet | +| **Indirizzo** | [`0x679C6625f9479cf3b711F7a246C8F7a6655E4517`](https://sepolia.etherscan.io/address/0x679C6625f9479cf3b711F7a246C8F7a6655E4517) | +| **Data Deploy** | 21 Febbraio 2026 | +| **Etherscan** | [Visualizza su Sepolia Etherscan](https://sepolia.etherscan.io/address/0x679C6625f9479cf3b711F7a246C8F7a6655E4517) | --- ## Autore -Francesco Castaldi – Università di Bologna -Corso: Blockchain e Criptovalute -``` \ No newline at end of file +**Francesco Castaldi** +Università di Bologna – Corso di Blockchain e Criptovalute + +[![GitHub](https://img.shields.io/badge/GitHub-FrancescoCastaldi-181717?logo=github)](https://github.com/FrancescoCastaldi) + +--- + +
+ +*Progetto sviluppato a scopo accademico* + +