blockchain-orakels zijn services van derden die slimme contracten voorzien van externe informatie. Ze dienen als brug tussen blockchains en de buitenwereld.

Schaalbaarheid en interoperabiliteit worden vaak beschouwd als de twee heilige grails van de crypto-ruimte. Interoperabiliteit wordt gedefinieerd als het vermogen van verschillende software om effectief met elkaar te communiceren en informatie uit te wisselen. Orakels zijn een krachtig hulpmiddel dat interoperabiliteit tussen verschillende blockchains kan bieden en kan communiceren met externe gegevensbronnen.

Waarom interoperabiliteit belangrijk is

  • Er zijn momenteel verschillende gecentraliseerde faalpunten binnen de gedecentraliseerde ruimte. Bijv. De uitwisselingen fungeren als een portaal tussen de gecentraliseerde en de gedecentraliseerde ruimte. Omdat ze echter zeer kwetsbaar zijn, worden ze altijd aangevallen door hackers.
  • Om blockchains te laten slagen, moeten ze kunnen communiceren met legacysystemen zoals financiële instellingen, enz. Het is essentieel om een ​​robuust contactpunt tussen de twee te behouden.
  • Aanvankelijk dacht de gemeenschap dat het slimme contractecosysteem zou worden beheerst door ketenmaximalisme, d.w.z. een dominante keten die een aantal slimme contracten herbergt. We weten echter al dat er meerdere slimme contractplatforms zijn. Om maximale functionaliteit te bereiken, is het van cruciaal belang dat deze platforms weten hoe ze met elkaar moeten ‘praten’.

Orakels classificeren

Er zijn twee soorten interoperabiliteit die blockchain-projecten kunnen gebruiken:

  • Aan de ketting
  • Off-chain

Interoperabiliteit op de keten

Deze methode gebruikt een derde blockchain als brug tussen twee verschillende blockchains. Projecten zoals AION, Wanchain en ICON gebruiken deze methode. De volgende drie zijn de meest voorkomende benaderingen van interoperabiliteit in de keten:

  • Hub en Spoke: populair gemaakt door AION, in deze methode fungeert de verbindende blockchain als een centrale hub waarmee de andere blockchains, ook wel spaken genoemd, zijn verbonden.
  • Gedecentraliseerde uitwisseling: interoperabiliteit tussen twee afzonderlijke projecten kan worden gecreëerd door een gedecentraliseerde uitwisseling te bouwen.
  • Bruggen: bij deze methode fungeert de blockchain als een algemene brug tussen de communicatie en berichtenuitwisseling.

Interoperabiliteit buiten de keten

Deze methode maakt gebruik van off-chain of middleware-systemen om de interoperabiliteit te vergemakkelijken.

  • Atomic Swaps: Atomic swaps zijn een gedecentraliseerde methode die wordt gebruikt om twee activa uit te wisselen zonder via een gecentraliseerde uitwisseling te hoeven gaan. Als je meer wilt weten over Atomic Swaps, lees dan dit.
  • State Channels: Layer-2 implementaties, zoals state kanalen, kunnen off-chain interactie en atomaire swaps mogelijk maken.
  • Besturingssysteem: een blockchain-besturingssysteem maakt cross-chain messaging en atomic swaps mogelijk door bovenop de deelnemende blockchains te draaien.
  • Orakels: Orakels kunnen ook een brede mate van onderlinge communicatie tussen blockchains en bedrijfssystemen mogelijk maken.

Afgezien hiervan kunnen we orakels ook categoriseren in software- en hardware-orakels:

  • Software Oracle: de informatie die binnen de software-orakels wordt doorgegeven, is afkomstig van online bronnen zoals websites, back-end-API’s of zelfs andere slimme contracten. Het soort informatie dat hier wordt opgenomen, kan variëren van aandelenkoersen tot gegevens over sportevenementen.
  • Hardware Oracle: Hardware-orakels gebruiken IoT-apparaten om gegevens uit de echte wereld te volgen en te verifiëren voordat ze naar het slimme contract worden verzonden.

Waarom hebben we Blockchain Oracles nodig??

Slimme contracten zijn ontworpen om onomkeerbare operaties uit te voeren. Daarom moet de informatie die in het contract wordt ingevoerd, afkomstig zijn van een relatief betrouwbare bron. Daarom kan het een dilemma zijn als gegevens van een externe bron komen. Aan de andere kant verhoogt het het aantal use-cases exponentieel.

