Capability Improvement Proposal (CIP)

Ähnlich wie bei den BIPs und EIPs hat die Burst-Community CIPs (kurz für „Capability Improvement Proposal“ oder gar „Coin Improvement Proposal“) eingerichtet, um die Weiterentwicklung von Burstcoin voranzutreiben. CIPs beschreiben daher neue Standards für die Burstcoin-Plattform, einschließlich Protokoll Anpasungen , Client-APIs und generelle Anpassungen.

Definition des Burst-CIPs

Ein (Burst)Coin oder Capability Improvement Proposal (CIP) ist ein Dokument, das der Burst-Community Informationen liefert oder ein neues Merkmal für Burst, seine Prozesse oder Umgebung beschreibt. Die CIPs stellen das primäre Verfahren da, um neue Features vorzuschlagen, Beiträge der Community zu einem Thema zu sammeln und/oder  die getroffenen Designentscheidungen zu dokumentieren. Der CIP-Autor ist verantwortlich für die Konsensbildung innerhalb der Gemeinschaft und die Dokumentation abweichender Meinungen. Da die CIPs als Textdateien in einem versionierten Repository gepflegt werden, ist ihre Revisionshistorie der historische Beleg des Vorschlages.

CIP-Workflow

Der CIP-Prozess beginnt mit einer neuen Idee für Burst. Jedes potenzielle CIP muss einen Autor haben – jemanden, der das CIP im unten beschriebenen Stil und Format schreibt, die Diskussionen in den entsprechenden Foren leitet und versucht, einen Gemeinschaftskonsens über die Idee aufzubauen. Der CIP-Autor sollte zunächst versuchen festzustellen, ob die Idee CIP-fähig ist.

Kleine Verbesserungen oder Patches für eine bestimmte Software erfordern oft keine Standardisierung zwischen mehreren Projekten; diese benötigen keinen CIP und sollten in den jeweiligen projektspezifischen Entwicklungs-Workflow mit einer Patch-Übermittlung an den entsprechenden Issue Tracker eingereicht werden.

Darüber hinaus wurden viele Ideen zur Änderung von Burstcoin eingebracht, die aus verschiedenen Gründen abgelehnt wurden. Der erste Schritt sollte darin bestehen, vergangene Diskussionen zu durchsuchen, um zu sehen, ob eine Idee bereits berücksichtigt wurde und wenn ja, welche Probleme in ihrem Verlauf aufgetreten sind. Nach der Überprüfung vergangener Arbeiten ist der beste Weg, um fortzufahren, indem Sie über die neue Idee im Burstcoin Discord oder im Burst Reddit posten. Nachdem der Autor die Burst-Community gefragt hat, ob eine Idee eine Chance auf Akzeptanz hat, sollte im Burst Reddit ein Entwurf eines CIP vorgelegt werden. Dies gibt dem Autor die Möglichkeit, den Entwurf des CIP zu konkretisieren, damit er richtig formatiert und von hoher Qualität ist und zusätzliche Bedenken hinsichtlich des Vorschlags berücksichtigt werden.

Nach einer Diskussion sollte der Vorschlag dem CIPs-Repository eingebracht werden. Sobald der CIP von einem Redakteur zur Aufnahme als Entwurf genehmigt wurde (der sicherstellen muss, dass die oben genannten Schritte durchgeführt wurden), wird der CIP mit dem Entwurfstatus zusammengeführt, und der Redakteur öffnet einen neuen Pull-Request zur Aktivierung des CIP. Diese Pull-Anfrage dient als Kommentar / Diskussionsfaden für den CIP und muss mindestens 30 Tage offen bleiben.

Gründe für die Ablehnung von CIPS sind unter anderem Doppelarbeit, Missachtung von Formatierungsregeln, zu ungenau oder zu allgemein, technisch unsolide, keine angemessene Motivation oder Rückwärtskompatibilität oder nicht im Einklang mit der Burstcoin-Philosophie.

Es wird dringend empfohlen, dass ein  CIP sich auf eine Thematik bzw. auf eine  Idee konzentriert. Je fokussierter der CIP ist, desto erfolgreicher ist er in der Regel. Im Zweifelsfall teilen Sie Ihren CIP in mehrere auf.

