10. Peppercoin

 

 

 

Peppercoin è una società di pagamento che ha rivisto il suo approccio per  affrontare le sfide sui piccoli pagamenti. La società, che ha base in Waltham,  Massachusetts, fu fondata in tardo 2001 dai Professori del MIT Silvio Micali e Ron  Rivest (la “R” di RSA in Sicurezza). Dopo aver lanciato inizialmente un servizio di micropagamenti on-line, nel dicembre 2003.

Prima di iniziare a parlare del protocollo su cui si fonda Peppercoin,lo schema MR02, verrà fatta una panoramica sui micropagamenti in generale.

 

 

10.1 Micropagamenti

 

Un “micropagamanto” è ogni pagamento che è abbastanza piccolo da rendere il suo trattamento relativamente costoso in rapporto al valore dell'operazione complessiva. Dato che le tasse per trattare tipiche carte di credito possono essere venticinque centesimi per operazione, si può considerare un “micropagamento”  ogni pagamento sotto $10. 

Si considera l'introduzione di micropagamenti efficienti nel mondo dell'e-commerce significativa come l'invenzione delle monete di metallo del Lydians nel 640 A.C. Oggi, è chiaro che i piccoli pagamenti elettronici diverranno presto luogo comune. Non solo pagare per scaricare musica (si veda il recente successo dell'iTunes di Apple), ma anche per scaricare altro: download digital ed altri beni digitali e servizi. I piccoli pagamenti elettronici cominceranno a sostituire  monete di metallo e la piccola carta conterà per gli acquisti nel mondo reale.  Un trattamento efficiente è essenziale per un metodo di micropagamento riuscito;  non ha nessun senso fare pagare venticinque centesimi per trattare un pagamento di dieci centesimi! 

Continua la descrizione dei micropagamenti analizzando i vari metodi con cui essi sono gestiti.

 

 

10.2 Metodi di aggregazione

 

La chiave per un trattamento efficiente di micropagamenti è, chiaramente, l'aggregazione di molti piccoli micropagamenti in alcuni più grandi macropagamenti. Si distinguono quattro livelli di aggregazione:

 

1. Senza aggregazione

Non viene fatta aggregazione, ogni pagamento fa la sua strada circa il ciclo di pagamento intero, da acquirente a commerciante  da commerciante (acquirente) banca a consumatore (emittente) banca a consumatore  (per accreditare).Poiché ogni parte tocca ogni pagamento questo metodo  è estremamente inefficiente e costoso.

2. Aggregazione sessione-livello

Con aggregazione sessione-livello (anche noto come commerciante-livello), il commerciante raccoglie molti piccoli pagamenti da un dato consumatore - tra tutti quelli spesi da quel consumatore durante un giorno - e sottopone un macropagamento  rappresentando l'ammontare globale dovuto alla fine del giorno(o sessione). Questo metodo funziona solamente qualche volta: quando il consumatore fa piccoli acquisti ripetuti presso lo stesso commerciante in un periodo di tempo breve;  non funziona in generale.

 

3. Aggregazione per intermediazione

Un altro approccio per offrire l'aggregazione è creare un nuovo intermediario  con cui tutti i consumatori e commercianti devono interagire per trattare i micropagamenti. Questo intermediario tenta di monitorizzare ogni micropagamento  fatto da ogni consumatore ad ogni commerciante partecipante, per poi  sottoporre al trattamento del sistema tecnico bancario solamente pagamenti che  rappresentano l'intero ammontare speso da quel consumatore durante il  determinato periodo di tempo, o l' intero ammontare ricevuto da un dato commerciante durante  quel periodo di tempo. Questo approccio richiede ancora maneggio di ogni pagamento  da parte dell'intermediario, che è realizzato replicando la funzionalità dell'intero  sistema bancario esistente, a costo più basso! Chiaramente, la strada verso un miglioramento dovrebbe essere ridurre l'ammontare di meccanismi e trattamenti  coinvolti, non aumentandoli!

 

4. Aggregazione universale

“Peppercoin” usa l'aggregazione universale che viene anche chiamata  "cryptographic Selection" o aggregazione many/many/many,  siccome aggrega agevolmente attraverso molti consumatori, molti commercianti  e molti providers di servizi di pagamento.

