This book contains the Polkadot Fellowship Requests for Comments (RFCs)
detailing proposed changes to the technical implementation of the Polkadot network.
This RFC proposes the addition of a secondary market feature to the broker pallet, enabling users to list and purchase regions. This includes creating, purchasing, and removing listings, as well as emitting relevant events and handling associated errors.
-Currently, the broker pallet lacks functionality for a secondary market, which limits users' ability to freely trade regions. This RFC aims to introduce a secure and straightforward mechanism for users to list regions they own for sale and allow other users to purchase these regions. This functionality can enhance the flexibility and utility of the broker pallet, making it more user-friendly and valuable.
-The main drawback is the additional complexity introduced to the broker pallet, which may increase maintenance overhead. Moreover, there is a potential risk of security vulnerabilities in the new market functionalities, such as unauthorized region transfers or incorrect balance adjustments.
-
@@ -347,9 +208,9 @@ detailing proposed changes to the technical implementation of the Polkadot netwo
| Authors | Jonas Gehrlein |
-
+
This document is a proposal for restructuring the bulk markets in the Polkadot UC's coretime allocation system to improve efficiency and fairness. The proposal suggests separating the BULK_PERIOD into MARKET_PERIOD and RENEWAL_PERIOD, allowing for a market-driven price discovery through a clearing price Dutch auction during the MARKET_PERIOD followed by renewal offers at the MARKET_PRICE during the RENEWAL_PERIOD. The new system ensures synchronicity between renewal and market prices, fairness among all current tenants, and efficient price discovery, while preserving price caps to provide security for current tenants. It seeks to start a discussion about the possibility of long-term leases.
-
+
While the initial RFC-1 has provided a robust framework for Coretime allocation within the Polkadot UC, this proposal builds upon its strengths and uses many provided building blocks to address some areas that could be further improved.
In particular, this proposal introduces the following changes:
@@ -369,14 +230,14 @@ detailing proposed changes to the technical implementation of the Polkadot netwo
The premise of this proposal is to reduce complexity by introducing a common price (that develops releative to capacity consumption of Polkadot UC), while still allowing for market forces to add efficiency. Longterm lease owners still receive priority IF they can pay (close to) the market price. This prevents a situation where the renewal price significantly diverges from renewal prices which allows for core captures. While maximum price increase certainty might seem contradictory to efficient price discovery, the proposed model aims to balance these elements, utilizing market forces to determine the price and allocate cores effectively within certain bounds. It must be stated, that potential price increases remain predictable (in the worst-case) but could be higher than in the originally proposed design. The argument remains, however, that we need to allow market forces to affect all prices for an efficient Coretime pricing and allocation.
Ultimately, this the framework proposed here adheres to all requirements stated in RFC-1.
-
+
Primary stakeholder sets are:
- Protocol researchers and developers, largely represented by the Polkadot Fellowship and Parity Technologies' Engineering division.
- Polkadot Parachain teams both present and future, and their users.
- Polkadot DOT token holders.
-
+
The BULK_PERIOD has been restructured into two primary segments: the MARKET_PERIOD and RENEWAL_PERIOD, along with an auxiliary SETTLEMENT_PERIOD. This latter period doesn't necessitate any actions from the coretime system chain, but it facilitates a more efficient allocation of coretime in secondary markets. A significant departure from the original proposal lies in the timing of renewals, which now occur post-market phase. This adjustment aims to harmonize renewal prices with their market counterparts, ensuring a more consistent and equitable pricing model.
@@ -423,12 +284,12 @@ detailing proposed changes to the technical implementation of the Polkadot netwo
- Long-term Coretime: The Polkadot UC is undergoing a transition from two-year leases without an instantaneous market to a model encompassing instantaneous and one-month leases. This shift seems to pivot from one extreme to another. While the introduction of short-term leases, both instantaneous and for one month, is a constructive move to lower barriers to entry and promote experimentation, it seems to be the case that established projects might benefit from more extended lease options. We could consider offering another product, such as a six-month Coretime lease, using the same mechanism described herein. Although the majority of leases would still be sold on a one-month basis, the addition of this option would enhance market efficiency as it would strengthen the impact of a secondary market.
-
+
There are trade-offs that arise from this proposal, compared to the initial model. The most notable one is that here, I prioritize requirement 6 over requirement 2. The price, in the very "worst-case" (meaning a huge explosion in demand for coretime) could lead to a much larger increase of prices in Coretime. From an economic perspective, this (rare edgecase) would also mean that we'd vastly underprice Coretime in the original model, leading to highly inefficient allocations.
-
+
This RFC builds extensively on the available ideas put forward in RFC-1.
Additionally, I want to express a special thanks to Samuel Haefner and Shahar Dobzinski for fruitful discussions and helping me structure my thoughts.
-
+
The technical feasability needs to be assessed.
(source)
Table of Contents
@@ -1337,7 +1198,7 @@ privacy-enhancing mechanisms to address this concern.
| Authors | Kian Paimani |
-
+
This RFC proposes a new pallet_inflation to be added to the Polkadot runtime, which improves
inflation machinery of the Polkadot relay chain in a number of ways:
@@ -1347,7 +1208,7 @@ inflation machinery of the Polkadot relay chain in a number of ways:
systems, as proposed
RFC32.
-
+
The existing inflation logic in the relay chain suffers from a number of drawbacks:
-
+
First, let's further elaborate on the existing order. The current inflation logic is deeply nested
in pallet_staking, and pallet_staking::Config::EraPayout interface. Through this trait, the
@@ -1513,7 +1374,7 @@ prefixed by dynamic_params.
Whereby FixedAnnualInflationAmount is the fixed absolute value (as opposed to ratio) by
which the chain inflates annually, for example 100m DOTs.
-
+
The following drawbacks are noted:
- The solution provided here is possibly an over-engineering, if we want to achieve the goal of
@@ -1527,24 +1388,24 @@ of the inflation amount being reliant on eg. the staking-rate. We acknowledge th
but given that many PoS inflationary systems rely on the staking rate, we believe it is a
reasonable compromise. Such parameters can be ignored if the implementation does not need them.
-
+
The new pallet_inflation, among its integration into pallet_staking must be thoroughly audited
and reviewed by fellows. We also emphasize on simulating the actual inflation logic using the real
polkadot state with Chopsticks and try-runtime.
-
+
The proposed system in this RFC implies a handful of extra storage reads and writes "per inflation
cycle", but given that a reasonable instance of this pallet would probably decide to inflation eg.
once per day, the performance impact is negligible.
The drawback section above noted some ergonomic concerns.
The "New Order" section above notes the compatibility notes with the existing staking
and inflation system.
-
+
- Previous updates to the inflation system:
pallet_parameters- https://forum.polkadot.network/t/adjusting-the-current-inflation-model-to-sustain-treasury-inflow/3301
-
+
- Whether the design proposed in this RFC is worthy of the complexity implementing and integrating
it? Note that a draft implementation already exists, yet the amount of further work needed to
@@ -1555,7 +1416,7 @@ timestamps must be provided to the pallet in order to function, possibly being s
relay-chain. @ggwpez has explored issues related to on-demand core-time and time-based systems
here.
-
+
- If initial reaction is positive researchers and economic experts should formulate their desired
inflation parameters and systems, such that we can be sure the pallet is flexible enough in
@@ -1593,16 +1454,16 @@ the pallet design as it stands, this is very unlikely.
| Authors | Alex Gheorghe (alexggh) |
-
+
Extend the DHT authority discovery records with a signed creation time, so that nodes can determine which record is newer and always decide to prefer the newer records to the old ones.
-
+
Currently, we use the Kademlia DHT for storing records regarding the p2p address of an authority discovery key, the problem is that if the nodes decide to change its PeerId/Network key it will publish a new record, however because of the distributed and replicated nature of the DHT there is no way to tell which record is newer so both old PeerId and the new PeerId will live in the network until the old one expires(36h), that creates all sort of problem and leads to the node changing its address not being properly connected for up to 36h.
After this RFC, nodes are extended to decide to keep the new record and propagate the new record to nodes that have the old record stored, so in the end all the nodes will converge faster to the new record(in the order of minutes, not 36h)
Implementation of the rfc: https://github.com/paritytech/polkadot-sdk/pull/3786.
Current issue without this enhacement: https://github.com/paritytech/polkadot-sdk/issues/3673
-
+
Polkadot node developers.
-
+
This RFC heavily relies on the functionalities of the Kademlia DHT already in use by Polkadot.
You can find a link to the specification here.
In a nutshell, on a specific node the current authority-discovery protocol publishes Kademila DHT records at startup and periodically. The records contain the full address of the node for each authorithy key it owns. The node tries also to find the full address of all authorities in the network by querying the DHT and picking up the first record it finds for each of the authority id it found on chain.
@@ -1634,25 +1495,164 @@ You can find a link to the specification
+
In theory the new protocol creates a bit more traffic on the DHT network, because it waits for DHT records to be received from more than one node, while in the current implementation we just take the first record that we receive and cancel all in-flight requests to other peers. However, because the redundancy factor will be relatively small and this operation happens rarerly, every 10min, this cost is negligible.
-
+
This RFC's implementation https://github.com/paritytech/polkadot-sdk/pull/3786 had been tested on various local test networks and versi.
With regard to security the creation time is wrapped inside SignedAuthorityRecord wo it will be signed with the authority id key, so there is no way for other malicious nodes to manipulate this field without the received node observing.
-
+
Irrelevant.
-
+
Irrelevant.
-
+
Irrelevant.
-
+
The changes are backwards compatible with the existing protocol, so nodes with both the old protocol and newer protocol can exist in the network, this is achieved by the fact that we use protobuf for serializing and deserializing the records, so new fields will be ignore when deserializing with the older protocol and vice-versa when deserializing an old record with the new protocol the new field will be None and the new code accepts this record as being valid.
-
+
The enhancements have been inspired by the algorithm specified in here
+
+N/A
+
+N/A
+(source)
+Table of Contents
+
+
+
+
+This RFC proposes the addition of a secondary market feature to the broker pallet, enabling users to list and purchase regions. This includes creating, purchasing, and removing listings, as well as emitting relevant events and handling associated errors.
+
+Currently, the broker pallet lacks functionality for a secondary market, which limits users' ability to freely trade regions. This RFC aims to introduce a secure and straightforward mechanism for users to list regions they own for sale and allow other users to purchase these regions. This functionality can enhance the flexibility and utility of the broker pallet, making it more user-friendly and valuable.
+
+Primary stakeholders include:
+
+- Developers working on the broker pallet.
+- Secondary Coretime marketplaces
+- Users who own regions and wish to trade them.
+- Community members interested in enhancing the broker pallet’s capabilities.
+
+
+This RFC introduces the following key features:
+
+-
+
Storage Changes:
+
+- Addition of
Listings storage map to keep track of regions listed for sale and their prices.
+
+
+-
+
New Dispatchable Functions:
+
+create_listing: Allows a region owner to list a region for sale.purchase_listing: Allows a user to purchase a listed region.remove_listing: Allows a region owner to remove their listing.
+
+-
+
Events:
+
+ListingCreated: Emitted when a new listing is created.RegionSold: Emitted when a region is sold.ListingRemoved: Emitted when a listing is removed.
+
+-
+
Error Handling:
+
+ExpiredRegion: The region has expired and cannot be listed or sold.UnknownListing: The listing does not exist.InvalidPrice: The listing price is invalid.NotOwner: The caller is not the owner of the region.
+
+-
+
Testing:
+
+- Comprehensive tests to verify the correct functionality of the new features, including listing creation, purchase, removal, and handling of edge cases such as expired regions and unauthorized actions.
+
+
+
+
+The main drawback is the additional complexity introduced to the broker pallet, which may increase maintenance overhead. Moreover, there is a potential risk of security vulnerabilities in the new market functionalities, such as unauthorized region transfers or incorrect balance adjustments.
+
+
+
+- Comprehensive unit tests need to be provided to ensure the correctness of the new functionalities.
+- Scenarios tested should include successful and failed listing creation, purchases, and removals, as well as edge cases like expired regions and non-owner actions.
+
+
+
+- Security audits should be performed to identify any vulnerabilities.
+- Ensure that only region owners can create or remove listings.
+- Validate all inputs to prevent invalid operations.
+
+
+
+- The proposal does not introduce new privacy concerns as it only affects region trading functionality within the existing framework.
+
+
+
+
+- This feature is expected to introduce minimal overhead since it primarily involves read and write operations to storage maps.
+- Efforts have been made to optimize the code to prevent unnecessary computational costs.
+
+
+
+- The new functions are designed to be intuitive and easy to use, providing clear feedback through events and errors.
+- Documentation and examples will be provided to assist developers and users.
+
+
+
+- This proposal does not break compatibility with existing interfaces or previous versions.
+- No migrations are necessary as it introduces new functionality without altering existing features.
+
+
+
+- Discussions with community members and developers highlighted the need for a built-in secondary market.
+
-N/A
+
+- Should there be a limit on the number of regions a user can list at one time?
+- Are there additional security measures needed to prevent potential abuses of the new functionalities?
+
-N/A
+
+- Further enhancements could include advanced filtering and search capabilities for listings.
+- Integration with external NFT marketplaces for more robust trading options.
+- Development of user interfaces to interact with the new marketplace features seamlessly.
+
(source)
Table of Contents
diff --git a/proposed/0015-market-design-revisit.html b/proposed/0015-market-design-revisit.html
index a651e96..bd40b98 100644
--- a/proposed/0015-market-design-revisit.html
+++ b/proposed/0015-market-design-revisit.html
@@ -90,7 +90,7 @@
@@ -290,7 +290,7 @@