DORA: Scalable Distributed Oracles by Aniket Kate

I'm part of their research team and today I'm going to talk to you about the Dora our protocol for scalable and distributed Oracle protocols. So uh let's start with the word scalable and uh let's first establish that why we need scalability in the blockchain space. I'm pretty sure it is clear to many of you but as the web 3 and the D5 functions more and more it will be that we are going to use the same system now for doing different task not only just purely agree on a consensus and agree on the smart contract but we might be using the same set of system for running Oracle nodes providing randomness service for the games as well as the automation in general where we want to allow abstra account abstraction all sort of different things and the thing will be once we keep on adding these services here these nodes will be overwhelmed and because of that although some systems may look really fast when they begin it can happen eventually that they are much that there's a slowdown in terms of first throughput and then in latency for all such systems. So we can certainly expect as the blockchain grows as the usage of them grows for all sort of uh web3 applications that blockchain will be overwhelmed. And how can we solve this problem?

One thing we can do is to scale horizontally means for every different set of systems try to add more nodes and uh try to differentiate them across different systems. However, the failures does not really grow in this fashion. If you keep on adding uh nodes in a horizontal fashion, they'll be the system will become more errorprone. Another idea is that we'll uh have nodes which are vertically uh scalable in the sense that they have bigger compute power and more communication technology. However, all these things there are limit to this first and on top of that it can very well happen that the the system will slow down and it can also become significantly more uh costlier as it grows.

What it happens is that they also uh these both approaches can bring approaches to the cost barrier because you need to add more systems. We need more and more operators and we need bitter and becker systems and because of that it becomes expensive to add new nodes in the systems and eventually it can become an entry barrier because of these all this environment and the question that we ask is that can we do a better job with the same set of nodes and at supra we find that indeed we can do a much better job by observing some key insight into such environment and with that I want to introduce the supra's clan and tribe architecture So what we observe that there are very few task which we still need to work in what we know as super majority or 67% honest nodes which we'll call as a tribe and there we'll be running those task on those nodes which is very common all throughout the ecosystem. However, majority of task we find can be performed with just a honest majority of them and given such honest majority assumption we could divide those task much better and perform efficiency and this is what we known as supra client and drive model and the key thing here will be now given such a architecture the same say same node will be now much better utilized so let's say I want performing four task in a traditional system each node will have to run those four task let's say some Oracle problem some autoation service all of these things are working together each node will be performing those four task but with this client and tribe architecture only one task will be running as a tribe that means every node will be running and all other the four task will get divided among those four node so rather than running four task now every node node will be only running two task so it certainly make them much better scale and uh keep the latency and throughput much better how we do that and my aim will be to demonstrate that with the Oracle example but a brief uh our approach to talk about for sure we are not breaking any bounds or any knowledge that present over here the key idea is that uh we will be running a BF a consensus protocol but the uh and we are working on a supra BFT our new consensus protocol however this consensus protocol will be only used for integrity that means we'll never put any data there our data do not go on this it's only provides ordering and integrity through that and given such a approach we will see that most of other problem that we want to solve in the web3 world could become significantly more efficient and can run only on clans in particular we observe that we can do data delivery just in uh the clan or only majority no super honest majority required even in the synchronous world so is for the randomness service such as VRF service uh we want to do distributed key generation for all different tasks that can also happen just in the clan and as well as if we want to run Oracle service itself which will be focus of my talk today we'll be doing that it's important to understand that this is not a broadcast channels if you are used to that literature we are all our all our solutions are purely a synchronous nature and they are purely asynchronous primitive so with that once I establish our scalability approach let me now focus for my rest of the talk on how we are building Oracle server the one important advantage that you'll see from my talk here is that our approach of dividing the task in terms of ordering through an ordering service and rest of the solution uh just working in a clan also make the development much more easy. It becomes a very easy problem and we you will see that even a complex thing such as running a distributed Oracle in a synchronous environment can become much easy and easy to understand problem just in few minutes. Let's dive into Oracle.

