This repository has been archived by the owner on Sep 24, 2021. It is now read-only.
Market Ecosystem Components #2
Labels
Comments
Closed
|
I think I understand what you are trying to do here but while the idea is
compelling, it feels like premature abstraction to me.
While it would be cool to have a plug and play market maker, I don’t think
we (or at least I) understand what a single market implementation would
look like nearly well enough to start generalizing to a more abstract
component architecture. At least I would personally want to wait until the
forthcoming NIPs you talk about have not only been drafted, but also
implemented, before accepting this NIP, even with draft status.
I guess that is my main comment. I have other more nit picky feedback about
taxonomy and writing style, but those are a lot less important than the
above so I’ll save them for later.
…On Sun, Dec 17, 2017 at 4:50 PM Jaycen Horton ***@***.***> wrote:
Preamble
NIP: <to be assigned>
Title: NRC-2 Market Components
Author: ***@***.***
Type: Meta
Status: Draft
Created: 2017-12-17
Simple Summary
This specification outlines the core components of a market ecosystem
(implemented as smart contracts) which can be used to implement standard
commodity markets (such as for a Carbon Removal Credit in the case of Nori).
Abstract
This standard does not propose implementation details of any particular
component, but rather their relationships and high level ecosystem
overviews. Additionally, this marketplace takes no preference to any
particular type of commodity/participant implementation requirements.
Instead, this proposal outlines the necessary components (implemented as
smart contracts) needed for a market to exist: a Market, Participant, and
Commodity
Motivation
Defining a standard market component ecosystem allows for the creation of
different types of markets to exist using a set of registries at the
market, participant, and commodity level.
A registry of markets allow for a lookup of operating markets, a lookup of
commodities allow for a lookup of commodities in those markets, and a
lookup of participants allow for a lookup of identities allowed to directly
interact with the smart contracts within each market.
Starting with these foundational components allows for extensions to
market, commodity and participant rules to exist within each market as well
as across multiple markets.
Specification
Component Relationship Overview
<https://camo.githubusercontent.com/2b43a16f7f177430f3e6c34255c4d0e88f2d8e26/68747470733a2f2f7777772e6c7563696463686172742e636f6d2f7075626c69635365676d656e74732f766965772f65393264393733322d383039302d343164322d626464642d3136313335343535643137622f696d6167652e706e67>
While the purpose of this specification is to provide an overview of how
markets, commodities, and participants interact with each other, the scope
of each individualized specification will be defined in forthcoming
NIPs/NRCs. Instead, the following is a general description of the
compartmentalization of each component.
MarketRegistry
A market Registry is a smart contract which holds information about
available markets.There is at least one global registry (though other may
create more like the global Registry) to which you can add a market. Adding
a market to it would increase the experience of the user that the GUI
Client can use or not.
Each market in the MarketRegistry contain an (or many) associated
ParticipantRegistry smart contracts
Each market in the MarketRegistry contain an (or many) associated
CommodityRegistry smart contracts
Market
The Market component is a smart contract interface which allows for
creating a particular type of a market by creating a MarketType smart
contract which implements the Market interface to define basic
functionalities of a particular MarketType.
MarketFactory
MarketFactory is an abstract smart contract which is used for the creation
or addition of a new market and to update the MarketRegistry. Basic
functions for creating a new market type exist within this scope.
MarketType
The MarketType smart contract realizes the Market interface contract and
contains the scope for the basic functions of all market functions. The
MarketType contract can be extended to allow for multiple types of Market
realizations with specialized functionalities.
ParticipantRegistry
Each market in the MarketRegistry contain an (or many) associated
ParticipantRegistry smart contracts. A ParticipantRegistry contract
contains a list of users and their permission (based on ParticipantType
association) to perform certain actions on functions defined within the
scope of that particular market.
Participant
A Participant is a realizable smart contract interface for implementing
basic participant functionalities. The participant interface can be
realized by the PariticipantType contract, and define basic functionalities
for returning a PariticipantType for a specified user address.
ParticipantFactory
ParticipiantFactory is an abstract smart contract which is used for the
creation or addition of a new participant (and its type) and to update the
ParticipantRegistry. Basic functions for creating a new Participant exist
within this scope.
ParticipantType
Only basic and general participant functionalities must be defined here
and any specialized functionalities are created by extending the
ParticipantType smart contract.
CommodityRegistry
Each market in the MarketRegistry contain an (or many) associated
CommodityRegistry smart contracts. A CommodityRegistry contract contains a
list of commodities and their types (based on CommodityType association)
which, based on a ParticipantType within the scope of the same
MarketRegistry contract, a Participant can perform certain actions on for
that commodity defined within the scope of that particular market.
Commodity
A Commodity is a realizable smart contract interface for implementing
basic commodity functionalities. The Commodity interface can be realized by
the CommodityType contract, and defines basic functionalities for returning
a CommodityType for a specified user address.
CommodityFactory
CommodityFactory is an abstract smart contract which is used for the
creation or addition of a new commodity(and its type) and to update the
CommodityRegistry. Basic functions for creating a new Commodity exist
within this scope.
CommodityType
Only basic and general Commodity functionalities must be defined here and
any specialized functionalities are created by extending the CommodityType
smart contract. An example Extended Commodity type is an ERC-20 token or
ERC-721 token extending CommodityType contract.
Rationale
Creating a specification for a generalized commodity market allows for
creating any number of specialized markets with an interoperable function
set. Additionally defining the market into these three components
(Participant, Market, and Commodity), allows for the creation of different
participant requirements across different Market types or different
Commodity types. In addition, by compartmentalizing each of these
components from each other changes necessary in one of the components
should not affect the way the other components need to behave. This allows
for easier scale to commodity types, market types, and participant types
(and their respective requirements) by simply extending each interface, and
updating the registry accordingly.
For instance, a new CommodityType can extend the Commodity interface by
using CommodityFactory to create the Commodity from a ParticipantType that
has the permissions neccesary for Modifying the CommoityRegistry. This
should not effect or require any changes to the Market components, as the
Commodity and Participant components are localized in scope for aparticular
Marekt in the MarketRegistry, and not the other way around. Changes to that
scoped Market might be adjusted using MarketFactory on that particular
Market but should not effect derived Participant or Commodity
functionalities and would instead extend or modify variables (such as a
Market name) that are not depended on by Participant or Commodity
components (such as changing the way a Market and Commodity are related in
such a way that causes existing functionality to break).
Backwards Compatibility
As this is the base standard for the rest of the Nori development, all
future implementations should refer to this standard and report any
potential errors within the scope of this specification so that
implementations can maintain scale and interoperability with the Nori
ecosystem.
Test Cases
N/A
Implementation
The implementation for each particular component will be defined in
specific Component NIP/NRCs.
Copyright
Copyright and related rights waived via CC0
<https://creativecommons.org/publicdomain/zero/1.0/>.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<#2>, or mute the thread
<https://github.com/notifications/unsubscribe-auth/AAHnm9bh5I3oB3M9hBUt0tphXh8mWspuks5tBba_gaJpZM4RE3Rv>
.
|
|
@pcardune I hear your comment, but don't feel like it's really all that much extra overhead and can provide quite a bit of scaling capacity, as well as allow for other people creating similar markets to participate. Desigining it like this allows for quite advantageous permission-based smart contracts by lookups in registries. Most of Noris focus will be on the commodityType component, which will honestly be as simple as extending ethereum/EIPs#721 Market rules will exist within extending and implementing MarketType (such as create new CRC listing), and permissions can be implemented in participants associated with MarketType. White/black listing can also be implemented in the participant components whilst keeping everything else quite modular and not requiring mass contract migration. |
|
I think explaining more of those details in the motivation section would be
helpful. Like perhaps with a couple examples to support the argument.
Permissions and migrations sound like kind of a big deal so to the extent
that this abstraction simplifies those problems, that should be spelled out
in the motivation.
…On Sun, Dec 17, 2017 at 10:45 PM Jaycen Horton ***@***.***> wrote:
@pcardune <https://github.com/pcardune> I hear your comment, but don't
feel like it's really all that much extra overhead and can provide quite a
bit of scaling capacity, as well as allow for other people creating similar
markets to participate. Desigining it like this allows for quite
advantageous permission-based smart contracts by lookups in registries.
Most of Noris focus will be on the commodityType component, which will
honestly be as simple as extending ethereum/EIPs#721
<ethereum/EIPs#721>
Market rules will exist within extending and implementing MarketType (such
as create new CRC listing), and permissions can be implemented in
participants associated with MarketType. White/black listing can also be
implemented in the participant components whilst keeping everything else
quite modular and not requiring mass contract migration.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#2 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AAHnm236dlw6gy3ntkr4o97J28gF7WWsks5tBgolgaJpZM4RE3Rv>
.
|
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Preamble
Simple Summary
This specification outlines the core components of a market ecosystem (implemented as smart contracts) which can be used to implement standard commodity markets (such as for a Carbon Removal Credit in the case of Nori).
Abstract
This standard does not propose implementation details of any particular component, but rather their relationships and high level ecosystem overviews. Additionally, this marketplace takes no preference to any particular type of commodity/participant implementation requirements. Instead, this proposal outlines the necessary components (implemented as smart contracts) needed for a market to exist: a Market, Participant, and Commodity
Motivation
Defining a standard market component ecosystem allows for the creation of different types of markets to exist using a set of registries at the market, participant, and commodity level.
A registry of markets allow for a lookup of operating markets, a lookup of commodities allow for a lookup of commodities in those markets, and a lookup of participants allow for a lookup of identities allowed to directly interact with the smart contracts within each market.
Starting with these foundational components allows for extensions to market, commodity and participant rules to exist within each market as well as across multiple markets.
Specification
Component Relationship Overview
While the purpose of this specification is to provide an overview of how markets, commodities, and participants interact with each other, the scope of each individualized specification will be defined in forthcoming NIPs. Instead, the following is a general description of the compartmentalization of each component.
MarketRegistry
A market Registry is a smart contract which holds information about available markets.There is at least one global registry (though other may create more like the global Registry) to which you can add a market. Adding a market to it would increase the experience of the user that the GUI Client can use or not.
Each market in the MarketRegistry contain an (or many) associated ParticipantRegistry smart contracts
Each market in the MarketRegistry contain an (or many) associated CommodityRegistry smart contracts
Market
The Market component is a smart contract interface which allows for creating a particular type of a market by creating a MarketType smart contract which implements the Market interface to define basic functionalities of a particular MarketType.
MarketType
The MarketType smart contract realizes the Market interface contract and contains the scope for the basic functions of all market functions. The MarketType contract can be extended to allow for multiple types of Market realizations with specialized functionalities.
ParticipantRegistry
Each market in the MarketRegistry contain an (or many) associated ParticipantRegistry smart contracts. A ParticipantRegistry contract contains a list of users and their permission (based on ParticipantType association) to perform certain actions on functions defined within the scope of that particular market.
Participant
A Participant is a realizable smart contract interface for implementing basic participant functionalities. The participant interface can be realized by the PariticipantType contract, and define basic functionalities for returning a PariticipantType for a specified user address.
ParticipantType
Only basic and general participant functionalities must be defined here and any specialized functionalities are created by extending the ParticipantType smart contract.
CommodityRegistry
Each market in the MarketRegistry contain an (or many) associated CommodityRegistry smart contracts. A CommodityRegistry contract contains a list of commodities and their types (based on CommodityType association) which, based on a ParticipantType within the scope of the same MarketRegistry contract, a Participant can perform certain actions on for that commodity defined within the scope of that particular market.
Commodity
A Commodity is a realizable smart contract interface for implementing basic commodity functionalities. The Commodity interface can be realized by the CommodityType contract, and defines basic functionalities for returning a CommodityType for a specified user address.
CommodityType
Only basic and general Commodity functionalities must be defined here and any specialized functionalities are created by extending the CommodityType smart contract. An example Extended Commodity type is an ERC-20 token or ERC-721 token extending CommodityType contract.
Rationale
Creating a specification for a generalized commodity market allows for creating any number of specialized markets with an interoperable function set. Additionally defining the market into these three components (Participant, Market, and Commodity), allows for the creation of different participant requirements across different Market types or different Commodity types. In addition, by compartmentalizing each of these components from each other changes necessary in one of the components should not affect the way the other components need to behave. This allows for easier scale to commodity types, market types, and participant types (and their respective requirements) by simply extending each interface, and updating the registry accordingly.
For instance, a new CommodityType can extend the Commodity interface by using CommodityFactory to create the Commodity from a ParticipantType that has the permissions neccesary for Modifying the CommoityRegistry. This should not effect or require any changes to the Market components, as the Commodity and Participant components are localized in scope for aparticular Marekt in the MarketRegistry, and not the other way around. Changes to that scoped Market might be adjusted using MarketFactory on that particular Market but should not effect derived Participant or Commodity functionalities and would instead extend or modify variables (such as a Market name) that are not depended on by Participant or Commodity components (such as changing the way a Market and Commodity are related in such a way that causes existing functionality to break).
Backwards Compatibility
As this is the base standard for the rest of the Nori development, all future implementations should refer to this standard and report any potential errors within the scope of this specification so that implementations can maintain scale and interoperability with the Nori ecosystem.
Test Cases
N/A
Implementation
The implementation for each particular component will be defined in specific Component NIP/NRCs.
Copyright
Copyright and related rights waived via CC0.
The text was updated successfully, but these errors were encountered: