Soggettività in oracoli

(Tellor Core) (15 dicembre 2020)

Soggettività, ambiguità e oracoli decentralizzati

In un istante, hack di protocolli finanziari o incomprensioni del funzionamento interno di un contratto finanziario possono portare a enormi perdite con spesso poco ricorso . Che si tratti di prodotti finanziari tradizionali che si sono stabiliti al LIBOR, i trader che hanno visto il greggio diventare negativo per la prima volta nella storia questanno [1] o un contratto derivato che liquida hedger ignari, il prezzo di regolamento o la manipolazione degli oracoli è stata una cosa da molto prima di Vitalik e prestiti flash.

Il modo in cui è strutturato il tuo Oracle e i dati che stai recuperando sono specifiche fondamentali quando si crea un prodotto finanziario solido. La domanda apparentemente semplice di “quale prezzo usi?” è tuttaltro. La sfumatura coinvolta nella selezione della definizione corretta di cosa sia la verità riguardo al tuo input ha implicazioni sulla sicurezza che influenzeranno ogni aspetto del tuo prodotto.

Loracolo non problematico

Quando si inserisce un prezzo di liquidazione su una blockchain, si hanno due componenti:

– Come ottenere it on-chain

– Cosa comprare on-chain

Vedi, gli oracoli non sono definiti rigorosamente come blockchain. Piuttosto, gli oracoli relativi alle informazioni off-chain sono una decisione sociale su uno stato non legato al consenso della blockchain. Per decomprimerlo:

a) La verità è soggettiva. Ciò su cui un gruppo di persone concorda (in un contesto puramente digitale) è la verità. Il modo in cui arriviamo a questa verità è un modo codificato per raggiungere il “consenso sociale” (la verità soggettiva, concordata)

b) Lo strato 1 è il consenso sociale.

c) Livello 1 il consenso è solo su un insieme molto specifico di codici operativi e azioni.

d) Tutte le azioni sulla catena devono essere codificate nelle istruzioni di Livello 1 o avere il proprio consenso sociale (ad esempio, un contratto con una chiave amministratore è una forma specifica di governance autoritaria)

e) Gli oracoli collocano i dati sulla catena la cui validità non è gestita dal meccanismo di consenso di livello 1. Pertanto, gli oracoli devono anche avere un elemento umano, sociale o di consenso.

Gli oracoli rappresentano un problema interessante poiché cercano di fornire informazioni relative al verificarsi di un evento o allo stato di un sistema che non è nativo alla catena stessa. Mentre un meccanismo di consenso di livello 1 è rigorosamente definito con determinate operazioni e punti di conflitto, i sistemi Oracle cercano di estendere le capacità della catena a informazioni arbitrarie non concordate dai validatori di base. Il caso duso più comune attualmente riguarda il prezzo delle criptovalute sugli scambi centralizzati, seguito dagli eventi che si verificano su altre blockchain (blockheader, disponibilità dei dati, ecc.). Sebbene possa sembrare semplice dire cosa è successo o quale sia lo stato di qualche evento esterno, la verità è che la realtà potrebbe essere più soggettiva di quanto i sostenitori di soluzioni codificate possano ammettere.

Che cosè un prezzo?

Quando i protocolli scelgono un oracolo, scelgono il meccanismo del consenso sociale per determinare laccuratezza un input. Per un dato progetto di Oracle, non solo hai pensieri diversi su come convalidare un dato input, hai pensieri diversi su cosa sia quellinput.

Cè una differenza tra il prezzo di Bitcoin, il prezzo di Bitcoin su Coinbase, il prezzo di Bitcoin secondo lAPI di Coinbase e il prezzo al quale attualmente posso acquistare un intero Bitcoin su Coinbase.

Le definizioni contano.

La scelta dellinput (il feed prezzo in questo caso) determina su cosa i tuoi validatori baseranno laccuratezza. Tellor ha un (ottimo articolo sui prezzi di liquidazione), ma questo è un problema che non si limita a defi o blockchain e ha una solida letteratura di best practice.

Molte soluzioni Oracle sono semplicemente tecnologia che afferra da unAPI o lavora per portare in modo affidabile le informazioni da quellAPI sulla catena. Questo è un ottimo strumento per i builder o gli MVP, ma non è una soluzione Oracle completa.

Se presumi che il prezzo dellAPI sia sempre corretto, riponi completa fiducia nelloperatore di questo feed di prezzo. La manipolabilità di questi prezzi o lonestà / resistenza alla censura dellAPI dellexchange dovrebbero essere seri problemi per qualsiasi progetto. La verità è che anche la trasparenza del toolkit “leggi direttamente da unAPI” è un fallimento.

La sicurezza dello sconosciuto

Conoscere le regole del gioco è importante, ma ci sono sempre conseguenze impreviste quando sistemi complessi tentano di mappare ogni potenziale scenario. Come può attestare qualsiasi sviluppatore il cui software ha fallito nella produzione, il codice è difficile da ottenere correttamente.

