Subiectivitate în oracole

(Tellor Core) (15 dec.2020)

Subiectivitate, ambiguitate și oracole descentralizate

Într-o clipă, hacks de protocoale financiare sau neînțelegeri ale funcționării interne a unui contract financiar pot duce la pierderi uriașe, cu recursuri deseori puține . Fie că este vorba de produse financiare tradiționale care s-au stabilit în LIBOR, comercianții care au văzut țițeiul devin negativ pentru prima dată în istorie anul acesta [1] sau un contract de instrumente financiare derivate care lichidează hedgers nebănuși, prețul de decontare sau manipularea oracolului a fost un lucru cu mult înainte de Vitalik și împrumuturi flash.

Modul în care este structurat oracolul dvs. și datele pe care le recuperați sunt specificații cruciale atunci când creați un produs financiar robust. Întrebarea aparent simplă de „ce preț folosiți?” este orice altceva decât. Nuanța implicată în selectarea definiției corecte a ceea ce este adevărul în ceea ce privește contribuția dvs. are implicații de securitate care vor afecta fiecare aspect al produsului dvs.

Oracolul non-problem

Când plasați un preț de decontare pe un blockchain, aveți două componente:

– Cum să obțineți it on-chain

– Ce să obțineți on-chain

Vedeți, oracolele nu sunt la fel de strict definite ca blockchain-urile. Mai degrabă, oracolele referitoare la informațiile din afara lanțului sunt o decizie socială asupra unui stat care nu este legat de consensul blockchain-ului. Pentru a despacheta acest lucru:

a) Adevărul este subiectiv. Ceea ce este de acord cu un grup de oameni (într-un context pur digital) este adevărul. Modul în care ajungem la acest adevăr este o modalitate codificată de a realiza „consensul social” (subiectivul, adevărul convenit)

b) Stratul 1 este consensul social.

c) Stratul 1 consensul se referă doar la un set foarte specific de opcodes și acțiuni.

d) Toate acțiunile din lanț trebuie fie codificate în instrucțiunile de nivel 1, fie să aibă propriul consens social (de exemplu, un contract cu o cheie de administrare este o formă specificată de guvernare autoritară)

e) Oracolele plasează date în lanț a căror validitate nu este gestionată de mecanismul de consens de nivel 1. Prin urmare, oracolele trebuie să aibă, de asemenea, un element uman, social sau de consens.

Oracolele reprezintă o problemă interesantă, deoarece încearcă să furnizeze informații referitoare la apariția unui eveniment sau starea unui sistem care nu este nativ. la lanțul în sine. În timp ce un mecanism de consens de nivel 1 este strict definit cu anumite operațiuni și puncte de dispută, sistemele oraculare încearcă să extindă capacitățile lanțului la informații arbitrare care nu au fost agreate de validatorii de bază. Cel mai frecvent caz de utilizare se referă în prezent la stabilirea prețurilor criptomonedelor pe bursele centralizate, urmate de evenimentele care se întâmplă pe alte blockchain-uri (blockheaders, disponibilitatea datelor etc.). Deși poate părea simplu să spunem ce s-a întâmplat sau care este starea unui eveniment exterior, adevărul este că realitatea poate fi mai subiectivă decât ar putea admite susținătorii soluțiilor codificate.

Ce este un preț?

Când protocoalele aleg un oracol, ele aleg mecanismul consensului social pentru a determina acuratețea o intrare. Pentru un anumit design oracle, nu numai că aveți gânduri diferite cu privire la modul de validare a unei intrări date, ci aveți gânduri diferite cu privire la ceea ce este chiar intrarea respectivă.

Există o diferență între prețul Bitcoin, prețul Bitcoin pe Coinbase, prețul Bitcoin conform API-ului Coinbase și prețul la care pot cumpăra în prezent un întreg Bitcoin pe Coinbase.

Definițiile contează.

Alegerea intrării (feedul de prețuri în acest caz) determină pe ce se vor baza validatorii dvs. acuratețea. Tellor are un (articol minunat despre prețurile de decontare), dar aceasta este o problemă care nu se limitează la defi sau blockchain și are o literatură robustă cu cele mai bune practici.

Multe soluții oraculare sunt pur și simplu tehnologie care ia în calcul un API sau funcționează pentru a aduce fără încredere informații din acel API în lanț. Acesta este un instrument excelent pentru constructori sau MVP-uri, dar nu este o soluție oracle completă.

Dacă presupuneți că prețul din API este întotdeauna corect, aveți încredere deplină în operatorul acestui feed de prețuri. Manipularea acestor prețuri sau rezistența la onestitate / cenzură a API-ului bursei ar trebui să fie preocupări serioase pentru orice proiect. Adevărul este că transparența setului de instrumente „citit direct dintr-un API” este, de asemenea, o prăbușire.

Securitatea necunoscutului

Cunoașterea regulilor jocului este important, dar există întotdeauna consecințe neprevăzute atunci când sistemele complexe încearcă să traseze fiecare scenariu potențial. După cum poate atesta orice dezvoltator al cărui software a eșuat în producție, codul este greu de corectat.

Dar nu este doar cod, ci legi și reglementări în general.

