Questo studio non ha coinvolto partecipanti umani, soggetti umani, soggetti animali o campioni clinici. Pertanto, non era richiesta l'approvazione etica istituzionale e il consenso informato.
Materiali e software
L'ambiente utilizzato per distribuire il framework era Hyperledger Fabric versione 2.4.8, CouchDB, Docker Containers, distribuzione Minifab, applicazioni di elaborazione multimediale FFmpeg e il linguaggio di programmazione Go. Hyperledger Fabric forniva servizi per la gestione decentralizzata del registro e l'esecuzione degli smart contract, mentre CouchDB memorizzava e recuperava le informazioni sul copyright in modo efficiente tramite archiviazione off-chain. FFmpeg veniva utilizzato per la pre-elaborazione dei video e l'estrazione dei fotogrammi video, mentre gli algoritmi di hashing percettivo venivano applicati tramite librerie di hashing delle immagini nel linguaggio di programmazione Go. Un elenco di tutti gli strumenti e le rispettive descrizioni è illustrato nella Tabella dei Materiali.
Architettura del framework
Il framework proposto impiega algoritmi di hashing percettivo all'interno del blockchain autorizzato Hyperledger Fabric per consentire un approccio decentralizzato alla protezione del copyright video e alla validazione della proprietà. Il framework è composto da cinque componenti principali: preprocessing video, generazione percettiva di hash, registrazione del copyright basata su blockchain e verifica basata sulla similarità. In questo contesto, Hyperledger Fabric funge da livello di trust, fornendo record di proprietà immutabili, mentre CouchDB fornisce uno storage off-chain. L'architettura complessiva del framework proposto è raffigurata nella Figura 1.
Modello del sistema per la verifica del copyright
Un flusso di lavoro dettagliato del sistema in esame è mostrato nella Figura 2. Inizia con l'acquisizione video, seguita dall'estrazione dei fotogrammi a intervalli regolari usando FFmpeg. I frame estratti vengono elaborati all'interno dell'ambiente di implementazione Hyperledger Fabric, che include azioni come la registrazione della proprietà, l'amministrazione dei certificati, la comunicazione tra peer e la validazione delle transazioni. L'hashing percettivo viene applicato ai frame estratti, seguito dal calcolo della distanza di Hamming per valutare il grado di somiglianza. Se la distanza di Hamming è inferiore alla soglia, il frame è considerato autentico e simile al contenuto registrato; altrimenti, viene trattato come contenuto modificato.
Acquisizione video, preprocessing e creazione di hashing percettivo
I campioni video utilizzati nell'esperimento erano file MP4 a risoluzione 480p, con una durata media di circa 26 secondi. Il dataset di valutazione comprendeva 15 campioni video, inclusi un video di riferimento originale e diverse versioni modificate. Queste modifiche includevano compiti di editing comuni come modificare i frame rate, inserire, cancellare o sostituire i fotogrammi, e applicare distorsioni come ritagliare, scalare, rotazione ed effetti di sovrapposizione. Il dataset includeva anche compressione, rumore, testo e aggiunte di adesivi, effetti glitch e altro ancora. Tutti i video erano in formato MP4 a risoluzione 480p e subivano gli stessi passaggi di pre-elaborazione e generazione delle impronte digitali. Progettato per testare la resilienza del sistema, questo dataset copre una vasta gamma di scenari reali che coinvolgono violazione e manipolazione. Prima di essere soggetti al rilevamento e alla conferma del copyright, i file video venivano sottoposti a pre-elaborazione in FFmpeg. I fotogrammi dai file video venivano estratti a intervalli di 1 secondo per ottenere riassunti di contenuto condensati sotto forma di contenuti visivi che rimanevano computazionalmente poco costosi da elaborare. Successivamente, questi fotogrammi venivano convertiti in scala di grigi e normalizzati per minimizzare le variazioni di intensità dei pixel dovute alle condizioni di illuminazione, alle differenze di codifica e compressione.
Quattro funzioni di hashing percettivo sono state utilizzate per produrre impronte digitali di contenuti video sotto forma di hashing medio (aHash), hashing differenziale (dHash), hashing percettivo (pHash) e hashing wavelet (wHash).
Per la generazione di hash, i frame venivano prima convertiti in scala di grigi e ridimensionati a 8x8 pixel per calcolare aHash e dHash. Con aHash, veniva generata un'impronta digitale a 64 bit confrontando ogni pixel con il valore medio della scala di grigi. L'algoritmo dHash ha fatto qualcosa di simile, creando anch'esso un'impronta digitale a 64 bit, ma ha osservato come differissero le intensità dei pixel orizzontali adiacenti. Per pHash, i fotogrammi venivano ridimensionati a 32x32 pixel, quindi veniva calcolata la trasformata discreta del coseno. Per generare l'impronta percettiva a 64 bit, sono stati utilizzati solo i coefficienti DCT a bassa frequenza 8x8. Per quanto riguarda wHash, i fotogrammi sono stati nuovamente ridimensionati a 32x32 pixel, ma questa volta sono stati elaborati con una trasformata wavelet di Haar. Un hash a 64 bit veniva generato a partire dai coefficienti delle wavelet a frequenza più bassa estratti. Tutte queste impostazioni dei parametri mirano a un buon equilibrio tra efficienza computazionale e forza per gestire le tipiche modifiche video.
Per eseguire calcoli efficienti delle funzioni hash, queste immagini venivano normalizzate e ridimensionate. Il metodo di hashing medio funziona confrontando l'intensità dei pixel con quella della media dell'immagine. L'hashing delle differenze funziona in modo simile ma si concentra sui gradienti locali confrontando l'intensità dei pixel con quella dei pixel vicini. L'hashing percettivo utilizza le caratteristiche di Fourier che derivano dalla DCT, mentre l'hashing wavelet si basa sui risultati della trasformata wavelet per estrarre le caratteristiche.
Registrazione e verifica del copyright basate su blockchain
Le impronte percettive, i metadati di proprietà, i timestamp e i dettagli delle transazioni ottenuti vengono inseriti nella blockchain Hyperledger Fabric tramite lo smart contract vitChain. L'implementazione della blockchain include due organizzazioni, due peer, due nodi ordinati, due nodi autorità di certificazione (CA) e database di stato CouchDB, tutti collegati tramite un autocanale. Il framework blockchain autorizzato facilita l'elaborazione sicura, l'accesso limitato e la conservazione a prova di manomissione dei dati del copyright.
La procedura di registrazione del copyright inizia una volta che il proprietario del contenuto carica il video tramite l'interfaccia utente. Quando un utente invia un video per la registrazione del copyright, il livello applicativo chiama lo smart contract vitChain tramite l'Hyperledger Fabric SDK. Questa registrazione include un ID transazione unico, informazioni sul proprietario, ID video, timestamp e quattro tipi di valori hash percettivi: aHash, dHash, pHash e wHash. Inoltre, ci sono i metadati sui contenuti. L'app invia la proposta di transazione ai peer che lo approvano. Questi pari gestiscono quindi la logica degli smart contract e garantiscono che la transazione sia conforme alla politica di endorsement. Dopo la validazione riuscita, la transazione passa al servizio di ordinazione. Qui, le transazioni verificate vengono raggruppate in blocchi e inviate ai nodi peer per essere incluse nel registro. Nel frattempo, i metadati correlati vengono inseriti in CouchDB. Si collegano ai record della blockchain tramite l'ID della transazione, consentendo semplici ricerche e mantenendo coerenti sia i dati on-chain che off-chain.
Dopo la preelaborazione e i calcoli di hash percettivo, le impronte digitali, insieme ai metadati associati, vengono assemblate in una transazione da eseguire dallo smart contract. La validazione delle transazioni viene effettuata dai pari partecipanti in conformità con la politica di approvazione specificata. Al momento dell'approvazione, la transazione viene passata al servizio ordinatore per essere inclusa in un blocco sul registro distribuito. Per un funzionamento affidabile, abbiamo incluso la gestione degli errori di base nei processi di registrazione e verifica. Prima che avvenga una transazione, l'app controlla i metadati obbligatori, le informazioni sulla proprietà e gli hash percettivi per evitare problemi. Se le transazioni non rispettano le regole di endorsement o hanno parametri non validi, i nodi peer le rifiutano categoricamente. Quando si verificano problemi come fallimenti di comunicazione o errori di elaborazione, il sistema li registra e invia un avviso amministrativo. Questo aiuta a prevenire piccoli errori di elaborazione che si propaghino nel sistema. Durante i controlli del copyright, i video contenenti metadati non validi o valori hash corrotti sono esclusi dal processo di verifica. Anche i video per i quali la generazione delle impronte digitali fallisce sono esclusi dal processo di verifica. Nel complesso, questi passaggi mantengono i dati puliti e rafforzano l'affidabilità del framework. Le informazioni sulla proprietà del video protetto da copyright diventano immutabili e sono disponibili per un recupero successivo.
Verifica
Il processo di verifica prevede passaggi simili di preprocessing e calcolo delle impronte digitali, seguiti da un confronto delle impronte digitali con le impronte digitali memorizzate nella blockchain, utilizzando una misura di somiglianza basata sulla distanza di Hamming. In base alla misura di somiglianza, lo smart contract determina le informazioni sul copyright del video inviato. Il flusso di lavoro di interazione è rappresentato nella Figura 3.
Verifica del copyright basata sulla similarità
Il processo di verifica del copyright confronta le impronte digitali percettive derivate dal video di interrogazione con quelle precedentemente archiviate nel sistema blockchain. Lo stesso processo di preelaborazione e generazione di hash value utilizzato durante la registrazione viene ripetuto nella fase di verifica per mantenere la coerenza. La somiglianza viene misurata usando la distanza di Hamming, che conta il numero di differenze di bit tra due valori hash. Distanze Hamming più piccole indicano una maggiore somiglianza tra i due video, mentre distanze Hamming maggiori indicano manipolazione dei contenuti. Per verificare se il video di query corrispondeva a quello registrato, abbiamo usato la distanza di Hamming tra i loro valori hash percettivi. Sulla base di esperimenti preliminari, è stata selezionata una soglia di distanza Hamming di 20 per fornire un equilibrio adeguato tra la robustezza alle operazioni di elaborazione video comuni e la sensibilità alle modifiche non autorizzate. I video con una distanza di Hamming di 20 o meno erano considerati rappresentanti lo stesso contenuto protetto da copyright. Se fosse di più, mostrerebbe grandi cambiamenti. Questo 20 è stato scelto per gestire i montaggi video comuni come compressione, filtraggio, transcodifica e variazioni di frame rate, ma rileva comunque modifiche non autorizzate. Vengono effettuate misurazioni di somiglianza per tutte le impronte digitali raccolte, poi aggregate per produrre una conclusione di verifica del copyright. I video che si discostano dai contenuti registrati vengono segnalati per ulteriori controlli.
Ambiente di distribuzione
L'ambiente del banco di prova è stato creato utilizzando container Docker e lo strumento di orchestrazione Minifab. Una rete blockchain basata su Hyperledger Fabric versione 2.4.8 è stata implementata con CouchDB come database di stato e livello di archiviazione per i dati degli smart contract. Lo smart contract vitChain è stato implementato in Go e distribuito utilizzando il ciclo di vita del chaincode Hyperledger Fabric. I parametri di distribuzione sono riassunti nella Tabella 2. La rete era composta da due organizzazioni partecipanti, ovvero il Content Creator e il Videographer. Per garantire l'integrità delle transazioni e prevenire registrazioni o modifiche non autorizzate del copyright, è stata implementata una politica di endorsement multi-organizzazione, che richiedeva l'approvazione di entrambe le organizzazioni prima che una transazione potesse essere messa nel registro contabile. In particolare, la politica di endorsement seguiva una regola AND, espressa come AND ('ContentCreatorMSP.peer', 'VideographerMSP.peer').