Con l'aggregazione universale, ogni negoziante partecipante tratta i micropagamenti  direttamente, usando speciali software di crittografia.  Il software controlla prima la validità del micropagamento, per esempio controllando la firma digitale del consumatore su quel micropagamento.  Se il micropagamento è valido, il commerciante completa poi l'operazione  e consegna i beni acquistati al consumatore.  Il software controlla poi se il micropagamento “permette un  aggiornamento” (ad un macropagamento). Se il micropagamento non permette  un aggiornamento, il commerciante registra soltanto il micropagamento, e non necessita di ulteriori trattamenti . Se il micropagamento permette un aggiornamento ad un  macropagamento, il commerciante depositerà quel micropagamento come un  macropagamento con la sua banca. La procedura di "qualifica" ha una natura crittografica tale che né  il consumatore né il commerciante possono simulare la decisione affinché un  particolare micropagamento permetta l'aggiornamento e divenga un macropagamento. La procedura di qualifica  dipende dalla firma digitale del commerciante sui dati derivati  dal micropagamento, così che le altre parti, come il commerciante  e le banche del consumatore, può controllare che un micropagamento determinato permetteva davvero un aggiornamento. 

Il commerciante  non ha bisogno di tenere alcun genere di record di operazioni precedenti,  ammontare cumulativo speso da ogni consumatore, o  altro.

Il sistema Peppercoin assicura che ad un consumatore non venga mai accreditato  più di quello che lui ha speso. La banca del consumatore agisce come un buffer finanziario tra le spese in contanti  a commercianti e le ricevute dal consumatore, in una maniera molto  simile, ma non identico, a quello che accade trattando con la carta di credito standard. L'uso di crittografia - basato su firme digitali  da consumatori e commercianti - previene anche le varie forme di frode  di uno o due parti contro l'altra(le altre). 

Depositi fatti dal commerciante sono solamente nella forma di macropagamenti. Ai Consumatori è accreditato solamente  l'ammontare che loro hanno speso presso tutti i commercianti oltre il periodo di accredito(e.g. un mese). Non c'è nessun intermediario coinvolto che deve occuparsi di ogni pagamento.

 

10.3 Lo schema MR02

 

Lo schema MR02 è il protocollo su cui si fonda PepperCoin, prende il nome dalle iniziali degli autori Silvio Micali e Ron Rivest e lo 02 sta a sottolineare il miglioramento di uno schema precedente MR01 che lasciava irrisolto il problema della possibilità da parte dell'utente di pagamenti eccessivi. Invece MR02 garantisce che ad un utente onesto non sia mai addebitato più di quello che veramente spende. Il piccolo rischio di un pagamento eccessivo è passato dall’utente alla banca. Questo è preferibile per due motivi:

1. pagamenti eccessivi accadono molto raramente,  e per un ammontare moderato. Ora se questo può infastidire gli utenti, non infastidirà le banche, che sono abituate a gestire rischi sostanziali, maggiori del rischio di un piccolo pagamento eccessivo;

2. il rischio relativo a lungo andare tende a diminuire, e così è meno probabile per la banca, dato che ha un’esperienza ben più grande del singolo utente.

Un’altra significativa caratteristica dello schema è la sua estrema semplicità. Di conseguenza, piuttosto che tentare con molto sforzo di prevenire gli inganni, punisce semplicemente le parti che ingannano, o lo elimina dal sistema prima che possa creare danni sostanziali.

 

 

Preliminari

 