Een orakel ondertekent claims over de toestand van de wereld en uploadt deze naar de blockchain. Blockchains lijken in hun geïsoleerde realiteit te leven, volledig afgesneden van de rest van de wereld. Een orakel kan de blockchain verbinden met de echte wereld door deze te voorzien van relevante informatie. De informatie kan worden opgehaald of verzameld uit een of meerdere vertrouwde bronnen door een of meerdere orakels. Laten we een eenvoudig voorbeeld nemen om te zien hoe orakels werken.

  • Alice en Bob wedden op wie de NBA-finale gaat winnen.
  • Alice gelooft dat LA Lakers gaat winnen, terwijl Bob gokt op de Milwaukee Bucks.
  • Nadat ze overeenstemming hebben bereikt over de uitbetalingen, ondertekenen ze de deal door hun geld vast te leggen in een slim contract. Het slimme contract geeft geld vrij aan de winnaar op basis van de resultaten.
  • Hoe weet het contract nu precies wie de winnaar van de wedstrijd was? Het hangt van het orakel af om het de relevante informatie te geven.
  • Het orakel vraagt ​​een vertrouwde API om erachter te komen welk team heeft gewonnen en geeft deze informatie door aan het slimme contract. Het contract stuurt het geld vervolgens naar Alice of Bob, afhankelijk van de uitkomst.
  • Zonder dat het orakel zijn werk doet, kan het slimme contract niet weten wie de winnaar van de wedstrijd was.

Blockchain-gebruiksscenario’s

# 1 Voorspellingsmarkt

Gedecentraliseerde voorspellingsmarkten zoals Augur en Gnosis maken gebruik van de “kennis van de massa” om de toekomstige toestand van de markten te voorspellen. Deze markten moeten kennis vergaren via meerdere orakels of gebeurtenissen buiten de keten.

# 2 Defi

De combinatie van slimme contracten en financiën heeft het tijdperk van Gedecentraliseerde financiering (DeFi). Deze producten hebben toegang nodig tot betrouwbare datafeeds, die kunnen worden geleverd door orakels.

# 3 Verzekering

Het zou mogelijk kunnen zijn om via orakels verzekeringsproducten over de blockchain te kopen. Aangezien het grootste probleem bij verzekeringen fraude is, zijn de decentralisatie van de blockchain en de betrouwbaarheid van orakels een perfecte combinatie om dit probleem op te lossen.

# 4 Verzending

Oracles kan de bestaande, gecentraliseerde GPS-systemen vervangen om betrouwbare locatiekaarten te bieden voor dApps om zendingen te volgen.

# 5 De stal in “stablecoins” plaatsen

MakerDAO’s Dai stablecoin gebruikt een netwerk van meerdere Oracles om voortdurend de prijs van Ether aan hem te rapporteren. Ze moeten zich constant bewust zijn van de prijs, zodat ze kunnen weten of ze hun onderpand moeten consolideren of liquideren om de prijs van Dai stabiel te houden.

Hoe de betrouwbaarheid van Blockchain Oracle te behouden?

Er zijn vier technieken die orakels kunnen gebruiken om de betrouwbaarheid ervan te behouden:

  • Meerdere databronnen.
  • Meerdere orakels.
  • Stimuleringsmechanismen.
  • Vertrouwde uitvoeringsomgeving.

Meerdere databronnen

Als uw orakel informatie verzamelt uit meerdere gegevensbronnen, is de kans klein dat het verkeerde informatie ontvangt. Het orakel zelf kan echter als een punt van mislukking fungeren.

Meerdere orakels

Een andere benadering is om meerdere orakels te gebruiken om informatie te verzamelen die het “single-point-of-failure” -probleem teniet doet. Het risico hierbij is echter dat de kans bestaat dat een meerderheid van deze orakels mogelijk gecompromitteerde informatiebronnen heeft.

Stimuleringsmechanisme

Orakels kunnen een pagina uit het Casper-protocol halen en een “inzet-slashing” -mechanisme opnemen om ervoor te zorgen dat de betrokken actoren worden gestimuleerd om eerlijk te handelen. De sleutel hier is om een ​​vorm van tokenomics op te nemen die de knooppunten in het oracle-netwerk dwingt om eerlijk werk te verrichten en zich goed te gedragen. Als ze goed presteren, krijgen ze een beloning, zo niet, dan kunnen ze gestraft worden via een slashing-mechanisme.

Vertrouwde uitvoeringsomgeving (TEE’s)

