{"id":33888,"date":"2019-10-31T21:55:15","date_gmt":"2019-10-31T18:55:15","guid":{"rendered":"https:\/\/prohoster.info\/blog\/sluchajnye-chisla-i-detsentralizovannye-seti-implementatsii\/"},"modified":"2019-10-31T21:55:15","modified_gmt":"2019-10-31T18:55:15","slug":"sluchajnye-chisla-i-detsentralizovannye-seti-implementatsii","status":"publish","type":"post","link":"https:\/\/prohoster.info\/it\/blog\/administrirovanie\/sluchajnye-chisla-i-detsentralizovannye-seti-implementatsii","title":{"rendered":"Numeri casuali e reti decentralizzate: implementazioni","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Introduzione<\/h1>\n

<\/p>\n

function getAbsolutelyRandomNumer() {\n        return 4; \/\/ returns absolutely random number!\n}<\/code><\/pre>\n
<\/p>\n
Come nel caso del concetto di cifratura assolutamente resistente della crittografia, i protocolli reali \"Publicly Verifiable Random Beacon\" (di seguito PVRB) cercano solo di avvicinarsi il pi\u00f9 possibile a uno schema ideale, poich\u00e9 nelle reti reali non \u00e8 applicabile in modo puro: \u00e8 necessario accordarsi su un singolo bit, ci devono essere molti turni e tutti i messaggi devono essere estremamente veloci e sempre consegnati. Ovviamente, nelle reti reali non \u00e8 cos\u00ec. Pertanto, nella progettazione di PVRB per compiti specifici nei blockchain moderni, oltre all'impossibilit\u00e0 di controllare il random ottenuto e alla resistenza crittografica, emergono anche molti problemi puramente architettonici e tecnici.<\/p>\n
<\/a><\/noindex><\/p>\n
Il blockchain stesso funge essentially da ambiente di comunicazione per PVRB, in cui i messaggi = transazioni. Questo consente di astraersi parzialmente dai problemi di rete, dalla mancata consegna dei messaggi e dai problemi del software intermedio: tutti questi rischi vengono assunti dalla rete decentralizzata, e il suo valore principale per PVRB \u00e8 l'impossibilit\u00e0 di revocare o danneggiare una transazione gi\u00e0 inviata, il che non consente ai partecipanti di ritirarsi dal protocollo, a meno che non abbiano effettuato un attacco di successo al consenso. Tale livello di sicurezza \u00e8 accettabile, quindi PVRB deve essere resistente ai collusioni dei partecipanti nella stessa misura della catena principale del blockchain. Inoltre, questo suggerisce che PVRB deve far parte del consenso, se la rete ha concordato sulla catena principale di blocchi, affinch\u00e9 possa concordare anche su un singolo random risultante onesto. Oppure, PVRB \u00e8 semplicemente un protocollo standalone, implementato tramite contratto intelligente, che opera in modo asincrono rispetto al blockchain e ai blocchi. Entrambi i metodi hanno i loro vantaggi e svantaggi, e la scelta tra di essi \u00e8 estremamente non banale. <\/p>\n
<\/p>\n
Due modi di implementare PVRB<\/h2>\n
<\/p>\n
Descriviamo in dettaglio due varianti di implementazione di PVRB: la versione standalone, che funziona utilizzando un contratto intelligente indipendente dal blockchain, e la versione integrata nel consenso, secondo la quale la rete concorda sulla catena di blocchi e sulle transazioni incluse. In tutti i casi, terr\u00f2 presente i popolari motori blockchain: Ethereum, EOS, e tutti quelli simili nel modo di ospitare e processare contratti intelligenti. <\/p>\n
<\/p>\n
Contratto autonomo<\/h3>\n
<\/p>\n
In questa versione, PVRB rappresenta un contratto intelligente che accetta transazioni da random-producer (di seguito RP), le elabora, combina i risultati e, di conseguenza, giunge a un valore che pu\u00f2 essere ottenuto da qualsiasi utente di questo contratto. Questo valore potrebbe non essere memorizzato direttamente nel contratto, ma essere rappresentato solo da dati da cui si pu\u00f2 determinare in modo univoco un solo valore del risultato casuale. In questo schema, gli RP sono gli utenti della blockchain, e chiunque pu\u00f2 essere coinvolto nel processo di generazione.<\/p>\n
<\/p>\n
Questa opzione del contratto autonomo ha vantaggi:<\/p>\n
<\/p>\n