Assumiamo che T denoti (la codifica di) una transazione e che T specifichi tutte le quantità ritenute utili come l’utente U, il commerciante M, la banca B, “la merce”, il tempo della transazione, il valore(monetario) della transazione, ecc. Per semplicità assumiamo che ogni transazione ha un valore fissato (uguale ad un centesimo) e ci sia un fissato rate di selezione, denotato da s (s è la frazione dei pagamenti che ci si aspetta sia selezionato per il deposito), esso è compreso tra 0 e 1, per ogni micropagamento utente e commerciante interagiscono accordandosi per un predeterminato valore di s, così che la selezione avviene con probabilità s: un micropagamento non selezionato non ha valore e può essere scartato, mentre uno selezionato può essere depositato per un ammontare di 1/s centesimi. Esempio: s = 1/1000 ed ogni micropagamento è 1 centesimo, in media su 1000 micropagamenti, 999 sono scartati e 1 depositato, pagando così 1/(1/1000) = 1000 centesimi come costo di una singola transazione. Usando questo approccio vengono minimizzati i costi dei processi, infatti ritornando all'esempio precedente vengono pagati 1000 centesimi per le 1000 transazioni compiute dall'utente effettuando, però, un unico deposito.

Inoltre ogni check inviato dall'utente al commerciante è già "preselezionato" per la pagabilità, infatti M può immediatamente verificare se un check C è pagabile, perchè può valutare facilmente F(SIG_M(C)) e confrontarlo con il rate di selezione s (come si vedrà in dettaglio di seguito); in  un certo senso ogni check è etichettato "pagabile" o "non pagabile", ciò ci assicura le seguenti proprietà:

- la frazione dei check etichettati "pagabili" è approssimativamente s,

- l'utente non può leggere l'etichetta del check che egli invia,

- il commerciante può leggere l'etichetta e renderlo visibile agli altri.

Denotiamo con F(.) una funzione pubblica fissata che prende stringhe di bit arbitrarie come input e ritorna come output un numero tra 0 e 1, compresi. Per esempio F può operare prendendo in input la stringa 'e'  facendola quindi precedere da zero e da un punto, e interpretando il risultato come un numero binario, così che, per esempio “011” diventa “0.011” che è interpretato come il numero 3/8.

Se X è una delle parti in causa (nel nostro caso utente o commerciante) e Y è un messaggio denotiamo con SIG_x(Y) la firma digitale di X su Y. Per semplicità assumiamo che ogni messaggio è trattato con una funzione hash one-way prima di essere firmato. Per esempio:  SIG_x(Y) può essere implementata come (Y,SIG_x(H(Y)), dove H è una fissata funzione hash one-way pubblica.

 

 

Lo schema base

 

Le seguenti fasi illustrano il funzionamento del protocollo:

• Set up: ogni utente ed ogni commerciante stabilisce una sua chiave pubblica(con la corrispondente chiave segreta) per uno schema di firma digitale sicuro. Lo schema di firma del commerciante deve essere deterministico.

• Pagamento:  un utente U paga un commerciante M per una transazione T(con il rate di selezione s). Viene calcolato il check C= SIG_U(T). L’utente include il tempo ed un numero seriale SN in ogni operazione di check/transazione(il numero seriale dovrebbe iniziare da 1 ed essere assegnato sequenzialmente). Il check C è pagabile se F(SIG_M(C)) < s. Se C è pagabile allora M invia alla banca B sia C che SIG_M(C) per il deposito.

• Deposito selettivo: sia maxSN_U il massimo numero seriale di un check pagabile di U processato finora da B (inizialmente maxSN_U = 0). Assumiamo che C sia un nuovo check pagabile e che le firme di U e di M siano corrette. Quindi la banca B accredita 1/s centesimi sul conto di M. Inoltre, se il numero seriale SN del check è più grande di maxSN_U, la banca B addebita sul conto di U SN - maxSN_U centesimi, e setta maxSN_U = SN e può giustificare la sua azione restituendo ad U SIG_M(C) (Un eccezione alla regola di sopra è fatta se la banca nota che il nuovo check ha lo stesso numero seriale di un check precedentemente processato, o se il numero seriale del check e il tempo sono “fuori ordine” rispetto ai check precedentemente processati, o se l’ammontare del check è eccessivo, o se si presentano altre condizioni definite dalla particolare banca. In questo casi eccezionali la banca può multare l’utente e/o compiere altre azioni come essa ritiene appropriato).

• Emissione selettiva:  la banca può mantenere statistiche ed eliminare dal sistema(revocando i loro certificati) gli utenti i cui check pagabili causano eccezioni (come visto sopra) perché essi hanno numerato e/o datato inconsistentemente, o perché i loro check sono pagabili “più frequentemente di quanto ci si aspetti”. Allo stesso modo si possono eliminare i commercianti con le stesse problematiche, o perché sono stati spesi check “pagabili più frequentemente”.

 

Rappresentazione grafica dello schema base

 

Correttezza dello Schema

Si dimostra che lo schema è corretto analizzando  le proprietà del protocollo.

La fase di set-up è semplice e generale. Non c'è bisogno di un set-up separato per ogni coppia (U,M).

La fase di pagamento è non interattiva. L'utente U semplicemente invia un messaggio firmato al commerciante M, al quale M non deve rispondere.

SIG_M(C) è una quantità non predicibile da U, poichè U non conosce la chiave segreta di M. Dunque anche se U può controllare il check C, comunque egli voglia(per esempio scegliendo la transazione) SIG_M(C) sarà sicuramente random di conseguenza F(SIG_M(C)) è un numero casuale e sufficientemente lungo, compreso tra 0 e 1, che dovrà essere minore di s per rendere il check "pagabile".

La banca B agisce solo per una frazione s di micropagamenti e lo fa processando solo macropagamenti. Ogni check inviato da M a B è pagabile ed ognuno di questi check è in realtà un macropagamento che ha valore 1/s centesimi.

Due parti (tra U, M e B) non possono imbrogliare con successo una terza parte. Anche con l'aiuto di B, U non può scrivere un check pagabile con "meno di s chance". Invece il valore SIG_M(C) è non predicibile sia per B che per U, anche se essi condividono informazioni circa SIG_M(C') per ogni check C' precedente e scelgono insieme C. Allo stesso modo M e B non possono imbrogliare U. Una volta scelta la chiave pubblica di firma nella fase di set-up, essendo lo schema di firma deterministico, c'è un solo possibile valore SIG_M(C) per ogni check C. Inoltre quando la chiave pubblica di M viene scelta, M e B non conoscono quale sia il check di U. Anche se B ed M sono capaci di indovinare o controllare quale transazioni di U saranno eseguite, esse non possono scegliere la chiave pubblica di M, così da garantire che i check di U saranno pagabili con probabilità più alta di s. Infatti, il check di U per una transazione T, che consiste di SIG_u(T), non predicibile sia per M che per B.