Damit ein CIP akzeptiert werden kann, muss er bestimmte Mindestkriterien erfüllen. Er muss eine klare und vollständige Beschreibung der vorgeschlagenen Erweiterung enthalten. Die Erweiterung muss eine  Verbesserung darstellen. Die vorgeschlagene Umsetzung muss gegebenenfalls solide sein und darf das Protokoll nicht übermäßig komplizieren.

CIP Types

  • Ein Standards Track CIP beschreibt jede Änderung, die die meisten oder alle Burst-Implementierungen betrifft, wie z.B. eine Änderung des Netzwerkprotokolls, eine Änderung der Block- oder Transaktionsgültigkeitsregeln oder jede Änderung oder Ergänzung, die die Anwendungen mit Burst verändern. Standards  Track CIPs bestehen aus zwei Teilen, einem Design-Dokument und einer Referenzimplementierung.

  • Ein Informativer CIP  beschreibt ein Burst-Design-Problem oder stellt der Burst-Community allgemeine Richtlinien oder Informationen zur Verfügung, schlägt aber kein neues Merkmal vor. Informative CIPs stellen nicht unbedingt einen Konsens oder eine Empfehlung der Burst-Community dar, so dass es den Nutzern und Entwicklern freisteht, informative CIPs zu befolgen oder nicht.

  • Ein Prozess-CIP beschreibt einen Prozess oder schlägt eine Änderung in (oder ein Ereignis in) einem Prozess vor. Prozess-CIPs sind wie Standards Track-CIPs, gelten aber für andere Bereiche als das Burst-Protokoll selbst. Sie können eine Implementierung vorschlagen, aber nicht in die Codebasis von Burst; sie erfordern oft einen Konsens der Gemeinschaft; im Gegensatz zu informativen CIPs sind sie mehr als Empfehlungen, und es steht den Nutzern in der Regel nicht frei, sie zu ignorieren. Beispiele sind Verfahren, Richtlinien, Änderungen im Entscheidungsprozess sowie Änderungen an den Tools oder der Umgebung, die in der Burst-Entwicklung verwendet werden.

Übersicht der Burst-CIPs

No. Layer Title Owner Type Status
__1 Applicaton Dynamic BRS Node Capabilities @rico666 Informational Active
__2 Enhancement (Hard Fork) Quadruple Block Size @rico666 Standard Active
__3 Enhancement (Hard Fork) Variable Slot-based Fees @rico666 Standard Active
__4 Enhancement (Hard Fork) Multi-Out Transactions @rico666 Standard Active
__5 Enhancement (Hard Fork) POC 2 @rico666 Standard Active
__6 Enhancement Unconfirmed Tx Queue Optimizations @Brabantian Standard Active
__7 Enhancement Differential Unconfirmed Tx Propagation @Brabantian Standard Active
__8 Informal Define Tx and Balance „Dust“ @rico666 Standard Draft
__9 Enhancement (Hard Fork) To-All Transactions @rico666 Standard Draft
_10 Enhancement (Hard Fork) Anchor Real-World Data in Blockchain @rico666 Standard Draft
_11 Enhancement (Hard Fork) Tethered Assets @rico666 Standard Draft
_12 Enhancement BFS – Burst File System @JohnnyDeluxe Standard Draft
_13 Enhancement Suggested Transaction Fees @Brabantian Standard Active
_14 Enhancement Burst Actions through Deeplink QR-codes @Brabantian Standard Active
_15 Enhancement (Hard Fork) RWFDS-enabled FEE_QUANT Introspection and Adjustment @frank_the_tank Standard Draft
_16 Enhancement PoC2.X16 – A New Optimized Plot File Format @JohnnyFFM Standard Draft
_17 Enhancement Differential UT Propagation in push & pul @Brabantian Standard Active
_18 Applications Cross-Platform Wallet UIl @blankey1337, @ohager Standard Active
_19 Enhancement Multi-Out: View Incoming Transactions @harry1453 Standard Active
_20 Enhancement (Hard Fork) Updated AT fees @frank_the_tank, @jjos, @burstjack Standard Active
_21 Enhancement (Hard Fork) Adjustment for Asset-Issuance fee @frank_the_tank, @burstjack Process Active
_22 Enhancement Burst Deep Link Specification @ohager Process Draft