# Analisi indexing smart contracts DAE

## Introduzione

Nelle ultime settimane ho approfondito la documentazione di The Graph.
Non avendolo mai utilizzato in un progetto in fase di produzione ma solo su progetti eseguiti in locale mi sono posto il problema di valutare se esso possa essere effettivamente utilizzato per il nostro caso d'uso o se è meglio virare su altri metodi.
In questo documento vorrei descrivere i pro e i contro che ho trovato in The Graph dopo alcuni test eseguiti questo weekend per poi procedere nel migliore dei modi con le prossime fasi implementative della web app.

## Caching dei dati degli smart contract a database

Il caching dei dati degli smart contract è necessario quando si sviluppa un'applicazione Web3 perchè permette di salvare in un database tradizionale (PostgreSQL, MySQL, ecc) i dati contenuti negli smart contract e poterli richiedere senza saturare gli RPC endpoint.
Senza un database tradizionale diventa difficile eseguire query su dati relazionati tra di loro (es. tutti i corsi a cui è iscritto uno studente).

## Cos'è The Graph e a cosa serve?

The Graph è un protocollo utilizzato nel mondo Web3 per l'indicizzazione automatica dei dati contenuti negli smart contract.
E' sostanzialmete un server (nodo) che rimane in ascolto tramite un RPC endpoint sulla produzione di nuovi blocchi in una chain e, tramite gli eventi emessi nelle transazioni ivi contenute, effettua il caching a database.
Le regole che definiscono come e quali dati cachare sono definite in dei file chiamati subgraph che possono essere programmati a piacimento.
Ho preso in considerazione The Graph tra le altre soluzioni perchè l'ho utilizzato in passato e funziona bene, permette di fruire dei dati a frontend tramite GraphQL e ne velocizza lo sviluppo di parecchio, è open source, è decentralizzato (nelle prossime sezioni approfondisco questo aspetto) ed utilizzato da molti servizi Web3.

## In che modo si può utilizzare The Graph

Esistono 3 modi in cui si può beneficiare delle caratteristiche di The Graph

1. Utilizzare Hosted Service
2. Utilizzare Subgraph Studio (rete decentralizzata)
3. Eseguire un proprio nodo The Graph

### 1. Utilizzare Hosted Service

Hosted Service è un servizio fornito dagli sviluppatori del protocollo per fare il deploy dei propri subgraph in dei nodi che gestiscono loro. E' gratuito e le query al subgraph illimitate.
Troppo bello per non avere la fregatura...piano piano il servizio verrà dismesso a favore della rete decentralizzata (Subgraph Studio). La migrazione è graduale e consiste nello spostare le chain sulle quali è possibile andare a indicizzare i dati tramite subgraph da un servizio all'altro (Ethereum non è già più disponibile anche se molte altre ancora lo sono).
Sul sito indica Q1 2023 il termine di migrazione completa quindi non farei affidamento su questo servizio.

### 2. Subgraph Studio (rete decentralizzata)

Subgraph Studio è un servizio gestito sempre dagli sviluppatori di The Graph per fare il deploy dei subgraph sulla rete decentralizzata.
La faccio breve. Analogamente alle blockchain tradizionali esiste una catena di nodi che, tramite un protocollo chiamato Proof of Indexing, indicizza i dati degli smart contract in modo distribuito. La rete è gia ben avviata e ha 200 validatori.
Questo pone due problemi oltre a diversi benefici come alta reperibilità dei dati e tempo di ricezione delle risposta delle query elevate.

I due problemi principali sono:
1. Incentivo per far indicizzare i propri subgraph dai validatori
2. Costo delle query

#### 1. Incentivo

I validatori non lavorano a gratis e vogliono indicizzare solo dei subgraph di buona qualità quindi esistono dei "curators" che segnalano i subgraph di buona qualità depositando GRT (The Graph Token).
I curators prendono parte delle fee degli indexer e ricevono penalità se scelgono subgraph di scarsa qualità (vedi [The Graph Curating](https://thegraph.com/docs/en/network/curating/))
C'è scritto nei docs che è consigliabile fare lo stake di almeno 10000 GRT (ad oggi 1600$) che noi dovremmo effettuare pena la non indicizzazione dei dati. Non è un vero e proprio costo perchè si può fare l'unstake ma il rischio è sostanzialmente legato al token.

#### 2. Costo delle query

Ogni query fatta da frontend ha un costo, abbastanza irrorio (media 0.0004$ query) e si può cachare i dati delle query sul server della nostra web app per ridurle al minimo ma è comunque un costo da valutare.
Ognuno può decidere di richiedere un API key e pagare per ottenere i dati dal sottografo, nel caso voglia realizzare una propria app.

### 3. Self Hosted Node

Questo weekend mi sono concentrato sul seguente metodo conoscendo i costi del precedente.
Ho provato a lanciare un istanza condivisa da circa $20/mese su Linode che ha 2 CPU e 4GB di RAM, a lanciare un [graph-node](https://github.com/graphprotocol/graph-node) e a deployare il nostro subgraph. Indicizza senza problemi. Non ho fatto un load test ma l'istanza usava risorse minime e comunque si può eventualmente scalare con il tempo.
Il problema è l'RPC endpoint che si satura. In pratica il nodo, per ogni blocco, fa le richiesta all'endpoint per i dati di tutte le transazioni che ci sono, che sono tra le 100 e le 200 a blocco minimo.
Ho usato la versione free di Alchemy che ha il billing calcolato a CU (Compute Unit), quindi anche eseguedo tutte le transazioni in batch si sfora comunque. Infatti, anche se le richieste vengono in questo modo ridotte lo stesso utilizzano tanta potenza computazionale per essere eseguite. Facendo un due conti neanche con i piani a pagamento se ne viene fuori ad un prezzo ragionevole.
Altri servizi stile Alchemy comunque non hanno piani abbordabili. Quindi escludo di farci un indexer da noi perchè richiederebbe di runnare un full node di Ethereum e ci spingiamo troppo oltre.

### 4. Soluzione alternativa

Una soluzione possibile che si può prendere in considerazione è la seguente ma è un po' macchinosa e poco flessibile.
In pratica, si potrebbe far passare ogni transazione Web3 firmata a frontend (creazione di un corso, minting delle credentials,...) per un api endpoint sul nostro server che trasmette la transazione alla rete e fa il caching delle informazioni in essa contenute.

(voglio creare un corso) => (firmo la transazione) => (invio transazione firmata a /api/new-course) => (i dati arrivano al server che invia transazione su Eth e fa il cache dei dati a database)

Il problema è che è un po' più lunga e complessa l'implementazione e se vengono effettuate operazioni web3 al di fuori della web app quest'ultima non può saperlo e quindi sono da gestire questi casi. Quindi dipende quanto questa cosa ci crei problemi.

## Visione personale

Le scelte che possiamo attuare sono sostanzialmente la 2 e la 4.
La 4 potrebbe essere applicata per prima se non crea problemi il fatto che qualcuno possa eseguire operazioni Web3 al di fuori dell'app.
La 2 è più interessante perchè, oltre a risolvere diversi problemi implementativi, è decentralizzata.
Utilizzando quest'ultima si darebbe la possibilità a tutti un domani di crearsi la propria piattaforma di elearning (scuole, università, aziende ecc...) e di personalizzarla in base alle proprie esigenze semplicemente clonando la repository della web app, facendo le modifiche di cui necessitano e gestendosi autonomamente i corsi e i costi.