Met TEE’s kan een toepassing worden uitgevoerd in een afgezonderde omgeving die “enclave” wordt genoemd en die hem hardwarebescherming biedt. De enclave:

  • Zorgt voor de integriteit van het project.
  • Houdt de operaties vertrouwelijk.
  • Hiermee kan de applicatie geheugen buiten de enclave lezen en schrijven. Met andere woorden, het kan zijn eerlijkheid en werkintegriteit bewijzen zonder precies te moeten verspillen aan wat ze doen.

Veelbelovende blockchain-Oracle-projecten

Er zijn drie orakelprojecten die we onder de loep zullen nemen. Zij zijn:

  • Kettingschakel.
  • Augur.
  • RIF-gateways

Kettingschakel

Blockchain-orakels - de sleutel tot schaalbaarheid en interoperabiliteit

ChainLink is een gedecentraliseerd oracle-netwerk gebouwd op ethereum. Het wil een veilige blockchain-middleware zijn die van plan is om verschillende slimme contracten over blockchains te verbinden. Het netwerk is op 30 mei 2019 live gegaan. Het bedrijf hierachter heet “SmartContract”. In september 2017 haalde ChainLink maar liefst $ 32 miljoen op in zijn ICO.

ChainLink is van plan slimme contracten te creëren om veilig te communiceren met bronnen buiten de blockchain, zoals cryptografisch beveiligde datafeeds, en om interoperabiliteit tussen blockchains mogelijk te maken. ChainLink richt zich momenteel op het creëren van een gedecentraliseerd netwerk van orakels die compatibel zijn met de blockchains Bitcoin, Ethereum en Hyperledger..

ChainLink-netwerk: on-chain en off-chain

Het ChainLink-protocol maakt gebruik van zowel on-chain als off-chain componenten.

Component op ketting

  • Filtert de orakels op basis van de statistieken die door een partij bij een slim contract worden gevraagd.
  • Verzamelt de orakels die overeenkomen met de SLA-vragen en sorteert ze met behulp van reputatie- en aggregatiemodellen.
  • Biedt een collectief eindresultaat op basis van de vraag.

Component zonder ketting

  • Dit onderdeel bestaat uit oracle-knooppunten die zijn verbonden met het Ethereum-netwerk. Deze knooppunten reageren onafhankelijk op de juiste off-chain verzoeken.
  • De off-chain nodes die voldoen aan specifieke, vooraf bepaalde eisen, verzamelen de informatie die door deze contracten wordt gevraagd.
  • ChainLink fungeert als een goedkope tussenpersoon om gegevens om te leiden en toe te wijzen.
  • Off-chain nodes worden beloond met het native LINK-token voor hun services.

Augur

Blockchain-orakels - de sleutel tot schaalbaarheid en interoperabiliteit

Augur is een betrouwbaar, gedecentraliseerd orakel- en voorspellingsmarktplatform. Het maakt gebruik van de wijsheid van de menigte om op te speculeren en de objectieve uitkomst van elk evenement te rapporteren.

Voorspellingsmarkten zijn speculatieve markten waar gebruikers aandelen in de uitkomst van een evenement kunnen kopen en verkopen. Stel dat u gespecialiseerde kennis heeft op een bepaald gebied. Bijv. Een basketbalwedstrijd. Door verschillende factoren in overweging te nemen, wedt u op een gunstig resultaat.

Hoe werkt Augur?

Blockchain-orakels - de sleutel tot schaalbaarheid en interoperabiliteit

Er zijn drie soorten mensen die augur gebruiken:

  • The Reporters aka Oracles: ze rapporteren over de resultaten van hun vakgebieden. Wanneer een evenement bijna volwassen is, rapporteren ze over het resultaat. Als ze verkeerd rapporteren of helemaal niet rapporteren, lopen ze het risico 20% van hun REP (native Augur-tokens) te verliezen. De waarde van augur is recht evenredig met de kwaliteit van de verslaggevers. Waarom? Want als veel van de verslaggevers oneerlijk zijn, zal niemand augur willen gebruiken, wat de vraag aanzienlijk zal verminderen. Dit dwingt alle verslaggevers om eerlijk te blijven.
  • The Wagerers: Ze wedden op de toekomst van de markten op basis van de rapporten van de verslaggevers.
  • The Market Creators: zij zullen de markten creëren waar de verslaggevers over kunnen rapporteren en daarmee markttarieven kunnen verdienen.

De rapportageperiode