Inoltre il protocollo risulta corretto per utenti onesti: assumiamo che ad un certo tempo t, ad un utente onesto U sono stati addebitati maxSN_U centesimi, dove maxSN_U è il più alto numero seriale dei check di U depositati con successo. Assumiamo ora che, dal tempo t, U ha fatto n transazioni. Quindi, perché un utente onesto numera i suoi check sequenzialmente partendo da 1, n sarà il numero seriale più alto di ogni check che U ha scritto, e dunque maxSN_U ≤ n. Essendo ciò, ad U verrà addebitato al più 1 centesimo per transazione. Per cortesia, M può informare U quando un check è pagabile, ma in questo schema è preferibile che M non informi l’utente, e certamente non è necessario per M stesso. E' meglio che l’utente non conosca quei numeri seriali che non sono risultati pagabili.

Per incorrere ad addebiti minori, un utente malizioso U’, può provare ad abbassare artificialmente maxSN_U usando almeno due volte un numero seriale SN. Dunque U’ può imbrogliare la banca (B) nel seguente modo: un utente malizioso si accorda con un commerciante malizioso M’, così da assicurare che un check di U’ speso da M’ è sempre pagabile. Infatti, per ogni potenziale check C, M’ può dire ad U’ il valore di SIG_M’(C), così non è difficile predire per U’ se il check potrà essere pagabile. Con una piccola procedura trial-and-error  U’ scrive solo check pagabili. In questo modo U’ pagherà sempre e solo 1/s centesimi a B, mentre B pagherà 1/s centesimi(per esempio 10$ se s = 1/1000) ad M’ per ogni check pagabile con lo stesso SN. U’ e M’ possono quindi dividere il loro ricavo: inoltre, U’ può coincidere con M’ se setta esso stesso come commerciante.

 

 

Varianti

 

