Reward Distribution

Jellyverse Architektur

Übersicht

Wie allgemein bekannt ist, erfordert jede Ausführung auf der Ethereum Virtual Machine (EVM) die Bezahlung von Gas-Fees (Gebühren). Daher ist eine automatisierte Verteilung von Rewards (JLY Tokens) nicht effizient und muss vom Nutzer manuell eingesammelt werden (claimen).

Die Berechnung und Verteilung der Rewards muss konfigurierbar und überprüfbar sein, um neuen Projekten den Aufbau auf Jellyverse zu ermöglichen und die Dezentralität des Ökosystems zu gewährleisten. Die Belohnungsverteilung ist eines der Schlüsselelemente des Jellyverse und besteht aus zwei Smart Contracts:

1. minter.sol

2. rewarddistributor.sol

Diese beiden Smart Contracts arbeiten nahtlos zusammen, um eine wöchentlich wiederkehrende Distribution zu ermöglichen. Einfach ausgedrückt kann jeder Benutzer eine Off-Chain-Berechnung durchführen, wobei ein bereitgestellter (oder optionaler) Snapshot verwendet wird, um festzustellen, welche Adressen berechtigt sind, Belohnungen zu erhalten. Dieser Ansatz gewährleistet Flexibilität, vollständige Dezentralisierung und Effizienz im Verteilungsprozess.

Minter.sol

Dieser Smart Contract wird einen Ownable-Smart Contract erben, sodass er von der Governance aufgerufen werden kann, um wichtige Parameter zu aktualisieren.

Reward Distributor

Um die Gas-Effizienz zu optimieren, folgt das System einem wöchentlichen Zyklus. Innerhalb dieses Zyklus wird ein Snapshot erstellt, die Verteilung der Rewards berechnet und anschließend für die Benutzer zur Verfügung gestellt. Benutzer können Token nur für einen Snapshot (Zyklus) gleichzeitig beanspruchen. Wenn sie über einen längeren Zeitraum keine Rewards über die Claim-Funktion erhalten haben, sind mehrere Ausführungen möglich. Um diesen Prozess zu erleichtern, wird ein Multicall-Mechanismus verwendet.

Von einem technischen Standpunkt aus ist es möglich, jeden Snapshot und jedes Zeitintervall für die Verteilung auszuwählen. In der Praxis ist jedoch die Erstellung von JLY-Token im JLY-Vertrag festgelegt und dient als Einschränkung für den Reward-Distributor. Darüber hinaus könnte die Community eine Einigung über einen inoffiziellen, leicht überprüfbaren Abstimmungszyklus erzielen, der alle X Blöcke stattfindet.

Das System kann die Blockscout API oder ähnliche Dienste für die Erstellung von Snapshots verwenden. Jedoch ist es von entscheidender Bedeutung, die Sicherheit durch die Implementierung eines On-Chain-Snapshots zu verbessern, möglicherweise unter Verwendung von Cryo. Dieser On-Chain-Snapshot sollte genau mit dem Snapshot übereinstimmen, der aus der Blockscout API (oder anderen Quellen) erhalten wurde.

Aufgrund der Komplexität im Zusammenhang mit der Stimmrechtsberechnung, die von der Sperrfrist im Staking abhängt, ist es entscheidend, eine Momentaufnahme des gesamten relevanten Zustands durchzuführen. Anschließend kann ein Off-Chain-Skript die Daten nutzen um einen 'Merkle-Patricia-Tree' eines gegebenen Zustand zu erstellen. Dadurch kann jeder Nutzer leicht überprüfen, dass derselbe Merkle-Tree unter Verwendung desselben Zustands (Snapshot / Momentaufnahme) erstellt wurde.

Für jeden Snapshot wird eine JSON-Datei generiert und als "<blockNumber>_snapshot.json" benannt.

Ein Off-Chain TypeScript verwendet die OpenZeppelin Merkle-Tree-Bibliothek, um einen Merkle-Tree für diesen Snapshot zu erstellen. Berechnungen für Token-Ansprüche von Liquiditätsanbietern oder Stakern (Chest-NFTs) sollten auf einem Prozentsatz der wöchentlichen Emission von JLY-Token basieren. Um die Gasnutzung zu optimieren, werden diese Berechnungen Off-Chain durchgeführt. Das Skript kann ebenso in Python, Rust, Go oder einer anderen geeigneten Sprache geschrieben werden. Jeder Datenpunkt des Merkle-Tree sollte den Index im Merkle-Tree, die Adresse des Begünstigten und die Anzahl der JLY-Token, die diesem Begünstigten zustehen (skaliert auf 18 Dezimalstellen), enthalten.

Der Merkle-Tree wird sowohl auf IPFS als auch in einem GitHub-Repository hochgeladen. GitHub dient als zentraler Ort zur Speicherung aller Snapshots und ermöglicht einen bequemen Zugriff. Zusätzlich wird er auf IPFS gespeichert, um die Dezentralisierung sicherzustellen.

Zur Verwaltung von beanspruchten Tokens und zur Verhinderung von doppelten Ansprüchen wird eine Bitmap namens "Claimed" verwendet. Es ist beabsichtigt, dies mithilfe des BitMaps-Contracts von OpenZeppelin für Effizienz und Zuverlässigkeit umzusetzen.