De rapportage verloopt in twee fasen. Binnen de eerste maand na de voltooiing van het evenement dienen de verslaggevers hun rapport in bij het netwerk, dat goed beveiligd is en weggehouden wordt van het publiek. Een maand later vindt de tweede fase plaats waarin de rapporten worden getoond in een open grootboek, dat voor iedereen gratis te zien is. Als dat is gebeurd, bereiken we een definitieve consensus.

Nasleep van de consensus

  • De gokkers krijgen hun passende beloning voor het plaatsen van hun weddenschappen.
  • De verslaggevers die eerlijk hebben gerapporteerd, krijgen vergoedingen van de weddenschappen.
  • De verslaggevers die niet correct rapporteerden, krijgen 20% van hun REP afgetrokken en dat gaat op zijn beurt naar de verslaggevers die eerlijk en nauwkeurig rapporteerden.

RIF-gateways

Onderstam (RSK) is een slim contractplatform die is verbonden met de blockchain van Bitcoin door middel van sidechain-technologie. Met Rootstock kun je applicaties maken die compatibel zijn met ethereum (het web3 / EVM / Solidity-model) terwijl je toch geniet van de beveiliging die wordt geboden door de blockchain van Bitcoin. In wezen is Rootstock een combinatie van:

  • Een Turing-complete deterministische virtuele machine met resources (voor slimme contracten) is compatibel met de EVM van Ethereum.
  • Een in twee richtingen gekoppelde bitcoin-zijketen (voor handel in BTC-valuta) op basis van een sterke federatie.
  • Een SHA256D-consensusprotocol voor merge-mining (voor consensusbeveiliging op basis van de miners van Bitcoin) met een blokinterval van 30 seconden. (voor snelle betalingen).

Rootstock zal ook zijn technische stack gebruiken – de Rootstock Infrastructure Framework Open Standard (RIFOS) om te helpen bij het bouwen van een gezond economisch systeem bovenop Bitcoin, een soort van gedecentraliseerde AWS. Het zal het gebruik van blockchain-technologie vergemakkelijken door het voor iedereen zo eenvoudig mogelijk te maken. Houd rekening met de volgende kenmerken als het om RIFOS gaat:

  • Zolang een product compatibel is met de onderliggende protocollen, kunnen ontwikkelaars het naadloos integreren in het RIFOS-ecosysteem.
  • Alle afzonderlijke componenten van RIFOS zijn ontworpen om de potentiële voordelen te maximaliseren voor diegenen die hun infrastructuurdiensten willen aanbieden binnen het ecosysteem van het protocol.
  • Alle componenten worden beschermd door de beveiliging die wordt geboden door het bitcoin-netwerk.
  • De protocollen zullen mechanismen bevatten om netwerkeffecten en schaalvoordelen teweeg te brengen.
  • De meeste services die in RIFOS worden uitgevoerd, worden gebruikt met behulp van een enkele token (RIF).

RIF Gateways beknopt overzicht

RIF Gateways biedt een netwerk van orakels om veilige en fraudebestendige interacties met de buitenwereld mogelijk te maken. Het stelt een interfacelaag voor die de toegang tot Oracle-services en cross-chain integraties verenigt, blockchains voorzien van een implementatie-agnostisch protocol voor zowel intern als extern dataverbruik. Hier zijn enkele punten over RIF Gateways om in gedachten te houden:

  • Bouwt bruggen tussen blockchains.
  • Het stelt dataproviders en consumenten in staat deel te nemen aan veilige en gestandaardiseerde gegevensoverdrachten.
  • Ondersteunt een breed scala aan modellen voor gegevensverbruik, abonnementen en betalingen.

RIF Gateways biedt drie verschillende Oracle-services

  • Datadiensten: om externe gegevens van de blockchain te consumeren.
  • Triggers-service: externe gegevens consumeren vanuit de blockchain.
  • Planningsservice: Verzoek om toekomstige uitvoering van een blockchain-transactie.

# 1 Datadiensten

Een gegevensservice levert een specifiek soort gegevens uit de buitenwereld. Externe gegevens kunnen afkomstig zijn van een enkele gegevensbron of een netwerk van meerdere gegevensbronnen. Dit is hoe het werkt:

  • De maker en aanbieder van een datadienst wordt ‘datadienstverlener’ genoemd.
  • Consumenten kunnen kiezen uit verschillende soorten gegevensservices en vervolgens communiceren met het slimme contract van de bijbehorende gegevensserviceprovider om de externe gegevens op te halen.
  • De serviceprovider moet de datadienst-interfaces implementeren in hun slimme contracten.
  • De aanbieder moet zijn gegevens periodiek bijwerken, omdat de consument mogelijk de laatste gegevens nodig heeft of de gegevens die een tijdje geleden zijn gepubliceerd.

