Der Hardfork welcher zur Schaffung der Hive Blockchain geführt hat, wurde von Entwicklern aus der Community entwickelt.
In den letzten Monaten wuchs das Hive Ökosystem langsam aber stetig und es ist eine Reihe von Community Mitgliedern dazugestoßen, welche sich bereit erklärt haben, zum Open Source Code hinter Hive und allem was dazu gehört, beizutragen. Diese Zahl an Entwicklern wächst auch jeden Tag weiter. Wenn man jetzt selbst zu dieser Truppe stoßen oder einfach nur wissen will was dort gemacht wird, kann man beim Core Entwicklungs Post anfangen. Jetzt steht der erste Hive Hardfork kurz bevor, an dem mehr als zwanzig Entwickler mitgewirkt haben.
Neben den offensichtlichen Themen des Hardforks, gibt es noch einige Bereiche, die nicht auf den ersten Blick zu finden sind, selbst wenn man weiß wie man im Repo suchen muss. Um jeden den es Interessiert einen Überblick zu geben, gibt es hier eine Übersicht über den Release Kandidaten(den aktuellen Code für den Hardfork), die Erstellung eines Testnet zum testen dieses, einen möglichen Zeitplan und einen Überblick über die Inhalte des HF24.
Was ist ein Hardfork Release Kandidat? Wann können wir mit dem HF24 rechnen?
In der Softwareentwicklung ist es üblich an einem bestimmten Punkt eine Reihe von Updates und Features auszuwählen, welch ein einer "Finalen Version" als nächste Version veröffentlicht werden sollen. Doch muss diese Version noch getestet werden. Ein Release Kandidat gilt als soweit stabil und einsatzbereit, es werden nur noch Bugs behoben. Der Code wird hierfür eingefroren, also es werden keine weiteren Funktionen mehr eingebaut, sondern nur die bestehenden getestet. Solange keine großen Bugs gefunden werden, kann diese Version unverändert veröffentlicht werden, weshalb man es nur als Kandidat und nicht als endgültige Version bezeichnet.
Der @HiveIO -Account wird am Montag den 8. Juni, einen Beitrag mit Details über den Release Kandidaten und das Testnet für HF24 veröffentlichen.
Nachdem schon viele zum Code beigetragen haben, doch es braucht noch viel mehr Leute die mithelfen. Vor allem jetzt in der Testphase. Im nächsten Beitrag werden sie erklären wie man mithelfen kann, auf jeder Ebene der Entwicklung. Hierbei geht es von dem was Endnutzer, Projekte, Node Betreiber und Entwickler jeweils machen können.
Je nachdem wie die Testphase läuft, kann schon zwei oder drei Wochen nach deren Beginn der Termin für den Hardfork liegen. Wenn jedoch schwere Fehler auftreten, kann sich dies noch einmal um vier oder fünf Wochen nach hinten hinausschieben. Je mehr Menschen sich am Testen beteiligen, desto schneller ist die Arbeit erledigt. Neben diesen Fragen, muss man bei der Terminfindung für einen Hardfork auch die Node Betreiber berücksichtigen. Diese brauchen Zeit sich auf den Hardfork vorzubereiten und ihre Nodes dafür vorzubereiten. Andernfalls kann es sein das man Aufgrund der Wartungsarbeiten hierfür längere Ausfallzeiten hinnehmen muss.
Welche Änderungen sind in HF24 enthalten? Was wird dieser Hardfork bewirken?
Der wichtigste Teil des Hardforks ist es dafür zu sorgen, dass es für alle einfacher und schneller möglich ist das Hive-Netzwerk zu nutzen und zu unterstützen. Viele der Entwickler am Hardfork haben ihre Arbeit dokumentiert. Dies ist ein kurzer Überblick zu den wichtigsten Themen des Hardforks:
- Änderung der Blockchain-ID
Damit bestehende Frontends und dApps schnell und einfach migrieren können, wurde die Blockchain-ID zum Zeitpunkt der Gründung von Hive nicht geändert. Dies ist jedoch ein wichtiger Teil der Verbesserung des sicheren Zugriffs auf die Blockchain in der Zukunft und muss jetzt in Vorbereitung auf weitere Projekte erfolgen, die zum Ökosystem hinzukommen.
- 30 Tage Cooldown neuer HP für die Abstimmung bei Governance Fragen.
Das Hive-Governance-System besteht sowohl aus Witness- als auch aus DHF-Abstimmungen. Wenn zusätzliche neue Hive aufgepowert werden, wird deren Gewicht in den folgenden 30 Tagen NICHT für die Abstimmung über das Governance berücksichtigt. Dadurch wird jedem potentiellen böswilligen koordinierten Übernahmeversuch ein gesunder Pufferzeitraum hinzugefügt, der der Community die Möglichkeit gibt zu reagieren und der eine wichtige, aber dennoch vernünftige Sicherheitsvorkehrung darstellt, um Angriffe über an Börsen gelagerten Coins zu verhindern, ohne die Coins in irgendeiner Weise zu benachteiligen.
- Eine große Anzahl vorläufiger Änderungen, um den Betrieb einer Hive-Node zu erleichtern.
Dies ist eine vereinfachte Erklärung, die eine Menge Arbeit und Teile des Core Codes abdeckt. Einer der restriktivsten Teile des wachsenden Hive waren die Kosten, der Umfang der benötigten Ressourcen und die Schwierigkeit, die Infrastruktur zur Unterstützung der Blockchain zu betreiben. Das bedeutet, dass es viel schwieriger war, die weitere Dezentralisierung von Hive mit mehr Seed Nodes, Witness Nodes und RPC-Nodes zu unterstützen, als es sein sollte. Börsen, die Nodes betreiben, benötigten längere Wartungszeiten und direktere Hilfe im Hive. Projekte, dApps und Entwickler, die auf Hive aufbauen wollen, haben festgestellt, dass es schwierig sein kann, damit anzufangen, weil sie sich keine eigene Node leisten können oder weil die öffentlichen Möglichkeiten immer noch begrenzt sind. Das klingt zwar sehr technisch, führt aber auch für Endbenutzer und Investoren direkt zu einer schlechten Erfahrung. Hive einfacher, schneller und erschwinglicher zu machen, ermöglicht eine bessere Dezentralisierung, von der Blockchain-Ebene bis hin zur Vielfalt der Projekte und Nutzer im Ökosystem.
- Korrektur am Airdrop. Fälschlicher Weise ausgeschlossene Nutzer und Nutzer deren persönliche Proposal erfolgreich waren, bekommen ihren Airdrop.
Die Liste der Korrekturen ist in einem früheren Beitrag zu finden. Auch wenn die Community gegen einen Airdrop für die Benutzer die für die Sun Witnesse gestimmt haben, gestimmt hat, wurden einige Einzelvorschläge von der Community unterstützt und werden während des ersten Blocks des Hardfork per Airdrop verteilt.