diff --git a/docs/_static/build/.Rhistory b/docs/_static/build/.Rhistory new file mode 100644 index 00000000..e69de29b diff --git a/docs/crypto.rst b/docs/crypto.rst index fad32a7b..5bdfae72 100644 --- a/docs/crypto.rst +++ b/docs/crypto.rst @@ -10,5 +10,4 @@ research. Here are our current projects: :maxdepth: 1 crypto/multisig - Light client diff --git a/docs/polkadot/XCMP/index.md b/docs/polkadot/XCMP/index.md index 7d0d2306..ebbb487b 100644 --- a/docs/polkadot/XCMP/index.md +++ b/docs/polkadot/XCMP/index.md @@ -53,7 +53,7 @@ This restriction is enforced by allowing XCMP only between pairs of parachain wh ## Authentication for consistent history -A fork of the Polkadot relay chain defines a possible history of Polkadot. For parachains that refer to a particular relay chain history, we want to act on those messages and only those that were sent in this history. This means that we must use the relay chain to authenticate messages. To make this efficient and scalable we make it as light in computation and data storage as possible for the relay chain. To authenticate messages, a collator can include messages in a PoW block as follows: +A fork of the Polkadot relay chain defines a possible history of Polkadot. For parachains that refer to a particular relay chain history, we want to act on those messages and only those that were sent in this history. This means that we must use the relay chain to authenticate messages. To make this efficient and scalable we make it as light in computation and data storage as possible for the relay chain. To authenticate messages, a collator can include messages in a PoV block as follows: 1. A collator should find out from the relay chain what the latest messages for their parachain are, and then try to obtain those messages from the sending parachain. They can get these from validators who validated the sending parablock, full nodes of the sending chain or nodes of the receiving chain that already have them. diff --git a/docs/polkadot/economics.rst b/docs/polkadot/economics.rst index 5c43087d..f1091f46 100644 --- a/docs/polkadot/economics.rst +++ b/docs/polkadot/economics.rst @@ -10,6 +10,10 @@ Economics economics/* -This chapter covers the different economic aspects considered in the Polkadot protocol. It explains the fundamental mechanisms of the native token DOT, providing information on inflation, NPoS payments, and calculation of transaction fees. A substantial part of Polkadot’s value proposition is the ability to provide shared security for decentralized applications which can enter the ecosystem by docking onto the Relay Chain. Those Parachains are application-specific data structures that are globally coherent and validatable by the validators of the Relay Chain. The right to participate as a Parachain can be obtained by winning a Blockchain-specific candle auction format, for which we provide a game-theoretical analysis. +This chapter covers the economic research done at the Web3 Foundation. -In addition, this chapter holds sections insights from behavioral economic projects. +We use tools from microeconomics, behavioral economics, and game theory to analyze different aspects of the protocol. + +.. This chapter covers the different economic aspects considered in the Polkadot protocol. It explains the fundamental mechanisms of the native token DOT, providing information on inflation, NPoS payments, and calculation of transaction fees. A substantial part of Polkadot’s value proposition is the ability to provide shared security for decentralized applications which can enter the ecosystem by docking onto the Relay Chain. Those Parachains are application-specific data structures that are globally coherent and validatable by the validators of the Relay Chain. The right to participate as a Parachain can be obtained by winning a Blockchain-specific candle auction format, for which we provide a game-theoretical analysis. + +.. In addition, this chapter holds sections insights from behavioral economic projects. diff --git a/docs/polkadot/economics/behavioral-economics/1-validator-selection.md b/docs/polkadot/economics/1-validator-selection.md similarity index 100% rename from docs/polkadot/economics/behavioral-economics/1-validator-selection.md rename to docs/polkadot/economics/1-validator-selection.md diff --git a/docs/polkadot/economics/2-parachain-theory.md b/docs/polkadot/economics/2-parachain-theory.md new file mode 100644 index 00000000..a3eba474 --- /dev/null +++ b/docs/polkadot/economics/2-parachain-theory.md @@ -0,0 +1,17 @@ +==================================================================== + +**Authors**: Samuel Häfner and Alistair Stewart + +**Last updated**: April 17, 2021 + +==================================================================== + +# Theoretical Analysis of Parachain Auctions + +As explained [here](/polkadot/overview/3-parachain-allocation.md) and [here](https://wiki.polkadot.network/docs/en/learn-auction) Polkadot uses a candle auction format to allocate parachain slots. A candle auction is a dynamic auction with the distinguishing feature that the ending time is random. In this project, we analyze the effects of such a random-closing rule on equilibrium play when some bidders have front-running opportunities. + +Front-running opportunities emerge on blockchains because upcoming transaction become known among the network participants before they are included in new blocks. For blockchain implementations of auctions, this means that some bidders can see and potentially react to other bidders' bids before they come into effect; i.e., are recorded on the chain and are thus taken into account by the auction mechanism. In first-price auctions, this gives tech-savvy bidders the possibility to outbid other bidders as they please. In second-price auctions, the auctioneer could raise the payment of the winning bidder at no cost by registering his own (pseudonymous) bidder. + +Whereas cryptographic solutions to these problems exist, they are either very computing intensive or require multiple actions by the bidders. As an alternative that works without encrypting bids, this project analyzes a dynamic first-price auction with a random ending time. Time is discrete and in every round two bidders move sequentially in a fixed order. We show that a random-closing rule both revenue-dominates a hard-closing rule and makes participation for the bidder being front-run more attractive. In particular, under a uniform ending time distribution both the utility of the disadvantaged bidder and total revenues approach that of a second-price auction as the number of rounds grows large. Furthermore, the good is allocated efficiently. + +A direct link to [most recent version of the paper will be here.](/polkadot/economics/2-parachain-theory.md) diff --git a/docs/polkadot/economics/behavioral-economics/2-parachain-experiment.md b/docs/polkadot/economics/3-parachain-experiment.md similarity index 97% rename from docs/polkadot/economics/behavioral-economics/2-parachain-experiment.md rename to docs/polkadot/economics/3-parachain-experiment.md index 94a5b4ab..57f584cc 100644 --- a/docs/polkadot/economics/behavioral-economics/2-parachain-experiment.md +++ b/docs/polkadot/economics/3-parachain-experiment.md @@ -11,7 +11,7 @@ # Introduction ## Goals -The goal of this project is to gain some concept of the expected bidding behavior of participants in the upcoming [parachain candle auctions](../2-parachain-allocation.md) on Kusama/Polkadot. Currently, the planned format can be described as a multi-object first-price candle auction, which in that form has never been analyzed theoretically or empirically in the literature. +The goal of this project is to gain some concept of the expected bidding behavior of participants in the upcoming [parachain candle auctions](/polkadot/overview/3-parachain-allocation.md) on Kusama/Polkadot. Currently, the planned format can be described as a multi-object first-price candle auction, which in that form has never been analyzed theoretically or empirically in the literature. We will conduct an experimental investigation, with a design which models the basic mechanisms of the auction. The implementation is off-chain and follows standard experimental economics procedures, but mimics the key features of the blockchain (i.e., six second blocks, (potentially) transaction costs). Insights from the experiment can be used to gain an understanding of the bidding behavior, learn how organize the UI and potentially improve the overall design before going live. Generally, the project has the following goals: diff --git a/docs/polkadot/economics/4-gamification.md b/docs/polkadot/economics/4-gamification.md new file mode 100644 index 00000000..ed844466 --- /dev/null +++ b/docs/polkadot/economics/4-gamification.md @@ -0,0 +1,114 @@ +==================================================================== + +**Authors**: Jonas Gehrlein + +**Last updated**: 22.04.2021 + +==================================================================== + +# Non-monetary incentives for council members + +## Overview + +Behavioral economics has proven that non-monetary incentives are viable motivators and resemble an alternative to incentives created by money (see, e.g., [Frey & Gallus, 2015](https://www.bsfrey.ch/articles/C_600_2016.pdf)). This is especially true for environments where behavior is mainly driven by intrinsic motivation. In those situations, monetary incentives can even crowd-out the intrinsic behavior leading to less motivation ([Gneezy & Rustichini, 2000](https://academic.oup.com/qje/article-abstract/115/3/791/1828156)). The current advances in technologies surrounding Non-fungible Tokens (NFTs) can be utilized as an additional incentive layer for council member's engagement and participation. NFTs as tool can be perfectly combined with insights from the academic literature about the concept of "gamification" to foster engagement and reward good behavior. + +This can help improve on a few issues the network has today: Namely governance participation is low and staking behavior is not optimal. + +### Problem statement + +Governance is one of the most important aspects of the Polkadot ecosystem and relies on active participation both of the token holders and the elected council. However, turnout-rates of referenda are mostly below 5%, reaching super low rates of below 1% in some cases. To improve on that, the lottery pallet proposed for Kusama introduces monetary incentives to increase voting turnouts. + +In comparison to that, council members are expected to be less responsive to monetary incentives and might be better motivated with non-economic incentives. The proposed system is aimed mainly to improve on council member participation. This can easily be extended in the future for all token holders to incentivize good behavior (with regard to staking, and governance). + +### Goals + +The goals is to design a mechanism which automatically applies certain tools from gamification (e.g., badges, achievements, levels) to council members to... + +* ... promote the engagement and liveness of council members. +* ... use established techniques from the literature to improve on the whole council governance process. +* ... make it easier for users to evaluate and compare council members. + +Improving on all those domains would further strengthen the position of the network in the blockchain ecosystem. + +## Literature + +Gamification received increasing attention in the recent years and was even called the "most notable technological developments for human +engagement" ([Majuri et al., 2018](https://trepo.tuni.fi/bitstream/handle/10024/104598/gamification_of_education_2018.pdf)). It is used to enhance learning outcomes (e.g., [Denny, 2013](https://dl.acm.org/doi/abs/10.1145/2470654.2470763?casa_token=XsWtSZeFt-QAAAAA:MPWbtFfjzQZgWzyTI9hWROarJb1gJDWqDHNG4Fyozzvz3QIK-kMuMxfSwE26y9lKYUuZnV7aDZI)), model online communities (e.g., [Bista, 2012a](https://ieeexplore.ieee.org/abstract/document/6450959)) and improve sustainable behavior (e.g., [Berengueres et al., 2013](https://ieeexplore.ieee.org/abstract/document/6483512?casa_token=tmdUK7mtSSEAAAAA:ZxJnvYNAcuRaMHbwNqTJnahpbxal9xc9kHd6mY4lIahFhWn2Gmy32VDowMLVREQjwVIMhd9wcvY)). Gamification can be used as "means of supporting user engagement and enhancing positive patterns in service use, such as increasing user activity, social interaction, or quality and productivity of actions" ([Hamari, Koivisto & Sarsa, 2014](https://ieeexplore.ieee.org/abstract/document/6758978?casa_token=F2o_LQE-CNgAAAAA:vA_xBEe0ltKmMPRmTfkyW78LThHP9hLKK06oj1gKpOeDfoCTG7l_p-KSVlcdhNpaErLjzrm8p90)). While there is no agreed-upon definition, it can be best described as "a process of enhancing a service with affordances for gameful experiences in order to support user's [sic] overall value creation” ([Huotari & Hamari, 2012, p. 19](https://dl.acm.org/doi/abs/10.1145/2393132.2393137?casa_token=MU2yq2P4TOoAAAAA:Xuy9ZEzo2O7H-WCbqMheezkrodpab2DlFWkLjVt3jYExuP--vsjEROt4BKt5ZEbVou9rVnQSQBs)). That means, applying this concept does change the underlying service into a game but rather enriches it with motivational affordances popular in gaming (points, levels, badges, leaderboards) ([Deterding, 2012](https://dl.acm.org/doi/fullHtml/10.1145/2212877.2212883?casa_token=B9RD9ZPneIMAAAAA:34lrdGKwOUZyZu8fLobERuPLIBzNQxxwlgWLJnonn5Ws8Ya65aO_pdifhlHiSBwjDb0mWyFD0aM), [Hamari, Koivisto & Sarsa, 2014](https://ieeexplore.ieee.org/abstract/document/6758978?casa_token=F2o_LQE-CNgAAAAA:vA_xBEe0ltKmMPRmTfkyW78LThHP9hLKK06oj1gKpOeDfoCTG7l_p-KSVlcdhNpaErLjzrm8p90)). +Zichermann & Linder (2010) argue that that intrinsic motivation is unreliable and variable. Thereby, gamification can craft extrinsic motivators to internalize the intrinsically motivated behavior. It is crucial that this is done with non-economic incentives, because monetary incentives could lead to the crowding-out of intrinsic motivation ([Gneezy & Rustichini, 2000](https://academic.oup.com/qje/article-abstract/115/3/791/1828156)). A field where gamification has not yet been (explicitly) applied systematically is voting behavior (i.e., governance participation). One notable exception is a large-scale experiment with 61 million users of facebook, where researchers found that an *I voted* indication on their status page, could have been responsible for about 340'000 additional voters in the 2010 election ([Bond et al., 2012](https://www.nature.com/articles/nature11421) and [this article](https://www.nature.com/news/facebook-experiment-boosts-us-voter-turnout-1.11401)). The main driver here is considered to be peer-pressure elicited on facebook friends. While the researchers did not explicitly link this intervention with gamification, it could be perceived as such and might also work to incentivize participation of a small group. A similar application is the famous *I voted* badge in US elections, which has proven to be successful ([see](https://www.usvotefoundation.org/voter-reward-badge)). Voters like to show off badge and motivate others to go as well (some shops even offer perks for customers having that badge). + + A review on 91 scientific studies reveals that gamification provides overall positive effects in 71% of cases, 25% of cases no effect and only in 3% of studies were negative results reported ([Majuri et al., 2018](https://trepo.tuni.fi/bitstream/handle/10024/104598/gamification_of_education_2018.pdf)). such as increased engagement and enjoyment, while awcknowledging that the effectiveness is context-dependent. Despite the overwhelming majority of positive results, some studies indicate negative effects of gamification and suggest that there are some caveats. One source of negative effects are higher perceived competition of the interaction with peers, which could demotivate some users ([Hakulinen et al., 2013](https://ieeexplore.ieee.org/abstract/document/6542238)). Another reason for critique is the lack of clear theoretical foundation and the resulting diverse approach to the questions. + +The design process of the gamification elements can be further influenced by insights from related social science research. Namely how to counter some psychological biases affecting decision making in small committees as well as leveraging additionally motivational factors generated by *loss-aversion* and the resulting *endowment effect*. + +Literature has shown, that small decision making groups tend to suffer from *group think*. This bias describes the situation, where the outcome from the decision process is far from optimal, because the individuals of the group do not speak their opinions freely ([Janis, 1971](http://agcommtheory.pbworks.com/f/GroupThink.pdf)) or are influenced in a way that they act against their best knowledge (consciously or unconsciously). This issue arises especially in groups comprised of members with different power and status. Major disasters have been accounted to *group think*, such as the *Bay of Pigs Invasion* and the *Space Shuttle Challenger disaster* ([Janis, 1991](https://williamwolff.org/wp-content/uploads/2016/01/griffin-groupthink-challenger.pdf)). In later analyses it was found that there were plenty of evidence available, which had been willingful neglected by committee members. This problem is also related to the pressure to behave conform with authority figures, as illustrated by famous psychological experiments (e.g., [Milgram, 1963](https://www.demenzemedicinagenerale.net/pdf/MilgramOriginalWork.pdf), [Asch, 1961](https://psycnet.apa.org/record/1952-00803-001)). Fortunately, the current governance process already mitigates that problem by dividing the final decision between the council and all token holders. However, knowing about this issue, we can implement mechanisms to further improve the outcome of council decision making. A study by [MacDougall & Baum (1997)](https://journals.sagepub.com/doi/abs/10.1177/104973239700700407) has shown that explicitly announcing a "devil's advocate" can improve the outcome by challenging the consensus frequently. + +Studies in behavioral economics further show that individual decision making is influenced by *loss-aversion*. This results from a non-linear utility function with different shapes in the gain and loss domain of a subjective evaluation of an outcome relative to some reference point. Specifically, the absolute dis-utility of a loss is higher than the gain in utility of a corresponding gain ([Kahneman & Tversky, 1992](https://link.springer.com/article/10.1007/BF00122574)). A resulting effect of that is the *endowment effect* ([Kahneman, Knetsch & Thaler, 1990](https://www.journals.uchicago.edu/doi/abs/10.1086/261737)), which describes the situation where a good is valued much more only because of the fact of possessing it. A practical implication for design of incentive systems is that users are exerting higher effort to keep something once there is the option to lose it again. + + +In conclusion, a carefully designing gamified experience can improve the overall governance process and result in more active discussions, and hopefully better decisions. + + +## Awarding mechanism (WIP) +In general, the most commonly used gamification elements are ([Hamari, Koivisto & Sarsa, 2014](https://ieeexplore.ieee.org/abstract/document/6758978?casa_token=F2o_LQE-CNgAAAAA:vA_xBEe0ltKmMPRmTfkyW78LThHP9hLKK06oj1gKpOeDfoCTG7l_p-KSVlcdhNpaErLjzrm8p90)): + +* Points +* Badges (Trophies) +* Achievements +* Levels + +A very complex task is to design an automatic mechanism to award council members NFTs based on their on-chain (and potentially off-chain) behavior. On the one hand, focusing only on easily measurable outcome levels of participation (e.g., speed of voting, pure quantity of propositions) can easily backfire and are prone to be abused. In addition, it is hard to deduce the quality of a vote by those quantitative measurements. To mitigate this, it is important to observe the whole process and the later outcome of the election. + +On the other hand, only incentivizing positive election outcomes could make council members too conservative, only proposing winners, neglecting provocative but potentially beneficial proposals. The best strategy is to come up with a mix of different NFTs where the positive weights of the individual NFTs are less severe and therefore leave enough space for all behavior. + +In addition, the proposed NFTs should also incorporate important insights from social science research (as mentioned above e.g., to incorporate preventive measures against *Groupthink* or design some NFTs to leverage *Loss-Aversion*). + +### Achievements (static) + +Achievements are absolute steps to be reached and cannot be lost, once obtained. Potential triggers could be: + +* Become a council member + + +### Badges (perishable) +Generally, Badges are perishable and resemble an achievement relative to something. This means, once the relative status is lost, so is the badge. This is a very interesting concept as it incorporates the motivating factor of the *endowment-effect* (see literature section), where individuals exert higher motivation to hold on to the badge. + +Those are good to include states of the situation such as: + +* Be the most backed council member +* Be the oldest council member +* The devil's advocate (vote against the majority of other council members) + +### Levels (ranks) +Gaining certain badges could also mean we can implement some level system which could essentially sum up all the badges and achievements into one quantifiable metric. + +### Council actions +The following list, composed by Raul Romanutti, illustrates several frequent actions council members can perform and build a good basis of outcome variables to be entwined in an awarding mechanism. + +* Vote on a treasury proposal motion +* Vote on a runtime upgrade motion +* Vote on referendum +* Submit an external motion proposal +* Submit a regular motion to Council +* Submit an external motion to Council (we can have a lot of granularity here) +* Submit a preimage for a proposal +* Close a motion after majority is reached +* Submit a runtime upgrade motion to Council (external motion) +* Vote on a treasury proposal motion (proposed by community members) - how do we judge rejections here? +* Vote on an identity registrar proposal (proposed by community members) +* Endorse a tip proposal (proposed by community members or councillors) +* Open a tip to a community member +* Propose a Technical Committee nomination (proposed by councillors) +* Vote on a Technical Committee nomination +* Open a bounty proposal +* Vote on a bounty proposal +* Vote on a Bounty curator nomination (proposed by councillors) +* Open a motion to unassign a bounty curator +* Become the curator of an active bounty +* Propose an external motion for a specific chain to use a common-good chain slot +* Vote on an external motion for a specific chain to use a common-good chain slot + +## NFT Gallery +A prerequisite for NFTs to develop their motivating effect, it is necessary to visually display them and make them viewable in NFT galleries. This requires the support of wallets and explorers. Due to the popularity of NFTs, many of projects are currently working on those solutions and it is expected that solutions will further improve. + +As an additional benefit, governance focused applications could orderly display the council members, their achievements / badges and levels, which can make it also much more easy and enjoyable for nominators to compare and engage with the council members. This could substantially improve the turnout rates in council member elections, and results are more precise in representing the opinion of all stakeholders. This, in turn, would further increase the incentives exerted by the NFTs on the council members. + diff --git a/docs/polkadot/economics/behavioral-economics.rst b/docs/polkadot/economics/behavioral-economics.rst deleted file mode 100644 index 3b8d15a6..00000000 --- a/docs/polkadot/economics/behavioral-economics.rst +++ /dev/null @@ -1,14 +0,0 @@ -==================== -Behavioral Economics -==================== - - -.. toctree:: - :hidden: - :glob: - :maxdepth: 1 - - behavioral-economics/* - - -This chapter covers the research field of behavioral economics, which focuses on human interaction with the protocol and analyzes situations where the behavior of the users deviate from rational expectations. One such deviation stems from limited cognitive resources of users which complicate the efficient selection of suitable validators. To help the users, we are researching tools to provide an optimal selection based on user’s preferences. Another research area is the experimental investigation of the parachain slot auctions. \ No newline at end of file diff --git a/docs/polkadot/networking.rst b/docs/polkadot/networking.rst index 5d89b0f0..7b99a0e6 100644 --- a/docs/polkadot/networking.rst +++ b/docs/polkadot/networking.rst @@ -1,6 +1,6 @@ \==================================================================== -**Owners**: :doc:`/team_members/Ximin` +**Owners**: Ximin Luo **Other authors**: Fatemeh Shirazi, Rob Habermeier diff --git a/docs/polkadot/networking/1-parachains.rst b/docs/polkadot/networking/1-parachains.rst index 231b46b2..3ace66a6 100644 --- a/docs/polkadot/networking/1-parachains.rst +++ b/docs/polkadot/networking/1-parachains.rst @@ -1,6 +1,6 @@ \==================================================================== -**Owners**: :doc:`/team_members/Ximin` +**Owners**: Ximin Luo \==================================================================== diff --git a/docs/polkadot/networking/3-avail-valid.rst b/docs/polkadot/networking/3-avail-valid.rst index 0f4fbe01..288965e4 100644 --- a/docs/polkadot/networking/3-avail-valid.rst +++ b/docs/polkadot/networking/3-avail-valid.rst @@ -1,6 +1,6 @@ \==================================================================== -**Owners**: :doc:`/team_members/Ximin` +**Owners**: Ximin Luo \==================================================================== diff --git a/docs/polkadot/networking/4-xcmp.rst b/docs/polkadot/networking/4-xcmp.rst index ea630ead..1fc7f649 100644 --- a/docs/polkadot/networking/4-xcmp.rst +++ b/docs/polkadot/networking/4-xcmp.rst @@ -1,6 +1,6 @@ \==================================================================== -**Owners**: :doc:`/team_members/Ximin` +**Owners**: Ximin Luo **Other authors**: Rob Habermeier, Fatemeh Shirazi diff --git a/docs/polkadot/networking/L-authentication.rst b/docs/polkadot/networking/L-authentication.rst index 04a73799..8c32ef81 100644 --- a/docs/polkadot/networking/L-authentication.rst +++ b/docs/polkadot/networking/L-authentication.rst @@ -1,6 +1,6 @@ \==================================================================== -**Owners**: :doc:`/team_members/Ximin` +**Owners**: Ximin Luo \==================================================================== diff --git a/docs/polkadot/networking/L-discovery.rst b/docs/polkadot/networking/L-discovery.rst index 9427af8b..e80435ac 100644 --- a/docs/polkadot/networking/L-discovery.rst +++ b/docs/polkadot/networking/L-discovery.rst @@ -1,6 +1,6 @@ \==================================================================== -**Owners**: :doc:`/team_members/Ximin` +**Owners**: Ximin Luo \==================================================================== diff --git a/docs/polkadot/overview.rst b/docs/polkadot/overview.rst index 2c5d5692..b8c55769 100644 --- a/docs/polkadot/overview.rst +++ b/docs/polkadot/overview.rst @@ -4,11 +4,11 @@ Overview This chapter talks about the high-level design and architecture of Polkadot, including parachains functionality as well as interoperation with external -blockchains. - +blockchains. Other chapters include the token economics and the parachain allocation. .. toctree:: + :hidden: :glob: - :maxdepth: 1 + :maxdepth: 2 - index + overview/* diff --git a/docs/polkadot/index.md b/docs/polkadot/overview/1-polkadot-introduction.md similarity index 73% rename from docs/polkadot/index.md rename to docs/polkadot/overview/1-polkadot-introduction.md index 94bbc59e..77ccbd3f 100644 --- a/docs/polkadot/index.md +++ b/docs/polkadot/overview/1-polkadot-introduction.md @@ -1,25 +1,25 @@ -# Polkadot introduction +# Introduction -Polkadot consists of a main chain called the relay chain and multiple sharded chains called parachains. The relay chain is maintained by validators that are selected through the [NPoS scheme](NPoS/index.md#the-npos-scheme) and is responsible for producing blocks of the relay chain (via [BABE](block-production/Babe.md)) and keeping the state of all the parachains. -These validators need to vote on the consensus, see [GRANDPA](finality.md), over all the parachains blocks. For parachains, there are additional actors called collators and fishermen that are responsible for parachain block production and reporting invalid parachain blocks respectively. In the figure below an example cut-out of Polkadot with part of the relay chain, one parachain, three validators and five collators are shown. +Polkadot consists of a main chain called the relay chain and multiple sharded chains called parachains. The relay chain is maintained by validators that are selected through the [NPoS scheme](/polkadot/NPoS/index.md#the-npos-scheme) and is responsible for producing blocks of the relay chain (via [BABE](/polkadot/block-production/Babe.md)) and keeping the state of all the parachains. +These validators need to vote on the consensus, see [GRANDPA](/polkadot/finality.md), over all the parachains blocks. For parachains, there are additional actors called collators and fishermen that are responsible for parachain block production and reporting invalid parachain blocks respectively. In the figure below an example cut-out of Polkadot with part of the relay chain, one parachain, three validators and five collators are shown. -![Figure 1 - Relay chain, Validators, Parachain, and Collators](images/data_structure.png) +![Figure 1 - Relay chain, Validators, Parachain, and Collators](/polkadot/images/data_structure.png) -Validators are assigned to parachains, which are responsible for validating parachain blockd and keeping them available via the [A&V scheme](Availability_and_Validity.md). Moreover, another feature of Polkadot is enabling interchain messaging among parachains, called [XCMP](XCMP.md). +Validators are assigned to parachains, which are responsible for validating parachain blockd and keeping them available via the [A&V scheme](/polkadot/Availability_and_Validity.md). Moreover, another feature of Polkadot is enabling interchain messaging among parachains, called [XCMP](/polkadot/XCMP.md). -The security goal of Polkadot is to be Byzantine fault tolerant when the participants are rational. Rewards are given out when validators behave correctly and validators misbehaviour is punished via the [Slashing mechanism](slashing.md). More details on incentives and economics are reviewed [here](./economics/1-token-economics.md). +The security goal of Polkadot is to be Byzantine fault tolerant when the participants are rational. Rewards are given out when validators behave correctly and validators misbehaviour is punished via the [Slashing mechanism](/polkadot/slashing.md). More details on incentives and economics are reviewed [here](2-token-economics.md). -Furthermore, Polkadot has a decentralised governance scheme that can change any Polkadot design decisions and parameterisation. Details on low-level cryptographic primitives can be found [here](keys/index.md) and Polkadot's networking schemes is in progress with some details being reviewed [here](networking.html). +Furthermore, Polkadot has a decentralised governance scheme that can change any Polkadot design decisions and parameterisation. Details on low-level cryptographic primitives can be found [here](/polkadot/keys/index.md) and Polkadot's networking schemes is in progress with some details being reviewed [here](/polkadot/networking.html). -![Figure 2 - Data structures and participants](images/whole.png) +![Figure 2 - Data structures and participants](/polkadot/images/whole.png) **For other information regarding the project please refer to the [wiki page](https://wiki.polkadot.network).** -**We also provide implementation level specification of the protocol for the [host](specifications/host.md) as well as the [runtime](specifications/runtime.md).** +**We also provide implementation level specification of the protocol for the [host](/polkadot/specifications/host.md) as well as the [runtime](/polkadot/specifications/runtime.md).** ## High-level properties @@ -33,12 +33,12 @@ The research focuses on how to enable having such publicly available system in t So let us start with abstract state machines. A state machine has a certain state type and state transition type. As the time goes on, state transitions occur. -![Figure 1 - Block to transition](images/block_to_transition.png) +![Figure 1 - Block to transition](/polkadot/images/block_to_transition.png) The data that determines the state transitions is structured as bundles of transactions - individual small state transitions triggered by the users of the system. Each bundle is called a block. In order to achieve its properties, ensures that those blocks are hash connected forming joint data structure. -![Figure 2 -State transition properties](images/properties.png) +![Figure 2 -State transition properties](/polkadot/images/properties.png) ### 1 Utility @@ -48,7 +48,7 @@ Each state transition should bring some utility to the system participants. In o - state machines should provide some utility to participants - state transitions processed by these state machines reflect well the state transition needs of participants. -![Utility](images/usefulness.png) +![Utility](/polkadot/images/usefulness.png) To ensure that the state machines provide utility we should ensure that there is a mechansim that enables participants to decide what state machines should be included and how they should change to reflect participant needs. This mechanism is the [Polkadot governance scheme](https://github.com/paritytech/polkadot/wiki/Governance). @@ -56,35 +56,35 @@ To ensure that useful state transitions are processed by those state machines, w ### 2 Validity -![Validity](images/validity.png) +![Validity](/polkadot/images/validity.png) The notion of validity in Polkadot is determined by a state transition validation function (STVF). Each chain in the ecosystem has to have one implemented. In order for all nodes to be able to run this function it is being distributed as deterministic WebAssembly (Wasm) code which can be executed by the Polkadot Host. -The blocks are produced by parachain collators, then they get validated using the STVF by the subset of validators responsible for the given parachain to finally get included in the Polkadot Relay Chain. During this process validators, parachain collators and other parties are free to challenge claims of validity to trigger additional check, these parties are referred to as fishermen. [Read here about parachain validity](Availability_and_Validity.md). +The blocks are produced by parachain collators, then they get validated using the STVF by the subset of validators responsible for the given parachain to finally get included in the Polkadot Relay Chain. During this process validators, parachain collators and other parties are free to challenge claims of validity to trigger additional check, these parties are referred to as fishermen. [Read here about parachain validity](/polkadot/Availability_and_Validity.md). ### 3 Finality -![Finality](images/canonicality.png) +![Finality](/polkadot/images/canonicality.png) -Finality of the Polkadot network state machines is achieved via a combination of a block production mechanism with eventual probabilistic consistency ([BABE scheme](block-production/Babe.md)) and [GRANDPA finality gadget](finality.md). +Finality of the Polkadot network state machines is achieved via a combination of a block production mechanism with eventual probabilistic consistency ([BABE scheme](block-production/Babe.md)) and [GRANDPA finality gadget](/polkadot/finality.md). This approach allows for block production (thus transaction confirmations) to be fast, while allowing for as fast as possible economic finality with compact proofs. ### 4 Availability -![Availability](images/availability.png) +![Availability](/polkadot/images/availability.png) -In order for the critical data from all chains to remain reachable by users and subsequent block producers, Polkadot makes use of an erasure coding based [availability scheme](Availability_and_Validity.md). +In order for the critical data from all chains to remain reachable by users and subsequent block producers, Polkadot makes use of an erasure coding based [availability scheme](/polkadot/Availability_and_Validity.md). ### 5 Messaging reliability -![Messaging](images/messaging.png) +![Messaging](/polkadot/images/messaging.png) -Besides ensuring all the above properties for all parachain, a crucial element of Polkadot is that these state machines are able to affect each others state transitions. This is done via the [Cross-Chain Message Passing (XCMP) scheme](XCMP.md). +Besides ensuring all the above properties for all parachain, a crucial element of Polkadot is that these state machines are able to affect each others state transitions. This is done via the [Cross-Chain Message Passing (XCMP) scheme](/polkadot/XCMP.md). ### 6 Size -![Size](images/size.png) +![Size](/polkadot/images/size.png) To ensure that the state transitions can be processed and stored by the network their size has to be reasonable. Mechanisms such as transaction fees and block limits are there to limit the storage size and computation required for each block. diff --git a/docs/polkadot/economics/1-token-economics.md b/docs/polkadot/overview/2-token-economics.md similarity index 99% rename from docs/polkadot/economics/1-token-economics.md rename to docs/polkadot/overview/2-token-economics.md index 2090d14a..38b8b30e 100644 --- a/docs/polkadot/economics/1-token-economics.md +++ b/docs/polkadot/overview/2-token-economics.md @@ -87,9 +87,9 @@ __Adjustable parameter:__ Define the *decay rate* $d$ so that the inflation rate \begin{align} I_{NPoS}(x) &= \begin{cases} -I_0 + x\Big(i_{ideal} - \frac{I_0}{\chi_{ideal}}\Big) +I_0 + \Big(I_{NPoS}(\chi_{ideal}) - I_0\Big)\frac{x}{\chi_{ideal}} &\text{for } 0 \ No newline at end of file diff --git a/docs/team_members.rst b/docs/team_members.rst index 7396ad88..68630c8c 100644 --- a/docs/team_members.rst +++ b/docs/team_members.rst @@ -20,7 +20,6 @@ The core Web3 Foundation research team working on various areas relevant to dece team_members/samuel team_members/Sergey team_members/syed - team_members/Ximin Specification Team ================== diff --git a/docs/team_members/Ximin.md b/docs/team_members/Ximin.md deleted file mode 100644 index 0f55342f..00000000 --- a/docs/team_members/Ximin.md +++ /dev/null @@ -1,19 +0,0 @@ -# Ximin Luo - -ximin@web3.foundation - -Ximin is a research engineer at Web3 Foundation working on secure peer-to-peer networking. - -**Research Areas** - -Ultimately driven by the desire to see secure scalable and decentralised systems replace today's existing centralised computing systems that propagate hierarchical power relationships, Ximin's interests span a wide range of topics including: gossiping protocols, structured and unstructured peer-to-peer routing schemes, coding and secret-sharing schemes, consensus protocols, messaging protocols, decentralised naming schemes, distributed hash tables, verifiable distributed data structures, voting protocols, group authentication and applied cryptography. - -He tends to write code and documentation over papers. - -**Short Bio** - -Elsewhere Ximin is an active [Debian Developer](https://qa.debian.org/developer.php?login=infinity0) and has contributed to Debian since 2010. Among other responsibilities, he maintains the rust compiler there and helps run the [Debian Rust team](https://salsa.debian.org/rust-team). He also regularly contributes to many other free software projects. - -He previously worked on [DFINITY](https://dfinity.org), [Reproducible Builds](https://reproducible-builds.org), e2e group chat at [MEGA](https://mega.nz), anti-censorship at [Tor](https://www.torproject.org), and [Freenet](https://freenetproject.org). Before all of that he graduated out of [Cambridge, UK](https://www.cam.ac.uk) and was also at [Google](https://www.google.com) for a couple of years. - -After too much time spent writing Java "design pattern" boilerplate and debugging inane JavaScript runtime errors, he got interested in strongly-typed functional programming languages. These days he prefers writing large secure scalable systems in [Haskell](https://haskell.org) or [Rust](https:www.rust-lang.org) or [OCaml](https://ocaml.org). He might get into [Agda](https://wiki.portal.chalmers.se/agda/pmwiki.php) or [Idris](https://www.idris-lang.org/) some day.