├── ISSUE_TEMPLATE.md ├── PULL_REQUEST_TEMPLATE.md ├── README.md ├── meta-mip ├── MMIP-1.md └── MMIP-1 │ └── process.png ├── mip-X.md └── mips ├── mip-16.md ├── mip-2.md ├── mip-3.md ├── mip-4.md └── mip-8.md /ISSUE_TEMPLATE.md: -------------------------------------------------------------------------------- 1 | 2 | ATTENTION! If you would like to submit an MIP and it has already been written as a draft (see the [template](https://github.com/mvs-org/mips/blob/master/mip-X.md) for an example), please submit it as a [Pull Request](https://github.com/mvs-org/mips/pulls). 3 | 4 | If you are considering a proposal but would like to get some feedback on the idea before submitting a draft, then continue opening an Issue as a thread for discussion. Note that the more clearly and completely you state your idea the higher the quality of the feedback you are likely to receive. 5 | 6 | Keep in mind the following guidelines from [MMIP-1](https://github.com/betachen/mips/blob/master/meta-mip/MMIP-1.md): 7 | 8 | > Each MIP must have a champion - someone who writes the MIP using the style and format described below, shepherds the discussions in the appropriate forums, and attempts to build community consensus around the idea. The MIP champion (a.k.a. Author) should first attempt to ascertain whether the idea is MIP-able. Posting to the the Protocol Discussion forum or opening an Issue is the best way to go about this. 9 | 10 | > Vetting an idea publicly before going as far as writing a MIP is meant to save the potential author time. Asking the Metaverse community first if an idea is original helps prevent too much time being spent on something that is guaranteed to be rejected based on prior discussions (searching the Internet does not always do the trick). It also helps to make sure the idea is applicable to the entire community and not just the author. Just because an idea sounds good to the author does not mean it will work for most people in most areas where Metaverse is used. 11 | 12 | > Once the champion has asked the Metaverse community as to whether an idea has any chance of acceptance, a draft MIP should be presented as a Pull Request. This gives the author a chance to flesh out the draft MIP to make properly formatted, of high quality, and to address initial concerns about the proposal. 13 | -------------------------------------------------------------------------------- /PULL_REQUEST_TEMPLATE.md: -------------------------------------------------------------------------------- 1 | When opening a pull request to submit a new MIP, please use the suggested template: 2 | -------------------------------------------------------------------------------- /README.md: -------------------------------------------------------------------------------- 1 | # MIPs 2 | Metaverse Improvement Proposals (MIPs) describe standards for the Metaverse platform, including core protocol specifications, client APIs, and contract standards. 3 | 4 | # Contributing 5 | First review [MMIP-1](meta-mip/MMIP-1.md). Then clone the repository and add your MIP to it. There is a [template MIP here](mip-X.md). Then submit a Pull Request to Metaverse's [MIPs repository](https://github.com/mvs-org/mips). 6 | 7 | # MIP status terms 8 | * **Draft** - an MIP that is open for consideration 9 | * **Accepted** - an MIP that is planned for immediate adoption, i.e. expected to be included in the next hard fork (for Core/Consensus layer MIPs). 10 | * **Final** - an MIP that has been adopted in a previous hard fork (for Core/Consensus layer MIPs). 11 | * **Deferred** - an MIP that is not being considered for immediate adoption. May be reconsidered in the future for a subsequent hard fork. 12 | 13 | # Non-final MIPs 14 | | Number | Title | Author | Layer | Status | 15 | | ------------------------- | ------------------------------------------------------- | ----------------------------- | --------- | ---------- | 16 | | [2](mips/mip-2.md) | Adjust reward rate of deposit function | Hao Chen, Youming | Core/ECO | Draft | 17 | | [9](mips/mip-9.md) | Digital Assets(MST) UnLock Conditionally | Hao Chen, Youming | ECO | Draft | 18 | | [15](mips/mip-15.md) | Digital Assets(MST) Token Swap | Hao Chen, Youming | ECO | Draft | 19 | | [16](mips/mip-16.md) | Digital Identity(Avatar):MVS Avatar Reputation System | Hao Chen, Pattsoi | ECO | Draft | 20 | 21 | # Deferred MIPs 22 | | Number | Title | Author | Layer | Status | 23 | | -------------------------------------------------- | -------------------------------------------------------------------------------------------- | ------------------------------------------ | ---------- | -------- | 24 | | NULL | | | | | 25 | | [14](mips/mip-14.md) | Mining Token(MST) Rewards | Hao Chen | ECO | Draft | 26 | 27 | # Finalized MIPs (standards that have been adopted) 28 | | Number | Title | Author | Layer | Status | 29 | | -------------------------------------------------- | -------------------------------------------------------------------------------------------- | -------------------------------------------| ---------- | -------- | 30 | | [1](meta-mip/MMIP-1.md) | MIP Purpose and Guidelines | Eric Gu, Youming Jiang, Hao Chen | Meta | Final | 31 | | [3](mips/mip-3.md) | Digital Assets Secondary Issuance | Hao Chen, Youming | ECO | Final | 32 | | [4](mips/mip-4.md) | Digital Assets Issuance Right and Extension Rights | Hao Chen, Youming | ECO | Final | 33 | | [6](mips/mip-6.md) | Digital Assets(MST) Domain-name | Hao Chen, Youming | ECO | Final | 34 | | [7](mips/mip-7.md) | Digital Assets(MST) Lock | Hao Chen, Youming | ECO | Final | 35 | | [8](mips/mip-8.md) | Digital Assets(MST) UnLock on block height | Hao Chen, Youming | ECO | Final | 36 | | [11](mips/mip-11.md) | Digital Identity(Avatar) Phase1: address and human readable name | Hao Chen | ECO | Final | 37 | | [12](mips/mip-12.md) | Digital Identity(Avatar) Phase1: Certifications | Hao Chen | ECO | Final | 38 | | [13](mips/mip-13.md) | Digital Assets(MIT) Register&Transfering | Hao Chen | ECO | Final | 39 | 40 | # Past Hard Forks 41 | | Codename | Aliases | Block number | Date (UTC) | 42 | |-------------------------------------- |---------------------------- |----------------|------------| 43 | | N/A | SuperNova | 1270000 | Jun.18.2018| 44 | | N/A | Future-Time Attack | 1030000 | Mar.16.2018| 45 | -------------------------------------------------------------------------------- /meta-mip/MMIP-1.md: -------------------------------------------------------------------------------- 1 | MIP: 1 2 | Title: MIP Purpose and Guidelines 3 | Status: Draft 4 | Type: Meta 5 | Author: Hao Chen 6 | Created: 2017-06-01 7 | 8 | What is an MIP? 9 | -------------- 10 | 11 | MIP stands for Metaverse Improvement Proposal. An MIP is a design document providing information to the Metaverse community, or describing a new feature for Metaverse or its processes or environment. The MIP should provide a concise technical specification of the feature and a rationale for the feature. The MIP author is responsible for building consensus within the community and documenting dissenting opinions. 12 | 13 | MIP Rational 14 | ------------ 15 | 16 | We intend MIPs to be the primary mechanisms for proposing new features, for collecting community input on an issue, and for documenting the design decisions that have gone into Metaverse. Because the MIPs are maintained as text files in a versioned repository, their revision history is the historical record of the feature proposal. 17 | 18 | For Metaverse implementers, MIPs are a convenient way to track the progress of their implementation. Ideally each implementation maintainer would list the MIPs that they have implemented. This will give end users a convenient way to know the current status of a given implementation or library. 19 | 20 | MIP Types 21 | --------- 22 | 23 | There are three types of MIP: 24 | 25 | - A **Standard Track MIP** describes any change that affects most or all Metaverse implementations, such as a change to the 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 Metaverse. Furthermore Standard MIPs can be broken down into the following categories. 26 | - **Core** - improvements requiring a consensus fork (e.g. [MIP02]]), as well as changes that are not necessarily consensus critical but may be relevant to “core dev” discussions. 27 | - **Networking** - includes improvements around, as well as proposed improvements to network protocol. 28 | - **Interface** - includes improvements around client [API/RPC] specifications and standards, and also certain language-level standards like method names . The label “interface” aligns with the [interfaces repo] and discussion should primarily occur in that repository before an MIP is submitted to the MIPs repository. 29 | - **ECO** - economy-level standards and conventions, including token usage standards such as digital asset standards (**[MST] Metaverse Smart Token**,**[MIT] Metaverse Identifiable Token**), digital identity standards (**[Avatar] Metaverse Didigtal Identity**). 30 | 31 | - An **Informational MIP** describes a Metaverse design issue, or provides general guidelines or information to the Metaverse community, but does not propose a new feature. Informational MIPs do not necessarily represent Metaverse community consensus or a recommendation, so users and implementers are free to ignore Informational MIPs or follow their advice. 32 | - A **Meta MIP** (MMIP) describes a process surrounding Metaverse or proposes a change to (or an event in) a process. Process MIPs are like Standards Track MIPs but apply to areas other than the Metaverse protocol itself. They may propose an implementation, but not to Metaverse's codebase; they often require community consensus; unlike Informational MIPs, 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 Metaverse development. Any meta-MIP is also considered a Process MIP. 33 | 34 | MIP Work Flow 35 | ------------- 36 | 37 | The MIP repository Collaborators change the MIPs status. Please send all MIP-related email to the MIP Collaborators, which is listed under MIP Editors below. Also see MIP Editor Responsibilities & Workflow. 38 | 39 | The MIP process begins with a new idea for Metaverse. It is highly recommended that a single MIP contain a single key proposal or new idea. The more focused the MIP, the more successful it tends to be. A change to one client doesn't require an MIP; a change that affects multiple clients, or defines a standard for multiple apps to use, does. The MIP editor reserves the right to reject MIP proposals if they appear too unfocused or too broad. If in doubt, split your MIP into several well-focused ones. 40 | 41 | Each MIP must have a champion - someone who writes the MIP using the style and format described below, shepherds the discussions in the appropriate forums, and attempts to build community consensus around the idea. 42 | 43 | Vetting an idea publicly before going as far as writing an MIP is meant to save the potential author time. Asking the Metaverse community first if an idea is original helps prevent too much time being spent on something that is guaranteed to be rejected based on prior discussions (searching the Internet does not always do the trick). It also helps to make sure the idea is applicable to the entire community and not just the author. Just because an idea sounds good to the author does not mean it will work for most people in most areas where Metaverse is used. Examples of appropriate public forums to gauge interest around your MIP include [the Metaverse subreddit], [the Issues section of this repository], and [one of the Metaverse Gitter chat rooms]. In particular, [the Issues section of this repository] is an excellent place to discuss your proposal with the community and start creating more formalized language around your MIP. 44 | 45 | Once the champion has asked the Metaverse community whether an idea has any chance of acceptance a draft MIP should be presented as a [pull request]. This gives the author a chance to continuously edit the draft MIP for proper formatting and quality. This also allows for further public comment and the author of the MIP to address concerns about the proposal. 46 | 47 | If the MIP collaborators approve, the MIP editor will assign the MIP a number (generally the issue or PR number related to the MIP), label it as Standards Track, Informational, or Meta, give it status “Draft”, and add it to the git repository. The MIP editor will not unreasonably deny an MIP. Reasons for denying MIP status include duplication of effort, being technically unsound, not providing proper motivation or addressing backwards compatibility, or not in keeping with the Metaverse philosophy. 48 | 49 | Standards Track MIPs consist of three parts, a design document, implementation, and finally if warranted an update to the [formal specification]. The MIP should be reviewed and accepted before an implementation is begun, unless an implementation will aid people in studying the MIP. Standards Track MIPs must be implemented in at least three viable Metaverse clients before it can be considered Final. 50 | 51 | For an MIP to be accepted it 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. 52 | 53 | Once an MIP has been accepted, the implementations must be completed. When the implementation is complete and accepted by the community, the status will be changed to “Final”. 54 | 55 | An MIP can also be assigned status “Deferred”. The MIP author or editor can assign the MIP this status when no progress is being made on the MIP. Once an MIP is deferred, the MIP editor can re-assign it to draft status. 56 | 57 | An MIP can also be “Rejected”. Perhaps after all is said and done it was not a good idea. It is still important to have a record of this fact. 58 | 59 | MIPs can also be superseded by a different MIP, rendering the original obsolete. 60 | 61 | The possible paths of the status of MIPs are as follows: 62 | 63 | 64 | 65 | Some Informational and Process MIPs may also have a status of “Active” if they are never meant to be completed. E.g. MIP 1 (this MIP). 66 | 67 | What belongs in a successful MIP? 68 | --------------------------------- 69 | 70 | Each MIP should have the following parts: 71 | 72 | - Preamble - RFC 822 style headers containing metadata about the MIP, including the MIP number, a short descriptive title (limited to a maximum of 44 characters), the names, and optionally the contact info for each author, etc. 73 | 74 | 75 | 76 | - Simple Summary - “If you can’t explain it simply, you don’t understand it well enough.” Provide a simplified and layman-accessible explanation of the MIP. 77 | 78 | 79 | 80 | - Abstract - a short (~200 word) description of the technical issue being addressed. 81 | 82 | 83 | 84 | - Motivation (*optional) - The motivation is critical for MIPs that want to change the Metaverse protocol. It should clearly explain why the existing protocol specification is inadequate to address the problem that the MIP solves. MIP submissions without sufficient motivation may be rejected outright. 85 | 86 | 87 | 88 | - Specification - The technical specification should describe the syntax and semantics of any new feature. The specification should be detailed enough to allow competing, interoperable implementations for any of the current Metaverse platforms (cpp-Metaverse, go-Metaverse, parity, MetaverseJ, Metaversejs-lib, …). 89 | 90 | 91 | 92 | - Rationale - The rationale fleshes out the specification by describing what motivated the design and why particular design decisions were made. It should describe alternate designs that were considered and related work, e.g. how the feature is supported in other languages. The rationale may also provide evidence of consensus within the community, and should discuss important objections or concerns raised during discussion. 93 | 94 | 95 | 96 | - Backwards Compatibility - All MIPs that introduce backwards incompatibilities must include a section describing these incompatibilities and their severity. The MIP must explain how the author proposes to deal with these incompatibilities. MIP submissions without a sufficient backwards compatibility treatise may be rejected outright. 97 | 98 | 99 | 100 | - Test Cases - Test cases for an implementation are mandatory for MIPs that are affecting consensus changes. Other MIPs can choose to include links to test cases if applicable. 101 | 102 | 103 | 104 | - Implementations - The implementations must be completed before any MIP is given status “Final”, but it need not be completed before the MIP is accepted. While there is merit to the approach of reaching consensus on the specification and rationale before writing code, the principle of “rough consensus and running code” is still useful when it comes to resolving many discussions of API details. 105 | 106 | MIP Formats and Templates 107 | ------------------------- 108 | 109 | MIPs should be written in [markdown] format. Image files should be included in a subdirectory for that MIP. 110 | 111 | MIP Header Preamble 112 | ------------------- 113 | 114 | Each MIP must begin with an RFC 822 style header preamble. The headers must appear in the following order. Headers marked with "*" are optional and are described below. All other headers are required. 115 | 116 | ` MIP: ` (this is determined by the MIP editor) 117 | 118 | ` Title: ` 119 | 120 | ` Author: ` 121 | 122 | ` * Discussions-To: ` 123 | 124 | ` Status: ` 125 | 126 | ` Type: ` 127 | 128 | ` Created: ` 129 | 130 | ` * Replaces: ` 131 | 132 | ` * Superseded-By: ` 133 | 134 | ` * Resolution: ` 135 | 136 | The Author header lists the names, and optionally the email addresses of all the authors/owners of the MIP. The format of the Author header value must be 137 | 138 | Random J. User <address@dom.ain> 139 | 140 | if the email address is included, and 141 | 142 | Random J. User 143 | 144 | if the email address is not given. 145 | 146 | Note: The Resolution header is required for Standards Track MIPs only. It contains a URL that should point to an email message or other web resource where the pronouncement about the MIP is made. 147 | 148 | While an MIP is in private discussions (usually during the initial Draft phase), a Discussions-To header will indicate the mailing list or URL where the MIP is being discussed. No Discussions-To header is necessary if the MIP is being discussed privately with the author. 149 | 150 | The Type header specifies the type of MIP: Standards Track, Meta, or Informational. If the track is Standards please include the subcategory (core, networking, interface, or ERC). 151 | 152 | The Created header records the date that the MIP was assigned a number. Both headers should be in yyyy-mm-dd format, e.g. 2001-08-14. 153 | 154 | MIPs may have a Requires header, indicating the MIP numbers that this MIP depends on. 155 | 156 | MIPs may also have a Superseded-By header indicating that an MIP has been rendered obsolete by a later document; the value is the number of the MIP that replaces the current document. The newer MIP must have a Replaces header containing the number of the MIP that it rendered obsolete. 157 | 158 | Auxiliary Files 159 | --------------- 160 | 161 | MIPs may include auxiliary files such as diagrams. Such files must be named MIP-XXXX-Y.ext, where “XXXX” is the MIP number, “Y” is a serial number (starting at 1), and “ext” is replaced by the actual file extension (e.g. “png”). 162 | 163 | Transferring MIP Ownership 164 | -------------------------- 165 | 166 | It occasionally becomes necessary to transfer ownership of MIPs to a new champion. In general, we'd like to retain the original author as a co-author of the transferred MIP, but that's really up to the original author. A good reason to transfer ownership is because the original author no longer has the time or interest in updating it or following through with the MIP process, or has fallen off the face of the 'net (i.e. is unreachable or not responding to email). A bad reason to transfer ownership is because you don't agree with the direction of the MIP. We try to build consensus around an MIP, but if that's not possible, you can always submit a competing MIP. 167 | 168 | If you are interested in assuming ownership of an MIP, send a message asking to take over, addressed to both the original author and the MIP editor. If the original author doesn't respond to email in a timely manner, the MIP editor will make a unilateral decision (it's not like such decisions can't be reversed :). 169 | 170 | MIP Editors 171 | ----------- 172 | 173 | The current MIP editors are 174 | 175 | ` * Youming Jiang(@Youming)` 176 | 177 | ` * Eirc Gu(@Eric)` 178 | 179 | ` * Hao Chen(@Hao)` 180 | 181 | MIP Editor Responsibilities and Workflow 182 | -------------------------------------- 183 | 184 | For each new MIP that comes in, an editor does the following: 185 | 186 | - Read the MIP to check if it is ready: sound and complete. The ideas must make technical sense, even if they don't seem likely to be accepted. 187 | - The title should accurately describe the content. 188 | - Edit the MIP for language (spelling, grammar, sentence structure, etc.), markup (Github flavored Markdown), code style 189 | 190 | If the MIP isn't ready, the editor will send it back to the author for revision, with specific instructions. 191 | 192 | Once the MIP is ready for the repository, the MIP editor will: 193 | 194 | - Assign an MIP number (generally the PR number or, if preferred by the author, the Issue # if there was discussion in the Issues section of this repository about this MIP) 195 | 196 | 197 | 198 | - Accept the corresponding pull request 199 | 200 | 201 | 202 | - List the MIP in [README.md] 203 | 204 | 205 | 206 | - Send a message back to the MIP author with next step. 207 | 208 | Many MIPs are written and maintained by developers with write access to the Metaverse codebase. The MIP editors monitor MIP changes, and correct any structure, grammar, spelling, or markup mistakes we see. 209 | 210 | The editors don't pass judgment on MIPs. We merely do the administrative & editorial part. 211 | 212 | History 213 | ------- 214 | 215 | This document was derived heavily from [Bitcoin's BIP-0001] written by Amir Taaki which in turn was derived from [Python's PEP-0001]. In many places text was simply copied and modified. Although the PEP-0001 text was written by Barry Warsaw, Jeremy Hylton, and David Goodger, they are not responsible for its use in the Metaverse Improvement Process, and should not be bothered with technical questions specific to Metaverse or the MIP. Please direct all comments to the MIP editors. 216 | 217 | [Bitcoin's BIP-0001]: https://github.com/bitcoin/bips 218 | [Python's PEP-0001]: https://www.python.org/dev/peps/ 219 | [Metaverse's EIP-0001]: https://github.com/ethereum/EIPs 220 | -------------------------------------------------------------------------------- /meta-mip/MMIP-1/process.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/mvs-org/mips/a66a25f53e8c9a9e10e810242df82adb90f2688f/meta-mip/MMIP-1/process.png -------------------------------------------------------------------------------- /mip-X.md: -------------------------------------------------------------------------------- 1 | This is the suggested template for new MIPs. 2 | 3 | Note that an MIP number will be assigned by an editor. When opening a pull request to submit your MIP, please use an abbreviated title in the filename, `MIP-draft_title_abbrev.md`. 4 | 5 | ## Preamble 6 | 7 | MIP: 8 | Title: 9 | Author: 10 | Type: 11 | Category (*only required for Standard Track): 12 | Status: Draft 13 | Created: 14 | Requires (*optional): 15 | Replaces (*optional): 16 | 17 | 18 | ## Simple Summary 19 | "If you can't explain it simply, you don't understand it well enough." Provide a simplified and layman-accessible explanation of the MIP. 20 | 21 | ## Abstract 22 | A short (~200 word) description of the technical issue being addressed. 23 | 24 | ## Motivation 25 | The motivation is critical for MIPs that want to change the Metaverse protocol. It should clearly explain why the existing protocol specification is inadequate to address the problem that the MIP solves. MIP submissions without sufficient motivation may be rejected outright. 26 | 27 | ## Specification 28 | The technical specification should describe the syntax and semantics of any new feature. The specification should be detailed enough to allow competing, interoperable implementations for any of the current Metaverse platforms (cpp-ethereum, go-ethereum, parity, ethereumj, ethereumjs, ...). 29 | 30 | ## Rationale 31 | The rationale fleshes out the specification by describing what motivated the design and why particular design decisions were made. It should describe alternate designs that were considered and related work, e.g. how the feature is supported in other languages. The rationale may also provide evidence of consensus within the community, and should discuss important objections or concerns raised during discussion. 32 | 33 | ## Backwards Compatibility 34 | All MIPs that introduce backwards incompatibilities must include a section describing these incompatibilities and their severity. The MIP must explain how the author proposes to deal with these incompatibilities. MIP submissions without a sufficient backwards compatibility treatise may be rejected outright. 35 | 36 | ## Test Cases 37 | Test cases for an implementation are mandatory for MIPs that are affecting consensus changes. Other MIPs can choose to include links to test cases if applicable. 38 | 39 | ## Implementation 40 | The implementations must be completed before any MIP is given status "Final", but it need not be completed before the MIP is accepted. While there is merit to the approach of reaching consensus on the specification and rationale before writing code, the principle of "rough consensus and running code" is still useful when it comes to resolving many discussions of API details. 41 | 42 | ## Copyright 43 | Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/). 44 | -------------------------------------------------------------------------------- /mips/mip-16.md: -------------------------------------------------------------------------------- 1 | ## Preamble 2 | 3 | ``` 4 | MIP: 16 5 | Title: Metaverse Avatar Reputation System 6 | Author: Patrick Tsoi, Penny Mao 7 | Type: Standard Track 8 | Category: Core/ECO 9 | Status: Draft 10 | Created: 2018-10-29 11 | ``` 12 | **(The following is the Chinese version and will be translated into English later on）** 13 | ## Simple Summary 14 | 本文将基于对社会角色、社会地位与声誉的相关理论来阐述元界数字身份声誉系统的理论基础和模型设计。 15 | 16 | This MIP will explain the theoretical basis and model design of the Metaverse Avatar Reputation System in the Metaverse based on the relevant theories of social roles, social status and reputation. 17 | 18 | ## Theoretical Background 19 | ### Social Role、Social Status and Reputation (社会角色、社会地位与声望) 20 | 社会地位是指社会个人在社会上，根据其社会阶级所得到的荣誉和声望。社会地位可以通过自致或者先赋两种方式决定。一种是通过自致地位，即透过自己后天的努力争取回来的社会地位，或者指一个人在其一生中通过行使知识、能力、技巧等所取得的结果；二是先赋地位，即一个人是透过先天来自家族或者团体等承袭得到其于社会分层体系中所处的位置；先赋地位亦意指在某些社会中，一个人从出生起就被赋予无法改变的社会地位。在整个人类社会中有基于性别、年龄、种族、国别和家庭背景等的先赋社会地位。例如，某些家族基于巨大的物资财务而可能有着高知名度和声誉、`某些成员以能干闻名于社会`、以及坐拥巨大财富等特征，若一个人出生于其中，在成长过程里将会背负着很多期望。故此，他们会被赋予多种社会角色并加以训练，在这个逐步取得家族特征的过程中，他们将会被社会定位于这个家族之中。而职业所带来的地位则是可能个同时不属于先赋或自致地位的例子，它是一个人可以通过得到正确的知识和技巧而获社会定位到该工作的更高位置，从而建立个人在职业中的社会角色。 21 | 22 | Social status refers to the glory and prestige that social individuals receive in society and according to their social class. Social status can be determined either by self-intention or by giving two ways. One is through self-sufficiency, that is, the social status that is sought back through the efforts of the day after tomorrow, or the result of a person’s knowledge, ability, skill, etc. in his/her life. The second is the status of the first position, that is, a person is in a position in the social stratification system by inherited from the family or the group; the first status also means that in some society, a person from birth Being given an unchangeable social status. There are social status in the entire human society based on gender, age, ethnicity, country and family background. For example, some families may have high reputation and reputation based on huge material finances, some members are known for their ability to be socially, and have great wealth. If a person is born, he will bear the burden during his growth with a lot of expectations. Therefore, they will be given a variety of social roles and trained, in the process of gradually acquiring family characteristics, they will be positioned by the society in this family. The status brought by the profession is an example of a situation that is not at the same time a pre-existing or self-sufficient position. It is a person who can obtain a correct position in the work by obtaining the correct knowledge and skills. Social role in the profession. 23 | 24 | ### Social Role in blockchain(区块链中的社会角色) 25 | 基于区块链的形成数据空间，个体或者团体（法人）可以建立属于这个数据空间的唯一的数字身份包括属于声望、信用和权利。通过区块链的技术使得每一个数字身份可以通过数字签名确权证明或背书。当个人或者团体唯一的数字身份拥有了签名私钥，可以在任何时候证明自己的身份，以后可以在许多区块链上的应用场景，如预订酒店房间、预订航班机票、使用共享服务、进行网络金融借贷等所有需要验明真身的地方，都可以用其唯一的数字身份证明。 26 | 27 | Based on the blockchain forming data space, an individual or group (legal person) can establish a unique digital identity belonging to this data space including belonging to reputation, credit, and rights. Through the technology of the blockchain, each digital identity can be certified or endorsed by digital signature. When an individual or a group's unique digital identity has a signed private key, it can prove its identity at any time, and can be applied to many blockchains in the future, such as booking a hotel room, booking a flight ticket, using a shared service, and conducting a network. Financial lending and other places where you need to verify your true body can use their unique digital identity. 28 | 29 | 另外，唯一的数字身份下可以记录使用者在区块链上多个应用的不同的（社会）身份/角色以及其历史行为，如某一个数字身份向另外的一个数字身份进行资金资产的转账；数字身份之间的借贷；数字身份之间的结婚登记；数字身份下技能、学历、职业发展登记验证等等。使得数字身份不仅仅是一个验证身份证明“我是我”的工具同时也是记录“我做过什么”的历史行为记录的载体。 30 | 31 | In addition, the unique digital identity can record the different (social) identities/characters of the user's multiple applications in the blockchain and their historical behavior, such as the transfer of a digital identity to another digital identity for the transfer of capital assets; Lending between digital identities; marriage registration between digital identities; skills, education, and professional development registration verification under digital identity. Making digital identity more than just a tool to verify identity proof "I am me" is also a vehicle for recording historical records of "what I have done" 32 | 33 | ### Reputation system in blockchain（区块链中的声誉系统） 34 | 针对社会角色、社会地位以及声望的关系描述和在区块链上的使用，声誉反映的的是个人或者团体的社会地位，社会地位的高低从而影响该主体在职业、教育、经济和权力的领域。而声誉系统是可作为基于区块链上的数字身份的一个是核心的价值应用，区块链可以通过链上的数字身份和声誉系统推动区块链上的应用场景和使用频率、用户可以通过自己的数字身份及行为历史来建立自己的声誉，区块链系统会基于数字身份在区块链上的行为如数字货币转账、数字身份的建立、区块链上的借贷、在数字身份上登记学历证明、结婚证明等等行为来增减数字身份的声誉值。数字身份背后的声誉代表其在区块链上的社会地位及声誉、而可量化的声誉系统更能够直接或间接与其他在区块链上的应用相互影响数字身份在这些应用中适用范围。 35 | 36 | 37 | 38 | Relating to the relationship between social roles, social status and prestige and the use of the blockchain, the reputation reflects the social status of the individual or group, and the level of social status affects the subject in the fields of occupation, education, economy and power. The reputation system is a core value application that can be used as a digital identity based on the blockchain. The blockchain can promote the application scenarios and frequency of use on the blockchain through the digital identity and reputation system on the chain. Establish your own reputation with your own digital identity and behavioral history. The blockchain system will increase or decrease reputation of digital identities based on the behavior of digital identities on the blockchain, such as digital currency transfers, the establishment of digital identities, lending on blockchains, registration of academic credentials on digital identities, marriage certificates, etc. The reputation behind digital identity represents its social status and reputation in the blockchain, and the quantifiable reputation system is more directly or indirectly interacting with other applications on the blockchain to influence the application of digital identity in these applications. 39 | 40 | ## Specification 41 | ### MVS Avatar Reputation System MARS （元界数字身份声誉系统) 42 | 区块链的到来，建立一个人人都可以信任的身份，甚至包括个人信用、个人权利，都可以第一次实现。通过区块链等数字签名来确权证明。当一个人只要拥有了签名私钥，可以在任何时候证明自己的身份，以后订酒店、订航班、参加考试、公司面试、网络借贷等所有需要验明身份的地方，都可以用一个区块链身份证搞定，且无法作假。元界数字身份声誉系统（简称MARS）是基于元界区块链(MVS)和元界数字身份(MVS Avatar)建立的基于声誉纽带关系系统，MARS旨在增加可以元界数字身份使用的延展性，不仅仅用于数字身份之间的MST和MIT的转账，而且延伸数字身份在数字货币的借贷、数字身份在元界区块链上应用的功能区分等。 43 | 44 | With the arrival of the blockchain, the establishment of an identity including trust, credit and individual rights, can be realized for the first time. Proof of power is confirmed by digital signatures such as blockchains. When a person has a signed private key, he can prove his identity at any time. After booking a hotel, booking a flight, taking an exam, a company interview, online lending, etc., all the places that need to be verified can use a block. The chain ID card is fixed and cannot be faked. The Digital Identity Reputation System (MARS) in Metaverse is a reputation-based relationship system based on the Metaverse blockchain and MVS Avatar. MARS aims to increase the use of digital identity in the Metaverse. Not only for the transfer of MST and MIT between digital identities, but also for the extension of digital identities in crypto currency lending, the functional differentiation of digital identities applied in the Metaverse blockchain. 45 | 46 | ### Market Reference (市场参考） 47 | 目前市场上最主要的两大个人声誉信用评级机构FICO及芝麻信用。在银行业运用最广泛的就是FICO分数，这是由FICO公司拥有的一种计算模型，其具体细节并没有批露，综合以下几个要点来决定决定了您的信用分数。 48 | 49 | At present, the two most important personal reputation credit rating agencies on the market are FICO and Sesame Credit. The most widely used in the banking industry is the FICO score, a calculation model owned by FICO. The details are not disclosed. The following points are used to determine your credit score. 50 | 51 | *1.还款历史 （35%）（payment history）* 52 | 53 | *2.债务与收入比例（30%） (amount Owed）* 54 | 55 | *3.信用史的长短（20%）（length of Credit History)* 56 | 57 | *4.新增的信用账户数量（10%）（New Credit Account)* 58 | 59 | *5.借款种类（10%）(types of credit used).* 60 | 61 | FICO分的区间在300~850分之间，不同的得分档次意味着不同的违约概率。 体现在违约率上，FICO分低于600分，贷款违约比例为1：8；信用分数在700~800，违约比例为1：123；信用分大于800分的借款人，违约比例仅为1：1292。 62 | 63 | The range of FICO points is between 300 and 850 points. Different scores mean different default probability. Reflected in the default rate, FICO score is less than 600 points, loan default ratio is 1:8; credit score is 700~800, default ratio is 1:123; borrowers with credit score greater than 800 points, the default ratio is only 1: 1292. 64 | 65 | 而芝麻信用根据阿里旗下的消费类应用如淘宝、支付宝等数据建立一个信用分体系，主要的核心模块有五个包括： 66 | 67 | Sesame Credit has established a credit system based on data from Ali's consumer applications such as Taobao and Alipay. The main core modules include five areas: 68 | 69 | 1.身份特征（15%）如公安实名认证，身份信息，信息稳定性等。(Character of identity 15%) Such as public security real-name authentication, identity information, information stability, etc. 70 | 71 | 2.信用历史（35%）如信用卡还款历史，微贷还款记录，水电煤缴费，罚单等（Credit History 35%）Such as credit card repayment history, loan repayment record, utilities payment, ticket, etc. 72 | 73 | 3.履约能力（20%）如支付账户余额，余额宝余额，车产信息，房产信息等（Performance Capability 20%）Such as payment account balance, saving account balance, vehicle information, property information, etc. 74 | 75 | 4.人脉关系（5%）如关系圈，朋友圈，信用水平，社交影响等 (Social Network 5%) Such as relationship network , friendship network, credit level, social influence, etc 76 | 77 | 5.行为偏好（25%）如账户活跃度,消费层次,缴费层次,消费偏好等 (Preferred Behavior 25%）Such as account activity level, consumption level, payment level, consumption preference, etc 78 | 79 | 芝麻分的分值范围为350至950，分值越高代表信用越好，相应违约率相对较低，较高的芝麻分可以帮助用户获得更高效、更优质的服务。 80 | 81 | Sesame scores range from 350 to 950. The higher the score, the better the credit, and the corresponding default rate is relatively low. The higher sesame score can help users get more efficient and better service. 82 | 83 | 84 | ### Model Design（模型设计） 85 | 元界数字身份的声誉系统的设计将基于目前元界区块链功能/数据的维度如充值记录、转账历史、MST数字货币存量、MIT数字资产存量、发币历史等并参考目前市场流行的信贷风险评估模型建立。 86 | 87 | The design of MARS will be based on Metaverse blockchain function/data dimensions such as recharge history, transaction history, MST digital currency stock, MIT digital asset stock, currency issue history, etc. Refer to the current popular credit risk assessment model established in the market. 88 | 89 | MARS模型的框架基于多维度的权重模型，根据元界区块链上不同的应用（包括公链在内）的所有数据维度以及对接的链外数据（如数字货币交易所、数字货币钱包等），每个数字身份或者应用都可以基各种数据建立应用（包括公链本身）的声誉模型。 90 | 91 | The framework of the MARS model is based on a multi-dimensional weight model, based on all data dimensions and interlinked out-of-chain data for different applications (including the public chain) on the Metaverse blockchain (such as digital currency exchange platform, digital currency wallets, etc.) Each digital identity or application can build a reputation model for the application (including the public chain ) based on various data. 92 | 93 | MARS系统旨在为元界区块链上各数字身份创建默认的声誉模型分数。MARS设计原则上允许各个数字身份可以基于自己的数据信息，包括元界区块链（基于元界区块链的数据维度及数据源）、链外数据等建立专属的MARS分数，如数字身份的用户可以使用数字货币交易所的数据API进行对接，将属于自己的交易所数据（如数字身份持有的所有 数字资产的总额、持币天数、持币地址、数量等信息）作为创建MARS分数的构成部分。 94 | 95 | The MARS system is designed to create reputational credit rating model for 96 | each digital identity on the Metaverse blockchain. In principle MARS allows 97 | individual digital identities to establish proprietary MARS scores based on 98 | their own data, including Metaverse Blockchain (data dimensions and data 99 | sources base on Metaverse blockchain), out-of-chain data such as digital 100 | identities. Users can use the data API of the digital currency exchange to 101 | connect, and the data of their own exchanges (such as the amount of all digital 102 | assets held by the digital identity, the number of days of holding assets, the 103 | position of the currency, the quantity, etc.), became the components of MARS 104 | score. 105 | 106 | 本MIP基于元界区块链及链外相关应用如（数字货币交易所）建立声誉评分体系为基准。 107 | 108 | This MIP is based on the establishment of a reputation scoring system based on the Metaverse blockchain and related applications, such as Digital Currency Exchange platform. 109 | 110 | ### Dimension Selection 维度选择 111 | 根据以上对目前市场的声誉信用评级模型结合元界区块链和数字身份的功能，以下维度将被选择为元界MARS的评级维度。 112 | 113 | Based on the above-mentioned reputational credit rating model for the current market combined with the function of the Metaverse blockchain and digital identity, the following dimensions will be selected as the rating dimension of the MARS 114 | 115 | *1.行为偏好（转账次数/月、充值次数/月、MIT发布资产数量/月、MST发币次数/月）占模型35%* 116 | 117 | Behavioral preference (number of transfers/month, number of refills/month, number of assets released by MIT/month, number of MST issue times/month) accounted for 35% of the model 118 | 119 | *2.履约能力（ETP账户地址资产量、MST资产量、MIT资产量）占模型30%* 120 | 121 | Performance capacity (ETP account address asset, MST asset, MIT asset) accounted for 30% of the model 122 | 123 | 3.信用历史（矿工费支付数量/次）20% 124 | 125 | Credit history (mining fee paid/time) 20% 126 | 127 | *4.人际关系（转账对象的数量）15%* 128 | 129 | Interpersonal relationship (number of transfer objects) 15% 130 | 131 | ### Model Construction （模型构建） 132 | 本模型将以元界数字身份在元界区块链的行为数据作为基础数据，采用层次分析法(Analytic Hierarchy Process, AHP)并结合评分卡方式计算元界MARS。首先定义分层的数字身份声誉评价指标体系，构造对比矩阵并经过一致性检验，获得组合指标权重，并引入需求列表、描述列表对本模型进行优化，实现对数字身份的声誉准确评价。 133 | 134 | This model will use the behavior data base of digital identity in Metaverse Blockchain as the basic data, and use the Analytic Hierarchy Process (AHP) combined with the scorecard method to calculate the MARS score. Firstly, a hierarchical digital identity reputation evaluation index system is defined. The comparison matrix is constructed and tested for consistency. The combined index weights are obtained, and the demand list and description list are introduced to optimize the model to achieve accurate evaluation of the digital identity. 135 | 136 | #### Analytic Hierarchy Process Introduction 层次分析法简介： 137 | 138 | 层次分析法(AHP)，也称层级分析法，是一种定性与定量结合的分析方法，多用于解决存在多目标以及不确定性和主观信息的复杂问题。 139 | 140 | Analytic Hierarchy Process (AHP), also known as hierarchical analysis, is a combination of qualitative and quantitative analysis methods, mostly used to solve complex problems with multiple objectives and uncertainty and subjective information. 141 | 142 | 层次分析法的基本步骤如下： 143 | 144 | The basic steps of the analytic hierarchy process are as follows: 145 | 146 | 1) 建立层次结构模型。在分析问题的基础上，将问题的各影响因素分为不同的层级，明确各级因素之间的相互作用，建立多层级的指标层，应注意层次分析结构中的每层元素个数一般不超过9个，因为同一层次中包含过多元素会给元素两两比较带来不便。 147 | 1) Establish hierarchical model. On the basis of analyzing the problems, the influencing factors of the problem are divided into different levels, the interaction between the various factors is clarified, and the multi-level index layer is established. It should be noted that the number of elements in each layer of the hierarchical analysis structure is generally not More than 9, because the inclusion of too many elements in the same level will bring inconvenience to the elements. 148 | 149 | 2) 构造因素对比判断矩阵。将处在同一层级且对同一上级指标有影响的各因素指标两两对比，依次构成对比矩阵，并将对比矩阵**A**表示: 150 | 2) Constructive factors compare judgment matrices. Compare the indicators of the factors at the same level and affect the same superior indicators, and then form a comparison matrix, and the comparison matrix **A** indicates: 151 | 152 | 153 | 154 | ![img](https://encrypted-tbn0.gstatic.com/images?q=tbn:ANd9GcSaMs4lSikwOu_TYPFzTZYn7XGuDNP99nFOqSEdXGfzhXBMA2Dfiw) 155 | 156 | 157 | 158 | 其中*a**ij*为因素*i*相对因素*j*而言的重要程度对比结果, *a**ij*的值越大表明因素*i*相对因素*j*而言越重要。 159 | 160 | Where a..ij is the comparison result of the importance degree of factor i relative to factor j. The larger the value of a..ij , the more important factor i is relative to factor j. 161 | 162 | 3) 计算权重向量。对每一对比矩阵进行计算，得出各矩阵的最大特征根及对应特征向量。对所得结果利用一致性指标进行一致性检验，若一致性检验通过，则将特征向量进行归一化计算后得出该组因素的权重向量；若一致性检验未通过，则返回步骤。 163 | 3）Calculate the weight vector. Each comparison matrix is calculated to obtain the largest eigenvalue and corresponding eigenvector of each matrix. The obtained result is consistently tested by the consistency index. If the consistency test is passed, the feature vector is normalized to obtain the weight vector of the group of factors; if the consistency test fails, the step is returned. 164 | 165 | 4) 计算各层次组合权重向量。同样对所得结果进行一致性检验，若检验通过，则可根据最终因素权重向量对结果进行决策，若检验未通过则重新构建对比矩阵或重新选择研究方法。 166 | 4) Calculate the combined weight vector for each level. The consistency test is also performed on the obtained results. If the test passes, the result can be determined according to the final factor weight vector. If the test fails, the comparison matrix is reconstructed or the research method is re-selected. 167 | 168 | #### MARS评价指标定义 MARS 169 | 170 | | Category | Factor 1 | Factor 2 | Factor 3 | Factor 4 | 171 | | :----------------------------------------- | :----------------------------------------------------------- | :-----------------------------------------: | :----------------------------------------------: | :-------------------------------------------------------: | 172 | | 行为偏好（Personal Behavior)（35%） | 转账次数/月(Transaction times/ month) | 充值次数/月(Deposit times/month) | MIT发布资产次数/月(MIT issue assets times/month) | MST发币次数/月(MST issue times/month) | 173 | | 履约能力（Capablility Performance）（30%） | ETP账户地址平均资产量/月 (ETP account address average assets) | MST平均资产量/月 (MST average assets/month) | MIT平均资产量/月 (MIT average assets/month) | 数字身份存在时间（天）(Duration of Digital Identity days) | 174 | | 信用历史（Credit History）(20%) | 矿工费支付平均数量/月(Mining average amount paid by miners/month) | | | | 175 | | 人际关系（Social Network）（15%） | 转账对象的数量/月（number of transfer objects/month) | | | | 176 | 177 | #### 构建MARS各因素判断矩阵 Construct MARS factor matrix 178 | 179 | **A**表示MARS分数，**B**表示影响**A**的所有一级指标：行为偏好**B**1，履约能力**B**2，信用历史**B**3，人际关系**B**4。将四个一级指标两两对比，使用3分位比率排定各指标的相对优劣等级，经专家打分，得出**A**相对于一级指标的判断矩阵： 180 | 181 | **A** represents the MARS score, and **B** represents all the primary indicators that affect A: B1 represents behavioral preference, B2 represents performance capability , B3 represents credit history, and B4 represents interpersonal relationship. Compare the four first-tier indicators in pairs, and use the 3-digit ratio to rank the relative merits of each indicator. After scoring by experts, the judgment matrix of A relative to the first-level indicators is obtained: 182 | 183 | 184 | 185 | ![img](https://latex.codecogs.com/gif.latex?A-B%3D%5Cbegin%7Bbmatrix%7D%201%20%26%200.5%20%26%202%20%26%202%5C%5C%202%20%26%201%20%26%204%20%26%202%5C%5C%200.5%20%26%200.25%20%26%201%20%26%203%5C%5C%200.33%20%26%200.5%20%26%200.2%20%26%201%20%5Cend%7Bbmatrix%7D) 186 | 187 | 其中A-B的最大特征值为 4.1725 188 | 189 | The maximum eigenvalue is 4.1725 190 | 191 | 192 | 193 | ![img](https://latex.codecogs.com/gif.latex?%5Clambda%20Max%20%3D%204.1725) 194 | 195 | 196 | 197 | 计算一致性指标*C.I*=(*λ*max-*n*)/(*n*-1)与平均随机一致性指标*R.I*。 198 | 199 | Calculate consistency index C.I*=(*λ*max-*n*)/(*n-1) and average Random consistency index R.I 200 | 201 | ![CI=\frac{\lambda_{max}(A)-n}{n-1}](https://wiki.mbalib.com/w/images/math/a/2/f/a2f76c2d18d4da97c14568579baa6a15.png) 202 | 203 | 根据以上模型最大特征值4.4527，CI =4.1725-4/(4-1) = 0.0575,RI=0.9。按下面公式计算成对比较阵 A 的随机一致性比率 CR，并规定*CR*=*CI*/*RI*，若*CR*＜0.1，则认为该判断矩阵具有满意一致性；若*CR*=0，则该判断矩阵具有完全一致性： 204 | 205 | According to the above model, the maximum eigenvalue is 4.4527, CI = 4.1725-4 / (4-1) = 0.0575, RI = 0.9. Calculate the random consistency ratio CR of the pairwise comparison matrix A according to the following formula, and specify CR=CI/RI. If CR<0.1, the judgment matrix is considered to have satisfactory consistency; if CR=0, the judgment matrix is complete. consistency: 206 | 207 | 208 | 209 | ![CR=\frac{CI}{RI}](https://wiki.mbalib.com/w/images/math/d/f/b/dfb18ca32123b073203bc41c6050bb0f.png) 210 | 211 | CR计算后得出为 0.06389小于0.1 212 | 213 | After CR calculation, it is 0.06389 less than 0.1. 214 | 215 | ![img](https://latex.codecogs.com/gif.latex?%5Csmall%20CR%3D0.0575/0.9%20%3D%200.06389) 216 | 217 | 因此以上矩阵具有满意一致性。 218 | 219 | Therefore the above matrix has satisfactory consistency. 220 | 221 | 由以上数据计算各B级权重可以得出4个一级指标的模型如下： 222 | 223 | Calculating the weights of each class B from the above data, the model of the four first-tier indicators can be obtained as follows: 224 | 225 | ![img](https://latex.codecogs.com/gif.latex?%5Csmall%20A%20%3D%200.258418168%20%5Ctimes%20B1%20+0.422866092%20%5Ctimes%20B2%20+%200.223179327%20%5Ctimes%20B3%20+%200.095536413%20%5Ctimes%20B4) 226 | 227 | 228 | 229 | **各B级分数则根据各以下分数进行加法运算：** B-level scores are added according to each of the following: 230 | 231 | #### MARS评分因素 MARS Scoring factors 232 | 233 | #### 1.转账次数/月、充值次数/月 Number of transfers/month, Number of refills/month 234 | 235 | | Times | Credit | 236 | | ----------- | -----: | 237 | | 0-10次 | 20分 | 238 | | 11-50次 | 50分 | 239 | | 51-200 | 70分 | 240 | | 200次或以上 | 100分 | 241 | 242 | #### 2.MIT发布资产次数/月、MST发币次数/月 Number of assets released by MIT/month, Number of MTS issue/month 243 | 244 | | Times | Credit | 245 | | --------- | -----: | 246 | | 0-1次 | 20分 | 247 | | 2-5次 | 50分 | 248 | | 5-8次 | 70分 | 249 | | 8次或以上 | 100分 | 250 | 251 | #### 3.ETP账户地址平均资产量、MST平均资产量/月 ETP account address average assets, MST average assets/ month 252 | 253 | | Amount | Credit | 254 | | -------------------------------- | -----: | 255 | | 约合0-5,000.00ETP | 20分 | 256 | | 约合5001.00-200,000.00ETP | 50分 | 257 | | 约合200,001.00-100,000,000.00ETP | 70分 | 258 | | 约合100,000,000.00ETP或以上 | 100分 | 259 | 260 | #### 4.MIT平均资产量/月 MIT Average assets/ month 261 | 262 | | Amount | Credit | 263 | | ----------- | -----: | 264 | | 0-10个 | 20分 | 265 | | 11-50个 | 50分 | 266 | | 51-200个 | 70分 | 267 | | 200个或以上 | 100分 | 268 | 269 | #### 5.矿工费支付平均数量/月 Mining average fee paid/ month 270 | 271 | | Amount | Credit | 272 | | ----------- | -----: | 273 | | 0-1ETP | 20分 | 274 | | 1-20ETP | 50分 | 275 | | 21-50ETP | 70分 | 276 | | 50ETP或以上 | 100分 | 277 | 278 | #### 6.转账对象的数量/月 Number of transfer objects/month 279 | 280 | | Amount of Unique Address | Credit | 281 | | ------------------------ | -----: | 282 | | 0-5个 | 20分 | 283 | | 5-20个 | 50分 | 284 | | 21-50个 | 70分 | 285 | | 50个或以上 | 100分 | 286 | 287 | #### 7.Avatar数字身份存在时长 Duration of Digital Identity Avatar 288 | 289 | | Period | Credit | 290 | | ------------------ | ------ | 291 | | 0-6 Months | 20分 | 292 | | 7-24 Months | 40分 | 293 | | 25-48 Months | 60分 | 294 | | 49-72months | 80分 | 295 | | 72months or longer | 100分 | 296 | 297 | MARS评分公式将引入基础分作为Avatar的底线分数，目前设定为200分，配合以上的B级指标的公式如下： 298 | 299 | The MARS scoring formula will introduce the base score as the bottom line score of Avatar, which is currently set to 200 points. The formula for the above B-level indicators is as follows: 300 | 301 | ![img](https://latex.codecogs.com/gif.latex?MARS%20%3D%20200%20+%20A) 302 | 303 | A公式为： 304 | 305 | A formula is: 306 | 307 | ![img](https://latex.codecogs.com/gif.latex?%5Csmall%20A%20%3D%200.258418168%20%5Ctimes%20B1%20+0.422866092%20%5Ctimes%20B2%20+%200.223179327%20%5Ctimes%20B3%20+%200.095536413%20%5Ctimes%20B4) 308 | 309 | 310 | 311 | ## 数据对接及展示 Other Data Source and display 312 | 通过对接其他链外的API数据作为MARS模型的数据源。 313 | 314 | By getting other API out-of-chain as a data source for the MARS model. 315 | 316 | 317 | ## Presentation of MARS 318 | 本MARS系统将根据MIP以上所以提及在区块链上的数据和维度及计算出来的MARS总分数，以仪表盘、KPI能力值等可视化的模块呈现给每一个Avatar用户，用户可以在MVS全节点、轻钱包的数字身份功能内查看MARS的分数（仪表盘）及各能力值（KPI能力值模块）的分布。而MARS的分数将以自动化的方式每月1日更新，若数字身份的创建时间不为每月的1日，则以当时所记录的数据即时计算。 319 | 320 | The MARS system refer to the data and dimensions on the blockchain and the calculated MARS total score based on the MIP. The visualized modules such as the dashboard and KPI capability values are presented to each Avatar user. The user can be in the MVS. View the MARS score (dashboard) and the distribution of each capability value (KPI capability value module) within the digital identity function of the node and light wallet. The MARS score will be updated on the 1st of every month in an automated manner. If the digital identity is not created on the 1st of each month, the data recorded at that time will be calculated immediately. 321 | 322 | ## Rationale 323 | To be written. 324 | 325 | ## Backwards Compatibility 326 | The main function of the The Metaverse Avatar Reputation System (MAR) is to reflect the MVS Avatar Data 327 | 328 | ## Test Cases 329 | To be written. 330 | 331 | ## Implementation 332 | 对于具体项目，将根据元界区块链及其他链外数据进行计算并形成仪表盘形式显示数字身份的声誉系统分数 333 | 334 | For specific projects , calculate reputation system score and display in dashboard form for digital identity based on Metaverse blockchain and other out-of-chain data 335 | -------------------------------------------------------------------------------- /mips/mip-2.md: -------------------------------------------------------------------------------- 1 | ## Preamble 2 | 3 | ``` 4 | MIP: 2 5 | Title: Adjust reward rate of deposit function 6 | Author: Chen Hao 7 | Type: Standard Track 8 | Category: Core/ECO 9 | Status: Draft 10 | Created: 2018-01-24 11 | ``` 12 | 13 | ## Simple Summary 14 | Because of deposit function for, users can get more ETP bonus from MVS ecosystem, which is bad inflation. 15 | Need to change inflation rate by adjusting reward rate. If Metaverse use the current reward rate, there are few problems: 16 | * The inflation rate is a little bit high 17 | * If large amount ETP deposit expire, they may have an impact on ETP price 18 | 19 | Refers to current reward rate: 20 | ![etprate](https://user-images.githubusercontent.com/15893135/33869224-9582fadc-df42-11e7-88d5-9a7997d1134c.png) 21 | 22 | Refers to [issue 1](https://github.com/mvs-org/mips/issues/1). 23 | 24 | ## Specification 25 | Fix a relative lower bonus rewards each block. 26 | 27 | ### ETP Total Amount and its Distribution 28 | ETP Total Amount and its Distribution 29 | 30 | | Holders | Amount | 31 | | --------------------------------- | ----------------- | 32 | | Initial Holdings of Foundation | 25,000,000 | 33 | | ICO Investors | 25,000,000 | 34 | | Mining and Coinbase Rewards | 30,000,000 | 35 | | Interest Rewards for Deposit | 20,000,000 | 36 | 37 | We can query this API to query the total interest rewards generated in real time. Presently, the coinlock interest reward we have designed is always greater than 1. As such, if we consider the deposit function in isolation, it is an inflationary mechanism with the maximum annualized income being 20%. 38 | In other words, we will inevitably exceed the 100 million ## Analysis Process 39 | The following are calculations are predominantly based on estimates because the results will be referenced in other sections. 40 | 41 | ### Analysis Process 42 | The following are calculations are predominantly based on estimates because the results will be referenced in other sections. 43 | 44 | According to our data, deposits have followed a roughly U-shaped distribution. 1-year deposits make up the majority, with middle-duration deposits being the least common. We will assume that the average yield of deposits across the entire network is 13%. 45 | 46 | Based on previous statistics, over 10 million ETP have been deposited at some point of time, reference [API 1](https://explorer.mvs.org/api/depositsum). At the moment, interest rewards across the entire network total about 1.44 million ETP, reference [API 2](https://explorer.mvs.org/api/rewards). From these figures, we can calculate that the observed average yield of deposits across the entire network is 14.19%, which is in line with our estimations. 47 | 48 | 10 million ETP makes up about 17.94% of the circulating supply, hence we assume that 17.94% of each year’s circulating supply will be deposited. ETP cap at some point in time in the future. 49 | 50 | bout 1 million new blocks will be generated each year, which means that 2.85 million ETP will be added to the circulating supply in a linear fashion. Taking into account the availability of ETP, we take half the ETP mined = 1.425 million ETP. 51 | Hence, we estimate that an additional 1.425m * 17.94% = 250,000 ETP will be deposited each year on top of the baseline amount, **and further estimate that it will take about 14 years for the total supply of ETP to reach 100 million** . 52 | Even if deposits across the entire network double to 35.88%, **it would require over 7 years for the total supply of ETP to reach 100 million**. We conclude that with no change in the consensus mechanism, the total supply of ETP will exceed 100 million in **2032**. In the extreme case, we will reach 100 million in **2025**. 53 | Thus, we have sufficient time to adjust the deposit function. 54 | 55 | 56 | ### Solution 57 | Suppose that use the same decay model as found in the mining reward mechanism. 58 | Assumptions: 59 | 1. The amount decays once every N blocks. Let the number of decayals be n. 60 | 2. Let the decay factor be m. 61 | 3. Let the current total interest be s. 62 | 4. Each block generates a fixed amount of ETP b. 63 | Then we have: 64 | ![image](https://camo.githubusercontent.com/60a78ca46d34376fbd5d6efe359619b7f7d8142c/68747470733a2f2f6c617465782e636f6465636f67732e636f6d2f6769662e6c617465783f5c6c696d5f7b6e5c72696768746172726f772b5c696e6674797d2673706163653b5c73756d5f305e6e7b6d5e6e7d2a4e2a622673706163653b3d2673706163653b32303030303030302673706163653b2d2673706163653b73) 65 | 66 | introduce the attenuation coefficient 0.95 and the attenuation height interval 500,000, assuming the total interest is 1.5 million when the main network activates MIP002: 67 | Let the decay factor = 0.95 and N = 500,000. Assuming that the current total interest s = 1.5 million when MIP 002 is activated, we have: 68 | ![image](https://camo.githubusercontent.com/f0e4b52bef5b6f9aafdbe967be1b7ac643fd72dc/68747470733a2f2f6c617465782e636f6465636f67732e636f6d2f6769662e6c617465783f5c6c696d5f7b6e5c72696768746172726f772b5c696e6674797d2673706163653b5c73756d5f305e6e7b302e39355e6e7d2a3530303030302a622673706163653b3d2673706163653b32303030303030302673706163653b2d2673706163653b31353030303030) 69 | 70 | We can calculate b = 1.85. 71 | 72 | Assuming that the above solutions are implemented, 73 | Let us assume that 1.85 ETP is generated each block as interest. Then, how should this 1.85 ETP be allocated? We have four options: 74 | 1. Allocate it proportionately according to the value of deposit-generating transactions in the current block 75 | 2. Allocate it proportionately according to the coin age of deposit-generating transactions in the current block 76 | 3. Randomly select one depositor from the higher-value deposit-generating transactions in the current block. 77 | 4. Randomly select one depositor from the higher-coin-age deposit-generating transactions in the current block. 78 | Like PoS, options 3 and 4 can be categorized as game-theoretic systems. For increased system stability, we need to provide a proof under situations 3 or 4. 79 | 80 | Meanwhile, we are considering the possibility of designing a hybrid PoW/PoS system for Metaverse that would enable simultaneous PoW and PoS mining. With regards to this, we have analyzed [TwinsCoin](https://eprint.iacr.org/2017/232.pdf), [Hcash](https://h.cash/themes/zh-cn/dist/pdf/HcashWhitepaper-Rev0.8.1.pdf) and other mixed-mining tokens. 81 | 82 | ### Mixed Mining Coin List 83 | | Coin | Conclusion | 84 | | --------------------------------- | ----------------- | 85 | | ETH | To be studied | 86 | |Hcash | Not many documents, code-based, requires further analysis | 87 | | nevacoin | Altcoin based on BTC, fairly old code | 88 | | steepcoin.net | Open-source with white paper. Can refer to their model | 89 | |TwinsCoin | Open-source with white paper. Can refer to their model | 90 | | emercoin| Has white paper, can refer to their model | 91 | | byzcoin | To be studied | 92 | 93 | TODO... 94 | 95 | ## Rationale 96 | To be written. 97 | 98 | ## Backwards Compatibility 99 | Existed deposit transactions is valid always, however, if this MIP done, system DO NOT accept old type deposit transaction any more. 100 | 101 | ## Test Cases 102 | Test cases for an implementation are mandatory for MIPs that are affecting consensus changes. Other MIPs can choose to include links to test cases if applicable. 103 | 104 | ## Implementation 105 | The implementations must be completed before any MIP is given status "Final", but it need not be completed before the MIP is accepted. While there is merit to the approach of reaching consensus on the specification and rationale before writing code, the principle of "rough consensus and running code" is still useful when it comes to resolving many discussions of API details. 106 | 107 | -------------------------------------------------------------------------------- /mips/mip-3.md: -------------------------------------------------------------------------------- 1 | ## Preamble 2 | 3 | ``` 4 | MIP: 3 5 | Title: Digital Assets Secondary Issue (Secondary offering) 6 | Author: Hao Chen 7 | Type: Standard Track 8 | Category: ECO 9 | Status: Final 10 | Created: 2018-03-29 11 | ``` 12 | 13 | ## Simple Summary 14 | To provide asset secondary issue functions for Metaverse Smart Token (MST), not including ETP.  15 | 16 | ## Abstract 17 | Digital Assets Secondary Issue（DASI）could be compared to secondary offering tools in the field of securities.  18 | 19 | ## Motivation 20 | Under lots of user cases, it is apparent that users can't determine the upper issuance limit of MST. Thus, single issuance has a higher opportunity cost.  21 | 22 | For example, the total number of the first MST issuance is 1 billion which can't meet the market demand and it is hoped to issue another half biliion tokens. In order to lower the opportunity cost, we propose Secondary Issue function.  23 | 24 | ## Specification 25 | There are preconditions for DASI. Firstly, assets creation should be based on MIP-004 asset creation function, and the necessary conditions for assets issuance need to be spedified when the asset is created.  26 | 27 | If the following two conditions are satisfied, the asset could be secondarily issued.  28 | 1. One has the right of issuance. Asset issuance rights are defined in MIP-004 and could be transferred to others.  29 | 2. Target asset holdings of the account equals or exceeds the minimum required threshold; 30 | 31 | All network consensus verification is required, which involves the change of consensus agreement. 32 | 33 | ## Rationale 34 | TODO... 35 | 36 | ## Backwards Compatibility 37 | New function, no need of compatiblity requirment. 38 | 39 | ## Test Cases 40 | 1. Repeated addtional issuance 41 | 2. Secondary issue non-existent assets 42 | 3. Conduct secondary issuance when users have no issuance right 43 | 4. Conduct secondary issuance when the asset holding is lower than minimum required threshold 44 | 45 | ## Implementation 46 | It is recomended to add secondaryissue（additionalissue）API. 47 | Currently, there is no product-benchmarkeing in the market. 48 | -------------------------------------------------------------------------------- /mips/mip-4.md: -------------------------------------------------------------------------------- 1 | ## Preamble 2 | 3 | ``` 4 | MIP: 4 5 | Title: Digital Assets - Issuance Right and the Extensions of Other Rights  6 | Author: Hao Chen 7 | Type: Standard Track 8 | Category: ECO 9 | Status: Final 10 | Created: 2018-04-10 11 | ``` 12 | 13 | ## Simple Summary 14 | To provide Metaverse Smart Token (MST) with transferrable issuance right.  15 | 16 | ## Abstract 17 | The issuance right refers to the right to conduct initial issuance and secondary issuance, and is defined at underlying technology of blockchian as a part of Metaverse MST infrastructure.  18 | 19 | ## Motivation 20 | The transferability is a necessary feature of Digital Asset.  21 | 22 | ## Specification 23 | The distribution of rights and obligations 24 | 25 | By default, the first issuer will have the issuance right and is only owned by him. 26 | 27 | At the time of first issuance, the issuer could specify the minimum issuance threshold percentage for asset holdings. 28 | 29 | The definable range of the threshold: 30 | - -1   No threshold requirement. That is, if one gets the issuance right, he can conduct additional issuance without limitation of times. 31 | - 0   Never be able to conduct additional issuance. Even if one has the issuance right, he cannot use it. 32 | - 1~100 Asset holdings accounting for the percentage of issued shares. The amount of asset holdings for the account with issuance rights must exceed the threshold percentage. 33 | 34 | 35 | Each asset has only one issuance right which can be transferred separately and the asset holdings will not be affected. After the transfer, the original issuer no longer has the right of secondary issuance, while the receiving account gets it.  36 | 37 | ## Rationale 38 | 39 | To be written. 40 | 41 | ## Test Cases 42 | 43 | To be written. 44 | 45 | ## Implementation 46 | add new type `asset certificate` in output attachment; 47 | 48 | -------------------------------------------------------------------------------- /mips/mip-8.md: -------------------------------------------------------------------------------- 1 | ## Preamble 2 | 3 | ``` 4 | MIP: 8 5 | Title: Digital Aseets Lock-Unlock Model on block height 6 | Author: Frank Su 7 | Type: Standard Track 8 | Category: ECO 9 | Status: Draft 10 | Created: 2018-04-11 11 | ``` 12 | 13 | ## Simple Summary 14 | In fact, the Digital Aseets Lock-Unlock model is the function combinated by MIP-3(Digital Assets Secondary Issue), MIP-7 Digital Aseets - Lock), and MIP-8(Digital Aseets - Unlock). We decide to list a series of adjustable parameters for user to adjust by themselves, like Issue/issuance quantit, Freeze quantity, Release period, etc. 15 | ## Motivation 16 | Customized asset locks and batch unlocks requirements, allowing users more flexibility to set their own assets. 17 | 18 | ## Abstract 19 | At the present stage, the following 3 models are set up for users to choose. 20 | 1. Quantitative Release Model 21 | 1. Fixed Inflation rate Release Model 22 | 1. No Lock Model 23 | 24 | These models can be choosen in below function： 25 | 1. Issue 26 | 2. Secondaryissue 27 | 3. Swap 28 | 29 | ## Specification 30 | First of all, in order to facilitate the description of subsequent calculation formulas, we define the following parameters in a unified way： 31 | IQ：Total issue/secondaryissue quantity at this time, must >0 32 | LQ：Total lock quantity at this time, must >=0 33 | LP：Total lock period, in Day units, must >0 and be the integer number 34 | UC：Unlock period, in Day units, defines the unlock interval. For example, UC = 30 meant that parts of assest will be unlocked every 30 days, must >0 and be the integer number 35 | UP_t: Unlock Percentage in period t 36 | UQ_t: Quantity of Unlocks in period t 37 | IR_t: Inflation Rate in period t 38 | 39 | Following limiting logic will be added below： 40 | 1. IQ and LQ are required parameters and must be filled in by users while asseets issuing or secondaryissuing 41 | 2. When LQ > 0, LP/UC is required. UP_t, UQ_t, IR_t are dynamically calculated and recorded according to the selected model background. 42 | 43 | ### Quantitative Release Model 44 | 45 | #### Summary： 46 | This model unlock Token with a fixed quantity release model for each period. At the same time, the market's inflation rate will also theoretically change from 100% to 0%. 47 | 48 | #### Model Logic： 49 | After choosing this model, the IQ/ LQ/ LP/ UC must be filled and greater than 0. The background automatically calculates and saves the UP_t (UQ_t) data according to the following formula. In this mode, UP_1=UP_2=... =UP_t (UQ_t). Thus, Thus,only UP_1 (UQ_1) stored in the background is enough: 50 | ![p3](https://images-cdn.shimo.im/UTC37744UJoVHLCn/image.png) 51 | 52 | For example, user issued and locked all 20 million A-Token on 1st Dec 2017. The total lock period is 360 days and will be released each 30 days. Then, the program can get the data as below: 53 | ![p3](https://images-cdn.shimo.im/UgM92otoER0pgWlo/image.png) 54 | 55 | The subsequent unlocking program will unlock the A-Token according to the same UQ=1666666.67 every 30 days, and the last issue will unlock all remained lock A-TOKEN as the LQ cannot be divied by the whole release period(LP/UC = 12). 56 | 57 | ### Fixed Inflation rate Release Model 58 | 59 | #### Summary： 60 | This model unlock Token with a Inflation rate release model for each period and dynamically adjust the Quantity of unlocks per period. 61 | 62 | #### Model Logic： 63 | After choosing this model, the IQ/ LQ/ LP/ UC/ IR_t must be filled and greater than 0. The background automatically calculates and saves the UP_t (UQ_t) data according to the following formula. In this mode, IR_1= IR_2=…= IR_t. Thus,only IR_1 stored in the background is enough: 64 | ![p1](https://images-cdn.shimo.im/1mIR9hf3CgwAJfM9/image.png) 65 | 66 | For example, user issued and locked all 20 million A-Token on 1st Dec 2017. The total lock period is 360 days and will be released each 30 days. Also, he hopes that each unlock will only bring 8% IR for his token. Then, the program can get the data as below: 67 | ![p2](https://images-cdn.shimo.im/5tueFZsDKkkgI56z/image.png) 68 | 69 | The subsequent unlocking program will unlock the A-Token according to the each UQ_t every 30 days, and the last issue will unlock all remained lock A-TOKEN as the LQ cannot be divied by the whole release period(LP/UC = 12). 70 | 71 | ### No Lock Model 72 | 73 | #### Summary： 74 | This model provides a normal Token mode without any locking. 75 | 76 | #### Model Logic： 77 | After choosing this model, IQ must be filled and greater than 0, while LQ is 0. In fact, there is no requirement for asset lock and unlock. 78 | 79 | For example, user issued all 20 million A-Token on 1st Dec 2017 without any locking. It means that all these 20 million Token can be directlly circulated on the chain. Then, the program can get the data as below: 80 | ![p5](https://images-cdn.shimo.im/uU97rtk6NQYUr1dR/image.png) 81 | 82 | ## Rationale 83 | To be written. 84 | 85 | ## Backwards Compatibility 86 | New functions, no compatibility requirements. 87 | 88 | ## Test Cases 89 | To be written. 90 | 91 | ## Implementation 92 | To be written. 93 | 94 | ## Copyright 95 | To be written. 96 | 97 | 98 | --------------------------------------------------------------------------------