So what we looking into is now our uh Dora protocol a distributed Oracle agreement protocol. So I don't what is the oracle problem. So most of you already aware of that but most of the prominent blockchain systems are not uh are not equipped a me with a mechanism to bring the data from outside world from exchanges environment whatever you call to the blockchain system directly and they cannot connect to those entities directly. What we need instead is a mechanism to somehow connect a mechanism or set of nodes which are going to take this information from the outside world and provide that to the blockchain in a secure and verifiable manner and that's where the distributed oracle problems come in. So how typically that happens let's start with the most simple step there that connecting the data sources to the Oracle nodes.

Okay. So the first thing you have to do is that there'll be those nodes which are uh for the uh for the security we want them to be distributed and they connected to the all these different nodes and those nodes basically collect data from the data sources. So in my figure on the left hand side you can see the data sources and they're connected to those nodes. Uh what we want to make sure is the two things in this case. First thing is that every data source is connected to multiple nodes because the sum of nodes could be crashed or may become turned malicious.

So we want to make sure that every data source gets opportunity to connect it to enough number of nodes and at the simultaneously we want to make sure that even every node is connected to multiple data sources because the sum of data sources may even turn malicious and may provide uh incorrect information or incorrect feed. So with that assuming that every data source is connected to some honest node and every honest node is connected to some data source we have we can make sure that the honest information can be available to the honest nodes in the system but the problem is still half solved. We have to collect this information and now feed that in a secure fashion to the blockchain. And this is a problem which we can call as the distributed oracle problem. So let's try to briefly define what it means.

It's not very complicated. It simply says that there are bunch of nodes. Each of them have a value which I'm showing you as a vi and we want to make sure that they all agree on that value and that they sign it and then forward that uh to the a particular smart contract that is expecting that value from them. So to make it work in that particular fashion uh we want to make sure that this value is available to them. So the way it can happen is that uh to to such a protocol uh should be required property that that protocol should indeed finish that means termination.

We want to make sure that this oracle node as a group output the same value the same key pair let's say if it is a BTC to uh USD exchange they say that the the value that we want to propose as the current value of the BTC to USD is this particular value. So that's the agreement property. And finally, we want to make sure that what is known as minmax validity that the final output should be something in the range of honest inputs. It should not be the case that an adversarial node proposed some outrageous value and we agree on that. That's certainly not a useful thing.

And it's important to observe here that given such a thing uh what we required in a traditional environment as it is done by the current Oracle node we required 67% honest majority that super honest majority that we ask for and it's a wellestablished bounds and limit which is coming from the similarity of this problem to baantine agreement problem if you heard this term or approximate algorithm problem and because of that we nearly required two3 majority why this two-third majority required could be easily explained by a simple example that I want to show and to do that I'm going to take a very simple approach toward building such a solution which I'll call as a SMR based approach which is the supra approach uh in general so we are going to assume that we have access to an ordering service just like any blockchain we just take transaction we order them and we're putting that on an SMR now given such a service here's a very simple way to build such a oracle So I'm going to show that with the four nodes here. So assume that on the left hand side as I'm showing there are four node systems as it is a four node system. One of them could be a malicious node and let's say my first node is a malicious node over here and they are all trying to put the uh take their data input for let's say uh BTC2 USD pair and try to put that onto the blockchain and in such a environment when such a uh data is getting sent the first yellow line there shows a possible improve from the adversary he may try to actually shift the value towards positive or negative the way it motivates it and we want to make sure that the final value that we agree upon is certainly in the honest domain. So in this example that means for one dishonest value I at least want two more honest values so that the final output will be in the honest range. To do that because we work in a synchronous environment for any fast system we have to make sure that the one node the node fourth node in my example just can't even send it data in time.

So we this just directly show that even with the simple example shows that to make the system work we required four node out of which one of them is dishonest which directly result into this two3 honest majority in general. So that's a very simple way that we take a complex problem as Oracle problem and show that how that can be easily extracted by assuming SMR service. But this abstraction also help us in a very interesting manner that so as we show that we still required three on three honest majority or n greater than 3f plus one when even when we go for oracle but I want to focus on one interesting aspect is that uh when we look at these data pairs there's there could be interesting characteristic that can be present over there that for honest parties or legitimate or correctly functioning parties we don't expect that their input will be diverging from each other a lot I mean let's Okay, let me take a simple example. Let's say we are measuring temperature or we are putting some extra input. All input, all honest parties are typically going to measure that in a very close range to each other.