Acesta este un lucru cunoscut problemă în guvernare. Dacă încercați să scrieți ce se întâmplă în fiecare caz, îi determinați pe oameni să găsească lacune și modalități de a ocoli legea. Acesta este motivul pentru care avem judecători și juri în lumea reală care vin cu pedepse personalizate pe decizii nuanțate. Este imposibilă reguli specifice pentru fiecare situație și modul în care traducem acest principiu în universul digital este dificil.

Formalizarea protocolului este ideea că codul nu necesită aport uman și nu se schimbă. După cum știm din experiență, totuși, acest lucru duce la rigiditate, la cazuri neprevăzute și, adesea, la abandonarea protocolului, deoarece narațiunea din jurul cazului său de utilizare ar trebui să se schimbe dacă codul nu. Capacitatea unei comunități de a răspunde la probleme nespecificate care pot apărea este esențială pentru ca un sistem să rezolve efectiv o problemă în timp. Modul în care o comunitate face acest lucru este locul în care apare consensul social.

Acest lucru revine la principiile blockchain-ului. Este blockchain-ul „codul este lege” sau este un „consens comunitar”. Este o modalitate prin care comunitățile sunt de acord cu adevărul sau o bucată de cod fără minte care funcționează la fel ca un calculator?

Oracle Manipulation

Dacă cunoașteți regulile și puteți juca sistemul fără pedeapsă, atunci regulile vor fi încălcate. Deși se dorește transparență, exactitatea cu privire la derivarea datelor este de fapt o eroare în acest scenariu.

Ideea că specificațiile legaliste nu sunt necesare este ceva ce se ia de la sine înțeles. Chiar dacă nu este specificat în contractul dvs. de închiriere, dacă acoperișul suflă într-un uragan, proprietarul dvs. este responsabil să îl remedieze în timp util. Societățile au legi care împiedică lucruri foarte generale (de exemplu, conducerea nesăbuită, conduita dezordonată etc.); nu avem nevoie de o declarație if / else pentru fiecare scenariu. Dacă o persoană în care avem încredere (de ex. Un ofițer de poliție) vă vede făcând ceva prost, poate pune capăt asta. Nu trebuie să scrieți în lege că împușcarea unei arbalete în timp ce călăriți cu un monociclu este ilegală; avem modalități de a folosi doar bunul simț.

Totuși, contractele inteligente funcționează diferit. Părțile care utilizează un oracol prea specific (semnatarul unic API sau chiar prețul Uniswap) sunt supuse unui risc mai mare de manipulare. Am văzut că mai multe hacks se întâmplă acolo unde oracolul aduce corect datele pe lanț, dar există consecințe neprevăzute în ceea ce privește prețul, deoarece acesta a fost manipulat. Comunitatea în aceste cazuri nu are nici un recurs. Ești blocat cu ceea ce ți-a dat codul și de cele mai multe ori asta înseamnă că cineva pierde bani. Obținerea unui feed fără încredere nu vă spune că este corectă în ceea ce privește un consens de schimburi sau o comunitate și nu vă poate proteja dacă cineva găsește chiar o modalitate de a arunca prețul cu privire la sursa respectivă de date. [2]

În ciuda apelurilor la „cod ca lege” sau durerea de a lucra cu comunitățile și alte protocoale, nu doriți un oracol care să fie pur și simplu o bucată de cod. În același mod în care Ethereum sau Bitcoin se bifurcă / revine dacă protocolul consens este atacat, un oracol complet ar trebui să aibă flexibilitate în cazul unui atac. Puteți avea o formă de acord comunitar (sau un proces în cazuri foarte specifice) în legătură cu prețul bun. Dacă API-ul Coinbase nu funcționează, nu îl utilizați. Dacă apare o nouă sursă de lichiditate, asigurați-vă că o includeți. Nu este știință de rachete, dar este un proces manual; unul care va avea nevoie de timp pentru a obține dreptate, dar unul care nu este limitat de propria sa anvergură.

Consensul social comunitar Tellor

Tellor oferă o modalitate de a conveni asupra adevărului. Oracolul Tellor nu este o tehnică criptografică magică pentru monitorizarea lumii exterioare și transmiterea ei către Ethereum. Este o rețea de participanți individuali care sunt stimulați cripto-economic să raporteze și să valideze date corecte.

Este bine recunoscut că nu există o soluție la „problema oracolului”, dar de multe ori aceasta este pentru a contracara dificultățile de compromis pe care un proiect trebuie să îl facă atunci când vine vorba de selectarea corectă a unui feed de prețuri și a mecanismelor de securitate din jurul acestuia.

Dacă sunteți un proiect defi care dorește să utilizeze exclusiv prețuri centralizate cu costuri de atac cunoscute, ați fi fi mai bine să săriți peste consensul comunității din protocol și să lucrați pentru a permite doar schimburilor să scrie prețul în contractul dvs. Cu toate acestea, dacă sunteți un proiect sau cunoașteți unul, care ar putea beneficia de un oracol robust și descentralizat, contactați-vă și simțiți-vă liber să oferiți www.tellor.io o privire.

[1] https://www.bbc.com/news/business-52350082#:~:text=The\%20price\%20of\%20US \% 20oil, world\% 20have\% 20kept\% 20people\% 20inside .

[2] https://news.bitcoin.com/100 -million-liquidated-on-defi-protocol-compound-following-oracle-exploit /