Dezentrales Abstimmen und vertrauensloses autonomes Hardforking


Als ich 2012/3 zum ersten Mal von Bitcoin besessen war, war mir klar, dass es für bitcoinähnliche Systeme viel mehr Anwendungen als Werttransfer gab, um die Welt zu verbessern. Das Wichtigste unter ihnen war die dezentrale Abstimmung für nachweislich faire und sichere politische Wahlen. Dies war lange bevor die QRL existierte und sogar bevor die konsensbezogenen Probleme in Bezug auf Bitcoin und das Blockgrößen-Fiasko auftraten.

Interessenkonflikte sind in jedem Ökosystem unvermeidlich, in dem Wert geschaffen, übertragen und gespeichert wird. Wenn wir aus dieser Zeit der Bitcoin-Geschichte etwas gelernt haben, sollten sich dezentrale Währungsblockaden autonom anpassen können, ohne auf Gatekeeping-Entwickler angewiesen zu sein, die möglicherweise nicht dieselben Ziele oder Standpunkte der Stakeholder (Nutzerbasis) dieser Kryptowährung teilen . Umstrittene Konsensänderungen dürfen in einem solchen System nur nach einem festgelegten Upgrade-Pfad eingeführt werden.

Es erscheint logisch, dass der Ort, an dem umstrittene Entscheidungen sowohl für die Netzwerk- als auch für die Token-Funktionalität getroffen werden müssen, an der Kette liegt – der einzige Wahrheitspunkt für alle.

(Hinweis: Dies kann die Standard- und einfachste Position für die Zurückstellung umstrittener Entscheidungen nicht aufhalten, sondern setzt einfach den Status Quo fort.)

Seit einiger Zeit debattieren das Kernteam und die Community über verschiedene System-Upgrades im Rahmen unseres QIP (QRL Improvement Process). Dieser Prozess auf Github ermöglicht es jedem, eine Verbesserung des bestehenden QRL-Ökosystems vorzuschlagen. Dort kann ein sicherer Dialog zwischen Entwicklern und Benutzern stattfinden, in dem technische Gesichtspunkte diskutiert oder die Vorzüge eines bestimmten Upgrades transparent diskutiert werden. Eine solche Diskussion umfasst natürlich nur einen kleinen Teil der Community und zieht in der Regel technische Benutzer an und schließt interessierte, aber nicht technische Benutzer aus. Trotzdem ist es ein grober Maßstab für die Entscheidung, ob ein Merkmal aktiv verfolgt oder beiseite gelegt werden soll.

Das QIP-System ist ein wahres Juwel für die QRL, aber die Steuerung des Projekts kann in Zukunft verbessert werden.

Die kommende QRL-Core-Hardgabel enthält mehrere aufregende neue Funktionen, darunter ephemere Nachrichtenübermittlung, Multisignatur-Wallet-Funktion (in die Webwallet-GUI integriert) und eine Erweiterung von Multisig, bei der ledger-weite Umfragen von allen QRL-Benutzern mit einer nicht-signaturbasierten Benutzeroberfläche abgehalten und abgestimmt werden können. keine Balance.

Wie funktioniert das? Lassen Sie uns zunächst erläutern, wie unser QRL-Multisig-Setup funktioniert. Zuerst wird im Node oder Webwallet eine neue Multisig-Adresse mit a erstellt MultisigCreateTx Wobei mehr als eine QRL-Adresse mit Unterzeichnergewichtung zur Adresse hinzugefügt wird (denken Sie an das Stimmrecht für jede Adresse). Weiter um Geld zu bewegen a MultiSigSpendTx wird von einer der aufgelisteten Adressen erstellt und der zu übertragende Wert und die Zieladresse (n) werden deklariert. Schließlich kann jeder Unterzeichner a MultiSigVoteTx zum unterzeichnen der ausgabentransaktion – sobald der schwellenwert erreicht ist, werden die mittel verschoben (hinweis: multisig vote und ausgabe sind funktional identisch). Obwohl dies kompliziert klingt, ist es über die Click-through-GUI des Webbrowsets äußerst einfach.

Also, abstimmen ..?

Damit die buchungsweite Abstimmung durchgeführt werden kann, ist jetzt eine magische Mehrfachsignaturadresse (Q11000000000000000000000000000000000000000000000000000000000000000000000000000000 – und nicht mehr verwendbar) festgelegt. Diese Adresse ist speziell, da sie keine begrenzte Liste spezifischer QRL-Adressen enthält alle QRL-Adressen mit einem Saldo ungleich Null gelten als gültige Unterzeichner.

Während es sich im Backend tatsächlich um modifizierte Multisig-Funktionen handelt, gibt es zwei neu präsentierte Transaktions-Subtypen, die zur Abstimmung verwendet werden können:

  1. ProposalCreateTx
  2. ProposalVoteTx

Jede QRL-Adresse kann eine gültige erstellen ProposalCreateTx und starten Sie eine ledgerweite Umfrage. Diese Transaktion legt den Abfragetyp (QIP, Benutzer, konsensändernde Konfigurationseinstellungen usw.) fest und ermöglicht das Festlegen eines bestimmten QIP mit einer zusätzlichen optionalen beschreibenden Textzeichenfolge und einem Ablaufdatum für die Blockhöhe.

