Galactica Network Reputation Design Implementation
The Galactica Network Reputation Framework binds other network components, namely Reputation Root Contract and zkCertificates to create a protocol capable of expressive DeSoc primitives.
It leverages Persistent Identities, which are protocol representations of humans, to quantify a multitude of users’ interactions with other users, dApps and the entirety of the ecosystem — the web3 footprint — and create a virtual correspondence to the real-world concept of reputation. dApps and other users can then use these data as inputs into their own business logic. Reputation is an immensely important social primitive — meritocratic governance, undercollateralized lending, attestations and social networks are only the tip of the iceberg of use cases it enables.
This article describes the Cosmos subnet-powered implementation and also includes a brief overview of other designs that were considered but not chosen. For an elaborate investigation into the properties of these other designs an inquiring reader is kindly directed to a standalone whitepaper with the same title available in the research section on our website.
Note that this is an exploratory implementation and our best shot so far, not necessarily an optimal, nor is it an exclusive solution and can be augmented with alternatives described here or those we have not considered.
We warmly welcome any feedback and critique.
Target Properties
This document specifies an approach to measuring a user’s web3 footprint in the Galactica Network (henceforth, Galactica). It is a central component of the reputation framework as it provides specific data concerning user behavior on Galactica. EVM blockchains have no direct way to access historical transaction data from on-chain smart contracts. This makes it a difficult task to calculate the reputation based on the user’s previous behavior.
A successful solution is expressive, efficient, and accurate:
- Expressive enough to provide the data needed for conceivable and reasonable reputation functions such that they can be flexible enough to be specified by users’ reputation functions (e.g. ecosystem contribution, creditworthiness, long-time loyalty);
- Efficient enough in terms of storage and computation to work in a decentralized and high throughput blockchain;
- Accurate enough to provide meaningful data that cannot be faked;
- Requires contingency options integrated into the node to provide a blockchain-wide possibility for contingent token transfers without requiring changes to the ERC20 standard;
- In the limited info stored setup, the burden of standard creation needs to be decentralized. In other words, different data feeds must be able to exist around one dApp. What to store must not be left entirely up to dApp creators;
This article first outlines the reputation function as well as the RRC, then the approaches considered are outlined and finally the current (Sub-chains) solution is presented.
Reputation function and RRC
Reputation functions are defined by dApps and users. They can either create a custom function based on the available on-chain data or reuse such functions provided by other parties. Available inputs for reputation functions are a ZKP by the user being rated and on-chain data. The ZKP is sent to the reputation smart contract, verified for ZK validity and consistency of the Merkle roots with chain data.
The Root reputation contract (RRC) is a special smart contract on the Galactica blockchain. It works as a registry for reputation requirements of contingent transactions. Every address can register a minimum score and reputation function in the form of an address to the smart contract defining the reputation function. Whenever someone wants to send funds to an address, the protocol looks up the reputation requirements in the RRC to determine if the transaction is contingent. For more information please consider the Reputation Root Contract (RRC) section in the Galactica Network Whitepaper.
Approaches Considered
There are various ways to measure a user’s web3 footprint and determine their reputation. Ideally, it takes the whole transaction history into account and offers expressive reputation functions while still being efficient enough to be verified by a distributed blockchain. This is a complex task with contradictory goals (expressiveness vs efficiency).
An exhaustive list can be found in Table 1 — we had to forego part of them right at the outset, as they do not possess the target properties.
Subchains Approach
While it appears challenging to implement, as it requires node development and also every validator will have to store more than just blocks, this approach is decentralized, trustless, and easy to use for everyone. As it will become clear from the information provided further in this document, this approach furthermore addresses all of the limitations described in the previous solutions considered.
Cosmos Subchains
Subchain is an independent network that is connected to the mainnet. The connection usually includes a bridge and technology that allows the exchange of information between the subchain and the mainnet. In this case, the IBC protocol will be utilized, allowing synchronization between the states of EVM-compatible networks. Subchains are often used to reduce the load on a mainnet by delegating specific features to them. They receive inputs from the main network, carry out computations and send the results back.
It was concluded that it is beneficial to use subchains for reputation metrics calculations. The subchain reads data from the mainnet blocks through RPC, validates block hashes, calculates reputation, then submits the calculation results back to the mainnet. The first subchain will be launched by Galactica and used to calculate the reputation metric that the governance framework will utilize to determine users’ voting power.
Reputation Module
The Reputation module is a typical Cosmos SDK modul and is embedded at the core of Galactica Network. The on-chain reputation calculation method utilized here allows the use of the logic present in a smart contract based on the Reputation value. This logic can be used to reach a consensus among Validators based on block production results, in addition to amending Reputation values.
Each Validator calculates Reputation values independently and only validates Merkle root hashes from the data they used for calculations.
The module operates in two synchronization modes:
- Sync (Historical) — a state in which the Reputation has not yet been calculated from historical data and the Reputation is actively indexing. In this state, the Reputation value cannot be used in other smart contracts;
- Live (On-head) — Reputation is calculated for the head block and it is possible to use the Reputation in other smart contracts and modules.
Stages of Historical Data Synchronization
During historical data indexing, a Validator performs the following actions:
- Reads the subsequent block;
- Validates blockchain hashes;
- For each transaction:
a. Decodes transactions and their events;
b. Carries out the formation of source data;
c. Carries out data aggregation by event type or another group;
d. Calculates Reputation based on aggregations calculated in the past;
e. Saves the result of the Reputation calculation in a smart contract.
Validators store source and aggregated data off-chain; however, they keep the Merkle root hashes of that data on-chain. To add new functions which build the source data and data aggregations, special EVM smart contracts (repositories) are provided. It makes it possible to add functions that expand the functionality of the Reputation module.
Utilizing multiple intermediate steps in the indexing pipeline makes storing data off-chain possible, allowing for lower on-chain storage. The smart contract that considers the reputation value is public — anyone can observe what the reputation consists of.
Live Blocks Processing
Live blocks processing utilizes the same algorithm as historical processing to calculate reputation metrics in every new block. It implements EVM hooks PostTxProcessing to subscribe for incoming transactions.
Contingent Transactions
When the live processing module receives a transaction, a check is carried out to verify its compliance with the established reputational requirements. This includes two mechanisms:
- An address on the Galactica Network can be set up with a threshold of a minimum reputation value needed by senders to be able to send funds to this address. In case the reputation of a sender is insufficient, the transaction will fail. This will work with native asset transfers as well as with erc20, erc721, and erc1155 token standards.
- A smart contract may set up reputation requirements for every public mutable method. The contract needs to have a view method, containing a dictionary of:
a. Method id;
b. Reputation metric id;
c. Condition;
If the executor does not meet the listed reputation requirement(s) — the transaction will fail.
Calculation Process
The implementation of a subchain (blockchain node) includes a special Indexer specifically for on-chain events. This Indexer can collect, store, and aggregate specific events described in a root on-chain contract.
For example, it can store and aggregate trades from multiple DEX protocols on the mainnet. The description for such logic would resemble the following:
Step 1:
- List of contract addresses of these DEXs
- List of trade methods from these DEXs ABIs (a list for every DEX)
- List of fields which should be stored in Indexer
Step 2:
- Using the resulting entries and a formula compute a specific value (e.g. total volume traded, number of trades, total fees paid).
The Reputation value, which is a result of an aggregation, will be re-calculated every block by all subchain Validators following given rules.
Using the Indexer, we can calculate metrics for every address, at every block. What remains is to actually calculate the Reputation. The formula (or formulas) for calculating it are located within the root smart contract, and Validators of a subchain will calculate Reputation based on values obtained from the Indexer, then push those values to the mainnet using IBC.
The role of subchains in this process is to avoid the overload of Indexers and only store on-chain what is required for critical calculations.
Delays
There is a delay between events that happen on the mainnet and those subsequently delivered to a subchain. This delay may be up to N blocks in duration (subject to further testing to estimate the exact delay), meaning that even in a subchain the Reputation is delayed, and thus, unsuitable for time-sensitive operations such as flash loans.
This delay may lead to a state where certain subchains may be utilized solely by specific protocol subcategories — e.g. a dedicated subchain for lending protocols. This specialization of subchains will allow them to track the interactions of a given user among themselves without delay.
For example, provide undercollateralized loans to those users who have a lot of positive activity on the mainnet (delayed info) and never failed to pay for a loan (instant data, located on a subchain). Such a hybrid Reputation metric may help lending protocols merge a user’s overall score from the mainnet, with a trustless lending rating that lives on the said subchain.
GalaLend Example
- Alice uses lending dApps on the Galactica Network. Some of them query her dApp-specific humanID in the smart contract to identify her uniquely. (The humanID is useful in this approach as it allows the computation of a user’s reputation when their activity is split over multiple addresses.);
- The lending dApps and other Galactica services usage history is aggregated and stored by the Galactica validators. Some of them are maintaining subchains and others — the mainnet. They use this aggregated data to calculate the reputation of every humanID in line with various formulas. The result of calculation — the reputation itself stored on every change in a special smart contract in the form of a Merkle tree.
- When Alice wants to present her reputation, she does it on-chain. The input is a ZKP that takes Alice’s zkKYC, her humanIDs for specific dApps, and the reputation results for these humanIDs from the smart contract mentioned in point 2. The ZKP proves Alice’s reputation score without revealing her concrete address(es), humanIDs, or intermediate ratings;
Subchain economics
This will be discussed in a separate article specifically dedicated to subchain economics.
