Internet computer wiki

Chiamate HTTPS

Chiamate HTTPS

Sulla blockchain ICP i canister smart contract possono eseguire chiamate HTTPS esterne alla blockchain verso URL specifici, sia per ottenere dati off-chain che per interagire con sistemi off-chain, ad esempio servizi Web 2.0 o infrastrutture IT tradizionali. I risultati di queste chiamate sono processati ed accettati dal “consensus” prevenendo il non-determinismo. Questo elimina il bisogno di terze parti “trusted” come oracoli o bridges.

Spesso, gli smart contract hanno bisogno di ottenere dati dal mondo reale, che vengono generati fuori dall’universo sicuro e inarrestabile che è la blockchain, oppure di interagire con sistemi off-chain. A causa del funzionamento standard di una blockchain, storicamente, queste interazioni hanno creato molti ostacoli agli sviluppatori. Tradizionalmente per ottenere dati off-chain, gli smart contract interagiscono con servizi centralizzati chiamati oracoli come Chainlink. Questi servizi vengono forniti da intermediari fidati (aziende) che si occupano di copiare i dati off-chain nella blockchain in modo che gli smart contracts possano accedervi. I problemi con questi servizi sono:

  • bisogna essere sicuri della loro onestà e non devono essere hackerati
  • devono essere pagati

Oltretutto non sono d’aiuto quando uno smart contract ha bisogno di interagire con servizi off-chain, per esempio quando devono chiamare una APIs web-based.
Per risolvere questi limiti, ICP fornisce una feature detta “HTTPS outcall”.

Le chiamate esterne HTTPS permettono ai canister smart contract ospitati su ICP di richiedere un URL, per esempio per scaricare un registro degli ultimi prezzi di un asset listato su un exchange centralizzato come Coinbase Pro.

Quando questo avviene, ogni nodo nella subnet blockchain che ospita lo smart contracts, richiede l’URL separatamente. Ogni nodo poi localmente passa il risultato ottenuto ad una funzione speciale (implementata dal canister richiedente) utilizzando una query call, la quale “pre-processa” il risultato con l’obiettivo di renderlo coerente con quello che gli altri nodi hanno ottenuto e “pre-processato” (nell’esempio con coinbase, siccome ogni nodo richiede il registro prezzi in momenti leggermente diversi, i risultati potrebbero differire)

 

Se i risultati pre-processati , ottenuti dalle query calls ai canisters, sono sufficientemente coerenti fra tutti i nodi, il risultato è concordato dal “consensus” e restituito allo smart contract che ha richiesto l’URL, il quale può continuare a processare in maniera “trustless” l’originale chiamata smart contract (TX).

 

Per poter innescare un’azione in un sistema off-chain, nella sua richiesta per un URL, uno smart contract può includere una firma chain key crittografata. Questo permette al servizio target di validare la richiesta in quanto proveniente da una genuina esecuzione di uno smart contract concordata dal consensus. In queste architetture, quando un servizio off-chain riceve una valida richiesta per un URL, deve pensare solo ad eseguirla una volta , visto che molti nodi faranno la stessa richiesta e per ognuna oltre la prima, il servizio restituirà lo stesso identico risultato.

Architettura

La capacità di un canister di effettuare chiamate esterne HTTPS, è stata implementata come estensione dello stack del protocollo ICP, in particolare del suo layer di consenso. La possibilità di accogliere le estensioni mostra la forza dell’architettura di ICP e del suo protocollo di consenso. In questa sezione daremo dettagli sull’architettura di questa feature: mostreremo quali componenti dello “stack” devono essere estesi e quali nuovi componenti sono necessari e spiegheremo il flusso del protocollo attraverso lo stack.

Chiamate HTTPS - request lifecycle

HTTPS Outcall Request Lifecycle

