You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardexpand all lines: PIPs/pip-1.md
+49-19
Original file line number
Diff line number
Diff line change
@@ -9,39 +9,69 @@ created: 2023-07-10
9
9
10
10
## What is an PIP?
11
11
12
-
Pactus Improvement Proposals (PIPs) serve as a comprehensive framework for outlining and defining the standards
13
-
for the Pactus platform's ongoing development and enhancement. These proposals cover various aspects of the platform,
14
-
including core protocol specifications and client application programming interfaces (APIs). By establishing a clear
15
-
and consistent set of guidelines, PIPs ensure seamless interoperability and extensibility across the Pactus ecosystem,
12
+
Pactus Improvement Proposals (PIPs) serve as a comprehensive framework for outlining and defining the standards
13
+
for the Pactus platform's ongoing development and enhancement. These proposals cover various aspects of the platform,
14
+
including core protocol specifications and client application programming interfaces (APIs). By establishing a clear
15
+
and consistent set of guidelines, PIPs ensure seamless interoperability and extensibility across the Pactus ecosystem,
16
16
fostering a robust and efficient environment for developers and users alike.
17
17
18
18
## PIP Rationale
19
19
20
-
We intend PIPs to be the primary mechanisms for proposing new features, for collecting community technical input on an issue, and for documenting the design decisions that have gone into Pactus. Because the PIPs are maintained as text files in a versioned repository, their revision history is the historical record of the feature proposal.
20
+
We intend PIPs to be the primary mechanisms for proposing new features, for collecting community technical input on an issue,
21
+
and for documenting the design decisions that have gone into Pactus.
22
+
Because the PIPs are maintained as text files in a versioned repository,
23
+
their revision history is the historical record of the feature proposal.
21
24
22
-
For Pactus implementers, PIPs are a convenient way to track the progress of their implementation. Ideally, each implementation maintainer would list the PIPs that they have implemented. This will give end users a convenient way to know the current status of a given implementation or library.
25
+
For Pactus implementers, PIPs are a convenient way to track the progress of their implementation.
26
+
Ideally, each implementation maintainer would list the PIPs that they have implemented.
27
+
This will give end users a convenient way to know the current status of a given implementation or library.
23
28
24
29
## PIP Types
25
30
26
31
There are three types of PIP:
27
32
28
-
**Standards Track** PIP: Describes any change that affects most or all Pactus implementations, such as—a change to the network protocol, a change in block or transaction validity rules, proposed application standards/conventions, or any change or addition that affects the interoperability of applications using Pactus. Standards Track PIPs consist of three parts—a design document, an implementation, and (if warranted) an update to the formal specification. Furthermore, Standards Track PIPs can be broken down into the following categories:
33
+
**Standards Track** PIP:
34
+
Describes any change that affects most or all Pactus implementations, such as—a change to the network protocol,
35
+
a change in block or transaction validity rules, proposed application standards/conventions,
36
+
or any change or addition that affects the interoperability of applications using Pactus.
37
+
Standards Track PIPs consist of three parts—a design document, an implementation, and
38
+
(if warranted) an update to the formal specification.
39
+
Furthermore, Standards Track PIPs can be broken down into the following categories:
29
40
30
-
**Core*: Improvements requiring a consensus fork, as well as changes that are not necessarily consensus critical but may be relevant to "core dev" discussions or any change to transaction, block, address or their new versions.
41
+
**Core*: Improvements requiring a consensus fork, as well as changes that are not necessarily consensus critical but
42
+
may be relevant to "core dev" discussions or any change to transaction, block, address or their new versions.
31
43
32
44
**Networking*: Includes improvements around Pactus networking protocol.
33
45
34
-
**Interface*: Includes improvements around clients, API/RPCs specifications, and how users and applications interact with the blockchain. The label "interface" aligns with the interfaces repo, and discussion should primarily occur in that repository before a PIP is submitted to the PIPs repository.
35
-
36
-
**PRC*: Application-level standards and conventions, including contract standards such as token standards, name registries, URI schemes, library/package formats, and wallet formats.
37
-
38
-
**Meta PIP**: Describes a process surrounding Pactus or proposes a change to (or an event in) a process. Process PIPs are like Standards Track PIPs but apply to areas other than the Pactus protocol itself. They may propose an implementation, but not to Pactus's codebase; they often require community consensus; unlike Informational PIPs, they are more than recommendations, and users are typically not free to ignore them. Examples include procedures, guidelines, changes to the decision-making process, and changes to the tools or environment used in Pactus development. Any meta-PIP is also considered a Process PIP.
39
-
40
-
**Informational** PIP: Describes a Pactus design issue, or provides general guidelines or information to the Pactus community, but does not propose a new feature. Informational PIPs do not necessarily represent Pactus community consensus or a recommendation, so users and implementers are free to ignore Informational PIPs or follow their advice.
41
-
42
-
It is highly recommended that a single PIP contain a single key proposal or new idea. The more focused the PIP, the more successful it tends to be. A change to one client doesn't require a PIP; a change that affects multiple clients, or defines a standard for multiple apps to use, does.
43
-
44
-
A PIP must meet certain minimum criteria. It must be a clear and complete description of the proposed enhancement. The enhancement must represent a net improvement. The proposed implementation, if applicable, must be solid and must not complicate the protocol unduly.
46
+
**Interface*: Includes improvements around clients, API/RPCs specifications, and how users and
47
+
applications interact with the blockchain.
48
+
The label "interface" aligns with the interfaces repo, and discussion should primarily occur
49
+
in that repository before a PIP is submitted to the PIPs repository.
50
+
51
+
**PRC*: Application-level standards and conventions, including contract standards such as
52
+
* token standards, name registries, URI schemes, library/package formats, and wallet formats.
53
+
54
+
**Meta PIP**: Describes a process surrounding Pactus or proposes a change to (or an event in) a process.
55
+
Process PIPs are like Standards Track PIPs but apply to areas other than the Pactus protocol itself.
56
+
They may propose an implementation, but not to Pactus's codebase; they often require community consensus;
57
+
unlike Informational PIPs, they are more than recommendations, and users are typically not free to ignore them.
58
+
Examples include procedures, guidelines, changes to the decision-making process,
59
+
and changes to the tools or environment used in Pactus development.
60
+
Any meta-PIP is also considered a Process PIP.
61
+
62
+
**Informational** PIP: Describes a Pactus design issue, or provides general guidelines or
63
+
information to the Pactus community, but does not propose a new feature.
64
+
Informational PIPs do not necessarily represent Pactus community consensus or a recommendation,
65
+
so users and implementers are free to ignore Informational PIPs or follow their advice.
66
+
67
+
It is highly recommended that a single PIP contain a single key proposal or new idea.
68
+
The more focused the PIP, the more successful it tends to be.
69
+
A change to one client doesn't require a PIP; a change that affects multiple clients,
70
+
or defines a standard for multiple apps to use, does.
71
+
72
+
A PIP must meet certain minimum criteria. It must be a clear and complete description of the proposed enhancement.
73
+
The enhancement must represent a net improvement. The proposed implementation,
74
+
if applicable, must be solid and must not complicate the protocol unduly.
0 commit comments