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 | Informal | Burst Deep Link Specification | @ohager | Standard | Active |
_23 | Enhancement | Enforce Slot fees | @Curbsdhifter | Process | Active |
_24 | Enhancement | New deadline algorithm based on a logarithm transformation | @jjos | Process | Active |
_25 | Enhancement | Minor Network Changes | @harry1453 | Process | Active |