ChainLink

Chainlink (originariamente scritto ChainLink) è una piattaforma di oracoli blockchain che comprende reti di oracoli decentralizzate. Queste reti forniscono dati e risultati di calcolo tra blockchain e sistemi esterni, consentendo agli smart contract di utilizzare informazioni che non sono disponibili nel proprio stato blockchain. Il progetto è stato introdotto da SmartContract.com, la società ora conosciuta come Chainlink Labs.

Un oracolo non rende di per sé un fatto esterno parte del consenso di una blockchain. Fornisce invece un input che il contratto è stato programmato per accettare. La progettazione di Chainlink tenta di ridurre la dipendenza da un singolo oracolo combinando più operatori di nodi e, ove appropriato, più origini dati.

Storia

Sergey Nazarov e Steve Ellis hanno fondato SmartContract.com nel 2014 per connettere dati esterni e blockchain pubbliche. Ellis, Nazarov e l'informatico della Cornell Ari Juels hanno pubblicato il primo white paper di Chainlink nel settembre 2017. Descriveva i contratti on-chain per la selezione dei nodi Oracle, il reporting dei dati e l'aggregazione dei risultati, insieme al software off-chain gestito dagli operatori Oracle.

Il progetto ha creato una fornitura fissa di un miliardo di LINK. Nella vendita di token del settembre 2017, la società ha venduto 350 milioni di LINK per circa 32 milioni di dollari; altri 350 milioni sono stati riservati agli operatori dei nodi e agli incentivi ecosistemici, e 300 milioni sono stati destinati alla società. Queste allocazioni descrivono la distribuzione iniziale, non il numero di token in circolazione in una data successiva.

La rete Chainlink è stata lanciata su Ethereum a maggio 2019 con un feed di prezzo ETH/USD. Il suo ambito si è successivamente ampliato oltre i feed di dati di mercato ad altri servizi Oracle e alla comunicazione cross-chain. Un secondo white paper, pubblicato nel 2021, ha usato il termine più ampio rete di oracoli decentralizzata per gruppi di nodi in grado di fornire dati e calcoli off-chain ai cosiddetti smart contract ibridi.

Chainlink è stato adattato anche ad ambienti non Ethereum. Nel 2020, il progetto Polkadot dimostrò una prima integrazione di Chainlink con una blockchain basata su Substrate. Tale esperimento non significa che Chainlink sia una parachain nativa di Polkadot.

Architettura

Le blockchain normalmente richiedono che ogni nodo di convalida ottenga lo stesso risultato da una transazione. Un contratto quindi non può effettuare direttamente una richiesta web arbitraria e rimanere deterministico. Un sistema oracolare supera questo confine ottenendo informazioni off-chain e pubblicando un risultato che un contratto on-chain può leggere.

Nel progetto originale di Chainlink, un contratto richiedente specifica i requisiti per un lavoro Oracle. I contratti on-chain aiutano a selezionare gli operatori dei nodi, a ricevere i loro report e ad aggregare le risposte. I nodi fuori catena ottengono i dati richiesti, li formattano e inviano risultati firmati. Distribuzioni diverse possono utilizzare set di nodi, origini dati, regole di aggregazione e condizioni di aggiornamento diversi, quindi "Chainlink" non denota un modello di fiducia uniforme per ogni feed o servizio.

I progetti successivi di Chainlink utilizzano il reporting off-chain, in cui un gruppo di nodi comunica off-chain e invia un report aggregato on-chain. Ciò riduce il numero di transazioni on-chain mantenendo i contributi firmati che possono essere controllati secondo il protocollo.

Servizi

La piattaforma è stata utilizzata per diversi tipi correlati di servizi Oracle:

• Feed di dati pubblicare valori come i dati di riferimento dei prezzi degli asset affinché i contratti possano leggerli.
• Servizi di richiesta e risposta restituire dati o calcoli richiesti da un'applicazione.
• Automazione consente di richiamare le funzioni del contratto registrato quando vengono soddisfatte le condizioni configurate.
• Casualità verificabile fornisce risultati accompagnati da prova crittografica per applicazioni che richiedono risultati imprevedibili.
• Messaggistica incrociata trasporta messaggi e istruzioni di trasferimento di token tra le reti blockchain supportate.

Questi servizi condividono marchio e infrastruttura ma hanno protocolli, configurazioni dei nodi e presupposti di sicurezza distinti. La disponibilità su una catena o per un feed di dati non implica che ogni servizio Chainlink sia disponibile su ogni rete.

Protocollo di interoperabilità cross-chain

Il Cross-Chain Interoperability Protocol (CCIP) di Chainlink supporta messaggi, trasferimenti di token o messaggi combinati con trasferimenti di token tra reti supportate. Le connessioni sono organizzate in corsie direzionali; il supporto di una rete non implica che siano disponibili tutti gli asset o i percorsi. Il CCIP è entrato in accesso anticipato sulla mainnet il 17 luglio 2023 su Avalanche, Ethereum, Optimism e Polygon.

I pool di token attuano il meccanismo di trasferimento specifico per ciascun asset: i token possono essere bloccati o bruciati sulla chain di origine e rilasciati o coniati su quella di destinazione. Il trasferimento dipende quindi dai pool pertinenti e dai permessi del token, anziché spostare fisicamente un token tra blockchain. I messaggi vengono elaborati in modo asincrono: all’invio sulla chain di origine seguono la verifica e l’esecuzione sulla destinazione. L’accettazione sulla chain di origine non dimostra di per sé che l’applicazione di destinazione abbia completato l’operazione.

CCIP 2.0

