Sviluppo dell’applicazione
3.4 Piattaforma Server
3 L i b K e y M a n a g e r . K e y S t o r a g e s t o r a g e k e y s t o r e = L i b K e y M a n a g e r . k e y M a n a g e r S t o r a g e () ;
4 r e q u i r e((( k e y s t o r e . i s K e y A c t i v e [msg.s e n d e r] == t r u e) || ( i n c l u d e Q a x h && (msg.s e n d e r == k e y s t o r e . p a r e n t A d d r e s s ) ) ) ,
5 " T h i s m e t h o d can o n l y be c a l l e d by the o w n e r of
the s a f e ") ;
6 _ ;
7 }
Listing 3.22: Modifier from AccessControl.sol
Principali API della piattaforma Qaxh.io
• user.qaxh.io/testid/id?:
Creazione di uno UserSafe attraverso Mobile Connect e France Connect.
• user.qaxh.io/testid/idregister?
Registrazione dentro lo SchemeDirectory dello UserSafe.
• deployment.qaxh.io/deploy/emoneycreate?:
Creazione di una moneta interoperabile.
• corporate.qaxh.io/pdf/signinit?:
Creazione di un sistema di firme per documenti aziendali.
• deployment.qaxh.io/hatch/hatchcreate?:
Creazione di un HatchSafe.
• deployment.qaxh.io/hatch/schemecreate?:
Creazione di un SchemeDirectory.
Figura 3.27: API Overview
Principali API-Services Qaxh.io
• deployment.qaxh.io/onbaording/onbaordingcreate?:
Creazione della Folder OnBoarding.
• deployment.qaxh.io/deploy/mandatecreate?:
Creazione del servizio di Mandate.
• deployment.qaxh.io/habilitation/habilitationcreate?:
Creazione della Folder Habilitation.
• creditor.qaxh.io/mandate/confirmation?:
Api di servizio di conferma per un addebito all’interno di Mandate.
• acquirer.qaxh.io /acquirer/acquirernotify?:
Api di servizio per un acquirer per ricevere un quadro aggiornato su alcuni ordini di un determinato contratto di HabilitationFolder.
Tutte le API mostrate in precedenza sono state implementate in Python sfruttando la libreria, messa a disposizione dalla Ethereum Fondation, Web3py. La libreria in questione permette di inviare transazioni, interagire con i contratti intelligenti, leggerea dei dati dei blocchi e una varietà di altri casi d’uso; tuttavia l’intero funzionamento della libreria si basa sull’impostazione da parte del programmatore del punto di accesso alla rete Blockchain scelta. Su tale punto focale è possibile distinguere due metodologie di accesso, che corrispondono a due tecnologie differenti, sfruttate in QAXH.IO:
• Infura: un’applicazione che si connette alla blockchain di Ethereum, inte-ragisce con la blockchain di Ethereum e gestisce i nodi per conto dei suoi utenti [32]. Nata per risolvere i principali problemi di qualsiasi connessione alla blockchain:
1. La memorizzazione dei dati su Ethereum è costosa.
2. Può essere complessa l’impostazione di una connessione alla blockchain.
3. La sincronizzazione con la blockchain può risultare lenta.
4. La struttura della blockchain occupa molto spazio.
Molte applicazioni basate su Ethereum si affidano a Infura per connettersi alla blockchain di Ethereum ed effettuare transazioni per i propri utenti. Ma Infura è un servizio centralizzato ed è quindi vulnerabile ad attacchi che potrebbero limitarne la funzionalità e la correttezza. Inoltre questa centralizzazione potrebbe essere utilizzata per censurare le transazioni da parte di governi o terze parti.
Più servizi lo utilizzano, maggiormente centralizza la blockchain di Ethereum attorno a una società. Questo andando contro l’idea stessa di decentraliz-zazione, con cui nasce la blockchain, ha portato a sviluppare soluzioni poco centralizzate attraverso alcuni particolari strumenti come Geth.
• Nodo Geth: Il nodo Geth [35] è un vero e proprio nodo della blockchain, sviluppato su uno screen linux del server Natixis, vedi la figura 3.13. Questo nodo permette gli scenari piu comuni all’interno di Ethereum:
1. Creazione di account.
2. Trasferimento di asset.
3. Distribuzione ed interazione con i contratti.
Tuttavia è pensato anche per i classici scenari per gli sviluppatori : 1. Permette l’accesso alle reti di test piu comuni.
2. Permette la creazione di una propria rete interna.
3. Permette la gestione di un Miner interno.
Questo tool sviluppato dalla fondazione Ethereum fornisce ulteriori possibilità ad un neofita della Blockchain, sostituendo e integrandosi perfettamente con tecnologie eistenti come Metamask.
Figura 3.28: Overview dei punti d’accesso
Punto di accesso alla Blockchain
1 i n f u r a _ u r l = " h t t p s :// r i n k e b y . i n f u r a . io / v3 / < I n f u r a l i n k > "
23 l o g g i n g . i n f o (’ w e b 3 c o n n e c t i o n ’)
45 w e b 3 = W e b 3 ( W e b 3 . H T T P P r o v i d e r ( i n f u r a _ u r l ) )
Listing 3.23: Classica connessione tramite Infura
1 c l a s s W 3 C o n n e c t i o n :
2 c l a s s _ _ W 3 C o n n e c t i o n : 3 def _ _ i n i t _ _ ( s e l f ) :
4 p a t h = os . p a t h . j o i n ( P A T H _ D I R _ N O D E , " g e t h . ipc ") 5 p r o v i d e r = W e b 3 . I P C P r o v i d e r ( path , True , t i m e o u t = 1 0 ) 6 # p r o v i d e r = W e b 3 . H T T P P r o v i d e r (" h t t p :// r i n k e b y . q a x h . io
/")
7 # An a t t e m p t to i m p l e m e n t a t o o l l i k e i n f u r a i n t e r n a l to Q a x h . io
89 if p r o v i d e r is N o n e :
10 r a i s e E x c e p t i o n ( f" C o u l d n ’ t c o n n e c t to g e t h n o d e via IPC at p a t h { p a t h } ")
11 s e l f . w3 = W e b 3 ( p r o v i d e r )
1213 # XXX : T h i s is o n l y n e c e s s a r y w h e n u s i n g r i n k e b y 14 s e l f . w3 . m i d d l e w a r e _ s t a c k . i n j e c t ( m i d d l e w a r e .
g e t h _ p o a _ m i d d l e w a r e , l a y e r =0) 1516 _ _ i n s t a n c e = N o n e
1718 def _ _ i n i t _ _ ( s e l f ) :
19 if not W 3 C o n n e c t i o n . _ _ i n s t a n c e :
20 W 3 C o n n e c t i o n . _ _ i n s t a n c e = W 3 C o n n e c t i o n . _ _ W 3 C o n n e c t i o n ()
2122 def _ _ g e t a t t r _ _ ( self , a t t r ) :
23 r e t u r n g e t a t t r( W 3 C o n n e c t i o n . _ _ i n s t a n c e . w3 , a t t r )
Listing 3.24: Nodo geth (usato sul Server)
Key for Hatch & Scheme creation
Figura 3.29: Scheme & Hatch creation
1 @app . route (" / h a t c h / s c h e m e c r e a t e ", m e t h o d s =[" P O S T "]) 2 def s c h e m e c r e a t e () :
34 l o g g i n g . i n f o (" [ S C H E M E C R E A T E ] ") 5 r e s p o n s e = {}
6 r e s p o n s e [" t x _ h a s h "] = " "
78 otp = str( r e q u e s t . a r g s . get (’ c e r e m o n y o t p ’) ) 109 r e s u l t = db . g e t _ o t p _ v a l i d i t y ( otp )
11 """ c h e c k r e s u l t 12 """
13 db . s e t _ o t p _ u s e d ( r e s u l t )
1415 e o a r = r e q u e s t . a r g s . get (’ e o a r ’) 1617 """
18 C h e c k s u m E o a r for w e b 3 19 """
20 i n f o _ c o n t r a c t = d e p l o y _ S c h e m e _ c o n t r a c t ( p a r e n t A d d r e s s ) 21 r e t u r n j s o n i f y ( i n f o _ c o n t r a c t )
Listing 3.25: Creazione dello scheme con OTP & eoar
1 @app . route (" / h a t c h / h a t c h c r e a t e ", m e t h o d s =[" P O S T "])
2 def h a t c h c r e a t e () : 34 """
5 s e t t i n g r e s p o n s e ...
67 Otp o p e r a t i o n s ...
89 E x t r a c t a r g u m e n t s as P a r e n t A d d r e s s and H a t c h N a m e ..
1011 """
12 # d e p l o y m e n t of H a t c h S a f e
13 i n f o _ c o n t r a c t = d e p l o y _ H a t c h S a f e _ c o n t r a c t ( p a r e n t A d d r e s s , mode , h a t c h N a m e , urlId , u r l R e g i s t e r , o t p I d )
1415 r e t u r n j s o n i f y ( i n f o _ c o n t r a c t )
Listing 3.26: Creazione del Hatch (stesso modello dello Scheme)
Diamond Server
L’implementazione del Diamond Server, ovvero il server per la creazione di un’i-dentità "Safe"in QAXH.IO, è anch’esso implementato in python, sfruttando il framework Flask. Quest’ultimo permette l’importazione di un toolkit di nome Blueprint sfruttato per estendere le funzionalità offerte dalle API di creazione, quali autenticazione e accounting. L’implementazione della famiglia delle API user.qaxh.io/testid/ esula dallo scopo di tale tesi quindi è possibile limitarsi a riportare come alla base del funzionamento vi sia un Redirect HTTP al fine di reindirizzare la richiesta di autenticazione al provider di identità digitale Mobile Connect et moi, già citato negli scorsi capitoli. Per quanto riguarda la creazione di un UserSafe è possibile ricollegarci alla sezione 3.3.1, mostrando per intero la costruzione di un Diamond-Identità a partire dalle varie Facets, già distribuite sulla Blockchain:
1. Compilazione di una Facet con conseguente creazione di un file JSON.
2. Distribuzione di una Facet su Ethereum attraverso tool come Truffle (le metodologie verranno approfondite nel prossimo capitolo).
3. Estrazione dell’indirizzo appena distribuito dal file JSON.
4. Estrazione dell’ABI dal file JSON.
5. Creazione di un’istanza del contratto a partire dagli ultimi due elementi estratti.
6. Creazione di un array di strutture che raggruppi le coppie Indirizzo-ABI.
7. Creazione del Diamond con l’array descritto nel 6 come parametro di input.
1 h a b i l i t a t i o n _ f a c e t _ d a t a = u t i l s . d e s e r i a l i z e _ d i a m o n d _ j s o n ("
H a b i l i t a t i o n D i r e c t o r y F a c e t ") 23
4 h a b i l i t a t i o n f a c e t _ i n s t a n c e = w3 . eth . c o n t r a c t ( a d d r e s s = u t i l s . g e t _ c o n t r a c t _ a d d r e s s ( h a b i l i t a t i o n _ f a c e t _ d a t a ) , abi =
h a b i l i t a t i o n _ f a c e t _ d a t a [’ abi ’]) 56 # p r e p a r i n g the D i a m o n d C u t A r r a y
7 d i a m o n d c u t _ a r r a y . a p p e n d ( u t i l s . s e t _ c o n t r a c t _ c u t _ a r r a y (’ Add ’, h a b i l i t a t i o n f a c e t _ i n s t a n c e ) )
8 """
9 o t h e r f a c e t s ..
10 """
1112 d i a m o n d _ d a t a = u t i l s . d e s e r i a l i z e _ d i a m o n d _ j s o n (" D i a m o n d ") 13 d i a m o n d _ a b i = d i a m o n d _ d a t a [" abi "]
14 d i a m o n d _ b y t e c o d e = d i a m o n d _ d a t a [" b y t e c o d e "]
15 c o n t r a c t _ c l a s s = w3 . eth . c o n t r a c t ( abi = d i a m o n d _ a b i , b y t e c o d e = d i a m o n d _ b y t e c o d e )
1617 l o g g i n g . i n f o (" \ n U n l o c k i n g . . . \ n ")
18 w3 . g e t h . p e r s o n a l . u n l o c k A c c o u n t ( Q A X H _ A D D R E S S , Q A X H _ P A S S W O R D ) 19 l o g g i n g . i n f o (" \ n D e p l o y i n g D i a m o n d U s e r s a f e . . . \ n ")
20 l o g g i n g . i n f o (" \ n D i a m o n d c u t _ a r r a y : " + j s o n . d u m p s ( d i a m o n d c u t _ a r r a y ) + " \ n ")
21 t x _ h a s h = c o n t r a c t _ c l a s s . c o n s t r u c t o r ( d i a m o n d c u t _ a r r a y , [ h a t c h _ a d d r e s s , k e y A d d r e s s , d e a d l i n e , eIDAS , a g e O f M a j o r i t y , QI_hash , QE_hash , c u s t o m e r I d ]) . t r a n s a c t ({
22 ’ f r o m ’: Q A X H _ A D D R E S S ,
23 ’ gas ’: 9 0 0 0 0 0 0 ,
24 ’ g a s P r i c e ’: w3 . t o W e i ( g a s P r i c e _ i n _ g w e i , ’ g w e i ’) , 25 ’ v a l u e ’: w3 . t o W e i (0.02 , " E t h e r ")
26 })
27 l o g g i n g . i n f o ( f" W a i t i n g for D i a m o n d u s e r S a f e d e p l o y m e n t { t x _ h a s h . hex () } ")
28 w3 . g e t h . p e r s o n a l . l o c k A c c o u n t ( Q A X H _ A D D R E S S )
Listing 3.27: Diamond steps
Folder-Type Server
Il Server-side per i business services delle Folder è principalmente basato su due API principali:
• /qaxh.service/foldercreate: API di creazione del contratto che riceve come argomenti i vari parametri da inserire nel costruttore del contratto.
• /qaxh.service/folderregister: API di registrazione della Folder all’interno dello SchemeDirectory.
Come già visto nel Listing 3.27 in questa sottosezione è utile mostrare l’implemen-tazione classica delle strutture Web3 che permette una transazione all’interno della blockchain.
1 # e x t r a c t abi f r o m . sol
2 h a t c h _ a b i = u t i l s . d e s e r i a l i z e _ j s o n (" H a t c h S a f e ") [" abi "]
34 # I n s t a n c e c o n t r a c t f r o m A d d r e s s and ABI
5 s c h e m e = w3 . eth . c o n t r a c t ( s c h e m e A d d r , abi = h a t c h _ a b i ) 67 # s i g n the t r a n s a c t i o n
8 # t = f u n c . b u i l d T r a n s a c t i o n (
9 # { ’ n o n c e ’: .. , ’ f r o m ’: ’0 x E 5 c 6 d E A 0 4 8 E B ’ , ’ gas ’: 6 2 0 0 0 0 0 , ’ g a s P r i c e ’: w . eth . g a s P r i c e })
10 # s i g n e d _ t x = w . eth . a c c o u n t . s i g n T r a n s a c t i o n ( t , K e y P r i v a t e ) 11 # tx = w . eth . s e n d R a w T r a n s a c t i o n ( s i g n e d _ t x . r a w T r a n s a c t i o n ) 12 # It ’ s the s a m e w i t h " u n l o c k A c c o u n t " for a c c o u n t of n o d e g e t h
in the s e r v e r
13 w3 . p e r s o n a l . u n l o c k A c c o u n t ( Q A X H _ A D D R E S S , Q A X H _ P A S S W O R D ) 1415 # c a l l a f u n c t i o n w i t h the p a r a m e t e r s
16 t x _ h a s h = s c h e m e . f u n c t i o n s . r e g i s t e r S a f e ( safe , s a f e T y p e , CID , 0) . t r a n s a c t (
17 {’ f r o m ’: Q A X H _ A D D R E S S , ’ gas ’: 6 2 0 0 0 0 0 , ’ g a s P r i c e ’: w3 . eth . g a s P r i c e })
1819 w3 . p e r s o n a l . l o c k A c c o u n t ( Q A X H _ A D D R E S S )
Listing 3.28: Codice per la registrazione nello Scheme
In ambito di Folder-Type è ragionevole riportare le differenze tra le API del server n.16 e le API del server n.7 in quanto il primo rappresenta il vero server della piattaforma qaxh.io, un vero "HatchServer", al contrario il secondo rappresenta un’altro protagonista dei servizi di ogni Folder, l’Acquirer Server. Su quest’ultimo sono implementate tutte le API fornite e pensate da QAXH.IO per gli actor-Acquirer, quali banche, istituzioni ed entità governative. Quest’ultimi grazie a questi strumenti implementati sui loro server, mantenendo un semplice indirizzo Ethereum, potranno gestire tutti i servizi delle Folder (Smart Contract) che li vedono protagonisti, usufrendo di tutti gli elementi tipici della blockchain, quali autorizzazione e confidenzialità.
3.4.2 Gestione dei poteri bancari
Procedendo nello stesso modo della sezione precedente, è possibile fornire i dettagli dell’implementazione server del servizio di Gestione dei poteri bancari.