Questo post illustrerà come scrivere uno smart contract che effettua un “dominant assurance contract”.
Le raccolte fondi tramite contratti di assicurazione come nelle campagne di Kickstarter soffrono spesso per scarsa partecipazione, nelle quali le persone che valutano il bene proposto non contribuiscono ai finanziamenti poiché esse si aspettano che il goal venga raggiunto senza il loro contributo, o perché essi dubitano della sua riuscita e non vogliono partecipare ad un tentativo fallito.
La “non partecipazione” fa aumentare il rischio che una campagna fallisca. Alex Tabarrok ha inventato i “dominant assurance contract” per rispondere a questa preoccupazione.
I dominant assurance contract necessitano di una piattaforma per conservare il denaro che viene pagato ai partecipanti di una campagna fallita. Questa ricompensa è proporzionale al pegno iniziale.
Per esempio, se un sostenitore mette in gioco una ricompensa del 10%, allora tutti i partecipanti di una campagna fallita verranno rimborsati con un 110% delle loro quote.
La motivazione è rappresentata dal fatto che adesso i partecipanti ne traggono vantaggio in ogni caso – o ricevono un bonus se la campagna fallisce, oppure il bene valutato è ottenuto se la campagna ha successo.
Rivendicare la ricompensa
Eseguire un contratto di assicurazione tramite uno smart contract è abbastanza semplice. Modificare quel codice per eseguire un dominant assurance contract richiede solamente un pò di logica in più.
Il contract verrà parametrizzato per la lunghezza della campagna misurata in giorni, l’importo del goal e la percentuale della ricompensa per i partecipanti se il goal non dovesse essere raggiunto.
Lo smart contract controllerà alcuni semplici valori:
–totalPledges controllerà il totale dell’importo impegnato basandosi sul balance dell’indirizzo al quale, tramite smart contract si inviano i soldi.
–balance0f mapping controllerà l’importo di ether da rimborsare agli account nel caso di fallimento della campagna.
Inizialmente balance0f [owner] sarà fissato a tutti gli ether in deposito di garanzia che vengono trasferiti quando il contract viene attivato. L’importo verrà ridotto nel momento in cui vengono fatti i pegni.
Pegni
Il contratto accetta pegni ed ether associati:
Il contratto contabilizza gli ether impegnati aggiornando sia totalPledges che balance0f [sender].
Contabilizza anche l’importo implicito della ricompensa trasferendo il saldo di ether dal proprietario al mittente.
E’ possibile che il contratto esaurisca i fondi per le ricompense, così il contratto evita il rischio di sotto-eccedenza controllando il saldo disponibile dei proprietari.
Questo rischio si presenta in due diversi scenari: quando viene impegnato un importo superiore a quello previsto, o quando non c’è una ricompensa sufficiente depositata in garanzia.
Il primo è una buona notizia (ma va gestito) ed il secondo potrebbe essere fatto di proposito e ne parleremo più avanti.
Post-campagna
La logica per gestire i trasferimenti post-campagna è esattamente la stessa del’assurance contract semplice:
Anche se la logica è la stessa, diventa un pò più delicato per quanto riguarda le ricompense.
–claimFunds è semplice perché tutti i fondi, che siano fondi impegnati o ricompense in deposito di garanzia, vanno al proprietario nel momento in cui la campagna è riuscita.
–getRefund è semplice perché il lavoro complicato di controllare i pegni e le ricompense viene effettuato su pledge.
Allo stesso modo, tutti i fondi delle ricompense in deposito di garanzia rimanenti/in eccesso compariranno su balance0f [owner], il che vuol dire che il proprietario può anche utilizzare getRefund per rivendicare quei fondi in eccesso.
Insufficiente ricompensa in deposito di garanzia (funzione)
Da notare che il costruttore non chiedeva al proprietario di depositare in garanzia gli ether sufficienti per coprire una campagna fallita.
Poiché le variabili di deposito sono pubbliche, è irrilevante determinare la quantità sufficiente degli ether in deposito di garanzia (su balance0f [owner] ).
Questo conferisce ai sostenitori la flessibilità per utilizzare un contratto con soltanto una ricompensa parzialmente finanziata.
Questo vorrebbe dire che i primi creditori avrebbero diritto ad una ricompensa in caso di fallimento, ma i creditori che arrivano dopo no.
Questo potrebbe essere un punto di progetto interessante per le campagne che vogliono incoraggiare i primi creditori.
In sintesi
–I dominant assurance contracts possono essere facilmente eseguiti con smart contracts.
–La funzione ricompensa presenta soltanto un pò più di complessità.
Il contratto completo
Commenti