DE (EN below)
In meinem letzten Beitrag habe ich erklärt, wie man Splinterlandskarten an jemand anderen sendet und wie man die Ids erhält.
In diesem Beitrag erkläre ich, wie man eingehende und ausgehende Delegationen einlesen kann.
Ausgehende Delegationen
Mit Hivejs kann man ganz einfach herausfinden, an wen ein Nutzer etwas delegiert hat und wie viel. Dafür gibt es die Funktion hive.api.getVestingDelegations an die man nur 3 Parameter übergeben muss.
- account für welchen Nutzer man die Liste erhalten möchte
- from bei welchem Nutzer die Liste starten soll
- limit die maximale Anzahl an Delegationen, die zurückgegeben werden soll. Maximum sind 1000!
Hat ein Nutzer an mehr als 1000 Nutzer etwas delegiert, so muss man mehrere Aufrufe ausführen und mit from beim letzten ausgegebenen Nutzer starten. Achtung, der übergebene Nutzer wird mit ausgegeben, somit nicht erst der nächste Nutzer.
Die Sortierung der Liste erschließt sich mir nicht, weder alphabetisch noch nach min_delegation_time ist die Liste sortiert.
Die Liste beinhaltet den Delegierenden, den Delegierten, eine Id, die min Delegations Zeit und die Menge in VEST.
"Min Delegations Zeit" bedeutet, wann die Delegation gestartet wurde und ändert sich nicht, wenn diese erhöht wird.
Da die Angabe in VEST ist, muss diese in Hive umgerechnet werden. Dafür werden total_vesting_fund_hive und total_vesting_shares benötigt.
Diese können über die Funktion hive.api.getDynamicGlobalProperties abgerufen werden.
Dabei errechnet sich die Hivepower durch:
total_vesting_fund_hive : total_vesting_shares * vesting_shares
Ist doch eigentlich ganz logisch, aber damit man nicht rechnen muss, gibt es die Funktion hive.formatter.vestToHive, die diese 3 Werte als Parameter erwartet.
Hier habe ich ein kleines Script erstellt, bei dem ihr sehen könnt, wie es funktioniert.
Eigentlich fehlt hier eine Abfrage, wenn es mehr als 1000 Delegationen gibt, müssten die nächsten abgerufen werden. Aber ich gehe mal davon aus, dass keiner an mehr als 1000 Nutzer etwas delegiert.
Falls ihr jemanden kennt, sagt Bescheid und ich erweitere das Script.
Eingehende Delegationen
Leider gibt es für eingehende Delegationen, also die Delegationen, die ein Nutzer von jemand anderen erhält, keine spezielle Funktion. Viel mehr müssen wir dafür die Funktion hive.api.getAccountHistory nutzen, die ich u.a. hier schon beschrieben habe.
Um alle eingehenden Delegationen zu erhalten, müsste man die ganzen Transaktionen eines Nutzers durchgehen, und da man mit einem Aufruf nur 2000 Einträge prüft, müsste man dutzende oder gar hunderte Aufrufe ausführen. 2000 Einträge sind es nur, wenn die Zahl der Delegationen in den 2000 Transaktionen unter dem übergebenen Limit liegen.
Bei @hive-coding habe ich aktuell sehr wenige Transaktionen, sodass 3 Aufrufe ausreichen.
Bei @mein-senf-dazu habe ich bereits über 170.000 Einträge auf der Chain. Somit würde ich mind. 85 Aufrufe benötigen. In der Tat sind es aber wegen abgebrochenen Aufrufen deutlich mehr, 236 Aufrufe.
Ich habe euch ein kleines Script erstellt, damit ihr seht, wie es gehen würde, es funktioniert auch, ist aber nicht zu empfehlen!
Um die bestehenden Delegationen zu erhalten, muss man den letzten Eintrag eines Delegierenden nutzen, bei dem vesting_shares nicht "0.000000 VESTS" ist. Dann wurde die Delegation beendet.
In Zeile 171-184 prüfe ich dies, speichere einen neuen Delegierenden in einem Array und gebe diesen aus. Das Array wird jedes Mal erneut geprüft, wenn eine Delegation gefunden wurde.
Hier findet ihr das Script, dass aber nicht zu empfehlen ist, da einfach sehr viele Aufrufe nötig sind, je älter bzw. eher aktiver ein Nutzer ist.
Alternative?
Eine alternative sollte HiveSQL sein, das noch kostenlos ist und kostenlos bleiben sollte, daher wäre es toll, wenn ihr für HiveSQL Proporsal von @arcange ein Vote gebt:
Vote for this proposal (#247) on Peakd.com
Vote for this proposal (#247) on Ecency
Vote for this Proposal (#247) using HiveSigner
Ich werde HiveSQL sicherlich in Kürze mal testen und dazu etwas posten.
Peakd.com nutzt dafür scheinbar Hive Keychain
Ecency vermutlich HiveSql oder hat eine eigene Datenbank dafür.
Sobald ich eine für jeden nutzbare Möglichkeit gefunden habe, werde ich dieses posten.
Wer Fragen hat, kann gern ein Kommentar da lassen. Am besten @mein-senf-dazu erwähnen, damit ich es mitbekomme.
EN
In my last post I explained how to send splinterland maps to someone else and how to get the ids.
In this post I explain how to read inbound and outbound delegations.
Outgoing delegations
With Hivejs you can easily find out to whom a user has delegated something and how much. For this there is the function hive.api.getVestingDelegations to which you only have to pass 3 parameters.
- account for which user you want to get the list
- from which user the list should start at
- limit the maximum number of delegations to return. Maximum is 1000!
If a user has delegated something to more than 1000 users, you have to make several calls and start with from at the last delegated user. Attention, the delegated user is also output, thus not only the next user.
The sorting of the list is not clear to me, neither alphabetically nor by min_delegation_time is the list sorted.
The list contains the delegator, the delegate, an id, the min delegation time and the quantity in VEST.
"Min delegation time" means when the delegation was started and does not change when it is increased.
Since the specification is in VEST, it must be converted to Hive. For this total_vesting_fund_hive and total_vesting_shares are needed.
These can be retrieved using the hive.api.getDynamicGlobalProperties function.
Here, the hivepower is calculated by:
total_vesting_fund_hive : total_vesting_shares * vesting_shares
This is actually quite logical, but so that you don't have to calculate, there is the function hive.formatter.vestToHive, which expects these 3 values as parameters.
Here I created a small script where you can see how it works.
Actually there is a query missing here, if there are more than 1000 delegations, the next ones would have to be retrieved. But I assume that nobody delegates anything to more than 1000 users.
If you know someone, let me know and I'll extend the script.
Incoming delegations
Unfortunately, there is no special function for incoming delegations, that is, the delegations that a user receives from someone else. Much more we have to use the function hive.api.getAccountHistory for that, which I already described here among others.
To get all the incoming delegations, you would have to go through all the transactions of a user, and since you only check 2000 entries with one call, you would have to do dozens or even hundreds of calls. 2000 entries are only if the number of delegations in the 2000 transactions is less than the limit passed.
With @hive-coding I currently have very few transactions, so 3 calls are enough.
With @my-senf-dazu I have already more than 170.000 entries on the chain. So I would need at least 85 calls. But in fact it is much more, 236 calls, because of aborted calls.
I have created a small script for you to see how it would work, it also works, but is not recommended!
To get the existing delegations you have to use the last entry of a delegator where vesting_shares is not "0.000000 VESTS". Then the delegation was terminated.
In lines 171-184, I check this, store a new delegator in an array, and output it. The array is checked again each time a delegation is found.
Here you can find the script, but it is not recommended, because simply a lot of calls are needed, the older or rather more active a user is.
Alternative?
An alternative should be HiveSQL, which is still free and should stay free, so it would be great if you vote for HiveSQL Proporsal by @arcange:
Vote for this proposal (#247) on Peakd.com
Vote for this proposal (#247) on Ecency
Vote for this Proposal (#247) using HiveSigner
I will certainly test HiveSQL in the near future and post something about it.
Peakd.com seems to use Hive Keychain for it
Ecency probably HiveSql or has their own database for it.
As soon as I find a usable way for everyone, I will post this.
If you have any questions, feel free to leave a comment. It's best to mention @mein-senf-dazu, so I don't miss it.