Acest document este o hârtie tehnică albă și nu un document de ofertă de niciun fel.
Tokenii care sunt descriși aici și care pot fi eliberați de către Companie nu vor fi acțiuni sau valori mobiliare de orice tip. Acestea nu vă vor da dreptul la niciun fel de proprietate sau alt interes în Eventum Limited. Acestea vor fi doar un mijloc prin care veți putea utiliza platforma Eventum care urmează să fie dezvoltată. Nu există nicio garanție că platforma va fi dezvoltată. Nu există nicio garanție că utilitatea Token-urilor sau a proiectului descris aici va fi livrată.
Citiți cu atenție întreaga secțiune Considerații juridice și renunțare la răspundere la sfârșitul acestui document.
Eventum: Platformă pentru fluxurile de date descentralizate din lumea reală
Martin Mikeln, Luka Perović
eventum.network
18 ianuarie 2018
v2.0
Abstract
Lumea a devenit bazată pe date, iar accesul la informații în timp real, care vine adesea prin intermediul unor fluxuri de date externe (adică API-uri), este esențial. Problema este că o cantitate enormă de date din lumea reală din jurul nostru nu este niciodată capturată și transformată într-un API în timp real. Prezentăm proiectarea și implementarea unei noi platforme, numită Eventum, unde adevărul este obținut din mulțime și apoi automat transformat într-un API în timp real. Oricine din lume poate fi plătit pentru ceea ce văd și experimentează, în timp ce dezvoltatorii obțin toate datele pe care le doresc mai ieftin și mai fiabil. Eventum folosește înțelepciunea principiului mulțimii într-o rețea descentralizată de furnizare de date și de validare a nodurilor cu blocuri ca sistem judecătoresc. Ne propunem să oferim un nivel mult mai necesar pentru feed-urile de date sigure, fiabile și ieftine, care nu se bazează pe o singură sursă de adevăr.
Cuvinte cheie: feed-uri de date, în timp real, API, înțelepciunea mulțimilor, rețea descentralizată, blockchain, consens, contracte inteligente, Ethereum, noduri de validare, Swarm
1. Problemă Datele sunt aurul secolului 21 [1] [2] [3] [4]. Pentru a supraviețui și a crește, companiile moderne trebuie să fie bazate pe date și să aibă acces la informații în timp real, adesea prin feed-uri externe de date (API-uri).
Problema este că există o cantitate enormă de date din lumea reală în jurul nostru, care nu pot fi captate și transformate într-un API în timp real. Fie că facem cumpărături pentru o nouă pereche de blugi, luăm un autocolant la un concert, citim cele mai recente știri online, urmărind un joc de fotbal de pe canapeaua noastră sau derulând prin newsfeed-ul Twitter, avem acces la cantități inestimabile de date care nu sunt folosite și imposibil de generat bani.
Mai mult, datele care sunt disponibile prin fluxurile de date sunt adesea nesigure și neconfirmate, deoarece se bazează pe o singură sursă de date susceptibilă la o rată ridicată de erori și eșecuri. Exemple notabile includ: (1) sistemele false de detectare a știrilor, unde este imposibil ca un singur sistem uman sau AI să detecteze fiabil știrile dubioase și să fure în mod fals; (2) un sistem de moderare a conținutului în timp real, în care un comentariu care poate părea potrivit unei persoane ar putea fi semnalat ca rasist de către cineva altceva; (3) perspectiva unilaterală a reporterului asupra evenimentelor din lumea reală, cum ar fi concerte, turnee, conflicte globale, revolte și proteste.
Aproape toate datele API existente în lumea reală sunt controlate strict de o singură companie, care deține un control total asupra datelor și a prețurilor. Aceasta înseamnă că marjele semnificative sunt incluse în prețuri, iar siguranța și integritatea datelor nu pot fi garantate. Un bun exemplu sunt API-urile cu date sportive, care pot depăși sute de mii de dolari pentru un sport pe sezon [5].
Aceasta prezintă un decalaj în mai multe miliarde de dolari [6] [7] [8], unde pe de o parte există o cerere enormă de date fiabile și fiabile de date de la fiecare companie modernă, iar pe de altă parte există peste 2 miliarde de persoane cu smartphone-uri [9] și acces ușor la o parte semnificativă a acestor date, fără nici o modalitate de a le furniza și de a le valorifica.
2. Soluţie O soluție la problemele prezentate mai sus este Eventum. Eventum este o platformă descentralizată, unde adevărul este derivat din mulțime și apoi automat transformat într-un API în timp real. Reporterii sunt plătiți pentru ceea ce văd și experimentează, în timp ce dezvoltatorii obțin toate datele pe care le doresc mai ieftin și mai fiabil.
Înțelepciunea principiului mulțimilor [10] [11] este folosită pentru a determina adevărul din mai multe surse de date (adică oamenii care raportează datele) în loc de o singură sursă de date, care elimină părtinirea și punctul unic de eșec. Acest proces se realizează în timp real printr-o rețea descentralizată de noduri de raportare și validare în sistemul Eventum. Sistemele de criptografie asimetrică și blochează, Ethereum [12], Swarm [13] și Whisper [14], sunt de asemenea utilizate pentru a asigura un sistem sigur și echitabil cu economie de piață liberă.
Eventum este o platformă open-source, extensibilă, cu o interfață API ușor de folosit și un SDK flexibil. Dezvoltatorii pot obține orice date din lumea reală sub forma unui API, fiind de asemenea siguri că datele sunt verificate, adică rezultatul unui consens, pentru care regulile sunt stabilite de către dezvoltatorul însuși. Datele nu pot fi stocate sau controlate de o terță parte și toate fondurile sunt stocate în siguranță în blocul de blocuri. Mai mult decât atât, prețul este guvernat numai de economia de piață liberă, ceea ce înseamnă că există taxe și marje zero la prețul datelor.
Timpul nostru este valabil, iar observațiile și capacitățile noastre cognitive sunt cu mult peste ceea ce este capabil de orice sistem de inteligență artificială. Deci, de ce să nu folosiți acest lucru și să monezi ceea ce vedeți, faceți și experimentați. Când deveniți furnizor de date, furnizați informații prin intermediul unui desktop sau al unei aplicații mobile și obțineți o recompensă dacă sunteți parte a consensului (de exemplu, sunteți de acord cu majoritatea celorlalți reporteri). De asemenea, puteți ajuta rețeaua și câștiga venituri pasive, executând un nod de validare care funcționează ca masternode just-in-time.
3. Cum functioneaza Sistemul Eventum este o punte între furnizorii de date și dezvoltatori. Furnizorii de date au acces la date care sunt valoroase, pe care apoi le raportează printr-o aplicație mobilă / desktop la nodurile de validare din sistemul Eventum. Nodurile de validare așteaptă apoi obținerea unui consens (mai mulți furnizori de date trimit aceleași informații) și apoi trimit aceste date dezvoltatorului sub forma unui API în timp real. Dezvoltatorul blochează o recompensă într-un contract inteligent, care este apoi împărțit și dat la furnizorii de date care au făcut parte din consens. Recompensa este împărțită proporțional cu viteza la care au fost furnizate datele, astfel încât natura API în timp real este stimulată.
Figura 1. Fluxul de date prin rețeaua Eventum
4. Vizualizare arhitecturală Eventum este o platformă construită pe o rețea descentralizată de noduri de raportare și de validare cu bloc de bloc ca sistem judiciar [15]. Platforma este formată din 3 straturi: stratul de bază, stratul de servicii și stratul de aplicație. Atât rețeaua descentralizată a nodurilor, care asigură viteza în timp real, cât și blocul, care asigură soluția de securitate și de plată, sunt strâns integrate în toate cele trei straturi.
Figura 2. Arhitectura pe 3 straturi cu rețea Eventum descentralizată + Ethereum și Swarm
Blocajul este necesar pentru ca platforma să fie sigură și corectă. Este necesar ca economia de piață liberă să funcționeze, fondurile să fie stocate și distribuite în condiții de siguranță, mecanismul de soluționare a litigiilor să fie transparent, sistemul de reputație să funcționeze și ca regulile consensuale să fie stocate în condiții de siguranță. Blocul este, de asemenea, responsabil de guvernanța descentralizată, care este construită în stratul central și supraveghează toate schimbările sistemului. Eventum este agnostic de tip blockchain și poate fi folosit cu orice blocaj care acceptă contracte inteligente, cum ar fi Ethereum, Neo [16] și Lisk [17]. Versiunea Alpha se bazează în prezent pe contracte inteligente de la Ethereum.
În timp ce toate informațiile sensibile sunt stocate pe blocul de blocuri, natura în timp real a Eventum necesită sute de mii sau chiar milioane de tranzacții pe secundă. Acest lucru nu este posibil pe blocul propriu-zis, chiar și cu soluțiile de scalare cum ar fi lanțurile laterale [18] și sharning [19]. Acesta este motivul pentru care raportarea datelor, construirea consensului, calcularea calendarului și a recompenselor, protocoalele de descoperire și rutarea se efectuează off-chain într-o rețea descentralizată a nodurilor Eventum. Toate datele sunt criptate, iar nodurile sunt întotdeauna obligate să convină asupra datelor pe care le primesc și să le trimită (adică atingând consensuri intermediare) astfel încât nodurile malitioase să fie rapid detectate și ignorate.
5. Noduri 5.1. Noduri de validare Nodurile de validare reprezintă partea esențială a rețelei descentralizate Eventum și sunt responsabile pentru captarea datelor, construirea consensului și furnizarea datelor către dezvoltatori. Nodurile de validare câștigă taxe pentru fiecare piesă de date care este procesată corect, fiind, de asemenea, implicată în guvernarea sistemului, unde votul fiecărui nod este ponderat de reputația sa. Aceștia sunt obligați să pună la dispoziție un anumit număr de jetoane EVT pe durata pieței (inclusiv timpul de contestare) pe care îl validează și astfel să acționeze ca masternoide just-in-time. Sunt ușoare și funcționează eficient pe dispozitive mobile.
Pentru a preveni acțiunile rău intenționate, nodurile de validare sunt selectate aleatoriu chiar înainte de crearea pieței, procesează date criptate și fac parte din sistemul de reputație. Deoarece modelul distribuției token este corect (capace personale), centralizarea este de asemenea limitată.
Comunicarea cu alte noduri este o parte crucială a sistemului și se bazează pe o versiune îmbunătățită a algoritmului de bârfe [20], unde trebuie să se ajungă la un consens în mai mulți pași ai protocolului. Un mecanic similar este utilizat și pentru descoperirea și rutarea nodurilor, în timp ce contractele Swarm și inteligente sunt utilizate pentru stocarea altor date (de exemplu lista nodurilor, fluxurile actuale de date, regulile de consens, categoriile și descrierile). Când va fi implementată o versiune stabilă a Whisper (protocol de comunicare pentru DApps), toate comunicările contractuale vor fi făcute astfel.
5.2. Furnizarea de date noduriNodurile de raportare a datelor au o cantitate limitată de comunicare între blocuri și comunicare unidirecțională către nodurile de validare. Aceștia sunt responsabili numai pentru furnizarea datelor către sistem.
6. Contracte inteligente Contractele inteligente sunt responsabile pentru siguranța și corectitudinea evenimentului Eventum și sunt utilizate pentru plasarea, plasarea fondurilor, sistemul de reputație, disputa, mecanismul de revizuire și guvernanța. La crearea pieței, dezvoltatorul se blochează în răsplata sa, împreună cu hash-ul regulilor de consens (care sunt salvate pe Swarm). După procesul de selecție, mai întâi, nodurile de validare sunt adăugate la contract și apoi la furnizorii de date. Un alt set de contracte este utilizat pentru păstrarea și actualizarea scorului de reputație al tuturor nodurilor din sistem și un alt set pentru mecanismul de contestare și revizuire. Modificările la stratul central al arhitecturii Eventum se realizează printr-un sistem de vot descentralizat implementat în setul de contracte responsabile pentru guvernarea sistemului.
7. Autentificare În timp ce Eventum nu impune nicio autentificare în afară de cheia privată / publică asociată cu fiecare nod, ea suportă identificatori de autentificare, care pot fi utilizați în întregul sistem. Aceasta înseamnă că autentificarea poate fi necesară pentru unele (sau toate) părți ale sistemului, care pot fi deosebit de utile pentru a garanta unicitatea voturilor furnizorilor de date. Autentificarea poate fi de asemenea utilă atunci când este necesar un set special de furnizori de date (de exemplu, doar medicii se pot alătura unei anumite piețe). Dacă este posibil, ar trebui utilizat un sistem de autentificare și identitate descentralizat (de ex. Civic [21]).
Dacă se folosește un identificator de autentificare, hash-ul său (care reprezintă persoana și rolurile sale asociate) este utilizat pentru a genera o nouă identitate Eventum. Această informație este legată împreună cu adresa unui nod, cheia criptografică publică și alte informații necesare pentru o comunicare eficientă în interiorul sistemului și scrise într-o listă de noduri publice (care este distribuită tuturor nodurilor din sistem). Integritatea datelor poate fi verificată independent de fiecare client prin compararea listei de noduri cu lista de la alți clienți. Identitatea utilizatorilor poate fi, de asemenea, verificată prin efectuarea unui control retroactiv al identificatorului public cu platforma de identitate. Verificările automate ale identității și ale integrității sunt integrate în sistem, iar orice modificare a informațiilor (de exemplu locația noului nod) poate fi efectuată numai de către proprietarul cheii publice. Schimbarea în sine este propagată prin algoritmul de bârfe către alți clienți.
8. Crearea de piețe Pentru a primi date de la Eventum, un dezvoltator trebuie mai întâi să definească ce fel de date dorește, care sunt regulile consensului și cât de mult este dispus să plătească pentru el. Acest proces se numește generare de piață. Fiecare piață creată poate consta dintr-unul sau mai multe fluxuri de date, în care fiecare feed de date poate fi de tip single event sau de tip cu mai multe evenimente. Fluxul de date constă în unul sau mai multe câmpuri de date care reprezintă un singur raport sau o decizie care trebuie luată de furnizorii de date.
Figura 3. Fiecare piață poate conține fluxuri multiple de date pe care trebuie să se ajungă la consensuri. Se ajunge la un consens cu privire la o colecție de câmpuri de date.
Flexibilitatea lui Eventum îi oferă dezvoltatorilor posibilitatea de a-și păstra datele personale (adică numai aceștia pot debloca datele cu cheia privată), pentru a le deschide tuturor (adică plătesc datele, dar au acces gratuit la rezultatele API-urilor cu toată lumea) fluxul de date cu alți dezvoltatori și taxa pentru o taxă de acces. Partajarea datelor reduce fluxurile de date duplicate și salvează resursele nodurilor.
Un obstacol semnificativ în spațiul de dezvoltare este învățarea noilor feed-uri de date / specificațiile API și adaptarea sistemelor existente pentru a primi datele în formatul specificat. Dacă sistemul trebuie să primească date de la mai multe API-uri, soluția este, de obicei, o arhitectură complexă, care este predispusă la erori, ineficiente și cu cicluri lungi de dezvoltare.
Pentru a rezolva această problemă, Eventum folosește un mic set de câmpuri predefinite și lasă totul dezvoltatorului. Definiția pieței este pur și simplu o specificație JSON a regulilor de consens și a câmpurilor de date, în timp ce datele primite de la nodurile de validare provin direct la webhook definit de dezvoltator (și structura este excactă așa cum a fost definită în definiția pieței). Aceasta înseamnă că dezvoltatorii trebuie doar să definească tipurile de date și să aleagă reguli de consens. O definiție a pieței poate fi generată și printr-un UI simplu, care simplifică în continuare procesul.
Fiecare feed de date trebuie să fie definit de unul sau mai multe tipuri de date acceptate pentru ca furnizorii să ajungă cu succes la un consens. Dacă se utilizează mai multe câmpuri de date, se ajunge la un consens numai dacă toate sunt identice. Tipurile de date de bază acceptate sunt boolean, integer, float și string (cu litere mici). Dezvoltatorii pot folosi, de asemenea, tip de date categorice care pot deține un număr fix de tipuri de date de bază și unde rezultatul este acceptat atunci când unul sau mai multe dintre aceste tipuri de date au o valoare.
Tipuri de date de bază:boolean: tipul valorilor încorporate True and False. Utile în expresii condiționate și oriunde altundeva doriți să reprezentați adevărul sau falsitatea unei anumite condiții.
integer: numere întregi cu cel puțin 32 biți de precizie
float: numere în virgulă mobilă, echivalent cu dublurile C
string: șir de caractere insensibile la caz
categoric: o valoare care deține unul sau mai multe tipuri de date de bază (fixe). Cel puțin una dintre valori trebuie să aibă o valoare.
9. Reguli de consens Cel de-al doilea set de date care trebuie inclus - și este, desigur, parte integrantă a sistemului - conține regulile de consens și parametrii de raportare. Eventum are un algoritm încorporat care întotdeauna calculează și recomandă cea mai bună setare pentru parametrii descriși mai jos, pe baza statisticilor actuale de piață și a tipului de date care sunt raportate, dar parametrii pot fi întotdeauna ajustați manual.
Unii dintre parametri sunt: min_people: numărul minim de persoane care trebuie să se alăture fluxului de date,
max_people: numărul maxim de persoane care se pot alătura feedului de date,
min_consensus: numărul minim de persoane care trebuie să formeze un consens,
consensus_rule: procentajul de voturi care trebuie să fie în aceeași formă cu majoritatea,
consensus_mode: setat la confirmări sau final *,
recompensa: recompensa totală pentru toți participanții care au format consensul,
min_validation_nodes: numărul minim de noduri de validare care primesc și procesează date de la furnizori,
start_dispute_time: timpul petrecut după consens a fost atins atunci când informațiile despre rezultatul sunt trimise unui subset (definit de Z) a persoanelor care nu au ajuns la un consens,
max_dispute_time: intervalul de timp în care oamenii trebuie să deschidă o dispută,
market_join_bonus: bonus care scade recompensa pentru persoanele care s-au alaturat feed-ului devreme,
identitate_hash: identificator de autentificare care poate impune indirect limite pentru persoanele care aderă la fluxul de date, cum ar fi nivelul de țară, vârstă, sex și reputație
K: factor de miză utilizat în calculul participării (C / n * K) care poate fi plătit de către furnizorii de date atunci când se alătură fluxului de date,
categoria / categoria2 / categoria 3: trei niveluri ale categoriilor selectate pentru feedul de date care influențează capacitatea de căutare a hranei pentru date,
rezumat / informații / reguli: identificatori diferiți care explică informațiile și regulile privind feedul de date,
Z: factor de validare încrucișată care definește partea furnizorilor de date care nu au făcut parte din consens și vor primi rezultatul consensului, astfel încât o dispută să poată fi deschisă imediat,
time_to_join: timpul până când utilizatorii pot intra pe piață,
start_event: definește începutul raportării **,
stop_voting: timpul până la care trebuie să se oprească raportarea: acest lucru ar putea fi stabilit de un procentaj din alegători (care trebuie să fie mai mare decât min_consensus) sau de un timbru de timp absolut ***
* Prin setarea consensus_mode la confirmări (implicit), dezvoltatorul poate alege să obțină rezultate imediat după atingerea consensului, primind, de asemenea, confirmări ale consensului (și eventual nou consens care îl înlocuiește pe cel vechi dacă majoritatea se schimbă). Dacă consensus_mode este setat la final, el va primi doar starea finală atunci când este atinsă stop_voting. Prima opțiune este setată implicit, deoarece consensul de schimbări este foarte rar și viteza cu care este livrat consensul este mult mai rapidă în opțiunea implicită.
** start_event ar putea fi dinamic și este în mod implicit definit cu o valoare medie a timbrelor de la voturile consensuale. Dacă opțiunea stop_voting este definită cu o marcă de timp, se poate ajunge la un consens și numai atunci poate fi evaluată o regulă stop_voting. Dacă stop_voting împiedică includerea anumitor voturi în consens, nu se ajunge la un consens și se termină piața; în caz contrar, se ajunge la un consens și datele sunt împinse dezvoltatorului.
Parametrii principali care definesc consensul sunt min_consensus și consensus_rule. Se ajunge la un consens atunci când cel puțin min_consensul furnizorilor de date, care trebuie să reprezinte, de asemenea, un consensus_rule al voturilor, raportează aceleași date.
Exemplu: min_consensus 10, consensus_rule 2/3 -> Se ajunge la un consens dacă 14 din 20 de voturi raportează aceleași date, deoarece 14> 2/3 din 20 14> 10.
{
"datafeeds":[
{
"name": "UCL Final - Ronaldo scores",
"description": "Report when Ronaldo scores its first goal in UCL Final",
"category1" : "Sports",
"category2" : "Football",
"category3" : "UCL",
"min_people": 20,
"max_people": 200,
"min_consensus": 20,
"consensus_rule": 0.66,
"reward_amount": 0.03,
"reward_currency": "ETH",
"stake_K": 1,
"cross_validate_Z": 0.1,
"data_type": "boolean",
"default_value": "None",
"min_validation_nodes": 4,
"start_dispute_time": 7200,
"max_dispute_time": 86400,
"market_join_bonus": 1.1,
"identity_hash": "None",
"reporting_timestamp": 1502944665,
"time-to-join": 1502344665,
"webhook_url": "https://example.com/eventum_api/ronaldo_scores"
....
},
{
"name": "UCL Final - Yellow Card",
...
}
]
10. Mecanismul de recompensare Furnizorii de date raportează informațiile corecte numai dacă sunt recompensați atunci când furnizează aceleași informații ca majoritatea alegătorilor. Recompensa este oferită de dezvoltator care plătește datele verificate, sigure și în timp real de la sistemul Eventum.
Recompensa este blocată în contractul inteligent atunci când piața este creată, împreună cu parametrii feed-ului de date și regulile de consens. Suma recompensei ar putea fi de orice mărime, dar doar oferte competitive vor fi luate pe piața liberă, care este guvernată doar de cerere și ofertă. Deoarece calculul prețului potrivit este greu, Eventum calculează automat prețul optim pentru piață de la parametrii feed-ului de date, regulile de consens și prețurile curente din sistem. Această estimare poate fi ajustată pentru a intra în ecosistem cu mai multe (sau mai puțin) prețuri agresive.
Fiecare furnizor de date care face parte din consens va primi în medie o parte din recompensa egală cu C / n, unde n este numărul furnizorilor de date din consens. Dar, deoarece recompensa este împărțită proporțional cu viteza cu care au fost furnizate datele, cota furnizorului este mai mare sau mai mică decât C / n. Cotele de recompensă sunt distribuite cu o funcție descrescătoare în scădere. Aceasta stimulează natura în timp real a Eventum-ului.
Pentru a împiedica oamenii să ghicească rezultatul pe care trebuie să-l raporteze (și astfel obține o parte mai mare a recompensei pentru a fi mai rapid), dezvoltatorii trebuie să definească datele care trebuie raportate cu proprietăți unice.
Exemplu: Raportarea unui cartonaș galben la meciul de fotbal se poate face în orice moment, deci o opțiune mai bună este să cereți un eveniment de cartonaș galben și minutul în care a fost atribuită cartonașul galben. O opțiune mai bună este de a raporta fotbalistului care a primit cartea.
11. Staking (Furnizori de date) Furnizorii pot fi liberi să se alăture oricărei piețe, pot fi obligați să aibă un anumit nivel de reputație, pot fi forțați să dețină o sumă fixă de jetoane sau poate fi utilizată o abordare hibridă, sub prag. Aceleași mecanisme pot fi folosite pentru a limita votul în sine.
În ambele cazuri, dacă furnizorii de date acționează în mod malefic sau votează altfel decât o majoritate, mizele lor merg la fondul de recompense.
Dacă se folosește mecanicul de plasare, mărimea mizei este C / n * K, unde C este recompensa totală stabilită de dezvoltator, n este numărul actual de persoane care s-au alăturat feedului de date până în prezent și K este factorul de miză setat de dezvoltator (de obicei între 1 și 5).
Pentru a reduce speculațiile de timp și manipulările pieței, dezvoltatorii pot utiliza parametrul market_join_bonus. Este un factor de scalare pentru răsplata pe care fiecare utilizator o primește dacă intră pe piață înainte de a ajunge la min_people. min_people, precum și proporționalitatea inversă a mizelor și a numărului de furnizori de date (numărul mic de furnizori plătește mize mai mari), împiedică grupurile de persoane să profite de fluxurile de date aproape goale și să încerce să forțeze majoritatea fără consecințe.
12. Selectarea nodurilor de validare Când toți parametrii sunt selectați, JSON-ul este salvat pe Swarm, în timp ce hash-ul său și recompensa se blochează la un contract inteligent pe Ethereum. Când se ajunge la max_people sau pass_to_join, nodurile de validare sunt selectate în mod just-in-time și adăugate la contractul inteligent. Deoarece nodurile de validare nu sunt cunoscute în avans, nici dezvoltatorii, nici furnizorii de date nu le pot influența. Nodurile de validare sunt selectate aleatoriu (oricine are șansa egală de a fi selectat) printr-o funcție de blocare care se bazează pe ultimul hash bloc. Aceasta este o metodă sigură pentru generarea de numere aleatorii în cazul Eventum, deoarece valoarea pieței este de obicei mult mai mică decât recompensa minieră, o piață este un lucru de scurtă durată, de obicei durează doar o perioadă de câteva blocuri și deoarece furnizarea de date nodurile nu s-au alăturat încă și astfel piața nu a putut ajunge chiar la min_people.
contract select_validation_node {
/* Select a random validation node with an ID between 0 and 1000 */
function randomNode(uint seed) constant returns (uint randomNumber) {
return(uint(sha3(block.blockhash(block.number-1), seed ))%1000);
}
}
Când este selectat nodul de validare, acesta trebuie să se alăture pieței într-un interval de timp specificat; în caz contrar, începe o căutare pentru un nou nod, până la atingerea min_validation_nodes. Datele despre noua piață sunt apoi propagate prin rețea și notificările sunt trimise tuturor furnizorilor de date abonați
13. Se alătură fluxului de date Furnizorii de date pot descoperi noi piețe prin sistemul integrat de notificări push, dacă sunt abonați la anumiți dezvoltatori, subiecte sau categorii. De asemenea, pot căuta și filtra anumite tipuri de date, evenimente, nume, date și locații. Deoarece prețul este unul dintre cei mai importanți factori, 2 furnizori de date sunt afișați 2 numere: rata medie actuală și rata medie minimă. Rata medie actuală este egală cu rata medie pe care o vor primi dacă nimeni altcineva nu se va alătura pieței. Recompensa minimă este recompensa medie pe care o vor primi în cazul în care numărul maxim de persoane intră pe piață (acest lucru este stabilit de către dezvoltator și este afișat reporterului). În orice caz, aceste numere sunt doar o medie, deoarece recompensele sunt atribuite proporțional cu viteza cu care sunt raportate datele, deci recompensa lor poate fi mai mare (dacă sunt mai rapide decât media reporterului) sau mai mică (dacă acestea sunt mai lente apoi reporterul mediu). Acest lucru contribuie la corectitudinea sistemului și este o inițiativă excelentă pentru reporteri să acționeze și să raporteze rapid, acordându-le în același timp o estimare bună a recompensei pe care o vor primi.
În cazul în care activarea este activată și furnizorul de date se alătură înainte ca numărul minim de persoane să fie atins așa cum se specifică în min_people, el plătește C / min_people * K altfel el plătește C / n * K. Miza se întoarce după ce evenimentul sa încheiat și timpul de dispută a trecut (start_dispute_time + max_dispute_time) fără ca litigiile să fie deschise sau până când toate litigiile sunt rezolvate. Dacă nu trimite datele cu care majoritatea a fost de acord sau încearcă să manipuleze piața într-un alt mod, miza lui este luată și pusă în rezervă, iar reputația sa este redusă.
Furnizorii de date au timp să se alăture fluxului de date și să trimită miza până când trece time_to_join. Ei trebuie, de asemenea, să treacă orice criteriu, așa cum se specifică prin identitatea_hash. Dacă se vor alătura înainte de atingerea valorii min_people, nivelul lor de bază va fi majorat cu suma market_join_bonus. Deoarece aderarea la piață înseamnă adunarea la contractul inteligent, timpul tranzacției cu blochează trebuie luat în considerare.
14. Raportarea datelor Evenimentul poate avea un timp de start definit (definit prin marcajul temporal salvat în parametrul start_event) sau poate fi nedefinit, iar furnizorii de date raportează informațiile atunci când o au. În ultima versiune, start_event este definită cu o valoare mediană a timestampurilor din voturile consensuale. Cu cheia publică a dezvoltatorului, datele criptate sunt trimise la nodurile de validare, care pot acum, într-o manieră complet descentralizată, să compare rezultatele și să voteze ceea ce majoritatea consideră că sunt datele corecte. Ei au, de asemenea, lista completă a tuturor furnizorilor de date care participă (pe care le pot verifica mereu în contractul inteligent fără taxe) împreună cu datele raportate, astfel încât să poată verifica dacă numai persoane înregistrate le transmit date.
În cazul în care raportul dintre furnizorii de date și nodurile de validare nu este echilibrat (de exemplu un număr considerabil mai mare de furnizori de date), furnizorii de date (n) aleg un subset de noduri de validare aleatoriu (adică I3) din toate nodurile trimite votul. Aceste noduri folosesc algoritmul de bârfe pentru a-și spune reciproc despre voturile pe care le cunosc. Ei acceptă votul ca fiind adevărul, atunci când îl primesc de la majoritatea altor noduri de validare. Dacă nodurile selectate inițial nu răspund, furnizorii de date aleg noi. Nodurile de validare pot reduce cantitatea de conexiune de la furnizorii de date la n la fiecare nod de validare la (n / m) * I în cel mai bun caz, ceea ce reduce foarte mult sarcina pe nodurile de validare. Algoritmul de alfabetizare este O (log n) rapid, deci informația călătorește extrem de repede pentru m scăzut (care va fi de obicei cazul). Această reducere I, desigur, scade acuratețea calculului latenței medii (mai ales dacă unul sau mai mulți dintre nodurile de validare I nu sunt disponibile și furnizorul de date trebuie să trimită votul la un nou nod).
Nodurile de validare acceptă date atâta timp cât nu primesc aceleași date (de exemplu aceleași răspunsuri / informații) de la cel puțin un număr de min_consensus de furnizori de date, care trebuie să reprezinte și consensul_rul al voturilor, cu alte cuvinte n [data]> consensus_rule * n> min_consensus. De îndată ce fac acest lucru (și ei sunt de acord între ei cu o regulă de consens), aceștia trimit informații despre consens dezvoltatorului, împreună cu lista utilizatorilor care au ajuns la acest consens și latențele lor, ambele supuse ⅔ acord între nodurile de validare. Datele noi care vin după min_consensus sunt de asemenea transmise dezvoltatorului și servesc ca o confirmare a deciziei min_consensus (de exemplu, 87% dintre alegători sunt, de asemenea, de acord cu min_consensus). În cazul în care noi voturi vin în schimbarea majorității consensus_rule cu cel puțin un număr de voturi min_consensus, consensul inițial este anulat, corecția automată este trimisă dezvoltatorului și persoanelor din consensul inițial, mizele și reputația. Dacă se atinge opțiunea stop_voting, încep să răspundă cu stop_broadcast, iar furnizorii opresc trimiterea datelor. Nodurile de validare pot apela acum contract inteligent (de fapt, votează unul dintre ei pentru a face acest lucru, altele apoi verificați) pentru a aloca mize tuturor furnizorilor de date care au făcut parte din consens. Mizele sunt atribuite după o perioadă de grație (de exemplu, 2 ore după încheierea consensului, astfel încât litigiile pot fi deschise) și numai dacă majoritatea nodurilor de validare atribuie acelorași participanți aceleiași structuri de participare, recompensele sunt atribuite, nodurile de validare sunt validate taxele și dezvoltatorii primesc miza înapoi.
Fiecare feed de date poate fi, de asemenea, setat ca un tip de eveniment multiplu. În acest caz, nodurile de validare urmăresc numărul de rundă și difuzează evenimentul next_round furnizorilor de date. Evenimentele multiple se încheie atunci când: fie se ajunge la un consens pe un stop_votat (de exemplu, într-un meci de fotbal oamenii raportează noi fauluri până se termină jocul și ajung la un consens privind un eveniment care se încheie) în cazul în care există un eveniment la care oamenii raportează, toată lumea primește o recompensă ca și cum ar ajunge la un consens), se ajunge la max_rounds sau când se ajunge la max_time. Deci, un eveniment de tip multiple se comportă la fel ca o serie de evenimente unice cu un mecanic special pentru a pune capăt pieței.
{
"data":[
{
"event_id": 10510252,
"event_name": "Super Bowl LII - Report a touchdown",
"description": "Touchdown, Super Bowl LII, 4/2/2018",
"consensus_rules": "cc13fdfc9c5ca32a7bcd2ab7146c07db9fb5c9f34e3b159408f684",
"contract": "0x24528467dfdabaef3fba7ad5796e39cfa9a99201",
"category1" : "Sports",
"event_start": 1517788800,
"event_end": 1517846400,
"event_ended_by": 3,
"event_state": 3,
"event_nonce": 2,
"consensus": 1,
"consensus_reached_in": 5,
"consensus_value": "86f1d0C35E40DbC027d205C3C1a73727C7d3C4C9511ec6021bd8",
"consensus_changed": 0,
"number_of_providers": 24,
"consensus_size": 19,
"validation_node": "0xhucc4bd8ee760243dbbf815511ec161d1cd6957d8",
"average_reputation": 3.45
}
]
}
15. Plăți și litigii Fiecare furnizor de date care face parte din consens obține răsplata sa, care este egală cu C / n * speed_factor, în care speed_factor ajustează exponențial răsplata în sus sau în jos față de media C / n. Aceasta înseamnă că, dacă furnizorul de date este destul de rapid, el poate obține exponențial mai mult decât rata medie. Recompensa poate, desigur, să fie și mai mare dacă furnizorul de date a intrat în feedul devreme și a achiziționat market_join_bonus, care este un multiplicator adăugat la calculul C / n * speed_factor. Dacă miza a fost utilizată, recompensa totală este diferența dintre C / n * speed_factor * market_join_bonus și miza care devine returnată (C / n * K).
15.1. Recompensă piscină Dacă furnizorul de date nu face parte din majoritate, el își pierde miza și toate fondurile ajung la fondul de recompense care este folosit pentru recompensele acordate nodurilor care rezolvă cu succes diferendul. Dacă biliardul de recompense este umplut peste un anumit nivel, partea rămasă ajunge la toți participanții la sistem care au un nivel pozitiv de reputație - aceasta funcționează ca un venit pasiv pentru toți cei care participă la sistem în conformitate cu regulile.
15.2. Reputatie Răsplata scăzută cu aer este redusă proporțional cu nivelul de reputație al destinatarului. Reputația este obținută prin respectarea regulilor sistemului (raportarea datelor cu majoritatea, având un timp bun de funcționare a nodului de validare, rezolvarea disputelor etc.) și pierderea prin joc împotriva sistemului. Fiecare participant începe cu un scor de reputație de 3.
Nivelul redus de reputație limitează feedul de date pe care vă puteți alătura, recompense pasive, taxe de nod validare și alte beneficii. Având un nivel redus de reputație pentru o perioadă lungă de timp, rezultă un steag la nivel de sistem. Sistemul de reputație este încorporat la cel mai scăzut nivel al protocolului și este implementat în contractele inteligente și Swarm.
Reputația este implementată ca sistem de stivuire pe mai multe niveluri. Sunt acordate mici sancțiuni (f -0,5) furnizorilor de date care intră pe piață, dar nu raportează datele. Sunt acordate sancțiuni medii (f -1) furnizorilor de date care au votat, nu au făcut parte din consens, ci se află în trei abateri standard ale mediei de la start_event (dacă nu sunt implementate cu marcajul temporal). Sunt acordate mari sancțiuni (f -3) furnizorilor de date care au votat, nu au făcut parte din consens și s-au aflat în afara celor trei deviații standard ale mediei de la start_event (ceea ce probabil înseamnă că au jucat jocuri de noroc și au încercat să prezică rezultatul piaţă). Un multiplicator este adăugat variabilei f pentru fiecare încălcare. Scorul de reputație poate crește, desigur, ceea ce înseamnă că dacă sunteți un participant cu reputație în sistem, vă puteți permite mai multe erori.
15.3. Conflicte Eventum este un sistem de auto-convergență care, în aproape toate cazurile, oferă adevărul. Cu toate acestea, pot exista cazuri în care un grup mare de persoane formează un consens, dar votul lor sa bazat pe informații false (intenționat sau neintenționat). Pentru a diminua acest risc, dezvoltatorii pot defini un factor Z care definește procentul furnizorilor de date care nu au format majoritatea vor primi o notificare că datele lor nu au fost acceptate ca fiind corecte. Procentul furnizorilor de date care primesc această notificare este mărit exponențial (de exemplu, dacă 96 din 100 de persoane ajung la un consens, toate cele 4 vor primi notificarea).
Nodurile de validare trimit această notificare după ce trece start_dispute_time. Fiecare furnizor de date care primește această notificare poate să nu fie de acord cu rezultatul pieței și să deschidă o litigiu. Trebuie să-și împartă un număr mare de jetoane (suma exactă depinde de nivelul de reputație), care îi revine în cazul în care disputa are succes. Evenimentul de litigiu este difuzat către alți furnizori de date care sunt abonați la fluxuri de date similare (aceeași categorie, evenimente similare, ...), care acum pot câștiga o recompensă pentru o soluționare pozitivă a litigiilor. Noi furnizori de date (u) sunt recrutați pentru soluționarea litigiilor până când formează un grup (împreună cu persoanele care au format o minoritate (n)) cel puțin la fel de mare ca și cei care au format majoritatea (m) în raportul original de date : n + u> = m. Dacă n + u decide cu 100% că m a avut dreptate (sau numai u este de 2/3 sau mai mult încrezător că m avea dreptate), litigiul este răsturnat și jetoanele de la persoana care a deschis contestația se adresează tuturor celor care au ajutat să decidă rezultatul (împreună cu recompense suplimentare de la fondul de recompense). Persoana care a deschis litigiul pierde și reputația. Dacă n + u este de acord cu o majoritate de 2/3 că m a fost greșit, jetoanele de la m merg la n + u (împreună cu recompense suplimentare din fondul de recompense și o recompensă mai mare pentru furnizorul de date care a deschis litigiul).
15.4. Vânzarea datelor Pentru ca mecanismul de litigiu să funcționeze, furnizorii de date trebuie să trimită rezultatul consensului la cel puțin unii dintre furnizorii de date care au raportat datele.
Ele trimit rezultatul la Z% din persoanele care nu au fost incluse în consens după start_dispute_time. Z și start_dispute_time sunt setate de dezvoltator (de ex. Z 30%, start_dispute_time 30min). Cu acești doi parametri, dezvoltatorul controlează cât de puternic crede în rezultatul consensului (cât de repede dorește să primească litigiul dacă ar putea fi unul, ceea ce ar putea însemna că datele originale pe care le-a primit greșit) și cât de repede și cât de ușor / primiți informații despre rezultatul consensului (de exemplu, care este valoarea rezultatului de consens pentru dezvoltator în timp definit de start_dispute_time), ceea ce înseamnă, în schimb, cât de ușor este ca furnizorii de date să vândă informații consensuale clienților terță parte chiar și atunci când votează aleator . Dezvoltatorul controlează, de asemenea, K, care definește miza care, la rândul său, diminuează rentabilitatea furnizorilor de date de a vinde / împărtăși rezultatele consensului. Persoanele care au greșit pot contesta până la max_dispute_time. După ultimul eveniment (în cazul unei piețe de tip eveniment cu mai multe evenimente) se încheie, se adaugă max_dispute_time și, dacă nu există niciun litigiu, se iau recompense / mizele.
Să aruncăm o privire la cineva care încearcă să vândă date consensuale cu următoarele seturi de variabile: C / n $ 1, K 3, Z = 20%, piața deciziei binare. Valoarea estimată sau câștigul (E) atunci când joacă corect este $ 1, E când jocul este aleatoriu - $ 1, în cazul vânzării datelor consensuale, prețul de vânzare trebuie să fie mai mare de 15 $ pentru a fi profitabil pentru atacator și 25 $ sau mai mult dacă atacatorul vrea să fie mult mai profitabil decât să joace echitabil (dacă presupunem că jucătorul corect cunoaște întotdeauna răspunsul, formează majoritatea și nu este suficient de repede pentru a primi o recompensă mai mare decât reporterul mediu (deci nu primește bonusul speed_factor) și nici că primește bonus de înscriere pe piață , care ar putea adăuga toate la câștigurile sale). Aceasta presupune că atacatorul poate să vândă datele, chiar dacă știe că, jucând la întâmplare, are doar 10% șansă să obțină datele deloc (care dezvoltatorul poate scădea și mai mult prin scăderea lui Z), ceea ce este greu (sau cel mai probabil imposibil) de a vinde. Mai mulți oameni sunt pe piață, mai mulți dezvoltatori pot scădea Z și totuși să fie siguri că sunt destui oameni care vor începe diferendul dacă este necesar - la Z = 5%, atacatorul este profitabil la 60 $ și mai profitabil decât să joace la 100 $.
Deoarece dezvoltatorul poate crește și start_dispute_time, datele trebuie să fie valoroase chiar și după trecerea timpului, ceea ce, dacă dezvoltatorul alege cu înțelepciune, diminuează (sau anulează) valoarea datelor cu totul altceva.
Dacă dezvoltatorul ridică factorul K, el poate scădea E pentru atacator chiar mai departe. Deoarece atacatorul este marcat după ce X de ori joacă împotriva pieței și identitatea sa este probabil verificată, el nu are nici o inițiativă de a începe chiar un atac de acest gen chiar dacă toți ceilalți factori sunt de partea lui.
Exemplu pentru date valoroase, min, dar min mici, C / n $ 10, K 6, Z 3%, start_dispute_time 1h, marcate 3: atacatorul trebuie să poată vinde date consensuale vechi de o oră în timp ce are șansa de a primi consensul de 1,5% rezultă deloc și are nevoie să-l vândă pentru cel puțin $ 2000 pentru a fi profitabil. Asta este, bineînțeles, statistic bun pentru el, dar el va trebui să voteze în mod aleatoriu mai mult de 66 de ori înainte de a primi date consensuale și să-l vândă pentru 2000 de dolari, dar pentru că devine semnalat după 3 ori de joc pe piață greșit, nu există nici un fel pentru ca el să facă un atac ca acesta.
15.5. Sistemul de revizuire Pentru a reduce în continuare șansa furnizorilor frauduloși de a intra colectiv pe piață și de a ajunge la un consens cu privire la unele date aleatorii, este inclus un sistem de revizuire în stratul de servicii al Eventum, unde un set de algoritmi AI încearcă să recunoască comportamentul necinstit și întreabă utilizatorii aleatorii (de preferință pe piețe similare sau cu aceleași cerințe) pentru a confirma rezultatul pieței suspecte înainte de data limită a litigiului. Acești comentatori primesc, de asemenea, o recompensă specială din fondul de recompense pentru a examina și (opțional) contestația deschisă. Sistemul de examinare utilizează mulți parametri diferiți pentru a recunoaște comportamentul suspect, inclusiv statisticile de rețea (latențe, originile nodurilor ...) și analiza comportamentului (modele de vot similare, aceleași piețe ...).
16. Modelul Token Nodurile de validare câștigă taxe pentru captarea, procesarea și furnizarea corectă a datelor în jetoanele Eventum (EVT). Tokenul este utilizat și în mecanismul de plasare, sistemul de reputație, litigiile și guvernanța. EVT este o parte esențială a platformei și combină cele mai importante părți ale sistemului. Deoarece fiecare piesă de date care trece prin sistem este conectată la un token care este plătit ca o taxă pentru nodurile de validare, utilizarea sporită a sistemului crește cererea pentru token-uri.
Toate jetoanele EVT vor fi sortate și distribuite în evenimentul de generare a jetoanelor (TGE), iar suma totală a acestora nu se poate schimba.
Utilizatorii platformei Eventum care creează piețe (dezvoltatori) plătesc o taxă pe baza valorii datelor validate. Nodurile de validare sunt apoi plătite pentru validarea acestor date și care acționează ca un intermediar între reporterii de date și dezvoltatorii care furnizează securitate în rețea.
Taxa de validare este aproximată în momentul creării pieței. Deoarece aproximările pot fi dezactivate, platforma cere dezvoltatorului să blocheze X de ori mai mare decât suma aproximată. Taxele folosite pentru plata nodurilor de validare sunt stabilite de propriii proprietari ai nodurilor de validare. Fiecare validator poate decide care este taxa minimă pe care sunt dispuși să o valideze. Această dinamică de piață forțează piața de validare să se străduiască și să atingă echilibrul dintre cerere și ofertă. Dacă taxa minimă necesară pentru validarea datelor este modificată în timpul evenimentelor, dezvoltatorul poate crește / micșora taxa. Această creștere / scădere a taxelor poate să apară în mod automat sau manual de către dezvoltator (se poate opta pentru a fi notificat despre aceste modificări).
În timp ce taxele sunt plătite în principal în EVT, este posibil să se utilizeze și alte jetoane ERC-20. Pentru a stimula utilizarea jetonului nostru și a ne asigura că nodurile de validare sunt încă plătite în mod constant în EVT, toate celelalte jetoane ERC-20 vor fi schimbate automat la EVT pe schimburile descentralizate. În plus, plata taxelor cu alte jetoane ERC-20 va crește taxa pentru N% (N niciodată sub 1%). N se calculează pe baza numărului de dezvoltatori care decid să utilizeze alte jetoane ERC-20 pentru a plăti taxele, crescând atunci când raportul crește și scade când scade. Acest mecanic păstrează tokenul viabil și ușor de utilizat, permițând în același timp dezvoltatorilor să folosească alte jetoane dacă aleg. Diferența dintre alte plăți cu jetoane ERC-20 și EVT este trimisă la pool-ul de recompense.
Literatură[1] Connie Crosby (2011). Importanța știrilor și informațiilor în timp real. legătură
[2] James Cotton (2014). Date: importanța legăturii de precizie, integritate și integrare în timp real
[3] Watson, Hugh J. și colab. Afaceri inteligente în timp real: cele mai bune practici la Continental Airlines. Managementul sistemelor informatice 23.1 (2006): 7.
[4] Watson, Hugh J. și Barbara H. Wixom. Starea actuală a serviciilor de informații de afaceri. Computer 40.9 (2007).
[5] Sportradar AG, link
[6] Gartner, Inc. (2017). Gartner declară că Business Intelligence și Piața Google Analytics vor atinge 18,3 miliarde de dolari în 2017
[7] Știri PennState (2011). Piața de căutare în timp real în valoare de peste 30 milioane USD pe zi
[8] George Collins, director, Deloitte Consulting LLP și directorul departamentului de tehnologie, Deloitte Digital US, The Wall Street Journal (2015), Companiile care evaluează valoarea afacerii API-urilor
[9] Statista Inc. (2017). Numărul utilizatorilor de smartphone-uri din întreaga lume în perioada 2014-2020
[10] Vitalik Buterin (2014). SchellingCoin: Un link minimal-fiabil pentru feed-uri universale
[11] James Surowiecki (2005). Înțelepciunea mulțimilor, 978-0-385-50386-0
[12] Fundația Ethereum, legătură
[13] Roi, legătura
[14] Șoaptă, legătură
[15] Descentralizarea Totul cu Vitalik Buterin de la Ethereum Întrerupeți SF 2017, link
[16] NEO, link
[17] Lisk, legătură
[18] Lănțișoare laterale, legătură
[19] Strângere în Ethereum, legătura
[20] Șah, Devavrat. Algoritmi de alfabetizare. Fundamente și tendințe în rețea 3.1 (2009): 1-125.
[21] Civic, legătură
Considerații juridice și renunțare la răspundere Informațiile prezentate în secțiunea Considerații juridice și renunțări la răspundere juridică nu sunt exhaustive și nu implică niciun element al unei relații contractuale. Cu toate că depunem toate eforturile rezonabile pentru a ne asigura că informațiile furnizate în acest document sunt exacte și actualizate, aceste materiale nu constituie în niciun caz consiliere profesională. Persoanele care intenționează să participe la orice eveniment de generare de jetoane trebuie să solicite consultanță profesională independentă înainte de a acționa.
CONSIDERAȚII LEGALE Compania va face eforturi rezonabile pentru a aborda orice eveniment de generare de jetoane într-o manieră responsabilă și sensibilă. Având în vedere incertitudinea juridică a tehnologiilor distribuite, a întreprinderilor și a activităților, precum și a criptocurităților și a afacerilor și activităților legate de criptare, într-o serie de jurisdicții, compania a petrecut timp și resurse pentru a-și lua în considerare abordarea sa de afaceri și unde propune să funcționeze acum și în viitorul. Este posibil ca jetoanele Companiei care fac obiectul oricarui eveniment de generare de jetoane (Token-urile) să poată cuprinde o garanție în jurisdicția dvs. sau oferta de vânzare de către Companie a Token-urilor din jurisdicția dvs. poate fi o activitate reglementată sau interzisă. Compania nu acceptă nicio responsabilitate sau răspundere față de dvs. în aceste sau în alte circumstanțe. Vă recomandăm cu tărie să luați consultanță juridică independentă cu privire la legalitatea în jurisdicția dvs. cu privire la orice participare din partea dvs. la orice eveniment de generare a jetoanelor și la achiziționarea de către dvs. a oricăror mărci de identificare.
Token-urile vor fi jetoane de utilitate funcționale concepute pentru a fi utilizate numai pe platforma de afaceri a companiei, care urmează să fie dezvoltată. Tokenii nu sunt și nu vor fi titluri de valoare. Nu se preconizează că societatea va lua în mod activ orice măsuri pentru a face Tokenul tranzacționat pe orice piață reglementată sau nereglementată sau primară sau secundară. În cazul în care achiziționați Token, achiziția dvs. nu poate fi rambursată sau schimbată. Token-urile nu vă dau dreptul la niciun fel de drepturi de proprietate, de guvernare, de vot sau de drepturi sau drepturi similare în cadrul Companiei sau în oricare dintre companiile afiliate acesteia. Token-urile vor fi vândute ca produse digitale, similare cu software-ul descărcat, muzică digitală și altele asemenea. Nu ar trebui să luați în considerare Token-urile de cumpărare decât dacă aveți experiență anterioară cu jetoanele criptografice, software-ul bazat pe blocheți și tehnologia distribuită a cărților și dacă nu ați primit consultanță profesională independentă.
NU sfaturi Nici o parte a informațiilor de aici nu ar trebui să fie considerată consultanță în afaceri, juridică, financiară sau fiscală cu privire la Companie, la Token sau la orice eveniment de generare de jetoane. Ar trebui să vă consultați propriul dvs. consultant juridic, financiar, fiscal sau alt profesionist cu privire la orice informații de aici. Ar trebui să știți că vi se poate solicita să suportați riscul financiar al oricărei achiziții de Token pentru o perioadă nedeterminată de timp.
LIMITARE A RĂSPUNDERII În nici un caz nu va fi responsabil sau răspunzător sau răspunzător Compania sau vreunul dintre angajații, funcționarii, directorii, partenerii, administratorii, reprezentanții, agenții, consilierii, contractanții sau voluntarii lor (în continuare Reprezentanții Companiei) în orice mod, către orice cumpărător al oricăror mărci de valoare pentru orice pierdere de orice natură care decurge din sau din sau în legătură cu cumpărarea oricăror mărci de credit, cu excepția celor specificate explicit în termenii legați de o astfel de achiziție .
Informațiile conținute aici și Token-urile sunt furnizate într-un mod așa cum este și fără nici o declarație sau garanție de niciun fel, expresă sau implicită. Vă asumați toată responsabilitatea și riscul cu privire la utilizarea de către dvs. a informațiilor conținute aici și în altă parte și a achiziționării oricărei cantități de Token și a utilizării acestora. Dacă legea aplicabilă nu perm