Chainlink ha annunciato CCIP 2.0 il 28 settembre 2026. L’annuncio ha introdotto i Cross-Chain Verifier (CCV) configurabili, inclusa la verifica gestita dall’emittente o da terzi, l’esecuzione Faster-Than-Finality attivabile su base facoltativa e i controlli di policy definiti dall’emittente tramite l’Automated Compliance Engine (ACE). Sono opzioni di configurazione, non prove che ogni asset supportato utilizzi verifiche aggiuntive o che un trasferimento soddisfi un particolare requisito legale. Resoconti indipendenti hanno confermato il rilascio e distinto gli utenti CCIP esistenti da chi ha adottato le nuove funzionalità.

La documentazione indica come predefiniti la finalità completa della chain di origine, il Chainlink Committee Verifier e l’executor Chainlink. Le integrazioni esistenti non adottano automaticamente le nuove funzioni facoltative.

Usi nella tokenizzazione

CCIP è stato testato come livello di interoperabilità per asset finanziari tokenizzati e i relativi dati. Nel 2023, Swift ha riferito di esperimenti per collegare la propria infrastruttura alle blockchain, inclusa la rete di test Sepolia di Ethereum, utilizzando Chainlink e CCIP. A maggio 2024, DTCC ha riferito del progetto pilota Smart NAV con dieci partecipanti di mercato, che utilizzava CCIP per distribuire dati sul valore patrimoniale netto dei fondi comuni tra ambienti blockchain. Si è trattato di un progetto pilota per la distribuzione di dati, non di un resoconto di trasferimenti effettivi di fondi. Questi progetti mostrano usi sperimentali; non dimostrano un’adozione o un impiego commerciale generalizzato di CCIP 2.0.

Token LINK

LINK è un token Ethereum compatibile con ERC-20 utilizzato in alcune parti del sistema Chainlink. Il white paper originale descrive pagamenti dai contratti richiedenti agli operatori dei nodi e depositi di garanzia volti a scoraggiare comportamenti scorretti. Anche i design successivi utilizzano LINK nei meccanismi di staking. Il ruolo del token dipende dal servizio e dalla versione del protocollo; detenere LINK non attribuisce all’utente la proprietà di dati esterni né garantisce la correttezza della risposta di un oracolo.

Considerazioni su fiducia e sicurezza

Decentralizzare un oracolo può ridurre il rischio che un operatore fallisca o invii un valore falso, ma non può stabilire che una fonte esterna sia accurata. Un contratto può comunque fallire perché le sue origini dati sono sbagliate o manipolate, vengono utilizzati troppo pochi nodi indipendenti, le regole di aggregazione non sono adatte, gli aggiornamenti vengono ritardati o il contratto utilizzatore gestisce un report valido in modo errato.

Gli utenti Oracle devono quindi valutare la fonte dei dati, la diversità dei nodi e delle fonti, la politica di aggiornamento, il metodo di aggregazione, gli indirizzi dei contratti e il comportamento in caso di guasto dell'esatto servizio che utilizzano. Il codice del contratto intelligente e la configurazione di Oracle sono limiti di sicurezza separati.

Presupposti di sicurezza del CCIP

Come documentato a ottobre 2026, il Committee Verifier predefinito di CCIP 2.0 utilizza una rete di 16 operatori e richiede almeno nove attestazioni firmate. I requisiti effettivi dei verificatori dipendono dalla configurazione della corsia, del pool di token, del destinatario e del mittente. Le impostazioni predefinite della corsia fungono da valori di ripiego, mentre i verificatori imposti dalla corsia sono sempre obbligatori. L’esecuzione sulla destinazione richiede tutti i verificatori obbligatori e la soglia configurata di quelli facoltativi. Un CCV aggiuntivo fornisce un controllo obbligatorio solo quando lo richiede la configurazione applicabile; inoltre, l’indisponibilità di un’attestazione obbligatoria può ritardare l’esecuzione. La descrizione del comitato predefinito non va quindi considerata un quadro completo del modello di fiducia di ogni integrazione personalizzata.

La finalità completa della chain di origine resta l’impostazione predefinita. Faster-Than-Finality è facoltativo e consente l’esecuzione con meno conferme, accettando una maggiore esposizione alle riorganizzazioni della chain di origine. A seconda del meccanismo di trasferimento, le conseguenze documentate possono includere esecuzioni duplicate, token non coperti, inflazione dell’offerta o perdita di fondi.

Contano anche le distinzioni tra versioni. L’architettura CCIP 2.0 mantiene un contratto RMN on-chain e un proxy per gli arresti di emergenza: le operazioni interessate vengono annullate quando il soggetto pertinente è contrassegnato come “cursed”. Questa salvaguardia è distinta dalla rete Risk Management Network off-chain descritta per le versioni precedenti di CCIP.

L’amministrazione dei token, i permessi dei pool, i verificatori personalizzati e il codice dell’applicazione ricevente introducono ulteriori dipendenze. La guida per gli emittenti di token afferma che i pool personalizzati non rientrano negli audit di Chainlink e richiedono una revisione indipendente. Le modifiche alla configurazione gestita da CCIP utilizzano un processo multisignature e un timelock basato sui ruoli, con un ritardo per revisione e veto oppure un percorso con quorum esplicito per le modifiche urgenti; non si può presumere un ritardo obbligatorio per ogni modifica. La documentazione del protocollo e gli audit precedenti non dimostrano la sicurezza di una specifica configurazione o applicazione distribuita.

Collegamenti esterni

• Official website
• Chainlink software repository
• Developer documentation