La figura in alto mostra il processo di una richiesta HTTPS outcall anche attraverso i nuovi componenti aggiunti per far funzionare questa feature. Le frecce numerate indicano i seguenti passaggi:

 

  1. Un canister effettua una richiesta per una HTTPS outcall al canister gestore a livello esecutivo. La richiesta viene salvata nello stato replicato della subnet corrispondente.
  1. Un nuovo componente nel consensus layer chiamato “HTTP pool manager “ legge i cambi di stato e tiene traccia delle richieste HTTPS in uscita.
  1. Ogni volta che l’HTTP pool manager vede una nuova richiesta, la inoltra al networking layer, ad un nuovo componente chiamato “ HTTP adapter shim”. Questo è un componente relativamente semplice che si occupa di comunicare con l’ HTTP adapter, il quale è un processo separato in esecuzione insieme al processo “replica” ma isolato per ragioni di sicurezza

 

  1. L’ “HTTP adapter shim” inoltra la richiesta all’ adattatore HTTP utilizzando RPC
  1. L’adattatore HTTP di ogni nodo emette la richiesta HTTPS al server remoto
  1. Una risposta viene restituita dal server remoto ad ogni adattatore HTTP
  1. Ogni adattatore HTTP restituisce la risposta al componente “HTTP adapter shim”.
  1. “HTTP adapter shim” invoca una funzione opzionale sul canister che effettua la chiamata. Lo scopo di questa funzione è spiegato in dettaglio più avanti, ma in breve, essa si occupa di fare in modo che tutte le risposte siano uguali così la subnet può raggiungere il consensus.

 

  1. L’ “HTTP adapter shim” inoltra la risposta trasformata all’ HTTP pool manager
  1. Il consensus layer a quel punto distribuisce parti della risposta a tutti i nodi così chi ha creato il blocco può verificare che un numero sufficiente di nodi abbia ricevuto la sua identica risposta.

 

  1. Colui che ha creato il blocco a quel punto include la risposta in un blocco.
  1. La risposta è resa disponibile al layer esecutivo.
  1. Viene invocata una funzione callback per restituire la risposta al canister in

modo asincrono.

Come raggiungere il consensus su un risultato?

Come menzionato prima, ogni nodo effettua una richiesta HTTP al server target e riceve una risposta. Ci sono varie ragioni per le quali una risposta non è necessariamente la stessa su tutte le “replica” per una stessa query API:

  • Una tipica implementazione di web server aggiunge elementi variabili a contenuti altrimenti identici come timestamps o identificatori univoci. In questo caso, il contenuto attuale (ad esempio il prezzo di un asset) può essere uguale in ogni risposta mentre questi campi variabili differiscono.
  • Non tutte le API sono implementate in modo che siano facilmente interrogabili e restituiscano lo stesso dato in ogni risposta, ad esempio una API di dati finanziari può restituire gli elementi in diverso ordine in ogni risposta o può avere differenti timestamps iniziali.

Per permettere alle “replica” di accordarsi su una singola risposta, come parte del consensus, le diverse risposte devono essere uguali . Per avere questa proprietà, ogni “replica” invoca una funzione di trasformazione sulla risposta ricevuta e continua a processare ogni risposta trasformata. La risposta trasformata è usata per tentare di raggiungere il consensus, come detto prima: trasmettendo inizialmente un artefatto corrispondente alla risposta trasformata con la quale una “replica” può osservare se la risposta data ha un sufficiente numero di risposte trasformate uguali.

 

Adesso vedremo alcuni esempi di come può essere raggiunto il consensus per una risposta HTTP ed illustreremo i differenti casi con un esempio di una semplice API meteo.

Tutte le risposte sono uguali

Il caso più semplice è quello in cui le risposte ricevute dalle “replicas” sono uguali.

In questo caso, non è necessaria la funzione di trasformazione perché le risposte sono già uguali ed il consenso può essere raggiunto per esse.

Alcune risposte non sono uguali

Mettiamo il caso che meno di un terzo delle risposte possono essere arbitrariamente diverse dalle altre e che il resto siano uguali. Le risposte differenti possono essere il risultato del server che risponde in modo diverso o che i nodi siano compromessi e che falsifichino la risposta (corretta) ricevuta. Questo caso è gestito esattamente come sopra, senza richiedere la funzione di trasformazione e con il protocollo di consenso ICP che si occupa delle risposte devianti e che si accoda alla maggioranza dei “replicas”.

Parti variabili in tutte le risposte

Il caso più comune è quello in quale ogni risposta restituita dal server HTTP è differente per i motivi menzionati sopra. Questo caso richiede una funziona di trasformazione per “normalizzare” le risposte per essere uguali (per almeno ⅔ delle “replicas”). Le risposte trasformate possono essere approvate dal protocollo come nel casi precedenti. Ovviamente meno di ⅓ delle risposte può essere ancora differente (come nel caso precedente) consentendo comunque il consensus.

Come si può notare, tutti i casi sopra menzionati possono essere gestiti con una estensione del protocollo di consenso ICP.

La cosa importante è che lo sviluppatore dei canister ha bisogno di fornire la funzione di trasformazione se necessario (il tipico caso di utilizzo di un API). Rimandiamo il lettore alla documentazione sulle funzionalità per avere una linea guida per scrivere una funzione di trasformazione ed altre informazioni per aiutare gli sviluppatori ad approcciarsi a questa funzionalità.