DIECI DOMANDE SULLA BLOCKCHAIN

Intervista al team di Takamaka, capitanato dall’ing. Giovanni Antino che risponde ad alcune domande sul progetto.

In un’ampia panoramica vengono affrontate questioni relative alla tecnologia, chiarendo anche le differenze con altre e più blasonate blockchain ed evidenziandone differenze ma anche punti di forza.

Sicurezza, oracoli, programmabilità e sviluppi futuri, se vuoi conoscere Takamaka, intervista da leggere per capire e conoscere il progetto e la sua direzione.

1) Mi par di aver inteso che si tratta di una blockchain completamente nuova a sé stante. Non e’ un fork o un layer2 di block chain esistenti.

Si tratta di una blockchain interamente costruita da zero, sfrutta l’algoritmo Proof-of-Stake (PoS)

2) Piu’ veloce di Ethereum ed economico ma cosa ne pensi rispetto a Algorand o blockchain derivate da Cosmos (e.g. Terra)?

La velocità della blockchain Takamaka è vincolata alle risorse hardware rese disponibili dai nodi, quindi l’effetto rete ( inteso come performance e scalabilità ) la fanno l’hardware. Algorand ha introdotto il Pure Pos ( PPOS ) delegando ai possessori dei token ( e allo staking ) la sicurezza della rete e al protocollo ASA la gestione di token diversi da quello nativo. TERRA invece è un progetto ampio e complesso non solo SC, derivati e Stablecoin, ma molto di piu’. COSMOS ( Atom ), rende le blockchain interoperabili, grazie ai substrati TENDERMINT e Cosmos SDK, ottimizzano performance e sicurezza.

Takamaka è (diventerà) un ecosistema programmabile, in cui elaborare SC, fare transazioni ed integrare le funzioni con IoT e portare nuove soluzioni. Si tratta di un progetto complesso, a metà strada tra le performance di ALGORAND e la programmabilità di TERRA, una blockchain sicura e monolitica, ma che per il momento non prevede l’interoperabilità con altre soluzioni.

3) Gli smart contract sono sviluppati in Java. E’ corretto il parallelo :Ethereum usa solidity e i contratti girando nella E(thereum)VM e nel caso di Takamaka si una Java e pertanto la Java virtual machine?

SI.  Takamaka è un framework Java per la scrittura di contratti intelligenti, i programmatori possono utilizzare Java per scrivere codice che può essere installato ed eseguito su blockchain.

4) Ci sono 2 Token, Il verde che ho interpretato essere un token di governance ma anche utilizzabile per le transazioni. Il reward dalle operazioni di staking e’ il green token. Ma il rosso? Lo Staking è pagato sia con token rosso TKR che con Token Verde TKG. Se ho ben capito e’come il verde eccetto per: 1) essere una stablecoin 2) non e’generato come reward dello staking.

SI Corretto.

a. Come si garantisce la stabilita’ di TKR? Non e’un una stable coin “algoritmica” come il DAI ad esempio.. giusto? Allora e’ come Theter? AiLiA fa da garante?

TKR è una stablecoin tipo Tether. Il totale dei TKR è stato emesso al blocco zero, chi acquista TKR, versa ad AiliA SA, denaro corrente ed in cambio riceve TKR. Il denaro è depositato presso la banca BPS e garantisce il valore della stablecoin emessa. Recentemente Takamaka ha ottenuto la “Financial Services Standards Association (VQF)”, che certifica che l’azienda rispetta le normative antiriciclaggio e che la TKR, stablecoin di Takamaka, dal valore 1:1: con l’USD, è ufficialmente in conformità con il regolatore svizzero ed è a tutti gli effetti moneta digitale!

b. il white paper riporta “determinismo” nella determinazione dei fee… immagino che questo valga solo con TKR. TKG e’un token “standard” ed e’soggetto a fluttuazioni. Quindi e’ l’utente che decide se tollerare fluttuazioni o meno dei fee e scegliere il token da usare.

