added arch and concepts stubs
This commit is contained in:
mfahampshire
@@ -2,8 +2,8 @@
|
||||
"index": "Introduction",
|
||||
"concepts": "Core Concepts",
|
||||
"architecture": "Architecture",
|
||||
"traffic": "Traffic Flow",
|
||||
"cryptography": "Crypto",
|
||||
"traffic": "Traffic Flow",
|
||||
"rewards": "Rewards",
|
||||
"---": {
|
||||
"type": "separator"
|
||||
|
||||
@@ -0,0 +1,7 @@
|
||||
{
|
||||
"overview": "Overview",
|
||||
"mixnet": "Mixnet",
|
||||
"nyx": "Nyx Blockchain",
|
||||
"nym-vs-others": "Nym vs Other Platforms",
|
||||
"nym-not-p2p": "Why Nym is Not P2P"
|
||||
}
|
||||
@@ -0,0 +1,14 @@
|
||||
# Mixnet Components
|
||||
The mixnet is made up of nodes running in several different roles:
|
||||
* **Mix Nodes** provide network security for network content _and_ metadata by performing packet-mixing on traffic travelling through the network.
|
||||
* **Gateways** REWRITE act as message storage for clients which may go offline and come back online again, and defend against denial of service attacks. The default gateway implementation included in the Nym platform code holds packets for later retrieval. For many applications (such as simple chat), this is usable out of the box, as it provides a place that potentially offline clients can retrieve packets from. The access token allows clients to pull messages from the gateway node.
|
||||
* **Services** are applications that communicate with nym clients, listening and sending traffic to the mixnet. This is an umbrella term for a variety of different pieces of code, such as the Network Requester.
|
||||
|
||||
## Smoosh Status
|
||||
These were originally completely separate binaries. They are in the process of being 'smooshed' together into a single `nym-node` binary which runs in different modes.
|
||||
|
||||
Completed:
|
||||
* The `nym-network-requester` is now part of a `nym-node` running in as an Exit Gateway.
|
||||
|
||||
Upcoming:
|
||||
* Whether a `nym-node` is running as a Gateway or Mix Node will be set based on network conditions, and change epoch to epoch. Currently the role is set manually by the operator and does not change automatically over time.
|
||||
@@ -0,0 +1,5 @@
|
||||
{
|
||||
"nodes": "Nodes",
|
||||
"clients": "Clients",
|
||||
"archive": "Archive"
|
||||
}
|
||||
+7
-5
@@ -2,10 +2,12 @@
|
||||
|
||||
> The gateway setup and maintenance guide has migrated to the [Operator Guides book](https://nymtech.net/operators/nodes/gateway-setup.html).
|
||||
|
||||
Gateways are key to both the usability of the mixnet, and the operation of the mixnet's tokenomics. They serve two main functions:
|
||||
* In the future (when the mixnet is no longer running in 'free to use' mode), to check for zkNym credentials (previously referred to as [Coconut Credentials](../bandwidth-credentials.md)) with which users can anonymously prove they have paid to send traffic through the mixnet. A % of the worth of these credentials will be distributed to the operator of the gateway periodically as payment for providing their service. The more credentials user clients 'spend' with them, the higher the rewards for the gateway operator and their delegators will be. The rest of this value will be sent to the Mixmining Pool, a pool of tokens from which `NYM` rewards are distributed to mix node operators.
|
||||
* Act as a mailbox for connected clients. Clients create a lasting relationship with a gateway on initialisation, binding themselves to always use a particular gateway as their ingress point for mixnet traffic (this also means that this gateway is the egress point for any traffic sent _to_ this client - see the [mixnet traffic flow page](../architecture/traffic-flow.md) and the [addressing scheme](../architecture/addressing-system.md) for further details). If a client is offline and the Gateway can't deliver packets addressed to it, they will hold these packets until the client comes back online.
|
||||
REWRITE AND INCLUDE ALL THE STUFF ABOUT INGRESS AND EXIT GATEWAYS
|
||||
|
||||
## Further Reading
|
||||
* [Nym Whitepaper](https://nymtech.net/nym-whitepaper.pdf) section 4.2
|
||||
Gateways are key to both the usability of the mixnet, and the operation of the mixnet's tokenomics. They serve two main functions:
|
||||
* In the future (when the mixnet is no longer running in 'free to use' mode), to check for zkNym credentials (previously referred to as [Coconut Credentials](../bandwidth-credentials.md)) with which users can anonymously prove they have paid to send traffic through the mixnet. A % of the worth of these credentials will be distributed to the operator of the gateway periodically as payment for providing their service. The more credentials user clients 'spend' with them, the higher the rewards for the gateway operator and their delegators will be. The rest of this value will be sent to the Mixmining Pool, a pool of tokens from which `NYM` rewards are distributed to mix node operators.
|
||||
* Act as a mailbox for connected clients. Clients create a lasting relationship with a gateway on initialisation, binding themselves to always use a particular gateway as their ingress point for mixnet traffic (this also means that this gateway is the egress point for any traffic sent _to_ this client - see the [mixnet traffic flow page](../architecture/traffic-flow.md) and the [addressing scheme](../architecture/addressing-system.md) for further details). If a client is offline and the Gateway can't deliver packets addressed to it, they will hold these packets until the client comes back online.
|
||||
|
||||
## Further Reading
|
||||
* [Nym Whitepaper](https://nymtech.net/nym-whitepaper.pdf) section 4.2
|
||||
* [Nym Blog: Gateways to Privacy](https://blog.nymtech.net/gateways-to-privacy-51196005bf5)
|
||||
@@ -0,0 +1,49 @@
|
||||
# Nym Clients
|
||||
|
||||
A large proportion of the Nym mixnet's functionality is implemented client-side.
|
||||
|
||||
Clients perform the following actions on behalf of users:
|
||||
|
||||
* determine network topology - what nodes exist, their public encryption keys, etc.
|
||||
* register with a gateway
|
||||
* authenticate with a gateway
|
||||
* receive and decrypt messages from the gateway
|
||||
* create layer-encrypted Sphinx packets LINK
|
||||
* send Sphinx packets with real messages
|
||||
* send Sphinx packet _cover traffic_ when no real messages are being sent LINK
|
||||
* retransmit un-acknowledged packet sends - if a client sends 100 packets to a gateway, but only receives an acknowledgement ('ack') for 95 of them, it will resend those 5 packets to the gateway again, to make sure that all packets are received.
|
||||
|
||||
> at the moment due to the fact that the mixnet is primarily message based LINK, this requires another client on the 'other side' of the mixet to send packets to, unless you're using the `nymvpn` client (part of the NymVPN app) or the `socks5` client, which operates as a SOCKS4,4a, or 5 proxy. In the future we wish to remove this point of friction and have all nym clients construct IP packets.
|
||||
|
||||
## Types of Nym clients
|
||||
At present, there are three Nym clients:
|
||||
|
||||
- the websocket (native) client
|
||||
- the SOCKS5 client
|
||||
- the wasm (webassembly) client
|
||||
|
||||
You need to choose which one you want incorporate into your app. Which one you use will depend largely on your preferred programming style and the purpose of your app.
|
||||
|
||||
> Technically there is a fourth client used by the NymVPN app: certain bits of functionality such as the creation of IP packets will be pulled into the three other clients in the future.
|
||||
|
||||
### The websocket client
|
||||
Your first option is the native websocket client (`nym-client`). This is a compiled program that can run on Linux, Mac OS X, and Windows machines. It can be run as a persistent process on a desktop or server machine. You can connect to it with **any language that supports websockets**.
|
||||
|
||||
> Rust developers can import websocket client functionality into their code via the [Rust SDK](../sdk/rust/rust.md).
|
||||
|
||||
### The webassembly client
|
||||
If you're working in JavaScript or Typescript in the browser, or building an [edge computing](https://en.wikipedia.org/wiki/Edge_computing) app, you'll likely want to choose the webassembly client.
|
||||
|
||||
It's packaged and [available on the npm registry](https://www.npmjs.com/package/@nymproject/nym-client-wasm), so you can `npm install` it into your JavaScript or TypeScript application.
|
||||
|
||||
> The webassembly client is most easily used via the [Typescript SDK](../sdk/typescript.md). Typescript developers who wish to send API requests through the mixnet can can also check the [`mixfetch`]() package.
|
||||
|
||||
### The SOCKS5 client
|
||||
The `nym-socks5-client` is useful for allowing existing applications to use the Nym mixnet without any code changes. All that's necessary is that they can use one of the SOCKS5, SOCKS4a, or SOCKS4 proxy protocols (which many applications can - crypto wallets, browsers, chat applications etc).
|
||||
|
||||
When used as a standalone client, it's less flexible as a way of writing custom applications than the other clients, but able to be used to proxy application traffic through the mixnet without having to make any code changes.
|
||||
|
||||
_Rust developers can import socks client functionality into their code via the [Rust SDK](../sdk/rust/rust.md)_.
|
||||
|
||||
## Commonalities between clients
|
||||
All Nym client packages present basically the same capabilities to the privacy application developer. They need to run as a persistent process in order to stay connected and ready to receive any incoming messages from their gateway nodes. They register and authenticate to gateways, encrypt/decrypt Sphinx packets, and produce and send cover traffic LINK.
|
||||
@@ -1,49 +0,0 @@
|
||||
# Network Overview
|
||||
|
||||
Nym is a privacy platform. It provides strong network-level privacy against sophisticated end-to-end attackers, and anonymous access control using blinded, re-randomizable, decentralized credentials. Our goal is to allow developers to build new applications, or upgrade existing apps, with privacy features unavailable in other systems.
|
||||
|
||||
The Nym platform knits together several privacy technologies, integrating them into a system of cooperating networked nodes.
|
||||
|
||||
At a high level, our technologies include:
|
||||
|
||||
* a **mixnet**, which encrypts and mixes Sphinx packet traffic so that it cannot be determined who is communicating with whom. Our mixnet is based on a modified version of the **Loopix** design.
|
||||
* a privacy enhancing signature scheme called **Coconut**. Coconut allows a shift in thinking about resource access control, from an identity-based paradigm based on _who you are_ to a privacy-preserving paradigm based on _right to use_.
|
||||
* **Sphinx**, a way of transmitting armoured, layer-encrypted information packets which are indistinguishable from each other at a binary level.
|
||||
* the **Nyx** blockchain, a general-purpose CosmWasm-enabled smart contract platform, and the home of the smart contracts which keep track of the mixnet.
|
||||
|
||||
The most important thing to note is that these technologies ensure privacy at two different levels of the stack: **network data transmission**, and **transactions**.
|
||||
|
||||
Here's an overview diagram of the different types of nodes making up the network:
|
||||
|
||||
|
||||
|
||||
Developers can think of the network as being comprised of **infrastructure nodes** and **clients** for interacting with this infrastructure via **P**rivacy-**e**nhanced **app**lications (PEApps).
|
||||
|
||||
## Mixnet Infrastructure
|
||||
The mixnet - the different pieces of software that your traffic will pass through when using an privacy-enhanced app (PEApp) - is made up of several different types of nodes:
|
||||
|
||||
* **Mix Nodes** provide network security for network content _and_ metadata, making it impossible to see who is communicating with who, by performing packet-mixing on traffic travelling through the network.
|
||||
|
||||
* **Gateways** act as message storage for clients which may go offline and come back online again, and defend against denial of service attacks. The default gateway implementation included in the Nym platform code holds packets for later retrieval. For many applications (such as simple chat), this is usable out of the box, as it provides a place that potentially offline clients can retrieve packets from. The access token allows clients to pull messages from the gateway node.
|
||||
|
||||
* **Services** are applications that communicate with nym clients, listening and sending traffic to the mixnet. This is an umbrella term for a variety of different pieces of code, such as the network requester binary.
|
||||
|
||||
* **Nyx Blockchain Validators** secure the network with proof-of-stake Sybil defenses, determine which nodes are included within the network, and work together to create Coconut threshold credentials which provide anonymous access to data and resources. They also produce blocks and secure the Nyx Blockchain. Initially, this chain was used only to house the CosmWasm smart contracts keeping track of Nym's network topology, token vesting contracts, and the `NYM` token itself. In recent months, we've decided to expand the role of Nyx and instead expand its role by making it an open smart contract platform for anyone to upload CosmWasm smart contracts to. Validators also provide privacy-enhanced credentials based on the testimony of a set of decentralized, blockchain-based issuing authorities. Nym validators use the [Coconut](https://arxiv.org/abs/1802.07344) [signature scheme](https://en.wikipedia.org/wiki/Digital_signature) to issue credentials. This allows privacy apps to generate anonymous resource claims through decentralised authorities, then use them with Service Providers.
|
||||
|
||||
## Privacy-enhanced applications (PEApps)
|
||||
PEApps use a Nym client to connect to the network in order to get the available Network Topology for traffic routing, and send/receive packets to other users and services. Clients, in order to send traffic through the mixnet, connect to gateways. Since applications may go online and offline, a client's gateway provides a sort of mailbox where apps can receive their messages.
|
||||
|
||||
Nym clients connect to gateways. Messages are automatically piped to connected clients and deleted from the gateway's disk storage. If a client is offline when a message arrives, it will be stored for later retrieval. When the client connects, all messages will be delivered, and deleted from the gateway's disk.
|
||||
|
||||
When it starts up, a client registers itself with a gateway, and the gateway returns an access token. The access token plus the gateway's IP can then be used as a form of addressing for delivering packets.
|
||||
|
||||
There are two basic kinds of privacy enhanced applications:
|
||||
|
||||
* **Client apps** running on mobile or desktop devices. These will typically expose a user interface (UI) to a human user. These might be existing apps such as crypto wallets that communicate with Nym via our SOCKS5 proxy, or entirely new apps.
|
||||
* **Service Providers**, which will usually run on a server, and take actions on behalf of users without knowing who they are.
|
||||
|
||||
Service Providers (SPs) may interact with external systems on behalf of a user. For example, an SP might submit a Bitcoin, Ethereum or Cosmos transaction, proxy a network request, talk to a chat server, or provide anonymous access to a medical system such as a [privacy-friendly coronavirus tracker](https://constructiveproof.com/posts/2020-04-24-coronavirus-tracking-app-privacy/).
|
||||
|
||||
There is also a special category of Service Provider, namely SPs that do not visibly interact with any external systems. You might think of these as crypto-utopiapps: they're doing something, but it's not possible from outside to say with any certainty what their function is, or who is interacting with them.
|
||||
|
||||
All apps talk with gateways using Sphinx packets and a small set of simple control messages. These messages are sent to gateways over websockets. Each app client has a long-lived relationship with its gateway; Nym defines messages for clients registering and authenticating with gateways, as well as sending encrypted Sphinx packets.
|
||||
@@ -1,45 +0,0 @@
|
||||
# Network Rewards
|
||||
|
||||
Node operator and delegator rewards are determined according to the principles laid out in the section 6 of [Nym Whitepaper](https://nymtech.net/nym-whitepaper.pdf).
|
||||
|
||||
Below is a TLDR of the variables and formulas involved in calculating these rewards per epoch. The initial reward pool contains 250 million NYM, leaving a circulating supply of 750 million NYM.
|
||||
|
||||
|Symbol|Definition|
|
||||
|---|---|
|
||||
|<img src="https://render.githubusercontent.com/render/math?math=R"></img>|global share of rewards available, starts at 2% of the reward pool.
|
||||
|<img src="https://render.githubusercontent.com/render/math?math=R_{i}"></img>|node reward for mixnode `i`.
|
||||
|<img src="https://render.githubusercontent.com/render/math?math=\sigma_{i}"></img>|ratio of total node stake (node bond + all delegations) to the token circulating supply.
|
||||
|<img src="https://render.githubusercontent.com/render/math?math=\lambda_{i}"></img>|ratio of stake operator has pledged to their node to the token circulating supply.
|
||||
|<img src="https://render.githubusercontent.com/render/math?math=\omega_{i}"></img>|fraction of total effort undertaken by node `i`.
|
||||
|<img src="https://render.githubusercontent.com/render/math?math=k"></img>|number of nodes stakeholders are incentivised to create, set by the validators, a matter of governance. Currently determined by the reward set size.
|
||||
|<img src="https://render.githubusercontent.com/render/math?math=\alpha"></img>|Sybil attack resistance parameter - the higher this parameter is set the stronger the reduction in competitivness gets for a Sybil attacker.
|
||||
|<img src="https://render.githubusercontent.com/render/math?math=PM_{i}"></img>|declared profit margin of operator `i`.
|
||||
|<img src="https://render.githubusercontent.com/render/math?math=PF_{i}"></img>|uptime of node `i`, scaled to 0 - 1, for the rewarding epoch
|
||||
|<img src="https://render.githubusercontent.com/render/math?math=PP_{i}"></img>|cost of operating node `i` for the duration of the rewarding eopoch.
|
||||
|
||||
Node reward for node `i` is determined as:
|
||||
|
||||
<img src="https://render.githubusercontent.com/render/math?math=R_{i}=PF_{i} \cdot R \cdot (\sigma^'_{i} \cdot \omega_{i} \cdot k %2b \alpha \cdot \lambda^'_{i} \cdot \sigma^'_{i} \cdot k)/(1 %2b \alpha)"></img>
|
||||
|
||||
|
||||
where:
|
||||
|
||||
<img src="https://render.githubusercontent.com/render/math?math=\sigma^'_{i} = min\{\sigma_{i}, 1/k\}"></img>
|
||||
|
||||
|
||||
and
|
||||
|
||||
<img src="https://render.githubusercontent.com/render/math?math=\lambda^'_{i} = min\{\lambda_{i}, 1/k\}"></img>
|
||||
|
||||
|
||||
Operator of node `i` is credited with the following amount:
|
||||
|
||||
<img src="https://render.githubusercontent.com/render/math?math=min\{PP_{i},R_{i}\} %2b max\{0, (PM_{i} %2b (1 - PM_{i}) \cdot \lambda_{i}/\delta_{i}) \cdot (R_{i} - PP_{i})\}"></img>
|
||||
|
||||
|
||||
Delegate with stake `s` recieves:
|
||||
|
||||
<img src="https://render.githubusercontent.com/render/math?math=max\{0, (1-PM_{i}) \cdot (s^'/\sigma_{i}) \cdot (R_{i} - PP_{i})\}"></img>
|
||||
|
||||
|
||||
where `s'` is stake `s` scaled over total token circulating supply.
|
||||
@@ -1,7 +0,0 @@
|
||||
# Node Types
|
||||
|
||||
```admonish info
|
||||
We are working on a detailed description of how each component of Nym Mixnet and Nyx blockchain functions, as well as references to any literature and technical specs.
|
||||
|
||||
Meanwhile please refer to our [**Operators Guide**](https://nymtech.net/operators) book.
|
||||
```
|
||||
@@ -1,9 +1,5 @@
|
||||
# Nym vs Other Systems
|
||||
|
||||
### Why use Nym: Understanding the Significance of Nym
|
||||
|
||||
Nym is the first system we're aware of which provides integrated protection on both the network and transaction level at once. This seamless approach gives the best possible privacy protections, ensuring that nothing falls through the cracks between systems.
|
||||
|
||||
The diagram and brief explainer texts below give a high level overview of the difference between Nym and other comparable systems.
|
||||
|
||||
> If you want to dig more deeply into the way traffic is packetised and moved through the mixnet, check out the [Mixnet Traffic Flow](https://nymtech.net/docs/architecture/traffic-flow.html) page of the docs.
|
||||
|
||||
@@ -0,0 +1,16 @@
|
||||
# Network Components
|
||||
|
||||
The Nym platform knits together several privacy technologies, integrating them into a system of cooperating networked nodes in order to provide network-level privacy and metadata anonymity.
|
||||
|
||||
The core components are:
|
||||
* a **mixnet**, which encrypts and mixes Sphinx packet traffic so that it cannot be determined who is communicating with whom. Our mixnet is based on a modified version of the **Loopix TODO LINK** design.
|
||||
* a privacy enhancing signature scheme called **zk-nym**, based on the Coconut and Ecash schemes. This allows a shift in thinking about resource access control, from an identity-based paradigm based on _who you are_ to a privacy-preserving paradigm based on _right to use_.
|
||||
* **Sphinx**, a way of transmitting armoured, layer-encrypted information packets which are indistinguishable from each other at a binary level.
|
||||
* A CosmWasm-enabled blockchain called **Nyx**, the home of the various smart contracts used by the mixnet.
|
||||
|
||||
|
||||
TODO REDO DIAGRAM
|
||||
|
||||
|
||||
|
||||
* **Nyx Blockchain Validators** secure the network with proof-of-stake Sybil defenses, determine which nodes are included within the network, and work together to create Coconut threshold credentials which provide anonymous access to data and resources. They also produce blocks and secure the Nyx Blockchain. Initially, this chain was used only to house the CosmWasm smart contracts keeping track of Nym's network topology, token vesting contracts, and the `NYM` token itself. In recent months, we've decided to expand the role of Nyx and instead expand its role by making it an open smart contract platform for anyone to upload CosmWasm smart contracts to. Validators also provide privacy-enhanced credentials based on the testimony of a set of decentralized, blockchain-based issuing authorities. Nym validators use the [Coconut](https://arxiv.org/abs/1802.07344) [signature scheme](https://en.wikipedia.org/wiki/Digital_signature) to issue credentials. This allows privacy apps to generate anonymous resource claims through decentralised authorities, then use them with Service Providers.
|
||||
@@ -1,3 +1,5 @@
|
||||
# Introduction
|
||||
|
||||
Nym's network documentation covering network architecture, crypto systems, etc.
|
||||
Nym's network documentation covering network architecture, node types, tokenomics, and crypto systems.
|
||||
|
||||
TODO INCLUDE SITEMAP COMPONENT FOR SUBDIR
|
||||
|
||||
@@ -1 +1,45 @@
|
||||
TODO maybe make dir
|
||||
# Network Rewards
|
||||
|
||||
Node operator and delegator rewards are determined according to the principles laid out in the section 6 of [Nym Whitepaper](https://nymtech.net/nym-whitepaper.pdf).
|
||||
|
||||
Below is a TLDR of the variables and formulas involved in calculating these rewards per epoch. The initial reward pool contains 250 million NYM, leaving a circulating supply of 750 million NYM.
|
||||
|
||||
|Symbol|Definition|
|
||||
|---|---|
|
||||
|<img src="https://render.githubusercontent.com/render/math?math=R"></img>|global share of rewards available, starts at 2% of the reward pool.
|
||||
|<img src="https://render.githubusercontent.com/render/math?math=R_{i}"></img>|node reward for mixnode `i`.
|
||||
|<img src="https://render.githubusercontent.com/render/math?math=\sigma_{i}"></img>|ratio of total node stake (node bond + all delegations) to the token circulating supply.
|
||||
|<img src="https://render.githubusercontent.com/render/math?math=\lambda_{i}"></img>|ratio of stake operator has pledged to their node to the token circulating supply.
|
||||
|<img src="https://render.githubusercontent.com/render/math?math=\omega_{i}"></img>|fraction of total effort undertaken by node `i`.
|
||||
|<img src="https://render.githubusercontent.com/render/math?math=k"></img>|number of nodes stakeholders are incentivised to create, set by the validators, a matter of governance. Currently determined by the reward set size.
|
||||
|<img src="https://render.githubusercontent.com/render/math?math=\alpha"></img>|Sybil attack resistance parameter - the higher this parameter is set the stronger the reduction in competitivness gets for a Sybil attacker.
|
||||
|<img src="https://render.githubusercontent.com/render/math?math=PM_{i}"></img>|declared profit margin of operator `i`.
|
||||
|<img src="https://render.githubusercontent.com/render/math?math=PF_{i}"></img>|uptime of node `i`, scaled to 0 - 1, for the rewarding epoch
|
||||
|<img src="https://render.githubusercontent.com/render/math?math=PP_{i}"></img>|cost of operating node `i` for the duration of the rewarding eopoch.
|
||||
|
||||
Node reward for node `i` is determined as:
|
||||
|
||||
<img src="https://render.githubusercontent.com/render/math?math=R_{i}=PF_{i} \cdot R \cdot (\sigma^'_{i} \cdot \omega_{i} \cdot k %2b \alpha \cdot \lambda^'_{i} \cdot \sigma^'_{i} \cdot k)/(1 %2b \alpha)"></img>
|
||||
|
||||
|
||||
where:
|
||||
|
||||
<img src="https://render.githubusercontent.com/render/math?math=\sigma^'_{i} = min\{\sigma_{i}, 1/k\}"></img>
|
||||
|
||||
|
||||
and
|
||||
|
||||
<img src="https://render.githubusercontent.com/render/math?math=\lambda^'_{i} = min\{\lambda_{i}, 1/k\}"></img>
|
||||
|
||||
|
||||
Operator of node `i` is credited with the following amount:
|
||||
|
||||
<img src="https://render.githubusercontent.com/render/math?math=min\{PP_{i},R_{i}\} %2b max\{0, (PM_{i} %2b (1 - PM_{i}) \cdot \lambda_{i}/\delta_{i}) \cdot (R_{i} - PP_{i})\}"></img>
|
||||
|
||||
|
||||
Delegate with stake `s` recieves:
|
||||
|
||||
<img src="https://render.githubusercontent.com/render/math?math=max\{0, (1-PM_{i}) \cdot (s^'/\sigma_{i}) \cdot (R_{i} - PP_{i})\}"></img>
|
||||
|
||||
|
||||
where `s'` is stake `s` scaled over total token circulating supply.
|
||||
|
||||
Reference in New Issue
Block a user