• Variante teorica.  

   

  Risulta cruciale che F(SIG_M(C)) sia un numero casuale, sufficientemente grande in modo da garantire la sicurezza dall'utente malizioso. Questa condizione di sicurezza dipende dallo schema di firma e dalla definizione di F. Per esempio consideriamo una F che ritorna la frazione binaria, la cui rappresentazione sono i 20 bit meno significativi del suo input. La condizione di sicurezza è immediatamente vera, se lo schema di firma digitale è uno dei modelli come gli oracoli casuali. La condizione viene anche mantenuta se il commerciante usa uno schema di firma appropriato come può essere RSA. Il commerciante M sceglie casualmente la sua chiave RSA come una stringa lunga 1024 bit, quindi, dato c=2, gli ultimi 20 bit di SIG_M(C) forniscono una stringa Y di 20 bit essenzialmente indistinguibile da una stringa casuale di 20 bit, non importa come sia stato scelto C. (Se C viene scelto in una maniera particolare, il commerciante M può utilizzare H(C), dove H è una funzione hash one-way, come "oracolo" casuale).

   

  Lo stesso punto cruciale può essere risolto formalmente senza ricorrere ad un modello di "oracolo" casuale. Cioè dovrebbe essere sufficiente per il commerciante utilizzare una funzione casuale verificabile (VRF) piuttosto che uno schema di firma digitale ordinario. Una VRF comprende una coppia di chiavi ed una coppia di algoritmi: una chiave pubblica PK (che specifica una funzione F_PK che rende difficile calcolare F_PK(C) ), una chiave segreta SK, un algoritmo di valutazione E ed un algoritmo di verifica V. Il commerciante può selezionare PK e SK e stabilire PK come sua chiave VRF pubblica, così che un check C diviene pagabile se F_PK(C) < s(rate di selezione). Egli può immediatamente determinare se C è pagabile, perché conosce SK e può facilmente determinare F_PK. Inoltre può permettere alla banca di verificare che C è pagabile rilasciando una prova P_C.

   

   

• Variante pratica.

         Si può operare su vari parametri:

 - Tempo. 

Lo schema base permette ad un commerciante di depositare un check pagabile in qualsiasi istante. Inoltre la banca può rifiutare di accreditare il conto del commerciante durante la fase di deposito a meno che non presenti un check pagabile che ha un tempo sufficientemente corretto. Questo da uno stimolo in più al commerciante per verificare la correttezza del tempo del check che egli riceve. Invece se il tempo è errato, egli può rifiutare di fornire la “merce” richiesta. Il tempestivo deposito assicura che all’utente non venga addebitato “troppo tardi”, altrimenti spenderebbe dei soldi che in realtà non possiede.

 

- Funzioni F e G. 

Le funzioni F e G possono non essere fissate, ma variare. Per ogni istanza, un check o una transazione possono specificare quale F o G debba essere usata con loro.

Le condizioni di pagabilità del check F(SIG_M(C)) < s , potrebbe essere rimpiazzato da F(SIG_M(G(C)))  < s, dove G è una data funzione/algoritmo. Così piuttosto che firmare C stesso, il commerciante può firmare una quantità dipendente da C, denotata da G(C). La condizione di pagabilità del check può essere scelta in diversi modi. Per minimizzare il numero di firme del commerciante, piuttosto che usare F(SIG_M(G(C))), per determinare la pagabilità del check si può usare F(SIG_M(G(V_i))), dove { V_i } è una sequenza di valori associati ad una sequenza di istanti. Un check C relativo ad una transazione T in un certo giorno i può essere pagabile se F(SIG_M(V_i)) < s.

Si noti che è meglio, in questa variante, che il commerciante nasconda tutte le informazioni circa i check che sono stati scartati e quei check sono stati messi da parte per essere accreditati in un dato intervallo di tempo/giorni. Altrimenti un utente malizioso potrebbe predire o piuttosto dedurre F(SIG_M(G(V_i))) e dare ad M check che non sono pagabili o che hanno meno probabilità di essere pagabili. Per questa ragione, se un commerciante usa un approccio V_i, si raccomanda che egli memorizzi tutti i suoi check pagabili di un dato intervallo di tempo/giorno, per poi inviarli tutti alla banca alla fine dell’intervallo di tempo/giorno. In questo modo anche una banca maliziosa non può accordarsi con un utente per permettergli di imbrogliare il commerciante.

