GravityScore: an approach to rating management in a decentralized network

Decentralized networks offer unique, previously unavailable opportunities, allowing people to store, transfer, and accumulate values without a custodian. After many years of expansion, the world of decentralized solutions is currently represented by a multitude of isolated blockchains, where assets are transferred across through centralized gateways, and data is provided through centralized oracles.

Thus, much of the business logic depends on a large number of disparate independent entities, some of which remain largely centralized. So far, no single project has aimed at integrating these processes in a fully decentralized way, except Gravity Protocol. Gravity introduces an innovative approach to interoperability that allows for a greater decentralization without introducing a new native token. For more information, read our article Introducing Gravity Protocol and the Gravity Whitepaper.

Indeed, the introduction of a new native token in a cross-chain solution looks unnecessary when each of the target blockchains has its token. To solve some aspects of the issue of reputation, one strategy that Gravity implements is the requirement for all Gravity nodes to lock funds in one of the supported blockchains. Even so, the issue of managing interactions among the participants remains open, which makes it necessary to introduce a special mechanism called GravityScore.

Peer-to-peer rating

In a blockchain system, the oracles are usually seen as providers of the “ultimate truth”. It is important, thus, to properly regulate the relationship between them and establish checks and balances that would prevent malicious actors from disrupting the stability of a system. One of the ideas is to create higher-level entities that would observe and be in control of oracles. However, if looked upon closely, it becomes evident that this solution does not solve the problem at hand. Hypothetically, the end users that receive data could serve as such judges but it seems improbable that achieving a sufficient enough reaction speed in that system is feasible. Therefore, there remains a need in Gravity Protocol to regulate the relationship amongst peers, which is being solved by GravityScore.

As stated in the Gravity Whitepaper:

Oracle systems require trust. Trust is a fundamental concept that represents the level of risk to individual users of a system, where the higher the trust, the lower the risk assessment of the extent of potential damage in the event of force majeure or attack is. The trust in a system is essentially the sum total of trust in individual oracles, which is dependent on the history of actions inside and outside the system and on internal mechanisms that conduct monitoring and evaluation of the reputation of oracles. To maintain the trustworthiness of oracle networks, it is of absolute necessity to incorporate built-in security systems and self-governance strategies, capable of working automatically and for manual interventions. For instance, an oracle that has become malicious and capable of affecting the entire system, should automatically be excluded from the consensus of active oracles that sign the data and deliver it to a target blockchain.

GravityScore is a subsystem of the Gravity Protocol that allows for the evaluation of each Gravity Node’s behavior. Two entities are needed to be implemented on the internal Gravity ledger to achieve that:

• p2pScores —a numerical representation of the nodes’ opinion about each other;
• GravityScore — the resulting rating vector, based on separate p2pScores.

A great deal of research about rating within p2p networks took place in the era of the first file hosting services. A number of different rating systems were created: ReGreT, EigenTrust, models using the Bayesian approach, and many others. In Gravity Protocol, EigenTrust was chosen because it satisfies the requirements of trust transitivity, is easy to implement, and computationally inexpensive.

In the Gravity network, nodes regularly provide p2pScores, which are then recalculated through the EigenTrust algorithm into the GravityScore vector. Thus, the relation between the entities of the Gravity reputation system is as follows:

GravityScore Update

Internal ledger updates

Internal Distributed Ledger (IDL) is a “software message bus” that supports communication of Gravity nodes with each other and provides storage with a quick finalization consensus. GravityScore updates in the internal ledger occur at regular intervals, simultaneously with the production of new blocks, and each new update is based on a recalculation of the current p2pScore.

To update the p2pScore, each node observes the other participants and refreshes its “opinion” status about its peers based on the results of the observation. Among the actions monitored, there are data feed accuracy, correct interaction with the customer’s smart-contracts, and timely updates of the Gravity internal ledger.

Over time, these evaluations are conducted as follows:

Each Gravity node sends a transaction with the current p2pScore to the Gravity ledger at its own frequency. The block producer updates the rating by calculating each participant’s rating according to the EigenTrust algorithm and the current p2pScores values.

Finally, below is the overall GravityScore update flow:

Updates in target chains

In contrast to the updates in the Gravity ledger, frequent synchronization in the target chains can be costly. To reduce this implied cost, a mixed approach can be used: an infrequent fixed period of rating updates (1h, 6h, etc.) and full update triggers when significant changes of the GravityScore of participants happen.

To summarize, this article describes the key points of the system design that allow Gravity nodes to form and update a general quantitative view of each other’s behavior and make decisions that support the network operation.

As stated in the Gravity Whitepaper:

…this is the key feature of Gravity binding it together and giving it integrity as a system or as a decentralized service that can be trusted. It is due to this decentralized reputation system that such properties as self-management in Gravity networks are achieved, along with secure mechanisms of disconnecting malicious nodes and protection against attacks on the network through the production of malicious nodes, which may suddenly constitute the majority. In addition, the flexibility of Gravity reputation management is also an important advantage that allows attracting and retaining new participants with a high reputation in the industry, allowing the expansion of the user base of the operating Gravity network.

To find more theoretical information about the reputation system, see the Gravity Whitepaper or the technical documentation about the reputation system.

Thanks to Dmitry Gubanov for providing this research article. For more information about the Gravity protocol, visit the Gravity website, join the community on Twitter or Telegram or contact press@gravity.tech.