KATE ANIKET (US)
TOBKIN JOSHUA (US)
YANG YIN (CN)
US20220147774A1 | 2022-05-12 | |||
US20220278854A1 | 2022-09-01 | |||
US20190394047A1 | 2019-12-26 |
CLAIMS What is claimed is: 1. A method comprising: obtaining, by a first oracle node of a consensus network, a first set of data points from a data source that is external to the consensus network having a plurality of nodes; obtaining, by a second oracle node of the consensus network, a second set of data points from the data source that is external to the consensus network; computing, by the first oracle node, a first median of the first set of data points; computing, by the second oracle node, a second median of the second set of data points; forming, by an aggregator node, a cluster of data points from the first set of data points and the second set of data points, wherein the cluster contains data points within a predetermined distance; proposing, by the aggregator node, the cluster to the plurality of nodes such that a vote on the cluster is performed by the plurality of nodes; generating, by the aggregator node, a quorum certificate message in response to the vote; and committing, by the aggregator node, the cluster to a block of the consensus network. 2. The method of claim 1, wherein the distance defines a maximum distance between any two data points of the cluster. 3. The method of claim 1, wherein the consensus network comprises oracle nodes, aggregator nodes, and blockchain nodes. 4. The method of claim 1, wherein forming, by an aggregator node, a cluster of data points from the first set of data points and the second set of data points, wherein the cluster contains data points within the predetermined distance, comprises: computing a distance between each point of the first set of data points and each point of the second set of data points; inserting values into the cluster corresponding to the first set of data points and each point of the second set of data points that are within the predetermined distance; and excluding values from the cluster corresponding to the first set of data points and each point of the second set of data points that exceed the predetermined distance. 5. The method of claim 1, further comprising: detecting volatility of the first set of data points or the second set of data points, wherein detecting volatility comprises: comparing a value from the first set of data points or the second set of data points with a previous value that is weighted by a constant parameter and a historical value parameter; and classifying the volatility based on the comparison of the value. 6. The method of claim 1 wherein the cluster of data points from the first set of data points and the second set of data points includes the first median and the second median.. 7. The method of claim 1, wherein generating, by the aggregator node, the quorum certificate message in response to the vote comprises: receiving votes from a set of oracle nodes of the consensus network, wherein each vote is generated by an oracle node of the set of oracle nodes; and creating the quorum certificate in response to receiving a vote from a majority of oracle nodes from the set of oracle nodes. 8. A distributed oracle agreement system comprising: a consensus network comprising a set of oracle nodes and an aggregator node; wherein the set of oracle nodes includes a first oracle node configured to: obtain a first set of data points from a data source that is external to the consensus network; compute a first median of the first set of data points; wherein the set of oracle nodes includes a second oracle node configured to: obtain, a second set of data points from the data source; compute a second median of the second set of data points; wherein the aggregator node is configured to: form a cluster of data points from the first set of data points and the second set of data points, wherein the cluster contains data points within a predetermined distance; propose the cluster to the set of oracle nodes such that a vote on the cluster is performed by the set of oracle nodes; generate a quorum certificate message in response to the vote; and commit the cluster to a block of the consensus network. 9. The distributed oracle agreement system of claim 8, wherein the predetermined distance defines a maximum distance between any two data points of the cluster. 10. The distributed oracle agreement system of claim 8, wherein the aggregator node is further configured to: compute a distance between each point of the first set of data points and each point of the second set of data points; insert values into the cluster corresponding to the first set of data points and each point of the second set of data points that are within the predetermined distance; and exclude values from the cluster corresponding to the first set of data points and each point of the second set of data points that exceed the predetermined distance. 11. The distributed oracle agreement system of claim 8, wherein the set of oracle nodes is further configured to: detect volatility of the first set of data points or the second set of data points, wherein detecting volatility comprises: compare a value from the first set of data points or the second set of data points with a previous value that is weighted by a constant parameter and a historical value parameter; and classify the volatility based on the comparison of the value. 12. The distributed oracle agreement system of claim 8, wherein the cluster of data points from the first set of data points and the second set of data points includes the first median and the second. 13. The distributed oracle agreement system of claim 8, wherein to generate, by the aggregator node, the quorum certificate message in response to the vote comprises: receiving votes from a set of oracle nodes of the consensus network, wherein each vote is generated by an oracle node of the set of oracle nodes; and creating the quorum certificate in response to receiving a vote from a majority of oracle nodes from the set of oracle nodes. 14. A method comprising: obtaining, by a set of oracle nodes, a first set of data points and a second set of data points from a set of data sources that is external to the set of oracle nodes; selecting a cluster value from the set of first set of data points or the second set of data points; forming, by the set of oracle nodes, a cluster of data points from the first set of data points and the second set of data points, wherein the cluster of data points are within a predetermined distance of the cluster value; proposing, by a node of the set of oracle nodes, the cluster value to the other nodes of the set of oracle nodes, such that a vote on the cluster is performed by the set of oracle nodes; generating, by the node, a quorum certificate message in response to the vote; and committing, by the node, the cluster to a block of a blockchain. 15. The method of claim 14, wherein the predetermined distance defines the maximum distance between any two data points of a cluster of data points. 16. The method of claim 14, wherein forming, by the set of oracle nodes, a cluster of data points from the first set of data points and the second set of data points comprises: computing a distance between each point of the first set of data points and each point of the second set of data points; inserting values into the cluster corresponding to the first set of data points and each point of the second set of data points that are within the predetermined distance; and excluding values from the cluster corresponding to the first set of data points and each point of the second set of data points that exceed the predetermined distance. 17. The method of claim 14 further comprising: detecting volatility of the first set of data points or the second set of data points, wherein detecting volatility comprises: comparing a value from the first set of data points or the second set of data points with a previous value that is weighted by a constant parameter and a historical value parameter; and classifying the volatility based on the comparison of the value. 18. The method of claim 14 wherein the cluster of data points from the first set of data points and the second set of data points includes a first median and a second median. 19. The method of claim 14, wherein the set of oracle nodes and the blockchain are components of a consensus network. 20. The method of claim 14, wherein the first set of data points and the second set of data points are each vectors that include multiple data points, and wherein the predetermined distance is the distance of the vector coordinates from an origin of a vector space. |
[0048] Upon failing to form a cluster (for reasons described above), the aggregator node 202 may receive fallback votes 204 from multiple nodes of the oracle network 104. If any aggregator node receives enough votes to satisfy a fallback quorum, the aggregator node 202 sends a fallback proposal with a quorum certificate to the blockchain network. The fallback proposal may be generated by receiving votes from 3^ + 1 nodes with the aggregators waiting to receive data values from 2^ + 1 nodes. While generating the fallback proposal, the oracle network computes median values from the data values from 2^ + 1 nodes. In some embodiments, the oracle network 104 may process multiple data values (e.g., a set of values) from the data sources simultaneously. To process multiple data values, an additional step to detect anomalous data source values can be performed. For example, there may be relationships that exist amongst different variables that are received from the data sources. For example, let variables ^ ^ , ^ ^ , and ^ ^ denote values of the ratios BTC/USD, ETH/USD, and BTC/ETH, respectively. The oracle network 104 may have a predetermined relationship that ^ ^ = ^ ^ ∗ ^ ^ among these variables. In an ideal relationship, ^ ^ − ^ ^ ∗ ^ ^ = 0. In practice, due to variation in observation time (e.g., receiving the data value data source) and information propagation across different data sources |^1 − ^2 ∗ ^3| may be greater than zero. However, it may be expected that |^1 − ^2^3| ≤ ^ ^ where ^ ^ is the correlation distance denoting a reasonably small deviation that may exist under normal circumstances. The oracle network 104 may use the correlation between variables may to detect anomalous behaviors in the variables. For example, let ^( ^ ^ , ^ ^ , ⋯ , ^ ^ ) ∶ (^ ^ ∪ {0}) ^ → ^ ^ ∪ {0} denote a function that takes values (e.g., non-negative values) of variables (e.g., a commodity price) and computes the invariant that exists amongst them. For an ideal set of values, the invariant value is “0”. [0049] In practice, the oracle network 104 may assign a predefined correlation distance ^ ^ for each such ^-tuple of values (e.g., commodity prices). The oracle network 104 may detect an anomaly whenever the invariant is greater than the predefined correlation distance, such as ^( ^ ^ , ^ ^ , ⋯ , ^ ^ ) > ^ ^ . The oracle network 104 may also perform forensic analysis using the example, as described above, the oracle network 104 detects an anomaly if ^( ^ ^ , ^ ^ , ⋯ , ^ ^ ) > ^ ^ . If an anomaly is detected, then at least some values from data sources are exhibiting anomalous activity. [0050] In an example with data sources providing data about multiple variables τ, the oracle network 104 may compute multiple invariants to detect whether a particular data-source is outputting anomalous values. For an ^-th data-source, the oracle network 104 can compute ^ ( ^ ^ , ^ ^ , ⋯ , ^ ^ ) = ^ ^ , where ^ ^ is the invariant deviation. To detect anomalous activity, the oracle network 104 compares ^ ^ > ^ ^ + ^ ^ ^ ^ , where ^ ^ is arithmetic mean of values of ^ above for data sources and ^ ^ is the standard deviation. ^ ^ is a tolerance parameter (e.g., a constant parameter) that is configurable to the configuration network 104 and data sources 102. If ^ ^ > ^ ^ + ^ ^ ^ ^ , the data sources is determined anomalous. When the oracle network 104 performs for values of multiple variables τ, similar multivariate analyses may be used to detect if one or more nodes are behaving anomalously. [0051] In order to use vectors, the DORA process presupposes that all dimensions of each vector are independent of the other dimensions. Let ^ ^ = (^ ^^ , ⋯ , ^ ^^ ) represent an n- dimensional vector provided by an ^-th data-source. The node receives such vectors from at least 2^ ^ + 1 data sources and computes a median vector by computing component-wise medians of the input vectors. For example, if a node receives vectors (^ ^ , ⋯ , ^ ^ ) from m different data- sources, then the median vector is computed as follows: ^^^^^^(^ ^ , ⋯ , ^ ^ ) = (^^^^^^(^ ^^ , ^ ^^ , ⋯ , ^ ^^ ), ⋯ , ^^^^^^(^ ^^ , ^ ^^ , ⋯ , ^ ^^ )). The oracle node then sends the median vector to the aggregator node as described above. Similar to as described above, the data-sources may be weighted. To apply a weight to the vector, the oracle node computes the median by computing component-wise weighted median. [0052] To form a cluster using vectors, the agreement distance is denoted as ^. Two vectors ^ ^ and ^ ^ agree with each other if ||^ ^ − ^ ^ || ^ ≤ ^. As briefly described above, the distance is L2-norm for distance for the vector configuration. ||^ ^ − ^ ^ || ^ = ^(^ ^^ − ^ ^^ ) ^ + (^ ^^ − ^ ^^ ) ^ + ⋯ + (^ ^^ − ^ ^^ ) ^
[0053] A set of vectors {^ ^ , ⋯ , ^ ^^^^ } forms a cluster if all the vectors mutually agree with each vector in the set as defined above (e.g., within the agreement distance). In another example, Let there be ^ data-sources. Let ^′ be a depth of an orderbook of transactions. Let (^ ^^ , ^ ^^ ), ⋯ , (^ ^^^ , ^ ^^^ ) denote the orderbook given by ^-th data source. The oracle network presupposes that any sell transaction executing at price ^, will also execute at any price ^′ > ^. Similarly, any purchase transaction executing at price ^, will also execute at any price ^′ < ^. Using these presuppositions, the oracle network 104 can compute a cumulative pv -distribution for an available liquidity of the commodity of the orderbook. The oracle network can compute a cumulative distribution separately for purchase transactions and sell transactions. The cumulative distribution (^ ^^ , ^ ^^ ) denotes a cumulative volume ^ ^^ of the commodity available for purchase/sell at price ^ ^^ at ^-th source/exchange. All honest sources should exhibit highly correlated pv-distributions. In this example, the oracle network is processing two-dimensional data and therefore, there is a possibility of data manipulation along both the directions. Additionally, the dimensions of the data are not independent of each other because a commodity with greater transaction higher volume can potentially increase a price of the commodity, and similarly a lower price can potentially increase the transaction volume. In the absence of any adversary (i.e., all exchanges executing transactions are honest), the ideal representative value may be represented ∑ ^ by ^^^ ∑ ^ ^ ^ ^ ^ ^ ^^ ^ ^^ ^ ^ ^^ . In other words, the ideal representative price may be the mean of the pv - output a single price, the oracle network 104 combines the purchase-side and sell- side distribution and computes a volume weighted mean as shown above. If the combined distribution is skewed toward the sell-side, the computed price would tend to be on the higher side, indicating higher overall price at which a trade can potentially happen considering the available liquidity in the market. Analogously, the computed price would be on the lower side if the combined distribution is skewed toward the buy-side, indicating lower overall price at which a trade can happen considering the available liquidity in the market. In an example where not all exchanges are honest, the adversary may add spurious (^′, ^′) values in the orderbook of corrupted sources. [0054] In another example the term “pv-distribution” being cumulative, separately on buyside and sellside, will be implied. For any given pv-distribution, derived from the orderbook of a data source, the oracle network 104 estimates a volume ^ ^ at any arbitrary ^ ^ , where ^ ^ < ^ ^ < ^ ^^ . For a continuous domain, a quadratic regression may be computed such that under normal circumstances, the cumulative pv-distribution tends to exhibit quadratic therefore, a quadratic regression on the discrete pv -distribution would give the ability to transfer the distribution into a continuous domain. However, a risk of the quadratic regression is that a single abnormal point can affect the quadratic curve in an adverse fashion. The adverse effect increases as the number of points under adversarial control increases. [0055] In another example, a piecewise-linear interpolation for any two (^ ^, ^ ^ ) and (^ ^, ^ ^ ) may be performed. The Piecewise-linear interpolation uses the equation ^(^ ^, ^ ^ ) + (1 − ^)(^ ^ , ^ ^ ), where 0 ≤ ^ ≤ 1 provides the oracle network 104 the ability to find the volume ^ ^ at any point ^ ^ between ^ ^ and ^ ^ . One advantage of using piecewise linear interpolation is that the adverse effect only starts after the adversarial point in the cumulative distribution and the part of the piecewise-linear distribution before such an adversarial point remains unaffected. Another advantage of piecewise-linear interpolation over quadratic regression is the speed at which it can be computed. In some cases, the intermediate volume found via linear interpolation would likely be lower than the one found via quadratic regression in most cases. After the oracle network 104 has obtained pv-distributions from all the data sources in the continuous domain, the distributions may be sampled at a regular interval at points ^ ^ = ^ ^ + (^ − 1)^, where ^ is the sampling interval, ^ is from 1 to ^ , and ^ is the sample size with ^ ^ being the best ask/bid (depending upon buy/sell side of the curve we look at). In some cases, ^ < 0 may be buy-side and ^ > 0 may be sell-side. For any given sampling price point ^ ^ , the oracle network 104 determines the median of (^ ^^ , ^ ^^ , ^ ^^ ) from pv-distributions computed for every data source from 1 to m as described above. The median pv-distribution would now have following points: (^^, ^^^^^^(^^^, ^^^, ⋯ , ^^^)), (^^, ^^^^^^^^^^, ^^^, ⋯ , ^^^^, ⋯ , ^^^, ^^^^^^ ( ^^^, ^^^, ⋯ , ^^^ ) ^. compute the mean of the median pv-distribution. If all data sources are honest, the median pv- distribution will have high correlation and any multiplicative vertical shift of the distribution is not ∑ ^ ^ ^^ ^ going to affect the mean of the distribution. The mean may be computed ^^^ ^^ ^ . In some embodiments, sets of nodes up to and including all oracle node performs the operations mentioned above upon obtaining orderbook data from various data sources. The set of nodes that perform the above operations output the mean price to an aggregator. Using the DORA protocol will account for available liquidity while outputting a price. This approach mitigates effects of adversarial deviation in the price or the volume. [0056] The oracle network 104 can detect high volatility by performing a history consistency check on the output for the round of DORA. For example, let ^ ^ denote the value output for a variable for a round ^. The oracle network 104 computes the history consistency check by performing the following check: ^ ^^^ − ^ ^ ^ ^ ≤ ^ ^ ≤ ^ ^^^ + ^ ^ ^ ^ , with ^ ^^^ indicating the S-value of the previous round (e.g., the value for round 4 in a current round 5). For any length/window of history ^ ^ , the oracle computes a standard deviation of all the S- values within this window denoted as ^ ^ . The oracle network 104 assigns a parameter ^ ^ to control the interval of acceptable values. oracle network 104 generates a flag for an S-value that anomalous if the S-value fails the history consistency check. It should be noted that the history consistency check is similar to a Z-score from statistics. A Z-score in statistics is defined as follows: ^ = ^^^ ^ . The Z-score indicates how many standard deviations away from the mean a given observation is. In contrast, to compute the history consistency check described above, the current value (observation) is within ^ ^ standard deviations of last ^ ^ values away from the ^ ^^^ value (e.g., the previous round). By using the previous value to check for anomalous current values, the oracle network 104 allows the history consistency check to be more adaptive to recent trends such as sustained higher deviations in previous rounds. This process improves the tolerance of anomalous data and reduces false positives when compared to using the arithmetic mean such as the Z-score. [0057] In some configurations, the oracle network 104 may classify the deviations using the history consistency check above. For example, if the ^ ^ falls within a bound defined by ^ ^^^ ± ^ ^ ^ ^ , the oracle network 104 flags the data value as Green as a highly consistent value. If ^ ^ instead falls within ^ ^^^ ± ^ ^^ ^ ^ , then the oracle network 104 may flag the data value as Yellow as a moderately value. If ^ ^ falls outside of ^ ^^^ ± ^ ^^ ^ ^ , then the oracle network 104 may flag the data value as Red as inconsistent. In some embodiments, the oracle network 104 may generate an additional message such as a notification or other metadata including the flag color or the consistency value. [0058] FIG. 3 illustrates an example of a timing diagram for the output of the DORA process to a consensus network according to an embodiment of the present disclosure. As described above, the oracle network receives data values from the set of data sources. The aggregator node of the oracle network forms a cluster and proposes the cluster to the nodes of the oracle network. The nodes of the oracle network vote on the proposed cluster and if a majority (50% + 1 node) vote to output the cluster, the aggregator node outputs the value to a block of the blockchain network. As further described, the gathering, cluster, and output process is asynchronous and as such each round may be a different length. FIG.3 illustrates multiple rounds (i.e., 5 rounds) of receiving values, forming a cluster, and outputting the value to the blockchain. Each round is started at a predetermined time interval such as every 1 second, 2 seconds, or another time interval. Each round has a start point 302A-302E that corresponds to a distributed oracle agreement process being initialized. Each round also has an endpoint 304A-304E. As shown in FIG.3, the endpoints 304A, 304B, 304C, and 304E visually illustrate the cluster being committed to the blockchain network 106. Endpoint 304D, however, visually illustrates a process being cancelled. In some instances, a distributed oracle agreement process is unable to form a cluster due to dishonest data sources, data sources experiencing failure, a failure of some nodes in the network, or another system issue. This can cause the distributed oracle agreement process executing between 302D and 304D to extend beyond a subsequent process (e.g., the end point 304D occurs after 304E). Because the distributed oracle agreement processes are asynchronous, the subsequent distributed oracle agreement process (i.e., round 5) initializes normally. At end point 304E, the cluster from round 5 is committed to the blockchain network 106. Each node of the oracle network 104 stops performing all operations corresponding to round 4 after the output from round 5 is committed to the blockchain network 106. [0059] FIG.4 illustrates a flowchart of a consensus network using DORA according to an embodiment of the present disclosure. For example, process 400 may include a series of computing operations that may be performed by one or more computing devices such as one or more processors of the distributed oracle agreement system as described above. [0060] The one or more processors of the distributed oracle agreement system may be specialized processors configured to execute instruction-set-architecture (ISA) instructions, machine instructions, machine dependent instructions, microcode, firmware instructions, state- setting data, or either source code or object code written in any combination of one or more programming languages, including an object oriented programming language such as PHP, Rust, Python, Ruby, Scala, C++ or the like, and conventional procedural programming languages, such as the "C" programming language or similar programming languages. The instructions may include one or more code segments. The code segment or machine-executable instructions may represent a procedure, a function, a subprogram, a program, a routine, a subroutine, a module, a software package, a class, or any combination of instructions, data structures, or program statements. The code segment may be coupled to another code segment or a hardware circuit by passing and/or receiving information, data, arguments, parameters, or memory contents. Information, arguments, parameters, data, etc. may be passed, forwarded, or transmitted via any suitable means including memory sharing, message passing, token passing, network transmission, among others. The instructions may execute entirely on the system gateway, partly on the system gateway, as a stand-alone software package, partly on the system gateway and partly on a remote computer or entirely on the remote computer or server. The remote computer may be connected to the system gateway through any type of network, including a hard-wired connection, a local area network (LAN), a wide area network (WAN), or the connection may be made to an external computer (for example, through the Internet using an Internet Service Provider). In various embodiments, electronic circuitry including, for example, programmable logic circuitry, field- programmable gate arrays (FPGA), or programmable logic arrays (PLA) may execute the computer readable program instructions by utilizing state information of the computer readable program instructions to personalize the electronic circuitry, in order to perform aspects of the present disclosure. [0061] Each block in the flowchart may represent a module, segment, or portion of instructions, which include one or more executable instructions for implementing the specified logical function(s). In some alternative implementations, the functions noted in the block may occur in a different order than is shown in FIG.4. For example, two operations shown in succession may be executed substantially concurrently, or the operations may sometimes be executed in the reverse order, depending upon the functionality involved. It will also be noted that each operation of flowchart can be implemented by special purpose hardware-based systems that perform the specified functions or acts or carry out combinations of special purpose hardware and computer instructions. While the following description uses the examples of data source values, an oracle network, and a blockchain network, these are merely illustrative, and any data sources can be processed in a similar manner by an oracle network that is a subset of nodes of a blockchain network and are not intended to be limiting. [0062] At block 402, the process 400 involves obtaining, by a first oracle node of a consensus network, a first set of data points from a data source that is external to the consensus network having a plurality of nodes. As described above, the set of data sources may be accessible to the oracle network. The first oracle network node obtains stored values from the set of data sources with each of the stored values corresponding to a value that varies over time. The first node computes the median of the 2^ ^ + 1 data sources that are monitored by the first node. [0063] At block 404, the process 400 involves obtaining, by a second oracle node of a consensus network, a second set of data points from the data source that is external to the consensus network. As described above, the set of data sources may be accessible to the oracle network. The second oracle node obtains stored values from the set of data sources with each of the stored values corresponding to a value that varies over time. [0064] At block 406, the process 400 involves computing, by the first oracle node, a first median of the first set of data points. As described above, The first node computes the median of the 2^ ^ + 1 data sources that are monitored by the first node. While the process 400 describes computing a median, this is not limiting as other computed statistical values may be used. [0065] At block 408, the process 400 involves computing, by the second oracle node, a second median of the second set of data points. As described above, The second node computes the median of the 2^ ^ + 1 data sources that are monitored by the second node. While the process 400 describes computing a median, this is not limiting as other computed statistical values may be used. [0066] At block 410, the process 400 involves forming, by an aggregator node, a cluster of data points from the first set of data points and the second set of data points, wherein the cluster contains data points within a distance. As described above, The aggregator node 202 attempts to form a cluster by computing a set of data values such as the medians or other statistical aggregate value of the first set of data points and the second set of data points that are within an agreement distance. The agreement distance defines the maximum distance between data values that may be included in the same cluster. For example, a first node of the oracle network provides a median of 100 dollars, a second node of the oracle network provides a median of 102 dollars, and a third node of the oracle network provides a median of 105. For any agreement distance greater than or equal to 5 units, a cluster can be formed with the values (100, 102, 105). Using the same example, any agreement distance greater than 2 units and less than 5 units will result in the aggregator node forming a cluster of (100, 102) while excluding the value 105. [0067] At block 410, the process 400 involves proposing, by the aggregator node, the cluster to the plurality of nodes such that a vote on the cluster is performed by the plurality of nodes. As described above, the aggregator node may propose the cluster or a selected/computed value from the cluster. For example, returning to the previous example with the cluster of (100, 102, 105), the aggregator node may select a value from the cluster or compute an average of the cluster. To propose the value, the aggregator node may communicate the value to the other nodes of the oracle network. [0068] At block 412, the process 400 involves generating, by the aggregator node, a quorum certificate message in response to the vote. As described above, the aggregator receives votes in response to the proposal of the cluster performed at block 410. The aggregator node will count the votes until a majority of votes is returned. After the majority of votes is returned, the aggregator node will prepare a quorum certificate including the value. [0069] At block 414, the process 400 involves committing, by the aggregator node, the cluster to a block of the consensus network. As described above, each node of the blockchain participates in the block chain network by receiving data such as from the aggregator node of the oracle network 104. The nodes of the blockchain network 106 may validate the data received and insert the data into a block of the blockchain if a consensus is satisfied. [0070] Under unusual circumstances, such as when none of the aggregator nodes is able to form a cluster, the distributed oracle agreement system switches to a fallback mechanism. When using the fallback mechanism, the requirement of total nodes increases to 3f + 1 with the aggregators wait for 2f + 1 nodes to provide a value and compute a median. In this fallback mechanism, the arithmetic mean can not be used anymore since the values introduced by the Byzantine nodes in this set of size 2f + 1 could be unbounded. Using the fallback mechanism, the oracle network computes a median from the agreed upon set of size 2f + 1. To further scale the fallback mechanism, the fallback process may be distributed by assigning multiple subsets of aggregators from the 3f + 1 nodes available to perform oracle functions in the entire consensus network. Multiple subsets can be selected randomly from nodes of the blockchain network 106. By selecting nodes of the blockchain network 106, every subset has an honest simple majority with a high probability (e.g., probability of failure is less than 1 in a Billion). The aggregators may be selected from nodes of the blockchain network 106 to ensure that there is at least one honest aggregator (e.g., no majority required) within the set of aggregators. Multiple aggregators may be used to ensure no liveness issues occur and progress on the protocol is continuously made. In contrast, conventional protocols must elect a new leader/aggregator if the leader/aggregator is Byzantine which delays progress of the protocol. The size and the number of the sets of aggregators are chosen such that each set of aggregators has an honest simple majority. Since under normal circumstances the sets of aggregators only need an honest simple majority, the responsibilities to track multiple variables and bring their values may be assigned to the sets of aggregators. [0071] FIG. 5 illustrates a performance chart 500 that shows a correspondence between cluster formation and agreement distance according to an embodiment of the present disclosure. As the time window during which data can be received by the oracle network 104 increases, it is expected to see more deviation in values among values of various data sources. Therefore, for a given value from the data sources, the aggregator node is able to form coherent clusters more often for 30 second windows as compared to 60 second windows. However, as shown in FIG.5, there is an increase in data availability from a data source between the 30 to the 60 seconds observation periods. This contributed to the increased percentage of coherent cluster formation for a 60 second window for larger data sets. Note that this choice of has a bearing on both the safety and the performance of the protocol. Smaller values of the predetermined distance (e.g., agreement distance) will result in the protocol having to fall back more often, whereas higher values of from the data source potentially allow higher deviation from the ideal representative value of the mean of honest values. If the value of a data sources increases or decreases significantly, for safety and performance reasons, the predetermined distance should be adjusted up and downwards accordingly. [0072] FIG. 6 illustrates a performance chart 600 that shows a correspondence between failure probability and number of aggregator nodes according to an embodiment of the present disclosure. In particular, FIG.6 shows a logarithmic plot of how the probability of having a set of all Byzantine aggregators is reduced as the size of the set of aggregators increases. For example, because up to 1/3 of the nodes in network of 100 nodes may be Byzantine, it is evident that as the size of the set of aggregator nodes within the network of 100 nodes increases, the probability of not having a single honest aggregator drops exponentially as illustrated in chart 600. [0073] FIG. 7 illustrates an example of a computing device 700 of a computer system capable of implementing distributed oracle agreement. The computing device 700 may include processor(s) 710 (e.g., CPU, GPU, or other processing unit), a memory 720, and communication interface(s) 740 (e.g., a network interface) to communicate with other devices and receive data from those devices, such as external data sources, proposed clusters, votes, quorum certificates, committed values to the blockchain, and other information, as described above. Memory 720 may include volatile memory, such as RAM, and/or non-volatile memory, such as ROM and storage media. Examples of storage media include solid-state storage media (e.g., solid state drives and/or removable flash memory), optical storage media (e.g., optical discs), and/or magnetic storage media (e.g., hard disk drives). The aforementioned instructions (e.g., software or computer- readable code) may be stored in any volatile and/or non-volatile memory component of memory 720. The computing device 700 may, in some embodiments, further include input device(s) 750 (e.g., a keyboard, mouse, joystick, controller, or touchscreen) and output device(s) 760 (e.g., a display, head-up display, AR display, VR display, printer). The aforementioned elements of the computing device 700 may be connected to one another through a bus 730, which represents one or more busses. In some embodiments, the processor(s) 710 of the computing device 700 includes both a CPU and a GPU. In some embodiments, the computing device 700 may be a networked set of computing devices communicatively coupled to a communication network such as a wireless network, wired network, cellular, satellite, or other means of communication between the networked computing devices. [0074] Instructions executable by one or more processors may be stored on a non- transitory computer-readable medium. Therefore, whenever a computer-implemented method is described in this disclosure, this disclosure shall also be understood as describing a non-transitory computer-readable medium storing instructions that, when executed by one or more processors, configure and/or cause the one or more processors to perform the computer-implemented method. Examples of non-transitory computer-readable medium include RAM, ROM, solid-state storage media (e.g., solid state drives), optical storage media (e.g., optical discs), and magnetic storage media (e.g., hard disk drives). A non-transitory computer-readable medium may be part of the memory of a computer system or separate from any computer system. [0075] While various aspects and embodiments have been disclosed, other aspects and embodiments are contemplated. The various aspects and embodiments disclosed are for purposes of illustration and are not intended to be limiting, with the true scope and spirit being indicated by the claims in this application. [0076] Embodiments implemented in computer software may be implemented in software, firmware, middleware, microcode, hardware description languages, or any combination thereof. A code segment or machine-executable instructions may represent a procedure, a function, a subprogram, a program, a routine, a subroutine, a module, a software package, a class, or any combination of instructions, data structures, or program statements. A code segment may be coupled to another code segment or a hardware circuit by passing and/or receiving information, data, arguments, parameters, or memory contents. Information, arguments, parameters, data, etc. may be passed, forwarded, or transmitted via any suitable means including memory sharing, message passing, token passing, network transmission, etc. [0077] The actual software code or specialized control hardware used to implement these systems and methods is not limiting of the methods and embodiments described herein. Thus, the operation and behavior of the systems and methods were described without reference to the specific software code being understood that software and control hardware can be designed to implement the systems and methods based on the description herein. [0078] When implemented in software, the functions may be stored as one or more instructions or code on a non-transitory computer-readable or processor-readable storage medium. The steps of a method or algorithm disclosed herein may be embodied in a processor-executable software module, which may reside on a computer-readable or processor-readable storage medium. A non-transitory computer-readable or processor-readable media includes both computer storage media and tangible storage media that facilitate transfer of a computer program from one place to another. A non-transitory processor-readable storage media may be any available media that may be accessed by a computer. By way of example, and not limitation, such non-transitory processor-readable media may comprise RAM, ROM, EEPROM, CD-ROM or other optical disk storage, magnetic disk storage or other magnetic storage devices, or any other tangible storage medium that may be used to store desired program code in the form of instructions or data structures and that may be accessed by a computer or processor. Disk and disc, as used herein, include compact disc, laser disc, optical disc, digital versatile disc, floppy disk, and Blu-ray disc where disks usually reproduce data magnetically, while discs reproduce data optically with lasers. Combinations of the above should also be included within the scope of computer-readable media. Additionally, the operations of a method or algorithm may reside as one or any combination or set of codes and/or instructions on a non-transitory processor-readable medium and/or computer- readable medium, which may be incorporated into a computer program product. [0079] The preceding description of the disclosed embodiments is provided to enable any person skilled in the art to make or use the present subject matter. Various modifications to these embodiments will be readily apparent to those skilled in the art, and the generic principles defined herein may be applied to other embodiments without departing from the spirit or scope of the subject matter. Thus, the present subject matter is not intended to be limited to the embodiments shown herein but is to be accorded the widest scope consistent with the following claims and the principles and novel features disclosed herein. While various aspects and embodiments have been disclosed, other aspects and embodiments are contemplated. The various aspects and embodiments disclosed are for purposes of illustration and are not intended to be limiting.