Una maniera particolare per implementare l’approccio di sopra consiste nell’utilizzare una catena di funzioni hash one-way. Dunque, il commerciante calcola una sequenza di valori:

x₀, x₁ , x₂  , … , x_n

dove

X_i = H(X_i+1) per i = 0, 1 , … , n-1

 Dove H è una funzione hash, e mette X₀ nel suo file pubblico, o altrimenti pubblica X₀. Quindi si può usare Xi piuttosto che F(SIG_M(G(V_i))) in ogni intervallo i di tempo/giorni.

 

 

10.4 Pregi di Peppercoin

 

 

Facilita d’uso

 

Il metodo Peppercoin di base può essere perfezionato in una varietà di modi, per  massimizzare la facilità d'uso per il consumatore in una determinata situazione. Per esempio, mentre il metodo Peppercoin di base richiede che ogni consumatore abbia la  capacità di firma digitale, si può eliminare facilmente questo requisito per avere una parte fidata per il consumatore che firma i pagamenti per lui come un  mandatario; questo è un approccio naturale in un ambiente web-services.  Il metodo Peppercoin può anche essere perfezionato affinché per il consumatore sia  come una naturale dilazione della procedura di analisi della sua carta di credito, incrementando ulteriormente la  facilità d'uso per il consumatore.

 

Scalabilità

 

Peppercoin ha la capacità di "scalare"  operazioni molto grandi, sicché tutto “il vero lavoro” che coinvolge i micropagamenti viene gestito direttamente dal consumatore e dal commerciante.

     

Non interattività

 

Il metodo Peppercoin è non-interattivo nel senso che un micropagamento con Peppercoin può essere spedito via e-mail o può essere trasmesso direttamente dal consumatore al commerciante. Non c'è bisogno che il commerciante interagisca col consumatore durante il processo di pagamento, o che sia on-line per la durata del pagamento. 

 

Procedura di "qualifica" a basso costo

 

ll semplice metodo di aggregazione universale descritto sopra  richiede al commerciante di calcolare una firma digitale per ogni micropagamento ricevuto.  Per alcuni commercianti che stanno trattando un volume molto alto di beni con prezzi molto bassi, questo può essere un po' oneroso.  È possibile ridurre questo calcolo notevolmente costoso, cambiando leggermente  la procedura di qualifica. Per esempio, può dipendere solamente, dalla firma del commerciante per la durata del micropagamento, misurato dal minuto più vicino. Quindi il negoziante ha bisogno di calcolare solamente una firma digitale  al minuto.

  

Pagamenti di taglia variabile

 

Anche se questo punto già possa essere chiaro, noi enfatizziamo sul fatto che il sistema di micropagamento Peppercoin si occupa di micropagamenti di taglie diverse in  una maniera liscia ed efficiente. L'unico fattore rilevante è il rapporto fra la taglia del macropagamento e la taglia del micropagamento. Per esempio,  se un macropagamento è da dieci dollari ed un micropagamento è da dieci centesimi, questo  rapporto è uno a cento; in questo caso la procedura di qualifica assicura che  per ogni cento micropagamenti da dieci centesimi, in media,  viene permesso un aggiornamento ad un macropagamento.

 

Varianza di reddito

 

Il commerciante vedrà una riduzione considerevole dei suoi costi per il trattamento delle operazioni, passando dai micropagamenti ai macropagamenti. Ma il commerciante potrebbe avere degli svantaggi dalla procedura di qualifica, per esempio potrebbe capitare che durante un dato  periodo un numero insolitamente piccolo di micropagamenti possa permettere un aggiornamento ad un macropagamento. Ma il costo del risparmio previsto da Peppercoin  prevede  un beneficio per il commerciante su ognuna delle operazioni, e  cresce cumulativamente nel valore in proporzione alle operazioni trattate, andando a sommergere “l'instabilità” nelle decisioni di qualifica.