Il sistema determina le fee in modo agnostico dal token (le calcola in TK) poi sta all’utente scegliere con cosa pagarle. Se sul wallet sono presenti TKR il sistema provvede al pagamento esclusivamente in TKR. Se i TKR non fossero sufficienti il sistema pagherà prima con i TKR e il restante con i TKG altrimenti solo in TKG. Il determinismo si riferisce al calcolo dei costi delle transazioni. Per quelle base l’unico criterio valutato è il numero di byte. Il caricamento di un hash, che la lunghezza fissa costa sempre circa 0,07 TK(G/R). Da questo segue che il costo di esecuzione è calcolabile a priori. Permettendo di pianificare un budget basato sul carico di lavoro. Per gli smart contract il discorso è analogo solo che va considerato anche il consumo di memoria RAM e i cicli di CPU. In questo caso il determinismo è conseguenza del modo in cui sono state programmate le funzioni. In fine resta lo scoglio del costo del token rispetto al cambio. Mentre il TKG non è controllabile il TKR ha un valore fissato. Essendo la catena: (byte della transazioni) → (TK) → (TKG) La prima transazione è deterministica, la seconda conversione è costante da questo segue il costo predicibile. In fase di costruzione si sono volutamente rimossi tutti i parametri di cambio costo legati al workload del network.

c. Se ho ben intenso TKG non e’ scambiabile con TKR? Quindi per fare “cassa” lo devo vendere su DEX

In questo momento il TKG può essere scambiato solo sull’exchange LATOKEN, non sono attualmente previsti DEX che accettano lo scambio di TKG, causa la sua PoS. Non si esclude che in un prossimo futuro potrà essere proposto da Takamaka, un DEX, per cambiare i token nativi Takamaka, con TKG

5) Problema di sicurezza nella gestione degli smart contract. Java e’ turing complete. Come ci si pone nelle transazioni “finanziare”? che non richiedono codice complesso (no loop?!). E’ corretto dire che sono previsti due tipi di contratti per ovviare al problema

La blockchain Takamaka è strutturata su 2 livelli, quello attualmente in produzione non è turing completo. In pratica è costituito da un preset di operazioni a costo costante che coprono:

● lo scambio dei token nativi (TKG, TKR)
● la configurazione dello staking
● la registrazione di dati

Dalle analisi fatte in fase di progettazione abbiamo estratto questo subset minimo. Tutte le funzioni sopra descritte sono critiche dal punto di vista della sicurezza, di uso comune e costose a livello di occupazione di spazio e strutture dati. Con questa scelta abbiamo limitato la quantità massima di risorse richieste per ogni operazione ponendo effettivamente un tetto alla complessità dell’esecuzione. Senza questo accorgimento non sarebbe possibile garantire il throughput riportato nelle specifiche. Come giustamente notato, la drastica riduzione della complessità operazionale a livello base permette di implementare controlli molto stringenti, di utilizzare il parallelismo di calcolo e di garantire un alto livello di sicurezza. Una conseguenza negativa della garanzia di throughput è la necessità di limitare il tempo di esecuzione. Se prendiamo un programma turing completo questo, generalmente, non è possibile. Per evitare che contratti complessi vengano scartati a causa della cadenza di rilascio dei blocchi si è deciso di innestare il layer turing completo su un livello differente rimuovendo questi vincoli.

Grazie a questa scelta le operazioni base sono veloci e a costo predicibile mentre gli smart contract non sono soggetti a limitazioni di natura meramente tecnologica. Per rispondere alla sua domanda sì, la blockchain lavora su due livelli, uno sincrono e cadenzato che gestisce le operazioni bulk e uno asincrono (rispetto al rilascio di blocchi) che si fa carico della complessità operazionale dei programmi completi.

6) Come viene garantita la “qualita’’ delle info dagli oracoli (es. piu’ oracoli interrogati per uno smart contract?) dal punto di vista del codice si usa “requests” library in python.

Come sa la blockchain di base non può chiedere informazioni al mondo. Si tratta di un sistema chiuso e autoreferenziale. Questa non è una limitazione dell’implementazione ma è una caratteristica intrinseca di questi sistemi. Se io ammettessi la lettura di informazioni esterne legherei la correttezza dell’esecuzione alla disponibilità e integrità di una fonte esterna. Se questa venisse a mancare, in un determinato momento del tempo, la correttezza transazionale non sarebbe più verificabile indipendentemente da ogni nodo. Ovviamente chiunque può scrivere e implementare un oracolo in base alle proprie necessità quello che possiamo fare noi è fornire un esempio e delle linee guida implementative per creare un processo di immissione di dati il più possibile attendibile.

