
Rialo Quiz 27.0 #9 @RialoHQ @RialoKorea Ang “Oracle tax” ay tumutukoy sa: 1️⃣ Libreng data feeds 2️⃣ Mahal na external data services 3️⃣ Blockchain rewards 4️⃣ Gas optimization techniques Ang tamang sagot ay 2️⃣ Mahal na external data services. Ang mga blockchain ay gumagana sa loob ng onchain environment, ngunit maraming aplikasyon ang nangangailangan ng impormasyon na nasa labas ng chain. Mga presyo ng asset. Mga market data. Mga pangyayari sa totoong mundo. Mga impormasyon sa kredito. Iba pang external data. Hindi kayang ipagpalagay ng blockchain na ang mga impormasyong ito ay available na sa onchain. Dito napupunta ang mga oracle at iba pang external data services. Isang aplikasyon ay maaaring magdepende sa isang external service upang makakuha ng impormasyon mula sa totoong mundo at gawing available ito sa blockchain. Ngunit ang koneksyong ito ay nagdadala ng isa pang layer sa pagitan ng aplikasyon at ang data na kailangan nito. At may gastos ang layer na ito. Ito ang ideya sa likod ng terminong “Oracle tax.” Ito ay tumutukoy sa karagdagang gastos na nililikha kapag ang mga blockchain application ay kailangang magdepende sa external data infrastructure upang makakuha ng impormasyon na kailangan para sa execution. Ang gastos ay hindi limitado sa presyo ng isang data feed lamang. Maaari ring mayroong infrastructure, integration, latency, maintenance, at coordination na kasali sa pagpapanatili ng koneksyon ng external data sa isang onchain application. Mas mahalaga ito kapag ang mga aplikasyon ay nangangailangan ng data nang tuloy-tuloy kaysa sa pagkakataon-lamang. Isipin ang isang financial application. Kung kailangan ng system na i-update ang presyo ng asset nang tuloy-tuloy, kailangan nito ang tuloy-tuloy na flow ng external market information. Ang isang Prediction Market ay maaari ring kailanganin ang external information upang matukoy kung ano ang nangyari sa totoong mundo pagkatapos matapos ang trading. Ang isang RWA application ay maaaring kailanganin ang external information para sa pricing, lending, trading, at risk management. Sa bawat kaso, depende ang aplikasyon sa isang tulay sa pagitan ng totoong mundo at ang blockchain. Direktang konektado ito sa middleware problem na binigkas sa Rialo’s Learn Papers. Ang middleware ay maaaring maglaman ng feeds, indexing, scheduling, bridging, at iba pang serbisyo na nasa pagitan ng aplikasyon at blockchain infrastructure. Mas maraming functionality na nasa labas ng blockchain, mas maraming koneksyon ang kailangang panatilihin ng mga developer. Ang arkitektura ng Rialo ay tumutugon sa problema sa data nang iba’t ibang paraan. Ang Rialo Stream ay disenyo bilang native data-feed layer para sa DeFi at RWAs. Ang mas malawak na sistema ng Rialo ay may kasamang Rialo Read Path, na nagbibigay ng direkta access sa validator data at state. Mahalaga ito dahil ang layunin ay hindi lamang ilagay ang mas maraming data sa onchain. Kailangan maging usable ng aplikasyon ang data na depende dito. Nakita na natin ito sa real-time financial data architecture ng Rialo, kung saan ang 1,337 live-updating tickers ay kumakatawan sa mga real-world financial assets. Maaaring suportahan ng mga feed na ito ang mga aplikasyon na may kinalaman sa pricing, lending, trading, at risk management. Parehong prinsipyo ang umiiral sa RWAs. Ang pag-tokenize ng isang real-world asset ay isa lamang bahagi ng proseso. Maaari pa ring kailanganin ng aplikasyon ang tuloy-tuloy na impormasyon tungkol sa asset na iyon at sa mas malawak na merkado nito. Kaya naman, ang infrastructure na nag-uugnay sa real-world data → blockchain → application logic ay naging fundamental na bahagi ng sistema. Ang “oracle tax” ay naglalarawan sa gastos ng external dependency na ito. At dito nakikita ang koneksyon ng arkitektura ng Rialo sa quiz: dahil ginagawa nito ang data feeds bilang native na bahagi ng infrastructure, disenyo ang Rialo upang bawasan ang pagkakadepende sa hiwalay na external data integrations para sa mga aplikasyon na nangangailangan ng real-world information. Ang tamang sagot ay 2️⃣ Mahal na external data services.
