Dies ist eine Übersetzung des Original-Artikel von @blocktrades:
https://peakd.com/p/@blocktrades/roadmap-for-hive-related-work-by-blocktrades-in-the-next-6-months
Das BlockTrades-Team plant eine Menge zukünftiger Arbeiten für das Hive-Ökosystem. Dieser Beitrag beschreibt einige der Änderungen, die wir bisher geplant haben.
Ich möchte mich im Voraus entschuldigen, da dies immer noch ein etwas roher Abklatsch meiner Gedanken über manchmal komplizierte Themen ist. Das bedeutet, dass einige der Themen für jedermann geschrieben sind, während andere Themen ziemlich technische Details enthalten, die bei der ersten Lesung (und vielleicht auch bei späteren) wahrscheinlich schwer zu erfassen sein werden. Wenn wir der Umsetzung einiger dieser Ideen näher kommen, werde ich versuchen, auf einzelne Ideen aus diesem Beitrag in späteren Beiträgen näher einzugehen (falls jemand anderes diese Herausforderung in der Zwischenzeit nicht angenommen hat).
Ich teile diese Änderungen in mehrere Kategorien ein, weil sie sich auf verschiedene Systeme auswirken und daher unterschiedliche Planungsanforderungen haben.
Blockchain-Konsensus-Änderungen (Hardfork-Änderungen)
Es handelt sich hierbei um Änderungen des Governance-Modells von Hive, so dass diese Änderungen einen HardFork und die Zustimmung der 20 führenden Zeugen erfordern.
Änderungen im Hardfork-Modell erfordern, dass alle Nodes aktualisiert werden müssen, um weiterhin im Hive-Netzwerk arbeiten zu können, was die Koordination etwas mühsam macht. Die Hive-Entwickler versuchen daher zu vermeiden, dass zu viele Hardforks erforderlich sind (in der Regel werden mehrere Hardfork-Änderungen gleichzeitig geplant).
Der aktuelle Plan sieht vor, Hardfork 25 für etwa 6 Monate von jetzt an zu planen (hauptsächlich, um zu vermeiden, dass Austausche zu früh nach dem letzten Hardfork-Upgrade erfolgen müssen). Bei den für Hardfork 25 geplanten Protokolländerungen handelt es sich voraussichtlich um eher einfache Änderungen, die wahrscheinlich schon viel früher als in 6 Monaten kodiert werden.
Die geplanten Änderungen für den Hardfork sind NICHT erforderlich, um unsere anderen geplanten Änderungen am Hive-Ökosystem durchzuführen: Das bedeutet, dass wir viele wichtige und nützliche Änderungen am Hive vor dem nächsten Hardfork vornehmen können.
Was ist mit HMTs (benutzerdefinierte Token)?
Die einzige denkbare Änderung, die wir an den Blockchain-Regeln in Hardfork 25 vornehmen könnten und die nicht unbedingt einfach wäre, wäre die Aktivierung von HMTs (vor allem, weil der HMT-Code noch nicht gut getestet ist und vor der Veröffentlichung wahrscheinlich verbessert werden müsste).
Zum jetzigen Zeitpunkt haben wir noch keine Entscheidung darüber getroffen, ob HMTs aktiviert werden sollen oder nicht, weil wir der Meinung sind, dass es eine vernünftige Chance gibt, dass wir etwas Nützlicheres im Sinne einer Tokenisierung auf dem 2nd Layer realisieren können. Kurz gesagt, das Thema bedarf weiterer Forschung und wird in einem späteren Beitrag eingehend erörtert werden, nachdem wir die Optionen vollständig ausgelotet haben.
Meine persönliche Präferenz im Moment ist es, benutzerdefinierte Tokens auf der 2. Ebene unter Verwendung eines Smart-Contract Bewertungssystems zu implementieren, das viel mehr Flexibilität erlaubt, als dies bei HMTs möglich ist. Um dies jedoch machbar zu machen, müssen wir ein robustes Modell für dezentralisierte Anwendungen der 2. Ebene definieren (auf das in späteren Abschnitten dieses Beitrags näher eingegangen wird).
Erwähnenswert ist auch, dass es sich dabei nicht um exklusive Optionen handeln muss: Es ist möglich, HMTs auf der ersten Schicht und intelligente vertragsbasierte Token auf der zweiten Schicht zu implementieren. Aber dies könnte für Hive-Benutzer verwirrender sein und keinen wirklichen Nutzen bringen.
Governance-Änderungen geplant für Hardfork 25
Ablauf der Stimmabgabe für Zeugen, Bevollmächtigte und Vorschläge.
Gegenwärtig verfallen die Governance-Stimmen nicht, was zu Abstimmungen führen kann, die sich nie ändern, entweder aufgrund von Unachtsamkeit des Wählers oder in schlimmeren Fällen, weil der Eigentümer seine Schlüssel verliert oder verstorben ist (ja, bei Hive können Tote wirklich noch abstimmen). Dies kann zu nicht optimalen Abstimmungen führen, da der Stake die Menschen und Vorschläge, über die abgestimmt wird, nicht richtig überwacht.
Um dieses Problem anzugehen, werden wir die Abstimmungen über die Governance so einstellen, dass sie automatisch ein Jahr nach der letzten Governance-Aktion eines Kontos verfallen. Dies wird umgesetzt, indem für jedes Hive-Konto eine "Zeit der letzten Governance-Aktion" gespeichert wird (diese Information wird Teil der Profilinformationen eines Kontos sein).
Jedes Mal, wenn ein Benutzer eine Vollmacht zur Stimmabgabe erteilt oder über einen Witness oder einen Vorschlag (Proposal) abstimmt bzw. seine Stimme aufhebt, wird diese letzte Governance-Aktionszeit auf die aktuelle Zeit aktualisiert. Wenn ein Jahr vergeht, ohne dass das Konto eine Governance-Aktion durchführt, werden die Witness- und Proposalvotes des Kontos annulliert, und jede Vollmacht (Proxy) des Kontos wird zurückgesetzt.
Benutzeroberflächen wie Hive Wallets und Browser werden aktualisiert, um eine Warnung zu melden, wenn sich die Stimmen eines Kontos dem Ablaufdatum nähern. Solche Warnungen sollen verhindern, dass ein aktiver Benutzer vergisst, eine Governance-Aktion zu setzen, die das Ablaufen seiner Stimmen verhindert.
Nur um deutlich zu machen, wie dies in der Praxis funktioniert: Ihre Stimmen verfallen nur, wenn Sie ein ganzes Jahr lang keine Governance-Aktion ergreifen. Diese Änderung sollte sich also nur auf Personen auswirken, die nicht mehr "aufpassen", was vor sich geht (oder die die Kontrolle über ihre Schlüssel verloren haben).
Änderung des 5-minütigen Abstimmungsfensters in ein längeres Fenster und Bereitstellung proportionaler Belohnungen während des Fensters
Gegenwärtig führt eine Abstimmung, die früher als 5 Minuten nach der Veröffentlichung eines Beitrags stattfindet, zu weniger Kurationsbelohnungen für den Wähler. Dies führte zum Anstieg von Bots mit automatischer Stimmabgabe, die am oder nahe dem Ende dieses 5-Minuten-Fensters abstimmen, was manuelle Wähler stark benachteiligt.
Mit dieser Änderung wird es keine Strafe mehr für die vorzeitige Stimmabgabe für einen Post/Kommentar geben. Außerdem hat es keinen Vorteil mehr, früher abzustimmen als jeder andere, der innerhalb der neuen längeren Zeitspanne abstimmt.
Für Wähler, die innerhalb des Zeitfensters abstimmen, wird es immer noch einen Vorteil geben, aber die Idee ist, dass das neue Zeitfenster lang genug sein sollte, damit die manuellen Kuratoren gute Inhalte finden und so den Vote Bots gleichgestellt werden können.
Wie lang sollte das neue Fenster sein? Ich plädiere für einen Zeitraum zwischen 2 Stunden und höchstens 24 Stunden. Ich bin generell dafür, dass es näher an 2 Stunden liegt, um einen freundlichen Wettbewerb zwischen den manuellen Wählern zu ermöglichen und eine etwas zügigere Kuration zu fördern, die gute Inhalte schneller auf die Trendseite bringt.
Es wird nicht erwartet, dass durch diese Änderung automatische Abstimmungs-Bots abgeschafft werden, aber sie sollte den finanziellen Anreiz beseitigen, einen automatischen Abstimmungs-Bot zu benutzen, anstatt manuell abzustimmen.
Diese Änderung wird dennoch zu einem Anreiz führen, "populäre" Inhalte auszuwählen, da die Wähler in den ersten 2 Stunden etwas mehr Belohnungen erhalten als spätere Wähler auf einem Beitrag.
Das bedeutet, dass "intelligente" Bots mit automatischer Stimmabgabe wahrscheinlich anfangen werden, erfolgreichen manuellen Kuratoren hinterherzulaufen, indem sie gegen Ende der 2-Stunden-Periode abstimmen und versuchen werden, ihre Belohnungen zu maximieren. Im Großen und Ganzen scheint dieser Anreiz vorteilhaft zu sein, da er dazu führen dürfte, dass eine gute manuelle Kuratierung auch die leitende Kraft dafür sein wird, wie die Bots abstimmen.
Non-Konsens Änderungen an hived Blockchain-Software
Es handelt sich dabei um Änderungen, die ohne großen Aufwand vorgenommen werden können und bei denen oft nicht jeder seine API Node aktualisieren muss. Zu den Änderungen dieser Art gehören: 1) Geschwindigkeits- und Speicheroptimierungen, 2) kleinere Fehlerbehebungen, 3) Hinzufügung und Änderungen der API-Funktionalität. Sie sind in der Regel auch nicht sehr umstritten, da sie keine Auswirkungen auf das Governance haben.
Da nicht kontroverse Änderungen in der Regel nicht von allen ein Upgrade ihrer Node erfordern, können diese Änderungen veröffentlicht werden, sobald sie fertig sind, anstatt als Teil einer großen geplanten Veröffentlichung geplant zu werden. Als einfaches Beispiel haben wir seit HF-24 7 solcher Non-Consensus-Releases gehabt (wir befinden uns gerade bei Hived v1.24.7).
Die meisten dieser Änderungen betrafen nur die Betreiber von API-Nodes, so dass normale Witness und Exchanges ihre Nodes nicht aktualisieren mussten (die meisten Hive-Nodes laufen noch immer in v1.24.2).
Es gibt mehrere Bereiche, die wir untersuchen können, um Verbesserungen an der Blockchain ohne Konsens vorzunehmen:
- weitere Reduzierungen der Speichernutzung
- Verbesserungen der Peer-to-Peer-Netzwerk Ebene
- Verbesserungen der API-Dienste
- ein hived-Plugin zur Bereitstellung von Echtzeitdaten für Anwendungen im 2.ten Layer.
Von den oben genannten Bereichen halte ich 4) für die kritischste Veränderung. Gegenwärtig dauert es über 4 Tage, um alle vorhandenen Blockchaindaten mit einer neuen hivemind-Instanz zu synchronisieren. Wir sollten in der Lage sein, diese Zeit erheblich zu verkürzen, indem wir ein benutzerdefiniertes Plugin erstellen, das eine hivemind-Datenbank füllen kann (wir haben Messungen durchgeführt, die zeigen, dass die Füllzeit der hivemind-Datenbank auf einem System mit schnellem IO aufgrund von CPU-Engpässen auf der hivemind-Seite der Hauptengpass beim hivemind-Vollsynchronisations-Timing ist).
Ein weiteres Problem ist, dass der aktuelle "Live-Sync"-Prozess von hivemind absichtlich 2 Blöcke hinter dem Head-Block zurückbleibt, weil hivemind nicht in der Lage ist, Mikrobearbeitung durch hived zu verarbeiten. Die Erstellung eines Plugins, das direkt in die Datenbank von hivemind schreibt, wird ein schnelleres Füllen der Daten ermöglichen und es hived auch ermöglichen, die erforderlichen Änderungen an der Datenbank von hivemind im Falle von Mikro-Forks zu verwalten. Dies wiederum bedeutet, dass hivemind in der Lage sein wird, mit den aktuellsten Blockdaten zu arbeiten, wodurch die 6-Sekunden-Verzögerung (2 Blöcke hinter dem Kopfblock in 3s-Block-Intervallen = 6s), die es derzeit hat, eliminiert wird. Dies ist sehr wichtig für eine interaktive Erfahrung der Hive-Benutzer auf den verschiedenen Hive-Frontends.
Entwicklung des 2nd Layer Ökosystems
Dies ist einer der Bereiche, dem wir in den nächsten Monaten voraussichtlich die meiste Zeit widmen werden. Das Wichtigste, was ich tun möchte, ist, einen einfachen Rahmen für die Erstellung neuer Hive-Anwendungen zu schaffen.
Im Moment verlassen sich Anwendungen normalerweise auf API-Nodes, um einen Großteil ihrer Blockchain-Informationen über API-Aufrufe bereitzustellen (wobei die Daten von einer hived-Node und dem hivemind Social Media Microservice kommen). Einige Anwendungen verarbeiten auch direkt custom_json-Operationen, um Funktionen zu implementieren, die im Allgemeinen nur für ihre Anwendung gelten. Dieser Ansatz "funktioniert", aber er könnte definitiv verbessert werden.
Herausforderungen bei der Implementierung von Anwendungen im 2nd Layer
Ein Problem besteht darin, dass Anwendungen entweder ihren eigenen leistungsstarken API-Node betreiben müssen oder auf die von anderen bereitgestellten API-Nodes angewiesen sind. Im Idealfall sollte es für eine Anwendung möglich sein, eine einfache Api-Node zu betreiben, der alle von der Anwendung benötigten Daten bereitstellt, so dass die Abhängigkeit von der Betriebszeit und Datenintegrität externer API-Nodes vermieden wird.
Ein weiteres Problem ist die Verarbeitung von custom_json Streams (und anderen Operationen) angesichts von Forks, bei denen Operationen in bereits verarbeiteten Blöcken zugunsten neuer Daten verworfen werden müssen. Dies ist eines der potenziell schwierigsten Probleme für jede blockchain-basierte Anwendung.
Ein leichtgewichtiges Framework für Anwendungen der 2. Ebene (über "modulare hivemind"-Knoten)
Um die oben genannten Probleme anzugehen, planen wir die Schaffung eines leichtgewichtigen Frameworks, das einen Großteil des Technologiestacks von hivemind nutzt, kombiniert mit dem neuen hived Plugin, das wir entwickeln und das den Empfang und die Verarbeitung von Blockchain-Daten in Echtzeit vereinfachen und die einfache Handhabung von Forks über einen generischen Undo-Mechanismus unterstützen wird.
Im Gegensatz zu einer traditionellen hivemind-Installation wird der Betreiber eines solchen 2nd-Layer-Knotens jedoch entscheiden können, welche Daten er speichern und welche APIs er unterstützen möchte. Beispielsweise könnte eine 2nd-Layer-Node, die ein Spiel unterstützt, zunächst nur Kontostände und Spielverlauf, aber keine Social-Media-Daten aufzeichnen. Wenn der Node-Betreiber jedoch später weitere Daten und API-Unterstützung zu seiner 2nd-Layer-Node hinzufügen möchte, wollen wir es einfach machen, diese über eine Art Upgrade-Mechanismus hinzuzufügen. Ich glaube, es war @howo, daer den Begriff "modular hivemind" geprägt hat, um diese Idee zu bezeichnen.
Konsistenzprüfung zur Dezentralisierung des Vertrauens in Blockchain-Ökosystem
Hinweis: Dies ist eines der Themen, die ich zu Beginn dieses Beitrags erwähnt habe und die vielleicht nicht trivial zu verstehen sind, es sei denn, Sie sind Programmierer (und vielleicht nicht einmal dann).
Eine weitere wichtige Funktion, die für Anwendungen der 2nd Layer sehr nützlich wäre, ist eine Möglichkeit, die Prüfung der Datenkonsistenz zwischen mehreren API-Servern zu automatisieren. Ein solches System würde wesentlich dazu beitragen, die Notwendigkeit zu verringern, einem bestimmten Knoten zu vertrauen, der eine Anwendung der 2. Ebene unterstützt (d.h. das Vertrauen zu dezentralisieren).
Eine Möglichkeit dazu wäre, dass dezentralisierte Anwendungen der 2. Ebene periodisch (z.B. einmal alle 1000 Blöcke) einen Hash ihres Zustands (oder eines Teils davon) erzeugen und als Blockchain-Transaktion veröffentlichen. Anwendungen der 2. Ebene, die den gleichen Hash erzeugen, geben eine Erklärung ab, dass sie die Blockchaindaten auf die gleiche Weise interpretieren (d.h. sie arbeiten nach den gleichen Protokollregeln).
In einem solchen System können Anwendungen der 2. Ebene entscheiden, nach unterschiedlichen Regeln zu arbeiten (ein Protokoll-Zweig), während sie weiterhin auf demselben Blockchain-Netzwerk koexistieren. Durch die Veröffentlichung von Hashes ihres Zustands wissen die Benutzer jedoch, welche Nodes sich entschieden haben, nach einem gemeinsamen Regelwerk zu arbeiten, und sie können daher eine sachkundige Entscheidung darüber treffen, auf welche Nodes sie sich für Daten verlassen wollen. Natürlich kann sich ein Benutzer immer dafür entscheiden, einfach seine eigene Node zu betreiben, was etwas ist, was wir viel billiger und einfacher machen wollen. Aber selbst in diesem Fall ist es eine sehr wertvolle Information, zu wissen, wer ein bestimmtes Protokoll unterstützt, da der Grad des Konsenses unter den Protokollbenutzern eine wichtige Voraussetzung für den Wert dieses Protokolls ist.
Erhöhung der Entwicklungsgeschwindigkeit von Open-Source-Benutzeroberflächen für Hive (z.B. hive.blog , ecency.com usw.)
In den letzten Monaten habe ich mich darauf konzentriert, mehr Programmierer für Benutzeroberflächen in unser Team aufzunehmen, um die verstärkte Entwicklung von Open-Source-Frontends auf Hive-Basis zu unterstützen. Natürlich beschäftigte BlockTrades bereits eine Reihe von Front-End-Programmierern, aber sie waren alle an andere Projekte gebunden und konnten nicht ohne schwerwiegende Auswirkungen auf die Zeitplanung dieser Projekte verlagert werden.
Es macht im Moment wenig Sinn, auf die genauen Änderungen einzugehen, die wir an den Hive-Frontends vornehmen werden, da diese Änderungen oft recht klein sind, jederzeit durchgeführt werden können und im Allgemeinen von der Benutzernachfrage bestimmt werden. Ich hielt es jedoch für wichtig zu sagen, dass wir uns der Bedeutung bewusst sind, wie Benutzeroberflächen den Genuss von Hive in all seinen Facetten (als Währung, als Plattform für blockchainbasierte Anwendungen und als Rückgrat für soziale Medien) beeinflussen, und dass wir unsere Bemühungen in diesem Bereich verstärken werden.
Ein neues dezentralisiertes Reputations-/Ratingsystem mit Web-of-Trust-Konzepten
Das letzte Thema ist das Thema, das mich am meisten interessiert, und ich werde später noch viel mehr dazu sagen können, aber es ist ein riesiges Thema und verdient viele eigene Beiträge, um es in verdauliche Häppchen aufzuteilen.
Die Grundidee für dieses System besteht darin, dass Sie Personen, die Sie in verschiedenen Disziplinen kennen, Bewertungen der Urteilsfähigkeit zuteilen und auch Ihre eigenen Bewertungen zu Produkten/Menschen/Ideen veröffentlichen. Basierend darauf, wem Sie vertrauen und wie sehr Sie ihnen in den verschiedenen Bereichen der Urteilsfähigkeit vertrauen, berechnet dieses System unter Verwendung Ihres Web-of-Trust-Netzwerks Ratingnoten zu potenziell jedem Thema, zu dem Menschen Meinungen bilden.
Ich hätte es in diesem Beitrag fast nicht erwähnt, aber da dies so etwas wie ein Fahrplan der geplanten Hive-bezogenen Arbeit für Blockhandel ist und dies als eine Hive-Anwendung der 2. Ebene fungieren wird, dachte ich mir, ich sollte es jetzt zumindest kurz erwähnen, da ich plane, mit diesen Arbeiten in den nächsten 6 Monaten zu beginnen. Ich sage "beginnen", weil das Reputations-/Ratingsystem als ein langfristiges Projekt geplant ist, das über viele Jahre hinweg wachsen und sich auf viele verschiedene Bereiche ausdehnen wird. Zu Beginn müssen wir uns natürlich darauf konzentrieren, einen Prototyp zu erstellen, der eine relativ kleine Teilmenge von Dingen abdeckt, die bewertet werden können, sowie einige Mechanismen zur Berechnung von Ratings und zur Analyse, wie sich Ratings verändern, wenn ein Benutzer Änderungen an seinem Vertrauensnetz vornimmt.
Schlussbemerkung
Beachten Sie bitte auch, dass dies nur ein Fahrplan der Dinge ist, an denen BlockTrades derzeit zu arbeiten plant. Zum Beispiel arbeitet @howo derzeit an der Unterstützung für wiederkehrende Zahlungen, um Zahlungsmodelle im Patreon-Stil zu ermöglichen.