Porto ora un esempio relativo ad un problema concreto delle applicazioni finanziarie, i tassi di cambio. Alla fine gli stessi principi possono essere applicati a qualsiasi sorgente di dati. Identificare una fonte sicura ed affidabile, condivisibile da tutti gli utilizzatori dell’oracolo. Nel nostro caso https://sdw-wsrest.ecb.europa.eu/help/ il porta europeo per la pubblicazione dei dati ufficiali, compreso il tasso di cambio giornaliero prodotto dalla BCE. Questo è il dato ufficiale riconosciuto da tutti gli operatori che cambiano da e verso Euro e dalle alle altre banche centrali. Una normale applicazione scaricherebbe semplicemente il dati scartando i dati di firma (il
lucchetto che si vede nella barra degli indirizzi dei browser) una volta verificata l’integrità della stessa. L’oracolo deve invece garantire il caricamento di dati inalterati esattamente come sono prodotti dalla fonte. Per farlo genera un file, che oltre a contenere il dato grezzo, contiene anche:

● l’intera catena dei certificati dal root-ca fino a quello utilizzato per la firma del dato (si tratta dell’attuale standard per la verifica di integrità in tutti i sistemi pubblici https://en.wikipedia.org/wiki/Public_key_infrastructure )
● la firma del messaggio contenente i cambi
● i tassi di cambio grezzi così come sono prodotti dal portale europeo
● la più recente versione della revocation list (https://en.wikipedia.org/wiki/Certificate_revocation_list )

L’ultimo passaggio è necessario per garantire la buona fede dell’oracolo. L’oracolo verifica che i dati rientrino in un range determinato dal programmatore dello stesso che evita l’inclusione di dati palesemente errati. Le fonti, come quella citata, presentano dei
sistemi di controllo multipli e degli schemi per permettere ad un’applicazione di capire se il dato è corrotto. A questo punto carica tutto in una transazione di BLOB accessibile a chiunque sulla blockchain. Qui la base dell’oracolo di ferma. Tutte le successive elaborazioni faranno riferimento a questa particolare installazione di dati.

● Essendo [i dati] caricati in blockchain saranno disponibili indipendentemente a tutti i nodi in qualunque momento.
● I certificati delle Root-CA sono presenti in tutti i dispositivi dal momento della loro installazione da parte del produttore.

Persino i cellulari li devono conoscere e sono necessari per il corretto funzionamento dell’infrastruttura di verifica di internet (la loro durata è di circa 40 anni). Il fatto di averli inseriti nella transazione permette a qualunque dispositivo di decidere se il dato base utilizzato per la firma sia valido o meno. In fine si implementa un ultimo livello di controllo all’interno della logica applicativa dello smart contract che, in caso di variazioni fuori da un determinato range, potrebbe attendere più conferme prima di procedere con l’esecuzione. Questi controlli sono implementati a priori nella versione installata dello smart contract e non rappresentano una “sorpresa” per chi lo utilizza. Chi lo utilizza implicitamente li accetta quando decide di far uso di quel programma. Per concludere, in questo particolare caso si è scelto di collegare l’oracolo ad una fonte la cui compromissione renderebbe inutile lo smart contract. Per spiegarmi meglio, se Mastercard chiude ricevute e carte di credito Mastercard non servono più a molto. Per quanto riguarda le richieste e l’implementazione la blockchain è scritta in java ma presenta un’interfaccia REST nativa. Le librerie di collegamento o il linguaggio in cui è scritto l’oracolo dipendono solo dalla preferenza del programmatore.

7) Come viene salvata la blockchain? Intendo si usa una database ..di che tipo? Uno standard come mysql, postgres… che consentono il rollback per avere transazioni ACID. In questo caso tramite API sono stati sviluppate o sono in progetto piattaforme per blockchain analytics accessibili dalla community? Come il wallet interroga la rete?

La versione attuale del wallet utilizza delle tabelle di hash differenziali per salvare i dati e la loro evoluzione tenendo conto di eventuali fork. Questa tecnica ha il vantaggio di essere computazionalmente estremamente efficiente e rende i dati verificabili manualmente. Le tabelle sono scritte come json serializzati su testo per facilitare il debug. Questi file possono essere acceduti direttamente e consultati come fossero degli snapshot anche da applicazioni esterne che eseguono sullo stesso server. Lo svantaggio di questa tecnica è l’occupazione di spazio e il tipo di query che si possono eseguire, qui è possibile trovare una breve descrizione https://en.wikipedia.org/wiki/Hash_table . In pratica, se io voglio trovare un bilancio mi basta sapere l’address a cui è associato e in 3 passi lo ottengo (O(1) tempo costante), indipendentemente dal numero di bilanci presenti all’interno della blockchain garantendo il mantenimento delle prestazioni nel tempo. Questo viene fatto al costo di sacrificare l’efficienza di una query che listi tutti oppure alcuni dei bilanci o che li estragga per valore.

Un’altra caratteristica della struttura dati è la gestione dei fork. ogni blocco determina un cambiamento di stato dell’intera struttura. Se però quel blocco dovesse venire “scartato” perché parte di una storia secondaria io devo potermi istantaneamente ricollegare allo stato precedente. Questo avanzamento della storia ad albero con la possibilità di ricollegarmi a qualunque punto della storia in modo istantaneo ha un costo notevole a livello di spazio. La differenza principale con i database è che io posso portare avanti un numero arbitrario di versioni del mondo fino al raggiungimento della finalità, gestirle in parallelo il tutto senza perdite
di efficienza computazionale. Questa struttura ci ha dato il tempo di migliorare la formulazione della finalità di takamaka e
renderla esplicita, al link seguente trovate l’ultima versione del paper relativo:

ttps://downloads.takamaka.dev/research/TPoS_Finality_EN.pdf grazie a questa modifica abbiamo potuto introdurre una limitazione alla complessità di gestione dei fork e iniziare lo sviluppo della nuova versione del client basata su PostgreSQL.

Senza questo cambiamento non sarebbe stato possibile gestire in modo efficiente i dati su un DB standard. L’introduzione del database standard permetterà l’esecuzione di query complesse di data mining su nodi di replica della blockchain oltre a dare un ulteriore livello di integrità ai dati. Attualmente, il software esegue un primo calcolo e poi una verifica. Se il risultato dei datafile non è consistente il blocco viene scartato. Questo non sarà più necessario grazie alle regole di consistenza intrinseche alla struttura di PostgreSQL che estenderanno anche le possibilità di data mining.

Attualmente l’esecuzione delle query di data mining è possibile grazie a delle strutture specifiche e al supporto di un database elasticsearch che verrà rimosso nelle successive versioni. Qui è possibile trovare una la documentazione necessaria a connettersi alla blockchain:
● https://takamaka.dev/docs/ApiNode
● https://github.com/takamaka-dev/webbootstrapper/blob/master/README.md
● https://takamaka.dev/
● https://github.com/takamaka-dev/ Comprese le applicazioni e gli SDK.

8) E in merito a “blockchain explorer”… dove si vedono le transazioni?