Hoe verloopt de interactie tussen de aanbieder en de consument?

Er zijn twee methoden die een consument kan gebruiken om de gegevens van de provider te consumeren: een direct pull-model of een abonnementsservice.

Trek model

De consument betaalt voor de gegevens per zoekopdracht. De gevraagde gegevens worden rechtstreeks bij de provider overgenomen. Dit is een duurder en langzamer model.

Abonnementsmodel

Een consument betaalt een vaste prijs voor toegang. Door één stuk gegevens aan meerdere klanten te leveren, kan de serviceprovider de kosten voor het ophalen van de gegevens uit de buitenwereld over alle abonnees verdelen. RIF biedt twee abonnementsmodellen:

  • On-demand: de consument vraagt ​​de aanbieder om de waarde naar behoefte, zolang het abonnement geldig is.
  • Push: Provider pusht de nieuwe gegevens periodiek naar de abonnees.

# 2 Triggerservices

Een triggerservice stelt de aanbieder in staat om informatie vanuit de blockchain te verkrijgen en deze voor een prijs aan de consument te geven. De consument kan zijn eigen meldingsoplossing bouwen op de API van de aanbieder. De kenmerken van de Trigger-services zijn als volgt.

  • Elke triggerprovider moet worden geassocieerd met een unieke domeinnaam. Dit zorgt voor een gemakkelijke toegankelijkheid voor de gebruiker.
  • Providers moeten voldoen aan een vooraf gedefinieerde interface die is ontworpen om te worden gebruikt door toepassingen van derden.
  • Consumenten hebben de vrijheid om te kiezen tussen een enkele aanbieder of zich te abonneren op een reeks aanbieders.

Vooraf gedefinieerde triggers

De aanbieder kan een meldingsdienst aanbieden over bepaalde slimme contracten of gebeurtenissen binnen de blockchain. Hij doet dit door een vaste reeks gebeurtenissen te melden die worden uitgezonden door het contract dat wordt nageleefd.

Aangepaste triggers

De consument kan ook een trigger bouwen specifiek voor zijn eigen behoeften. Ze moeten aan de provider de bron van de gebeurtenissen specificeren waarover ze willen worden geïnformeerd, bijv. het slimme contractadres.

  • Zelfs een niet-technische gebruiker om zijn eigen meldingsservice te maken.
  • Om een ​​actie te activeren, stelt de provider consumenten in staat om te specificeren welke actie wordt uitgevoerd zodra een overeenkomende gebeurtenis is ontvangen.
  • Consumenten hebben de vrijheid om de lijst met gebeurtenissen in te stellen die door de triggerprovider worden gemeld.

Hoe verloopt de interactie tussen de aanbieder en de consument?

De triggerservice biedt de pull- en abonnementsmodellen

Trek model

De consument vraagt ​​specifiek om een ​​melding over een bepaald evenement.

Abonnementsmodel

Net als bij datadiensten betaalt een consument een vooraf bepaalde prijs voor de dienst. Triggers hebben echter alleen het push-abonnementsmodel.

# 3 Transactieplanningsservices

De dienst voor transactieplanning is een gedecentraliseerde oplossing waarmee een klant toekomstige uitvoeringen van on-chain transacties kan programmeren. Net als bij Data Services en Trigger Services kunnen nieuwe planningsserviceproviders zich aansluiten door een nieuwe planningsservice te registreren die via de RIF Marketplace zal worden ontdekt. Consumenten kunnen intern / on-chain of extern / off-chain zijn.

Hoe verloopt de interactie tussen de aanbieder en de consument?

De scheduler-service kan ook pull- en abonnementsmodellen aanbieden.

Trek model

De consument betaalt het vereiste bedrag nadat hij een enkel transactieschema heeft aangevraagd voor een gedelegeerde uitvoering. De uitvoering kan worden gepland voor een specifieke tijd en een bepaald “uitvoeringsvenster”.

Abonnementsmodel

Consumenten kunnen zich abonneren om de uitvoering van een specifieke functie herhaaldelijk te delegeren. De consument betaalt een onderhandelde prijs voor het herhaaldelijk uitvoeren van een functie. RIF Scheduler Services-protocol stelt alleen de push-abonnementsmodus voor het delegeren van een repetitieve uitvoering.

Mike Owergreen Administrator
Sorry! The Author has not filled his profile.
follow me