And this is a nice observation which can be utilized. Same can be holding by the way for exchange data that all on nodes will see exchange data to be values to be very close to each other. And if we set that particular uh value to let's say a parameter delta now it is possible that this problem that required two3 majority in general system can become much easily solvable even purely for honest majority and that's what we call as dohar dora with the coherent cluster. So if there is a coherent cluster that is formed by the honest parties inputs the problem becomes much easier to solve and again because of the smi design I can just show this whole complex thing in just two slides. So let's take two examples.

Now you see my number of nodes reduced from four to three in this example. So uh first node is as always a ban node but let's say he give the input such that it is part of a coherent cluster. In some simple definition we say that coherent question is defined by a parameter delta that if the all the inputs are in a d range delta then we accept those as input. So if adversary puts the input in a coherent cluster we accept it and we move ahead just with the two inputs here even when the third slow inputs from honest guy did not appear on the SMR chain. Okay.

And if it happens on the other that adversary puts a value which is not in the current cluster too bad for the adversary. we are going to ignore it and we'll we'll wait for the input now from the honest party and then agree on such a system. So I want to again emphasize this aspect this SMR design makes it such a complex system much easy to understand just keep posting data and use ordering to build efficient protocols. So you can see here this directly shows that if the coherent cluster is satisfied then we can solve this problem just with three node which transact into only a simple honest majority and not super honest majority required. So because of that then uh typically we can expect that we running one SMR service and on top of that we could run multiple such uh oracle instances together.

I mean we may be running BTC to USD, E2 USD, you name it. All these things can be run efficiently uh for different data sources we can run and rather than every node running this oracle for each of the system now we could do a much much better job because each of them could be running fewer service or only maybe one service which can make the system uh function really well and provide a much better throughput. But it can indeed happen that there are extreme volatility situations that where those mal values may not match each other that they are not in that coherent cluster and even for honest inputs the values turning out to be not in that particular coherent cluster. Question there is then can we do better there. So as it turns out it's not that it's all or nothing.

If it turns out that this is a a really volatile situation and that we cannot agree on the value directly, we can have a fallback ready and we also have a fallback protocol where in the extreme volatile situation we may go for try to collect input from more parties so that we indeed go back to this uh simple design of 3F plus one honest majority and in that case then problem will turn from a clan problem to a tribe problem. uh but we we indeed expect that this to happen extremely regularly and what we turned out that we actually uh this is the pro basic protocol flow I already show followed there and what we did is that uh we looked at the results what we did is we take the UTC uh BTC versus USD data for a complete month to check that uh if we assume that all the sources are honest and uh correspondingly they gave their value how the trend look like in terms of the coherent clusters in the forming coherent clusters so that all the ones input will be close to each other. What we observe that uh in majority of cases with a really high probability like easily uh one in 90 like easily 95 100 instances for a small trade-off we could get coherent cluster of a much bigger value. So what I'm trying to show over here is that we uh we took different uh seven exchanges where we collected a data for a month. We on purpose pick the month of the October or November where we had to deal with the uh FTX related uh issues so that we can indeed see the high flexibility reason.

And what we did there is that we took this data and we try to see uh when we look at the input from these different exchanges how close were they to each other and if we form a coherent cluster value uh how many times we can be sure that we can continue to have run the program much more efficiently. So the chart on the right hand side shows more on the x and x uh x-axis show the agreement distance which precisely shows how much is the distance for simplicity of expression we are showing on the x-axis not the exact value which will be few dollar uh but basically a ratio in terms of the uh the difference of the value as compared to the average value that we've seen throughout the uh throughout that particular period and what we observe here is that even when aggregate distance of 1.2 which which can also look by the very similar to the slipage that you expect at all the exchanges for really small ex uh seepage as the slippage we increase as we increase the agreement distance indeed the protocol functions much better but even for really small sweepage values majority of time easily 90 amount 90 uh 90% of more times we can see that the problem becomes cluster problem and can be solved much more efficiently for all the Oracle question. With that, I'm coming to the end of my talk. Uh my aim here was to demonstrate the scalability approach that Supra is taking.

I was able to only talk about the Oracle problem over here. But uh we are working on many other interesting problems in this space and I indeed look forward to communicate with all of you for any question that they have regarding Dora as well as for the other solution that we're working on. So I'll be around in the stage after my talk and I look forward to communicate you with you further. Thanks a lot.