https://exp.takamaka.dev/

9) Ultima… vista la disponibilità di una stablecoin… e’ plausibile lo sviluppo di applicazioni come Chai payment (terra blockchain)?

Il WALLET di Takamaka, funziona (già) come strumento di pagamento e vista la possibilità di custodire TKR ( stablecoin ), riconosciuto come denaro digitale dalla svizzera, avviare sistemi di pagamento ( per chi li accetta ) con la stablecoin garantita dal denaro custodito in banca. Inoltre nella road map è prevista l’integrazione del wallet con carta di credito personalizzata, con cui poter spendere TKR. E sono in fase di presentazioni “case study” sul cashback da proporre a grandi catene di intrattenimento. Inoltre la società ha formalmente presentato domande per acquisire la licenza bancaria, in svizzera.

In collaborazione con Laura Lorenzi 

📌 Ti interessa Takamaka ?
Iscriviti alla Newsletter quindicnale e rimani aggiornato.
Aggiornamenti sulla tecnologie e le opportunità di business.

La nostra tecnologia il tuo busines

Takamaka built on Java

https://www.linkedin.com/newsletters/our-technology-your-business-6872427944225112065/

 

Resta aggiornato con la Newsletter Settimanale

Scrivi la tua Email

PS: Ricordati di cliccare nella mail di conferma che riceverai e in ogni momento potrai cancellare la tua sottoscrizione.