-
Notifications
You must be signed in to change notification settings - Fork 58
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Merge pull request #1 from filecoin-project/notary-content
Notary content
- Loading branch information
Showing
12 changed files
with
418 additions
and
1 deletion.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,136 @@ | ||
--- | ||
name: Notary Application | ||
about: Application form for Notaries to recieve DataCap (both new and existing) | ||
title: '' | ||
labels: request | ||
assignees: '' | ||
|
||
--- | ||
# Notary Application | ||
### PLEASE NOTE ANY APPLICATION SUBMITTED BEFORE THE FINALIZATION OF THE GOVERNING FIP OR THIS REPO WILL BE DISCARDED | ||
|
||
To apply as a notary, please fill out the following form. | ||
|
||
## Core Information | ||
- Name: | ||
- (Optional) Affiliated Organization: | ||
- Website / Social Media: | ||
- On-chain Address(es) to be Notarized: | ||
- Region of Operation: [North America, South America, Europe, Africa, Greater China, Asia-GCN, Oceania] | ||
- Use case(s) to be supported: [Please select from [here](/notaries/templates/README.md#definitions)] | ||
- DataCap Requested: | ||
|
||
_Please respond to the questions below in pargraph form, replacing the text saying "Please answer here". Include as much detail as you can in your answer!_ | ||
|
||
## Long Term Network Alignment | ||
### Time Commitment | ||
Describe the nature and duration of your affiliation with the Filecoin project. Please include relevant Github handles, miner ids, significant projects or contributions (with links). | ||
``` | ||
Please answer here. | ||
``` | ||
|
||
### Stake Exposure | ||
Please cite total token at stake (currently available, locked as collateral, vesting over time) and any substantiating evidence. | ||
``` | ||
Please answer here. | ||
``` | ||
|
||
## Industry Reputation | ||
### In-protocol Reputation | ||
Please describe (in detail) your activity and tenure as a member of the Filecoin community. Please note (with links where possible) any contributions made to implementations of Filecoin, the spec, documentation, or to substantially help the Filecoin ecosystem grow. | ||
``` | ||
Please answer here. | ||
``` | ||
|
||
### In-protocol Security | ||
Please describe your contributions to the security of Filecoin and the duration over which you've made contributions. Please also include any links or references who might be able to substantiate your contributions (e.g. if you've filed several bugs, please cite who you've communicated with on the Filecoin side). | ||
``` | ||
Please answer here. | ||
``` | ||
|
||
### External Reputation | ||
Please describe the nature of your organization, including the country of registration, size of the organization, and time since inception. | ||
``` | ||
Please answer here. | ||
``` | ||
|
||
Please share any relevant details to help substantiate information about your organization (website, named officers, links to social media profiles). | ||
``` | ||
Please answer here. | ||
``` | ||
|
||
Please share any relevant external information regarding your organization (e.g. news articles, social media profiles, etc.) | ||
``` | ||
Please answer here. | ||
``` | ||
|
||
|
||
## Diversity and Decentralization | ||
### Use Case Diversity | ||
(Optional) Any additional information you'd like to share about the use case(s) you plan to support? | ||
``` | ||
Please answer here. | ||
``` | ||
|
||
|
||
# Allocation Plan | ||
## Concreteness of Allocation Plan | ||
### Allocation Strategy | ||
How do you plan on allocating the DataCap requested above? Please describe your allocation strategy with as much specificity as you can. | ||
``` | ||
Please answer here. | ||
``` | ||
|
||
Are there any internal processes you plan on impelementing regarding the target, amount, or rate at which you'll allocate DataCap? | ||
``` | ||
Please answer here. | ||
``` | ||
|
||
How do you plan on securing the DataCap to ensure your organization (and its delegated members) are the ones allocating the DataCap? | ||
``` | ||
Please answer here. | ||
``` | ||
|
||
### Client Due Diligence | ||
How will you vet your Client to ensure they are spending that DataCap responsibly? | ||
``` | ||
Please answer here. | ||
``` | ||
|
||
What questions will you ask to ensure the Client can properly handle the DataCap you intend to allocate to them? | ||
``` | ||
Please answer here. | ||
``` | ||
|
||
What processes will you employ to confirm that a Client is not improperly over-allocating DataCap to a single entity? | ||
``` | ||
Please answer here. | ||
``` | ||
|
||
### Bookkeeping Plan | ||
Do you plan on keeping records of your allocation decisions? If so, with what level of specificity do you intend to respond to any audit requests? | ||
``` | ||
Please answer here. | ||
``` | ||
|
||
Do you plan on conduct your allocation decisions in public (e.g. Github repo), private (e.g. over email, Telegram, etc), or both? | ||
``` | ||
Please answer here. | ||
``` | ||
|
||
## Track Record | ||
### Past allocation | ||
Have you previously received DataCap to allocate before? If so, please link to any previous applications. | ||
``` | ||
Please answer here. | ||
``` | ||
|
||
Cumulatively, how much DataCap have you previously successfully allocated? | ||
``` | ||
Please answer here. | ||
``` | ||
|
||
Have there been (or are there still) any disputes raised against you from your previous DataCap allocations? | ||
``` | ||
Please answer here. | ||
``` |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -1 +1,38 @@ | ||
# fil-name-governance | ||
# Notary Governance | ||
⚠️⚠️⚠️ ***This is still Work In Progress but one can follow the repository for the latest discussion and changes. Please do not file any applications prior to the confirmation of the governing FIP and this repository.*** | ||
|
||
The purpose of this repository is to manage the governance and evolution of specific Mechanisms and Operations of the program as insantiated in this [FIP]() and illustrated in the following diagram. | ||
|
||
<img src="images/governance-layers.jpg" alt="governance-layers" width="70%" height="70%"> | ||
|
||
Within this repository, you will find: | ||
- Increased specification, governance, and evolution for Mechanisms and Operations layers. | ||
- Information on Root Key Holders, available actions, roles and responsibility. | ||
- Information on how to become a Notary, selection rubric, recommended guidelines, active Notaries. | ||
- Information on how to file a Dispute, and the steps for how disputes are resolved. | ||
|
||
## Overview | ||
- Principles | ||
- Decentralization and Diversity | ||
- Tranparency and Accountability | ||
- Community Governance | ||
- Low-Cost Dispute Resolution | ||
- Limited Trust Earned over Time | ||
- Terms of Service | ||
- A Useful Storage Network | ||
- Roles & Responsibilities | ||
- [Root Key Holders](https://github.com/filecoin-project/notary-governance/tree/main/root-key-holders#overview) | ||
- [Notaries](https://github.com/filecoin-project/notary-governance/tree/main/notaries#overview) | ||
- Clients | ||
- Interaction Diagram | ||
|
||
<img src="images/interaction-diagram.jpg" alt="interaction-diagram" width="70%" height="70%"> | ||
|
||
## Dispute / Audit Framework | ||
TBD | ||
|
||
## Governance and Iteration Process | ||
Within this repository are the governing documents, selection criteria, and processes for Notaries and Root Key Holders. Improvements to these documents and processes may be proposed via Pull Requests - where open discussion can happen asynchronously via the community. Similar to a FIP, any proposed changes must be done within the constraints of improving the Mechanisms and Operations to better meet the overarching Principles. | ||
|
||
On a regular cadence (tbd), a call will be scheduled for open decisioning of proposed changes with the final accepted changes to be merged by the editors of this repository. | ||
|
Loading
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
Loading
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,24 @@ | ||
# Overview | ||
Notaries are selected to act as [fiduciaries](https://www.merriam-webster.com/dictionary/fiduciary) for the Filecoin network. Notaries are entrusted to uphold the [Principles]() of the program - responsibly allocating DataCap to help foster legitimate use cases on Filecoin. This document aims to provide additional specificity to the role/responsibility of Notaries, define the application and selection process, and the process for making changes. | ||
|
||
## Roles & Responsibilities | ||
The base responsibilities of the Notaries are as follows: | ||
- Allocate DataCap to clients in order to subsidize reliable and useful storage on the network. | ||
- Verify that clients receive a DataCap commensurate with the level of trust that is warranted based on information provided. | ||
- Ensure that in the allocation of the DataCap no party is given excessive trust in any form that might jeopardize the network. | ||
- Follow operational guidelines, keep record of decision flow, and respond to any requests for audits of their allocation decisions. | ||
|
||
**Note:** Notaries are given autonomy in their decision making process and encouraged to allocate DataCap based on their best judgement. However, Notaries should expect to answer any questions about previous allocation decisions before receiving future DataCap to distribute. Guidelines for reasonable allocation strategies are supplied in this repository (both a [recommended scoring mechanism for prospective Clients](), as well as a [sample set of questions to ask of Clients]()). While not mandatory to use, these documents represent the expected baseline for well-behaved Notaries. | ||
|
||
## Restrictions | ||
As stated above, Notaries are given a high degree of autonomy in their decision making power. To start, we aim to have a minimal set of constraints to ensure this mechanism is used fairly. This list may be expanded or removed entirely as this Mechanism stabalizes. | ||
|
||
* **No self dealing**: To prevent conflicts of interest, Notaries should not allocate DataCap to clients over which they control the private keys. In the event this is an issue, the Notary should contact another Notary (in the same geography or aligned to the same use case) to handle the allocation for that specific client. | ||
|
||
## Application / Selection Process | ||
For those interested in providing this service to the Filecoin network, they may apply to this role by filing an Issue [here](). | ||
|
||
Please note, applications are reviewed on a ***regular cadence (tbd)*** basis - and will be graded according to this community defined [criteria](). Edits to the criteria, will follow the same process as any proposed change to this repository, defined [here](/README.md#process-for-modifications). | ||
|
||
## Removal Process | ||
Notaries that have consistent and substantive issues raised against them and have been found to be legitimately abusing their power will be made ineligible for DataCap allocations. The process for raising and resolving disputes can be found [here](). |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1 @@ | ||
|
1 change: 1 addition & 0 deletions
1
notaries/active-notaries/notary-1/notary-1-sample-client-application.md
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1 @@ | ||
|
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,68 @@ | ||
# Overview | ||
How to use these rubrics: | ||
- Once a prospective Notary has filed an issue to apply, their application will be publicly graded on the below criteria. | ||
- First, the applicant will be checked to see none of the criteria for [Automatic Disqualification](/notaries/templates#automatic-disqualification). | ||
- Next, the applicant will be ranked based on their merits as a Notary. Note, per row the applicant can get a score 1-5. If an applicant does not provide evidence, they will get a 0 for that row. Definitions for terms used in the criteria can be found below the rubrics. | ||
- Once the applicant has been ranked as a Notary, the outputs are fed into the [Allocation Rubric](/notaries/templates#notary-allocation-plan-rubric). This considers the merits of the applicant as a Notary along with their previous track record, and the robustness of their plan to determine the [final allocation amount](/notaries/templates#final-allocation-amount). | ||
|
||
All scoring decisions should happen in public on the issue as filed, and iteration (e.g. improvements to an allocation plan) may be made within the issue. Editors of the repo will be able to assign the final score based on the merits of the application. On a regular cadence, review of open applications can occur where scoring decisions can be reviewed. When a final score is determined, a label will be set such that Root Key Holders can be made aware action is required. | ||
|
||
## Notary Rubric | ||
|
||
| Category | Combination Logic | L1 | L2 | L3 | L4 | L5 | | ||
|-|-|-|-|-|-|-| | ||
| **Long Term Network Alignment** | Max(Time Commitment, Stake Exposure)| | ||
|Time Commitment| |Substantial, sustained contributions to Filecoin min. 6 mos | Substantial, sustained contributions to Filecoin min. 1 year | Substantial, sustained contributions to Filecoin min. 2 years | Substantial, sustained contributions to Filecoin min. 3 years | Substantial, sustained contributions to Filecoin min. 4 years | | ||
|Stake Exposure||100k tokens at stake|100-500k tokens at stake|1MM tokens at stake|5MM tokens at stake|10MM tokens at stake| | ||
|**Industry Reputation**| Max(In-protocol Reputation, In-protocol Security, External Reputation)| | ||
|In-protocol Reputation|| Reputable leader in Filecoin Ecosystem for 1 year |Reputable leader in Filecoin Ecosystem for 2 years |Reputable leader in Filecoin Ecosystem for 3 years |Reputable leader in Filecoin Ecosystem for 4 years|Reputable leader in Filecoin Ecosystem for 4+ years| | ||
|In-protocol Security|| Contributions in identifying, responsibly disclosing, and fixing security vulnerabilities in protocols or services in the Filecoin community | Sustained contributions for 2+ years in identifying, responsibly disclosing, and fixing **serious** protocol or service vulnerabilities, in the Filecoin community | Sustained contributions for 2+ years in identifying, responsibly disclosing, and fixing **major** protocol or service vulnerabilities, in the Filecoin community | Sustained contributions for 3+ years in identifying, responsibly disclosing, and fixing **major** protocol or service vulnerabilities, in the Filecoin community | Sustained contributions for 4+ years in identifying, responsibly disclosing, and fixing **major** protocol or service vulnerabilities, in the Filecoin community| | ||
|External Reputation||Registered organization with a strong reputation outside of Filecoin for over 2 years |-| Registered organization with a substantial and global reputation outside of Filecoin for over 5 years|-|Company with substantial reputational risk (i.e. publicly traded company) whose reputation and reach exceed Filecoin| | ||
|**Diversity and Decentralization**| 0.7*(Geographic Distribution) + 0.3*(Use Case Diversity)| | ||
|Geographic Distribution||>=4 existing Notaries or >=30% global DataCap has been allocated to the Region|3 existing Notaries or 20-30% global DataCap has been allocated to the Region|2 existing Notaries or 10-20% global DataCap has been allocated to the Region|1 existing Notary or <10% global DataCap has been allocated to the Region|Unrepresented geography| | ||
|Use Case Diversity||Highly represented use case (4+ existing)|Highly represented use case (3 existing)|Somewhat represented use case (2 existing)|Under-represented use case (1 existing)|Unrepresented use case| | ||
|
||
### Definitions | ||
**Stake**: Stake, or tokens at stake, is defined as the sum of all locked, unvested, and liquid tokens at the time of application and should be roughly maintained over the course of the applicant's position as a Notary. | ||
|
||
**Substantial, sustained contributions**: Participation as a miner, active work as a developer (building ecosystem tooling, client applications, protocol improvements, etc) with significant impact, or active community advocate substantially increasing the reach and adoption of Filecoin. | ||
|
||
**Reputable leader**: Contributions to the Filecoin protocol and/or spec, creating and maintaining widely adopted services inside the commmunity, and cultivating the success of other members in the Filecoin ecosystem. | ||
|
||
**Registered Organization**: A registered organization must be a government recognized entity with a minimum of the following: | ||
- Website | ||
- Named officers | ||
- Social media presence | ||
|
||
**Geographies**: [North America, South America, Europe, Africa, Greater China, Asia-GCN, Oceania] | ||
|
||
**Sample Use cases**: | ||
- Professional Services (Hosting Reseller, Digital Preservation, Long-term Backups, Long-term Log Storage) | ||
- Developer Tools (Package Managers, Automatic Notaries) | ||
- Decentralized Applications | ||
- Web 2.0 Applications | ||
- User Content (Personal Storage, User Generated Media) | ||
- Scientific Data (Satellite Imagery, Geological Data, Computer Vision, Autonomous Driving) | ||
- Media & Entertainment | ||
- Other | ||
|
||
## Notary Allocation Plan Rubric | ||
| Category | Combination Logic | L1 = Eligible up to 10TB | L2 = Eligible up to 100TB | L3 = Eligible up to 1PB | L4 = Eligible up to 10PB | L5 = Eligible up to 50PB | | ||
|-|-|-|-|-|-|-| | ||
|**Weighted Notary Level**| Floor(0.3*(Long Term Network Alignment) + 0.4*(Industry Reputation) + 0.3*(Diversity and Decentralization))| | ||
|**Concreteness of Allocation Plan**|Floor(0.4*(Allocation Strategy)+0.4*(Client Due Diligence) + 0.2*(Bookkeeping Plan))| | ||
|Allocation Strategy||Minimal specificity in allocation strategy but demonstrates how allocation will reflect the Principles|Moderate specificity in allocation strategy in alignment with the Principles|Detailed plan, including tooling, to successfully allocate DataCap in a way that reflects the goals and values of the Principles|Detailed and convincing plan, including tooling, to successfully allocate DataCap in a way that reflects the goals and values of the Principles|L4 Requirements| | ||
|Client Due Diligence||Minimal due diligence protecting against abuse and vetting clients|Base due diligence protecting against abuse and vetting clients |Robust due diligence for protecting against abuse and vetting clients|Robust due diligence for protecting against abuse and vetting clients|L4 Requirements| | ||
|Bookkeeping Plan||Minimal plan to document DataCap allocation decision and ready to provide justification when challenged or dispute|Base plan to document DataCap allocation decision and ready to provide justification when challenged or dispute|Detailed plan, with tooling, to document DataCap allocation decision and ready to provide justification when challenged or dispute|Detailed plan, with tooling and defined audit processes, to document DataCap allocation decision and ready to provide justification when challenged or dispute|L4 Requirements| | ||
|**Track Record**| Max(Past Allocations)| | ||
|Past Allocations||No previous track record | Successful allocation <100TB of DataCap. Justifications and audit trail can be produced when challenged|Successful allocation of 100TB of DataCap. Convincing justifications and audit trail can be produced when challenged|Successful allocation of 1PB of DataCap. Convincing justifications and audit trail can be produced when challenged|Successful allocation of 10PB of DataCap. Convincing justifications and audit trail can be produced when challenged| | ||
|**Scale of Allocation**|Max(DataCap Requested)| | ||
| DataCap Requested || <10TB | 10-100TB | 100TB- 1PB | 1-10PB | 10PB+ | | ||
|
||
#### Final Allocation Amount | ||
Final Allocation Amount = Min(Round(0.5*(Track Record) + 0.3*(Weighted Notary Leveling) + 0.2*(Concretness of Allocation Plan)), Scale of Allocation) | ||
|
||
## Automatic Disqualification | ||
The following criteria are grounds for automatic disqualification as a Notary: | ||
- Being found to be in violation of Filecoin's [Code of Conduct](https://github.com/filecoin-project/community/blob/master/CODE_OF_CONDUCT.md). | ||
- Severe or consistent acts of impropriety and abuse of one's role as Notary or as a Root Key Holder. Impropriety is defined as violating the Principles of this Mechanism, acting outside the remit of one's role (both as defined in this repository and as self-attested in the application process), or generally abusing the power entrusted to the role. Accusations of impropriety are expected to be filed via the [Disputes Mechanism](/README.md#dispute--audit-framework), where the accused will have an opportuntity to respond and justify their actions to the community. |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1 @@ | ||
TBD |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1 @@ | ||
TBD |
Oops, something went wrong.