Um über eine bestehende ledgerweite Umfrage abzustimmen, erstellt eine QRL-Adresse einfach eine ProposalVoteTx mit dem entsprechenden geliefert ProposalCreateTx txid und liefert die Abstimmungsdaten – unterstützen, ablehnen, enthalten usw ..

Einige von Ihnen werden bemerkt haben, dass das Verfolgen und Katalogisieren von dezentralen Umfragen und Abstimmungen in der Kette im QRL einfach ist, wenn Sie die magische Adresse im Explorer nachschlagen – und alle Daten in lesbarer, nützlicher Form auf der Seite für Protokollaktualisierungen in Echtzeit übertragen.

Mit dem oben genannten Verhalten ist es jedem QRL-Benutzer möglich, ein neues QIP vorzuschlagen und die Community und die Stakeholder (Münzhalter) zu bitten, objektiv darüber abzustimmen, ob das Verfahren fortgesetzt werden soll – es sind keinerlei Entwickler oder Kernteams erforderlich -, vollständig dezentralisiert.

Die Adleraugen werden sich fragen, was "konsensändernde Konfigurationseinstellungen" bedeuten.

Sobald ledgerweite Abstimmungen und Abstimmungen aktiv sind, besteht die Möglichkeit, ein sich selbst änderndes Verhalten für Regeln und Verhaltensweisen des Netzwerkkonsenses zu erstellen.

Die folgenden Parameter sind Konfigurationseinstellungen im qrl-core-Client. Wenn sie geändert werden, verursachen sie möglicherweise eine harte Gabelung und teilen das Netzwerk in eine oder mehrere Ketten auf. Sie sind möglicherweise alle ‘änderbar’, wenn die Abstimmung über die Kette durchgeführt wird:

  1. Blockzeitintervall
  2. Block-Belohnung
  3. Gesamtemission
  4. maximale Blockgröße
  5. konsensändernde Schwelle
  6. Ablaufdatum der Blockhöhenabfrage
  7. Mindesttransaktionsgebühr
  8. hartcodierte peer_list
  9. Reorganisationslimit
  10. Mindestversion des akzeptierten qrl-Knotens
  11. Konsensalgorithmus (für eine spätere Version!)

Es ist möglich mit der Vorschlag Transaktions-Subtypen, um eine direkte Netzwerkänderung vorzuschlagen und nach Erreichen eines zufriedenstellenden Schwellenwerts für diesen On-Chain-Vorschlag die neuen Konsens-Einstellungen ab dem nächsten Block autonom einzugeben. Somit kann eine Umfrage mit einer erfolgreichen Abstimmung die Parameter des Netzwerks auf eine vollständig dezentrale, vertrauenslose und autonome Weise verändern.

Tatsächlich werden die bestehenden Regeln des Systems in die Kette verschoben und können nur durch einen buchungsweiten Abstimmungskonsens geändert werden.

Beispiele

Ein Beispiel könnte darin bestehen, die Emissionskurve auf der Grundlage eines Konsenses zu ändern oder Blockierungen häufiger oder seltener als derzeit vorzunehmen. Eine weitere einfache Änderung wäre, die peer_list zu ändern, um eine neue IP-Adresse zu ändern, die als Erkennungsknoten für neue Teilnehmer im Netzwerk fungiert. Sagen wir, einige der frühesten Netzwerkknoten würden auf eine neue Plattform migrieren. Während eines Netzwerk-Transaktions-Spam-Angriffs kann es erforderlich sein, eine vorübergehende Mindesttransaktionsgebühr zu implementieren. Dies kann über einen Abstimmungsvorschlag und ein direktes Fork-Update erfolgen, um die Mindesttransaktionsgebühr von Null zu erhöhen.

Zukünftige Upgrades

Es ist auch möglich, diese anfänglichen einfachen, sich selbst ändernden Änderungen um zukünftige Codemodule zu erweitern, um eine Änderung des Mining-Algorithmus oder ein anderes Konsens-Upgrade zu automatisieren – beispielsweise die Migration zu POS auf einer bestimmten Blockhöhe.

In Kürze wird ein QIP veröffentlicht, das dies detaillierter erläutert. Interessenten können uns in naher Zukunft dabei helfen, diese Änderungen auf QRL testnet zu testen.

Hard Fork – Ein Netzwerk-Upgrade, das nicht mit vorhandenen Clients abwärtskompatibel ist, wobei ältere Knoten sich anders verhalten, wenn sie nicht aktualisiert werden, was möglicherweise dazu führt, dass zwei Versionen der Kette weiterarbeiten.

Coins Kaufen: Bitcoin.deAnycoinDirektCoinbaseCoinMama (mit Kreditkarte)Paxfull

Handelsplätze / Börsen: Bitcoin.de | KuCoinBinanceBitMexBitpandaeToro

Lending / Zinsen erhalten: Celsius NetworkCoinlend (Bot)

Cloud Mining: HashflareGenesis MiningIQ Mining

Werbung: Immobilienmakler HeidelbergMakler Heidelberg

By continuing to use the site, you agree to the use of cookies. more information

The cookie settings on this website are set to "allow cookies" to give you the best browsing experience possible. If you continue to use this website without changing your cookie settings or you click "Accept" below then you are consenting to this.

Close