Ma non è solo codice, sono leggi e regolamenti in generale.

Questo è un noto problema nella governance. Se provi a scrivere cosa succede in ogni caso, le persone trovano scappatoie e modi per aggirare la legge. Questo è il motivo per cui abbiamo giudici e giurie nel mondo reale che escogitano punizioni personalizzate su decisioni sfumate. Regole specifiche per ogni situazione sono impossibili e il modo in cui traduciamo questo principio nelluniverso digitale è difficile.

La formalizzazione del protocollo è lidea che il codice non richiede input umano e non cambia. Come sappiamo per esperienza, tuttavia, ciò porta a rigidità, casi limite imprevisti e spesso un abbandono del protocollo poiché la narrativa attorno al suo caso duso potrebbe dover cambiare se il codice non lo fa. La capacità di una comunità di rispondere a problemi non specificati che possono sorgere è fondamentale affinché un sistema risolva effettivamente un problema nel tempo. Il modo in cui una comunità fa questo è dove nasce il consenso sociale.

Questo risale ai principi della blockchain. Blockchain è “il codice è legge” o è un “consenso della comunità”. È un modo per le comunità di concordare la verità o un pezzo di codice insensato che funziona in modo molto simile a una calcolatrice?

Oracle Manipulation

Se conosci le regole e puoi giocare con il sistema senza punizione, le regole verranno infrante. Sebbene la trasparenza sia desiderata, lesattezza per quanto riguarda la derivazione dei dati è in realtà un bug in questo scenario.

Lidea che le specifiche legalistiche non siano necessarie è qualcosa di più scontato. Anche se non è specificato nel contratto di locazione, se il tetto viene spazzato via in un uragano, il tuo padrone di casa è responsabile di risolverlo in modo tempestivo. Le società hanno leggi che impediscono cose molto generali (ad esempio guida spericolata, comportamento disordinato, ecc.); non richiediamo unistruzione if / else per ogni scenario. Se una persona di cui ci fidiamo (ad esempio un agente di polizia) ti vede fare qualcosa di stupido, può metterla fine. Non è necessario scrivere nella legge che sparare con una balestra mentre si è in sella a un monociclo è illegale; abbiamo modi per usare solo il buon senso.

I contratti intelligenti però funzionano in modo diverso. Le parti che utilizzano un oracolo troppo specifico (il singolo firmatario API o anche il prezzo Uniswap), sono soggette a un rischio di manipolazione più elevato. Abbiamo visto diversi hack accadere in cui loracolo porta correttamente i dati sulla catena, ma ci sono conseguenze impreviste riguardo a quel prezzo man mano che è stato manipolato. La comunità in questi casi non ha ricorso. Sei bloccato con ciò che il codice ti ha dato e il più delle volte significa che qualcuno perde soldi. Ottenere un feed senza fiducia non ti dice che è corretto per quanto riguarda un consenso di scambi o una comunità e non può proteggerti se qualcuno trova anche il modo di spendere il prezzo per quanto riguarda quella fonte di dati. [2]

Nonostante le richieste di “codice come legge” o il dolore di lavorare con le comunità e altri protocolli, non vuoi un oracolo che sia semplicemente un pezzo di codice. Allo stesso modo in cui Ethereum o Bitcoin si biforcano / ripristinano se il protocollo di consenso viene attaccato, un oracolo completo dovrebbe avere flessibilità in caso di attacco. Puoi avere una forma di accordo comunitario (o un processo in casi molto specifici) su ciò che è un buon prezzo. Se lAPI Coinbase non funziona, non utilizzarla. Se compare una nuova fonte di liquidità, assicurati di includerla. Non è scienza missilistica, ma è un processo manuale; uno che richiederà tempo per essere corretto, ma che non sia limitato dal proprio ambito.

Tellor Community Social Consensus

Tellor fornisce un modo per concordare sulla verità. Loracolo di Tellor non è una tecnica crittografica magica per monitorare il mondo esterno e trasmetterlo a Ethereum. È una rete di singoli partecipanti che sono incentivati ​​dal punto di vista criptoeconomico a segnalare e convalidare dati accurati.

È stato ben riconosciuto che non esiste una soluzione al “problema delloracolo”, ma spesso si tratta di superare i difficili compromessi che un progetto deve realizzare quando si tratta di selezionare correttamente un feed di prezzo e i meccanismi di sicurezza che lo circondano.

Se sei un progetto definitivo che cerca di utilizzare esclusivamente prezzi centralizzati con costi di attacco noti, dovresti sarebbe meglio saltare la parte del protocollo del consenso della comunità e lavorare per consentire agli scambi di scrivere il prezzo sul tuo contratto. Se, tuttavia, sei un progetto, o ne conosci uno, che potrebbe trarre vantaggio da un oracolo robusto e decentralizzato, contattaci e sentiti libero di dare www.tellor.io uno sguardo.

[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 /