Funktionsweise von Ethereum Improvement Procits (EIPs)

Wie Ethereum Improvement Proposes (EIPs) funktionieren. Um die Notwendigkeit von ERC-Standards (Ethereum Request for Comments) zu verstehen, sollten Sie verstehen, wie Updates, Upgrades und Codeänderungen in Ethereum stattfinden.
Ethereum Improvement Proposals (EIPs) beschreiben Standards für die Ethereum Plattform, einschließlich Kernprotokollspezifikationen, Client-APIs und Vertragsstandards. Diese werden von jedem Ethereum Community-Mitglied vorgeschlagen und anschließend intern diskutiert.
Erst nachdem Sie die Verbindung zwischen EIPs und ERCs vollständig verstanden haben, können Sie verstehen, wie ERCs funktionieren. Also, zuerst die Dinge.
EIP-Typen
Bevor Sie in den EIP-Status eintauchen, sollten Sie verstehen, was der Zweck jedes EIP-Typs ist und warum es eine Vielzahl von ihnen gibt.
Standard Track: Dies beschreibt alle Änderungen, die sich auf die meisten oder alle Ethereum-Implementierungen auswirken, z. B. eine Änderung des Netzwerkprotokolls, eine Änderung der Block- oder Transaktionsgültigkeitsregeln, vorgeschlagene Anwendungsstandards/Konventionen oder jede Änderung oder Ergänzung, die die Interoperabilität von Anwendungen mit Astraleum.
Kern: Dies bezieht sich auf Verbesserungen, die eine Konsensgabel erfordern (wie EIP5 und EIP101) sowie Änderungen, die nicht unbedingt konsenskritisch sind, aber für Diskussionen mit „Core Dev“ relevant sein können (z. B. Änderungen an der Miner/Node -Strategie 2, 3 und 4 von EIP86).
Vernetzung: Dies beinhaltet Verbesserungen rund um devp2p (EIP8) und das Light Ethereum Subprotokoll sowie vorgeschlagene Verbesserungen an den Netzwerkprotokollspezifikationen von Whisper und Swarm.
Schnittstelle: Dies bezieht sich auf Verbesserungen rund um Client API/RPC -Spezifikationen und -Standards sowie bestimmte Sprachstandards wie Methodennamen (EIP6) und VertragsabIS. Die Bezeichnung „Schnittstelle“ richtet sich nach dem Repo der Schnittstelle und die Diskussion sollte in erster Linie in diesem Repository stattfinden, bevor ein EIP an das EIPS-Repository übermittelt wird.
ERC: Dies sind Standards und Konventionen auf Anwendungsebene, einschließlich Vertragsstandards wie Token-Standards (ERC20), Namensregistries (ERC137), URI-Schemata (ERC681), Bibliotheks-/Paketformate (EIP190) und Wallet-Formate (EIP85).
Meta: Dies beschreibt einen Prozess um Ethereum herum oder der eine Änderung (oder ein Ereignis in) einem Prozess vorschlägt. Prozess-EIPs sind wie Standard Track EIPs, gelten aber für andere Bereiche als das Ethereum Protokoll selbst. Sie können eine Implementierung vorschlagen, aber nicht zur Codebasis von Ethereum. Sie erfordern oft einen Konsens der Gemeinschaft. Im Gegensatz zu Informations-EIPs sind sie mehr als Empfehlungen, und Benutzer können sie normalerweise nicht ignorieren. Beispiele sind Verfahren, Richtlinien, Änderungen am Entscheidungsprozess und Änderungen an den Tools oder Umgebungen, die in der Ethereum-Entwicklung verwendet werden. Jede Meta-EIP gilt auch als Prozess-EIP.
Information: Diese Art von EIP beschreibt ein Ethereum Designproblem oder stellt allgemeine Richtlinien oder Informationen für die Ethereum Community bereit, schlägt jedoch keine neue Funktion vor. Informative EIPs stellen nicht notwendigerweise den Konsens der Ethereum Community oder eine Empfehlung dar, so dass Benutzer und Implementierer frei sind, Informations-EIPs zu ignorieren oder ihren Ratschlägen zu folgen.
Bedingungen für den EIP-Status
Es gibt viel zu verstehen, wenn Sie vollständig erfassen möchten, welche EIPs implementiert sind, welche ERCs in jedem integriert sind und welche natürlich endgültig und live sind. Die wichtigsten EIP-Status sind:
Entwurf - eine EIP, die zur Prüfung offen ist und sich schnell durchläuft und Änderungen ändert.
Last Call - ein EIP, das mit seiner ersten Iteration durchgeführt wird und bereit für die Überprüfung durch ein breites Publikum.
Akzeptiert - eine Kern-EIP, die sich seit mindestens zwei Wochen im letzten Aufruf befindet und alle technischen Änderungen, die angefordert wurden, wurden vom Autor angesprochen. Der Prozess für Core-Entwickler zu entscheiden, ob ein EIP in ihre Kunden als Teil eines Hard Fork kodiert werden soll, ist nicht Teil des EIP-Prozesses. Wenn eine solche Entscheidung getroffen wird, wird die EIP in Final übergehen.
Final (Nicht-Kern-): Eine EIP, die sich seit mindestens zwei Wochen im letzten Aufruf befindet, und alle technischen Änderungen, die angefordert wurden, wurden vom Autor angesprochen.
Final (Core) - ein EIP, das die Core-Entwickler beschlossen haben, in einer zukünftigen harten Fork zu implementieren und freizugeben oder bereits in einer harten Fork freigegeben wurde.
Zurückgestellt - eine EIP, die nicht zur sofortigen Annahme in Betracht gezogen wird. Kann in Zukunft für eine nachfolgende harte Gabel überdacht werden.
Im nächsten Leitfaden werde ich mir verschiedene ERCs ansehen, wie sie funktionieren, dort Zweck und die verschiedenen Arten von Standards gibt und wie sie verwendet werden können.
Bleib dran.