Il problema dell'oracle: perché la blockchain non può leggere il contatore da sola
Una blockchain è un ambiente chiuso — deterministico, isolato, privo di accesso al mondo fisico per costruzione. Ogni nodo della rete deve eseguire lo stesso calcolo e arrivare allo stesso risultato: questo è il meccanismo che garantisce il consenso. Se i contratti potessero leggere liberamente da fonti esterne, due nodi che eseguono lo stesso contratto in momenti diversi otterrebbero dati diversi, e il consenso collasserebbe.
L'oracle è il ponte tra il mondo fisico e la blockchain. Porta dati esterni on-chain firmandoli crittograficamente. Il problema è immediato: se un singolo oracle mente o viene compromesso, il contratto esegue su dati falsi — e sulla blockchain, l'esecuzione è irreversibile.
Per un sistema di certificazione energetica, questo non è un rischio teorico. È la differenza tra una GO che certifica produzione reale e una GO che certifica una dichiarazione.
Chainlink: rete decentralizzata di oracle
Chainlink è la rete oracle più diffusa nell'ecosistema blockchain. La sua architettura affronta il problema del singolo oracle distribuendo l'aggregazione: ogni dato viene fornito da più node operator indipendenti, i quali firmano individualmente il risultato. Il contratto on-chain riceve le risposte multiple e applica un meccanismo di aggregazione (mediana, media pesata, threshold) prima di accettare il valore.
Chainlink CCIP (Cross-Chain Interoperability Protocol) estende questa logica al passaggio di messaggi e dati tra blockchain diverse. Un dato prodotto su Polygon — dove il costo del gas è contenuto — può essere trasmesso su Ethereum mainnet o su qualsiasi altra chain supportata, con garanzie crittografiche sull'integrità del trasferimento.
Per la tokenizzazione energetica, questo significa: il dato del contatore viene registrato su una chain economica per l'operatività quotidiana, e bridgiato su Ethereum mainnet per la liquidità e l'integrazione con protocolli DeFi o piattaforme di trading di certificati.
Architettura in quattro strati
Strato 1 — Hardware fisico
Il punto di partenza è il misuratore. In Italia, la seconda generazione di smart meter AMM (Advanced Metering Management, standard ARERA 646/2017) espone i dati via protocollo DLMS/COSEM su HAN (Home Area Network) o tramite interfaccia ottica. Gli inverter fotovoltaici di fascia industriale (SMA, Fronius, Huawei) espongono API REST o Modbus TCP con granularità oraria o sub-oraria. I sensori ambientali — irraggiamento, temperatura moduli, stato stringhe — completano il quadro.
La qualità del dato dipende dalla qualità dell'installazione. Un contatore AMM mal posizionato, un inverter con firmware obsoleto, un sensore di irraggiamento ombreggiato: ogni anomalia hardware si propaga attraverso tutti gli strati successivi. Il punto di verità è fisico prima che digitale.
Strato 2 — Edge e aggregazione
I dati raw vengono raccolti e normalizzati da un gateway edge locale. Lo standard europeo di riferimento è FIWARE NGSI-LD — sviluppato dalla FIWARE Foundation con supporto EU e adottato da ENTSO-E per le smart grid. NGSI-LD definisce un modello a entità e attributi con semantica standardizzata: un contatore è una entità con attributi (activePower, reactivePower, voltage) espressi in unità fisiche riconosciute da qualsiasi sistema conforme allo standard.
Il gateway FIWARE serve anche da buffer locale: se la connettività verso l'oracle cade, i dati vengono accumulati localmente con timestamp accurato (GPS o NTP) e inviati in batch al ripristino della connessione. Nessun dato viene perso per problemi di rete temporanei.
Strato 3 — Oracle Chainlink
Il Chainlink node configura un job che legge l'endpoint NGSI-LD del gateway FIWARE via HTTPS REST a intervalli regolari (tipicamente ogni 15 o 60 minuti). Il node:
- Legge il valore di produzione cumulata in kWh
- Calcola la produzione dell'intervallo per differenza
- Firma il dato con la propria chiave privata ECDSA
- Invia la transazione firmata al contratto aggregatore su Polygon
Quando più node hanno inviato il dato, il contratto aggregatore calcola la mediana e la fissa come valore ufficiale del periodo. Nessun singolo node può alterare il risultato unilateralmente.
Strato 4 — Smart contract ERC-1155
Il contratto di minting riceve il dato aggregato e verifica che:
- Il valore sia plausibile rispetto al periodo (nessun impianto da 100 kWp produce 500 kWh in un'ora)
- L'impianto sia registrato nel contratto registry (solo impianti verificati possono generare token)
- Il periodo non sia già stato tokenizzato (prevenzione del doppio minting)
Se tutte le verifiche passano, il contratto minta un token ERC-1155 con metadata che includono: coordinate GPS dell'impianto, periodo di produzione, kWh prodotti, hash del dato originale FIWARE, hash della transazione oracle. Il token è trasferibile — rappresenta il diritto a quella produzione certificata.
Proof of Physical Asset: tokenizzare la realtà, non il documento
Il termine tecnico per questo schema è Proof of Physical Asset (PoPA). È la differenza fondamentale tra due approcci alla tokenizzazione:
- Tokenizzare un documento: si prende una GO GSE cartacea, se ne fa un hash, si minta un token che punta a quell'hash. La blockchain certifica che il documento non è stato alterato. Ma non certifica che il documento corrisponda a produzione reale.
- Tokenizzare la produzione: il token nasce dal dato fisico del contatore, firmato dall'oracle prima che qualsiasi documento venga emesso. La corrispondenza tra token e realtà fisica è crittograficamente garantita, non dichiarata.
Per un buyer corporate che usa il token per il Scope 2 market-based CSRD, la distinzione è sostanziale. L'assurance del revisore su una PoPA è significativamente più semplice di quella su un documento GO tradizionale.
Circuit breaker: gestione delle anomalie
Un sistema di minting automatizzato deve gestire i casi anomali senza intervento umano per i casi semplici, con alert immediato per i casi complessi.
Il contratto implementa un circuit breaker parametrizzato: se il dato ricevuto dall'oracle è fuori dai range fisicamente plausibili per l'impianto in quella stagione (irraggiamento nullo a mezzogiorno di luglio, produzione positiva con inverter segnalato offline), il minting viene sospeso automaticamente. Un evento on-chain notifica il sistema di monitoring, che invia alert al tecnico responsabile. La verifica manuale sblocca il circuit breaker o esclude il periodo dalla tokenizzazione.
Il deployment Solaria
Solaria ha implementato questa architettura sugli impianti pilota della rete gestita. Il dato dell'inverter, firmato dall'oracle Chainlink, è registrato on-chain su Polygon entro 15 minuti dalla produzione. Il numero di serie della GO GSE corrispondente — quando emessa dal sistema tradizionale — è linkato alla transazione blockchain, creando un bridge bidirezionale tra il sistema certificativo europeo e il registro on-chain.
Il buyer può verificare la corrispondenza in autonomia su Polygonscan, senza dipendere da una dichiarazione del venditore.
